Ingenieria Del Software - Roger S. Pressman 6ta Edicion2 PDF

Roger S.
Pressman
Sexf a edi ci n
N
C r<
r i
y
/
D FTWAR
Un enfoque prctico
Me
Graw
u U
I /
* 3%&*$>
TM
PDF Editor
CONTENI DO BREVE
CAPITULO 1 Software e ingeniera del software 1
PARTE UNO El proceso del software 21
PARTE DOS
CAPTULO 2 El proceso: una visin general 2 2
CAPTULO 3 Modelos prescriptivos de proceso 4 8
CAPITULO 4 Desarrollo gil 7 7
Prctica de la ingeniera del software 103
CAPTULO 5 La prctica: una visin genrica 104
CAPTULO 6 Ingeniera de sistemas 1 33
CAPTULO 7 Ingeniera de requisitos 155
CAPTULO 8 Model ado del anlisis 191
CAPTULO 9 Ingeniera del diseo 2 4 5
CAPITULO 10 Diseo arquitectnico 2 7 5
CAPTULO 11 Diseo al nivel de componentes 3 1 5
CAPTULO 12 Diseo de la interfaz de usuario 3 5 0
CAPTULO 13 Estrategias de prueba del software 3 8 2
CAPTULO 14 Tcnicas de prueba del software 4 1 8
CAPITULO 15 Mtricas del producto para el software 4 6 2
PASTE TRES Aplicacin de la ingeniera Web 501
CAPTULO 16 Ingeniera We b 5 0 2
CAPTULO 17 Formulacin y planeacin para ingeniera We b 5 1 7
CAPTULO 18 Modelado de anlisis para aplicaciones We b 5 4 4
CAPITULO 19 Modelado de diseo para aplicaciones We b 5 6 6
CAPTULO 20 Cmo probar aplicaciones Web 6 0 4
PARTE CUATRO Gestin de proyectos de software 639
CAPTULO 21 Conceptos de gestin de proyectos 6 4 0
CAPTULO 22 Mtricas de proceso y proyecto 6 6 3
CAPITULO 23 Estimacin para proyectos de software 6 9 0
CAPTULO 24 Calendarizacin de proyectos de software 7 2 4
CAPTULO 25 Gestin del riesgo 747
CAPITULO 26 Gestin de la calidad 767
CAPTULO 27 Gestin del cambio 796
vii
TM
PDF Editor
viii CONTENIDO BREVE
PARTE CINCO Temas avanzados en ingeniera del software 829
CAPTULO 28 Mtodos formales 8 3 0
CAPTULO 29 Ingeniera del software de sala limpia 8 5 8
CAPITULO 30 Ingeniera del software basada en componentes 8 7 9
CAPITULO 31 Reingeniera 9 0 2
CAPITULO 32 El camino por recorrer 9 2 7
TM
PDF Editor
CONT E NI DO
Prefacio xxviii
Recorrido xxxi
CAPTULO 1 SOFTWARE E INGENIERIA DEL SOFTWARE 1
1.1 El papel evolutivo del software 2
1.2 Software 5
1.3 La naturaleza cambiante del software 8
1.4 Software heredado 1 1
1.4.1 Calidad del software heredado
1.4.2 Evolucin del software 12
1. 5 Mitos del software 14
1.6 Cmo inicia todo 17
1.7 Resumen 18
Referencias 18
Problemas y puntos a considerar 19
Otras lecturas y fuentes de informacin 20
PARTE UNO: EL PROCESO DEL SOFTWARE 21
CAPITULO 2 EL PROCESO: UNA VISION GENERAL 22
2.1 Ingeniera del software: una tecnologa estratificada 23
2. 2 Marco de trabajo para el proceso 24
2. 3 Integracin del modelo de capacidad de madurez (IMCM| 29
2. 4 Patrones del proceso 34
2. 5 Evaluacin del proceso 36
2. 6 Modelos de proceso personales y en equipo 38
2. 6. 1 Proceso de software personal (PSP) 39
2. 6. 2 Procesos de software en equipo (PSE) 40
2. 7 Tecnologa del proceso 42
2. 8 Producto y proceso 43
2. 9 Resumen 44
Referencias 45
Otras lecturas y fuentes de informacin 4 7
CAPTULO 3 MODELOS PRESCRIPTIVOS DE PROCESO 48
3.1 Modelos prescriptivos 4 9
3. 2 El modelo en cascada 50
3. 3 Modelos de proceso incrementles 51
3. 3. 1 El modelo incremental 52
3. 3. 2 El modelo DRA 53
i x
TM
PDF Editor
CONTENIDO
3. 4 Modelos de proceso evolutivos 54
3. 4. 1 Construccin de prototipos 55
3. 4. 2 El modelo en espiral 58
3. 4. 3 El modelo de desarrollo concurrente 6 0
3. 4. 4 Un comentario final sobre los procesos evolutivos 61
3. 5 Modelos especializados de proceso 63
3. 5. 1 Desarrollo basado en componentes 63
3. 5. 2 El modelo de mtodos formales 64
3. 5. 3 Desarrollo del software orientado a aspectos 65
3. 6 El proceso unificado 6 7
3. 6. 1 Una breve historia 6 7
3. 6. 2 Fases del proceso unificado 6 8
3. 6. 3 Productos de trabajo del proceso unificado 71
3. 7 Resumen 7 2
Referencias 73
Problemas y puntos o considerar 74
CAPTULO 4 DESARROLLO GIL 77
4. 1 Qu es la agilidad? 7 9
4. 2 Qu es un proceso gil? 81
4. 2. 1 Las polticas del desarrollo gil 81
4. 2. 2 Factores humanos 82
4. 3 Modelos giles de proceso 84
4. 3. 1 Programacin extrema |PE) 84
4. 3. 2 Desarrollo adaptativo de software (DAS) 8 9
4. 3 .3 Mtodo de desarrollo de sistemas dinmicos (MDSD) 91
4. 3. 4 Mel 9 2
4. 3. 5 Cristal 9 5
4. 3. 6 Desarrollo conducido por caractersticas |DCC| 95
4. 3. 7 Modelado gil |MA) 9 7
4. 4 Resumen 9 9
Referencias 100
PARTE DOS: PRCTICA DE LA INGENIERA DEL SOFTWARE 103
CAPTULO 5 LA PRACTICA: UNA VISIN GENRICA 104
5. 1 La prctica de la ingeniera del software 105
5. 1. 1 La esencia de la prctica 106
5. 1. 2 Principios esenciales 107
5. 2 Prcticas de comunicacin 109
5. 3 Prcticas de la planeacin 1 1 3
5 .4 Prctica del modelado 116
TM
PDF Editor
CONTENIDO
x i
5. 4. 1 Principios del modelado del anlisis 117
5. 4. 2 Principios de modelado del diseo 119
5. 5 Prctica de la construccin 122
5. 5. 1 Principios y conceptos de codificacin 123
5. 5. 2 Principios de las pruebas 124
5. 6 Despliegue 126
5.7 Resumen 128
Referencias 129
Problemas y puntos o considerar 130
CAPTULO 6 INGENIERA DE SISTEMAS 133
6. 1 Sistemas basados en computadora 134
6. 2 La jerarqua de la ingeniera de sistemas 1 36
6. 2. 1 Modelado del sistema 137
6. 2. 2 Simulacin del sistema 139
6. 3 Ingeniera de procesos de negocios: una visin general 140
6. 4 Ingeniera de producto: una visin general 142
6. 5 Modelado del sistema 144
6. 5. 1 Modelado Hatley-Pirbhai 144
6. 5. 2 Modelado del sistema con UML 147
6. 6 Resumen 151
Referencias 152
CAPTULO 7 INGENIERA DE REQUISITOS 155
7. 1 Un puente hacia el diseo y la construccin 156
7. 2 Tareas de la ingeniera de requisitos 157
7. 2. 1 Inicio 158
7. 2. 2 Obtencin 158
7. 2. 3 Elaboracin 159
7. 2. 4 Negociacin 160
7. 2. 5 Especificacin 160
7. 2. 6 Validacin 161
7. 2. 7 Gestin de requisitos 161
7. 3 Inicio del proceso de la ingeniera de requisitos 163
7. 3. 1 Identificacin de los interesados 164
7. 3. 2 Reconocimiento de mltiples puntos de vista 164
7. 3. 3 Trabajo con respecto a la colaboracin 164
7. 3. 4 Formulacin de las primeras preguntas 165
7. 4 Obtencin de requisitos 166
7. 4. 1 Recopilacin conjunta de requisitos 167
7. 4. 2 Despliegue de la funcin de calidad 171
7. 4. 3 Escenarios del usuario 172
TM
PDF Editor
CONTENIDO
7. 4. 4 Productos de trabajo de la obtencin 173
7. 5 Desarrollo de casos de uso 173
7. 6 Construccin del modelo de anlisis 179
7. 6. 1 Elementos del modeb de anlisis 179
7. 6. 2 Patrones de anlisis I 83
7. 7 Negociacin de requisitos 1 84
7. 8 Validacin de requisitos 186
7. 9 Resumen 186
Referencias 187
Problemas y puntos a considerar 1 88
CAPTULO 8 MODELADO DEL ANLISIS X91
8.1 Anlisis de requisitos 192
8. 1. 1 Filosofa y objetivos generales 193
8. 1. 2 Reglas prcticas de anlisis 194
8. 1. 3 Anlisis del dominio 194
8. 2 Enfoques de modelado del anlisis 196
8. 3 Conceptos del modelado de dalos 197
8. 3. 1 Objetos de datos 197
8. 3. 2 Atributos 198
8. 3. 3 Relaciones 199
8. 3. 4 Cardinalidad y modalidad 199
8 .4 Anlisis orientado a objetos 201
8. 5 Modelado basado en escenarios 202
8. 5. 1 Escritura de casos de uso 202
8. 5. 2 Desarrollo de un diagrama de actividad 208
8. 5. 3 Diagramas de carril 209
8. 6 Modelado orientado al flujo 211
8. 6. 1 Creacin de un modelo de flujo de datos 21 1
8. 6. 2 Creacin de un modelo de control del flujo 214
8. 6. 3 Especificacin de control 215
8. 6. 4 Especificacin de proceso 217
8. 7 Modelado basado en clases 219
8. 7. 1 Identificacin de clases de anlisis 219
8. 7. 2 Especificacin de atributos 222
8. 7. 3 Definicin de operaciones 223
8. 7. 4 Modelado de Clase-ResponsabilidadColaborador (CRC) 225
8. 7. 5 Asociaciones y dependencias 232
8. 7. 6 Paquetes de anlisis 233
8. 8 Creacin de un modelo de comportamiento 234
8. 8. 1 Identificacin de eventos con el caso de uso 235
8. 8. 2 Representaciones de estado 236
8. 9 Resumen 239
TM
PDF Editor
CONTENIDO
Referencias 241
Problemas y punios o considerar 241
Oirs lecturas y fuentes de informacin 243
CAPTULO 9 INGENIERA DEL DISEO 245
9. 1 Diseo dentro del contexto de la ingeniera del software 247
9. 2 Proceso y calidad del diseo 249
9. 3 Conceptos del diseo 252
9. 3. 1 Abstraccin 252
9. 3. 2 Arquitectura 253
9. 3. 3 Patrones 254
9. 3. 4 Modularidad 254
9. 3. 5 Ocultacin de informacin 256
9. 3. 6 Independencia funcional 256
9. 3. 7 Refinamiento 257
9. 3. 8 Refabricacin 258
9. 3. 9 Clases de diseo 259
9. 4 El modelo de diseo 262
9. 4. 1 Elementos del diseo de dolos 263
9. 4. 2 Elementos del diseo arquitectnico 264
9. 4. 3 Elementos de diseo de interfaz 264
9. 4. 4 Elementos de diseo ol nivel de componentes 266
9. 4. 5 Elementos de diseo al nivel del despliegue 267
9. 5 Diseo de software basado en patrones 269
9. 5. 1 Descripcin de un patrn de diseo 269
9. 5. 2 Utilizacin de potrones en el diseo 270
9. 5. 3 Marcos de trabajo 270
9. 6 Resumen 271
Referencias 272
Otros lecturas y fuentes de informacin 273
CAPTULO 10 DISEO ARQUITECTNICO 275
10.1 Arquitectura del software 276
10.1.1 Qu es lo arquitectura? 276
10. 1. 2 Por qu es importante la arquitectura? 277
10.2 Diseo de datos 278
10.2.1 Diseo de datos ol nivel arquitectnico 278
10. 2. 2 Diseo de datos al nivel de componentes 279
10. 3 Estilos y patrones arquitectnicos 280
10.3.1 Una breve taxonoma de estilos arquitectnicos 281
10. 3. 2 Patrones arquitectnicos 284
10. 3. 3 Organizacin y refinamiento 287
10.4 Diseo arquitectnico 287
10.4.1 Representacin del sistemo en el contexto 288
TM
PDF Editor
ri v CONTENIDO
10. 4. 2 Definicin de arquetipos 289
10. 4. 3 Refinamiento de la arquitectura en componentes 290
10. 4. 4 Descripcin de la creacin de instancias del sistema 292
10. 5 Evaluacin de diseos arquitectnicos alternos 294
10.5.1 Un mtodo de anlisis de compensacin para la arquitectura 294
10. 5. 2 Complejidad arquitectnica 296
10. 5. 3 Lenguajes de descripcin arquitectnica 296
10. 6 Correlacin del flujo de datos en una arquitectura del software 297
10.6.1 Flujo de transformacin 297
10. 6. 2 Flujo de transaccin 298
10. 6. 3 Correlacin de transformaciones 299
10. 6. 4 Correlacin de transacciones 306
10. 6. 5 Refinamiento del diseo arquitectnico 310
10. 7 Resumen 311
Referencias 312
CAPTULO 11 DISEO AL NIVEL DE COMPONENTES 315
11.1 Qu es un componente? 316
11.1.1 Concepto orientado a objetos 317
11. 1. 2 El concepto convencional 318
11. 1. 3 Un concepto relacionado con el proceso 321
11.2 Diseo de componentes basados en clases 322
11.2.1 Principios bsicos de diseo 322
11. 2. 2 Lneas generales de diseo al nivel de componentes 325
11. 2. 3 Cohesin 3 2 7
11. 2. 4 Acoplamiento 329
11. 3 Conduccin del diseo al nivel de componentes 331
11.4 Lenguaje de restriccin de objetos 337
1 1.5 Diseo de componentes convencionales 340
1 1.5.1 Notacin grfica del diseo 340
11. 5. 2 Notacin tabular del diseo 342
11. 5. 3 Lenguaje de diseo de programas 343
11. 5. 4 Comparacin entre notaciones de diseo 345
11. 6 Resumen 346
Referencias 347
CAPTULO 12 DISEO DE LA INTERFAZ DE USUARIO 350
12.1 Las reglas de oro 351
12.1.1 Dar el control al usuario 351
12. 1. 2 Reducir la carga en la memoria del usuario 353
12. 1. 3 Lograr que la interfaz sea consistente 354
TM
PDF Editor
CONTENIDO
xv
12. 2 Anlisis y diseo de la interfaz de usuario 356
12.2.1 Modelos del anlisis y diseo de la interfaz 356
12. 2. 2 El proceso 358
12. 3 Anlisis de la interfaz 359
12.3.1 Anlisis del usuario 360
12. 3. 2 Anlisis y modelado de tareas 361
12. 3. 3 Anlisis del contenido de la pantalla 367
12. 3. 4 Anlisis del entorno de trabajo 367
12. 4 Pasos del diseo de la interfaz 368
12.4.1 Aplicacin de los pasos del diseo de lo interfaz 369
12. 4. 2 Patrones de diseo de la interfaz de usuario 371
12. 4. 3 Temas de diseo 372
12. 5 Evaluacin del diseo 377
12. 6 Resumen 378
Referencias 379
Otras lecturas'y fuentes de informacin 380
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOFTWARE 382
13.1 Un enfoque estratgico para la prueba del software 383
13.1.1 Verificacin y validacin 384
13. 1. 2 Organizacin para las pruebas del software 385
13. 1. 3 Estrategia de prueba para arquitecturas convencionales del software 386
13. 1. 4 Estrategia de prueba del software paro arquitecturas orientadas a objetos 388
1 3. 1. 5 Criterios para completar la prueba 389
13.2 Aspectos estratgicos 390
13. 3 Estrategias de prueba para el software convencional 391
13.3.1 Prueba de unidad 392
13. 3. 2 Prueba de integracin 394
13. 4 Estrategias de prueba para software orientado a objetos 402
13.4.1 Prueba de unidad en el contexto orientado a objetos 402
13. 4. 2 Prueba de integracin en el contexto orientado a objetos 4 0 3
13. 5 Pruebas de validacin 4 0 4
13.5.1 Criterios de la prueba de validacin 404
1 3. 5. 2 Revisin de la configuracin 4 0 5
13. 5. 3 Pruebas alfa y beta 4 0 5
13. 6 Prueba del sistema 4 0 6
13.6.1 Prueba de recuperacin 407
1 3. 6. 2 Prueba de seguridad 4 0 7
13. 6. 3 Prueba de resistencia 408
13. 6. 4 Prueba de desempeo 408
13. 7 El arte de la depuracin 4 0 9
13.7.1 El proceso de depuracin 4 1 0
13. 7. 2 Consideraciones psicolgicas 411
TM
PDF Editor
xvl
CONTENIDO
13. 7. 3 Estrategias de depuracin 4 1 2
13. 7. 4 Correccin del error 414
13. 8 Resumen 415
Referencias 41
CAPTULO 14 TCNICAS DE PRUEBA DEL SOFTWARE 418
14.1 Fundamentos de las pruebas del software 4 1 9
14.2 Pruebas de caj a negra y caj a blanca 422
14.3 Pruebas de caj a blanca 4 2 3
14.4 Prueba de la ruta bsica 4 2 3
14.4.1 Notacin de grfica de flujo 4 2 3
14. 4. 2 Rutos independientes del programa 4 2 5
14. 4. 3 Derivacin de casos de prueba 4 2 7
14. 4. 4 Matrices de grficas 4 3 0
14. 5 Pruebas de la estructura de control 4 3 0
14.5.1 Prueba de condicin 431
14. 5. 2 Prueba del flujo de datos 431
14. 5. 3 Prueba de bucles 432
14.6 Pruebo de caj a negra 41 3
14.6.1 Mtodos grficos de prueba 434
14. 6. 2 Particin equivalente 4 3 6
14. 6. 3 Anlisis de valores lmite 4 3 7
14. 6. 4 Prueba de tabla ortogonal 438
14. 7 Mtodos de pruebas orientadas a objetos 441
14.7.1 Implicaciones del concepto orientado a objetos en el diseo de casos de prueba 442
14. 7. 2 Aplicabilidad de mtodos convencionales de diseo de casos de prueba 4 4 2
14. 7. 3 Prueba basada en fallas 4 4 3
14. 7. 4 Casos de prueba y jerarqua de clase 4 4 4
14. 7. 5 Prueba basada en escenarios 4 4 4
14. 7. 6 Estructuras de superficie y de fondo en pruebas 4 4 6
14. 8 Mtodos de pruebo aplicables al nivel de clase 4 4 7
14.8.1 Prueba aleatoria para clases orientadas a objetos 447
14. 8. 2 Prueba de particin al nivel de clase 448
14.9 Diseo de caso de prueba de interclase 449
14.9.1 Prueba de clases mltiples 4 4 9
14. 9. 2 Pruebas derivadas de modelos de comportamiento 451
14. 10 Prueba de entornos especializados: arquitecturas y aplicaciones 452
14. 10. 1 Pruebas de interfaces grficas de usuario 452
14. 10. 2 Prueba de arquitecturas diente/servidor 452
14. 10. 3 Prueba de la documentacin y las funciones de ayuda 454
14. 10. 4 Prueba de sistemas de tiempo real 4 5 5
14. 11 Patrones de prueba 4 5 6
TM
PDF Editor
CONTENIDO
xvl l
14. 12 Resumen 4 5 7
Referencias 4 5 9
Problemas y puntos a considerar 4 5 9
Otras lecturas y fuentes de informacin 4 6 0
CAPTULO 15 MTRICAS DEL PRODUCTO PARA EL SOFTWARE 462
15.1 Calidad general 4 6 3
15. 1. 1 Factores de calidad de McCall 464
15. 1. 2 Factores de calidad del estndar ISO 9 1 2 6 4 6 5
15. 1. 3 La transicin a un concepto cuantitativo 466
15.2 Un marco conceptual para las mtricas del producto 467
15. 2. 1 Medidas, mtricas e indicadores 4 6 7
15. 2. 2 El reto de las mtricas del producto 468
15. 2. 3 Principios de medicin 4 6 9
15. 2. 4 Medicin del software orientado a objetivos 4 7 0
15. 2. 5 Los atributos de las mtricas efectivas del software 471
15. 2. 6 Panorama de las mtricas del producto 472
15. 3 Mtricas para el modelo de anlisis 4 7 4
15.3.1 Mtricas basadas en la funcin 4 7 4
15. 3. 2 Mtricas para la calidad de la especificacin 4 7 7
15. 4 Mtricas para el modelo de diseo 4 7 9
15. 4. 1 Mtricas del diseo arquitectnico 4 7 9
15. 4. 2 Mtricas para el diseo orientado a objetos 481
15. 4. 3 Mtricas orientadas a clases: la coleccin de mtricas de CK 4 8 3
15. 4. 4 Mtricas orientadas a objetos: la coleccin de mtricas para el diseo orientado
a objetos 486
15. 4. 5 Mtricas orientadas a objetos propuestos por Lorenz y Kidd 4 8 7
15. 4. 6 Mtricas de diseo al nivel de componentes 487
15. 4. 7 Mtricas orientadas a la operacin 491
15. 4. 8 Mtricas de diseo de la interfaz de usuario 4 9 2
15.5 Mtricas para el cdigo fuente 493
15. 6 Mtricas para pruebas 4 9 4
15.6.1 Mtricas de Halslead aplicadas a las pruebas 494
15. 6. 2 Mtricas para pruebas orientadas a objetos 4 9 5
15. 7 Mtricas para el mantenimiento 4 9 6
15. 8 Resumen 4 9 7
Referencias 4 9 7
PARTE TRES: APLICACIN DE LA INGENIERA WEB SOI
CAPTULO 16 INGENIERA WEB 502
16.1 Atributos de los sistemas y aplicaciones basados en Web 504
16. 2 Estratos de la Ingeniera de WebApp 507
TM
PDF Editor
xvlll CONTENIDO
16.2.1 Proceso 5 0 7
16. 2. 2 Mtodos 5 0 7
16. 2. 3 Herramientas y tecnologa 508
16.3 El proceso de ingeniera Web 508
16.3.1 Definicin del marco de trabajo 5 0 9
16. 3. 2 Refinamiento del marco de trabajo 512
16. 4 Mejores prcticas en ingeniera Web 512
16. 5 Resumen 514
Referencias 5 1 5
CAPTULO 17 FORMULACIN Y PLANEACIN PARA INGENIERA WEB 517
17.1 Formulacin de sistemas basados en Web 518
17.1.1 Preguntas de formulacin 519
17. 1. 2 Recopilacin de requisitos para WebApps 520
17. 1. 3 El puente hacia el modelado de anlisis 5 2 5
17. 2 Planeacin de proyectos de ingeniera Web 5 2 5
17.3 El equipo de ingeniera Web 5 2 6
17.3.1 Los actores 526
17. 3. 2 Construccin del equipo 528
17. 4 Conflictos de gestin de proyecto para ingeniera Web 528
17.4.1 Planeacin de WebApp: subcontratacin 5 3 0
17. 4. 2 Planeacin de WebApp: ingeniera Web en casa 5 3 3
17. 5 Medicin para ingeniera Web y WebApps 536
17.5.1 Mediciones para esfuerzo de ingeniera Web 537
17. 5. 2 Medicin del valor de negocios 538
17. 6 Las "peores prcticas" para proyectos WebApp 539
17. 7 Resumen 540
Referencias 541
CAPTULO 18 MODELADO DE ANLISIS PARA APLICACIONES WEB 544
18.1 Requisitos para el anlisis de las WebApps 5 4 5
18.1.1 La jerarqua de usuario 546
18. 1. 2 Desarrollo de casos de uso 547
18. 1. 3 Afinacin del modelo de caso de uso 5 4 9
18. 2 El modelado de anlisis para WebApps 5 5 0
18. 3 El modelo de contenido 551
18.3.1 Definicin de objetos de contenido 551
18. 3. 2 Relaciones y jerarqua de contenido 552
18. 3. 3 Clases de anlisis para WebApps 553
18.4 El modelo de interaccin 554
18. 5 El modelo funcional 5 5 7
TM
PDF Editor
CONTENIDO xl x
18. 6 El modelo de configuracin 559
18. 7 Anlisis relacin-navegacin 5 5 9
18.7.1 Anlisis de relaciones: preguntas clave 560
18. 7. 2 Anlisis de navegacin 561
18. 8 Resumen 563
Referencias 5 6 3
CAPTULO 19 MODELADO DE DISEO PARA APLICACIONES WEB 566
19.1 Temas de diseo para ingeniera Web 5 6 7
19.1.1 Diseo y calidad de una WebApp 5 6 7
19. 1. 2 Metas de diseo 571
19. 2 Pirmide del diseo IWeb 572
19. 3 Diseo de la interfaz de la WebApp 573
19.3.1 Principios y directrices del diseo de la interfaz 574
19. 3. 2 Mecanismos de control de la interfaz 5 7 9
19. 3. 3 Flujo de trabajo en el diseo de la interfaz 580
19. 4 Diseo esttico 582
19.4.1 Cuestiones de la plantilla 582
19. 4. 2 Cuestiones de diseo grfico 583
19. 5 Diseo del contenido 584
19.5.1 Objetos de contenido 584
19. 5. 2 Cuestiones del diseo de contenido 585
19. 6 Diseo arquitectnico 585
19. 6. 1 Arquitectura de contenido 586
19. 6. 2 Arquitectura de WebApp 588
19. 7 Diseo de navegacin 590
19.7.1 Semntica de navegacin 591
19. 7. 2 Sintaxis de navegacin 592
19. 8 Diseo al nivel de componentes 593
19. 9 Patrones de diseo hipermedia 594
19. 10 Mtodo de diseo hipermedia orientado a objetos (MDHOO] 5 9 5
19. 10. 1 Diseo conceptual para el MDHOO 595
19. 10. 2 Diseo de navegacin mediante el MDHOO 596
19. 10. 3 Diseo abstracto de la interfaz e implementacin 597
19. 11 Mtricas de diseo para WebApps 598
19. 12 Resumen 599
Referencias 6 0 0
Otras lectura y fuentes de informacin 603
CAPTULO 20 CMO PROBAR APLICACIONES WEB 604
20. 1 Prueba de conceptos para WebApps 6 0 5
20. 1. 1 Dimensiones de calidad 6 0 5
TM
PDF Editor
CONTENIDO
20. 1. 2 Errores dentro de un ambiente WebApp 606
20. 1. 3 Estrategias de pruebas 607
20. 1. 4 Planeacin de los pruebas 608
20. 2 El proceso de pruebo: un panorama 6 0 9
20. 3 Prueba del contenido 612
20. 3. 1 Objetivos de la prueba de contenido 6 1 2
20. 3. 2 Prueba de las bases de datos 613
20. 4 Prueba de la interfaz del usuario 6 1 6
20. 4. 1 Estrategia de pruebas de la interfaz 6 1 6
20. 4. 2 Prueba de mecanismos de la interfaz 6 1 7
20. 4. 3 Prueba de la semntica de la interfaz 619
20. 4. 4 Prueba de la facilidad de uso 620
20. 4. 5 Pruebas de compatibilidad 622
20. 5 Prueba al nivel de componentes 6 2 3
20. 6 Pruebas de navegacin 6 2 5
20. 6. 1 Prueba de la sintaxis de navegacin 6 2 5
20. 6. 2 Prueba de la semntica de navegacin 6 2 6
20. 7 Prueba de la configuracin 628
20. 7. 1 Conflictos en el lado del servidor 628
20. 7. 2 Conflictos en el lado del cliente 6 2 9
20. 8 Pruebas de seguridad 630
20. 9 Pruebas del desempeo 631
20. 9. 1 Objetivos de las pruebas del desempeo 632
20. 9. 2 Pruebas de carga 6 3 3
20. 9. 3 Pruebas de tensin 6 3 3
20. 10 Resumen 6 35
Referencias 6 3 6
PARTE CUATRO: GESTIN DE PROYECTOS DE SOFTWARE 639
CAPTULO 21 CONCEPTOS DE GESTIN DE PROYECTOS 640
21. 1 El espectro de la gestin 641
21. 1. 1 El personal 641
21. 1. 2 El producto 642
21. 1. 3 El proceso 642
21. 1. 4 El proyecto 643
21. 2 Personal
21. 2. 1 Los participantes 644
21. 2. 2 Lderes de equipo 644
21. 2. 3 El equipo de software 645
21. 2. 4 Equipos giles 649
21. 2. 5 Conflictos de coordinacin y comunicacin 6 5 0
21. 3 El producto 651
TM
PDF Editor
CONTENIDO xxi
21. 3. 1 mbito del software 651
21. 3. 2 Descomposicin del problema 652
21. 4 El proceso
21. 4. 1 Combinacin del producto y el proceso 6 5 3
21. 4. 2 Descomposicin del proceso 6 5 4
21. 5 El proyecto 6 5 6
21. 6 El principio W5HH 6 5 7
21. 7 Prcticas crticas 658
21. 8 Resumen 6 5 9
Referencias 6 6 0
CAPTULO 22 MTRICAS DE PROCESO Y PROYECTO 663
22. 1 Mtricas en los dominios del proceso y el proyecto 664
22. 1. 1 Mtricas del proceso y mejora del proceso de software 6 6 4
22. 1. 2 Mtricas del proyecto 6 6 7
22. 2 Medicin del software 668
22. 2. 1 Mtricas orientadas al tamao 6 6 9
22. 2. 2 Mtricas orientadas a la funcin 6 7 0
22. 2. 3 Reconciliacin de las mtricas LDC y PF 671
22. 2. 4 Mtricas orientadas a objetos 673
22. 2. 5 Mtricas orientadas a casos de uso 674
22. 2. 6 Mtricas de proyectos de ingeniera Web 6 7 4
22. 3 Mtricas para calidad del software 6 7 6
22. 3. 1 Medicin de la calidad 6 7 7
22. 3. 2 Eficacia en la eliminacin de defectos 678
22. 4 Integracin de las mtricas dentro del proceso de software 6 8 0
22. 4. 1 Argumentos para las mtricas del software 6 8 0
22. 4. 2 Establecimiento de una lnea base 681
22. 4. 3 Recopilacin, clculo y evaluacin de mtricas 682
22. 5 Mtricas para organizaciones pequeas 682
22. 6 Establecimiento de un programa de mtricas de software 684
22. 7 Resumen 6 8 6
Referencias 687
CAPTULO 23 ESTIMACIN PARA PROYECTOS DE SOFTWARE 690
23. 1 Observaciones acerca de la estimacin 691
23. 2 El proceso de planificacin del proceso 692
23. 3 mbito del software y factibilidad 6 9 3
23. 4 Recursos 694
23. 4. 1 Recursos humanos 6 9 5
23. 4. 2 Recursos de software reutilizables 6 9 5
TM
PDF Editor
xxi i CONTENIDO
23. 4. 3 Recursos del entorno 6 9 6
23. 5 Estimacin de proyectos de software 6 9 6
23. 6 Tcnicas de descomposicin 698
23. 6. 1 Tamao del software 698
23. 6. 2 Estimacin basada en el problema 699
23. 6. 3 Un ejemplo de estimacin basada en LDC 7 0 0
23. 6. 4 Un ejemplo de estimacin basada en PF 702
23. 6. 5 Estimacin basada en el proceso 704
23. 6. 6 Un ejemplo de estimacin basada en el proceso 705
23. 6. 7 Estimacin con casos de uso 7 0 5
23. 6. 8 Un ejemplo de estimacin basada en casos de uso 7 0 7
23. 6. 9 Reconciliacin de estimaciones 708
23. 7 Modelos empricos de estimacin 709
23. 7. 1 La estructura de los modelos de estimacin 7 1 0
23. 7. 2 El modelo COCOMO II 710
23. 7. 3 La ecuacin del software 712
23. 8 Estimocin para proyectos orientados a objetos 7 1 3
23. 9 Tcnicas de estimacin especializadas 714
23. 9. 1 Estimacin para desarrollo gil 714
23. 9. 2 Estimacin para proyectos de ingeniera Web 715
23. 10 La decisin desarrollar-comprar 217
23. 10. 1 Creacin de un rbol de decisin 7 1 7
23. 10. 2 Subcontratacin 718
23. 11 Resumen 720
Referencias 721
CAPTULO 24 CALENDARIZACIN DE PROYECTOS DE SOFTWARE 724
24. 1 Conceptos bsicos 7 2 5
24. 2 Calendarizacin de proyecto 7 2 7
24. 2. 1 Principios bsicos 728
24. 2. 2 Relacin entre el personal y el esfuerzo 7 2 9
24. 2. 3 Distribucin del esfuerzo 732
24. 3 Definicin de un conjunto de tareas para el proyecto de software 732
24. 3. 1 Ejemplo de conjunto de tareas 733
24. 3. 2 Refinamiento de las tareas principales 734
24. 4 Definicin de uno red de tareas 7 35
24. 5 Calendarizacin 736
24. 5. 1 Cronogramas 738
24. 5. 2 Seguimiento de la calendarizacin 739
24. 5. 3 Seguimiento del progreso en un proyecto OO 741
24. 6 Anlisis del valor ganado 742
24. 7 Resumen 744
TM
PDF Editor
CONTENIDO xxlll
Referencias 744
CAPTULO 25 GESTIN DEL RIESGO 747
25. 1 Estrategias de riesgo reactivas y proactivas 748
25. 2 Riesgos del software 749
25. 3 Identificacin de riesgos 7 5 0
25. 3. 1 Evaluacin del riesgo global del proyecto 752
25. 3. 2 Componentes y controladores del riesgo 753
25. 4 Proyeccin del riesgo 754
25. 4. 1 Desarrollo de una tabla de riesgos 755
25. 4. 2 Evaluacin del impacto del riesgo 7 5 7
25. 5 Refinamiento del riesgo 7 5 9
25. 6 Reduccin, supervisin y gestin del riesgo 759
25. 7 El plan RSGR 763
25. 8 Resumen 764
Referencias 764
CAPTULO 26 GESTIN DE LA CALIDAD 767
26. 1 Conceptos de calidad 768
26. 1. 1 Calidad 769
26. 1. 2 Control de calidad 770
26. 1. 3 Garanta de la calidad 770
26. 1. 4 Costo de la calidad 7 7 0
26. 2 Garanta de la calidad del software (SQA) 771
26. 2. 1 Algunos antecedentes 772
26. 2. 2 Actividades de SQA 7 7 3
26. 3 Revisiones del software 774
26. 3. 1 Impacto de los defectos de software en el costo 7 7 5
26. 3. 2 Amplificacin y eliminacin del defecto 776
26. 4 Revisiones tcnicas formales 778
26. 4. 1 La unta de revisin 778
26. 4. 2 Informe de la revisin y conservacin de registros 7 7 9
26. 4. 3 Directrices de la revisin 7 8 0
26. 4. 4 Revisiones basadas en muestras 781
26. 5 Enfoque formales acerca del SQA 783
26. 6 Garanta de la calidad estadstica del software 783
26. 6. 1 Un ejemplo genrico 784
26. 6. 2 Seis sigma para ingeniera del software 7 8 5
26. 7 Fiabilidad del software 786
26. 7. 1 Medidas de fiabilidad y disponibilidad 7 8 7
TM
PDF Editor
xxl v CONTENIDO
26. 7. 2 Seguridad del software 788
26. 8 Los estndares de calidad ISO 9 0 0 0 789
26. 9 El plan de SQA 79]
26. 10 Resumen 792
Referencias 792
CAPTULO 27 GESTIN DEL CAMBIO 796
27. 1 Gestin de la configuracin del software 797
27. 1. 1 Un escenario de GCS 798
27. 1. 2 Elementos de un sistema de gestin de la configuracin 799
27. 1. 3 Lneas base 800
27. 1. 4 Elementos de configuracin del software 801
27. 2 El depsito de ECS 803
27. 2. 1 El papel de depsito 803
27. 2. 2 Caractersticas y contenidos generales 804
27. 2. 3 Caractersticas de la GCS 805
27. 3 El proceso de GCS 806
27. 3. 1 Identificacin de objetos en la configuracin del software 807
27. 3. 2 Control de la versin 808
27. 3. 3 Control del cambio 810
27. 3 .4 Auditora de la configuracin 813
27. 3. 5 Informe de estado 814
27. 4 Gestin de la configuracin para ingeniera Web 815
27. 4. 1 Problemas en la gestin de la configuracin para WebApps 815
27. 4. 2 Objetos de configuracin WebApp 817
27. 4. 3 Gestin del contenido 817
27. 4. 4 Gestin del cambio 820
27. 4. 5 Control de la versin 822
27. 4. 6 Auditora y elaboracin de informes 823
27. 5 Resumen 824
Referencias 825
PARTE CINCO: TEMAS AVANZADOS EN INGENIERIA DEL SOFTWARE 829
CAPTULO 28 MTODOS FORMALES 830
28. 1 Conceptos bsicos 831
28. 1. 1 Deficiencias de los enfoques menos formales 832
28. 1. 2 Matemticas en el desarrollo de software 833
28. 1. 3 Conceptos de mtodos formales 833
28. 2 Preliminares matemticos 837
28. 2. 1 Conjuntos y especificacin constructiva 837
TM
PDF Editor
CONTENIDO
xxv
28. 2. 2 Operaciones de conjuntos 838
28. 2. 3 Operadores lgicos 840
28. 2. 4 Sucesiones 841
28. 3 Aplicacin de la notacin matemtica para la especificacin formal 842
28. 4 Lenguajes formales de especificacin 844
28. 5 Lenguaje restringido a objetos (OCL) 845
28. 5. 1 Un breve panorama de la sintaxis y la semntica del OCL 845
28. 5. 2 Ejemplo de uso del OCL 847
28. 6 El lenguaje de especificacin Z 849
28. 6. 1 Breve panorama de la sintaxis y semntica Z 849
28. 6. 2 Un ejemplo que utiliza Z 849
28. 7 Los diez mandamientos de los mtodos formales 852
28. 8 Mtodos formales: el camino por recorrer 853
28. 9 Resumen 854
Referencias 855
CAPTULO 29 INGENIERA DEL SOFTWARE DE SALA LIMPIA 858
29. 1 El enfoque de sala limpia 859
29. 1. 1 La estrategia de sala limpia 860
29. 1. 2 Qu hace diferente a la sala limpia? 862
29. 2 Especificacin funcional 863
29. 2. 1 Especificacin de caj a negra 8 6 5
29. 2. 2 Especificacin de caja de estado 866
29. 2. 3 Especificacin de caja transparente 866
29. 3 Diseo de sala limpia 867
29. 3. 1 Refinamiento y verificacin del diseo 867
29. 3. 2 Ventajas de la verificacin del diseo 871
29. 4 Pruebas de sala limpia 872
29. 4. 1 Pruebas estadsticas de uso 873
29. 4. 2 Certificacin 874
29. 5 Resumen 875
Referencias 876
CAPTULO 30 INGENIERA DEL SOFTWARE BASADA EN COMPONENTES 879
30. 1 Ingeniera de sistemas basada en componentes 880
30. 2 El proceso de ISBC 882
30. 3 Ingeniera del dominio 883
30. 3. 1 El proceso de anlisis del dominio 883
30. 3. 2 Funciones de caracterizacin 884
30. 3. 3 Modelado estructural y puntos de estructura 885
30. 4 Desarrollo basado en componentes 886
TM
PDF Editor
xxvl CONTENIDO
30. 4. 1 Calificacin, adaptacin y composicin de componentes 887
30. 4. 2 Ingeniera de componentes 890
30. 4. 3 Anlisis y diseo para la reutilizacin 891
30. 5 Clasificacin y recuperacin de componentes 892
30. 5. 1 Descripcin de los componentes reutilizables 892
30. 5. 2 El entorno de reutilizacin 894
30. 6 Economa de la ISBC 8 9 5
30. 6. 1 Impacto sobre la calidad, la productividad y el costo 896
30. 6. 2 Anlisis de costo empleando puntos de estructura 897
30. 7 Resumen 898
Referencias 899
CAPTULO 31 RHNGENIERA 902
31. 1 Reingeniera de procesos de negocio 9 0 3
31. 1. 1 Procesos de negocios 904
31. 1. 2 Un modelo de RPN 904
31. 2 Reingeniera del software 906
31. 2. 1 Mantenimiento del software 9 0 7
31. 2. 2 Un modelo de procesos de reingeniera del software 908
31. 3 Ingeniera inversa 912
31. 3. 1 Ingeniera inversa para comprender los datos 91 3
31. 3. 2 Ingeniera inversa para comprender el procesamiento 9 1 4
31. 3. 3 Ingeniera inversa de interfaces de usuario 9 1 5
31. 4 Reestructuracin 9 1 6
31. 4. 1 Reestructuracin del cdigo 9 1 7
31. 4. 2 Reestructuracin de los datos 9 1 7
31. 5 Ingeniera directa 918
31. 5. 1 Ingeniera directa para arquitecturas cliente/servidor 9 2 0
31. 5. 2 Ingeniera directa para arquitecturas orientadas a objetos 921
31. 5. 3 Ingeniera directa de interfaces de usuario 922
31. 6 La economa de la reingeniera 9 2 3
31. 7 Resumen 923
Referencias 924
CAPTULO 32 EL CAMINO POR RECORRER 927
32. 1 La importancia del software. Segunda parte 928
32. 2 El mbito del cambio 9 2 9
32. 3 Las personas y la forma en la que construyen sistemas 9 3 0
32. 4 El "nuevo" proceso de ingeniera del software 931
32. 5 Nuevos modos de representar la informacin 9 3 3
32. 6 La tecnologa como impulsor 9 35
TM
PDF Editor
CONTENIDO
xxvi
32. 7 La responsabilidad de la ingeniera del soflware 9 3 6
32. 8 Un comentario final 938
Referencias 939
ndice analtico 943
Siglas ms comunes en ingeniera del software 953
TM
PDF Editor
C A P T U L O
CONCEPTOS
CLAVE
or oc t e r s t i c a s
s o f t wa r e S
i q &a c i n 8
mr*B$ d e f al l a . . . 6
defi ni ci n . " / ' r .
ie s o f t wa r e . 5
det er i or o . . 6
evol uci n 1 2
hi st ori a 3
wi t os 14
r e t os 11
s o f t wa r e
her edado I I
SOFTWARE E I NGENI ER A
DEL SOFTWARE
E
s comn dar se cuent a que la i nvenci n de una tecnol oga puede t ener
efect os pr ofundos e i nesper ados en ot r as t ecnol og as con l as que en apa-
riencia no ti ene ni nguna relacin, como en empr esas comerci al es, en per-
sonas y aun en la cultura en su conj unt o. Este f enmeno a menudo se denomi na
"la ley de l as consecuenci as imprevistas".
En la actualidad, el soft ware de comput adora es la tecnologa individual ms im-
port ant e en el mbi t o mundial. Tambin es uno de los ej empl os principales de la
ley de las consecuenci as imprevistas. Nadie en la dcada de 1950 podra haber pre-
dicho que el soft ware se convertira en una tecnologa indispensable en los nego-
cios, la ciencia y la ingeniera; t ampoco que el soft ware permitira la creacin de
tecnologas nuevas (por ejemplo, la ingeniera gentica), la expansi n de tecnolo-
gas existentes (como las telecomunicaciones), el fin de tecnologas ant i guas (co-
mo la industria de la impresin); que el soft ware sera la fuerza conductora detrs
de la revolucin de las comput ador as personales; que los productos empaquet ados
de soft ware se podran comprar en los cent ros comerciales; que una compa a de
soft ware se volvera muy grande y ms influyente que la mayora de las compa as
de la era industrial; que una gran red construida con soft ware l l amada Internet cu-
brira y cambiara todo, desde la investigacin bibliogrfica hast a las compr as de
los consumi dores y los hbi tos diarios de los j venes (y no tan jvenes).
Nadie podra haber previsto que el sof t war e estara rel aci onado con si st emas
de t odo tipo: de t ransport e, mdi cos, de t el ecomuni caci ones, militares, industria-
les, de ent r et eni mi ent o, m qui na s par a ofi ci na (la lista par ece no t ener fin).
Qu e s ? El software de computa-
dora es el producto que los ingenieros
de software construyen y despus
mantienen en el largo plazo. Incluye
los programas que se ejecutan dentro
de una computadora de cualquier tamao y arqui-
tectura, el contenido que se presenta conforme los
programas se ejecutan y los documentos, tanto f-
sicos como virtuales, que engloban todas las for-
mas de medios electrnicos.
Qui n l o hace? Los ingenieros de software lo
construyen y lo mantienen, y casi todos en el mun-
do industrializado lo usan de manera directa o in-
directa.
Por qu e s i mport ant e? Porque afecta de for-
ma muy cercana todos los aspectos de nuestras vi-
das y se ha vuelto omnipresente en el comercio, la
cultura y las actividades cotidianas.
Cul es son l os pas os ? El software de compu-
tadora se construye de la misma forma que cual-
quier producto de xito: mediante la aplicacin de
un proceso que conduzca a un resultado de alta
calidad que satisfaga las necesidades de la gente
que usar el producto. Se aplica un enfoque de in-
geniera del software.
Cul e s el product o obt eni do? Desde el pun-
to de vista del ingeniero de software, el producto
obtenido J o forman los programas, el contenido
(datos) y los documentos que constituyen el softwa-
re. Pero desde el enfoque del usuario, el producto
obtenido es la informacin resultante que de algu-
na manera mejora el mundo del usuario.
Cmo pi rado est ar s eguro d e que l o he
hecho correct ament e? Una manera es leer el
resto de este texto, seleccionar las ideas aplicables
a un software especfico y aplicarlas.
1
TM
PDF Editor
2
CAPTULO 1 SOFTWARE E I NGENI ERA DEL SOFTWARE
Y si se t oma en cuent a la ley de l as consecuenci as imprevistas, hay muchos efect os
que t odav a es imposible predeci r en el t r abaj o diario.
Por ltimo, nadi e podra haber pr edi cho que mi l l ones de pr ogr amas de compu-
t ador a t endr an que corregirse, adapt ar se y mej or ar se conf or me pasar a el t i empo y
que la labor de desarrollar est as act i vi dades de "mant eni mi ent o" absorber a m s
gent e y recursos que t odo el t r abaj o apl i cado para la creaci n del sof t war e nuevo.
y los descubrimientos tecnolgicos son los el ement os conductores del cri
A medi da que la i mportanci a del sof t war e ha crecido, la comuni dad del sof t war e
ha i nt ent ado de maner a cont i nua desarrol l ar t ecnol og as que hagan ms fcil, ms
rpi da y me nos car a la const rucci n y el mant eni mi ent o de pr ogr amas de compu-
t ador a de alta calidad. Al gunas de est as t ecnol og as se limitan al domi ni o de una
aplicacin especfica (por ejempl o, al di seo y la i mpl ement aci n de sitios Web);
ot ras se enf ocan al domi ni o de una tecnol oga (como la programaci n ori ent ada a
obj et os y la pr ogr amaci n ori ent ada a aspectos); y exi st en ot r as con base general
(por ejempl o, si st emas operat i vos como LINUX). Sin embar go, an no se desarrol l a
una tecnol oga de sof t war e que lo haga todo, y la probabilidad de que st a surj a en
el fut uro es pequea. Aun as, l as per sonas dej an s us trabajos, su seguri dad y hast a
sus vi das en manos del soft ware de comput ador as. Ms vale que st e sea bueno.
Este texto present a un mar co para qui enes const ruyen sof t war e de comput ador a:
l as per sonas que deben hacer buen soft ware. El marco, que incluye un proceso, un
conj unt o de mt odos y una serie de her r ami ent as se llama ingeniera del software.
r - r ~ - . J i ngeni er a 05 r . - r - - <
(eri al es d e la vida humana, par a que as la vida sea ms fcil, segura y pl acent era
Richard Fairley y Mor * !
CLAVE
El software es tanto un
producto como el vehcu-
lo para su entrega.
En la act ual i dad, el sof t war e t i ene un papel dual . Es, a la vez, un pr oduct o y un
veh cul o medi ant e el cual se ent rega un product o. Como product o, ofrece la pot en-
cia de cmput o pr esent ada como har dwar e de una comput ador a o, de maner a ms
amplia, por una red de comput ador as accesi bl e medi ant e har dwar e local. Sin impor-
t ar el lugar en que resi da el soft ware, ya sea en un celular o dent ro de una compu-
t adora central, st e es un t r ansfor mador de i nformaci n; realiza la producci n, el
manej o, la adquisicin, la modificacin, el despl i egue o la t ransmi si n de la i nforma-
cin que puede ser t an si mpl e como un sol o bit o t an compl ej a como una pr esent a-
cin mul ti medi a. En su papel de veh cul o para la ent rega de un product o, el soft wa-
re act a como la base para el control de la comput ador a (si stemas operativos), la co-
muni caci n de i nformaci n (redes), y la creaci n y el control de ot ros pr ogr amas
(utileras de sof t war e y ambi ent es).
TM
PDF Editor
CAPTULO 1 SOFTWARE E INGENIERA DEL SOFTWARE 3
( e o N S U f l ^
S se te e tiemp o, te-
am uno o ms de es-
te iros clsicos.
H gase atenci n en
ts indicciones err -
mas q ue estos exp er-
to h icieron en lo
oferente o eventos y
nologias. Cons rve-
se la h umildad: nadie
sab e en realidad el fo-
to) de los sistemas
f e s e construyen.
El sof t war e ent rega el product o m s i mport ant e de nuest r o ti empo: i nformaci n.
Transforma l os dat os per sonal es (por ejempl o, las t r ansacci ones financieras de un
individuo) de forma que los dat os sean m s tiles en un cont ext o local; manej a in-
formaci n de negoci os para mej orar la compet i vi dad; proporci ona una va para las
redes de i nformaci n al rededor del mundo (Internet) y proporci ona los medi os para
adquirir i nformaci n en t odas sus formas.
El papel del sof t war e de comput ador a ha exper i ment ado un cambi o significativo
en un peri odo un poco mayor a 50 aos. Las mej or as sust anci al es en el des empeo
del har dwar e, l os cambi os pr of undos en l as arqui t ect uras de cmput o, los enor mes
i ncr ement os en l as capaci dades de memor i a y al macenami ent o, y la ampl i a varie-
dad de opci ones de salida y de ent r ada han propi ci ado el surgi mi ent o de si st emas
ms el abor ados y compl ej os basados en comput ador as.
Los libros popul ar es publ i cados dur ant e las dcadas de 1970 y 1980 ofr ecen una
ampl i a visin histrica de la cambi ant e percepcin de las comput ador as y del soft wa-
re y su i mpacto en la cultura. Osborne [OSB79] describi una "nueva Revolucin In-
dustrial". Toffler [TOFSO] l l am al surgi mi ento de la microelectrnica parte de "la ter-
cera ola del cambio" en la historia de la humani dad, y Naisbitt [NAI182] predijo la
t ransformaci n de una soci edad industrial en una "sociedad de la informacin". Fei-
genbaum y McCorduck [FEI83] sugirieron que la informacin y el conoci mi ent o (con-
trolados por comput adoras) seran el punt o de enfoque para el poder en el siglo xxi, y
Stoll [STO89] ar gument que la "comunidad electrnica" creada por redes y soft ware
era la cl ave del i ntercambi o de conoci mi ent o al rededor del mundo. Todos est os escri-
t ores tenan razn.
Al comi enzo de la dcada de 1990, Toffler [TOF90] describi un "cambi o de po-
der" en el que t odas l as vi ej as est r uct ur as (gubernament al es, educat i vas, industria-
les, econmi cas y militares) se desi nt egrar an a medi da que l as comput ador as y el
sof t war e conduj er an a una "democrat i zaci n del conoci mi ento". Yourdon [YOU92]
se pr eocupaba de que l as compa as est adouni denses pudi eran per der su mar gen
competi ti vo en negoci os rel aci onados con el soft ware y predi jo "la declinacin y ca-
da del pr ogr amador estadounidense". Hammer y Champy [HAM93] ar gument aban que
las tecnologas de i nformaci n represent ar an un papel primordial en la "reingenie-
ra de la corporacin". A medi ados de la dcada de 1990 la penetraci n de las compu-
t ador as y del sof t war e provoc el surgi mi ent o de una seri e de libros de "neoluditas"
(como Resisting th e Virtual Life, edi t ado por James Brook y Iain Boal, y Th e Future Does
Not Comp ute, de St ephen Talbot). Estos aut or es sat ani zaban a la comput ador a al en-
fatizar i nqui et udes legtimas, per o i gnorando los gr andes benefi ci os que ya se hab an
obt eni do [LEV95],
" l o s comput ador as facilitan la realizacin de muchas cosas, pero la mayor a de l as cosas que fnat r t on no necesitan ho-
ftwfy Rooney
TM
PDF Editor
4 CAPTULO 1 SOFTWARE E I NGENI ERA DEL SOFTWARE
(258339
Poto feeruncomwlo-
rio sobre as amplio
rengo de tpicos reb-
cionadoscor el sotwo-
6 V| ese
A finales de la dcada de 1990, Yourdon [YOU96] eval u de nuevo a l os candi da-
t os a profesi onal es del sof t war e y sugiri el "surgi mi ent o y resurrecci n" del pr ogr a-
mador est adouni dense. A medi da que Internet cobr aba mayor i mportanci a, el giro
que hab a dado Yourdon parec a ser el correcto. Al finalizar el siglo xx, el enf oque
cambi nuevament e, esta vez con el i mpact o del Y2K, "bomba de t i empo" (por ej em-
pl o [YOU98a], [KAR99]). Aunque l as fat al es predi cci ones de aquel l os que vi sl umbra-
ban una cat st rofe respect o al Y2K fuer on falsas, sus popul ar es escri t os acar r ear on
la per manenci a del sof t war e en la vida de l os ser es humanos.
Ya iniciado el nuevo siglo, Johnson [JOHOl] explic el poder del "surgi mi ento" co-
mo un f enmeno que explica lo que sucede cuando i nt erconexi ones pr esent es en
ent i dades rel at i vament e si mpl es resul t an en un si st ema que "se aut oor gani za para
for mar un compor t ami ent o ms adapt abl e e inteligente". Yourdon [YOUR02] r et om
los t rgi cos sucesos ocurri dos el 11 de sept i embre de 2001 en Nueva York par a ex-
plicar el i mpact o cont i nuo del t errori smo global en la comuni dad i nformt i ca. Wol-
fram [WOL02] present un t rat ado sobre "un nuevo tipo de ciencia" en donde expone
una teora unificadora basada sobre t odo en el aboradas si mul aci ones de soft ware. Da-
cont a y sus col egas [DAC03] explicaron la evolucin de la "red semnti ca", y cmo es-
to cambi ar el modo en que la gent e i nteracta a travs de las redes globales.
' Me i nt roduj e en et futuro, ms alia de lo que el ojo humano puede ver. Tuve una visin del mundo y de t odo lo
viiloso que podra ser."
En la actual i dad una enor me industria del sof t war e se ha convert i do en un factor
domi nant e en la econom a del mundo industrializado. El pr ogr amador solitario de la
era inicial ha sido sustituido por equi pos de especi al i st as en soft war e, en l os que ca-
da uno se enf oca en una part e de la tecnol oga requeri da para desarrol l ar una apli-
caci n compl ej a. Hasta ahora, l as pr egunt as f or mul adas al pr ogr amador solitario
son l as mi smas que se hacen cuando se const ruyen l os si st emas basados en compu-
t ador as modernas: 1
Por qu t arda t ant o la obt enci n del sof t war e t ermi nado?
Por qu son t an al tos los cost os de desarrol l o del soft war e?
Por qu es imposible encont r ar t odos los errores en el sof t war e ant es de en-
t regarl o a l os clientes?
I En uri excelente libro de ensayos sobre el negocio del software, Tom DeMarco [DEM95] expone la
idea contraria. Explica: "En vez de cuestionarse por qu cuesta tanto el software, uno debe pregun-
tarse qu se ha hecho para hacer que hoy el software cueste tan poco. La respuesta a esa pregunta
ayudar a continuar con el extraordinario nivel de logros que siempre ha distinguido a la industria
del software".
TM
PDF Editor
Por qu se gast an t ant o t i empo y esf uer zo en el mant eni mi ent o de l os pro-
gr amas exi st ent es?
Por qu es difcil medi r el pr ogr eso al desarrol l ar y darl e mant eni mi ent o al
soft war e?
stas y muchas ot ras pr egunt as demuest r an la preocupaci n de la industria por el
sof t war e y por la maner a en que st e se desarrolla; una preocupaci n que ha con-
ducido a la adopci n de la prctica de la ingeniera del soft ware.
A Cmo debe
V d e f M r s e
el sof t ware?
El software se
desarrolla, no
se manufactura.
\
CLAVE
B software no se
iesgosta, pero
se deteriora.
En 1970, menos del uno por ci ent o de las per sonas podr an haber defi ni do lo que sig-
nificaba "software de comput adora". En la actualidad, la mayora de los profesi onal es
y muchos mi embr os del pbl i co cr een que ent i enden el soft ware. Pero, en realidad
lo hacen?
Una definicin de sof t war e en un libro de texto puede t ener la si gui ente forma: el
software se forma con 1) las instrucciones (p rogramas de comp utadora) q ue al ejecutar-
se p rop orcionan las caractersticas, funciones y el grado de desemp e o deseados; 2) las
estructuras de datos q ue p ermiten q ue los p rogramas manip ulen informaci n de mane-
ra adecuada; y 3) los documentos q ue describ en la op eraci n y el uso de los p rogramas.
No exi st e duda de que se pueden encont r ar defi ni ci ones m s compl et as. Pero se re-
quiere m s que una definicin formal.
Para ent ender el sof t war e (y la ingeniera del software), es i mport ant e exami nar
las caractersti cas que lo hacen di ferente de ot ras cosas que const ruye el ser huma-
no. El sof t war e es un el ement o lgico, en lugar de fsico, de un si st ema. Por lo t an-
to, el sof t war e ti ene caractersti cas muy di ferent es a l as del hardware:
1. El software se desarrolla o construye; no se manufactura en el sentido clsico.
A pesar de que existen similitudes ent re el desarrollo del sof t war e y la manu-
factura del har dwar e, l as dos acti vi dades son di ferent es en lo f undament al . En
ambas, la alta calidad se al canza por medi o del buen di seo, per o la fase de
manufact ur a del har dwar e puede incluir pr obl emas de calidad i nexi st ent es (o
que son fciles de corregir) en el soft ware. Ambas acti vi dades dependen de
l as per sonas, per o la relacin ent re la gent e utilizada y el t r abaj o real i zado es
di ferent e por compl et o (vase el captulo 24). Ambas acti vi dades requi eren la
const rucci n de un "producto", per o l os enf oques son diferentes. Los cost os
del soft ware se concent r an en la ingeniera. Esto significa que los proyect os
de sof t war e no se pueden manej ar como si fuer an proyect os de manuf act ur a.
2. El software no se "desgasta".
En la figura 1.1 se muest r a, para el har dwar e, la t asa de fallas como una f un-
ci n del ti empo. La relacin, l l amada a menudo "curva de la baera", indica
TM
PDF Editor
Tiempo
^ C O N S E J O ^
Si se desea redu el
deterioro del software,
es necesario realiz ar
un mejor dise o ((op -
lalos 9- 12).
CLAVE
Los mtodos de la
ingeniera del software
pretenden reducir lo
magnitud de los picos
y lo pendiente de lo
curva real que se
muestra en la
figuro 1. 2.
que el har dwar e t i ene un nmer o consi der abl ement e alto de fallas al inicio de
su vida (a menudo st as se atribuyen a defect os de di seo o manufact ura).
Despus, los defect os se corri gen y la t asa de fallas baj a hast a un nivel est abl e
(se desea que st e sea muy bajo) por al gn peri odo. Sin embar go, confor me
pasa el tiempo, la t asa de fallas se eleva de nuevo conf or me l os component es
del har dwar e sufren los efect os acumul at i vos del polvo, la vibracin, el abuso,
l as t emper at ur as ext r emas y muchos ot ros mal es ambi ent al es. Expresado en
for ma m s simple, el har dwar e comi enza a desgastarse.
El sof t war e es i nmune a los mal es ambi ent al es que desgast an el hardware.
Por lo t ant o, la curva de la t asa de fallas par a el soft ware deber a t ener la for-
ma de la "curva idealizada" que se muest r a en la figura 1.2. Los defect os sin
descubri r causan t asas de falla al t as en las pr i mer as et apas de vida de un pro-
gr ama. Sin embar go, l os errores se corrigen (en el mej or de los casos sin
agregar ot ros errores) y la curva se apl ana como se muest r a en la figura 1.2.
La curva i deal i zada es una simplificacin bur da del model o de fallas real para
el sof t war e (para m s i nformaci n vase el captulo 26). Sin embar go, la im-
plicacin es clara: el sof t war e no s e desgast a, pero s se deteriora.
Esta contradi cci n apar ent e s e puede explicar de mej or maner a si se consi -
dera la "curva real" de la figura 1.2. Durant e su vida,2 el soft ware experi ment a
cambi os. Confor me st os ocurren se present a la posibilidad de introducir
errores, lo que ocasi ona que la curva de fallas t enga un pico, como se mues-
tra en la figura 1.2. Ant es de que la curva pueda regresar a su est ado original
con una t asa de fallas estable, se requiere ot ro cambi o, lo que ocasi ona que la
2 De hecho, desde el moment o en que comienza el desarrollo, y mucho ant es de que se entregue la
primera versin, el cliente puede solicitar cambios.
TM
PDF Editor
CAPTULO 1 SOFTWARE E INGENIERA DEL SOFTWARE
7
Curvas de
tedia par a
el software.
Tiempo
Curva i deal i zada
Corva real
curva t enga ot ro pico. De est a maner a, el nivel de fallas m ni mo se comi enza
a elevar; el sof t war e se deteriora debi do a los cambi os.
Ot ro aspect o del desgast e ilustra la diferencia ent r e el har dwar e y el soft -
Ln or arte del W 3 r e ' C u a n d o u n c o r n P o n e n t e d e l har dwar e se desgast a se sustituye con un
sofwore <rn se cons- repuest o. Pero en el sof t war e no existen repuest os. Cualquier falla del sof t wa-
troye a lo medida del r e implica un error en el di seo o el pr oceso medi ant e el cual se pas del dis-
c e n t e . o al cdi go mqui na ejecutabl e. Por lo t ant o, el mant eni mi ent o del sof t war e
implica de maner a consi derabl e una compl ej i dad mayor que el del har dwar e.
3 . A p esar de q ue la industria tiene una tendencia h acia la construcci n p or comp o-
nentes, la mayora del software an se construye a la medida.
Consi drese la forma en que se di sea y const ruye un har dwar e de control
para un pr oduct o de cmput o. El i ngeni ero de di seo di buj a un esquema sim-
pl e del si st ema de circuitos digital, realiza al gunos anlisis f undament al es pa-
ra asegur ar se de que el di seo realizar l as funci ones apropi adas y despus
busca en los cat l ogos de component es digitales cada circuito i nt egrado de
acuer do con un nmer o de parte, una funcin definida y validada, una interfaz
bi en definida y un conj unt o est andar i zado de directrices de integracin. Una
vez sel ecci onado cada component e, puede solicitrsele para despus ens am-
blarlo.
Cuando una disciplina de ingeniera evol uci ona se crea una coleccin de
di seos est ndar de component es. Los t omi l l os y los circuitos i nt egrados son
sl o dos ej empl os de l os miles de component es est ndar que utilizan l os in-
geni eros mecni cos y elctricos al di sear si st emas nuevos. Los component es
reutilizables se han cr eado para que el i ngeni ero se pueda concent r ar en l os
TM
PDF Editor
8 CAPITULO 1 SOFTWARE E I NGENI ER A DEL SOFTWARE
el ement os que en real i dad son i nnovador es en el diseo; es decir, en l as par-
tes que r epr esent an algo nuevo. En el mundo del har dwar e, la reutilizacin de
component es es una par t e nat ural del pr oceso de ingeniera. En el mbi t o del
soft war e, dicha actividad apenas se ha comenzado a ext ender.
" l os i deas son los bl oques de construccin de los i deas. "
, H J ason Zebehazy
Un component e de sof t war e se debe di sear e i mpl ement ar de for ma que
pueda utilizarse en muchos pr ogr amas di ferentes. Los component es reutiliza-
bl es moder nos encapsul an t ant o l os dat os como el pr oceso que se aplica a s-
tos, lo que permi t e al i ngeni ero de sof t war e cr ear apl i caci ones nuevas a partir
de par t es reutilizables.3 Por ej empl o, l as i nt erfaces act ual es con el usuar i o se
const ruyen con component es reutilizables que permi t en la creaci n de vent a-
nas grficas, mens despl egabl es y una ampl i a vari edad de mecani smos de
i nt eracci n. Las est r uct ur as de dat os y l os det al l es de pr ocesami ent o requeri-
dos par a construi r la i nt erfaz est n cont eni dos en una librera de componen-
t es reutilizables para la const rucci n de la interfaz.
1 . 3 L a n a t u r a l e z a c a m b i a n t e d e l s o f t w a r e
En la act ual i dad existen siete gr andes cat egor as del sof t war e de comput ador a que
pr esent an ret os cont i nuos para los i ngeni eros de soft war e.
Sof t ware de s i s t e mas . El sof t war e de si st emas es una coleccin de pr ogr amas
escritos para servir a ot ros pr ogr amas. Al gunos pr ogr amas de si st emas (como l os
compi l adores, edi t ores y utileras para la admi ni st raci n de archivos) pr ocesan es-
t ruct uras de i nformaci n compl ej as per o det ermi nadas. 4 Otras apl i caci ones de siste-
ma s (por ej empl o, component es del si st ema operativo, cont rol adores, sof t war e de
red, pr ocesador es par a t el ecomuni caci ones) pr ocesan dat os i ndet ermi nados. En ca-
da caso, el rea de sof t wr e de si st emas se caract eri za por una interaccin muy in-
t ensa con el har dwar e de la comput ador a; utilizacin por ml ti pl es usuari os; oper a-
ci n concurrent e que requi ere la gest i n de itinerarios, de compart i ci n de recursos,
y de pr ocesos sofi sti cados; est ruct uras de dat os compl ej as y mltiples i nt erfaces ex-
t emas.
Sof t ware de apl i caci n. El sof t war e de aplicacin consi st e en pr ogr amas i nde-
pendi ent es que resuel ven una necesi dad de negoci os especfica. Las apl i caci ones en
3 La ingeniera del software basado en componentes se presenta en el captulo 30.
4 El software es determinado si el orden y el ritmo de las entradas, el procesamiento y las salidas son
predecibles. El software es indeterminado si el orden y el ritmo de las entradas, el procesamiento y
las salidas no se pueden predecir.
TM
PDF Editor
9
esta rea procesan dat os empresari al es o tcnicos de forma que facilitan las opera-
ciones de negocios o la toma de decisiones tcnicas o de gestin. Adems del pro-
cesamiento de dat os convencional, el software de aplicacin se utiliza para controlar
las funci ones de negocios en tiempo real (por ejemplo, el procesami ent o de transac-
ciones en los punt os de venta y el control de procesos de manufact ura en tiempo
real.)
Sof t ware ci ent fi co y de ingeniera. El soft ware cientfico y de ingeniera, que se
caracterizaba por algoritmos "devoradores de nmeros", abarca desde la ast ronom a
hasta la vulcanologa, desde el anlisis de la tensin automotri z hasta la dinmica
orbital de los transbordadores espaciales, y desde la biologa molecular hasta la ma-
nufactura automati zada. Sin embargo, las aplicaciones moder nas dentro del rea
cientfica y de ingeniera se alejan en la actualidad de los algoritmos numri cos con-
vencionales. El diseo asistido por comput adora, la simulacin de si st emas y otras
aplicaciones interactivas han comenzado a t omar caractersticas de soft ware en
tiempo real e incluso de software de sistemas.
Sof t ware emport ado. El soft ware emport ado reside dentro de la memoria de slo
lectura del si stema y con l se implementan y controlan caractersticas y funci ones
para el usuario final y el sistema mismo. El soft ware incrustado puede desempear
funci ones limitadas y curiosas (como el control del teclado de un horno de mi croon-
das) o proporcionar capaci dades de control y funci onami ent o significativas (por
ejemplo, las funci ones digitales de un automvil, como el control de combustible, el
despliegue de dat os en el tablero, los si stemas de frenado, etctera).
Sof t ware de l nea de productos. El software de lnea de productos, diseado pa-
ra proporcionar una capacidad especfica y la utilizacin de muchos clientes diferen-
tes, se puede enfocar en un nicho de mercado limitado (como en los productos para
el control de inventarios) o dirigirse hacia los mercados masivos (por ejemplo, apli-
caciones de procesadores de palabras, hoj as de clculo, grficas por computadora,
multimedia, entretenimiento, manej o de bases de datos, administracin de personal
y finanzas en los negocios).
Apl i caci ones basadas en Web. Las "WebApps" engloban un espectro amplio de
aplicaciones. En su forma ms simple, las WebApps son apenas un poco ms que un
conjunto de archivos de hipertexto ligados que presenta informacin mediante texto
y algunas grficas. Sin embargo, a medida que el comercio electrnico y las aplica-
ciones B2B adquieren mayor importancia, las WebApps evolucionan hacia ambi entes
computacionales sofisticados que no slo proporcionan caractersticas, funciones de
cmput o y contenidos independientes al usuario final, sino que estn integradas con
bases de dat os corporativas y aplicaciones de negocios.
Sof t ware de i ntel i genci a artificial. Este soft ware utiliza algoritmos no numri-
cos en la resolucin de probl emas compl ejos que es imposible abordar por medio de
un anlisis directo. Las aplicaciones dent ro de esta rea incluyen la robtica, los sis-
TM
PDF Editor
10 CAPTULO 1 SOFTWARE E INGENIERA DEL SOFTWARE
t emas expert os, el reconoci mi ent o de pat r ones (imagen y voz), las redes neur onal es
artificiales, la comprobaci n de t eor emas y los j uegos en comput ador a.
"No exi st e una comput adora que t enga senti do comn. "
Marvin Minsk y
Existen millones de ingenieros de soft ware que trabajan duro en una o ms de est as ca-
tegoras. En al gunos casos se construyen si st emas nuevos, pero en otros las aplicacio-
nes existentes se corrigen, adapt an y mejoran. Es comn ver a un joven ingeniero de
soft ware que trabaja en programas ms viejos que l mismo. Las generaci ones pasadas
de creadores de sof t war e han dej ado un l egado en cada una de las cat egor as que se
han defi ni do pr r afos atrs. Se espera que el l egado de la generaci n act ual facilite
la t area de l os i ngeni eros de soft ware del futuro. No obst ant e, en el hori zont e han
apareci do ret os nuevos:
Co mp u t a c i n ubi c ua . El creci mi ent o rpido de l as r edes i nal mbri cas podra
conduci r pront o a la verdadera comput aci n distribuida. El ret o para los i ngeni eros
de soft ware ser desarrol l ar soft ware de si st ema y de aplicacin que permita que dis-
positivos pequeos, comput ador as per sonal es y si st emas de empr esa se comuni -
quen a t ravs de gr andes redes.
Al i me nt a c i n d e l a r ed. La World Wide Web se convi erte con rapidez en un dis-
positivo comput aci onal , as como en un proveedor de cont eni do. El reto para los in-
geni eros de soft ware es cr ear apl i caci ones si mpl es (por ej empl o, pl aneaci n de las
finanzas personal es) y compl ej as que beneficien a mer cados de usuar i os finales es-
pecficos al rededor del mundo.
"No si empre es posible predecir, pero siempre es posible pr epar ar se. "
Annimo
: , .I... i;v..;;ivrf;vKMi^W
Fu e nt e a bi e r t a . Existe una t endenci a creci ente que impulsa la distribucin del c-
digo fuent e para aplicaciones de si st emas (como si st emas operativos, bases de dat os
y ambi ent es de desarrollo) de forma que los cl i ent es hagan modi fi caci ones locales.
El ret o para l os i ngeni eros de soft ware es construir un cdi go f uent e que sea descrip-
tivo en s mi smo, pero, an ms i mport ant e, desarrol l ar t cni cas que permi t an t an-
to a los clientes como a los di seador es conocer los cambi os real i zados y la forma
en que se mani fi est an dent ro del soft ware.
La " nue va e c onom a " . La locura del punt o-com que se afi anz en los mer cados
financieros haci a finales de la dcada de 1990 y la subsi gui ent e rupt ura en los pri-
mer os aos del siglo xxi ha l l evado a mucha gent e de negoci os a creer que la nueva
econom a est muert a. La nueva econom a est viva y sal udabl e, pero evol uci onar
con lentitud; la caract eri zar la comuni caci n y la distribucin masi va. Andy Lipp-
man [L1P02J punt ual i za est a situacin cuando escribe:
TM
PDF Editor
CAPTULO 1 SOFTWARE E INGENIERA D a SOFTWARE 11
Estamos entrando en una era caracterizada por las comunicaciones entre las mquinas dis-
tribuidas y la gente dispersa, en lugar de la que define una conexin entre dos individuos o
entre un individuo y una mquina. El antiguo enfoque de la telefona se refiere a "conexio-
nes con"; la siguiente ola se refiere a "conexiones entre". Por mencionar algunos ejemplos,
se tiene Napster, la mensajera instantnea, los sistemas de mensaje cortos y las BlackBe-
rries.
El reto para los ingenieros de soft ware es construir aplicaciones que faciliten la comu-
nicacin y la distribucin de productos en masa medi ant e productos apenas en forma-
cin.
Cada uno de est os "nuevos retos" obedecer sin duda la ley de las consecuenci as
i mprevi stas y t endrn efect os (para la gent e de negoci os, los i ngeni eros de sof t war e
y los usuar i os finales) que no pueden predeci rse en la actual i dad. Sin embar go, los
i ngeni eros de sof t war e se pueden preparar al iniciar un pr oceso que t enga la sufi-
ci ent e agilidad y adaptabi l i dad como para acopl arse a los cambi os drsti cos en la
tecnol oga y l as regl as de negoci os que con seguri dad se pr esent ar n en la dcada
siguiente.
t a ] comput adora por s mi sma har una transicin histrica de algo que se usa pora t ar eas anal t i cas. . . o algo que
puede provocar emoci ones. "
David Vask evitch
M 4 SOFTWARE HSREPAPP
Existen ci ent os de miles de pr ogr amas de comput ador a y t odos per t enecen a uno de
los siete gr andes domi ni os de aplicacin soft ware de si st emas, sof t war e de aplica-
Qu es el c n, sof t war e cientfico y de ingeniera, sof t war e empot r ado, sof t war e de product o,
software WebApps y apl i caci ones IA que se expusi eron en la seccin 1.3. Al gunos de est os
heredado? pr ogr amas son de vanguar di a slo di vul gados ent re ci ertas per sonas, i ndust ri as y
gobiernos, per o ot ros son ms viejos, y en al gunos casos much o ms viejos.
Estos pr ogr amas viejos con frecuenci a referi dos como software h eredado han
sido el foco de at enci n y preocupaci n cont i nua desde la dcada de 1960. Dayani-
Fard y sus col egas [DAY99] describen el sof t war e her edado de la si gui ente forma:
Los sistemas de software heredado... fueron desarrollados hace dcadas y han sido mo-
dificados en forma continua para cumplir los requerimientos de los cambios en los nego-
cios y en las plataformas de cmputo. La proliferacin de dichos sistemas ha causado
dolores de cabeza a las grandes organizaciones, las cuales los perciben como costosos en
su mantenimiento y riesgosos en su evolucin.
Liu y s us col egas (LIU98) ext endi eron est a descri pci n al escribir que "muchos siste-
mas her edados persi st en como el soport e de las funci ones cent ral es de negoci os y
son i ndi spensabl es para l as empr es as ". Por lo t ant o, al sof t war e her edado lo carac-
terizan. su l ongevi dad y el ser crtico par a los negoci os.
TM
PDF Editor
1.4.1 Cal i dad del software her edado
Qu se de-
* be hacer si
se tiene un
software hereda-
do con poca cali-
dad?
f Cules son
los tipos de
cambios que se
realizan sobre
el software
heredado?
^ O N S E J O ^
Cualq uier ingeniero de
software deb e recono-
ce! q ue el camb io es
natural. No deb e in-
tentar comb atirlo.
Por desgracia, existe una caracterstica adicional que tal vez est presente en el soft-
ware heredado: p oca calidad.5 Algunas veces, los si stemas heredados tienen diseos
imposibles de extender, cdigo complicado, document aci n escasa o inexistente, ca-
sos de prueba y resultados que nunca fueron archivados, un historial de cambi o ma-
nej ado con pobreza, etctera; la lista podra seguir hasta tener una longitud consi-
derable. No obstante, est os si stemas son el soporte de "las funci ones centrales de
negocios y son indispensables para las empresas" [LIU98]. Qu se puede hacer?
La nica respuesta razonabl e podra ser no hacer nada, al menos hasta que el sis-
tema heredado experimente algn cambi o significativo. Pero si satisface las necesi-
dades de sus usuarios y funciona de manera confiable, el sistema no est roto y no
requiere arreglos. Sin embargo, conforme pasa el tiempo, los si st emas heredados
evolucionan por una o ms de las razones siguientes:
El soft ware debe adapt arse para satisfacer las necesidades de los nuevos am-
bientes o las nuevas tecnologas de cmputo.
El soft ware debe mejorarse para implementar los nuevos requerimientos de
los negocios.
El soft ware debe extenderse para hacerlo operable con si st emas y bases de
datos ms modernos.
El software debe redisearse para hacerlo viable dentro de un ambiente de red.
Cuando suceden est as formas de evolucin en un software heredado, ste debe so-
meterse a una reingeniera (captulo 31) de modo que conserve su viabilidad en el
futuro. La met a de la ingeniera de soft ware moderna es "imaginar metodologas que
se basen en la nocin de la evolucin"; est o es, la nocin de que "los si st emas de
soft ware cambi an de maner a continua, los nuevos si stemas de soft ware se constru-
yen a partir de los viejos, y... todos deben interactuar y cooperar con los dems"
[DAY99].
1.4.2 Evolucin del software
El soft ware de computadora evoluciona a travs del tiempo, sin importar su dominio
de aplicacin, t amao o complejidad. El cambio (que con frecuencia es llamado
mantenimiento del software) conduce est e proceso, y se presenta cuando se corrigen
errores, cuando el soft ware se adapta a un nuevo ambiente, cuando el cliente soli-
cita caractersticas o funci ones nuevas, y cuando la aplicacin experimenta una rein-
geniera para proporcionar beneficios en un contexto moderno. Sam Williams
[WIL02] refiere esta situacin cuando escribe:
5 En este caso, la calidad se juzga con base en el pensamiento moderno de la ingeniera del softwa-
re, que en cierto modo es un criterio injusto, puesto que algunos conceptos y principios modernos
de la ingeniera del software an no haban sido bien entendidos cuando se desarroll el software
heredado.
TM
PDF Editor
CAPITULO 1 SOFTWARE E INGENIERA DEL SOFTWARE
13
Debido a que los pr ogr amas a gran escal a como Wi ndows y Solaris se expanden bien en
el intervalo de 30 a 50 mi l l ones de lneas de cdigo, los admi ni st r ador es de proyecto exi-
tosos han aprendi do a dedicar t ant o t i empo a combi nar los enr edos de nuest ro cdi go he-
r edado como a agr egar cdi go nuevo. Para decirlo de maner a ms simple, en una dcada
en la que el desempeo pr omedi o del microchip de PC se i ncr ement cien veces, la i nca-
paci dad de escal ar el soft war e i ncl uso a t asas lineales ha pasado de un pequeo secret o
a una enor me al teraci n en t oda la industria.
En los ltimos 30 aos, Manny Lehman [LEH97a] y sus colegas han analizado en
forma detallada la industria del soft ware y los si stemas en un esfuerzo dirigido a de-
sarrollar una teora unificada p ara la evoluci n del software. Los detalles de dicho tra-
bajo superan el enfoque del presente texto,6 pero las leyes subyacentes derivadas de
su estudio son dignas de destacarse [LEH97b]:
La l ey del c a mbi o c ont i nuo ( 1974) . Los si stemas de tipo electrnico7 deben
adaptarse en forma continua, de lo contrario se volvern menos satisfactorios a tra-
vs del tiempo.
La l ey d e l a compl ej i dad cr eci ent e ( 1974) . Cuando un sistema de tipo elec-
trnico est en evolucin, su complejidad se incrementa a menos que se realice el
trabajo necesario para mantenerla o reducirla.
La l ey de la aut or r egul aci n ( 1974) . El proceso de evolucin de un sistema de
tipo electrnico se autorregula con la distribucin del producto y las mediciones del
proceso cercanas a la normal.
La l ey de l a c ons e r va c i n d e l a es t abi l i dad or gani zaci onal ( 1980) . La tasa
de actividad global efectiva promedio en un sistema de tipo electrnico en evolucin
no vara a lo largo del periodo de vida del producto.
La l ey d e la cons er vaci n d e la f ami l i ar i dad ( 1980) . Cuando un sistema de
tipo electrnico est en evolucin y se quiere tener un desarrollo satisfactorio, todos
los involucrados con el sistema, como los desarrolladores, el personal de ventas y los
usuarios, deben mant ener el dominio sobre su conteni do y comportami ento. El cre-
cimiento excesivo disminuye ese dominio. Por tanto, el crecimiento promedio per-
manece sin cambi o durante la evolucin del sistema.
La l ey del cr eci mi ent o c ont i nuo ( 1980) . El contenido funcional de los siste-
mas de tipo electrnico debe i ncrementarse en forma continua para mant ener la sa-
tisfaccin del usuario a lo largo del periodo de vida del sistema.
La l ey d e l a cal i dad de c r e c i e nt e ( 1996) . La calidad de los si stemas de tipo
electrnico parecer declinar a menos que stos se mant engan y adapten en forma
rigurosa de acuerdo con los cambi os en su ambi ent e operacional.
6 Para una clara explicacin de la evolucin del software, el lector interesado puede revisar [LEH97a],
7 Los sistemas de tip o electr nico son programas de software que han sido implementados en un con-
texto computacional del mundo real y que, por tanto, evolucionarn a travs del tiempo.
TM
PDF Editor
14
CAPTULO 1 SOFTWARE E I NGENI ERA DEL SOFTWARE
La l ey del s i s t ema de ret roal i ment aci n ( 1996) . Los procesos de evolucin de
los sistemas de tipo electrnico constituyen sistemas de retroalimentacin con niveles,
ciclos y agentes mltiples, y deben tratarse de forma que se obt engan mejoras signifi-
cativas sobre cualquier base razonable.
Las leyes que Lehman y sus col egas han defi ni do son una par t e i nherent e de la
realidad de un i ngeni ero de soft ware. En lo sucesi vo, en est e t ext o se discutirn mo-
del os para el pr oceso del soft ware, mt odos de ingeniera de sof t war e y t cni cas de
gest i n que pr et enden mant ener la calidad del sof t war e mi ent r as st e se encuent r a
en evolucin.
1 . 5 MI T O S DKL SOFTWARE
Los mi t os del soft ware creencias acerca del sof t war e y de los pr ocesos empl eados
para construirlo se pueden rast rear hast a l os pri meros d as de la comput aci n. Los
mi t os t i enen ci ertos at ri but os que l os convi ert en en insidiosos. Por ejempl o, los mi-
t os parecen una relacin de hechos r azonabl es (al gunas veces cont i enen el ement os
verdaderos), se observan de maner a intuitiva, y con frecuenci a los promul gan prac-
t i cant es experi ment ados, qui enes "conocen el terreno".
"En ausencia de nor mas significativas, una industria nueva como el soft war e suel e c epender de los cost umbres. "
Tom De Ma r c o
R e f e r e n c i a W e b
Lo red de administrado-
res de proyectos de
soflwore puede ayudor
a leiminar con stos y
otros mitos. Dicho red
se puede encontrar en
www. s p mn . c o n i .
En la actualidad, la mayora de los profesi onal es reconoci dos en la ingeniera del
sof t war e identifican los mi tos en su real di mensi n: act i t udes equi vocadas que han
causado pr obl emas serios a los admi ni st radores y al personal tcni co por igual. Sin
embar go, las ant i guas act i t udes y viejos hbi t os son difciles de modificar, por lo que
an subsi st en creenci as fal sas sobre el soft ware.
Mi t os d e l a a d mi ni s t r a c i n. Los admi ni st radores con responsabi l i dades sobre el
soft ware, al igual que sus par es en la mayora de l as disciplinas, a menudo est n ba-
j o presi n por mant ener los presupuest os, evitar que l os itinerarios se ext i endan y
mej orar la calidad. De la mi sma forma que una per sona a punt o de ahogar se se afe-
rra a un tronco, con frecuenci a el admi ni st rador del soft ware se aferra a un mito si
si ent e que esta creenci a reducir la presin (aun en forma temporal).
Mito: Ya se tiene un lib ro lleno de estndares y p rocedimientos p ara la cons
trucci n de software. Esto p rop orcionar a mi gente todo el conocimien-
to necesario?
Real i dad: Tal vez sea verdad que el libro de est ndar es existe, per o se usa? Los
encar gados de la const rucci n del soft ware saben de su existencia?
El libro refleja la prctica moder na de la ingeniera del soft war e? Es-
t compl et o? Es adapt abl e? Est dirigido al mej or ami ent o del tiem-
TM
PDF Editor
CAPTULO 1 SOFTWARE E INGENIERIA DEL SOFTWARE 15
c o n s c j o .
i- resano trab ajar
w p ara entender
m se deb e h acer an-
e s de comenz ar. I n
xtsunes no es p os
xesarrollar todos
o detalles, p ero en-
r; tws se sep a, me-
xr es el riesgo q ue se
po de entrega sin dejar de enfocarse en la calidad? En muchos casos
la respuesta a t odas estas preguntas es no.
Mito: Si se est atrasado en el itinerario es p osib le contratar ms p rogramado-
res p ara as terminar a tiemp o (algunas veces llamado el concep to de la
h orda mongola).
Realidad: El desarrollo de soft ware no es un proceso mecni co como la manu-
factura. En pal abras de Brooks [BR075]: "Agregar gente a un proyec-
to de soft ware at rasado lo atrasa ms". De inicio, est e enunci ado po-
dra parecer contrario a la intuicin. Sin embargo, cuando se agregan
nuevos integrantes a un equipo la gente que ya estaba t rabaj ando de-
be invertir tiempo en la enseanza a los recin llegados, lo cual redu-
ce el tiempo dedicado al esfuerzo para el desarrollo productivo. Se
puede agregar gente, pero slo de una manera pl aneada y bien coor-
dinada.
Mito: Si decido sub contratar el p royecto de software a un tercero, p uedo rela-
jarme y dejar q ue esa comp a a lo construya.
Realidad: Si una organizacin no enti ende cmo administrar y controlar inter-
nament e los proyectos de software, de manera invariable entrar en
conflicto al subcontratar est e tipo de proyectos.
Mitos del cliente. El cliente que solicita un soft ware de computadora puede ser la
persona del escritorio de al lado, un grupo tcnico en el piso de abajo, el departa-
ment o de vent as o de mercadotecnia, o una compa a externa que ha solicitado el
soft ware baj o contrato. En muchos casos, el cliente cree en mitos acerca del soft wa-
re porque los profesionales y administradores del soft ware hacen muy poco para co-
rregir la desinformacin. Los mitos conducen a expectativas falsas (del cliente) y en
definitiva a insatisfaccin con el desarrollador.
Mito: Un enunciado general de los ob jetivos es suficiente p ara comenz ar a es-
crib ir p rogramas; los detalles se p ueden afinar desp u s.
Realidad: A pesar de que no siempre es factible que el enunci ado de los reque-
rimientos sea comprensible y estable, un enunci ado ambiguo de los
objetivos es la receta perfecta para el desastre. Los requerimientos
precisos (los cuales se derivan usual ment e en forma iterativa) se de-
sarrollan slo mediante la comunicacin continua y efectiva entre el
cliente y el desarrollador.
Mito: Los req uerimientos del p royecto camb ian de manera continua, p ero el
camb io p uede ajustarse con facilidad p orq ue el software es flexib le.
Realidad: Es verdad que los requerimientos del soft ware cambian, pero el im-
pact o del cambio vara de acuerdo con el moment o en que st e se in-
troduce. Cuando los cambios en los requerimientos se solicitan en
TM
PDF Editor
16 C A P T U L O 1 SOFTWARE E INGENIERA DEL SOFTWARE
^ C O N S E J O ^
Siemp re q ue se p ien-
se q ue no h ay tiemp o
p aro lo ingeniera del
software, se deb e
considerar si h ab r
tiemp o p ora h acerlo
todo de nuevo.
et apas t empr anas (antes de iniciar con el di seo o el cdigo), el im-
pact o en el cost o es rel at i vament e pequeo. 8 Sin embar go, confor me
pasa el tiempo, el i mpact o en el cost o crece con rapidez se han dis-
tribuido los recursos, se ha est abl eci do un mar co general para el dise-
o y el cambi o puede provocar una convulsin que requi era recur-
sos adi ci onal es y una modificacin significativa en el di seo.
Mi t os del desar r ol l ado! ". Los mi tos que an subsi st en ent re los desabol l ador es
del sof t war e han per maneci do a t ravs de 50 aos de cultura de programaci n. Du-
rant e los pri meros aos del soft ware, la programaci n era vista como una for ma de
arte; por ello, l as viejas for mas y act i t udes son difciles de eliminar.
Mi t o: Una vez q ue el p rograma h a sido escrito y p uesto a funcionar, el trab ajo
est terminado.
Real i dad: Alguien dijo al guna vez que ent re m s rpido se comi ence a escribir
cdigo, ms t i empo pasar para que el pr ogr ama est t ermi nado. Los
dat os de la industria indican que ent re 60 y 80 por ciento de t odo el
esf uer zo apl i cado en el soft ware se realizar despus de que el siste-
ma haya sido ent r egado al cliente por pri mera vez.
Mi t o: Mientras el p rograma no se est ejecutando, no existe forma de evaluar
su calidad.
Real i dad: Uno de los mecani smos m s efectivos para el asegur ami ent o de la ca-
lidad del soft ware se puede aplicar desde el inicio de un proyecto: la
revisin tcnica formal. Las revisiones al soft ware (descritas en el cap-
tulo 26) son un "filtro de calidad" que han pr obado ser ms efectivas
que las pr uebas para encont rar ciertas clases de errores en el soft ware.
Mi t o: El nico p roducto del trab ajo q ue p uede entregarse p ara tener un p royec-
to exitoso es el p rograma en funcionamiento.
Real i dad: Un pr ogr ama en f unci onami ent o es sl o una part e de la confi guraci n
del sof t war e que incluye muchos el ement os. La document aci n pro-
porci ona un f undament o para la ingeniera exitosa y, an ms i mpor-
t ant e, represent a una gua para el mant eni mi ent o del soft ware.
Mi t o: La ingeniera del software ob ligar a emp render la creaci n de una docu-
mentaci n voluminosa e innecesaria y de manera invariab le tornar ms
lento el p roceso.
Real i dad: La ingeniera del sof t war e no se refiere a la el aboraci n de documen-
tos. Est rel aci onada con la creaci n de calidad. Una mej or calidad
8 Muchos ingenieros de software han adopt ado un enfoque "gil" que adapta los cambios en forma
incremental, con lo que se controla su impacto y costo. Los mt odos giles se exponen en el cap-
tulo 4.
TM
PDF Editor
conduce a la reduccin de los trabajos redundant es. Y una menor can-
tidad de trabajos r edundant es resulta en menores tiempos de entrega.
Muchos profesi onal es de los si st emas reconocen la falacia de los mitos del soft-
ware. Por el contrario, las actitudes y los mt odos habituales conducen a adoptar
mal as prcticas administrativas y tcnicas, a pesar de que la realidad exige un me-
jor enfoque. El reconoci mi ento de las realidades del soft ware es el primer paso ha-
cia la formulacin de soluciones prcticas para la ingeniera del software.
Cualquier proyecto de soft ware se inicia por alguna necesidad de negocios: la nece-
sidad de corregir un defecto en una aplicacin existente; el imperativo de adapt ar un
si stema heredado a un ambi ent e de negocios cambi ant e; el requerimiento de ext en-
der las funci ones y caractersticas de una aplicacin existente; o la necesidad de
crear un producto, servicio o sistema nuevos.
Con frecuencia, en el inicio de un proyecto de ingeniera del soft ware la necesi-
dad de negoci os se expresa de manera informal durant e una simple conversacin.
En el recuadro que est abaj o se present a una conversacin tpica.
Con excepcin de una referencia pasaj era, el soft ware no se menci on durant e la
conversacin. Aun as, el soft ware har la diferencia en el futuro de la lnea de pro-
ductos H ogarSeguro. El mercado aceptar el producto slo si el soft ware incrustado
en l satisface de manera apropiada las necesi dades del cliente (que an no ha sido
definido). En los captulos subsecuent es se dar segui mi ent o a la ingeniera del soft-
war e en H ogarSeguro.
HOGARSEGURO9
Cmo se inicia un proyecto
1
La escena: Sala de untas en CPI
, una compaa (ficticia! que fabrica productos de
erjumo para uso comercial y domstico.
Los actores: Mal Golden, gerente general, desarrollo de pro-
3. r e; lisa Prez, gerente de mercadotecnia; tee Warren, geren-
* de ingeniera; Joe Camalleri, vicepresidente ejecutivo, desarrollo
-e negocios. j
La conversacin:
J oe: Dime Lee, de qu se trata ese asunto que escuch? Tu equi-
po est desarrollando un qu? Una caja inalmbrica genrica
universal? * -
Lee: Es genial, como del tamao de una caja de cerillos, se pue-
de conectar a sensores de todos los tipos, una cmara digital, CO-
S a cualquier cosa. Usando el protocolo 802.1 Ib inalmbrico.
9 El proyecto H ogarSeguro se usar a lo largo de este texto para ilustrar los trabajos internos de un
equipo de proyecto, mientras ste construye un producto de software. La compaa, el proyecto y
las personas son ficticios, pero las situaciones y los problemas son reales.
TM
PDF Editor
Nos permite tener acceso a lo salida del dispositivo sin usar ca-
bles. Pensamos que nos llevar a una nueva generacin de pro-
ductos, , ' ' ' y' ,, , f l i .
J oe: Ests de acuerdo, Mal?
Mol; S. De hecho, por las ventas tan irregulares que ha habido
este ao, necesitamos algo nuevo. Lisa y yo hemos estado hacien-
do una pequea investigacin de mercado, y pensamos que te-
nemos una lnea de productos que podra llegar a ser grande.
J oe: Qu tan grande? Como para ser una lnea bsica?
Atol (evitando un compromiso directa): Dile de nuestra
idea, Lisa.
Lisa: Es toda una nueva generacin de lo que llamamos "pro-
ductos para la administracin domstica". Los llamamos H ogarSe-
gtiro. Utilizan la nueva interfase inalmbrica, proporcionan a los
usuarios domsticos o dueos de negocios pequeos un sistema
que se controla con su PC: seguridad en el hogar, vigilancia de la
casa, control de aparatos e instrumentos. T sabes, apagar el aire
acondicionado de tu casa mientras estas manejando, y ese tipo de
cosos f ' ^
Lee (interrumpiendo): Ingeniera hizo un estudio de factibi-
lidad de esta idea, Joe. Se puede realizar a un bajo costo de ma-
nufactura. La mayor parte del hardware lo tenemos en existencia.
El software es un asunto por resolver, pero nada que no podamos
hacer.
J oe: Interesante. Ahora, pregunt sobre la lnea bsica.
Mal: Las PC han penetrado el 60 por ciento de los hogares en
Estados Unidos. Si logramos ponerle el precio adecuado a esta
cosa, podra ser una aplicacin demoledora. Nadie ms tiene
nuestra caja inalmbrica; nos pertenece. Tendremos una ventajo
dedos aos sobre la competencia. Ganancias? Podran ser en-
tre 30 y 40 millones de dlares en el segundo ao.
J oe (sonriendo): Vamos a llevar esto al siguiente nivel. Estoy
interesado.
1 . 7 R E S U ME N
El software se ha convertido en el elemento clave de la evolucin de los sistemas y
productos basados en computadoras, as como en una de las tecnologas ms impor-
tantes en el mbito mundial. En los pasados 50 aos, el software ha evolucionado des-
de ser una herramienta para la solucin de problemas especializados y el anlisis de
informacin, hasta convertirse en una industria por s mismo. Todava se tienen pro-
bl emas al desarrollar soft ware de alta calidad a tiempo y dent ro del presupuesto. El
software programas, datos y documentos se dirige a un amplio espectro de tecno-
logas y r eas de aplicacin. En la actualidad el soft ware evoluciona de acuerdo con
un conjunto de leyes que han permaneci do inalteradas a lo largo de 30 aos. La in-
tencin de la ingeniera del soft ware es proporcionar un marco general para cons-
truir soft ware con una calidad mucho mayor.
R E F E R E N C I A S
[BR0751 Brooks, F., Th e Myth ical Man~Month , Addison-Wesley, 1995.
|DAC03] Dacont a, M L. Obrst y K. Smith, Th e Semantic Web , Wiley, 2003.
IDAY99] Dayani-Fard, H. el al., "Legacy Soft ware Systems: Issues, Progress, and Challenges",
IBM Technical Report: TR-74. 165-k, abril de 1999, disponible en ht t p: / / www. cas. i bm. com/
t oront o/ publ i cat i ons/ TR-74. 165/ k/ l egacy. ht ml .
IDEM951 DeMarco, T Wh y Does Software Cos So Much ?, Dorset House, 1995.
| FEI83| Feigenbaum, E. A. y P. McCorduck, Th e Fifth Generation, Addison-Wesley, 1983.
IHAM93] Hammer, M. y J. Champy, Recingineering th e Corp oration, HarperCollins Publishers,
1993.
TM
PDF Editor
19
[JOHO1 ] Johnson, S., Emergence: The Connected Uves ofAnts, Brains, Cities and Software, Scrib-
ner, 2 0 0 1 .
[KAR99] Karlson, E. y J. Kolber, A Basic Introduction to Y2K. How theyear 2000 Computer Crisis
Affects YOU, Next Era Publications, Inc, 1999.
[LEH97a] Lehman, M y L. Belady, Program Evolution: Processes of Software Change, Academi c
Press, 1997.
[LEH97b] Lehman, M. e al., "Metrics and Laws of Sof t war e EvolutionThe Nineties View", en
Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997,
puede descargarse de ht t p: / / www. ece. ut exas. edu/ ~per i y/ wor k/ paper s/ f east l . pdf .
[LEV95] Levy, S., "The Luddites Are Back", en Newsweek, 12 de julio de 1995, p. 55.
[LIP02] Li ppman, A., "Round 2.0", en Context Magazine, agost o de 2002, ht t p: / / www. cont ext -
mag. com/ .
[LIU98] Liu, K. e al., "Report on t he First SEBPC Workshop on Legacy Systems", Durham Uni-
versity, f ebr er o de 1998, di sponi bl e en ht t p: / / www. dur . ac. uk/ CSM/ SABA/ l egacy- wks pl /
report. html.
[OSB79) Osbor ne, A., Running WildThe Next Industrial Revolution, Osborne/ McGraw-Hi l l ,
1979.
[NAI821 Naisbitt,)., Megatrends, Warner Books, 1982.
[STO891 Stoll, C., The Cuckoo's Egg, Doubleday, 1989.
|TOF80|Tof(ler, A., The Third Wave, Morrow Publishers, 1980.
[TOF90] Toffler, A. Powershift, Bant am Publishers, 1990.
[WIL02] Williams, S., "A Unified Theory of Soft ware Evolution", en salon. com, 2002. ht t p: / / www.
s al n. com/ t ech/ f eat ur e/ 2002/ 04/ 08/ l ehman/ i ndex. ht ml .
[WOL02] Wolfram, S., A New Kind of Science, Wolfram Media, Inc., 2002.
[YOU92] Yourdon, E., The Decline and Fall of the American Programmer, Yourdon Press, 1992.
IYOU96] Yourdon, E., The Rise and Resurrection of the American Programmer, Yourdon Press,
1996.
|YOU98a] Yourdon, E. y J. Yourdon, Time Bomb 2000, Prentice-Hall, 1998.
[YOU98b] Yourdon, E., Death March Projects, Prentice-Hall, 1999.
[YQU02] Yourdon, E., Byte Wars, Prentice-Hall, 2002.
1. 1. Encont rar al me nos ci nco ej empl os adi ci onal es de la maner a en que la ley de l as conse-
cuenci as imprevistas se aplica al soft ware de comput ador a.
1. 2. Encont rar al gunos ej empl os (positivos y negativos) que i ndi quen el i mpact o del sof t war e
en la soci edad actual. Revisar una de las referenci as ant eri ores a 1990 en la seccin 1.1, e indi-
car l as pr edi cci ones del aut or que resul t aron correct as, asi como las que f uer on er r neas.
1. 3. Desarrollar sus propias respuest as a las pregunt as f ormul adas en la secci n 1.1. Debt an-
se con los compaer os de clase.
1. 4. La definicin de soft ware que se present a en la seccin 1.2 se aplica a los sitios Web? Si la
respuest a es afirmativa, indicar la sutil diferencia ent re un sitio Web y el sof t ware convenci onal .
1. 5. Muchas apl i caci ones moder nas cambi an f r ecuent ement e (ant es de present arl as al usua-
rio final y despus de que se empi eza a utilizar la primera versin). Sugi ranse al gunas formas
de construir sof t ware para det ener el det eri oro debido al cambi o.
1. 6. Consi dr ense las si et e cat egor as pr es ent adas en la secci n 1.3. Es posi bl e aplicar el
mi smo enf oque de la i ngeni er a del s of t war e a cada una de el l as? Explicar la r espuest a.
1. 7. Sel ecci onar al guno de los nuevos r et os menci onados en la secci n 1.3 (o al gn desaf o
an ms nuevo que pudiera haber surgi do desde la impresin de est e texto) y escribir un docu-
ment o de una cuartilla que describa la tecnologa y los ret os que represent a para los i ngeni eros
de soft ware.
TM
PDF Editor
20 CAPITULO 1 SOFTWARE E INGENIERA DEL SOFTWARE
1. 8. Descri bi r con pal abr as pr opi as la ley de la conservacin de la estabilidad organizacional
(seccin 1.4.2).
1. 9. Describir con pal abr as propi as la ley de la conservacin de la familiaridad (seccin 1.4.2.).
1. 10. Describir con pal abr as propi as la ley de la calidad decreciente (seccin 1.4.2,).
1. 11. A medi da que la pr esenci a del sof t war e se vuelve ms general i zada, los ri esgos al pbli-
co (debido a las fallas e n los programas) r epr esent an una preocupaci n significativa y creci en-
te. Desarrol l ar un escenar i o cat ast r f i co real i st a en el que la falla de un pr ogr ama de compu-
t adora podr a produci r un gran dao (ya s ea econmi co o humano) .
1 . 1 2 . Exami nar con at enci n al gr upo de not i ci as de I nt er net comp. r i sk y pr epar ar un r esu-
men de los riesgos al pbl i co que se han di scut i do r eci ent ement e. Fuent e al t ernat i va: Software
Engineering Note publ i cada por la ACM.
O T R A S LECTURAS Y FUENTES DE I N F O R MA C I N 1 0
Existen miles de libros que t rat an sobr e el sof t war e de comput ador a. La i nmensa mayor a dis-
cut e los l enguaj es de pr ogr amaci n o las apl i caci ones del sof t ware, per o muy pocos t rat an del
sof t war e en s mi smo. Pr essman y Herrn (Software Shock, Dorset House, 1991) pr esent an uno
de los pri meros debat es (dirigidos al pblico en general) del sof t war e y de la forma en que los
profesi onal es lo const ruyen. El libro ms vendi do de Negropont e (Being Digital, Alfred A. Knopf,
Inc., 1995) of rece una visin de la comput aci n y su i mpact o global e n el siglo xxi. DeMarco
[DEM95] ha escrito una coleccin de ensayos divertidos y pr of undos acer ca del sof t war e y del
pr oceso a t ravs del cual st e se desarrol l a. Los libros de Norman (The Invisible Computer, MIT
Press, 1998) y Bergman (Inf ormat i on Appliances and Beyond, Academi c Pr ess/ Mor gan Kauf-
mann, 2000) sugieren que el i mpact o ext endi do de las PC disminuir conf or me los i nst r umen-
t os de informacin y la comput aci n omni present e conect en a t odos en el mundo industrializado
y casi cual qui er "aparat o" que se posea est conect ado a una nueva i nfraest ruct ura de Internet.
Minasi (The Software Conspiracy: Why Software Companies Put Out Faulty Products, How They
Can Hurt You, and What You Can Do, McGraw-Hill, 2000) ar gument aba que la "plaga moder na"
de las i mpur ezas del sof t war e se puede eliminar y sugi ere f or mas de lograrlo. Compai ne (Digi-
tal Divide: Facing a Crisis or Creating a Myth, MIT Press, 2001) escribe que la "brecha" ent re aque-
llos que t i enen acceso a los r ecur sos de i nformaci n (como la Web) y l os que no lo t i enen se es-
t reduci endo conf or me avanza la pri mera dcada del pr esent e siglo.
En Internet existe una ampl i a variedad de f uent es de i nformaci n sobr e tpicos rel aci onados
con el sof t war e y su admi ni st raci n. Asimismo, en nuest r o sitio web se puede encont r ar una lis-
ta act ual i zada de r ecur sos en la red que son rel evant es para el est udi o del sof t ware:
ht t p: / / www. mh h e . c o m/ p r e s s ma n .
10 La seccin Otras lecturas yfuentes de informacin que se presenta al final de cada captulo ofrece un
breve panorama de las fuentes impresas que pueden ayudarle a aumentar su comprensin de los
t emas principales presentados en este captulo. Hemos creado un sitio de internet muy extenso para
apoyar Ingeniera del sojbvare: un enfoque prctico en ht t p: / / www. mhhe. com/ pressman. Entre los
muchos tpicos incluidos se encuentran referencias captulo por captulo sobre ingeniera del soft-
ware existentes en la red que complementan del material presentado en cada capitulo. Con estas
referencias se proporciona un enlace con Amazon.com para localizar los libros que se mencionan
en cada seccin.
TM
PDF Editor
P A R T E
Uno
EL PROCESO
DEL SOFTWARE
E
n esta parte de Ingeniera del software un enfoque prctico se
estudiar el proceso que proporciona un marco de trabajo
para la prctica de la ingeniera del software. En los captu-
los siguientes se responden estas preguntas:
Qu es un proceso de software?
Cules son las actividades del marco general presentes en
todos los procesos del software?
Cmo se modelan los procesos y cules son los patrones del
proceso?
Cules son los modelos de proceso prescriptivo y cules son
sus fortalezas y debilidades?
Cules son las caractersticas de los modelos incrementales
que los hacen idneos para los proyectos modernos de soft-
ware?
Qu es el proceso unificado?
Por qu la "agilidad" es un lema en el trabajo de la ingeniera
moderna del software? v
Qu es el desarrollo gil del software y cmo difiere de los
modelos de proceso ms tradicionales?
Cuando se respondan estas preguntas se estar mejor prepara-
do para entender el contexto en el cual se aplica la prctica de la
ingeniera del software.
21
TM
PDF Editor
C A P I T U L O
EL PROCESO:
UNA VI SI N GENERAL
C O N C E P T O S
CL AVE
act i vi dades
sombrilla 2 8
conj unt o
de t ar e as 2 7
eval uaci n
del proceso 3 6
IMCM 2 9
ISO 9 0 0 1 : 2 0 0 0 . 38
marco de t r abaj o
del pr oceso 24
pat r ones
del procesa 3 4
PSE . 4 0
PSP 3 9
t ecnol og a
del proceso 42
E
|n un f asci nant e l i bro que of r ece la visin de un economi st a sobre el s o
wa r e y la i ngeni er a del sof t war e, Howar d Baetjer, Jr. [BAE981 come nt a s o
bre el pr oceso del sof t war e:
Debi do a que el sof t war e, c o mo cual qui er capi t al , e s conoci mi ent o mat er i al i zado, y
da do que el conoci mi ent o en un inicio e s di sperso, tcito, l at ent e y e n gr an medi da
i ncompl et o, el desar r ol l o del s of t war e e s un pr oce s o de apr endi zaj e social. El pr oc e s o
e s un di l ogo e n el cual el conoci mi ent o q u e el s of t war e debe convert i r s e conj unt a y
se mat er i al i za e n es t e l t i mo. El pr oces o pr opor ci ona i nt eracci n ent r e l os u s u a r i o s
y l as h e r r a mi e n t a s e n e v o l u c i n , y e n t r e l os d i s e a d o r e s y s u s he r r a mi e nt a s
[tecnolog a]. Es un pr oceso i t erat i vo e n el que la her r ami ent a en evol uci n si rve c o mo
un me di o par a la comuni caci n, en el cual cada nueva et apa del di l ogo logra obt e-
ne r m s conoci mi ent o til de l as pe r s ona s i mpl i cadas.
De hecho, la const r ucci n del s of t war e de comput ador a es un pr oceso itera
tivo de apr endi zaj e, y el resul t ado, al go que Baet j er l l amar a "el capi t al del soft
ware", es una mat eri al i zaci n del conoci mi ent o r ecol ect ado, depur ado y orga
ni zado conf or me el pr oceso est uvo e n ej ecuci n.
Qu e s ? Cuando se trabaja para
construir un producto o sistema es im-
portante seguir una serie de pasos pre-
decibtes: una especie de mapa de ca-
rreteras que ayude a crear un resultado
de alta calidad y a tiempo. El mapa de carreteras
que debe seguirse se llama proceso de software.
Qui n l o h a c e ? Los ingenieros de software
y sus jefes adaptan el proceso a sus necesidades y
despus lo siguen. Adems, la gente que ha so-
licitado el software tiene una funcin qu de-
sempear en el proceso de definirlo, construirlo
y probarlo. s
Por q u e s i mpor t ant e ? Porque ofrece esta
bilidad, control y organizacin a una actividad
que puede volverse catica si no se controla. Sin
e mbar ga un enfoque de ingeniera del software
moderno debe ser "gil". Debe requerir slo
aquellas actividades, controles y documentacio-
nes apropiados para el equipo del proyecto y el
producto que ha de producirse.
Cul es s on l os pa s o s ? En detalle, el proceso que
se adopte depende del software que se est cons-
truyendo. Un proceso puede ser apropiado para
crear un software para un sistema de aeronutica,
mientras que un proceso distinto por completo sera
el indicado para la creacin de un sitio Web.
Cul e s el producto obteni do? Desde el
punto de vista del ingeniero de software, los
productos obtenidos son los programas, docu-
mentos y datos que se producen como conse-
cuencia de las actividades y t areas definidas
por el proceso.
Cmo puedo estar seguro de que lo he
he c ho correct ament e? Existen muchos meca-
nismos de evaluacin del proceso de software que
permiten a las organizaciones determinar la "ma-
durez" del proceso de software. No obstante, la
calidad, el tiempo requerido, la viabilidad a largo
plazo del producto que se construye son los mejo-
res indicadores de la eficacia del proceso que se
utiliza. |
22
TM
PDF Editor
CAPTULO 2 EL PROCESO: UNA VISIN GENERAL
23
Pero, qu e s con exact i t ud un pr oce s o de s of t wa r e de s de un punt o de vista t c-
ni co? Dent r o del cont ext o de e s t e libro, un proceso de software s e def i ne c o mo un
ma r c o de t r abaj o par a l as t ar eas q u e s e r equi er en en la const r ucci n de s of t war e de
alta cal i dad. El pr oce s o e s un s i nni mo de i ngeni er a del s of t war e? La r es pues t a e s
s y no. Un pr oce s o de s of t war e def i ne el e nf oque que se adopt a mi e nt r as el s of t wa -
re est en desar r ol l o. Per o la i ngeni er a del s of t wa r e t ambi n abar ca l as t ecnol og as
que r equi er e el pr oce s o ( mt odos t cni cos y he r r a mi e nt a s aut omat i zadas ) .
An m s i mpor t ant e e s que la i ngeni er a del s of t war e la r eal i zan pe r s ona s
cr eat i vas y con conoci mi e nt o que de be n t r abaj ar en un pr oces o de s of t war e ma du-
ro que s ea apr opi ado par a el pr oduct o que cons t r uyen y par a l as d e ma n d a s de s us
mer cados .
2 . 1 I NGE NI E R A DEL S OF TWARE: UNA T E CNOL OG A ES TRATI F I CADA
A pes ar de que ci ent os de aut or e s ha n def i ni do en f or ma i ndi vi dual la ingeniera del
software, la def i ni ci n que pr opus o Fritz Bauer [NAU69] e n una conf er enci a f unda -
ment al s obr e la mat er i a an s e pue de ut i l i zar c o mo ba s e par a el debat e:
[La ingenier a del s of t war e es] el est abl eci mi ent o y uso de pri nci pi os sl i dos de la i ngeni e-
ra par a obt ener econmi cament e un sof t war e confi abl e y que f unci one de modo efi ci en-
te en mqui nas real es.
Casi cual qui er lector s e sent i r t ent ado a s uma r ot r as i deas a est a definicin. Dice po-
co sobr e los aspect os t cni cos de la cal i dad del sof t war e; no s e refi ere de ma ne r a di-
rect a a la necesi dad de sat i sf acer al cl i ent e o al t i empo de ent r ega de un pr oduct o; omi -
t e menci onar la i mpor t anci a de la medi ci n y la mt ri ca; no est abl ece la i mpor t anci a
de un pr oces o efect i vo. No obst ant e, la definicin de Bauer of r ece una idea bsi ca.
Cul es son "los pri nci pi os sl i dos de la i ngeni er a" que pue de n apl i carse en el desa-
rrollo del s of t war e de comput ador a? De qu ma ne r a s e const r uye "econmi cament e"
un s of t war e "confiable"? Qu se requi ere par a cr ear pr ogr amas de comput ador a que
f unci onen "de ma ne r a efi ci ent e" no sl o en una, si no en vari as "mqui nas real es" di fe-
r ent es? Est as i nt er r ogant es cont i nan s i endo un ret o par a los i ngeni eros de sof t war e.
"Ms q ue una disciplina o un cuer po de conoci mi ent o, la i ngeni er a e s un ver bo, una pa l a br a d e accin, una ma n e r a
de abor dar un pr obl e ma. "
Scot t Wh t r ai r e
El IEEE [IEE93] ha e l abor ado una defi ni ci n m s compr ens i bl e al est abl ecer :
Ingeniera del software: I) La aplicacin de un enfoque sistemtico, disciplinado y cuanti-
ficable al desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de la
ingeniera al software. 2) El estudio de enfoques como en 1).
Y aun as , lo que e s "si st emt i co, di sci pl i nado" y "cuant i fi cabl e" par a un equi po de soft -
war e, pue de s er gr avos o par a ot ro. Se r equi er e de di sci pl i na, per o t ambi n de adap-
t abi l i dad y agi l i dad.
A C mo s e
* d e f n e l a
w software?
TM
PDF Editor
24
PAKTE UNO EL PROCESO DEL SOFTWARE
Es t r a t os d e l a
i n g e n i e r a d e
s of t wa r e .
CLAVE
La ingeniera del
soft ware abarca un
prot eso, mt odos y
herramientas.
C r o s s Me s u n o
www. s t s c
hiH.af.mil.
La i ngeni er a del s of t war e e s una t ecnol og a est r at i f i cada. Como s e mues t r a en la
figura 2. 1, cual qui er e nf oque de la i ngeni er a (i ncl ui do el de la i ngeni er a del s of t wa -
re) de be est ar s us t e nt a do en un c ompr omi s o con la cal i dad. La Gest i n de la Cal i dad
Total, Si gma Sei s y e nf oque s si mi l ar es f ome nt a n una cul t ur a de mej or a cont i nua del
pr oces o, y e s es t a cul t ur a la que al final c onduc e al desar r ol l o de e nf oque s muy ef ec-
t i vos par a la i ngeni er a del s of t war e. La ba s e q u e sopor t a la i ngeni er i a del s of t wa r e
e s un enfoque en la calidad.
La ba s e de la i ngeni er a del s of t wa r e e s el es t r at o del proceso. El pr oce s o de la in-
geni er a del s of t wa r e e s el e l e me nt o que ma nt i e ne j unt os l os es t r at os de la t ecnol o-
g a y que per mi t e el desar r ol l o r aci onal y a t i e mpo del s of t wa r e de comput ador a. El
pr oc e s o def i ne un ma r c o de t r abaj o [PAU93] que de be es t abl ecer s e par a la ent r ega
ef ect i va de la t ecnol og a de la i ngeni er a del s of t war e. El pr oce s o del s of t wa r e f or ma
la ba s e par a el cont r ol de la gest i n de l os pr oyect os de s of t wa r e y est abl ece el con-
t ext o en el cual s e apl i can l os m t odos t cni cos, s e ge ne r a n l os pr oduct os del t r aba-
j o ( model os, doc ume nt os , dat os, r epor t es, f or mat os , et ct er a) , s e es t abl ecen l os f un-
da me nt os , s e as e gur a la cal i dad, y el c a mbi o s e ma n e j a de ma ne r a apr opi ada.
Los mtodos de la i ngeni er a del s of t war e pr opor ci onan l os "cmo" t cni cos par a
const rui r sof t war e. Los mt odos abar can un ampl i o espect r o de t ar eas que i ncl uyen la
comuni caci n, el anl i si s de requi si t os, el mode l a do del di seo, la const r ucci n del
pr ogr ama, la real i zaci n de pr ue ba s y el soport e. Los mt odos de la i ngeni er a del sof t -
wa r e s e bas an en un conj unt o de pri nci pi os bs i cos que gobi er nan cada r ea de la t ec-
nol og a e i ncl uye act i vi dades de model ado y ot r as t cni cas descri pt i vas.
Las herramientas de la i ngeni er a del s of t war e pr opor ci onan el s opor t e aut omat i -
z a do o s e mi a ut oma t i z a do pa r a el pr oc e s o y l os mt odos . Cua ndo l as he r r a mi e nt a s
s e i nt egr an de f or ma q u e la i nf or maci n que cr ee una de el l as pue da usar l a ot r a, s e
di ce que s e ha est abl eci do un s i s t ema par a el s opor t e del desar r ol l o del s of t war e, que
con f r ecuenci a s e de nomi na i ngeni er a del software asistida por computadora.
2 . 2 M A R C O DE T R A B A J O P ARA EL P R OC E S O
Un marco de trabajo est abl ece la ba s e par a un pr oce s o de s of t war e compl e t o al i den-
tificar un n me r o pe q ue o de actividades del marco de trabajo apl i cabl es a t odos l os
pr oyect os de s of t war e, sin i mpor t ar su t a ma o o compl ej i dad. Adems , el ma r c o de
: r abaj o del pr oce s o abar ca un c onj unt o de actividades sombrilla apl i cabl es a lo l ar go
e! pr oce s o del s of t war e.
TM
PDF Editor
25
Un ma r c o d e
t r a b a j o d e l
p r o c e s o
d e s of t wa r e .
Pr oceso del sof t war e
Ma r c o d e t r a ba j o del pr oces o
Act i vi dades sombrilla
Act i vi dad del mar co d e t r a ba j o #1
acci n de la ingenier a de soft ware #1. 1
Conjunto
de tareas
t or eos del t r a ba j o
pr oduci os del t r a ba j o
puni os d e as e gur ami e nt o
d e la c a l i da d
f undame nt os del pr oyect o
acci n de la ingenier a de soft ware #1 .k
Conjunto
de tareas
t or eas del f r a boj o
pr oduct os del t r a ba j o
punt os d e as e gur ami e nt o
d e lo c a l i da d
f undament os del pr oyect o
Act i vi dad del mar co d e t r a ba j o #n
accin de la ingeniera del software #n.l
Conjunto
de tareas
t ar eas del t r a ba j o
d e la c a l i da d
acci n de lo ingeniera de soft ware #n. m
Conjunto
de tareas
t or eas del t r aboj o
d e lo cal i dad
Como s e mues t r a en la figura 2. 2, cada act i vi dad dent r o del ma r c o cont i ene un
c onj unt o de acciones de ingeniera del software-, es decir, una ser i e de t ar eas r el aci o-
na da s que pr oduce un pr oduct o del t r abaj o en la ingeniera del software (por ej empl o,
el di s eo e s una acci n de la i ngeni er a del sof t war e) . Cada acci n la f or man tareas
de trabajo i ndi vi dual es que compl e t an al guna par t e del t r abaj o i mpl i cado por la ac-
ci n.
"Un pr oceso de f i ne qui n est haci endo qu, cundo y cmo l ogr ar cierta me t a . "
I var J acobs on, Gr ady Booch y J a me s Rumbaugh
TM
PDF Editor
26 PARTE UNO EL PROCESO DEL SOFTWARE
El si gui ent e marco de trabajo genrico del proceso (ut i l i zado c o mo ba s e par a la
descr i pci n de l os mode l os de pr oce s o e n l os cap t ul os s ubs ecuent es ) s e pue de apl i -
car en la i nme ns a mayor a de l os pr oyect os de s of t war e:
Co muni c a c i n. Esta act i vi dad del ma r c o de t r abaj o implica una i nt ensa col abo-
r aci n y comuni caci n con l os cl i ent es; 1 a de m s , abar ca la i nvest i gaci n de requi si -
t os y ot r as act i vi dades r el aci onadas.
Pl ane ac i n. Esta act i vi dad es t abl ece un pl an par a el t r abaj o de la i ngeni er a del
s of t war e . Descr i be l as t ar eas t cni cas que de be n r eal i zar se, l os r i esgos pr obabl es,
l os r ecur s os que s e r n r equer i dos, l os pr oduct os del t r abaj o que han de pr oduci r se y
un pr ogr a ma de t r abaj o.
Mo de l a do . Est a act i vi dad abar ca la cr eaci n de mode l os que per mi t en al des a-
rrol l ador y al cl i ent e e nt e nde r mej or l os r equi si t os del s of t war e y el di s eo que l ogra-
r sat i sf acer l os.
Cons t r uc c i n. Esta act i vi dad c ombi na la gener aci n del cdi go (ya s ea ma nua l
o aut omat i zado) y la r eal i zaci n de pr ue bas ne ce s ar i as par a descubr i r er r or es en el
cdi go.
De s pl i e g ue . El s of t wa r e ( como una ent i dad compl et a o un i ncr e me nt o compl e-
t a do de ma ne r a parci al ) s e ent r ega al cl i ent e, qui en eval a el pr oduct o reci bi do y
pr opor ci ona i nf or maci n bas ada en su eval uaci n.
Est as ci nco act i vi dades genr i cas del ma r c o de t r abaj o s on t i l es dur ant e el des ar r o-
llo de pr ogr a ma s pe que os , la cr eaci n de gr a nde s apl i caci ones en la red, y e n la in-
geni er a de s i s t e ma s ba s a dos e n c omput a dor a s gr a nde s y compl ej as . Los det al l es del
pr oce s o del s of t wa r e s er n muy di f er ent es en cada cas o, pe r o l as act i vi dades de nt r o
del ma r c o pe r ma ne c e r n i gual es.
"Enstein a r g u me n t a b a q ue deb a existir una explicacin si mpl i fi cada de la nat ur al e za por que Oos no e s capr i choso ni
ar bi t r ar i o. Tol f e no conf or t a al i ngeni er o del s of t war e. Mucha de la compl ej i dad que de be ma ni obr a r es de carct er
ar bi t r ar i o. "
Fred Br ooks
Si s e us a un e j e mpl o der i vado del ma r c o de t r abaj o genr i co del pr oceso, la act i -
vi dad de elaboracin del modelo la c ompone n d o s acci one s de la i ngeni er a del sof t -
war e: anlisis y diseo. El anl i si s2 abar ca un conj unt o de t ar eas d e t r abaj o (por e j e m-
pl o, la i nvest i gaci n, el abor aci n, negoci aci n, especi f i caci n y val i daci n de r equi -
sitos) q u e c onduc e n a la cr eaci n del mode l o de anl i si s (o a la especi f i caci n de re-
1. Un cliente es cualquier persona que tiene un inters en el xito del resultado del proyecto: gerentes
de negocios, usuarios finales, gente de apoyo, etctera. Rob Thomset bromea diciendo que "un
cliente (en ingls stakeholder) es una persona que sostiene una estaca (stakc) grande y afilada... si
no cuidas a tus clientes, ya sabes dnde terminar la estaca".
2. El anlisis se explicar con mayor detenimiento en los captulos 7 y 8.
9 Cul es
* son l as cinco
act i vi dades del
mar co de t r a ba j o
del pr oces o
ge ne r a l ?
TM
PDF Editor
27
CLAVE
l e n a s proyectos
i diferentes
s de t oreas.
E a qpo de soft ware
conjunto de
u e c s con base en
s j o b l e ma y en las
nrectefsticos del
qui si t os) El di s eo abar ca t ar eas de t r abaj o ( di seo de dat os, di s eo ar qui t ect ni -
co, di s eo de i nt er f az y di s eo al nivel de c ompone nt e s ) que cr e an un mode l o de di-
s e o (una especi f i caci n de di seo) . 3
Como t ambi n s e apr eci a en la figura 2. 2, cada acci n de la i ngeni er a del s of t wa -
re la r epr es ent a un gr an n me r o de di f er ent es conjuntos de tareas: una seri e de t a-
r e a s de t r abaj o, pr oduct os r el aci onados, punt os par a el a s e gur a mi e nt o de la cal i dad
y f unda me nt os de pr oyect o dent r o de la i ngeni er a del s of t war e. El c onj unt o de t a-
r eas que mej or se aj ust e a las neces i dades del pr oyect o y a l as car act er st i cas del equi -
po e s el que s e es coge al final. Est o i mpl i ca que una acci n de la i ngeni er a del sof t -
wa r e ( como el di seo) s e pue de adapt ar a l as ne c e s i da de s espec f i cas del pr oyect o
de s of t wa r e y a l as car act er st i cas del equi po de pr oyect o.
I NFORMACI N
Conjunto de tareas
Un conjunto de tareas define el t r abaj o real
que debe realizarse par a cumplir los objetivos de
j na occin de ingeniera del software. Por ejemplo, la
-ecopilacin de requisitos" es una accin importante de la
-geni er a del software que ocurre durante la actividad de
comunicacin. La meta de la reunin de requisitos es
entender qu desean los distintos clientes del software que
se va a construir.
Para un proyecto pequeo, al parecer simple, el
conjunto de t areas par a la recopilacin de requisitos
nuede ser como se enumera a continuacin:
1. Hacer una lista de los clientes par a el proyecto.
2 Invitar a todos los clientes a una reunin informal.
3. Pedir a cada cliente que haga una lista de
caractersticas y funciones requeridas.
4. Establecer un debat e sobre los requisitos y el aborar
una lista final.
5 Priorizar los requisitos.
6. Advertir las r eas de incertidumbre.
: a r a un proyecto de software mayor y ms complejo, se
-equerira un conjunto diferente de tareas. Este puede
-ckiir la siguiente lista:
1 Hacer una lista de los clientes par a el proyecto.
2- Entrevistar a cada uno de los clientes, por separ ado,
par a determinar de manera general sus deseos y
necesidades.
3. Elaborar una lista preliminar de las funciones y
caractersticas bas adas en la informacin que
ofrezcan los clientes.
4. Hacer un programa de reuniones par a recopilar los
requisitos.
5. Conducir las reuniones.
. Producir escenarios informales de los usuarios como
parte de cada reunin.
7. Refinar escenarios de los usuarios con base en el
intercambio de informacin con los clientes.
8. Elaborar una lista revisada de los requisitos de los
clientes.
9. Utilizar tcnicas de despliegue de funciones de
calidad par a jerarquizar los requisitos.
10. Empaquetar los requisitos par a que puedan
ent regarse de manera incremental.
11. Observar las restricciones que sern puestas en el
sistema.
12. Debatir mtodos par a validar el sistema.
Ambos conjuntos de t areas consiguen la recopilacin
de requisitos, pero son muy diferentes en cuanto a
profundi dad y formalidad. El equi po de software elige el
conjunto de t areas que permitir al canzar la meta de cada
actividad del proceso y accin de ingeniera del software
que mantenga la calidad y agilidad.
3 Cabe acl arar que "la elaboracin del model o" debe interpretarse de un modo diferente cuando se rea-
liza el mant eni mi ent o de un soft ware existente. En al gunos casos ocurre el model ado del di seo y el
anlisis, pero en ot ras situaciones de mant eni mi ent o se le utiliza para ayudar a ent ender el soft ware
heredado, al igual que par a represent ar adi ci ones o modi fi caci ones en ste.
TM
PDF Editor
\
CLAVE
Las a c t i vi da de s
s ombr i l l a ocur r e n a l o
l a r go del p r o c e s o d e
s o f t wa r e y s e e n f o c a n
d e mo d o pr i nci pal e n
la ge s t i n, el r a s t r e o y
el cont r ol del pr oy e c t o.
\
CLAVE
l a a d a p t a c i n del
p r o c e s o d e s o f t wa r e e s
e s e nci al p o r a el xi t o
del pr oy e c t o.
i De qu
m a n e r a
di f i er en l os
model os del
pr oces o e nt r e s i ?
El ma r c o de t r abaj o descr i t o en la vi si n gener al de la i ngeni er a de s of t wa r e l o
compl et a una ser i e de actividades sombrilla. Las act i vi dades t pi cas e n es t a cat egor a
i ncl uyen:
S e g u i mi e n t o y c ont r ol del pr o y e c t o de s o f t wa r e : per mi t e que el e qui po de
s of t wa r e eval e el pr ogr e s o c ompa r ndol o con el pl an del pr oyect o y as t oma r l as
acci one s neces ar i as par a ma nt e ne r el pr ogr ama.
Ge s t i n de l r i e s go: eval a l os r i esgos que pudi er an af ect ar los r es ul t ados del
pr oyect o o la cal i dad del pr oduct o.
As e g ur a mi e n t o de l a c al i dad de l s o f t wa r e : def i ne y c onduc e l as act i vi dades
r equer i das par a as egur ar la cal i dad del s of t war e .
Re v i s i o ne s t c n i c a s f o r ma l e s : eval a l os pr oduct os del t r abaj o de la i ngeni e-
ra del s of t wa r e en un e s f ue r zo e n c a mi n a d o a descubr i r y el i mi nar l os er r or es a nt e s
de que s t os s e pr opa gue n haci a la si gui ent e acci n o act i vi dad.
Me di ci n: def i ne y recol ect a me di ci one s del pr oceso, el pr oyect o y el pr oduct o
par a ayudar al equi po a ent r egar s of t war e que s at i s f aga l as ne ce s i dade s del cl i ent e;
s e pue de us ar en conj unt o con t oda s l as ot r as act i vi dades del ma r c o de t r abaj o o ac-
t i vi dades sombr i l l a.
Ge s t i n d e l a c o nf i gur ac i n del s o f t wa r e : ma n e j a los ef ect os del cambi o a
t r avs del pr oce s o del s of t war e.
Ge s t i n d e l a reut i l i zaci n: def i ne l os cri t eri os par a la reut i l i zaci n de pr oduc-
t os del t r abaj o (se i ncl uyen c o mp o n e n t e s del sof t war e) y est abl ece me c a ni s mos pa -
ra la cr eaci n de c ompone nt e s reut i l i zabl es.
Pr e par ac i n y pr o duc c i n del pr o duc t o d e t rabaj o: abar ca l as act i vi dades
r equer i das par a cr ear pr oduct os del t r abaj o c o mo model os , doc ume nt os , regi st ros,
f or mat os y listas.
Las act i vi dades sombr i l l a s e apl i can dur a nt e el pr oce s o del s of t wa r e y s e t r at an con
det al l e en cap t ul os pos t er i or es de est e t ext o.
Todos l os mode l os de pr oce s o s e car act er i zan dent r o del ma r c o del pr oce s o mo s -
t r ado en la fi gura 2. 2. La apl i caci n i nt el i gent e d e cual qui er mode l o d e pr oce s o del
s of t wa r e de be r econocer que la adapt aci n (al pr obl ema, pr oyect o, e qui po y a la cul -
t ura or gani zaci onal ) e s esenci al par a el xi t o de est a act i vi dad. Per o l os mode l os de
pr oce s o di f i eren de ma n e r a f undame nt al en:
El flujo gl obal de act i vi dades y t ar eas, y l as i nt e r de pe nde nci as ent r e l as ac-
t i vi dades y l as t ar eas.
El gr ado e n el cual l as t ar eas de t r abaj o est n def i ni das dent r o de c a da ac-
tividad del ma r c o de t r abaj o.
El gr a do e n el cual s e i dent i f i can y s e sol i ci t an l os pr oduct os de t r abaj o.
La f or ma en la que s e apl i can l as act i vi dades de as egur ami ent o de la cal i dad.
La ma n e r a en la que s e apl i can l as act i vi dades de s egui mi ent o y cont rol .
TM
PDF Editor
CAPTULO 2 EL PROCESO. UNA VEI N GENERAL 29
El gr ado gener al de det al l e y el rigor con el que se descr i be el pr oceso.
El gr a do en el que los cl i ent es e s t n c ompr ome t i dos con el pr oyect o.
El gr ado de a ut onom a ot or gado al equi po de pr oyect o de s of t war e.
El gr ado en el cual e s t n def i ni dos la or gani zaci n y l as r es pons abi l i dades
e n el equi po.
"Si ent o que una r ec eto es slo un l e ma con el que un cocinero i nt el i gent e pue de j ugar cada vez de una mane r a di st i nt a. "
Ma d a ma Benoi t
r
Los mode l os de pr oc e s o que e nf at i zan la def i ni ci n, la i dent i f i caci n y la apl i caci n
det al l ada de l as act i vi dades del pr oce s o han si do apl i cados dent r o de la comuni dad
de la i ngeni er a del s of t wa r e en l os l t i mos 30 aos . La apl i caci n de es t os modelos
prescrptivos i nt ent a mej or ar la cal i dad del si st ema, hace r que l os pr oyect os s e an m s
manej abl es , que l as f e chas de ent r ega y los cos t os s e a n m s pr edeci bl es, y gui ar a
l os e qui pos de i ngeni er os de s of t war e mi ent r as r eal i zan el t r abaj o que r equi er e cons -
truir un si st ema. Por desgr aci a, ha habi do oc a s i one s en que es t os obj et i vos no s e han
al canzado. Si l os mode l os pr escr i pt i vos s e apl i can en f or ma dogmt i ca y sin ni ngu-
na adapt aci n, s t os pue de n i ncr e me nt ar el gr ado de bur ocr aci a as oci ada con la
cons t r ucci n de s i s t emas ba s a dos en c omput a dor a s , y de ma ne r a i nadver t i da cr ear
di f i cul t ades par a l os des ar r ol l ador es y los cl i ent es.
En a o s r eci ent es s e han pr opue s t o mode l os de pr oce s o que s ubr ayan la agi l i dad
del pr oyect o y si guen un conj unt o de pri nci pi os, 4 l os cual es c onduc e n a un e nf oque
car act er i za m ^ s i nf or mal par a el pr oce s o del s of t wa r e (di cho e nf oque n o e s me n o s ef ect i vo, se-
oceso gn a r gume nt a n qui e ne s l o pr opusi er on) . Est os modelos giles del proceso r esal t an la
"? manej abi l i dad y adapt abi l i dad. Son apr opi ados par a mu c h o s t i pos de pr oyect os y s on
t i l es de ma ne r a par t i cul ar c ua ndo se desar r ol l an apl i caci ones en la red.
Cul de l os e nf oque s par a el pr oc e s o del s of t wa r e e s el mej or ? Esta pr egunt a ha
ocas i onado un de ba t e emoci onal ent r e l os i ngeni er os de s of t wa r e y s e abor dar en
el cap t ul o 4. Por ahor a, e s i mpor t ant e dar s e cue nt a de que e s t os dos e nf oque s de
pr oc e s o t i enen una me t a c omn: cr ear s of t war e de al t a cal i dad que sat i sf aga l as ne-
ces i dades del cl i ent e, pe r o t i enen per spect i vas di f er ent es.
El I nst i t ut o de Ingeni er a del Sof t war e (SEI, por s u s si gl as en ingls) ha des ar r ol l ado
un mode l o compl et o de un ampl i o pr oce s o ba s a do en un conj unt o de capaci dade s
de s of t wa r e y de s i s t e ma s que deben es t ar pr e s e nt e s c onf or me l as or gani zaci ones
a l c a nz a n di f er ent es gr ados de capaci dad y ma dur e z del pr oceso. El SEI s os t i ene que
par a l ograr e s t a s c a pa c i da de s una or gani zaci n de be cr ear un mode l o de pr oc e s o (fi-
gur a 2.2) que s e aj ust e a l as di r ect r i ces es t abl eci das por la integracin del modelo de
capacidad de madurez (IMCM) [CMM02].
" ff ' WnBBBmSBRtM
' l c l K e r . w W c i ' ) l O w i i j j i l
4 Los modelos giles y los principios que los guan se explican en el captulo 4
TM
PDF Editor
30
PARTE UNO EL P R O C E S O DEL S O F T WA R E
Per f i l d e c a p a -
c i d a d d e l r e a
d e l p r o c e s o d e
l a I MCM
[PHI02].
R e f e r e n c i a W e b
Uno "mf oi madn
IMCM p u e d e
obl enei se en
ht t p: / / www. s e L
cmu. ed. i i / anmi / .
1
s
- 8
I
Z
pp
Pl a ne a c i n de l pr oye c t o
GR Ge s t i n d e r equi si t os
MA Me di c i n y anl i s i s
G C
Ge s t i n d e l a c onf i gur a c i n
ACPP As e g u r a mi e n t o d e l a c a l i d a d
de l p r o d u c t o y el p r o c e s o
GR
MA G C ACPP
r e a d e l p r o c e s o
La IMCM r epr es ent a un mode l o compl e t o de pr oc e s o en d o s f or ma s di f er ent es: 1)
c o mo un mode l o cont i nuo y 2) c omo un mode l o di scr et o. El mode l o cont i nuo IMCM
descr i be un pr oc e s o en dos di mens i ones , c o mo s e i l ust ra en la figura 2. 3. Cada r ea
del pr oce s o (por ej empl o, la pl ane aci n del pr oyect o o la gest i n de l os requi si t os)
se eval a de ma ne r a f or mal cont r a l as me t a s y pr ct i cas es pec f i cas y s e cl asi fi ca de
a c ue r do con l os s i gui ent es ni vel es de capaci dad:
Ni vel O: I nc o mpl e t o . El r ea del pr oc e s o (por ej empl o, la gest i n de requi si t os)
a n no s e real i za o t odav a no al canza t odas l as me t a s y obj et i vos def i ni dos par a el
nivel 1 de capaci dad.
Ni vel 1: Re al i z ado. Todas l as me t a s espec f i cas del r e a del pr oce s o ( como l as
def i ni la IMCM) ha n si do sat i sf echas. Las t ar eas de t r abaj o r equer i das par a pr odu-
cir el pr oduct o espec f i co ha n s i do r eal i zadas.
Ni vel 2: Admi ni s t r ado. Todos l os cri t eri os del ni vel 1 han si do sat i sf echos. Ade-
ms , t odo el t r abaj o as oci ado con el r ea de pr oce s o s e aj us t a a una poltica or gani -
zaci onal defi ni da; t oda la ge nt e que ej ecut a el t r abaj o t i ene a c c e s o a r ecur s os ade-
c ua dos par a r eal i zar su l abor; l os cl i ent es e s t n i mpl i cados de ma ne r a act i va e n el
r ea de pr oceso, c ua ndo e s t o s e r equi er e; t oda s l as t ar eas de t r abaj o y pr oduct os es-
t n " moni t or eados , cont r ol ados y r evi sados; y s on e val uados e n a pe go a la descr i p-
cin del pr oces o" [CMM02].
Ni vel 3: De f i ni do. Todos los cr i t er i os del ni vel 2 s e ha n cumpl i do. Adems , el
pr oce s o es t " adapt ado al conj unt o de pr oc e s os e s t ndar de la or gani zaci n, de
acue r do con l as pol t i cas de adapt aci n de est a mi s ma , y cont r i buye a la i nf or maci n
de l os pr oduct os del t r abaj o, me di ci one s y ot r as mej or as del pr oce s o par a l os act i -
vos del pr oce s o or gani zaci onal " [CMM02],
Ni vel 4: Admi ni s t r ado e n f o r ma cuant i t at i va. Todos l os cri t eri os del nivel 3
han si do cumpl i dos. Adems , el r ea del pr oce s o s e cont r ol a y mej or a me di ant e me-
di ci ones y eval uaci n cuant i t at i va. "Los obj et i vos cuant i t at i vos par a la cal i dad y el
TM
PDF Editor
31
d e s e mp e o del pr oce s o e s t n es t abl eci dos y s e ut i l i zan c o mo un cri t eri o par a admi -
ni st r ar el pr oces o" [CMM02],
Ni vel 5: Me j or ado. Todos l os cri t eri os del ni vel 4 ha n si do sat i sf echos. Ade ms ,
el r e a del pr oce s o "se adapt a y me j or a me di a nt e el us o de me di os cuant i t at i vos (es-
t ad st i cos) par a conoce r l as ne c e s i da de s c a mbi a nt e s del cl i ent e y mej or ar de ma n e -
ra cont i nua la ef i caci a del r ea del pr oce s o que s e es t cons i der ando" [CMM02],
"Gran pa r t e de i a crisis del s of t war e es aut oi nf l i gi da, como cuando CIO dice: "Pr ef i er o que est mal a q ue est t ar de.
Si empr e podemos r epar ar l o des pus . "
Ma r k Paul k
( CONSEJ O^ -
ax orgomzotin
alo IMCM.
Se nbargo, la
3Bc aspecto del
-axto puede sei
Gsw en algunas
La IMCM def i ne cada r ea del pr oc e s o en f unci n de " met as espec f i cas" y de l as
"pr ct i cas espec f i cas" r equer i das par a al canzar di chas me t as . Las metas especficas
es t abl ecen l as car act er st i cas que de be n exi st i r par a que l as act i vi dades i mpl i cadas
por un r ea de pr oce s o s e an ef ect i vas. Las prcticas especficas convi er t en una me t a
e n un conj unt o de act i vi dades r el aci onadas con el pr oceso.
Por ej empl o, la pl a ne a c i n de l pr o y e c t o e s una de l as oc ho r e a s del pr oce s o
def i ni das por la IMCM par a la cat egor a de "gest i n del proyect o". 5 Las me t a s e s pe -
c fi cas (ME) y l as pr ct i cas espec f i cas as oci adas (PE) que s e ha n def i ni do par a la pl a-
neaci n del pr oyect o s on [CMM02]:
ME 1 E s t abl e c e r e s t i ma c i o n e s
PE 1.1-1 Est i mar el al cance del pr oyect o.
PE 1.2-1 Est abl ecer e s t i maci one s par a los at r i but os del pr oduct o y l as t ar eas
del t r abaj o.
PE 1.3-1 Defi ni r el ci cl o de vida del pr oyect o.
PE 1.4-1 Det er mi nar e s t i maci one s de e s f ue r z o y cost o.
ME 2 De s arrol l ar un pl an d e pr o y e c t o
PE 2. 1-1 Est abl ecer el pr e s upue s t o y el pr ogr ama.
PE 2. 2-1 Ident i fi car l os r i esgos del pr oyect o.
PE 2. 3-1 Pl anear la gest i n de l os dat os.
PE 2. 4-1 Pl anear l os r ecur s os del pr oyect o.
PE 2. 5-1 Pl anear l os conoci mi e nt os y habi l i dades que s e r equi er en.
PE 2. 6-1 Pl anear la par t i ci paci n del cl i ent e.
PE 2. 7-1 Est abl ecer el pl an de pr oyect o.
5 Otras reas del proceso definidas como "gestin del proyecto" incluyen: monitoreo y control del pro-
yecto, gestin de acuerdos con proveedores, gestin integrada del proyecto para IPPD, gestin del
riesgo, integracin del equipo, gestin de integracin del proveedor y gestin cuantitativa del pro-
yecto.
TM
PDF Editor
Re f e r e n c i a We b
Una informacin
compl e t o, a s i c omo
obtenerse en
www. s e i . t n u .
e d u / t mmi / .
ME 3 Co mp r o me t e r s e c o n l a pl a ne a c i n
PE 3. 1-1 Revi sar l os pl a ne s que af ect an el pr oyect o.
PE 3. 2-1 Conci l i ar el t r abaj o y l os ni vel es de r ecur sos.
PE 3. 3-1 Compr ome t e r s e con la pl aneaci n
Ade m s de l as me t a s y pr ct i cas espec f i cas, la IMCM t ambi n def i ne una ser i e de
ci nco me t a s ge nr i cas y pr ct i cas r el aci onadas con cada r ea del pr oceso. Cada una
de l as me t a s genr i cas c or r e s ponde a u n o de l os ci nco ni vel es de capaci dad. Por lo
t ant o, par a l ograr un nivel de capaci dad par t i cul ar s e de be al canzar la me t a genr i -
ca par a e s e nivel y l as pr ct i cas genr i cas que cor r e s ponde n a es a met a. Par a i l us-
t rar lo ant er i or , a cont i nuaci n s e e n u me r a n l as me t a s ge nr i cas (MG) y l as pr ct i -
c a s genr i cas (PG) par a el r ea del pr oce s o de pl aneaci n del pr oyect o [CMM02J:
MG 1 Al c anz ar l as me t a s e s pe c i f i c a s
PG 1.1 Real i zar pr ct i cas bas e.
MG 2 I ns t i t uci onal i zar un p r o c e s o de g e s t i n
PG 2. 1 Est abl ecer una pol t i ca or gani zaci onal .
PG 2. 2 Pl anear el pr oceso.
PG 2. 3 Pr opor ci onar r ecur sos.
PG 2. 4 Asi gnar r esponsabi l i dades.
PG 2. 5 Capaci t ar gent e.
PG 2. 6 Manej ar conf i gur aci ones .
PG 2. 7 Ident i fi car y hace r par t i ci par a cl i ent es.
PG 2. 8 Moni t or ear y cont r ol ar el pr oceso.
PG 2. 9 Eval uar la adher enci a de un mo d o obj et i vo.
PG 2. 10 Revi sar el e s t a t us con un al t o gr ado de gest i n.
MG 3 I ns t i t uci onal i zar un p r o c e s o de f i ni do
PG 3.1 Est abl ecer un pr oce s o def i ni do.
PG 3. 2 Recol ect ar i nf or maci n de la mej or a.
MG 4 I ns t i t uci onal i zar un p r o c e s o ma n e j a d o e n f o r ma cuant i t at i va
PG 4. 1 Est abl ecer obj et i vos cuant i t at i vos pa r a el pr oces o.
PG 4.2 Est abi l i zar el d e s e mp e o del s ubpr oces o.
MG 5 I ns t i t uci onal i zar un p r o c e s o d e me j o r a mi e nt o .
PG 5.1 Asegur ar la me j or a cont i nua del pr oceso.
PG 5. 2 Corregi r l as c a us a s de l os pr obl e mas de s de la ra z
El mode l o di scr et o d e la IMCM def i ne l as mi s ma s r eas , me t a s y pr ct i cas del pr o-
c e s o que el mode l o cont i nuo. La pri nci pal di f er enci a e s que el mode l o di scr et o es t a-
bl ece ci nco ni vel es de ma dur e z , en vez de ci nco ni vel es de capaci dad. Para l ograr un
nivel de ma dur e z s e de be n cons egui r me t a s y pr ct i cas espec f i cas r el aci onadas con
un conj unt o de r e a s del pr oces o. La r el aci n ent r e l os ni vel es de ma dur e z y l as
r e a s del pr oc e s o s e mue s t r a n en la figura 2. 4.
TM
PDF Editor
CAPITULO 2 EL PROCESO: UNA VISIN GENERAL
33
I NFORMACI N
La IMCM: se debe o no hacer?
La IMCM es un modelo total del proceso. Defi-
ne (en al rededor de 700 pginas) las caracte-
- cas del proceso que deben existir si una organizacin
establecer un proceso de software completo. La pre-
que se ha debatido durante una dcada es la IMCM
a excesiva? Como la mayor part e de las cosas en la vida (y
an el software) la respuesta no es un simple s o no.
Siempre debe adopt arse el espritu de la IMCM. Frente
3 esgo de la simplificacin excesiva, se argument a que el
re-arrollo del software debe tomarse con seriedad: debe
cxanearse; debe controlarse de manera uniforme; debe
; ~earse con precisin; debe conducirse de manera pro-
s o n a l . Debe centrarse en las necesi dades de los clientes
o s proyecto, las habilidades de los ingenieros de software
la calidad del producto terminado. Nadi e debe poner en
duda estas deas.
-os requisitos detallados de la IMCM deben tomarse en
: _enta con seriedad si una organizacin construye siste-
mas grandes y complejos que impliquen docenas o cientos
de personas por varios meses o aos. Es posible que la
IMCM sea correcta en ciertas situaciones, si la cultura orga-
nizacional es flexible frente a modelos de procesos estnda-
res y se realiza una gestin par a lograr que sea un xito.
No obstante, en ot ras situaciones 3S posible que la
IMCM sea demasi ado par a que una organizacin la asi-
mile de manera exitosa. Esto significa que la IMCM es
mala o demasi ado burocrtica o que est pasada de mo-
da? No. Tan slo significa que lo correcto par a la cultura
de una compa a puede no serlo par a otra.
La IMCM es un logro significativo par a la ingeniera del
software. Proporciona una exposicin integral de las activi-
dades y acciones que deben estar presentes cuando una
organizacin construye un software de comput adora. Aun
si una organizacin de software elige no adopt ar sus deta-
lles, todo equi po de software debe retomar su espritu y
aprender de su exposicin del proceso y la prctica de la
r e a s d e l
r e q u e r i d a s
p e a a l c a n z a r
i c ni vel d e
s c x t u i e z .
Ni vel E nf oque
reas del proce s o
De opti mi zaci n
Mejora
continua del
proteso
Innovaci n organi zaci onal y de s pl i e gue
Anl i si s caus al y resol uci n
Ges t i onado de
mo do cuanti tati vo
Gestin
cuantitativa
E jecucin del proces o organi zaci onal
Gesti n cuanti tati va del proyect o
Def i ni do
Estandarizacin
del proceso
Desarrol l o de requi si tos
Sol uci n tcnica
Integraci n del product o
Verificacin
Val i daci n
E nfoque del proces o organi zaci onal
Definicin del proces o organi zaci onal
Capaci taci n organi zaci onal
Gesti n i nt egrada del proyect o
Gesti n i nt egrada del prove e dor
Gesti n del ri es go
Anl i si s y resol uci n de l a deci si n
Ambi ent e organi zaci onal para l a i nt egraci n
E quipo i nt egrado
Ges t i onado
Gestin
bsica del
proyecto
Gesti n de requi si tos
Pl aneaci n del proyect o
Moni t oreo y control del proyect o
Gesti n de acuerdos del prove e dor
Medi ci n y anl i si s
As egurami ent o de la cal i dad del
producto y del proces o
Gesti n de la conf i guraci n
E jecutado
TM
PDF Editor
34 PASTE UNO EL PROCESO D A SOFTWARE
P A T R O N E S DEL P P O C E S O
Qu es un
pat r n
del pr oces o?
El pr oce s o de s of t war e pue de def i ni r se c o mo una col ecci n de pa t r one s que def i nen
un conj unt o de act i vi dades, acci ones, t ar eas de t r abaj o o c ompor t a mi e nt os r el aci o-
na dos [AMB98] que r equi er e el desar r ol l o de un s of t wa r e de c omput a dor a . Di cho en
t r mi nos gener al es , un patrn de proceso of r ece una pl ant i l l a: un m t odo cons i s t en-
t e pa r a descri bi r una car act er st i ca i mpor t ant e del pr oce s o de s of t war e. Medi ant e la
combi naci n de pat r ones , un e qui po de s of t wa r e pue de const r ui r un pr oce s o que s a-
t i sf aga lo me j or posi bl e l as ne ce s i dade s de un pr oyect o.
"Lo repet i ci n de pot r ones es muy di st i nt o o la repet i ci n de par t es. Adems, l as por t es di f er ent es s e r n nicas por que
los pat r ones s on ni cos. "
Ch r i s t o p h e r Al e x a n d e r
CVVE
Uno pl ant i l l o del p o t r n
o f r e c e un me d i o
c ons i s t e nt e por a
descr i bi r un pot r n.
Los pa t r one s pue de n def i ni r se e n cual qui er gr ado d e abst r acci n. 6 En al gunos ca-
s os s e pue de ut i l i zar un pat r n par a descri bi r un pr oce s o compl et o (por ej empl o, un
prot ot i po). En ot r as s i t uaci ones se ut i l i zan l os pa t r one s par a descri bi r una act i vi dad
del ma r c o de t r abaj o i mpor t ant e ( como la pl aneaci n) o una t ar ea dent r o de una ac-
tividad del ma r c o de t r abaj o (por ej empl o, la es t i maci n de un pr oyect o) .
Ambl er [AMB98] pr opus o la si gui ent e plantilla par a descri bi r un pat r n de pr oceso:
No mb r e del pat r n. Al pat r n s e le as i gna un nombr e si gni fi cat i vo que descr i ba su
f unci n de nt r o del s of t wa r e ( como c o mu n i c a c i n c o n el cl i ent e) .
Pr ops i t o. Se descr i be con br evedad el obj et i vo del pat r n. Por ej empl o, el obj et i -
vo de la c o mu n i c a c i n c o n e l c l i e nt e e s "est abl ecer una r el aci n de col abor aci n
con el cl i ent e en un e s f ue r zo e nc a mi na do a defi ni r el al cance del pr oyect o, l os requi -
si t os del ne goci o y ot r as condi ci ones del pr oyect o". El pr ops i t o pue de expandi r s e
con t ext os expl i cat or i os adi ci onal es y di agr amas apr opi ados, si s e r equi er en.
Ti po. Se especi f i ca el t i po de pat r n. Ambl er [AMB98] sugi er e t r es tipos:
Los patrones de tarea def i nen una acci n de la i ngeni er a del s of t war e o
una t ar ea de t r abaj o que e s par t e del pr oce s o y r el evant e par a una pr ct i -
ca exi t osa de la i ngeni er a del s of t wa r e (por ej empl o, la r e c o pi l ac i n d e
r e qui s i t o s e s un pat r n de t ar ea) .
Los patrones de escenario def i nen una act i vi dad del ma r c o de t r abaj o par a
el pr oces o. Debi do a que una act i vi dad del ma r c o de t r abaj o r ene ml t i -
pl es t ar eas de t r abaj o, un pat r n de e s ce nar i o i ncor por a ml t i pl es pat r o-
ne s de t ar ea r el evant es par a el e s ce nar i o (actividad del ma r c o de t r abaj o) .
Un e j e mpl o del pat r n de es cenar i o e s la c o muni c a c i n. Est e pat r n i n-
cor por ar a el pat r n de t ar ea r e uni n d e r e qui s i t o s y ot r os.
6 Los patrones se aplican a muchas actividades de ingeniera del software. El anlisis, el diseo y los
patrones de prueba se explican en los captulos 7, 9, 10, 12y 14. Los patrones y "antipatrones" para
las actividades de gestin de proyectos se explican en la parte 4 de este libro.
TM
PDF Editor
35
Los patrones de fase def i nen la s e cue nci a de act i vi dades del ma r c o de t r a-
ba j o que ocur r e j unt o con el pr oces o, a un c ua ndo el fl uj o gener al de act i -
vi dades e s i t erat i vo por nat ur al eza. Un ej empl o de un pat r n de f ase puede
s er un mo d e l o e n e s pi ral o d e c o ns t r uc c i n d e pr ot ot i pos . 7
Co n t e x t o i ni ci al . Se des cr i ben l as condi ci ones e n l as cual es s e apl i ca el pat r n.
Ant es de iniciar st e s e de be cues t i onar 1) q u act i vi dades or gani zaci onal es o rel a-
t i vas al equi po han ocur r i do, 2) cul e s el e s t a do de e nt r ada par a el pr oces o, y 3)
qu i nf or maci n de i ngeni er a del s of t war e o i nf or maci n del pr oyect o ya exi st e.
Por ej empl o, el pat r n de pl a ne a c i n (un pat r n di scret o) r equi er e q u e 1) l os
cl i ent es y l os i ngeni er os de s of t wa r e hayan est abl eci do una col abor aci n e n c ua nt o
a comuni caci n; 2) s e haya c ompl e t a do con xi t o un gr an n me r o de pa t r one s de
t ar ea (especi f i cados) par a el pat r n de c o mu n i c a c i n c o n e l cl i ent e; y 3) s e co-
noz c a n l os al cance s del pr oyect o, l os r equi si t os bs i cos del negoci o y l as rest ri c-
ci ones del pr oyect o.
Pr obl e ma. Se descr i be el pr obl ema que debe resol ver el pat r n. Por ej empl o, el pr o-
bl ema que debe resol ver l a c o mun i c a c i n c o n e l c l i e nt e pue de descri bi rse de la
si gui ent e mane r a: La comunicacin entre el desarrolladory el cliente muchas veces es
inadecuada porque no se establece un formato efectivo para obtener informacin, no se
crea un mecanismo til para registrarla, y no se realiza una revisin significativa.
Sol uc i n. Se descr i be la i mpl ement aci n del pat r n. En est a secci n s e di scut e c-
mo el e s t a do inicial del pr oce s o ( exi st ent e a nt e s de que se haya i mpl e me nt a do el
pat r n) s e modi f i ca c o mo cons ecuenci a del inicio del pat r n. Tambi n s e descr i be
c mo la i nf or maci n de la i ngeni er a del s of t wa r e o la i nf or maci n del pr oyect o,
di sponi bl e a nt e s de i ni ci ado el pat r n, s e t r ans f or ma c o mo cons e cue nci a de la ej e-
cuci n exi t osa del pat r n.
Co n t e x t o r e s ul t ant e . Se descr i ben l as condi ci ones que habr una ve z que el pa -
t rn haya s i do i mpl e me nt a do con xi t o. Para compl et ar el pat r n de be n r eal i zar se
l as s i gui ent es pr egunt as : 1) qu act i vi dades or gani zaci onal e s o r e l aci onadas con
el equi po debi er on habe r ocur r i do?, 2) cul e s el e s t a do de sal i da par a el pr oce -
so?, y 3) qu i nf or maci n de la i ngeni er a del s of t wa r e o i nf or maci n del pr oyect o
ha si do desar r ol l ada?
Pa t r o n e s r e l a c i o na do s . Se pr opor ci ona una lista de t odos l os pa t r one s de pr oce -
s o di r e ct ame nt e r e l aci onados con st e, en f or ma j er r qui ca o de al guna ot ra f or ma.
Por ej empl o, el pat r n es t aci onar i o de c o mu n i c a c i n abar ca l os pa t r one s de t ar ea
r e uni n de l e q u i p o para e l pr oye c t o, de f i ni c i n d e una l ne a de c o l a bo r a -
ci n, a i s l a mi e nt o d e a l c a n c e s , r e uni n d e r e qui s i t os , de s c r i pc i n d e r e s -
t r i c c i one s y una c r e a c i n de un mo d e l o mi ni - s pe c .
7 Estos patrones de fase se exponen en el capitulo 3.
TM
PDF Editor
www. o mb y s o f t .
( o m/ p r o t e s s
Pat t er nsPoge. ht ml .
Us o s c o n o c i d o s / E j e mp l o s . Se i ndi can i os e j e mpl os espec f i cos e n l os cual es el
pat r n e s apl i cabl e. Por ej empl o, la c o mun i c a c i n e s obl i gat or i a al pri nci pi o de
cada pr oyect o de s of t war e; s e r e comi e nda por me di o del pr oc e s o de s of t war e, y e s
obl i gat ori a una vez que la act i vi dad de de s pl i e g ue est r eal i zada.
Los pa t r one s de pr oc e s o pr opor ci onan un me c a ni s mo ef ect i vo par a descri bi r
cual qui er pr oc e s o de s of t war e. Los pa t r one s per mi t en una or gani zaci n de i ngeni e-
ra del s of t wa r e par a desar r ol l ar un descr i pci n del pr oce s o j er r qui co que comi e n-
ce en un al t o gr ado de abst r acci n (un pat r n de fase). La descri pci n s e refina hast a
un c onj unt o de pat r one s es t aci onar i os q u e descr i ben act i vi dades del ma r c o de t r a-
baj o, y m s t ar de s e refi na de un mo d o j er r qui co e n pat r one s de t a r e a s m s det a-
l l ados par a cada pat r n est aci onar i o. Despus de que s e han desar r ol l ado los pat r ones
de pr oceso, pue de n r eut i l i zar se par a la def i ni ci n de var i ant es de pr oceso; e s decir,
un equi po d e s of t war e pue de defi ni r un mode l o de pr oc e s o pe r s onal i zado us a ndo
pat r one s c o mo bl oques de cons t r ucci n par a el mode l o de pr oceso.
I NFORMACI N
Ejemplo de un patrn del proceso
El siguiente patrn de proceso abr evi ado des-
cri be un enf oque apl i cabl e cuando los clientes
tienen una i dea gener al de lo que debe hacerse, pero no
est n seguros de los requisitos especficos del software.
Nombre del patrn. Prototipo.
Pr o p s i t o . El objetivo del pat rn es construir un model o
(un prototipo) que los clientes evalen de modo iterativo
en un esfuerzo encami nado a identificar los requisitos
del software.
Ti po. Patrn de fase.
Co n t e x t o i ni ci al . Deben cumplirse las siguientes condi-
ciones ant es de iniciar este pat rn: 1) los clientes han
sido identificados; 2) se ha establecido un modo de co-
municacin ent re los clientes y el equi po de t r abaj o; 3)
los clientes han identificado el pr obl ema que ha de re-
solverse; 4) se ha desarrol l ado un entendimiento inicial
del al cance del proyecto, los requisitos bsi cos del ne-
goci o y las restricciones del proyecto.
Pr o b l e ma . Los requisitos son vagos o no existen. No
obstante, se reconoce con cl ari dad la existencia de un
probl ema, y ste de be ir a c ompa a do de una solucin
de software. Los clientes no est n seguros de lo que de-
sean; es decir, no pueden describir ningn detalle de
los requisitos del software.
So l uc i n. Aqu se present a una descripcin del proceso
de prototipo. Para ms detalles, vase el captulo 3.
Co n t e x t o r e s ul t a nt e . Los clientes apr ueban un prototi-
po de software que identifica requisitos bsi cos (por
ej empl o, model os de interaccin, rasgos comput aci ona-
les, funci ones de procesamiento). Despus 1) el prototi-
po puede evolucionar recorriendo una serie de
incrementos pa r a convertirse en el software de produc-
cin, o 2) el prototipo se descart a y el software de pro-
duccin se construye con otros pat rones de proceso.
P a t r o n e s r e l a c i o n a d o s . Los siguientes pat r ones est n
r el aci onados con est e pat r n: c o mu n i c a c i n c o n
el cliente; di seo iterativo; desarrol l o itera-
tivo; eval uaci n del cliente; extracci n de
requisitos.
Us o s c o n o c i d o s / e j e mp l o s . El prototipo se recomien-
da cuando los requisitos son inseguros.
2 . 5 E V A L U A C I N PE , P R OC E S O
La exi st enci a de un pr oc e s o de s of t wa r e no e s gar ant a de que s t e s er e nt r e ga do
a t i empo, de que sat i sf ar l as ne c e s i da de s del cl i ent e, o de que mos t r ar l as car ac-
t er st i cas t cni cas que conduci r n a car act er st i cas de cal i dad a l ar go pl azo (cap t u-
lo 26). Los pat r one s de pr oce s o de be n ir a c o mp a a d o s de una pr ct i ca sl i da de la
TM
PDF Editor
37
Mejorami ento del
proceso de s of t ware
Determinacin
de la capaci dad
Motiva
CLVE
i " c e v a l u a c i n s e
T & n e c o mp r e n d e r
3 e s t a d o oc t uol d e l
TXSSO d e s o f t w a r e y
n t e n t o me j o r a r l o .
^ De q u e
t cni cas
: < ol e s s e
s p o n e pa r a
n d i u r el pr oces o
fc s o f t wa r e ?
i ngeni er a del s of t wa r e (part e 2 de est e libro). Adems , el pr oc e s o mi s mo de be eva-
l uar se par a as e gur ar s e de que cumpl a una ser i e de cri t eri os bs i cos del pr oc e s o que
han de mos t r a do s er es enci al es par a una i ngeni er a de s of t wa r e exi t osa. 8 La r el aci n
ent r e el pr oce s o de s of t wa r e y l os m t odos apl i cados par a la eval uaci n y el mej o-
r ami e nt o s e mues t r a en la figura 2.5. Se ha n pr opue s t o var i os e nf oque s par a la eva-
luacin del proceso de software en l as d c a da s pas adas :
El m t o d o d e e v a l ua c i n d e l a IMCM e s t nda r par a e l me j o r a mi e n t o del
p r o c e s o ( ME IE MP) of r ece un mode l o de ci nco pa s os par a la eval uaci n del pr oce-
s o que i ncl uye la i ni ci aci n, el di agnst i co, el est abl eci mi ent o, la acci n y el apr e n-
di zaj e. El m t odo MElEMP utiliza el SE1 IMCM (secci n 2.3) c o mo ba s e par a la eva-
l uaci n [SEIOO],
La apr e c i ac i n ba s a da e n el CMM par a el me j o r a mi e n t o del p r o c e s o i n-
t e r no (ABC MPI) of r ece una t cni ca de di agnst i co par a eval uar la ma dur e z rel a-
tiva de una or gani zaci n de s of t wa r e me di ant e la ABC MPI (un pr ecur s or de la IMCM,
el cual s e expl i c en la secci n 2.3) c o mo ba s e par a la eval uaci n [DUNOi].
El e s t n d a r S PI CE ( 1 S O / I E C 1 5 5 0 4 ) d e f i n e u n c o n j u n t o d e r e q u i s i t o s p a r a l a
eval uaci n del pr oce s o de s of t war e; lo que pr e t e nde e s ayudar a l as or gani zaci ones
en el desar r ol l o de una eval uaci n obj et i va de la ef i caci a de cual qui er pr oce s o de
s of t war e def i ni do [SPI99].
El I S O 9 0 0 1 : 2 0 0 0 p a r a s o f t w a r e e s u n e s t n d a r g e n r i c o q u e s e a p l i c a a c u a l -
q u i e r o r g a n i z a c i n q u e d e s e e me j o r a r l a c a l i d a d g e n e r a l d e l o s p r o d u c t o s , s i s t e ma s
8 La IMCM del SEI [CMM02] describe, en detalle y con amplitud, l as caracter sticas de un proceso de
soft ware y los criterios para un pr oceso exitoso.
TM
PDF Editor
o servi ci os que pr ovee. Por lo t ant o, el e s t ndar s e apl i ca de mo d o di r ect o a c ompa -
as y or gani zaci one s de s of t war e.
Debi do a que el ISO 9001: 2000 s e us a de ma ne r a ampl i a e n el mbi t o i nt er naci onal ,
s e e xa mi na r con br evedad en l os pr r af os que si guen.
"Los or gani zaci ones de s of t war e han mos t r ado defi ci enci as si gni fi cat i vas en su habi l i dad par a capi t al i zar l as exper i en-
cias g a n a d a s en pr oyect os compl et os. "
NASA
La Or gani zaci n I nt er naci onal de Es t andar i zaci n (ISO, por s us si gl as en ingls)
ha est abl eci do el e s t ndar ISO 9001: 2000 [ISOOO] par a defi ni r l os r equi si t os de un
si st ema de gest i n de cal i dad (cap t ul o 26) que sirva par a el abor ar pr oduct os de m s
al t a cal i dad y as mej or ar la sat i sf acci n del cl i ent e. 9
La est r at egi a f unda me nt a l que sugi er e el ISO 9001: 2000 s e descr i be de la si gui en-
t e ma ne r a :
El ISO 9001: 2000 s ubr aya la i mpor t anci a que t i ene par a una or gani zaci n i dent i fi car, i m-
pl ement ar , ges t i onar y mej or ar de ma ne r a cont i nua la ef ect i vi dad de l os pr oc e s os ne ce s a-
rios par a el s i s t e ma de admi ni st r aci n de la cal i dad, y ges t i onar l as i nt er acci ones de es t os
pr oces os par a cons egui r l os obj et i vos de la or gani zaci n. . .
El ISO 9001: 2000 ha a dopt a do un ci cl o de "pl anear - hacer - r evi s ar - act uar " que se apl i -
ca a l os e l e me nt os de gest i n de cal i dad de un pr oyect o de s of t war e. Dent r o de un
cont ext o de s of t war e, "pl anear " est abl ece l os obj et i vos, l as act i vi dades y t ar eas del
pr oce s o neces ar i os par a cons egui r un s of t wa r e de al t a cal i dad y una sat i sf acci n
del cl i ent e; "hacer " i mpl ement a el pr oces o de s of t war e (i ncl ui das l as act i vi dades del
ma r c o de t r abaj o y l as act i vi dades sombri l l a); "revi sar" moni t or ea y mi de el pr oce s o
par a as e gur ar s e de que t odos l os r equi si t os es t abl eci dos par a la gest i n de cal i dad
hayan si do cumpl i dos; "act uar " inicia l as act i vi dades de me j or a mi e nt o del pr oc e s o de
s of t war e, el cual t i ene una cont i nui dad de t r abaj o par a me j or ar el pr oceso.
Para un t r at ami ent o m s det al l ado del ISO 9001: 2000 l os l ect or es i nt er es ados en
el t e ma de be n cons ul t ar l os e s t nda r e s ISO o [CIA01], [KET01] o [MONOIJ.
2 . 6 MO D E L O S DE P R OC E S O P E RS ONAL E S Y EN E QUI P O
El mej or pr oces o de s of t war e e s el que es t cer ca de la gent e que real i zar el t r abaj o.
Si un mode l o de pr oce s o de s of t wa r e ha s i do des ar r ol l ado en un mbi t o cor por at i vo
u or gani zaci onal , puede s er ef ect i vo s l o si e s en gr an medi da adapt abl e par a sat i s-
f acer l as ne c e s i da de s del equi po del pr oyect o, que e s el que en r eal i dad lleva a c a bo
el t r abaj o de i ngeni er a del s of t war e. En un es cenar i o ideal, c a da i ngeni er o de sof t -
wa r e cr ear a un pr oce s o que l l ene lo me j or posi bl e s us pr opi as neces i dades , y al mi s-
9 El asegur ami ent o de la calidad del sof t war e (ACS), un el ement o i mport ant e de la gestin de calidad,
ha sido definido como una actividad sombrilla que se aplica a t ravs de todo el mar co de t rabaj o del
proceso. Se expone en detalle en el capitulo 26.
Un e xc e l e nt e r e s u me n
del ISO 9 0 0 1 : 2 0 0 0
puede encont r as e e n
h t t p : / / p r o x l o m.
com/ i s o-
9001 . ht m.
TM
PDF Editor
39
mo t i empo sat i sf aga l as ampl i as ne c e s i da de s del equi po y la or gani zaci n. De mo d o
al t er nat i vo, el e qui po mi s mo cr ear a su pr opi o pr oces o, y al mi s mo t i e mpo cubri r a
l as ne ce s i dade s m s r educi das de l os i ndi vi duos y l as ne ce s i dade s ampl i as de la or -
gani zaci n. Wat t s Humphr ey ([HUM97] y [HUMOO]) a r gume nt a que e s posi bl e cr ear
un "pr oces o de s of t wa r e per s onal " o un "pr oces o de s of t wa r e en equi po". Ambos re-
qui er en de un a r duo t r abaj o, capaci t aci n y coor di naci n, pe r o a mb o s s e pue de n
consegui r . 1 0
"Unn per s ona que t i ene xi t o slo se ho f o r ma d o el hbi t o de hacer l as cosos que lo g ent e sin xi t o no ha c e . "
De xt e r Yager
A Ot Kt i vi -
V U H M
r a 4* t r a ba j o
* S z a n dur an-
fcdPSP?
2.6.1 Proceso de software personal (PSP)
Cada desar r ol l ador utiliza al gn pr oce s o par a const r ui r un s of t wa r e de c omput a do-
ra. El pr oc e s o pue de s er f ort ui t o o ad hoc, pue de cambi ar a di ari o, pue de no s er efi -
ci ent e, ef ect i vo o has t a exi t oso, pe r o exi st e un pr oceso. Wat t s Humphr ey [HUM97]
s ugi er e que par a cambi ar un pr oc e s o per sonal i nefect i vo, un i ndi vi duo de be pas ar
por cuat r o f ases, en l as cual es se r equi er e capaci t aci n e i ns t r ument aci n cui dado-
sa. El proceso de software personal (PSP) r esal t a la medi da per s onal del pr oduct o de
t r abaj o que se pr oduce y la cal i dad r esul t ant e del pr oduct o de t r abaj o. Ade ms , el
PSP r esponsabi l i za al pr of esi onal e nc a r ga do de la pl aneaci n del pr oyect o (por ej em-
pl o, la es t i maci n y la pl ani f i caci n) y le conf i er e el pode r de cont r ol ar la cal i dad de
t odos l os pr oduct os de t r abaj o del s of t wa r e que s e desar r ol l an.
El mode l o PSP def i ne ci nco act i vi dades del ma r c o de t r abaj o: pl aneaci n, di s eo
de al t o nivel, revi si n del di s eo de al t o nivel, desar r ol l o y anl i si s de r esul t ados.
Pl ane ac i n. Est a act i vi dad sel ecci ona r equi si t os y, con ba s e en st os, desar r ol l a
el t a ma o y la es t i maci n de l os r ecur sos. Adems , s e es t i man los def ect os (el n-
me r o de def ect os pr oyect ado en el t r abaj o) . Todas l as me di ci one s s e r egi st r an en ho-
j as de t r abaj o o en pl ant i l l as. Al final, s e i dent i f i can l as t ar eas de desar r ol l o y s e cr ea
un pr ogr a ma del pr oyect o.
Di s e o de al t o ni vel . Se el abor an l as es peci f i caci ones e xt e r nas par a q u e cada
c ompone nt e s ea cons t r ui do y s e cr ea un di s eo del c ompone nt e . Se cons t r uyen pr o-
t ot i pos c ua ndo exi st e i ncer t i dumbr e. Todos l os e l e me nt os s e regi st ran y r as t r ean.
Re vi s i n de l di s e o d e al t o ni vel . Los m t odos f or mal es de veri f i caci n (cap-
t ul o 26) s e apl i can a er r or es des cubi er t os en el di seo. Las me di ci one s s e ma nt i e ne n
par a t odas l as t ar eas i mpor t ant e s y l os r es ul t ados de t r abaj o.
De s ar r ol l o. El di s eo al nivel de c ompone nt e s e r ef i na y revi sa. Se gener a, re-
visa, compi l a y pr ueba el cdi go. Las me di ci one s s e mant i e ne n par a t odas l as t ar eas
i mpor t ant e s y l os r es ul t ados de t r abaj o.
10 Vale la pena mencionar que los proponentes del desarrollo gil del software (capitulo 4) tambin ar-
gumentan que el proceso debe permanecer cerca del equipo. Ellos proponen un mtodo alternativo
para lograrlo.
TM
PDF Editor
40
PARTE UNO a PROCESO DEL SOFTWARE
CLAVE
El PSP d e s t o c o l o
n e c e s i d a d d e r e gi s t r a r
y a n a l i z a r l o s t i p o s d e
e r r o r e s q u e s e
c o me t e n p o r a
d e s a r r o l l a r e s t r a t e g i a s
e n c a mi n o d o s o
e l i mi n a r l o s .
ts informacin sobre
lo construccin de
equipos de al t o
desempefl o empl eando
el PSE y el PSP puede
obt enerse en
www. sel . cmu.
eAi/tsp/.
Anl i s i s de r e s ul t ado s . Medi ant e l as medi ci ones y me di da s r ecol ect adas (una
cant i dad sust anci al de da t os de be anal i zar s e de ma ne r a est ad st i ca) s e det er mi na la
ef ect i vi dad del pr oceso. Las medi ci ones y me di da s de be n of r ecer una gu a par a mo -
di fi car el pr oc e s o y as me j or ar su ef ect i vi dad.
El PSP des t aca la necesi dad que t i ene cada i ngeni er o de s of t wa r e de i dent i f i car l os
ei Tores de s de el pri nci pi o y la i mpor t anci a de e nt e nde r l os t i pos de er r or es que s ue -
le comet er . Est o se lleva a c a bo me di ant e una act i vi dad de eval uaci n r i gur osa apl i -
cada en t odos l os pr oduct os de t r abaj o que ge ne r a el i ngeni er o de s of t war e.
El PSP r epr es ent a un e nf oque di sci pl i nado, ba s a do en medi ci ones, de la i ngeni e-
ra de s of t wa r e que puede conduci r a un c hoque de cul t ur as a mu c h o s pr of es i ona-
les. Sin e mba r go, c ua ndo el PSP s e pr es ent a de un modo a de c ua do a l os i ngeni er os
de s of t wa r e [HUM96], la mej or a r esul t ant e en la pr oduct i vi dad de la i ngeni er a del
s of t wa r e y la cal i dad de s t e son si gni f i cat i vas [FER97]. No obst ant e, la i ndust ri a no
ha a dopt a do con ampl i t ud el PSP. Las r azone s , t r i st ement e, t i enen m s r el aci n con
la nat ur al eza h u ma n a y la i nerci a or gani zaci onal que con l as f ue r z a s y debi l i dades
del e nf oque del PSP. Est e l t i mo e s un r e t o i nt el ect ual y d e ma n d a un gr ado de c om-
pr omi s o (por par t e de l os pr of es i onal es y s us j efes) que n o s i empr e e s posi bl e obt e-
ner. La capaci t aci n e s r el at i vament e l arga y s u s cos t os son al t os. En lo cul t ural , el
gr ado r equer i do de medi ci n e s difcil par a muc ha gent e i nvol ucrada con el sof t war e.
Una i nt er r ogant e e s si el PSP pue de us ar s e c o mo un pr oce s o de s of t war e ef ect i vo
a un ni vel per sonal . La r es pues t a es, sin duda, s. Pero a un si el PSP no e s a dopt a do
en su t ot al i dad, val e la pe na est udi ar mu c h o s de l os conce pt os de me j or a del pr oce-
s o que st e pr es ent a.
2.6.2 Proceso de software en equipo (PSE)
Debi do a que muc hos pr oyect os de s of t war e en el mbi t o i ndust ri al l os dirige un equi -
po de pr of esi onal es, Wat t s Humphr ey ext endi l as l ecci ones apr endi das par a la i nt ro-
ducci n del PSP y pr opus o un proceso de soJ\ware en equipo (PSE). La me t a del PSE e s
const rui r un equi po de pr oyect o "aut odi ri gi do" que se or gani ce par a pr oduci r un sof t -
wa r e de alta cal i dad. Humphr ey [HUM98] def i ne l os si gui ent es obj et i vos del PSE:
Const r ui r equi pos aut odi r i gi dos que pl a ne e n y t engan un s e gui mi e nt o de su
t r abaj o, es t abl ezcan me t a s y pos e an s us pr oce s os y pl anes. Est os gr upos
pue de n ser e qui pos de s of t wa r e pur os o equi pos de pr oduct o i nt egr ado
(EP1) de 3 a 20 i ngeni er os.
Most r ar a l os j ef es c mo pr e par ar y mot i var a s us e qui pos y c mo ayudar -
l os a s os t ener un al t o de s e mpe o.
Acel er ar el me j or a mi e nt o del pr oc e s o de s of t wa r e al r eal i zar , con el c om-
por t ami e nt o nor mal y e s pe r ado, el nivel 5 del MCM.
Of r ecer una gu a de me j or a mi e nt o a or gani zaci one s de al t a ma dur e z .
TM
PDF Editor
CAPTULO 2 EL PROCESO: UNA VISIN GENERAL 41
^ O M S E J O ^ ^
CLAVE
Facilitar la e ns e a nz a uni ver si t ar i a de habi l i dades de e qui po i ndust ri al de
cal i dad.
Un e qui po aut odi r i gi do e nt i e nde en f or ma cons i s t ent e s us me t a s y obj et i vos ge-
ner al es. Def i ne f unci one s y r es pons abi l i dades par a cada uno de s us mi embr os ; re-
gi st ra da t os cuant i t at i vos del pr oyect o ( como pr oduct i vi dad y cal i dad); i dent i fi ca un
pr oceso de equi po apr opi ado par a el proyect o y una est rat egi a para i mpl ement ar el pro-
ceso; def i ne e s t nda r e s l ocal es apl i cabl es al t r abaj o de i ngeni er a de s of t wa r e del
equi po, eval a e n cada mo me n t o riesgos y r eacci ones; y regi st ra, ges t i ona y r epor t a
el es t at us del pr oyect o.
"Encont r ar buenos j ugador es es fcil. Hacer que j ueguen en equi po es ot ra hi st ori a. "
Ca s e y St a n g e l
El PSE def i ne l as si gui ent es act i vi dades del mar co de t rabaj o: l anzami ent o, di seo
de al t o nivel, i mpl ement aci n, i nt egr aci n y pr ueba, y anl i si s de resul t ados. Al igual
que sus cont r apar t es en el PSP (nt ese que la t er mi nol og a e s di ferent e), es t as activi-
da de s per mi t en al equi po pl anear , di sear y const rui r un s of t war e de una ma ne r a dis-
ci pl i nada al mi s mo t i empo que mi den de modo cuant i t at i vo el pr oces o y el pr oduct o.
Los anl i si s de r esul t ados mue s t r an el es cenar i o par a el mej or ami ent o del pr oceso.
El PSE utiliza una ampl i a vari edad de escritos, f or mas y es t ndar es que si rven par a
gui ar a l os mi e mbr os del e qui po en su t r abaj o. Los escritos def i nen act i vi dades es pe-
c fi cas del pr oce s o (por ej empl o, l anzami ent o, di seo, i mpl ement aci n, i nt egr aci n
y pr ueba, y anl i si s de r es ul t ados del proyect o) y ot r as f unci ones m s det al l adas del
t r abaj o ( como pl aneaci n del desar r ol l o, desar r ol l o de requi si t os, gest i n de la con-
figuracin de s of t war e y pr ueba de uni dad) que son par t e del pr oce s o del equi po.
Con fines i l ust rat i vos, e s til t omar en cue nt a la act i vi dad inicial del pr oceso: el lan-
zamiento del proyecto.
Cada pr oyect o e s "l anzado" con una s ecuenci a de t ar eas (defi ni da c o mo un escri -
to) que per mi t e al e qui po est abl ecer una ba s e sl i da par a iniciar el pr oyect o. Se re-
c omi e nda el si gui ent e escrito de lanzamiento (sl o de ma ne r a gener al ) [HUMOOj:
Revi sar l os obj et i vos del pr oyect o con la gest i n y acor dar y doc ume nt a r
l as me t a s del equi po.
Est abl ecer l as f unci ones del equi po.
Definir el pr oc e s o de desar r ol l o del equi po.
El abor ar un pl an de cal i dad y pl ant ear l os obj et i vos de cal i dad.
Pr epar ar un pl an par a l as ne ce s i dade s de s opor t e necesar i as.
Pr oduci r una est r at egi a de desar r ol l o gener al .
El abor ar un pl an de desar r ol l o par a el pr oyect o en su t ot al i dad.
Hacer pl a ne s det al l ados par a cada i ngeni er o en la si gui ent e f ase.
Adapt ar los pl anes i ndi vi dual es a un pl an de equi po.
TM
PDF Editor
PARTE UNO EL PROCESO DEL SOFTWARE
Hacer un bal ance de la cant i dad de t r abaj o del e qui po par a obt e ne r un pr o-
gr a ma m ni mo e n t r mi nos gener al es.
Val orar l os riesgos del pr oyect o y as i gnar r esponsabi l i dad de r as t r eo pa r a
cada riesgo cl ave.
Es i mpor t ant e s e al ar que la act i vi dad de l a nz a mi e nt o pue de apl i car se a nt e s de c a -
da act i vi dad del ma r c o de t r abaj o del PSE, el cual s e expl i c pr r af os at r s. Est o s e
aj us t a a la nat ur al e za i t erat i va de mu c h o s pr oyect os y per mi t e que el e qui po s e a da p-
t e a l as ne c e s i da de s c a mbi a nt e s del cl i ent e y a l as l ecci ones apr e ndi das de act i vi da-
d e s pr evi as.
El PSE r e conoce que l os me j or e s e qui pos de s of t war e s on aut odi r i gi dos. Los
mi e mbr os del e qui po pl ant ean l os obj et i vos del pr oyect o, a da pt a n el pr oc e s o par a
cubri r s us neces i dades , cont r ol an el pr ogr ama y la medi ci n y el anl i si s de l as me -
di das r ecol ect adas; a de m s , t r abaj an de ma ne r a cont i nua par a mej or ar el e nf oque
del equi po r es pect o de la i ngeni er a del s of t war e.
Al igual que el PSP, el PSE e s un e nf oque r i gur oso par a la i ngeni er a del s of t wa r e
que of r ece benef i ci os di st i nt os y cuant i f i cabl es en pr oduct i vi dad y cal i dad. El equi po
debe c ompr ome t e r s e con el pr oc e s o y de be reci bi r capaci t aci n pa r a as e gur ar s e de
que el e nf oque s e apl i que de ma ne r a apr opi ada.
Los mode l os genr i cos de pr oce s o t r at ados en l as s ecci ones pr e c e de nt e s de be n
adapt ar s e par a que l os utilice un e qui po de pr oyect o de s of t war e. Para l ograrl o s e
ha n des ar r ol l ado herramientas de tecnologa del proceso de s t i nadas a ayudar a l as or -
gani zaci one s de s of t wa r e a anal i zar s us pr oc e s os act ual es, or gani zar s us t ar eas,
cont r ol ar y moni t or ear su pr ogr eso, y admi ni s t r ar su cal i dad t cni ca [NEG99].
Las he r r a mi e nt a s de t ecnol og a del pr oc e s o per mi t en q u e una or gani zaci n de
s of t wa r e const r uya un mode l o a ut oma t i z a do del ma r c o de t r abaj o c omn del pr oce -
so, de l os c onj unt os de t a r e a s y l as act i vi dades sombr i l l a expl i cadas e n la secci n
2.2. El model o, que a me n u d o s e r epr es ent a c o mo una red, e nt onc e s pue de anal i zar -
s e par a de t e r mi nar el flujo de t r abaj o t pi co y e xa mi na r l as es t r uct ur as de pr oce s o al -
t er nat i vas que podr an conduci r a la r educci n del t i e mpo o cos t o del desar r ol l o.
Una vez cr e ado un pr oc e s o acept abl e e s posi bl e ut i l i zar ot r as he r r a mi e nt a s de
t ecnol og a del pr oce s o par a l ocal i zar, moni t or e ar e i ncl uso cont r ol ar t oda s l as t a r e a s
de i ngeni er a del s of t wa r e def i ni das c o mo una par t e del mode l o del pr oces o. Cada
mi e mbr o del e qui po de s of t wa r e pue de e mpl e a r di chas he r r a mi e nt a s en la e l abor a-
ci n de una lista d e veri f i caci n de l as t a r e a s de t r abaj o que se de be n desar r ol l ar , l os
pr oduct os del t r abaj o que e s i mper at i vo pr oduci r , y l as act i vi dades par a el as e gur a-
mi e nt o de la cal i dad que de be n r eal i zar se. La her r ami ent a de t ecnol og a del pr oce-
s o t ambi n s e pue de apr ove char par a coor di nar el us o de ot r as he r r a mi e nt a s de la
i ngeni er a del s of t wa r e asi st i da por c omput a dor a que s e an apr opi adas par a una t a-
r ea de t r abaj o part i cul ar.
TM
PDF Editor
43
HERRAMIENTAS DE SOFTWARE
Herramientas de modelado del
proceso
Obj e t i vo: Si una organizacin t rabaj a en el
-ej orami ent o de un proceso de un negocio (o de un softwa-
-5). el primer objetivo es entenderlo. Las herramientas de
-xj del ado del proceso (tambin llamadas tecnologa del
z -oceso o herramientas de gestin del proceso) se utilizan
oaro representar los elementos clave de un proceso par a
- j e ste pueda entenderse con mayor claridad. Tales herra-
tambin ofrecen vnculos con descripciones del pro-
que ayudan a quienes se interesen en el proceso a
las acciones y las t areas de t rabaj o necesarias pa-
-3 desarrollado. Las herramientas de modelacin del proce-
so proporcionan vnculos con otras herramientas que
: -ecen soporte a actividades definidas del proceso.
Me c ni c a: Las herramientas de esta categor a permiten
; equipo definir los elementos de un modelo del proceso
nico (acciones, t areas, productos de trabajo), ofrecen una
gua detallada del contenido o la descripcin de cada ele-
mento del proceso, y despus gestionan el proceso mien-
tras se conduce. En algunos casos las herramientas de
tecnologa del proceso incorporan t areas de gestin del
proyecto estndar, como estimacin, itinerario, rastreo y
control.
He r r a mi e n t a s r e p r e s e n t a t i v a s : "
Igrafx Process Tools, distribuidas por Corel Corporation
(www. igrafx. com/produc s/process), es una serie de
herramientas que permiten al equi po organizar, medir
y modelar el proceso de software.
Objexis Team Portal, desarrol l ado por Objexis Corporation
(www.objexis.com), proporciona la definicin y el con-
trol completos del flujo de t rabaj o del proceso.
4*
Si el p r o c e s o e s d bi l , s i n d u d a el p r o d u c t o final s u f r i r l a s c o n s e c u e n c i a s . As i mi s -
mo , u n a c o n f i a n z a e x c e s i v a e n el p r o c e s o e s p e l i g r o s a . En u n b r e v e e n s a y o Ma r g a -
r e t Da v i s ( DAV95] c o me n t a s o b r e l a d u a l i d a d de l p r o d u c t o y el p r o c e s o :
Al r ededor de cada di ez a os , a ve c e s cada ci nco, la c omuni da d del s of t wa r e r edef i ne "el
pr obl e ma" c a mbi a ndo su e nf oque de l os as pe ct os del pr oduct o a l os a s unt os del pr oces o.
Ent once s s e ha n obt e ni do l e ngua j e s de pr ogr amaci n es t r uct ur ados (product o) s e gui dos
por m t odos de anl i si s e s t r uct ur ado (proceso) y e ncaps ul aci n de dat os (product o), as
c o mo el nf as i s act ual e n el Model o de Madur e z de Capaci dad pa r a el Desar r ol l o de Soft -
wa r e del Inst i t ut o de I ngeni er a del Sof t war e (proceso) ( segui dos por l os m t odos or i ent a-
dos a obj et os y el desar r ol l o gil de sof t war e] .
Mi ent r as la t endenci a nat ur al de un p ndul o e s l l egar al r e pos o en el p u n t o me di o en-
t r e dos ext r emos , el obj et i vo de la c omuni da d del s of t wa r e cambi a e n f or ma c ons t a nt e
por que cada vez q u e una osci l aci n t er mi na se apl i ca u n a nue va f uer za. Est as osci l aci o-
ne s s on noci vas e n s mi s ma s por que c o n f u n d e n al pr of esi onal pr ome di o del s of t wa r e con
l os c a mbi os r adi cal es e n el si gni f i cado de ha c e r el t r abaj o o dej ar que s t e s e desar r ol l e
sol o. Las os ci l aci ones t a mpoc o r esuel ven "el pr obl ema", pue s t o que es t n des t i nadas a fa-
llar mi e nt r as el pr oduct o y el pr oce s o s e a n t r at ados c o mo si f or ma r a n una di cot om a e n
l ugar de una dual i dad.
11 Las her r ami ent as menci onadas aqu represent an una muest r a de est a categora. En la mayora de
los casos los nombr es son mar cas regi st radas de sus respect i vos desarrol l adores.
TM
PDF Editor
Existen pr ecedent es en la comuni dad cientfica hacia las noci ones de dualidad, cuan-
do las cont radi cci ones en las observaci ones no se pueden explicar por compl et o con una
u otra teora compet i dora. La nat ural eza dual de la luz, la cual parece ser en forma simul-
t nea una partcula y una onda, ha sido acept ada desde la dcada de 1920, cuando Louis
de Broglie la propuso. Creo que las observaci ones posibles sobre los art efact os del soft-
ware y su desarrol l o demuest r an una dualidad f undament al ent re el product o y el proce-
so. No se puede llegar a ent ender el art efact o compl et o, su contexto, uso, significado y
valor si sl o se ve como un proceso o ni cament e como un product o. . .
Todas las actividades humanas pueden verse como un proceso, pero cada ser huma-
no tiene un sent i do de aut oval oraci n de aquel l as actividades que gener an una represen-
tacin que puede empl ear o apreci ar ms de una per sona, empl ear una y otra vez, o
aprovechar en algn ot ro contexto. Es decir, el ser humano encuent r a placer en reutilizar
sus product os y en que ot ros los reutilicen.
Por lo tanto, mi ent ras la rpida asimilacin de reutilizar met as en el desarrollo de soft-
ware aument a de maner a potencial la satisfaccin que experi ment an los profesi onal es de
su trabajo, t ambi n aument a la urgenci a de acept aci n de la dualidad del product o y el
proceso. Considerar un art efact o reutilizable como sl o un product o o slo como un pro-
ceso oscurece el cont ext o y las maner as de utilizarlo, u oscurece el hecho de que cada uso
resulta en un product o que, a su tiempo, se aprovechar como ent rada a al guna otra ac-
tividad de desarrol l o de soft ware. Poner un punt o de vista sobre el ot ro reduce en f orma
sustancial las oport uni dades de reutilizar y, por lo tanto, pierde la oport uni dad de incre-
ment ar la satisfaccin del t rabaj o.
"Si n d u d o , el s i s t e mo i deal , si s e p u d i e r a obt e ne r , ser i a un cdi go t an f l exi bl e y di mi nut o c o mo por o p r o v e e r p o r ant i -
ci pado e n c a d a si t uaci n concebi bl e una r e gl a e xa c t a . Pe r o l a vi da es d e ma s i a d o c ompl e j a p a r a o b t e n e r es t o i d e a
i ncl uso con t o d o el p o d e r h u ma n o . "
Be nj a m n Ca r d o z o
La g e n t e o b t i e n e t a nt a (o m s ) s a t i s f a c c i n del p r o c e s o c r e a t i vo q u e del p r o d u c -
t o final. Un pi nt or di s f r ut a l os t r a z o s del pi ncel t a n t o c o mo el r e s u l t a d o del c ua dr o.
Un e s cr i t or di s f r ut a la b s q u e d a d e u n a me t f o r a a p r o p i a d a t a n t o c o mo el l i br o t e r -
mi n a d o . Un pr of e s i ona l del s o f t wa r e c r e a t i vo d e b e s e nt i r t a n t a s a t i s f a c c i n del p r o -
c e s o c o mo del p r o d u c t o t e r mi n a d o .
El t r a b a j o q u e r e al i za la g e n t e d e s o f t wa r e c a mb i a r e n l os a o s q u e s i gue n. La
dua l i da d del p r o d u c t o y el p r o c e s o e s u n e l e me n t o i mp o r t a n t e p a r a ma n t e n e r a la
g e n t e c r e a t i va c o mp r o me t i d a mi e n t r a s finaliza la t r a ns i c i n d e s d e l a p r o g r a ma c i n
h a s t a la i nge ni e r a del s o f t wa r e .
2 , 9 R E S U M E N
La i nge ni e r a del s o f t wa r e e s u n a di s ci pl i na q u e i nt e gr a al p r o c e s o , l os m t o d o s y l as
h e r r a mi e n t a s p a r a el de s a r r ol l o del s o f t wa r e d e c o mp u t a d o r a . Se h a p r o p u e s t o un
gr a n n me r o d e mo d e l o s d e p r o c e s o p a r a l a i nge ni e r a del s o f t wa r e , p e r o t o d o s d e -
finen u n c o n j u n t o d e a c t i vi da de s del ma r c o de t r a ba j o, u n a c ol e c c i n d e t a r e a s c o n -
TM
PDF Editor
45
d u c i d a s p a r a r e a l i z a r c a d a act i vi dad, p r o d u c t o s d e t r a b a j o g e n e r a d o s c o mo c o n s e -
c u e n c i a d e l as t a r e a s y u n c o n j u n t o de a c t i vi da de s s ombr i l l a q u e a c o mp a a n el p r o -
c e s o e nt e r o. Los p a t r o n e s d e p r o c e s o p u e d e n a p r o v e c h a r s e p a r a de f i ni r l as c a r a c t e -
r s t i cas del mi s mo .
La i nt e gr a c i n del mo d e l o d e c a p a c i d a d de ma d u r e z (IMCM) e s u n mo d e l o t ot al
del pr oc e s o, q u e de s c r i be l a s me t a s , pr c t i c a s y c a p a c i d a d e s e s pe c f i c a s c o n q u e de -
b e c o n t a r u n p r o c e s o d e s o f t wa r e ma d u r o . El SPICE y o t r o s e s t n d a r e s d e f i n e n l os
r e qui s i t os p a r a gui a r u n a e v a l u a c i n del p r o c e s o d e s o f t wa r e , y el e s t n d a r ISO
9 0 0 1 : 2 0 0 0 e x a mi n a la ge s t i n de la cal i dad d e n t r o d e u n pr oc e s o.
Se h a n p r o p u e s t o l os mo d e l o s p e r s o n a l y e n e q u i p o pa r a el p r o c e s o d e s o f t wa r e .
Amb o s d e s t a c a n la me di c i n, la p l a n e a c i n y la a ut odi r e c c i n c o mo i ngr e di e nt e s
c l a ve p a r a u n p r o c e s o d e s o f t wa r e e xi t os o.
Los pr i nci pi os , c o n c e p t o s y m t o d o s q u e pe r mi t e n r e al i zar el p r o c e s o l l a ma d o in-
geniera del software s e r n c o n s i d e r a d o s e n el r e s t o de e s t e l i bro.
[AMB98] Ambler, S., Process Patterns: Buiiding Large-Scale Systems Using Object Technology,
Cambridge University Press/SIGS Books, 1998.
[BAE98] Baet j er, Jr., H., Software as Capital, IEEE Comput er Society Press, 1998, p. 85.
[CIA01] Ci anfrani , C. et ai, ISO 9001:2000 Explained, Ameri can Soci et y of Quality, 2001.
[CMM02] Capability, Maturity Model Integration (CMMI), Versin 1.1, Software Engineering Institute,
marzo de 2002, disponible en ht t p: / / www. sei . cmu. edu/ cmmi / .
[DAV95] Davis, M "Process and Product: Dichotomy or Duality", en Software Engineering Notes,
ACM Press, vol. 20, nm. 2, abril de 1995, pp. 17-18.
[DUN01 IDunaway, D. y S. Masters, CMM-Based Appraisalfor Intemal Process Improvement (CBAIPI
Versin 1.2 Method Description, Sof t war e Engi neeri ng institute, 2001, puede descar gar se de
ht t py/ www. sei . cmu. edu/ publ i cat i ons/ document s/ 01 . report s/ 01 tr033.html
[ELE98| El Emam, K., J. Drouin y W. Mel (eds.), SPICE: The Theory and Practice of Software
Process Improvement and Capability Determination, IEEE Comput er Society Press, 1998.
[FER97] Ferguson, P. et al., "Results of applying t he per sonal sof t war e process", en IEEE
Computer, vol. 30, nm. 5, mayo de 1997, pp. 24-31.
[HUM96] Humphrey, W., "Using a Defined and Measuf ed Personal Sof t war e Process", en IEEE
Software, vol. 13, nm. 3, mayo-j uni o de 1996, pp. 77-88.
[HUM971 Humphrey, W Introduction to the Personal Software Process, Addison-Wesley, 1997.
[HUM98] Humphrey, W., "The Three Di mensi ons of Process I mpr ovement , Part III: The Team
Process", en Crosstalk, abril de 1998. Disponible en ht t p: / / www. st sc. hi l l . af . mi l / cr osst al k/
1998/ apr/ di mensi ons. asp.
[HUM001 Humphrey, W., Introduction to the Team Software Process, Addison-Wesley, 2000.
[IEE93] 1EE Standards Collection: Software Engineering, 1EE St andar d 610. 12-1990, IEEE, 1993.
[15000] ISO 9001:2000 Document Set, Int ernat i onal Or gani zat i on for St andar ds, 2000, ht t p: / /
www. i so. ch/ i so/ en/ i so9000-14000/ iso9000/ 9000isoindex.html.
[15001] "Gui dance on t he Pr ocess Appr oach t o Quality Management Syst ems", Document
ISO/ TC 176/ SC2/ N544R, Int ernat i onal Or gani zat i on for St andar ds, mayo de 2001.
[KET01) Ketola, J. y K, Robert s, ISO 9001:2000 in a Nutshell, 2a. ed. , Pat n Press, 2001.
[MONOll Monnich, H., Jr. y H. Monnich, ISO 9001:2000 for Small-and Medium-Sized Businesses,
Ameri can Society of Quality, 2001.
[NAU69] Naur, P. y B. Randall (eds.). Software Engineering: A Report on a Conference Sponsored
by the NATO Science Cominee, NATO, 1969.
[NEG991 Negele, H., "Modeling of Int egrat ed Product Devel opment proceses", Proc. 9th Annual
Symposium ofINCOSE, Reino Unido, 1999.
TM
PDF Editor
[PAU93] Paulk, M. e al., Capabihty Maturity Model/or Software, Sof t war e Engi neeri ng Institute,
Carnegie Mellon University, Pittsburgh, PA, 1993.
[PHI02] Phillips, M "CMMI VI. 1 TUtorial", abril de 2002, di sponi bl e en ht t p: / / www. s ei . cmu.
e du/ c mmi / .
[SEI00] SCAMPl, VI.0 Standard CMMI Assessment Method for Process Improvement: Method
Description, Sof t war e Engi neeri ng Institute, Techni cal Report CMU/SEI-2000-TR-009,
di sponi bl e en ht t p/ / www. s ei . cmu. edu/ publ i cat i ons / document s / 00. r epor t s / 00t r 009. ht ml
[SPI991 "SPICE: Sof t war e Process Assessment , Part 1: Concept s and lntroduction", Versin 1.0,
ISO/IEC JTCI, 1999.
2.1. En la i nt roducci n a est e capitulo, Baetjer punt ual i za: "El pr oceso of r ece una i nt eracci n
ent r e usuari os y di seadores, ent re usuari os y her r ami ent as en evol uci n, ent r e di seador es y
her r ami ent as en evolucin [tecnologia]". Hganse ci nco pr egunt as respect o a a) lo que los di-
s eador es deben pr egunt ar a los usuari os; b) los usuar i os deben pr egunt ar a los di seador es;
c) lo que los usuar i os deben pr egunt ar se a s mi s mos sobr e el pr oduct o de s of t war e que se
const rui r; y d) lo que los di s eador es deben pr egunt ar se a s mi s mos sobr e el pr oduct o de
sof t ware que se construir y el proceso que se utilizar para hacerlo.
2. 2. En la figura 2.1 se colocan los tres est rat os de ingeniera del soft ware arriba de un estrato ti-
tulado "un enf oque en la calidad". Esto implica un programa de calidad de una organizacin am-
plia como gestin de la calidad total. Realizar una pequea investigacin y desarrollar una gua de
los principios clave de un programa de gestin de calidad total.
2 . 3 . Existe la posibilidad de que las act i vi dades genr i cas del pr oceso de ingenier a del soft -
ware no se apl i quen? Si es as, descr base.
2 . 4 . Las act i vi dades sombri l l a ocurren a lo l argo de t odo el pr oceso del sof t war e. Se apl i can
de modo uni f or me a t r avs del pr oceso o al gunas est n concent r adas en una o m s act i vi da-
des del mar co de trabajo?
2. 5. Descr base un mar co de t rabaj o del pr oceso con pal abr as propias. Cuando se dice que las
actividades del marco de t rabaj o son aplicables a t odos los proyectos, esto significa que las mis-
mas t ar eas de t r abaj o se apl i can a t odos los proyect os, sin i mport ar el t amao y compl ej i dad?
Expliqese la respuest a.
2.6. Intente est abl ecer un conj unt o de t areas par a la actividad de comunicacin.
2. 7. Investigar un poco m s acerca de la IMCM y discutir las vent aj as y desvent aj as de los mo-
del os de la IMCM cont i nuo y discreto.
2.8. Desplegar la document aci n de la IMCM del sitio de la red del SEI y sel ecci onar un rea del
proceso que no sea la planeacin del proyecto. Hacer una lista de las met as especficas (ME) y de
las prct i cas especi fi cas (PE) asoci adas que se defi nan medi ant e el rea que se haya elegido.
2. 9. Consi derar la actividad de comunicacin dent r o del mar co de t rabaj o. Desarrol l ar un pa-
trn compl et o del pr oceso (podra ser un pat r n discreto) apr ovechando los pri nci pi os descri -
tos en la seccin 2.4.
2. 10. Cul es el propsi t o de la eval uaci n del proceso? Por qu el SPICE ha sido desarrol l a-
do como un est ndar para la eval uaci n del proceso?
2.11. Investigar m s sobr e el PSP y pr epar ar una breve pr esent aci n que i ndi que los benef i -
cios cuant i t at i vos del proceso.
2.12. La utilizacin de "escritos" (un mecani smo requeri do en el PSE) no goza de gran acept a-
cin ent re la comuni dad del sof t ware. Hacer una lista de las vent aj as y desvent aj as mi ent ras se
t oman en cuent a los escritos y sugeri r al menos dos si t uaci ones en que serian tiles y ot r as dos
si t uaci ones en donde no tendr an t ant os beneficios.
TM
PDF Editor
47
El est ado actual de la ingeniera deL sof t ware y el pr oceso de sof t ware lo det ermi nan bi en
publ i caci ones mensual es como IEEE Software, Computer, y IEEE Transactions on Software Engi-
neering. Publicaciones peri di cas como Application Development Trends y Cutter IT Journal a
menudo cont i enen artculos sobre t emas de ingeniera del soft ware. La disciplina se "resume"
cada ao en la Proceeding of the International Conference on Software Engineering, pat roci nado
por el IEEE y ACM, y se discute a profundi dad en publ i caci ones como ACM Transactions on
Software Engineering and Methodology, ACM Software Engineering Notes y Annals of Software
Engineering. Miles de pgi nas de la red est n dedi cadas a la ingeniera del sof t ware y al
proceso de soft ware.
En los aos reci ent es se han publ i cado muchos libros referent es al proceso de sof t ware y a
la ingeniera del soft ware. Algunos pr esent an un panor ama del proceso en su totalidad,
mi ent ras ot ras cent ran su at enci n en unos cuant os t emas i mport ant es y excluyen otros. Entre
las propuest as ms popul ares se encuent ran:
Abran, A. y) . Moore, SWEBOK: Guide to the Software Engineering Body of Knowledge, IEEE,
2002.
Ahern, D, etal., CMMI Distilled, Addison-Wesley, 2001.
Chrisis, B. ef al., CMMI: Cuidelines for Process Integration and Product Improvement, Addison-
Wesley, 2003.
Chri st ensen, M. y R. Thayer, A Projecl Manager's Guide to Software Engineering Best Practices,
1EEE-CS Press (Wiley), 2002.
Glass, R., Fact and Fallacies of Software Engineering, Addison-Wesley, 2002.
Hunter, R. y R. Thayer (eds.), Software Process Improvement, 1EEE-CS Press (Wiley), 2001.
Persse, ) . , Implementing the Capability Maturity Model, Wiley, 2001.
Pfleeger, S Software Engineering: Theoiy and Practice, 2a. ed Prentice-Hall, 2001.
Potter, N. y M. Sakry, Making Process Improvement Work, Addison-Wesley, 2002.
Sommerville, I., Software Engineering, 6a. ed Addison-Wesley, 2000
En lo que respecta a lecturas ms ligeras, un libro de Robert Glass (Sof t ware Conftict,
Yourdon Press, 1991) present a ensayos sorprendent es y cont roversi al es sobre el sof t ware y el
proceso de ingeniera del soft ware. Yourdon (Death March Piojects, Prentice-Hall, 1997) expone
lo que sal e mal cuando fallan gr andes proyect os de sof t ware y cmo evitar esos errores.
Gar mus (Measuring the Software Process, Prentice-Hall, 1995) y Florac y Carlton (Measuring
the Software Process, Addison-Wesley, 1999) explican cmo evaluar de modo estadstico la
eficacia de cualquier pr oceso de soft ware.
Se ha publicado una gran vari edad de procedi mi ent os y est ndar es de la ingeniera del
sof t ware desde la dcada pasada. El IEEE Software Engineering Standards cont i ene muchos
est ndar es di ferent es que cubren casi cada uno de los aspect os i mport ant es de la tecnologa.
El conj unt o de document os ISO 9001:2000 proporci ona una gua a las organi zaci ones de
sof t ware que deseen mej orar sus actividades de gestin de calidad. Ot ros est ndar es de inge-
niera del sof t ware se pueden obt ener del Depar t ament o de Defensa, la FAA y ot ras agenci as
guber nament al es y no lucrativas de Est ados Unidos de America. Fairclough (Sof t ware Enginee-
ring Guides, Prentice-Hall, 1996) ofrece una referencia det al l ada de est ndar es de ingeniera del
sof t ware producida por la Agencia Espacial Europea (ESA, por sus siglas en ingls).
En Internet est disponible una gran vari edad de f uent es de i nformaci n sobre ingeniera
del sof t ware y el pr oceso de soft ware. Una lista act ual i zada de referenci as de la World wi de
Web rel evant es par a el proceso de sof t ware puede encont rarse en el sitio:
h t t p : / / www. mh h e . c o m/ p r e s s ma n .
TM
PDF Editor
C A P T U L O
3
MODELOS PRESCRIPTIVOS
DE PROCESO
C O N C E P T O S
CLAVE
construccin de
prot ot i pos . . . . .55
desarrol l o
concurrent e . . . .60
mt odos
(ori nal es .64
modelo DBC . . . .63
model o DRA . . . .53
model o DSOA . . .65
model o en
cascada .50
modelo en
espi ral .58
modelo
i ncremenl al . . . .52
model o
prescri pt i vo . . .49
pr oceso
evol ut i vo 54
proceso
unificado 67
L
os model os prescri pt i vos de pr oceso se pr opusi er on or i gi nal ment e par a or -
denar el caos del desar r ol l o de sof t war e. La historia ha i ndi cado que es t os
model os convenci onal es han t ra do consi go cierta cant i dad de est r uct ur as
tiles par a el t r abaj o en la i ngeni er a del sof t war e, y han pr opor ci onado un ca-
mi no a segui r r azonabl ement e ef ect i vo par a los equi pos de sof t war e. Sin em-
bar go, el t r abaj o de la i ngeni er a del sof t war e y el pr oduct o resul t ant e an
pe r mane ce n "al bor de del caos" [NOGOO],
En un docume nt o i nt ri gant e sobr e la ext r aa rel aci n ent r e el or den y el caos
en el mundo del sof t war e, Noguei ra y s us col egas est abl ecen:
El bor de del caos s e def i ne c o mo "un e s t a do nat ur al ent r e el or den y el caos, una
rel aci n est r echa ent r e la est r uct ur a y la sor pr esa" [KAU95J. El bor de del caos se pue de
vi sual i zar c o mo un es t ado i nest abl e, es t r uct ur ado en f or ma parci al . . . e s i nest abl e
por que e s at r a do de ma ne r a cons t ant e haci a el caos o haci a el or de n absol ut o.
Se t i ende a pe ns a r q u e el or den e s el e s t a do i deal de la nat ur al e za. Est o podr a ser
un er r or . La i nvest i gaci n. . . apoya la t eor a de que la oper aci n l ej os del equi l i bri o
ge ne r a cr eat i vi dad, pr oces os or ga ni z a dos por s mi s mo s y r et r oal i ment aci n cr e-
ci e nt e [ R0096J. El or den abs ol ut o si gni f i ca la a us e nc i a de vari abi l i dad, lo cual ser a
una vent aj a e n a mbi e nt e s i mpr edeci bl es. El c a mbi o ocur r e c ua ndo exi st e a l guna es-
t r uct ur a par a q u e pue da or gani zar s e, di cha es t r uct ur a n o de be s er t an rigida c o mo
pa r a que evi t e el cambi o. Por ot r o l ado, de ma s i a do c a os pue de i mposi bi l i t ar la coor -
di naci n y la coher enci a. La fal t a de es t r uct ur a no s i empr e si gni fi ca des or den.
Qu e s ? Los modelos prescriptivos
de proceso definen un conjunto dis-
tinto de actividades, acciones, tareas,
fundamentos y productos de trabajo
que se requieren para desarrollar
software de alta calidad. Estos modelos de pro-
ceso no son perfectos, pero proporcionan una
gua til para el t rabaj o de la ingeniera del soft-
ware.
Qui n l o ha c e ? Los ingenieros de software y
sus gerentes adaptan un modelo prescriptivo de
proceso a sus necesidades y despus lo siguen.
Adems, la gente que ha solicitado el software
tiene un papel por desempear conforme se eje-
cuta el modelo de software.
Por q u e s i mpor t ant e ? Porque proporciona
estabilidad, control y organizacin a una activi-
dad que si no se controla puede volverse cati-
ca. Algunas veces los modelos de proceso pres-
criptivo se han referido como "modelos rigurosos
de proceso", ya que a menudo incluyen las capa-
cidades sugeridas por la IMCM (captulo 2). Sin
embargo, iodos los modelos de proceso se pue-
den adapt ar para usarlos de forma efectiva y en
un proyecto de software especfico.
Cul es s on l os p a s o s ? El proceso conduce a
un equipo de software a travs de un conjunto
de actividades del marco de t rabaj o que se
organizan en un flujo de proceso, el cual puede
ser lineal, ncremental o evolutivo. La terminolo-
g a y los detalles de cada modelo de proceso
difieren, pero las actividades genricas del
marco de trabajo permanecen razonablemente
consistentes.
48
TM
PDF Editor
CAPTULO 3 MODELOS PRESCRIPTIVOS DE PROCESO
49
i Cul es el producto obteni do? Desde el
ounto de vista de un ingeniero de software, los
productos de t rabaj o son los programas, docu-
mentos y datos que se producen como conse-
cuencia de las actividades y t areas que define el
proceso.
Cmo puedo estar seguro de que l o he
he c ho c o r r e c t a me nt e ? Existe cierta canti-
dad de mecanismos par a la evaluacin del pro-
ceso de software que permite a las organizacio-
nes determinar la "madurez" de sus respectivos
procesos. Sin embargo, los mejores indicadores
de la eficacia del proceso que se utiliza son la
calidad, el tiempo de entrega y la viabilidad a
largo plazo del producto que se construye
Las i mpl i caci ones f i l osf i cas de e s t e a r gume nt o s on si gni f i cat i vas r es pect o de la
i ngeni er a del s of t war e. Si l os mode l os pr escr i pt i vos del pr oceso1 bus can est r uct ur a
y or den, st os r esul t an i napr opi ados par a un mu n d o del s of t wa r e que se bas a en el
cambi o? Ade ms , si s e r e c ha z a n l os mode l os convenci onal es del pr oce s o (y el or den
que s t os i mpl i can) y s e r e e mpl azan con al go me n o s es t r uct ur ado, se i mposi bi l i t a
al canzar la coor di naci n y la coher enci a en el t r abaj o del s of t war e ?
No exi st en r e s pue s t as fciles, pe r o exi st en opci ones di sponi bl es par a l os i ngeni e-
ros de s of t war e. En e s t e cap t ul o s e e xa mi na r el e nf oque del pr oce s o prescri pt i vo,
en el cual el or den y la consi st enci a del pr oyect o s on l os as pe ct os domi na nt e s . En el
cap t ul o 4 s e e xa mi na r el e nf oque del pr oc e s o gil e n el cual la or gani zaci n pr o-
pi a, la col abor aci n, la comuni caci n y la adapt abi l i dad domi na n la filosofa del pr o-
ceso.
3 . 1 M O D E L O S P RE S CP T P T I VOS
CLAVE
d e s c r i p t i v o
n o con
Or eos
a c t o s
fcto
Cual qui er or gani zaci n de i ngeni er a del s of t war e de be descri bi r un conj unt o ni co
de act i vi dades dent r o del ma r c o de t r abaj o (cap t ul o 2) par a el (los) pr oceso( s) de
s of t war e que adopt e. Tambi n de be l l enar cada act i vi dad del ma r c o de t r abaj o con
un c onj unt o de acci one s de i ngeni er a del s of t war e, y def i ni r cada acci n en c ua nt o
a un c onj unt o de t a r e a s q u e i dent i f i que el t r abaj o (y l os pr oduct os del t r abaj o) que
de be n compl e t ar s e par a al canzar l as me t a s de desar r ol l o. Despus, la or gani zaci n
de be adapt ar el mode l o de pr oce s o r es ul t ant e y aj us t ar l o a la nat ur al eza espec f i ca
de cada pr oyect o, a l as pe r s ona s que lo r eal i zar n, y el ambi e nt e en el que s e ej ecu-
t ar el t r abaj o. Sin i mpor t ar el mode l o del pr oce s o sel ecci onado, l os i ngeni er os de
s of t war e ha n el egi do d e ma ne r a t radi ci onal un ma r c o de t r abaj o genr i co par a el
pr oceso, el cual i ncl uye l as si gui ent es act i vi dades dent r o del mar co: comuni caci n,
pl aneaci n, model ado, const r ucci n y desarrol l o.
"Exi st en muchos f or ma s de ir bocio del ant e, per o slo una de per manecer . "
Frankl i n D. Roosewel t
1 Los modelos prescriptivos de proceso a menudo se denominan modelos "convencionales" de proceso
TM
PDF Editor
En l as s e cci one s s i gui ent es s e e xa mi na r n var i os de l os mode l os pr escr i pt i vos del
pr oce s o de s of t war e. Se l es l l ama "prescri pt i vos" por que pr escr i ben un c onj unt o de
e l e me nt os del pr oceso: act i vi dades del ma r c o de t r abaj o, acci one s de i ngeni er a del
s of t war e, t ar eas , pr oduct os del t r abaj o, a s e gur a mi e nt o de la cal i dad, y me c a ni s mos
de cont r ol del c a mbi o par a cada pr oyect o. Cada mode l o de pr oce s o pr escr i be t a m-
bi n un flujo de trabajo; e s t o es, la f or ma en la cual l os e l e me nt os del pr oc e s o s e i nt e-
r r el aci onan e nt r e s.
Todos l os mode l os de pr oce s o del s of t wa r e s e aj us t an a l as act i vi dades genr i cas
del ma r c o de t r abaj o descr i t as en el cap t ul o 2, pe r o c a da u n o apl i ca una i mpor t an-
ci a di f er ent e a e s t a s act i vi dades y def i ne un flujo de t r abaj o que i nvoca c a da act i vi -
dad del ma r c o de t r abaj o (as c o mo acci ones y t a r e a s de la i ngeni er a del sof t war e)
de una ma ne r a di f er ent e.
Existen ocas i ones en que l os requi si t os de un pr obl ema s e ent i enden de una ma ne r a
r azonabl e: cuando el t r abaj o fluye desde la comuni caci n a t r avs del despl i egue de
una ma ne r a casi lineal. Esta si t uaci n s e encuent r a a veces c ua ndo e s necesar i o hace r
adapt aci ones o mej or as bien def i ni das a un si st ema exi st ent e (por ej empl o, una adap-
t aci n a un sof t war e cont abl e debi do a l os cambi os en las r egul aci ones del gobi erno).
Est o puede ocurri r t ambi n en un nme r o l i mi t ado de pr oyect os de nue vos desarrol l os,
per o sl o cuando los r equer i mi ent os est n bien def i ni dos y son est abl es en f or ma r azo-
nabl e.
El modelo en cascada, al gunas veces l l amado el ciclo de vida clsico, sugi er e un enf o-
que si st emt i co, secuenci al 2 haci a el desar r ol l o del sof t war e, que se inicia con la es pe-
cificacin de r equer i mi ent os del cl i ent e y que cont i na con la pl aneaci n, el model ado,
la const r ucci n y el despl i egue para cul mi nar en el sopor t e del s of t war e t er mi nado.
El mode l o en c a s c a da e s el par adi gma m s ant i guo par a la i ngeni er a del s of t wa -
re. Sin e mbar go, en l as d c a da s pas adas , l as cr t i cas a est e mode l o de pr oc e s o ha n
El mo d e l o e n c a s c a d a .
^ O N S E J f l j ^
Aunque un proceso
sea prescriptivo, no se
debe asumir que ste
es esttico. Los
modelos prescriptivos
se deben adaptar o
las personas, al
problema y al
proyecto.
2 A pesar de que el model o en cascada original, que propuso Winston Royce [ROY70], prev "ciclos
de retroalimentacin", la i nmensa mayora de l as organi zaci ones que aplica est e model o de proceso
lo trata como si fuera est ri ct ament e lineal.
TM
PDF Editor
51
w q e
M i e l
oc a s i ona do que aun sus m s f er vi ent es pr act i cant es hayan cue s t i onado su ef i caci a
[HAN95], Ent re l os pr obl e mas que al gunas veces s e e nc ue nt r a n al apl i car el mode l o
en c a s c a da est n:
1. Es mu y r ar o que l os pr oyect os r eal es si gan el flujo s ecuenci al que pr opone el
model o. A pes ar de que el mode l o lineal i ncl uye i t eraci ones, lo hace de ma ne r a
i ndi rect a. Como r esul t ado, l os cambi os c onf unde n mi e nt r as el equi po de
pr oyect o act a.
2. Con f r ecuenci a e s difcil par a el cliente est abl ecer t odos los requi si t os de ma ne r a
expl cita. El mode l o en c a s c a da lo r equi er e y s e e nf r e nt a n di f i cul t ades al i n-
cor por ar la i ncer t i dumbr e nat ur al pr e s e nt e en el inicio de mu c h o s pr oyect os.
3 . El cl i ent e de be t ener paci enci a. Una ver si n que f unci one de l os pr ogr a ma s
es t ar di sponi bl e c ua ndo el pr oyect o est muy avanzado. Un er r or gr ave ser
de s as t r os o si no s e det ect a a nt e s de la revi si n del pr ogr ama.
En un anl i si s i nt er es ant e de pr oyect os r eal es, Br adac [BRA94] concl uy que la
nat ur al e za lineal del mode l o en c a s c a da c onduc e a "es t ados de bl oqueo" en l os cua-
l es al gunos mi e mbr os del equi po del pr oyect o de be n e s pe r ar a ot r os par a t er mi nar
t a r e a s dependi ent es . De hecho, el t i e mpo de e s pe r a pue de s upe r ar el que s e apl i ca
en el t r abaj o pr oduct i vo. El e s t a do de bl oqueo t i ende a s er m s c omn al pri nci pi o y
al final del pr oce s o secuenci al .
En la act ual i dad, el t r abaj o del s of t wa r e es t ace l e r ado y s uj e t o a una c a de na infi-
ni t a de c a mbi os (de car act er st i cas, f unc i one s y cont e ni do de la i nf or maci n) . Con
f r ecuenci a, el mode l o e n c a s c a da n o e s apr opi ado par a di cho t r abaj o. Sin e mba r go,
pue de servi r c o mo un mode l o de pr oc e s o til en s i t uaci ones donde l os r equer i -
mi e nt os e s t n fijos y donde el t r a ba j o s e real i za, has t a su concl usi n, de una ma n e -
ra l i neal .
msn
3 . 3 M O D E L O S DE P R OC E S O I NC R E ME NT AL E S
En mu c h a s s i t uaci ones l os r equi si t os i ni ci al es del s of t war e est n bi en def i ni dos en
f or ma r azonabl e, pe r o el e nf oque gl obal del e s f ue r z o de desar r ol l o excl uye un pr o-
ces o pur a me nt e l i neal . Adems , qui z haya una ne ce s i dad i mper i osa de pr opor ci o-
na r de ma n e r a r pi da un conj unt o l i mi t ado de f unci onal i dad par a el usuar i o y des -
pu s r ef i nar l a y expandi r l a en l as e nt r e gas pos t er i or es del s of t war e. En es t os c a s os
s e el i ge un mode l o de pr oce s o di s e ado par a pr oduci r el s of t wa r e en f or ma i ncr e-
ment al .
"Con de ma s i a da f r et uenci o, el f r obaj o en el s of t war e si gue lo pr i mer o ley del ciclismo: no importa haci a dnde vayas,
es mont a a ar r i ba y cont r a e l vi ent o. "
Anni mo
TM
PDF Editor
52
CLAVE
El model o incrementol
ent rega uno serie de
l anzami ent os,
llamados mementos,
que proporcionan en
forma progresiva ms
funcionalidad para los
di ent es a medi da que
se ent rega cada uno
de los incrementos.
( C ONS E J ^
Si el cliente demando
lo entrega en una
fecha imposible de
cumplh, sugirase
entregar uno o ms
incrementos para esa
fecho y el resto del
software lincrementos
adicionales) despus.
PASTE UNO EL PROCESO DEL SOFTWARE
3. 3. 1 E l mo d e l o i n c r e me n t a l
El modelo incremental c ombi na e l e me nt os del mode l o e n c a s c a da apl i cado en f or ma
i t erat i va. Como s e mue s t r a en la figura 3. 2, el mode l o i ncr ement al apl i ca s e cue nci as
l i neal es de ma n e r a e s c a l ona da c onf or me a v a n z a el t i e mpo en el cal endar i o. Cada
s ecuenci a lineal pr oduce "i ncr ement os " del s of t war e [MCD93]. Por ej empl o, el sof t -
wa r e pr oce s ador de t ext o, des ar r ol l ado con el par adi gma i ncr ement al e n su pr i mer
i ncr ement o, podr a r eal i zar f unci ones bs i cas de admi ni st r aci n de ar chi vos, edi ci n
y pr oducci n de document os ; en el s e gundo i ncr ement o, edi ci ones m s sofi st i cadas, y
t endr a f unci ones m s compl e j as de pr oducci n de doc ume nt os ; e n el t er cer i ncr e-
me nt o, f unci one s de cor r ecci n or t ogr f i ca y gr amat i cal ; y e n el cuar t o, c a pa c i da de s
a v a n z a d a s de conf i gur aci n de pgi na. Se de be t ener en cue nt a que el flujo del pr o-
ces o de cual qui er i nc r e me nt o pue de i ncor por ar el par adi gma de const r ucci n de
pr ot ot i pos que s e e xpone en la secci n 3. 4. 1.
A me nudo, al ut i l i zar un mode l o i ncr ement al el pr i mer i nc r e me nt o e s un produc-
to esencial. Es decir, s e i ncor por an l os r equi si t os bsi cos, pe r o mu c h a s car act er st i -
cas s upl e me nt ar i as ( al gunas conoci das , ot r as no) no se i ncor por an. El pr oduct o
esenci a] que da en ma n o s del cl i ent e (o s e s ome t e a una eval uaci n det al l ada). Como
r es ul t ado de la eval uaci n s e desar r ol l a un pl an par a el i nc r e me nt o si gui ent e. El pl an
af r ont a la modi f i caci n del pr oduct o esenci al con el fin de sat i sf acer de me j or ma n e -
ra l as ne c e s i da de s del cl i ent e y la ent r ega de car act er st i cas y f unci onal i dad adi ci o-
nal es. Est e pr oce s o s e repi t e de s pu s de la ent r ega de cada i ncr e me nt o mi e nt r as no
s e haya e l abor ado el pr oduct o compl et o.
El mode l o de pr oc e s o i ncr ement al , al igual que la const r ucci n de pr ot ot i pos y
ot r os e nf oq ue s evol ut i vos, e s i t erat i vo por nat ur al eza. Per o a di f er enci a de la c ons -
t r ucci n de pr ot ot i pos, el mode l o i ncr ement al s e e nf oc a en la e nt r e ga de un pr oduc-
t o oper aci onal con c a da i ncr ement o. Los pr i mer os i nc r e me nt os s on ver s i ones
El mo d e l o
i nc r e me nt a l .
Ti empo del cal endari o d e proyect o
TM
PDF Editor
53
"i ncompl et as" del pr oduct o final, pe r o pr opor ci onan al us uar i o la f unci onal i dad que
neces i t a y una pl at af or ma par a eval uar l o. 3
El desar r ol l o i ncr ement al e s til s obr e t odo c ua ndo el per s onal neces ar i o par a una
i mpl ement aci n compl et a no est di sponi bl e. Los pr i mer os i ncr e me nt os s e pue de n
i mpl e me nt ar con me n o s gent e. Si el pr oduct o esenci al e s bi en reci bi do s e agr ega (si
se requi ere) m s per s onal par a i mpl e me nt ar el i nc r e me nt o si gui ent e. Adems , l os
i nc r e me nt os s e pue de n pl ane ar par a mane j ar l os r i esgos t cni cos. Por ej empl o, un
s i s t ema gr a nde podr a r equer i r la di sponi bi l i dad de un ha r dwa r e nue vo que est en
desar r ol l o y cuya f echa de ent r ega e s i nci ert a. Ser a posi bl e pl anear l os pr i mer os
i ncr e me nt os de f or ma que s e evi t e el us o de est e har dwar e, lo que permi t i r a la
ent r ega de f unci onal i dad parci al a l os us uar i os finales sin r e t r as os de s or de nados .
3.3.2 El modelo DRA
El desarrollo rpido de aplicaciones (DRA) e s un mode l o de pr oce s o de s of t war e i ncr e-
me nt a l que r esal t a un ci cl o de desar r ol l o cort o. El mode l o DRA e s una adapt aci n a
"alta vel oci dad" del mode l o e n c a s c a da en el que s e l ogra el desar r ol l o r pi do
me di a nt e un e nf oque de const r ucci n ba s a do e n c ompone nt e s . Si s e e nt i e nde n bi en
l os r equi si t os y s e limita el mbi t o del proyect o, 4 el pr oc e s o DRA per mi t e que un
e qui po de desar r ol l o cr ee un "si st ema c ompl e t a me nt e f unci onal " dent r o de un per i o-
do muy cor t o (por ej empl o, de 60 a 90 das) [MARSH ].
Como ot r os mode l os de pr oceso, el e nf oque DRA cumpl e con l as act i vi dades
genr i cas del ma r c o de t r abaj o que ya se han pr e s e nt ado. La comunicacin t r abaj a
par a e nt e nde r el pr obl e ma de negoci os y l as car act er st i cas de i nf or maci n que de be
i ncl ui r el s of t war e . La planeacin e s es enci al por que var i os e qui pos de s of t wa r e t r a-
baj an e n par al el o s obr e di f er ent es f unci ones del si st ema. El modelado i ncl uye t r es
gr a nde s f a s e s mode l ado de negoci os, mode l a do de dat os y mode l a do del pr oce-
so y es t abl ece r e pr e s e nt aci one s del di s eo que si r ven c o mo ba s e par a la act i vi dad
de const r ucci n del mode l o DRA. La construccin r esal t a el e mpl e o de c o mp o n e n t e s
de s of t wa r e exi st ent e y la apl i caci n de la gener aci n aut omt i ca de cdi go. Por lti-
mo, el despliegue es t abl ece una ba s e par a l as i t er aci ones s ubs e cue nt e s , si s t a s s on
neces ar i as [KER94].
El model o de pr oceso DRA s e ilustra en la figura 3.3. Es obvi o que l as rest ri cci ones
de t i empo i mpues t as s obr e un pr oyect o DRA exi gen un "mbi t o de escal as" [KER94].
Si una apl i caci n de negoci os se puede modul ar de f or ma que cada gr an f unci n
pue da compl et ar s e en me n o s de t r es me s e s ( medi ant e la apl i caci n del e nf oque ya
3 Es importante observar que para todos los modelos de proceso giles que se tratan en el captulo 4
tambin se utiliza una filosofa incremental.
4 Estas condiciones no se pueden garantizar por ningn medio. De hecho, muchos proyectos de soft-
ware tienen los requisitos muy pobremente definidos al principio. En tales casos los enfoques de
construccin de prototipos o evolutivos (seccin 3.4) son mejores opciones de proceso. Vase
[REI951.
TM
PDF Editor
5 4 PARTE UNO EL PROCESO DEL SOFTWARE
El mo d e l o
DRA.
E q u i p o # n
Comuni c ac i n Comuni c ac i n
model ado del negocio
model ado de tos dat os
model ado del proceso
E q u i p o # 2
Mo d e l a d o
model ado del negocio
model ado de los dat os
model ado del proceso
reutilizacin de
componentes
generaci n
de cdi go
automtico
^ t u e b a s ^ ^ ^
E q u i p o # !
modelado del negocio
modelado de los datos
modelado del proceso
Construcci n
reutilizactn de
componentes
generocin do
codi go automtico
pruebas
Cons t rucci n
reutilizacin de
componentes
generaci n automtica
de cdi go
pruebas
/
6 0 - 9 0 d as
De s pl i e gue
integracin
ent rega
retroalimentocin
j l Cul es
son l as
de s ve nt aj as del
model o DRA?
descrito), sta es una candi dat a para el DRA. Cada gran funci n se puede abordar
medi ant e un equi po de DRA por separ ado, par a despus i nt egrarl as y formar un todo.
Como t odos los model os de proceso, el enf oque DRA t i ene i nconveni ent es
[BUT94]: 1) para proyect os gr andes, per o escal abl es, el DRA necesi t a sufi ci ent es
r ecur sos huma nos par a crear el nme r o correct o de equi pos DRA; 2) si los desar r o-
l l adores y cl i ent es no se compr omet en con l as act i vi dades r pi das necesar i as par a
compl et ar el si st ema en un mar co de t i empo muy breve, l os proyect os de DRA falla-
rn; 3) si un si st ema no se puede modul ar en f or ma apropi ada, la const rucci n de
l os compone nt e s necesar i os par a el DRA ser probl emt i ca; 4) si el al t o r endi mi en-
to es un aspect o i mport ant e, y se al canzar al convert i r i nt erf ases en compone nt e s
del si st ema, el enf oque DRA podr a no f unci onar; y 5) el DRA ser a i napr opi ado cuan-
do los ri esgos t cni cos son al t os (por ej empl o, cuando una apl i caci n nueva aplica
muchas nuevas t ecnol og as).
3 . 4 MO D E L O S P E P ROCE S O EVOLUTI VOS
El soft ware, como t odos l os si st emas compl ej os, evol uci ona con el t i empo [GIL88j.
Los requi si t os de l os negoci os y pr oduct os a me nudo cambi an conf or me se realiza
el desarrol l o; por lo t ant o, la rut a lineal que conduce a un pr oduct o final no ser real;
l as est ri ct as f echas t ope del mer cado imposibilitan la concl usi n de un pr oduct o
TM
PDF Editor
55
C& VE
j a m dente
m m r e necesidad
m e . aeronosepa
wmm e s detalles,
a m r m t p o s o
wmraeseun
compl et o, por lo que s e de be pr e s e nt ar una ver si n l i mi t ada par a l i berar la pr esi n
compet i t i va y de negoci os; s e t i ene cl ar o un c onj unt o de r equi si t os del pr oduct o o
s i s t ema esenci al , pe r o t odav a s e de be n def i ni r l os det al l es de l as e xt e ns i one s del
pr oduct o o s i s t emas . En s t a s y ot r as s i t uaci ones si mi l ares, l os i ngeni er os d e sof t -
wa r e neces i t an un mode l o de pr oc e s o que haya si do di s e ado de ma ne r a expl ci t a
par a incluir un pr oduct o que evol uci one con el t i empo.
Los modelos evolutivos s on iterativos; los caract eri za la f or ma en que permi t en que
l os i ngeni eros de sof t war e desarrol l en versi ones cada vez m s compl et as del sof t war e.
3.4.1 Construccin de prototipos
A me n u d o un cl i ent e def i ne un c onj unt o de obj et i vos gener al es par a el s of t war e,
pe r o no i dent i fi ca l os r equi si t os det al l ados de ent r ada, pr oce s ami e nt o o sal i da. En
ot r os cas os , el r es pons abl e del desar r ol l o del s of t wa r e es t i nsegur o de la ef i caci a de
un al gor i t mo, de la adapt abi l i dad de un si st ema oper at i vo o de la f or ma que deber a
t omar la i nt er acci n huma no- m q ui na . En s t as , y e n mu c h a s ot r as si t uaci ones, un
paradigma de construccin de prototipos pue de of r ecer el me j or enf oque.
A pes ar de que la const r ucci n de pr ot ot i pos s e pue de ut i l i zar c o mo un mode l o
de pr oce s o i ndependi ent e, s e e mpl e a m s c o m n me n t e c o mo una t cni ca suscept i -
bl e de i mpl ement ar s e de nt r o del cont ext o de cual qui er a de l os mode l os de pr oce s o
e xpue s t os en est e cap t ul o. Sin i mpor t ar la f or ma en que s t e s e apl i que, el par adi g-
ma de const r ucci n de pr ot ot i pos ayuda al i ngeni er o de s i s t e mas y al cl i ent e a e nt e n-
der de me j or ma ne r a cul ser el r esul t ado de la const r ucci n c ua ndo l os r equi si t os
e s t n sat i sf echos.
El pa r a di gma de const r ucci n de pr ot ot i pos (figura 3.4) s e inicia con la comuni -
caci n. El i ngeni er o de s of t wa r e y el cl i ent e e nc ue nt r a n y def i nen l os obj et i vos gl o-
ae prototipos.
TM
PDF Editor
bal es par a el s of t war e, i dent i f i can l os r equi si t os conoci dos y l as r e a s del e s q ue ma
e n donde e s neces ar i a m s def i ni ci n. Ent onces s e pl ant ea con r api dez una i t eraci n
de const r ucci n de pr ot ot i pos y se pr es ent a el mode l a do (en la f or ma de un di s eo
rpi do). El di s eo r pi do s e cent r a en una r epr es ent aci n de aquel l os as pe ct os del
s of t wa r e que s e r n vi si bl es par a el cl i ent e o el us uar i o final (por ej empl o, la conf i -
gur aci n de la i nt er f az con el us uar i o y el f or mat o de l os despl i egues de sal i da). El
di s eo r pi do c onduc e a la const r ucci n de un pr ot ot i po. Despus, el pr ot ot i po lo
eval a el cl i e nt e / us uar i o y con la r et r oal i ment aci n s e r ef i nan l os r equi si t os del sof t -
wa r e que s e desar r ol l ar . La i t er aci n ocur r e c ua ndo el pr ot ot i po s e aj us t a par a
sat i sf acer l as ne c e s i da de s del cl i ent e. Est o per mi t e que al mi s mo t i e mpo el de s ar r o-
l l ador ent i enda me j or lo que s e de be hacer .
De ma ne r a ideal, el pr ot ot i po deber a servi r c o mo un me c a ni s mo par a i dent i f i car
l os r equi si t os del sof t war e. Si se cons t r uye un pr ot ot i po de t r abaj o, el desar r ol l ador
i nt ent a e mpl e a r l os f r a gme nt os del pr ogr ama ya exi s t ent es o apl i ca he r r a mi e nt a s
( como ge ne r a dor e s de i nf or mes , admi ni s t r ador es de ve nt anas , et ct er a) que per mi -
t en pr oduci r pr ogr a ma s de t r abaj o con r api dez.
Pero qu de be hace r s e con el pr ot ot i po una vez cumpl i do el pr opsi t o descr i t o?
Br ooks [BR075] of r ece una r es pues t a:
En la mayor a de l os pr oyect os , el pr i mer s i s t ema cons t r ui do a p e n a s s e ut i l i za. Tal vez s e a
de ma s i a do l ent o, muy gr a nde o t or pe e n s u us o, o r e na l as t res car act er st i cas a la vez.
No exi st e ot ra opci n que c ome nz a r de nuevo, a unque s e a dol or oso, e s lo mej or , y const r ui r
una r evi si n r edi s eada e n la q u e s e r es uel van e s t os pr obl emas . . . Cuando s e apl i ca un
c onc e pt o nue vo de s i s t ema o una t ecnol og a nueva, s e t i ene que const r ui r un s i s t ema in-
servible y que s e a neces ar i o desechar , por que i ncl uso la mej or pl aneaci n n o e s omni sci ent e
c o mo par a que el s i s t ema es t per f ect o de s de la pr i me r a vez. Por l o t ant o, la pr e gunt a de
la admi ni s t r aci n n o e s si de be const r ui r se un s i s t ema pi l ot o y des echar l o. Est o t e ndr que
hace r s e . La ni ca pr e gunt a e s si se pl ane a la cons t r ucci n de un de s e chabl e o s e pr ome t e
ent r egr s el o a l os cl i ent es.
El pr ot ot i po pue de servi r c o mo "pr i mer si st ema", el que Br ooks r e comi e nda des e-
char . Per o s t a tal vez s ea una vi si n i deal i zada. Es ver dad que a l os cl i ent es y l os
des ar r ol l ador es l es gust a el pa r a di gma de const r ucci n de pr ot ot i pos. A l os us uar i os
l es gust a el si st ema real y a l os des ar r ol l ador es l es gust a const r ui r al go de i nmedi a-
t o. Sin e mbar go, la const r ucci n de pr ot ot i pos t ambi n s e t or na pr obl emt i ca por l as
si gui ent es r azones :
1. El cl i ent e ve lo que par ece una ver si n en f unc i ona mi e nt o del s of t war e, sin
s aber que el pr ot ot i po es t uni do "con chi cl e y cabl e par a embal aj e", que por
la pri sa de hacer l o f unci onar n o s e ha cons i de r ado la cal i dad del s of t wa r e
gl obal o la faci l i dad de ma nt e ni mi e nt o a l argo pl azo. Cua ndo s e i nf or ma que
el pr oduct o de be const r ui r se ot r a ve z par a ma nt e ne r los al t os ni vel es de cali-
dad, el cl i ent e no lo e nt i e nde y pi de la apl i caci n de "unos pe q ue os aj ust es"
par a que s e pueda el abor ar un pr oduct o final a part i r del prot ot i po. Es muy f re-
cuent e que la gest i n del desar r ol l o de s of t wa r e s e a muy l ent a.
^ O N S E J O ^
Resstase o la presin
por convertir un
prototipo burdo en un
producto. Como
resultado, casi
siempre lo calidad se
reduce.
TM
PDF Editor
57
2 . A me nudo, el desar r ol l ador es t abl ece c ompr omi s os de i mpl ement aci n par a
l ograr que el pr ot ot i po f unci one con r api dez. Tal vez s e utilice un s i s t ema
oper at i vo o l enguaj e de pr ogr amaci n i na de c ua do s l o por que es t di sponi bl e
y e s conoci do; s e pue de i mpl ement ar un al gor i t mo i nef i ci ent e s l o par a
mos t r ar capaci dad. De s pus de un t i empo, el desar r ol l ador qui z s e f ami -
liarice con es t as sel ecci ones y ol vi de l as r a z one s por l as que s on i napr opi adas.
La sel ecci n me n o s ideal ahor a se convi er t e en una par t e integral del si st ema.
A pes ar de que tal vez sur j an pr obl emas , la const r ucci n de pr ot ot i pos pue de s er
un par adi gma ef ect i vo par a la i ngeni er a del s of t war e. La cl ave e s def i ni r l as r egl as
del j uego de s de el pri nci pi o; e s decir, el cl i ent e y el desar r ol l ador s e de be n pone r de
a c ue r do en que el pr ot ot i po se const r uya y sirva c o mo un me c a ni s mo par a la def i ni -
ci n de requi si t os, en que s e descar t e, al me n o s en par t e, y en que de s pu s s e de s a -
rrolle el s of t wa r e real con un e nf oque haci a la cal i dad.
HOGARSEGURO
Seleccin de un modelo de proceso. Primera parte
El e s c e na r i o : Sala de reuniones
gr upo de ingenier a del soft ware en CPI
uno compa a (ficticia) que fabrica produc-
consumo par a uso domstico y comercial.
l ee Warren, gerente de ingeniera; Doug
gerente de ingeniera del software; Jamie Lazar,
del equi po de software; Vinod Raman, miembro
>= equipo de software; y Ed Robbins, miembro del equi-
de software. U,
conversaci n:
e : Entonces recapitulemos. He pas ado algn tiempo
anal i zando la lnea de productos HogarSeguro como la
nos en el momento. No hay duda, tenemos mucho tra-
bajo que hacer slo par a definir esta cosa, pero me gus-
que comenzaron a pensar acerca de cmo enfoca-
la part e del software de este proyecto.
Parece que en el pas ado hemos estado muy
aesorganizados en nuestro enfoque hacia el software.
E d: No lo s, Doug. Siempre sacamos el producto.
Doug: Es cierto, pero con muchos sacrificios, y este pro-
yecto parece mayor y ms complejo que cualquier cosa
que hayamos hecho antes.
- a mi e : No par ece ser tan duro, pero estoy de acuer do. . .
xss' ro enfoque ac hoc en los proyectos pasados no fun-
: onar aqu , en particular si tenemos un tiempo de ntre-
l e nuy restringido.
Doug ( s onr i e ndo) : Qui ero que nuestro enfoque sea
. - poco ms profesional. Asist a un curso corto la semo-
na pas ada y aprend mucho acerca de la ingeniera del
software. . . es una buena dea. Necesitamos un proceso
aqu .
J a mi e ( f r unc i e ndo e l c e o ) : Mi t rabaj o es construir
programas de computadora, no andar moviendo papeles.
Do ug : Dale una oport uni dad antes de decirme que no.
Me refiero a esto. [Doug describe el marco de t r abaj o del
proceso expuesto en el captulo 2 y los modelos prescrip-
tivos del proceso que se han present ado hasta este
punto.]
Do ug: Entonces, me parece que un modelo lineal no es
par a nosotros... supone que tenemos todos los requisitos
frente a nosotros y, conociendo este lugar, eso no es pro-
babl e.
Vi no d: S, y ese model o DRA suena muy ori ent ado a la
IT... Tal vez sea bueno par a construir un sistema de con-
trol de inventarios o al go as, pero no es correcto par a
HogarSeguro.
Do ug : Estoy de acuerdo.
E d: Ese enfoque de construccin de prototipos me pare-
ce bueno. De cualquier manera se par ece mucho a lo
que hacemos aqu .
Vi nod: se es el problema. Me preocupa que no nos
proporcione la suficiente estructura.
Do ug : No hay de qu preocuparse. Tenemos muchas
otras opciones, y quiero que seleccionen lo mejor par a el
equi po y el proyecto.
TM
PDF Editor
58
C K J E V V E
El mo d e l o e n e s pi r a l s e
p u e d e a d o p t a r y
a p l i c a r l o o t r a v s d e l
ci cl o d e vi da c o mp l e t o
d e u n o a p l i c a c i n ,
d e s d e e l d e s a r r o l l o d e l
c o n c e p t o h a s t a e l
ma n t e n i mi e n t o .
3.4.2 El modelo en espiral
El modelo en espiral, que Boehm [BOE88] pr opus o or i gi nal ment e, e s un mode l o de
pr oces o de s of t wa r e evol ut i vo que conj uga la nat ur al e za i t erat i va de la const r ucci n
de pr ot ot i pos con l os as pe ct os cont r ol ados y s i s t emt i cos del mode l o en cas cada.
Pr opor ci ona el mat er i al par a el desar r ol l o r pi do de ver s i ones i ncr ement al es del
s of t war e. Boehm [BOEOlj descr i be est e mode l o de la si gui ent e ma ne r a :
El mode l o de desar r ol l o en espi ral e s un ge ne r a dor del mode l o de pr oc e s o gui ado por el
ri esgo que s e e mpl e a par a conduci r s i s t e mas i nt ensi vos de i ngeni er a del s of t wa r e con-
cur r e nt e y con ml t i pl es usuar i os. Ti ene d o s car act er st i cas di st i nt i vas pr i nci pal es. Una de
el l as e s un e nf oq ue c clico par a el cr eci mi ent o i ncr ement al del gr ado de def i ni ci n e i m-
pl ement aci n de un s i s t ema, mi e nt r as di s mi nuye su gr ado de r i esgo. La ot r a e s un con-
j unt o de punt os de fijacin par a a s e gur a r el c ompr omi s o del us uar i o con s ol uci one s de
s i s t ema q u e s e a n fact i bl es y mu t u a me n t e sat i sf act or i as.
Cuando s e apl i ca el mode l o en espi ral , el s of t wa r e s e desar r ol l a en una seri e de
e nt r e ga s evol ut i vas. Dur ant e l as pr i me r as i t er aci ones, la ent r ega tal ve z s ea un docu-
me n t o del mode l o o un pr ot ot i po. Dur ant e l as l t i mas i t er aci ones se pr oduce n ver-
si ones cada ve z m s compl e t as del s i s t ema desar r ol l ado.
u n pr oce s o en espi ral s e di vi de e n un c onj unt o de act i vi dades del ma r c o de t ra-
baj o que def i ne el equi po de i ngeni er a del s of t war e. Para pr ops i t os i l ust rat i vos s e
apr ove chan l as act i vi dades genr i cas del ma r c o de t r abaj o e xpue s t a s p gi na s at r s. 5
Cada una de l as act i vi dades del ma r c o de t r abaj o r epr es ent a un s e gme nt o de la rut a
en espi ral que s e pr es ent a en la fi gura 3.5. Cuando c omi e nz a est e pr oce s o evol ut i vo
el equi po de s of t war e real i za act i vi dades i mpl i cadas e n un ci rcui t o al r ededor de la
Pl aneaci n
estimacin
itinerario
anlisis de riesgos
Un modelo
en espiral
t pi co.
Model ado
anlisis
diseo
prueba
5 El model o en espiral expuest o en est a seccin e s una variacin del model o que propuso Boehm. Para
ms i nformaci n sobre el model o en espiral original, vase [BOE88]. En |BOE98] se puede encon-
trar una exposicin ms reci ente del model o en espiral de Boehm.
TM
PDF Editor
59
espiral que tiene una direccin en el sentido del movimiento de las manecillas del
reloj, y que se inicia desde el centro. El riesgo (captulo 25) es un factor considerado
en cada revolucin. Los puntos de fijacin una combinacin de productos de tra-
bajo y condiciones incluidas a lo largo de la ruta de la espiral se consideran para
cada paso evolutivo.
El primer circuito alrededor de la espiral quiz genere el desarrollo de una espe-
cificacin del producto; los pasos subsecuent es alrededor de la espiral se pueden
aprovechar para desarrollar un prototipo y despus, en forma progresiva, versiones
ms elaboradas del software. Cada paso a travs de la regin de planeacin resulta
en aj ust es al plan del proyecto. Los costos y el itinerario se ajustan con base en la
retroalimentacin derivada de la relacin con el cliente despus de la entrega.
Adems, el administrador del proyecto ajusta el nmero de iteraciones planeado que
se requiere para completar el software.
A diferencia de otros model os de proceso que terminan cuando se entrega el soft-
ware, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del softwa-
re de computadora. Por lo tanto, el primer circuito alrededor de la espiral podria
representar un "proyecto de desarrollo del concepto", el cual se inicia en el centro de
la espiral y contina por mltiples iteraciones6 hasta que el desarrollo del concepto
est completo. Si el concepto se desarrollar en un producto real, el proceso conti-
na en la siguiente fase de la espiral y comienza un "proyecto de desarrollo de un
producto nuevo". El nuevo producto evolucionar a travs de un nmero de itera-
ciones alrededor de la espiral. Despus, un circuito alrededor de la espiral se podra
emplear para representar un "proyecto de mej orami ent o del producto". En esencia,
la espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el
soft ware se retira. En ocasiones el proceso est inactivo, pero siempre que se inicie
un cambio el proceso comi enza en el punt o de entrada aprobado (por ejemplo,
mej orami ent o del producto).
El modelo en espiral es un enfoque realista para el desarrollo de soft ware y de sis-
t emas a gran escala. Como el software evoluciona conforme avanza el proceso, el
desarrollador y el cliente entienden y reaccionan de mejor manera ant e los riesgos
en cada etapa evolutiva. El modelo en espiral emplea la construccin de prototipos
como un mecani smo encami nado a reducir riesgos pero, en forma ms importante,
permite al desarrollador la aplicacin del enfoque de la construccin de prototipos
en cualquier etapa evolutiva del producto. Mantiene el enfoque sistemtico de los
pasos que sugiere el ciclo de vida clsico, pero lo incorpora al marco de trabajo ite-
rativo que refleja de forma ms verdica el mundo real. El modelo en espiral exige
una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y,
si se aplica en forma apropiada, debe reducir los riesgos ant es de que se vuelvan
problemticos.
6 Las flechas que apuntan hacia dentro a lo largo del eje que separa la regin de despliegue de la de
:omunicacin indican una posibilidad de iteracin local a lo largo de la misma ruta de la espiral.
TM
PDF Editor
( c OHSEJ O^ -
A menudo, el modelo
concurrente es m s
apropiado para
proyectos de inge-
nier a de sistemas
( cap tulo 6) , donde
est n implicados dife-
rentes equipos de
ingenier a.
As como ot ros paradi gmas, el model o en espiral no es una panacea. Es difcil
convencer a los cl i ent es (en particular en si t uaci ones baj o contrato) de que el enfo-
que evolutivo es controlable, ya que se requiere una habilidad consi derabl e para
eval uar el riesgo y se confia en dicha habilidad para obt ener el xito. Si un riesgo
i mport ant e no se descubre y admi ni st ra, sin duda surgirn probl emas.
3.4.3 El modelo de desarrollo concurrente
El modelo de desarrollo concurrente, l l amado al gunas veces ingenier a concurrente, se
represent a en forma esquemt i ca como una serie de act i vi dades del mar co de t ra-
bajo, acci ones y t areas de la ingeniera del sof t war e y sus est ados asoci ados. Por
ejemplo, la actividad de modelado, definida para el model o en espiral, se lleva a cabo
al invocar las acci ones siguientes: const rucci n de prototipos o model ado y especi-
ficacin del anlisis y diseo. 7
En la figura 3.6 se proporci ona un esquema de una t area de ingeniera de soft ware
rel aci onada con la actividad de model ado para el model o de proceso concurrent e.
La actividad model ado puede est ar en al guno de los est ados8 dest acados men-
ci onados ant es en cualquier moment o dado. De forma similar, ot ras actividades o
t areas (por ej empl o, la comuni caci n y la construccin) se represent an de una mane-
ra anl oga. Todas las act i vi dades existen de forma concurrent e, per o se encuent r an
en di ferent es est ados. Por ejemplo, al principio del proyect o la actividad de comuni-
cacin (no s e muest ra en la figura) ha compl et ado su pri mera iteracin y existe en el
est ado de e n e s pe ra de cambi os. La actividad de modelado que existi en el est a-
do ni nguno mi ent ras se real i zaba la comuni caci n inicial, ahora realiza una transi-
cin al est ado e n desarrol l o. Sin embargo, si el cliente indica cambi os en los requi-
sitos, la actividad de modelado se mueve del est ado en desarrol l o al est ado de en
es pera de cambi os .
El model o de proceso concurrent e define una serie de event os que di spararn
t ransi ci ones de est ado a est ado para cada una de las actividades, acci ones o t ar eas
de la ingeniera del soft ware. Por ej empl o, durant e los pri meros est ados del di seo
(una acci n de la ingeniera del sof t war e que ocurre en el curso de la actividad de
modelacin) no se det ect a una i nconsi st enci a en el model o del anlisis. Esto gene-
ra el event o correccin del an lisis del modelo, el cual di sparar la creacin del an-
lisis desde el est ado real i zado hast a el est ado de en e s pe ra de cambi os .
El model o de proceso concur r ent e se aplica a t odos los tipos de desarrol l o de soft-
war e y proporci ona una visin exact a del est ado act ual de un proyecto. En lugar de
confi nar las actividades, acci ones y t areas de la ingeniera del sof t war e a una
secuenci a de event os, defi ne una red de actividades. Cada actividad, accin o t area
en la red existe de maner a si mul t nea con ot r as actividades, acci ones o tareas. Los
7 Se debe notar que el anlisis y el diseo son acciones complejas que requieren un debate sustan-
cial. La parte 2 de este libro considera estos tpicos en forma detallada.
8 Un estado es alguna forma de comportamiento observable desde el exterior.
TM
PDF Editor
CAPTULO 3 MODELOS PRESCRIPTiVOS DE PROCESO
61
linguno
Re p r e s e n t a el e s t a d o
d e u n a a c t i v i d a d o t o r e a d e l a
i n g e n i e r a d e s o f t wa r e
Baj o
desar r ol l o
en esper a
d e cambi os
En modi fi caci n
revisin
Act i vi dad d e mode l a do
event os gener ados en un punt o de la red del pr oceso di sparan t ransi ci ones ent re los
est ados.
3.4.4 Un comentario inal sobre los procesos evolutivos
Ya se ha det ect ado que al sof t war e de comput ador as moder no lo caracteriza el cam-
bio cont i nuo, los t i empos de ent r ega muy reducidos, y una necesi dad i nt ensa de
satisfacer al cl i ent e/ usuari o. En muchos casos, el t i empo de llegada al mer cado es
el requisito de gestin ms i mport ant e. Si se pi erde una vent ana del mercado, el
mi smo proyect o de sof t war e puede perder su significado.9
"l i ego bast o aqu , y slo el ma a na gua mi cami no. "
Da v e Ma t t h e ws Band
Los model os evol ut i vos de pr oceso se concibieron para abocar se a est os aspec-
t os y, adems, como model os de proceso de clase general . Estos model os t ambi n
t i enen debilidades, las cual es r esumen Nogueira y s us col egas [NOGOO]:
9 Sin embargo, es importante notar que llegar en primer lugar a un mercado no garantiza el xito. De
hecho, muchos productos de software muy exitosos han sido los segundos o hasta los terceros en lle-
gar al mercado (al aprender errores de los antecesores).
TM
PDF Editor
A pesar de los i ncuest i onabl es beneficios de los procesos evolutivos de soft ware, se tienen
al gunas dificultades con est e tipo de procesos. La primera dificultad es que la const ruc-
cin de prot ot i pos |y ot ros procesos evolutivos ms el aborados] implican un probl ema
para la planeacin del proyecto debido al nmero incierto de ciclos requeridos para construir
el product o. La mayora de las t cni cas de gestin y est i maci n de proyect os se basa en
confi guraci ones lineales de las actividades, por lo que st as no s e aj ust an por compl et o.
La segunda dificultad es que los procesos evolutivos de soft ware no est abl ecen la ve-
locidad mxi ma de la evolucin. Si las evol uci ones suceden demasi ado rpido, sin un pe-
riodo de relajacin, existe la cert i dumbre de que el proceso caer en el caos. Por ot ro lado,
si la velocidad es demasi ado lenta, se podr a afect ar la productividad.
Una tercera dificultad es que los procesos de soft ware se deben enfocar en la flexibili-
dad y extensibilidad en vez de en la alta calidad. Esta afi rmaci n suena at emori zant e. Sin
embargo, se debe priorizar la velocidad del desarrollo sobre los cero defectos. Si el desarrollo
se ext i ende par a al canzar una alta calidad, se producira un ret raso en la ent rega del pro-
ducto, la cual se hara cuando el ni cho de oport uni dad ya haya desapareci do. Este cambi o
de paradi gma lo i mpone la compet enci a en el borde del caos.
En efecto, un proceso de sof t war e que se enfoca en la flexibilidad y la velocidad del
desarrol l o por enci ma de la alta calidad suena at emori zant e. Aun as, est a idea la ha
propuest o cierto nmer o de r espet ados expert os en la ingeniera del sof t war e (por
ejemplo, [YOU95], [BAC97]).
El propsi t o de los model os evolutivos es desarrollar sof t war e de alta calidad10 de
una maner a iterativa o i ncrement al . Sin embargo, es posible aplicar un proceso evo-
lutivo para dest acar la flexibilidad, extensibilidad y velocidad del desarrollo. El reto
para los equi pos de sof t war e y sus dirigentes es est abl ecer un bal ance apropi ado
ent re est os parmet ros crticos del proyect o y el product o, y el product o y la satis-
faccin del cliente (el rbitro final de la calidad del soft ware).
HOGARSEGURO
proceso. Segunda parte
Ed: Ahora veo algo que me gusta. Un enfoque
incremental tiene sentido y en realidad me gusta el flujo
de ese modelo en espiral. Eso lo hace realista.
Vi nod: Estoy de acuerdo. Entregamos un incremento,
aprendemos de la retroalimentacin del cliente,
replaneamos, y despus entregamos afro incremento.
Tambin se ajusta a la naturaleza del producto. Podemos
tener algo en el mercado muy rpido y despus agregar
funcionalidad con cada versin. Es decir, con cada
incremento.
Seleccin de un modelo de
El e s c e na r i o: Sala de reuniones
para el grupo de ingeniera del software en CPI
Corporation, una compaa que fabrica productos de
consumo para uso domstico y comercial.
Los a c t or e s : Lee Warren, gerente de ingeniera; Doug
Miller, gerente de ingeniera del software; Ed y Vinod,
miembros del equipo de ingeniera del software.
La conversaci n:
(Doug descri be las opciones de procesos
evolutivos)
10 En este contexto, la calidad del software se define con mucha amplitud para abarcar no slo la sa-
tisfaccin del cliente, sino tambin una variedad de criterios tcnicos tratados en el captulo 26.
TM
PDF Editor
C A P T U L O 3 MODELOS PRESCRIPTIVOS DE PROCESO
63
1*1 ir: uto, Doug, dijeron que Ooug; lee, ese es un pensamiento de la vieja escuela,
d con con cada vuelta alrededor de la Como Jijo Ed, debemos mantenerlo realista. Digo que es
o es muy bueno, necesitamos un plan, un mejor mover el plan a medida que aprendemos ms y
efaemos apegamos a l. conforme solicitan los cambios.
f i v M o n F l O S E S P E C I A L I Z A D OS T1B P R O C E S O
Los model os especializados de proceso adoptan muchas de las caractersticas de
uno o ms de los modelos convencionales present ados en las secciones anteriores.
Sin embargo, los modelos especializados tienden a aplicarse cuando se ha elegido
un enfoque de ingeniera del software definido de una manera muy est recha. "
3.5.1 Desarrollo basado en componentes
Los nuevos component es de software comerciales (NCSC), desarrollados por vende-
dores que los ofrecen como productos, se pueden emplear cuando el soft ware est
en proceso de construccin. Estos component es proporcionan funcionalidad dirigi-
da con interfaces bien definidas que permiten que el component e se integre en el
software.
El modelo de desarrollo basado en componentes (DBC) (captulo 30) incorpora muchas
de las caractersticas del modelo en espiral. Es evolutivo por naturaleza [NIE92] y exige
un enfoque iterativo para la creacin del software. Sin embargo, el modelo configura
aplicaciones a partir de componentes de software empaquetados en forma previa.
Las actividades de model ado y construccin comienzan con la identificacin de
los component es candidatos. Estos component es se pueden disear como mdul os
de soft ware convencionales o como clases o paquet es de clases orientados a obje-
tos.12 Sin importar la tecnologa que se aplique en la creacin de los component es,
el modelo de desarrollo basado en component es incorpora los siguientes pasos
(implementados mediante un enfoque evolutivo):
Los productos basados en component es disponibles se investigan y evalan
para el dominio de aplicacin en cuestin.
Se consideran los aspect os de integracin de component es.
Se disea una arquitectura de soft ware (captulo 10) para adaptar los compo-
nentes.
11 En algunos casos estos modelos especializados de proceso se pueden describir de mejor manera
como una coleccin de tcnicas o una metodologa para alcanzar una meta especifica del desarro-
llo del software. Sin embargo, stas implican un proceso.
12 La tecnologa orientada a objetos se trata a lo largo de la parte 2 de este libro. En este contexto, una
c ase encapsu/a una sene de datos y os procedimientos que procesan dichos datos. Un paquete de cla-
ses es una coleccin de clases relacionadas que trabajan juntas para alcanzar algn resultado final.
TM
PDF Editor
Los component es (captulo 11) se integran en la arqui t ect ura.
Se realizan pr uebas det al l adas (captulo 11) para asegur ar una funcionalidad
apropi ada.
El model o de desarrol l o basado en component es conduce a la reutilizacin del
soft ware, la cual proporci ona benefi ci os a los i ngeni eros de soft ware. Con base en
est udi os de reutilizacin, QSM Associates, Inc. i nforma que el ensambl aj e de com-
ponent es conduce a una reducci n de 70 por ci ent o del ciclo de desarrollo; 84 por
ci ent o del cost o del proyect o y un ndice de productividad de 26.2, compar ado con
una nor ma de la industria de 16.9 [YOU94], A pesar de que est os resul t ados est n en
funcin de la robust ez de la biblioteca de component es, no hay duda de que el
model o de desarrol l o basado en component es proporci ona vent aj as significativas
para los i ngeni eros de soft ware.
3.5.2 El modelo de mtodos formales
El model o de mtodos formales (captulo 28) compr ende un conj unt o de act i vi dades
que conducen a la especificacin mat emt i ca del sof t war e de comput ador a. Los
mt odos formal es permi t en que un ingeniero de sof t war e especifique, desarrolle y
verifique un si st ema basado en comput ador a al aplicar una not aci n mat emt i ca
rigurosa. Algunas organi zaci ones de desarrol l o del sof t war e aplican en la act ual i dad
una variacin de est e enfoque, l l amado ingenier a del software de sala limpia [M1L87,
DYE92], Este model o se explica en el captulo 29.
"Es ms fcil escribir un progromo incorrecto que ent ender uno correcto. "
Al an Per l i s
Si los m t o-
* dos formales
pueden demost rar
la correcci n del
sof t w are, por q u
no se ut iliza en
forma ex t ensa?
Cuando se utilizan mt odos formal es durant e el desarrollo, st os proporci onan
un mecani smo para eliminar muchos de los pr obl emas difciles de superar con otros
par adi gmas de la ingeniera del soft ware. La ambi gedad, el est ado i ncompl et o y la
inconsistencia se descubr en y corrigen con mayor facilidad no medi ant e una revi-
sin ad hoc, si no a t ravs de la aplicacin de un anl i si s matemtico. Cuando los
mt odos formal es se utilizan dur ant e el di seo sirven como base para la verificacin
de pr ogr amas y, por consi gui ent e, permi t en que el ingeniero de sof t war e descubra y
corrija errores que de otra maner a podr an no haberse det ect ado.
A pesar de que an no existe un enf oque establecido, los model os de mt odos for-
mal es ofrecen la pr omesa de un sof t war e libre de defectos. Sin embargo, s e ha men-
ci onado una gran preocupaci n acerca de su aplicabilidad en su ent or no de gestin:
En la act ual i dad, el desarrol l o de model os formal es es muy caro y consume
mucho tiempo.
Se requi ere una capaci t aci n detallada, debi do a que pocos responsabl es del
desarrol l o de soft ware cuent an con los ant ecedent es necesari os para aplicar
mt odos formal es.
TM
PDF Editor
CAPITULO 3 MODELOS PEESCRIPnVCS DE PROCESO
65
CXVE
k s intereses
los cuales
n i d i a s
del
Es difcil la utilizacin de est os model os como un mecani smo de comuni -
cacin con clientes que no tienen muchos conoci mi ent os tcnicos.
No obstante, tal vez el enfoque a travs de mt odos formales haya ganado adeptos
entre los desarrolladores de software que deben construir sistemas de alta seguridad (por
ejemplo, en los campos de la aeronutica y de los dispositivos mdicos), y entre los desa-
rrolladores que padecen severas penurias econmi cas cuando aparecen errores en el
software.
3.5.3 Desarrollo del software orientado a aspectos
Sin importar el proceso de sof t war e que se elija, los const ruct ores de soft ware com-
plejo i mpl ement an de maner a invariable un conj unt o especfico de caractersticas,
funci ones y cont eni do de i nformaci n. Estas caract er st i cas especficas del soft ware
se model an como component es (por ejemplo, clases ori ent adas a objetos) y despus se
const ruyen dent ro del cont ext o de una arquitectura de si st ema. Conforme los siste-
mas basados en comput ador a se vuel ven ms el aborados (y complejos), ciertos
"intereses" propi edades requeri das par a el cliente o r eas de inters t c n i c o -
abar can toda la arquitectura. Algunos i nt ereses son propi edades de alto nivel de un
si st ema (por ej empl o, seguridad, falta de tolerancia). Otros i nt ereses afect an las f un-
ci ones (como la aplicacin de regl as de negocios), mi ent ras que ot ros son sistmi
eos (como la si ncroni zaci n de t ar eas o la gestin de memoria).
Cuando los i nt ereses se rel aci onan con mltiples funci ones, caractersticas e
i nformaci n del si st ema, con frecuenci a se denomi nan intereses generales. Los reque-
rimientos de aspectos defi nen est os i nt ereses general es que ej ercen un i mpact o a tra-
vs de la arqui t ect ura del soft ware. El desarrollo de software orientado a aspectos
(DSOA), referido con frecuenci a como programacin orientada a aspectos (POA), es
un par adi gma de la ingeniera del sof t war e rel at i vament e nuevo que proporci ona un
proceso y enfoque met odol gi co para definir, especificar, di sear y construir aspee-
tos "mecani smos m s all de subrut i nas y l egados para localizar la expresi n de
un inters general " [ELRO1 ].
Grundy [GRU02] explica con mayor profundi dad los aspect os en el cont ext o de lo
que l l l ama ingenier a de componentes orientada a aspectos [ICOA]:
La ICOA utiliza un concept o de capas hori zont al es a t ravs de component es de sof t war e
descompuest os en forma vertical, l l amados "aspectos", para caract eri zar propi edades
general es de los component es, los cual es pueden ser funci onal es y no funci onal es. Por lo
general, los aspect os si st mi cos incluyen i nt erfases con el usuario, t rabaj o en col abo-
racin, distribucin, persistencia, gest i n de la memori a, pr ocesami ent o de transiciones,
seguri dad, integridad y otros. Los component es pueden proporci onar o requerir uno o ms
"detalles de aspect o" rel aci onados con un aspect o particular, como un mecani smo de
visin, acceso ext ensi bl e y tipo de i nt erfase (aspect os de la i nt erfase con el usuario);
generaci n, t ransport aci n y recepcin de event os (aspectos de distribucin); al mace-
nami ent o/ r ecuper aci n e indizacin de dat os (aspect os de persistencia); aut ent i fi caci n,
codificacin y derechos de acceso (aspectos de seguridad); atomicidad de la t ransacci n,
TM
PDF Editor
control de concurrenci a y control del t ransport e (aspect os de transaccin), y as sucesi va-
ment e. Cada detalle de aspect o tiene una serie de propi edades en relacin con caract er s-
ticas personal es y no funci onal es del detalle.
Hasta ahor a no se ha concret ado un proceso ori ent ado a aspect os diferente. Sin
embargo, es probable que tal proceso adopt e caractersticas de los model os de pro-
ceso en espiral y concurrent e (secciones 3.4.2 y 3.4.3). La nat ural eza evolutiva del
model o en espiral es apropi ada cuando se identifican y const ruyen los aspectos. La
nat ural eza paralela del desarrol l o concurrent e es esenci al porque los aspect os se
desarrollan de maner a independiente de los component es del soft ware localizados
y, aun as, los aspect os tienen un i mpact o directo sobre est os component es. Por lo
tanto, resulta esencial i mpl ement ar una comunicacin asincrnica ent re las activi-
dades del proceso de soft ware apl i cadas al desarrollo y la construccin de aspect os
y component es.
Si se desea conocer una exposicin detallada del desarrollo del soft ware ori ent a-
do a aspectos, se recomi enda remitirse a libros dedi cados a est a materia. El lector
i nt eresado puede consultar [GRA03], [KIS02] o (ELRO1 ].
Gestin del proceso
Objet i vo: Ayudar en la definicin, ejecucin
y gestin de los modelos prescriptivos del
proceso.
Mecni ca: Las herramientas de gestin del proceso
permiten que una organizacin o equipo de software
defina un modelo completo de proceso del software
(actividades del marco de trabajo, tareas de
aseguramiento de la calidad, puntos de verificacin,
fundamentos y productos de trabajo). Adems, las
herramientas proporcionan una gua mientras los
ingenieros de software hacen el trabajo tcnico y una
plantilla para los gerentes, que deben rastrear y controlar
el proceso de software.
Herrami ent as repres ent at i vas 1 3
La GDPA , una serie de herramientas para la definicin del
proceso de investigacin, desarrollada en la
Universidad de Bremen en Alemania
(www.lnformatlk .uni-bremen.de/uniform/gdpa/
home.htm),proporciona un amplio espectro de
funciones para el modelado y la gestin del proceso.
SpeeDev, desarrollado por Spee Dev Corporation
(www.speedev.com), Incluye una serie de herramientas
para la definicin del proceso, gestin de los requisitos,
resolucin de caractersticas, planeacin del proyecto y
seguimiento del mismo.
Step Gate Process, desarrollado por Objexis
(www.objexis.com), incluye muchas herramientas que
ayudan en la automatizacin del flujo de trabajo.
En el sitio de Internet http://205. 252. 62. 38/English/
D-ProcessNotation.htm es posible encontrar una valiosa
exposicin sobre los mtodos y la notacin que se
puede usar para definir y describir un modelo completo
del proceso.
13 Las herramientas mencionadas aqu representan un muestreo de esta categora. En la mayora de
los casos los nombres son marcas registradas de sus respectivos desarrolladores..
TM
PDF Editor
En su libro fundament al sobre el proceso unificado, Ivar Jacobson, Grady Booch y
James Rumbaugh [JAC99] exponen la necesidad de un proceso de software "guiado
por los casos de uso, de arquitectura cntrica, iterativo e incremental". Estos auto-
res establecen:
En la act ual i dad la t endenci a e n el sof t war e se encami na a s i s t emas mayor es y compl e-
jos. Eso se debe en par t e al hecho de que las comput ador as se volvan m s poder osas cada
ao, lo que al ent aba que l os usuar i os esper ar an m s de ellas. Esta t endenci a t ambi n la
i mpul s el us o expandi do de Internet par a el i nt er cambi o de t odo tipo de i nformaci n.
Nuest ro apet i t o por un sof t war e cada vez m s compl ej o cr ece en la medi da en la que
apr endemos cmo puede mej or ar se un pr oduct o desde que sale uno hast a que llega el
ot ro. Necesi t amos un sof t war e que se adapt e mej or a nuest r as necesi dades, per o que, a
su vez, haga el sof t war e m s compl ej o. En r esumen, quer emos ms.
De alguna manera, el proceso unificado (PU) es un intento encami nado a reunir los
mejores rasgos y caractersticas de model os de procesos de software, pero los carac-
teriza de manera que implementa muchos de los mej ores principios del desarrollo
gil de soft ware (captulo 4). El proceso unificado reconoce la importancia de la
comunicacin con el cliente y los mt odos encami nados a describir el punt o de vista
del cliente con respecto a un sistema (por ejemplo, el caso de uso' 4). El PU enfatiza
el importante papel de la arquitectura de software, y "ayuda al arquitecto a enfocar-
se en las met as correctas, como el entendimiento, el ajuste a los cambi os futuros y
la reutilizacin" [JAC99]. Sugiere un flujo de proceso iterativo e incremental y que
proporciona el sentido evolutivo esencial en el desarrollo del soft ware moderno.
En esta seccin se presenta una visin general de los el ement os clave del proce-
so unificado. En la parte 2 de este texto se analizan los mt odos que pueblan el pro-
ceso y las tcnicas y notaciones compl ement ari as del UML,' las cuales se requieren
al aplicar el proceso unificado en el trabajo real de la ingeniera del software.
3.6.1 Una breve historia
Durante la dcada de 1980 y al principio de la dcada siguiente, los mt odos y len-
guajes de programacin orientados a objetos (OO)16 obtuvieron una amplia difusin
entre la comunidad de la ingeniera del software. Durante el mismo periodo se pro-
14 Un caso de uso (captulos 7 y 8) es un contexto narrativo o plantilla que describe una caracterstica
o funcin del sistema desde el punto de vista del usuario. El caso de uso lo escribe el usuario y sirve
como una base para la creacin de un modelo de anlisis ms completo.
15 El UML (Jnified Modeling Language) se ha convertido en la notacin ms utilizada para el modelado del
anlisis y el diseo. Representa una unin entre tres importantes notaciones orientadas a objetos.
16 Si el lector no se encuentra familiarizado con los mtodos orientados a objetos, en los captulos 8 y
9 se presenta una breve revisin general de ellos. Para una presentacin ms detallada vase
[REE02] (STIO1 ] o (FOW99].
TM
PDF Editor
puso una amplia variedad de anlisis y diseo orientados a objetos (AOO y DOO) y
se introdujo un model o de proceso orientado a objetos de propsito general (similar
a los modelos evolutivos present ados en este captulo). Al igual que la mayora de
los paradi gmas "nuevos" para la ingeniera del software, los seguidores de cada uno
de los mt odos de AOO y DOO argument aban acerca de cul de ellos era el mejor,
pero ningn mt odo o lenguaje domi n la escena de la ingeniera del software.
Al principio de la dcada de 1990, James Rumbaugh [RUM91], Grady Booch
[B0094] e Ivar Jacobson [JAC92] comenzaron a trabajar en un "mtodo unificado"
que combinara las mej ores caractersticas de cada uno de sus mt odos individuales
y adoptara caractersticas adicionales que propusieran otros expertos (por ejemplo,
[WIR90]) en el campo OO. El resultado fue el lenguaje de model ado unificado (UML,
por sus siglas en ingls) que contiene una notacin robusta para el model ado y el
desarrollo de sistemas OO. Para 1997, el UML se convirti en un estndar de la
industria para el desarrollo de soft ware orientado a objetos. Al mismo tiempo,
Rational Corporation y otras firmas desarrollaron herrami ent as aut omt i cas para
apoyar los mt odos del UML.
El UML proporciona la tecnologa necesaria para apoyar la prctica de la ingenie-
ra del soft ware orientada a objetos, pero no provee el marco de t rabaj o del proceso
que gue a los equipos en la aplicacin de la tecnologa. En los aos siguientes,
Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, un marco de traba-
jo para la ingeniera del soft ware orientada a objetos, medi ant e la utilizacin del
UML. En la actualidad, el proceso unificado y el UML se emplean de forma amplia en
proyectos OO de todos los tipos. El model o iterativo e incremental que propone el
PU puede y debe adaptarse para satisfacer necesi dades de proyecto especficas.
Como consecuencia de la aplicacin del UML se puede producir un arreglo de
productos de trabajo (por ejemplo, modelos y documentos). Sin embargo, stos los
reducen los ingenieros de software para lograr que el desarrollo sea ms gil y reac-
tivo ant e el cambio.
Re f e r e nc i a Web
En www.
rationol.com/
products/rup/
whitepapers.jsp s
pueden encont rar
document os tiles
sobre el PIJ.
3.6.2 Fases del proceso uniicado17
Se han analizado cinco actividades genricas del marco de t rabaj o y se ha explica-
do que st as se pueden aplicar para describir cualquier model o de proceso del soft-
ware. El proceso unificado no es la excepcin. En la figura 3.7 se muestran las
"fases" del proceso unificado (PU) y se relacionan con las actividades genricas que
se trataron en el captulo 2.
La fase de i n i c i o del PU abarca la comunicacin con el cliente y las actividades de
planeacin. Al colaborar con los clientes y usuarios finales se identifican los requisi-
tos de negocios para el software, se propone una arquitectura aproximada para el
17 Algunas veces el proceso unificado se llama proceso unificado racional (PUR) despus de que lo res-
paldara la Rational Corporation, un contribuyente importante en el desarrollo y refinamiento del
proceso y un constructor de ambientes completos (herramientas y tecnologa).
TM
PDF Editor
CAPITULO 3 MODELOS PRESCR1PTIVOS DE PROCESO
69
sistema, y se desarrolla un plan para la naturaleza iterativa e incremental del siste-
ma subsiguiente. Los requisitos fundament al es de negocios se describen a travs de
un conjunto preliminar de casos de uso que describen cules caractersticas y fun-
ciones son deseables para cada clase importante de usuarios. En general, un caso de
uso describe una secuencia de acciones que desarrolla un actor (por ejemplo, una
persona, una mquina, ot ro sistema) cuando ste interacta con el software. Los
casos de uso ayudan a identificar el mbito del proyecto y proporcionan una base
para la planeacin de ste.
En este punto, la arquitectura no es ms que un esquema tentativo de los subsis-
t emas ms importantes y de las funciones y caractersticas que los forman. Despus,
la arquitectura se refinar y expandir en un conj unt o de modelos que representa-
rn visiones diferentes del sistema. La planeacin identifica recursos, evala los ries-
gos importantes, define un itinerario y establece una base para las fases que se apli-
carn conforme se desarrolle el incremento del software.
La fase de elaboracin abarca la comunicacin con el cliente y las actividades de
modelado del modelo genrico del proceso (figura 3.7). La elaboracin refina y
expande los casos de uso preliminares que se desarrollaron como una parte de la
fase de inicio; adems, expande la representacin arquitectnica para incluir cinco
visiones diferentes del software: el modelo de caso de uso, el model o de anlisis, el
modelo de diseo, el model o de implementacin y el modelo de despliegue. En algu-
nos casos, la elaboracin crea una "lnea de base arquitectnica ejecutable" [ARL02]
que representa un sistema ejecutable en su "primer corte".18 La lnea de base arqui-
tectnica demuestra la viabilidad de la arquitectura, pero no proporciona t odas las
\
Produccin
18 Es importante destacar que la directriz arquitectnica no es un prototipo que se deseche (seccin
3.4.1). En lugar de ello la directriz se aprovecha durante la siguiente fase del PU.
TM
PDF Editor
caractersticas y funciones necesari as para utilizar el sistema. Adems, el plan se
revisa de manera cuidadosa al trmino de la fase de elaboracin para asegurar que
el mbito, los riesgos y los datos entregados an son razonables. Las modificacio-
nes al plan se deben hacer en este moment o.
La fase de construccin del PU es idntica a la actividad de construccin definida
para el proceso genrico del software. Si se utiliza el modelo arquitectnico como
entrada, la fase de construccin desarrolla o adquiere los component es del softwa-
re que harn que cada caso de uso sea operativo para los usuarios finales. Lograr
est o requiere que los modelos de anlisis y di seo iniciados durant e la fase de ela-
boracin se completen para reflejar la versin final del incremento del software.
Todas las caractersticas y funciones necesari as y requeridas del incremento del soft-
ware (por ejemplo, la entrega) se implementan en cdigo fuente. Conforme los com-
ponent es estn en proceso de implementacin, se disean y ejecutan pruebas de
unidad para cada uno de ellos. Adems, se realizan las actividades de integracin
(ensamblaje de component es y pruebas de integracin). Los casos de uso se utilizan
para derivar un conjunto de pruebas de aceptacin que se ejecutan ant es del inicio
de la siguiente fase del PU.
La fase de transicin del PU abarca las ltimas et apas de la actividad genrica de
construccin y la primera parte de la actividad genrica de despliegue. El soft ware
se entrega a los usuarios finales para realizar pruebas beta,19 y la retroalimentacin
del usuario reporta tanto defectos como cambios necesarios. Adems, el equipo de
software crea la informacin de soporte necesaria (por ejemplo, manual es del usua-
rio, guas de resolucin de problemas, procedimientos de instalacin) para el lanza-
miento. Al final de la fase de transicin, el incremento de soft ware se convierte en
un l anzami ent o de soft ware utilizable.
La fase de produccin del PU coincide con la actividad de despliegue del proceso
En www. genrico. Durante esta fase se monitorea el uso subsiguiente del software, se pro-
P o r c i o n a e l soporte para el ambiente operativo (infraestructura), y se reciben y eva-
lan los informes de defectos y los requerimientos de cambios.
Re f e r e nc i a Web
Es probable que mientras se realizan las fases de construccin, transicin y pro-
duccin ya se hayan iniciado los t rabaj os para el siguiente incremento del software.
Esto significa que las cinco fases del PU no suceden en una secuencia, sino en una
concurrencia por etapas.
A lo largo de las fases del PU se distribuye un flujo de t rabaj o de ingeniera del
software. En el contexto del PU, un flujo de trabajo es anlogo a un conjunto de tareas
(definido en el captulo 2). Esto es, un flujo de t rabaj o identifica las t areas necesarias
para completar una accin importante de ingeniera del soft ware y los productos de
19 En la prueba beta, una accin de prueba controlada (captulo 13), el software lo utilizan usuarios fina-
les reales, con la intencin de descubrir defectos y deficiencias. Se establece un esquema de informe
de defectos y deficiencias de manera formal, y el equipo de software evala la retroalimentacin.
TM
PDF Editor
71
trabajo que se producen como consecuencia de la realizacin exitosa de t areas. Se
debe destacar que no todas las tareas identificadas para un flujo de trabajo del PU se
realizan para cualquier proyecto de software. El equipo debe adaptar el proceso
(acciones, tareas, subt areas y productos de trabajo) para satisfacer sus necesidades.
3.6.3 Productos de trabajo del proceso unificado
En la figura 3.8 se ilustran los productos de trabajo clave que se produjeron como
consecuencia de las cuatro fases tcnicas del PU. Durante la fase de inicio, el pro-
psito es establecer una "visin" general para el proyecto, identificar un conjunto de
requisitos de negocios, formar un caso de negocios para el software y definir los ries-
gos del proyecto y del negocio que pudieran representar un obstculo para el xito.
Desde el punt o de vista del ingeniero de software, el producto de trabajo ms impor-
tante generado durante la etapa de inicio es el modelo de caso de uso: una coleccin
de casos de uso que describen la forma en que actores externos ("usuarios" huma-
nos y no humanos del software) interactan con el sistema y obtienen valor a partir
de ste. En esencia, el model o de casos de uso es una coleccin de escenarios de uso
con plantillas est andari zadas que implican caractersticas y funciones del soft ware
medi ant e la descripcin de una serie de condiciones previas, un flujo de event os o
un escenario, y un conjunto de condiciones exteriores para la interaccin represen-
tada. En un inicio, los casos de uso describen requisitos al nivel del dominio de nego-
cios (por ejemplo, el grado de abstraccin es alto). Sin embargo, el model o de casos
de uso se refina y elabora conforme cada fase del PU se ejecuta y sirve como una
entrada importante para la creacin de productos de trabajo subsecuentes. Durante
la fase de inicio slo se completa entre el 10 y 20 por ciento de los casos de uso.
Despus de la elaboracin, se ha creado entre un 80 y 90 por ciento del modelo.
La fase de elaboracin produce un conj unt o de productos de trabajo que elabora
requisitos (incluso requisitos no funcionales20), as como una descripcin arquitec-
tnica y un diseo preliminar. Cuando el ingeniero de software inicia con el anlisis
orientado a objetos, el objetivo primordial es definir un conjunto de clases de anli-
sis que describan en forma adecuada el comport ami ent o del sistema. El modelo de
an lisis del PU es un producto de trabajo que se desarrolla como consecuencia de
esta actividad. Los paquet es de clases y anlisis (colecciones de clases) definidos
como una parte del modelo de anlisis se refinan despus en un modelo de diseo,
el cual identifica clases de diseo, subsi st emas y las interfases entre los subsistemas.
Los model os de anlisis y diseo expanden y refinan una representacin evolutiva
de la arquitectura del software. Adems, en la fase de elaboracin se revisan los ries-
gos y el plan de proyecto para asegurar que cada uno de ellos conserve su validez.
La fase de construccin produce un modelo de implementacin que traduce las
clases de diseo en component es de soft ware que se construirn para ejecutar el sis-
20 Requisitos que no se pueden deducir del modelo de caso de uso.
TM
PDF Editor
72 PARTE UNO a PROCESO DEL SOFTWARE
Principales
productos de
t rabaj o
producidos
par a cada
fase del PU.
Fase de inicio
Document o d e la visin
Mode l o inicial d e c a s o
d e uso
Gl os ar i o inicial
del pr oyect o
Ca s o inicial d e negoci o
Eval uaci n inicial
del r i esgo
Plan d e pr oyect o,
f ases e i t er aci ones
Mode l o del ne goc i o
si es neces ar i o
Uno o m s prot ot i pos
Fase de el abor aci n
Model o d e cos os d e uso
Requisitos supl ement ari os,
s e incluyen los no
f unci onl es
Mode l o d e anl i si s
Descri pci n d e la
arqui t ect ura del sof t war e
Prot ot i po ar qui t ect ni co
ej ecut abl e
Mode l o d e di s eno
prel i mi nar
l i si a r evi s ada d e ri esgos
Plon d e pr oyect o que
incluye
pl an d e i t eraci n
flujos d e t r abaj o adapt ados
f undament os
pr oduct os t cni cos
del t r abaj o
Ma nua l prel i mi nar
del usuari o
Fase de const rucci n
Model o del di s eo
Component es del
sof t war e
Increment o i nt egr ado
del sof t war e
Plan y pr ocedi mi ent o
d e pr ue ba s
Ca s os d e pr ueba
Document aci n
del sopor t e
manual es del usuar i o
manual es d e i nst al aci n
descr i pci n del
i ncrement o act ual
Fose d e t r ansi ci n
Increment o d e s of t war e
i nt egr ado ;
Ret roal i ment aci n gener al
del usuari o
t ema, y un model o de despliegue convierte los component es en el ambi ent e fsico de
comput aci n. Por ltimo, un model o de prueba descri be las pr uebas empl eadas para
asegur ar que los casos de uso se reflejen de maner a apropi ada en el sof t war e que se
ha const rui do.
La fase de transicin ent rega el i ncr ement o del sof t war e y eval a los product os
de t rabaj o el aborados durant e la et apa en que los usuari os finales t rabaj an con el
soft ware. En esta et apa se produce la ret roal i ment aci n proveni ent e de las pr uebas
beta y los requeri mi ent os cualitativos de cambio.
3 . 7 RES UMEN
Los model os prescriptivos del proceso de sof t war e se han apl i cado dur ant e muchos
aos en un esf uer zo encami nado a or denar y est ruct urar el desarrol l o del soft ware.
Cada uno de est os model os convenci onal es sugiere un flujo de proceso que de algu-
na forma es diferente, per o t odos realizan el mi smo conj unt o de act i vi dades genri-
cas del mar co de t rabaj o: comuni caci n, pl aneaci n, model ado, const rucci n y des-
pliegue.
El model o en cascada sugi ere una progresin lineal de act i vi dades del mar co de
t rabaj o que a menudo resulta i nconsi st ent e con la realidad moder na en el mundo del
sof t war e (por ej empl o, con el cambi o cont i nuo, los si st emas en evolucin, las fechas
de ent rega restringidas). Sin embargo, est e model o se puede aplicar en si t uaci ones
en las cual es los requi si t os est n bien definidos y son est abl es.
TM
PDF Editor
C A P I T U L O 3 MODELOS PRESCiaPTIVOS DE PROCESO
73
Los model os incrementales del proceso de software producen soft ware como una
serie de entregas de incrementos. El modelo DRA est diseado para proyectos gran-
des que se deben entregar en marcos de tiempo muy reducidos.
Los modelos de proceso evolutivos reconocen la naturaleza evolutiva de la mayo-
ra de los proyectos de ingeniera del software y estn diseados para ajustarse al
cambio. Los model os evolutivos, como el de construccin de prototipos y el model o
en espiral, generan productos de trabajo incrementales (o versiones del software en
funcionamiento) con rapidez. Estos modelos se pueden adaptar para aplicarlos a tra-
vs de t odas las actividades de la ingeniera del software: desde el desarrollo de con-
ceptos hasta el mantenimiento del sistema a largo plazo.
El modelo basado en component es destaca la reutilizacin y ensambl adura de
componentes. Los model os de mt odos formales conducen a la utilizacin de un
enfoque basado en las mat emt i cas para el desarrollo y la verificacin del software.
El model o orientado a aspect os incluye los intereses generales que cubren la arqui-
tectura total del sistema.
El proceso unificado es un proceso de soft ware "guiado por los casos de uso, de
arquitectura cntrica, iterativo e incremental" diseado como un marco para los
mt odos y herrami ent as del UML. El proceso unificado es un model o incremental en
el que se definen cinco fases: 1) una fase de inicio que abarca la comunicacin con el
cliente y las actividades de planeacin, y destaca el desarrollo y el refinamiento de
casos de uso como un modelo primario; 2) una fase de elaboracin que abarca la
comunicacin con el cliente y las actividades de modelado con un enfoque en la crea-
cin de modelos de anlisis y diseo, con nfasis en las definiciones de clase y repre-
sentaciones arquitectnicas; 3) una fase de construccin que refina y despus traduce
el model o de diseo en component es de soft ware implementados; 4) una fase de
transicin que transfiere el software del desarrollador al usuario final para realizar
las pruebas beta y obtener la aceptacin; y 5) una fase de produccin en la cual se
realiza el moni t oreo continuo y el soporte.
[AMB02] Ambler, S. y L. Const ant i ne, The Unified Process Inception Phase, CMP Book s, 2002.
[ARL02] Arlow, J. e I. Neust andt , UML and the Unified Process, Addison-Wesley, 2002.
[BAC97] Bach, )., "Good Enough Quality: Beyond t he Buzzword", en IEEE Computer, vol.30,
nm. 8, agost o de 1997, pp. 96-98.
[BOE88] Boehm, B., "A Spiral Model for Sof t war e Devel opment Enhancement ", en Computer,
vol. 21, nm. 5, mayo de 1988, pp. 61-72.
[BOE98] Boehm, B., "Using t he WINWIN Spiral Model: A Case Study", en Computer, vol.3,
nm. 7, julio de 1998, pp. 33-34.
[BOEOl] Bohem, B., "The Spiral Model as a Tool for Evolutionary Sof t war e Acquisition", en
CrossTalk, mayo de 2001, di sponi bl e en ht t p: / / www. st sc. hi l l . af . mi l / cr osst al k / 2001/ 05/
boehm. ht ml .
( B0094) Booch, G., Object- Oriented A nalysis and Design, 2a. ed., Benj ami n Cummi ngs, 1994.
[BRA94] Bradac, M., D. Peny y L. Votta, "Prototyping a Process Monitoring Experiment", en IEEE TTans
Software Engineering, vol. 20, nm. 10, octubre de 1994, pp. 774-784.
[BR075J Brook s, F., The Mythical Mar- Month, Addison-Wesley, 1975.
TM
PDF Editor
IBUT941 Butler,)., "Rapid Application Devel opment in Action", en Managing System Development,
Applied Comput er Research, vol. 14, nm. 5, mayo de 1994, pp. 6-8.
[DYE 92] Dyer, M., The Cleanroom A pproach to Quality Software Development, Wiley, 1992.
[ELR01] Elrad, T., R. Fi l man y A. Bader (eds.), "Aspect - Ori ent ed Pr ogr ammi ng", en Comm. A CM,
vol. 44, nm. 10, oct ubr e de 2001, edi ci n especi al .
[FOW99] Fowler, M. y K. Scott, UML Distilled, 2a. ed. , Addi son-Wesl ey, 1999.
[GIL88] Gilb, T Principies of Software Engineering Management, Addi son- Wesl ey, 1998.
[GRA03] Gr adeck i , J. y N. Lesi eck i , Mastering A spectJ: A spect- Oriented Programming in Java,
Wiley, 2003.
[GRU02J Grundy, J., "Aspect -Ori ent ed Component Engi neeri ng", 2002, ht t p: / / www. es . auck l and.
ac. nz/ - j ohn- g/ as pect s . ht ml .
[HAN95] Hanna, M., "Farewel l t o Wat erfal l s", en Software Magazine, ma y o de 1995, pp. 38- 46.
[HES96] Hesse, W., "Theor y and Pr act i ce of t he Sof t war e ProcessA Field St udy a nd its
Impl i cat i ons for Project Management ", Software Process Technology, 5th European Workshop,
EWSPT 96, Spri nger LNCS 1149, 1996, pp. 241 -256.
[HESOI] Hesse, w. , "Di nosaur Meet s Ar chaeopt er yx? Seven The s e s on Rat i onal ' s Uni fi ed
Pr ocess (RUP)", en Proc. 8th Intl. Workshop on Evaluation of Modeling Methods in System
A nalysis and Design, Ch. Vil Int erl ak en, 2001.
[JAC92] Jacobson, 1., Object- Oriented Software Engineering, Addi son-Wesl ey, 1992.
[)AC991 J acobs on, i Booch, G. y J. Rumbaugh, The Unified Software Development Process,
Addi son-Wesl ey, 1999.
[KAU95] Kauf f man, S., A l Home in the Universe, Oxford, 1995.
[KER94J Ke r r J . y R. Hunt er, Inside RA D, McGraw-Hill, 1991.
[MAR911 Ma r t i n , R a p i d A pplication Development, Prentice-Hall, 1991.
[McDE93] McDer mi d J. y P. Rook , "Sof t war e De ve l opme nt Pr oces s Model s", en Software
Engineer's Reference Book, CRC Press, 1993, pp. 15/ 26- 15/ 28.
|M1L87] Mills, H.D., M. Dyer y R. Linger, "Cl eanr oom Sof t war e Engi neer i ng", en IEEE Software,
sept i embr e de 1987, pp. 19-25.
[NIE92] Ni erst rasz, O., S. Gi bbs y D. Tsi chri t zi s, "Component - Or i ent ed Sof t war e Devel opment ",
en CA CM, vol. 35, nm. 9, sept i embr e de 1992, pp. 160-165.
[NOGOO] Noguei ra, J., C. J ones y Luqi, "Surfi ng t he Edge of Chaos: Appl i cat i ons t o Sof t war e
Engi neeri ng", Comma nd and Cont rol Research Technol ogy Symposi um, Naval Post Gr adat e
School, Mont erey CA, j uni o de 2000, disponible en
ht t p/ / www. dodccr p. or g/ 2000CCRTS/ cd/ ht ml / pdf _paper s/ Tr ack _4/ 075. pdf .
IREE02] Reed, P., Developing A pplications with java and UML, Addi son- Wesl ey, 2002.
[REI95] Reilly, J. P, "Does RAD Uve Up th t he Hype", en IEEE Software, s ept i embr e de 1995, pp.
24-26.
[ R0096] Roos, l ' The Poised Or gani zat i on: Navigating Effectively on Knowl edge Landscapes",
1996, di sponi bl e en ht t p: / / www. i md. ch/ f ac/ r oos / paper _po. ht ml .
[ROY70] Royce, W.W., "Managi ng t he Devel opment of Large Sof t war e Syst ems: Concept s and
Techni ques" en, Proc. WESCON, agos t o de 1970.
[RUM91] Rumbaugh, J. et al., Object- Oriented Modeling and Design, Prent i ce- Hal l , 1991.
[STI01] Stiller, E. y C. LeBlanc, Project- Based Software Engineering: A n Object- Oriented A pproach,
Addi son-Wesl ey, 2001.
[WIR90] Wirfs-Brock , R B. Wi l k erson y L. Wei ner, Designing Object- Oriented Software, Pr ent i ce-
Hall, 1990.
[YOU94J Yourdon, E "Sof t war e Reuse", en A pplication Development Strategies, vol. 6, nm. 12,
di ci embre de 1994, pp. 1-16.
[YOU95] Yourdon, E., "When Goood Enough Is Best ", en IEEE Software, vol. 12, nm. 3, ma y o
de 1995, pp. 79-81.
3 . 1 . Leer [NOGOO] y escr i bi r un d o c u me n t o de dos o t r es p gi na s que t r at e s obr e el i mpact o
del "caos" en la i ngeni er a del sof t war e.
TM
PDF Editor
CAPTULO 3 MODELOS PRESCRIFITVOS DE PROCESO
75
3- 2. Dar tres ej empl os de proyect os de sof t war e que pudi eran adapt arse al model o en cascada.
Ser especfico.
3- 3. Proporci onar t res ej empl os de proyect os de sof t war e que pudi er an adapt ar s e al model o
de const rucci n de prototipos. Ser especfico.
3. 4. Cul es adapt aci ones se r equi er en en el pr oceso si el pr ot ot i po evol uci onar haci a un
si st ema o product o que puede ent regarse?
3. 5. Para lograr un desarrol l o rpido el model o DRA as ume la existencia de una cosa. Cul es
y por qu dicha suposi ci n no si empre es verdadera?
3. 6. Proporci onar t res ej empl os de pr oyect os de s of t war e que pudi er an adapt ar s e al model o
Incremental. Ser especfico.
3. 7. Qu se puede deci r acer ca del sof t war e que est en desarrol l o o en mant eni mi ent o
mi ent ras se avanza hacia fuera del flujo de proceso en espiral?
3. 8. Es posi bl e combi nar model os de pr oceso? Si la r espuest a es afi rmat i va, menci nes e un
ejemplo.
3. 9. El model o concur r ent e del pr oceso defi ne un conj unt o de "est ados". Describir con
pal abr as pr opi as l o que r epr esent an es t os est ados, y des pus i ndi car c mo ent r an en j uego
dent ro del model o concurrent e del proceso.
3 . 1 0 . Cules son las vent aj as y desvent aj as de desarrol l ar sof t war e para el cual la calidad es
"lo suf i ci ent ement e buena"? Esto es, qu pas a cuando se resal t a la vel oci dad del desarrol l o
sobre la calidad del proyect o?
3 . 1 1 . Proporci onar t res ej empl os de proyect os de sof t war e que pudi eran adapt ar se al model o
basado en component es. Ser especifico.
3 . 1 2 . Es posible probar que un component e de sof t war e o incluso un pr ogr ama compl et o est
correcto. Entonces, por qu no t odos lo hacen?
3 . 1 3 . Exponer con ar gument os pr opi os el si gni fi cado de "i nt ereses general es". I-a i t erat i va
sobr e el ADP se expande con rapi dez. Invest i gar y escribir un document o breve sobr e la
situacin actual.
3. 14. El proceso unificado y el UML son la mi sma cosa? Explicar la respuest a.
3. 15. Cul es la diferencia ent re una fase del PU y un flujo de t rabaj o del PU?
Q T R A S LECTVRAS Y F UENTES DE I N F O R MA C I N
La mayor part e de los textos sobre ingeniera del soft ware consi deran los model os prescrip-
tivos de proceso con algn detalle. Los libros de Sommerville (Sof t ware Engineering, sext a
edicin, Addison-Wesley, 2000), Pfleeger (Sof t ware Engineering: Theoiy and Practice, Prentice-
Hall, 2001), y Schach (Object- Oriented and Classical Software Engineering, McGraw-Hill, 2001)
consi deran los paradi gmas convenci onal es y anal i zan sus fort al ezas y debilidades. A pesar de
que no se dedi ca en forma especfica al proceso, Brook s (The Mythicai Man- Month, segunda
edicin, Addison-Wesley, 1995) present a la experiencia ganada en proyect os ant i guos que
tienen una gran relacin con el proceso. Firesmith y Henderson-Sel l ers (The OPEN Piocess
Framework: A n Introduction, Addison-Wesley, 2001), present a una plantilla general para crear
"procesos de soft ware flexible, pero, an as, indisciplinados" y anal i za los at ri but os y objetivos
del proceso.
Sharpe y McDermott ( Workjlow Modeiing: Too/s for Process Iniprovement and A pplication
Development, A rtech House, 2001) presentan herramientas para el modelado de procesos de
soft ware y negocios. Jacobson Criss y onsson ( Software Reuse, Addison-Wesley, 1997) y
McCIure ( Software Reuse Techniques, Prentice-Hall, 1997) pr esent an mucha i nformaci n til
TM
PDF Editor
sobr e el desarrol l o basado en component es. Hei neman y Council (Component- Based Software
Engineering, Addison-Wesley, 2001) describen el pr oceso requeri do par a i mpl ement ar si st emas
basados en component es. Kenett y Bak er (Sof t ware Process Quality: Management and Control,
Marcel Dek k er, 1999) consi deran la forma en que la gestin de calidad y el di seo de proceso
est n conect ados en forma ntima ent re si.
Ambriola ( Software Process Technology, Springer-Verlag, 2001), Derni ame y sus col egas
( Software Process: Principies, Methodology, and Technology, Springer-Verlag, 1999) present an
conferenci as edi t adas que incluyen muchos aspect os t eri cos y de investigacin y que son
rel evant es para el pr oceso de soft ware.
Jacobson, Booch y Rumbaugh han escrito el libro f undament al sobre el proceso uni fi cado
[)AC99]. Sin embargo, los libros de Arlow y Neustadt [ARL02] y una serie de t res vol menes de
Ambler y Const ant i ne [AMB02] ofrecen una excel ent e i nformaci n compl ement ari a. Krutchen
( The Rational Unified Process, segunda edicin, Addison-Wesley, 2000) ha escrito una valiosa
introduccin al PU. La gestin de un proyect o dent ro del cont ext o del PU est escrita en detalle
por Royce ( Software Project Management: A Unified Framework, Addison-Wesley, 1998). La
descripcin definitiva del PU la ha desarrol l ado la Rational Corporation y est disponible en
lnea en www. rat i onal . com.
En Internet existe una ampl i a vari edad de f uent es de i nformaci n sobre la ingeniera y el
proceso del soft ware. En el sitio web de SEPA se puede encont rar una lista act ual i zada de refe-
renci as en la red mundi al que son rel evant es par a el proceso de soft ware:
ht t p: / / www. mhhe . c om/ pr e s s ma n.
TM
PDF Editor
C A P I T U L O
DESARROLLO
GIL
j
B
J
*5
. J7
..91
..n
..17
.M
41
J7
.84
XI
E
n 2001, Kent Beck y ot ros 16 not abl es desarrol l adores, escri t ores y consul-
t ores [BEC01] (conocidos como la "Alianza gil") firmaron el "Manifiesto
para el desarrol l o gil de software", el cual estableca:
Hemos descubi er t o mej or es f or mas de desarrol l ar sof t war e al const rui rl o por nuest ra
cuent a y ayudar a ot r os a hacerl o, Por medi o de est e t r abaj o he mos l l egado a val orar:
A l os individuos y sus interacciones sobr e l os pr ocesos y l as her r ami ent as.
Al software en funcionamiento sobr e la document aci n ext ensa.
A la colaboracin del cliente sobr e la negoci aci n del cont rat o.
A ia respuesta al cambio sobr e el segui mi ent o de un pl an.
Esto es, aunque l os t r mi nos a la der echa t i enen valor, nosot r os val or amos m s
l os aspect os de la i zqui erda.
Un mani fi est o se asoci a por lo general con un movi mi ent o poltico emer gen-
te.- aquel que at aca a la vieja vanguardi a y sugi ere un cambi o revolucionario (en
el mej or de los casos para mejorar). De al guna forma, est o es con exactitud de
lo que se trata el desarrol l o gil.
A pesar de que las ideas subyacent es que conducen al desarrol l o gil han es-
t ado pr esent es por muchos aos, no ha si do si no hast a la dcada pasada que es-
t as ideas han cristalizado en un "movimiento". En esenci a, los mt odos giles1
se desarrol l aron en un i nt ent o por superar las debilidades advert i das y real es en
la ingeniera del sof t war e convenci onal . El desarrol l o gil proporci ona benefi ci os
i mport ant es, per o es imposible aplicarlo en t odos los proyectos, product os, per-
sonas y si t uaci ones.
Qu e s ? La ingeniera de softwa-
re gil combina una filosofa y un
conjunto de directrices de desarrollo.
La filosofa busca la satisfaccin del
cliente y la entrega temprana de soft-
a-e ncremental; equipos de proyecto peque-
mos y con alta motivacin; mtodos informales;
. - mnimo de productos de trabajo de la inge-
niera del software; y una simplicidad general
del desarrollo. Las directrices de desarrollo resal-
an la entrega sobre el anlisis y el diseo (aun-
que estas actividades no se descartan), y la
comunicacin activa y continua entre los desa-
rrolladores y ios clientes.
Qui n l o hace ? Los ingenieros de software y
otros participantes del proyecto {gerentes, clien-
tes y usuarios finales) trabajan juntos en un equi-
po gil: un equipo con organizacin propia y
que controla su propio destino. Un equipo gil
fomenta la comunicacin y la colaboracin entre
todos los que trabajan en l.
Por q u e s i mport ant e? El ambiente moder-
no de los negocios ocasiona que los sistemas
basados en computadoras y los productos de
1 A los mtodos giles algunas veces se les llama mt odos ligeros o livianos
77
TM
PDF Editor
78 PARTE UNO a PROCESO Da SOFTWARE
software estn acelerados y en cambio continuo.
La ingeniera del software gil representa una
opcin razonable a la ingeniera convencional
para ciertas clases de software y ciertos tipos de
proyectos de software. Ha demostrado su ufili-
dad al entregar sistemas exitosos con rapidez.
Cul es s on l os pa s o s ? El desarrollo gil
podra llamarse con mayor precisin "ingeniera
del software ligera". Las actividades bsicas del
'*f- marco de trabajo -comunicacin con el cliente,
planeacin, modelado, construccin, entrega y
; evolucin - se conservan, pero stas se canfor -
;\ man como un conjunto mnimo de tareas que
empuja al equipo de proyecto hacia la construc-
cin y la entrega (habr quienes argumenten
que esto se hace a costa del anlisis del proble-
ma y del diseo de la solucin).
Cul e s el product o obt eni do? Los clientes e
ingenieros de software que han adoptado la filo-
sofa gil tienen la misma visin: el nico pro-
ducto de trabajo realmente importante es un
"incremento de software" en funcionamiento, el
cual se entrega al cliente en una fecha prometi-
da.
C mo pue do es t ar s e guro d e q ue l o he
hecho correct ament e? Si el equipo de soft-
ware est de acuerdo en que el proceso funcio-
na y dicho equipo produce incrementos de soft-
ware entregables que satisfacen al cliente,
entonces el trabajo est bien hecho.
No es la anttesis de la prctica slida de la ingeniera del sof t war e y es posible
aplicarla como una filosofa pr edomi nant e para cualquier t rabaj o de soft ware.
En la econom a moder na, a menudo resulta difcil o imposible predecir cmo evo-
lucionarn con el t i empo los si st emas basados en comput ador as (por ejemplo, las
apl i caci ones Web). Las condi ci ones del mer cado cambi an con rapi dez, las necesi da-
des de los usuari os finales evol uci onan, y las nuevas amenazas competitivas emer-
gen sin previo aviso. En muchas si t uaci ones ya es imposible definir por compl et o los
requisitos ant es de que comi ence el proyecto. Los i ngeni eros de sof t war e deben ser
t an giles como para responder a un ambi ent e de negoci os fluido.
Lo ant eri or significa que el reconoci mi ent o de est as real i dades moder nas ocasio-
na que se descart en los valiosos principios, concept os, mt odos y her r ami ent as de
la ingeniera del soft ware? No, en lo absol ut o; Como t odas las disciplinas de inge-
niera, la ingeniera del sof t war e cont i na en evolucin. Se puede adapt ar con faci-
lidad para enfrent ar los ret os que implica una exigencia de agilidad.
"Agilidad: 1 , todo lo dems: 0. "
Tom DeMarco
En un libro que invita a la reflexin y trata sobre el desarrol l o gil de soft ware,
Alistair Cock burn [COC02a] ar gument a que los model os prescriptivos de proceso
pr esent ados en el captulo 3 tienen una falla i mport ant e: olvidan las fragilidades de las
personas que construyen el software de computadora. Los i ngeni eros de sof t war e no
son robots. Ellos muest r an una gran vari edad en los estilos de t rabaj o y diferencias
significativas en su grado de habilidad, creatividad, orden, consi st enci a y espont a-
neidad. Algunos se comuni can muy bien en forma escrita, ot ros no. Cock burn argu-
ment a que los model os de pr oceso pueden "enfrent ar las debilidades comunes de la
gent e con disciplina o tolerancia [alguna de las dos]" [CQC02a], y que los model os
TM
PDF Editor
de proceso m s prescriptivos eligen la disciplina. l establece: "Como la consi st en-
cia en la accin es una debilidad humana, las met odol og as que exigen un alto gra-
do de disciplina son frgiles" [CC)C02a].
Los model os de pr oceso funci onarn si proporci onan un mecani s mo realista que
f oment e la disciplina necesari a, o deben est ar caract eri zados de maner a que mues-
tren "tolerancia" por la gent e que realiza el t rabaj o de la ingeniera del soft ware. De
maner a invariable, la gent e de soft ware adopt a y sost i ene m s fci l ment e las prc-
ticas t ol erant es, per o (como Cock burn lo admite) tal vez sea menos productiva. Co-
mo la mayora de las cosas en la vida, se deben consi derar los intercambios.
AA.
Qu es la agilidad en el cont ext o del t rabaj o de la ingeniera del soft ware? Ivar Ja-
cobson [JAC02] proporci ona una definicin til:
A gilidad se ha convert i do act ual ment e en la pal abra de moda en cuant o se describe un
moder no proceso de soft ware. Cualquiera es gil. Un equi po gil es un equipo rpi do
que responde de maner a apropi ada a los cambios. st os son, en gran parte, la mat eri a
del desarrol l o de soft ware. Cambi os en el soft ware que se va a construir, cambi os en-
tre los mi embr os del equipo, cambi os debi dos a las nuevas tecnologas, cambi os de to-
do tipo que pueden incidir en el product o que se const ruye o en el proyect o que crea el
product o. En cualquier actividad de soft ware se debe incluir un soport e para los cam-
bios, est o es algo que adopt amos por que es el al ma y el corazn del soft ware. Un equi -
po gil reconoce que el sof t war e lo desarrol l an individuos que t rabaj an en equi po y que
las apt i t udes de est a gente, y su capaci dad par a colaborar, son esenci al es par a el xi-
to del proyecto.
De acuer do con la visin de Jacobson, la insistencia en el cambi o es el conduct or
primordial hacia la agilidad. Los i ngeni eros de sof t war e deben t ener pies veloces si
quieren aj ust arse a los cambi os rpidos que describe Jacobson.
[CONSUO.
*
"Ln agilidad es dinmica, t on contenido especfico, ajustable al cambio de maner a dinmico y ori ent ada ol
crecimiento."
St even G oldman el al.
e cometer el
supone/ que
proporciona
para
soluciones.
un
y lo disciplina
Pero la agilidad es ms que una respuest a efectiva al cambio. Tambin incluye la
filosofa del mani fi est o enunci ado al principio de est e captulo. Estimula las est ruc-
t uras y act i t udes de los equi pos para que la comuni caci n (entre los mi embr os del
equipo, ent re los t cni cos y la gent e de negoci os, ent re los i ngeni eros de sof t war e y
sus gerentes) sea m s fcil. Resalta la ent rega rpida del sof t war e operat i vo y le res-
ta importancia a los product os de t rabaj o i nt ermedi o (lo cual no si empre es bueno);
adopt a al cliente como una part e del equi po de desarrol l o y t rabaj a para eliminar la
actitud del tipo "nosot ros y ust edes" que an perj udi ca a muchos proyect os de soft-
ware; r econoce que la pl aneaci n tiene sus lmites en un mundo incierto y que el
plan de proyect o debe ser flexible.
TM
PDF Editor
La Alianza gil [AGI03J define 12 principios para quienes quieren alcanzar la agi-
lidad:
1. Nuestra mayor prioridad es satisfacer al cliente medi ant e la entrega temprana
y continua de soft ware valioso.
2. Bienvenidos los requisitos cambiantes, incluso en fases tardas del desarrollo.
La estructura de los procesos giles cambia para la ventaja competitiva del
cliente.
3. Entregar con frecuencia software en funcionamiento, desde un par de sema-
nas hasta un par de meses, con una preferencia por la escala de tiempo ms
corta.
4. La gente de negocios y los desarrolladores deben trabajar juntos a diario a lo
largo del proyecto.
5. Construir proyectos alrededor de individuos motivados. Darles el ambi ent e y
el soporte que necesitan, y confiar en ellos para obtener el t rabaj o realizado.
6. El mt odo ms eficiente y efectivo de transmitir informacin hacia y dentro de
un equipo de desarrollo es la conversacin cara a cara.
7. El soft ware en funci onami ent o es la medida primaria de progreso.
8. Los procesos giles promueven el desarrollo sustentable. Los patrocinadores,
desarrolladores y usuarios deben ser capaces de mant ener un paso const ant e
de manera indefinida.
9. La atencin continua a la excelencia tcnica y al buen diseo mejora la agili-
dad.
10. La simplicidad el arte de maximizar la cantidad de t rabaj o no realizado es
esencial.
11. Las mejores arquitecturas, los mejores requisitos y los mej ores diseos emer-
gen de equipos autoorganizados.
12. A intervalos regulares el equipo refleja la forma en que se puede volver ms
efectivo; ent onces su comport ami ent o se ajusta y adeca en concordancia.
La agilidad se puede aplicar en cualquier proceso de soft ware. Sin embargo, pa-
ra lograrlo es esencial que el proceso sea di seado en una forma que permita al
equi po del proyecto adapt ar y coordi nar las t areas, conducir la pl aneaci n en una
forma que ent i enda la fluidez de un enfoque de desarrollo gil, eliminar t odo pe-
ro no los product os de t rabaj o esenci al es y mant ener l os controlados, y enfat i zar
una estrategia de ent rega incremental que proporci one soft ware en funci ona-
mi ent o al cliente tan rpido como sea factible para el tipo de product o y el am-
biente operativo.
TM
PDF Editor
CAPITULO 4 DESARROLLO GIL
81
4.2 ES tf PPQCESO AgU-?
Cualquier proceso gil de software s e caracteriza de una maner a que refiere t res su-
posi ci ones clave [FOW02) acerca de la mayora de los proyect os de soft ware:
1. Resulta difcil predecir cul es requisitos del soft ware persistirn y cul es cam-
biarn. De igual forma, es difcil presagi ar cmo cambi arn las pri ori dades del
cliente mi ent ras se ej ecut a un proyecto.
2. Para muchos tipos de soft ware, el di seo y la const rucci n est n intercalados.
Esto es, ambas actividades se deben realizar de maner a conj unt a, de modo
que los model os de di seo sean pr obados conforme se crean. Resulta difcil
predecir cunt o di seo se necesi t a ant es de que la const rucci n se utilice para
probar el diseo.
3. El anlisis, el di seo y la const rucci n no son predeci bl es (desde el punt o de
vista de la planeacin), lo que sera deseabl e.
Dados los punt os ant eri ores, surge una pregunt a i mport ant e: cmo se crea un
proceso susceptible de mani pul ar en forma impredecible? La respuest a, como ya se
ha punt ual i zado ant es, reside en la adaptabilidad del proceso (a un proyecto y a con-
di ci ones t cni cas que cambi an con rapidez). Por lo t ant o, un pr oceso gil debe ser
adaptable.
Pero una adapt aci n cont i nua sin un progreso logra muy poco. Por lo tanto, un
proceso gil de soft ware debe adapt ar se en forma incremental. Para llevar a cabo
una adapt aci n incremental, un equi po gil requi ere de la ret roal i ment aci n con el
cliente (para que sea factible realizar las adapt aci ones apropi adas). Un catalizador
efectivo para la ret roal i ment aci n del cliente es un prototipo operaci onal o una por-
cin de un si st ema operaci onal . Por lo t ant o, debe instituirse una estrategia incremen-
tal de desarrollo. Los incrementos de software (prototipos ej ecut abl es o una porci n de
un si st ema operacional) deben ent regarse en cort os peri odos par a que la adapt aci n
mant enga un buen ritmo con el cambi o (imprevisibilidad). Este enfoque iterativo le
permi t e al cliente eval uar el i ncrement o del sof t war e de maner a regular, proporci o-
nar la ret roal i ment aci n necesari a al equi po de soft ware, e influir sobre las adapt a-
ci ones del proceso que se realizan para adecuar la ret roal i ment aci n.
"No existe un sustituto par a la retroalimentacin rpida, ni en el proceso de desarrollo ni en el producto mi smo. "
Mart in Fow ler
4.2.1 Las polticas del desarrollo gil
Existe un debat e consi derabl e (a veces estridente) sobre los benefi ci os y la aplicabi-
lidad del desarrol l o gil del sof t war e como alternativa a procesos de ingeniera del
soft ware m s convenci onal es. Jim Highsmith [HIG02a] (a maner a de broma) anal i za
los ext remos cuando caract eri za el sent i mi ent o del campo proagilidad ("agilitado-
TM
PDF Editor
^ CONSLI O^
No es necesario elegir
entre agilidad e inge-
nier a del softwore. En
lugar de ello, se
puede definir un
enfoque de ingenier a
de software que sea
gil.
res"). "Los met odl ogos tradicionales son un conj unt o de tipos que se arrast ran en
el l odo y que prefieren produci r document aci n que no fluye, en vez de un si st ema
de t rabaj o que cubra las necesi dades del negocio. " Como cont rapart e, est abl ece la
posicin del campo de la ingeniera del soft ware (de nuevo, en forma de broma):
"Los met odl ogos ' ligeros' y, eh, ' giles' son un conj unt o de i nt rusos i nformt i cos
que van a est ar ah para dar una mal di t a sorpresa cuando i nt ent en elevar sus j ugue-
tes al nivel de sof t war e de la empresa".
Al igual que t odos los ar gument os sobre la t ecnol og a del soft ware, est e debat e
sobr e la met odol og a corre el riesgo de degener ar en una guerra religiosa. Si estalla
la guerra, desapar ece el pensami ent o racional, y las creencias, en vez de los hechos,
gu an la t oma de deci si ones.
Nadie est en contra de la agilidad. La pregunt a real es: cul es la mej or mane-
ra de lograrla? Igual de i mport ant e es la pregunt a: cmo s e const ruye un sof t war e
que sat i sfaga hoy las necesi dades de los clientes y muest r e las caract er st i cas de ca-
lidad que le permi t an ext enderse y escal ar para cubrir a largo pl azo las necesi dades
del cliente?
No existen r espuest as absol ut as para ni nguna de est as pregunt as. Aun dent ro de
la escuel a gil se han propuest o varios model os de proceso (seccin 4.3), cada uno
con un enf oque sut i l ment e diferente para el probl ema de la agilidad. Dent ro de cada
model o hay un conj unt o de "ideas" (que los agilitadores suel en llamar "t areas de tra-
bajo") que represent an una separaci n significativa de la ingeniera del sof t war e
convenci onal . Y aun as, muchos concept os de agilidad son tan sl o adapt aci ones de
buenos concept os de la ingeniera del soft ware. Como punt o final, hay mucho que
ganar si se consi dera lo mej or de ambas escuel as, y nada que ganar si se deni gra al-
guno de los dos enfoques.
El lector i nt eresado puede consul t ar [HIGO 1 ], [HIG02a] y [DEM02] para un ani ma-
do r esumen de los aspect os t cni cos y polticos i mport ant es.
4.2.2 Factores humanos
Los def ensor es del desarrollo gil del sof t war e resaltan la i mport anci a de los "facto-
res de las personas" en un desarrollo gil exitoso. Como est abl ecen Cock burn y
Highsmith [COCOl]: "El desarrol l o gil se cent ra en los t al ent os y las habi l i dades de
los individuos, puest o que el pr oceso se aj ust a a per sonas y equi pos especficos". El
punt o clave en esta afirmacin es que el proceso se ajusta a las necesidades de las per-
sonas y del equipo, y no al revs.2
"Aquello apenas suficiente par a un equipo es excesivo o insuficiente pora otro. "
Alist air Cock burn
2 La mayora de las organizaciones de software exitosas reconocen esta realidad sin importar el mo-
delo de proceso que elijan.
TM
PDF Editor
* wft-
i
VE
G X
propia
r i j a j o que
3 equipo
propios
y define
Si los mi embr os del equi po de soft ware van a manej ar las caractersticas del pro-
ceso que se aplica para construirlo, debe existir un gran nmer o de rasgos clave en-
tre la gent e de un equi po gil y el equi po mismo.-
Compet enci a. En el cont ext o de un desarrollo gil (al igual que en la ingeniera
del soft ware convencional), la "compet enci a" abarca un t al ent o i nnat o, habilidades
especficas rel aci onadas con el soft ware, y un conoci mi ent o general del proceso
que el equi po haya elegido aplicar. La habilidad y el conoci mi ent o del proceso pue-
den y deben ens ear s e a toda la gent e que f unge como mi embr o de un equi po
gil.
Enf oq ue c omn. Aunque los mi embros del equi po gil desempeen t areas di-
ferent es y aport en distintas habilidades al proyecto, t odos deben enfocarse en una
met a: ent regar al cliente un i ncrement o de t rabaj o de soft ware dent r o del t i empo
establecido. Alcanzar esta met a requiere que el equi po t ambi n se cent re en adap-
t aci ones cont i nuas (pequeas y grandes) medi ant e las cual es el pr oceso satisfar
las necesi dades del equipo.
Col aboraci n. La ingeniera del soft ware (sin consi derar el proceso) incluye
evaluar, anal i zar y usar i nformaci n que se comuni ca al equi po de soft ware; crear
i nformaci n que ayudar al cliente y a otros a ent ender el t rabaj o del equipo; y
construir i nformaci n (software de comput ador a y bases de dat os relevantes) que
ofrezca un valor comercial para el cliente. Estas t ar eas se cumpl i rn si los mi em-
br os del equi po col aboran, ent re ellos, con el cliente y con sus gerent es.
Habi l i dad para la t oma de de ci s i one s . Todo buen equi po de sof t war e (in-
cluidos los equi pos giles) debe permitirse la libertad de cont rol ar su propi o desti-
no. Esto implica que al equi po se le d aut onom a, es decir, autoridad para t omar
deci si ones en cuant o a cuest i ones t cni cas y del proyecto.
Capaci dad de res ol uci n de probl e mas c onf us os . Los gest ores de sof t war e
deben reconocer que el equi po gil enfrent ar ambi gedades y sufrir gol pes de
maner a cont i nua debi do al cambio. En al gunos casos, el equi po debe acept ar que
el probl ema que est resol vi endo hoy tal vez no sea el probl ema que debe resol-
verse maana. Sin embargo, las lecciones aprendi das en cualquier actividad para
la resolucin de probl emas (incluidas aquel l as que sirven para sol uci onar el pro-
bl ema errneo) pueden beneficiar al equi po en fases post eri ores del proyecto.
Conf i anza y r e s pe t o mut uo. El equi po gil se debe convertir en lo que De
Marco y Lister [DEM98] l l aman un equi po "cuaj ado" (vase el captulo 21). Un equi-
po cuaj ado muest ra la confi anza y el respet o necesari os par a que "se unan con
t ant a fuerza, que el todo sea mayor que la suma de las partes" [DEM98],
Organi zaci n propi a. En el cont ext o del desarrol l o gil, la organizacin propia
implica t res factores: 1) el equi po gil se organi za a s mi smo para el t rabaj o que
debe hacerse; 2) el equi po organi za el proceso que mej or se aj ust a a su ambi ent e
local; 3) el equi po organi za el pr ogr ama de t rabaj o con el que se al cance de mej or
TM
PDF Editor
maner a la ent rega del i ncr ement o del soft ware. La organi zaci n propia tiene varios
benefi ci os tcnicos, per o lo ms i mport ant e es que mej ora la col aboraci n y eleva
la moral del equipo. En esenci a, el equi po sirve como su propia gestora. Ken Sch-
waber [SCH02] punt ual i za est os aspect os cuando escribe: "El equi po sel ecci ona la
cant i dad de t rabaj o que cree que es capaz de hacer dent r o de la iteracin, y el
equi po se compr omet e con el t rabaj o. Nada desal i ent a m s a un equi po que al-
guien ms se compr omet a por l. Nada motiva ms a un equi po que acept ar la res-
ponsabilidad de cumplir los compr omi sos que l mi smo hizo".
4 . 3 MODE L OS GI LES DE PROCESO
La historia de la ingeniera del sof t war e est llena de decenas de descri pci ones y me-
todologas, mt odos de model ado y not aci ones, her r ami ent as y t ecnol og as obsol e-
tas. Cada el ement o surgi con not ori edad y despus lo eclips al go nuevo y (supues-
t ament e) mej or. Con la introduccin de un ampl i o espect ro de model os giles de
proceso cada uno en busca de su acept aci n dent ro de la comuni dad del desarro-
llo de soft ware el movi mi ent o gil est en la mi sma ruta histrica. 3
"Nuestro profesin vo tros ios metodologas como un adolescente va t ras la ropa. "
St ephen Haw rysh y Jim Ruprecht
Ref er enci a Web
w w w .ex t remepra
groromiiig.org/
eiKontror uno
En las si gui ent es secci ones se pr esent a una visin general de cierto nmer o de di-
ferent es modelos giles de proceso. Existen muchas similitudes (en filosofa y prcti-
ca) ent re est os enf oques. La intencin es subrayar aquel l as caract er st i cas de cada
mt odo que lo hacen nico. Es i mport ant e seal ar que todos los model os gi l es se
aj ust an (en mayor o menor grado) al Manifiesto para el desarrollo de software y a los
principios enunci ados en la seccin 4.1.
4.3.1 Programacin extrema (PE)
A pesar de que los pri meros t rabaj os sobr e las i deas y los mt odos asoci ados con la
programacin extrema ( PE) se realizaron a finales de la dcada de 1980, el t rabaj o
f undament al sobre la materia, escrito por Kent Beck [BEC99], se public en 1999. Los
libros subsi gui ent es de Jeffries et al. tJEFOl] sobre los det al l es t cni cos de la PE, y el
t rabaj o adicional de Beck y Fowler [BECOlb] sobr e la pl aneaci n de la PE expusi eron
los det al l es del mt odo.
La PE utiliza un enf oque ori ent ado a obj et os (parte 2 de est e libro) como su para-
di gma de desarrol l o preferido. La PE abarca un conj unt o de regl as y prct i cas que
ocurren en el cont ext o de cuat ro actividades del mar co de t rabaj o: pl aneaci n, dise-
3 Esto no es algo malo. Antes de que uno o ms modelos o mtodos sean aceptados como un estn-
dar de facto, todos deben competir por los corazones y las mentes de los ingenieros de software.
Los "ganadores" evolucionan con la mejora que proporciona la prctica, mientras que los "perde-
dores" desaparecen o se unen a los modelos "ganadores".
TM
PDF Editor
CAPTULO 4 DESARROLLO GIL
85
k i
diseo simple
carias CRC
soluciones pico
prototipos
Lan
d e '
programacin en pareja
o, codificacin y pruebas. En la figura 4.1 se ilustra el proceso de la PE y se obser-
van al gunas de las ideas y t areas clave asoci adas con cada actividad del mar co de tra-
bajo. En los siguientes prrafos se r esumen las actividades clave de la PE.
Pl aneaci n. La actividad de pl aneaci n comi enza creando una serie de historias
(tambin l l amadas historias del usuario) que descri ben las caract er st i cas y la funcio-
ralidad requeridas para el soware que se construir . Cada historia ( similar a los ca-
sos de uso descritos en los cap tulos 7 y 8) la escribe el cliente y se coloca en una
cart a ndice. El cliente le asi gna un valor (es decir, una prioridad) a la historia basn-
dose en los val ores general es del negoci o respect o de la caracterstica o la funcin. 4
Los mi embr os del equi po de la PE eval an ent onces cada historia y le asi gnan un
costo, el cual se mi de en s emanas de desarrollo. Si la historia requi ere m s de tres
s emanas de desarrollo, se le pide al cliente que la divida en historias menor es, y se
realiza de nuevo la asi gnaci n del valor y el cost o. Es i mport ant e dest acar que las
historias nuevas pueden escribirse en cualquier moment o.
Los cl i ent es y el equi po de PE t rabaj an j unt os para decidir cmo agr upar las hi s-
torias haci a el prxi mo l anzami ent o (el si gui ent e i ncr ement o de soft ware) para que
el equi po de la PE las desarrolle. Una vez est abl eci do el compromiso bsi co (el
acuer do de las historias que se incluirn, la fecha de ent rega y ot ras cuest i ones del
proyecto) para un l anzami ent o, el equi po de la PE or dena las hi st ori as que se desa-
rrollarn de una de las si gui ent es tres maner as: 1) t odas las historias ser n imple-
4 El valor de una historia puede depender tambin de la presencia de otra historia.
TM
PDF Editor
Enelslio
c 2. c om/ c gi / wi k i ?
pl ami i ngGame se
puede encont rar un
vel l osa "j uego de
pl oneadi t " poro la PE.
ment adas de un modo i nmedi at o (dentro de pocas semanas) ; 2) las historias con va-
lor ms alto se mover n en el pr ogr ama y se i mpl ement ar n al principio; o 3) las
hi st ori as m s ri esgosas se mover n dent ro del pr ogr ama y se i mpl ement ar n al
principio.
Despus de que se ha ent regado el pri mer l anzami ent o del proyect o (tambin lla-
mado i ncrement o de software), el equi po de la PE calcula la velocidad del proyecto.
Dicho de un modo m s simple, la velocidad del proyecto es el nmer o de historias de
los clientes i mpl ement ado dur ant e el pri mer l anzami ent o. Ent onces, la velocidad del
proyecto puede utilizarse para I) ayudar a est i mar fechas de ent rega y el programa
para l anzami ent os subsecuent es, y 2) det ermi nar si se ha hecho un compromi so ex-
cesivo en al gunas de las historias de t odo el proyect o de desarrollo. Si se present a
un compromi so excesivo, el cont eni do de los l anzami ent os se modifica o se cambi an
las fechas de las ent r egas finales.
Conforme avanza el t rabaj o de desarrollo, el cliente puede agregar historias, cam-
biar el valor de la historia existente, dividir historias o eliminarlas. Ent onces el equi-
po de la PE consi dera de nuevo los l anzami ent os rest ant es y modifica sus pl anes de
acuer do con ello.
"Lo programaci n ext r ema es uno disciplina de desarrollo de soft ware que se basa en valores de simplicidad,
comunicacin, retroalimentacin y audaci a. "
Ron Jeffries
Di s eo. El di seo de la PE sigue de maner a rigurosa el principio MS (mant enerl o
simple). Si empre se prefiere un di seo simple respect o de una present aci n ms
compleja. Adems, el di seo ofrece una gua de i mpl ement aci n para una historia
como est escrita, ni ms ni menos. Se desapr ueba el di seo de funci onal i dad extra
(porque el desarrollador supone que se requerir ms tarde).
La PE apoya el uso de t arj et as CRC ( capitulo 8) como un mecanismo efectivo pa-
ra pensar en el sof t war e en un contexto orientado a objetos. Las t arj et as CRC (cola-
borador-responsabi l i dad-cl ase) identifican y organi zan las cl ases ori ent adas al obje-
to6 que son rel evant es para el i ncr ement o del soft ware actual. El equi po PE condu-
ce el ejercicio del di seo por medi o de un proceso similar al descrito en el captulo
8 (seccin 8.7.4.). Las t arj et as CRC son el ni co product o de t rabaj o real i zado como
part e del proceso de la PE.
Si se encuent ra un probl ema difcil de di seo como part e del di seo de la histo-
ria, la PE recomi enda la creacin i nmedi at a de un prototipo operaci onal de esa por-
cin del diseo. El prototipo del diseo, l l amado la solucin pico, se i mpl ement a y
evala. El propsito es reducir el riesgo cuando comi ence la verdadera i mpl ement a-
5 Estas directrices de diseo se deberan seguir en todos los mtodos de ingeniera del software,
aunque a veces las notaciones y terminologas sofisticadas que se utilizan en el diseo pueden em-
plearse de una manera ms simple.
6 En el capitulo 8, y a lo largo de la parte 2 del libro, se estudian las clases orientadas a objetos.
TM
PDF Editor
87
cin y validar las est i maci ones originales en la historia que cont i ene el probl ema del
diseo.
La PE apoya la refabricacin, una tcnica de const rucci n que t ambi n lo es de di-
seo. Fowler [FOWOO] descri be la refabricacin de la siguiente maner a:
Refabricacin es el proceso de cambi ar un sistema de soft ware de tal maner a que no al-
tere el comport ami ent o ext erno del cdigo y que mej or e la est ruct ura interna. Es una ma-
ner a disciplinada de limpiar el cdigo [y modi fi car/ si mpl i fi car el di seo interno], lo que
minimiza las oport uni dades de introducir errores. En esencia, al refabricar, se mej ora el
di seo del cdigo despus de que se ha escrito.
Debido a que el di seo de la PE vi rt ual ment e no utiliza la not aci n y produce, si aca-
so, muy pocos product os de trabajo, distintos a las t arj et as de CRC y sol uci ones pi-
co, el di seo se consi dera como un art efact o que puede y debe modificarse de ma-
nera cont i nua a medi da que prosi gue la const rucci n. El propsito de refabricar es
controlar est as modi fi caci ones al sugerir pequeos cambi os del di seo que "pueden
mej orar de maner a radical el diseo" [FOWOO], Sin embargo, debe not arse que el es-
f uer zo requeri do para refabricar puede aument ar en forma drstica a medi da que
crece el t amao de la aplicacin.
Una noci n cent ral en la PE es que el di seo ocurre t ant o ant es como despus
del comi enzo de la codificacin. Refabri car significa que el di seo ocurre de mane-
ra cont i nua a medi da que se const ruye el si st ema. De hecho, la actividad de cons-
t rucci n mi sma le proporci onar al equi po de PE una gua sobr e cmo mej or ar el
di seo.
Codi f i caci n. La PE recomi enda que despus de di sear las historias y realizar el
t rabaj o de di seo preeliminar el equi po no debe moverse haci a la codificacin, si no
que debe desarrollar una serie de pr uebas de unidad que ejerciten cada una de las
historias que vayan a incluirse en el l anzami ent o act ual (i ncrement o de soft ware). 7
Una vez creada la prueba de unidad, el desarrol l ador es ms capaz de cent rarse en
lo que debe i mpl ement arse para pasar la prueba de unidad. No se agrega nada ex-
t rao (MS). Una vez que el cdigo est compl et o, la uni dad puede probarse de i nme-
diato, y as proporci onar una ret roal i ment aci n i nst ant nea a los desarrol l adores.
Un concept o clave durant e la actividad de codificacin (y uno de los aspect os de
la PE de los que m s se ha hablado) es la programacin en pareja. La PE recomi enda
que dos per sonas t rabaj en j unt as en una est aci n de t rabaj o de comput ador a para
crear el cdi go de una historia. Esto proporciona un mecani smo para la resolucin
de probl emas en t i empo real (dos cabezas pi ensan mejor que una) y el asegur ami en-
t o de la calidad en las mi smas condi ci ones. Tambin alienta que los desarrol l adores
se mant engan cent rados en el probl ema que se tiene a la mano. En la prctica, ca-
da persona tiene un papel sut i l ment e diferente. Por ej empl o, una persona puede pen-
7 Este enfoque es anlogo a conocer las preguntas del examen antes de comenzar a estudiar. Esto fa-
cilita mucho ms el estudio al enfocar la atencin slo sobre las preguntas que sern formuladas.
TM
PDF Editor
P A R T E U N O EL PROCESO DEL SOFTWARE
\
CLAVE
l as pruebas de
aceptacin de la PE se
derivan de las historias
del usuario.
sar en los detalles de codificacin de una porcin particular del diseo, mientras que la
otra se asegura de que se sigan los est ndares de codificacin (una parte requerida de
la PE) y que el cdigo que se genera "coincida" con el diseo ms amplio de la historia.
Cuando los pr ogr amador es compl et an su t rabaj o el cdi go que desarrollaron se
integra con el t rabaj o de otros. En al gunos casos est o lo lleva a cabo di ari ament e el
equi po de integracin. En ot ros casos, la parej a de pr ogr amador es es la responsabl e
de la integracin. Esta estrategia de "integracin continua" ayuda a evitar probl emas de
compatibilidad e i nt erfaz y proporci ona un ambi ent e de "prueba de humo" (captulo
13) que ayuda a descubrir los errores desde el principio.
Pruebas. Ya se ha hecho not ar que la creacin de una prueba de uni dad8 ant es de
comenzar la codificacin es un el ement o clave para el enf oque de la PE. Las prue-
bas de unidad que se crean deben i mpl ement arse con un mar co de t rabaj o que per-
mita aut omat i zarl as (por lo t ant o, pueden ej ecut arse de maner a fcil y repetida). Es-
t o apoya una estrategia de regresin de prueba (captulo 13) cuando el cdigo se mo-
difica (al cual a menudo se le confi ere la filosofa de la PE de refabricar).
Cuando las uni dades individuales de prueba se or gani zan en un "conj unt o univer-
sal de pr uebas" [WEL99], las pr uebas de integracin y validacin del si st ema pueden
real i zarse a diario. Esto proporci ona al equi po de PE una indicacin cont i nua del
progreso y t ambi n puede encender luces de emergenci a previas si las cosas sal en
mal. Wells [WEL99] establece: "Arreglar pr obl emas pequeos cada pocas hor as t o-
ma menos t i empo que arreglar probl emas enor mes justo ant es de la fecha lmite".
Las pruebas de aceptacin de la PE, t ambi n l l amadas pruebas del cliente, las espe-
cifica el cliente y se enf ocan en las caract er st i cas general es y la funcionalidad del
si st ema, el ement os visibles y revisables por el cliente. Las pr uebas de acept aci n se
derivan de las historias del usuari o que se han i mpl ement ado como part e de un lan-
zami ent o de soft ware.
HOGARSEGURO
Tomar en cuenta el desarrollo de software gil
El escenario:
Los a c t or e s : Doug Miller, gerente de ingeniera de
software; Jamie lazar, miembro del equipo de software;
Vinod Raman, miembro del equi po de software.
La conversaci n:
(llaman a la puerta)
J a mi e : Doug, tienes un minuto?
Doug: Seguro Jamie, qu pasa?
J a mi e : Hemos estado pensando en nuestra
conversacin de ayer acerca del proceso... t sabes, de
cul sera el proceso que elegiramos pora este nuevo
proyecto de HogarSeguro.
Doug: Y?
8 Las pruebas de unidad, que se tratan con detalle en el captulo 13, se enfocan sobre un component e
individual del software, al ejercitar la interfaz de los componentes, las estructuras de dat os y la fun-
cionalidad en un esfuerzo por descubrir los errores locales en el componente.
TM
PDF Editor
89
- cobndo con un amigo de otra
' r e coment sobre la programacin
i r - oê c de proceso gil, has odo algo
i buenas y malas.
c; -osotros nos suena muy bien. Te
e; software muy rpido, utiliza algo
rocin en pareja para hacer
i de rci' dad en tiempo real... pienso que es
.c'- cs ideas realmente buenas. Por
e concepto de la programacin en
i 2e cue todos los participantes del
corte del equipo de desarrollo.
Eso significa que mercadotecnia
l el equipo con nosotros?
i): Ellos son participantes, no?
Dios!... Van a estar pidiendo cambios
-^cesariamente. Mi amigo me dijo que hay
ir" los cambios durante el proyecto de
ustedes creen que debamos usar PE?
Es dgo que definitivamente deberamos de
Doug: Estoy de acuerdo. Y aun si elegimos como
nuestro enfoque un modelo incremental, no existe
ninguna razn por la que no podamos incorporar mucho
de lo que la PE tiene que ofrecer.
Vi nod: Doug, antes dijiste "escuch cosas buenas y
malas". Cules fueron las "malos*2
Doug: Lo que no me gusta es Iq forma en que l PE
menosprecia el anlisis y el dise... es como decir que
la accin real slo est en ia escritura del cdigo.
(los miembros del equipo se miran entre s y sonren)
Doug: Entonces, estn de acuerdo con el enfoque de la
PE?
Jami e ( habl ando por ambos ) : Jefe, lo que
nosotros hacemos es escribir cdigo!.
Doug (riendo): Es cierto, pero me gustara verlos
dedicar un poco menos de tiempo a la codificacin y a la
recodificacin y un poco ms de tiempo a analizar lo
que se tiene que hacer y a disear una solucin que
funcione.
Vi nod: Puede ser que adoptemos ambas formas,
agilidad con un poco de disciplina.
Doug: Vinod, creo que podemos hacerlo. De hecho,
estoy seguro de ello.
4.3.2 Desarrollo adaptativo de software (DAS)
El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith [HIGOO] como
una tcnica para construir soft ware y sistemas complejos. Los apoyos filosficos del
DAS se enfocan en la colaboracin humana y la organizacin propia del equipo.
Highsmith [HIG98] expone lo anterior cuando escribe:
La organi zaci n propia es una propi edad de los si st emas adapt at i vos compl ej os, similar a
un "aj" colectivo; es en el moment o de energa creativa cuando surge la solucin a algn
probl ema persistente. La organi zaci n propia emerge cuando los individuos, los agent es
i ndependi ent es (clulas en un cuerpo, especi es en un ecosi st ema, desarrol l adores en un
equi po de soft ware) cooperan [colaboran] para crear sal i das emergent es. Una salida
emer gent e es una propiedad m s all de la capaci dad de cualquier agent e individual. Por
ejemplo, las neur onas individuales del cerebro no poseen conciencia, pero en forma co-
lectiva gener an la propi edad de la conciencia. Tendemos a ver est e f enmeno del surgi-
mi ent o colectivo como un accidente, o al menos como i ndependi ent e y sin reglas. El
estudio de la organi zaci n propi a demuest ra que dicha visin es errnea.
TM
PDF Editor
90 PASTE UNO EL PROCESO DEL SOFTWARE
Desarrollo
adapt at vo de
software.
pl anean del ciclo adaptativo
enunciado de la misin
restricciones del proyecto
requisitos b sicos
plan de lanzamiento en el tiempo
Recopilacin de requisitos
JA D
especificaciones m nimas
Lanzamiento
incremento de software
ajuste para ciclos subsecuentes
componentes implementados/probados
grupos de enfoque para retroalimentacin
revisiones tcnicas formales
post mortem
Ref er enci a Web
www.adaptivesd.
<om s e pueden
m k Cules son
w las caract e-
r st icas de los
ciclos adapt at ivos
del DAS?
^ O N S I J O ^
La colaboracin
efectivo con el cliente
ocurrir slo si se
eliminan todas las
actitudes del tipo " yo
y ustedes" .
Highsmith ar gument a que un enf oque de desarrol l o gil y adapt at i vo basado en la
col aboraci n es "t ant o como una f uent e de orden en las compl ej as i nt eracci ones en-
tre disciplina e ingeniera". l define un "ciclo de vida" del DAS (figura 4.2), el cual
incorpora tres fases: especul aci n, col aboraci n y aprendi zaj e.
Especul aci n. En esta fase se inicia el proyect o y se conduce el ciclo adaptat vo de
planeacin. Este ltimo utiliza i nformaci n de inicio del proyect o el enunci ado de
la misin del cliente, rest ri cci ones de proyect o (por ej empl o, f echas de ent rega o des-
cri pci ones del cliente) y los requisitos bsicos para definir el conj unt o de ciclos de
l anzami ent o (i ncrement os del soft ware) que s e requerirn para el proyecto. 9
Col aboraci n. La gent e mot i vada t rabaj a j unt a de una forma que multiplica su t a-
lento y s us sal i das creat i vas m s all de sus nmer os absol ut os. Este enf oque de co-
laboracin es un t ema recurrent e en t odos los mt odos giles, pero la cooperaci n
no es fcil. No es sl o comuni caci n, aunque la comuni caci n es parte de ella. No
es sl o un asunt o de t rabaj o en equipo, aunque un equi po "cuajado" (captulo 21) es
esencial para la presenci a de la col aboraci n real. No es un r echazo al individualis-
mo, ya que la creatividad individual represent a un papel i mport ant e en el pensa-
mi ent o de col aboraci n. Esto es, por enci ma de todo, una cuest i n de confi anza. Las
per sonas que t rabaj an j unt as deben confi ar ent re s para 1) criticar sin ani mosi dad;
9 Obsrvese que el plan del ciclo adaptativo puede adaptarse, y con probabilidad lo har, al proyecto
cambiante y a las condiciones del negocio.
TM
PDF Editor
91
2) ayudar sin resent i mi ent os; 3) t rabaj ar tan dur o o m s duro de lo que ya lo hacen;
4i t ener el conj unt o de apt i t udes para contribuir al t rabaj o en curso; y 5) comuni car
as probl emas o preocupaci ones en una forma que conduzca a la acci n efectiva.
Me gusta escuchar. He aprendi do mucho al escuchar a las personas, l a mayof a de la gent e nunca escucha. "
Ernest Hemingw ay
Aprendi zaje. Como mi embr os de un equi po de DAS se comi enzan a desarrollar los
component es i nt egrant es de un ciclo adapt at i vo, la importancia radica en el apr en-
dizaje y en el progreso a t ravs de un ciclo compl et o. De hecho, Highsmith [HIGGOO]
ar gument a que los desarrol l adores de sof t war e a menudo sobreest i man su com-
prensi n (de la tecnologa, el pr oceso y el proyecto), y que el aprendi zaj e les podra
ayudar a mej orar su gr ado de ent endi mi ent o real. Los equi pos del DAS apr enden de
tres maner as:
1. G rupos e nf ocados . El cliente o los usuari os finales proporcionan retroali-
ment aci n sobre los i ncrement os de soft ware que se ent regan. Esto indica en
forma directa la satisfaccin o la insatisfaccin de las necesi dades del negocio.
2. Revi s i ones t cni cas f ormal es . Los mi embros del equi po del DAS revisan
los component es del sof t war e desarrol l ado mi ent ras mej oran su calidad y su
aprendi zaj e.
3. Post mortem. El equi po de DAS se vuelve introspectivo al vigilar su propi o
des empeo y proceso (con el proposi t o de apr ender acerca de su enf oque y
despus mejorarlo).
Es i mport ant e dest acar que la filosofa del DAS es meritoria sin importar el model o
de proceso empl eado. El acent o general en la di nmi ca de la organi zaci n propia en
los equipos, la col aboraci n i nt erpersonal y el aprendi zaj e individual y por equi po
conducen grupos de proyect os de sof t war e con una mayor posibilidad de xito.
4.3.3 Mtodo de desarrollo de sistemas dinmicos (MDSD)
El mtodo de desarrollo de sistemas din micos [STA97] es un enf oque de desarrol l o de
soft ware gil que "proporciona un mar co de t rabaj o para construir y mant ener siste-
mas con restricciones de t i empo muy est rechas medi ant e el empl eo de la const ruc-
cin de prototipos i ncrement al es en un ambi ent e de proyect o cont rol ado" [CCS02].
Similar a al gunos aspect os del proceso DRA descrito en el captulo 3, el MDSD su-
giere una filosofa t omada de una modificacin del principio de Pareto. En est e ca-
so, 80 por ci ent o de la aplicacin se puede ent regar en 2096 del t i empo que t omar a
ent regar 100 por ci ent o de la aplicacin (sistema compl et o).
Al igual que la PE y el DSA, el MDSD sugiere un proceso iterativo de soft ware. Sin
embargo, el enfoque del MDSD en cada iteracin sigue la regla del 80 por ciento. Es-
to es, slo se necesi t a el t rabaj o suficiente para cada i ncr ement o y para facilitar el
TM
PDF Editor
En www. c s 3 n c .
c o m/ DS DM. h t m
uno
MOSB.
movi mi ent o hacia el nuevo i ncrement o. Los detalles rest ant es se pueden compl et ar
post eri orment e cuando se conozcan m s los requisitos de negoci os o cuando los
cambi os hayan sido solicitados o aj ust ados.
En la red mundi al hay una organi zaci n (DSDM Consort i um, www. dsdm. org) que
de maner a colectiva as ume el papel de "conservador" del mt odo. Esta organi zaci n
ha definido un model o gil de proceso, l l amado el ciclo de vida del MDSD. Este m-
t odo defi ne t res ciclos iterativos diferentes, a los cual es preceden dos act i vi dades del
ciclo de vida adicionales:
Estudio defectibilidad: est abl ece los requisitos bsi cos de negoci o y las restriccio-
nes asoci adas con la aplicacin del mt odo y para eval uar si la aplicacin es una
candi dat a viable para el proceso del MDSD.
Estudio de negocios: est abl ece los requisitos funci onal es y de i nformaci n que per-
mitirn que la aplicacin proporci one un valor al negocio; t ambi n defi ne la arqui-
tectura bsi ca de la aplicacin.
Iteracin de modelo funcional produce una seri e de prototipos i ncrement al es que
demuest r an la funci onal i dad para el cliente (nota: t odos los prot ot i pos del MDSD es-
tn di seados para evol uci onar hacia la aplicacin ent regabl e). El propsi t o duran-
te est e ciclo iterativo es recopilar requisitos adi ci onal es medi ant e la ret roal i ment a-
cin de lo que obt i ene el usuario, mi ent ras st e t rabaj a con el prototipo.
Iteracin de construccin y diseo: revisa la const rucci n de prot ot i pos dur ant e la
iteracin del model o funci onal para asegurar que cada uno de ellos ha sido desarro-
llado de una maner a que le permitir proporci onar un valor operat i vo de negoci os
para los usuari os finales. En al gunos casos, la iteracin del model o funci onal y el di-
seo y la iteracin de const rucci n suceden en forma concurrent e.
implemeniacin: col oca el i ncr ement o de soft ware m s reci ent e (un prototipo
"operacionalizado") en el ambi ent e operativo. Se debe dest acar que 1) el i ncremen-
to puede no est ar 100 por ci ent o compl et o o 2) se pueden requerir cambi os cuando
el i ncr ement o se coloca en el sitio. En cualquier caso, el t rabaj o de desarrol l o del
MDSD cont i na al regresar a la actividad de iteracin del model o de funci n.
El MDSD s e puede combi nar con la PE para obt ener un enf oque conj unt o que de-
fine un model o slido de proceso (el ciclo de vida del MDSD) con los aspect os prc-
ticos (PE) necesari os para const rui r i ncr ement os de soft ware. Adems, los concep-
t os del DAS de col aboraci n y equi pos aut oor gani zados se pueden adapt ar a un mo-
del o de proceso combi nado.
4.3.4 Mel
Mel (trmino deri vado de una j ugada de rugby10) es un model o gil de pr oceso que
desarrol l aron Jefff Sutherland y su equi po a principios de la dcada de 1990. En aos
10 Un grupo de jugadores se alinea alrededor del baln y los compaeros de equipo trabajan juntos (al-
gunas veces de manera violenta) para desplazar el baln hacia el lado contrario del campo de juego
TM
PDF Editor
93
recientes, Schwaber y Beedle [SCH01] han pr esent ado el desarrol l o posterior de los
mt odos de mel. Los principios de la mel [ADM96] son consi st ent es con el mani -
fiesto gil.
Los equi pos de t rabaj o pequeos est n or gani zados para "maxi mi zar la co-
muni caci n, minimizar los gast os general es y maxi mi zar el hecho de compar -
tir conoci mi ent o tcito e informal".
El proceso debe adapt ar se a los cambi os t cni cos y de negoci os "para asegu-
rar que se produzca el mej or product o posible".
El proceso produce i ncr ement os frecuent es de sof t war e "los cual es se pueden
i nspecci onar, ajustar, probar, document ar y construir".
El t rabaj o de desarrol l o y la gent e que lo realiza est n divididos en "particio-
nes o paquet es de baj o acopl ami ent o".
Conforme se const ruye el product o se realizan pr uebas y document aci n
const ant es.
Los procesos de mel proporci onan la "capaci dad de decl arar un product o co-
mo ' real i zado' si empre que est o se requiera (porque la compet enci a acaba de
hacer un l anzami ent o, por que la compa a necesita el dinero, por que el usua-
ri o/ cl i ent e necesita las funci ones, por que ya se est en el moment o en que se
prometi..." [ADM96].
Con los principios de la mel se guan las actividades dent ro de un pr oceso que in-
corpora las si gui ent es actividades del mar co de t rabaj o, requisitos, anlisis, diseo,
evolucin y ent rega. En cada actividad del mar co de t rabaj o las t ar eas de t rabaj o su-
ceden dent r o del pat rn de proceso (tratado en el prrafo siguiente) l l amado sprint.
El t rabaj o real i zado dent r o de un sprint (el nmer o requeri do de sprints variar de
acuer do con el t amao y la complejidad del producto) se adapt a al pr obl ema y con
frecuenci a lo modifica en t i empo real el equi po de mel. En la figura 4.3 se ilustra el
flujo general del proceso de mel.
I
"i os m t e n o s permiten construir un software m s suave." - " )
Mifce Beet le et al.
La mel subraya el uso de un conj unt o de "pat rones de proceso de soft ware"
(NOY02] que ha pr obado su efectividad en proyect os con t i empos de ent rega muy re-
ducidos, requisitos cambi ant es y condi ci ones crticas en los negocios. Cada uno de
est os pat r ones de pr oceso defi ne un conj unt o de actividades de desarrollo:
Retrasos: son una lista que consi dera la prioridad de los requisitos o caractersti-
cas de proyect o que proporci onan un valor comercial para el cliente. En cualquier
moment o se pueden agregar el ement os a los ret rasos (as se introducen los cam-
bios). El gerent e de product o evala los ret rasos y act ual i za las pri ori dades de acuer-
do con lo requerido.
TM
PDF Editor
94 PA RTE UNO EL PROCESO DEL SOFTWA RE
Flujo de proceso de la mel.
Mel: reunin diaria de 15 minutos
Los miembros del equipo responden
a las preguntas bsicas
1) Qu hiciste desde la ltima reunin?
2) Tienes algn obstculo?
3) Qu hars antes de la prxima reunin?
Retraso del producto:
Caracteristicas del producto deseadas por el cliente
que han recibido prioridad
La nueva funcionalidad
se demuest ra
al final del sprint
Retraso de sprint:
Caractersticas
asignadas
al sprint
Elementos
de retraso
expandidos
CLAVE
La mel incorporo un
conjunto de potrones
de proceso que resalta
las prioridades del
proyecto, la divisin
del trabajo, las
unidades de trabajo, la
comunicacin y la
retroalimentacin
frecuente del diente.
Sprint: consi sl e en uni dades de Lrabajo que se requi eren para satisfacer un requi-
sito definido en los ret rasos en un peri odo predefi ni do (el l apso usual es de 30 das).
En est a et apa, los el ement os de los ret rasos a los que se dirigen las uni dades de tra-
baj o del sprint est n congel ados (es decir, dur ant e el sprint no se i nt roducen cam-
bios). Por lo t ant o, el sprint permite a los mi embr os del equi po t rabaj ar en un am-
bi ent e enf ocado al cort o plazo, pero estable.
Reuniones de mel: son reuni ones cort as (por lo general de 15 minutos) y las rea-
liza a diario el equi po de mel. Existen tres pr egunt as que pl ant ean y responden to-
dos los mi embr os del equipo.
Qu hiciste desde la ltima reuni n?
Cules obst cul os encont rast e?
Qu esper as lograr para la siguiente reuni n del equi po?
Un lder de equipo, l l amado "maest ro de la mel", preside la reuni n y eval a las
r espuest as de cada persona. Cada reuni n de mel ayuda al equi po a descubrir pro-
bl emas pot enci al es t an pront o como sea posible. Estas reuni ones diarias t ambi n
conducen a la "socializacin del conoci mi ent o" [BEE99] y, por ende, a promover una
est ruct ura de equi po con organi zaci n propia.
TM
PDF Editor
CAPITULO 4 DESARROLLO GIL
95
Demostracin: se ent rega el i ncrement o de sof t war e al cliente de forma que st e
demuest r e y eval e la funci onal i dad i mpl ement ada. Es i mport ant e seal ar que la de-
most raci n qui z no cont enga toda la funcionalidad pl aneada, sino aquel l as funcio-
nes susceptibles de ent regarse dent ro del periodo establecido.
Beedle y sus col egas [BEE99] pr esent an un anlisis compl et o de est os pat r ones y
est abl ecen: "La MEL supone la existencia del caos. . . ". El pat rn de proceso de la
mel permite que un equi po de desarrol l o de sof t war e t rabaj e de maner a exitosa en
un mundo donde la eliminacin de la incertidumbre es imposible.
4.3.5 Cristal
Alistair Cock burn [COC02a] y Jim Highsmith [HIG02b| crearon la familia cristal de los
mtodos giles11 con el fin de lograr un enfoque de desarrol l o de sof t war e que colo-
ca un premi o en la "manej abi l i dad" dur ant e lo que Cock burn caract eri za como "un
juego cooperat i vo de inventiva y comuni caci n con recursos limitados, con una me-
ta primaria consistente en la entrega de soft ware til y en funci onami ent o y una meta
secundari a de prepararse para el juego siguiente" [CC)C02b].
Para al canzar la manej abi l i dad, Cock burn y Highsmith definieron un conj unt o de
met odol og as, cada una de ellas con el ement os esenci al es comunes a t odas, y fun-
ciones, pat r ones de proceso, product os de t rabaj o y prcticas ni cas en cada una de
ellas. En realidad, la familia cristal es un conj unt o de procesos giles, los cual es han
pr obado su efectividad en di ferent es tipos de proyectos. El objetivo es permitir que
los equi pos giles sel ecci onen el mi embr o de la familia cristal m s apropi ado para
su proyect o y ambi ent e.
4.3.6 Desarrollo conducido por caractersticas (DCC)
El desarrollo conducido por caracter sticas (DCC) lo concibieron ori gi nal ment e Peter
Coad y sus col egas [COA99] como un model o de proceso prct i co para la ingeniera
del sof t war e ori ent ada a obj et os. St ephen Pal mer y John Felsing [PAL02] han ext en-
dido y mej orado el trabajo de Coad, al describir un proceso adaptativo y gil que puede
aplicarse en proyectos de soft ware de t amao moder ado y grande.
En el cont ext o del DCC una caracter stica "es una funcin val uada por el cliente
que puede i mpl ement arse en dos s emanas o menos" [COA99]. La importancia que
se le concede a la definicin de caract er st i cas proporci ona los si gui ent es beneficios.
Como las caract er st i cas son bl oques pequeos de funcionalidad ent regabl e,
los usuari os las descri ben con mayor facilidad, pueden ent ender cmo st as
se rel aci onan con ot ras con mayor rapidez, y pueden revisarlas de mej or ma-
nera en bsqueda de ambi gedades, errores u omi si ones.
Las caractersticas s e pueden organi zar en un agr upami ent o j errqui co rela-
ci onado con el negocio.
11 El nombre " cristaI" se deriva de las caractersticas de los cristales geolgicos, cada uno con su pro-
pio color, forma y dureza.
TM
PDF Editor
96 PMCTEISNO O-TOOCSOCELSOFWIME.
Como una caracterstica es el i ncrement o de sof t war e ent regabl e, el equi po
desarrolla caract er st i cas operat i vas cada dos semanas.
Debido a que l as caractersticas son pequeas, sus di seos y represent aci ones
de cdi go son ms fciles de i nspecci onar de maner a efectiva.
La pl aneaci n del proyecto, la elaboracin de su pr ogr ama y su rast reo los
gua la jerarqua de la caracterstica, en l ugar de hacerl o un conj unt o de ta-
reas de ingeniera del soft ware adapt ado en forma arbitraria.
Coad y sus col egas [COA99] sugieren la si gui ent e plantilla par a definir una caract e-
rstica:
<acci n> el <resul t ado> <porlparaldela> un <objet o>
donde un <objet o> es "una persona, sitio o cosa (incluyendo papeles, moment os en
el t i empo o intervalos de tiempo, o descri pci ones del tipo de cat l ogo de entrada)".
Los ej empl os de las caract er st i cas para una aplicacin de comerci o el ect rni co po-
dran ser:
A gregar el producto a un carrito de supermercado.
Desplegar las especificaciones tcnicas de un producto.
A lmacenar la informacin de navegacin para un cliente.
Un conj unt o de caractersticas agrupa caractersticas rel aci onadas en cat egor as re-
l aci onadas con el negoci o y se define como [COA99]:
<acci n><- ar, - er, - ir> un <objet o>
Por ejemplo: hacer a venta del producto es un conj unt o de caract er st i cas que podra
abarcar las caract er st i cas rel aci onadas con anterioridad y ot ras.
El enfoque del DCC define cinco act i vi dades de "colaboracin" dent ro del mar co
de t rabaj o (en el DCC st as se llaman "procesos") como se muest ra en la figura 4.4.
Desarrollo
conducido por
caractersticas
[COA99]
(usado con
autorizacin).
(ms forma que
contenido)
Una lista de
caractersticas
agrupadas
en conjuntos
y reas
de contenido
Un plan de desarrollo
Propietarios de clase
Propietarios
del conjunto
de caractersticas
Un paquete
de diseo
(secuencias)
Funcin
cliente-valor
completada
TM
PDF Editor
97
El DCC concede una mayor importancia a las directrices y tcnicas de la gestin
del proyecto que muchos otros mt odos giles. Cuando los proyectos crecen en ta-
mao y complejidad, con frecuencia la gestin ad hoc del proyecto es inadecuada.
Resulta esencial para los desarrolladores, sus gerentes y el cliente entender el esta-
tus del proyecto: cules logros se han tenido y cules programas se han encontrado.
Si la presin de la fecha lmite es significativa, resulta crtico determinar si los incre-
ment os de soft ware (caractersticas) estn programados de manera apropiada. Para
lograrlo el DCC define seis punt os de fijacin durante el diseo y la implementacin
de una caracterstica: "ensayo del diseo, diseo, inspeccin del diseo, cdigo, ins-
peccin del cdigo, promocin de la construccin" [COA99].
4.3.7 Modelado g (MA)
En muchas situaciones los ingenieros de software deben construir sistemas grandes y
crticos para los negocios. El mbito y la complejidad de dichos sistemas se deben mo-
delar de forma que 1) todas las circunscripciones entiendan mejor lo que se debe lo-
grar; 2) el problema se divida de manera efectiva entre la gente que lo debe resolver;
y 3) la calidad se evale en cada paso conforme el sistema se desarrolla y construye.
En los ltimos 30 aos se ha propuesto una amplia variedad de mt odos y not a-
cin para el model ado de ingeniera del soft ware en el anlisis y diseo (tanto arqui-
tectnico como al nivel de componentes). Estos mt odos tienen un mrito significa-
tivo, pero se ha comprobado que su aplicacin enfrenta dificultades y es desafiante
poderlos sostener (sobre muchos proyectos). Parte del problema es el "peso" de es-
tos mt odos de modelado. Con esto se hace referencia al volumen de notacin re-
querida, el grado de formalismo sugerido, el t amao de los modelos para proyectos
grandes, y la dificultad para el mant eni mi ent o del model o conforme ocurren los
cambios. Aun as, el model ado del anlisis y el diseo tiene un beneficio sustancial
para los proyectos grandes: por ninguna otra razn que hacer que est os proyectos
sean manej abl es en el sentido intelectual. Existe un enfoque gil para el model ado
de la ingeniera del soft ware que pudiera proporcionar una alternativa?
En el "Sitio oficial del model ado gil", Scott Ambler [AMB02] describe el modela-
do gil (MA) de la siguiente manera:
El model ado gil (MA) es una tecnologa basada en la prctica para el model ado efectivo
de los si st emas basados en soft ware. Dicho de una forma ms simple, el model ado gil es
una coleccin de valores, principios y prct i cas par a el model ado de soft ware que puede
aplicarse en un proyecto de desarrol l o de soft ware de una maner a efectiva y ligera. Los
model os giles son ms efectivos que los tradicionales porque son sl o lo sufi ci ent emen-
t e buenos, no tienen que ser perfect os [AMB02]:
Adems de los valores consistentes con el manifiesto gil, Ambler sugiere valor y hu-
mildad. Un equipo gil debe tener el valor para tomar decisiones que ocasionarn el
rechazo y la refabricacin de un diseo. Debe tener la humildad de reconocer que
qui enes manej an la tecnologa no tienen t odas las respuestas, y que los expertos en
negocios y otros participantes de la empresa son dignos de respeto y consideracin.
TM
PDF Editor
^CONSUO^^.
" V iajar ligero" es un
enfoque apiopiado
paro lodo el trabajo
de ingenier a del
software. Construir
slo aquellos modelos
que proporcionan
valor eni m s, ni
menos
A pesar de que el MA sugiere un arregl o ampl i o de principios de model ado
"esenciales" y "suplementarios", los responsabl es de que el MA sea nico son los si-
gui ent es [AMB02J:
Modelar con un propsito. Un desarrollador que use el MA debe t ener una met a
especfica en ment e (por ej empl o, comuni car informacin al cliente o ayudarle a en-
t ender mej or algn aspect o del software) ant es de crear el model o. Una vez identifi-
cada la met a para el modelo, el tipo de notacin que se usar y el grado de detalle
requerido sern ms obvios.
Usar mltiples modelos. Existen muchos model os y not aci ones diferentes con los
cual es describir el soft ware. Slo un pequeo subconj unt o es esencial para la ma-
yora de los proyectos. El MA sugiere que para proporcionar la visin necesari a ca-
da model o debe present ar un aspect o diferente del si st ema, y slo aquellos mode-
los que proporci onen un valor para la audi enci a a la que est n dirigidos deben
usarse.
V iajar ligero. La realizacin de t rabaj o de la ingeniera del soft ware requiere con-
servar slo los model os que proporci onarn valor a largo pl azo y descart ar el res-
to. Cada product o de t rabaj o que se conserve debe recibir mant eni mi ent o confor-
me se present an cambi os. Esto representa un t rabaj o que reduce la velocidad del
equipo. Ambler [AMB02] observa que "cada vez que se decide conservar un mode-
lo se intercambia la agilidad por la conveni enci a de tener la informacin disponible
para el equi po de una forma abst ract a (por ende, existe una posibilidad de mej orar
la comuni caci n dent ro del equipo, as como con los propietarios del proyecto)".
El contenido es m s importante que la representacin. El model ado debe comuni -
car informacin a la audiencia a la que est dirigido. Un model o si nt ct i cament e
perfecto que comuni que slo un poco del cont eni do til no tiene t ant o valor como
un model o con una notacin defect uosa que, sin embargo, comuni que un conteni-
do valioso para su audi enci a.
Conocer los modelos y las herramientas con que se crean. Es necesari o ent ender
las fort al ezas y debilidades de cada model o y las her r ami ent as con los que se cre.
A daptar en forma local. El enfoque del model ado se debe adapt ar a las necesi da-
des del equi po gil.
Desarrollo gil
Objet ivo: El objetivo de las herramientas del
desarrollo gil es ayudar en uno o ms
aspectos del desarrollo gil con nfasis en la facilitacin
V
de la generacin rpida de software operativo. Estas
herramientas tambin se pueden utilizar cuando se aplican
los modelos prescriptivos de proceso (captulo 3).
Mecnica: La mecnica de las herramientas vara. En general,
los conjuntos de herramientas tcnicas incluyen apoyo
automatizado para la planeacin del proyecto, el desarrollo
/
TM
PDF Editor
s 3e viso y \ a recopilacin de requisitos, e\ diseo
, a generacin de cdigo y la realizacin de pruebas,
os represent at i vas: ' 2
a c l omo el desarrollo gil es un tpico actual, la
*rporia de los vendedores de herramientas de
CI-ore pretenden vender herramientas que apoyen el
s-TDGue gil. Las herramientas que se presentan a
xr r r i ua r i n tienen caractersticas que las hacen tiles
se - a e r a particular par a los proyectos giles.
- eme, desarrollado por Microtool
i microtool.com), proporciona soporte par a la
gestin de un proceso g'A en vanas actividades
tcnicas dentro del proceso.
Ideogramic UML, desarrollado por Ideogramic
(www.ideogramic.com) es un conjunto de herramientas
par a el UML creado en forma especfica par a usarlo
dentro de un proceso gil.
Together Tool Set, distribuido por Borland
(www.borland.com o www.togethersoft.com),
proporciona un paquet e de herramientas que apoya
muchas actividades tcnicas dentro de la PE y otros
procesos giles.
Una filosofa gil para la ingeniera del software se relaciona con cuatro aspectos
clave: la importancia de la organizacin propia de los equipos, los cuales controlan
el t rabaj o que realizan; comunicacin y colaboracin ent re los mi embros del equipo
y entre los profesionales y sus clientes; un reconocimiento de que el cambi o repre-
senta una oportunidad; y un especial cuidado en la entrega rpida del soft ware que
satisfaga al cliente. Los modelos de proceso gil se disearon para cumplir con ca-
da uno de est os aspectos.
La programacin extrema (PE) es el proceso gil que ms se utiliza. Organizada
como cuatro actividades del marco de t rabaj o planeacin, diseo, codificacin y
pruebas, la PE sugiere algunas tcnicas innovadoras y poderosas que permiten a
un equipo gil crear frecuentes l anzami ent os de soft ware al entregar caractersticas
y funcionalidad que describe y despus prioriza el cliente.
El desarrollo de software adaptativo (DSA) destaca la colaboracin humana y la
organizacin propia del equipo. Organizado con tres actividades del marco de tra-
baj o especulacin, colaboracin y aprendizaje, el DSA utiliza un proceso iterati-
vo que incorpora la planeacin del ciclo adaptativo, mt odos de recopilacin de re-
quisitos relativamente rigurosos y un ciclo iterativo de desarrollo que incorpora gru-
pos enfocados en el cliente y revisiones tcnicas formales como mecani smos de re-
troalimentacin en tiempo real. El mt odo de desarrollo de sistemas dinmicos
(MDSD) define tres diferentes ciclos iterativos iteracin funcional del modelo, itera-
cin de diseo y construccin e implementacin precedidos por dos actividades del
ciclo de vida adicionales: estudio de factibilidad y estudio de negocios. El MDSD abo-
12 Las her r ami ent as me nc i ona da s aqu s on sl o una muest r a de esta categora. En casi t odos los
casos los nombr es son mar cas regi st radas de s us respectivos desarrolladores.
TM
PDF Editor
ga por el uso de programas y sugiere que slo se requiere el t rabaj o suficiente para ca-
da incremento de software y as facilitar el movimiento hacia el incremento prximo.
La mel subraya el uso de un conj unt o de pat rones de proceso de soft ware que
han probado su efectividad en proyectos con lmites de t i empo muy aj ust ados, requi-
sitos cambi ant es y que son crticos para el negocio. Cada pat rn de proceso define
un conj unt o de t areas de desarrollo y permite al equipo de mel construir un proce-
so que se adapt e a las necesi dades del proyecto.
Cristal es una familia de model os giles de proceso que pueden adapt arse a las
caractersticas especficas de un proyecto. Como ot ros enf oques giles, cristal adop-
ta una estrategia iterativa, pero se aj ust a al rigor del proceso para incluir proyectos
de t amaos y compl ej i dades diferentes.
El desarrol l o conduci do por caractersticas (DCC) es algo ms "formal" que ot ros
mt odos giles, pero aun as mant i ene la agilidad al enfocar al equipo de proyecto
en el desarrollo de caractersticas, funci ones que eval a el cliente y que se pueden
i mpl ement ar en dos s emanas o menos. El DCC concede una mayor importancia al
proyecto y a su gestin que ot ros enf oques giles. El model ado gil (MA) sugiere que
el model ado es esencial para t odos los si st emas, pero que la complejidad, tipo y ta-
ma o del model o debe aj ust arse al soft ware que ser construido. Mediante la pro-
posicin de una serie de principios de model ado esenci al es y compl ement ari os, el
MA proporciona una gua til para los profesi onal es durant e las t areas de anlisis y
di seo.
[ADM961 Advanced De ve l opme nt Met hods , Inc., "Ori gi ns of Ser um", 1996, ht t p: / / www. c ont r oI -
c h a o s . c o m/ .
(AG103] The Agile Al l i ance Home Page, ht t p: / / www. a gi l e a l l i a nc e . or g/ home .
[AMB02] Ambl er , S " What i s Agile Model i ng (AM)?", 2002, h t t p : / / www. a g i l e mo d e l i n g . c o m/
i ndex. ht m.
[BEC991 Beck, K., Extreme Programming Explained: Embrace Change, Addi son- Wesl ey, 1999.
IBECOla] Beck, K. etal., "Manifest for Agile Soft ware Development", ht t p: / / www. agi l emani f est o. or g/ .
(BECOlb] Beck, K. y M. Fowl er , Planning Extreme Programming, Addi son-Wesl ey, 2001.
[BEE991 Beedl e, M. et al., "SCRUM: An ext ens i n pa t t e r n l a ngua ge for hyper pr oduct i ve s of t wa r e
de ve l opme nt " , i ncl ui do en. Pattern Languages ofProgram Design 4, Addi s on Wesl ey, Long-
ma n , Readi ng, MA, 1999. Obt e ni d o de h t t p : / / j e f f s u t h e r l a n d . c o m/ s c r u m/ s c r u m- p l o p . p d f .
[BUSOO] Bus c hma nn, E etal., Pattern-OrientedSoftwareArchitecture, 2 vol me ne s , Wiley, 1996,
2000.
[COA991 Coad, P, E. Le f e bvr e yJ . DeLuca, lava Modeling in Color with UML, Pr ent i ce- Hal l , 1999.
[COCO 1 ] Cockbur n, A. y j . Hi ghs mi t h, "Agile Sof t wa r e De ve l opme nt : The Pe opl e Fact or ", IEEE
Computer, vol 34, nm. 11, novi e mbr e de 2001, pp. 131-133.
[COC02a] Cockbur n, A., Agile Sojbware Development, Addi son-Wesl ey, 2002.
[COC02bl Cockbur n, A., "What is Agile a nd What Doe s It Imply?", pr e s e nt a d o e n el Agile Deve-
l opme nt Summi t e n We s t mi ns t e r Col l ege e n Sal t Lake City, ma r z o de 2002, ht t p: / / c r y s t a l -
me t hodol ogi e s . or g/ .
[CCS02] CS3 Cons ul t i ng Servi ces, 2002, ht t p: / www. c s 3i nc . c om/ DSDM. ht m.
[DEM981 DeMar co, T. y T. Lister, Peopleware, 2a. ed. , Dorset House, 1998.
[DEM02] DeMar co, T. y B. Boehm, "The Agile Met hods Fray", e n IEEE Computer, vol . 35, nm. 6,
j uni o de 2002, pp. 90- 92.
TM
PDF Editor
101
[FOWOO] Fowl er, M. etal., Refactoring: Improving theDesign o/Existing Code, Addi son-Wesl ey,
2000.
[FOWOl] Fowler M. yj . Highsmith, "The Agile Manifest", Software Development Magazine, agost o
de 2001, ht t p: / / www. s dma ga zi ne . com/ docume nt s / s =844/ s dm0108a . ht m.
[FOW02] Fowl er, M., "The New Met hodol ogy", j uni o de 2002, ht t p: / / www. ma r t i nf owl e r . c om/
art i cl es/ newMet hodol ogy. ht ml #N8B.
[H1G98] Hi ghsmi t h, J., "LifeThe Artificial a nd t he Real", Software Developmcnt, 1998, en
ht t p: / / www. adapt i ves d. com/ ar t i cl es / or der . ht ml .
[H1G00] Hi ghs mi t h, ) . , Adaptive Software Development: An Evolutionaiy Approach lo Managing
Complex Systems, Dorset House Publishing, 1998.
[HIG01] Hi ghsmi t h, ). (ed.), "The Great Met hodol ogi es Debat e: Part 1", Cutter IT Journal, vol. 14.
nm. 12, di ci embre de 2001.
[HIG02a] Highsmith, J. (ed.), "The Great Met hodol ogi es Debat e: Part 2", Cutter IT Journal, vol. 15.
nm. I, ener o de 2002.
[HIG02b] Hi ghsmi t h, )., Agile Software Development Ecosystems, Addi son-Wesl ey, 2002.
[JAC02J Jacobson, I, "A Resoundi ng ' Yes' t o Agile ProcessesBut Also More", Cutter IT Journal,
vol. 15, nm. 1, ener o de 2002, pp. 18-24.
[JEFOI] Jeffries, R, etal., ExtremeProgramming Installed, Addison-Wesley, 2001.
[NOY02] Noyes, B., "Rugby, Anyone?", Managing Development (una publ i caci n en l i nea de
Fawcet t e Techni cal Publications), j uni o de 2002, ht t p: / / www. f a wc e t l e . c om/ r e s our c e s / ma -
nagi ngdev/ met hodol ogi es / s cr um/ .
[PAL02] Pal mer, S. y j . Felsing, A PracticaI Guide to Feature Driven Development, Prent i ce-Hal l ,
2002.
[SCH01] Schwaber , K. y M Beedle, Agile Software Development withSCRUM, Prent i ce-Hal l , 2001.
[SCH02] Schwaber , K, "Agile Pr oces s es and Self Or gani zat i on", Agile Alliance, 2002,
ht t p: / / www. aanpo. or g/ ar t i cl es / i ndex.
[STA971 S t a p l e t o n , DS DMDy n a mi c System Development Method: The Method in Practice, Ad-
dison Wesley, 1997.
[WEL99I Wells, D., "XPUnit Tests", 1999, ht t p: / / www. e xt r e me pr ogr a mmi ng. or g/ r ul e s /
uni t t est s. ht ml .
4.1. Lase de nuevo el "Mani fi est o par a el desar r ol l o gil de s of t war e" al pri nci pi o de es t e ca-
p t ul o. El l ect or pue de pe ns a r en una si t uaci n en la que u n o o m s de l os cuat r o "val or es"
pueda met er a un equi po de s of t war e en probl emas?
4.2. Descri base agilidad (para proyect os de sof t war e) con pal abr as propi as.
4.3. Por qu un pr oces o i t erat i vo facilita m s ma ne j a r el cambi o? Todos l os pr oces os gi l es
t r at ados en est e cap t ul o s on i t erat i vos? Es posi bl e concl ui r un pr oyect o en sl o una i t eraci n
y an as segui r si endo gil? Expl i qense l as respuest as.
4.4. Podra cada uno de los procesos giles describirse recurri endo a las actividades genri cas del
mar co de t rabaj o menci onadas en el captulo 2? Construyase una tabla que col oque las actividades
genri cas dent ro de las actividades definidas para cada proceso gil.
4.5. Tr t ese de i dear un "principio de agi l i dad" adi ci onal que pudi er a ayudar a una equi po de
i ngeni er a del s of t war e a vol verse an m s manej abl e.
4.6. Sel ecci nese un pri nci pi o de agilidad de l os e nunci a dos de la secci n 4.1 y t r t ese de de-
t er mi nar si cada uno de l os model os de pr oces o pr es ent ados en est e cap t ul o muest r an el prin-
cipio.
4.7. Por qu cambi an t ant o l os requi si t os? Despus de t odo, la gent e n o s abe lo que qui ere?
4.8. Cons i dr ens e l os s i et e r as gos e nunc i a dos e n la secci n 4.2.2. Or d ne ns e l os r a s gos con
bas e en su per cepci n des de lo que es m s i mpor t ant e has t a lo que t i ene me nor i mpor t anci a.
4. 9. La mayor a de l os pr oces os gi l es r ecomi endan la comuni caci n car a a car a. Aun en la
act ual i dad, los mi embr os de un equi po de s of t war e y s us cl i ent es pueden est ar geogr f i camen-
TM
PDF Editor
te separados entre s. Esto implica la necesidad de evitar la separacin geogrfica? Es posible
pens ar en formas de contrarrestar este problema?
4. 10. Escrbase una historia del usuario para PE que describa los "sitios favoritos" o la caracters-
tica de "favoritos" disponible en la mayora de los exploradores Web.
4. 11. Qu es una solucin pico en PE?
4 . 1 2 . Descr banse los concept os de PE refabricacin y programacin en pareja con pal abr as
propias.
4 . 1 3 . Utilcese la plantilla del pat rn de proceso pr esent ada en el capitulo 2 y desarrl l ese un
pat r n de pr oces o par a cual qui era de los pat r ones de mel pr es ent ados en la secci n 4.3.4.
4. 14. Por qu se dice que cristal es una familia de mtodos giles?
4 . 1 5 . Utilcese la plantilla de caract er st i ca par a el DCC descri t o en la secci n 4.3.6 y def nase
un conj unt o de caractersticas de un expl orador Web. Ahora desarrl l ese un conj unt o de carac-
tersticas para el conj unt o menci onado ant es.
4 . 1 6 . Vistese el sitio oficial del model ado gil y hgas e una lista compl et a de t odos los princi-
pios de MA esenci al es y compl ement ari os.
O T R A S LECTURAS Y FUENTES DE I N F O R MA C I N
La filosofa total y los principios subyacent es del desarrol l o gil de soft ware se consi deran a
profundi dad en los libros de Ambler (Agile Modeling, Wiley, 2002), Beck [BEC99], Cockburn
[COC02] y Highsmith [HlG02bl.
Los libros de Beck 1BEC99], Jef'fries y sus col egas (Extreme Programming Installed, Addison-
Wesley, 2000), Succi y Marchesi (Extreme Programming Examined, Addison Wesley, 2001), New-
kirk y Martin (Extreme Programming in Practice, Addison Wesley, 2001) y Aver y sus col egas
(.Extreme Programming Applied: Play lo Win, Addison-Wesley, 2001) ofrecen una exposicin de
los pros y cont ras de la PE j unt o con una gua de la mej or forma de aplicarla. McBreen (Ques-
tioning Extreme Programming, Addison Wesley, 2003) as ume una posicin crtica con respecto a
la PE, al definir cundo y dnde sta es apropi ada. Por ot ro lado, McBreen (Pair Programming
Iluminated, Addison-Wesley, 2003) present a una consideracin profunda de la programaci n en
pareja.
Fowler y sus col egas (Refactoring: Improving the Design of Existing Code, Addison-Wesley,
1999) se enfoca en un nivel muy detallado en el i mport ant e concept o de la refabricacin dentro
de la PE. McBreen (Software Craftsmanship: The New Imperative, Addison-Wesley, 2001) analiza
el arl e del soft ware y aboga a favor de las al t ernat i vas giles y la ingeniera de soft ware tradi-
cional.
El DSA lo aborda a profundi dad Highsmith [HIG001. Stapetlon realiz un t rat ami ent o valioso
del MDSD (DSDM: The Method in Practice, Addison-Wesley, 1997). Palmer y Felsing [PAL02]
pr esent an un t rat ami ent o det al l ado del DCC. Carmichael y Haywood (Better Software Faster.
Prentice-Hall, 2002) present an ot ro til t rat ami ent o del DCC que incluye un recuent o paso a pa-
so por la mecni ca del proceso. Schwaber y sus col egas (Agile Software Development with
SCRUM, Prentice-Hall, 2001) pr esent an un detallado t rat ami ent o de la mel .
Martin (Agile Software Development, Prentice-Hall, 2003) anal i za los principios, pat rones y
prcticas giles poni endo especial cui dado en la PE. Poppendi eck y Poppendieck (Lean Deve-
lopment; An Agile Toolkit for Software Development Managers, Addison-Wesley, 2003) proporcio-
na las directrices para manej ar y cont rol ar los proyect os giles. Highsmith (Agile Software
Development Ecosyslems, Addison-Wesley, 2002) present a una valiosa visin de principios, pro-
cesos y prct i cas giles. .
En Internet se di spone de una ampl i a vari edad de fuent es de i nformaci n sobre el desarro-
llo gil de soft ware. En el sitio web de SEPA se puede encont rar una lista act ual i zada de refe-
renci as en la red mundial, las cual es son rel evant es par a el pr oceso gil:
TM
PDF Editor
P A R T E
Dos
PRCTI CA DE LA I NGENI ER A
DEL SOFTWARE
E
n esta part e de Ingeniera del software: un enfoque prctico se apren-
der acerca de los principios, concept os y mt odos que compr ende la
prctica de la ingeniera del soft ware. En los captulos siguientes se
abordarn las siguientes preguntas:
Qu concept os y principios guan la prctica de la ingeniera del soft-
ware? ; | wf c ^ P
De qu maner a la ingeniera de si st emas conduce a una ingeniera del
soft ware efectiva?
Qu es la ingeniera de requisitos, y cul es son los concept os rela-
ci onados que conducen a un buen anlisis de requisitos?
Cmo se crea el model o de anlisis y cul es son sus el ement os?
Qu es ingeniera de diseo y cul es son los concept os rel aci onados
que conducen a un buen diseo?
Qu conceptos, model os y mt odos se utilizan para crear diseos ar-
quitectnicos, de interfaz y al nivel de component es?
Qu est rat egi as son aplicables a la realizacin de pr uebas de soft ware?
Qu mt odos se utilizan para di sear casos de prueba efectivos?
Qu medi ci ones y mt ri cas s e usan para est abl ecer la calidad del anli-
sis y los model os de diseo, cdigo fuent e y casos de prueba?
Una vez que est as pregunt as hayan sido respondidas, habr una mej or
preparacin para la prctica de la ingeniera del soft ware.
103
TM
PDF Editor
C A P T U L O
5
LA PRCTI CA:
UNA VI SI N GENRI CA
C O N C E P T O S
CLAVE
pri nci pi os de:
el anl i s i s . . . 1 1 7
el des pl i egue 1 2 6
el di s ea . . . 1 1 9
el mode l a da
gH 121
la codi fi caci n 1 2 3
l a comuni ca-
cin 1 0 9
l a i ngeni er a
del s o f t wa r e 1 0 7
la pl aneaci n 1 1 3
las pruebas .124
pr e gunt a s
WS HH 1 1 5
r esol uci n d e
pr obl e ma s 1 0 6
E
n un libro que explora las vidas y los pensami ent os de los i ngeni eros de
soft ware, Ellen Ullman [ULL97] represent a un f r agment o de vida al relatar
los pensami ent os de un pract i cant e baj o presi n:
No t e ngo i dea de qu hor a es. No hay ve nt a na s en est a ofi ci na, t ampoco reloj, s l o el
LHD pa r pa d e a nt e e n roj o de un hor no de mi cr oonda s , el cual pa r pa de a 12:00, 12:00,
12:00, 12:00. Joel y y o h e mo s e s t a do pr ogr a ma nd o por d as. Te ne mos un "bi cho", el
ne c i o de moni o de u n error. Por e s o la pul s aci n r oj a si n t i empo s e si ent e bi en, c o mo
u n a l ect ura de nue s t r os cer ebr os , l os c ua l e s s e h a n s i ncr oni zado de al guna ma n e r a
a la mi s ma vel oci dad del par padeo. . .
En q u e s t a mo s t r abaj ando?. . . Los det al l es s e me e s c a pa n a hor a . Podr a mos es t ar
a y u d a n d o a ge nt e pobr e y e nf e r ma o a j us f a ndo una seri e de r ut i nas de ba j o ni vel par a
veri fi car bi t s en un pr ot ocol o de una ba s e de da t os di st ri bui da, n o me i mpor t a. Me de-
ber a i mpor t ar ; e n ot r a par t e de m s er m s t ar de, qui z c ua nd o s a l ga mos de es t e-
cuar t o l l eno de c omput a dor a s me i mpor t ar mu c h o por qu, p a r a qui n y con qu
pr ops i t o es t oy es cr i bi endo s of t wa r e . Per o a hor a no. He p a s a d o a t r avs de una
me mb r a n a donde el mu n d o real y s us us os ya n o i mpor t an. Soy un i ngeni er o de s of t -
war e. . .
Sin duda, una i magen oscura de la prctica de la ingeniera del soft ware, per o
con la que, despus de reflexionar, muchos de los lectores de est e libro sern
capaces de identificarse.
Qu e s ? La prctica es un amplio
arreglo de conceptos, principios,
mtodos y herramientas que deben
p considerarse cuando se planea y
desarrolla el software. Representa los
detalles -l as consideraciones tcnicas y los
cmos- que estn bajo la superficie del proceso
de software: las cosas que se necesitarn para
realmente construir software de computadora de
alfa calidad.
Qui n l o h a c e ? La prctica de la ingeniera del
software la aplican los ingenieros de software y
sus gerentes.
Por q u e s i mp o r t a n t e ? El proceso del soft-
ware proporciona a todos los involucrados en la
creacin de un sistema o producto basado en
computadora un mapa del camino para llegar
de manera exitosa a su destino. La prctica pro-
porciona los detalles que se necesitan para tran-
sitar a lo largo del camino. Indica dnde estn
ubicados los puentes, los bloqueos del camino y
los obstculos. Ayuda a entender los conceptos
y principios que se deben comprender y seguir
para conducir de manera segura y rpida.
Ensea cmo conducir, dnde reducir y dnde
aumentar la velocidad. En el contexto de la inge-
niera del software, la prctica es lo que se rea-
liza a diario mientras el software evoluciona
desde una idea hasta una realidad,
Cu l e s s on l os p a s o s ? Existen tres elementos
de la prctica que se aplican sin importar el
modelo de proceso que se escoja. stos son los
104
TM
PDF Editor
CAPTULO 5 LA PRCTI CA: UNA VISIN GENRI CA
105
^CDKCptos, los principios y los mtodos. Un cuar-
to elemento de la prctica -l as herramientas-
apoya la aplicacin de los mtodos.
e s el pr od uc t o o b t e n i d o ? La prctica
- : .ye ias actividades tcnicas que producen
- o ; = os productos de trabajo definidos por el
ci t o de proceso del software que se ha elegi-
puedo estar seguro de que lo he
kecho c o r r e c t a me n t e ? Primero se
comprender con firmeza los conceptos y princi-
pios aplicables al trabajo que se realiza en el
momento (por ejemplo, el diseo). Despus es
preciso asegurarse que se ha seleccionado un
mtodo apropiado para el trabajo; se debe
tener la certeza que se ha entendido la forma de
aplicar el mtodo y el uso de las herramientas
automatizadas cuando stas son apropiadas
para la tarea, y se debe ser firme en la necesi-
dad de usar tcnicas para asegurar la calidad
de los productos de trabajo que se produzcan.
Las per sonas que crean sof t war e de comput ador a pract i can el arte, la maest r a o
la disciplina1 l l amada ingeniera del soft ware. Pero, qu es la "prctica" de la inge-
niera del soft ware? En un sent i do genrico, la prctica es una coleccin de concep-
tos, principios, mt odos y her r ami ent as a las que un i ngeni ero de sof t war e recurre a
diario. La prctica permi t e a los ger ent es coordinar proyect os de sof t war e e ingenie-
ros de la especialidad para construir pr ogr amas de comput ador a. La prctica multi-
plica un model o de proceso de sof t war e con los cmos t cni cos y de gestin nece-
sari os para realizar el t rabaj o. La prctica t ransforma un enf oque fortuito en al go
ms organi zado, m s efect i vo y con ms probabi l i dades de al canzar el xito.
5 . 1 L A P R C T I C A P E LA I N GE N I E R A P E L S OF T WAR E
En el captulo 2 se introdujo un model o de proceso de sof t war e genri co compues-
t o de una serie de act i vi dades que est abl ecen un mar co de t rabaj o para la prctica
de la ingeniera del soft ware. Las actividades genri cas del marco de t rabaj o comu
nicacin, pl aneaci n, model ado, const rucci n y despl i eguey las act i vi dades som-
brilla est abl ecen la arqui t ect ura de una esquel et o para el t rabaj o de ingeniera del
soft ware. Todos los model os de proceso de sof t war e pr esent ados en los cap t ul os 3
y 4 pueden organi zarse en est e esquel et o arquitectnico. Pero qu cabida tiene ah
la prctica de la ingeniera del software? En las secci ones si gui ent es se consi derarn
los concept os y principios genri cos que se aplican a las act i vi dades del mar co de
trabajo. 2
1 Algunos escritores utilizan uno de estos trminos y excluyen los otros. En realidad, la ingeniera del
software es las tres cosas a la vez.
2 Se exhorta al lector para que revise las secciones relevantes dentro de este captulo, conforme se
discutan los mtodos especficos de la ingeniera del software y las actividades sombrilla en los ca-
ptulos posteriores del libro
TM
PDF Editor
106 PARTE DOS PRCTICA DE LA INGENIERA DEL SOFTWARE
^ O N S E J O ^
Se podra orgumentar
que el enfoque de
Polya consiste en
simple sentido com n.
Es verdad. Peio es
sorprendente la
frecuencia con ta que
el sentido com n no
es com n en el
mundo del software.
5.1.1 La esenci a de la prctica
En un libro clsico, How to Solve It, escrito ant es de que existieran las comput adoras
modernas, George Polya [POL45] puntualiz la esencia de la resolucin de proble-
mas y, en consecuencia, la esencia de la prctica de la ingeniera del software:
1. Entender el problema (comunicacin y anlisis).
2. Planear una solucin (modelado y diseo de software).
3. Llevar a cabo el plan (generacin de cdigo).
4. Examinar el resultado para probar la precisin (realizacin de pruebas y asegu-
ramiento de la calidad).
En el contexto de la ingeniera del soft ware est os pasos de sentido comn conducen
a una serie de preguntas esenciales [adaptadas de POL45):
Ent e nde r el pr obl e ma .
A quin le interesa la solucin del problema? Es decir, quines son los clientes?
Cules aspectos se desconocen? Qu datos, funciones, caractersticas y
comport ami ent os se requieren para resolver de manera apropiada el
problema?
El problema puede dividirse en categoras? Es posible representar probl emas
menores que puedan entenderse con mayor facilidad?
El problema puede representarse de manera grfica? Se puede crear un
modelo de anlisis?
Pl anear l a s ol uci n.
Se haban visto problemas similares antes? Existen pat rones reconocibles en
una solucin potencial? Hay un soft ware existente que implemente los datos,
las funciones, las caractersticas y los comport ami ent os que se requieren?
Se ha resuelto un problema similar? Si es as, los el ement os de la solucin
pueden reutilizarse?
Sepueden definirlos subproblemas? Si es as, las soluciones para los subpro-
bl emas parecen fciles?
Se puede representar una solucin de modo que conduzca a una implementa-
cin efectiva? Se puede crear un modelo de diseo?
Ll evar a c a bo el pl an.
La solucin marcha conforme al plan? El cdigo fuente se puede seguir
conforme al model o de diseo?
Es probable que cada parte de la solucin del componente sea correcta? Se ha
revisado el diseo y el cdigo, o mejor an, se han aplicado al algoritmo
pruebas de correccin?
TM
PDF Editor
CAPTULO 5 LA PRCTICA: UNA VISIN GENRICA
107
Exa mi na r el r e s ul t a d o.
Es posible probar cada parte de la solucin del componente? Se ha i mpl emen-
t ado una est rat egi a de prueba razonabl e?
La solucin produce resultados acordes con los datos, funciones, rasgos y
comportamientos que se requieren? El sof t war e ha sido val i dado contra t odos
los requisitos de los clientes?
"En la solucin de codn problema existe un grano de descubrimiento."
George Polya
i m amenzat un
i software,
i e s a seguro
tun
d e negocios
o s usuarios
i abren /.
5.1.2 Principios esenci al es
El diccionario define la pal abra principio como "una ley o supuest o i mport ant e que
se requi ere en un si st ema de pensami ent o". A t ravs de est e libro se exami nan prin-
cipios en muchos grados di ferent es de abst racci n. Algunos se enf ocan en la inge-
niera del soft ware como un t odo, ot ros consi deran una actividad genri ca y espec-
fica del mar co de t rabaj o (por ejemplo, comuni caci n con el cliente), y ot ros se cen-
tran en acci ones de la ingeniera del sof t war e (como di seo arquitectnico) o t ar eas
t cni cas (escribir un escenari o de uso). Sin i mport ar qu t an especficos son, los
principios ayudan a est abl ecer un conj unt o slido de prctica de ingeniera del soft -
ware. Por esa razn son i mport ant es.
David Hooker [H0096] ha propuest o siete principios esenciales, los cual es se
enf ocan en la prctica de la ingeniera del sof t war e como un todo, que se reprodu-
cen ensegui da. 3
El p r i me r pr i nci pi o: la razn por la que todo existe
Un si st ema de sof t war e existe por una razn: para ofrecer un valor a sus usuarios.
Todas las deci si ones deben t omar se con est o en ment e. Antes de especificar un
requisito de un si st ema, ant es de seal ar una pi eza de funci onal i dad del si st ema,
ant es de det ermi nar las pl at af or mas del har dwar e o los procesos de desarrollo, uno
debe hacerse pregunt as como: esto agrega un val or real al si st ema? Si la respuest a
es negat i va no s e debe hacer. Todos los dems principios est n apoyados en ste.
El s e g u n d o pr i nci pi o: MS (mantenerlo simple)
El di seo de sof t war e no es un proceso fortuito. Existen muchos fact ores que deben
consi derarse en cualquier esf uer zo de diseo. Todo el diseo debe ser tan simple como
sea posible, pero no ms simple. Esto facilita un si st ema de m s fcil comprensi n y
ent endi mi ent o. Esto no qui ere decir que las caractersticas, hast a las i nt ernas, deban
descart arse en nombr e de la simplicidad. Adems, los di seos ms el egant es por lo
general son los m s simples. Simple t ampoco significa "rpido y malo". De hecho, se
3 Reproducido con permi so del autor [H00961. Hooker defi ne pat rones para est os principios en:
ht t p: / / c2. com/ cgi / wi ki 7SevenPri nci pl esOfSoft wareDevel opment
TM
PDF Editor
requi ere de mucha reflexin y t rabaj o sobre mltiples i t eraci ones para simplificar. El
resul t ado buscado es un sof t war e que se mant enga y sea menos pr openso al error.
' Existe cierta majestuosidad en la simplicidad, la cual est muy por encima de la curiosidad del ingenio."
Al e xa nde r Pope ( 1 6 8 8 - 1 7 4 4 )
\
CLAVE
Si el s of t war e t i ene un
valor, act o cambi ar a
lo l ar go de s u vi da til.
Por esa r azn, el
s of t war e debe
const rui rse d e t or mo
que s e le puedo dor
mant eni mi ent o.
El t e r c e r pr i nci pi o: mantener a visin
Una visin clara es esencial para el xito de un proyecto de software. Sin la visin clara
el proyect o podra t ermi nar con "dos [o ms] significados" en uno. Sin una integri-
dad concept ual un si st ema amenaza con t ornarse en una masa confusa de di seos
incompatibles, uni da por un tipo i nadecuado de tornillos...
Arriesgar la visin arqui t ect ni ca de un si st ema de sof t war e debilita y al final
r ompe hast a un si st ema bien di seado. Tener a un arqui t ect o capaz de mant ener la
visin y reforzar lo acordado ayuda al asegur ami ent o de que un proyect o de soft -
war e sea exitoso.
El c u a r t o pr i nci pi o: lo que uno produzca, otros lo consumirn
En muy pocas ocasi ones un si st ema de sof t war e con fuerza industrial se const ruye
y utiliza de maner a aislada. De al guna u otra forma, alguien m s utilizar, mant en-
dr, document ar o depender de su capaci dad de ent ender el si st ema. Por lo tanto,
si empre debe especificarse, di searse e i mpl ement arse con la idea de que alguien
ms t endr que ent ender lo que se realice. La audi enci a de cualquier product o de
soft ware es pot enci al ment e grande, por lo que se debe especificar t omando en cuen-
ta a los usuarios. Se debe di sear t eni endo en ment e a qui enes lo i mpl ement en, as
como codificar consi der ando a aquel l os que deben mant ener y ext ender el si st ema.
Tal vez alguien t enga que depurar el cdi go escrito y eso lo convertir en un usua-
rio del cdigo. El hecho de facilitar el t rabaj o a ot ro agrega valor al si st ema.
El qui nt o pr i nci pi o: estar abierto al futuro
Un si st ema con una larga vida tiene m s valor. En los ambi ent es comput aci onal es
de la actualidad, en los que las especi fi caci ones cambi an a cada moment o y las pla-
t aformas de har dwar e son obsol et as despus de al gunos meses, la vida del sof t wa-
re se mide, de modo tpico, en mes es en lugar de aos. No obst ant e, los verdaderos
si st emas de soft ware "con fuerza industrial" deben durar ms tiempo. Estos si st emas
t endr n xito si est n listos para adapt arse a st os y otros cambi os. Los si st emas que
logran el xito son aquel l os que han sido di seados de est a maner a desde el princi-
pio. Nunca se debe disear para llegar a una esquina. Uno si empre se debe preguntar:
"qu tal si?", y prepararse para t odas las r espuest as posibles, al crear si st emas que
resuel van el probl ema general, no un probl ema especfico.4 Es muy probabl e que
est o conduzca a la reutilizacin de un si st ema ent ero.
4 Nota del autor: esta recomendacin puede ser peligrosa si se lleva hasta el extremo. El diseo para
el "problema general'' algunas veces requiere compromisos de desempeo y puede implicar un ma-
yor esfuerzo para el proyecto.
TM
PDF Editor
CAPTULO 5 LA PRCTI CA UNA VISIN GENRICA 109
El s e xt o pri nci pi o: planear para la reutilizacin
La reutilizacin ahorra tiempo y esfuerzo. 5 Al alcanzar un alto grado de reutilizacin
se logra una de las met as ms difciles en el desarrollo de un sistema de software.
La reutilizacin de cdigo y diseos ha sido proclamada como un beneficio impor-
tante del uso de tecnologas orientadas a objetos. Sin embargo, la recuperacin de
la inversin no es automtica. Las posibilidades de reutilizacin que proporciona la
programacin orientada a objetos (o convencional) se podrn considerar si se tiene
una visin a futuro y una planeacin. Existen muchas tcnicas para llevar a cabo la
reutilizacin en cada etapa del proceso de desarrollo del sistema; las relativas al
diseo detallado y al nivel de cdigo son muy conocidas y estn bien document adas.
La nueva bibliografa se est enfocando en la reutilizacin del diseo en la forma de
pat rones de software. Sin embargo, esto es slo una part e de la batalla.
La comunicacin de oportunidades para la reutilizacin a otros integrantes de la
organizacin es primordial. Cmo se puede reutilizar algo cuya existencia se ignora?
La planeacin adelantada para la reutilizacin reduce el costo e incrementa el valor de los
componentes reutilizablesy los sistemas en que dichos componentes se incorporan.
El s pt i mo pr i nci pi o: pensar
Este ltimo principio tal vez sea el que ms se pasa por alto. Casi siempre, cuando se
tiene un pensamiento claro y completo antes de la accin, se producen los mejores resul-
tados. Cuando se reflexiona acerca de algo existe una mayor probabilidad de hacer-
lo bien. Siempre se obtiene conocimiento de la manera de hacerlo bien de nuevo. Si
se piensa en algo y aun as se hace mal, esto se convierte en una experiencia valio-
sa. Un efecto colateral del pensami ent o es aprender a reconucer, cuando alguien no
sabe algo, en qu punt o se puede investigar la respuesta. Cuando el pensami ent o
claro se ha introducido en el sistema es cuando surge su valor real. La aplicacin de
los primeros seis principios requiere una reflexin intensa, por lo que las r ecompen-
sas potenciales son enormes.
Si t odos los ingenieros de soft ware y todos los equipos de desarrollo tan slo
siguieran los siete principios de Hooker, muchas de las dificultades que se han expe
rimentado durante la construccin de sistemas complejos basados en computadora
se podran eliminar.
Antes de que los requisitos del cliente puedan analizarse, modelarse o especificarse,
stos deben recopilarse por medi o de una actividad de comunicacin (tambin lla-
mada obtencin de requisitos). Un cliente tiene un problema que se puede ajustar a
Nota del autor: aunque esto es cierto para quienes reutilizan el software en proyectos futuros, la reu-
tilizacin puede resultar cara para quienes deben disear y construir componentes reutilizables. Al-
gunos estudios indican que el diseo y la construccin de componentes reutilizables pueden costar
entre 25 y 200 por ciento ms que el software solicitado En algunos casos, la diferencia de costo no
se puede justificar.
TM
PDF Editor
^ ^ ONSEJ O^ ^ -
Antes de comunicar se
debe estar seguro de
entender el punto de
vista de lo olio paite,
saber un poco (le sus
necesidades, y
entonces opinar.
una solucin basada en comput ador a. Un desarrollador responde a la solicitud c J
ayuda del cliente. La comuni caci n ha comenzado. Pero el cami no desde la c o mu l
nicacin hast a el ent endi mi ent o suele est ar lleno de baches.
La comunicacin efectiva (entre pares tcnicos, con el cliente u otros part i ci pant es
del software y con los gerent es de proyecto) est entre las actividades ms desafiantes!
que enfrent a un ingeniero de software. En este cont ext o se exami nan los principio* I
concept os de comunicacin de acuerdo con la manera en que se aplican en la c o ma l
nicacin con el cliente. Sin embargo, muchos de los principios se aplican del mi s j n J
modo a las formas de comunicacin que ocurren dent ro de un proyecto de software I
Pr i nci pi o #1: Escuchar. Se debe cent rar la at enci n en las pal abras de qui e - |
habla, en vez de formul ar la respuest a a di chas pal abras. Es necesari o pedir u r J
explicacin si al go no est claro, per o deben evitarse las i nt errupci ones const ant es J
Nunca se debe ser conflictivo con pal abras o actitudes (por ejemplo, dirigir la mi r i - l
da a los lados o sacudi r la cabeza) cuando una persona habla.
Pr i nci pi o #2: Prepararse antes de comunicar. Se debe invertir al gn tiemp J
en ent ender el probl ema ant es de reuni rse con otros. Si es necesari o, se puede r e a J
lizar una investigacin para ent ender el negoci o y domi nar la jerga. Si se tiene la re~-l
ponsabi l i dad de conduci r la reunin, es r ecomendabl e preparar una agenda del d J
ant es de la junta.
Pr i nci pi o #3: Alguien debe facilitar la actividad. Cualquier reuni n de corr. --|
nicacin debe t ener un lder o medi ador 1) para mant ener una conversaci n di ns-i
mica y en una direccin productiva; 2) para medi ar en cualquier conflicto que oca- I
rra; 3) para asegur ar que se sigan los ot ros principios.
Pr i nci pi o #4: La comunicacin cara a cara es 1o mejor. Pero, por lo general,
funci ona mej or cuando est present e otra represent aci n de la i nformaci n relevan-
te. Por ejemplo, un participante podra crear un esquema o un document o que sirva
como foco de la discusin.
"Los preguntas y las respuestas llanas forman el comino ms corto hacia la mayora de las perplejidades."
Mor k Twal n
Pr i nci pi o #5: Tomar notas y documentar las decisiones. Las cosas suel en
caer en mal ent endi dos. Alguien que participe en la comuni caci n debe servir como
"grabadora" y escribir t odos los punt os y deci si ones i mport ant es.
Pr i nci pi o #6: Buscar la colaboracin. La col aboraci n y el consenso se pre-
sent an cuando el conoci mi ent o colectivo de los mi embros del equi po se combi na
para describir las funci ones o caractersticas del product o o si st ema. Cada pequea
col aboraci n sirve para construir confi anza ent re los mi embros del equi po y crear
una met a comn par a dicho equipo.
Pr i nci pi o #7: Conservar el enfoque, examinar un mdulo a la vez. Entre
ms gent e est implicada en una comuni caci n, ms posibilidades existen de que la
TM
PDF Editor
CAPTULO 5 LA PRCTI CA: UNA VISIN GENRICA
111
discusin salte de un tpico al siguiente. El medi ador debe mant ener la conversaci n
cent rada en un mdul o sin dejar un t ema hast a que ste haya sido resuelto (sin
embargo, vase el principio #9).
INFORMACIN
La d i fe re nci a e ntre cli e nte s y us ua ri o s ta le s
Los ingenieros de software se comunican con
muchos participantes diferentes, pero los clientes
finales tienen el impacto ms significativo
el t rabaj o tcnico que sigue. En al gunos casos el
v el usuario son uno mismo, pero en muchos
el cliente y el usuario final son personas
, que t rabaj an par a diferentes administradores en
organi zaci ones de negocios.
es la persona o gr upo que: 1) en un inicio
el software que se va a construir; 2) define los
generales de negocios par a el software; 3)
proporciona los requisitos bsicos del producto; 4)
coordina los recursos econmicos par a el proyecto. En un
negocio de productos o sistemas, con frecuencia el cliente
es el depart ament o de mercadotecnia. En un ambiente de
TI el cliente puede ser un componente o depart ament o del
negocio.
Un usuario final es la persona o grupo que: 1) en realidad
usar el software que se construye par a al canzar algn
propsito de negocios, y 2) definir los detalles operativos
del software de forma que el propsito del negocio pueda
al canzarse.
mi pasa si
i s e p e d e
i m arreglo
le en
con el
Pr i nci pi o #8: Si algo no est claro, se hace un dibujo. La comunicacin ver-
bal slo llega hast a cierto punto. Con frecuencia un esquema o figura puede propor-
cionar claridad cuando las pal abras fallan al realizar su trabajo.
Pr i nci pi o #9: a) Una vez que se llega a un acuerdo sobre algo, se debe con-
tinuar; b) si no se puede llegar a un acuerdo, se debe continuar; c) si una
caracterstica o Juncin no est clara y no se puede clarificar en el momento,
se debe continuar. La comuni caci n, como cualquier actividad de ingeniera del
soft ware, requiere de tiempo. En lugar de que se itere sin fin, los participantes deben
reconocer que hay muchos tpicos que requi eren anlisis (vase el principio #2) y
que "continuar" al gunas veces es la mej or forma agilitar la comuni caci n.
Pr i nci pi o #10: La negociacin no es un concurso o un juego. Funciona
mejor cuando ambas partes ganan. En muchas ocasi ones los ingenieros de soft
war e y el cliente deben negociar funci ones y caractersticas, prioridades y fechas de
entrega. Si el equipo ha colaborado de buena forma, t odas las part es tienen una met a
comn. Por lo tanto, la negociacin demandar el compromi so de t odas las partes.
HOGARSEGURO
A Erro re s d e co muni ca ci n
Ej j El e s c e n a r i o : Lugar de t r abaj o
de ingeniera del software.
a c t o r e s : Jamie Lazar, miembro del equi po de
Vinod Raman, miembro del equi po de
Ed Robbins, miembro del equi po de software.
La c o nv e r s a c i n:
E d: Qu han o do acerca de este proyecto de
HogarSeguro?
Vi no d: La reunin de inicio est pr ogr amada par a la
prxima semana.
TM
PDF Editor
112 P A R T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
Jami e: Yo ya he investigado un poco, pero no me fue
bien.
E d: Qu quieres decir?
J a mi e : Bueno, le hice una llamada a Usa Prez, la
responsable de mercadotecnia en este asunto.
Vi no d: Y...?
J a mi e : Yo quer a que me dijera al go sobre las
caractersticas y funciones de HogarSeguro... ese tipo de
cosas. En lugar de eso, comenz a hacerme preguntas
sobre seguridad de sistemas, vigilancia de sistemas... no
soy una experta.
Vi no d: Qu te dice eso?
(Jamie se encoge de hombros.)
Vi no d: Que mercadotecnia nos necesitar par a que
actuemos como consultores y que ser mejor que
hagamos al go de t area en esta r ea del producto ant es
de la reunin de inicio. Doug dijo que quer a que
"col aborramos" con nuestro cliente, as que ser mejor
que apr endamos cmo hacerlo.
E d: Probablemente sera mejor que furamos a su
oficina. Las llamadas telefnicas no funcionan par a este
tipo de asuntos.
J a mi e : Ambos estn en lo correcto. Debemos act uar
untos o nuestras primeras comunicaciones sern un lo.
Vi no d: Vi que Doug lea un libro sobre "ingeniera de
requisitos". Podra apost ar que ah se enlistan algunos
principios par a la buena comunicacin. Se lo voy a pedir
prestado maana.
Ja mi e : Buena i dea. . . despus nos puedes ensear.
Vi no d ( s onr i e ndo) : S, claro.
CONJ UNTO DE TAREAS
Co njunto d e ta re a s ge nri ca s pa ra la co muni ca ci n
Salidas y ent radas resultantes.
%
3.
5.
1. Identificar al cliente primario y otros
participantes (seccin 7. 3. 1).
2. Reunirse con el cliente primario par a
las "preguntas libres de contexto" (seccin 7. 3. 4), las
cuales definen:
Las necesi dades y valores del negocio.
Las caractersticas y necesi dades del usuario final.
Las salidas visibles que se hayan requerido par a
el usuario.
Las restricciones del negocio.
Desarrollar un enunciado escrito de una pgi na
sobre el mbito del proyecto, el cual est sujeto a
revisin.
Revisar el enunci ado del mbito con los interesados
en el software y ajusfarlo segn lo requerido.
Col aborar con el cliente y el usuario final par a
definir:
Escenarios de uso visibles par a el cliente con el
uso del formato est ndar6 (seccin 7.5).
Caractersticas, funciones y comportamientos
importantes del software.
Riesgos de negocios definidos por el cliente
(seccin 25. 3).
. Desarrollar una breve descripcin escrita (por
ejemplo, una serie de listas) de escenarios,
sal i das/ ent radas, caractersticas/funciones y riesgos.
7. Iterar con el cliente par a refinar los escenarios,
sal i das/ ent radas, caractersticas/funciones y riesgos.
8. Asignar prioridades definidas por el cliente a cada
escenario del usuario, caracterstica, funcin y
comportamiento (seccin 7. 4. 2).
9. Revisar toda la informacin recopilada durant e la
actividad de comunicacin con el cliente y otros
participantes, y aj ust ar a de la forma que se
requiera.
10. Prepararse par a la actividad de planeacin
(captulos 23 y 24).
6 Los f or mat os para escenari os de uso se di scut en e n el cap t ul o 8.
TM
PDF Editor
CAPTULO 5 LA PRCTICA UNA VISIN GENRICA
113
5 , 3 P R C T I C AS PE LA P L ANE ACI N
La actividad de comuni caci n ayuda al equi po de sof t war e a definir sus met as y obj e-
tivos general es (por supuest o, suj et o al cambi o conf or me pasa el tiempo). Sin
embar go, ent ender est as met as y objetivos no es lo mi s mo que definir un plan para
llegar a ellos. La actividad de planeacin abarca un conj unt o de prct i cas t cni cas y
de gest i n que permi t en al equi po de sof t war e definir un mapa del cami no mi ent ras
se viaja a t ravs de su met a estratgica y objetivos tcticos.
"En la preparacin poro la batalla siempre he encont rado que los pl anes son intiles, pero que la planeacin es
indispensable.'
Dwi ghf D. Ei s e n h o we r
Existen muchos enf oques di ferent es para la pl aneaci n. Algunas per sonas son
"minimalistas", y ar gument an que el cambi o con frecuenci a obvia la necesi dad de un
plan detallado. Otros son tradicionalistas, y dicen que el plan proporci ona un mapa
efectivo del cami no, y mi ent ras m s det al l ado sea ste, menor probabilidad habr de
que el equi po pierda el rumbo. Adems, ot ros son "agistas" y ar gument an que tal
vez un "juego de pl aneaci n" rpido sea necesario, per o que el mapa del cami no sur-
gir cuando comi ence el "t rabaj o real" sobre el soft ware.
Qu hacer? En muchos proyect os la sobrepl aneaci n consume t i empo y no pro-
duce frut os (demasi adas cosas cambian), per o la pl aneaci n insuficiente es una
receta para el caos. Como la mayor a de las cosas en la vida, la pl aneaci n se debe
producir con moderaci n, lo suficiente par a proporci onar una gua til para el equi
po no ms, no menos.
Sin i mport ar el rigor con el que se conduzca la pl aneaci n, los si gui ent es princi-
pios son vlidos en t odo moment o.
Pr i nci pi o #1: Entender los alcances del proyecto. Es imposible utilizar un
mapa de carret eras si no se sabe el sitio a donde se qui ere ir. El hecho de ent ender
los al cances proporci ona al equi po de sof t war e un dest i no.
Pr i nci pi o #2: Involucrar al cliente en la actividad de planeacin. El cliente
defi ne prioridades y est abl ece las rest ri cci ones del proyecto. El aj ust e de est as reali
dades a menudo requiere que los i ngeni eros de soft ware negoci en las r denes de
ent rega, los lmites de t i empo y ot ros asunt os rel aci onados con el proyecto.
Pr i nci pi o #3: Reconocer que la planeacin es iterativa. El plan de un pro-
yecto nunca se graba en una piedra. En cuant o comi ence el t rabaj o es muy probable
que las cosas cambi en. En consecuenci a, debe aj ust ar se el plan para adapt arl o a los
cambi os. Adems, los model os iterativos e i ncremnt al es del proceso dictan la repla-
neaci n (despus de la ent rega de cada i ncrement o de software) basada en la retroa-
limentacin recibida de los usuarios.
oceica
'1
v " o / e t o s .
TM
PDF Editor
114
PARTE DOS PRCTICA DE LA INGENIERA DEL SOFTWARE
Pr i nci pi o #4: Estimar con base en el conocimiento disponible. La finalidad
de la est i maci n es proporci onar un indicio del esfuerzo, cost o y duracin de las
t areas, con base en el conoci mi ent o que el equi po tiene del t rabaj o que s e va a rea-
lizar. Si la i nformaci n es vaga o poco confiable, las est i maci ones t endrn, de igual
forma, poca confiabilidad.
Pr i nci pi o #5: Considerar el riesgo cuando se define el plan. Si el equi po ha
definido riesgos que t i enen un alto i mpact o y una alta probabilidad, es necesari o un
plan de cont i ngenci a. Adems, el plan de proyect o (que incluye el calendario) se
debe aj ust ar para incluir la posibilidad de que uno o m s de est os riesgos se torne
un probl ema real.
Pr i nci pi o #6: Ser realista. Las per sonas no t rabaj an el 100 por ci ent o de cada
da. El ruido si empre ent ra en cualquier comuni caci n humana. Las omi si ones y la
ambi gedad son hechos de la vida. Los cambi os ocurrirn. Hasta los mej or es inge-
ni eros de soft ware comet en errores. stas y ot ras real i dades deben consi derarse
mi ent ras se est abl ece el plan del proyecto.
"0 xito est ms en funcin del sentido comn consistente que del genio."
An Wo n g
\
CLAVE
El trmino granuloridod
se refiere ol detalle con
el que al gunos
el ement os de lo
pl aneaci n se
representan o dirigen.
Pri nci pi o #7: Ajustar la granularidad mientras se define el plan. La granu-
laridad s e refiere al grado de detalle que se i nt roduce conf or me se desarrolla el plan.
Una "granularidad fina" en el plan proporci ona detalles significativos de las t areas de
t rabaj o, los cual es se pl anean en i ncrement os rel at i vament e cort os de t i empo (de
forma que el aj ust e y el control se den con frecuencia). Un plan de "granularidad
gruesa" proporci ona t ar eas de t rabaj o ms amplias, las cual es se pl anean en perio-
dos m s largos. Por lo general, la granul ari dad cambi a de fina a gruesa conf or me el
t i empo lmite del proyect o est m s lejos de la fecha actual. En las si gui ent es s ema-
nas o mes es el proyect o se puede pl anear con detalle significativo. Las actividades
que no se real i zarn por muchos mes es no requi eren una granul ari dad fina (hay
demasi adas cosas que pueden cambiar).
Pr i nci pi o #8: Definir cmo se intentar asegurar la calidad. El plan debe
identificar la forma en que el equi po de sof t war e pret ende asegurar la calidad. Si
habr revi si ones t cni cas formales, 7 st as se deben calendarizar. En caso de que se
utilice programaci n en parej a (captulo 4) dur ant e la const rucci n sta debe est ar
definida de maner a explcita en el plan.
Pr i nci pi o #9: Describir cmo se pretende incluir el cambio. Incluso a la
mejor pl aneaci n puede superarl a el cambi o incontrolable. El equi po de soft ware
debe identificar la forma en que se incluirn los cambi os conf or me se realiza el tra-
baj o de ingeniera del soft ware. Por ejemplo, el cliente puede solicitar un cambi o en
7 Las revisiones tcnicas formales se estudian en el capitulo 26.
TM
PDF Editor
115
cualquier moment o? Si se present a una solicitud de cambi o el equipo est obliga-
do a implementarlo de inmediato? Cmo se evalan el impacto y el costo del cam-
bio?
Pr i nci pi o #10: Adaptar el plan a menudo y hacer los ajustes cuando stos
se requieran. Da tras da los proyectos de soft ware van por detrs del calendario
establecido. Por ello, es de mucha ayuda adaptar el progreso a diario. Se deben bus-
car reas problemticas y situaciones en las que el t rabaj o calendarizado no vaya de
acuerdo con el trabajo que se ejecuta en realidad. Cuando se encuent ran desfases,
el plan se ajusta en concordancia con ello.
En la bsqueda de mayor efectividad, todos los integrantes del equipo de softwa-
re deben participar en la actividad de planeacin. Slo ent onces son mi embros del
equipo "comprometidos" con el plan.
En un excelente document o sobre procesos y proyectos de software, Barry
Boehm [BOE96] establece: "Se necesita un principio de organizacin que se reduzca
para proporcionar pl anes [de proyecto] simples para proyectos simples." Boehm
sugiere un enfoque dirigido a los objetivos, fundament os y calendarios del proyecto,
a las responsabilidades, enfoques tcnicos y de gestin y a los recursos requeridos.
l lo llam principio W^HH (why, what, when, who, where, how, how), debido a una
serie de preguntas que conducen a una definicin de caractersticas clave del pro-
yecto y el plan de proyecto resultante:
I Oifcs Por qu e s t en des ar r ol l o e s t e s i s t e ma ? Todas las part es deben evaluar la
I validez de las razones del negocio para el trabajo en el software. Dicho de otra
manera, el propsito del negocio justifica el gasto de personal, tiempo y dinero?
Qu s e ha r ? Se debe identificar la funcionalidad que se construir y, por ende,
las tareas requeridas para realizar el trabajo.
i se
' y
t se deben
r pn
prtyetfo C u n d o s e t e r mi n a r ? Es n e c e s a r i o e s t a bl e c e r u n flujo d e t r a b a j o y u n t i e mp o
lmite para las t areas clave del proyecto, asi como identificar los fundament os reque-
ridos por el cliente.
Qui n e s el r e s pons a bl e de una f unci n? Se deben definir el papel y la res-
ponsabilidad de cada mi embro del equipo de software
En d nd e s e ubi can de nt r o de l a or gani zaci n? No t odos los papeles y res-
ponsabilidades residen dentro del mismo equipo de software. El cliente, los usuarios
y otros participantes tambin tienen responsabilidades.
Cmo s e r eal i zar el t r a ba j o e n l os s e nt i dos t cni co y d e ges t i n? Una
vez que se establece el mbito del producto, es necesario definir una estrategia tc-
nica y de gestin para el proyecto.
Cunto s e necesi ta de cada recurso? La r e s p u e s t a a e s t a p r e g u n t a s e obt i e
ne al desarrollar estimaciones (captulo 23) con base en las respuest as a las pregun-
tas anteriores.
TM
PDF Editor
Las r espuest as a las pr egunt as W5HH de Boehm son i mport ant es i ndependi ent e-
ment e del t a ma o o la compl ej i dad de un proyect o de soft ware. Pero, cmo se ini-
cia el proceso de pl aneaci n?
" Pe ns a mos que los desar r oi l ador es de s of t war e est n per di endo uno ver dad vital: la nayor i a de l as or gani zaci ones no
s a be n l o que l a c e n . Ellas pi ensan que lo s aben, per o no es as "
Tom DeMar co
CONJ UNTO DE TAREAS
Co njunto d e ta ze o s ge nri ca s pa ra la pla ne a ci n
8 1. Reevaluar el mbi t o del proyecto
(secciones 7. 4 y 21. 3).
2. Evaluar los riesgos (seccin 25. 4) .
3. Desarrollar o refinar los escenari os del usuari o
(secciones 7. 5 y 8.5).
4. Extraer funci ones y caractersticas a part i r de los
escenari os (seccin 8. 5).
5. Definir las funciones y caractersticas tcnicas que
forman la infraestructura del software.
. Agr upar las funciones y caractersticas (escenarios)
de acuer do con la pri ori dad del cliente.
7. Cr ear un plan de proyecto con una gr anul ar i dad
gr uesa (captulos 2 3 y 24).
Definir el nmero proyect ado de incrementos de
software.
Establecer un cal endar i o general del proyecto
(captulo 24).
Establecer las fechas de ent rega proyect adas par a
c a da incremento.
9.
Crear un plan con gr anul ar i dad fina par a la
iteracin actual (captulos 2 3 y 24).
Definir t ar eas de t r abaj o pa r a cada funcin y
caracterstica (seccin 23. 6).
Estimar el esfuerzo pa r a cada t ar ea de t r abaj o
(seccin 23. 6) .
Asi gnar responsabi l i dad par a cada t area de
t r abaj o (seccin 23. 4) .
Definir los product os de t r abaj o que sern
produci dos.
Identificar los mtodos par a el asegurami ent o de
la cal i dad que se usarn (captulo 26).
Describir los mtodos pa r a el cambi o en la gestin
(captulo 27).
Rastrear el progreso de maner a regular (seccin
24. 5. 2).
Obs er var las r e a s probl emt i cas (por ej empl o, el
desf ase del cal endari o).
Hacer los aj ust es que se requi eran.
5 . 4 P RCTI CA DEL MQP ELAP O
Los model os se crean par a obt ener un mej or ent endi mi ent o de la ent i dad real que s e
construir. Cuando la ent i dad es un obj et o fsico (por ejemplo, un edificio, un avin,
una mqui na), se puede construir un model o idntico en forma y t amao, per o en
menor escala. Sin embargo, cuando la ent i dad es soft ware, el model o debe t omar
una forma diferente. Debe ser capaz de represent ar la i nformaci n que el sof t war e
t ransforma, la arqui t ect ura y las funci ones que permi t en que ocurra la t r ansf or ma-
cin, las caractersticas que desean los usuari os, y el compor t ami ent o del si st ema
conforme se realiza la t ransformaci n. Los model os deben cumplir est os objetivos
en di ferent es grados de abst racci n (primero al pr esent ar el sof t war e desde el punt o
de vista del cliente y despus al represent ar el sof t war e en un nivel ms tcnico).
TM
PDF Editor
CAPITULO 5 LA PRCTI CA: UNA VISIN GENRICA
117
C L V E
s de
5 r epf esent on tos
del di ent e.
nodel os de di seo
i uno
i concret a
c c construccin
K
C L A V E
) del
s s enf oca en
t del
Cb
" i q u e s e
Jo
( s e debe
Mr '
q u e
En el t rabaj o de la ingeniera del soft ware se crean dos cl ases de modelos: mode-
los de anlisis y model os de diseo. Los modelos de anlisis represent an los requisi-
tos del cliente al present ar el soft ware en t res domi ni os diferentes: el dominio de la
informacin, el domi ni o funcional y el dominio del comport ami ent o. Los modelos de
diseo represent an caractersticas del soft ware que ayudan a los profesi onal es a
construirlo de maner a efectiva: la arquitectura (captulo 10), la interfaz del usuario
(captulo 12), y el detalle al nivel de component es (captulo 11).
En las secci ones siguientes se present an los principios y concept os bsicos que
son relevantes para el model ado del anlisis y el diseo. Los mt odos tcnicos y la
notacin que permiten que los i ngeni eros de soft ware creen model os de anlisis y
di seo se present an en los captulos posteriores.
"El p r i me r p r o b l e ma del i nge ni e r o e n cua l qui e r s i t uaci n d e di s e o e s des cubr i r cul e s r e a l me n t e el p r o b l e ma . "
5.4.1 Principios del model ado del anlisis
En las pasadas t res dcadas s e ha desarrollado un gran nmer o de mt odos de
model ado del anlisis. Los investigadores han identificado los probl emas del anli-
sis y sus causas y han desarrollado una variedad de not aci ones de model ado y los
concept os heursticos correspondi ent es para manej arl os. Cada mt odo de anlisis
tiene un punt o de vista nico. Sin embargo, t odos los mt odos de anlisis estn rela-
ci onados por medi o de una serie de principios operativos:
Pr i nci pi o SI: El dominio de informacin de un problema debe represen-
tarse y entenderse. El dominio de informacin lo f or man los dat os que fluyen hacia
el si st ema (a partir de los usuari os finales, ot ros si st emas o dispositivos externos),
los dat os que fluyen desde el si st ema (a travs de la interfaz del usuario, interfases
de red, reportes, grficas y ot ros medios) y los al macenami ent os de dat os que se
recopilan y reorgani zan los obj et os consi st ent es de informacin (es decir, los dat os
que se mant i enen en forma permanent e).
Pr i nci pi o #2: Se deben definir las funciones que ejecuta el software. Las
funci ones del soft ware proporcionan un benefi ci o directo a los usuari os Anales y
t ambi n aport a soport e i nt erno a aquel l as caractersticas visibles para el usuario.
Algunas funci ones t ransforman los dat os que fluyen hacia el sistema. En ot ros casos,
las funci ones efect an algn grado de control sobre el procesami ent o i nt erno del
soft ware o el ement os ext ernos del si st ema. Las funci ones se pueden describir en
muchos grados diferentes de abstraccin, que van desde un enunci ado general del
propsito hast a una descripcin detallada de los el ement os del procesami ent o que
deben utilizarse.
Principio #3: Se debe representar el comportamiento del software (como
una consecuencia de eventos externos). Al comportamiento del software de compu
t adora lo gua su interaccin con el ambi ent e externo. La ent rada que proporci onan
TM
PDF Editor
PARTE DOS PRCTICA ES LA INGENIERA DEL SOFTWARE
los usuari os finales, los dat os de control que aport a un si st ema ext erno o los dat os
de moni t oreo que se recolectan a t ravs de una red ocasi onan que el soft ware se
comport e de una maner a especifica.
Pr i nci pi o #4: Los modelos que presentan informacin, funcin y compor-
tamiento deben partirse de forma que descubran el detalle de una manera
estratificada (o jerrquica). El model ado del anlisis es el primer paso en la reso-
lucin de probl emas en la ingeniera del soft ware. Esto permite al profesional ent en-
der mej or el probl ema y est abl ecer una base para la solucin (diseo). Los proble-
mas compl ej os son difciles de resolver por completo. Por esta razn, se utiliza una
estrategia de "divide y ganars". Un probl ema grande y compl ej o s e divide en sub-
probl emas hasta que cada subprobl ema es relativamente fcil de entender. Este con-
cept o se llama particin, y es una estrategia clave en el model ado del anlisis.
Pr i nci pi o #5: La tarea del anlisis debe moverse de la informacin esencial
hacia el detalle de implementacin. El model ado del anlisis comi enza con la
descripcin del probl ema desde la perspectiva del usuario final. La "esencia" del pro-
bl ema se describe sin ni nguna consideracin de la forma en la que se i mpl ement a-
r la solucin. Por ejemplo, un videojuego requiere que el j ugador "instruya" al pro-
tagonista en qu direccin seguir cuando ste se mueve dent ro de un laberinto peli-
groso. Esa es la esenci a del probl ema. El detalle de implementacin (descrita en
forma normal como una part e del model o del diseo) indica cmo se implementar
la esencia. Respecto del videojuego se podra aplicar la ent rada de voz. De maner a
alternativa, se podra digitar un comando del teclado, o se podra apunt ar un joystick
(o un mouse) en una direccin especfica.
CONJUNTO DE TAREAS
Co njunto d e ta re a s ge nri ca s pa ra
1. Revisar los requisitos del negoci o, las 3.
caract er st i cas/ necesi dades del
usuario, las sal i das visibles par a el
usuario, las restricciones del negoci o, y otros
requisitos tcnicos que se hayan det ermi nado
durant e las actividades de comunicacin con el
cliente y de pl aneaci n.
Expandir y refnar los escenari os del usuari o (seccin
8. 5).
Definir a todos los actores.
Representar la forma en que los actores
interactan con el software.
Extraer funciones y caractersticas a partir de los
escenari os del usuario.
Revisar los escenari os del usuari o par a verificar
que estn completos y su exactitud (seccin 26. 4).
4.
e l mo d e la d o d e l a nli s i s
Model ar el dominio de la informacin (seccin 8.3).
Representar todos los obj et os importantes de
informacin.
Definir los atributos par a cada obj et o de
informacin.
Representar las relaciones entre los obj et os de
informacin.
Model ar el domi ni o funcional (seccin 8. 6).
Most rar la forma en que las funciones modifican
los obj et os de dat os.
Refinar las funciones par a proporci onar los
detalles de la el aboraci n.
Escribir una narraci n del procesami ent o que
describa c a da funcin y subfuncin.
Revisar los modelos funcionales (seccin 26. 4).
y
TM
PDF Editor
119
I R \
5. Modelar el dominio del comportamiento (seccin Revisar los modelos de comportamiento (seccin
8.8). 26. 4).
Identificar los eventos externos que ocasionan Analizar y modelar la inferase del usuario (captulo
cambios en el comportamiento dentro del ] 2).
sistema.
Dirigir el anlisis de tareas.
Identificar los estados que representan cada forma
de comportamiento observable desde el exterior. C r e a r Pr ot Hpos de la imagen en pantalla,
Presentar el modo en el que un evento lleva al 7 - Revisar todos los modelos en cuanto a que estn
sistema a cambi ar de un est ado a otro. completos, su consistencia y las omisiones.
y
5.4.2 Principios de model ado del diseo
El model o de di seo del sof t war e es el equi val ent e al pl ano de una casa para un
arquitecto. Comi enza con la represent aci n de la totalidad del obj et o que ser cons-
truido (por ejemplo, una reproducci n tridimensional de la casa) y con lentitud lo
refina para proporci onar una gua para construir cada detalle (por ej empl o, el dise-
o de la plomera). En forma similar, el model o del di seo que se crea para el soft -
war e proporci ona una variedad de di ferent es vistas del si st ema.
"Primero ve que el diseo seo sabio y justo: overiguodo esto, persigelo resueltamente; no por un rechozo dejes ir el
propsito que t e has resuelto efectuar.*
William Shakespeare
No hay pocos mt odos para derivar los di ferent es el ement os de un di seo de soft-
ware. Algunos mt odos se gu an medi ant e los dat os al permitir a la est ruct ura de
dat os dictar la arqui t ect ura del pr ogr ama y los component es de procesami ent o resul-
tantes. A otros los conduce el pat rn a! utilizar i nformaci n acerca del domi ni o del
probl ema (el model o de anlisis) para desarrollar estilos arqui t ect ni cos y pat r ones
de procesami ent o. Incluso otros est n ori ent ados a objetos, al usar los obj et os del
domi ni o del probl ema como los conduct or es para la creacin de est ruct uras de dat os
y los mt odos par a manipularlos. An as, t odos ellos siguen un conj unt o de princi
p os de di seo que se pueden aplicar sin i mport ar el mt odo que se utilice:
Pr i nci pi o # 1: 7 diseo debe ser rastreable hasta el modelo de anlisis. El
model o de anlisis describe el domi ni o de la i nformaci n del probl ema, las funcio-
nes visibles para el usuario, el compor t ami ent o del si st ema y un conj unt o de cl ases
de anlisis que empaquet a los obj et os del negoci o con los mt odos que les sirven.
El mo d e l o d e d i s e o t r a d u c e e s t a i n f o r ma c i n a u n a a r q u i t e c t u r a : u n c o n j u n t o d e
subsi st emas que i mpi ement an las funci ones ms i mport ant es y un conj unt o de dise-
os al nivel de component es que son la realizacin de las cl ases de anlisis. Excepto
el model o asoci ado con la i nfraest ruct ura de soft ware, los el ement os del model o de
di seo deben ser rast reabl es hast a el model o de anlisis.
TM
PDF Editor
120
Eli C S . WWWC .
fld/~aobyon/
Des i gn/ se pueden
entontiar comentoios
profundos sobie el
proceso de diseo.
Junto con una
expos wndet o
esttico del diseo.
Pr i nci pi o #2: Siempre se debe considerar la arquitectura del sistema que
se va a construir. La arquitectura del software (captulo 10) es el esqueleto del sis-
t ema que se va a construir. ste afecta las interfases, las estructuras de datos, el flujo
y el comportamiento del control del programa, la manera en que se pueden realizar
las pruebas, la facilidad de mantenimiento del sistema resultante, y mucho ms. Por
todas est as razones, el diseo debe iniciarse con las consideraciones del diseo
arquitectnico. Slo despus de que se ha establecido la arquitectura, es posible
considerar los aspectos al nivel de componentes.
Pr i nci pi o #3: El diseo de datos es tan importante como el diseo de fun-
ciones de procesamiento. El diseo de datos es un el ement o esencial del diseo
arquitectnico. La manera en que se realizan los objetos de los dat os dentro del dise-
o no puede dejarse a la suerte. Un diseo de dat os bien estructurado ayuda a sim-
plificar el flujo del programa, facilita el diseo y la implementacin de los compo-
nent es del software, y confiere ms eficiencia al procesami ent o en general.
Pr i nci pi o #4: Las interfaces (internas y externas) deben disearse con cui-
dado. La manera en que fluyen los dat os ent re los component es de un sistema tiene
mucho que ver con la eficiencia del procesamiento, la propagacin del error y la sim-
plicidad del diseo. Una interfaz bien diseada facilita la integracin y ayuda a quien
realiza la prueba a validar funciones de componentes.
Pr i nci pi o #5: El diseo de interfaz del usuario debe ajustarse a las necesi-
dades del usuario final. Sin embargo, en cada caso, debe resaltarse la facilidad del
uso. La interfaz del usuario es la manifestacin visible del software. Sin importar qu
tan sofisticadas sean sus funciones internas, sin importar qu tan comprensibles
sean las estructuras de datos, no importa qu tan bien diseada est su arquitectu-
ra, un diseo de interfaz pobre siempre conduce a la percepcin de que el software
est "mal" hecho.
Pr i nci pi o #6: El diseo al nivel de componentes debe ser independiente del
modo funcional. La independencia funcional es una medida del "significado senci-
llo" de un component e de software. La funcionalidad que entrega un component e
debe ser cohesiva; es decir, debe centrarse en una y slo una funcin o subfuncin.8
Pr i nci pi o #7: Los componentes deben estar apareados entre s en forma
mnima y vinculados con el ambiente extemo. El apareami ent o se consigue de
muchas maneras: va interfaz de componente, por mensajes, a travs de dat os glo-
bales. A medida que aument a el nivel de apareami ent o, la probabilidad de propaga-
cin del error tambin aument a y la facilidad de mantenimiento general del softwa-
re disminuye. Por lo tanto, el apareami ent o de component es debe mant enerse tan
bajo como sea posible.
8 En el captulo 9 se puede encontrar una exposicin adicional acerca de la cohesin.
TM
PDF Editor
121
Pr i nci pi o #8: Las representaciones del diseo (modelos) deben ser fcil-
mente comprensibles. El propsi t o del di seo es comuni car i nformaci n a los pro-
fesi onal es que gener ar n cdigos, a aquel l os que probarn el soft ware, y a qui enes
tal vez mant engan el sof t war e en lo futuro. Si el di seo es difcil de ent ender, no ser-
vir como un medi o efectivo de comuni caci n.
Pr i nci pi o #9: El diseo debe desarrollarse de manera iterativa. En cada ite-
racin el diseador debe buscar la mayor simplicidad. Como casi t odas las acti-
vidades creativas, el di seo ocurre de modo iterativo. Las pri meras iteraciones sir-
ven para refinar el di seo y corregir errores, per o las iteraciones post eri ores deben
buscar que el di seo sea tan simple como sea posible.
Cuando se aplican est os principios de maner a apropi ada, el i ngeni ero de sof t wa-
re crea un di seo que muest ra los fact ores i nt ernos y ext ernos de calidad. Los facto-
res de calidad externos son aquel l as propi edades del sof t war e que los usuari os pue-
den observar fci l ment e (como velocidad, confiabilidad, correccin, facilidad de
uso). Los factores de calidad internos son i mport ant es para los i ngeni eros de soft wa-
re, ya que conducen haci a un di seo de alta calidad desde una perspectiva tcnica.
Lograr fact ores de calidad i nt ernos requiere que el di seador ent i enda concept os
bsi cos de di seo (captulo 9).
INFORMACIN
Mo d e la d o gi l
En su libro s obr e mode l a do gi l , Scott Ambl er
[AMB02] def i ne una serie d e pr i nci pi os'
c ua ndo el anl i si s y el di seo se conducen
del cont ext o d e la filosofa del desarrol l o gil d e
(captulo 4):
# 1 : La met a pr i mar i a del equi po d e sof t war e es
construir soft ware, no cr ear model os.
# 2: Vi aj ar l i gero; es decir, no de be n cr ear se ms
model os d e los necesar i os.
# 3: Intentar pr oduci r el model o m s si mpl e que
descri bi r el pr obl ema o el sof t war e.
~zo # 4: Const rui r model os de f or ma que stos s ean
aj ust abl es al cambi o.
# 5: Ser c a p a z d e enunci ar un pr opsi t o explcito
pa r a c a d a model o que se cr ee.
# 6: Ada pt a r los model os desar r ol l ados al
sistema que se t i ene en ma no.
Principio # 7: Trotar d e construir model os tiles, per o
ol vi darse d e construir model os perfect os.
Principio # 8: No volverse dogmt i co acer ca d e la sintaxis
del model o. Si st e comuni ca su cont eni do d e ma ne r a
exi t osa, la r epr esent aci n es s ecundar i a.
Principio # 9: Si el instinto indica que un modelo no es el
correcto aunque ste luzca bien en el papel,
probablemente existe una razn para estar
preocupados.
Principio # 10: Obt ener ret roal i ment aci n ran pr ont o como
sea posi bl e.
Sin i mpor t ar el model o d e pr oces o que se elija o las
pr ct i cas espec fi cas d e la i ngeni er a del sof t war e que se
apl i quen, t odos los equi pos d e s of t war e qui er en ser gi l es.
Por lo tonto, estos pri nci pi os se de be n apl i car sin i mport ar
el model o d e pr oces o del sof t war e que se ha ya
sel ecci onado.
9 Los pr i nci pi os me nc i ona d os en e s t a s ecci n se ha n a br e vi a do y a d a p t a d o par a l os pr ops i t os de e s t e
libro.
TM
PDF Editor
CONJ UNTO DE TAREAS
Co njunto d e ta re a s ge nri ca s pa ra e l
1. Utilizar el model o d e anl i si s,
sel ecci onar un estilo arqui t ect ni co
(pat rn) a pr opi a d o pa r a el sof t war e
(captulo 10).
2. Dividir el model o d e anl i si s en subsi st emas d e
di s eo y ubi car stos dent r o d e la arqui t ect ura
(captulo 10).
Tener la cer t eza de que c a d a subsi st ema es
coher ent e en el sent i do funci onal .
Di sear i nt erfases d e subsi st ema.
Ubi car las cl ases o f unci ones de anl i si s p a r a
c a da subsi st ema.
Medi ant e la utilizacin del model o del domi ni o d e
la i nf or maci n, di s ear est ruct uras d e da t os
a pr opi a d a s .
3. Disear la interfaz del usuario (captulo 12).
Revisar los resul t ados del anl i si s d e t ar eas .
4.
d i s e o
Especi fi car la secuenci a d e acci n con ba s e en los
escenar i os del usuar i o.
Cr e a r un model o d e compor t ami ent o d e la
i nt erfaz.
Definir los obj et os d e la i nt er f az y mecani smos de
control.
Revisar el di seo d e la i nt er f az y aj usf ar l o como
sea neces ar i o (seccin 26. 4) .
Conduci r el di seo al nivel d e component e.
Especificar t odos los al gori t mos en un g r a d o
rel at i vament e b a j o d e abst r acci n.
Refinar la i nt erfaz d e c a d a component e.
Definir les est ruct uras d e dat os en el nivel d e
component e (seccin 26. 4) .
Revisar el di seo en el nivel de component es
(seccin 26. 4) .
Desarrol l ar un model o d e despl i egue (seccin 9. 4. 5) .
5 . 5 P R C T I C A DE LA CONS T RUCCI N
La actividad de construccin abarca una serie de t ar eas de codificacin y realizacin
de pr uebas que conducen al sof t war e operat i vo que est listo para ent regarl o al
cliente o usuari o final. En el t rabaj o de la ingeniera del soft ware moderna la codifi-
cacin puede ser: 1) la creaci n directa de cdigo f uent e de un l enguaj e de progra-
maci n; 2) la generaci n aut omt i ca de cdi go fuent e al utilizar una represent aci n
i nt ermedi a del di seo del component e que ser const rui do; 3) la generaci n aut o-
mt i ca de cdigo medi ant e un l enguaj e de programaci n de cuart a generaci n (por
ejemplo, Visual C++).
"Durante gron parte de mi vida he sido un fisgn del software, asomndome furtivamente en el cdigo sucio de otros
personas. Ocasionalmente, encuent ro uno joya real, un programa bien estructurado escrito con un estilo consistente,
sin enredos, desarrollado de forma que cada component e es simple y organizado, y diseado para que el producto
puedo cambiar con facilidad."
David Pa ma s
El enf oque inicial de las pr uebas est al nivel de component es, con frecuenci a lla-
madas pruebas de unidad. Los ot ros niveles de prueba incluyen: 1) pruebas de inte-
gracin (realizadas mi ent ras el si st ema est en construccin) 2) pruebas de validacin,
las cual es eval an si los requisitos han sido sat i sfechos para el si st ema compl et o (o
para el i ncrement o de soft ware); y 3) pruebas de aceptacin, que realiza el cliente en
un esf uer zo encami nado a ejercitar las caractersticas y funci ones.
TM
PDF Editor
123
j ^ O MS C J O ^ .
s encootrar
Existe una serie de principios y concept os aplicables a la codificacin y las prue-
bas. stos se pr esent an en las secci ones siguientes.
5.5.1 Principios y conceptos de codi fi caci n
Los principios y concept os que guan la t area de codificacin est n al i neados de
maner a muy cer cana al estilo de la programaci n, los l enguaj es de la programaci n
y los mt odos de programaci n. Sin embargo, existe un conj unt o de principios f un-
dament al es que pueden est abl ecerse:
Pr i nci pi os d e p r e p a r a c i n : Antes de escribir una lnea de cdigo se debe estar segu-
ro de:
toe/
1.
ceun
2.
: elegante
2.
toe/
3.
: equivocado.
ario prestar
xriculor al
4.
mapto le
t e
s 4e codificacifl.
war e que se va a construir y el ambi ent e en el que st e va a operar.
Seleccionar un ambi ent e de programaci n que proporci one her r ami ent as que
faciliten el trabajo.
5. Crear un conj unt o de pruebas de unidad que sern apl i cadas una vez que se
compl et e el component e que se va a codificar.
Pr i nci pi os d e codi f i ca ci n: Cuando se comience a escribir el cdigo se debe estar
seguro de:
1. Restringir los algoritmos al seguir la prctica de la programaci n est ruct urada
[BOHOO],
2. Seleccionar las est ruct uras de dat os que satisfarn las necesi dades del diseo.
3. Ent ender la arquitectura del sof t war e y crear i nt erfases que sean consi st ent es
con ella.
4. Mant ener la lgica condicional t an simple como sea posible.
5. Crear ciclos ani dados en una forma que los haga fciles de probar.
6. Seleccionar nombr es de variables significativas y seguir ot ros est ndar es lo-
cal es de codificacin.
7. Escribir cdi go que t enga document aci n propia.
8. Crear una confi guraci n lineal (por ejemplo, sangr as y lneas en bl anco que
ayuden a la comprensi n del cdigo).
Pr i nci pi os d e val i daci n: Despus de haber completado los primeros pases de codi-
ficacin, se debe estar seguro de
1. Conducir un ensayo de cdigo cuando sea apropi ado
2. Realizar pr uebas de uni dad y corregir los errores que se hayan descubi ert o.
3. Refabricar el cdigo.
TM
PDF Editor
124
2 .
Los libros sobre codificacin y los principios que la guan incluyen t rabaj os recien-
tes sobre el estilo de programaci n [KER78], construccin prctica de soft ware
IMCC93], perlas de programaci n [BEN991, el arte de la programaci n [KNU99],
aspect os de la programaci n pragmt i ca IHUN99], y muchos otros.
Co njunto d e ta ze o s ge nri ca s po za la co ns tzucci n
CONJUNTO DE TAREAS
1. Construir la infraestructura
arquitectnica (captulo 10).
Revisar el diseo arquitectnico.
Codificar y probar los componentes que forman la
infraestructura arquitectnica.
Adquirir patrones arquitectnicos reutilizables.
Probar la infraestructura par a asegur ar la
integridad de la interfaz.
Construir un componente del software (captulo 11).
Revisar el diseo al nivel de componente.
Crear una serie de pruebas de unidad par a el
componente (secciones 13. 3. 1 y 14.7).
Codificar las estructuras de dat os y la inferase del
componente.
3.
Codificar los algoritmos internos y las funciones de
procesamiento relacionadas.
Revisar el cdi go conforme ste se escribe (seccin
26. 4).
Buscar la exactitud.
Asegurarse de que se han mantenido los
est ndares de codificacin.
Asegurarse de que el cdi go se documenta a s
mismo.
Realizar pruebas de unidad al componente.
Dirigir todas las pruebas de unidad.
Corregir los errores descubiertos.
Aplicar de nuevo las pruebas de unidad.
Integrar el componente terminado a la infraestructura
arquitectnica.
Cules son
los objetivos
de los pruebas al
soft ware?
5.5.2 Principios de l as pruebas
En un libro clsico sobre las pruebas real i zadas al soft ware, Glen Myers [MYE79]
est abl ece una serie de reglas que bien pueden servir como objetivos de las pruebas:
Las pruebas consisten en un proceso en el que se ejecuta un programa con la
intencin de encont rar un error que an no se descubre.
Un buen caso de prueba es aquel en el que hay una gran probabilidad de
encont rar un error que an no se descubre.
Una prueba exitosa es aquella que encuent ra un error que an no se
descubra.
Estos objetivos implican un cambi o radical desde el punt o de vista de al gunos desa-
rrolladores de soft ware. stos se oponen a la visin inusual de que la prueba exito-
sa es aquella en la que no se encuent r an errores. El objetivo aqu es di sear pr uebas
que de maner a sistemtica descubran di ferent es clases de errores y que lo hagan
con un gast o m ni mo de tiempo y esfuerzo.
Davis [DAV95] sugiere un conj unt o de principios para las pruebas, 10 el cual se ha
adapt ado para aprovecharl o en est e libro:
10 Aqu se present a slo un pequeo subconj unt o de los principios de Davis para l as pruebas. Para ob-
tener ms i nformaci n vase (DAV95).
TM
PDF Editor
125
F C O N S E J O .
) amplio
'.de
.debe
quese
'ai lo grande" ,
enla
del
i se termina
cxqueo-,ol
teios
. Para las
soto es
re
yprobar
Pr i nci pi o # 1: Todas las pruebas deben ser rastreables hasta los requisitos
del clienteEl objetivo de las pr uebas real i zadas al sof t war e es descubrir errores.
De aqui se despr ende que los defect os ms severos (desde el punt o de vista del clien-
te) son aquel l os que hacen fallar el pr ogr ama al t rat ar de satisfacer sus requisitos.
Pr i nci pi o #2: Las pruebas se deben planear mucho antes de que comience
el proceso de prueba. La pl aneaci n de las pruebas (captulo 13) puede comenzar
t an pront o como el model o de anlisis est compl et o. La definicin det al l ada de los
casos de prueba puede comenzar en cuant o el model o de di seo haya sido solidifi-
cado. Por t ant o, t odas las pruebas se pueden pl anear y di sear ant es de que se haya
gener ado cualquier cdigo.
Pr i nci pi o #3: El principio de Pareto es aplicable para las pruebas de soft-
ware. Para est abl ecerl o de maner a simple, el principio de Pareto implica que 80 por
ci ent o de los errores descubi ert os dur ant e las pruebas con probabilidad sern ras-
t reabl es hast a 20 por ci ent o de t odos los programas. El probl ema, por supuest o, es
aislar est os component es sospechosos y despus probarl os.
Pr i nci pi o #4: Las pruebas deben comenzar " en lo pequeo" y progresar
hacia " lo grande" . Las pri meras pr uebas que se pl anean y ej ecut an, por lo general,
se enf ocan en los component es individuales. Conforme progresan las pruebas, el
enfoque cambi a en un i nt ent o de encont r ar errores en grupos i nt egrados de compo-
nent es y, por ltimo, en el si st ema compl et o.
Pr i nci pi o #5: Las pruebas exhaustivas no son posibles. El nmer o de per-
mut aci ones ent r e las rutas, incluso de un programa con un t amao moderado, es
excepci onal ment e grande. Por est a razn es imposible ej ecut ar cada combi naci n
de rut as para las pruebas. Sin embargo, se puede cubrir de maner a adecuada la lgi-
ca del pr ogr ama para asegur ar que se hayan ej erci t ado t odas las condi ci ones al nivel
de component es (captulo 14).
CONJ UNTO DE TAREAS
Co njunto d e ta re a s ge nri ca s pa ra la s prue ba s
1. Disear pruebas de unidad pora
cada componente del software
(seccin 13. 3. 1)
Revisar cada prueba de unidad por a asegurar una
cobertura apr opi ada.
Dirigir la prueba de unidad.
Aplicar de nuevo las pruebas de unidad.
2. Desarrollar una estrategia de integracin (seccin
13.3.2).
Establecer el orden y la estrategia que se usar
par a la integracin.
Definir las "construcciones" y las pruebas
requeri das par a ejercitarlas
11 Este principio se refiere a las pr uebas funcionales, es decir, a l as que se enf ocan en los requisitos.
Las pruebas estructurales (que se enf ocan en los detalles arqui t ect ni cos o lgicos) pueden no refe-
rirse en forma directa a los requisitos especficos.
TM
PDF Editor
GIIIKi
126
Dirigir pruebas de humo a diario.
Dirigir pruebas de regresin cada vez que sea
necesario.
Desarrollar una estrategia de validacin (seccin
13.5).
Establecer los criterios de validacin.
Definir las pruebas requeridas par a validar el
software.
Dirigir las pruebas de integracin y validacin.
Aplicar de nuevo las pruebas cada vez que sea
5. Dirigir las pruebas con mucho orden.
Realizar las pruebas de recuperacin (seccin
13. 6. 1).
Realizar las pruebas de seguridad (seccin
13.6.2).
Realizar las pruebas de tensin (seccin 13. 6. 3).
Realizar las pruebas de desempeo (seccin
13. 6. 4).
6. Coordinar con el cliente las pruebas de aceptacin
(seccin 13. 5. 3).
\
( c O M S E J O ^ .
Se debe tener lo
seguridad de que el
tente sobe qu
esperar antes de que
se entregue el me-
mento de software.
De otra manera, el
dente esperai ms
deloquesel
Como se menci on en el captulo 2, la actividad de despliegue abarca tres acciones:
entrega, soporte y retroalimentacin. Como el software moderno es evolutivo por
naturaleza, el despliegue no se presenta una sola vez, sino varias veces conforme el
software avanza hacia su terminacin. Cada ciclo de entrega le proporciona al clien-
te y a los usuarios finales un incremento de software operativo que provee funcio-
nes y caractersticas tiles. Cada ciclo de soporte proporciona documentacin y asis-
tencia humana para t odas las funciones y caractersticas introducidas durante todos
los ciclos de despliegue que se han present ado hasta la fecha. Cada ciclo de retroa-
limentacin ofrece al equipo de software una gua importante que conduce a modi-
ficaciones en las funciones, caractersticas y el enfoque que se t oma para el siguien-
te incremento.
La entrega de un incremento de soft ware representa un fundament o importante
para cualquier proyecto de software. Cuando el equipo se prepara para crear un
incremento, se debe seguir una serie de principios clave:
Pr i nci pi o # I : Se deben administrar las expectativas que el cliente tiene del
software. Con demasi ada frecuencia, el cliente espera ms de lo que el equipo ha
prometido ent regar y de inmediato se present a un desacuerdo. Esto genera una
retroalimentacin improductiva que arruina la moral del equipo. En su libro sobre la
administracin de expectativas, Naomi Kartun [KAR94] establece: "El punt o inicial
para administrar las expectativas es volverse ms consciente acerca de lo que se
comunica y de la forma en que se hace". Sugiere que un ingeniero de soft ware debe
ser cuidadoso de no enviar al cliente mensaj es conflictivos (como prometer ms de
lo que se puede entregar de manera razonable en el marco de tiempo con el que se
cuenta, o entregar ms de lo que se promete para un incremento de soft ware y des-
pus menos de lo prometido para el siguiente).
TM
PDF Editor
127
Pri nci pi o #2: Se debe ensamblar y probar un paquete de entrega completo.
Se debe ensamblar un CD-ROM u otro medi o que contenga todo el soft ware ejecu-
table, archivos con los dat os de soporte, document os de soporte y otra informacin
relevante para que despus lo prueben los usuarios reales. Todos los protocolos de
instalacin y otras caractersticas operativas se deben ejercitar posteriormente en
t odas las configuraciones de cmput o posibles (por ejemplo, hardware, sistemas
operativos, dispositivos perifricos, arreglos de red).
Pr i nci pi o #3: Se debe establecer un rgimen de soporte antes de entregar
el software. Un usuario final espera responsabilidad e informacin exacta cuando
surja una pregunta o problema. Si el soporte es ad hoc o, an peor, inexistente, el
cliente se siente insatisfecho de inmediato. El soporte debe ser planeado, el material
de soporte se debe preparar y se deben establecer mecani smos para mant ener un
registro apropiado con que el equipo de soft ware pueda realizar una evaluacin
categrica de los tipos de soporte solicitados.
Pr i nci pi o #4: Se debe proporcionar material instructivo apropiado a los
usuarios finales. El equipo de soft ware entrega ms que el soft ware en s; en caso
de ser necesario, se debe desarrollar un ent renami ent o apropiado, se deben propor-
cionar directrices para la resolucin de problemas, y se deben publicar descripciones
acerca de "cul es la diferencia con este incremento de software".12
Pr i nci pi o #5: El software con errores se debe arreglar primero y entregar-
se despus. Ante la presin del tiempo, al gunas organizaciones de soft ware entre-
gan incrementos de baja calidad con una advertencia para el cliente de que los erro-
res "se eliminarn en la prxima versin". Esto es un error. En el negocio del soft-
ware se dice: "Los clientes olvidarn que se les entreg un producto de alta calidad
unos pocos das despus, pero nunca olvidarn los problemas que les caus un pro-
ducto de baja calidad. El soft ware se los recuerda todos los das".
El software ent regado proporciona un beneficio para el usuario final, pero t am-
bin provee una retroalimentacin til para el equipo de software. Al utilizar el incre-
ment o, los usuarios finales deben ser motivados a coment ar sobre las caractersti-
cas y funciones, facilidad de uso, confiabilidad y cualesquiera otras caractersticas
apropiadas. La retroalimentacin debe recopilarla y registrarla el equipo de soft wa-
re y aprovecharla para 1) hacer modificaciones inmediatas al incremento entregado
(si es necesario); 2) definir los cambios que sern incorporados en el prximo incre-
ment o planeado; 3) realizar las modificaciones necesarias al diseo para ajustarlo a
los cambios; y 4) revisar el plan (incluyendo el calendario de entrega) del prximo
incremento para reflejar los cambios.
12 Durante la actividad de comunicacin el equipo de software debe determinar los tipos de materia-
les de ayuda que quieren los usuarios.
TM
PDF Editor
128 PARTE DOS PRCTICA DE LA INGENIERIA DEL SOFTWARE
CONJ UNTO DE TAREAS
2. Establecer la persona o grupo encargado del
r - o p o r * f o L u m o n o
Crear la documentacin o las herramientas de
soporte por computadora.
Est abl ecer mecani smos d e cont act o (por ej empl o,
un sitio we b, t el fono, cor r eo electrnico).
Est abl ecer mecani smos pa r a la l ocal i zaci n d e
pr obl emas .
Est abl ecer mecani smos pa r a el r epor t e d e
pr obl emas .
3.
Co njunto d e ta re a s ge ne ri ca s pa ra e l
1. Cr e a r medi os de ent r ega.
Ensambl ar y pr oba r t odos los
ar chi vos ej ecut abl es.
Ensambl ar y pr oba r t odos los ar chi vos d e dat os.
Cr e a r y pr oba r t oda la document aci n del usuari o.
Impl ement ar l as versi ones el ect rni cas (por
ej empl o, pdf).
Impl ement ar ar chi vos d e " a yuda " con hi pert ext o.
Impl ement ar una gu a pa r a la resolucin d e
pr obl emas .
Pr obar los medi os d e ent r ega con un gr upo
pe que o d e usuari os represent at i vos.
4 .
5.
6.
d e s pli e gue
Est abl ecer una ba s e d e dat os pa r a el r epor t e d e
pr obl emas / er r or es .
Est abl ecer mecani smos d e ret roal i ment aci n del
usuar i o.
Definir el pr oces o d e ret roal i ment aci n.
Definir las f or mas d e ret roal i ment aci n (en papel o
el ect rni ca)
Est abl ecer la ba s e d e da t os d e ret roal i ment aci n.
Definir el pr oces o d e eval uaci n d e la
ret roal i ment aci n.
Di semi nar los medi os de ent r ega a t odos los
usuari os.
Dirigir l as f unci ones d e s opor t e cont i nuas.
Pr opor ci onar asi st enci a en la instalacin y el
inicio.
Pr opor ci onar asi st enci a cont i nua y d e resolucin
de pr obl emas .
Recopi l ar la ret roal i ment aci n del usuar i o
Registrar la ret roal i ment aci n.
Eval uar la ret roal i ment aci n.
Comuni car s e con los usuar i os s obr e la
ret roal i ment aci n.
La prctica de la ingeniera del soft ware incluye concept os, principios, mt odos y
her r ami ent as que aplican los i ngeni eros de sof t war e durant e el proceso de soft wa-
re. Cada proyect o de ingeniera del soft ware es diferente, aun as existe un conj unt o
de principios y t ar eas aplicables para cada actividad del mar co de t rabaj o del proce-
so, sin importar el proyect o o product o.
Si se pret ende dirigir una buena prctica de la ingeniera del soft ware, es necesa-
rio un conj unt o de punt os esenci al es t cni cos y de gestin. Los punt os tcnicos
incluyen la necesi dad de ent ender los requisitos y las r eas de i ncert i dumbre del pro-
totipo, as como la necesi dad de definir de maner a explcita la arqui t ect ura del soft-
war e y el plan de integracin de component es. Los punt os esenci al es de gestin
incluyen la necesi dad de definir pri ori dades y especificar un cal endari o realista que
las refleje, la necesi dad de precisar medi das de control del proyect o apr opi adas para
la calidad y el cambio.
TM
PDF Editor
129
Los principios de comunicacin con el cliente se enfocan en la necesidad de redu-
cir el ruido y mejorar el canal de comunicacin conforme progresa la conversacin
entre el desarrollador y el cliente. Ambas partes deben colaborar para que se esta-
blezca la mejor comunicacin.
Los principios de planeacin se enfocan en las directrices encami nadas a cons-
truir el mejor mapa para realizar el trabajo que conducir a terminar un sistema o
producto. El plan se puede disear slo para un incremento de software, o se puede
definir respecto del proyecto completo. Independientemente de ello, el plan debe
indicar qu se har, quin lo har y cundo se completar el trabajo.
El model ado incluye tanto el anlisis como el diseo, al describir representacio-
nes del soft ware que se vuelven ms detalladas de manera progresiva. La finalidad
de los modelos es solidificar la comprensin del t rabaj o que se realizar y propor-
cionar una gua tcnica para quienes implementarn el software.
La construccin incorpora un ciclo de codificacin y pruebas en el cual primero
se genera el cdigo fuente y despus ste se prueba para detectar errores. La inte-
gracin combina los component es individuales e involucra una serie de pruebas que
se enfocan en los aspect os del funcionamiento general y de las interfases locales.
Los principios de codificacin definen las acciones genricas que deben ocurrir ant es
de que se escriba el cdigo, mientras st e se crea y despus de que se haya comple-
tado. Aunque existen muchos principios para las pruebas, slo uno es el dominante:
las pruebas se forman con un proceso en el que un programa se ejecuta con el obje-
tivo de encontrar un error.
Durante el desarrollo del soft ware evolutivo se presenta el desarrollo para cada
incremento de soft ware que se presenta al cliente. Los principios clave para la entre-
ga consideran administrar las expectativas del cliente y dotar al usuario con infor
macin de soporte para el software. El soporte necesita una preparacin previa. La
retroalimentacin permite al cliente sugerir cambios que tienen un valor de negocios
y proporcionan al desarrollador una entrada para el prximo ciclo iterativo de la
[AMB02] Ambler, S. y R. Jeffrics, Agile Modeling, Wiley, 2002.
1BEN99] Bentley, J Programming Pearls, 2a. ed., Addison-Wesley, 1999.
IBOE 96] Boehm, B., "Anchoring t he Sof t war e Process", en IEEE Software, vol. 13, nm. 4, julio
de 1996, pp. 73-82.
[BOHOO] Bohl, M. y M. Rin, Tools for Structured Design: An Introduction lo Programming Logic,
5a. ed., Prentice-Hall, 2000.
[DAV95] Davis, A., 201 Principies of Software Development, McGraw-Hill, 1995.
[FOW991 Fowler, M. et al., Refactoring: Improving the Design ofExisting Code, Addison-Wesley,
1999.
[GAR95] Garl an, D. y M. Shaw, "An i nt roduct i on t o Sof t war e Architeclure", en dvanees in
Software Engineering and Knowledge Engineering, vol. 1 (V. Ambri ol a y G. Tortora, eds.),
World Scientific Publishing Company, 1995.
[HIG00I Highsmith, ]., Adaptive Software Development: An Evolutionary Approach to Managing
Complex Systems, Dorsct House Publishing, 2000.
TM
PDF Editor
[H0096] Hooker, D "Seven Principies of Soft ware Development", septiembre de 1996, disponible
en http://c2. com/cgi/wikiSevenPrinciplesOfSoftwareDevelopment.
[HUN95] Hunt , D., A. Bailey y B. Taylor, The Art of Facilitation, Per seus Book Group, 1995.
[HUN99] Hunt A., D. Thomas y W. Cunni ngham, The Pragmatic Programmer, Addison-Wesley,
1999.
DUS99] Justice, T. etal., TheFacilitators Fieldbook, AMACOM, 1999.
[KAN931 Kanner, C., J. Falk y H. Q. Nguyen, Testing Computer Software, 2a. ed., Van Nost rand
Reinhold, 1993.
[KAN96J Kaner, S. et al., The Facilitator's Cuide to Preparatoiy Decisin Making, New Society
Publishing, 1996.
[KAR94] Karten, N., Managing Expcctations, Dorset House, 1994.
[KER78] Kerni ghan, B. y P. Pl auger, The Elements of Programming Style, 2a. ed., McGraw-Hill,
1978.
[KNU98] Knuth, D The Art of Computer Programming, 3 vol menes , Addison-Wesley, 1998.
[MCC93] McConnnell, S., Code Complete, Microsoft Press, 1993.
(MCC97J McConnell, S "Soft ware' s Ten Essentials", en IEEE Software, vol. 14, nm. 2, mar zo-
abril, 1997, pp. 143-144.
[MYE78J Myers, G Composite Structured Design, Van Nostrand, 1978.
[MYE79] Myers, G The Art of Software Testing, Wiley, 1979.
[PAR72] Pa ma s , D.L., "On Criteria to Be Used in Decomposi ng Syst ems i nt o Modules", en
CACM, vol. 14, nm. 1, abril de 1972, pp. 221-227.
1POL45] Polya, G How to Solve II, Princeton University Press, 1945.
[ROS75] Ross, D., J. Goodenough y C. Irvine, "Sof t war e Engi neeri ng: Process, Principies and
Goals", en IEEE Computer, vol. 8, nm. 5, mayo de 1975.
[SHA95a) Shaw, M. y D. Garlan, "Formulations and Formalisms in Soft ware Architecture", Volume
1000Lecture Notes in Computer Science, Springer-Verlag, 1995.
[SHA95b] Shaw, M. et al., "Abstractions for Soft ware Architecture and Tools t o Support Them",
en IEEE Trans. Software Engineering, vol. SE-21, nm. 4, abril de 1995, pp. 314-335.
ISTE74] St evens, W., G. Myers y L. Const ant i ne, "St ruct ured Design", en IBM Systems Journal,
vol. 13, nm. 2, 1974, pp. 115-139.
[TAY90] Taylor D. A., Object-Oriented Technology: A Manager's Guide, Addison-Wesley, 1990.
[ULL97] Ullman, E., Cise to the Machine: Technophilia and its Discontents, City Lights Books,
1997.
[W1R71] Wirth, N "Program Devel opment by St epwi se Refinement", en CACM, vol. 14, nm. 4,
1971, pp. 221-227.
[ W0095] Wood, J. y D. Silver, Joint Application Design, Wiley. 1995.
[ZAH90] Zahniser, R. A., "Building Soft ware in Groups", en American Programmer, vol. 3, nms.
7-8, julio-agosto de 1990.
5.1. Int nt ese resumi r en un pr r af o breve los "siete principios para el desarrol l o de soft ware"
de David Hooker (seccin 5.1). Trt ese de ext r aer la esenci a de su guia en sl o unas cuant as
oraci ones y sin usar las pal abras de Hooker.
5.2. Existen ot ros punt os t cni cos "esenciales" que se puedan r ecomendar a los i ngeni eros de
software? Enunciar cada uno de ellos y explicar por qu se han incluido.
5.3. Existen otros punt os "esenciales" de gestin que se puedan r ecomendar a los ingenieros de
software? Enunciar cada uno de ellos y explicar por qu se ha incluido.
5.4. Un pri nci pi o i mpor t ant e de la comuni caci n est abl ece "pr epar e ant es de comuni car".
Cmo podr a est a pr epar aci n mani f est ar se por si mi s ma en los pr i mer os t r abaj os que se
real i zan? Cules pr oduct os de t rabaj o podr an resul t ar como consecuenci a de la preparaci n
oport una?
TM
PDF Editor
131
5. 5. Hgas e una i nvest i gaci n de la "faci l i t aci n" pa r a la act i vi dad de comuni ca ci n (utilcen-
s e l as r ef er enci as q u e s e pr opor ci ona n u ot r as) y pr e p r e s e un c onj unt o de di r ect r i ces que se
e nf oque n sl o e n la faci l i t aci n.
5 . 6 . En qu di f i er en la comuni ca ci n gil y la comuni caci n de la i ngeni er a de s of t wa r e t ra-
di ci onal ? En qu s on si mi l ar es?
5.7. Por qu e s neces ar i o cont i nuar ?
5.8. Real i zar una i nvest i gaci n de la "negoci aci n" pa r a la act i vi dad de comuni ca ci n y pr epa-
rar un c onj unt o de di r ect r i ces q u e s e e nf oque n s l o e n la negoci aci n.
5.9. Descri bi r l o que si gni fi ca granularidad e n el cont ext o de un cal endar i o de pr oyect o.
5. 10. Por qu s on i mpor t ant es l os mode l os e n el t r abaj o de la i ngeni er a de s of t war e? Si empr e
s on neces ar i os ? Son cal i f i cador es par a su r es pues t a acer ca de la neces i dad?
5. 11. Cul es s on l os t r es "domi ni os " que s e cons i de r a n dur a nt e el mode l a do del anl i si s?
5. 12. Tr at ar de agr egar un pri nci pi o adi ci onal a l os e nunc i a dos par a la codi f i caci n de la s ec-
ci n 5. 6.
5. 13. Qu e s una pr ue ba exi t os a?
5. 14. Se e s t de a c ue r do con el s i gui ent e enunci ado?: "debi do a que e nt r e ga mos ml t i pl es
i nc r e me nt os al cl i ent e, n o d e b e mo s p r e o c u p a mo s por la cal i dad e n l os pr i mer os i ncr ement os :
l os pr obl e ma s s e pue de n r esol ver e n i t er aci ones pos t er i or es . Expl i qese la r es pues t a.
5. 15. Por qu e s i mpor t ant e la r et r oal i ment aci n par a el e qui po de s of t wa r e ?
OTRAS LECTURAS Y FUENTES DE I NF ORMACI N
La comuni ca ci n c on el cl i ent e e s una act i vi dad muy i mpor t a nt e e n la i ngeni er a del s of t wa r e ;
n o obs t ant e, a l gunos pr of es i onal es n o dedi can t i empo a l eer acer ca de ella. Los l i br os de Pa r de e
(To Satsfy and Delight Your Costumer, Dorset House, 1996) y Kart en [KAR94] pr opor ci onan una
gr an per s pect i va de l os m t o d o s pa r a la i nt er acci n efect i va con el cl i ent e. En mu c h o s l i bros
s obr e la ges t i n de pr oyect os s e cons i de r a n l os c onc e pt os y pr i nci pi os de la comuni ca ci n y la
pl a ne a ci n. Las of er t as t i l es r el at i vas a la gest i n de pr oyect os i ncl uyen: Hughs y Cot t erel l
(Software Project Management, s e gunda edi ci n, McGraw-Hi l l , 1999), Phillips (The Software
Project Manager's Handbook, IEEE Comput e r Soci et y Pr ess, 1998), McConnel l (Software Project
survivai ouide, Microsoft Press, 1998) y Gilb (Principies of software Engineering Management.
Addi son-Wesl ey, 1998).
Casi cual qui er libro s obr e i ngeni er a del s of t wa r e cont i e ne una exposi ci n til s obr e l os con-
cept os y pr i nci pi os pa r a el anl i si s, el di s eo y l as pr uebas . Ent re l as me j or e s of e r t a s es t n l os
l i bros de Endr es y s us col e ga s (Handbook of Software and Systems Engineering, Addi son-Wesl ey,
2003), Sommer vi l l e (Software Engineering, sext a edi ci n, Addi son-Wesl ey, 2000), Pf l eeger
(Software Engineering: Theory and Practice, Prent i ce-Hal l . 2001) y Schach (Object-Oriented and
Ciassicai Software Engineering, McGraw-Hi l l , 2001). Davi s ha r ecopi l ado una ampl i a col ecci n de
pr i nci pi os de s of t wa r e en [DAV95],
Los c onc e pt os y pr i nci pi os del mod e l a d o s e cons i de r a n e n mu c h o s libros de di ca dos al a n -
lisis de r equi si t os o al di s eo de s of t war e. Young (EJfective Requirements Practices, Addi son-
Wesley, 2001) r es al t a un "equi po conj unt o" de cl i ent es y des ar r ol l ador es que el abor en los requi -
si t os col ect i vament e. Wei ger s (Software Requirements, Mi crosoft Press, 1999) pr e s e nt a mu c h o s
r equi si t os cl ave de i ngeni er a y r equi si t os de l as pr ct i cas de gest i n. Sommer vi l l e y Kot onya
(Requirements Engineering: Process and Techniques, Wiley. 1998) anal i zan l os conce pt os y l as t c-
ni ca s de "obt enci n" y ot r os pr i nci pi os de la i ngeni er a de r equi si t os.
El libro de Nor ma n (The Design ofEveryday Things. Cur r ency/ Doubl eday. 1990) e s una l ect u-
ra obl i gada pa r a cual qui er i ngeni er o de s of t wa r e que i nt ent e hacer el t r abaj o de di s eo
Wi nogr ad y s us col egas (Bringing Design to Software, Addi son- Wesl ey. 1996) ha n edi t ado una
excel ent e col ecci n de e ns a yos q u e t r at an s obr e l os a s pe c t os pr ct i cos del di s eo de s of t war e.
Cons t ant i ne y Lockwood (Software for Use, Addi son-Wesl ey, 1999) pr e s e nt a n l os c onc e pt os as o-
TM
PDF Editor
ci ados con el "diseo cent rado en el usuario". Tognazzini (Tog on Software Design, Addison-
Wesley, 1995) present a una valiosa exposicin filosfica de la nat ural eza del di seo y el impac-
to de las deci si ones sobre la calidad y la capacidad del equipo par a producir un soft ware que
proporci one un gran valor a su cliente.
Hay ci ent os de libros que t rat an sobre uno o ms el ement os de la actividad de construccin.
Kernighan y Plauger (KER78] escribieron un texto clsico sobre el estilo de programaci n;
McConnell (MCC93] present a directrices pr agmt i cas para la const rucci n prctica de software;
Bentley BEN99] sugiere una amplia vari edad de perl as de programaci n; Knuth [KNU98] ha
escrito una serie clsica de t res vol menes sobr e el art e de la programaci n, y Hunt |HUN99|
sugiere directrices pragmt i cas de programaci n. La bibliografa sobr e pr uebas ha florecido en
la dcada pasada. Myers [MYE79] s e conser va como un clsico. Los libros de Whitaker (How to
Break Software, Addison-Wesley, 2002), Kaner y sus col egas (Lessons Learned in Software Testing,
Wiley, 2001) y Marick (The Craft of Software Testing, Prentice-Hall, 1997) present an concept os y
principios i mport ant es sobre las pruebas, as como una gua pragmt i ca considerable.
En Internet existe una ampl i a vari edad de fuent es de i nformaci n sobre la prctica de la
ingeniera del soft ware. En el sitio web de SEPA se puede encont rar una lista act ual i zada de
referenci as en la red mundial, las cual es son rel evant es para la prctica de la ingeniera de soft-
ware:
TM
PDF Editor
C A P T U L O
I NGENI ER A
DE SI STEMAS
6
C O N C E P T O S
CLAVE
H
ace casi 500 aos, Maquiavelo dijo: "No hay nada ms difcil de llevar a
cabo, ms peligroso de realizar o de xito m s incierto que encabezar la
introduccin de un nuevo orden de cosas". Durant e los 50 ltimos aos,
los si st emas bas ados en comput ador a han introducido un nuevo orden. Aunque
la tecnologa ha t eni do varios avances desde la poca de Maquiavelo, sus pala-
bras an siguen vigentes.
La ingeniera del sof t war e ocurre como consecuenci a de un pr oceso l l amado
ingeniera de sistemas. En lugar de concent r ar se sl o en el soft ware, esta disci-
plina se cent ra en una variedad de el ement os mi ent ras analiza, disea y orga-
niza aquel l os el ement os de un si st ema que pueden ser un producto, un servicio
o una tecnologa para la t ransformaci n o control de i nformaci n.
El proceso de ingeniera de si st emas as ume distintas formas, segn el domi -
nio de aplicacin en que se utilice. La ingeniera de procesos de negocios se apli-
ca cuando el cont ext o del t rabaj o se enfoca en una empr esa. Cuando se va a
construir un product o (en est e cont ext o un product o incluye todo, desde un tel-
f ono i nal mbri co hast a un si st ema de control de t rfi co areo), al proceso se le
llama ingeniera de producto.
Tanto la ingeniera de pr ocesos de negoci o como la de product o i nt ent an
poner orden en el desarrol l o de si st emas bas ados en comput ador a. Aunque cada
uno de ellos se utiliza en un domi ni o de aplicacin diferente, ambos buscan
poner al sof t war e en su contexto. Es decir, t ant o la ingeniera de procesos de
Qu e s ? Antes de que sea posible
construir el software, por medio de la
ingeniera, se debe entender el "siste-
ma" en que ste reside. Pora lograr-
lo es necesario determinar el objetivo
general del sistema; se debe identificar el papel
que tienen el hardware, el software, las perso-
nas, las bases de datos, los procedimientos y
otros elementos del sistema; y se deben identifi-
car, analizar, especificar, modelar, validar y ges-
tionar los requisitos operacionales. Estas activi-
dades son el fundamento de la ingeniera de sis-
temas.
Qui n l o h a c e ? Un ingeniero de sistemas tra-
baja para entender los requisitos de un sistema
al trabajar con el cliente, usuarios futuros y otros
-reresados.
P o r q u e s i mp o r t a n t e ? Existe un a nt i guo
proverbio que dice: "los rboles no dejan ver el
bosque". En este contexto, el "bosque" es el sis-
tema y los rboles son los elementos tecnolgi-
cos (incluido el software) que se requieren para
realizar el sistema. Si se construyen los elemen-
tos tecnolgicos de una manera precipitada
antes de entender el sistema, sin duda se come-
tern errores que decepcionarn al cliente
Antes de preocuparse por los rboles se debe
entender el bosque.
Cu l e s s on l os p a s o s ? 5e identifican los obje-
tivos y requisitos operacionales ms detallados
al obtener informacin del cliente; se analizan
los requisitos para evaluar su claridad, si est
completo y es consistente; se crea una especifi
cacin, q u e p o r lo general est incorporada a
133
TM
PDF Editor
un modelo de sistema, que despus lo validan
los participantes y clientes. Por ltimo, se gestio-
nan los requisitos del sistema para asegurar que
los cambios se controlan de manera apropiada.
Cul e s el pr oduct o obt e ni do? Se debe pro-
ducir una representacin efectiva del sistema,
como consecuencia de b ingeniera del mismo. Se
puede realizar a travs de un prototipo, una
especificacin o incluso un modelo simblico,
pero debe comunicar las caractersticas operati-
vas, funcionales y de comportamiento del siste-
ma que se va a construir e incorporarlo dentro
de la arquitectura del sistema.
Cmo puedo est ar seguro de que lo he
h e c h o c o r r e c t a me n t e ? Mediante una revi-
sin de todos los productos de trabajo obteni-
dos, para verificar su claridad, si est completo
y es consistente. Es importante mencionar que
los cambios en los requisitos de un sistema
deben gestionarse con mtodos slidos de GCS
(captulo 27).
negoci os como la ingeniera de producto, 1 t rabaj an par a asi gnar un papel al soft wa-
re de comput ador a y, al mi smo tiempo, est abl ecer los enl aces que unen al soft ware
con ot ros el ement os de un si st ema bas ado en comput adora.
Este cap t ul o se cent rar en las necesi dades de gestin y en las act i vi dades espe-
cficas del proceso que permi t an a la organi zaci n de sof t war e asegurarse de hacer
las cosas correct as en el t i empo correct o y del modo correcto.
6 . 1 SI STEMAS BASADOS EN COMP UTADORA
La pal abra sistema tal vez sea el t rmi no m s usado y del que m s se abusa en el
lxico tcnico. Se habl a de si st emas polticos, si st emas educativos, de si st emas de
aviacin y si st emas de fabricacin, de si st emas bancari os y si st emas de l ocomoci n.
La pal abra dice muy poco. El adjetivo se utiliza par a describir el sistema y as ent en-
der el cont ext o en el que se usa la pal abra. El diccionario Webster define si st ema de
la siguiente maner a:
I. Un conj unt o o disposicin de cosas rel aci onadas que forman una uni dad o un t odo or-
gnico; 2. Una serie de hechos, principios, reglas, et ct era, clasificado y di spuest os de ma-
nera or denada que muest r an un plan lgico de la uni n de las partes; 3. Un mt odo o plan
de clasificacin o disposicin; 4. Una maner a est abl eci da de hacer algo; mt odo; procedi-
miento...
En el diccionario apar ecen cinco defi ni ci ones ms, pero no se sugiere un si nni mo
preciso. Sistema es una pal abra especial. Al ret omar la definicin del diccionario
Webster, un si st ema bas ado en comput ador a se define como:
Un conj unt o o disposicin de el ement os que est n or gani zados para cumplir una met a
predefinida al procesar informacin.
1 En realidad, el trmino ingeniera de sistemas se emplea con frecuencia en este contexto. Sin em-
bargo, para los propsitos de este libro "ingeniera de sistemas" es genrico y abarca la ingeniera
de procesos del negocio y la ingeniera de producto.
TM
PDF Editor
CAPITULO 6 INGENIERA DE SISTEMAS
135
^ O N S E J Q ^
r a d e be coer en lo
i de tener una
i 'centrodo en el
i'.Fara
'.deben
r todos los
i de un
i antes de
en el
Es posible que la met a sea apoyar una funci n de negoci o o desarrollar un produc-
t o que pueda venderse para generar beneficios. Para cumplir la met a, un si st ema
bas ado en comput ador a empl ea una vari edad de el ement os del si st ema:
Sof t wa r e . Programas de comput adora, est ruct uras de dat os y document aci n
que sirven para hacer efectivo el mt odo, procedi mi ent o o control lgico que se
requiere.
Ha r dwa r e . Dispositivos electrnicos que proporci onan capaci dad de clculo, dis-
positivos de interconexin (por ejemplo, conmut ador es de red, dispositivos de tele-
comuni caci n) que permi t en el flujo de dat os, y dispositivos el ect romecni cos (como
sensores, mot ores, bombas) que proporci onan una funci n ext erna, del mundo real.
Pe r s o n a s . Usuari os y oper ador es del har dwar e y soft ware.
Ba s e s d e d a t o s . Una ext ensa y organi zada recopilacin de i nformaci n a la cual
s e tiene acceso a t ravs de soft ware y que persi st e a t ravs del tiempo.
Do c u me n t a c i n . Informaci n descriptiva (por ejemplo, model os, especificacio-
nes, manual es, archi vos de ayuda en lnea, sitios web) que detalla el uso y operaci n
del si st ema.
Pr o c e d i mi e n t o s . Los pas os que defi nen el uso especfico de cada el ement o del
si st ema o el cont ext o de procedi mi ent o en que reside el si st ema.
Estos el ement os se combi nan de varias maner as para t ransformar la i nformaci n.
Por ejemplo, un depar t ament o de mercadot ecni a t ransforma la i nformaci n brut a de
vent as en un perfil del compr ador tpico del producto; un robot t ransforma un archi-
vo de r denes que cont i ene i nst rucci ones especficas en un conj unt o de seal es de
control que provocan alguna accin fsica especfica. La creacin de un sistema de infor-
macin para asesorar al depart ament o de mercadotecnia y un software de control para
el robot requiere de la ingeniera de sistemas.
"Nunca confes en una computadora que no puedas lanzar por la ventana."
Stcve Woiniak
K
CL/AVE
complejos
eafcdod una
s q u e a
i si st emas.
Una caracterstica compl i cada de los si st emas bas ados en comput adora es que tal
vez constituyen un macr oel ement o de un si st ema an mayor. El macroelemento es
un si st ema bas ado en comput ador a que es part e de un si st ema mayor bas ado t am-
bin en comput adora. Por ejemplo, un sistema de automatizacin de una ftbnca se
consi dera una j erarqu a de si st emas. En el nivel ms baj o de la jerarqua se encuen-
tra una mqui na de control numri co, robot s y dispositivos de ent r ada de i nforma
cin. Cada uno de st os es un si st ema bas ado en comput adora por der echo propio.
Los el ement os de la mqui na de control numri co incluyen har dwar e electrnico y
el ect romecni co (por ejemplo, procesador y memori a, mot ores, sensores), sof t war e
(para comuni caci ones y control de la mqui na), per sonas (el operador de la mqui -
na), una bas e de dat os (el pr ogr ama de CN al macenado), document aci n y proced-
TM
PDF Editor
1 3 6 P A R T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
mientos. Podra aplicarse una descomposi ci n similar al robot y al dispositivo de
ent r ada de i nformaci n. Todos son si st emas bas ados en comput adora.
En el si gui ent e nivel de la j erarqu a se defi ne una clula de fabricacin. sta es ur
si st ema bas ado en comput adora que puede t ener el ement os propi os (por ejemplo,
comput ador as, i nst al aci ones mecni cas), y t ambi n integra los macr oel ement os que
se han denomi nado mqui na de control numri co, robot y dispositivo de ent rada de
informacin.
En r esumen, la clula de fabricacin y sus macr oel ement os est n compuest os de
el ement os del si st ema con las et i quet as genri cas: soft ware, hardware, personas
bases de dat os, procedi mi ent os y document aci n. En al gunos casos los macroele-
ment os pueden compart i r un el ement o genrico. Por ejemplo, el robot y la mqui na
de CN podra operarl as el mi smo operador (el el ement o personas). En otros casos,
los el ement os genri cos son exclusivos de un si st ema.
El papel del ingeniero de si st emas es definir los el ement os de un si st ema espec-
fico basado en comput ador a en el cont ext o de la jerarqua global de si st emas
(macroel ement os). En las secci ones si gui ent es se exami nan las t ar eas que constitu-
yen la ingeniera de si st emas de comput ador as.
L H J E RARQU A P E LA I NGENI ER A PE SI STEMAS
Sin i mport ar su domi ni o de enfoque, la ingeniera de si st emas abarca una serie de
mt odos para navegar de arriba hacia abaj o y de abaj o haci a arriba en la jerarqua
ilustrada en la figura 6.1. El proceso de la ingeniera de si st emas por lo general
comi enza con una "visin global". Es decir, se exami na el domi ni o ent ero del nego-
cio o product o para asegurarse de que se puede est abl ecer el cont ext o tecnolgico
o de negoci os apropi ado. La visin global es refi nada para enf ocar se t ot al ment e en
un dominio especfico de inters. Dentro de un domi ni o especial se analiza la necesi-
dad de el ement os del si st ema (por ejemplo, informacin, soft ware, hardware, perso-
nas). Al final se inicia el anlisis, di seo y const rucci n del el ement o del si st ema
deseado. En la part e alta de la jerarqua se establece un cont ext o muy amplio, y en el
de la parte baja se conducen actividades tcnicas detalladas, real i zadas por la disci-
plina de ingeniera correspondi ent e (por ejemplo, ingeniera de hardware o software).2
Dicho de una maner a un poco ms formal, la visin global (VG) la compone un
conj unt o de domi ni os (D,) en donde cada uno de ellos puede ser un si st ema o un sis-
t ema de si st emas por derecho propio.
VG = (D D2, D3,.... Dn 1
Cada domi ni o lo componen elementos (E;) especficos, los cual es tienen un papel
para cumplir el objetivo y las met as del domi ni o o component e:
Tj s o e r de Sistemas
X5 S ) proporciona
M s t uert es tiles en
wwwj Kose. org.
\
CLVE
< x bueno ingeniera de
set eni os comi enza con
r ent endr ni ent o doro
del c o n t e x t o - l o visin
y despus, de
nuera progresiva, el
e v o q u e se delimita
osta lo comprensin
de los detalles tcnicos.
2
Sin embargo, en algunas situaciones los ingenieros del sistema deben considerar primero los ele-
mentos individuales del sistema. Mediante el uso de este enfoque, los subsistemas se describen de
abajo hacia arriba al considerar primero los componentes detallados que forman el subsistema.
TM
PDF Editor
CAPITULO 6 INGENIERA DE SISTEMAS
137
A' - I; / 2. 3, m )
Por ltimo, cada el ement o se i mpl ement a al especificar los componentes (Q) tcni-
cos que logran la funcin necesari a para un el ement o:
E = I C C2 , CA Cjtl
En el cont ext o de soft ware un component e podra ser un pr ogr ama de comput ado-
ra, un component e reutilizable de un programa, un mdul o, una clase u obj et o o
incluso un enunci ado en l enguaj e de programaci n.
"Siempre diseo los cosos considerndolos en su cont ext o inmediato superior: uno silla en un cuorto, un cuarto en una
casa, uno casa en un vecindario, un vecindario en un plan urbano."
Eliel S a a r i n e n
Es i mport ant e not ar que el i ngeni ero de si st emas est recha m s el enf oque de tra-
baj o conforme avanza hacia abaj o en la j erarqu a descrita. Sin embargo, la visin
global muest ra una clara definicin de la funcionalidad general que le permitir al
i ngeni ero ent ender el domi ni o y el si st ema o product o en el cont ext o apropi ado.
d e
d e
6.2.1 Model ado del si stema
El modelado de sistemas es un el ement o i mport ant e del proceso de ingeniera de sis-
t emas. Sin importar que el enf oque est en la visin global o en la visin detallada,
el ingeniero crea model os que [MOT92]:
Dominio de neg,
o de product o
Dominio de inters
Elemento del sistema
Vi s i n del e l e me n t o
~ i r n r ~ i r n r ~ i i 11 ~ ~ i
111111 TTf f l 1 11 I t r r d 111 I L L L UI I I I l z m
Vi s i n d e t a l l a d a
Visin del dominio
Vi s i n g l o b a l
TM
PDF Editor
Qu se
logro ton el
modelo de lo
ingeniera de
sistemas?
%
CLAVE
Un i ngeni ero d e
s i s t emas consi dera l os
si gui ent es f act or es al
det er mi nar sol uci ones
al t er nat i vas:
supuest os,
si mpl i fi caci ones,
l i mi t aci ones,
restricciones y
preferenci as del
cliente.
Definen los procesos que satisfacen las necesidades de la visin que se considera
Representen el comportamiento de los procesos y los supuestos en los que se
basa el comportamiento.
Definen de modo explcito las entradas exgenas3 y endgenas de informa-
cin al modelo.
Representan todas las uni ones (incluidas las salidas) que permiten al
ingeniero entender mejor la visin.
Al construir un modelo del sistema el ingeniero debe considerar algunas restricciones:
1. Supuestos que reducen el nmero de permut aci ones y variaciones posibles, lo
que permite al modelo reflejar el problema de una manera razonable. Por
ejemplo, un producto de representacin tridimensional que utiliza la industria
del entretenimiento para crear animaciones realistas. Un dominio del producto
permite la representacin de formas humanas en tres dimensiones. Las entra-
das a este dominio comprenden la habilidad de adaptar movimiento de un ac-
tor humano vivo, de un video o de la creacin de modelos grficos. El
ingeniero de sistemas hace ciertos supuestos sobre el intervalo de movimiento
humano permitido (por ejemplo, las piernas no pueden enrollarse alrededor
del torso) de modo que pueda limitarse el proceso y la gama de entradas.
2. Simplificaciones que permiten la creacin del modelo a tiempo. Para ilustrarlo
se puede considerar una compaa de productos de oficina que vende y sumi-
nistra una amplia variedad de fotocopiadoras, escneres y equipos similares.
El ingeniero de sistemas modela las necesidades de la organizacin suminis-
tradora y trabaja para entender el flujo de informacin que engendra una or-
den de suministro. Aunque una orden de suministro puede originarse desde
muchas fuentes, el ingeniero t oma en cuenta slo dos de ellas: la demanda
interna y la peticin externa. Esto permite una particin simplificada de entra-
das que se requiere para generar la orden de suministro.
3. Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se modela un sis-
t ema de aeronutica para un avin de prxima generacin. Como el avin
tiene un diseo de dos motores, el dominio de monitoreo para la propulsin
ser model ado para acomodar un mximo de dos mot ores y sus numerosos
sistemas asociados.
4. Restricciones que guan la manera de crear el modelo y t omar el enfoque al
implementarlo. Por ejemplo, la infraestructura tecnolgica para el sistema de
representacin tridimensional descrito ant es utiliza procesadores duales ba-
sados en G5. La complejidad de clculo de los problemas debe restringirse
para encajar en los lmites de proceso que imponen estos procesadores.
3 Las entradas exgenas unen un elemento de una visin dada con otros elementos en el mismo ni-
vel o en otros niveles; las entradas endgenas unen componentes individuales de un elemento en
una visin particular.
TM
PDF Editor
C A P T U L O 6 INGENIERA DE SISTEMAS
139
5. Preferencias que i ndi can la arqui t ect ura preferi da par a t odos los dat os, funci o-
nes y t ecnol og a. La sol uci n preferi da a veces ent ra en confl i ct o con ot ros
f act or es restrictivos. Sin embar go, la sat i sfacci n del cl iente muchas veces se
t oma en cuent a has t a el punt o de real i zar su enf oque preferi do.
El model o de si st ema resul t ant e (desde cual qui er visin) puede recl amar una sol u-
cin aut omt i ca por compl et o, semi aut omt i ca o un enf oque manual . De hecho, con
f r ecuenci a es posi bl e caract eri zar model os de cada t i po que si rvan como sol uci ones
al t ernat i vas del pr obl ema que se t i ene ent re manos . En esenci a, el i ngeni ero de sis-
t e mas t an sl o modi fi ca la infl uencia relativa de di ferent es el ement os del si st ema
(personas, har dwar e, soft ware) par a crear model os de cada tipo.
"Las c o s o s s i m p l e s d e b e n s e t s i m ) l e s . La s t o s a s c o m p l e j o s d e b e n s e r p o s i b l e s . "
Al a n Kay
6.2.2 Si mul aci n del si st ema
*
idelo
~ simulo-
i sistema
unentoel
'pmyecto.
rio
eutuar
x proceso
' el cual
rvn
mbolo en
i e r o a n , y
jzor oros
poro afinar
Muchos s i s t emas bas ados en comput ador a i nt eract an con el mundo real en forma
react i va. Es decir, los event os del mundo real l os moni t or ean el har dwar e y el soft -
war e que compone n el si st ema bas ado en comput ador a y, con base en est os even-
tos, el si st ema i mpone cont rol sobr e l as mqui nas, l os pr ocesos e i ncl uso sobr e la
gent e que gener a l os event os. Los si st emas de t i empo real y si st emas empot r ados a
me nudo per t enecen a la cat egor a de si st emas react i vos.
Muchos si st emas de la cat egor a de los react i vos cont r ol an mqui nas o pr oces os
(como aer ol neas comer ci al es o refi ner as de petrl eo) que deben oper ar con un
gr ado muy al t o de confi abi l i dad. Si el si st ema falla podr an ocurrir pr di das ccon
mi cas o huma na s significativas. Por est a r azn, el model ado del si st ema y las herra-
mi ent as de si mul aci n se ut i l i zan par a ayudar a el i mi nar sor pr esas cuando se cons-
truyen si st emas reactivos bas ados en comput adora. Estas herrami ent as se aplican
dur ant e el proceso de ingeniera de si st emas, cuando se especifica el papel del hard-
ware, el soft ware, las bases de dat os y las personas. El model ado y las herrami ent as de
simul acin permi t en al i ngeni ero de si st emas probar una especificacin del sistema.
Herramientas de simulacin del sistema
N
Ob j e t i vo : Las herramientas de simulacin del
sistema proporcionan al ingeniero de software
c capaci dad de predecir el comportamiento de un
esterna de tiempo real antes de que ste se construya.
Adems, estas herramientas permiten al ingeniero de
software desarrollar maquet as del sistema en tiempo
-al, lo que permite al cliente tener una visin del
funcionamiento, operacin y respuesta antes de la
implementacin real.
Me c n i c a : Las herramientas de esta categora permiten
al equi po definir los elementos de un sistema basado
en comput adoras, y despus ejecutar varias
simulaciones par a entender mejor las caractersticas
operacionales y el desempeo general del sistema.
Y
TM
PDF Editor
140 PARTE D OS PRCTICA DE LA INGENIERA DEL SOFTWARE
r
Existen dos ampl i as cat egor as d e si mul aci n del
si st ema: 1) her r ami ent as d e propsi t os gener al es q u e
pueden model ar d e ma ne r a virtual cual qui er si st ema
b a s a d o en comput ador as , y 2) her r ami ent as d e
propsi t os especi al es, q u e est n di s e a da s pa r a
empl ear l as en un domi ni o de apl i caci n espec fi ca
(como en si st emas d e aer ol neas, si st emas d e
manuf act ur a, sistemas electrnicos).
He r r a m i e n t a s r e p r e s e n t a t i va s 4
CSIM, desar r ol l ado por Lockheed Mart n Advance d
Technol ogy Labs [www. al l . ext emal . l nco. com), es un
si mul ador d e event os di scret os d e propsi t os gener al es
pa r a sistemas or i ent ados a di a gr a ma s d e edificios.
Simics, desar r ol l ado por Virtutech (www. virtutech. com), es
una pl at af or ma d e si mul aci n d e si st ema que pue de
model ar y anal i zar si st emas ba s a dos en ha r dwa r e y
sof t war e.
SIX, des ar r ol l ado por Wol veri ne Sof t war e
(www. wol veri ne. com), pr opor ci ona bl oques d e
const rucci n d e pr opsi t o gener al p a r a model ar el
de s e mpe o d e una ampl i a var i edad d e si st emas.
En ht t p: / / www. i ds i a. ch/ ~andr ea/ s i mt ool s . ht ml se pue de
encont r ar una seri e d e vnculos a var i as fuent es d e
si mul aci n de sistemas.
Cules
son las
r qar t er t ur as que
se definen y
desarrollan como
p r t e de la IPN?
La me t a de la ingeniera de procesos de negocios (IPN) e s defi ni r ar qui t ect ur as que per-
mi t an que un negoci o util ice i nf or maci n de ma n e r a efect i va. Cuando l as neces i da
de s de t ecnol og a de i nf or maci n de u na c ompa a s e obs e r van de ma ne r a gl obal
casi n o hay duda de que s e r equi er a la i ngeni er a de s i s t emas . No s l o s e r equi er e la
especi f i caci n de la ar qui t ect ur a de c mput o apr opi ada, s i no t ambi n s e de be des a-
rrol l ar la ar qui t ect ur a de s of t wa r e que puebl a la conf i gur aci n ni ca de f ue nt e s de
c mpu t o de la or gani zaci n. La i ngeni er a de pr oce s os de negoci os e s un e nf oque
que cr ea u n pl an gener al pa r a i mpl ement ar la ar qui t ect ur a de c mput o [SPE93],
Se de be n anal i zar y di s ear t r es ar qui t ect ur as di f er ent es dent r o del cont e xt o de
obj et i vos y me t a s de negoci os.
Ar qui t ect ur a de da t os
Ar qui t ect ur a de apl i caci ones
I nf r aest r uct ur a de la t ecnol og a
La arquitectura de datos pr opor ci ona un ma r c o de t r abaj o par a l as ne c e s i da de s de
i nf or maci n de un negoci o o de u na f unci n de negoci os . Los l adril l os de la arqui -
t ect ur a s on l os obj et os de da t os que ut i l i za el negoci o. Un obj et o de l os dat os c on-
t i ene un conj unt o de at r i but os que def i ne al gn as pect o, cual i dad, car act er st i ca o
descr i pt or de l os dat os que s e descr i ben.
Una ve z def i ni do u n c onj unt o de da t os s e i dent i fi can s us r el aci ones. Una relacin
i ndi ca la f or ma e n que l os obj et os e s t n cone ct ados ent r e s. Co mo e j e mpl o s e pue-
4 Las herramientas mostradas aqu son una muestra de esta categora. En la mayora de los casos los
nombres estn registrados por sus respectivos desarrolladores.
TM
PDF Editor
141
^ ONS E J O^
de
no debe
en PE I ni
Sin embargo,
i que estos
noseh an
el ingeniero
. oos
que el
m/ y o y e c l o e s
den cons i der ar l os obj et os c l i e n t e y p r o d uc t o A. Los dos obj et os pu e de n cone ct ar -
s e por la r el aci n compra-, e s deci r, un c l i e n t e compra p r o d uc t o A o p r o d uc t o A es
comprado por u n c l i e n t e . Los obj et os de da t os (que pu e de n exi st i r ci ent os o has t a
mi l es par a u na act i vi dad de ne goci os i mpor t ant e) fluyen ent r e f unci one s de negoci o,
e s t n or ga ni z a dos dent r o de u na ba s e de da t os y s e t r ans f or man par a of r ecer i nfor-
ma c i n que sat i sf ace l as ne c e s i da de s del negoci o.
La arquitectura de aplicacin abar ca aquel l os e l e me nt os de un s i s t ema que t r ans-
f or ma n obj et os dent r o de la ar qui t ect ur a de da t os por al gn pr ops i t o del negoci o.
En el cont ext o de est e l i bro s e consi der a que la ar qui t ect ur a de apl i caci n e s el si s-
t e ma de pr ogr a ma s (soft ware) que r eal i za est a t r ans f or maci n. Sin e mbar go, en un
cont ext o m s ampl i o, la ar qui t ect ur a de apl i caci n pue de i ncor por ar el papel de l as
pe r s ona s ( qui enes son t r ans f or mador e s y us uar i os de i nf or maci n) y pr ocedi mi ent os
de ne goci os que n o ha n s i do aut omat i zados .
La infraestructura tecnolgica pr opor ci ona el f u n d a me n t o par a l as es t r uct ur as de
da t os y d e apl i caci n. La i nf r aes t r uct ur a c ompr e nde el ha r dwa r e y el s of t wa r e con
q u e s e apoyan l as apl i caci ones y l os dat os. Est o i ncl uye c omput a dor a s , s i s t e mas de
oper aci n, r edes de comput ador a, enl aces de t el ecomuni caci ones, t ecnol og as de al ma-
c e na mi e nt o y la ar qui t ect ur a (por ej empl o, cl i ent e, servi dor) di s eada par a i mpl e-
me nt a r e s t a s t ecnol og as.
En la figura 6. 2 se def i ne e i l ust ra u na j er ar qu a de pr oc e s o de negoci os par a
mode l a r es t as ar qui t ect ur as de si st ema.
jerarqua
a d e l
d e
Ar ea de negoci o
La empr esa. Pl a n e a c i n
e s t r a t gi c a
d e l a i n fo r m a c i n
(vi s i n gl o b a l )
Pl a n e a c i n
e s t r a t gi c a
Pl a n e a c i n
e s t r a t gi c a
Requisito de pr oceso
Un r
neg
ea de
ocio
1 L
An l i s i s d e l
r e a d e
n e go c i o
(vi s i n d e
d o m i n i o )
Co n s t r uc c i n
e i n t e gr a c i n
(vi s i n
d e t a l l a d a )
In ge n i e r o
d e s o f t wa r e
11
TM
PDF Editor
142 C A P T U L O 6 INGENIERA DE SISTEMAS
^ CONSEJ O^ -
A menudo se utiliza
en este contexto el
modelo concurrente
del proceso ( captulo
3 ) . Coda disciplina de
ingeniera trabaja en
paralelo. Se ebe
estar seguro de que
se promueva la
comunicacin
mientras cada
disciplina desempe a
su trabajo.
La me t a de la ingeniera de producto e s t r aduci r el de s e o del cl i ent e, de u n a seri e de
c a pa c i da de s def i ni das, a un pr oduct o del t r abaj o. Par a cons egui r es t a me t a la inge-
ni er a de pr oduct o c omo la i ngeni er a de pr oc e s os de negoci os de be cr ear una
ar qui t ect ur a y una est r uct ur a. La ar qui t ect ur a abar ca cuat r o c o mp o n e n t e s de si st e-
ma di st i nt os: s of t war e, har dwar e , dat os (y ba s e s de dat os) y pe r s onas . Se est abl ece
u na i nf r aest r uct ur a de s opor t e e i ncl uye la t ecnol og a r equer i da par a uni r l os com-
pone nt e s y la i nf or maci n ( como doc ume nt os , CD-ROM, vi deo) que s e e mpl e a para
dar s opor t e a l os c ompone nt e s .
Como lo mues t r a la figura 6.3, la visin gl obal s e cons i gue me di ant e la i ngeni er a
de r equi si t os (cap t ul o 7). Los r equi si t os gener al es del pr oduct o s e obt i enen del clien-
te. Est os r equi si t os c ompr e nde n ne c e s i da de s de i nf or maci n y cont r ol , f unci onal i dad
del pr oduct o y compor t ami ent o, d e s e mp e o gener al del pr oduct o, di s eo, restric-
ci ones de la i nt er f az y ot r as ne c e s i da de s especi al es. Una vez que s e c onoc e n est os
r equi si t os, el t r abaj o de la i ngeni er a de r equi si t os e s as i gnar f unci n y compor t a-
mi e nt o a cada u n o de l os cuat r o c ompone nt e s a nt e s descr i t os.
Una vez he c ha la as i gnaci n c omi e nz a la i ngeni er a de c o mp o n e n t e s del si st ema.
La i ngeni er a de c ompone nt e s del s i s t ema e s en r eal i dad u n c onj unt o de act i vi dades
c onc ur r e nt e s que di ri ge por s e pa r a do cada u n o de l os c o mp o n e n t e s del si st ema
i ngeni er a de s of t war e, i ngeni er a de har dwar e , i ngeni er a h u ma n a e i ngeni er a de
La j e r a r qua d e
l a i nge ni e r a d e
p r o d uc t o s .
Ha r dwa r e
Ca pa c i da de s
Sof t war e
Requisito d e pr oceso
In ge n i e r a d e
c o m p o n e n t e
(vi s i n d e
d o m i n i o )
Dat os Funcin
Compor-
t ami ent o
1 1 1
m i ITT
Mo d e l a d o d e
a n l i s i s y d i s e o
(vi s i n d e l
e l e m e n t o )
Co m p o n e n t e s
d e p r o gr a m a
Co n s t r uc c i n
e i n t e gr a c i n
(vi s i n
d e t a l l a d a )
In ge n i e r o
d e s o f t wa r e
El product o
compl et o
In ge n i e r a d e
r e qui s i t o s
TM
PDF Editor
143
ba s e s de dat os. Cada u na de e s t a s di sci pl i nas de i ngeni er a t oma una vi si n de domi -
ni o espec fi ca, per o e s i mpor t ant e s e al ar que l as di sci pl i nas de i ngeni er a de be n
es t abl ecer y ma nt e ne r una comuni caci n act i va ent r e el l as. Part e del papel de la
i ngeni er a de r equi si t os e s es t abl ecer l os me c a ni s mos de i nt er f az que per mi t an que
e s t o s uce da.
La visin de e l e me nt o par a la i ngeni er a de pr oduct o e s la di sci pl i na de i ngeni e-
ra apl i cada a un c ompone nt e as i gnado. Par a la i ngeni er a de s of t wa r e e s t o si gni fi ca
act i vi dades de mode l a do del anl i si s y di s eo (cubi ert o en det al l e e n cap t ul os pos -
t eri ores) y act i vi dades de const r ucci n y despl i egue que abar can: gener aci n de
cdi go, pr ue ba s y tareas" de sopor t e. Los mode l os de anl i si s de t a r e a s as i gnan requi -
si t os a l as r e pr e s e nt aci one s de dat os, f unci n y compor t ami e nt o. El di s eo convi er -
t e el mode l o de anl i si s en di s eos de dat os, ar qui t ect ni cos, d e i nt er f az y e n el ni vel
de c ompone nt e s del s of t war e.
HOGARSEGURO
Ingeniera de sistema preliminar
El e s c e n a r i o : Lugar de t rabaj o
: de ingeniera del software despus de la una
e> inicio de HogarSeguro
s : Jamie Lazar, miembro del equi po de
Vinod Raman, miembro del equi po de
Ed Robbins, miembro del equi po de software,
r s a c i n :
3 que estuvo muy bien.
S pero todo lo que hicimos fue ver el sistema
general; todava tenemos que reunir muchos
par a hacer el software.
Por eso tenemos juntas adicionales
s en los prximos cinco das. Por cierto,
aue dos de los "dientes" estuvieran aqu en las
semanas. Ya sabes, que estn con nosotros
zoe podamos comunicarnos en realidad y
. Y qu opinaron los dems?
Bueno, me miraron como si estuviera loco, pero
[el gerente de ingeniera del software] le gust la
- es gi l - as que est habl ando con ellos.
io est aba t omando notas con mi PDA durante la
v obtuve uno lista de funciones bsicas.
Qu bien, dj ame ver.
Ed : Ya les mande a los dos una copia por correo
electrnico. Revsenla y luego habl amos
Vi n o d : Qu te par ece despus de la comi da?
(Jamie y Vinod recibieron el siguiente texto de Ed.)
Notas preeliminares de la estructura/funcional idad de
HogarSeguro:
El sistema utilizar una o ms PC. varios panel es de
control manual es y montables en la par ed, varios
sensores y varios controladores de
d i s p o s i t i v o s / a p l i c a c i o n e s .
Todos se comunicarn por protocolos inalmbricos
(por ejemplo, 802. 1 Ib) y sern di seados par a la
construccin efe casas nuevas y la aplicacin en casas
existentes.
Todo el hardware, a excepcin de nuestra nueva caj o
inalmbrica, estar fuera del anaquel
Funcionalidad bsica del software obt eni da de la
conversacin de inicio.
Funciones de seguridad de la casa:
Sensor de movimiento de puert a/ vent ana par a
monitorear un acceso no aut ori zado (robos).
Moni toreo de fuego y humo
Monitoreo de nivel de agua en stano (por ejemplo,
inundocin o rompimiento del calentador de aguo).
TM
PDF Editor
Monitoreo d e movimiento en el exterior.
Cambi o de colocacin de seguri dad por Internet.
Funciones de vigilancia en la casa:
Conect ar a una o ms cmar as de vi deo col ocadas
f uer a/ dent r o de la casa.
Controlar pa nor a ma / z oom en las cmar as.
Definir zonas de monitoreo de las cmar as.
Mostrar t omas d e la cmar a en PC.
Tener acceso a las t omas d e la cmar a va Internet.
Gr abar digital y selectivamente las t omas de b
cmar a.
Most rar d e nuevo las t omas de la cmar a.
Funciones de l a gestin de la casa:
Controlar al umbr ado.
Controlar instrumentos.
Controlar HVAC.
Controlar equi po de audi o/ vt deo en la cas a
Habilitar la cas a dent ro de una modal i dad
"vacaci ones/ vi aj e" con un conjunto de bot ones:
Disponer apar at os / al umbr ado/ HVAC p a r a que
acten de maner a apr opi ada
Disponer un mensaj e en la mqui na cont est adora.
Cont act ar vendedor es pa r a suspender ent r ega de
peridicos, correo, etctera.
Funciones de la gestin d e comunicacin:
Funciones de la mqui na cont est adora.
Lista de l l amadas a travs d e un identificador.
Hora del mensaj e.
Texto del mensaj e a travs de un sistema d e
reconocimiento de voz.
Funciones del cor r eo electrnico (t odas las funciones
est ndares del cor r eo electrnico).
Most rar correo electrnico est ndar
Lectura de voz por correo electrnico va acceso
telefnico.
Directorio telefnico personal .
Vnculo con el PDA.
Ot r as funciones:
Por definirse.
Todas las funciones sern accesibles va Internet con
una cont rasea apr opi ada como proteccin.
6 . 5 MODE L ADO DEL SI STEMA
Debido a que un si st ema puede represent arse con di ferent es gr ados de abstraccin
(por ej empl o, la visin global, la visin de dominio, la visin de el ement o), los mode-
los de sistema t i enden a ser j errqui cos o estratificados por nat ural eza. En la parte
m s alta de la jerarqua se pr esent a un model o del si st ema compl et o (la visin glo-
bal) . Los obj et os principal es de dat os, l as funci ones de pr ocesami ent o y l os compor-
t ami ent os se represent an sin incluir el component e del si st ema que i mpl ement ar
l os el ement os del model o de visin global. A medi da que la jerarqua se refina o
estratifica se model a el detal l e al nivel de component es (en est e caso, represent a-
ci ones de hardware, soft ware, etctera). Al final, los model os de si st emas evolucio-
nan a model os de ingeniera (los cual es se refinan despus) que son especficos para
la disciplina de ingeniera apropi ada.
6.5.1 Model ado Hatley-Pirbhcri
Todo si st ema basado en comput ador a puede model arse como t ransformaci n de la
i nformaci n al empl ear una plantilla de ent rada-proceso-sal i da. Hatley y Pirbha;
[HAT87] han ampl i ado esta visin par a incluir dos caract er st i cas adi ci onal es del sis-
t ema: pr ocesami ent o de la i nt erfaz del usuari o y mant eni mi ent o y pr ocesami ent o de
TM
PDF Editor
C A P I T U L O 6 INGENIERA DE SISTEMAS
1 4 5
K
CLAVE
i - e p c e s e n t a l o
i.el
> y l o
) t o n l o
r d e l us ua r i o y
/
aut ocompr obaci n. Aunque e s t a s car act er st i cas adi ci onal es n o est n pr e s e nt e s en
t odos los s i s t e mas ba s a dos e n c omput a dor a , s on c omu ne s y su especi f i caci n ha c e
que cual qui er mode l o de s i s t ema s ea m s r obust o.
Con el us o de la r epr es ent aci n de ent r ada, pr oces ami ent o, sal i da, pr oc e s a mi e n-
t os de la i nt er f az del us uar i o y pr oc e s a mi e nt o de aut ocompr obaci n, u n i ngeni er o de
s i s t e mas pue de cr ear un mode l o de c o mp o n e n t e s de si st ema que dej e un f unda-
me nt o par a e t a pa s post er i or es e n cada u na de l as di sci pl i nas de i ngeni er a.
En el desar r ol l o de un mode l o de s i s t ema s e utiliza u na pl ant i l l a mode l o del si s-
t e ma [HAT87]. El i ngeni er o de s i s t e mas as i gna e l e me nt os de si st ema a cada una de
l as ci nco r egi ones de pr oc e s a mi e nt o dent r o de la pl antil l a: 1) i nt er f az del usuar i o, 2)
ent r ada, 3) f unc i ona mi e nt o y cont rol del si st ema, 4) sal i da, y 5) ma nt e ni mi e nt o y
a ut oc ompr oba c i n.
Al igual que casi t oda s l as t cni cas de mode l a do ut i l i zadas en la i ngeni er a de si s-
t e ma s y de s of t war e, la pl ant i l l a mode l o del s i s t ema le per mi t e al anal i st a cr ear u na
j er ar qu a en det al l e. En el ni vel m s al t o de la j er ar qu a es t el diagrama de contexto
del sistema (DCS). El di agr ama de cont ext o "est abl ece l os l i mi t es de i nf or maci n
ent r e el s i s t ema que i mpl e me nt a y el a mbi e nt e en el que oper a el s i s t ema" [HAT87].
Es decir, el DCS def i ne t odos l os pr oduct or e s ext er nos de i nf or maci n que el si st e-
ma util iza, t odos l os c ons umi dor e s e x t e mo s de i nf or maci n que el s i s t ema crea, y
t oda s l as e nt i dade s que se c omuni c a n a t r avs de la i nt er f az o r eal i zan mant e ni -
mi e nt o y aut ocompr obaci n.
Par a i l ust rar el us o del DCS s e cons i der ar u n sistema de clasificacin de cinta
transportadora (SCCT) descr i t o en la si gui ent e decl ar aci n (un t a nt o conf usa) de
obj et i vos:
El SCCT debe desarrollarse de manera que las cajas que se mueven a lo largo de la cinta
transportadora sean identificadas y ordenadas en uno de los seis contenedores al final de
la cinta. Las cajas pasarn a travs de una estacin clasificadora, donde se identificarn.
Con base en un nmero de identificacin impreso en un lateral tle la caja y un coillyo de
barras, las cajas se mandarn a los contenedores apropiados. Las cajas pasan en un or-
den aleatorio y estn igualmente espaciadas. La linea se mueve con lentitud.
Una computadora de escritorio localizada en la estacin clasificadora ejecuta todo el
software del SCCT, interacta con el lector de cdigo de barras para leer nmeros de parte
en cada caja, interacta con el equipo de monitoreo de la lnea transportadora para obte-
ner la velocidad de la linea transportadora, almacena todos los nmeros de parte clasifi-
cados, interacta con un operador de la estacin clasificadora para producir varios
reportes y diagnsticos, manda seales de control al hardware para clasificar las cajas, y
se comunica con un sistema de automatizacin central de la fbrica.
El DCS par a el SCCT s e mue s t r a e n la figura 6. 4. El di a gr a ma s e di vi de en ci nco s eg-
me nt os pri nci pal es. El s e gme nt o de arriba r epr esent a el pr oces ami ent o de la i nt er f az
del usuar i o, y l os s e gme nt os de la i zqui er da y de la der echa mue s t r an el pr oces a-
mi e nt o de e nt r ada y de sal i da, r es pect i vament e. El s e gme nt o cent r al cont i e ne f un-
ci ones de cont rol y pr oces o, y el s e gme nt o de a ba j o s e enf oca en el ma nt e ni mi e nt o
TM
PDF Editor
Di a gr a m a d e
c o n t e xt o d e l
s i s t e m a d e l
SCCT.
y la aut ocomprobaci n. Cada caj a que se muest ra en la figura represent a una enti-
dad externa-, es decir, un product or o consumi dor de i nformaci n del si st ema. Por
ejempl o, el lector de cdigo de barras produce i nformaci n que es introducida al sis-
t ema SCCT. El smbol o para el si st ema compl et o (o, a nivel es m s baj os, subsi st emas
principales) es un rect ngul o con l as esqui nas redondeadas. Por lo t ant o, el SCCT se
represent a en la regin de pr ocesami ent o y control al cent ro del DCS. Las fl echas eti-
quet adas que se muest r an en el DCS represent an i nformaci n (datos y control) que
va de un ambi ent e ext erno haci a el si st ema SCCT. La ent i dad ext erna lector de cdi-
go de barras produce ent rada de i nformaci n et i quet ada como cdi go de barras. En
esenci a, el DSC col oca cual quier si st ema en el cont ext o del ambi ent e ext erno.
El ingeniero de si st emas refina el di agrama de cont ext o de arqui t ect ura al estu-
diar con ms detalle el rect ngul o sombr eado de la figura 6.4. Se identifican los sub-
si st emas principal es que permi t en funci onar al si st ema clasificador de cinta t rans-
port adora dent ro del cont ext o definido por el DCS. Los subsi st emas principal es se
defi nen en un diagrama de flujo del sistema (DFS) que se obt i ene del DCS. El flujo de
i nformaci n a t ravs de las regi ones del DCS se utiliza para gui ar al ingeniero de sis-
t emas en el desarrol l o del DFS, un esquema m s det al l ado del SCCT. El di agrama de
flujo del si st ema muest ra los subsi st emas principales y el flujo de l as l neas de infor-
maci n i mport ant es (datos y control). Adems, la plantilla del si st ema divide el pro-
ceso del subsi st ema en cada una de l as cinco regi ones de pr oceso pr evi ament e estu-
diadas. En est e punt o, cada uno de los subsi st emas puede cont ener uno o ms ele-
ment os del si st ema (por ejempl o, hardware, soft ware, personas) tal y como los ha
asi gnado el i ngeni ero de sistemas.
TM
PDF Editor
C A P T U L O 6 INGENIERA DE SISTEMAS 147
Di agr ama de flujo de ms al t o nivel de lo arqui t ect ura
DFS de A
DFS de C
El di agr ama de fl uj o del s i s t ema (DFS) inicial s e convi er t e en el n o d o super i or de
u na j er ar qu a de DFS. Cada r ect ngul o r e donde a do del DFS ori gi nal pu e de e xpan
di rse en ot r a pl ant i l l a de ar qui t ect ur a dedi cada a ella en f or ma excl usi va. Est e pr o-
c e s o s e i l ust ra de ma ne r a e s que mt i ca en la fi gura 6.5. Cada uno de los DFS del si s-
t e ma puede ut i l i zarse c o mo punt o de par t i da de s ubs i gui ent es f as es de i ngeni er a
par a el s ubs i s t e ma que se descr i be.
En l os subsi gui ent es t r abaj os de i ngeni er a s e pue de n especi f i car (delimitar) l os
s ubs i s t e ma s y la i nf or maci n que fl uyen ent r e el l os. Un r el at o descr i pt i vo de cada
s ubs i s t ema y u na def i ni ci n de t odos l os da t os que fl uyen ent r e l os s ubs i s t e ma s s on
e l e me nt os i mpor t ant e s de la especi f i caci n del si st ema.
6.5.2 Model ado del si st ema con UML
El UML pr opor ci ona u na cant i dad i mpr es i onant e de di agr amas que pue de n util izar-
s e par a el anl i si s y di s eo al ni vel de s of t wa r e y del s i s t ema. 5 Para el SCCT s e mode -
lan cuat r o e l e me nt os i mpor t ant e s del si st ema: 1) el ha r dwa r e que per mi t e el SCCT;
2) el s of t wa r e que i mpl ement a el a c c e s o a la ba s e de dat os y la cl asi fi caci n; 3) el
oper ador que acat a var i as pet i ci ones del s i s t ema; y 4) la ba s e de da t os que cont i ene
i nf or maci n r el evant e del cdi go de bar r as y el dest i no.
5 En los captulos del 8 al 11 se presenta una exposicin ms detallada de los diagramas de UML. Para
una exposicin completa del UML el lector interesado debe consultar [SCH02], [LAR01] o [BEN99],
TM
PDF Editor
148 P ART E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
D i a g r a m a d e
d e s p l i e g u e
d e l h a r d w a r e
d e SCCT.
En wwwj o t i o i wi .
t o r o / t i m l / n d e x.
j s p s e puede
e s p e k o c w com pleta
de lo s m t W r a y
sem ntico del UML
p oster iofes).
El ha r dwa r e del SCCT s e pue de mode l a r en el ni vel del s i s t ema me di a nt e u n dia-
grama de despliegue de UML, c o mo s e i l ust ra e n la figura 6. 6. Cada caj a t r i di mensi o-
nal mue s t r a u n e l e me nt o del ha r dwa r e que e s par t e de la ar qui t ect ur a fsica del si s-
t ema. En al gunos cas os , l os e l e me nt os del ha r dwa r e t endr n que di s ear s e y cons -
t rui rse c o mo par t e del pr oyect o. Sin e mbar go, en mu c h o s c a s os l os e l e me nt os del
ha r dwa r e s e pue de n adqui ri r ya const r ui dos. El r et o par a el equi po de i ngeni er a es
r eal i zar la i nt er f az de l os e l e me nt os del ha r dwa r e de ma n e r a apr opi ada.
Los e l e me nt os del s of t wa r e pa r a el SCCT s e pue de n model ar e n una var i edad de
f or ma s me di ant e el u s o de UML. Los a s pe c t os de pr ocedi mi ent o del s of t wa r e del
SCCT s e pue de n r e pr e s e nt ar me di ant e un diagrama de actividad (figura 6.7). Esta
not aci n del UML e s si mi l ar al di agr ama de flujo y s e ut i l i za par a r epr es ent ar lo que
s ucede mi e nt r as el s i s t ema r eal i za s us f unci ones . Los r ect ngul os r e donde a dos
i mpl i can u na f unci n espec f i ca del s i s t ema; l as flechas r e pr e s e nt an el flujo a t r avs
del s i s t ema; el r ombo de deci si n r e pr e s e nt a u na deci si n r ami f i cada (cada flecha
que sal e del r ombo es t et i quet ada) ; l as l neas sl i das hor i zont al es i mpl i can la r ea-
l i zaci n de act i vi dades en par al el o.
Ot ra not aci n de UML que s e pue de us ar par a mode l a r s of t wa r e e s el diagrama de
clase (j unt o c on mu c h o s di agr amas r el aci onados con l as cl ases que se e xa mi na n en
a pa r t a dos pos t er i or es de est e libro). En el ni vel de la i ngeni er a del s i s t ema l as cl a-
s es 6 s e ext r aen e n un e nunci ado del pr obl ema. Par a el SCCT l as cl ases candi dat as
6 En captulos anteriores se destac que una clase representa un conjunto de entidades que forman
parte del dominio del sistema. El sistema puede almacenar o transformar estas entidades o pueden
servir como un productor o consumidor de la informacin que el sistema produce.
TM
PDF Editor
C A P I T U L O 6 INGENIERA DE SISTEMAS
149
podr an s er de: c a j a , l n e a d e c o n d uc c i n , l e c t o r d e c d i g o d e b a r r a s , c o n t r o -
l a d o r d e m a n i o b r a s , s o l i c i t ud d e l o p e r a d o r , r e p o r t e , p r o d uc t o y ot ras. Cada
cl ase encaps ul a un conj unt o de at r i but os que r epr es ent a t oda la i nf or maci n ne ce s a-
ria acer ca de la cl ase. Una descr i pci n de cl ase t ambi n cont i ene un conj unt o de ope-
r aci ones que s e apl i can a la cl ase en el cont ext o del s i s t ema SCCT. En la figura 6.8 s e
mue s t r a un di agr ama de cl ase de UML la cl ase c a j a .
El ope r ador del SCCT se pue de model ar con un di agr ama de UML de t i po c a s os
de us o c o mo s e mues t r a en la fi gura 6. 9. El di agr ama de c a s o de us o i l ust ra la f or ma
en la que un act or (en e s t e c a s o el oper ador que s e r epr es ent a con u na figura a dhe -
rida) i nt er act a con el si st ema. Cada val o et i quet ado dent r o de la caj a (la cual
r epr es ent a la f r ont er a del s i s t ema SCCT) i mpl i ca un c a s o de us o un es cenar i o
escr i t o que descr i be u na i nt er acci n con el s i s t ema.
Producir la
\ enr r ada del
^ Co n d u c t o r d e t e n i d o
5
Co n d u c t o r n movi mi e nt o
c
Obt ener estatus
5 operaci n
)(
Leer el c d i g o ^ ( Obt ener el estatus
de bar r as J y del conductor
D
Cdi go de barras
invlido
TM
PDF Editor
150
P A P T E D O S PRACTICA DE LA INGENIERA DEL SOFTWARE
Di a gr a m a d e
c l a s e d e UML
p a r a l a c l a s e
c a j a .
Co j a '
cdi go de bar r as
vel oci dad haci a del ant e
ubi caci n del conduct or
altura
profundi dad
peso
cont eni do
atributos
Nombr e de la cl ase
lectura del cdi go
de bar r as! )
act ual i zaci n
de vel oci dad))
lectura de vel oci dad!)
act ual i zaci n
de la ubi caci n!)
lectura de ubi caci n!)
obtencin de di mensi ones!)
pobt enci n del pes o( )
verificacin de cont eni do!)
Atributos
Oper aci ones
(los parntesis
al final del nombre
indican la lista de
atributos que requi ere
la operaci n)
TM
PDF Editor
CAPTULO 6 INGENIERA DE SISTEMAS
151
Herramientas de modelado de sistemas
Ob j e t i vo : Las herramientas de model ado de
^ sistemas proporcionan al ingeniero de software
c opa c i da d de modelar todos los elementos de un
j sS>ema bas ado en comput adoras al usar una notacin
| especfica par a la herramienta.
c n i c a : Las mecnicas de las herramientas var an.
lo general, las herramientas de esta categora ayudan
a rigeniero de sistemas a modelar 1) la estructura de
I saos los elementos funcionales del sistema; 2) el
| comportamiento esttico y dinmico del sistema; 3) la
uf uz mquina-humano.
He r r a m i e n t a s r e p r e s e n t a t i va s 7
describe, desarrol l ado por Embarcadero Technologies
I --w embarcadero. com), es una adapt aci n de
I -errami ent as de model ado basadas en UML que puede
i - pr es ent ar sistemas de software o sistemas completos.
Rational XDE and Rose, desarrol l ado por Rational
Technologies (www.rational.com), proporciona una
adapt aci n basada en UML de herramientas de
desarrollo y model ado par a sistemas basados en
comput adoras, la cual se utiliza de manera ampl ia.
Real-Time Studio, desarrol l ado por Artisan Software
(www.artisansw.com) es una conjunto de herramientas
de model ado y desarrollo que dan soporte al
desarrollo de sistemas en tiempo real.
Telelog ic Tau, desarrol l ado por Telelogic
(www.telelogic.com), es un conjunto con herramientas
basadas en UML que da soporte al model ado de
diseo y anlisis, y tiene vnculos con caractersticas de
construccin de software.
Un si sl ema de al t a t ecnol og a c ompr e nde var i os c ompone nt e s : har dwar e , s of t war e,
pe r s onas , ba s e s de dat os y pr ocedi mi ent os . La i ngeni er a de s i s t e mas ayuda a t r a-
duci r l as ne c e s i da de s del cl i ent e e n u n mode l o de s i s t ema que e mpl e a u n o o m s de
e s t os c ompone nt e s .
La i ngeni er a de s i s t e mas c omi e nz a al adopt ar una "visin gl obal ". Se anal i za el
domi ni o del negoci o o pr oduct o par a est abl ecer t odos l os r equi si t os bsi cos. El enf o-
que s e r educe e nt onc e s a u na "vi si n de domi ni o", donde cada u n o de. l os e l e me n
t os del s i s t ema s e anal i za en f or ma i ndi vi dual . Cada e l e me nt o s e as i gna a u n o o m s
c ompone nt e s de i ngeni er a, l os cual es s e es t udi an apl i cando la di sci pl i na de i nge-
ni er a cor r espondi ent e.
La i ngeni er a del pr oce s o de negoci os e s un e nf oque de la i ngeni er a de s i s t e mas
me di ant e el cual s e def i nen ar qui t ect ur as que per mi t an a un negoci o ut i l i zar la i nfor-
ma c i n de ma n e r a ef i caz. El obj et i vo de la i ngeni er a del pr oc e s o de negoci os e s
cr ear u na ar qui t ect ur a de dat os , u na ar qui t ect ur a de apl i caci n y u na i nf r aest r uct u-
ra de t ecnol og a compr ens i bl es que sat i sf agan l as ne c e s i da de s de la est r at egi a de
negoci o y l os obj et i vos y me t a s de cada r e a del negoci o.
La i ngeni er a de pr oduct os e s un e nf oque de la i ngeni er a de s i s t e mas que
c omi e nz a con el anl i si s del si st ema. El i ngeni er o de s i s t e ma s i dent i fi ca l as neces i -
7 Las herramientas mostradas aqu son una muestra dentro de esta categora. En la mayora de los
casos los nombres estn registrados por sus respectivos desarrolladores.
TM
PDF Editor
1 5 2 P ART E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
da de s del cl i ent e, de t e r mi na la fact i bi l i dad e c onmi c a y t cni ca, y as i gna f unci ones
y r e ndi mi e nt os al s of t war e, el har dwar e , l as pe r s ona s y l as ba s e s de dat os; e s decir
a l os c o mp o n e n t e s cl ave de la i ngeni er a.
[BEN991 Bennett, S., S. McRobb y R. Farmer, Object-Oriented Systems A nalysis and Design Ustg
UML, McGraw-Hill, 1999.
[HAR93] Hares, J. S., Information E ngineeringfor A dvanced Practitioner, Wiley, 1993, pp. 12-13.
[HAT87] Hatley, D.). e I. A. Pirbhai, Strategies for Real-Time System Specification, Dorset House
1987.
[LAR01] Larman, C., A pplying UML and Pattems: A n Introduction to Object-Oriented A nalysis and
Design and [h e Unifed Process, 2a. ed Prentice-Hall, mayo de 2001.
[MAR901 Martin, J. Information E ngineering: Book IIPlanning and A nalysis, Prentice-Hall, 1990.
[MOT92] Motamarri, S., "Systems Modeling and Description", en Software E ngineering Notes, ve
17, nm. 2, abril de 1992, pp. 57-63.
|SCH02)Schmuller,)., Teach YourselfUML in 24 Hours, 2a. ed., Sams Publishing, 2002.
[SPE93] Spewak, S., E nterprise A rch itecture Planning, QED Publishing, 1993.
[THA97] Thayer, R. H. y M. Dorfman, Software Requirements E ngineering, 2a. ed., IEEE Computer
Society Press, 1997.
6. 1. Encontrar tantos sinnimos como se pueda de la palabra "sistema". Buena suerte!
6. 2. Construir un "sistema de sistemas" jerrquico para un sistema, producto o servicio con el
cual se est familiarizado. La jerarqua se debe extender hasta los elementos simples del siste-
ma (hardware, software, etctera) de al menos una rama de cada estructura.
6. 3. Seleccionar un sistema o producto grande con el que est familiarizado. Definir el conjun-
to de dominios que definan la visin global del sistema o producto. Describir el conjunto de ele-
mentos que componen uno o dos de los dominios. Para un elemento, identificar los compo-
nentes tcnicos que deben desarrollarse.
6. 4. Seleccionar algn sistema o producto grande con el cual est familiarizado. Establecer las
suposiciones, simplificaciones, limitaciones, restricciones y preferencias que se deberan hacer
para construir un modelo de sistema de modelo eficaz (y realizable).
6. 5. La ingenieria de procesos del negocio requiere definir datos, arquitectura de aplicaciones,
adems de una infraestructura de aplicaciones. Describir cada uno de estos trminos mediante
un ejemplo.
6. 6. Un ingeniero de sistemas puede tener una de tres procedencias: el desarrollo de sistemas,
el cliente o una organizacin externa. Discutir los pros y los contras de cada procedencia
Describir un ingeniero de sistemas "ideal".
6. 7. El profesor entregar una descripcin de alto nivel de un sistema o producto basado en
computadoras.
a) Desarrollar un conjunto de preguntas que se debera realizar como ingeniero de siste-
mas.
b) Proponer al menos dos ubicaciones diferentes para el sistema con base en las respues-
tas a sus preguntas.
c) En clase, comparar sus ubicaciones con las de sus compaeros.
6. 8. Desarrollar un diagrama de contexto del sistema para el sistema basado en computado-
ras que se haya elegido (o uno asignado por su profesor).
TM
PDF Editor
153
6. 9 Aunque la informacin hasta este punto est muy entrecortada, trtese de desarrollar un
diagrama de desarrollo, un diagrama de actividad, un diagrama de clase y un diagrama de caso
de uso con UML para el producto HogarSeguro.
6. 10. Realizar una investigacin bibliogrfica y escribir un documento breve que describa
cmo funcionan las herramientas de modelado y simulacin. Alternativa: recopile bibliografa
de dos o ms vendedores de herramientas de modelado y simulacin y evale sus similitudes y
diferencias.
6. 11. Existen caractersticas de un sistema que no se puedan establecer durante las activida-
des de la ingeniera de sistemas? Describir las caractersticas, si existen, y explicar por qu su
consideracin se debe retrasar a fases posteriores del desarrollo.
6. 12. Existen situaciones en las que la especificacin formal del sistema se pueda abreviar o
eliminar por completo? Expliqese la respuesta.
OT RAS LECTURAS Y FUENTES DE I NF ORMACI N
Los libros de Hatley y sus colegas (Processfor Systems A rch itecture and Requirements E ngineering,
Dorset House, 2001), Buede {Th e E ngineering Design of Systems: Models and Meth ods, Wiley,
1999), Weiss y sus colegas (Software Product-Une E ngineering, Addison-Wesley, 1999),
Blanchard y Fabrycky (System E ngineering and A nalysis, 3a. ed., Prentice-Hall, 1998), Armstrong
y Sage (Introduction lo Systems E ngineering, Wiley, 1997), y Martin (Systems E ngineering
Guidebook, CRC Press, 1996) presentan el proceso de la ingeniera del sistema (con un nfasis
distinto en la ingeniera) y proporcionan una gua muy valiosa. Blanchard ( System E ngineering
Management, segunda edicin, Wiley, 1997) y Lacy ( System E ngineering Management, McGraw-
Hill, 1992) exponen aspectos de gestin de la ingeniera del sistema.
Chorafas ( E nterprise A rch itecture and New Generation Systems, St. Lucie Press, 2001) presen-
ta ingeniera de informacin y arquitecturas de sistema para la "siguiente generacin" de solu-
ciones de TI; se incluyen sistemas basados en Internet. Wallnau y sus colegas (Building Systems
from Comercial Componennts, Addison-Wesley, 2001) se enfoca en los aspectos de la ingeniera
de sistemas basada en componentes para productos y sistemas de informacin. Lozinsky
( E nterprise-Wide Software Solutions: Integration Strategies and Practices, Addison-Wesley, 1998)
abarca el uso de paquetes de software como una solucin que permite a las compaas pasar
de los sistemas heredados a los procesos de negocio modernos. Una exposicin muy valiosa del
riesgo y la ingeniera del sistema se presenta en el libro de Bradley ( E limination of Risk in
Systems, Tharsis Boooks, 2002).
Davis ( Business Process Modeling with A ris: A PracticaI Ouie, Springer-Verlas, 2001). Bustard
y sus colegas (System Models for Business Process Improvement, Artech House, 2000), y Scheer
( Business Process E ngineering: Reference Models for Industrial E nterprises, Springer-Vcrlag, 1998)
describen los mtodos de modelado del proceso de negocios para sistemas de informacin y de
toda una empresa.
Davis y Yen ( Th e Information System Consuitant's Handbook: Systems A nalysis and Design, CRC
Press, 1998) presentan una cobertura enciclopdica de los aspectos del anlisis y diseo de sis-
temas en el dominio de los sistemas de informacin. Una ayuda excelente del IEEE por Thayer
y Dorfman [THA97J discute la interrelacin entre los anlisis al nivel de sistema y al nivel de
software.
Law y sus colegas (Simulation Modeling and A nalysis, McGraw-Hill, 1999) analizan tcnicas
de modelado y simulacin de sistemas para una amplia variedad de dominios de aplicacin.
Para los lectores involucrados de manera activa en el trabajo de sistemas o que estn inte-
resados en un tratamiento ms elaborado del tpico, los libros de Gerald Weinberg (A n
Introduction to General System Th inking, Wiley, Interscience, 1976, y On th e Design of Stable
Systems, Wiley-Interscience, 1979) se han convertido en clsicos y ofrecen una excelente expo-
sicin sobre el "pensamiento general de sistemas", lo que de manera implcita conduce a un
enfoque general del anlisis y dise o de sistemas. Otros libros ms recientes de Weinberg
( General Principies of Systems Design, Dorset House, 1998 y Reth inking Systems A nalysis and
Design, Dorset House, 1998) continan la tradicin de este primer trabajo.
TM
PDF Editor
P ART E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
En Internet existe una ampl i a variedad de f uent es de i nformaci n sobre la ingeniera de
t emas y mat eri as rel aci onadas. En el sitio Web de SEPA, h t t p : / / www. m h h e . c o m / p r e s s m a r .
se puede encont rar una lista act ual i zada de referenci as en la red mundi al que son relevante
para la ingeniera del si st ema, la ingeniera de la i nformaci n, la ingeniera de proceso del neg-]
ci y la ingeniera del product o.
TM
PDF Editor
C A P I T U L O
I NGENI ER A
DE REQUI SI TOS 7
CEPTOS
VE
>...173
. . . . 159
.179
.160
.161
.158
.169
.160
.158
.183
.171
.162
.161
L
a compr e ns i n de l os r equi si t os de un pr obl e ma es t ent r e l as t ar eas m s
difciles que e nf r e nt a u n i ngeni er o de s of t war e. Cuando se pi ens a por pri-
me r a vez acer ca de el l o, la i ngeni er a de r equi si t os n o pa r e c e t an difcil.
De s pus de t odo, el cl i ent e n o s a be l o que s e r equi er e? Los us uar i os finales no
deber an e nt e nde r bi en l as car act er st i cas y f unci ones que l es pr opor ci onar n u n
benef i ci o? Es s or pr e nde nt e , per o e n mu c h a s ocas i one s la r es pues t a a e s t a s pr e-
gu nt a s es: "no". Y a u n si l os cl i ent es y us uar i os finales s on expl ci t os e n s u s ne -
ces i dades , e s t os r equi si t os pu e de n cambi ar dur a nt e el proyect o. La i ngeni er a de
r equi si t os e s difcil.
En el pr l ogo a un l i bro de Ral ph Young [YOUO1 s obr e l as pr ct i cas ef ect i vas
e n l os requi si t os, el aut or de e s t e libro escri bi :
Es tu peor pesadilla. Un cliente entra en tu oficina, se sienta, te mira directo a los ojos,
y dice: "Yo s que usted piensa que entiende lo que digo, pero lo que usted no en
tiende es que lo que digo no es realmente lo que quiero decir". Esto sucede de ma-
nera invariable cuando el proyecto est avanzado, despus de que se han realizado
los compromisos relativos al tiempo de entrega, las reputaciones estn en juego y el
dinero est en serio peligro.
Todos los que hemos trabajado en el negocio de los sistemas y el software por ms
de unos cuantos aos hemos vivido esta pesadilla, y slo unos pocos de nosotros he-
mos aprendido a continuar aun con esta circunstancia. Nosotros t enemos dificulta-
des cuando traamos de obtener requisitos de nuestros clientes. Tenemos problemas
al comprender la informacin que adquirimos. Con frecuencia, registramos los rc-
Qu e s ? La i ngeni er a d e requi si -
t os a y u d a a i os i ngeni er os d e sof t wa-
re a e nt e nde r me j or el p r o b l e ma e n
cuya sol uci n t r a b a j a r n . Incl uye el
c onj unt o d e t a r e a s q u e c onduc e n o
cul s e r el i mpact o del s of t wa r e
el negoci o, q u e s lo q u e el cl i ent e q u i e r e
i nt er act uar n los us uar i os f i nal es con el
e.
lo hace? Los i ngeni er os d e s of t wa r e
veces r ef er i dos c o mo ingenieros de sis-
o analistas e n el mu n d o d e la TI) y ot r os
( ger ent es , cl i ent es y us uar i os fi nal es)
en la i ngeni er a d e requi si t os.
Por q u es i mpor t ant e? El di s e o y la cons-
t rucci n d e un e l e ga nt e p r o g r a ma d e comput a-
d o r a q u e r esuel va el p r o b l e ma i ncor r ect o n o
s at i s f ace l as ne c e s i da de s d e na di e . Por lo tanto,
es muy i mpor t ant e e nt e nde r lo q u e el cl i ent e
qui e r e ant e s d e c o me n z a r a di s e ar y const r ui r
un si st ema b a s a d o en c o mp u t a d o r a .
Cul es son los pa s os ? La i ngeni er a d e requi -
sitos e mp i e z a con la f a s e d e inicio, la cual es
una t a r e a q u e de f i ne el mbi t o y la na t ur a l e z a
dei pr obl e ma q u e d e b e r esol ver se. De s pus con-
t i na con la obt e nci n, q u e es u n a t a r e a q u e
a y u d a al cl i ent e a def i ni r sus ne c e s i da de s ; pos-
t er i or ment e s i gue con l a e l a bor a c i n, q u e e s la
155
TM
PDF Editor
156 P A R T E D O S PRCTICA DE LA INGENIERA D A SOFTWARE
f as e d o n d e se r ef i nan y modi f i can los r equi si t os
bs i cos . Cu a n d o el cl i ent e h a de f i ni do el pr obl e-
ma se lleva a c a b o ia ne goci aci n, d o n d e s e
def i ne c u l e s son l as pr i or i dade s , c u l e s a s pe c -
t os son es enci al es y e n q u mo me n t o s e r equi e-
ren. Por l t i mo, el pr obl e ma s e es peci f i ca d e
a l guna ma n e r a , y de s pu s es va l i da do y r evi sa-
d o p a r a a s e g u r a r q u e la conce pci n del pr obl e-
ma q u e t i ene el i nge ni e r o de s of t wa r e coi nci de
con la pe r c e pc i n del cl i ent e.
Cul es el p r o d uc t o o b t e n i d o ? El obj et i vo
del pr oc e s o de la i ngeni er a d e r equi si t os e s
dar l e a t oda s l as p a r t e s u n a expl i caci n escr i t a
del pr obl e ma . Esto p u e d e l ogr a r s e p o r me di o d e
var i os pr oduc t os d e t r a ba j o: e s c e na r i os d e uso,
l i st as d e f unci ones y car act er s t i cas , mode l os de
anl i si s o a l g u n a es peci f i caci n.
Cmo pue do est ar s egur o de que lo he
hecho cor r ect ament e? El i nge ni e r o d e soft-
wa r e r evi sa l os pr oduct os d e t r a b a j o d e la i nge-
ni er a d e r equi si t os unt o con el cl i ent e y los
us uar i os f i nal es p a r a a s e g u r a r s e q u e h a y a
e nt e ndi do lo q u e en r e a l i da d pr e t e nd a n deci r l e.
Es ne c e s a r i o h a c e r una a dve r t e nc i a : a u n des-
pu s d e q u e t oda s l as par t e s es t n d e a c u e r d o ,
l as c os a s c a mb i a n , y c ont i nua r n ha c i ndol o a
t r avs d e la vi da del pr oyect o.
quisitos de una manera desorganizada e invertimos muy poco tiempo en verificar lo que
registramos. Permitimos que el cambio nos controle en lugar de establecer mecanismos
para controlarlo. En resumen, fallamos al establecer un cimiento slido para el sistema o
software. Cada uno de estos problemas representa un reto. Cuando stos se combinan, la
imagen es desalentadora incluso para los gerentes y profesionales del sofware ms expe-
rimentados. Pero existen soluciones.
Sera de s hone s t o deci r que la i ngeni er a de r equi si t os e s la "sol uci n" par a l os r et os
que s e han e nunci ado. Per o pr opor ci ona u n e nf oque sl i do par a abor dar di chos
desaf i os.
7 . 1 U N P VE NT E H A C I A EL DI S E O Y LA C O H S T R V C C I N
Las act i vi dades de di s eo y cons t r ucci n de s of t war e de c omput a dor a s on desaf i an-
t es, cr eat i vas y has t a di vert i das. De hecho, la const r ucci n e s t an i rresi st i bl e que
mu c h o s des ar r ol l ador es de s of t war e qui er en ent r ar en ella a nt e s de c ompr e nde r con
cl ari dad de qu e s lo que s e necesi t a. Ellos a r gume nt a n que l as c os a s s e acl ar ar n
mi e nt r as const r uyen; que l os i nt er es ados en el s of t war e s e r n c a pa c e s de ent ender
mej or l as ne ce s i dade s s l o de s pu s de e xa mi na r l as pr i mer as i t er aci ones del soft-
war e; que l as c os a s c a mbi a n t a n r pi do que la i ngeni er a de r equi si t os e s u na prdi-
da de t i empo; que la l nea de ba s e pr oduce u n pr ogr a ma que f unci ona y t odo lo
d e m s e s secundar i o. Lo que ha c e s educt or es a es t os a r gu me nt os e s que cont i enen
e l e me nt os de ver dad. ' Per o cada u n o de el l os e s i mper f ect o y pue de conduci r a un
pr oyect o de s of t war e fallido.
1 En particular, esto es cierto para los proyectos chicos (menos de un mes) que implican un esfuerzo
relativamente pequeo. Conforme el software crece en tamao y complejidad, estos argumentos co-
mienzan a derrumbarse.
TM
PDF Editor
C A P T U L O 7 INGENIERA DE REQUISITOS
157
" La p a r t e m s d i fc i l d e c o n s t r ui r un s i s t e m a d e s o ft wa r e e s d e c i d i r qu c o n s t r ui r . Ni n gun a p a r t e d e l t r a b a j o e s t r o p e a
t a n t o e l s i s t e m a r e s ul t a n t e s i s e h a c e m a l . Ni n gun a p a r t e e s m s d i fc i l d e r e c t i fi c a r d e s p us . "
F r e d B r o o k s
LVE
ida p a r a e l
Si l e l l a ,
esuhOTite
' d e n o
d e l
La i ngeni er a de requi si t os, c o mo t oda s l as d e m s act i vi dades de la i ngeni er a del
s of t war e, de be adapt ar s e a l as ne c e s i da de s del pr oceso, el pr oyect o, el pr oduct o y l as
pe r s ona s que r eal i zan el t r abaj o. Desde la per spect i va del pr oce s o del s of t war e, la
i ngeni er a de r equi si t os (IR) e s u n a acci n de la i ngeni er a del s of t war e que comi e n-
za dur ant e la act i vi dad de comuni caci n y cont i na en la act i vi dad de model ado.
En al gunos c a s os s e el i ge un e nf oque abr evi ado. En ot r os, cada una de l as t ar eas
def i ni das par a c ompr e nde r l os r equi si t os s e de be llevar a cabo de ma ne r a ri gurosa.
Sobr e t odo, el equi po de s of t wa r e debe adapt ar su e nf oque a la IR, lo que no signifi-
ca a ba ndono. Es esenci al que el e qui po de s of t wa r e haga u n e s f ue r z o real por ent en-
der l os r equi si t os d e u n pr obl e ma antes de i nt ent ar resol verl o.
La i ngeni er a de r equi si t os t i ende un pue nt e haci a el di s eo y la const r ucci n.
Per o dnde s e ori gi na el pue nt e ? Se pue de a r gume nt a r q u e c omi e nz a al pi e de l os
par t i ci pant es del pr oyect o (es deci r, ger ent es, cl i ent es, us uar i os finales), donde s e
def i nen l as necesi dades del negoci o, s e descr i ben l os escenar i os de los usuari os, se deli-
ne an l as car act er st i cas y f unci ones, y s e i dent i fi can l as r est r i cci ones del pr oyect o.
Ot r os qui z s ugi er an que c omi e nz a con la def i ni ci n m s ampl i a del s i s t ema, e n el
que el s of t wa r e e s sl o u n c ompone nt e (cap t ul o 6) del domi ni o del s i s t ema que e s
a n mayor . Pero sin i mpor t ar el punt o de inicio, el t r abaj o a lo l ar go del pue nt e se
inicia en la par t e al t a del pr oyect o, l o que per mi t e que el equi po de s of t war e examl
n e el cont e xt o del t r abaj o de s of t war e q u e s er realizado,- l as ne c e s i da de s especi fi -
cas que el di s eo y la cons t r ucci n de be n abor dar ; l as pr i or i dades que i ndi can el
or de n en el q u e se de be compl et ar el t r abaj o; y la i nf or maci n, l as f unci ones y l os
c ompor t a mi e nt os q u e t e ndr n un i mpact o pr of undo en el di s eo r esul t ant e.

La i ngeni er a de r equi si t os pr opor ci ona el me c a ni s mo apr opi ado par a e nt e nde r lo
que el cl i ent e qui ere, anal i zar l as neces i dades , eval uar la fact i bi l i dad, negoci ar una
sol uci n r azonabl e, especi f i car la sol uci n sin ambi ge dade s , val i dar la especi f i ca-
ci n, y admi ni s t r ar l os r equi si t os c onf or me s t os s e t r ans f or man en un s i s t ema ope-
r aci onal [THA97]. El pr oc e s o de la i ngeni er a de r equi si t os s e l l eva a c a bo a t r avs de
si et e di st i nt as f unci ones : inicio, obtencin, elaboracin, negociacin, especificacin,
validacin y gestin.
Resul t a i mpor t ant e des t acar que a l guna s de es t as f unci one s de la i ngeni er a de
r equi si t os ocur r en e n par al el o y que t oda s de be n adapt ar s e a l as ne ce s i dade s del
pr oyect o. Todas e s t n di ri gi das a defi ni r lo que el cl i ent e qui ere, y t odas si r ven par a
est abl ecer una ba s e sl i da r es pect o del di s eo y la const r ucci n de lo que obt endr
el cl i ent e.
TM
PDF Editor
158 P ART E D O S PRCTICA DE LA INGENIERA DA SOFTWARE
7.2.1 Inicio
Cmo se inicia un pr oyect o de s of t war e ? Es u n e ve nt o ai sl ado que s e convi er t e en
el cat al i zador par a un nue vo si st ema o pr oduct o ba s a do e n c omput a dor a ? O la
neces i dad evol uci ona con el t i empo? No exi st en r e s pue s t as def i ni t i vas par a es t as
pr egunt as .
" Po r l o ge n e r a l , t a s s e m i l l a s d e l o s d e s a s t r e s m s i m p o r t a n t e s e n s o ft wa r e s e s i e m b r a n e n l o s p r i m e r o s t r e s m e s e s
d e s d e e l c o m i e n zo d e l p r o y e c t o . '
Ca p e r s J o n e s
En al gunos casos, una conver saci n i nf or mal e s t odo lo que s e necesi t a par a pre-
cipitar un e s f ue r zo i mpor t ant e de i ngeni er a del sof t war e. Pero e n gener al , la mayor a
de l os pr oyect os comi e nza c ua ndo s e identifica u na necesi dad de negoci os o s e des-
cubr e un nuevo me r cado o servi ci o pot enci al . Los par t i ci pant es de la comuni dad de
negoci os (es decir, l os ger ent es, gent e de mer cadot ecni a, ger ent es de product o) defi-
nen un cas o de negoci os par a la i dea, t r at an de i dent i fi car la ampl i t ud y pr of undi dad
del mer cado, hace n un anl i si s prel i mi nar de factibilidad, e i dent i fi can u na descri pci n
f unci onal del mbi t o del proyect o. Toda es t a i nf or maci n est suj et a a cambi os (una
si t uaci n probabl e), per o e s sufi ci ent e par a susci t ar conver saci ones con la or gani za-
cin de i ngeni er a del sof t war e. 2
Al inicio3 del pr oyect o l os i ngeni er os de s of t war e ha c e n una seri e de pr egunt as
l i bres d e cont ext o, l as cual es s e e xpone n en la secci n 7.3.4. El obj et i vo e s est abl e-
cer u na compr e ns i n bs i ca del pr obl ema, l as pe r s ona s que qui er en u na sol uci n, la
nat ur al eza de la sol uci n que s e des ea, y la ef ect i vi dad de la comuni caci n prel i mi -
nar ent r e el cl i ent e y el desar r ol l ador .
7.2.2 Obt enci n
En ver dad par ece muy si mpl e pr egunt ar l e al cl i ent e, a l os us uar i os y ot r os i nt er esa-
dos cul es s on l os obj et i vos par a el s i s t e ma o pr oduct o, qu e s lo que s e de be l ograr,
de qu f or ma el pr oduct o sat i sf ace l as ne c e s i da de s del negoci o y por l t i mo c mo se
ut i l i zar el s i s t ema o pr oduct o da a da. Per o no e s si mpl e, e s muy difcil.
Christel y Kang [CR192] i dent i fi can u n a seri e de pr obl e ma s que ayudan a e nt e nde r
Po r qu por qu e s difcil la obtencin de requi si t os:
Pr o b l e m a s d e m b i t o . El l mi t e del si st ema est mal def i ni do o l os
e s d i fc i l
c o m p r e n d e r c o n
claridad |o que cl i e nt e s / us uar i os especi f i can det al l es t cni cos i nneces ar i os que pu e de n
qwe r e e l c l i e n t e ? conf undi r , e n l ugar de cl ari fi car, l os obj et i vos ge ne r al e s del s i s t ema.
2 Si se va a construir un sistema basado en computadora, las discusiones comienzan con la ingenie-
ra del sistema, una actividad que define la visin global y la visin de dominio para el sistema (ca-
pitulo 6).
3 Los lectores del capitulo 3 recordarn que el proceso unificado define una "fase de inicio" ms com-
pleta, la cual incluye las tareas de inicio, obtencin y elaboracin tal como se examinan en este ca-
ptulo.
TM
PDF Editor
C A P I T U L O 7 INGENIERA DE REQUISITOS
159
e s
sedebe
adavees
mcbose
dise o,
wt t d e
s e
P r o b l e ma s d e c o mp r e n s i n . Los cl i ent es/ usuar i os no est n segur os por
compl et o de qu es lo que se necesi t a, compr enden poco acer ca de las capa-
ci dades y l i mi t aci ones de su ambi ent e de cmput o, no compr enden del t odo
el domi ni o del pr obl ema, t i enen di fi cul t ades al comuni car necesi dades al
i ngeni ero de si st emas, omi t en i nformaci n que consi der an "obvia", especi -
fican requi si t os que chocan con las necesi dades de ot ros cl i ent es/ usuar i os, o
especi fi can requi si t os ambi guos o i nest abl es.
P r o b l e ma s d e vol at i l i dad. Los pr obl emas cambi an conf or me t r anscur r e el
t i empo.
Para ayudar a super ar est os pr obl emas, l os i ngeni eros de requi si t os deben real i zar
en f or ma or gani zada la actividad de recopi l aci n de requisitos.
7.2.3 El aboraci n
La i nf or maci n consegui da con el cl iente dur ant e el inicio y la obt enci n se expan-
de y se refi na dur ant e la elaboracin. Esta actividad de la i ngeni er a de requi si t os se
enf oca en el desarrol l o de un model o t cni co refi nado de l as funci ones, caract er st i -
cas y rest ri cci ones del sof t war e.
La el aboraci n es una acci n del model ado del anl i si s (captulo 8) y se compo-
ne de una serie de t ar eas de model ado y refi nami ent o. La el aboraci n se conduce
medi ant e la creaci n y el r ef i nami ent o de escenar i os del usuar i o que descri ben la
f or ma en que el usuar i o final (y ot r os act ores) i nt eract uarn con el si st ema. Cada
escenar i o del usuar i o s e anal i za par a obt ener cl ases de anlisis: ent i dades del domi -
ni o de negoci os visibles par a el usuar i o final. Se defi nen los at ri but os de cada cl ase
de anl i si s y se identifican los servicios4 que requi ere cada clase. Se identifican las
r el aci ones y la col aboraci n ent r e l as cl ases y se pr oduce una vari edad de di agr amas
de UML compl ement ar i os.
El resul t ado final de la el aboraci n es un model o de anl i si s que defi ne el domi -
ni o de la i nformaci n, las f unci ones y el compor t ami ent o del probl ema.
INFORMACIN
Modelado del anlisis
1 Supngase por un momento que es necesario
especificar todos los requisitos par a la
i de una cocina gourmet. Se conocen las
de la sala, la ubicacin de las puertas y
y el espacio disponible en la par ed.
especificar por completo lo que se va a construir
hacer una lista de todos los gabinetes y
aplicaciones (su fabricante, modelo, nmero y
dimensiones). Despus se podran especificar las
contrapartes (laminado, granito, etctera), uniones de
plomera, pisos y los techos. Esta lista podr a constituir una
especificacin til, pero no proporciona un modelo de lo
que se desea. Para completar el modelo se podra crear
una representacin tridimensional que muestre la posicin
4 Tambin se utilizan los trminos operaciones y mtodos.
TM
PDF Editor
/ T .
de los gabi net es y apl icaciones y los relaciones ent re ellos.
A partir del model o, sera ms fcil eval uar la eficiencia
del flujo de t r abaj o (un requisito pa r a t odas las cocinas), y
la apari enci a esttica del saln (un requisito personal , per o
muy importante.)
Los modelos de anlisis se construyen por una razn
muy par eci da a la del desarrol l o de un pl ano de t r abaj o o
una representacin tridimensional par a el caso de la
cocina. Es importante eval uar cada component e del
sistema en relacin con los otros. Esto permite determinar
cmo encaj an los requisitos en esta visin y eval uar la
"esttica" del sistema como ha sido concebi do.
^ O N S E J O ^
E n una negociacin
e k a i no debe babet
ganador ni perdedor.
A mbas parles ganan
porque se solidifica un
'trato" con el que las
dos pueden vivir.
CLAVE
l o formal i dad y el
f or mat o de una
especificacin varan
con el t amao y la
complejidad del
sof t war e que se va a
construir.
7.2.4 Negoci aci n
Dados los recursos l imitados del negocio, no resulta inusual que los clientes y usua-
rios pi dan m s de lo que se puede lograr. Tambin es rel at i vament e comn que dife-
rent es clientes o usuari os propongan requisitos que ent ran en conflicto ent re s a
ar gument ar que su versin es "esencial par a nuest ras necesi dades especiales".
El ingeniero de requi si t os debe conciliar est os conflictos por medi o de un proce-
so de negociacin. Se pide a los clientes, usuari os y otros i nt eresados que ordenen
sus requisitos y despus di scut an los conflictos rel aci onados con la prioridad. Se
identifican y anal i zan los riesgos asoci ados con cada requisito (para obt ener ms
detalles vase el captulo 25). Se hacen "estimaciones" prel i mi nares del esf uer zo
requeri do par a su desarrollo y despus s e utilizan para eval uar el i mpact o de cada
requisito en el cost o del proyect o y sobre el t i empo de ent rega. Medi ant e un enfoque
iterativo, l os requisitos se eliminan, combi nan o modifican de forma que cada parte
al cance cierto grado de satisfaccin.
7.2.5 Especi fi caci n
En el cont ext o de los si st emas basados en comput ador a (y en software), el t rmi no
especificacin tiene significados di ferent es par a per sonas distintas. Una especifica-
cin puede ser un document o escrito, un conj unt o de model os grficos, un model o
mat emt i co formal, una coleccin de escenari os de uso, un prot ot i po o cualquier
combi naci n de st os.
Al gunos sugi eren que para una especificacin se debe desarrol l ar y utilizar una
"plantilla est ndar" [SOM97] ar gument an que est o conduce a que los requi si t os sean
pr esent ados de una maner a ms consi st ent e y por ende ms ent endi bl e. Sin embar-
go, al gunas veces es necesari o ser flexible mi ent ras se desarrol l a una especificacin.
Respect o de si st emas gr andes el mej or enf oque podra ser un document o escrito que
combi nara descri pci ones en el l enguaj e natural y model os grficos. Por ot ro lado, en
cuant o a product os o si st emas ms pequeos, podra ser que no se necesi t e ms que
escenari os de uso, cuando dichos si st emas resi dan en ambi ent es t cni cos que se
compr endan bien.
La especificacin es el product o de t rabaj o final que genera la ingeniera de requi-
sitos. Sirve como base par a las act i vi dades de ingeniera de sof t war e subsecuent es.
TM
PDF Editor
CAP TULO 7 INGENIERA DE REQUISITOS
161
dave
c wtdon
tsb
. Se mo-
tel
xantsis
yqueh s
se tan esta-
Descr i be la f unci n y el d e s e mp e o de un s i s t ema ba s a do e n c omput a dor a y l as r es -
t r i cci ones que regi rn su desar r ol l o.
7.2.6 Val i daci n
La cal i dad de l os pr oduct os de t r abaj o pr oc e de nt e s de la i ngeni er a de r equi si t os s e
eval a dur a nt e un p a s o de validacin. La val i daci n de r equi si t os e xa mi na la especi -
ficacin par a as egur ar que t odos l os r equi si t os de s of t war e s e han est abl eci do de
ma ne r a pr eci sa; que s e han de t e ct ado l as i nconsi st enci as, omi s i one s y er r or es y que
s t os ha n si do cor r egi dos, y que l os pr oduct os de t r abaj o cumpl e n con l os e s t nda-
r es es t abl eci dos par a el pr oceso, pr oyect o y pr oduct o.
El me c a ni s mo pr i mar i o par a la val i daci n de r equi si t os e s la r evi si n t cni ca f or -
mal (cap t ul o 26). El equi po de revi si n que val i da l os r equi si t os i ncl uye i ngeni er os
de s of t war e, cl i ent es, us uar i os y ot r os i nt er es ados que e xa mi na n la especi f i caci n y
bus c a n er r or es e n el cont eni do o la i nt er pr et aci n, r e a s que tal ve z r equi er an una
cl ari fi caci n, i nf or maci n f al t ant e, i nconsi st enci as (que e s un pr obl ema i mpor t ant e
c u a ndo s e desar r ol l an pr oduct os o s i s t e mas gr andes) , conf l i ct os ent r e l os requi si t os,
o r equi si t os i rreal es ( i nal canzabl es) .
I NFORMACI N
Lista de verificacin para la validacin de requisitos
Con f r ecuenci a resulta til exami nar c a d a
requisito frent e a una seri e d e pr egunt as en
d e lista de veri fi caci n. Ensegui da se pr esent a un
subconj unt o d e las pr egunt as que de be n
K x
El requi si t o se pue de pr obar ? Si es as , se pueden
especi f i car las pr uebas ( al gunas veces l l amadas criterios
d e val i daci n) pa r a ej erci t ar el requisito?
j - cs requisitos est n est abl eci dos de ma ne r a cl ar a?
Estos pueden mal i nt er pr et ar se?
2 fuente del requi si t o (por ej empl o, una per sona, una
-Eoj l oci n o un regl ament o) est i dent i fi cada? El
e r u n a d o final del requi si t o ha si do e xa mi na do por la
u e nt e ori gi nal o c ompa r ndol o con el l a?
; E -equisito est rest ri ngi do en t rmi nos cuant i t at i vos?
j Cul es ot ros requisitos est n r el aci onados con ste?
j i n regi st rados d e mane r a cl ar a por medi o d e una
TTcfriz de r ef er enci as c r uz a da s u ot r o mecani smo?
3 requisito viola al guna restriccin del domi ni o del
K
El requisito es r ast r eabl e p a r a cual qui er model o d e
sistema q u e haya si do cr eado?
El requi si t o es r ast r eabl e pa r a los obj et i vos gener al es
del si st ema o pr oduct o?
La especi fi caci n est est r uct ur ada d e una f or ma que
conduzca a su compr ensi n, r ef er enci a y t raducci n
fcil en pr oduct os d e t r abaj o ms tcnicos?
Se ha c r e a do al gn ndi ce pa r a la especi fi caci n?
Los requisitos as oci ados con el rendi mi ent o, el
de s e mpe o y las caract er st i cas oper oci onal es se han
est abl eci do d e mane r a cl ar a? Cul es requisitos
par ecen ser implcitos?
i a l e o b te n e r
d e
t so b r e

7.2.7 Gestin de requi si t os
En el cap t ul o 6 s e est abl eci que l os requi si t os par a l os s i s t emas bas ados en compu-
t a dor a s c a mbi a n y que el de s e o de cambi ar l os per si st e dur a nt e la vi da del si st ema.
La gest i n de r equi si t os e s u n conj unt o de act i vi dades que ayudan al e qui po de pr o-
yect o a i dent i fi car, cont r ol ar y r ast r ear l os r equi si t os y l os c a mbi os a es t os en cual -
TM
PDF Editor
^ C O N S I J O ^
Cuando un sistema es
grande y complejo, la
determinacin de las
conexiones entre los
reqtiiih K puede ser
una totea redituable.
Se recomiendo el uso
de las tablas de rastrea-
bilidad pora facilitar un
poco el trabajo.
qui er mo me n t o mi e nt r as s e desar r ol l a el pr oyect o. 5 Muchas de e s t a s act i vi dades s oa l
i dnt i cas a l as act i vi dades de la gest i n de la conf i gur aci n del s of t wa r e (CCS) que I
s e t r at an e n el cap t ul o 27.
La gest i n de r equi si t os c omi e nz a con la i dent i fi caci n. Cada r equer i mi ent o se
as i gna a un sol o i dent i f i cador . Una vez i dent i f i cados l os r equi si t os s e desar r ol l an las
t abl as de r ast r eabi l i dad. En la figura 7.1 s e mue s t r a de ma ne r a e s que mt i ca u n a
t abl a de r ast r eabi l i dad, cada u na de el l as r el aci ona l os r equi si t os con u n o o mas
a s pe c t os del si st ema o de su ambi ent e. Ent re l as mu c h a s t abl as de r ast r eabi l i dad
posi bl es e s t n l as si gui ent es:
Ta b l a d e r a s t r e a b i l i d a d d e l a s c a r a c t e r s t i c a s . Muest r a la ma ne r a en que los
r equi si t os s e r el aci onan con l as car act er st i cas del s i s t e ma / pr oduc t o obser vabl es
par a el cl i ent e.
Ta b l a d e r a s t r e a b i l i d a d d e l a f ue n t e . Ident i fi ca la f ue nt e de cada requi si t o.
Ta b l a d e r a s t r e a b i l i d a d d e d e p e n d e n c i a . Indi ca la f or ma e n que l os requi si t os
e s t n r el aci onados e nt r e s.
Ta b l a d e r a s t r e a b i l i d a d d e l s ub s i s t e m a . Est abl ece cat egor as ent r e l os requ:
si t os de acue r do con el (los) s ubs i s t e ma (s) que gobi er na (n).
Ta b l a d e r a s t r e a b i l i d a d d e l a i n t e r f a z. Muest r a la f or ma en que l os requi si t os
s e r el aci onan con l as i nt er f ases i nt er nas y e x t e ma s del si st ema.
En mu c h o s casos, e s t a s t abl as de r ast r eabi l i dad s e ma nt i e ne n c o mo par t e de la
ba s e de dat os de l os r equi si t os de f or ma que pue da bus cr s el es con r api dez para
e nt e nde r c mo el cambi o e n u n r equi si t o af ect ar di f er ent es a s pe c t os del si st ema
que s e const r ui r .
Ta b l a
ge n r i c a d e
r a s t r e a b i l i d a d . Requ
\ Aspe<
UI S TO^ ^ \ ^
:to es
A0 1
pec
M
i co d
A 0 3
el sist
, , .
A0 4
ema
A 0 5
3 SU Q mbi e
8{J?B5
nte
Ai
ROI
R0 2
R 0 3

R 0 4
R0 5
Rn n
v H
5 La gestin formal de requisitos se inicia slo para proyectos grandes, los cuales tienen cientos de re-
quisitos identificables. En los proyectos pequeos esta funcin de la ingeniera de requisitos es bas-
tante menos formal.
TM
PDF Editor
163
Ingeniera de requisitos
Ob j e t i vo : Las herramientas de la ingeniera
de requisitos ayudan en la recopilacin,
o, gestin y validacin de requisitos.
l i c a : La mecnica de las herramientas vara. Por lo
* las herramientas de la ingeniera de requisitos
i una vari edad de modelos grficos (por
d UML) que muestran los aspectos de informacin,
niento y comportamiento de un sistema. Estos
l forman la base par a todos las otras actividades
r s Droceso del software.
t i t a s r e p r e s e n t a t i va s 6
: Systems Guide, Inc. ha pr epar ado una lista
i completa de herramientas par a la
i de requisitos, sta se puede encontrar en
i. systemsguild. com/Guildsite/Robs/retools
. 5 model ado de requisitos se estudia en el captulo 8.
E -et rami ent as que se presentan a continuacin se
i en la gestin de requisitos.
, desarrol l ado por Cybernetic Intelligence GMBH
---.easy-rm.com), construye un di cci onari o/ gl osari o
especfico del proyecto que contiene descripciones y
atributos detallados de los requisitos.
OnVourMark Pro, desarrol l ado por Omni-Vista
(www.omni-vista.com), construye una base de datos de
los requisitos, establece relaciones entre stos, y
permite a los usuarios anal i zar la relacin entre los
requisitos y los cal endarios/costos.
Rational RequisitePro, desarrol l ado por Rational Software
(www.rational.com), permite a los usuarios desarrollar
una base de datos de los requisitos, representa las
relaciones entre stos y los organi za, prioriza y rastrea.
RTM, desarrol l ado por Integrated Chi pware
(www.chipware.com), es una herramienta par a la
descripcin y rastreobilidad de requisitos que tambin
soporta ciertos aspectos del control del cambi o y
gestin de las pruebas.
Se debe hacer notar que muchas t areas de la gestin de
requisitos se pueden realizar con una simple hoja de
clculo o un sistema pequeo par a el manej o de bases
de dat os.
En un e s ce nar i o i deal , los cl i ent es y l os i ngeni er os de s of t wa r e t r abaj an j unt os en el
mi s mo equi po. 7 En t al es casos, la i ngeni er a de r equi si t os se t r at a s l o de gui ar con-
ve r s aci one s si gni fi cat i vas con col egas que s on mi e mbr os bi en conoci dos del equi po.
Sin e mbar go, en la r eal i dad a me n u d o e s bas t ant e di f er ent e.
Los cl i ent es pue de n est ar en u na ci udad o pa s di ferent e, pueden t ener sl o una
i dea vaga de lo que se requi ere, tal vez t engan opi ni ones confl i ct i vas acer ca del si st e-
ma que s e const rui r, qui z su conoci mi ent o t cni co s ea l i mi t ado y t engan un t i empo
l i mi t ado par a i nt er act uar con el i ngeni er o de requi si t os. Ni nguna de es t as si t uaci ones
e s deseabl e, per o s on muy comune s , y el equi po de s of t war e con f r ecuenci a se ve obli-
ga do a t r abaj ar dent r o de l as r est r i cci ones que i mpone est a si t uaci n.
En l as s e cci one s s i gui ent es s e e xa mi na n l os pa s os r equer i dos par a i ni ci ar la i nge-
ni er a de requi si t os; e s decir, par a c o me n z a r un pr oyect o de f or ma que s e ma nt e nga
en movi mi e nt o haci a u na sol uci n exi t osa.
6 Las herramientas mencionadas aqu son una muestra dentro de esla categora. En la mayora de los
casos los nombres estn registrados por sus respectivos desarrolladores.
7 Este enfoque se recomienda para todos los proyectos y es una parte integral de la filosofa para el
desarrollo gil de software
TM
PDF Editor
fe?
CLAVE
Un i nt er es ado e s
cual qui er a q u e
participo e n f or ma
di rect a en el s i s t e ma
q u e s e va a desarrol l ar
u obt i ene benef i ci os de
s t e.
7.3.1 Ident i fi caci n de los i nt er esados
Sommer vi l l e y Sawyer [SOM97] def i nen a l os interesados c o mo " t odos aquel l os
se benef i ci an en u na f or ma di rect a o i ndi rect a del s i s t ema que es t e n desarrol l o*
Ya se ha i dent i f i cado a l os s os pe c hos os usual es: ge r e nt e s de ope r a c i one s de nc
cios, ge r e nt e s de pr oduct o, gent e de mer cadot ecni a, cl i ent es i nt er nos y e xt e mos
us uar i os finales, consul t or es, i ngeni er os de pr oduct o, i ngeni er os de s of t war e, ing
ni er os de s opor t e y ma nt e ni mi e nt o y ot r os. Cada i nt er es ado t i ene u na visin di f r
rent e del si st ema, obt i ene benef i ci os di f er ent es c ua ndo st e s e desarrol l a de ma n"
exi t osa, y es t abi er t o a di f er ent es r i esgos si el e s f ue r z o de desar r ol l o l l egara a fallar
En el i ni ci o el i ngeni er o de r equi si t os pue de cr ear u na lista d e pe r s ona s que c
t ri bui rn dur a nt e la obt enci n de r equi si t os (secci n 7.4). La lista inicial cr ecer c
f or me s e es t abl ezca cont act o con l os i nt er esados, ya que a c a da u n o de el l os se
pr egunt ar : "Con qui n m s pi ens a que deber a habl ar ?"
7.3.2 Reconoci mi ent o de ml t i pl es punt os de vi st a
Debi do a que exi st en mu c h o s cl i ent es di f er ent es, l os r equi si t os del s i s t ema s e explo-
r ar n de s de di ver sos punt os de vi st a. Por ej empl o, el gr upo de me r cadot e cni a est
i nt er es ado en f unci one s y car act er st i cas que es t i mul en al me r c a do pot enci al , que
ha ga n que el nue vo s i s t ema s ea fcil de vender . Los ge r e nt e s de negoci os e s t n inte-
r e s a dos en un gr upo de car act er st i cas que s e pu e da n const r ui r si n r ebas ar un pre-
s upue s t o y que e s t n l i st as par a l l egar a ni chos de me r c a do def i ni dos. Los usuar i os
finales pu e de n de s e ar car act er st i cas con l as que est n f ami l i ar i zados y s e a n fciles
de a pr e nde r y util izar. Los i ngeni er os de s of t wa r e qui z e s t n i nt er es ados en fun-
ci ones que den el s opor t e de la i nf r aes t r uct ur a y car act er st i cas m s accesi bl es a l
me r cado. Los i ngeni er os de s opor t e s e pue de n e nf ocar e n la faci l i dad de mant eni -
mi e nt o del s of t war e .
" Co l o que a t r e s i n t e r e s a d o s e n un o h a b i t a c i n y p r e g n t e l e s qu t i p o d e s i s t e m a qui e r e n . Es p r o b a b l e que o b t e n ga
c ua t r o o m s o p i n i o n e s d i fe r e n t e s "
An n i m o
Cada uno de es t os c ompone nt e s (y ot ros) pr opor ci onar n i nf or maci n al pr oces o
de la i ngeni er a de requi si t os. Conf or me s e r ecopi l a i nf or maci n de s de ml t i pl es
punt os de vista, l os r equi si t os que s ur j an pue de n s er i ncons i s t ent es o e nt r ar en con-
flicto con al gn ot ro. El t r abaj o del i ngeni er o de r equi si t os e s cat egor i zar t oda la
i nf or maci n de l os i nt er es ados (i ncl ui dos l os r equi si t os i ncons i s t ent es y confl i ct i vosi
en u na f or ma que per mi t a a qui e ne s t ome n la deci s i ones el egi r un c onj unt o de requi -
si t os par a el s i s t ema que s e a n cons i s t ent es de ma n e r a i nt er na.
7.3.3 Tr abaj o con r espect o a l a col abor aci n
En l os cap t ul os pr evi os s e ha me nc i ona do que l os cl i ent es (y ot r os i nt er esadosi
deber an col abor ar ent r e s (evi t ando pel eas i nsi gni fi cant es) y con l os pr of esi onal es
TM
PDF Editor
165
de la ingeniera del sof t war e si se desea obt ener un si st ema exitoso. Pero, cmo se
logra est a col aboraci n?
El t r abaj o del i ngeni ero de requi si t os es identificar r eas en comn (es decir, los
requi si t os en l os que t odos l os i nt er esados est n de acuerdo) y r eas de conflicto o
i nconsi st enci a (esto es, los requi si t os sol i ci t ados por un i nt eresado que ent r an en
confl icto con l as necesi dades de otro). sta es, por supuest o, la ltima cat egor a que
pr esent a un desafi o.
Utilizacin de los 'puntos de prioridad"
INFORMACIN
Jna forma de resolver los conflictos entre
requisitos, al mismo tiempo que se entiende
port ando relativa de todos, es la utilizacin de
: de "votacin" bas ado en puntos de prioridad.
r *r e s ados reciben la misma cant i dad de puntos
que pueden "gastarse" en cualquier nmero de
Se presenta una lista de requisitos y los
-idcan la importancia relativa de cada uno
(desde su punto de vista) al asignarle uno o ms puntos de
prioridad. Los puntos asi gnados no se pueden reutilizar.
Una vez que los puntos de prioridad del interesado se han
agot ado, dicha persona no puede realizar ninguna otra
accin sobre los requisitos. Los puntos totales que asignen
a cada requisito todos los interesados indican la
importancia general de cada requisito.
La col aboraci n no significa, necesar i ament e, que l os requi si t os se defi nan por
consenso. En muchos casos, l os i nt er esados col aboran al proporci onar su visin de
los requisitos, pero un fuerte "campen de proyecto" (por ejemplo, un gerent e de nego-
cios o un t cni co i mport ant e) puede t omar la decisin final acerca de cul es requi -
si t os se acept an.
7.3.4 For mul aci n de l as pr i mer as pr egunt as
En est e captul o se ha dest acado que las pr egunt as f or mul adas al inicio del proyec-
to deben ser "libres de cont ext o" [GAU89]. El pri mer conj unt o de pr egunt as libres de
cont ext o se enf oca en el cliente y ot ros i nt eresados, met as gener al es y en los Dene-
ficios. Por ej empl o, el i ngeni ero de requi si t os podr a pregunt ar:
Quin est det r s de la solicitud de est e t rabaj o?
Quin usar la sol ucin?
Cul ser el benefi ci o econmi co de una sol uci n exi t osa?
Existe ot ra f uent e par a la solucin requeri da?
Est as pr egunt as ayudan a identificar a t odos los part i ci pant es que t endr an inte-
rs en el sof t war e que ser const rui do. Adems, est as pr egunt as identifican el bene-
ficio medi bl e de una i mpl ement aci n exitosa y las al t ernat i vas posibl es par a perso-
nal i zar el desarrol l o del soft ware.
"Es m e j o r s a b e r o i go d e b s p r e gun t a s que t o d o d e l o s r e s p ue s t a s . "
J a m e s Th n r b e r
TM
PDF Editor
166
P A R T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
7 Cua l e s s o n
l a s p r e gun -
t a s que a y ud a n a
o m p r e n d e r e n
f o r m a p r e l i m i n a r
e l p r o b l e m a ?
La si gui ent e serie de pr egunt as per mi t e que el equi po de sof t war e compr e
mej or el pr obl ema y dej a que el cl iente expr ese sus per cepci ones acer ca de una
cin:
Cmo podra car act er i zar se un buen resul t ado gener ado por una sol uci n
exi t osa?
Cul es pr obl emas deber a at acar est a sol uci n?
Podra ust ed describir o most r ar el ambi ent e de negoci os en el que se
util izar la sol uci n?
Los aspect os especi al es del de s e mpe o o l as rest ri cci ones af ect ar n la fo
en que se busque la sol uci n?
La seri e final de pr egunt as se enf oca en la efect i vi dad de la actividad de com
caci n en s mi sma. Gause y Wei nberg [GAU89] las l l aman las "met apr egunt as'
pr oponen la si gui ent e lista abrevi ada:
Es ust ed la per s ona adecuada par a cont est ar est a pr egunt a? Sus r espuest as
son "oficales"?
Mis pr egunt as son r el evant es par a su pr obl ema?
Estoy haci endo demas i adas pr egunt as?
Alguien m s puede pr opor ci onar i nformaci n adi ci onal ?
Deber a pr egunt ar l e al guna ot ra cosa?
" 0 que p r e gun t a e s un t o n t o d ur a n t e t i n t o m i n ut o s ; e l que n o p r e gun t a e s un t o n t o p o r s i e m p r e . "
Pr o ve r b i o c h i n o
Est as pr egunt as (y otras) ayudar n a "r omper el hiel o" y a iniciar la conversaci n 1
esenci al par a la obt enci n exitosa. Pero un f or mat o de reuni n de pr egunt a y res-
puest a no es un enf oque que haya si do exi t oso de mane r a cont undent e. De hecho, I
la sesi n de pr egunt as y r espuest as se debe usar sl o par a el pr i mer encuent ro, y
des pus se debe r eempl azar por un f or mat o de obt enci n de requi si t os que combi - !
ne el ement os de resol uci n de pr obl emas, negoci aci n y especi fi caci n. En la sec-
cin 7.4 se pr esent a un enf oque de est e tipo.
7 . 4 O B T E N C I N DE REQUI S I TOS
El f or mat o de pr egunt a y r espuest a descri t o en la secci n 7.3.4 es til en la et apa ini-
cial, per o no es un enf oque que haya si do exi t oso de maner a decisiva par a una
obt enci n de requi si t os m s det al l ada; de hecho, la sesi n de pr egunt as y respues-
t as se debe usar sl o par a el pri mer encuent r o y des pus se debe r eempl azar por un
f or mat o de obt enci n de requi si t os que combi ne el ement os de la resol uci n, elabo-
racin, negoci aci n y especi fi caci n del pr obl ema. En la si gui ent e secci n se pre-
sent a un enf oque de est e tipo.
TM
PDF Editor
C A P I T U L O 7 INGENIERA DE REQUISITOS
167
Cu l e s
s o n l a s
b s i c a s
a c a b o
7.4.1 Recopi l aci n conj unt a de requi si t os
Cua ndo s e de s e a est i mul ar un e s f ue r z o c onj unt o y or i ent ado al e qui po de r ecopi l a-
cin de requi si t os, u n e qui po de par t i ci pant es y des ar r ol l ador es t r abaj an j unt os par a
i dent i fi car el pr obl ema, pr opone r e l e me nt os de sol uci n, negoci ar di f er ent es enf o-
que s y especi f i car u n conj unt o pr el i mi nar de r equi si t os par a la sol uci n [ZAH90].8
Se han pr opues t os mu c h o s y di f er ent es e nf oque s par a la r ecopi l aci n conj unt a de
requi si t os. Cada u n o utiliza un es cenar i o muy di ferent e, pe r o t odos apl i can al guna
var i aci n de l as si gui ent es di r ect r i ces bsi cas:
Las r e uni one s l as di ri ge al guno de l os asi st ent es, ya s ea un i ngeni er o de
s of t war e o u n cl i ent e (j unt o con ot r os par t i ci pant es i nt er esados) .
Se es t abl ecen r egl as par a la pr epar aci n y la par t i ci paci n.
Se sugi er e una a ge nda que s e a t an f or mal c o mo par a cubri r t odos l os punt os
i mpor t ant es, pe r o t an i nf or mal c o mo par a est i mul ar el flujo de i deas.
Un mode r a dor ( puede s er un cl i ent e, un desar r ol l ador o un agent e ext er no)
cont r ol a la r euni n.
Se utiliza un " me c a ni s mo de def i ni ci n" ( pueden s er hoj as de t r abaj o,
grfi cos, hoj as adher i bl es, u n t abl er o el ect r ni co, un me ns a j e r o el ect r ni co o
un f or o virtual).
La me t a e s i dent i fi car el pr obl ema, pr opone r e l e me nt os de sol uci n, negoci ar
di f er ent es e nf oque s y especi f i car un conj unt o de r equi si t os de sol uci n preli-
mi na r e s en u na a t ms f e r a que c onduz c a al cumpl i mi ent o de la met a.
Para e nt e nde r me j or el flujo de l os e ve nt os ( conf or me s t os ocur r en) , s e pr e s e n-
t a u n es cenar i o br eve que descr i be la s e cue nci a de e ve nt os que c onduc e n a la r eu-
ni n par a la r ecopi l aci n de r equi si t os y que ocur r en dur a nt e la r euni n y de s pu s
de st a.
" De d i c a m o s m uc h o t i e m p o - l o m a y o r a d e l e s fue r zo d e l p r o y e c t o - n o a l a m p l e m e n t a c i n n i a l a s p r ue b a s , s i n o a
t r a t a r d e d e c i d i r qu e s l o que s e va a c o n s t r ui r . "
B r i a n La wr e n c e
Dur ant e la f ase de i ni ci o (secci n 7.3), l as pr e gunt a s y r es pues t as bs i cas es t a-
bl ecen el mbi t o del pr obl e ma y la per cepci n gl obal de una sol uci n. Fuera de es t as
r e uni one s inicial es, l os par t i ci pant es escr i ben una "solicitud de pr oduct o" de una o
dos pgi nas . Se fijan un l ugar, una hor a y una f echa par a la r euni n y s e sel ecci ona
un moder ador . Los mi e mbr os del equi po de s of t wa r e y ot r as or gani zaci one s i nt er e-
8 A este enfoque se le llama algunas veces tcnica de especificacin facilitada de la aplicacin (FAST,
por sus siglas en ingls).
TM
PDF Editor
l l i l I Mi
requisitos. En
www.rarola.
c o m / wp - j a d J i t m
bueno descripcin de
^ O N S E J O ^
Si un sistema o
producto servir o
much os usuarios se
debe tener lo
completa seguridad de
que los requisitos se
obtienen de una
muestra representa-
tivo de los usuarios. Si
slo uno de los
usuarios define todos
los requisitos, el
tiesgo de rech azo es
alto.
s a da s s on i nvi t ados a asi st i r. La sol i ci t ud de pr oduct o s e di st ri buye a t odos l os asi s-
t ent es a nt e s de la f echa de r euni n.
Mi ent r as revi sa la sol i ci t ud de pr oduct o en l os d as pr evi os a la r euni n, s e pi de a
cada as i s t ent e hace r u na lista de obj et os que s on par t e del ambi e nt e que r odea al sis-
t ema, ot r os obj et os que st e pr oduci r , y obj et os que utiliza par a r eal i zar s us f un-
ci ones. Adems , s e le pi de a cada asi st ent e que el abor e una lista de l os servi ci os
( pr ocesos o f unci ones) que mani pul an o i nt er act an con l os obj et os. Por l timo,
t ambi n s e pr epar an l i st as de l as r est r i cci ones (por ej empl o, cost o, t a ma o, r egl as
del negoci o) y de l os cri t eri os de r endi mi ent o (por ej empl o, vel oci dad, exact i t ud). Se
i nf or ma a l os as i s t ent es que no s e e s pe r a que l as l i st as s e a n exhaust i vas, s i no que
refl ej en la per cepci n que cada pe r s ona t i ene del si st ema.
Como un ej empl o, 9 cons i dr es e el f r a gme nt o de u n doc u me nt o pr evi o a la reu-
ni n, escr i t o por u na pe r s ona de me r cadot e cni a i nvol ucr ada e n el pr oyect o de
HogarSeguro. Esta per s ona escri be la si gui ent e nar r aci n acer ca de la f unci n de segu-
ridad en el hogar que s er par t e de HogarSeguro.
Nuestra investigacin indica que el mercado para los sistemas de administracin del ho-
gar est creciendo a una tasa de 40 por ciento anual. La primera funcin de HogarSeguro
que saquemos al mercado debera ser ia funcin de seguridad en el hogar. La mayora de
la gente est familiarizada con los "sistemas de alarma", por lo que dicha funcin sera f-
cil de vender.
La funcin de seguridad en el hogar protegera contra o reconocera una variedad de
"situaciones" indeseables como una entrada ilegal, fuego, inundaciones, niveles de mo-
nxido de carbono y otras. Utilizar nuestros sensores inalmbricos para detectar cada si-
tuacin, el usuario podr programarla y llamar por telfono automticamente a una
oficina de monitoreo cuando detecte alguna situacin.
En r eal i dad, ot r os podr an cont r i bui r a est e r el at o dur ant e la r euni n par a la r eco-
pi l aci n de r equi si t os, y mu c ha m s i nf or maci n est ar a di sponi bl e. Per o a u n con
i nf or maci n adi ci onal , la ambi ge dad podr a es t ar pr es ent e, e s pr obabl e q u e exi s-
t i eran omi s i ones y podr an ocurri r er r or es. Por ahor a, la "descri pci n f unci onal "
ant er i or s er suf i ci ent e.
El e qui po de r ecopi l aci n de r equi si t os lo c o mp o n e n r e pr e s e nt ant e s de l os de par -
t a me nt os de mer cadot ecni a, de i ngeni er a de ha r dwa r e y s of t wa r e y de manuf act u-
ra. Se ut i l i zar un mode r a dor ext er no.
Cada pe r s ona desar r ol l a l as l i st as pr e vi a me nt e descr i t as. Los obj et os descr i t os
par a HogarSeguro podr an i ncl ui r el panel de cont rol , l os det ect or es de humo, los
s e ns or e s en pue r t a s y vent anas , l os det ect or es de movi mi ent o, u na al ar ma, un even-
t o ( cuando al gn s e ns or se act i ve), u na pant al l a, u na PC, n me r o s t el ef ni cos, una
9. El ejemplo de HogarSeguro (con extensiones y variaciones) se utiliza para ilustrar mtodos impor-
tantes de la ingeniera del software en muchos de los captulos que siguen. Como ejercicio, seria til
realizar una reunin para la recopilacin de requisitos propia y desarrollar una serie de listas para
sta.
TM
PDF Editor
169
l l amada t el ef ni ca y ot r os. La lista de ser vi ci os podr a incluir la configuracin del si s-
t ema, la colocacin de la al ar ma, el monitoreo de s ens or es , la marcacin t el ef ni ca,
la programacin del panel de cont r ol y la lectura de pant al l a ( obsr vese que los s er -
vi ci os act an s obr e l os obj et os) . De u na ma n e r a simil ar, cada as i s t ent e el abor ar lis-
t as de r est r i cci ones (por ej empl o, el s i s t ema de be r econocer c u a ndo l os s e ns or e s n o
e s t n en f unci onami ent o, de be s er ami gabl e par a el usuar i o, de be t ener u na i nt er f az
di r ect a con la l nea t el efni ca) y cr i t er i os de r e ndi mi e nt o (por ej empl o, el e ve nt o de
un s e ns or de be s er r econoci do en u n s e gu ndo o me nos ; s e debe i mpl ement ar un
e s q u e ma par a la pri ori dad de l os event os) .
" l o s h e c h o s n o d e j a n d e e xi s t i r s l o p o r que s o n i gn o r a d o s . "
Aldoas Huxley
i r e p r i m i r el
t e i g n o r a r la
i c e n t e p o r
N A c o s t o s o " 0
i t c t i c a " . L a
n a que s
r u n o l i s t o q u e
p a r a
i l o g r a r
b
ib mente
Cua ndo se inicia la r euni n par a la r ecopi l aci n de doc ume nt os , el pr i mer t pi co
q u e s e t r at a e s la nes es i dad y la j ust i fi caci n pa r a el nue vo pr oduct o, t odos de be n
est ar de a c ue r do en que la ne ce s i dad del pr oduct o s e j ust i fi ca. Una ve z est abl eci do
el acue r do, cada par t i ci pant e pr es ent a s us l i st as par a exami nar l as . Las l i st as pue de n
fijarse e n l as pa r e de s del sal n u s a ndo hoj as gr a nde s de papel , pe gar s e en l os mur os
me di ant e hoj as adhes i vas o escr i bi r se en un pi zar r n. De ma n e r a al t er nat i va, l as lis-
t as pu e de n ha be r si do col ocadas e n un bol et n el ect r ni co, en un si t i o Web i nt er no,
o s i t uadas dent r o de u n a mbi e nt e de f or o de di scusi n (ch at room) par a r evi sar l as
a nt e s d e la r euni n. En f or ma i deal , cada a s unt o en la lista debe per mi t i r mani pu-
l arse por s e pa r a do pa r a que l as l i st as se pu e da n combi nar , l os a s u nt os pue da n
bor r ar se y s e l es pu e da n r eal i zar adi ci ones. En es t a e t apa la crtica y el de ba t e e s t n
es t r i ct ament e pr ohi bi dos.
Des pus de que l as l istas i ndi vi dual es s obr e el r ea de un t pi co s e hayan pr e-
s ent ado, el gr upo cr ea u na lista c ombi na da . Di cha lista el i mi na l os a s u nt os r e dun-
dant es , i ncor por a i deas nu e va s sur gi das dur a nt e el debat e, pe r o n o bor r a na da .
Des pus de ha be r s e c r e a do l as l i st as c ombi na da s par a t oda s l as r e a s de l os di st i n-
t os t pi cos, el mode r a dor coor di na el debat e. La lista combi nada s e r educe, se
i ncr ement a o r epl ant ea par a r ef l ej ar de ma ne r a apr opi ada el pr oduc t o/ s i s t e ma q u e
s e desar r ol l ar . El obj et i vo e s desar r ol l ar una lista c ons e ns a da en el r ea de cada
t pi co (obj et os, servi ci os, r est r i cci ones y r endi mi ent o) . De s pus di chas l i st as s e i nt e-
gr an par a la acci n post er i or .
Cua ndo s e compl e t an l as l istas c ons e s a da s , el equi po s e di vi de en s ube qui pos
me nor e s ; cada uno t r abaj a par a desar r ol l ar miniespecificaciones par a u n o o m s
a s u nt os de cada u na de l as l i st as. 10 Cada mi ni especi f i caci n e s una expl i caci n con-
ci sa de la pal abr a o f r ase cont eni da en la lista. Por ej empl o, la mi ni especi f i caci n
par a el obj et o P a n e l d e c o n t r o l de HogarSeguro podr a ser:
10 En lugar de crear miniespecificaciones, muchos equipos de software eligen desarrollar escenarios
del usuario llamados casos de uso. stos se consideran con detalle en la seccin 7.5.
r
TM
PDF Editor
1 1
El Pa n e l d e c o n t r o l es una unidad empotrada en la pared con un tamao aproximado de
9 x 5 pulgadas. El panel de control tiene conexin inalmbrica con los sensores y una PC
La interaccin con el usuario ocurre por medio de un tablero de 12 teclas. Una pantalla
LCD de 2 x 2 pulgadas proporciona la retroalimentacin del usuario. El software provee
sugerencias e imgenes interactivas y funciones similares.
Despus, cada s ube qui po pr es ent a s u s mi ni especi f i caci ones a t odos los asi st ent es
par a coment ar l as . Se r eal i zan l as adi ci ones, anul aci one s y el abor aci ones post en: -!
res. En al gunos casos, el desar r ol l o de l as mi ni especi f i caci ones descubr i r nueve*
r equi si t os de obj et os, servi ci os, r est r i cci ones y r endi mi ent o que s e agr e gar n a las
l i st as ori gi nal es. Dur ant e l os de ba t e s el equi po e ncont r ar al gn a s u nt o que i
pue da r esol ver se dur a nt e la r euni n. Se ma nt e ndr una lista de a s u nt os pendi ent es
par a que de s pus s e pue da act uar s obr e e s t a s i deas.
De s pus de compl et ar l as mi ni especi f i caci ones, cada asi st ent e ha c e una lista a
cri t eri os de val i daci n par a el pr oduc t o/ s i s t e ma y la pr es ent a al equi po. Ent onces s a
cr ea u na lista c ons e ns a da de cri t eri os de val i daci n. Por l t i mo, u n o o m s p a r t i !
pa nt e s (o a ge nt e s e xt e mos ) r eci ben el e nc a r go de escri bi r l as es peci f i caci ones c o r - i
pl et as me di ant e el u s o de t oda s l os a s u nt os t r at ados en la r euni n.
HOGARSEGURO
Guiar una reunin para a recopilacin de requisitos
Ei e s c e n a r i o : Una sala de
reuniones. Se real iza la pri mera reunin pa r a l a
recopilacin d e requisitos.
Lo s a c t o r e s : Jami e Lazar, mi embro del equi po de
soft ware; Vinod Raman, mi embro del equi po de
software; Ed Robbins, mi embro del equi po de soft ware;
Doug Miller, mi embro del equi po de soft ware; tres
miembros de mercadot ecni a; un represent ant e d e
ingeniera del product o; y un moderador.
La c o n ve r s a c i n : .
Mo d e r a d o r ( a p un t a n d o h a c i a e i p i za r r n
b l a n c o ) : Entonces s a es la lista actual d e obj et os y
servicios pa r a la funcin de seguri dad en el hogar.
Pe r s o n a d e m e r c a d o t e c n i a : Desde nuestra
perspectiva, esta lista abar ca t oda la funcin.
Vi n o d : Nadi e menci on que los usuari os quer an t oda
la funci onal i dad de Hogar Segur o accesi bl e por Internet?
Eso incluira la funcin de seguri dad en el hogar, no?
Pe r s o n a d e m e r c a d o t e c n i a : S, es correcto...
tendremos que agr e gar es a funci onal i dad y los objetos
apr opi ados. '{
Facilitador: Eso t ambi n agr e ga al gunas
restricciones?
J a m i e : S, tanto tcnicas como legales.
Re p r e s e n t a n t e d e p r o d uc c i n : Y eso qu
significa?
J a m i e : Debemos estar seguros de que al guien ext erno
no pueda entrar en el sistema, des ar mado y robar la
casa o hacer al go peor. Gr an part e d e la
responsabi l i dad r ecae en nosotros.
Do ug: Muy cierto.
Me r c a d o t e c n i a : Pero aun as necesitamos la
conectvidad por Internet... slo asegrense de impedir
que cualquier intruso entre.
Ed : Es ms fcil decirlo que hacerl o y. . .
Mo d e r a d o r (i n t e r r um p i e n d o ) : No quiero debatir
este asunt o ahor a. Anotemos q u e es una accin que
de be real i zarse y continuemos.
(Doug, que lleva el registro de b reunin, hace la
anot aci n correspondiente. )
Mo d e r a d o r : Siento que an hay ms cosas por
consi derar aqu .
(El gr upo utiliza los siguientes 4 5 minutos en refinar y
expandi r los detalles d e la funcin d e seguri dad en el
hogar. )
TM
PDF Editor
171
7.4.2 Despl i egue de l a f unci n de cal i dad
El despliegue de la Juncin de calidad (QFD. por sus siglas en ingls) es una tcnica
que t raduce l as necesi dades del cliente en requisitos t cni cos para el soft ware. El
QFD "se concent ra en aument ar la satisfaccin del cliente desde el proceso de la
ingeniera del sof t war e [ZUL92]." Para lograr lo anterior, el QFD resal t a una com-
prensi n de lo que es val ioso para el cliente y despus despliega est os val ores duran-
te el pr oceso de ingeniera. El QFD identifica t res tipos de requisitos [ZUL92]:
Re qui s i t o s n o r m a l e s . Reflejan los objetivos y met as establ ecidos para un pro-
duct o o si st ema dur ant e las reuni ones con el cliente. Si est os requisitos est n pre-
sent es, el cliente est ar satisfecho. Al gunos ej empl os de requisitos normal es podr-
an ser los tipos de grficos en pantalla, las funci ones especficas del si st ema, y los
niveles de rendi mi ent o solicitados.
Re qui s i t o s e s p e r a d o s . Estn implcitos en el producto o sistema y pueden parecer
tan obvios, aunque son fundamental es, que el cliente no los establece de manera expl-
cita. Su ausencia causara una insatisfaccin significativa. Algunos ejemplos de requisi-
tos esperados son la facilidad de la interaccin humano/ mqui na, correccin y confia-
bilidad operacional general y facilidad en la instalacin del software.
Re qui s i t o s e s t i m ul a n t e s . Reflejan l as caract er st i cas que van ms all de l as
expect at i vas del cliente y que pr ueban ser muy sat i sfact ori as cuando est n presen-
tes. Por ejempl o, un sof t war e procesador de pal abras se solicita con caract er st i cas
est ndar. El product o ent r egado cont i ene vari as capaci dades de confi guraci n de
pgi na que son bast ant e sat i sfact ori as e i nesperadas.
En la actualidad, el QFD abarca la totalidad del proceso de ingeniera [PAR96]. Sin
embargo, muchos conceptos del QFD son aplicables a la actividad de obtencin de requi-
sitos. En los prrafos siguientes se presenta una visin general de dichos conceptos
(adaptados para el software de computadora).
"A m e n ud o l o s e xp e c t a t i va s fa l l a n , y e n t r e m s l o h o c e n m s p r o m e t e n . *
W i l fi a m Sh a k e s p e a r e
En las reuni ones con el cliente, la Juncin de despliegue se aplica para det ermi nar
el valor de cada funcin que se requiere para el si st ema. El despliegue de la informa-
cin identifica l os dat os de los obj et os y event os que debe consumi r y produci r el sis-
t ema. Los dat os est n ligados a las funci ones. Por ltimo, el despliegue de tareas exa-
mi na el compor t ami ent o del si st ema o product o dent ro del cont ext o de su ent orno.
El anlisis de valor se realiza para det ermi nar la prioridad relativa de los requisitos
det er mi nados durant e cada uno de los tres despliegues.
El QFD utiliza ent revi st as y observaci n del cliente, sondeos y exploracin de los
dat os histricos (por ejempl o, l os report es de probl emas) como dat os crudos para la
actividad de recopilacin de requisitos. Despus, est os dat os se t raducen en una
TM
PDF Editor
172
tabla de requi si t os l l amada la tabla de la voz del cliente que s e revi sa con el cliente
Una vari edad de di agr amas, mat r i ces y mt odos de eval uaci n s e utilizan par a obt ener
l os requi si t os es per ados y t rat ar de consegui r los requi si t os est i mul ant es [BOS91].
7.4.3 Escenari os del usuar i o
Conf or me se r ecopi l an l os r equi si t os s e c omi e nz a a mat er i al i zar una vi si n ge ne r a
de l as f unci one s y car act er st i cas del si st ema. Sin embar go, r esul t a difcil cont i nuar
con act i vi dades de i ngeni er a del s of t war e m s t cni cas mi e nt r as el equi po de soft-
wa r e no ent i enda la ma ne r a en que l as di st i nt as cl ases de us uar i os f i nal es apl i car n
e s t a s f unci one s y car act er st i cas. Par a l ograrl o, l os des ar r ol l ador es y us uar i os pue-
den cr ear un conj unt o de es cenar i os que i dent i fi can u na c a de na de us o par a el sis-
t e ma que s e va a const r ui r . Los es cenar i os , l l amados con f r ecuenci a casos de use
(JAC92], pr opor ci onan una descr i pci n de c mo s e us ar el si st ema. Los c a s os de
us o se e xa mi na n con un mayor det al l e en la secci n 7.5.
HOGARSEGURO
Desarrollo de un escenario de uso preliminar
El e s c e n a r i o : Una sala de
euniones. Contina la primera reunin par a la
recopilacin de requisitos.
Lo s a c t o r e s : Jami e Lazar, miembro del equi po de
software; Vinod Romn, miembro del equi po de
software; Ed Robbins, miembro del equi po de software;
Doug Miller, miembro del equi po de software; tres
miembros de mercadotecnia; un representante de
ingeniera del producto; y un moderador.
La c o n ve r s a c i n :
Mo d e r a d o r : Hemos estado habl ando acerca de la
seguridad par a el acceso a la funcionalidad de
HogarSeguro, la cual ser accesible por Internet. Me
gustara tratar al go.
Desarrollemos un escenario de uso par a el acceso a la
funcin de seguri dad en el hogar.
J a m i e : Cmo? "
Mo d e r a d o r : Podemos hacerlo de un par de formas,
pero por ahor a me gustara mantener las cosas
realmente informales. Dinos (y apunt a a una persona de
mercadotecnia) cmo visualizas el acceso al sistema.
Pe r s o n a d e m e r c a d o t e c n i a : Humm. . . , bueno, es lo
que hara si estuviera fuera de casa y tuviera que dej ar a
alguien dentro, di gamos una persona de limpieza o un
tcnico en reparaci ones, quien no tendra el cdi go de
seguridad.
Mo d e r a d o r ( s o n r i e n d o ) : sa es la razn por lo que
lo har as. . . dime cmo lo har as realmente.
Pe r s o n a d e m e r c a d o t e c n i a : Humm. . . , la primera
cosa que necesitara es una PC. Entrara en un sitio web
que tendramos par a todos los usuarios de HogarSeguro.
Introducira mi identificacin de usuario y. . .
Vi n o d ( i n t e r r um p i e n d o ) : La pgi na web tendra que
estar asegur ada, codificada, par a garant i zar que
estamos seguros y. . .
Mo d e r a d o r ( i n t e r r um p i e n d o ) : sa es una buena
informacin, Vinod, pero es tcnica. Vamos a enfocarnos
en la forma en que el usuario final usar esta capaci dad,
de acuerdo?
Vi n o d : No hay probl ema.
Pe r s o n a d e m e r c a d o t e c n i a : Entonces, como est aba
diciendo, entrara en ei sitio web e introducira mi
identificacin de usuario y dos niveles de contrasea.
J a m i e : Qu pasa si olvido mi cont rasea?
Mo d e r a d o r ( i n t e r r um p i e n d o ) : Buen punto, Jamie,
pero no vamos a profundi zar en eso ahor a. Haremos
una not a del tema y la llamaremos una "excepcin*.
Estoy seguro que existirn otras.
Pe r s o n a d e m e r c a d o t e c n i a : Despus de introducir
las contraseas, apar ecer una pantalla represent ando
t odas las funciones de SafeHome. Seleccionara lo
funcin de seguridad en ei hogar. El sistema podr a
requerir que yo verificara quin soy, di gamos
pregunt ndome mi direccin, telfono o al go as.
TM
PDF Editor
1 7 3
despl egar a una i magen del panel d e control del
de seguri dad, unto con una lista de las funci ones
puedo real izar: activar el sistema, desactivar el
desactivar uno o ms sensores. Supongo q u e
i podr a permitirme reconfi gurar las zonas de
' y ot ras cosas como sa, pero no estoy seguro.
(Mientras la per sona de mercadot ecni a contina
habl ando, Doug toma las notas correspondi ent es. Dichas
not as forman la base pa r a el primer caso de uso
informal. De maner a alternativa, se le pudo haber
pedi do a la per sona d e mercadot ecni a que escribiera el
escenari o, pero esto se har a fuera d e la reunin. )
7.4.4 Product os de t r abaj o de l a obt enci n
Los pr oduct os de t r abaj o pr oduci dos c o mo cons ecuenci a de la obt enci n de requi si -
t os var i ar de a c ue r do con el t a ma o del si st ema o pr oduct o que s e vaya a const r ui r .
La mayor a de l os s i s t e mas i ncl uye l os si gui ent es pr oduct os de t r abaj o:
Un e nunc i a do de ne ce s i dad y fact i bi l i dad.
Un e nunc i a do l i mi t ado del mbi t o del s i s t ema o pr oduct o.
Una lista de cl i ent es, us uar i os y ot r os i nt er es ados que par t i ci par on en la
obt enci n de requi si t os.
Una descr i pci n del a mbi e nt e t cni co del si st ema.
Una lista de r equi si t os (de ma ne r a pr ef er ent e or ga ni z a dos por f unci n) y l as
r est r i cci ones de domi ni o apl i cabl es a c a da uno.
Un conj unt o de e s ce nar i os de u s o q u e pr opor ci onen un di s cer ni mi ent o de la
ut i l i zaci n del si st ema o pr oduct o en di f er ent es condi ci ones de oper aci n.
Cual esqui er a pr ot ot i pos des ar r ol l ados par a defi ni r de mej or f or ma l os r equi -
si t os.
Cada u n o de e s t os pr oduct os de t r abaj o l os r evi sa t oda la ge nt e que ha par t i ci pado
en la obt enci n de requi si t os.
7 . 5 D E S A R R O L L O P E C A S O S DE USO
En un libro q u e anal i za la ma ne r a de escri bi r c a s os de us o ef i caces, Alistair Cockbur n
[COCO 1 ] me nc i ona que "un c a s o de us o capt ur a un cont r at o. . . [que] descr i be el c om-
por t a mi e nt o del si st ema e n di f er ent es condi ci one s mi e nt r as s t e r e s ponde a la pet i -
ci n de u n o de s us usuar i os". En esenci a, un caso de uso cuent a una hi st ori a estili-
zada de la ma n e r a en que un us uar i o final (el cual de s e mpe a u n o de var i os pa pe -
l es posi bl es) i nt er act a con el s i s t ema en un conj unt o espec f i co de ci r cunst anci as.
La hi st ori a pue de s er un t ext o nar r at i vo, un e s q u e ma de t a r e a s o i nt er acci ones, u na
descr i pci n ba s a da en u na pl ant i l l a o una r epr es ent aci n por me di o de di agr amas .
Sin i mpor t ar su f or ma, un c a s o de us o mue s t r a el s of t wa r e o si st ema de s de el punt o
de vi st a del us uar i o final.
El pr i mer p a s o al escri bi r un c a s o de us o consi st e en defi ni r el conj unt o de "act o-
r es" q u e e s t ar n i nvol ucr ados en la hi st ori a. Los actores s on l as di f er ent es pe r s ona s
kVE
" u s s e
: d p un t o
B o cto r .
p o p e l
l o s
i cua n d o
c o r e l
TM
PDF Editor
174
www. r a t i o n d .
t o m / p r o d o c t s /
wh i t e p a p e r s /
1 0 0 6 2 2 . s p p u e d e
bojoise un excelente
documento sobre los
casos de uso.
? Qu s e
n e c e s i t a
s a b e r p a r a d e s a -
r r o l l a r un c a s o d e
us o e f i c a z ?
. 1HB
P A S T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
(o di sposi t i vos) que ut i l i zan el s i s t ema o pr oduct o dent r o del cont ext o de la f unci r
y el c ompor t a mi e nt o que se descri bi r. Los act or es r epr es ent an l os pape l e s que jue-
gan l as pe r s ona s (o di sposi t i vos) c onf or me el s i s t ema oper a. Def i ni do de u na mane-
r a m s f or mal , un act or e s al gn e l e me nt o que s e comuni ca con el s i s t ema o pro-
duct o y que e s ext er no al s i s t ema e n s mi s mo. Cada act or t i ene u na o m s met as
c u a ndo ut i l i za el si st ema.
Es i mpor t ant e s e al ar que un act or y un us uar i o final n o s on ne c e s a r i a me nt e le
mi s mo. Un us uar i o t pi co pue de de s e mpe a r var i os pape l e s al us a r u n si st ema
mi ent r as que u n act or r e pr e s e nt a u na cl ase de ent i dad ext er na (con f r ecuenci a, per-
n o si empr e, u na per sona) que d e s e mp e a sl o u n papel en el cont ext o del cas o de
us o. Como un ej empl o, cons i dr es e al ope r ador de una m q u i na (un usuar i o) que
i nt er act a con la c omput a dor a de cont r ol pa r a u na cl ul a de ma nuf a c t ur a que con-
t i ene var i os r obot s y m qui na s de cont r ol numr i co. Des pus de la revi si n cui da-
dos a de l os requi si t os, el s of t wa r e par a la c omput a dor a de cont r ol r equi er e cuat rc
di f er ent es mo d o s (act ores) par a su i nt er acci n: mo d o de pr ogr amaci n, mo d o de
pr ueba, mo d o de moni t or eo y mo d o de r esol uci n de pr obl emas . Por lo t ant o, se
pue de n defi ni r cuat r o act or es: el pr ogr amador , el que r eal i za l as pr uebas , el que
moni t or e a y el que r esuel ve l os pr obl emas . En al gunos c a s os el oper ador de la
m qui na pu e de de s e mpe a r t odos es t os papel es. En ot r as si t uaci ones, s on per s onas
di f er ent es l as que pu e de n de s e mpe a r el papel de cada act or.
Como la obt enci n de r equi si t os e s u na act i vi dad evol ut i va, no t odos l os act or es
s e i dent i f i can dur ant e la pr i mer a i t er aci n. Dur ant e st a e s posi bl e i dent i fi car los
act or es pr i mar i os 0AC92], mi e nt r as que l os act or es s e cundar i os s e i dent i f i can con
f or me s e apr e nde m s acer ca del si st ema. Los actores primarios i nt er act an par a
l ograr la f unci n r equer i da del s i s t ema y obt i enen el benef i ci o que s e es per a de st e
Ellos t r abaj an de ma ne r a di rect a y f r e cue nt e con el s of t war e. Los act or es s ecunda-
rios dan s opor t e al si st ema de ma ne r a que l os act or es pr i mar i os pu e da n ha c e r su t ra-
baj o.
Ya i dent i f i cados l os act or es pue de n desar r ol l ar se l os c a s os d e us o. J acobs on
[JAC92] s ugi er e var i as pr egunt as1 1 que s e deber an cont es t ar me di ant e un c a s o de
uso.
Qui n(es) es( son) el(los) act or(es) pri mari o(s)?
Cul es s on l as me t a s del act or ?
Cul es s on l as condi ci ones pr evi as que de be n exi st i r a nt e s de c o me n z a r la
hi st or i a?
Cul es s on l as t a r e a s o f unci ones pr i nci pal es que real i za el act or ?
Cul es e xce pci one s podr an cons i der ar s e mi e nt r as s e descr i be la hi st or i a?
Cul es s on l as var i aci ones posi bl es en la i nt er acci n del act or ?
11 Las preguntas de Jacobson se han extendido para proporcionar una visin ms completa del conte-
nido del caso de uso.
TM
PDF Editor
CAPTULO 7 INGENIERA DE REQUISITOS
175
Cul e s la i nf or maci n del s i s t ema que el act or adqui ri r, pr oduci r o
cambi ar ?
El act or t e ndr que i nf or mar al si st ema acer ca de cambi os en el me di o
a mbi e nt e ext er no?
Cul e s la i nf or maci n que el act or de s e a del s i s t ema?
El act or qui er e s er i nf or mado acer ca de cambi os i nes per ados ?
Como s e r ecor dar , l os r equi si t os bs i cos de HogarSeguro def i nen t r es act or es: el
p r o p i e t a r i o d e l a c a s a (un usuari o), u n a d m i n i s t r a d o r d e l a c o n f i gur a c i n
( pr obabl ement e la mi s ma pe r s ona que el p r o p i e t a r i o , pe r o en u na f unci n di f er en-
te), l os s e n s o r e s (di sposi t i vos agr e gados al si st ema) , y el s u b s i s t e m a d e m o n i t o -
r e o (la es t aci n cent r al que moni t or e a la f unci n de s egur i dad en el hogar donde
es t i nst al ado HogarSeguro) . Par a l os pr ops i t os de est e e j e mpl o s l o s e consi der a
al act or p r o p i e t a r i o . st e i nt er act a con la f unci n de segur i dad en el hogar en di fe-
r ent es f or mas me di a nt e el us o el panel de cont r ol de la al ar ma o u na PC:
I ngr esa u na c ont r a s e a par a permi t i r t oda s l as d e m s i nt er acci ones.
I ndaga acer ca del es t at us de u na z ona de segur i dad.
I ndaga acer ca del es t at us de un s ens or .
Pr esi ona el bot n de pni co en c a s o de emer genci a.
Act i va/ des act i va el si st ema de segur i dad.
Si s e cons i der a la si t uaci n e n la cual el pr opi et ar i o ut i l i za el panel de cont rol , el c a s o
de us o bsi co par a la act i vaci n del s i s t ema s e pr es ent a de la si gui ent e maner a: 1 2
HogarSeguro
n i
Ul
a l a r ma
veri fi car
f u e go
- -y.; '
sal i da
en c a s a
i nst ant e
des vi aci n
no listo
A
act i vado e nc e ndi do
O o
a p e g a d o sal i da en c a s a
uJ 0 0
max pr u e ba des vi aci n
CU CD CD
i nst ant e c di go
0 0
listo
000
' p a n ico '
12 Ntese que este caso de uso difiere de la situacin en la cual se entra en el sistema a travs de In-
ternet. En este caso, la interaccin se lleva a cabo por medio del panel de control, el acceso es dife-
rente que cuando se utiliza una PC.
TM
PDF Editor
176 P A R T E D O S PRCTICA DE LA INGENIERA D A SOFTWARE
1. El propietario observa el panel de control de HogarSeguro (figura 7.2) para determinar si
el sistema est listo para entrar. Si el sistema no est listo se despliega un mensaje de
no listo sobre la pantalla LCD, y el propietario debe cerrar en forma fsica puertas y ven-
tanas para que el mensaje desaparezca. (Un mensaje de no listo implica que un sensor
se encuentra abierto; es decir, que una puerta o ventana est abierta.)
2 El propietario utiliza el teclado para introducir una contrasea de cuatro dgitos. La con-
trasea se compara con la clave almacenada en el sistema. Si la contrasea es inco-
rrecta, el panel de control emitir un sonido y se reiniciar para recibir otra entrada. Si la
contrasea es correcta, el panel de control esperar la siguiente accin.
3. El propietario selecciona e introduce en casa o salida (vase la figura 7.2) para activar el
sistema. En casa activa slo los sensores del permetro (los sensores para la deteccin
de movimiento interno se desactivan). Salida activa todos los sensores.
4. Cuando se realiza la activacin, el propietario puede observar una luz roja de alarma.
El c a s o de us o bs i co pr es ent a una hi st ori a de al t o ni vel que descr i be la i nt er acci n
ent r e el act or y el si st ema.
En mu c h a s ocas i ones , l os c a s os de us o t i enen una mayor el abor aci n par a pro-
por ci onar m s det al l es acer ca de la i nt er acci n. Por ej empl o, Cockbur n [COCOi;
sugi er e la si gui ent e pl ant i l l a par a l as descr i pci ones det al l adas de l os c a s os de uso
^ O N S E J O ^
Con frecuencia, los
osos de uso se
escriben de manera
informal. Sin
embaigo, se reco-
mienda el uso de lo
plantilla mostrada
oqul pora aseguro:
que se consideren
todos los aspedos
clave.
Ca s o d e us o :
Ac t o r p r i m a r i o :
Me t a e n e l c o n t e xt o :
Co n d i c i o n e s p r e vi a s :
Ac t i va d o r :
Inicio de monitoreo
Propietario de la casa.
Establecer el sistema para monitorear los sensores
cuando el propietario salga de la casa o permanez-
ca dentro ella.
El sistema ha sido programado para una contrase-
a y reconocer diferentes sensores.
El propietario decide "iniciar" el sistema, es decir,
encender las funciones de alarma.
Es c e n a r i o :
1. Propietario: observa el panel de control.
2. Propietario: introduce la contrasea.
3. Propietario: selecciona "en casa" o "salida".
4. Propietario: observa la luz roja de alarma para indicar que HogarSeguro est en ope-
racin.
Exc e p c i o n e s :
1. El panel de control no est listo: el propietario verifica todos los sensores para deter-
minar cules estn abiertos; los cierra.
2. La contrasea es incorrecta (el panel de control emite un sonido): el propietario intro-
duce de nuevo la contrasea correcta.
3. La contrasea no es reconocida: debe contactarse el subsistema de monitoreo y res-
puesta para reprogramar la contrasea.
4. Se selecciona en casa: el panel de control emite un sonido doble y se enciende la luz
de en casa; se activan los sensores del permetro.
TM
PDF Editor
177
5. Se selecciona salida: el panel de control emite un sonido triple y se enciende la luz de
salida; se activan todos los sensores.
Pr i o r i d a d :
Di s p o n i b l e d e s d e :
F r e c ue n c i a d e us o :
Ca n a l h a c i a e l a c t o r :
Ac t o r e s s e c un d a r i o s :
Esencial, debe implementarse.
El primer incremento.
Muchas veces al da.
A travs de la interfaz del panel de control.
Tcnicos de soporte, sensores.
\
CLAVE
r t e r e s o d o s p ue d e n
r codo c a s o de
11 s i g n a r l e su
i relativa.
Ca n a l e s h a c i a l o s a c t o r e s s e c un d a r i o s :
Tcnico de soporte: lnea telefnica.
Sensores: interfaces almbricas e inalmbricas.
As un t o s p e n d i e n t e s :
1. Debera haber una forma de activar el sistema sin el uso de una contrasea o con una
clave abreviada?
2. El panel de control debera desplegar otros mensajes de texto?
3. De cunto tiempo dispone el propietario para introducir la contrasea desde el
moment o en que presiona la primera tecla?
4. Existe alguna forma de desactivar el sistema antes de que ste se active en realidad?
Los c a s os de u s o par a l as ot r as i nt er acci ones del p r o p i e t a r i o s e desar r ol l ar an de
u na ma n e r a si mi l ar. Es i mpor t ant e s eal ar que cada c a s o de us o de be r evi sar se con
cui dado. Si al gn e l e me nt o de la i nt er acci n e s ambi guo, exi st e la posi bi l i dad de que
u na revi si n del c a s o de us o des cubr a el pr obl ema.
HOGARSEGURO
Desarrollo de un diagrama de alto nivel para un caso de uso
nes. Contina la reunin par a la recopilacin de
requisitos.
Lo s a c t o r e s : Jami e Lazar, miembro del equi po de
s o ft wa r e ; Vinod Raman, miembro del equipo de software;
zz Robbins, miembro del equi po de software; Doug
ir, miembro del equi po de software; tres miembros de
- e- cadot ecni a; un representante de ngeniera del
rroducto; y un moderador.
l a c o n ve r s a c i n :
a r a d o r : Hemos invertido bastante tiempo
i acerca de la funcin de seguridad en el hogar
l HogarSeguro. Durante el descanso dibuj un
i ogr ama de caso de uso para resumir bs escenarios
s que son parte de esta funcin. Denle un vistazo,
i los asistentes ven la figura 7. 3)
J a m i e : Apenas estoy comenzando a apr ender la
notacin del UML. Entonces, la funcin de seguri dad en
el hogar b representa la caj a gr ande con los valos en
su interior? Y los vabs representan b s casos de uso
que escribimos en texto?
Mo d e r a d o r : S. Y las figuras pegadas representan
actores; es decir, las personas o cosas que interactan
con ei sistema segn se describe en el caso de uso. . . ah,
y utilic el cuadro etiquetado par a representar un actor
que no es una persona, en este caso son sensores.
Do ug : Eso es legal en el UML?
Mo d e r a d o r : Lo legalidad no es el punto. Lo importante
es comunicar b informacin. Yo pienso que el uso de una
figura que parece una persona pero que representa un
dispositivo puede confundirnos. Entonces he adapt ado
un poco b s cosas. No creo que esto represente un
problema.
TM
PDF Editor
178
Vi n o d : De acuer do, ent onces t enemos narrat i vos d e
cas os d e uso p a r a c a d a uno d e los val os. Necesi t amos
desar r ol l ar nar r at i vas m s det al l adas con bas e en
plantillas? He l edo a c e r c a d e ellas.
Mo d e r a d o r : Pr obabl ement e, pe r o eso pue de e s pe r ar
hast a q u e ha ya mos cons i de r ado ot r as f unci ones de
HogarSeguro.
P e r s o n a d e m e r c a d o t e c n i a : Esperen, he e s t ado
vi endo est e di a gr a ma , y d e r epent e me di cuent a q u e
he mos ol vi dado al go.
Mo d e r a d o r : De ver dad? Qu es l o que ol vi damos?
(La reuni n cont i na)
D i a g r a m a d e
c a s o d e u s o
p a r a l a
f u n c i n d e
s e g u r i d a d e n
e l h o g a r d e
HogarSeguro.
desactiva
sistema
Entra en el
sistema por
. Internet .
l i et ar i o
j c a s a
Responde c
evento de
v al ar ma^
' Encuentra
una condick
V de error
Ad mi n i s t r a d o r
d e l s i s t e ma
sensores y tas
caractersticas
del sistema
Desarrollo de casos de uso

Ob j e t i v o : Ayuda en el desarrol l o de cas os d e
uso al pr opor ci onar plantillas que slo
requi eren el l l enado d e espaci os en bl anco, pa r a as cr ear
cas os d e uso ef i caces. La mayor a d e las f unci onal i dades
pa r a los cas os d e uso est n i ncl ui das en un conj unt o d e
f unci ones ms ampl i o pa r a la i ngeni er a d e requisitos.
He r r a m i e n t a s r e p r e s e n t a t i v a s ' 3
Clear Requirement Workbench , des ar r ol l ado por LiveSpecs
Sof t war e (www. l i vespecs. com), pr opor ci ona sopor t e
aut omat i zado p a r a la cr eaci n y eval uaci n d e cas os
d e uso, as c omo una var i edad d e ot r as f unci ones pa r a
. la i ngeni er a d e requisitos.
La vast a mayor a d e las her r ami ent as pa r a el mode l a do
del anl i si s, b a s a d a s en UML, pr opor ci onan sopor t e
gr f i co y en texto p a r a el desar r ol l o y mode l ado d e
cas os d e uso.
Objects by Design, una fuent e pa r a her r ami ent as d e UML
( www. obj ect sbydesi gn. com/ t ool s/ uml t ool s_byCompany
html) pr opor ci ona vnculos compl et os pa r a conocer
her r ami ent as d e est e tipo.
En UseCases. or g ( www. usecases. or g) se pue de encont r ar
una var i edad d e pl antil l as pa r a desar r ol l ar cas os d e
uso, as c omo una ba s e de dat os pa r a soport arl os.
13 Las he r r a mi e nt a s me nc i ona da s aqu s on u n a mue s t r a de e s t a cat egor a. En la mayor a d e l os cas os
l os n o mb r e s e s t n r egi s t r ados por s us r espect i vos des ar r ol l ador es .
TM
PDF Editor
179
I Q D E L Q D E A N L I S I S
^ CONSEJ O^
.ienpre e s u n a b u e n a
o e c i n v o l u c r a r o l o s
n a e s a d o s . U n a d e
te m e j o r e s f o r m a s d e
f a c e r l o e s p e d i r l e a
a a u n o q u e e l a b o r e
o s o s d e u s o q u e
x s a i b o n l a f o r m o e n
p e s e u t i l i z a r e l
s o f t w a r e .
El obj et i vo del model o de anl i si s es describir los domi ni os r equer i dos de i nforma-
ci n, f unci onami ent o y compor t ami ent o par a un si st ema bas ado en comput ador as.
El model o cambi a en f or ma di nmi ca conf or me los i ngeni er os de s of t war e apr enden
m s acer ca del si st ema que se va a const rui r y los i nt er esados ent i enden mej or lo
que necesi t an. Por est a r azn el model o de anl i si s e s una r epr esent aci n de los
requi si t os en un mome nt o det er mi nado, por lo que se esper a que st e cambi e.
Conforme el model o de anl isis evol uci ona, ci ert os el ement os se vol vern relativa-
ment e est abl es, por lo que proporci onarn una base slida para las t ar eas de di seo
que si guen. Sin embar go, ot ros el ement os del model o pueden ser m s voltiles, lo que
indicar que el cliente an no ent i ende por compl et o los requisitos para el si st ema.
El model o de anl isis y los mt odos ut i l i zados para const rui rl o se descri ben con
det al l e en el cap t ul o 8. En las secci ones si gui ent es se pr esent a una breve visin
general .
7.6.1 Elementos del modelo de anlisis
Existen muchas maner as de buscar los requi si t os par a un si st ema basado en compu-
t ador a. Al gunas per s onas i nvol ucradas con el sof t war e di cen que lo mej or e s sel ec-
ci onar un modo de r epr esent aci n (por ej empl o, el caso de uso) y apl i carl o sin t omar
en cuent a t odos l os modos r est ant es. Ot ros pr of esi onal es cr een que resul t a val i oso
utilizar vari os modos de r epr esent aci n par a most r ar el model o de anl isis. Las dife-
r ent es f or mas de r epr esent aci n obl i gan al equi po de sof t war e a consi der ar los
requi si t os desde di st i nt os punt os de vista, un enf oque que t i ene mayor es probabi l i -
dades de descubri r omi si ones, i nconsi st enci as y ambi gedades.
Los el ement os espec fi cos del model o de anl i si s los det er mi na el mt odo de
model ado que se utilice (captulo 8). Sin embar go, existe un conj unt o de el ement os
genri cos comn a la mayor a de ios model os de anlisis:
El e me nt os bas ados e n e s c e nar i os . El si st ema se descri be, desde el punt o de
vista del usuar i o, por medi o de un enf oque bas ado en escenari os. Por ej empl o, los
cas os de us o bsi cos y s us cor r espondi ent es di agr amas de caso de uso (figura 7.3)
evol uci onan par a convert i rse en casos de uso m s el abor ados bas ados e n plantillas.
Los el ement os del model o de anl i si s bas ados en escenar i os con frecuenci a son los
pr i mer os que se desarrol l an dur ant e la el aboraci n del model o. Por tal mot i vo, sir-
ven como una ent r ada par a la creaci n de ot r os el ement os de model ado.
Un enf oque al go di ferent e dent r o del model ado bas ado en escenar i os muest r a las
act i vi dades o f unci ones que han si do defi ni das como par t e de la t area de obt enci n
de requisit os. Est as f unci ones exi st en dent r o de un cont ext o de pr ocesami ent o. Esto
es, la secuenci a de act i vi dades (t ambi n se pueden utilizar l os t r mi nos f unci ones u
oper aci ones) que descri be el pr ocesami ent o dent r o de un cont ext o l i mi t ado se defi -
ne c omo par t e del model o de anl isis. Como la mayor a de los el ement os del mode
lo de anl i si s (y ot r os model os de la i ngeni er a de soft ware) , l as act i vi dades (funcio
TM
PDF Editor
nes) s e p u e d e n r epr es ent ar en mu c h o s gr a dos di f er ent es de abs t r acci n. Los mo d e -
l os en est a cat egor a pue de n def i ni r se de ma ne r a i t erat i va. Cada i t eraci n pr opor -
ci ona det al l es adi ci onal es del pr oces ami ent o. Como un ej empl o, en la figura 7.4 s e
pr es ent a un di agr ama de act i vi dad e n UML par a la obt enci n de requi si t os. 14 Se
mue s t r a n t r es ni vel es de el abor aci n.
Diagramas
de actividad
para l a
obtencin de
documentos.
Priorizacin formal?
No
( Compl et ar j
la plantilla J
i
X
u| ar di.
del caso
Definir
act ores
Escribir
el escenari o
Cr ear casos
de uso
I
)
Di a g r a ma d e
c l a s e p a r a el
Sensor .
Sensor
nombr e/ i d
tipo
ubicacin
r ea
caractersticos
identificar! ]
act i var!)
desact i vor j )
reconf gurar()
14 El diagrama de actividad es bastante parecido al diagrama de flujo: un diagrama grfico para repre-
sentar las secuencias y lgica del flujo de control (captulo 11).
TM
PDF Editor
181
d e a i s l a r
e s b u s c a r
d e s a i p -
e s a i t o d e
x u s o . A l
s d e
r e c a p i t u l o
e n c o n t r a r
e s t e t e m a .
CLAVE
es uno
de manera
los estmulos
ocosionon los
entre los
El e me n t o s b a s a d o s e n c l a s e s . Cada es cenar i o de us o i mpl i ca un conj unt o de
"obj et os" que s e mani pul a mi ent r as un act or i nt er act a con el si st ema. Est os obj et os
s e cl asi fi can en cl ases: una col ecci n de cl as es con at r i but os si mi l ar es y compor t a-
mi ent os en c omn. Por ej empl o, s e pue de us a r un di agr ama de cl as e par a mos t r ar
una cl as e de S e n s o r par a la f unci n de segur i dad de HogarSeguro (figura 7.5).
Obs r ves e que el di agr ama lista l os at r i but os de l os s e ns or e s (por ej empl o, nombre/d,
tipo) y l as oper aci ones [por ej empl o, identificar( ), habilitar()\ que pue d e n apl i car se
pa r a modi f i car di chos at r i but os. Ade m s de l os di a gr a ma s de cl ase, ot r os e l e me nt os
del mode l a do del anl i si s mue s t r a n la f or ma en que l as cl as es col abor an con uno y
ot r o y l as r el aci ones e i nt er acci ones ent r e l as cl ases. Lo ant er i or s e e xa mi na con
mayor det al l e en el cap t ul o 8.
El e me nt o s de c o mpo r t a mi e nt o . El c ompor t a mi e nt o de un si st ema ba s a d o en
c omput a dor a pue d e t ener un pr of undo ef ect o s obr e el di s eo que s e elija, as c o mo
e n el enf oque de i mpl ement aci n que s e apl i que. Por l o t ant o, el model o de anl i si s
debe pr opor ci onar el ement os de mode l a do que mue s t r e n el compor t ami ent o.
El di a gr a ma de e s t a do (cap t ul o 8) es un m t od o par a r epr es ent ar el compor t a-
mi ent o de un s i s t ema al mos t r ar s us e s t a dos y l os e ve nt os que ocas i onan que di cho
s i s t ema cambi e de es t ado. Un e s t a do es cual qui er f or ma de c ompor t a mi e nt o obser -
vabl e. Adems , el di agr ama de e s t a do i ndi ca l as acci ones (por ej empl o, la act i vaci n
del pr oceso) que s e t oman c o mo cons ecuenci a de un e ve nt o part i cul ar.
Par a ilustrar un diagrama de es t ado, cons i dr es e el e s t a do de l ect ur a de c o ma n -
dos de una f ot ocopi ador a de ofi ci na. En la figura 7. 6 s e pr es ent a el di a gr a ma de es t a
do cor r es pondi ent e e n UML. Un r ect ngul o r e d ond e a d o r epr es ent a un es t ado. El r ec-
t ngul o s e di vi de en t r es r eas : 1) el nombr e del e s t a do (por ej empl o, Lect ura de
comandos ) , 2) l as variables de estado que i ndi can la ma ne r a en que el es t ado s e
5 en
pai ae l
de
Lectura
de comandos
Estatus del sistema = "Listo" ^
Mensaj e des pl egado =
"introducir cmd"
Display status - st eady
Estatus despl egado - est abl e.
Ent rada/ subsi st emas listo
Accin: pedir la ent r ada del
usuario en el panel
Acci n: leer la ent r ada del
\
Acci n: interpretar la ent r ada
del usuario
Nombr e del est ado
"Variables de est ado
Actividades de est ado
TM
PDF Editor
HOGARS E GURO
Modelado preliminar del comportamiento
L S J g l El e s c e n a r i o : Una salo de
reuniones. Contina lo reunin par o la recopilacin de
requisitos.
Los a c t o r e s : j ami e Lazar, miembro del equi po de
software; Vinod Raman, miembro del equi po de
software; d Robbins, miembro del equi po de software;
Doug Mier, miembro del equi po de software; tres
miembros de mercadot ecnia; un representante de
ingeniera del producto; y un moderador.
La c o n v e r s a c i n :
Mo d e r a d o r : Estamos a punto de terminar de habl ar
acerca de la funcionalidad de seguridad en el hogar de
HogarSeguro. Pero antes de hacerlo, me gustara discutir
el comportamiento de la funcin.
P e r s o n a d e me r c a d o t e c n i a : Yo no ent iendo lo que
quieres decir con comportamiento.
Ed ( r i e n d o ) : Es cuando le das al producto un "tiempo
fuero" si se comporta mal.
Mo d e r a d o r : No exactamente. Djenme explicarles. (El
moderador les explica al equipo de recopilacin de
requisitos los conceptos bsicos del model ado del
comportamiento.)
P e r s o n a d e me r c a d o t e c n i a : Esto parece un poco
tcnico, no s si yo pueda ayudar en esta part e.
Mo d e r a d o r : Seguro que puedes. Cul es el
comportamiento que observas desde el punto de vista de:
usuario?
P e r s o n a d e me r c a d o t e c n i a : Eh. . bueno, el sistema
estar monitoreando los sensores, estar leyendo
comandos del propietario de la casa. Desplegar su
estatus.
Mo d e r a d o r : Ves, t puedes hacerlo.
J a mi e : Tambin revisar la PC par a determinar si existe
al guna ent rada desde ah, por ejemplo: un acceso
bas ado en Internet o informacin de configuracin.
Vi n o d : S, de hecho, la configuracin del sistema es un
est ado por derecho propio.
Do u g : Me par ece que van muy rpi do. Vamos a
pensarl o un poco ms. . . Existe al guna forma de hacer
un di agr ama de esto?
Mo d e r a d o r : S existe, pero vamos a posponerlo para
despus de la reunin.
mani fi est a a s mi s mo en el mundo exterior, y 3) l as actividades de estado que ind;-l
can la f or ma en que se i ngresa al est ado (entrada/) y las acci ones (do:) i nvocadas!
mi ent r as se per manece en el mi smo.
El e me nt os or i e nt ados al flujo. Cuando la i nformaci n fluye a t ravs de un sis-l
t ema basado en comput ador a, st a se t r ansf or ma. El si st ema acept a la ent r ada eal
una vari edad de f or mas, apl ica f unci ones par a t ransformarl a y pr oduce una sal i c l
t ambi n en f or mas di ferent es. La ent r ada puede ser una seal de cont rol que t ran -l
mi t e un t ransduct or, una serie de nmer os que t ecl ea un oper ador humano, u - |
paquet e de i nformaci n t ransmi t i do a t ravs de una liga de red, o un vol umi nos-J
archi vo de dat os obt eni do de un al macenami ent o secundari o. La t ransformaci -. l
puede incluir una sola compar aci n lgica, un al gori t mo numr i co compl ej o o un
enf oque de i nt erferenci a de regl as per t eneci ent e a un si st ema expert o. La salical
puede encender una sola luz de LED o produci r un report e de 200 pgi nas. En efec-l
to, e s posi bl e cr ear un model o de fl uj o par a cual qui er si st ema ba s a do en compu-l
t adora, si n i mport ar su t a ma o o compl ej i dad. En el capt ul o 8 se pr esent a una expc-l
sicin m s det al l ada del model ado del flujo.
TM
PDF Editor
CAPI TULO 7 INGENIERA DE REQUISITOS
183
7.6.2 Patrones de anlisis
/
se puede
i t f y
s recursos
i s potrones.
A Existe algu-
i plantilla
i para
patro-
Cual qui er a que l l eve a c a bo i ngeni er a de r equi si t os en m s de u n o s c ua nt os pr o-
yect os de s of t war e comi enza a dar s e cuent a que ci er t as c os a s s uc e de n de ma ne r a
r ecur r ent e en t odos l os pr oyect os dent r o de un domi ni o de apl i caci n espec f i co. 1 5
st os pue de n de nomi na r s e patrones de anlisis [FOW97] y r epr es ent an al go (por
ej empl o, una cl ase, una f unci n o un compor t ami ent o) dent r o del domi ni o de apl i -
caci n que pue de r eut i l i zar se al model ar mu c h a s apl i caci ones.
Geyer-Shul t z y Hahsl er |GEY01] sugi er en dos benef i ci os que pue d e n as oci ar s e
con el us o de pa t r one s de anl i si s:
Primero, los patrones de anlisis aceleran el desarrollo de modelos de anlisis abstractos
que capturan los requisitos principales del problema concreto al proporcionar modelos
reutilizables del anlisis, los cuales incluyen ejemplos, asi como una descripcin de las
ventajas y limitaciones. Segundo, los patrones de anlisis facilitan la transformacin del
modelo de anlisis en un modelo de diseo al sugerir patrones de diseo y soluciones con-
fiables para problemas comunes.
Los pat r ones de anl i si s se i nt egr an al mode l o r espect i vo medi ant e una r ef er en-
cia al nombr e del pat r n. st os t ambi n s e encuent r an a l ma c e na d os en un deps i t o
par a que l os i ngeni er os de r equi si t os pue d a n ut i l i zar l os servi ci os de bs queda y as
encont r ar l os y reut i l i zarl os.
La i nf or maci n acer ca de un pat r n de anl i si s s e pr es ent a en una pl ant i l l a e s t n-
dar que t i ene la si gui ent e forma[GEY01]: 16
Nombre del patrn: un descriptor que captura la esencia del patrn. El descriptor se
utiliza dentro del modelo de anlisis cuando se hace alguna referencia al patrn
Intencin: describe aquello que el patrn pretende lograr o representar o el problema
que ataca dentro del contexto de un dominio de aplicacin
Motivacin: un escenario que ilustra la forma en que el patrn se puede utilizar para
atacar el problema.
Fuerzas y contexto: una descripcin de los aspectos externos (fuerzas externas) ca-
paces de afectar la manera en que se utiliza el patrn, asi como de los asuntos externos
que sern resueltos cuando se aplique el patrn. Los aspectos externos pueden incluir
cuestiones relacionadas con los negocios, restricciones tcnicas externas, y asuntos rela-
cionados con las personas
Solucin: una descripcin de la forma en que se aplica el patrn para resolver el pro-
blema, poniendo especial atencin en los aspectos estructurales y de comportamiento.
Consecuenci as: se enfoca en lo que sucede cuando se aplica el patrn y en los cam-
bios que se producen durante su aplicacin.
15 En algunas situaciones las cosas se repiten sin importar el dominio de aplicacin. Por ejemplo, las
caractersticas y funciones de las interfases del usuario son comunes, independientemente del do-
minio de aplicacin que se considere.
16 En la bibliografa se ha propuesto una variedad de plantillas de patrn. Los lectores interesados pue
den consultar [FOW97], IBUS96) y (GAM95), entre muchas otras fuentes.
lili
TM
PDF Editor
Diseo: examina la manera en que el patrn de anlisis se puede lograr por medio de
patrones de diseo conocidos.
Usos conoci dos: ejemplos de usos en sistemas reales.
Patrones relacionados: uno o ms patrones de anlisis que estn relacionados con
el patrn en cuestin, porque el patrn de anlisis 1) por lo general se utiliza junto con el
patrn en estudio, 2) es similar en el sentido estructural a dicho patrn, 3) es una varia-
cin del mismo.
En el cap t ul o 8 s e pr e s e nt a n ej empl os de pa t r one s de anl i si s, as c o mo ot r os an-
lisis de es t e t pi co.
I NF ORMACI N
Patrones
Los pat rones se pueden ver en casi cualquier
actividad de la vida diaria.
Considrense las pelculas de accin y aventuras - d e
manera ms especfica las pelculas policiacas de accin y
aventuras con matices de comedi a- . Se pueden definir
patrones par a el HroeyCompaero, CapilnJefedelHroe,
CriminalconCorazn y muchos ms.
Por ejemplo, el CapitrJefedelHroe de manera invariable
es ms viejo, usa corbata (el hroe no), les grita en forma
constante al HroeyCompaero, usualmente es quien da el
perfil cmico, o puede usarse en un papel ms malvolo para
poner trabas burocrticas o intereses personales en el camino
del HroeyCompaero. Se ha establecido un patrn
dramtico.
Para un ejemplo algo ms tcnico considrese un
telfono celular. Los siguientes pat rones son obvios: Llamar,
BuscorNmero, VerMensajes entre muchos otros. Cada
uno de estos patrones puede describirse una vez y despus
reutilizarse en el software par a cualquier telfono celular.
En un cont ext o i deal de la i ngeni er a de r equi si t os, l as t ar eas de inicio, obt enci n y
el abor aci n det er mi nan l os r equi si t os con el suf i ci ent e det al l e c o mo pa r a empr en-
der los pa s os s ubs e c ue nt e s de la i ngeni er a del s of t war e. Des gr aci adament e, est o
s ucede muy r ar a vez. En r eal i dad, el cl i ent e y el desar r ol l ador ent r an en un pr oces o
de negociacin, en el cual se le debe pedi r al cl i ent e un bal ance de la f unci onal i dad,
el r endi mi ent o y ot r as car act er st i cas del s i s t ema o pr oduct o f r ent e al cos t o y el t i em-
po de col ocaci n en el mer cado. El obj et i vo de es t a negoci aci n es desar r ol l ar un
pl an de pr oyect o que sat i sf aga l as ne c e s i da de s del cl i ent e al mi s mo t i empo que refle-
ja l as r est r i cci ones del mu n d o real (por ej empl o, t i empo, gent e, pr es upues t o) a las
que est s omet i do el equi po de s of t war e.
"Un ocuerdo es d orte de dividir un postel de tal formo que codo uno piense que se qued con la rebanada ms grande."
Ludwig Erhard
Las mej or es negoci aci ones s on aquel l as que bus c a n un r esul t ado del t i po "ganar -
ganar". 1 7 Est o es, el cl i ent e ga na al obt ener el s i s t ema o pr oduct o que sat i sf ace la
17 Se han escrito docenas de libros sobre las aptitudes para la negociacin (por ejemplo, [LEWOO], [FAR97],
(DON96)) sta es una de las competencias ms importantes que un ingeniero o gerente de software jo-
ven (o no tan joveni puede aprender. Se recomienda leer al menos uno de los libros mencionados.
TM
PDF Editor
CAPITULO 7 INGENIERA DE REQUISITOS
185
puede
mayor a de sus necesi dades, y el equi po de sof t war e gana al t rabaj ar con presu-
puest os y lmites de t i empo real i st as y al canzabl es.
Bohem [BOE98] defi ne un conj unt o de act i vi dades de negoci aci n en el inicio de
cada it eracin del pr oceso del sof t war e. En lugar de la actividad sencilla de comuni
caci n con el cliente, se defi nen las si gui ent es act i vi dades:
1. Ident ificacin de l os i nt er esados cl ave en el si st ema o subsi st ema.
2. Det ermi naci n de las "condi ci ones ganador as" de los i nt eresados.
3. Negoci aci n de las condi ci ones ganador as de los i nt er esados par a reconcil iar-
las en conj unt o de condi ci ones del tipo ganar - ganar par a t odos l os i nvol ucra-
dos (incluido el equi po de soft ware) .
La concl usi n exi t osa de est os pas os iniciales asegur a un resul t ado del tipo ganar -
ganar , el cual se convi ert e en el criterio cl ave par a cont i nuar con las act i vi dades sub-
s ecuent es de la i ngeni er a del sof t war e.
I NF ORMACI N
El arte de Ja negociacin
El aprendi zaj e del art e de la negociacin
efectiva es una actividad que sirve a travs de
tcnica y personal. La consideracin de las
: directrices puede resultar muy valiosa:
econocer que no es uno competencia. Para ser
exitoso, ambos lados deben tener el sentimiento de
naber ga na do o l ogrado algo. Las dos partes
endrn que llegar a un acuerdo.
Disear una estrategia. Decidir que es lo que se
deseara lograr; qu es lo que la otra part e quiere
al canzar, y qu es lo que se va a hacer par a que
ambas cosas sucedan.
Escuchar de manera activa. No se debe pensar en
formular una respuesta mientras la otra part e est
habl ando. Es necesario escuchar. Es posible que se
obt enga un conocimiento que ayudar a negoci ar de
mejor manera la posicin propi a.
4. Enfocarse en los intereses de la otra parte. Si se
quieren evitar los conflictos no se debe tomar una
pos i c i n i nf l exi bl e.
5. No dejar que se vuelva personal. Enfocarse en el
problema que debe ser resuello.
6. Ser creativo. Cuando existen situaciones de
estancamiento no se debe tener miedo de pensar
fuera de los cnones.
7. Estar listo para pactar. Una vez que se ha llegado a
un acuerdo, no es necesario esperar: se debe pact ar
dicho convenio y seguir adelanto.
HOGARS EGURO
El inicio de una negociacin
El e s c e n a r i o : Oficina de Lisa
, despus de la primera reunin par a la
i de requisitos.
- os a c t o r e s : Doug Miller, gerente de ingeniera de
aftware y Lisa Prez, gerente de mercadot ecnia.
Le c o n v e r s a c i n :
Li sa: Bien, escuch que en la primera reunin no les fue
ouy bien.
Doug: En real idad s. Enviaste algunos buenos
elementos a la reunin. . . contribuyeron bastante.
Lisa ( s onr i e ndo) : S dar o, ellos me dijeron que llegaron
y que no fue una actividad muy tranquila que digamos.
Do u g ( ri endo) : Me asegurar de quitarme la gorra de
tcnico la prxima vez que fe visite... Mira, Lisa, yo creo
que podemos tener un probl ema en terminar t odas fas
funcionalidades par a la funcin de seguridad en e hogar
TM
PDF Editor
par o las fechas de las que est habl ando tu gerencia. Es
muy pront< yo lo s, pero ya he est ado haci endo un
pequeo respaldo de la pl aneacin y. . .
Lisa: Debemos tenerlo paro esa fecha, Doug. De cul
funcionalidad ests habl ando?
Do ug : Me par ece que podemos sacar toda la funcin
de seguridad en el hogar par a la fecha lmite, pero
tendremos que retrasar el acceso por Internet hasta la
segunda ent rega.
l i s a : Doug, el acceso por Internet es lo que da a
HogarSeguro la cal idad de "novedoso". Vamos a
construir t oda nuestra campaa de mercadotecnia
al rededor de esto. Debemos tenerlo!
Do ug : Entiendo tu situacin, de verdad. El problema es
que par a dart e acceso a Internet necesitaremos tener un
sitio Web completamente seguro, ya construido y en
funcionamiento. Para eso se necesita tiempo y gente.
Tambin tendremos que construir funcionalidades
adicionales en la primera ent rega. . . no creo que lo
podamos hacer con los recursos que tenemos ahor a.
Lisa (frunciendo el ceo): Ya veo, pero debes
encontrar una forma de hacerlo. Es crucial par a las
funciones de seguridad en el hogar y par a las otras
funciones t ambi n. . . las otras funciones pueden esperar
hasta las siguientes entregas, est ar de acuerdo con
eso.
Lisa y Doug parecen estar en un callejn sin salida, y
an as deben negoci ar una solucin a este problema. Er
esta situacin, pueden "ganar" los dos? En el papel de
un mediador, cul sera una sugerencia apr opi ada?
7 . 8 V A L I D A C I N D E R E Q U I S I T O S
Al crear cada el ement o del model o de anlisis, st e se exami na par a conocer su c ? nl
si st enci a, sus omi si ones y ambi gedades. A los requi si t os que r epr esent a el mo d e J
el cl ient e l es da j erarqu a y se agr upan en paquet es de requi si t os que se i mpl emer J
t an c omo i ncr ement os de sof t war e y se le ent r egan. Una revisin del model o de a n a l
lisis se enf oca en las si gui ent es pr egunt as:
i se Q Cuando i
revisan los
requisitos, cules
preguntas deben
hacerse?
Cada requi si t o es consi st ent e con el obj et i vo general del s i s t ema/ pr oduct o'
Todos los requi si t os han si do especi fi cados con el gr ado apr opi ado de
abst racci n? Est o es, al gunos requi si t os pr opor ci onan un gr ado de det al l e
t cni co que sea i napropi ado en est a et apa?
El requi si t o es necesar i o en real i dad o r epr esent a una caract er st i ca
agr egada i rrel evant e par a el objet ivo del si st ema?
Cada requi si t o est l imit ado y no es ambi guo?
Cada requisito t i ene una at ri buci n? Esto es, existe una f uent e (por lo
general , especfica, individual) det er mi nada par a cada requisito?
Al gunos requi si t os ent r an en confl ict o con ot ros?
Cada requi si t o es al canzabl e en el ambi ent e t cni co que recibir al sist ema i
product o?
Cada requi si t o se puede pr obar una vez que st e haya si do i mpl ement ado'
El model o de requi si t os refl eja de maner a apr opi ada la i nformaci n, la
funci n y el compor t ami ent o del si st ema que ser const rui do?
El model o de requi si t os se ha somet i do a "particin" par a que exponga en
f or ma progresi va i nf or maci n m s det al l ada acer ca del si st ema?
TM
PDF Editor
187
Se han usado pat r ones de requi si t os para simpl ificar el model o de requisit os?
Todos l os pat r ones se han val i dado de maner a apr opi ada? Todos los
pat r ones son consi st ent es con los requi si t os del cliente?
st as y ot r as pr egunt as deben real i zarse y cont est ar se par a asegur ar que el model o
de requi si t os es un reflejo exact o de las necesi dades del cliente y que proporci ona
una base slida para el di seo.
Ant es de que el di seo y la const rucci n de un si st ema basado en comput ador a pue-
dan comenzar , es necesar i o ent ender los requisit os. Esto se logra r eal i zando una
seri e de t ar eas de i ngeni er a de requisit os, la cual se lleva a cabo dur ant e l as activi-
dades de comuni caci n con el cl ient e y model ado que han si do defi ni das para el pr o-
ceso genr i co del sof t war e. Los mi embr os del equi po de sof t war e real i zan si et e fun-
ci ones di st i nt as dent r o de la i ngeni er a de requisit os: inicio, obt enci n, el aboraci n,
negoci aci n, especi fi caci n, val i daci n y gest i n.
Al inicio del proyect o el desarrol l ador y el cl i ent e (as como ot r os i nt eresados)
est abl ecen los requi si t os bsi cos del pr obl ema, defi nen l as rest ri cci ones predomi -
nant es del proyect o y especi fi can las caract er st i cas y f unci ones m s i mpor t ant es
que deben est ar pr esent es en el si st ema par a que st e al cance sus objet ivos. Esta
i nformaci n es expandi da y refi nada dur ant e la obt enci n, una actividad para la
recopil acin de requi si t os que empl ea r euni ones que encabeza un moder ador facili
t adas, el QFD y el desarrol l o de escenar i os de uso.
La el aboraci n post eri or expande los requi si t os haci a un model o de anlisis; es
decir, una col eccin de el ement os del model o bas ados en escenar i os, en act i vi dades
y en cl ases, de compor t ami ent o y or i ent ados al flujo. En la creaci n de est os ele-
ment os s e puede utilizar una vari edad de not aci ones de model ado. El model o puede
referi rse a pat r ones de anl i si s, caract er st i cas del domi ni o del probl ema que son
r ecur r ent es a t ravs de di ferent es apl i caci ones.
Cuando se ident ifican los requi si t os y se crea el model o de anlisis, el equi po de
sof t war e, el cl ient e y ot r os i nt er esados en ei proyect o negoci an la prioridad, di spo-
nibilidad y cost o rel at ivo de cada requisito. El obj et i vo de est a negoci aci n es desa
rrollar un plan de proyect o real ist a. Adems, cada requi si t o y el model o de anl i si s
como un t odo se val i dan cont r ast ndol os con l as necesi dades del cl ient e para ase-
gurar que se const rui r el si st ema correct o.
S;::
[BOE98J Boehm, B. y A. Egyed, "Software Requircments Negotiation: Somc Lcssons Lcarned",
en Proc. Intl. Con/. Software Engineerng. ACM/IEEE, 1998, pp. 503-506.
[BOS91]Bossert, J. L., Quality Function Deployment: A Practitioner's Approach, ASQC Press, 1991.
[BUS96] Buschmann. F. et al., Pattem-Oriented Software Architecture: A System Paltcrn, Wiley,
1996.
TM
PDF Editor
iinirn
1 8 8 P A U T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
[COCOl] Cockburn, A., Wrting Effective Use-Cases, Addison-Wesley, 2001.
[CRI92] Christel, M. G. y K. C. Kang, "Issues in Requirements Elicitation", en Software Engineering |
institute. CMU/SEI-92-TR-12 7, septiembre de 1992.
[DON96] Donaldson, M. C. y M. Donaldson, Negotiating for Dummies, IDG Books Worldwide
1996.
[FAR97] Farber, D. C., Common Sense Negociation. The Art of Winning Gracefully, Bay Press, 1997
[FOW97] Fowler, M Analysis Pallems: Reusable Object Models, Addison-Wesley, 1977.
[GAM95] Gamma, E. et al, Design Pattems: Elemente of Reusable Object-Oriented Software
Addison-Wesley, 1995.
[GAU89] Gause, D. C. y G. M. Weinberg, Exploring Requirements: Quality Befte Design, Dorsei
House, 1989.
[GEY01] Geyer-Schultz, A. y M, Hahsler, Software Engineering with Analysis Pattems, Technica I
Report 01/2001, Institu fr lnformationsverarbeitung und-wirtschaft, Wirschaftsuniversi
Wien, noviembre de 2001, obtenido de http://wwwai.wu-wien.ac.at/~hahsler/research/vir-
Iib_working2001 /virlib/.
(JAC92J Jacobson, I., Objetc-Oriented Software Engineering, Addison-Wesley, 1992.
|LEW00j Lewicki, R., D. Saunders y J. Minton, Essentials ofNegotiation, McGraw-Hill, 2002.
[PAR96] Pardee, W To Satisjy and Delight Your Costumer, Dorset House, 1996.
ISOM97] Somerville, 1. y P. Sawyer, Requirements Engineering, Wiley, 1997.
[THA97] Thayer, R. H. y M Dorftnan, Software Requirements Engineering, 2a. ed., IEEE Computer
Society Press, 1997.
[YOUOl] Young, R., Effective Requirements Practices, Addison-Wesley, 2001.
[ZAH90] Zahniser, R. A., "Buiiding Software in Groups", en American Programmer, vol.3. nms. 7-
8, julio-agosto de 1990.
[ZUL92] Zultner, R., "Quality Function Deployment for Software: Satisfying Costumers", e n |
American Programmer, febrero de 1992, pp. 28-41.
7.1. Por qu varios desabolladores de software no prestan mucha atencin a la ingeniera de ]
requisitos? Se llegan a dar circunstancias en las que se puede omitir?
7. 2. Qu implica el "anlisis de factibilidad" cuando se examina dentro del contexto de la fun- ]
cin inicio?
7. 3. A usted se le ha dado la responsabilidad de obtener requisitos de un cliente que dice es
demasiado ocupado para reunirse con usted. Qu debe hacer?
7.4. Exponer algunos de los problemas que pueden surgir cuando los requisitos deben obte- ]
nerse de tres o cuatro clientes diferentes.
7.5. Por qu se dice que el modelo de anlisis representa una foto instantnea de un sisten
en el tiempo?
7.6. Suponga que ha convencido al cliente (usted es un excelente vendedor) de cada demanc
que ha hecho como desarrollador. Eso lo convierte en un negociador experto? Por qu?
7. 7. Desarrollar al menos tres "preguntas de contexto libre" adicionales que pueda hacerle i ]
algn interesado durante la fase de inicio.
7.8. A travs de este captulo se ha hecho referencia al "cliente". Describa al "cliente" para tas 1
desarrolladores de sistemas de informacin, para constructores de productos basados en compu- I
tadora, para constructores de sistemas. Debe tenerse precaucin: pueden existir ms clientes (
este problema de lo que se imagina.
7.9. Desarrolle un "paquete" que facilite la recopilacin de requisitos. El equipo debe incluir ur I
conjunto de directrices para realizar una reunin de recopilacin de requisitos y una serie de I
materiales que puedan utilizarse para facilitar la creacin de listas y otros dispositivos que pue-
dan ayudar en la definicin de requisitos.
TM
PDF Editor
189
7. 10. El profesor har grupos de cuatro o cinco estudiantes. La mitad del grupo representar el
papel del departamento de mercadotecnia, y la otra mitad, el de ingeniera del software. Lo que
se pretender es definir los requisitos para la funcin de seguridad de HogarSeguro, descrita en
este capitulo. Realizar una reunin de recopilacin de requisitos mientras se utilizan las direc-
trices presentadas en este capitulo.
7. 11. Desarrolle un caso de uso para una de las siguientes actividades:
a) Hacer un retiro en cajero automtico.
b) Utilizar su tarjeta de crdito para una comida en un restaurante.
c) Comprar la despensa con una cuenta de cobro en lnea.
d) Buscar libros (sobre un tema especfico) a travs de una librera en lnea.
e) Una actividad que defina su instructor.
7. 12. Qu representan las "excepciones" en los casos de uso?
7. 13. Explicar con brevedad cada uno de los elementos de un modelo de anlisis. Indicar con
qu contribuye cada elemento al modelo, cmo es que cada modelo es nico y qu informacin
general presenta cada modelo.
7. 14. Describir con argumentos propios un patrn de anlisis.
7. 15. Con la plantilla presentada en la seccin 7.6.2, sugerir uno o ms patrones para una apli-
cacin que aplique el instructor.
7. 16. Qu significa "ganar-ganar" en el contexto de la negociacin durante la actividad de
ingeniera de requisitos?
7. 17. Qu se cree que suceda cuando la validacin de requisitos descubre un error? Quin es
el indicado para corregir el error?
Debido a que es primordial para la creacin exitosa de cualquier sistema complejo basado en
computadora, la ingeniera de requisitos se expone en una gran cantidad de libros. Hull y sus
colegas (Requirements Engineerng, Springer-Verlag, 2002), Bray (An Introduccin to Requirements
Engineerng, Addison Wesley, 2002), Arlow (Requirements Engineerng, Addison-Wesey, 2001),
Gilb (Requirements Engineerng, Addison-Wesley, 2000), G r a h a m {Requircments Engineerng aricl
Rapid Development, Addison-Wesley, 1999) y Sommerville y Kotonya (Requirements Engineerng
Proceses and Techniques, Wiley. 1998) son slo algunos libros dedicados a este tema. Dan Bcrry
(http://se.uwaterloo.ca/~dbeny/bib.html) ha publicado una amplia variedad de escritos acerca
de tpicos relacionados con la ingeniera de requisitos.
Lauesen (Software Requirements: Styles and Techniques, Addison-Wesley, 2002) presenta una
amplia muestra de notaciones y mtodos para el anlisis de requisitos. Weigers (Software
Requirements, Microsoft Press, 1999) y Leffingwell y sus colegas (Managing Software Requirements:
A Unifted Approach, Addison-Wesley, 2000) presentan una coleccin til de las mejores prcti-
cas de requisitos y sugieren guias pragmticas para casi todos los aspectos del proceso de la
ingeniera de requisitos.
Robertson y Robertson (Masterng the Requirements Process, Addison Wesley, 1999) presen-
tan un estudio de caso muy detallado que ayuda a explicar todos los aspectos del anlisis de
requisitos y el modelo de anlisis de software. Kovitz (Practica! Software Requirements: A Manual
of Conten and Style, Manning Publications, 1998) explica paso a paso un enfoque para el anli-
sis de requisitos y una gua de estilo para aquellos que deben desarrollar especificaciones de
requisitos. Jackson (Software Requirements Analysis and Speciftcation: A Lexicn of Pracces,
Principies and Prejudices, Addison-Wesley, 1995) presenta una visin sugerente del tema de la A
a la Z (de manera literal). Ploesch (Asseraons, Scenaros and Prototypes, Springer-Verlag, 2003)
explica tcnicas avanzadas para desanollar requisitos de software.
TM
PDF Editor
Windle y Abreo (Software Requirements Using the Unifted Process, Prentice-Hall, 2002) expo-
nen la ingeniera de requisitos dentro del contexto del proceso unificado y la notacin del UML
Alexander y Steven (Writing Better Requirements, Addison-Wesley, 2002) presentan un breve
conjunto de directrices para escribir requisitos claros, representarlos como escenarios y revisar
el resultado final.
El modelado de casos de uso es a menudo el conductor de la creacin de todos los dems
aspectos del modelo de anlisis. Bittner y Spence (Use-Case Modeling, Addison-Wesley, 2002)
examinan el tema de manera amplia, as como Cockbum [COCOl), Armour y Miller (Advanced
Use-Case Modeling: Software Systems, Addison-Wesley, 2000), Kulak y sus colegas (Use Cases:
Requirements in Context, Addison-Wesley, 2000), y Schneider y Winters (Applying Use Cases,
Addison-Wesley, 1998).
En Internet se puede disponer de una amplia variedad de fuentes de informacin sobre an-
lisis e ingeniera de requisitos. En el sitio web de SEPA, ht t p: / / www. mhhe. com/ pressman,
se puede encontrar una lista actualizada de referencias en la red mundial que son relevantes
para el anlisis y la ingeniera de requisitos.
TM
PDF Editor
C AP I T UL O
MODELADO
DEL ANLI SI S
8
C E P T O S
VE
.194
>...196
.219
. . 211
....219
. . . 2 02
. . . .225
....197
....234
....215
.211
.198
194
E
n el mbi t o tcnico, la ingeniera de sof t war e comi enza con una serie de
t ar eas de model ado que conducen a una especificacin de requisitos y a
una represent aci n compl et a del di seo del soft ware que se const ruir. El
modelo de anlisis, que en real idad es una serie de model os, es la pri mera repre-
sent aci n tcnica de un si st ema.
En un libro sobre mt odos de model ado del anlisis, Tom DeMarco [DEM79]
describe el proceso de la siguient e maner a:
Al observar los problemas y fallas reconocidas de la fase de anlisis es necesario agre-
garle los siguientes objetivos:
Los productos del anlisis deben tener una elevada facilidad de manteni-
miento. Esto se aplica en particular ai documento final [especificacin de re-
quisitos de software].
Los problemas de gran tamao deben tratarse con un mtodo efectivo de par-
ticin. La especificacin del tipo de las novelas victorianas ya no sirve.
Deben utilizarse grficas cuando sea posible.
Se debe diferenciar entre consideraciones lgicas [esenciales] y fsicas [de im-
plementacin]...
Como mnimo se necesita...
Algo que ayude a hacer una particin de los requisitos y a documentarla antes
de la especificacin...
Algunos medios para el seguimiento y evaluacin de las interfases...
Herramientas nuevas para describir la lgica y la tctica, algo mejor que un
texto narrativo.
Aunque DeMarco escribi acerca de l os at ribut os del model ado del anl i si s hace
ms de un cuart o de siglo, sus cont ri buci ones s e si guen apl i cando en la not aci n
y l os mt odos moder nos de model ado del anlisis.
Q u e s ? La p a l a b r a es cr i t a e s un
ve h c ul o ma r a v i l l o s o p a r a l a c o mu n i -
c a c i n , p e r o n o e s , n e c e s a r i a me n t e ,
l a me j o r forma d e r e p r e s e n t a r l os
r e qui s i t os p a r a el s o f t wa r e d e c o m-
p u t a d o r a . El mo d e l a d o del a n l i s i s ut i l i za u n a
c o mb i n a c i n d e formatos e n t e xt o y d i a g r a ma s
p a r a r e p r e s e n t a r l os r e qui s i t os d e l os d a t o s , l as
Un c i o n e s y el c o mp o r t a mi e n t o d e u n a ma n e r a
q u e e s r e l a t i v a me n t e f ci l d e e n t e n d e r y, a u n m s
i mpor t a nt e , c o n d u c e a u n a r evi s i n p a r a l o g r a r l a
c o r r e c c i n , l a i n t e g r i d a d y l a c ons i s t e nc i a .
Q u i n l o h a c e ? Un i n g e n i e r o d e s o f t wa r e ( a l gu-
n a s v e c e s l l a ma d o a n a l i s t a ) c o n s t r u y e el mo d e l o
e mp l e a n d o r equi s i t os o b t e n i d o s d e l cl i ent e.
Por qu es i mport ant e? Para validar los
r equi si t os del s of t wa r e e s n e c e s a r i o e x a mi n a r l o s
d e s d e a l g u n o s p u n t o s d e vi st a di f e r e nt e s . El mo d e -
1 9 1
TM
PDF Editor
1 9 2 P A R T E D O S PRCTICA DE LA INGENIERA D a SOFTWARE
l ado del anl i si s r e pr e s e nt a los r equi si t os e n ml -
tiples " di mens i ones " , con l o q u e se i ncr ement a la
pr oba bi l i d a d d e e nc ont r a r er r or es , d e q u e sur -
j an i nconsi st enci as y d e q u e s e d e s c u b r a n omi -
si ones.
Cu l e s s o n l o s p a s o s ? Los requisitos d e infor-
maci n, f unci onal es y d e c ompor t a mi e nt o se
mode l a n me di a nt e var i os t i pos d e d i a g r a ma s . El
mo d e l a d o b a s a d o en e s c e na r i os r epr es ent a el
si st ema d e s d e el punt o d e vista del us uar i o. Ei
mo d e l a d o or i e nt a do al f l uj o i ndi ca c mo s e
t r ans f or man los obj et os d e d a t os al r eal i zar s e
l as f unci ones del pr oces ami ent o. El mo d e l a d o
b a s a d o en cl as es de f i ne obj et os , at r i but os y r el a-
ci ones. El mo d e l a d o del c ompor t a mi e nt o pr e-
sent a los e s t a dos del si st ema y sus cl ases, as
c o mo el i mpa c t o d e los event os s obr e sus est a-
dos . Un a vez q u e s e h a n c r e a d o los model o:
pr el i mi nar es , st os s e r ef i nan y a na l i z a n p a r o
eval uar su cal i dad, i nt egr i dad y consi st enci c
De s pu s , el mode l o d e anl i si s fi nal lo val i dar
i os i nt er es ados
Cul e s el product o obt eni do? Para el
mo d e l o d e anl i s i s e s pos i bl e el egi r una ampl i o
va r i e d a d d e t i pos d e d i a g r a ma s . Ca d a u n a de
es t as r e pr e s e nt a c i one s of r e c e una visin d e uno
o m s d e l os el ement os del model o.
Cmo pue do es t ar s e gur o de que lo he
h e c h o c o r r e c t a me nt e ? Los productos de
t r a b a j o del mo d e l a d o del anl i si s d e be n revi sar-
s e en l o rel at i vo a su cor r ecci n, i nt egr i dad y
consi st enci a. Est os d e b e n r ef l ej ar l as neces i da-
d e s d e t od os los i nt er es ados y es t abl ecer una
b a s e d e s d e la cual p u e d a conduci r s e el di seo.
8 . 1 A N L I S I S D E R E Q U I S I T O S
CLAVE
El modelo de anlisis y
lo especificacin de
requisitos proporciona
un medio para evaluar
la calidad uno vez que
el software est
construido.
El anlisis de requisitos genera la especificacin de caract er st i cas operaci onal es d J
soft ware; indica la i nt erfaz del sof t war e con ot ros el ement os del si st ema, y est abl e-'
ce l as rest ricciones que debe t ener el soft ware. El anlisis de requisitos permi t e que
el i ngeni ero de sof t war e (a veces l l amado en est e cont ext o analista o modelador) sd
ext i enda sobre requeri mi ent os bsi cos est abl ecidos dur ant e t areas ant eri ores a
ingeniera de requi si t os y const ruya model os que represent en escenari os del usua-l
rio, act ividades funcional es, cl ases de probl emas y s us rel aciones, el comport ami en-
to de las cl ases y el si st ema y, a medi da que se t ransforma, el flujo de dat os.
El anlisis de requisitos le proporci ona al di seador de sof t war e una represent a-
cin de informacin, funci n y compor t ami ent o que puede t rasl adar a di seos arqui-
tectnicos, de i nt erfaz y en el nivel de component es. Por ltimo, el model o de an-
lisis y la especificacin de requisitos ofrecen al desarrol l ador y al cliente los medios
para eval uar la calidad una vez const rui do el soft ware.
Por medi o del model ado del anlisis el ingeniero de sof t war e se cent ra primerc
en el qu, no en el cmo. Qu obj et os mani pul a el sist ema, qu funci ones debe
desempear el si st ema, qu compor t ami ent os muest ra el si st ema, qu interfaces se
defi nen y qu restricciones se aplican?1
En capt ul os ant eri ores se est abl eci que en est a et apa tal vez no fuera posible
real izar una especificacin compl et a de requisitos. Quiz el desarrol l ador no est
1 Es necesari o menci onar que conforme los cl ient es se vuel ven ms refi nados en el sent i do tecnol-
gico existe una t endenci a haci a la especificacin t ant o del cmo como del qu. Sin embar go, el en-
foque primario debe per manecer en el qu.
TM
PDF Editor
CAPI TULO 8 MODELADO DEL ANUSIS 193
de
Y
de
segur o de qu enf oque especfico real i zar la funcin y si se desempear de mane-
ra apropi ada. Est as real i dades favorecen un enfoque iterativo para el anlisis y el
model ado de requisitos. El anal i st a debe model ar lo que se conoce y utilizar ese
model o como base para di sear un i ncrement o de soft ware. 2
8.1.1 Filosofa y objetivos generales
El model o de anlisis debe cumplir t res objetivos primarios: 1) describir lo que
requi ere el cliente, 2) est abl ecer una base para la creacin de un di seo de soft wa-
re, y 3) definir un conj unt o de requisitos que puedan val idarse una vez const rui do el
soft ware. El model o de anlisis llena el vaco ent re una descripcin al nivel de siste-
ma (captulo 6) que detalla la funci onal i dad general del si st ema, la cual se logra al
aplicar soft ware, hardware, dat os, humanos y ot ros el ement os del si st ema y del
di seo de sof t war e (captulo 9) que det al l an la arqui t ect ura de aplicacin del soft-
war e, la i nt erfaz con el usuari o y la est ruct ura en el nivel de component es. Esta
rel acin se ilustra en la figura 8.1.
"Los probiemos dignos de otocor demuestran su volor devolviendo el golpe."
Es i mport ant e punt ual i zar que al gunos el ement os del model o de anlisis est n
pr esent es (en un grado ms alto de abstraccin) en la descripcin del si st ema, y que
esas t ar eas de ingeniera de requisitos en realidad comi enzan como part e de la inge-
niera de si st emas. Adems, t odos los el ement os del model o de anlisis son identi-
ficables de maner a directa en l as part es del model o del diseo. No si empre es posi-
ble una divisin clara de t ar eas de anlisis y di seo ent re est as dos i mport ant es act i-
vi dades del model ado. De modo invariable, como part e del anlisis se realiza algn
di seo y al gn anlisis se efect a dur ant e el diseo.
2 De manera alternativa, el equipo de software puede elegir la creacin de un prototipo (capitulo 3)
en un esfuerzo encaminado a entender mejor los requisitos para el sistema.
TM
PDF Editor
194
8.1.2 Reglas prcticas de anlisis
Arlow y Neustadt [ARL02] sugi eren varias reglas prct i cas que deben segui rse para
crear el model o de anlisis:
El modelo debe centrarse en los requisitos visibles dentro del problema o dominio
de negocio. El grado de abstraccin debe ser alto de forma relativa. "No se debe
perder t i empo en detalles" [ARL02] que t rat an de explicar cmo funci onar el
si st ema.
Cada elemento del modelo de anlisis debe agregarse a un acuerdo general de los
requisitos de software y proporcionar una visin interna del dominio de informa-
cin, funcin y comportamiento del sistema.
Debe retrasarse la consideracin de la infraestructura y otros modelos no funcio-
nales hasta el diseo. Por ejempl o, es posibl e que se requiera una base de
dat os, pero l as cl ases necesar i as para i mpl ement arl a, las funci ones que se
requi eren para acceder a ella y el compor t ami ent o que se exhibir cuando se
utilice debe consi derarse sl o despus de que se haya compl et ado el anlisis
de domi ni o del probl ema.
Se debe minimizar el acoplamiento de todo el sistema. Es i mport ant e repre-
sent ar l as rel aci ones ent re cl ases y funci ones. Sin embargo, si el nivel de
"int erconexin" es ext r emadament e alto se deben hacer esf uer zos para
reducirlo.
Se debe tener la seguridad de que el modelo de anlisis proporciona valor a todos
los interesados. Cada circunscripcin t iene su propi o us o del model o. Por
ej empl o, los i nt eresados rel aci onados con los negoci os deben utilizar el
model o para validar los requisitos; los di seadores, como base para el diseo;
la gent e de asegur ami ent o de la calidad, como ayuda par a pl anear pr uebas de
acept aci n.
El modelo debe mantenerse tan simple como sea posible. No se deben agregar
di agr amas adi ci onal es cuando st os no ofrezcan i nformaci n nueva. No se
deben utilizar f or mas de not aci n nuevas cuando bast a con una si mpl e lista.
8.1.3 Anlisis del dominio
Al exami nar la ingeniera de requisitos (captulo 7) se est abl eci que los pat r ones de
anlisis a menudo ocurren de nuevo en muchas apl i caci ones dent ro de un domi ni o
de negoci o especifico. Si est os pat r ones se defi nen y se clasifican por categora de
una maner a que permi t an al i ngeni ero o al anal ist a de sof t war e reconocerl os y reu-
tilizarlos, la creaci n del model o de anlisis se acel era. Un fact or de mayor impor-
t ancia es que la probabilidad de aplicar pat r ones de di seo reutilizables y compo-
nent es ej ecut abl es de sof t war e aument a en forma sust ancial . Esto ofrece t i empo al
mer cado y reduce l os cost os del desarrollo.
En www.iturls.
om/EBssh/
Software
Engineerng/
SE modS.asp
pueden encontrarse
muthos reURos tiles
pora el onfisb del
dominio.
TM
PDF Editor
CAPI TULO 8 MODELADO DEL ANLISIS
1 9 5
Entrada y salida para el anlisis del dominio.
Literatura tcnica
Aplicaciones existentes
Sondeos a los clientes
Recomendaci n expert a
Requisitos act ual es/ fut uros
Taxonom as de cl ase
^ Est ndares de reutilizacin
Model o
1 Model os funcionales de anlisis
m Lenguajes de domi ni o
del dominio
Pero, en pr i mer l ugar, c mo s e r econocen l os pat r ones de anl i si s? Qui nes l os
def i nen, l os as i gnan a una cat egor a y l os pr e pa r a n par a apl i car l os en pr oyect os s ub-
s ecuent es ? Las r es pues t as a es t as pr e gunt a s r esi den en el anlisis del dominio.
Fi resmi t h [FIR93] descr i be el anl i si s del domi ni o de la si gui ent e ma ne r a :
El anlisis del dominio de software es ia identificacin, el anlisis y la especificacin de re-
quisitos comunes de un dominio especifico de aplicacin para, de manera tpica, reutili-
zarlo en mltiples proyectos dentro de ese dominio de aplicacin... [El anlisis del
dominio orientado a objetos es] la identificacin, el anlisis y la especificacin de capaci-
dades comunes reutilizables dentro de un dominio especfico de aplicacin, en trminos
de objetos, clases, subensamblajes y marcos de trabajo.
El "domi ni o de apl i caci n espec f i co" pue de var i ar de s de aer onut i ca has t a servi ci os
bancar i os , de s de vi deoj uegos en mul t i medi a ha s t a s of t war e apl i cado en i ns t r umen-
tal mdi co. La met a del anl i si s o de domi ni o es di rect a: encont r ar o cr ear aquel l as
cl ases de anl i si s o f unci ones y car act er st i cas c o mu n e s q u e s e apl i can a mpl i a me n-
t e par a que pue da n reut i l i zarse. 3
aer del dominio.
"El gran arte del aprendizaje es entender poco a poco"
John Lock e
En ci ert a f or ma, el papel de un anal i st a de domi ni o es si mi l ar al de un maes t r o
f or j ador de he r r a mi e nt a s en un ambi ent e de ma nuf a c t ur a pes ada. El t r abaj o de est e
l t i mo es di s ear y f abr i car i ns t r ument os que pue da n s er us a dos por muc ha gent e
que real i za t r abaj os si mi l ares. El papel del anal i st a de domi ni o4 es descubr i r y defi ni r
3 Una visin complementaria del anlisis del dominio "involucra el modelado del dominio de forma
que los ingenieros de software y otros interesados puedan aprender ms de l.. no todas las clases
del dominio resultan necesariamente en el desarrollo de clases reutilizables" [LET03|.
4 No debe suponerse que si se cuenta con la colaboracin de un analista del dominio, un ingen! .>ro de
software no tiene por qu comprender el dominio de aplicacin. Todos los miembros de un equipo
de software deben tener algn conocimiento del dominio en el cual se colocar el software
TM
PDF Editor
pat r ones de anl i si s reut il izabl es, cl ases de anl i si s e i nf or maci n rel aci onada q u e
pueda usar mucha gent e en apl i caci ones pareci das.
La figura 8.2 [ARA89] ilustra ent r adas y sal i das cl ave par a el pr oceso de anlisis
de domi ni o. Las f uent es de conoci mi ent o del domi ni o se exami nan en un i nt ent o pe:
identificar obj et os que pueden ser reut i l i zados a t r avs del domi ni o.
8 . 2 E N F O & U E S D E M O D E L A D O P E . A M A M W K
Una visin del model ado del anlisis, l l amado anlisis estructurado, consi der a que los
dat os y el pr oceso que t r ansf or man los dat os s on ent i dades separ adas. Los objet os
de dat os se model an en una f or ma que defi ne sus at ri but os y rel aci ones. Los proce-
sos que mani pul an los obj et os de los dat os se model an de tal maner a que muest r an
cmo t r ansf or man los dat os, mi ent r as l os obj et os de dat os fluyen por el si st ema.
Un s egundo enf oque del model ado del anl i si s, l l amado anlisis orientado a obje-
tos, se cent r a en la definicin de cl ases y en la maner a en que st as col abor an ent re
el l as par a efect uar los requi si t os del cliente. El UML y el pr oceso uni fi cado (captulo
3) est n or i ent ados a obj et os en f or ma pr edomi nant e.
El [o]nlisis es frustrante, lleno de relociones interpersonales complejos, indefinido y difcil. En pocas palabras, es
fascinante. Una vez que ests enganchado, el viejo placer de la construccin de sistemas nunca ser suficiente para
satisfacerte."
Tom DeMarco
Aunque el model o de anl i si s pr opuest o en est e cap t ul o combi na caract er st i cas
de a mbos enf oques, es comn que los equi pos de sof t war e elijan uno y excluyan
t odas l as r epr esent aci ones del ot ro. El cuest i onami ent o no es cul es el mej or, si no
qu combi naci n de r epr esent aci ones le pr opor ci onar a los i nt er esados el mej or
model o de requisitos de soft ware y el puent e m s efect ivo para el di seo de soft ware.
El model ado del anl i si s conduce a la deri vaci n de cada uno de l os el ement os de
model ado mos t r ados en la figura 8.3. No obst ant e, el cont eni do espec fi co de cada
el ement o (por ej empl o, los di agr amas con que se const ruyen el el ement o y el mode-
lo) puede diferir de pr oyect o a proyect o. Como ya se ha punt ual i zado muchas veces
en est e libro, el equi po de sof t war e debe t rabaj ar par a mant ener l o si mpl e. Slo se
deben utilizar aquel l os el ement os que agr eguen val or al model o.
"Por qu debemos construir modelos? Por qu no construimos el sistema y yo? la respuesta es que podemos
construir modelos de tal forma que resaltemos o enfaticemos ciertas caractersticas crticas de un sistema, al mismo
tiempo que quitamos nfasis a otros aspectos del sistemo."
Ed Yourdon
TM
PDF Editor
C A P T U L O 8 MODELADO DEL ANLISIS
1 9 7
=xxlelo
Cosos de uso. texto
Cosos de uso. di ogramas
Diogromos de actividad
Diogramas de carril
i
Elementos orientados
' fojo
Diogramas de flujo de dat os
Diogramas de flujo de control
Narrativas de procesamiento
Model o de anlisis
Diagramas de clase
Paquetes de anlisis
Modelos CRC
Diagramas de col aboraci n
Di agramas de est ado
Di agramas de secuencia
8 . 3 C O N C E P T O S D E L M O D E L A D O D E D A T O S
M sobre
ddalos
K
CVVE
de datos es
nsRsenfcin de
informacin
que se
con software.
El model ado del anlisis a menudo comi enza con el modelado de datos. El i ngeni ero
o anal ist a de sof t war e defi ne t odos los obj et os de dat os que se pr ocesan dent ro del
si st ema y l as rel aci ones ent re los obj et os de dat os, adems de ot ra i nformaci n per-
t inent e para l as relaciones.
8.3.1 Objetos de datos
Un objeto de datos es una represent aci n de casi cual quier i nformaci n compuest a
que el sof t war e debe ent ender. Informacin compuesta se refiere a algo que t iene
muchas propi edades o at ri but os diferentes. Por lo t ant o, "anchura" (un valor indivi-
dual) no sera un obj et o de dat os vlido, per o las di me ns i one s (la i ncorporaci n de
altura, anchur a y profundidad) podr an definirse como un objet o.
Un obj et o de dat os puede ser una entidad externa (por ejemplo, cualquier cosa que
produzca o consuma informacin), una cosa (por ejemplo, un reporte o un despliegue),
un suceso (como una llamada telefnica) o un event o (como una alarma), un papel (por
ejemplo, un vendedor), una unidad organizacional (como un depart ament o de cont a-
dura), un lugar (como un almacn), o una estructura (como un archivo). Por ejemplo,
una persona o un aut o pueden verse como un objeto de dat os en el sent ido de que cual-
quiera de ellos puede definirse en t rmi nos de un conj unt o de atributos. La descripcin
del objeto de dat os incorpora el obj et o y t odos sus atributos.
Un obj et o de dat os encapsul a sl o dat os: no existe al guna referencia dent r o de un
obj et o de dat os a las oper aci ones act en sobre los dat os. 5 Por lo t ant o, el obj et o de
dat os puede represent arse como una tabla, tal como se muest ra en la figura 8.4. Los
encabezados de la t abl a refl ejan l os at ri but os del objet o. En est e caso, un aut o se
d e f i n e e n t r mi n o s d e mar ca, model o, nmer o de ser i e, t ipo de car r ocer a, col or y propi et a-
rio. El cont enido de la tabla represent a ej empl os especficos del objeto de datos. Por
ejemplo, un Chevy Corvette es una muest ra del objeto de dat os auto.
5 Esta distincin separa los objetos de datos y las clases u objetos definidos como parte del enfoque
orientado a objetos.
TM
PDF Editor
198 PARTE D OS PRCTICA DE LA INGENIERA DEL SOFTWARE
Representacin
tabular de
objetos de
datos.
\
CUV VE
Los atributos definen a
un objeto de datos,
describen sus
caractersticos y, en
algunos casos, hacen
referencia o otro
objeto.
Referenci a Web
"norniolizocin" es
importante para todos
oqueBos que intentnn
reolizai modelado de
datos. En www.
datamodel.org
puede encontrarse uno
introduccin til.
Nombr es
de atributos
Une los obj et os d e dat os ent re s,
en est e caso, pr opi et ar i o
i dent i fi cador
Atributos
descript ivos
Atributos
referenci al es
Ma r c a Model o # de id. Tipo Color Propi et ari o
Lexus LS400 AB 1 2 3 . . . Sedan Bl anco RSP
CCD
BMW 750iL XZ765. . . Coup Bl anco UL
| Ford Taurus Q1 2 A4 5 .
. Se d n Azul BLF
Instancia
8.3.2 Atributos
Los atributos defi nen l as propi edades de un obj et o de dat os y t oman una de las tres
caract er st i cas diferent es. Se pueden utilizar para 1) nombr ar una ocurrenci a de:
obj et o de dat os, 2) describir la ocurrenci a o 3) hacer referenci a a ot ra ocurrenci a er
ot ra tabla. Adems, se debe definir uno o m s at ri but os como un identificador; es
decir, el atributo identificador se conviert e en una "clave" cuando se desea encont rar
una ocurrenci a del obj et o de dat os. En al gunos casos, los val ores para el (los) ider-
tificador(es) son nicos, aunque est o no es un requisito. En referenci a al obj et o de
dat os aut o, un identificador razonabl e podra ser el nmer o de serie.
El conj unt o de at ri but os apropi ado para un obj et o de dat os se det ermi na medi ar-
te la comprensi n del cont ext o del probl ema. Los at ribut os para aut o sirven bier
para una aplicacin que utilice el Depar t ament o de vehculos de mot or, per o estes
at ribut os seran intiles para una compa a aut omot ri z que necesi t e un sof t war e
para el control de fabricacin. En est e ltimo caso, l os at ri but os para aut o tal ve r
i ncl ui r an t a mbi n nmero de serie, tipo de carrocera y color, pe r o a d e m s t endr an q u t j
a d i c i ona r s e mu c h o s m s a t r i but os ( c omo cdigo interior, tipo de tren de manejo, desigrs-
dor de paquete de ajuste, tipo de transmisin) pa r a ha c e r de a u t o u n obj et o si gni fi cat i va
en el cont ext o de control de fabricacin.
Objetos de datos y clases OO, son
V Cuando se debat e acer ca de los obj et os de
dat os es comn que surja una pr egunt a: un
obj et o de dat os es lo mismo que una clase or i ent ada a
objet os? La respuesta es: "no".
Un obj et o de dat os defi ne un elemento compuest o de
los dat os; esto es, i ncorpora una coleccin de elementos de
dat os individuales (atributos) y da un nombre a la
coleccin de elementos (el nombr e del obj et o de datos).
Ûna clase O O encapsul a atributos de los dat os, pero
I NF ORMACI N
lo mismo?
t ambi n i ncorpora las operaci ones que mani pul an los
dat os implicados por di chos atributos. Adems, la
definicin de clases implica una infraestructura completa
que es part e del enf oque de la ingeniera de soft ware
ori ent ada a objetos. Las clases se comuni can ent re s a
travs de mensaj es; pueden or gani zar se en j erarqu as;
proporci onan caractersticas her edadas pa r a obj et os que
son una instancia pa r a una clase.
TM
PDF Editor
CAP TULO 8 MODELADO DEL ANLISIS 199
o) Una conexin bsica entre objetos
de datos
b) Relaciones entre objetos
de datos
8.3.3 Relaciones
Los obj et os de dat os est n conect ados ent r e s de muchas maner as diferent es. Por
ejempl o, dos obj et os de dat os, pers ona y aut o, pueden represent arse con la si mpl e
not aci n ilustrada en la figura 8.5a. Se est abl ece una conexi n ent re p e r s o n a y
aut o porque los obj et os se rel aci onan ent re s. Pero, cul es son l as rel aciones? La
respuest a se det ermi na ent endi endo el papel de l as per sonas (propietarios, en est e
estn caso) y de l os aut os dent ro del cont ext o del sof t war e que se const ruir. Se puede
definir un conj unt o de par ej as obj et o/ rel aci n que defi nan las rel aci ones rel evant es.
Por ejempl o:
Una persona posee un aut o.
Una persona est asegurada para conducir un aut o.
Las rel aci ones posee y est asegurada para conducir defi nen l as conexi ones rel evan-
t es ent re pers ona y auto. En la figura 8.5b se ilustran est as par ej as obj et o/ rel aci n
de maner a grfica. Las fl echas de la figura 8.5b ofrecen i nformaci n i mport ant e
acerca de la direccionalidad de la rel acin y a menudo reducen la ambi gedad o las
mal as i nt erpret aci ones.
8.3.4 Cardinalidad y modal i dad
Los el ement os del model ado de dat os objet os de dat os, at ri but os y relaciones
ofrecen la base par a ent ender el domi ni o de i nformaci n de un probl ema. Sin
embargo, t ambi n es necesari o compr ender i nformaci n adicional rel aci onada con
est os el ement os bsi cos.
Hasta est e punt o se ha definido un conj unt o de obj et os y se han r epr esent ado l as
parej as obj et o/ rel aci n que los limitan. Pero un simple par que est abl ece que
obj e t ox se relaciona con obj et oY no proporci ona suficiente i nformaci n para los
propsi t os de la ingeniera del soft ware. Se debe ent ender cunt as ocurrenci as del
obj e t ox est n rel aci onadas con cunt as ocurrenci as del objetoY. Esto conduce al
concept o del model ado de dat os l l amado cardinalidad.
El model o de dat os debe ser capaz de represent ar el nmer o de ocurrenci as de
l os obj et os en una relacin dada. Tillmann [T1L93J define la cardinalidad de un par
obj et o/ rel aci n de la siguient e maner a: "Cardinalidad es la especificacin del nme-
TM
PDF Editor
I
Cmo se
maneja una
situacin en la
que un i
datos est rela-
cionado con la
ocurrencia de
muchos otros
objetos de datos?
ro de ocur r enci as de un [objeto] que puede rel aci onarse con el nmer o de ocurren-
ci as de ot ro [objeto]". Por ej empl o, un obj et o puede rel aci onarse sl o con ot ro obje-
to (una relacin 1:1); un obj et o puede rel aci onarse con muchos obj et os (una rel aci .
1 :N); un nmer o de ocur r enci as de un obj et o puede rel aci onarse con al gn otro]
nmer o de ocur r enci as de ot ro obj et o (una rel aci n M:N).6 La cardi nal i dad t ambi er !
defi ne "el nmer o mxi mo de obj et os que puede part i ci par en una rel aci n" [TIL93] A
Sin embar go, no indica si un obj et o part i cul ar de dat os debe part i ci par o no en la
rel aci n. El model o de dat os agr ega modal i dad al par obj et o/ r el aci n par a especif
car est a i nformaci n.
I NF ORMACI N
r
Diagramas de entidad-relacin
La par ej a objeto-relacin es la piedra angul ar
del modelo de dat os. Estas parej as pueden
representarse de manera grfica mediante el di agr ama de
entidad-relacin (DER).' El DER lo propuso originalmente
Peter Chen [CHE77] par a el diseo de sistemas de bases
relacinales, y despus otros lo han ampl i ado. Con el DER
se identifica un conjunto de component es primarios:
objetos de datos, atributos, relaciones e indicadores de
varios tipos. El propsito primordial del DER es representar
objetos de datos y sus relaciones.
Ya se ha hecho una introduccin de la notacin
rudimentaria par a el DER. Los objetos de dat os se
representan por medio de un rectngulo etiquetado. Las
relaciones se representan mediante una lnea etiquetada
que conecta objetos. En al gunas variaciones del DER la
lnea de conexin contiene un rombo que est etiquetado
con la relacin. Las conexiones entre objetos de datos y
relaciones se establecen mediante una variedad de
smbolos especiales que indican su cardinalidad y
modal i dad.
Para ms informacin sobre el model ado de dat os y el
di agr ama de entidad-relacin el lector interesado puede
consultar [THA00]
La modalidad de una relacin es de 0 si no hay una necesi dad explcita para que
ocur r a la rel aci n o la rel aci n es opci onal . La modal i dad es 1 si una ocurrenci a de
la rel aci n es obl i gat ori a.
6
7
Por ejemplo, un to puede tener muchos sobrinos y un sobrino puede tener muchos tios.
Aunque el DER todava se usa en algunas aplicaciones para el diseo de bases de datos, en la ac-
tualidad la notacin en UML es la ms utilizada para el diseo de datos.
TM
PDF Editor
CAP TULO 8 MODELADO DEL ANLISIS
2 0 1
in un medio aut omat i zado par a crear
s de entidad-relacin, diccionarios de objetos de
y modelos relacionados.
ka: Las herramientas en esta cat egora permiten
describir objetos de datos y sus relaciones. En
casos utilizan la notacin del DER; en otras
modelan las relaciones por medio de otros
. Adems permiten la creacin de un modelo
de dat os al generar un esquema de base de datos
SM80.
itas representativas8
ERWin, desarrollado por Computes Associates
ca.com), ayuda en el diseo de objetos de datos,
propias y elementos clave para bases de datos.
>, desarrol l ado por Embarcadero Software
embarcadero. com), brinda soporte al model ado
relacin.
Oracle/Designer, desarrol l ado por Oracl e Systems
(www.orade.com), modela procesos de negocios,
entidades de dat os y relaciones que se transforman en
diseos a partir de los cuales se generan aplicaciones
completas y bases de datos.
MetoScope, desarrol l ado por Madrone Systems
(www.madronesystems.com), es una herramienta par a
el model ado de datos de baj o costo que da soporte a
la representacin grfica de dat os.
ModelSphere, desarrol l ado por Magna Solutions GMBH
(www.magnasolutions.com), da soporte a una vari edad
de herramientas de model ado relaciona!.
VisibleAnolysl, desarrollado por Visible Systems
(www.visible.com), da soporte a una vari edad de
funciones de model ado del anlisis, incluido el
model ado de dat os.
Cualquier est udio sobre el anlisis ori ent ado a obj et os deber a comenzar defi ni endo
el t rmi no orientado a objetos. Qu es un punt o de vista ori ent ado a objet os? Por
qu un mt odo se consi dera ori ent ado a objet os? Qu es un objeto? Cuando la OO
obt uvo una ampl i a variedad de adept os durant e las dcadas de 1980 y 1990, existie-
ron muchas opi ni ones di ferent es (por ejempl o, [BER93|, TAY90], (STR88], [ B0086|
acerca de las r espuest as correct as a est as pregunt as. En la act ual idad ha surgido una
visin coher ent e de la OO.
El objetivo del anlisis ori ent ado a obj et os (AOO) es definir t odas l as cl ases (ade-
ms de las rel aci ones y el compor t ami ent o asoci ado con ellas) rel evant es para el
probl ema y que deben resol verse. Esto se logra llevando a cabo al gunas t areas:
1. Deben comuni carse los requi si t os bsi cos del usuari o ent re el cliente y el in-
geni ero de soft ware.
2. Deben identificarse l as cl ases (es decir, se defi nen los at ribut os y mt odos).
3. Se define una jerarqua de clases.
4. Deben represent arse las relaciones de objeto a objeto (conexiones ent re objetos).
5. Debe model arse el compor t ami ent o del objet o.
6. Las t ar eas 1 a 5 se vuelven a aplicar de maner a iterativa hast a que el model o
est compl et o.
8 Las herramientas mencionadas aqu son una muestra de esta categora. En la mayora de los casos
los nombres estn registrados por sus respectivos desarrolladores.
TM
PDF Editor
2 02 P A R T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
En lugar de exami nar un pr obl ema medi ant e un model o m s convenci onal cel l
t i po ent r ada- pr ocesami ent o- sal i da (flujo de i nformaci n) o un model o deri vado i
f or ma excl usiva de l as est r uct ur as j errqui cas de i nformaci n, el AOO const ruye i
model o or i ent ado a las cl ases que se bas a en la compr ensi n de l os concept os i
I NF ORMACI N
Conceptos orientados a objetos
Los conceptos orient ados a objetos (OO) estn
bien establecidos en el mundo de la ingeniera
del software. A continuacin se presentan las descripciones
abrevi adas de conceptos OO que se encuentran con
frecuencia durant e el model ado del anlisis. En el captulo
10 se presentan otros objetos O O que estn al ineados de
manera ms cercana al diseo de software.
Atributos: una coleccin de valores de los dat os que
describen una clase.
Clase: encapsul a los dat os y las abstracciones de
procedimiento requeridos par a describir el contenido y el
comportamiento de al guna entidad del mundo real. Dicho
de otra maner a, una clase es una descripcin
general i zada (por ejemplo, una plantilla, un patrn o un
pl ano de t rabaj o) que describe una coleccin de objetos
similares.
Objetos: instancias de una clase especfica. Los obj e^s
heredan los atributos y operaci ones de una clase.
Operaci ones: tambin l l amadas mtodos y servicios
proporcionan la representacin de uno de los
comportamientos de una clase.
Subclase: una especializacin de la superclase. Ur-c
subclase puede heredar tanto los atributos como las
operaci ones de una superclase.
Superclase: tambin l l amada una clase bsica, es ,
generalizacin de un conjunto de clases que estn
rel acionadas con ella.
Aunque el xit o de un si st ema o pr oduct o bas ado en comput ador a se
muchas f or mas, la sat i sfacci n del usuar i o encabeza la lista. Si los i nger
sof t war e ent i enden la maner a en que los usuar i os fi nal es (y ot r os act ores)
i nt eract uar con el si st ema, el equi po de sof t war e ser m s capaz de caract e
f or ma apr opi ada los requi si t os y const rui r model os significativos de anl isis r<
o. Por lo t ant o, el model ado del anl isis con UML comi enza con la creaci n de
nari os en la f or ma de casos de uso, di agr amas de act ividad y di agr amas de
8.5.1 Escritura de casos de uso
Un caso de uso capt ur a l as i nt er acci ones que ocur r en ent r e los product ores
sumi dor es de i nformaci n y del si st ema en s mi smo. En est a secci n se ex
f or ma en que se desarrol l an los casos de uso como una par t e de la act i n
model ado del anl i si s. 9
El concept o de un cas o de uso (captulo 7) e s r el at i vament e fcil de ent er
cribe un escenar i o de uso espec fi co en un l enguaj e di rect o desde el punt e
9 Los casos de uso son una parte particularmente importante del modelado del anlisis
terfases con el usuario. El anlisis de la interfaz se trata con detalle en el captulo 12.
TM
PDF Editor
CAP TULO 8 MODELADO DEL ANLISIS 2 0 3
de un act or definido. 10 Pero c mo puede s aber s e 1) sobre qu escribir? 2), cunt o
escribir acer ca de ello? 3), qu t an det al l ada debe s er la descri pci n?, y 4) cmo or ga-
ni zar la descri pci n? Est as s on l as pr egunt as que deben cont est ar se par a que los cas os
de uso t engan un val or c omo her r ami ent a par a el model ado del anl isis.
"[Los cosos de us o] s on s i mpl ement e uno a yudo para defi ni r lo que exi s t e f ue r a del si st ema ( act or es) y lo que deber a
r eal i zar el si st ema (cosos de uso) . "
Ivor Jacobson
s i t u -
i c a s o s d e
e l
l a i n g e -
ajusflos.
e s t o n o
d e b a n
l o s
i t c n i c a s
m e l
S o b r e q u e s c r i b i r ? Las pr i mer as dos t a r e a s de la i ngeni er a de requi si t os1 1 ini-
ci o y obt enci n pr opor ci onan la i nf or maci n neces ar i a par a c o me n z a r a escri bi r
c a s os de uso. Las r euni ones par a la r ecopi l aci n de requi si t os, des pl i egue de la f un-
ci n de cal i dad (QFD) y ot r os me c a ni s mos par a la i ngeni er a de r equi si t os s e ut i l i zan
par a i dent i fi car a l os i nt er esados, defi ni r el mbi t o del pr obl ema, especi f i car l as
me t a s oper at i vas gl obal es, e s que ma t i z a r t odos l os r equi si t os f unci onal es conoci dos
y descri bi r l as c os a s (objet os) que mani pul ar el si st ema.
El desar r ol l o d e una ser i e de c a s os de us o s e c omi e nz a haci endo una lista de l as
f unci ones o act i vi dades que r eal i za un act or espec f i co. st as pue de n obt ener s e de
una lista de f unci ones r equer i das del s i s t ema por medi o de conver s aci ones con l os
cl i ent es o us uar i os finales, o medi ant e una eval uaci n de l os di agr amas de act i vi dad
( secci n 8.5.2) des ar r ol l ados c o mo par t e del mode l a do del anl i si s.
Desarrollo de otro escenario de uso preliminar
la segunda unta par a la recopilacin
s: Jamie Lazar, miembro del equi po de
Ed Robbins, miembro del equi po de software;
f, gerente de ingeniera del software; tres
de mercadotecnia; un representante de
de producto; y un moderador.
: n :
n Es hora d s que comencemos a habl ar
de la funcin de vigilancia de HogarSeguro.
a desarrollar un escenario de usuario par a el
a la funcin de seguridad en el hogar.
J a mi e : Quin hace el papel del actor en esto?
Mo d e r a d o r : Creo que Meredith (una persona de
mercadotecnia) ha est ado t r abaj ando en esa
funcionalidad. Por qu no haces t el papel ?
Me r e d i t h : Quieres que lo hagamos igual que la ltima
vez, no es asi?
Mo d e r a d o r : Correcto... de la misma forma.
Me r e d i t h : Bueno, es obvio que la razn par a la
vigilancia es permitir que el propietario est pendiente de
la casa mientras l o ella estn fuera, gr abar y
reproducir videos que se hayan capt urado. . . ese tipo de
10 Un actor no es una persona especifica, sino el papel que desempea una persona (o dispositivo) den-
tro de un contexto especfico. Un actor "llama al sistema para entregar uno de sus servicios"
[COCOl],
11 Estas tareas de la ingeniera de requisitos se examinan con detalle en el captulo 7.
TM
PDF Editor
Ed: El video ser digital y se al macenar en disco?
Mo d e r a d o r : Buerva pregunt a, pero por ahor a
pospongamos los aspect os de implementacin.
Meredith? V
Me r e d i t h : De acuerdo, entonces bsicament e hay dos
part es par a la funcin de vigilancia... la primera
configura el sistema, incluyendo el establecimiento de un
piano de la casa -necesi t amos herramientas que ayuden
ol propietario a hacerl o- y la segunda part e es la funcin
de vigilancia real en s misma. Como el establecimiento
del pl ano es part e de la actividad de configuracin, me
enfocar en la funcin de vigilancia.
Mo d e r a d o r ( s o n r i e n d o ) : Me quitaste las pal abr as
de Id boca. >' s '
Me r e d i t h : Mm. . . Qui ero tener acceso a la funcin de
vigilancia, ya sea o travs de la PC o de Internet. Siento
que el acceso por Internet sera el de uso ms frecuente.
De cualquier manera, quiero ser capaz de despl egar
vistas de las cmar as en una PC y controlar el
movimiento y los acercamient os de una cmar a
especfica. Especifico la cmar a seleccionada desde el
pl ano de la casa. Qui ero gr abar y reproducir la salida
de las cmar as de maner a selectiva. Tombin quiero ser
capaz de bloquear el acceso o une o ms cmar as con
una contrasea especfica. Y quiero la opcin de ver
pequeas vent anas que muestren vistas de t odas las
cmar as y despus ser capaz de seleccionar la que
quiero destacar.
J a mi e : Esas se llaman vistas en miniatura.
Me r e d i t h : Bien, entonces quiero vistas en miniatura de
t odas los cmaras. Tambin quiero que la interfaz con le
funcin de vigilancia t enga la misma apariencia que
t odas las otras interfases de HogarSoguro. Qui ero que
sea intuitiva; es decir, que h sea necesario leer un
manual par a poder usarl a. / B U
Mo d e r a d o r : Buen t rabaj o, ahor a entremos en esta
funcin con un poco ms de detalle. ..
11
La funci n de vigilancia en el hogar de HogarSeguro que se exami na en el r ecua- 1
dro identifica las si gui ent es f unci ones (una lista abrevi ada) que real i za el act or i d e r - l
tificado como propi et ari o de l a casa:
Tener acces o a la cmar a de vigilancia va Int ernet .
Sel ecci onar la cmar a que desea ver.
Solicitar vi st as en mi ni at ura de t odas l as cmar as .
Despl egar vi st as de la cmar a en una vent ana de una PC.
Cont rol ar la visin panor mi ca y de acer cami ent o en una cmar a espec fi ca
Registrar en f or ma sel ect iva la sal ida de cmar a.
Repetir la sal ida de cmar a.
Conf or me se real i zan las conver saci ones post eri ores con el i nt er esado ( qui esl
des empea el papel de un propiet ario), el equi po de recopi l aci n de requi si t os desa-
rrolla casos de us o par a cada una de las f unci ones menci onadas. En general , 1:s
casos de uso se escri ben pr i mer o en un estilo narrat i vo i nformal . Si se requiere'
mayor formal i dad se rescri be el mi s mo caso de us o ut i l i zando un f or mat o est ruct u-
r ado similar al pr opuest o en el cap t ul o 7 y reproduci do en est a secci n como i r a
recuadro.
Con fines ilustrativos, consi dr ese la funci n "acceso a cmar a de vigilancia-des-
pl i egue de vi st as de cmar a (ACV-DVC)". El i nt er esado que des empea el papel e s
propi et ari o podra escribir el si gui ent e relato:
TM
PDF Editor
CAP TULO 8 MODELADO DEL ANLISIS 2 05
Caso de uso: Acceso a cmara de vigilancia-despliegue de vistas de cmara
(ACV-DVC)
Actor: propietario
Si me encuentro en un lugar lejano puedo usar una PC con un software de navegacin
apropiado para entrar al sitio web de los productos HogarSeguro. Ingreso mi clave de usua-
rio y dos niveles de contraseas y, despus de que estoy validado, tengo acceso a toda la
funcionalidad de mi sistema HogarSeguro instalado. Para tener acceso a la vista de una c-
mara especfica selecciono "vigilancia" de los botones desplegados para las funciones ms
importantes. Despus escojo "seleccionar una cmara" y se despliega un plano de planta
de la casa. Entonces selecciono la cmara en la que estoy interesado. En forma alterna,
puedo ver simultneamente una lista con vistas en miniatura de todas las cmaras al se-
leccionar "todas las cmaras" como mi opcin de visualizacin. Una vez que he seleccio-
nado una cmara, selecciono "vista" y una vista de un cuadro por segundo aparece en una
ventana, a la cual identifica la cmara clave. Si quiero cambiar de cmara, elijo "seleccio-
nar una cmara" y la ventana de visin original desaparece y se despliega de nuevo el
plano de planta de la casa.
Una var i aci n del c a s o de us o r el at ado pr es ent a la i nt er acci n c o mo una s ecuenci a
or de na da de l as acci ones del usuar i o. Cada acci n s e r epr es ent a c o mo un enunci a-
d o decl ar at i vo. Des pus de vi si t ar la f unci n ACV-DVC, s e pue de escri bi r:
Caso de uso: Acceso a cmara de vigilancia-despliegue de vi stas de cmara
(ACV-DVC)
Actor: propietario
1. El propietario entra en el sitio Web de HogarSeguro.
2. El propietario introduce su clave de usuario.
3. El propietario introduce dos contraseas (cada una de al menos ocho caracteres).
4. El sistema despliega todos los botones de las funciones ms importantes.
5. El propietario selecciona "vigilancia" de los botones de funciones ms importantes.
6. El propietario elige "seleccionar una cmara".
7. El sistema despliega el plano de planta de la casa.
8. El propietario selecciona un icono de cmara del plano de planta.
9. El propietario selecciona el botn "vista".
10. El sistema despliega una ventana de visin, identificado por la clave de la cmara.
11. El sistema muestra salida de video dentro de la ventana de visin con una veloci-
dad de un marco por segundo.
Es i mpor t ant e des t acar que es t a pr es ent aci n secuenci al no consi der a a l guna s i nt e-
r acci ones al t er nat i vas (la nar r at i va t i ene un fl uj o m s l i bre y r epr es ent a u n a s c ua n-
t as al t er nat i vas) . Los c a s os de us o de est e t i po s e r ef i er en al gunas veces c o mo esce-
narios primarios [SCH98].
"Los cosos d e uso pueden us ar s e e n muchos procesos [ d e s of t war e] . Nuest ro f avor i t o e s un proceso que s eo i t er at i vo y
conduci do por el r i esgo. "
Geri Schneider y Jason Winters
TM
PDF Editor
Cmo se
examinan
cursos
alternativos de
accin mientras
se desarrolla un
caso de uso?
Por supuest o, para una comprensi n compl et a de la funcin que se pret ende
cribir es esencial una descripcin de l as i nt eracci ones al t ernat ivas. Por lo tanto,
paso en el escenari o pri mari o se eval a real i zando las si gui ent es pregunt as [SC
El act o puede ej ecut ar ot ra accin en est e punt o?
Es posible que el act or encuent re al guna condi ci n de error en est e punt e -
es as, cul podra ser?
Es posibl e que el act or encuent r e al gn ot ro compor t ami ent o provocado
algn event o fuera de su control? Si es as, cul podra ser?
El resul t ado de las r espuest as a est as pregunt as es la creacin de un conj unt e
escenari os secundari os que son part e del caso de uso original, per o que represe
compor t ami ent os alternativos.
Por ejempl o, consi drense los pasos 6 y 7 en el escenari o pri mari o presen
lneas at rs:
6. El propietario elige "seleccionar una cmara".
7. El sistema despliega el plano de planta de la casa.
El actor puede ejecutar otra accin en este punto? La respuest a es: "s". Con refe
cia al relato de flujo libre, el act or puede elegir ver las vistas en mi ni at ura de t<~
las cmar as de maner a si mul t nea. Por ende, un escenari o secundari o podra
"Ver las vistas en mi ni at ura de t odas l as cmaras".
Es posible que el actor encuentre alguna condicin de error en este punto? C
un si st ema basado en comput ador a est en funci onami ent o puede ocurrir cualq
cant i dad de condi ci ones de error. En est e cont ext o se consi deran slo las condicio-
nes de error que pueden ocurrir como resul t ado direct o de l as acci ones descrit as er
los pasos 6 o 7. De nuevo, la respuest a a la pregunt a es: "s". Puede ser que nunca
se haya confi gurado un pl ano de pl ant a con i conos de las cmar as. Por lo t ant o, 5_
elegir "seleccionar una cmar a" se produce una condi ci n de error: "no existe un
pl ano de pl ant a confi gurado para est a casa".12 Esta condicin de error se convierte
en un escenari o secundari o.
Es posible que el actor encuentre algn otro comportamiento en este punto? De
nuevo, la respuest a a la pregunt a es: "si". Cuando se real izan los pasos 6 y 7 el sis-
t ema puede encont r ar una condicin de al arma. Esto podra resultar en que el siste-
ma despl egara una notificacin especial de al arma (tipo, ubicacin, accin del sis-
tema) y le proporci one al act or una serie de opci ones rel aci onadas con la naturale-
za de la al arma. Como est e escenari o secundari o puede ocurrir para casi t odas las
int eracciones, no se convertir en una part e del caso de uso para el ACV-DVC. Er
12 En este caso, otro actor, el administrador del sistema, tendra que configurar el plano de planta,
instalar e inicializar (es decir, asignar una ID a cada equipo) para todas las cmaras, as como rea-
lizar pruebas para estar seguro de que cada una de ellas es accesible por medio del sistema y a tra-
vs del plano de planta.
TM
PDF Editor
CAP TULO 8 MODELADO DEL ANLISIS 2 0 7
vez de eso, se desarrollar un caso de uso por separado "condicin de al arma
encontrada", el cual est ar referenciado a otros casos de uso, segn se requiera.
En relacin con las plantillas formales para los casos de uso que se muest ran en
el recuadro, los escenari os secundari os se represent an como excepciones a la
secuencia bsica descrita respecto al ACV-DVC.
HOGARS EGURO
Plantilla de caso de uso para 1a vigilancia
en contexto!
Caso de uso: Acceso o la cmar a
de vigilancia-despliegue de vistas
de cmar a (ACV-DVC).
Propietario !
Ver la salida de las cmar as
col ocadas a lo l argo de la casa
desde cualquier ubicacin remota
a travs de I
, previas: El sistema se debe configurar por
completo; se deben obtener ID y
contraseas apr opi adas para los
usuarios.
Ei propietario decide echarle un
vitazo a su casa mientras se
encuentra fuera de ella.
El propietario ent ra al sitio web de Producios
HogarSeguro.
2 El propietario introduce su ID de usuario,
i El propietario introduce dos cont raseas (cada una
de al menos ocho caracteres).
- El sistema despliega todos los botones de las
funciones ms importantes.
i El propietario selecciona "vigilancia" de los botones
de las funciones ms importantes.
6 El propietario selecciona "escoger una cmara".
El sistema despliega el pl ano de la casa.
8. El propietario selecciona el icono de una cmar a del
pl ano de pl ant a.
; El propietario selecciona el botn "vista".
0 El sistema despliega una vent ana de visualizacin
que est identificada con la ID de la cmar a.
11. El sistema despliega la salida de video dentro de ta
vent ana de visualizacin a un cuadro por segundo.
Excepciones:
1. La ID o las cont raseas son incorrectos o no se
reconocen; vase el caso de uso: "validar ID y
contraseas".
2. La funcin de vigilancia no est confi gurada par a
este sistema, as que el sistema despliega el mensaj e
de error apropi ado; vase el caso de uso:
"configurar la funcin de vigilancia".
3. El propietario selecciona "Ver vistas en miniatura
par a todas las cmaras"; vase el caso de uso: "Ver
vistas en miniatura par a t odas las cmaros".
4. No est disponible un pl ano de planta o ste no se
ha configurado, asi que el sistema despliega el
mensaj e de error apropi ado; vase ei caso de uso
"configurar plano de la casa".
5. Se encuent ra una condicin de al arma; vase el
caso de uso: "condicin de al arma encont rada".
Prioridad: Prioridad moder ada, que se
implementar despus de las
funciones bsicas.
Disponible en: El tercer incremento.
Frecuencia de uso: Poco frecuente.
Canal haci a el actor: A travs de un browser bas ado en
PC y conexin de Internet al sitio
web de HogarSeguro.
Actores secundarios: Administrador del sistema,
cmar as.
Canal es hacia los actores secundarios:
1. Administrador del sistema: sistema bas ado en PC.
2. Cmaras: conectividad inalmbrica
TM
PDF Editor
2 08 P ARTE D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
Aspectos pendientes: 3. La respuesta del sistema vio Internet ser aceptable
dado el anch de banda requerido par a fas vistas
de cmar a? I
1. Cul es el mecanismo que prot ege contra el uso no
aut ori zado de esta capaci dad por part e de los
empl eados de la compa a? 4. Se desarrollar una capaci dad par a proporci ona'
video a una tasa mayor de cuadros por segundo
cuando estn disponibles conexiones con mayor
ancho de banda? 9
2. La seguridad es suficiente? El ingreso no aut ori zado
en esta caracterstica representara una invasin
importante de la privacidad.
Cundo s e han ;
t emi i r ado j e est ri bi l l os
cosos do us ? Para uno
exposi t n valiosa de
est e tpico, vase
oot i ps. org/
use- t ases- done.
htmfooti ps. org/
use-cases-done.
ht ml
En muchos casos no es necesari o crear una represent aci n grfica de un es cer ;
rio de uso. Sin embargo, la represent aci n di agramt i ca puede facilitar la compren-
sin, en particular cuando el escenari o es compl ejo. Como se menci on en el car -
tulo 7, el UML proporci ona una capaci dad para hacer di agramas de casos de uso pre-
liminar para el product o HogarSeguro. Cada caso de us o s e represent a medi ant e l - 1
valo. En est a seccin sl o se ha exami nado en det al l e el caso de uso para el ACV-
DVC.
8.5.2 Desarrollo de un di agrama de actividad
El di agrama de actividad en UML (que se t rat en forma breve en los capt ul os 6 y 7
compl ement a el caso de uso al proporcionar una representacin grfica del flujo de inte
raccin dent ro de un escenari o especfico. De maner a similar al di agr ama de fluj:
un di agrama de actividad utiliza rect ngul os r edondeados para indicar una funci c-
especfica del sist ema, flechas para represent ar el flujo a t ravs del sist ema, romb> s
de decisin par a most rar una ramificacin por decisin (cada flecha que sal e de
r ombo se etiqueta), y lneas hori zont al es sl idas para indicar que ocurren activida-
des paralelas.
Diagrama
preliminar de
caso de uso
para el
sistema
HogarSeguro.
HogarSeguro
TM
PDF Editor
2 0 9
a de
de
a l a
de
e
ret as de
/ introducir cont r as ea^
e ID del usuario J
Cont r aseas/ I D vl i das Cont raseas/ 1 D no vlidos
Tambin se pueden
sel eccionar
ot ras funci ones
" Seleccionar u n a \ ( Opci n par a \
funci nî mport ant e/ \ rei ngreso J
Seleccionar
/ No restan
intentos de ent r ada
Restan intentos
de ent r ada
Seleccionar una
cmar a especfica
Seleccionar una cmara
i en miniatura
Seleccionar un cono
)
la salida de una cmar a
en una vent ana
C
Opci n par a
otra vista )
Salir de esta funcin
Ver otra cmar a
( CLAVE
de
enUML
te acciones
que
r t r a s s e
funcin.
En la figura 8. 7 s e mues t r a un di a gr a ma d e act i vi dad par a la f unci n de ACV-
DVC. Se de be r esal t ar que el di agr ama de act i vi dad agr ega det al l es adi ci onal es que
n o s e me nc i ona n de ma ne r a di rect a (pero s implcita) en el c a s o d e uso. Por e j e m-
pl o, un us uar i o pue d e i nt ent ar i ngr esar la I Dus uar i o y la c o nt r a s e a s l o un n me -
r o l i mi t ado de veces . Est o s e r epr es ent a me di a nt e un r o mb o de deci si n de ba j o de
opcin para reingreso.
8.5.3 Diagramas de carril
El diagrama de carril de UML e s una var i aci n til del di agr ama de act i vi dad, ya que
per mi t e al mode l a dor la r epr es ent aci n del flujo de act i vi dades descr i t as por el c a s o
de us o y, al mi s mo t i empo, i ndi car qu act or (si hay ml t i pl es a c t or e s i nvol ucr ados
en una f unci n espec fi ca) o cl ase de anl i si s t i ene la r esponsabi l i dad de la acci n
descr i t a medi ant e un r ect ngul o de act i vi dad. Las r es pons abi l i dades s e r epr es ent an
TM
PDF Editor
Introducir cont rasea
e ID del usuario
Cont r aseas/ I D vlidas
!ontraseas/ID
no vlidas
funcin importante
ion par a reingreso
Restan intentos
\ d e ent rada
Seleccionar una
. cmara especfica
;<xionar una cmara
especifica-vistas
en miniatura .
Sel ecci onar un
cono de cmar a
Gener ar salida
de video
Vista de sal i da de cmar a
en una vent ana et i quet ada
* 4
C&VE
Un diagrama de
caniles en UML
representa el flujo de
los occnes y los
der i sones e indico
a x f e s odor es realizan
r a l o uno de eSos.
c o mo s e gme nt os par al el os que di vi den el di agr ama en f or ma vert i cal , c o mo los
c a ni l e s de una al ber ca.
Existen t res cl ases de anl i si s Propi et ari o, Int erf az y Cmara con r esponsa-
bi l i dades di r ect as o i ndi rect as en el cont ext o del di agr ama de act i vi dad r epr es ent ado
en la figura 8.7. Respect o de la figura 8.8, el di agr ama de act i vi dad se r eor gani za de
f or ma que l as act i vi dades as oci adas con una cl ase de anl i si s part i cul ar per t enezcan
al carril cor r espondi ent e a di cha cl ase. Por ej empl o, la cl ase Int erf az r epr esent a la
i nt erfaz con el usuar i o de acuer do con la visin del propi et ari o. El di agr ama de activi
dad consi der a dos opci ones que s on r esponsabi l i dad de la i nt erfaz: opcin para el rein
Diagrama de carril para la funcin de Acceso a la cmara de vigilancia-despliegue de
vistas de cmara.
Propietario Cmara
Vistas en
miniatura
Interfaz
(
Tambin se
pueden
seleccionar
otras f Sel ecci onar vigilancia \
funciones N, J
No restan
intentos de ent rada
Opci n
" \ ^ por a otra vista y
Salir de
_ e s t a funcin
<8>
Ver otra
cmar a
TM
PDF Editor
CAP TULO 8 MODELADO DEL ANLISIS 2 11
greso y opcin para otra vista. Est as opci ones y l as deci si ones as oci adas con el l as per -
t enecen al carril de Int erf az. Sin embar go, l as flechas conducen desde es e carril de
r egr eso al carril de propi et ari o, donde ocur r en l as acci ones del propi et ari o.
J L .
DELADQ OBI AL FLUJ O
El mode l a do de da t os or i ent ado al flujo e s una de l as not aci ones de anl i si s ut il iza-
da s con mayor ampl i t ud en la act ual i dad. 1 3 Aunque el diagrama de flujo de datos
(DFD) y l os di a gr a ma s y la i nf or maci n r el aci onados n o s on una par t e f or mal de
UML, pue de n ut i l i zarse par a c ompl e me nt a r l os di a gr a ma s en UML y pr opor ci onar un
conoci mi ent o adi ci onal de l os r equi si t os y el flujo del s i s t ema.
El DFD t i ene una vi si n del si st ema del t i po ent r ada- pr oces o- s al i da. Est o es, l os
obj et os de da t os fluyen haci a el i nt eri or del s of t war e, s e t r ans f or man me di a nt e el e-
me nt os de pr oces ami ent o, y l os obj et os de da t os r es ul t ant es fluyen al ext er i or del
s of t war e. Los obj et os de da t os s e r epr es ent an medi ant e f l echas r ot ul adas y l as t r ans-
f or maci ones s e r epr es ent an por me di o de c rcul os ( t ambi n l l amadas burbujas). El
DFD s e pr es ent a en una f or ma j er r qui ca. Est o es, el pr i mer mode l o de flujo de da t os
( al gunas veces l l amado un DFD de nivel 0 o diagrama de contexto) r epr es ent a el si s-
t ema c o mo un t odo. Los di a gr a ma s de flujo de da t os s ubs e c ue nt e s r ef l nan el di a-
gr a ma de cont ext o, ya que pr opor ci onan una cant i dad cr eci ent e de det al l es con cada
nivel subsi gui ent e.
"Ei pr opsi t o d e los di a gr a ma s de f l uj o d e dat os e s pr opor ci onar un pue nt e semnt i co e nt r e l os usuar i os y l os
de s a bol l a dor e s de si st emas. "
Kenneth Rozar
*
x t s o n a s
f i e e l D F D
b t i e j o
y q u e n o
e n l a
m d e r n o .
i v i s i n q u e
a f o r m a d e
t p o t e n -
l U o l n i v e l
S i e s d e
r e c o m i e n d o
e l D F D .
8.6.1 Creacin de un modelo de flujo de datos
El di agr ama de f l uj o de d a t os per mi t e que el i ngeni er o de s of t wa r e desar r ol l e mode -
l os del domi ni o de i nf or maci n y del domi ni o f unci onal al mi s mo t i empo. A medi da
que el DFD s e r ef i na haci a gr a dos ma yor e s de det al l e, el anal i st a d e s e mpe a una
des compos i ci n f unci onal impl cit a del s i s t ema. Al mi s mo t i empo, el r ef i nami ent o
del DFD r esul t a en un cor r es pondi ent e r ef i nami ent o de dat os mi ent r as s e mu e v e
haci a l os pr oces os que i ncor por an la apl i caci n
Unas poc a s di r ect r i ces s i mpl es per mi t en obt ener una ayuda i nval uabl e dur a nt e la
cr eaci n de un di agr ama de flujo de dat os: 1) el nivel 0 del di agr ama de fl uj o de da t os
debe r epr es ent ar al s of t wa r e / s i s t e ma c o mo u n a sol a bur buj a; 2) la ent r ada y la sali-
da pr i mar i a deben es t abl ecer s e con cui dado; 3) la r ef i naci n debe c o me n z a r por el
ai s l ami ent o de pr oces os , obj et os de dat os y a l ma c e na mi e nt os de da t os candi dat os a
s er r e pr e s e nt a dos en el si gui ent e nivel; 4) t odas l as flechas y bur buj a s s e d e be n r ot u-
lar con nombr e s si gni fi cat i vos; 5) s e debe ma nt e ne r la cont i nui dad del fl uj o de i nfor-
13 El modelo de flujo de datos es una actividad de modelado esencial en el anlisis estructurado.
TM
PDF Editor
DFD al nivel
de contexto
para la
funcin de
seguridad de
HogarSeguro.
\
CLAVE
l a continuidad del fluo
de informacin debe
mant enerse conforme
se refina cada nivel del
DFD. Esto significa que
lo entrada y salida en
un nivel deben ser los
mi smas que la ent rada
y salida en un nivel
refinado.
maci n al cambi ar de nivel a nivel;14 y 6) la refinacin de l as bur buj as debe hacerse
una por una. Existe una t endenci a nat ural a compl icar de ms el di agrama de fin;:
de dat os. Esto ocurre cuando el anal ist a i nt ent a most rar muchos det al l es demasi a-
do pront o o represent ar aspect os de procedi mi ent o del sof t war e en lugar de ele
ment os del flujo de i nformaci n.
El uso del DFD y de la not aci n rel aci onada se ilustra de nuevo consi derando la
funcin de seguri dad en el hogar de HogarSeguro. En la figura 8.9 se muest ra un DFC
al nivel de cont ext o para la funcin de seguri dad. Las ent i dades ext ernas primarias
(cajas) producen i nformaci n para el uso del si st ema y consumen i nformaci n que
st e genera. Las fl echas rot ul adas r epr esent an obj et os de dat os o j erarqu as de obje-
t os de dat os. Por ejempl o, c o ma ndo s y dat os del usuari o abarcan t odos los
comandos de configuracin, t odos los comandos de act i vaci n/ desact i vaci n, t odas
las i nt eracci ones y t odos los dat os que se ingresan para calificar o expandi r un
comando.
El DFD de nivel 0 ahor a se expande a un model o de flujo de dat os de nivel 1. Pero
cmo se logra esto? Un enf oque simple, pero efectivo, es real izar un "anlisis gra-
matical" [ABB83] sobre la narrativa que describe la burbuj a al nivel de cont ext o. Esto
es, se aisl an t odos los sust ant i vos y verbos en la narrativa de procesamiento de
HogarSeguro15 obt eni da durant e la pri mera reuni n para la recopilacin de requisi-
tos. Con propsi t os ilustrativos, consi drese el si gui ent e t ext o narrat i vo de procesa-
mi ent o con la primera apari ci n de t odos los sust ant i vos subr ayados y la primera
apari ci n de t odos los verbos en itlicas.16
14 Esto es, los objetos de datos que Huyen hacia el sistema o cualquier transformacin en algn nivel,
deben ser los mismos objetos de datos (o sus partes constituyentes) que fluyen hacia la transfor-
macin en un nivel ms refinado.
15 Una narrativa del procesamiento es similar en estilo al caso de uso, pero algo diferente en prop-
sito. La narrativa del procesamiento proporciona una descripcin general de la funcin que ser de-
sarrollada. No es un escenario escrito desde el punto de vista de alguno de los actores.
16 Debe notarse que se omiten los sustantivos o verbos que son sinnimos o que no tienen una inge-
rencia directa en el proceso de modelacin. Tambin se debe notar que, cuando se considere el mo-
delado basado en clases de la seccin 8.7, se usar un anlisis gramatical similar.
TM
PDF Editor
s g r a m a t i c a l
i d e
i x w p u e d e
r u n
t p a s o i n i c i a l
: i n s t e a l g u n a
i p o r a d e f i n i r
E X d a t o s y l a s
s q u e
i e l l o s .
La funcin de seguridad de HogarSeguro permite al propietario configurar el sistema de se-
guridad cuando ste se instala, monitorear todos los sensores que se conectan al sistema
de seguridad y que interactan con el propietario a travs de Internet una PC o un panel
de control.
Durante la instalacin, la PC de HogarSeguro se utiliza para programar y configurar el
sistema. A cada sensor se le asigna un nmero y lipa, se programa una contrasea ma-
estra para habilitar o deshabilitar el sistema, y algunos nmeros telefnicos ingresan para
marcarse cuando se presenta un evento en los sensores.
Cuando se reconoce un evento en los sensores, el software solicita una alarma audible
que el propietario especifica durante las actividades de configuracin del sistema, el soft-
ware marca el nmero telefnico de un servicio de monitoreo. proporciona informacin
acerca de la ubicacin, reporta la naturaleza del evento que se ha detectado. El nmero
telefnico se remarca cada 20 segundos hasta que se obtiene una conexin telefnica.
El propietario recibe informacin de seguridad a travs de un panel de control, la PC o
un buscador que en forma colectiva se denomina una interfaz La interfaz despliega men-
sajes de opcin e informacin del estatus del sistema en el panel de control, la PC o la ven-
tana del buscador. La interaccin del propietario asume la siguiente forma...
En r el aci n con el anl i si s gr amat i cal c omi e nz a a surgi r un pat r n. Los ver bos s on
l os pr oces os de HogarSeguro-, es t o es, al final pue de n r epr es ent ar s e c o mo bur buj a s
en un DFD s ubs ecuent e. Los s us t ant i vos s on ent i dades e xt e r na s (cajas), obj et os de
da t os o d e cont r ol (fl echas), o a l ma c e na mi e nt os de da t os (l neas dobl es) . Des pus
debe obs er var s e que l os s us t ant i vos y ver bos se pue da n as oci ar de di st i nt as f or mas
t de nivel 1
i Va funcin
i seguridad de
TM
PDF Editor
DFD de nivel 2
que refina el
proceso de
monitoreo
de sensores.
^CQNSEJof f i
S e d e b e t e n e r l a
s e g u n d a d d e q u e l o d a
l o n a r r a t i v a d e p r o c e -
s a m i e n t o q u e s e
i n t e n t o a n a l i z a r e s t
e s c r i t a c o n e l m i s m o
g r a d o d e a b s t r a c c i n .
ent re s. Por ejempl o, a cada sensor se le asigna un nmer o y un tipo; por lo tanto,
el nmero y el tipo son at ri but os del obj et o de dat os s ens or. Ent onces, al realizar ur
anlisis gramat ical sobre la narrativa de pr ocesami ent o para una burbuj a en cual-
quier nivel del DFD, se puede generar mucha i nformaci n til acerca de cmo pro-
ceder con la refinacin para el siguient e nivel. En la figura 8.10 se present a un DFD
de nivel 1 para el cual se ha utilizado est a i nformaci n. El pr oceso al nivel de con-
texto most rado en la figura 8.9 se ha expandi do a seis procesos obt eni dos de un exa-
men del anlisis gramatical. De maner a similar, el flujo de i nformaci n ent re los pro-
cesos en el nivel 1 ha sido obt eni do del anlisis. Adems, se mant i ene la continui-
dad del flujo de i nformaci n ent re los niveles 0 y 1.
Los procesos r epr esent ados en el DFD de nivel 1 se refinan despus hacia niveles
ms baj os. Por ejempl o, es posibl e refi nar el proceso monitorear sensores haci a ur.
DFD de nivel 2 como se muest ra en la figura 8.11. De nuevo, debe seal arse que se
mant i ene la cont inuidad del flujo de informacin ent re los niveles.
La refinacin de los DFD cont i na hast a que cada burbuj a realiza una sola fun-
cin; es decir, hast a que el proceso que represent a la burbuj a desempee una funcin
que podra i mpl ement arse con facilidad como un component e de programa. En e
captulo 9 se exami na un concept o, l l amado cohesin, con el cual se eval a la sim-
plicidad de una funcin dada. Por ahor a, se busca refinar los DFD hast a que cada
burbuj a t enga "un solo significado".
8.6.2 Creacin de un modelo de control del flujo
En muchos tipos de apl icaciones el model o de dat os y el di agrama de flujo de dat os
son t odo lo que se necesit a para obt ener una visin significativa de l os requisitos de'.
Formato
par a el
despl i egue
Gener ar
seal
de al ar ma
Informacin de configuracin
al ar ma
ubicacin
del sensor
' D a l o s
de al ar ma Evaluar
contra
ifiguracin
Nmer o
telefnico
ID, tipo
de sensor
Leer
sensores
Mar car
telfono
Estatus
el sensor
Datos
de confi guraci n
Informacin
del sensor
Tonos de nmeros
telefnicos
TM
PDF Editor
2 15
\ C" " 0 s e
s of t war e. Sin embar go, c omo ya se ha me nc i ona do, exi st e una cl ase muy gr ande de
apl i caci ones que e s t n gui adas por event os e n l ugar de dat os , que pr oducen i nfor-
maci n de cont rol e n l ugar de r epor t es o despl i egues, y que pr oces an i nf or maci n
con un especi al i nt er s por el t i empo y el r endi mi ent o. Di chas apl i caci ones r equi e-
r en apl i car el modelado de control del flujo, a d e m s del mode l a do del f l uj o de dat os.
Ya s e ha me nc i ona do que un event o o e l e me nt o de cont r ol s e i mpl ement a c o mo
un val or bool e a no (por ej empl o, ver dader o o fal so, encendi do o a pa ga do, I o 0) o
una lista di scr et a de condi ci ones (vaco, s at ur ado, lleno). En la sel ecci n de l os e ve n-
t os que s on candi dat os pot enci al es se s ugi er en l as si gui ent es di rect ri ces:
Hacer una lista de t odos l os s e ns or e s que el s of t war e "lee".
Listar t odas l as condi ci ones de i nt er r upci n.
Listar t odos l os "i nt er r upt or es" que ma ne j a un oper ador .
Listar t odas l as condi ci ones de dat os.
De a c ue r do con el anl i si s de s us t ant i vos y ver bos apl i cado a la nar r at i va de
pr oces ami ent o, revi sar t odos l os " el ement os de cont r ol " c o mo posi bi l i dades
de e nt r a da s y sal i das del cont rol de fl ujo.
Descri bi r el c ompor t a mi e nt o de un si st ema medi ant e la i dent i fi caci n de s us
es t ados ; det er mi nar el gr ado en el que se al canza cada est ado, y defi ni r l as
t r ans i ci ones ent r e l os es t ados .
Enf ocar s e en posi bl es omi s i ones un er r or muy c om n al especi f i car el
cont rol ; por ej empl o, se pue de pr egunt ar : "exi st e al guna ot r a ma ne r a de
al canzar est e e s t a do o sal i r de l?".
8.6.3 Especificacin de control
La especificacin de control (EC) r epr es ent a el c ompor t a mi e nt o del si st ema (en el
nivel des de el cual es t referi do) de dos ma ne r a s di f er ent es. 1 7 La EC cont i ene un di a-
gr a ma de es t ado que es una especi f i caci n secuenci a! del compor t ami ent o. Tambi n
pue de cont ener una t abl a de act i vaci n del pr ogr ama: una especi f i caci n combi na-
t ori a del compor t ami ent o.
En la figura 8. 12 s e mue s t r a un di agr ama de es t ado pr el i mi nar 1 8 par a el mode l o
de cont rol del fl ujo en el nivel I par a HogarSeguro. El di agr ama indica c mo r es ponde
el s i s t ema a di f er ent es e ve nt os c onf or me st e at r avi esa l os cuat r o e s t a dos def i ni dos
en es t e nivel. Al r evi sar el di agr ama de est ado, un i ngeni er o de s of t wa r e pue de
det er mi nar el c ompor t a mi e nt o del s i s t ema y, an m s i mpor t ant e, pue de encont r ar
si exi st en "hoyos" en el c ompor t a mi e nt o especi f i cado.
17 Despus, en este mismo captulo, se presenta notacin adicional para el modelado del comporta-
miento.
18 La notacin para el diagrama de estado se muestra aqu de conformidad con la notacin del UML.
En el anlisis estructurado se cuenta con un "diagrama de transicin de estado", pero el formato del
UML es superior en contenido y representacin de informacin
TM
PDF Editor
2 16
P A R T E D O S PRCTI CA DE LA INGENIERA DEL SOFTWARE
Diagrama de estado para la funcin de seguridad de HogarSeguro.
s ens or Di s par odo/
rei ni ci oTempori zador
Por ejempl o, el di agrama de est ado (figura 8.12) indica que las t ransiciones desc;
el est ado desocupado pueden ocurrir si el si st ema se reinicia, activa o apaga. Si el sis-
t ema se activa (es decir, se enci ende el si st ema de al arma) ocurre una transicir
hacia el est ado MonitoreoEstatusSistema, los mensaj es que se despl iegan cambi an,
como se muest ra, y se solicita el proceso SistemaControfyMonitoreo. Con el estadc
Monitoreo Stratus Sistema ocurren dos t ransiciones: 1) al desact ivar el si st ema se pre-
sent a una transicin de regreso al est ado desocupado; 2) cuando se di spara un ser -
sor ocurre una t ransicin hacia el est ado AccinEnAIarma. Durant e la revisin se
consi deran t odas las t ransi ci ones y el cont eni do de t odos los est ados.
HOGARSEGURO
Modelado del flujo de datos
H e s c e nar i o: Cubculo de Jamie,
! que ha concluido la ltima reunin par a la
-ecopiiacin de requisitos.
Los a c t o r e s : Jamie, Vinod y Ed, miembros del equi po
e ingeniera de! software de HogarSeguro.
La conversacin:
(Jamie ha bosquej ado los modelos que se muestran en
las figuras 8. 9, 8. 10, 8. 11 y 8. 12 y se los muestra a Ed y
Vinod).
J a mi e : Tom un curso de ingeniera del software en la
universidad, y ah aprendi estas cosas. El profesor di jo
TM
PDF Editor
CAPI TULO 8 MODELADO DEL ANLISIS 2 1 7
La EC descr i be e! c ompor t a mi e nt o del s i s t ema, per o n o br i nda i nf or maci n acer -
ca del t r abaj o i nt eri or de l os pr oces os que act i va. La not aci n de mode l a do que pr o-
por ci ona est a i nf or maci n se est udi a en la secci n 8. 6. 4.
8.6.4 Especificacin de proceso
La especificacin de proceso (EP) s e utiliza par a descri bi r t odos l os pr oces os del
mode l o de fl uj o q u e a pa r e c e n e n el nivel final de r ef i naci n. El cont eni do de la es pe-
ci fi caci n de pr oces o pue de incluir t ext o nar r at i vo, una descr i pci n en l enguaj e de
di s eo de pr ogr a ma s (LDP)19 del al gor i t mo del pr oceso, ecuaci ones mat emt i cas ,
t abl as, di agr amas o gr f i cas. Al pr opor ci onar una EP par a a c o mp a a r c a da bur buj a
en el model o de fl uj o, el i ngeni er o de s of t war e cr ea una "mi ni especi f i caci n" que
pue de servi r c o mo gu a par a el di s eo del c ompone nt e del s of t wa r e que i mpl e me n-
t ar el pr oces o.
Para i l ust rar el us o d e la EP, cons i dr es e la t r ans f or maci n procesamiento de con-
trasea r epr es ent ada en el model o de fl uj o par a HogarSeguro (figura 8. 10). La EP par a
est a f unci n podr a t omar la f or ma:
EP: procesami ento de contrasea (en el panel de control). La transformacin pro-
cesamiento de contrasea valida la contrasea en el panel de control para la funcin de se-
est un poco pas ado de moda, pero saben
Me ayuda a clarificar las cosas.
Es genial. Pero aqu no veo ninguna ciase ni ningn
esto es slo un model o de flujo con algunos
de comportamiento incluidas.
Entonces, estos DFD representan una visin E-P-
iottware, no?
E-P-S?
Entrada-proceso-salida. En realidad los DFD son
. . . Si los observas por un momento,
la forma en que los objetos fluyen a travs del
y cmo stos se transforman.
como si pudi ramos convertir cada burbuj a
componente ejecut abl e. . . al menos en el nivel ms
del DFD.
Esa es la mejor parte, s se puede. De hecho,
forma de traducir los DFD a una arquitectura
Ed: De verdad?
J a mi e : S, pero primero debemos desarrollar un modelo
de anlisis completo, y ste no lo es.
Vi nod: Bueno, es un primer paso. Pero vamos a tener
que abor dar elementos basados en clases y tambin
aspectos del comportamiento, aunque este di agr ama de
est ado hace al go de eso.
Ed: Tenemos mucho t rabaj o por hacer y no mucho
tiempo par a hacerlo,
(Doug -el gerente de ingeniera del soft ware- entra en el
cubculo.)
Do u g : Entonces, los primeros d as est arn dedi cados al
desarrollo del modelo de anlisis, eh?
Jami e (con orgullo): Ya comenzamos.
Do ug : Bien, tenemos mucho t r abaj o por hacer y no
mucho tiempo par a hacerlo.
(Los tres ingenieros de software se miran entre s y
sonren.)
19 El lenguaje de diseo de programas (LDP) mezcla la sintaxis del lenguaje de programacin con la
narrativa en texto para proporcionar detalles del diseo del procedimiento. El LDP se estudia en el
captulo 11.
TM
PDF Editor
gur i dad de HogarSeguro. El procesamiento de contrasea r eci be una c ont r a s e a de cuat r o
d gi t os a part i r de la f unci n de interaccin con el usuario. La c ont r a s e a s e c ompa r a pri-
me r o c on la c ont r a s e a maes t r a a l ma c e na d a en el s i s t ema. Si la c ont r a s e a ma e s t r a coi n-
ci de [ Mensaj e de ID vl i da = ver dader o] s e pa s a a la f unci n de mensaje y despliegue del
estatus. Si la c ont r a s e a ma e s t r a n o coi nci de, s e c ompa r a n l os cuat r o d gi t os con una t a-
bl a de c ont r a s e a s s e c unda r i a s ( st as s e pue de n as i gnar a i nvi t ados o t r abaj ador es que
neces i t an ent r ar en la c a s a c ua nd o el pr opi et ar i o n o est ) . Si la c ont r a s e a coi nci de con
al guna ent r ada de nt r o de la t abl a ( mens aj e de Id vl i da = ver dader o] , s e pa s a a la f unci n
de mensaje y despliegue del estatus. Si n o exi st e al guna coi nci denci a [ mens aj e de Id vl i da
= fal so], s e pas a a la f unci n de me n s a j e y despl i egue del es t at us .
Si e n e s t a e t a p a s e d e s e a n t e n e r d e t a l l e s a l g o r t mi c o s a d i c i o n a l e s , s e p o d r a i ncl ui r
t a mb i n u n a r e p r e s e n t a c i n e n l e n g u a j e d e d i s e o d e p r o g r a ma s c o m o p a r t e d e la
EP. Si n e mb a r g o , m u c h o s p r o f e s i o n a l e s de l s o f t wa r e c r e e n q u e l a v e r s i n e n LDP s e
p u e d e p o s p o n e r h a s t a q u e c o mi e n c e el d i s e o d e c o mp o n e n t e s .
r
HERRAMI ENTAS DE SOFTWARE
Anlisis estructurado
Obj e t i vo: Las herramientas del anlisis
estructurado ayudan a un ingeniero de software
a crear modelos de datos, modelos de flujo y modelos de
comportamiento de una manera que permita la
verificacin de la continuidad y la consistencia, as como
su fcil edicin y extensin. Los modelos creados utilizando
estas herramientas brindan al ingeniero de software una
visin de la representacin del anlisis y ayudan o
eliminar errores antes de que stos se propaguen en el
diseo o, aun peor, en la misma implementacin.
Me c ni c a : Las herramientas de esta categora utilizan un
"diccionario de dat os" como la base de datos central par a
la descripcin de todos los objetos de datos. Una vez que
las ent radas del diccionario estn definidas, pueden
crearse di agr amas de entidad-relacin y se pueden
desarrollar las jerarquas de objetos. Las caractersticas de
di agramaci n del flujo de datos permiten crear fcilmente
este modelo grfico y tambin proporciona caracteristicas
par a la creacin de especificaciones de control (EC) y
especificaciones de proceso (EP). Las herramientas de
anlisis tambin ayudan al ingeniero de software en la
creacin de modelos de comportamiento que usan los
di agramas de est ado como notacin operativa.
He r r a mi e nt a s r e pr e s e nt a t i v a s 2 0
AxiomSys, desarrol l ado por STG, Inc. (www.stgcase.com),
proporciona un paquet e completo de herramientas
par a el anlisis de la estructura que incluye extensiones
de Hartley-Pirbhai par a el model ado de sistemas en
tiempo real.
MacA&D, WinA&D, desarrollados por Excel Software
(www.excelsoftware.com), proporcionan un conjunto
de herramientas simples y bar at as par a el anlisis y el
diseo en mqui nas Mac y Windows.
MetaCASE Workbench, desarrol l ado por Met acase
Consulting (www.metacase.com) es una
metaherramienta utilizada par a definir un mtodo de
anlisis o diseo (incluido en anlisis estructurado): sus
conceptos, reglas, notaciones y generadores.
System Architect, desarrol l ado por Popkin Software
(www.popkin.com), proporciona un amplio rango de
herramientas de anlisis y diseo, incluye herramientas
par a el model ado de dat os y el anlisis estructurado.
20 Las her r ami ent as menci onadas aqu represent an una muest r a de est a cat egora. En la mayor a de
los casos l os nombr es est n regist rados por sus respect i vos desarrol l adores.
TM
PDF Editor
219
8 - F MO D E L A D O RASADO EN CLASES
| De q u
f o r m a s e
s t a n a s
i l a s ( l a s e s
[ * t f s i s c o m o
; d e l
i d e s o l u -
i *
Qu s e d e be ha c e r pa r a d e s a r r o l l a r l o s e l e m e n t o s ba s a d o s e n c l a s e s d e u n m o d e l o
d e a n l i s i s : c l a s e s y o bje t o s , a t r i bu t o s , o pe r a c i o n e s , pa q u e t e s , m o d e l o s CRC y d i a -
gr a m a s d e c o l a bo r a c i n ? La s s e c c i o n e s s i gu i e n t e s pr e s e n t a n u n a s e r i e d e d i r e c t r i c e s
i n f o r m a l e s q u e a yu d a r n a i d e n t i f i c a r l o s y r e pr e s e n t a r l o s .
8.7.1 Id e n t i f i c a c i n d e c l a s e s d e a n l i s i s
Al o bs e r va r e l i n t e r i o r d e u n a ha bi t a c i n s e ve r q u e e xi s t e u n c o n j u n t o d e o bj e t o s
f s i c o s q u e pu e d e n i d e n t i f i c a r s e , c l a s i f i c a r s e y d e f i n i r s e c o n f a c i l i d a d ( e n t r m i n o s d e
a t r i bu t o s y o pe r a c i o n e s ). Pe r o c u a n d o s e "o bs e r va " e l e s pa c i o d e l pr o bl e m a d e u n a
a pl i c a c i n d e s o f t wa r e , q u i z l a s c l a s e s ( y l o s o bje t o s ) s e a n m s d i f c i l e s d e c o m -
pr e n d e r .
"El pr o bl e m a r e a l m e n t e d i f c i l e s d e s c u br i r c u l e s s o n l o s o bj e t o s c o r r e c t o s [ c l a s e s ] e n pr i m e r l u ga r . "
Ca r i Ar gi l a
Se pu e d e i n i c i a r l a i d e n t i f i c a c i n d e c l a s e s a l e xa m i n a r e l e n u n c i a d o d e l pr o bl e -
m a o ( d e a c u e r d o c o n l a t e r m i n o l o g a a pl i c a d a pr e vi a m e n t e e n e s t e c a p t u l o ) a l r e a -
l i za r u n "a n l i s i s gr a m a t i c a l " s o br e l a s n a r r a t i va s d e s a r r o l l a d a s pa r a e l s i s t e m a q u e
s e va a c o n s t r u i r o d e l o s c a s o s d e u s o . La s c l a s e s s e d e t e r m i n a n a l s u br a ya r c a d a
s u s t a n t i vo e i n t r o d u c i n d o l a s e n u n a s i m pl e t a bl a . Lo s s i n n i m o s d e be n a n o t a r s e . Si
l a c l a s e s e r e q u i e r e pa r a i m pl e m e n t a r u n a s o l u c i n , e n t o n c e s e s pa r t e d e l e s pa c i o d e
s o l u c i n ; po r o t r o l a d o , s i u n a c l a s e s l o s e n e c e s i t a pa r a d e s c r i bi r u n a s o l u c i n e s
pa r t e d e l e s pa c i o d e l pr o bl e m a . Qu s e d e be bu s c a r d e s pu s d e q u e t o d o s l o s s u s -
t a n t i vo s ha n s i d o a i s l a d o s ? La s clases s e m a n i f i e s t a n e n u n a d e l a s s i gu i e n t e s f o r m a s :
Entidades externas ( po r e je m pl o , o t r o s s i s t e m a s , d i s po s i t i vo s , pe r s o n a s ) q u e
pr o d u c e n o c o n s u m e n i n f o r m a c i n q u e u s a r u n s i s t e m a ba s a d o e n c o m pu -
t a d o r a .
Cosas ( po r e j e m pl o , r e po r t e s , d e s pl i e gu e s , l e t r a s , s e a l e s ) q u e s o n pa r t e d e l
d o m i n i o d e l a i n f o r m a c i n pa r a e l pr o bl e m a .
Sucesos o eventos ( po r e je m pl o , u n a t r a n s f e r e n c i a d e pr o pi e d a d o l a c o n s e c u -
c i n d e u n a s e r i e d e m o vi m i e n t o s d e r o bo t ) q u e o c u r r e n d e n t r o d e l c o n t e xt o
d e l a o pe r a c i n d e l s i s t e m a .
Papeles ( po r e je m pl o , ge r e n t e , i n ge n i e r o , pe r s o n a l d e ve n t a s ) q u e d e s e m pe a n
pe r s o n a s q u e i n t e r a c t a n c o n e l s i s t e m a .
Unidades organizacionales ( po r e je m pl o , d i vi s i n , gr u po , e q u i po ) r e l e va n t e s
pa r a a l gu n a a pl i c a c i n .
Sitios ( po r e je m pl o , e l pi s o d e m a n u f a c t u r a o e l pu e r t o d e c a r ga ) q u e e s t a -
bl e c e n e l c o n t e xt o d e l pr o bl e m a y l a f u n c i n gl o ba l d e l s i s t e m a .
TM
PDF Editor
220 P A S T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
Estructuras ( po r e je m pl o , s e n s o r e s , ve h c u l o s d e c u a t r o r u e d a s o c o m pu t a d o r a s
q u e d e f i n e n u n a c l a s e d e o bje t o s o c l a s e s d e o bje t o s r e l a c i o n a d a s .
Es t a c a t e go r i za c i n e s u n a d e l a s m u c ha s q u e s e ha n pr o pu e s t o e n l a bi bl i o gr a f a
Po r e je m pl o , s i l o s d e s a r r o l l a d o r e s d e l s o f t wa r e pa r a u n s i s t e m a d e o bs e r va d o -1
m d i c a d e f i n e n u n o bje t o c o n e l n o m br e d e Imagenlnvertida o Inversi ndel magen
po d r a n e s t a r c o m e t i e n d o u n e r r o r s u t i l . La Imagen o bt e n i d a d e l s o f t wa r e po d r a
po r s u pu e s t o , s e r u n a c l a s e ( e s u n a c o s a i n t e gr a n t e d e l d o m i n i o d e l a i n f o r m a c i n
La i n ve r s i n d e l a i m a ge n e s u n a o pe r a c i n q u e s e a pl i c a a l a c l a s e . Pr o ba bl e m e n t e
l a inversin<) s e d e f i n i r a c o m o u n a o pe r a c i n pa r a l a c l a s e Imagen, pe r o n o s e e s t a -
bl e c e r a c o m o u n a c l a s e d i f e r e n t e pa r a c o n n o t a r "i n ve r s i n d e i m a ge n ". Co m o e s t a -
bl e c e Ca s hm a n [ CAS89] : "El o bje t i vo d e l a o r i e n t a c i n ha c i a l o s o bje t o s e s e n c a ps u -
l a r , pe r o a u n a s m a n t e n e r s e pa r a d o s , l o s d a t o s y l a s o pe r a c i o n e s s o br e l o s d a t o s '
Pa r a i l u s t r a r l a f o r m a e n q u e l a s c l a s e s d e a n l i s i s pu e d e n d e f i n i r s e d u r a n t e l a s
pr i m e r a s e t a pa s d e l m o d e l a d o , s e u t i l i za d e n u e vo l a f u n c i n d e s e gu r i d a d c e
HogarSeguro. En l a s e c c i n 8.6.1 s e r e a l i z u n "a n l i s i s gr a m a t i c a l " s o br e l a n a r r a t i -
va d e l pr o c e s a m i e n t o 22 pa r a l a f u n c i n d e s e gu r i d a d . Al e xt r a e r l o s s u s t a n t i vo s s e
pu e d e pr o po n e r u n a s e r i e d e c l a s e s po t e n c i a l e s :
Cl as e pot e nc i al
pr o pi e t a r i o
s e n s o r
pa n e l d e c o n t r o l
i n s t a l a c i n
s i s t e m a ( a l i a s s i s t e m a d e s e gu r i d a d )
n m e r o , t i po
c o n t r a s e a m a e s t r a
n m e r o t e l e f n i c o
e ve n t o d e l s e n s o r
a l a r m a a u d i bl e
s e r vi c i o d e m o n i t o r e o
Cl as i f i caci n g e n e r a l
pa pe l o e n t i d a d e xt e r n a
e n t i d a d e xt e r n a
o c u r r e n c i a
c o s a
n o o bje t o s , a t r i bu t o s d e l s e n s o r
c o s a
c o s a
o c u r r e n c i a
u n i d a d o r ga n i za c i o n a l o e n t i d a d e xt e r n a
La l i s t a po d r a e xt e n d e r s e ha s t a q u e t o d o s l o s s u s t a n t i vo s e n l a n a r r a t i va d e l pr o c e -
s a m i e n t o ha ya n s i d o c o n s i d e r a d o s . Obs r ve s e q u e c a d a e n t r a d a e n l a l i s t a ha s i d o
21 Ot r a c a t e go r i za c i n i m po r t a n t e l a c u a l d e f i n e e n t i d a d , f r o n t e r a y c l a s e s d e c o n t r o l a d o r s e e xa -
m i n a e n l a s e c c i n 8.7.4.
22 Es i m po r t a n t e n o t a r q u e e s t a t c n i c a d e be u s a r s e t a m bi n pa r a t o d o s l o s c a s o s d e u s o d e s a r r o l l a -
d o s c o m o pa r t e d e l a a c t i vi d a d pa r a l a r e c o pi l a c i n d e r e q u i s i t o s ( o bt e n c i n ). Es t o e s , l o s c a s o s d e
u s o pu e d e n a n a l i za r s e gr a m a t i c a l m e n t e pa r a e xt r a e r c l a s e s d e a n l i s i s po t e n c i a l e s .
TM
PDF Editor
221
l l a m a d a c o m o u n o bj e t o po t e n c i a l . Ca d a u n o d e e l l o s d e be c o n s i d e r a r s e a f o n d o
a n t e s d e t o m a r u n a d e c i s i n f i n a l .
[ _ Co m o s e
( ( t e r m i n a
i d a s e
"La s c l a s e s l u c ha n , a l gu n a s c l a s e s t r i u n f a n , o t r a s s o n e l i m i n a d a s . "
Ma o Z e d o n g
t e n u n a
i anl i s i s ?
Co a d y Yo u r d o n [ COA91 ] s u gi e r e n s e i s c a r a c t e r s t i c a s d e s e l e c c i n q u e s e d e be n
u s a r c u a n d o u n a n a l i s t a c o n s i d e r a c a d a c l a s e po t e n c i a l pa r a i n c l u i r l a s e n e l m o d e l o
d e a n l i s i s :
1. Informacin referida. La c l a s e po t e n c i a l s e r t i l d u r a n t e e l a n l i s i s s l o s i l a
i n f o r m a c i n a c e r c a d e e l l a d e be r e c o r d a r s e pa r a q u e e l s i s t e m a pu e d a f u n c i o -
n a r .
2. Servicios requeridos. La c l a s e po t e n c i a l d e be t e n e r u n c o n j u n t o d e o pe r a c i o n e s
i d e n t i f i c a bl e s q u e pu e d a n c a m bi a r e l va l o r d e s u s a t r i bu t o s d e a l gu n a m a n e r a .
3. Atributos mltiples. Du r a n t e e l a n l i s i s d e r e q u i s i t o s e l e n f o q u e d e be e s t a r e n
l a i n f o r m a c i n "i m po r t a n t e "; u n a c l a s e c o n u n s o l o a t r i bu t o pu e d e , d e he c ho ,
s e r t i l d u r a n t e e l d i s e o , pe r o pr o ba bl e m e n t e e s m e j o r r e pr e s e n t a r l a c o m o
u n a t r i bu t o d e o t r a c l a s e d u r a n t e l a a c t i vi d a d d e a n l i s i s .
4. Atributos comunes. Es po s i bl e d e f i n i r u n c o n j u n t o d e a t r i bu t o s pa r a l a c l a s e
po t e n c i a l , y e s t o s a t r i bu t o s pu e d e n a pl i c a r s e e n t o d a s l a s i n s t a n c i a s d e l a
c l a s e .
5. Operaciones comunes. Es po s i bl e d e f i n i r u n c o n j u n t o d e o pe r a c i o n e s pa r a l a
c l a s e po t e n c i a l , y e s t a s o pe r a c i o n e s pu e d e n a pl i c a r s e e n t o d a s l a s i n s t a n c i a s
d e l a c l a s e .
6. Requisitos esenciales. La s e n t i d a d e s e xt e r n a s q u e a pa r e c e n e n e l e s pa c i o d e l
pr o bl e m a , y q u e pr o d u c e n o c o n s u m e n i n f o r m a c i n e s e n c i a l pa r a l a o pe r a -
c i n d e c u a l q u i e r s o l u c i n pa r a e l s i s t e m a , s e d e f i n i r n c a s i s i e m pr e c o m o
c l a s e s e n e l m o d e l o d e r e q u i s i t o s .
Co n s i d e r a r l a u n a c l a s e l e g t i m a pa r a i n c l u i r l a e n e l m o d e l o d e r e q u i s i t o s r e q u i e r e
q u e u n a c l a s e po t e n c i a l s a t i s f a ga t o d a s ( o c a s i t o d a s ) e s t a s c a r a c t e r s t i c a s . La d e c i -
s i n d e i n c l u i r c l a s e s po t e n c i a l e s e n e l m o d e l o d e a n l i s i s e s a l go s u bje t i va , y u n a
e va l u a c i n po s t e r i o r pu e d e o c a s i o n a r q u e s e d e s c a r t e o r e i n s t a l e u n a c l a s e . Si n
e m ba r go , e l pr i m e r pa s o d e l m o d e l a d o ba s a d o e n c l a s e s e s l a d e f i n i c i n d e c l a s e s , y
s e d e be n t o m a r d e c i s i o n e s ( i n c l u s o s u bje t i va s ). Co n e s t o e n m e n t e , s e a pl i c a n l a s
c a r a c t e r s t i c a s d e s e l e c c i n a l a l i s t a d e c l a s e s po t e n c i a l e s d e HogarSeguro:
Clase potencial
pr o pi e t a r i o
s e n s o r
pa n e l d e c o n t r o l
Nmero de caracterstica que apl i ca
r e c ha za d a ; 1 y 2 f a l l a n a u n q u e a pl i c a 6
a c e pt a d a : t o d a s a pl i c a n
TM
PDF Editor
222
P A E T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
i n s t a l a c i n
s i s t e m a ( a l i a s f u n c i n d e s e gu r i d a d )
n m e r o , t i po
c o n t r a s e a m a e s t r a
n m e r o t e l e f n i c o
e ve n t o d e l s e n s o r
a l a r m a a u d i bl e
s e r vi c i o d e m o n i t o r e o
r e c ha za d a :
a c e pt a d a : t o d o s a pl i c a n
r e c ha za d a : f a l l a 3, a t r i bu t o s d e l s e n s o r
r e c ha za d a : f a l l a 3
r e c ha za d a : f a l l a 3
a c e pt a d a : a pl i c a n 2, 3, 4, 5, 6
r e c ha za d a : I y 2 f a l l a n a u n q u e a pl i c a 6
Cl f AVE
l o s a t r i bu t o s s o n e l
c o n ju n t o d e o bj e t o s d e
d a t o s q u e d e f i n e n po r
c o m pl e t o l a c l a s e
d e n t r o d e l c o n t e xt o d e l
pr o bl e m a .
Se d e be s e a l a r q u e 1) l a l i s t a a n t e r i o r n o e s t c o m pl e t a ( s e t e n d r a n q u e a gr e ga r
s e s a d i c i o n a l e s pa r a t e r m i n a r e l m o d e l o ); 2) a l gu n a s d e l a s c l a s e s po t e n c i a l e s i
za d a s s e c o n ve r t i r n e n a t r i bu t o s pa r a l a s c l a s e s a c e pt a d a s ( po r e je m pl o , n m e r o
t i po s o n a t r i b u t o s d e s e n s o r , y c o n t r a s e a m a e s t r a y n m e r o t e l e f n i c o s e p u e d e n c o n
t i r e n a t r i bu t o s d e si st ema) ; 3) l a e xi s t e n c i a d e e n u n c i a d o s d i f e r e n t e s d e l pr o b
po d r a o c a s i o n a r d e c i s i o n e s d i s t i n t a s d e "a c e pt a c i n o r e c ha zo " ( po r e je m pl o , s i
pr o pi e t a r i o t u vi e r a u n a c o n t r a s e a d i f e r e n t e o s i pu d i e r a i d e n t i f i c a r s e po r s u vo z
c l a s e Propi et ari o s a t i s f a r a l a s c a r a c t e r s t i c a s 1 y 2 y s t a ha br a s i d o a c e pt a d a
8.7.2 Es pe c i f i c a c i n d e a t r i bu t o s
Lo s a t r i bu t o s d e s c r i be n u n a c l a s e q u e ha s i d o s e l e c c i o n a d a pa r a i n c l u i r l a e n
m o d e l o d e a n l i s i s . En e s e n c i a , l o s a t r i bu t o s s o n l o s q u e d e f i n e n l a c l a s e , l o c u a l
r i f i c a q u s i gn i f i c a l a c l a s e e n e l c o n t e xt o d e l e s pa c i o d e l pr o bl e m a .
En e l d e s a r r o l l o d e u n c o n j u n t o d e a t r i bu t o s s i gn i f i c a t i vo pa r a u n a c l a s e d e a n l i -
s i s u n i n ge n i e r o d e s o f t wa r e pu e d e e s t u d i a r d e n u e vo u n c a s o d e u s o y s e l e c c i n 3-
a q u e l l a s "c o s a s " q u e "pe r t e n e c e n " d e m a n e r a r a zo n a bl e a l a c l a s e . Ad e m s , s e d e be
c o n t e s t a r l a s i gu i e n t e pr e gu n t a pa r a c a d a c l a s e : Cu l e s e l e m e n t o s d e d a t o s ( c o m
pu e s t o s o e l e m e n t a l e s ) d e f i n e n e s t a c l a s e e n e l c o n t e xt o d e l pr o bl e m a ?
Es t o s e i l u s t r a c o n s i d e r a n d o l a c l a s e s i s t e ma d e f i n i d a pa r a HogarSeguro. Se h
m e n c i o n a d o q u e e l pr o pi e t a r i o pu e d e c o n f i gu r a r l a f u n c i n d e s e gu r i d a d pa r a r e f l e -
ja r l a i n f o r m a c i n d e l s e n s o r , i n f o r m a c i n d e l a r e s pu e s t a d e a l a r m a , i n f o r m a c i n d e
l a a c t i va c i n / d e s a c t i va c i n , i n f o r m a c i n d e l a i d e n t i f i c a c i n , y a s s u c e s i va m e n t e
Es t o s e l e m e n t o s d e d a t o s c o m pu e s t o s s e pu e d e n r e pr e s e n t a r d e l a s i gu i e n t e m a n e r a
i n f o r m a c i n d e i d e n t i f i c a c i n = ID d e l s i s t e m a + ve r i f i c a c i n d e l n m e r o t e l e f n i c o + e s t a t u s
d e l s i s t e m a
i n f o r m a c i n d e l a r e s pu e s t a d e a l a r m a = t i e m po d e r e t r a s o + n m e r o t e l e f n i c o
i n f o r m a c i n d e l a a c t i va c i n /d e s a c t i va c i n = c o n t r a s e a m a e s t r a + n m e r o d e i n t e n t o s pe r m i -
s i bl e s + c o n t r a s e a t e m po r a l
Al gu n o s d e l o s d a t o s a l a d e r e c ha d e l s i gn o d e i gu a l po d r a n r e f i n a r s e ha s t a u n n i ve l
e l e m e n t a l , pe r o pa r a l o s pr o ps i t o s d e e s t e c a p t u l o c o n s t i t u ye n u n a l i s t a r a zo n a bl e
d e a t r i bu t o s pa r a l a c l a s e s i s t e ma ( pa r t e s o m br e a d a d e l a f i gu r a 8.13).
TM
PDF Editor
C A P T U L O 8 MODELADO DEL ANLISIS 223
f a K U J o f .
2 definen los
pora uno
m sis, el
xbe estar en
nto
problema
tos comporto-
squeridos
a y k r mt a -
Lo s s e n s o r e s s o n pa r t e d e l s i s t e m a gl o ba l d e HogarSeguro, y a u n a s n o e s t n e n -
l i s t a d o s c o m o e l e m e n t o s d e d a t o s o c o m o a t r i bu t o s e n l a f i gu r a 8.13. Ya s e ha d e f i -
n i d o s e ns or c o m o u n a c l a s e , y va r i o s o bj e t o s d e s e ns or s e a s o c i a r n c o n l a c l a s e
si st ema. En ge n e r a l , s e e vi t a l a d e f i n i c i n d e u n e l e m e n t o c o m o u n a t r i bu t o s i m s
d e u n o d e l o s e l e m e n t o s s e a s o c i a r c o n l a c l a s e .
8.7.3 De f i n i c i n d e o pe r a c i o n e s
La s o pe r a c i o n e s d e f i n e n e l c o m po r t a m i e n t o d e u n o bje t o . Au n q u e e xi s t e n m u c ho s
t i po s d i s t i n t o s d e o pe r a c i o n e s , s t a s s e pu e d e n d i vi d i r , po r l o ge n e r a l , e n t r e s gr a n -
d e s c a t e go r a s : 1) o pe r a c i o n e s q u e m a n i pu l a n l o s d a t o s d e a l gu n a m a n e r a ( po r e j e m -
pl o , a l a gr e ga r , bo r r a r , r e f o r m a t e a r , s e l e c c i o n a r ), 2) o pe r a c i o n e s q u e r e a l i za n u n
c m pu t o , 3) o pe r a c i o n e s q u e pr e gu n t a n a c e r c a d e l e s t a d o d e u n o bje t o , y 4) o pe r a -
c i o n e s q u e m o n i t o r e a n u n o bj e t o pa r a l a o c u r r e n c i a d e u n e ve n t o d e c o n t r o l . Es t a s
f u n c i o n e s s e e j e c u t a n a l o pe r a r s o br e a t r i bu t o s o a s o c i a c i o n e s ( s e c c i n 8.7.5). Po r l o
t a n t o , u n a o pe r a c i n d e be t e n e r "c o n o c i m i e n t o " d e l a n a t u r a l e za d e l o s a t r i bu t o s y
a s o c i a c i o n e s d e l a c l a s e .
Co m o u n a pr i m e r a i t e r a c i n e n l a o bt e n c i n d e u n c o n j u n t o d e o pe r a c i o n e s pa r a
u n a c l a s e d e a n l i s i s , e l a n a l i s t a pu e d e e s t u d i a r o t r a ve z l a n a r r a t i va d e u n pr o c e s a -
m i e n t o ( o c a s o d e u s o ) y s e l e c c i o n a r a q u e l l a s o pe r a c i o n e s q u e pe r t e n e zc a n d e
m a n e r a r a zo n a bl e a l a c l a s e . Es t o s e l o gr a e s t u d i a n d o d e n u e vo e l a n l i s i s gr a m a t i -
c a l y a i s l a n d o l o s ve r bo s . Al gu n o s d e e s t o s ve r bo s s e r n o pc i o n e s l e g t i m a s y po d r n
c o n e c t a r s e c o n f a c i l i d a d a u n a c l a s e e s pe c f i c a . Po r e je m pl o , e n l a n a r r a t i va d e l pr o -
c e s a m i e n t o pr e s e n t a d a pr r a f o s a t r s e n e s t e c a p t u l o , s e o bs e r va q u e "a l s e n s o r s e
l e a s i gn a u n n m e r o y u n t i po " o "s e pr o gr a m a u n a c o n t r a s e a m a e s t r a pa r a ha bi l i -
t a r y d e s ha bi l i t a r e l s i s t e m a ". Es t a s f r a s e s i n d i c a n a l gu n o s he c ho s :
Si stema
ID s i s t e m a
ve r i f i c a c i n Nm e r o Te l e f n i c o
Es t a f u s s i s t e m a
Ti e m po r e t r a s o
Nu m e r t e l e f n i c o
Co n t r a s e a m a e s t r a
Co n t r a s e a t e m po r a l
Nm e r o d e i n t e n t o s
pr o gr a m a r ( )
d e s pl e ga r ! )
r e i n i c i a r ( )
bu s c a r ( )
m o d i f i c a r !)
l l a m a r ( )
TM
PDF Editor
Qu e u n a o pe r a c i n d e asignar<) e s r e l e va n t e pa r a l a c l a s e sensor.
Qu e u n a o pe r a c i n d e programar, () e s t e n c a ps u l a d a po r l a c l a s e si stema
Qu e habilitar() y deshabilitar() s o n o pe r a c i o n e s q u e s e a pl i c a n a l a c l a s e
si st ema
En u n a i n ve s t i ga c i n po s t e r i o r t a l ve z l a o pe r a c i n programarf) s e a d i vi d i d a e n J
s e r i e d e s u bo pe r a c i o n e s m s e s pe c f i c a s q u e s e r e q u i e r e n pa r a c o n f i gu r a r e l s i s t e -J
Po r e je m pl o , programarf) i m pl i c a l a e s pe c i f i c a c i n d e n m e r o s t e l e f n i c o s , l a c c "l
gu r a c i n d e c a r a c t e r s t i c a s d e l s i s t e m a ( c o m o a l c r e a r l a t a bl a d e s e n s o r e s , a l i r r J
d u c i r l a s c a r a c t e r s t i c a s d e l a a l a r m a ) y l a i n t r o d u c c i n d e c o n t r a s e a ( s ). Si n e m :a (
go , po r a ho r a programar() s e e s pe c i f i c a c o m o u n a s o l a o pe r a c i n .
Modelos de clase
El e s c e na r i o : Cu b c u l o d e Ed , a l
c o m e n za r e l m o d e l a d o d e l a n l i s i s .
Los a c t o r e s : Ja m i e , Vi n o d y Ed , m i e m br o s d e l e q u i po
d e i n ge n i e r a d e l s o f t wa r e d e HogarSeguro.
La convers aci n:
( Ed ha e s t a d o t r a ba j a n d o e n l a e xt r a c c i n d e c l a s e s o
pa r t i r d e l a pl a n t i l l a d e c a s o d e u s o pa r a e l "Ac c e s o a
l a c ma r a de vi gi l anci a- des pl i egue de vi st as
d e c ma r a " {pr e s e n t a d o e n u n r e c u a d r o a n t e r i o r e n
e s t e c a p t u l o ] y e s t m o s t r a n d o a s u s c o l e ga s l a s c l a s e s
q u e ha e xt r a d o .
Ed: En t o n c e s , c u a n d o e l pr o pi e t a r i o q u i e r e e s c o ge r u n a
c m a r a , l o e l l a d e be e l e gi r l a d e u n pl a n o d e pl a n t a . He
d e f i n i d o u n a c l a s e l l a m a d a Pl a no de Pl a nt a . Aq u e s t
e l d i a gr a m a . ' ' f '
( To d o s m i r a n l a f i gu r a 8. 14. ) 1 1 ,
Jami e : En t o n c e s Pl a no de Pl a nt a e s u n a c l a s e q u e s e
u n e a l a s pa r e d e s q u e e s t n c o m pu e s t a s po r s e gm e n t o s
d e pa r e d , pu e r t a s y ve n t a n a s , y t a m bi n l a s c m a r a s ;
e s o e s l o q u e s i gn i f i c a n e s a s l n e a s e t i q u e t a d a s , n o ?
Ed: S , e s a s l n e a s s e l l a m a n "a s o c i a c i o n e s ". La s c l a s e s
e s t n a s o c i a d a s e n t r e s d e a c u e r d o c o n l a s a s o c i a c i o n e s
a j e l e s he m o s t r a d o , [ l a s a s o c i a c i o n e s s e s t u d i a n e n l a
s e c c i n 8. 7. 5. ] f ,
Vi nod: En t o n c e s e l pl a n o d e pl a n t a r e a l e s t he c ho d e
paredes y c o n t i e n e c m a r a s y s e n s o r e s c o l o c a d o s d e n t r o
d e e s t a s pa r e d e s . Cm o s a be e l pl a n o d e pl a n t a d n c -e
c o l o c a r e s o s o bje t o s ? |
Ed: No l o s a be , pe r o l a s o t r a s c l a s e s s . Mi r e n l o s
a t r i bu t o s d e a ba j o , d i ga m o s , S e g me n t o s d e P a r e d :
c u a l e s s e u s a n pa r a c o n s t r u i r u n a pa r e d . El s e gm e n t o d e
pa r e d t i e n e u n a s c o o r d e n a d a s d e i n i c i o y f i n a l , y l a
o pe r a c i n d e dibujo(] ha c e e l r e s t o .
J a mi e ; Y l o m i s m o pa s a pa r a l a s pu e r t a s y ve n t a n a s .
Pa r e c e c o m o s i l a s c m a r a s t u vi e r a n u n o s po c o s d e
a t r i bu t o s e xt r a . | |
Ed: S , l o s n e c e s i t o pa r a po d e r d a r l a i n f o r m a c i n d e l
m o vi m i e n t o y e l a c e r c a m i e n t o .
Vi nod: Te n go u n a pr e gu n t a . Po r q u l a c m a r a t i e n e
u n a ID, pe r o l a s o t r a s c l a s e s n o ?
Ed: Va m o s a n e c e s i t a r i d e n t i f i c a r c a d a c m a r a pa r a
pr o ps i t o s d e l d e s pl i e gu e .
J a mi e : Ti e n e s e n t i d o pa r a m , pe r o t e n go a l gu n a s o t r a s
pr e gu n t a s , ( ja m i e ha c e pr e gu n t a s q u e r e s u l t a n e n
m o d i f i c a c i o n e s m e n o r e s .)
Vi no d: Ti e n e s t a r je t a s CRC pa r a c a d a u n a d e e s t a s
c l a s e s ? Si e s a s , d e be m o s s e gu i r l a s , s l o ha y q u e e s t a r
s e gu r o s d e q u e n o s e ha o m i t i d o n a d a .
Ed: No e s t o y s e gu r o d e c m o ha c e r l a s .
Vi nod: No e s d i f c i l , y l o s r e s u l t a d o s s o n m u y bu e n o s .
Le s m o s t r a r . ,
TM
PDF Editor
C A P I T U L O 8 MODELADO DEL ANLISIS
225
a de
para
^Planta
el
en el
Pl a n o d e Pl a n t a
t i po
n o m br e
Di m e n s i o n e s e xt e r n a s
d e t e r m i n a r Ti po ( )
po s i c i o n a r Pl a n o d e Pl a n t a ) )
e s c a l a r )
c a m bi a r c o l o r ) )
Se u bi c a d e n t r o d e .
C m a r a
r
u bi c a c i n
c a m po d e Vi s i n
An gu l o d e To m o
Co n f i gu r a c i n
Ac e r c a m i e n t o
Es pa r t e d e
Par d
t i po
Di m e n s i o n e s pa r e d
d e t e r m i n a r T
c a l c u l a r Di m
P 0
e n s i o n e s ( )
Segment o
de Pared
t i po
Co o r d e n a d a s i n i c i o
Co o r d e n a d a s f i n a l
Si gu i e n t e Se g m e n t
Pa r e d
d e t e r m m a r T po ( )
d i bu j a r
Ventana
t i po
Si gu e n t e Ve n t a n a
d e t e r m i n a r Ti po {)
d i bu j a r
Ve n t a n a
t i po
Si gu i e n t e Pu e r t a
d e t e r m i n a r Ti po f )
d i bu j a r
8.7.4 Mo d e l a d o d e Cl a s e -Re s po n s a bi l i d a d -Co l a bo r a d o r ( CRC)
El m o d e l a d o de Clase- Responsabilidad- Colaborador (CRC) [ WIR90] pr o po r c i o n a u n
m e d i o s i m pl e pa r a i d e n t i f i c a r y o r ga n i za r l a s c l a s e s r e l e va n t e s pa r a l o s r e q u i s i t o s d e l
s i s t e m a o pr o d u c t o . Am bl e r [ AMB95] d e s c r i be e l m o d e l a d o CRC d e l a s i gu i e n t e
f o r m a :
Un m o d e l o CRC e n r e a l i d a d e s u n a c o l e c c i n d e t a r j e t a s n d i c e e s t n d a r q u e r e pr e s e n t a n
c l a s e s . La s t a r j e t a s s e d i vi d e n e n t r e s s e c c i o n e s . A l o l a r go d e l bo r d e s u pe r i o r d e l a t a r je t a
s e e s c r i be e l n o m br e d e l a c l a s e . En e l c u e r po d e l a t a r je t a s e l i s t a n l a s r e s po n s a bi l i d a d e s
d e l a c l a s e a l a i zq u i e r d a y l o s c o l a bo r a d o r e s a l a d e r e c ha .
En r e a l i d a d , e l m o d e l o CRC pu e d e u t i l i za r t a r j e t a s n d i c e r e a l e s o vi r t u a l e s . El o bje t i -
vo e s d e s a r r o l l a r u n a r e pr e s e n t a c i n o r ga n i za d a d e l a s c l a s e s . La s responsabilidades
TM
PDF Editor
s o n l o s a t r i bu t o s y l a s o pe r a c i o n e s r e l e va n t e s pa r a l a c l a s e . Di c ho d e m a n e r a
s i m pl e , u n a r e s po n s a bi l i d a d e s "c u a l q u i e r c o s a q u e l a c l a s e s a be o ha c e " [ AMB9F1
Lo s colaboradores s o n a q u e l l a s c l a s e s q u e s e r e q u i e r e n pa r a q u e u n a c l a s e r e c i ba a
i n f o r m a c i n n e c e s a r i a pa r a c o m pl e t a r u n a r e s po n s a bi l i d a d . En ge n e r a l , u n a c o l a bc l
r a c i n i m pl i c a ya s e a u n a s o l i c i t u d d e i n f o r m a c i n o l a s o l i c i t u d d e a l gu n a a c c i n
"Un o d e l o s pr o ps i t o s d e l o s t a r je t a s CRC e s f o l l o r o l i n i c i o , f a l l a r c o n s t a n t e m e n t e y ( o l l a r s i n q u e s e a c a r o . Es m u c ho
m s ba r a t o t i r a r u n bu l t o d e t a r je t a s q u e r e o r ga n i za r u n a gr a n c a n t i d a d d e c d i go f u e n t e . "
C Ho r s t m u n r
En w w w .
t heuml coi e. com/
e n c o n t r a r s e u n a
c a s o s .
En l a f i gu r a 8.15 s e i l u s t r a u n a t a r je t a n d i c e CRC s i m pl e pa r a l a c l a s e Pl anode-
pl anta. La l i s t a d e r e s po n s a bi l i d a d e s q u e s e m u e s t r a e n l a t a r je t a CRC e s pr e l i m i n a r
y e s t s u j e t a a a d i c i o n e s o m o d i f i c a c i o n e s . La s c l a s e s Pared y Cmara s e a n o t a r
e n s e gu i d a d e l a r e s po n s a bi l i d a d q u e r e q u e r i r s u c o l a bo r a c i n .
Cl as es . La s d i r e c t r i c e s bs i c a s pa r a i d e n t i f i c a r c l a s e s y o bj e t o s ya s e ha n pr e s e -
t a d o e n e s t e m i s m o c a p t u l o . La t a xo n o m a d e l o s t i po s d e c l a s e s q u e s e pr e s e n t e r
l a s e c c i n 8.7.1 s e pu e d e e xt e n d e r c o n s i d e r a n d o l a s s i gu i e n t e s c a t e go r a s :
Clases de entidad, t a m bi n l l a m a d a s c l a s e s d e modelo o negocios, s e e xt r a e n
d e m a n e r a d i r e c t a d e l e n u n c i a d o d e l pr o bl e m a ( po r e je m pl o , Pl anodepl ant a
y Sensor) . De m a n e r a t pi c a , e s t a s c l a s e s r e pr e s e n t a n c l a s e s q u e s e a l m a c e -
n a r n e n u n a ba s e d e d a t o s y q u e pe r s i s t e n d u r a n t e l a a pl i c a c i n ( a m e n o s
q u e s e bo r r e n d e m a n e r a e s pe c f i c a ).
Clases de frontera. Se u t i l i za n pa r a c r e a r l a i n t e r f a z ( po r e j e m pl o , pa n t a l l a s
i n t e r a c t i va s o r e po r t e s i m pr e s o s ) q u e e l u s u a r i o ve y c o n l a c u a l i n t e r a c t a
c u a n d o s e u t i l i za e l s o f t wa r e . La s c l a s e s d e e n t i d a d c o n t i e n e n i n f o r m a c i n
Una carta
ndice del
modelo CRC.
i
|
i
- Cl a s e : Pl a n o d e Pl a n t a
- De s c r i pc i n

Re s po n s a bi l i d a d
Co l a bo r a d o r
De f i n e e l n o m br e / t i po d e l pl a n o d e pl a n t a
Ma n e j a l a po s i c i n d e l pl a n o d e pl a n t a
Es c a l a e l pl a n o d e pl a n t a pa r a s u d e s pl i e gu e
Es c a l a e l pl a n o d e pl a n t a pa r a s u d e s pl i e gu e
In c o r po r a pa r e d e s , pu e r t a s y ve n t a n a s Pa r e d
Mu e s t r a l a po s i c i n d e l a s c m a r a s d e vi d e o Cm a r a
TM
PDF Editor
i m po r t a n t e pa r a l o s u s u a r i o s , pe r o n o s e d e s pl i e ga n a s m i s m a s . La s c l a s e s
d e f r o n t e r a e s t n d i s e a d a s c o n l a r e s po n s a bi l i d a d d e m a n e j a r l a f o r m a e n
q u e l o s o bj e t o s d e e n t i d a d s e pr e s e n t a n a l o s u s u a r i o s . Po r e j e m pl o , u n a c l a s e
d e f r o n t e r a l l a m a d a Vent anadeCmara t e n d r a l a r e s po n s a bi l i d a d d e
d e s pl e ga r l a s a l i d a d e u n a c m a r a d e vi gi l a n c i a pa r a e l s i s t e m a HogarSeguro.
La s clases de controlador m a n e j a n u n a "u n i d a d d e t r a ba j o " [ UML03] d e s d e e l
i n i c i o ha s t a e l f i n a l . Es t o e s , l a s c l a s e s d e c o n t r o l a d o r s e pu e d e n d i s e a r pa r a
m a n e j a r 1) l a c r e a c i n o a c t u a l i za c i n d e l o s o bj e t o s d e e n t i d a d ; 2) l a i n m e -
d i a t e z d e o bj e t o s d e f r o n t e r a c o n f o r m e s t o s o bt i e n e n i n f o r m a c i n d e o bj e t o s
d e e n t i d a d ; 3) l a c o m u n i c a c i n c o m pl e j a e n t r e c o n j u n t o s d e o bj e t o s ; y 4) l a
va l i d a c i n d e d a t o s c o m u n i c a d o s e n t r e l o s o bj e t o s o e n t r e e l u s u a r i o y l a a pl i -
c a c i n . En ge n e r a l , l a s c l a s e s d e c o n t r o l a d o r n o s e c o n s i d e r a n s i n o ha s t a q u e
ha c o m e n za d o e l d i s e o .
"Lo s o bje t o s pu e d e n c l a s i f i c a r *
n y l o s q u e s e pi e r
d e m a n e r a c i e n t f i c a e n t r e s gr a n d e s c a t e go r a s : l o s
Am "
q u e n o f u n c i o n a n , l o s q u e s e
UoawlHflUlKf
pu e d e n c l a s i f i c a r *
n y l o s q u e s e pi e r Bol!.
Ru s s e l l Ba k e r
| h s
' r e c t r i c e s
n a r s e
i k a s i gn a c i n
d a -
i s I B d a s e s ?
Responsabi l i dades . En l a s s e c c i o n e s 8.7.2 y 8.7.3 s e ha n pr e s e n t a d o l a s d i r e c t r i -
c e s bs i c a s pa r a i d e n t i f i c a r r e s po n s a bi l i d a d e s ( a t r i bu t o s y o pe r a c i o n e s ). Wi r f s -Br o c k
y s u s c o l e ga s [ WIR90] s u gi e r e n c i n c o d i r e c t r i c e s pa r a d e t e r m i n a r l a s r e s po n s a bi l i d a -
d e s d e l a s c l a s e s :
1. La i nt el i genci a del s i s t ema s e de be distribuir ent re l as cl as es para
abordar de mej or manera l as ne c e s i dade s del probl ema Ca d a a pl i c a -
c i n a ba r c a u n c i e r t o gr a d o d e i n t e l i ge n c i a ; e s t o e s , l o q u e e l s i s t e m a s a be y
pu e d e ha c e r . Es t a i n t e l i ge n c i a pu e d e d i s t r i bu i r s e e n t r e l a s c l a s e s d e va r i a s
m a n e r a s d i f e r e n t e s . La s c l a s e s "po c o i n t e l i ge n t e s " ( a q u e l l a s q u e t i e n e n m e n o s
r e s po n s a bi l i d a d e s ) pu e d e n m o d e l a r s e pa r a a c t u a r a l s e r vi c i o d e u n a s c u a n t a s
c l a s e s "m u y i n t e l i ge n t e s " ( l a s q u e t i e n e n m u c ha s r e s po n s a bi l i d a d e s ). Au n q u e
e s t e e n f o q u e ha c e q u e e l f l u jo d e c o n t r o l e n u n s i s t e m a s e a d i r e c t o , t i e n e u n a s
c u a n t a s d e s ve n t a j a s : a) c o n c e n t r a t o d a l a i n t e l i ge n c i a e n u n a s po c a s c l a s e s , l o
q u e d i f i c u l t a l o s c a m bi o s , y b) t i e n d e a r e q u e r i r m s c l a s e s , y po r e n d e , u n m e -
jo r e s f u e r zo d e d e s a r r o l l o .
Si l a i n t e l i ge n c i a d e l s i s t e m a s e d i s t r i bu ye c o n m a yo r a m pl i t u d e n t r e l a s
c l a s e s d e u n a a pl i c a c i n , c a d a o bj e t o s a be y ha c e s l o u n a s c u a n t a s c o s a s ( l a s
c u a l e s , po r l o ge n e r a l , s o n bi e n e n f o c a d a s ), y l a c o he s i n d e l s i s t e m a m e j o r a .
Lo a n t e r i o r a u m e n t a l a f a c i l i d a d d e m a n t e n i m i e n t o d e l s o f t wa r e y r e d u c e e l
i m pa c t o d e l o s e f e c t o s c o l a t e r a l e s d e bi d o s a l c a m bi o .
Pa r a d e t e r m i n a r s i l a i n t e l i ge n c i a d e l s i s t e m a e s t bi e n d i s t r i bu i d a l a s r e s -
po n s a bi l i d a d e s a n o t a d a s e n c a d a t a r j e t a n d i c e d e l m o d e l o CRC d e be n e va -
l u a r s e y a s c o m pr o ba r s i a l gu n a c l a s e t i e n e u n a l i s t a d e r e s po n s a bi l i d a d e s
TM
PDF Editor
228 P A R T E D O S PRCTICA DE LA INGENIERIA D A SOFTWARE
d e m a s i a d o l a r ga . Es t o i n d i c a u n a c o n c e n t r a c i n d e i n t e l i ge n c i a .23 Ad e m s , l a s
r e s po n s a bi l i d a d e s pa r a c a d a c l a s e d e be n m o s t r a r e l m i s m o gr a d o d e a bs t r a c t i m
2. Cada responsabi l i dad debe es t abl ecers e tan general c o mo s e a posi -
ble. Es t a d i r e c t r i z i m pl i c a q u e l a s r e s po n s a bi l i d a d e s ge n e r a l e s ( t a n t o a t r i bu -
t o s c o m o o pe r a c i o n e s ) d e be n e s t a r e n l a pa r t e a l t a d e l a je r a r q u a d e l a c l a s e
( d e bi d o a q u e s o n ge n r i c a s s o n a pl i c a bl e s e n t o d a s l a s s u bc l a s e s ).
3. La i nformaci n y el comport ami ent o rel aci onado con ella deben
dent ro de la mi s ma cl ase. Co n e s t o s e l o gr a e l pr i n c i pi o OO l l a m a d o en
sulacin. Lo s d a t o s y l o s pr o c e s o s q u e m a n i pu l a n l o s d a t o s d e be n e m pa q u e -
t a r s e c o m o u n a u n i d a d c o he s i va .
4. La i nformaci n relativa a una cos a debe l ocal i zarse con una sol a
cl ase, no distribuirse entre muchas de ellas. Un a s o l a c l a s e d e be t o m a r
l a r e s po n s a bi l i d a d d e a l m a c e n a r y m a n i pu l a r u n t i po e s pe c f i c o d e i n f o r m a -
c i n . En ge n e r a l , e s t a r e s po n s a bi l i d a d n o s e pu e d e c o m pa r t i r e n t r e va r i a s c l a -
s e s . Si l a i n f o r m a c i n s e d i s t r i bu ye , e l s o f t wa r e s e vu e l ve m s d i f c i l d e
m a n t e n e r y m s d e s a f i a n t e d e pr o ba r .
5. Las responsabi l i dades pueden comparti rse entre cl as es rel aci onadas
cuando e s t o e s apropi ado. Exi s t e n m u c ho s c a s o s e n l o s q u e u n a va r i e d a d
d e o bje t o s r e l a c i o n a d o s d e be n m o s t r a r e l m i s m o c o m po r t a m i e n t o a l m i s m o
t i e m po . Co m o u n e je m pl o , c o n s i d r e s e u n vi d e o ju e go q u e d e be d e s pl e ga r l a s
s i gu i e n t e s c l a s e s : Jugador, Cuerpojugador, Brazosjugador, Piernasjuga-
dor, Cabezajugador. Ca d a u n a d e e s t a s c l a s e s t i e n e s u s pr o pi o s a t r i bu t o s
( po r e j e m p l o , po s i c i n , o r i e n t a c i n , c o l o r , ve l o c i d a d ) y t o d o s d e b e n a c t u a l i z a r s e y
d e s pl e ga r s e c u a n d o e l u s u a r i o m a n i pu l a u n jqy stick . Po r l o t a n t o , l a s r e s po n -
s a bi l i d a d e s actualizad) y desplegar, () d e be n c o m pa r t i r l a s c a d a u n o d e l o s o bje -
t o s m e n c i o n a d o s . El Jugador s a be c u a n d o a l go ha c a m bi a d o y s e r e q u i e r e
actualizar(). Co l a bo r a c o n l o s o t r o s o bje t o s pa r a l o gr a r u n a n u e va po s i c i n u
o r i e n t a c i n , pe r o c a d a o bje t o c o n t r o l a s u pr o pi o d e s pl i e gu e .
Col aboraci ones. La s c l a s e s c u m pl e n s u s r e s po n s a bi l i d a d e s e n u n a d e d o s f o r m a s :
1) u n a c l a s e pu e d e u t i l i za r s u s pr o pi a s o pe r a c i o n e s pa r a m a n i pu l a r s u s pr o pi o s a t r i -
bu t o s , y c o n e l l o c u m pl i r c o n u n a r e s po n s a bi l i d a d pa r t i c u l a r , o 2) u n a c l a s e pu e d e
c o l a bo r a r c o n o t r a s c l a s e s .
Wi r f s -Br o c k y s u s c o l e ga s [W1R90] d e f i n e n l a s colaboraciones d e l a s i gu i e n t e
m a n e r a :
La s c o l a bo r a c i o n e s r e pr e s e n t a n l a s s o l i c i t u d e s q u e u n c l i e n t e ha c e a u n s e r vi d o r c o n e l f i n
d e c u m pl i r u n a r e s po n s a bi l i d a d . Un a c o l a bo r a c i n e s l a m a t e r i a l i za c i n d e l c o n t r a t o e n -
t r e e l c l i e n t e y e l s e r vi d o r . . . Se d i c e q u e u n o bj e t o c o l a bo r a c o n o t r o o bj e t o s i , pa r a c u m -
pl i r c o n u n a r e s po n s a bi l i d a d , n e c e s i t a e n vi a r a l gu n o s m e n s a j e s a l o t r o o bj e t o . Un a
23 En t a l e s c a s o s pu e d e s e r n e c e s a r i o d i vi d i r l a s c l a s e s e n m l t i pl e s c l a s e s o s u bs i s t e m a s c o m pl e t o s
pa r a d i s t r i bu i r l a i n t e l i ge n c i a d e m a n e r a m s e f i c a z.
TM
PDF Editor
c o l a bo r a c i n s e n c i l l a f l u ye e n u n a d i r e c c i n , l o q u e r e pr e s e n t a u n a s o l i c i t u d d e l c l i e n t e a l
s e r vi d o r . De s d e e l pu n t o d e vi s t a d e l c l i e n t e , c a d a u n a d e s u s c o l a bo r a c i o n e s e s t a s o c i a d a
c o n u n a r e s po n s a bi l i d a d pa r t i c u l a r q u e ha i m pl e m e n t a d o e l s e r vi d o r .
La s c o l a bo r a c i o n e s i d e n t i f i c a n l a s r e l a c i o n e s e n t r e c l a s e s . Cu a n d o u n c o n ju n t o d e
c l a s e s c o l a bo r a pa r a l o gr a r a l gn r e q u i s i t o , s t e pu e d e o r ga n i za r s e e n u n s u bs i s t e -
m a ( u n a s pe c t o d e d i s e o ).
La s c o l a bo r a c i o n e s s e i d e n t i f i c a n a l d e t e r m i n a r s i u n a c l a s e pu e d e c u m pl i r c a d a
r e s po n s a bi l i d a d po r s m i s m a . Si n o e s a s , e n t o n c e s s e r e q u i e r e d e l a i n t e r a c c i n c o n
o t r a c l a s e y, po r e n d e , u n a c o l a bo r a c i n .
Co m o u n e je m pl o , c o n s i d r e s e l a f u n c i n d e s e gu r i d a d d e HogarSeguro. Co m o
pa r t e d e l pr o c e d i m i e n t o d e a c t i va c i n , e l o bje t o Panel deControl d e be d e t e r m i n a r
s i a l gn s e n s o r e s t a bi e r t o . Se d e f i n e u n a r e s po n s a bi l i d a d l l a m a d a determinar- esta-
tus- sensor(). Si l o s s e n s o r e s e s t n a bi e r t o s , Panel deControl d e be e s t a bl e c e r u n
a t r i bu t o d e est at us c o m o "n o l i s t o ". La i n f o r m a c i n d e l o s s e n s o r e s s e o bt i e n e d e
c a d a o bje t o sensor. Po r l o t a n t o , l a r e s po n s a bi l i d a d determinar- estatus- control() t r a -
ba ja e n c o l a bo r a c i n c o n sensor.
Pa r a a yu d a r s e e n l a i d e n t i f i c a c i n d e l o s c o l a bo r a d o r e s , e l a n a l i s t a pu e d e e xa m i -
n a r t r e s r e l a c i o n e s ge n r i c a s d i f e r e n t e s e n t r e l a s c l a s e s [ WIR90] : 1) l a r e l a c i n es-
parte- de, 2 ) l a r e l a c i n tiene- conocimiento- de, y 3) l a r e l a c i n depende de. Ca d a u n a
d e l a s t r e s r e l a c i o n e s ge n r i c a s s e c o n s i d e r a c o n br e ve d a d e n l o s s i gu i e n t e s pr r a -
f o s .
To d a s l a s c l a s e s q u e s o n pa r t e d e u n a c l a s e a gr e ga d a s e c o n e c t a n a s t a a t r a v s
d e u n a r e l a c i n d e l t i po es- parte- de. Co n s i d r e n s e l a s c l a s e s d e f i n i d a s pa r a e l vi d e o -
ju e go ya m e n c i o n a d o , l a c l a s e Cuerpojugador es- parte- de Jugador, a l i gu a l q u e
Brazosjugador, Pi ernasjugador y Cabezajugador En UML e s t a s r e l a c i o n e s s e
r e pr e s e n t a n c o m o l a a gr e ga c i n m o s t r a d a e n l a f i gu r a 8.16.
Cu a n d o u n a c l a s e d e be o bt e n e r i n f o r m a c i n d e o t r a c l a s e s e e s t a bl e c e l a r e l a c i n
tiene- conocimiento- de. La r e s po n s a bi l i d a d determinar- estatus- sensor() m e n c i o n a d a
a n t e s e je m pl i f i c a u n a r e l a c i n d e l t i po tiene- conocimiento- de.
La r e l a c i n depende- de i m pl i c a q u e d o s c l a s e s t i e n e n u n a d e pe n d e n c i a q u e n o s e
l o gr a m e d i a n t e l a s r e l a c i o n e s tiene- conocimiento- de o es- parte- de. Po r e je m pl o ,
cabezaj ugador s i e m pr e d e be e s t a r c o n e c t a d a a Cuerpojugador ( a m e n o s q u e e l
vi d e o ju e go s e a vi o l e n t o e n pa r t i c u l a r ). Au n a s , c a d a o bje t o pu e d e e xi s t i r s i n e l c o n o -
c i m i e n t o d i r e c t o d e l o t r o . Un a t r i bu t o d e l o bje t o Cabezajugador l l a m a d o posi ci n
central e s t d e t e r m i n a d o d e s d e l a po s i c i n c e n t r a l d e Cuerpojugador. Es t a i n f o r -
m a c i n s e o bt i e n e a t r a v s d e u n t e r c e r o bje t o , Jugador, q u i e n l a a d q u i e r e d e
Cuerpojugador Po r e n d e , Cabezajugador depende- de Cuerpojugador.
En t o d o s l o s c a s o s , e l n o m br e d e l a c l a s e d e l c o l a bo r a d o r s e r e gi s t r a e n l a t a r je t a
n d i c e d e l m o d e l o CRC e n s e gu i d a d e l a r e s po n s a bi l i d a d q u e ha pr o d u c i d o l a c o l a bo -
r a c i n . Po r l o t a n t o , l a t a r je t a n d i c e c o n t i e n e u n a l i s t a d e r e s po n s a bi l i d a d e s y l a s
c o l a bo r a c i o n e s c o r r e s po n d i e n t e s q u e pe r m i t e n q u e l a s r e s po n s a bi l i d a d e s pu e d a n
c u m pl i r s e ( f i gu r a 8.15).
TM
PDF Editor
Una clase
agregada
compuesta.
Cabezajugadoi CuerpoJugador BrazosJugador PiernasJugador
Cu a n d o s e ha d e s a r r o l l a d o u n m o d e l o CRC c o m pl e t o , l o s r e pr e s e n t a n t e s d e l d i c -
t e s y l a i n ge n i e r a d e l s o f t wa r e pu e d e n r e vi s a r e l m o d e l o u t i l i za n d o e l s i gu i e n t e e n >
q u e [ AMB95] :
1. To d o s l o s pa r t i c i pa n t e s e n l a r e vi s i n ( d e l m o d e l o CRC) r e c i be n u n s u bc o n -
j u n t o d e l a s t a r j e t a s n d i c e d e l m o d e l o CRC. La s t a r j e t a s q u e c o l a bo r a n s e d e -
be n s e pa r a r ( e s d e c i r , n i n gn r e vi s o r d e be t e n e r d o s q u e c o l a bo r e n ).
2. To d o s l o s e s c e n a r i o s d e c a s o d e u s o ( y l o s d i a gr a m a s d e c a s o d e u s o c o r r e s -
po n d i e n t e s ) d e be n o r ga n i za r s e e n c a t e go r a s .
3. El l d e r d e l a r e vi s i n l e e e l c a s o d e u s o e n f o r m a d e l i be r a d a . Cu a n d o e l l d e r
l l e ga a u n a c l a s e n o m br a d a pa s a u n a s e a l a l a pe r s o n a q u e t i e n e l a t a r je t a
n d i c e d e c l a s e c o r r e s po n d i e n t e . Po r e j e m pl o , u n c a s o d e u s o pa r a HogarSe-
guro c o n t i e n e l a s i gu i e n t e n a r r a t i va :
El pr o pi e t a r i o o bs e r va e l pa n e l d e c o n t r o l d e HogarSeguro pa r a d e t e r m i n a r s i e l s i s t e m a
e s t l i s t o pa r a l a e n t r a d a . Si n o l o e s t , e l pr o pi e t a r i o po d r c e r r a r f s i c a m e n t e ve n t a -
n a s y pu e r t a s pa r a q u e s e pr e s e n t e e l i n d i c a d o r d e l i s t o . [ Un i n d i c a d o r d e n o -l i s t o i m -
pl i c a q u e u n s e n s o r e s t a bi e r t o ; e s d e c i r , q u e e s a pu e r t a o ve n t a n a e s t a bi e r t a .]
Cu a n d o e l l d e r d e l a r e vi s i n l l e ga a "pa n e l d e c o n t r o l ", e n l a n a r r a t i va d e l c a s c
d e u s o , l a s e a l s e pa s a a l a pe r s o n a q u e po s e e l a c a r t a n d i c e d e l Panel de-
control . La f r a s e "i m pl i c a q u e u n s e n s o r e s t a bi e r t o " r e q u i e r e q u e l a t a r je t a
n d i c e c o n t e n ga u n a r e s po n s a bi l i d a d q u e va l i d a r e s t a i m pl i c a c i n ( l o c u a l s e
l o gr a m e d i a n t e l a r e s po n s a bi l i d a d determinar- estatus- sensor()). En s e gu i d a d e
l a r e s po n s a bi l i d a d e s c r i t a e n l a t a r je t a e s t e l c o l a bo r a d o r s ens or. En t o n c e s , l a
s e a l s e pa s a a l a c l a s e sensor.
4. Cu a n d o s e pa s a l a s e a l , l a pe r s o n a q u e po s e e l a t a r j e t a d e c l a s e d e be d e s c r i -
bi r l a s r e s po n s a bi l i d a d e s a n o t a d a s e n e l l a . El gr u po d e t e r m i n a s i u n a ( o m s )
d e l a s r e s po n s a bi l i d a d e s s a t i s f a c e e l r e q u i s i t o d e l c a s o d e u s o .
TM
PDF Editor
5. Si l a s r e s po n s a bi l i d a d e s y l a s c o l a bo r a c i o n e s a n o t a d a s e n l a s t a r je t a s n d i c e
n o s a t i s f a c e n e l c a s o d e u s o , s e ha c e n l a s m o d i f i c a c i o n e s n e c e s a r i a s a l a t a r -
je t a . Es t o pu e d e i n c l u i r l a d e f i n i c i n d e c l a s e s n u e va s ( y c o r r e s po n d e n a l a s
t a r je t a s d e n d i c e d e CRC) o l a e s pe c i f i c a c i n d e r e s po n s a bi l i d a d e s o c o l a bo r a -
c i o n e s n u e va s r e vi s a d a s s o br e l a s t a r je t a s e xi s t e n t e s .
Es t a f o r m a d e o pe r a c i n c o n t i n a ha s t a q u e s e t e r m i n a c o n e l c a s o d e u s o . Cu a n d o
s e ha n r e vi s a d o t o d o s l o s c a s o s d e u s o s e c o n t i n a c o n e l m o d e l a d o d e l a n l i s i s .
lelos CRC
! e s c e na r i o : Cu b c u l o d e Ed ,
I a n l i s i s .
s: Vi n o d y Ed , m i e m br o s d e l e q u i po d e
d e l s o f t wa r e d e HogarSeguro
i d e c i d i d o e n s e a r l e a Ed c m o d e s a r r o l l a r
s CRC m e d i a n t e u n e je m pl o .)
: Mi e n t r a s t ha s e s t a d o t r a ba j a n d o e n l o
y Ja m i e ha e s t a d o i n vo l u c r a d o c o n l a
i , yo he e s t a d o t r a ba j a n d o e n l a f u n c i n d e
i d e l ho ga r . | |
: Cu l e s e l e s t a t u s d e e s o ? Me r c a d o t e c n i a c a m bi a s u
: vi s t a a c a d a m o m e n t o . ,,t
Aq u e s t e l pr i m e r c o r t e d e l c a s o d e u s o pa r o
i a f u n c i n . l o he m o s r e f i n a d o u n po c o , pe r o
i d a r t e u n a i d e a ge n e r a !.
Fu n c i n d e a d m i n i s t r a c i n d e l ho ga r d e
: Qu e r e m o s u t i l i za r l a i n t e r f a z d e
i d e l ho ga r e n u n a PC o c o n u n a c o n e xi n
t pa r a c o n t r o l a r d i s po s i t i vo s e l e c t r n i c o s q u e
i c o n s o l a d o r e s d e i n t e r f o z i n a l m br i c o s . El s i s t e m a
> pe r m i t i r m e e n c e n d e r y a pa ga r l u c e s e s pe c f i c a s ,
a pl i c a c i o n e s c o n e c t a d a s a u n a i n t e r f a z
D, c o n f i gu r a r l o s s i s t e m a s d e c a l e f a c c i n y a i r e
i c o n l a s t e m pe r a t u r a s q u e yo d e f i n a ; pa r a
i q u i e r o s e l e c c i o n a r l o s d i s po s i t i vo s d e u n pl a n o d e
i d e l a c a s a . Ca d a d i s po s i t i vo d e be e s t a r
h i c a d o s o br e e l pl a n o d e l a pl a n t a . Co m o u n a
i o pc i o n a l , q u i e r o c o n t r o l a r t o d o s l o s
s i t i vo s a u d i o vi s u a l e s : a u d i o , t e l e vi s i n , DVD,
l y j&a d o r a s d i gi t a l e s , e t c t e r a
Co n u n a s o l o s e l e c c i n , q u i e r o s e r c a pa z d e c o n f i gu r a r
l a c a s a c o m pl e t a pa r a va r i a s s i t u a c i o n e s . Un a e s e n
c asa; l a o t r a , fuera de casa; u n a t e r c e r a , salida por la
noche, y u n a c u a r t a , viaje largo. To d a s e s t a s s i t u a c i o n e s
t e n d r n c o n f i gu r a c i o n e s q u e s e a pl i c a r n a t o d o s l o s
d i s po s i t i vo s . En l o s e s t a d o s salida por la noche y viaje
largo e l s i s t e m a d e be e n c e n d e r y a pa ga r l u c e s a
i n t e r va l o s a l e a t o r i o s ( pa r a a pa r e n t a r q u e a l gu i e n e s t e n
c a s a ) y c o n t r o l a r e l s i s t e m a d e c a l e f a c c i n y a i r e
a c o n d i c i o n a d o . De bo s e r c a pa z d e i n va l i d a r e s t a s
c o n f i gu r a c i o n e s a t r a v s d e In t e r n e t c o n l a pr o t e c c i n d e
u n a c o n t r a s e a a pr o pi a d a .
Ed: La ge n t e d e ha r d wa r e t i e n e c o n c e bi d a s t o d a s l a s
i n t e r f a s e s i n a l m br i c a s ?
Vi nod ( s onr i e ndo) : Es t n t r a ba j a n d o e n e l l a s ,
d i ga m o s q u e n o e s u n gr a n pr o bl e m a . De c u a l q u i e r
m a n e r a , e xt r a j e u n a s e r i e d e c l a s e s pa r a l a
a d m i n i s t r a c i n d e l ho ga r , y po d e m o s u t i l i za r a l gu n a d e
e l l a s c o m o e je m pl o . Us e m o s l a c l a s e
InterfazAdministracinHogar.
Ed: De a c u e r d o . . e n t o n c e s , l a s r e s po n s a bi l i d a d e s
s o n ... l o s a t r i bu t o s y o pe r a c i o n e s pa r a l a c l a s e , y l a s
c o l a bo r a c i o n e s s o n l a s c l a s e s ha c i a l a s q u e a pu n t a n l a s
r e s po n s a bi l i d a d e s .
Vi nod: Cr e o q u e n o e n t e n d i s t e l a CRC.
Ed: Ta l ve z u n po c o , pe r o c o n t i n a .
Vi nod: En t o n c e s , a q u e s t m i d e f i n i c i n d e c l a s e pa r a
InterfazAdministracinHogar.
Atributos:
Pa n e l o pc i o n e s : pr o po r c i o n a i n f o r m a c i n e n bo t o n e s q u e
pe r m i t e n a l u s u a r i o s e l e c c i o n a r u n a f u n c i o n a l i d a d .
Pa n e l s i t u a c i n : pr o po r c i o n a i n f o r m a c i n e n bo t o n e s q u e
pe r m i t e n a l u s u a r i o s e l e c c i o n a r l a s i t u a c i n .
TM
PDF Editor
Pi o n o d e pl a n t a : e l m i s m o q u e e l o bj e t o d e vi gi l a n c i a , pe r o
s t e d e s pl i e ga l o s d i s po s i t i vo s . ( > : .
Ic o n o s d e Di s po s i t i vo : i n f o r m a c i n s o br e i c o n o s q u e
r e pr e s e n t a n l u c e s , a pl i c a c i o n e s , c m a r a s , e t c t e r a .
Pa n e l e s d e Di s po s i t i vo : s i m u l a c i n d e u r i a a pl i c a c i n o
pa n e l d e c o n t r o l d e u n d i s po s i t i vo ; pe r m i t e e l c o n t r o l .
Operaciones:
Desp egarControllj, selecaonarControl(),
desplegarSihjcKn(), seleccionarSituacin(),
enlrarPlanodePlanla, seleca'onorlconoDispositivofj,
desplegarPanelDispositivofl entrar PanelDispositivolj, ...
Cl ase: InterhzAdministracinHogar
Responsabilidad Colaborador
d e s pi e ga r Co n t r o l Pa n e l o p e r a c i o n e s ( c l a s e )
s e l e c i o n a r Co n t r o l Pa n e l o p e r a c i o n e s ( c l a s e )
d e s pl e ga r Si t u a c i n Pane l Si t uac i n ( c l a s e )
s e l e c c i o n a r Si t u a c i n
e n t r a r Pl a n o d e Pl a n t a
Pa ne l Si t ua c i n ( c l a s e )
Pl a n o d e Pl a n t a ( c l a s e )
Ed: En t o n c e s c u a n d o s e i n vo c a l a o pe r a c i n
entrarplanodePlantall, s t a c o l a bo r a c o n e l o bj e t o
Pl a n o d e Pl a n t a c o m o e l q u e d e s a r r o l l a m o s pa r a l a
vi gi l a n c i a . Es pe r a , a q u t e n go s u d e s c r i pc i n . ( Ve n l a
f i gu r a 8. 14)
Vi nod: Exa c t a m e n t e . Y s q u i s i r a m o s r e vi s a r t o d o e l
m o d e l o d e c l a s e , po d r a m o s c o m e n za r c o n e s t a c a r t a
n d i c e , d e s pu s i r a l a c a r t a n d c e d e l c o l a bo r a d o r , y c e
a h , a u n a d e l o s c o l a bo r a d o r e s d e l o s c o l a bo r a d o r e s , y
a s s u c e s i va m e n t e ,
Ed: Bu e n a f o r m a d e e n c o n t r a r o m i s i o n e s o e r r o r e s .
Vinod: S.
K
cvE
Un a a s o c i a c i n d e f i n e
u n a r e l a c i n e n t r e
c l a s e s . La m u l t i pl i c i d a d
d e f i n e c u n t a s d e u n a
c l a s e e s t n
r e l a c i o n a d a s c o n
c u n t o s d e o t r o c l a s e .
^ Qu e s u n
e s t e r e o t i p o ?
8.7.5 As o c i a c i o n e s y d e pe n d e n c i a s
En m u c ho s c a s o s , d o s c l a s e s d e a n l i s i s s e r e l a c i o n a n e n t r e s d e a l gu n a m a n e r a , pa r e -
c i d a a l a f o r m a e n q u e s e r e l a c i o n a n d o s o bje t o s d e d a t o s ( s e c c i n 8.3.3). En UML e s t a s
r e l a c i o n e s s e l l a m a n asociaciones. V a s e d e n u e vo l a f i gu r a 8.14; l a c l a s e PlanodePlanta
s e d e f i n e a l i d e n t i f i c a r u n c o n ju n t o d e a s o c i a c i o n e s e n t r e Pl anodePl anta y o t r a s d o s c i a -
s e s , Cmara y Pared. La c l a s e Pared s e a s o c i a c o n t r e s c l a s e s q u e pe r m i t e n q u e s e
c o n s t r u ya u n a pa r e d , Segment odePared, Ventana y Puerta.
En a l gu n o s c a s o s , u n a a s o c i a c i n s e pu e d e d e f i n i r e n f o r m a m s e xt e n s a a l i n d i -
c a r multiplicidad ( e l t r m i n o cardinalidad ya s e u s a n t e s e n e s t e c a p t u l o ). En r e f e -
r e n c i a a l a f i gu r a 8.14, u n o bj e t o d e Pared s e c o n s t r u ye c o n u n o o m s o bj e t o s d e
Se gme nt os de Par e d. Ad e m s , e l o bj e t o Pared pu e d e c o n t e n e r 0 o m s o bj e t o s
d e Vent ana y 0 o m s o bj e t o s d e Puerta. Es t a s r e s t r i c c i o n e s d e m u l t i pl i c i d a d s e i l u s -
t r a n e n l a f i gu r a 8.17, d o n d e "u n o o m s " s e r e pr e s e n t a m e d i a n t e 1 ..* y "0 o m s " po -
m e d i o 0..* . En UML e l a s t e r i s c o i n d i c a u n a f r o n t e r a s u pe r i o r i l i m i t a d a e n e l r a n go .-
En m u c ho s c a s o s e xi s t e u n a r e l a c i n c l i e n t e -s e r vi d o r e n t r e d o s c l a s e s d e a n l i s i s .
En t a l e s c a s o s , u n a c l a s e d e c l i e n t e d e pe n d e d e a l gu n a m a n e r a d e l a c l a s e d e s e r vi -
d o r y s e e s t a bl e c e u n a relacin independencia. La s d e pe n d e n c i a s s e d e f i n e n m e d i a n -
t e u n e s t e r e o t i po . Un estereotipo e s u n "m e c a n i s m o d e e xt e n s i bi l i d a d " [ ARL02] d e n
24 Ot r a s r e l a c i o n e s d e m u l t i pl i c i d a d u n a a u n a , u n a a m u c ha s , m u c ha s a m u c ha s , u n a a u n r a n go e s -
pe c f i c o c o n l m i t e s i n f e r i o r y s u pe r i o r , y o t r a s s e pu e d e n i n d i c a r c o m o pa r t e d e u n a a s o c i a c i n
TM
PDF Editor
C A P I T U L O 8 MODELADO DEL ANLISIS 233
t r o d e l UML q u e pe r m i t e a u n i n ge n i e r o d e s o f t wa r e d e f i n i r u n e l e m e n t o d e m o d e l a -
d o e s pe c i a l c u ya s e m n t i c a d e f i n e e l c l i e n t e . En UML l o s e s t e r e o t i po s s e r e pr e s e n t a n
d e n t r o d e c o m i l l a s a n gu l a r e s ( po r e je m pl o , e s t e r e o t i po ) .
Co m o u n a i l u s t r a c i n d e u n a d e pe n d e n c i a s i m pl e d e n t r o d e l s i s t e m a d e vi gi l a n -
c i a d e HogarSeguro, u n o bje t o d e Cmara ( e n e s t e c a s o , l a c l a s e d e s e r vi d o r ) pr o -
po r c i o n a u n a i m a ge n d e vi d e o o u n o bje t o d e VentanadeDespl i egue ( e n e s t e c a s o ,
l a d e l c l i e n t e ). La r e l a c i n e n t r e e s t o s d o s o bje t o s n o e s u n a a s o c i a c i n s i m pl e , a u n a s
e xi s t e u n a a s o c i a c i n d e d e pe n d e n c i a . En u n c a s o d e u s o e s c r i t o pa r a l a vi gi l a n c i a
( q u e n o s e m u e s t r a ), e l m o d e l a d o r a pr e n d e q u e s e d e be pr o po r c i o n a r u n a c o n t r a s e a
e s pe c i a l pa r a ve r u bi c a c i o n e s e s pe c f i c a s d e c m a r a . Un a f o r m a d e l o gr a r e s t o e s q u e
Cmara pi d a u n a c o n t r a s e a y d e s pu s d pe r m i s o a VentanadeDespl i egue pa r a
pr o d u c i r l a i m a ge n d e vi d e o . Es t o s e pu e d e r e pr e s e n t a r c o m o s e m u e s t r a e n l a f i gu r a
8.18, d o n d e a c c e s o i m pl i c a q u e e l u s o d e l a s a l i d a d e l a c m a r a e s t c o n t r o l a d o
m e d i a n t e u n a c o n t r a s e a e s pe c i a l .
8.7.6 Pa q u e t e s d e a n l i s i s
Un a pa r t e i m po r t a n t e d e l m o d e l a d o d e l a n l i s i s e s l a c a t e go r i za c i n . Es t o e s , l o s
d i f e r e n t e s e l e m e n t o s d e l m o d e l o d e a n l i s i s ( po r e je m pl o , c a s o s d e u s o , c l a s e s d e
TM
PDF Editor
Paquetes.
MedioAmbi
+r bo l
i ent ej
+Pa i s a e
+Ca m i n o
+Pa r e d
+Pu e n t e
+Ed i f i c i o
+Ef e c t o Vi s u a l
+Escera
. Nombre del paquet e
Ref l l as DeUuef l oU.
Personaje |
+Re gl a s De Mo vi m e n l o
+Re s t r i c c o n e s En Ac c i n
J u ga d o r
Pr o t a go n i s t a
An t a go n i s t a
+Pa pe l d e So po r t e
\
CLAVE
Un pa q u e t e s e u t i l i zo
pa r o e n s a m bl a r u n o
c o l e c c i n d e c l a s e s
r e l a c i o n a d a s .
a n l i s i s ) s e c l a s i f i c a n d e u n a m a n e r a q u e l o s e m pa q u e t e c o m o u n a a gr u pa c i n
m a d a u n paquete de anlisis, a l a c u a l s e l e a s i gn a u n n o m br e r e pr e s e n t a t i vo .
Pa r a i l u s t r a r l a u t i l i za c i n d e pa q u e t e s d e a n l i s i s c o n s i d r e s e e l vi d e o j u e go q j d
s e pr e s e n t pr r a f o s a t r s . AI d e s a r r o l l a r e l m o d e l o d e a n l i s i s pa r a e l vi d e o ju e go >
o bt i e n e u n gr a n n m e r o d e c l a s e s . Al gu n a s s e e n f o c a n e n e l a m bi e n t e d e l j u e go ; ;
e je m pl o , l a s e s c e n a s vi s u a l e s q u e e l u s u a r i o ve m i e n t r a s s e d e s a r r o l l a e l ju e g:
Cl a s e s c o m o rbol, Pai saj e, Cami no, Pared, Puent e, Edificio, EfectoVi s'
po d r a n e s t a r d e n t r o d e e s t a c a t e go r a . Ot r a s s e e n f o c a n e n l o s pe r s o n a j e s d e n t r o ct. 1
j u e go a l d e s c r i bi r s u s c a r a c t e r s t i c a s f s i c a s , a c c i o n e s y r e s t r i c c i o n e s . Se po d r a n d e :"
n i r c l a s e s c o m o Jugador ( l a c u a l s e d e s c r i bi c o n a n t e r i o r i d a d ), Prot agoni st a
Ant agoni st a y Papel es deSoport e. Ad e m s , o t r a s d e s c r i be n l a s r e gl a s d e l ju e g :
c m o n a ve ga e l ju ga d o r a t r a v s d e l a m bi e n t e . Aq u s o n c a n d i d a t a s c l a s e s c o n -/:
Regl as DeMovi mi ent o y Rest ri cci onesEnAcci n. Pu e d e n e xi s t i r m u c ha s o t r i
c a t e go r a s . Es t a s c l a s e s pu e d e n r e pr e s e n t a r s e c o m o l o s pa q u e t e s d e a n l i s i s q u e S
m u e s t r a n e n l a f i gu r a 8.19.
El s i gn o d e m s q u e pr e c e d e a l n o m br e d e l a c l a s e d e a n l i s i s e n c a d a pa q u e a
i n d i c a q u e l a s c l a s e s t i e n e n vi s i bi l i d a d pbl i c a y q u e , po r l o t a n t o , s o n a c c e s i bl e s
d e s d e o t r o s pa q u e t e s . Au n q u e n o s e m u e s t r a n e n e s t a f i gu r a , ha y o t r o s s m bo l o s q u e
pu e d e n pr e c e d e r a u n e l e m e n t o d e n t r o d e u n pa q u e t e . Un s i gn o d e m e n o s i n d i c a q u e u n
e l e m e n t o e s t o c u l t o d e t o d o s l o s o t r o s pa q u e t e s , y u n s m bo l o # i n d i c a q u e u n e l e -
m e n t o e s a c c e s i bl e s l o a l a s c l a s e s c o n t e n i d a s d e n t r o d e u n pa q u e t e d a d o .
8 . 8 C R E A C I N P E MODELO P E COMP ORT AMI E NT O
Lo s d i a gr a m a s d e c l a s e , l a s t a r j e t a s n d i c e CRC y o t r o s m o d e l o s o r i e n t a d o s a l a s c l a -
s e s t r a t a d o s e n l a s e c c i n 8.7 r e pr e s e n t a n e l e m e n t o s e s t t i c o s d e l m o d e l o d e a n l i -
TM
PDF Editor
C A P T U L O 8 MODELADO DEL ANALISIS 235
i s e
i l o
i U s o f t -
i t e m o ?
kVE
i J s e
E d e f i n i r
l o gr a r l o ,
( c o s e
i d f i n d e
t e pu n t o s d e
i *
s i s . Aho r a e s t i e m po d e ha c e r u n a t r a n s i c i n a l c o m po r t a m i e n t o d i n m i c o d e l s i s t e -
m a o pr o d u c t o . Pa r a l o gr a r l o e l c o m po r t a m i e n t o d e l s i s t e m a d e be pr e s e n t a r s e c o m o
u n a f u n c i n d e l o s e l e m e n t o s e s pe c f i c o s y e l t i e m po .
El modelo de comportamiento i n d i c a l a f o r m a e n q u e e l s o f t wa r e r e s po n d e r a l o s e ve n -
t o s o e s t m u l o s e xt e r n o s . En l a c r e a c i n d e l m o d e l o e l a n a l i s t a d e be r e a l i za r l o s s i gu i e n -
t e s pa s o s :
1. Eva l u a r t o d o s l o s c a s o s d e u s o pa r a e n t e n d e r po r c o m pl e t o l a s e c u e n c i a d e
i n t e r a c c i n d e n t r o d e l s i s t e m a .
2. Id e n t i f i c a r l o s e ve n t o s q u e c o n d u c e n l a s e c u e n c i a d e i n t e r a c c i n y e n t e n d e r l a
f o r m a e n q u e e s t o s e ve n t o s s e r e l a c i o n a n c o n l a s c l a s e s e s pe c f i c a s .
3. Cr e a r u n a s e c u e n c i a pa r a c a d a c a s o d e u s o .
4. Co n s t r u i r u n d i a gr a m a d e e s t a d o pa r a e l s i s t e m a .
5. Re vi s a r e l m o d e l o d e c o m po r t a m i e n t o pa r a ve r i f i c a r s u e xa c t i t u d y c o n s i s t e n -
c i a .
Ca d a u n o d e e s t o s pa s o s s e e xpo n e e n l a s s e c c i o n e s s i gu i e n t e s .
8.8.1 Id e n t i f i c a c i n d e e ve n t o s c o n e l c a s o d e u s o
Co m o s e m e n c i o n e n l a s e c c i n 8.5, e l c a s o d e u s o r e pr e s e n t a u n a s e c u e n c i a d e
a c t i vi d a d e s q u e i m pl i c a a l o s a c t o r e s y a l s i s t e m a . En ge n e r a l , s i e m pr e q u e e l s i s t e -
m a y u n a c t o r i n t e r c a m bi a n i n f o r m a c i n o c u r r e u n e ve n t o . Si s e r e c u e r d a l a e xpl i -
c a c i n a n t e r i o r a c e r c a d e l m o d e l a d o d e l c o m po r t a m i e n t o e n l a s e c c i n 8.6.3, s e r
i m po r t a n t e pu n t u a l i za r q u e e l e ve n t o n o e s l a i n f o r m a c i n q u e s e ha i n t e r c a m bi a -
d o , s i n o e l hecho d e q u e l a i n f o r m a c i n ha ya s i d o i n t e r c a m bi a d a .
Lo s pu n t o s d e l i n t e r c a m bi o d e i n f o r m a c i n s e o bt i e n e n e xa m i n a n d o u n c a s o d e
u s o . A m a n e r a d e i l u s t r a c i n , s e r e c o n s i d e r a r e l c a s o d e u s o pa r a u n a pe q u e a
pa r t e d e l a f u n c i n d e s e gu r i d a d d e HogarSeguro.
El pr o pi e t a r i o u t i l i za e l t e c l a d o pa r a i n t r o d u c i r u n a c o n t r a s e a d e c u a t r o d gi t o s . La c o n -
t r a s e a s e c o m pa r a c o n la c o n t r a s e a vl i d a a l m a c e n a d a e n e l s i s t e m a . Si la c o n t r a s e a
e s i n c o r r e c t a , e l pa n e l d e c o n t r o l e m i t i r u n s o n i d o po r u n a s o l a ve z y s e r e i n i c i a r pa r a
e s pe r a r o t r a e n t r a d a . Si la c o n t r a s e a e s c o r r e c t a , e l pa n e l d e c o n t r o l e s pe r a r la a c c i n
po s t e r i o r .
La s pa r t e s s u br a ya d a s d e l e s c e n a r i o d e l c a s o d e u s o i n d i c a n e ve n t o s . Se d e be i d e n -
t i f i c a r a u n a u t o r pa r a c a d a e ve n t o ; l a i n f o r m a c i n i n t e r c a m bi a d a s e d e be a n o t a r , y
c u a l q u i e r c o n d i c i n o r e s t r i c c i n d e be r e gi s t r a r s e .
Co m o e j e m pl o d e u n e ve n t o t pi c o , c o n s i d r e s e l a f r a s e s u br a ya d a d e l c a s o d e u s o
"e l pr o pi e t a r i o u t i l i za e l t e c l a d o pa r a i n t r o d u c i r u n a c o n t r a s e a d e c u a t r o d gi t o s ". En
e l c o n t e xt o d e l m o d e l o d e a n l i s i s , e l o bje t o , propi etari o, 25 t r a n s m i t e u n e ve n t o a l
25 En e s t e e je m pl o s e a s u m e q u e c a d a u s u a r i o ( pr o pi e t a r i o ) q u e i n t e r a c t a c o n HogarSeguro t i e n e u n a
c o n t r a s e a d e i d e n t i f i c a c i n y q u e , po r l o t a n t o , e s u n o bje t o l e g t i m o .
TM
PDF Editor
< 5 *
< & V E
El s i s t e m o t i e n e
e s t a d o s q u e
r e pr e s e n t o n u n
c o m po r t a m i e n t o
e s pe c i f i c o o bs e r va bl e
d e s d e e l e xt e r i o r ; u n a
c i s e t i e n e e s t a d o s q u e
r e pr e s e n t a n s u
c u a n d o e l s i s t e m a
r e a l i za s u s f u n c i o n e s .
o bj e t o Panel deCont rol . El e ve n t o po d r a l l a m a r s e introduccin de contrasea
i n f o r m a c i n t r a n s f e r i d a s o n l o s c u a t r o d gi t o s q u e c o n s t i t u ye n l a c o n t r a s e a .
s t a n o e s u n a pa r t e e s e n c i a l d e l m o d e l o d e c o m po r t a m i e n t o . Es i m po r t a n t e :
q u e a l gu n o s e ve n t o s t i e n e n u n i m pa c t o e xpl c i t o s o br e e l f l u jo d e c o n t r o l d e l i
u s o , m i e n t r a s q u e o t r o s n o t i e n e n i m pa c t o d i r e c t o s o br e e l f l u jo d e c o n t r o l . Po r <
p o , e l e ve n t o introduccin de contrasea n o c a m bi a d e m a n e r a e xpl c i t a e l f l u j: i
c o n t r o l d e l c a s o d e u s o , pe r o l o s r e s u l t a d o s d e l e ve n t o comparacin de cont
( d e r i va d o d e l a i n t e r a c c i n "l a c o n t r a s e a s e c o m pa r a c o n l a c o n t r a s e a v
a l m a c e n a d a e n e l s i s t e m a ") t e n d r u n i m pa c t o e xpl c i t o s o br e l a i n f o r m a c i n
f l u jo d e c o n t r o l d e l s o f t wa r e d e HogarSeguro.
Un a ve z q u e s e ha n i d e n t i f i c a d o t o d o s l o s e ve n t o s , s t o s s e u bi c a n c o n l o s i
t o s i n vo l u c r a d o s . Lo s o bj e t o s pu e d e n s e r r e s po n s a bl e s d e ge n e r a r e ve n t o s ( po r <
p o , Propi et ari o ge n e r a e l e ve n t o d e introduccin de contrasea) o d e r e c o r
e ve n t o s q u e ha n o c u r r i d o e n c u a l q u i e r s i t i o ( po r e je m pl o , Panel deCont rol r e
c e e l r e s u l t a d o bi n a r i o d e l e ve n t o comparacin de contrasea).
8.8.2 Re pr e s e n t a c i o n e s d e e s t a d o
En e l c o n t e xt o d e l m o d e l a d o d e l c o m po r t a m i e n t o s e pu e d e n c o n s i d e r a r d o s d i f e
t e s c a r a c t e r i za c i o n e s d e l o s e s t a d o s : 1) e l e s t a d o d e c a d a c l a s e c o n f o r m e e l s i s t e
r e a l i za s u f u n c i n , y 2) e l e s t a d o d e l s i s t e m a c o m o s e o bs e r va d e s d e e l e xt e r i o r (
f o r m e e l s i s t e m a r e a l i za s u f u n c i n . 26
El e s t a d o d e u n a c l a s e i m pl i c a c a r a c t e r s t i c a s t a n t o pa s i va s c o m o a c t i va s [CHA^
Un estado pasivo e s s i m pl e m e n t e e l e s t a t u s a c t u a l d e t o d o s l o s a t r i bu t o s d e u n o bje
Po r e j e m pl o , e l e s t a d o pa s i vo d e l a c l a s e Jugador ( e n l a a pl i c a c i n d e vi d e o ji
e s t u d i a d a c o n a n t e r i o r i d a d ) i n c l u i r a l o s a t r i bu t o s d e po s i c i n y o r i e n t a c i n d e l Jugador ]
a s c o m o o t r a s c a r a c t e r s t i c a s r e l e va n t e s pa r a e l j u e go ( po r e je m pl o , u n a t r i bu t o i
i n d i q u e l a e xi s t e n c i a d e d e s e o s m gi c o s ). El estado activo d e u n o bj e t o i n d i c a e l e s t a '
a c t u a l d e l o bj e t o c u a n d o s t e e s t s u j e t o a u n a t r a n s f o r m a c i n o a u n pr o c e s a m i e
t o c o n t i n u o s . La c l a s e Jugador po d r a t e n e r l o s s i gu i e n t e s e s t a d o s a c t i vo s : en,
miento, en descanso, herido, en curacin, atrapado, perdido, e t c t e r a . De be o c u r r i r i
e ve n t o ( a l gu n a s ve c e s l l a m a d o u n disparador) pa r a o bl i ga r a u n o bj e t o a ha c e r
t r a n s i c i n d e u n e s t a d o a c t i vo a o t r o .
En l o s pr r a f o s s i gu i e n t e s s e e xpl i c a n d o s d i f e r e n t e s r e pr e s e n t a c i o n e s d e l c c
po r t a m i e n t o . La pr i m e r a i n d i c a l a f o r m a e n q u e u n a c l a s e i n d i vi d u a l c a m bi a s u s e s
d o c o n ba s e e n e ve n t o s e xt e r n o s , y l a s e gu n d a m u e s t r a e l c o m po r t a m i e n t o d e l so:":-
wa r e c o m o u n a f u n c i n d e l t i e m po .
Di agramas de e s t ado para c l as e s de anl i si s. Un c o m po n e n t e d e u n m o d e l ]
d e l c o m po r t a m i e n t o e s u n d i a gr a m a d e e s t a d o e n UML q u e r e pr e s e n t a l o s e s t a d
a c t i vo s pa r a c a d a c l a s e y l o s e ve n t o s ( d i s pa r a d o r e s ) q u e o c a s i o n a n c a m bi o s e n t r e
26 Lo s d i a gr a m a s d e e s t a d o pr e s e n t a d o s e n l a s e c c i n 8.6.3 m u e s t r a n e l e s t a d o d e l s i s t e m a . La e xpo
s i c i n e n e s t a s e c c i n s e e n f o c a r a l e s t a d o d e c a d a c l a s e d e n t r o d e l m o d e l o d e a n l i s i s .
TM
PDF Editor
C A P T U L O 8 MODELADO DEL ANLISIS 2 3 7
de estado
clase
trol.
Te m po r i za d o r s Ti e m po Ce r r a d o
M E
d e u n
* e s t a d o
e l
' s i n
l a s c l a s e s
. u n
f e s e c u e n c i a
-i t o o l
c f o r m a e n
r c s e s s e
* e s t a d o o
e s t o s e s t a d o s a c t i vo s . En l a f i gu r a 8.20 s e i l u s t r a u n d i a gr a m a d e e s t a d o pa r a l a c l a s e
Panel deCont rol e n l a f u n c i n d e s e gu r i d a d d e HogarSeguro.
Ca d a f l e c ha e n l a f i gu r a 8.20 r e pr e s e n t a u n a t r a n s i c i n d e s d e u n e s t a d o a c t i vo d e
u n a c l a s e ha s t a o t r o . La s e t i q u e t a s m o s t r a d a s pa r a c a d a f l e c ha r e pr e s e n t a n e l e ve n -
t o q u e d i s pa r a l a t r a n s i c i n . Au n q u e e l m o d e l o d e e s t a d o a c t i vo pr o po r c i o n a u n d i s -
c e r n i m i e n t o a c t i vo d e l a "hi s t o r i a d e vi d a " d e u n a c l a s e , e s po s i bl e e s pe c i f i c a r i n f o r -
m a c i n a d i c i o n a l pa r a pr o po r c i o n a r m a yo r pr o f u n d i d a d e n l a c o m pr e n s i n d e l c o m -
po r t a m i e n t o d e u n a c l a s e . Ad e m s d e e s pe c i f i c a r e l e ve n t o q u e o c a s i o n a l a t r a n s i -
c i n , e l a n a l i s t a pu e d e e s pe c i f i c a r u n a gu a r d i a y u n a a c c i n [ CHA93] . Un a guardia e s
u n a c o n d i c i n bo o l e a n a q u e d e be s a t i s f a c e r s e pa r a q u e o c u r r a l a t r a n s i c i n . Po r
e je m pl o , l a gu a r d i a pa r a l a t r a n s i c i n d e s d e e l e s t a d o d e "l e c t u r a " a l e s t a d o d e "c o m -
pa r a c i n " d e l a f i gu r a 8.20 s e pu e d e d e t e r m i n a r a l e xa m i n a r e l c a s o d e u s o :
s i ( i n t r o d u c c i n d e c o n t r a s e a = 4 d gi t o s ), e n t o n c e s c o m pa r a r c o n c o n t r a s e a a l m a c e n a d a
En ge n e r a l , l a gu a r d i a pa r a u n a t r a n s i c i n po r l o r e gu l a r d e pe n d e d e l va l o r d e u n o o
m s a t r i bu t o s d e u n o bje t o . En o t r a s pa l a br a s , l a gu a r d i a d e pe n d e d e l e s t a d o pa s i vo
d e l o bje t o .
Un a accin s u c e d e d e m a n e r a c o n c u r r e n t e c o n l a t r a n s i c i n d e l e s t a d o o c o m o
c o n s e c u e n c i a d e s t e , y po r l o ge n e r a l i m pl i c a u n a o m s o pe r a c i o n e s ( r e s po n s a bi l i -
d a d e s ) d e l o bje t o . Po r e je m pl o , u n a a c c i n c o n e c t a d a c o n e l e ve n t o contrasea intro-
ducida ( f i gu r a 8.20) e s u n a o pe r a c i n l l a m a d a ValidarContrasea() q u e d a a c c e s o a
TM
PDF Editor
^ r o p i e t a i i o j
Diagiama de secuencia (parcial) para la funcin de seguridad de HogarSeguro.
i
Pa n e l d e c o n t r o l
]
Si s t e m a
Se n s o r e s
I
Si s t e m a
lis l i s t o
< 2 > -
Co n t r a s e a i n t r o d u c i d a
Le c t u r a
n m e r De l n t e n l o s >
In t e n t o s m xi m o s
<2>
Te m po r i za d o ; >
Ti e m po c e r r a d o
So l i c i t u d d e bs q u e d a

Re s u l t a d o |
Co n t r a s e a = c o r r e c t a I
' j j So l i c i t u d d e a c t i va c i n
I
Se l e c c i n
Ac t i va c i n e xi t o s a
1
I Ac t i va c i n e xi t o s a
u n o bj e t o d e cont ras ea y r e a l i za u n a c o m pa r a c i n d gi t o po r d gi t o pa r a va l i d a r l a
c o n t r a s e a i n t r o d u c i d a .
Di agramas de s ecuenci a. El s e gu n d o t i po d e r e pr e s e n t a c i n d e c o m po r t a m i e n -
t o , l l a m a d o u n diagrama de secuencia e n UML, i n d i c a c m o l o s e ve n t o s c a u s a n t r a n -
s i c i o n e s d e o bj e t o a o bje t o . Un a ve z q u e s e ha n i d e n t i f i c a d o l o s e ve n t o s a l e xa m i n a r
u n c a s o d e u s o , e l m o d e l a d o r c r e a u n d i a gr a m a d e s e c u e n c i a : u n a r e pr e s e n t a c i n d e
c m o l o s e ve n t o s c a u s a n u n f l u jo d e u n e ve n t o a o t r o c o m o u n a f u n c i n d e l t i e m po .
En e s e n c i a , e l d i a gr a m a d e s e c u e n c i a e s u n a ve r s i n a br e vi a d a d e l c a s o d e u s o .
Re pr e s e n t a c l a s e s c l a ve y e ve n t o s q u e c a u s a n q u e e l c o m po r t a m i e n t o f l u ya d e c l a s e
a c l a s e .
En l a f i gu r a 8.21 s e i l u s t r a u n d i a gr a m a d e s e c u e n c i a pa r c i a l d e l a f u n c i n d e
s e gu r i d a d d e HogarSeguro. Ca d a f l e c ha r e pr e s e n t a u n e ve n t o ( d e r i va d o d e u n c a s o
d e u s o ) e i n d i c a c m o e l e ve n t o c a n a l i za e l c o m po r t a m i e n t o e n t r e l o s o bj e t o s d e
HogarSeguro. El t i e m po s e m i d e d e m a n e r a ve r t i c a l ( ha c i a a ba jo ), y l o s r e c t n gu l o s
ve r t i c a l e s d e l ga d o s r e pr e s e n t a n e l t i e m po i n ve r t i d o e n pr o c e s a r u n a a c t i vi d a d . Lo s
e s t a d o s s e pu e d e n m o s t r a r a l o l a r go d e u n a l n e a d e t i e m po ve r t i c a l .
El pr i m e r e ve n t o , sistema listo, s e d e r i va d e l a m bi e n t e e xt e r n o y c a n a l i za e l c o m -
po r t a m i e n t o a u n o bj e t o d e propi etari o. El pr o pi e t a r i o i n t r o d u c e u n a c o n t r a s e a . Se
pa s a u n e ve n t o d e solicitud de bsqueda a l s i s t ema, e l c u a l bu s c a l a c o n t r a s e a e n
u n a ba s e d e d a t o s s i m pl e y r e gr e s a u n resultado (encontrado o no encontrado) a l
Panel deCont rol ( a ho r a e n e l e s t a d o d e comparacin). Un a c o n t r a s e a vl i d a r e s u l -
TM
PDF Editor
C A P I T U L O 8 MODELADO DEL ANLISIS
239
t a e n u n e ve n t o contrasea=correcta pa r a e l Si st ema, e l c u a l a c t i va l o s s e n s o r e s c o n
u n e ve n t o d e solicitud de activacin. Po r l t i m o , e l c o n t r o l s e pa s a d e r e gr e s o a l pr o -
pi e t a r i o c o n e l e ve n t o activacin exitosa.
Un a ve z q u e s e ha d e s a r r o l l a d o u n d i a gr a m a d e s e c u e n c i a c o m pl e t o , t o d o s l o s
e ve n t o s q u e o c a s i o n a n t r a n s i c i o n e s e n t r e o bje t o s d e l s i s t e m a s e pu e d e n c o t e ja r c o n
u n c o n j u n t o d e e ve n t o s d e e n t r a d a y e ve n t o s d e s a l i d a ( d e u n o bje t o ). Es t a i n f o r m a -
c i n e s t i l e n l a c r e a c i n d e u n d i s e o e f i c a z pa r a e l s i s t e m a q u e s e r c o n s t r u i d o .
Modelado del anlisis generalizado en UML
Obj et i vo: La s he r r a m i e n t a s pa r a e l m o d e l a d o
d e l a n l i s i s pr o po r c i o n a n l a c a pa c i d a d d e
m o d e l o s ba s a d o s e n e s c e n a r i o s , m o d e l o s
e n c l a s e s y m o d e l o s d e c o m po r t a m i e n t o m e d i a n t e
UML.
3 La s he r r a m i e n t a s e n e s t a c a t e go r a s o po r t a n
-a n go d e d i a gr a m a s e n UML r e q u e r i d o s pa r a
u n m o d e l o d e a n l i s i s ( e s t a s he r r a m i e n t a s
s o po r t a n e l m o d e l a d o d e l d i s e o ). Ad e m s d e l a
x d i a gr a m a s , l a s he r r a m i e n t a s e n e s t a c a t e go r a
i l o ve r i f i c a c i n d e l a c o n s i s t e n c i a y l a c o r r e c c i n
o s d i a gr a m a s e n UML; 2) pr o po r c i o n a n v n c u l o s
s e o y l a ge n e r a c i n d e c d i go ; 3) c o n s t r u ye n
d e d a t o s q u e a yu d a n a l a a d m i n i s t r a c i n y
d e gr a n d e s m o d e l o s e n UML r e q u e r i d o s pa r a
c o m pl e jo s .
S r e pr e s e nt a t i v a s 2 7
he r r a m i e n t a s s o po r t a n u n r a n go c o m pl e t o
e n UML r e q u e r i d o s pa r a e l m o d e l a d o d e l
ArgoilML, u n a he r r a m i e n t a d e f u e n t e a bi e r t a
( a r go u m l .t i gr i s .o r g).
Control Center, d e s a r r o l l a d o po r To ge t he r So f t
( www.t a ge t he r s o f t .c o m ).
Enterprise Arch tect, d e s a r r o l l a d o po r Spa r x Sys t e m s
( www.s pa r xs ys t e m s .c o m .a u ).
Object Technology Work bench (OTW), d e s a r r o l l a d o po r
OTW So f t wa r e ( www.o t ws o f t wa r e .c o m ).
Power Designer, d e s a r r o l l a d o po r Syba s e
( www.s yba s e .c o m ).
Rational Rose, d e s a r r o l l a d o po r Ra t i o n a l Co r po r a t i o n
( www.r a t i o n a l .c o m ).
Sy stem Arch tect, d e s a r r o l l a d o po r Po pk i n So f t wa r e
( www.po pk i n .c o m ).
UML Studio, d e s a r r o l l a d o po r Pr a gs o f t Co r po r a t i o n
( www.pr a gs o f t .c o m ).
Visio, d e s a r r o l l a d o po r Mi c r o s o f t ( www.m i c r o s o f t .c o m ).
Visual UML, d e s a r r o l l a d o po r Vi s u a l Obj e c t Mo d e l e r s
( www.vi s u a l u m l .c o m ).
El o bje t i vo d e l m o d e l a d o d e l a n l i s i s e s c r e a r u n a va r i e d a d d e r e pr e s e n t a c i o n e s q u e
m u e s t r a n l o s r e q u i s i t o s d e l s o f t wa r e pa r a l a i n f o r m a c i n , l a f u n c i n y e l c o m po r t a -
m i e n t o . Es t o s e l o gr a a pl i c a n d o d o s d i f e r e n t e s f i l o s o f a s d e m o d e l a d o ( pe r o po t e n -
c i a l m e n t e c o m pl e m e n t a r i a s ): e l a n l i s i s e s t r u c t u r a d o y e l a n l i s i s o r i e n t a d o a o bje -
t o s . El a n l i s i s e s t r u c t u r a d o c o n s i d e r a a l s o f t wa r e c o m o u n t r a n s f o r m a d o r d e i n f o r -
27 La s he r r a m i e n t a s m e n c i o n a d a s a q u s o n u n a m u e s t r a d e e s t a c a t e go r a . En l a m a yo r a d e l o s c a s o s
l o s n o m br e s e s t n r e gi s t r a d o s po r s u s r e s pe c t i vo s d e s a r r o l l a d o r e s
TM
PDF Editor
240 P A S T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
m a c i n . s t e a yu d a a l i n ge n i e r o d e s o f t wa r e a i d e n t i f i c a r l o s o bje t o s d e d a t o s ,
r e l a c i o n e s y l a m a n e r a e n l a c u a l e s t o s o bje t o s d e d a t o s s e t r a n s f o r m a n m i e n t r a s
ye n a t r a v s d e l a s f u n c i o n e s d e pr o c e s a m i e n t o d e l s o f t wa r e . El a n l i s i s o r i e n t
o bje t o s e xa m i n a u n d o m i n i o d e pr o bl e m a d e f i n i d o c o m o u n c o n ju n t o d e c a s o s
u s o e n u n e s f u e r zo po r e xt r a e r c l a s e s q u e d e f i n e n e l pr o bl e m a . Ca d a c l a s e t i e n e
c o n ju n t o d e a t r i bu t o s y o pe r a c i o n e s . La s c l a s e s e s t n r e l a c i o n a d a s e n t r e s e n i
va r i e d a d d e f o r m a s d i f e r e n t e s y s e m o l d e a n m e d i a n t e l a a pl i c a c i n d e d i a gr a m a s i
UML. El m o d e l o d e a n l i s i s l o c o m po n e n c u a t r o e l e m e n t o s d e m o d e l a d o : m e
ba s a d o s e n e s c e n a r i o s , m o d e l o s d e f l u jo , m o d e l o s ba s a d o s e n c l a s e s y m o d e l o s
c o m po r t a m i e n t o .
Lo s m o d e l o s ba s a d o s e n e s c e n a r i o s m u e s t r a n l o s r e q u i s i t o s d e l s o f t wa r e d e s e e
pu n t o d e vi s t a d e l u s u a r i o . El c a s o d e u s o u n a d e s c r i pc i n n a r r a t i va o ba s a d a
u n a pl a n t i l l a d e u n a i n t e r a c c i n e n t r e u n a c t o r y e l s o f t wa r e e s e l e l e m e n t o
m a r i o d e l m o d e l a d o . El c a s o d e u s o , d e r i va d o d u r a n t e l a o bt e n c i n d e r e q u r
d e f i n e l o s c a s o s c l a ve pa r a u n a f u n c i n o i n t e r a c c i n e s pe c f i c a . El gr a d o d e f r
l i d a d y d e t a l l e d e l c a s o d e u s o va r a , pe r o e l r e s u l t a d o f i n a l pr o po r c i o n a l a e n
n e c e s a r i a a l a s o t r a s a c t i vi d a d e s d e m o d e l a d o d e l a n l i s i s . Lo s e s c e n a r i o s t a m
pu e d e n d e s c r i bi r s e po r m e d i o d e u n d i a gr a m a d e a c t i vi d a d : u n a r e pr e s e n t a c i n
f i c a d e l t i po d e u n d i a gr a m a d e f l u jo q u e m u e s t r a e l f l u jo d e l pr o c e s a m i e n t o d e -
d e u n e s c e n a r i o e s pe c f i c o . Lo s d i a gr a m a s d e c a r r i l i l u s t r a n l a f o r m a e n q u e e l
d e pr o c e s a m i e n t o i n c u m be a va r i o s a c t o r e s o c l a s e s .
Lo s m o d e l o s d e f l u jo s e e n f o c a n e n e l f l u jo d e o bje t o s d e d a t o s c o n f o r m e l a s
c i o n e s d e pr o c e s a m i e n t o l o s t r a n s f o r m a n . Lo s m o d e l o s d e f l u jo , q u e s e d e r i va n
a n l i s i s e s t r u c t u r a d o , u t i l i za n e l d i a gr a m a d e f l u jo d e d a t o s ; s t a e s u n a n o t a c i n
m o d e l a d o q u e m u e s t r a l a m a n e r a e n q u e u n a e n t r a d a s e t r a n s f o r m a e n u n a
c o n f o r m e l o s o bje t o s d e d a t o s s e m u e ve n a t r a v s d e l s i s t e m a . Ca d a f u n c i n d e l
wa r e q u e t r a n s f o r m a d a t o s s e d e s c r i be m e d i a n t e u n a e s pe c i f i c a c i n d e l pr o c *
n a r r a t i va . Ad e m s d e l f l u jo d e d a t o s , e s t e e l e m e n t o d e m o d e l a d o t a m bi n m u
e l f l u jo d e c o n t r o l ( u n a r e pr e s e n t a c i n q u e i l u s t r a l a f o r m a e n q u e l o s e ve n t o s
t a n e l c o m po r t a m i e n t o d e l s i s t e m a ).
El m o d e l a d o ba s a d o e n c l a s e s u t i l i za i n f o r m a c i n d e r i va d a d e e l e m e n t o s
m o d e l a d o o r i e n t a d o a l f l u jo y ba s a d o e n e s c e n a r i o s pa r a e xt r a e r c l a s e s c a n d i d a "
a t r i bu t o s y o pe r a c i o n e s d e l a s n a r r a t i va s ba s a d a s e n t e xt o . Se e s t a bl e c e n l o s c
r i o s pa r a l a d e f i n i c i n d e u n a c l a s e . La t a r je t a n d i c e c l a s e -r e s po n s a bi l i d a d -c o l
r a d o r pu e d e u s a r s e e n l a d e f i n i c i n d e r e l a c i o n e s e n t r e l a s c l a s e s . Ad e m s , s e p
a pl i c a r u n a va r i e d a d d e n o t a c i o n e s d e m o d e l a d o e n UML pa r a d e f i n i r je r a r q i
r e l a c i o n e s , a s o c i a c i o n e s , a gr e ga c i o n e s y d e pe n d e n c i a s e n t r e l a s c l a s e s . Lo s pa
t e s d e a n l i s i s s e u t i l i za n pa r a c a t e go r i za r y a gr u pa r c l a s e s d e m a n e r a q u e s e a n r r c
m a n e ja bl e s pa r a l o s s i s t e m a s gr a n d e s .
Lo s pr i m e r o s t r e s e l e m e n t o s d e l m o d e l a d o d e l a n l i s i s pr o po r c i o n a n u n a vi s i :
e s t t i c a d e l s o f t wa r e . Lo s m o d e l o s d e c o m po r t a m i e n t o m u e s t r a n u n d e s e m p
d i n m i c o . El m o d e l o d e c o m po r t a m i e n t o u t i l i za l a e n t r a d a d e e l e m e n t o s ba s a d o s
TM
PDF Editor
C A P T U L O 8 MODELADO DEL ANLISIS 2 4 1
e s c e n a r i o s , o r i e n t a d o s a l f l u jo y ba s a d o s e n c l a s e s pa r a r e pr e s e n t a r l o s e s t a d o s d e
l a s c l a s e s d e a n l i s i s y d e l s i s t e m a c o m o u n t o d o . Es t o s e l o gr a i d e n t i f i c a n d o l o s
e s t a d o s , d e f i n i e n d o l o s e ve n t o s q u e o c a s i o n a n q u e u n a c l a s e ( o s i s t e m a ) t e n ga u n a
t r a n s i c i n d e u n e s t a d o a o t r o , e i d e n t i f i c a n d o l a s a c c i o n e s q u e s u c e d e n c u a n d o s e
r e a l i za l a t r a n s i c i n . En e l m o d e l a d o d e l c o m po r t a m i e n t o s e u t i l i za l a n o t a c i n e n
UML d e l o s d i a gr a m a s d e e s t a d o y l o s d i a gr a m a s d e s e c u e n c i a .
[ ABB83] Abbo t t , R., "Pr o gr a m De s i gn by In f o r m a l En gl i s h De s c r i pt i o n s ", e n CACM, vo l . 26, n m .
11, n o vi e m br e d e 1983, pp. 892-894.
[ AMB95] Am bl e r , S "Us i n g Us e -Ca s e s ", e n Software Development, ju l i o d e 1995, pp. 53-61.
[ ARA89] Ar a n go , G. y R. Pr i e t o -Di a z, "Do m a i n An a l ys i s : Co n c e pt s a n d Re s e a r c h Di r e c t i o n s ", e n
Domairt Analy sis: Acquisition of Reusable Information for Software Construction, ( Ar a n go , G. y
R. Pr i e t o -Di a z, e d s .), IEEE Co m pu t e r So c i e t y Pr e s s , 1989.
[ ARL02] Ar l o w,). e I. Ne u s t a d t , UML and the Unified Process, Ad d i s o n -We s l e y, 2002.
[ BER93] Be r a r d , E. V., Essay s on Objetc- Oriented Software Engineering, Ad d i s o n -We s l e y, 1993.
[ BOO86] Bo o c h, G "Obje c t -Or i e n t e d De ve l o pm e n t ", e n IEE Trans. Software Engineering, vo l . SE-
12, n m . 2, f e br e r o d e 1986, pp. 21 l f f .
[ BUD96] Bu d d , T., An Introduction to Objetc- Oriented Programming, 2a . e d ., Ad d i s o n -We s l e y,
1996.
[ CAS89] Ca s hm a n , M., "Obje c t -Or i e n t e d Do m a i n An a l ys i s ", e n ACM Software Engineering Notes,
vo l . 14, n m . 6, o c t u br e d e 1989, p. 67.
[ CHA93] d e Cha m pe a u x, D., D. Le a y P. Fa u r e , Object- Oriented Sy stem Development, Ad d i s o n -
We s l e y, 1993.
[ CHE77] Che n , P., The Entity - Relationship Approach to Logical Database Design, QED In f o r m a t i o n
Sys t e m s , 1977.
[ COA91] Co a d , P. y E. Yo u r d o n , Object- Oriented Analy sis, 2a . e d ., Pr e n t i c e -Ha l l , 1991.
[ COCO 1 ] Co c k bu r n , A., Writing Effective Use Cases, Ad d i s o n -We s l e y, 2001.
[ DAV93] Da vi s , A Software Requirements: Objects, Functions and States, Pr e n t i c e -Ha l l , 1993.
[ DEM79] De Ma r c o , T., Structured Analy sis and Sy stem Speciftcation, Pr e n t i c e -Ha l l , 1979
[ FIR93] Fi r e s m i t h, D. G., Object- Oriented Requirements Analy sis and Logical Design, Wi l e y, 1993.
[ LET03] Le t hbr i d ge , T., c o m u n i c a c i n pe r s o n a l s o br e e l a n l i s i s d e l d o m i n i o , m a yo d e 2003.
[ OMG03] Obje c t Ma n a ge m e n t Gr o u p, OMG Un i f i e d Mo d e l i n g La n gu a ge Spe c i f i c a t i o n , ve r s i n
1.5, m a r zo d e 2003, d i s po n i bl e e n ht t p: / / www. r a t i o n a l . c o m / u m l / r e s o u r c e s / d o c u m e n t a -
t i o n / .
[ SCH02] Sc hm u l l e r , J., Teach Yoursel/UML in 2 4 Hours, 2a . e d ., SAMS Pu bl i s hi n g 2002.
[ SCH98J Sc hn e i d e r , G. y J. Wi n t e r s , Apply ing Use Cases, Ad d i s o n -We s l e y, 1998.
[ STR88] St r o u s t r u p, B., "Wha t i s Obje c t -Or i e n t e d Pr o gr a m m i n g?", e n IEEE So f t wa r e , vo l . 5, n m .
3, m a yo d e 1988, pp. 10-20.
[ TAY90] Ta yl o r , D. A., Object- Oriented Technology : A Manager s Guide, Ad d i s o n -We s l e y, 1990.
[ THA00] Tha l he i m , B Entity Relationship Modeling, Spr i n ge r -Ve r l a g, 2000.
[ TIL931 Ti l l m a n n , G., A Practical Guide to Logical Data Modeling, Mc Gr a w-Hi l l , 1993.
[ UML03] The UML Ca f , "Cu s t o m e r s Do n ' t Pr i n t The m s e l ve s ", d i s po n i bl e e n ht t p: / / www
t he u m l c a f e . c o m / a 0079. ht m , m a yo d e 2003.
( WIR90) Wi r f s -Br o c k , R., B. Wi l k e r s o n y L. We i n e r , Designing Object- Oriented Software, Pr e n t i c e -
Ha l l , 1990.
8. 1. Es po s i bl e c o m e n za r a c o d i f i c a r i n m e d i a t a m e n t e d e s pu s d e ha be r c r e a d o e l m o d e l o d e
a n l i s i s ? Expl i c a r l a r e s pu e s t a y d e s pu s ju s t i f i c a r l o s pu n t o s e n c o n t r a .
TM
PDF Editor
8 . 2 . Un a n l i s i s pr c t i c o e s a q u e l e n e l c u a l e l m o d e l o "d e be e n f o c a r s e e n l o s r e q u i s i t o s q u e
s o n vi s i bl e s d e n t r o d e l o s d o m i n i o s d e l pr o bl e m a o d e l n e go c i o ". Cu l e s t i po s d e r e q u i s i t o s nc
s o n vi s i bl e s e n e s t o s d o m i n i o s ? Da r a l gu n o s e j e m pl o s .
8. 3. Cu l e s e l pr o ps i t o d e l a n l i s i s d e l d o m i n i o ? Cm o s e r e l a c i o n a c o n e l c o n c e pt o d e l o s
pa t r o n e s d e r e q u i s i t o s ?
8. 4. En u n a s c u a n t a s l n e a s , t r t e s e d e d e s c r i bi r l a s d i f e r e n c i a s pr i m o r d i a l e s e n t r e e l a n l i s i s
e s t r u c t u r a d o y e l a n l i s i s o r i e n t a d o a o bj e t o s .
8. 5. Es po s i bl e d e s a r r o l l a r u n m o d e l o d e a n l i s i s e f i c a z s i n d e s a r r o l l a r l o s c u a t r o e l e m e n t o s
q u e s e m u e s t r a n e n l a f i gu r a 8.3? Expl i c a r l a r e s pu e s t a .
8. 6. Su pn ga s e q u e ha n pe d i d o c o n s t r u i r u n o d e l o s s i gu i e n t e s s i s t e m a s .
a ) Un r e gi s t r o d e c u r s o s ba s a d o e n r e d pa r a u n a u n i ve r s i d a d .
b) Un s i s t e m a pr o c e s a d o r d e r d e n e s ba s a d o e n In t e r n e t pa r a u n a t i e n d a d e c o m pu t a d o r a s
c) Un s i s t e m a s i m pl e d e f a c t u r a c i n pa r a u n n e go c i o pe q u e o .
d) El s o f t wa r e q u e r e e m pl a c e u n Ro l o d e x y q u e s e e n c u e n t r e d e n t r o d e u n t e l f o n o i n a l m -
br i c o .
e) Un l i br o d e c o c i n a a u t o m t i c o q u e e s t c o n s t r u i d o d e n t r o d e u n ho r n o e l c t r i c o o d e
m i c r o o n d a s .
Se l e c c i n e s e e l s i s t e m a q u e s e c o n s i d e r e i n t e r e s a n t e y d e s c r ba n s e s u s o bj e t o s d e d a t o s , r e l a -
c i o n e s y a t r i bu t o s .
8. 7. Di bu ja r u n m o d e l o a l n i ve l d e c o n t e xt o ( DFD d e n i ve l 0) pa r a u n o d e l o s c i n c o s i s t e m a s q u e
s e l i s t a n e n e l pr o bl e m a 8.6. Es c r i bi r u n a n a r r a t i va d e l pr o c e s a m i e n t o pa r a e l s i s t e m a a l n i ve l d e
c o n t e xt o .
8. 8. Ut i l i za r e l DFD a l n i ve l d e c o n t e xt o d e s a r r o l l a d o e n e l pr o bl e m a 8.7 pa r a d i bu j a r l o s d i a -
gr a m a s d e ( l u jo d e l o s n i ve l e s 1 y 2. Pa r a c o m e n za r , u t i l c e s e u n "a n l i s i s gr a m a t i c a l " e n l a
n a r r a t i va d e l pr o c e s a m i e n t o a l n i ve l d e c o n t e xt o . Re c u r d e s e e s pe c i f i c a r t o d o e l f l u i d o d e i n f o r -
m a c i n m i e n t r a s r o t u l a t o d a s l a s f l e c ha s q u e s e e n c u e n t r a n e n t r e l a s bu r bu j a s . s e n s e n o m br e s
s i gn i f i c a t i vo s pa r a c a d a t r a n s f o r m a c i n .
8. 9. De s a r r l l e n s e e s pe c i f i c a c i o n e s d e c o n t r o l ( EC) y e s pe c i f i c a c i o n e s d e pr o c e s o ( EP) pa r a e :
s i s t e m a q u e s e l e c c i o n e n e l pr o bl e m a 8.6. Tr t e s e d e q u e e l m o d e l o s e a l o m s c o m pl e t o po s i -
bl e .
8 . 1 0 . El d e pa r t a m e n t o d e o br a s pbl i c a s d e u n a c i u d a d gr a n d e ha d e c i d i d o d e s a r r o l l a r u n s i s -
t e m a d e r a s t r e o y r e pa r a c i n d e ba c he s ba s a d o e n l a We b ( SRRB). Se i n c l u ye l a s i gu i e n t e d e s -
c r i pc i n :
Lo s c i u d a d a n o s pu e d e n e n t r a r a l s i t i o We b y r e po r t a r l a u bi c a c i n y s e ve r i d a d d e l o s
ba c he s . Cu a n d o s t o s s e r e po r t a n e n t r a n a u n "s i s t e m a d e r e pa r a c i n d e l d e pa r t a m e n t o d e
o br a s pbl i c a s ", d o n d e s e l e s a s i gn a u n n m e r o d e i d e n t i f i c a c i n , ju n t o c o n l a d i r e c c i n d e l a
c a l l e , e l t a m a o ( e n u n a e s c a l a d e 0 a 10), l a u bi c a c i n ( e n l a o r i l l a d e l a c a l l e , e n m e d i o ,
e t c t e r a ), e l d i s t r i t o ( d e t e r m i n a d o po r l a d i r e c c i n d e l a c a l l e ), y l a u r ge n c i a d e l a r e pa r a -
c i n ( d e t e r m i n a d a po r e l t a m a o d e l ba c he ). Lo s d a t o s d e l a o r d e n d e t r a ba j o e s t n a s o -
c i a d o s c o n c a d a ba c he e i n c l u ye n l a u bi c a c i n y e l t a m a o d e l ba c he , n m e r o d e i d e n t i f i -
c a c i n d e l a r e pa r a c i n , c a n t i d a d d e pe r s o n a l n e c e s a r i o , ho r a s a pl i c a d a s a l a r e pa r a c i n ,
e s t a d o d e l ba c he ( t r a ba j o e n pr o gr e s o , r e pa r a d o , r e pa r a d o e n f o r m a t e m po r a l , n o r e pa r a -
d o ), c a n t i d a d d e m a t e r i a l d e r e l l e n o u t i l i za d o , y c o s t o d e l a r e pa r a c i n ( c l c u l o d e l a s ho r a s
a pl i c a d a s , n m e r o d e pe r s o n a s , m a t e r i a l y e q u i po u t i l i za d o s ). Po r l t i m o , s e c r e a u n a r c hi -
vo d e d a o s pa r a r e gi s t r a r i n f o r m a c i n s o br e a ve r a s r e po r t a d a s d e bi d o a l o s ba c he s , e l
c u a l i n c l u ye n o m br e d e l c i u d a d a n o , d i r e c c i n , n m e r o t e l e f n i c o , t i po d e d a o , pr e c i o d e l
d a o e n d l a r e s . El SRRB e s u n s i s t e m a ba s a d o e n l a We b; t o d a s l a s pe t i c i o n e s s e ha c e n
e n f o r m a i n t e r a c t i va .
Co n ba s e e n u n a n o t a c i n d e a n l i s i s e s t r u c t u r a d a , d e s a r r o l l e u n m o d e l o d e a n l i s i s pa r a e l
SRRB.
TM
PDF Editor
8.11. De s c r i bi r l o s t r m i n o s o r i e n t a d o s a o bj e t o s encapsulacirt y herencia.
8. 12. Es c r i bi r u n c a s o d e u s o ba s a d o e n u n a pl a n t i l l a pa r a e l s i s t e m a d e ge s t i n pa r a e l ho ga r
HogarSeguro, d e s c r i t o d e m a n e r a i n f o r m a l e n u n r e c u a d r o u bi c a d o e n s e gu i d a d e l a s e c c i n
8.7.4.
8. 13. Di bu ja r u n d i a gr a m a d e c a s o d e u s o e n UML pa r a e l s i s t e m a SRRB pr e s e n t a d o e n e l pr o -
bl e m a 8. 10. Te n d r n q u e ha c e r s e va r i o s s u pu e s t o s s o br e l a m a n e r a e n q u e e l u s u a r i o i n t e r a c -
t a c o n e s t e s i s t e m a .
8. 14. De s a r r o l l a r u n m o d e l o d e c l a s e pa r a e l s i s t e m a SRRB pr e s e n t a d o e n e l pr o bl e m a 8.10.
8. 15. De s a r r o l l a r u n c o n j u n t o c o m pl e t o d e t a r j e t a s n d i c e d e l m o d e l o CRC pa r a e l s i s t e m a SRRB
pr e s e n t a d o e n e l pr o bl e m a 8.10.
8. 16. En c a be za r u n a r e vi s i n d e l a s t a r j e t a s n d i c e d e CRC c o n s u s c o l e ga s . Cu n t a s c l a s e s
a d i c i o n a l e s , r e s po n s a bi l i d a d e s y c o l a bo r a d o r e s f u e r o n a gr e ga d o s c o m o c o n s e c u e n c i a d e l a r e vi -
s i n ?
8. 17. De s c r i bi r l a d i f e r e n c i a e n t r e u n a a s o c i a c i n y u n a d e pe n d e n c i a pa r a u n a c l a s e d e a n l i -
s i s .
8. 18. Qu e s u n pa q u e t e d e a n l i s i s y c m o d e be u t i l i za r s e ?
8. 19. De q u m a n e r a d i f i e r e u n d i a gr a m a d e e s t a d o pa r a c l a s e s d e a n l i s i s d e l o s d i a gr a m a s
d e e s t a d o pr e s e n t a d o s pa r a e l s i s t e m a c o m pl e t o ?
*
Se ha n pu bl i c a d o d o c e n a s d e l i br o s s o br e a n l i s i s e s t r u c t u r a d o . En l a m a yo r a s e t r a t a e l t e m a
d e u n a m a n e r a a d e c u a d a , pe r o s l o e n u n o s c u a n t o s s e pr e s e n t a u n t r a ba j o e n ve r d a d e xc e -
l e n t e . De Ma r c o y Pl a u ge r ( Structured Analy sis and Sy stem Specification, Pe a r s o n , 1985) e s u n c l -
s i c o q u e s i gu e s i e n d o u n a bu e n a i n t r o d u c c i n a l a n o t a c i n bs i c a . Lo s l i br o s d e Ke n d a l y
Ke n d a l (Sy stems Analy sis and Design, 5a . e d ., Pr e n t i c e -Ha l l , 2002) y Ho f f e r e al. (Modern Sy stems
Analy sis and Design, Ad d i s o n -We s l e y, 3a . e d ., 2001) s o n r e f e r e n c i a s va l i o s a s . El l i br o d e Yo u r d o n
(Modern Structured Analy sis, Yo u r d o n -Pr e s s , 1989) s o br e e l t e m a s e c o n s e r va e n t r e l a s pu bl i c a -
c i o n e s m s c o m pl e t a s a l a f e c ha .
Al i e n ( Da t o Modeling for Every one, Wr o x Pr e s s , 2002), Si m ps o n y Wi t t ( Data Modeling
Essentials, 2a . e d ., Co r i o l i s Gr o u p, 2000), Re i n gr u be r y Gr e go r y ( Data Modeling Handbook , Wi l e y,
1995) pr e s e n t a n gu a s d e t a l l a d a s pa r a c r e a r m o d e l o s d e d a t o s r e l a c i o n a d o s c o n l a c a l i d a d
i n d u s t r i a l . Un i n t e r e s a n t e l i br o d e Ha y ( Da t o Modeling Patterns, Do r s e t Ho u s e , 1995) pr e s e n t a
pa t r o n e s d e m o d e l o s d e d a t o s t pi c o s q u e s e e n c u e n t r a n e n m u c ho s n e go c i o s d i f e r e n t e s . Un t r a -
t a m i e n t o d e t a l l a d o d e l m o d e l a d o d e l c o m po r t a m i e n t o pu e d e e n c o n t r a r s e e n Ko wa l (Behavior
Models: Spejy ing User's Expectations, Pr e n t i c e -Ha l l , 1992).
Lo s c a s o s d e u s o s o n l a ba s e d e l a n l i s i s o r i e n t a d o a o bje t o s . Lo s l i br o s d e Bi t t n e r y Spe n c e
( Us e Case Modeling, Ad d i s o n -We s l e y, 2002), Co c k bu r n [ COCOl ] , Ar m o u r y Mi l l e r {Advanced Use-
Case Modeling: Software Sy stems, Ad d i s o n -We s l e y, 2000) y Ro s e m be r g y Sc o t (Use- Case Driven
Object Modeling with UML: A Practical Approach, Ad d i s o n -We s l e y, 1999) pr o po r c i o n a n u n a gu a
va l i o s a e n l a c r e a c i n y u s o d e e s t e i m po r t a n t e m e c a n i s m o d e r e pr e s e n t a c i n y l o gr o d e r e q u e -
r i m i e n t o s .
Ar l o w y Ne u s t a d t ha n e s c r i t o a pr e c i a bl e s a n l i s i s d e l UML [ ARL02] , Sc hm u l l e r [ SCH02] ,
Fo wl e r y Sc o t t ( UML Distilled, 2a . e d ., Ad d i s o n -We s l e y, 1999), Bo o c h y s u s c o l e ga s (The UML User
Cuide, Ad d i s o n -We s l e y, 1998) y Ru m ba u gh y s u s c o l e ga s (The Unified Modeling Language
Reference Manual, Ad d i s o n -We s l e y, 1998).
Lo s m t o d o s d e a n l i s i s y d i s e o q u e a po ya n e l pr o c e s o u n i f i c a d o l o s e xpl i c a La r m a n
(Appfy ing UML and Pattems: An Introducon to Object- Oriented Analy sis and Design and the Unified
process, 2a . e d ., Pr e n t i c e -Ha l l , 2001), De n n i s y s u s c o l e ga s ( Siy stem Analy sis and Design: An
Object- Oriented Approach with UML, Wi l e y, 2001), y Ro s e n be r g y Sc o t t (Use- Case Driven Object
Modeling with UML, Ad d i s o n -We s l e y, 1999), Ba l c e r y Me l l o r (Executable UML: A Foundation for
TM
PDF Editor
Model Driven Architecture, Ad d i s o n -We s l e y, 2002) e xpo n e n l a s e m n t i c a ge n e r a l d e l UML, l o s
m o d e l o s q u e s e pu e d e n c r e a r , y u n a f o r m a d e c o n s i d e r a r e l UML c o m o u n l e n gu a j e e je c u t a bl e
St a r r ( Executable UML: How to Build Class Models, Pr e n t i c e -Ha l l , 2001) o f r e c e u n a gu i a t i l y
s u ge r e n c i a s d e t a l l a d a s pa r a c r e a r c l a s e s d e d i s e o y a n l i s i s e f e c t i vo s .
En In t e r n e t s e d i s po n e d e u n a gr a n va r i e d a d d e f u e n t e s d e i n f o r m a c i n s o br e e l m o d e l a d o
d e l a n l i s i s . En e l s i t i o SEPA s e pu e d e e n c o n t r a r u n a l i s t a a c t u a l i za d a d e r e f e r e n c i a s d e l a r e d
q u e s o n n o t a bl e s pa r a e l m o d e l a d o d e l a n l i s i s :
ht t p: / / www. mhhe . c o m/ pr e s s ma n.
TM
PDF Editor
C A P T U L O
I NGENI ER A
DEL DI SEO 9
I CEPTOS
r e
....252
t m . . .253
i * ....259
....259
W ...262
....256
...254
it
...256
254
m . , . 258
>...257
L
a i n ge n i e r a d e l d i s e o a ba r c a u n c o n j u n t o d e pr i n c i pi o s , c o n c e pt o s y pr c -
t i c a s q u e c o n d u c e n a l d e s a r r o l l o d e u n s i s t e m a o pr o d u c t o d e a l t a c a l i d a d .
Lo s pr i n c i pi o s d e l d i s e o ( e xpl i c a d o s e n e l c a p t u l o 5) e s t a bl e c e n u n a f i l o -
s o f a pr i m o r d i a l q u e gu a n a l d i s e a d o r e n e l t r a ba j o q u e d e s e m pe a . Es n e c e s a -
r i o c o m pr e n d e r l o s c o n c e pt o s d e l d i s e o a n t e s d e q u e s e a pl i q u e n l a s m e c n i c a s
d e l a pr c t i c a d e l d i s e o , y l a pr c t i c a d e l d i s e o m i s m o c o n d u c e a l a c r e a c i n d e
va r i a s r e pr e s e n t a c i o n e s d e l s o f t wa r e , e l c u a l s i r ve c o m o gu a pa r a l a a c t i vi d a d d e
c o n s t r u c c i n q u e s i gu e .
La ingenier a del diseo n o e s u n a f r a s e c o m n d e n t r o d e l c o n t e xt o d e l a i n ge -
n i e r a d e l s o f t wa r e . Si n e m ba r go , d e be r a s e r l o . El d i s e o e s u n a a c t i vi d a d pr i -
m o r d i a l d e l a i n ge n i e r a . A pr i n c i pi o s d e l a d c a d a d e 1990, Mi t c h Ka po r , e l c r e a -
d o r d e Lo t u s 1-2-3, pr e s e n t u n "m a n i f i e s t o s o br e e l d i s e o d e s o f t wa r e " e n Dr.
Dobbs Journal. Ah a f i r m a :
Qu e s e l d i s e o ? Es e l l u ga r e n d o n d e u n a pe r s o n a s e pu e d e pa r a r c o n u n pi e e n
d o s m u n d o s e l m u n d o d e l a t e c n o l o g a y e l d e l a ge n t e y l o s pr o ps i t o s hu m a n o s
e i n t e n t a u n i r l o s ...
El c r t i c o d e a r q u i t e c t u r a r o m a n a Vi t r u vi u s a po r t l a n o c i n d e q u e l a s c o n s t r u c -
c i o n e s bi e n d i s e a d a s e r a n a q u e l l a s q u e m o s t r a ba n f i r m e za , c o m o d i d a d y pl a c e r . Lo
m i s m o d e be d e c i r s e d e l bu e n s o f t wa r e . Firmeza e l pr o gr a m a n o d e be t e n e r n i n gn
e r r o r q u e i n hi ba s u f u n c i n . Comodidad- , u n pr o gr a m a d e be c u m pl i r c o n l o s pr o ps i -
t o s pa r a l o s q u e f u e c r e a d o . Placer l a e xpe r i e n c i a d e u s a r e l pr o gr a m a d e be s e r a gr a
d a bl e . Aq u s e pr e s e n t a n l o s pr i n c i pi o s d e u n a t e o r a d e d i s e o pa r a s o f t wa r e .
Qu e s ? El d i s e o e s l o q u e c a s i
c u a l q u i e r i n ge n i e r o q u i e r e ha c e r . Es
e l s i t i o d o n d e m a n d a l a c r e a t i vi d a d ,
d o n d e l o s r e q u i s i t o s d e l c l i e n t e , l a s
n e c e s i d a d e s d e n e go c i o y l a s c o n s i -
d e r a c i o n e s t c n i c a s s e u n e n e n l a f o r m u l a c i n
d e u n pr o d u c t o o s i s t e m a . El d i s e o c r e a u n a
- pr e s e n t a c i n o m o d e l o d e l s o f t wa r e , pe r o a
3f e r e n c i a d e l m o d e l o d e a n l i s i s ( q u e s e e n f o c a
e n la d e s c r i pc i n d e l o s d a t o s , l a s f u n c i o n e s y e l
o m po r t a m i e n t o r e q u e r i d o s ), e l m o d e l o d e d i s e -
o pr o po r c i o n a d e t a l l e s a c e r c a d e l a s e s t r u c t u -
-a s d e d a t o s , l a s a r q u i t e c t u r a s , l a s n t e r f a c e s y
o s c o m po n e n t e s d e l s o f t wa r e q u e s o n n e c e s a r i o s
r a r a i m pl e m e n t a r e l s i s t e m a .
Qu i n l o h a c e ? Los i n ge n i e r o s d e s o f t wa r e
e n c a be za n c a d a u n a d e l a s t a r e a s d e d i s e o .
Po r q u e s i m p o r t a n t e ? El d i s e o pe r m i t e a l
i n ge n i e r o d e s o f t wa r e m o d e l a r e l s i s t e m a o pr o -
d u c t o q u e s e va a c o n s t r u i r . Es t e m o d e l o pu e d e
e va l u a r s e e n r e l a c i n c o n s u c a l i d a d y m e jo r a r -
s e a n t e s d e ge n e r a r c d i go , d e r e a l i za r pr u e ba s
y d e q u e l o s u s u a r i o s f i n a l e s s e ve a n i n vo l u c r a -
d o s a gr a n e s c a l a . El d i s e o e s e l s i t i o e n e l q u e
s e e s t a bl e c e l a c a l i d a d d e l s o f t wa r e .
Cu l e s s o n l o s p a s o s ? El d i s e o pr e s e n t a e l
s o f t wa r e d e d i f e r e n t e s f o r m a s . Pr i m e r o , d e be
r e pr e s e n t a r s e l a a r q u i t e c t u r a d e l s i s t e m a o pr o -
d u c t o . De s pu s , s e m o d e l a n l a s n t e r f a c e s q u e
c o n e c t a " e s o f t wa r e c o n l o s u s u a r i o s f i n a l e s ,
245
TM
PDF Editor
c o n o t r o s s i s t e m a s y d i s po s i t i vo s y c o n l o s pr o -
pi o s c o m po n e n t e s q u e l o c o n s t i t u ye n . Po r l t i m o ,
s e d i s e a n l o s c o m po n e n t e s d e l s o f t wa r e q u e s e
u t i l i za r n e n l a c o n s t r u c c i n d e l e l s i s t e m a . Ca d a
u n a d e e s t a s vi s i o n e s r e pr e s e n t a u n a a c c i n d e
d i s e o d i f e r e n t e , pe r o t o d a s d e be n a ju s t a r s e a
u n c o n ju n t o d e c o n c e pt o s bs i c o s d e l d i s e o q u e
d e t e r m i n a n t o d o e l t r a ba jo d e d i s e o .
Cu l e s e l pr o d u c t o o b r e n i d o ? Un m o d e l o
q u e a ba r c a r e pr e s e n t a c i o n e s a r q u i t e c t n i c a s , d e
i n t e r f a z, e n e ! n i ve l d e c o m po n e n t e s y d e d e s -
pl i e gu e . >/ -
Cmo p u e d o es t ar s e gur o de que lo he
hecho correct ament e? El m o d e l o d e d i s e ; :
l o e va l a e ! e q u i po d e s o f t wa r e e n u n e s f u e r :
e n c a m i n a d o a d e t e r m i n a r si s t e c o n t i e n e e r r
r e s , i n c o n s i s t e n c i a s u o m i s i o n e s ; si e xi s t e n m e -
r e s a l t e r n a t i va s ; y si e l m o d e l o pu e d e i m pl e m -
t a r s e d e n t r o d e l a s r e s t r i c c i o n e s , e l i t i n e r a r i o \ i
c o s t o q u e Ha n s i d o e s t a bl e c i d o s . C
La m e t a d e l a i n ge n i e r a d e l d i s e o e s pr o d u c i r u n m o d e l o d e r e pr e s e n t a d o r , :M
m u e s t r e f i r m e za , c o m o d i d a d y pl a c e r . Pa r a l o gr a r l o , u n d i s e a d o r d e be pr a c t i c a -
d i ve r s i f i c a c i n y d e s pu s l a c o n ve r ge n c i a . Be l a d y [ BEL81] e s t a bl e c e q u e "l a d i ve J
f i c a c i n e s l a a d q u i s i c i n d e u n r e pe r t o r i o d e a l t e r n a t i va s , l a m a t e r i a pr i m a d e l . s i
o : c o m po n e n t e s , s o l u c i o n e s d e c o m po n e n t e s y c o n o c i m i e n t o , t o d o c o n t e n i d c :
c a t l o go s , l i br o s d e t e xt o y e n l a m e n t e ". Un a ve z q u e s e ha i n t e gr a d o e s t e c o n j _ - j a
d e i n f o r m a c i n , e l d i s e a d o r d e be e l e gi r y t o m a r e l e m e n t o s d e l r e pe r t o r i o q u e
pl a n l o s r e q u i s i t o s d e f i n i d o s po r l a i n ge n i e r a d e r e q u i s i t o s ( c a p t u l o 7) y e l m o c e B
d e a n l i s i s ( c a p t u l o 8). Cu a n d o e s t o o c u r r e , s e c o n s i d e r a n y s e r e c ha za n l a s al t ea
n a t i va s , y e l i n ge n i e r o d e d i s e o c o n ve r ge e n "u n a c o n f i gu r a c i n pa r t i c u l a r d e c c o B
po n e n t e s y, po r l o t a n t o , e n l a c r e a c i n d e l pr o d u c t o f i n a l " [ BEL81] ,
La d i ve r s i f i c a c i n y l a c o n ve r ge n c i a d e m a n d a n i n t u i c i n y ju i c i o . Es t a s c u a l i d a ; J
e s t n ba s a d a s e n l a e xpe r i e n c i a d e c o n s t r u i r e n t i d a d e s s i m i l a r e s , u n c o n j u n t o
pr i n c i pi o s q u e gu a n c m o e vo l u c i o n a e l m o d e l o , u n c o n j u n t o d e c r i t e r i o s q u e p e J
m i t e n j u zga r l a c a l i d a d , y u n pr o c e s o d e i t e r a c i n q u e c o n d u c e a u n a r e pr e s e n t a r
d e l d i s e o f i n a l .
La i n ge n i e r a d e l d i s e o pa r a e l s o f t wa r e d e c o m pu t a d o r a e s t e n u n c a m bi o CCOH
t i n u o , e n l a m e d i d a e n q u e e vo l u c i o n a n m e j o r e s m t o d o s , m e j o r e s a n l i s i s y - J
c o m pr e n s i n m s a m pl i a . Au n e n l a a c t u a l i d a d , l a m a yo r a d e l a s m e t o d o l o g a s
d i s e o d e s o f t wa r e c a r e c e n d e pr o f u n d i d a d , f l e xi bi l i d a d y n a t u r a l e za c u a n t i t a t r . a.,
q u e po r l o ge n e r a l s e a s o c i a n c o n d i s c i pl i n a s d e d i s e o d e i n ge n i e r a m s c l s i c a I
Si n e m ba r go , e xi s t e n m t o d o s pa r a e l d i s e o d e s o f t wa r e , s e d i s po n e d e c r i t e - :
pa r a l a c a l i d a d d e l d i s e o , y e s po s i bl e a pl i c a r n o t a c i n d e d i s e o . En e s t e c a pi t
s e e xpl o r a r n l o s c o n c e pt o s y pr i n c i pi o s f u n d a m e n t a l e s a pl i c a bl e s a t o d o e l d i s e J
d e s o f t wa r e , l o s e l e m e n t o s d e l m o d e l o d e l d i s e o y e l i m pa c t o d e l o s pa t r o n e s s o t J
e l pr o c e s o d e d i s e o . En l o s c a p t u l o s 10, 11 y 12 s e e xa m i n a u n a va r i e d a d d e m : : -
d o s d e d i s e o d e s o f t wa r e m i e n t r a s s e a pl i c a n a l d i s e o a r q u i t e c t n i c o , d e i n t e r a J
y e n e l n i ve l d e c o m po n e n t e s .
TM
PDF Editor
C A P T U L O 9 INGENIERA DEL DISEO 247
t i n e n t o s b a s a d o s
e n e s c e n a r i o s
Di a gr a m a s d e f l u jo d e d a l o s
Di a gr a m a s d e f l u jo d e c o n t r o l
Na r r a t i va s d e pr o c e s a m i e n t o
r a m a s
i r a m a s
ira m a s
Di s e o d e i n t e r f a z
Mo d e l o d e a n l i s i s J
El e m e n t o s d e
Di a gr a m a s d e e s t a d o
Di a gr a m a s d e
s e c u e n c i a
Di s e o a r q u i t e c t n i c o
Di s e o d e d a t o s / d a s e
9 . 1 DI SEO DENTRO DEL CONTEXTO DE LA I NGENI ER A DEL SOFTWARE
*
ide
tsiempre
r r a r wf e -
ipara
tos
del diseo,
t que se ha
i fundo-
i x b e
laaquitec-
:9 toncesse
r otras
( seo.
El d i s e o d e l s o f t wa r e s e e n c u e n t r a e n e l n c l e o t c n i c o d e l a r e s pe c t i va i n ge n i e r a
y s e a pl i c a d e m a n e r a i n d e pe n d i e n t e a l m o d e l o d e s o f t wa r e q u e s e u t i l i c e . Un a ve z
q u e s e a n a l i za n y e s pe c i f i c a n l o s r e q u i s i t o s , e l d i s e o d e l s o f t wa r e e s l a l t i m a
a c c i n d e l a i n ge n i e r a c o r r e s po n d i e n t e d e n t r o d e l a a c t i vi d a d d e l m o d e l a d o , l a c u a l
e s t a bl e c e u n a pl a t a f o r m a pa r a l a c o n s t r u c c i n ( ge n e r a c i n d e c d i go y pr u e ba s ).
"El m i l a gr o m s c o m n d e l a i n ge n i e r a d e s o f t wa r e e s l a t r a n s i c i n d e l a n l i s i s a l c s e o y d e l d i s e o a l c d i go . "
Ri c ha r d Du e
Ca d a u n o d e l o s e l e m e n t o s d e l m o d e l o d e a n l i s i s ( c a p t u l o 8) pr o po r c i o n a l a
i n f o r m a c i n n e c e s a r i a pa r a c r e a r l o s c u a t r o m o d e l o s d e d i s e o q u e s e r e q u i e r e n
pa r a u n a e s pe c i f i c a c i n c o m pl e t a d e d i s e o . En l a f i gu r a 9.1 s e i l u s t r a e l f l u jo d e
i n f o r m a c i n d u r a n t e e l d i s e o d e l s o f t wa r e . Lo s r e q u i s i t o s d e l s o f t wa r e q u e m u e s -
t r a n l o s e l e m e n t o s ba s a d o s e n e s c e n a r i o s , ba s a d o s e n c l a s e s , o r i e n t a d o s a l f l u jo y d e
c o m po r t a m i e n t o a l i m e n t a n l a t a r e a d e d i s e o . Me d i a n t e l a n o t a c i n d e d i s e o y d e l o s
m t o d o s d e d i s e o q u e s e e xpo n e n e n c a p t u l o s po s t e r i o r e s , l a t a r e a d e d i s e o pr o -
d u c e u n d i s e o d e d a t o s -c l a s e , u n d i s e o a r q u i t e c t n i c o , u n d i s e o d e i n t e r f a z y u n
d i s e o d e c o m po n e n t e s .
El d i s e o d e d a t o s -c l a s e t r a n s f o r m a l o s m o d e l o s d e a n l i s i s y c l a s e s ( c a p t u l o 8)
e n l a s c l a s e s d e d i s e o y l a s e s t r u c t u r a s d e d a t o s q u e s e r e q u i e r e n pa r a i m pl e m e n -
Trcmsformacln del modelo de anlisis en un modelo de diseo.
Di s e o e n e l n i ve l
d e c o m po n e n t e s
El e m e n t o s b a s a d o s
e n c l a s e s
>o gr a m a s d e c l a s e
; : q u e t e s d e a n l i s i s
vt o d e l o s CRC
D a gr a m a s d e c o l a bo r a c i n
Mo d e l o d e d i s e o
TM
PDF Editor
t a r e l s o f t wa r e . La s c l a s e s y r e l a c i o n e s q u e d e f i n e n l a s t a r j e t a s n d i c e CRC y e l c o n -
t e n i d o d e t a l l a d o d e d a t o s q u e m u e s t r a n l o s a t r i bu t o s d e c l a s e y o t r a s n o t a c i o n e s pr o -
po r c i o n a n l a ba s e pa r a l a a c t i vi d a d d e d i s e o d e d a t o s . Un a pa r t e d e l d i s e o d e c l a -
s e s pu e d e o c u r r i r e n c o n j u n t o c o n e l d i s e o d e l a a r q u i t e c t u r a d e l s o f t wa r e . El d i s e -
o d e c l a s e m s d e t a l l a d o s e r e a l i za a m e d i d a q u e s e d i s e a c a d a c o m po n e n t e d e l
s o f t wa r e .
El d i s e o a r q u i t e c t n i c o d e f i n e l a r e l a c i n e n t r e l o s e l e m e n t o s e s t r u c t u r a l e s m s
i m po r t a n t e s d e l s o f t wa r e , l o s e s t i l o s a r q u i t e c t n i c o s y pa t r o n e s d e d i s e o q u e pu e -
d e n u s a r s e pa r a s a t i s f a c e r l o s r e q u i s i t o s d e f i n i d o s po r e l s i s t e m a , y l a s r e s t r i c c i o n e s
q u e a f e c t a n l a m a n e r a e n q u e s e pu e d e n i m pl e m e n t a r l o s pa t r o n e s a r q u i t e c t n i c o s
[ SHA96] . La r e pr e s e n t a c i n d e l d i s e o a r q u i t e c t n i c o e l m a r c o d e t r a ba j o d e u n
s i s t e m a ba s a d o e n c o m pu t a d o r a pu e d e d e r i va r s e d e l a e s pe c i f i c a c i n d e l s i s t e m a ,
d e l m o d e l o d e a n l i s i s y d e l a i n t e r a c c i n d e l o s s u bs i s t e m a s d e f i n i d o s d e n t r o d e l
m o d e l o d e a n l i s i s .
El d i s e o d e l a i n t e r f a z d e s c r i be l a f o r m a e n q u e e l s o f t wa r e s e c o m u n i c a c o n l o s
s i s t e m a s q u e i n t e r a c t a n c o n l y c o n l o s hu m a n o s q u e l o s u t i l i za n . Un a i n t e r f a z
i m pl i c a u n f l u jo d e i n f o r m a c i n ( po r e je m pl o , d a t o s o c o n t r o l ) y u n t i po d e c o m po r -
t a m i e n t o e s pe c i f i c o . Po r l o t a n t o , l o s e s c e n a r i o s d e u s o y l o s m o d e l o s d e c o m po r t a -
m i e n t o pr o po r c i o n a n m u c ha d e l a i n f o r m a c i n q u e s e r e q u i e r e e n e l d i s e o d e l a
i n t e r f a z.
El d i s e o a l n i ve l d e c o m po n e n t e s t r a n s f o r m a l o s e l e m e n t o s e s t r u c t u r a l e s d e l a
a r q u i t e c t u r a d e l s o f t wa r e e n u n a d e s c r i pc i n pr o c e d i m e n t a l d e l o s c o m po n e n t e s d e
s t e . La i n f o r m a c i n o bt e n i d a d e l o s m o d e l o s ba s a d o s e n c l a s e s , l o s m o d e l o s d e f l u jo
y l o s m o d e l o s d e c o m po r t a m i e n t o s i r ve n c o m o ba s e pa r a e l d i s e o d e c o m po n e n t e s
"Exi s t e n d o s f o r m a s d e c o n s t r u i r u n d i s e o d e s o f t wa r e . Un a f o r m a e s ha c e r l o t a n s i m pl e q u e o b v i a m e n t e n o h a y
d e f i c i e n c i a s , y l o o t r a e s ha c e r l o t a n c o m pl i c a d o q u e n o e xi s t e n d e f i c i e n c i a s o bvi a s . El pr i m e r m t o d o e s m u c ho m s
d i f c i l . "
CA. R. Ho n r e
Du r a n t e e l d i s e o s e t o m a n d e c i s i o n e s q u e a l f i n a l i n c i d i r n e n e l xi t o d e l a c o n s -
t r u c c i n d e l s o f t wa r e , a s c o m o e n , c o n e l m i s m o gr a d o d e i m po r t a n c i a , l a f a c i l i d a d
c o n q u e e l s o f t wa r e pu e d e m a n t e n e r s e . Pe r o , po r q u e s t a n i m po r t a n t e e l d i s e o '
La i m po r t a n c i a d e l d i s e o d e l s o f t wa r e pu e d e d e s c r i bi r s e c o n u n a s o l a pa l a br a :
calidad. El d i s e o e s l a e t a pa e n l a q u e s e f o m e n t a r l a c a l i d a d e n l a i n ge n i e r a d e !
s o f t wa r e . El d i s e o pr o po r c i o n a l a s r e pr e s e n t a c i o n e s d e l s o f t wa r e s u s c e pt i bl e s d e
e va l u a r r e s pe c t o d e l a c a l i d a d . El d i s e o e s l a n i c a f o r m a e n q u e , d e m a n e r a e xa c -
t a , u n r e q u i s i t o d e l c l i e n t e s e pu e d e c o n ve r t i r e n u n s i s t e m a o pr o d u c t o d e s o f t wa r e
t e r m i n a d o . El d i s e o d e l s o f t wa r e s i r ve c o m o f u n d a m e n t o pa r a t o d a s l a s a c t i vi d a d e s
s u bs e c u e n t e s d e l a i n ge n i e r a d e l s o f t wa r e y d e l s o po r t e d e s t e . Si n d i s e o s e c o r r e
e l r i e s go d e c o n s t r u i r u n s i s t e m a i n e s t a bl e , e l c u a l f a l l a r c u a n d o s e r e a l i c e n c a m -
bi o s pe q u e o s ; q u e s e r d i f c i l d e pr o ba r ; c u ya c a l i d a d n o po d r e va l u a r s e s i n o ha s t a
TM
PDF Editor
e t a pa s t a r d a s d e l pr o c e s o d e l s o f t wa r e , c u a n d o q u e d a po c o t i e m po y ya s e ha ga s -
t a d o m u c ho d i n e r o e n l .
9 . 2 P ROCE S O Y CALI DAD DEL DI S EO
El d i s e o d e l s o f t wa r e e s u n pr o c e s o i t e r a t i vo m e d i a n t e e l c u a l l o s r e q u i s i t o s s e t r a -
d u c e n e n u n "pl a n o " pa r a c o n s t r u i r e l s o f t wa r e . Al i n i c i o , e l pl a n o r e pr e s e n t a u n a
vi s i n ho l s t i c a d e l s o f t wa r e . Es d e c i r , e l d i s e o s e r e pr e s e n t a e n u n gr a d o a l t o d e
a bs t r a c c i n , e l c u a l pu e d e r a s t r e a r s e d e m a n e r a d i r e c t a ha s t a c o n s e gu i r e l o bje t i vo
e s pe c f i c o d e l s i s t e m a y r e q u i s i t o s m s d e t a l l a d o s d e c o m po r t a m i e n t o , f u n c i o n a l e s y
d e d a t o s . A m e d i d a e n q u e o c u r r e n l a s i t e r a c i o n e s d e l d i s e o , u n r e f i n a m i e n t o s u b-
s i gu i e n t e c o n d u c e a r e pr e s e n t a c i o n e s d e l d i s e o a gr a d o s m u c ho m s ba j o s d e a bs -
t r a c c i n . Es t o s gr a d o s a n s e pu e d e n r a s t r e a r ha s t a l o s r e q u i s i t o s , pe r o l a c o n e xi n
e s m s s u t i l .
A t r a v s d e l pr o c e s o d e l d i s e o , l a c a l i d a d e n e vo l u c i n d e s t e s e e va l a c o n u n a
s e r i e d e r e vi s i o n e s t c n i c a s f o r m a l e s o c o n r e vi s i o n e s d e d i s e o e xpl i c a d a s e n e l
c a p t u l o 26. Mc Gl a u ghl i n [ MCG91] s u gi e r e t r e s c a r a c t e r s t i c a s q u e s i r ve n c o m o gu a
e n l a e va l u a c i n d e u n bu e n d i s e o :
El d i s e o d e be i m pl e m e n t a r t o d o s l o s r e q u i s i t o s e xpl c i t o s c o n t e n i d o s e n e l
m o d e l o d e a n l i s i s , y d e be a j u s t a r s e a t o d o s l o s r e q u i s i t o s i m pl c i t o s q u e
d e s e a e l c l i e n t e .
El d i s e o d e be s e r u n a gu a l e gi bl e y c o m pr e n s i bl e pa r a q u i e n e s ge n e r a n
c d i go y q u i e n e s r e a l i za n pr u e ba s y, e n c o n s e c u e n c i a , d a n s o po r t e a l
s o f t wa r e .
El d i s e o d e be pr o po r c i o n a r u n a i m a ge n c o m pl e t a d e l s o f t wa r e d a n d o
d i r e c c i n a l o s d o m i n i o s d e d a t o s , f u n c i o n a l e s y d e c o m po r t a m i e n t o d e s d e
u n a pe r s pe c t i va d e i m pl e m e n t a c i n .
Ca d a u n a d e e s t a s c a r a c t e r s t i c a s e s e n r e a l i d a d u n a m e t a d e l pr o c e s o d e d i s e o .
Pe r o , c m o s e a l c a n za c a d a u n a d e e l l a s ?
"Es c r i bi r u n a br i l l a n t e pi e za d e c d i go q u e f u n c i o n e e s u n a c o s a ; d i s e a r a l go q u e pu e d a s o po r t a r a l a r go pl a zo u n
n e go c i o e s o t r a m u y d i f e r e n t e ."
C Fe r gu s o i t
Di rect ri ces de cal i dad. Co n e l f i n d e e va l u a r l a c a l i d a d d e u n a r e pr e s e n t a c i n d e
d i s e o s e d e be n e s t a bl e c e r l o s c r i t e r i o s t c n i c o s pa r a u n bu e n d i s e o . En s e c c i o n e s
po s t e r i o r e s d e e s t e c a p t u l o s e e xpo n d r n l o s c o n c e pt o s d e d i s e o q u e t a m bi n s i r -
ve n c o m o c r i t e r i o s d e c a l i d a d d e l s o f t wa r e . Po r a ho r a s e pr e s e n t a n l a s s i gu i e n t e s
d i r e c t r i c e s :
1. Un d i s e o d e be pr e s e n t a r u n a e s t r u c t u r a a r q u i t e c t n i c a q u e a ) s e ha ya c r e a d o
m e d i a n t e pa t r o n e s d e d i s e o r e c o n o c i bl e s , b) l a i n t e gr e n c o m po n e n t e s q u e
TM
PDF Editor
* Cu l e s s o n
l a s c a r a c t e -
r s t i c a s d e u n
bu e n d i s e o ?
2.
3.
4.
e xhi ba n bu e n a s c a r a c t e r s t i c a s d e d i s e o ( s t a s s e e xpl i c a n m s a d e l a n t e e r
e s t e c a p t u l o ), y c) pu e d a i m pl e m e n t a r s e d e m a n e r a e vo l u t i va , ' pa r a q u e d e
e s t a f o r m a f a c i l i t e l a i m pl e m e n t a c i n y l a s pr u e ba s .
Un d i s e o d e be s e r m o d u l a r , e s t o e s , e l s o f t wa r e d e be r d i vi d i r s e d e m a n
l gi c a e n e l e m e n t o s o s u bs i s t e m a s .
Un d i s e o d e be c o n t e n e r d i s t i n t a s r e pr e s e n t a c i o n e s d e l o s d a t o s , l a a r q u i t e :
t u r a , l a s i n t e r f a c e s y l o s c o m po n e n t e s .
Un d i s e o d e be c o n d u c i r a e s t r u c t u r a s d e d a t o s q u e s e a n a pr o pi a d a s pa r a
c l a s e s q u e ha br n d e i m pl e m e n t a r s e y q u e pr o c e d a n d e pa t r o n e s d e d a t o s
c o n o c i bl e s .
5. Un d i s e o d e be c o n d u c i r a c o m po n e n t e s q u e pr e s e n t e n c a r a c t e r s t i c a s f>
n a l e s i n d e pe n d i e n t e s .
Un d i s e o d e be c o n d u c i r a i n t e r f a s e s q u e r e d u zc a n l a c o m pl e ji d a d d e l a s c c - ]
n e xi o n e s e n t r e l o s c o m po n e n t e s y e l a m bi e n t e e xt e r n o .
Un d i s e o d e be o bt e n e r s e po r m e d i o d e u n m t o d o r e pe t i bl e q u e s e ba s e e r
i n f o r m a c i n o bt e n i d a d u r a n t e e l a n l i s i s d e r e q u i s i t o s d e l s o f t wa r e .
Un d i s e o d e be r e pr e s e n t a r s e po r m e d i o d e u n a n o t a c i n q u e c o m u n i q u e c e
m a n e r a e f i c a z s u s i gn i f i c a d o .
6.
7.
8 .
Es t a s d i r e c t r i c e s d e d i s e o n o s e l o gr a n po r c a s u a l i d a d . El pr o c e s o d e d i s e o d e l
wa r e f o m e n t a e l bu e n d i s e o a pl i c a n d o pr i n c i pi o s f u n d a m e n t a l e s d e d i s e o ,
m e t o d o l o g a s i s t e m t i c a y u n a r e vi s i n c u i d a d o s a .
INFORMACIN
Evaluacin de la calidad del diseo: la revisin t cnica formal
ha c e r u n r e s u m e n d e l a t c n i c a e n e s t e pu n t o . Un a RTF e s
u n a r e u n i n q u e d i r i ge n m i e m br o s d e l e q u i po d e s o f t wa -e
Po r l o ge n e r a l pa r t i c i pa n d o s , t r e s o c u a t r o pe r s o n a s ,
d e pe n d e d e l m bi t o d e l a i n f o r m a c i n d e d i s e o q u e s e
r e vi s a r . Ca d a pe r s o n a d e s e m pe a u n pa pe l : e l l der de
revisin pl a n e a l a r e u n i n , e s t a bl e c e l a a ge n d a y d e s pu s
r e a l i za l a r e u n i n ; e l relator t o m a n o t a s pa r a q u e n a d a s e
o l vi d e ; e l productor e s l a pe r s o n a c u yo pr o d u c t o d e t r a ba -:
( po r e je m pl o , e l d i s e o d e u n c o m po n e n t e d e l s o f t wa r e ) s e
r e vi s a . An t e s d e l a r e u n i n , c a d a pe r s o n a e n e l e q u i po d e
r e vi s i n r e c i be u n a c o pi a d e l pr o d u c t o d e t r a ba j o d e l
El d i s e o e s i m po r t a n t e po r q u e pe r m i t e q u e u n
e q u i po d e s o f t wa r e e va l e l a c a l i d a d 2 d e l s o f t wa r e a n t e s
d e m pl e m e n t a r l o ; e s d e c i r , e n u n m o m e n t o e n e l q u e l o s
e r r o r e s , o m i s i o n e s o i n c o n s i s t e n c i a s s o n f c i l e s d e c o r r e gi r
y n o r e s u l t a n c a r a s . Pe r o c m o s e e va l a l a c a l i d a d
d u r a n t e e l d i s e o ? El s o f t wa r e n o s e pu e d e c o m pr o ba r
po r q u e n o e xi s t e u n s o f t wa r e e je c u t a bl e a l c u a l a pl i c a r l e
pr u e ba s . Qu d e be ha c e r s e ?
Du r a n t e e l d i s e o , l a c a l i d a d s e e va l a a l r e a l i za r u n a
s e r i e d e r e vi s i o n e s t c n i c a s f o r m a l e s (RTF). La s RTF s e
t r a t a n c o n d e t a l l e e n e l c a p t u l o 26, 3 pe r o r e s u l t a va l i o s o
V
1 Pa r a s i s t e m a s m s pe q u e o s a l gu n a s ve c e s e l d i s e o pu e d e d e s a r r o l l a r s e e n f o r m a l i n e a l .
2 Lo s f a c t o r e s d e c a l i d a d t r a t a d o s e n e l c a p t u l o 15 pu e d e n a yu d a r a l e q u i po d e r e vi s i n m i e n t r a s
e va l a l a c a l i d a d .
3 En e s t e pu n t o s e po d r a c o n s i d e r a r l a r e vi s i n d e l a s e c c i n 26.4. La s RTF s o n u n a pa r t e c r t i c a
pr o c e s o d e d i s e o y u n m e c a n i s m o i m po r t a n t e pa r a l o gr a r l a c a l i d a d d e l d i s e o .
TM
PDF Editor
s e l e pi d e q u e l o l e a e n bu s c a d e e r r o r e s ,
o a m bi ge d a d e s . Cu a n d o l a r e u n i n c o m i e n za ,
' e s d e t e c t a r t o d o s l o s pr o bl e m a s d e l pr o d u c t o
: pa r a q u e s t o s pu e d a n c o r r e gi r s e a n t e s d e q u e
c -n pl e m e n t a c i n . La RTF t i e n e u n a d u r a c i n t pi c a
d e e n t r e 9 0 m i n u t o s y d o s ho r a s . Al c o n c l u i r l a RTF, e l
e q u i po d e r e vi s i n d e t e r m i n a si s e r e q u i e r e n a c c i o n e s
po s t e r i o r e s po r pa r t e d e l pr o d u c t o r a n t e s d e q u e e l
pr o d u c t o d e t r a ba j o d e l d i s e o pu e d a a pr o ba r s e c o m o
pa r t e d e l m o d e l o d e d i s e o f i n a l .
A
"Lo c a l i d a d n o e s a l go q u e s e po i ga e n c i m a d e l o s s u je t o s y o bje t o s c o m o a d o r n o e n u n r bo l d n o vi d o d . "
Ro be r l Pi r s i g
d e
a

tsena
mi ago,
:que

son
unirse
Atri butos de cal i dad. He wl e t l -Pa c k a r d [ GRA87] d e s a r r o l l u n c o n j u n t o d e a t r i bu -
t o s d e c a l i d a d ; e n t r e e l l o s e s t n l a f u n c i o n a l i d a d , l a f a c i l i d a d d e u s o , l a c o n f i a bi l i d a d ,
e l d e s e m pe o y l a s o po r t a bi l i d a d . Es t o s a t r i bu t o s d e c a l i d a d r e pr e s e n t a n u n o bje t i vo
pa r a t o d o e l d i s e o d e s o f t wa r e :
La funcionalidad s e e s t i m a a l e va l u a r e l c o n j u n t o d e c a r a c t e r s t i c a s y c a pa c i -
d a d e s d e l pr o gr a m a , l a ge n e r a l i d a d d e l a s f u n c i o n e s q u e s e e n t r e ga n y l a
s e gu r i d a d d e l s i s t e m a e n s u t o t a l i d a d .
La facilidad de uso s e va l o r a a l c o n s i d e r a r l o s f a c t o r e s hu m a n o s ( c a p t u l o 12),
l a e s t t i c a , c o n s i s t e n c i a y d o c u m e n t a c i n ge n e r a l e s .
La confiabilidad s e e va l a a l m e d i r l a f r e c u e n c i a y s e ve r i d a d d e l a s f a l l a s , l a
pr e c i s i n d e l o s r e s u l t a d o s d e s a l i d a , l a m e d i a d e l m o m e n t o d e f a l l a s ( MMF),
l a ha bi l i d a d pa r a r e c u pe r a r s e d e l a s f a l l a s y l a pr e vi s i bi l i d a d d e l pr o gr a m a .
El desempeo s e m i d e c o n l a ve l o c i d a d d e pr o c e s a m i e n t o , t i e m po d e
r e s pu e s t a , c o n s u m o d e r e c u r s o s , r e n d i m i e n t o y e f i c a c i a .
La soportabilidad c o m bi n a l a ha bi l i d a d d e e xt e n d e r e l pr o gr a m a ( e xt e n s i bi -
l i d a d ), l a a d a pt a bi l i d a d y l a s e r vi c i a bi l i d a d e s t o s t r e s a t r i bu t o s r e pr e s e n t a n
u n c o n c e pt o m s comn, facilidad de mantenimiento a d e m s , r e s i s t e n c i a a
pr u e ba s , c o m pa t i bi l i d a d , c o n f i gu r a bi l i d a d ( ha bi l i d a d pa r a o r ga n i za r y
c o n t r o l a r e l e m e n t o s d e l a c o n f i gu r a c i n d e s o f t wa r e ) ( c a p t u l o 27), l a f a c i l i d a d
c o n q u e pu e d e i n s t a l a r s e e l s i s t e m a , y l a f a c i l i d a d c o n q u e s e pu e d e n l o c a l i za r
l o s pr o bl e m a s .
No t o d o s l o s a t r i bu t o s d e l a c a l i d a d d e l s o f t wa r e t i e n e n e l m i s m o pe s o c u a n d o s e
d e s a r r o l l a e l d i s e o d e l s o f t wa r e . Ta l ve z u n a a pl i c a c i n t e n ga u n e s pe c i a l i n t e r s e n
l a s e gu r i d a d . Es po s i bl e q u e o t r a d e m a n d e d e s e m pe o c o n u n e n f o q u e pa r t i c u l a r e n l a
ve l o c i d a d d e pr o c e s a m i e n t o . Un a t e r c e r a pu e d e c e n t r a r s e e n l a c o n f i a bi l i d a d . Si n
i m po r t a r e l pe s o , e s i m po r t a n t e pu n t u a l i za r q u e e s t o s a t r i bu t o s d e c a l i d a d d e be n
c o n s i d e r a r s e a l c o m i e n zo d e l d i s e o , no d e s pu s d e q u e e l d i s e o e s t c o m pl e t o y
ha ya c o m e n za d o l a c o n s t r u c c i n .
TM
PDF Editor
Conjunto de tareas gen ricas para el diseo
CONJUNTO DE TAREAS
1. Exa m i n a r e l m o d e l o d e l d o m i n i o d e
l a i n f o r m a c i n y d i s e a r l a s e s t r u c t u r a s d e
d a t o s a pr o pi a d a s pa r a l o s o bje t o s d e d a t o s y
s u s a t r i bu t o s
2. Po r m e d i o d e l m o d e l o d e a n l i s i s , s e l e c c i o n a r u n
e s t i l o a r q u i t e c t n i c o ( pa t r n ) q u e s e a a pr o pi a d o
pa r a e l s o f t wa r e .
3. Di vi d i r e l m o d e l o d e a n l i s i s e n s u bs i s t e m a s d e
d i s e o y u bi c a r e s t o s s u bs i s t e m a s d e n t r o d e l a
a r q u i t e c t u r a .
As e gu r a r s e d e q u e c a d a s u bs i s t e m a e s c o he s i vo e n
s u f u n c i o n a m i e n t o .
Di s e a r l a s i n t e r f a c e s d e l s u bs i s t e m a .
Ubi c a r c l a s e s o f u n c i o n e s d e a n l i s i s pa r a c a d a
s u bs i s t e m a .
4. Cr e a r u n c o n ju n t o d e c l a s e s d e d i s e o o
c o m po n e n t e s .
Tr a d u c i r c a d a d e s c r i pc i n d e l a s c l a s e s d e a n l i s i s e n
u n a c l a s e d e d i s e o .
Ve r i f i c a r c a d a c l a s e d e d i s e o c o n t r a l o s c r i t e r i o s d e
d i s e o ; c o n s i d e r a r l o s a s pe c t o s d e l a he r e n c i a .
De f i n i r m t o d o s y m e n s a je s a s o c i a d o s c o n c a d a
c l a s e d e d i s e o .
5.
.
7.
Eva l u a r y s e l e c c i o n a r pa t r o n e s d e d i s e o pa r a u r c
c l a s e d e d i s e o o u n s u bs i s t e m a .
Re vi s a r l a s c l a s e s d e d i s e o y m o d i f i c a r l a s s e gn a
r e q u i e r a .
Di s e a r c u a l q u i e r i n t e r f a z r e q u e r i d a c o n s i s t e m a s :
d i s po s i t i vo s e xt e r n o s .
Di s e a r l a i n t e r f a z d e l u s u a r i o .
Re vi s a r l o s r e s u l t a d o s d e l a n l i s i s d e t a r e a s .
Es pe c i f i c a r l a s e c u e n c i a d e a c c i n c o n ba s e e n
e s c e n a r i o s d e l u s u a r i o .
Cr e a r u n m o d e l o d e c o m po r t a m i e n t o d e l a i n t e r i o r
De f i n i r l o s o bje t o s d e l a i n t e r f a z y m e c a n i s m o s d e
c o n t r o l .
Re vi s a r e l d i s e o d e l a i n t e r f a z y m o d i f i c a r l o s e ga -
s e r e q u i e r a .
Co n d u c i r e l d i s e o a l n i ve l d e c o m po n e n t e s .
Es pe c i f i c a r t o d o s l o s a l go r i t m o s a u n gr a d o d e
a bs t r a c c i n r e l a t i va m e n t e ba j o .
Re f i n a r l a i n t e r f a z d e c a d a c o m po n e n t e .
De f i n i r e s t r u c t u r a s d e d a t o s a l n i ve l d e c o m po n e r l e s
Re vi s a r c a d a c o m po n e n t e y c o r r e gi r t o d o s l o s <
d e s c u bi e r t o s .
De s a r r o l l a r u n m o d e l o d e d e s pl i e gu e .
A t r a v s d e l a hi s t o r i a d e l a i n ge n i e r a d e l s o f t wa r e ha e vo l u c i o n a d o u n c o n ju n t o i
c o n c e pt o s f u n d a m e n t a l e s d e d i s e o d e s o f t wa r e . Au n q u e e l gr a d o d e i n t e r s e n i
c o n c e pt o ha va r i a d o c o n l o s a o s , ha n pa s a d o l a pr u e ba d e l t i e m po . Ca d a u n o i
c e a l i n ge n i e r o d e s o f t wa r e u n f u n d a m e n t o s o br e e l c u a l pu e d e n a pl i c a r s e m t c
d e d i s e o m s e l a bo r a d o s .
M. A. Ja c k s o n DAC75] d i jo u n a ve z: "El c o m i e n zo d e l a s a bi d u r a pa r a [ u n i r
n i e r o d e s o f t wa r e ] e s r e c o n o c e r l a d i f e r e n c i a e n t r e ha c e r q u e u n pr o gr a m e f u n c k
y c o n s e gu i r q u e l o ha ga d e l m o d o c o r r e c t o ". Lo s c o n c e pt o s f u n d a m e n t a l e s d e l
o d e s o f t wa r e o f r e c e n e l m a r c o d e t r a ba j o n e c e s a r i o pa r a ha c e r l a s c o s a s "d e l i
c o r r e c t o ".
9.3.1 Abs t r a c c i n
Cu a n d o s e c o n s i d e r a u n a s o l u c i n m o d u l a r a c u a l q u i e r pr o bl e m a s e pu e d e n e xpc
m u c ho s grados de abstraccin. En u n a l t o gr a d o d e a bs t r a c c i n u n a s o l u c i n s e i
bl e c e e n t r m i n o s ge n e r a l e s c o n e l l e n gu a je d e l e n t o r n o d e l pr o bl e m a . En l o s gr a
d e m e n o r a bs t r a c c i n s e pr o po r c i o n a u n a d e s c r i pc i n m s d e t a l l a d a d e l a s o l u c i ; * J
TM
PDF Editor
" l a a bs t r a c c i n e s u n a d e l a s f o r m a s f u n d a m e n t a l e s e n l a s q u e e l hu m a n o s e e n f r e n t a a l o c o m pl e ji d a d .''
Gr a d y Bo o c h
5po r a
r Unciones
ly de
i sean tiles
l e n
i Si pueden
i dominio
ide
L s e r a an
En l a m e d i d a e n q u e c a m bi a n l o s d i f e r e n t e s gr a d o s d e a bs t r a c c i n s e t r a ba j a pa r a
c r e a r a bs t r a c c i o n e s pr o c e d i m e n t a l e s y d e d a t o s . Un a abstraccin procedimental s e
r e f i e r e a u n a s e c u e n c i a d e i n s t r u c c i o n e s q u e t i e n e u n a f u n c i n e s pe c f i c a y l i m i t a d a .
El n o m br e d e a bs t r a c c i n pr o c e d i m e n t a l i m pl i c a e s t a s f u n c i o n e s , pe r o s e o m i t e n
d e t a l l e s e s pe c f i c o s . Un e j e m pl o d e a bs t r a c c i n pr o c e d i m e n t a l s e r i a l a pa l a br a abrir
pa r a u n a pu e r t a . Abrir i m pl i c a u n a l a r ga s e c u e n c i a d e pa s o s pr o c e d i m e n t a l e s ( po r
e je m pl o , c a m i n a r a l a pu e r t a , a l c a n za r l a m a n i j a , d a r l e vu e l t a a l a m a n i j a y e m pu j a r
l a pu e r t a , ha c e r s e a u n l a d o pa r a a br i r pa s o a l a pu e r t a q u e s e a br e , e t c .).4
Un a abstraccin de datos e s u n a c o l e c c i n n o m br a d a d e d a t o s q u e d e s c r i be u n
o bj e t o d e d a t o s . En e l c o n t e xt o d e a bs t r a c c i n pr o c e d i m e n t a l , abrirse pu e d e d e f i n i r
c o m o u n a a bs t r a c c i n d e d a t o s l l a m a d a puerta. Co m o c u a l q u i e r o bj e t o d e d a t o s , l a
a bs t r a c c i n d e d a t o s pa r a puert a a ba r c a r a u n a s e r i e d e a t r i bu t o s q u e l a d e s c r i ba n
( po r e j e m pl o , pu e r t a , t i po , d i r e c c i n d e a pe r t u r a , m e c a n i s m o d e a pe r t u r a , pe s o , d i m e n s i o n e s ).
Se pu e d e d e c i r q u e l a a bs t r a c c i n pr o c e d i m e n t a l abrir e m pl e a r a l a i n f o r m a c i n c o n -
t e n i d a e n l o s a t r i bu t o s d e l a a bs t r a c c i n d e d a t o s puerta.
9.3.2 Ar q u i t e c t u r a
La arquitectura del software a l u d e a "l a e s t r u c t u r a ge n e r a l d e l s o f t wa r e y l a s f o r m a s
e n q u e l a e s t r u c t u r a pr o po r c i o n a u n a i n t e gr i d a d c o n c e pt u a l pa r a u n s i s t e m a "
[ SHA95a ] , En s u f o r m a m s s i m pl e , l a a r q u i t e c t u r a e s l a e s t r u c t u r a u o r ga n i za c i n d e
l o s c o m po n e n t e s d e l pr o gr a m a ( m d u l o s ), l a m a n e r a e n q u e s t o s c o m po n e n t e s
i n t e r a c t a n , y l a e s t r u c t u r a d e d a t o s q u e u t i l i za n l o s c o m po n e n t e s . En u n s e n t i d o
m s a m pl i o , s i n e m ba r go , l o s c o m po n e n t e s pu e d e n ge n e r a l i za r s e pa r a r e pr e s e n t a r
e l e m e n t o s i m po r t a n t e s d e l s i s t e m a y s u s i n t e r a c c i o n e s .
"Un a a r q u i t e c t u r a d e s o f t wa r e e s e l pr o d u c t o d e l t r a ba jo d e d e s a r r o l l o q u e o f r e c e e l m a yo r r e n d i m i e n t o d e l a
i n ve r s i n c o n r e s pe c t o a l a c a l i d a d , e l t i e m po y e l c o s t o ."
Le n Ba s s el al.
i _ AMpu e ( k
Un a d e l a s m e t a s d e l d i s e o d e s o f t wa r e e s d e r i va r u n a r e pr e s e n t a c i n a r q u i t e c -
t n i c a d e u n s i s t e m a . Es t a r e pr e s e n t a c i n s i r ve c o m o e l m a r c o d e t r a ba j o a pa r t i r d e l
c u a l s e c o n d u c e n a c t i vi d a d e s d e d i s e o m s d e t a l l a d a s . Un c o n j u n t o d e pa t r o n e s
4 Si n e m ba r go , d e be n o t a r s e q u e u n c o n ju n t o d e o pe r a c i o n e s pu e d e r e e m pl a za r s e c o n o t r o , s i e m pr e
q u e l a f u n c i n i m pl i c a d a po r l a a bs t r a c c i n d e pr o c e d i m i e n t o s e a l a m i s m a . Po r l o t a n t o , l o s pa s o s
r e q u e r i d o s pa r a i m pl e m e n t a r a br i r po d r a n c a m bi a r e n f o r m a s u s t a n c i a l s i l a pu e r t a f u e r a a u t o m -
t i c a y e s t u vi e r a u n i d a a u n s e n s o r .
TM
PDF Editor
254
( CONSEJ O^
No debe dejarse que
la arquitectura sucedo
por si sola. Sieso
paso, el resto del
tiempo de proy ecto se
invertir en tratar de
obligarla o ajustarse al
diseo. Se reco-
mienda disear la
arquitectura de
manera expl cita.
P A R T E D O S PRCTICA DE LA INGENIERA D A SOFTWARE
a r q u i t e c t n i c o s pe r m i t e q u e u n i n ge n i e r o d e s o f t wa r e r e u t i l i c e c o n c e pt o s e n e l n i ve a
d e d i s e o .
El d i s e o a r q u i t e c t n i c o pu e d e r e pr e s e n t a r s e a l u s a r u n o o m s d e m u c ho s m o d e -l
l o s d i f e r e n t e s ( GAR95J. Lo s modelos estructurales r e pr e s e n t a n l a a r q u i t e c t u r a c o c r c j
u n a c o l e c c i n o r ga n i za d a d e c o m po n e n t e s d e l pr o gr a m a . Lo s modelos del maree ja
trabajo i n c r e m e n t a n e l gr a d o d e a bs t r a c c i n d e l d i s e o a l i n t e n t a r i d e n t i f i c a r m a r : J
d e t r a ba j o r e pe t i bl e s d e l d i s e o a r q u i t e c t n i c o q u e s e e n c u e n t r a n e n t i po s d e a pl i c a -l
c i o n e s s i m i l a r e s . Lo s modelos dinmicos a bo r d a n l o s a s pe c t o s c o n d u c t u a l e s d e t a
a r q u i t e c t u r a d e l pr o gr a m a , a l i n d i c a r c m o pu e d e c a m bi a r l a c o n f i gu r a c i n d e l a e s t r _ ; ]
t u r a o e l s i s t e m a , c o m o f u n c i n d e l o s e ve n t o s e xt e r n o s . Lo s modelos del proceso s d
c e n t r a n e n e l d i s e o d e l pr o c e s o t c n i c o o d e n e go c i o s q u e e l s i s t e m a d e be c o r : r - |
n e r . Po r l t i m o , l o s modelos funcionales pu e d e n u t i l i za r s e pa r a r e pr e s e n t a r l a je r a r -j
q u i a f u n c i o n a l d e u n s i s t e m a . El d i s e o a r q u i t e c t n i c o s e e xpo n e e n e l c a p t u l o 10
9.3.3 Pa t r o n e s
Br a d Appl e t o n d e f i n e u n patrn de diseo d e l a s i gu i e n t e m a n e r a : "Un pa t r n e s u n
s e m i l l a d e c o n o c i m i e n t o , l a c u a l t i e n e u n n o m br e y t r a n s po r t a l a e s e n c i a d e u n a s : J
c i n pr o ba d a a u n pr o bl e m a r e c u r r e n t e d e n t r o d e c i e r t o c o n t e xt o e n m e d i o d e i n t e -I
r e s e s e n c o m pe t e n c i a " [ APP98] . Di c ho d e o t r o m o d o , u n pa t r n d e d i s e o d e s c r - n J
u n a e s t r u c t u r a d e d i s e o q u e r e s u e l ve u n pr o bl e m a d e d i s e o pa r t i c u l a r d e n t r e j t l
u n c o n t e xt o e s pe c f i c o y e n m e d i o d e "f u e r za s " q u e pu e d e n t e n e r u n i m pa c t o e n M
m a n e r a e n q u e s e a pl i c a y u t i l i za e l pa t r n .
po t r n d e s c r i be u n p r o b l e m a q u e o c u r r e u n o y o t r o ve z e n n u e s t r o e n t o r n o , y d e s pu s d e s c r i be l o e s e n c i o d e :
s o l u c i n o d i c ho pr o bl e m a , d e t a l f o r m a q u e p u e d o s u s a r e s t a s o l u c i n u n m i l l n d e ve c e s m s , s i n n u n c a ha c e r l o d o s
ve c e s d e l a m i s m a f o r m a . "
Chr i s t o phe r Al e xa n d
La f i n a l i d a d d e c a d a pa t r n d e d i s e o e s pr o po r c i o n a r u n a d e s c r i pc i n q u e l e : - J
m i t a a l d i s e a d o r d e t e r m i n a r 1) s i e l pa t r n e s a pl i c a bl e a l t r a ba j o a c t u a l , 2) s i J
pa t r n s e pu e d e r e u t i l i za r ( po r e n d e , a ho r r a r t i e m po d e l d i s e o ), y 3) s i e l pa t - r ^ l
pu e d e s e r vi r c o m o gu a pa r a d e s a r r o l l a r u n pa t r n s i m i l a r , pe r o d i f e r e n t e e n c u a . r u l
a l a f u n c i o n a l i d a d o e s t r u c t u r a . Lo s pa t r o n e s d e d i s e o s e e xpo n e n c o n m a yo r d e : - |
l i e e n l a s e c c i n 9.5.
9.3.4 Mo d u l a r i d a d
Lo s pa t r o n e s d e a r q u i t e c t u r a y d i s e o d e s o f t wa r e m a t e r i a l i za n l a modularidad
d e c i r , e l s o f t wa r e s e d i vi d e e n c o m po n e n t e s c o n n o m br e s i n d e pe n d i e n t e s y q u e e s pe - l
bl e a bo r d a r e n f o r m a i n d i vi d u a l . Es t o s c o m po n e n t e s l l a m a d o s mdulos s e i n t e g- s J
pa r a s a t i s f a c e r l o s r e q u i s i t o s d e l pr o bl e m a .
Se ha e s t a bl e c i d o q u e l a "m o d u l a r i d a d e s e l a t r i bu t o pa r t i c u l a r d e l s o f t wa r e C-JJ
pe r m i t e q u e u n pr o gr a m a s e a m a n e j a bl e d e m a n e r a i n t e l e c t u a l " [ MYE78] . El s o f t v.3-1
r e m o n o l t i c o ( e s d e c i r , u n pr o gr a m a gr a n d e c o m pu e s t o po r u n m d u l o s e n c i l l o } - a l
TM
PDF Editor
pu e d e e n t e n d e r l o c o n f a c i l i d a d u n i n ge n i e r o d e s o f t wa r e . El n m e r o d e r u t a s d e c o n -
t r o l , l a a m pl i t u d d e l a s r e f e r e n c i a s , e l n m e r o d e va r i a bl e s y l a c o m pl e ji d a d ge n e r a l
i m po s i bi l i t a r a c o m pr e n d e r l o . Es t e pu n t o s e i l u s t r a c o n e l s i gu i e n t e a r gu m e n t o ,
ba s a d o e n o bs e r va c i o n e s d e s o l u c i n d e pr o bl e m a s hu m a n o s .
Co n s i d r e n s e d o s pr o bl e m a s , p, y p2. Si l a c o m pl e ji d a d o bs e r va d a pa r a p] e s
m a yo r q u e l a d e p2 s e d e d u c e q u e e l e s f u e r zo r e q u e r i d o pa r a r e s o l ve r p, e s m a yo r q u e
e l e s f u e r zo n e c e s a r i o pa r a r e s o l ve r p2. Co m o u n c a s o ge n e r a l , e s t e r e s u l t a d o e s o bvi o
e n e l s e n t i d o i n t u i t i vo ; l a r e s o l u c i n d e u n pr o bl e m a d i f c i l t o m a m s t i e m po .
Ta m bi n s e d e d u c e q u e l a c o m pl e ji d a d o bs e r va d a d e d o s pr o bl e m a s , c u a n d o
e s t n c o m bi n a d o s , c o n f r e c u e n c i a e s m a yo r q u e l a s u m a d e l a s c o m pl e ji d a d e s o bs e r -
va d a s c u a n d o c a d a u n a d e e l l a s s e t o m a po r s e pa r a d o : e s t o c o n d u c e a u n a e s t r a t e -
gi a d e "d i vi d e y ve n c e r s " ( e s m s f c i l r e s o l ve r u n pr o bl e m a c o m pl e jo c u a n d o s t e
s e d i vi d e e n pi e za s m s m a n e ja bl e s ). Es t o t i e n e i m pl i c a c i o n e s i m po r t a n t e s c o n r e s -
pe c t o a l a m o d u l a r i d a d y a l s o f t wa r e . De he c ho , e s u n a r gu m e n t o pa r a l a m o d u l a r i -
d a d .
Es po s i bl e c o n c l u i r q u e s i e l s o f t wa r e s e s u bd i vi d e e n f o r m a i n d e f i n i d a , e l e s f u e r -
zo r e q u e r i d o pa r a d e s a r r o l l a r l o s e r e d u c i r e n f o r m a s e n s i bl e . Po r d e s gr a c i a , ha y
o t r a s f u e r za s q u e e n t r a n e n ju e go , l o q u e o c a s i o n a q u e e s t a c o n c l u s i n s e a ( t r i s t e -
m e n t e ) i n vl i d a . En r e l a c i n c o n l a f i gu r a 9.2, e l e s f u e r zo ( c o s t o ) pa r a d e s a r r o l l a r u n
s o l o m d u l o d e s o f t wa r e d e c r e c e c o n f o r m e s e i n c r e m e n t a e l n m e r o d e m d u l o s . Si
s e t i e n e e l m i s m o c o n ju n t o d e r e q u i s i t o s , m s m d u l o s s i gn i f i c a n u n t a m a o i n d i vi -
d u a l m e n o r . Si n e m ba r go , a m e d i d a q u e c r e c e e l n m e r o d e m d u l o s , e l e s f u e r zo
( c o s t o ) a s o c i a d o c o n l a i n t e gr a c i n d e l o s m d u l o s t a m bi n c r e c e . Es t a s c a r a c t e r s -
t i c a s c o n d u c e n t a m bi n a l a c u r va t o t a l d e l c o s t o o e l e s f u e r zo q u e s e m u e s t r a e n l a
f i gu r a . Exi s t e u n n m e r o M d e m d u l o s q u e r e s u l t a r a e n u n c o s t o d e d e s a r r o l l o
m n i m o , a u n q u e ha s t a e l m o m e n t o n o s e t i e n e l a s o f i s t i c a c i n n e c e s a r i a pa r a pr e -
d e c i r M c o n s e gu r i d a d .
La s c u r va s q u e s e m u e s t r a n e n l a f i gu r a 9.2 pr o po r c i o n a n u n a gu a t i l c u a n d o s e
c o n s i d e r a l a m o d u l a r i d a d . s t a d e be a pl i c a r s e , pe r o s e d e be t e n e r c u i d a d o d e pe r -
I
I Co s t o t o t a l d e l s o f t wa r e
/ l Co s t o po r i n t e gr a r
Co s t o / m d u l o
Nm e r o d e m d u l o s
TM
PDF Editor
\
CLAVE
Lo f i n a l i d o d d e l o
o c u l t a c i n d e
i n f o r m a c i n e s r e s e r va r
l o s d e t a l l e s d e l a s
e s t r u c t u r a s d e d a t o s y
d e l o s pr o c e s a m i e n t o s
d e pr o c e d i m i e n t o
d e t r s d e u n a i n t e i f o z
d e l m d u l o . El
c o n o c i m i e n t o d e l o s
d e t a l l e s n o d e be e s t a r
a l a l c a n c e d e l o s
u s u a r i o s d e l m d u l o .
m a n e c e r e r i l a ve c i n d a d d e M. De be e vi t a r s e l a m o d u l a r i d a d e xc e s i va o i n s u f i c i e n t e
pe r o c m o pu e d e c o n o c e r s e l a ve c i n d a d d e M? Qu t a n m o d u l a r d e be ha c e r s e e
s o f t wa r e ? La s r e s pu e s t a s a e s t a s pr e gu n t a s r e q u i e r e n c o m pr e n d e r o t r o s c o n c e pt o s
d e d i s e o q u e s e c o n s i d e r a r n d e s pu s , e n e s t e m i s m o c a p t u l o .
Un d i s e o y e l pr o gr a m a r e s u l t a n t e s e m o d u l a r i za n d e m a n e r a q u e e l d e s a r r o l l e
s e pu e d a pl a n e a r c o n m a yo r f a c i l i d a d ; s e pu e d a n d e f i n i r y e n t r e ga r i n c r e m e n t o s d e :
s o f t wa r e ; l o s c a m bi o s pu e d a n a j u s t a r s e c o n m a yo r f a c i l i d a d ; l a s pr u e ba s y l a e l i m i
n a c i n d e e r r o r e s s e pu e d a c o n d u c i r c o n m s e f i c i e n c i a , y e l m a n t e n i m i e n t o s e
pu e d a c o n d u c i r s i n e f e c t o s l a t e r a l e s d e c o n s i d e r a c i n .
9. 3. 5 Oc ul t a c i n d e i nf o r ma c i n
El c o n c e pt o d e m o d u l a r i d a d c o n d u c e a t o d o s l o s d i s e a d o r e s d e s o f t wa r e a f o r m u -
l a r s e u n a pr e gu n t a f u n d a m e n t a l : c m o pu e d e d e s c o m po n e r s e u n a s o l u c i n d e s o f t -
wa r e pa r a o bt e n e r e l m e j o r c o n j u n t o d e m d u l o s ? El pr i n c i pi o d e ocultacin de infor-
macin [ PAR72] s u gi e r e q u e l o s m d u l o s "s e c a r a c t e r i za n po r l a s d e c i s i o n e s d e d i s e -
o q u e ( c a d a u n o ) o c u l t a a l o s o t r o s ". En o t r a s pa l a br a s , l o s m d u l o s d e be n e s pe c i -
f i c a r s e y d i s e a r s e d e m a n e r a q u e l a i n f o r m a c i n ( pr o c e d i m i e n t o y d a t o s ) q u e e s t a
d e n t r o d e l m d u l o s e a i n a c c e s i bl e pa r a o t r o s m d u l o s q u e n o n e c e s i t e n e s a i n f o r -
m a c i n .
La o c u l t a c i n i m pl i c a q u e s e pu e d e c o n s e gu i r u n a m o d u l a r i d a d e f e c t i va a l d e f i n :
u n c o n j u n t o d e m d u l o s i n d e pe n d i e n t e s q u e s e c o m u n i q u e n e n t r e s y q u e i n t e r -
c a m bi e n s l o l a i n f o r m a c i n n e c e s a r i a pa r a l o gr a r l a f u n c i n d e l s o f t wa r e . La a bs -
t r a c c i n a yu d a a d e f i n i r l a s e n t i d a d e s d e pr o c e d i m i e n t o ( o i n f o r m a c i n ) q u e c o n f o r -
m a n e l s o f t wa r e . La o c u l t a c i n d e f i n e y f o r t a l e c e l a s r e s t r i c c i o n e s d e a c c e s o pa r a l o ;
d e t a l l e s d e pr o c e d i m i e n t o d e n t r o d e u n m d u l o y pa r a c u a l q u i e r e s t r u c t u r a d e d a t o s
l o c a l q u e u t i l i c e e l m d u l o [ ROS75] ,
El u s o d e l a o c u l t a c i n d e i n f o r m a c i n , c o m o u n c r i t e r i o d e d i s e o pa r a s i s t e m a s
m o d u l a r e s , pr o po r c i o n a l o s m a yo r e s be n e f i c i o s c u a n d o s e r e q u i e r e n m o d i f i c a c i o n e s
d u r a n t e l a r e a l i za c i n d e l a s pr u e ba s y, d e s pu s , e n e l c u r s o d e m a n t e n i m i e n t o d e
s o f t wa r e . Co m o l a m a yo r a d e l o s d a t o s y pr o c e d i m i e n t o s e s t o c u l t a d e l a s o t r a s
pa r t e s d e l s o f t wa r e , e xi s t e u n a pr o ba bi l i d a d m e n o r d e i n t r o d u c i r e r r o r e s i n a d ve r t i d o s
a l r e a l i za r l a s m o d i f i c a c i o n e s y pr o pa ga r l o s a o t r o s l u ga r e s d e n t r o d e l s o f t wa r e .
9. 3. 6 I n d e p e n d e n c i a f unc i o na l
El c o n c e pt o d e independencia funcional e s l a s u m a d i r e c t a d e l a m o d u l a r i d a d y d e l o s
c o n c e pt o s d e a bs t r a c c i n y o c u l t a c i n d e i n f o r m a c i n . En r e f e r e n c i a s o bl i ga d a s
s o br e e l d i s e o d e s o f t wa r e , Wi r t h | WIR71] y Pa m a s [ PAR72] a l u d e n a l a s t c n i c a s d e r e f i -
n a m i e n t o q u e m e j o r a n l a i n d e pe n d e n c i a d e l o s m d u l o s . Tr a ba j o s po s t e r i o r e s d e
St e ve n s , Mye r s y Co n s t a n t i n e [ STE74] c o n s o l i d a r o n e l c o n c e pt o .
La i n d e pe n d e n c i a f u n c i o n a l s e c o n s i gu e a l d e s a r r o l l a r m d u l o s c o n u n a f u n c i r
"d e t e r m i n a n t e " y u n a "a ve r s i n " a l a i n t e r a c c i n e xc e s i va c o n o t r o s m d u l o s . Di c h:
d e o t r a m a n e r a , s e d e s e a d i s e a r e l s o f t wa r e d e t a l m a n e r a q u e c a d a m d u l o a bo r d e
u n a s u bf u n c i n e s pe c f i c a d e l o s r e q u i s i t o s y t e n ga u n a s o l a i n t e r f a z c u a n d o s e
TM
PDF Editor
kVE
i a u n o
] d e l
e u n
] e n
t VE
) e s u n o
] d e l
e u n
i a n e c i a d o
s y a l
*
r nndencio a
id detalle
l ignorar los
t conduce
I t omisiones
t el diseo
i ms dif cil
i Se teco-
relrefh
r x s o a
o bs e r ve d e s d e o t r a s pa r t e s d e l a e s t r u c t u r a d e l pr o gr a m a . Es ju s t o pr e gu n t a r s e po r
q u e s i m po r t a n t e l a i n d e pe n d e n c i a .
El s o f t wa r e c o n u n a m o d u l a r i d a d e f e c t i va , e s d e c i r , c o n m d u l o s i n d e pe n d i e n t e s ,
e s m s f c i l d e d e s a r r o l l a r po r q u e l a f u n c i n s e pu e d e f r a c c i o n a r y l a s i n t e r f a c e s s e
s i m pl i f i c a n ( c o n s i d r e n s e l a s r a m i f i c a c i o n e s c u a n d o e l d e s a r r o l l o s e r e a l i za e n e q u i -
po ). Lo s m d u l o s i n d e pe n d i e n t e s s o n m s f c i l e s d e m a n t e n e r ( y pr o ba r ) po r q u e s e
l i m i t a n l o s e f e c t o s s e c u n d a r i o s q u e o r i gi n a n l a s m o d i f i c a c i o n e s a l d i s e o o a i c d i -
go , s e r e d u c e l a pr o pa ga c i n d e e r r o r e s , y e s po s i bl e e m pl e a r m d u l o s r e u t i l i za bl e s .
En r e s u m e n , l a i n d e pe n d e n c i a f u n c i o n a l e s u n a c l a ve pa r a e l bu e n d i s e o , y e l d i s e -
o e s l a c l a ve pa r a l o gr a r l a c a l i d a d d e l s o f t wa r e .
La i n d e pe n d e n c i a s e e va l a a pl i c a n d o d o s c r i t e r i o s c u a l i t a t i vo s : c o he s i n y a c o -
pl a m i e n t o . La cohesin e s u n a m e d i d a d e l a f u e r za f u n c i o n a l r e l a t i va d e u n m d u l o .
El acoplamiento e s u n a m e d i d a d e l a i n t e r d e pe n d e n c i a r e l a t i va e n t r e l o s m d u l o s .
La c o he s i n e s u n a e xt e n s i n n a t u r a l d e l c o n c e pt o d e o c u l t a c i n d e i n f o r m a c i n
d e s c r i t o e n l a s e c c i n 9.3.5. Un m d u l o c o he s i vo r e a l i za u n a s o l a t a r e a , pa r a l o q u e
r e q u i e r e m u y po c a i n t e r a c c i n c o n o t r o s c o m po n e n t e s e n o t r a s pa r t e s d e l pr o gr a m a .
Di c ho d e m a n e r a s e n c i l l a , u n m d u l o c o he s i vo d e be ( i d e a l m e n t e ) ha c e r s l o u n a c o s a .
El a c o pl a m i e n t o e s u n a m e d i d a d e l a i n t e r c o n e xi n e n t r e l o s m d u l o s d e u n a
e s t r u c t u r a d e s o f t wa r e . El a c o pl a m i e n t o d e pe n d e d e l a c o m pl e ji d a d d e l a i n t e r f a z
e n t r e l o s m d u l o s , e l pu n t o d o n d e s e r e a l i za u n a e n t r a d a o r e f e r e n c i a a u n m d u l o ,
y l o s d a t o s q u e pa s a n a t r a v s d e l a i n t e r f a z. En e l d i s e o d e s o f t wa r e s e i n t e n t a c o n -
s e gu i r e l a c o pl a m i e n t o m s ba j o po s i bl e . Un a c o n e c t i vi d a d s e n c i l l a e n t r e l o s m d u -
l o s d a c o m o r e s u l t a d o u n s o f t wa r e m s f c i l d e e n t e n d e r y m e n o s pr o pe n s o a e xpe -
r i m e n t a r e l "e f e c t o o l a " [ STE74] , e l c u a l s e pr e s e n t a c u a n d o s u r ge n pr o bl e m a s e n u n
l u ga r y d e s pu s s e pr o pa ga n a t r a v s d e l s i s t e m a .
9.3.7 Re f i n a m i e n t o
El refinamiento pa s o a pa s o e s u n a e s t r a t e gi a d e d i s e o d e s c e n d e n t e q u e pr o pu s o i n i -
c i a l m e n t e Ni k l a u s Wi r t h [ WIR71] . El d e s a r r o l l o d e u n pr o gr a m a s e r e a l i za a l r e t i n a r
d e m a n e r a s u c e s i va l o s n i ve l e s d e d e t a l l e pr o c e d i m e n t a l e s . Un a je r a r q u a s e d e s a -
r r o l l a a l d e s c o m po n e r e l e n u n c i a d o m a c r o s c pi c o d e u n a f u n c i n ( u n a a bs t r a c c i n
pr o c e d i m e n t a l ) pa s o a pa s o ha s t a a l c a n za r l a s o r a c i o n e s d e l l e n gu a j e d e pr o gr a m a -
c i n .
En r e a l i d a d , e l r e f i n a m i e n t o e s u n pr o c e s o d e elaboracin. Se i n i c i a c o n e l e n u n -
c i a d o d e u n a f u n c i n ( o u n a d e s c r i pc i n d e d a t o s ) q u e s e d e f i n e c o n u n a l t o gr a d o
d e a bs t r a c c i n . Es t o e s , e l e n u n c i a d o d e s c r i be l o s d a t o s o l a f u n c i n d e m a n e r a c o n -
c e pt u a l , pe r o n o pr o po r c i o n a i n f o r m a c i n a c e r c a d e l o s t r a ba j o s i n t e r n o s d e l a f u n -
c i n o d e l a e s t r u c t u r a i n t e r n a d e l o s d a t o s . El r e f i n a m i e n t o ha c e q u e e l d i s e a d o r
t r a ba j e s o br e e l e n u n c i a d o o r i gi n a l y q u e pr o po r c i o n e m s y m s d e t a l l e s c o n f o r m e
s e r e a l i za c a d a r e f i n a m i e n t o s u c e s i vo ( e l a bo r a c i n ).
La a bs t r a c c i n y e l r e f i n a m i e n t o s o n c o n c e pt o s c o m pl e m e n t a r i o s . La a bs t r a c c i n
l e pe r m i t e a u n d i s e a d o r e s pe c i f i c a r pr o c e d i m i e n t o s y d a t o s s i n c o n s i d e r a r d e t a l l e s
TM
PDF Editor
En www.
r e f a c t o r i n g.t o m
s e pu e d e n e n c e n t r o !
e xc e l e n t e s r e c ws o s
po r o l o l e f o b n t o e f c
d e gr a d o m e n o r . El r e f i n a m i e n t o a yu d a a l d i s e a d o r a r e ve l a r l o s d e t a l l e s d e
m e n o r m i e n t r a s s e r e a l i za e l d i s e o . Am bo s c o n c e pt o s a u xi l i a n a l d i s e a d o r
c r e a c i n d e u n m o d e l o d e d i s e o c o m pl e t o a m e d i d a q u e e vo l u c i o n a l a a c t i vi d a :
d i s e o .
"No f o l l . Slo e n c o n t r 10 000 f o r m o s f a llid o s d e ha c e r lo s c o s a s ."
Tho m o s
9.3.8 Re f a br i c a c i n
Un a a c t i vi d a d i m po r t a n t e d e d i s e o q u e s u gi e r e n m u c ho s m t o d o s gi l e s (
l o 4) e s l a refabricacin, t c n i c a d e r e o r ga n i za c i n q u e s i m pl i f i c a e l d i s e o ( o c _
d e u n c o m po n e n t e s i n c a m bi a r s u f u n c i n o c o m po r t a m i e n t o . Fo wl e r [ FOW99]
n e l a r e f a br i c a c i n d e l a s i gu i e n t e m a n e r a : "La r e f a br i c a c i n e s e l pr o c e s o d e c .
bi a r u n s i s t e m a d e s o f t wa r e d e t a l f o r m a q u e n o s e a l t e r e e l c o m po r t a m i e n t o
n o d e s u c d i go [ d i s e o ] y a n a s s e m e j o r e s u e s t r u c t u r a i n t e r n a . "
Cu a n d o u n s o f t wa r e s e r e f a br i c a e l d i s e o e xi s t e n t e s e e xa m i n a e n bu s c a
r e d u n d a n c i a s , e l e m e n t o s d e d i s e o i n t i l e s , a l go r i t m o s i n n e c e s a r i o s o i n s u f i c i c
e s t r u c t u r a s d e d a t o s i n a pr o pi a d a s o c o n s t r u i d a s d e m a n e r a i n c o r r e c t a , o c u a l c .
o t r a f a l l a d e d i s e o q u e s e pu e d a c o r r e gi r pa r a l o gr a r u n m e j o r d i s e o . Po r e je r r r
u n a pr i m e r a i t e r a c i n d e d i s e o po d r a pr o d u c i r u n c o m po n e n t e q u e m u e s t r a pal
c o he s i n ( r e a l i za t r e s f u n c i o n e s q u e t i e n e n m u y po c a s r e l a c i o n e s e n t r e s ). El
a d o r pu e d e d e c i d i r q u e e l c o m po n e n t e d e be r e f a br i c a r s e e n t r e s c o m po n e n t e s i
t i n t o s , c a d a u n o d e e l l o s c o n u n a e l e va d a c o he s i n . El r e s u l t a d o s e r u n s o f t wr
m s f c i l d e i n t e gr a r , pr o ba r y m a n t e n e r .
Conceptos de di seo
El e s c e na r i o : Cu b c u l o d e Vi n o d ,
c o m i e n za e l m o d e l a d o d e l d i s e o .
Los a c t o r e s : Vi n o d , Ja m i e y Ed , m i e m br o s d e l e q u i po
d e i n ge n i e r a d e l s o f t wa r e d e HogarSeguro. Ta m bi n ,
Sha k i r o u n n u e vo m i e m br o d e l e q u i po
l a conversacin:
(Lo s c u a t r o m i e m br o s d e l e q u i po a c a ba n d e r e gr e s a r d e
u n s e m i n a r i o m a t u t i n o , t i t u l a d o "Apl i c a c i n d e c o n c e pt o s
bs i c o s d e d i s e o ", q u e o f r e c i u n pr o f e s o r l o c a l d e
c i e n c i a c o m pu t a c i o n a l .)
Vi nod: Obt u vi e r o n a l go d e l s e m i n a r i o ?
i s a b a l a m a yo r pa r t e d e l a s c o s a s , pe r o
3u e n o e s u n a m a l a i d e a e s c u c ha r l a s d e n u e vo .
J a mi e : Cu a n d o r e a l i za ba m i s e s t u d i o s pr o f e s i o n a l e s o s
SC n u n c a e n t e n d r e a l m e n t e po r q u l a o c u l t a c i n d e
i n f o r m a c i n e r a t a n i m po r t a n t e c o m o d i c e n .
Vi nod: Po r q u e . . . e s u n a t c n i c a pa r a r e d u c i r l a
pr o pa ga c i n d e l e r r o r e n u n pr o gr a m a . En r e a l i d a d , i
l a i n d e pe n d e n c i a f u n c i o n a l t a m bi n s e l o gr a l o m i s m o
Shaki r a: Yo n o t e n go u n t t u l o e n SC, e n t o n c e s m u c ho s
d e l a s c o s a s q u e m e n c i o n e l i n s t r u c t o r s o n n u e va s p c r :
m . Y yo pu e d o ge n e r a r u n bu e n c d i go y r pi d o . No
ve o po r q u e s t e a s u n t o e s t a n i m po r t a n t e .
J a mi e : He vi s t o t u t r a ba j o , Sha l c , y s a be s q u ? T
ha c e s m u c ha s d e e s t a s c o s a s e n f o r m a n a t u r a l . |
e s q u e t u s d i s e o s y t u c d i go f u n c i o n a n .
TM
PDF Editor
CAPTULO 9 INGENIERA DEL DISEO
259
i ( sonri endo) : Sueno, yo siempre froto de
cdigo, montenerlo enfocado en una cosa,
r simples y restringidos las interfases, reutilizar
cdigo siempre que puedo... ese tipo de cosas.
Moduloridad, independencia funcional, ocultacin,
ves?
: Todava recuerdo el primer curso de
..acin que tom... nos ensearon a refinar el
iterativamente.
T sabes que lo mismo puede aplicarse al
El nico concepto del que no haba escuchado antes
"refabricacin".
Shaki ra: Se utiliza en Programacin Extrema, creo que
eso dijo.
Ed: S, no es por completo diferente al refinamiento, slo
lo haces despus de que el diseo o el cdigo han sido
completados. Si me preguntan a m, es un tipo de paso
hacia la optimizacin del software.
J a mi e : Regresemos al diseo de HogarSeguro. Creo
que deberamos poner estos conceptos en nuestra lista de
revisin mientras desarrollamos el modelo de diseo para
HogarSeguro.
Vi nod: Estoy de acuerdo. Pero igual de importante,
comprometmonos todos a pensar en ellos conforme
desarrollamos el diseo.
9.3.9 Clases de diseo
En el captulo 8 se menci on que el modelo de anlisis define un conj unt o comple-
to de clases de anlisis. Cada una de estas clases describe algn el ement o del domi-
nio del problema, con enfoque en los aspect os del problema visibles para el usuario
o el cliente. El grado de abstraccin de una clase de anlisis es relativamente alto.
Conforme evoluciona el model o de diseo, el equipo de soft ware debe definir un
conj unt o de clases de diseo que 1) refine las clases de anlisis al proporcionar deta-
lles del diseo que permitirn la implementacin de las clases, y 2) produzca un con-
junto nuevo de clases de diseo que implementen una infraestructura de soft ware
para soportar la solucin del negocio. Se sugieren cinco diferentes tipos de clases de
diseo, cada uno representa una capa distinta de la arquitectura de diseo [AMB01]:
Las clases de interfaz con el usuario definen t odas las abstracciones necesari as
para la interaccin humano-comput adora (IHC). En muchos casos, la IHC
ocurre dentro del contexto de una metfora (por ejemplo, un libro de verifica-
cin, un format o de orden, una mquina de fax) y las clases de diseo para la
interfaz pueden ser representaciones visuales de los el ement os de la
metfora.
Las clases del dominio de negocios a menudo son refinamientos de las clases
de anlisis definidas antes. Las clases identifican los atributos y servicios
(mtodos) necesari os para implementar algn el ement o del dominio de
negocios.
Las clases de proceso implementan abstracciones del negocio en un nivel ms
bajo, las cuales se requieren para manej ar por completo las clases del
dominio de negocios.
Las clases persistentes representan al macenami ent os de dat os (por ejemplo,
una base de datos) que persistirn ms all de la ejecucin del software.
( t e t i pos
c d a s e s
d i s e a d o r ?
TM
PDF Editor
Q u e s
una c l a s e de
d i s e o " b i e n
f o r m a d a " ?
Las clases de sistema implementan las funciones de gestin y control de!
software que permiten que el sistema opere y se comunique dentro de s;.
ent orno de computacin y con el mundo exterior.
A medida que evoluciona el model o de diseo, el equipo de software debe
llar un conjunto completo de atributos y operaciones para cada clase de dis
grado de abstraccin se reduce conforme cada clase de anlisis se transforrv
una representacin del diseo. Esto es, las clases de anlisis representan
servicios asociados que se aplican a stos) usando la jerga del dominio de n-
Las clases de diseo presentan un mayor detalle tcnico, pues son una gua
mplementacin.
Arlow y Neustadt [ARL021 sugieren revisar cada clase de diseo para asegur; -
la mi sma est "bien formada". Ellos definen cuatro caractersticas de una
diseo bien formada:
Compl eta y sufi ci ente. Una clase de diseo debe ser la encapsulacin
ta de todos los atributos y mt odos que se pueden esperar, en forma razonable
base en una interpretacin reconocible del nombre de la clase), que existar
clase. Por ejemplo, la clase e s c e na definida para el soft ware de edicin de -
est completa slo si contiene t odos los atributos y mt odos que pueden
de manera razonable con la creacin de una escena de video. La suficiencia
ra que la clase de diseo contenga slo aquellos mt odos que sean suficiente-
lograr el objetivo, ni ms ni menos.
Pri mi ti vi smo. Los mt odos asociados con una clase de diseo deben en
en el cumplimiento de un servicio para la clase. Una vez que el servicio h;
implementado con un mtodo, la clase no debe proporcionar otra forma de
ment ar la misma cosa. Por ejemplo, la clase vi deoCli p del soft ware de ed
video podran tener atributos punto-inicial y punto-final para indicar los punt os de
y fin del clip (ntese que el video bruto cargado en el sistema puede ser ms
que el clip que se usa). Los mtodos cstablecerPuntolnicialf) y establecerPuntoFinJ-
porcionan los nicos medios para configurar los puntos de inicio y fin del clip.
Cohesi n alta. Una clase de diseo cohesiva tiene un conjunto de r
dades pequeo y enfocado, y aplica atributos y mt odos de manera sencii:;
implementar dichas responsabilidades. Por ejemplo, la clase VideoClip del
re para la edicin de video podra contener un conjunto de mt odos para
videoclip. Mientras cada mt odo se enfoque slo en atributos asociados con e
clip se mant endr la cohesin.
Acopl ami ent o bajo. Dentro del modelo de diseo es necesario que las
diseo colaboren con alguna otra. Sin embargo, la colaboracin se debe
en un mnimo aceptable. Si un modelo de diseo tiene un acoplamiento alto
las clases de diseo colaboran con t odas las otras clases de diseo), el si;
difcil de implementar, probar y mant ener a travs del tiempo. En general, las :
TM
PDF Editor
261
de diseo dentro de un subsistema deben tener slo un conocimiento limitado de las
clases en otros subsistemas. Esta restriccin, llamada la Ley de Demter [LIE03],
sugiere que un mt odo slo debe enviar mensaj es a mt odos de clases vecinas.5
Pl anodePl ant a
1
tipo
dimensiones exteriores
1
Cmara
tipo
dimensiones exteriores
1
tipo
id
Campodevisin
Angulodebsqueda
Configuracinacercamiento
agregarCmara()
agregarPared()
agregarVentana))
borrarSegmento( |
dibujar))
tipo
id
Campodevisin
Angulodebsqueda
Configuracinacercamiento
agregarCmara()
agregarPared()
agregarVentana))
borrarSegmento( |
dibujar))
Se g me nt o
Coordenadainico
Coordenadafin
obteneripoj ]
dibujar))
Se g me nt o de pa r e d 1
1
Vent ana 1
1
Refinacin de una clase
El es cenari o: Cubculo de Ed,
contina el modelado del diseo.
Los act ores: Vinod y Ed, miembros del equipo de
-geniera del software de HogarSeguro.
La convers aci n:
Ed trabaja en la clase Pl anodePl ant a [vase el
debate en el recuadro de la seccin 8.7.4 y la figura
8.14] y la ha refinado para el modelo de diseo.)
anlisis en una clase de diseo
Ed: Entonces recuerdas la clase Pl anodePl ant a, no?
Se utiliza como una parte de las funciones de vigilancia v
administracin del hogar.
Vi nod ( af i rmando con l a c abe z a) : S, me parece
recordar que la usamos como parte de nuestros anlisis
de CRC para la administracin del hogar.
Ed: Lo hicimos. De cualquier manera, la estoy refinando
para el diseo. Q uiero mostrar cmo implementaremos
5 Una forma menos formal de enunciar la Ley de Demter es "Cada unidad debe hablar slo con sus
amigos; no con extraos."
TM
PDF Editor
realmente la clase Pl anodePl ant a. Mi idea es
implementarla como un conjunto de listas ligadas [una
estructura de datos especfica]. Entonces, tuve que
refinar la ciase de anlisis Pl anodepl ant a (figura
8.14) y, en realidad, hasta simplificarla.
Vi nod: La clase de anlisis slo mostraba cosas en el
dominio del problema, bueno, realmente sobre la
pantalla de la computadora, que fueran visibles paro el
usuario final no?
Ed: S, pero para la clase de diseo Pl anodePl ant a
tengo que agregar algunas cosas que son
mplementacin especfica. Necesitaba mostrar que
Pl anodePl ant a es una agregacin de segmentos - y
por ende la clase Se gme nt o- y que la clase
Se gme nt o est compuesta de listas para segmentos de
pared, ventanas, puertas y cosas as. la clase Cmara
colabora con Pl anodePl ant a y, obviamente, puede
haber muchas cmaras en el plano de planta.
Vi nod: Bueno, veamos una fotografa de esta nueva
clase de diseo Pl anodePl ant a.
(Ed le muestra el esquema de la figura 9.3.)
Vi nod: De acuerdo, veo lo que ests tratando de hace-
Esto te permite modificar fcilmente el plano de planta
porque puedes agregar nuevos elementos o borrar otro?
de la lista -l a agregacin- sin ningn problema.
Ed ( af i rmando con l a cabeza) : S, yo creo que
funcionar.
Vi nod: Yo tambin.
9 . 4 EL MQ P S L Q PE P S S Q
\
CLAVE
El modelo de diseo
tiene cuatro elementos
importantes: datos,
arquitectura,
componentes e
interfaz.
El modelo de diseo puede verse en dos di mensi ones diferentes, como se ilustra e-i
la figura 9.4. La di mensi n del proceso indica la evol uci n del model o de di seo co-
forme se ej ecut an las t ar eas de di seo como una part e del pr oceso del soft ware La
di mensi n de abstraccin represent a el gr ado de detalle a medi da que cada eleme*
t o del model o de anlisis se t ransforma en un equi val ent e del di seo y despus se
refina de una maner a iterativa. En la figura, la lnea punt eada indica la front era entre
los model os de anlisis y diseo. En algunos casos se distingue con claridad entre l:s
model os de anlisis y diseo; en otros, el model o de anl i si s se combi na con el dist
o y la distincin resulta menos obvia.
Los el ement os del model o del di seo utilizan muchos de los di agr amas en Uin-
aplicados en el model o de anlisis. La diferencia es que est os di agr amas est n r ei -
nados y el aborados como par t e del diseo; se proporci ona un mayor detalle para ;
i mpl ement aci n especfica y se resal t an la est ruct ura y el estilo arquitectnicos, 1:
component es que resi den dent r o de la arqui t ect ura y las i nt erfaces ent re los comp:
nent es y con el mundo exterior.
"Los pr e gunt a s acerca d e si el di seo es necesar i o o evi t abl e est n bas t ant e f ue r a de l ugar : el di s eno es i nevi t abl e, l a
al t er nat i va al bue n di seo e s el mal di seo y no su i nexi st enci a. "
Do u g l a s Ma r t i n
Sin embargo, es i mport ant e menci onar que los el ement os del model o anot ados ;
lo largo del eje hori zont al no si empre se desarrollan de una maner a secuencial. E~
la mayor a de los casos, el di seo arqui t ect ni co preliminar est abl ece la plataforrr =
y lo siguen el di seo de i nt erfaz y el di seo al nivel de component es, los cuales 3
menudo s e realizan en paralelo. El model o de despliegue con frecuenci a se retrase
hast a que el di seo ha sido desarrol l ado por compl et o.
TM
PDF Editor
CAPTULO 9 I NGE NI E R A DEL D I S E O 263
Dimensiones del modelo de diseo.
Alto
ode l o de anl i si s
O
O
e
*5
c
E
o
Di a g r a ma s d e c l a s e
Pa q ue t e s d e anl i s i s
Mo d e l o s CRC
Di a a r a ma s d e
c o l a b o r a c i n
Di a g r a ma s d e f l uj o
d e d a t o s
Di a g r a ma s d e f l uj o
d e cont r ol
Na r r a t i v a s d e
p r o c e s a mi e n t o
Re a l i z a c i o n e s d e cl as
d e d i s e o
Su b s i s t e ma s
Di a g r a ma s d e
de di seo
Boj o
Refinamientos c
Re a l i z a c i one s d e c l a s e s
d e d i s e o
Su b s i s t e ma s
Di a g r a ma s d e
Ca s o s d e us o - t ext o
Di a g r a ma s d e c a s o
d e us o
Di a g r a ma s d e a c t i vi d a d
Di a g r a ma s d e car r i l
Di a g r a ma s d e
Di a g r a ma s d e e s t a d o
Di a g r a ma s d e s e c u e n c i a
Di s e o d e i nf er as e
t c n i c a
Di s e o d e n a v e g a c i n
Di s e o d e I GU
Di a g r a ma s d e c l a s e
Pa q u e t e s d e a n l i s i s
Mo d e l o s CRC
Di a a r a ma s d e
Di a g r a ma s d e f
d e d a t o s
Di a a r a ma s d e flujo
d e l cont r ol
Na r r a t i v a s d e
p r o c e s a mi e n t o
Di a g r a ma s d e e s t a d o
Di a g r a ma s d e c o mp o n e n t e
Cl a s e s d e d i s e o
Refinamientos a:
Requi s i t os :
Res t r i cci ones
I n t e r o p e r a b i l i d a d
Ob j e t i v o s y
c o n f i g u r a c i n
Re a l i z a c i o n e s d e c l a s e
d e d i s e o
Subs i s t e ma s
Di a g r a ma s d e c o l a b o r a c i n
Di a g r a ma s d e d e s p l i e g u e
El e me nt os
a r q ui t e c t ni c os
El e me nt os
d e i nt e r f a z
El e me nt os al ni vel
d e c o mp o n e n t e s
El ement os al ni vel
del d e s p l i e g u e
Di mensi n del proceso
*VE
' t a
el diseo
e enfoca en
i boses de
I de los
.el
datos
las
de datos
quieren para
: los
* datos
9.4.1 Elementos del diseo de datos
Al igual que ot ras actividades de la ingeniera del soft ware, el diseo de datos (algu-
nas veces l l amado arquitectura de datos) crea un model o de dat os o i nformaci n que
se represent a con un alto grado de abstraccin (la visin de los dat os del cl i ent e/ usua-
rio). Despus, est e model o de dat os se refina en represent aci ones que de maner a
progresiva tienen una i mpl ement aci n especfica y que pueden procesarse medi an-
te el si st ema basado en comput ador a. En muchas apl i caci ones de sof t war e la arqui-
tectura de los dat os tendr una profunda influencia sobre la arqui t ect ura del soft wa-
re que los debe procesar.
La est ruct ura de los dat os si empre ha sido una parte i mport ant e del di seo del
soft ware. Al nivel de los component es del si st ema, las est ruct uras del di seo de
dat os y los al gori t mos con que se mani pul an son esenci al es para la creaci n de apli-
caci ones de alta calidad. Al nivel de aplicacin, la traduccin de un model o de dat os
(obtenido como una base de la ingeniera de requisitos) a una base de dat os es esen-
cial para al canzar los objetivos de negoci o de un si st ema. Al nivel de negoci os, la
coleccin de i nformaci n al macenada en bases de dat os di spersas y reorgani zadas
en una "conjuncin de dat os" permite la explotacin de dat os o el descubri mi ent o de
un conoci mi ent o que puede t ener un i mpact o sobre el xito del mi smo negocio. En
TM
PDF Editor
\
CLAVE
El modelo
arquitectnico se
derivo del dominio de
aplicacin, del modelo
de anlisis y de los
estilos y potrones
disponibles.
cada caso, el di seo de dat os j uega un papel i mport ant e. El di seo de dat os se exp:
ca con mayor detalle en el captulo 10.
9.4.2 Elementos del diseo arquitectnico
El diseo arquitectnico para el sof t war e es el equi val ent e al pl ano de pl ant a de u r :
casa. Este pl ano muest ra la confi guraci n general de las habi t aci ones, su t amaf
forma y las rel aci ones ent re ellas, y las puert as y vent anas que permi t en el mov
mi ent o haci a y desde los cuart os. El pl ano de pl ant a proporci ona una visin gl ot :
de la casa. Los el ement os del di seo arqui t ect ni co dan una visin general del so:
ware.
"Puedes usor un borrador en lo tabla de diseo o un martillo en el sitio de construccin."
Frank l l oyd Wrigbt
El model o arqui t ect ni co [SHA96] se obt i ene a partir de t res fuent es: I) la infc -
maci n acerca del domi ni o de aplicacin para el soft ware que se va a construir
los el ement os del model o de anlisis especfico, tales como di agramas de flujo a:
dat os o cl ases de anlisis, sus rel aci ones y col aboraci ones para el probl ema que
tiene a la mano, y 3) la disponibilidad de pat rones (seccin 9.5) y estilos arquitect
nicos (captulo 10).
9.4.3 Elementos de diseo de interfaz
El diseo de interfaz para soft ware es el equi val ent e a un conj unt o de di buj os deta
liados (y especificaciones) para puert as, vent anas y utilidades ext ernas de una casa.
Estos di buj os represent an el t amao y forma de las puer t as y vent anas, la maner a er
que operan, la maner a en que las conexi ones de las utilidades (como agua, e n e r e :
elctrica, gas, telfono) llegan a la casa y se distribuyen ent re las habi t aci ones reprt
sent adas en el pl ano de planta. Estos di buj os indican dnde est l ocal i zado el t i r
bre de la puert a, si hay un i nt ercomuni cador que anunci e la presenci a de un vista-
t e y cmo est instalado el si st ema de seguridad. En esenci a, los di buj os (y especifi-
caciones) det al l ados para las puertas, vent anas y utilidades ext ernas indican con-
fluyen las cosas y la i nformaci n desde y haci a la casa y dent ro de las habitaciones
que son part e del pl ano de planta. Los el ement os del di seo de i nt erfaz para so::
war e muest r an cmo fluye la i nformaci n haci a o fuera del si st ema y cmo st e es: :
comuni cado ent re los component es definidos como part e de la arquitectura.
"El pblico est ms fomiliarizodo con el diseo molo que con el bueno. En efecto, est condicionado o preferir el mal diseo porque ?
con lo que vive. Lo nuevo es omenozonte, lo viejo es seguro."
Existen t res el ement os i mport ant es del di seo de interfaz: 1) la i nt erfaz con e
usuari o (IU); 2) i nt erfaces ext ernas a ot ros si st emas, artefactos, redes u ot ros pr<
duct ores o consumi dor es de i nformaci n; y 3) i nt erfaces i nt ernas ent re vari os con"
TM
PDF Editor
KVE
s portes paro
de diseo
. la interfaz
i las
con sistemas
l i o
ros
am
dentro
ponent es de diseo. Estos el ement os de di seo de i nt erfaz permiten al sof t war e
comuni car se de maner a ext erna y permi t en la comuni caci n y col aboraci n i nt erna
ent re los component es que puebl an la arqui t ect ura del soft ware.
El di seo de la IU es una accin primordial de la ingeniera de soft ware, y se con-
sidera con detalle en el captulo 12. El di seo de una IU incorpora el ement os estti-
cos (por ej empl o, distribucin, color, grficas, mecani smos de interaccin), el emen-
tos er gonmi cos (por ejemplo, i nformaci n y ubicacin de la distribucin, met foras,
navegaci n de la IU), y el ement os t cni cos (como pat r ones de la IU, component es
reutilizables). En general, la IU es un subsi st ema ni co dent ro de la arquitectura de
aplicacin general .
El di seo de las i nt erfases ext ernas requiere i nformaci n definitiva acerca de la
ent i dad hacia donde se manda o recibe la i nformaci n. En t odos los casos, est a
i nformaci n debe recopilarse durant e la ingeniera de requisitos (captulo 7) y verifi-
carse una vez que comi ence el di seo de la interfaz. 6 El di seo de i nt erfases ext er-
nas debe incorporar revisin de errores y (cuando sea necesario) caract er st i cas
apr opi adas de seguri dad.
El di seo de las i nt erfaces i nt ernas est cer canament e al i neado con el di seo al
nivel de los component es (captulo 11). Las real i zaci ones del di seo de cl ases de
anlisis represent an t odas las oper aci ones y es quemas de mensaj es requeri dos para
permitir la comuni caci n y col aboraci n ent re las oper aci ones de vari as clases. Cada
PDAInalmbrico
TelfonoMvil
PaneldeControl
pantallaLCD
indicadoresLED
caractersticasTeclado
bocino
interfaselnalmbrica
leerGolpedeTeclal)
decodificarTeclaj)
desplegarEstatus()
luzLEDs))
enviarMensajeControl(
l Teclado
I n t e r f a z
Teclado
eerGolpedeTecla(
decodificarTecla()
6 No resulta poco comn que las caractersticas de la interfaz cambien con el tiempo. Por lo tanto, un
diseador debe asegurar que la especificacin para la interfaz se mantenga actualizada.
TM
PDF Editor
En www. os e i t . c om
puede encontrase
inforrootin muy
v o t a saine el dise ci
detall).
mensaj e debe ser di seado para aj ust arse a la t ransferenci a de i nformaci n de requi-
sitos y los requeri mi ent os funci onal es especficos de la operaci n que ha sido solici
t ada.
En al gunos casos, una i nt erfaz se model a de una maner a muy pareci da a u r ;
clase. El UML define una interfaz de la siguiente maner a [OMGOl]: "Una interfaz es
un det er mi nant e de las operaci ones [pblicas] visibles de maner a ext ema de una
clase, component e u ot ro clasificador (incluidos los subsi st emas) sin especificacin
de est ruct ura interna". Dicho de un modo m s simple, una i nt erfaz es un conj unt :
de oper aci ones que describe part e del compor t ami ent o de una clase y proporciona
acceso a esas operaci ones.
Por ejemplo, la funcin de seguridad de HogarSeguro empl ea un panel de contrc
que permi t e al propietario de la casa controlar ciertos aspect os de la funcin de
seguri dad. En una versin avanzada del sistema, las funci ones del panel de cont r.
pueden i mpl ement arse va PDA i nal mbri co o t el fono mvil.
La clase Panel deCont rol (figura 9.5) proporci ona el compor t ami ent o asoci ad;
con un teclado y, por lo tanto, debe implementar operaci ones de leerTeclaPresionada
y decodificafTecia(). Si est as oper aci ones se sumi ni st rarn a otra clase (en est e casc
a PDAInal mbri co y Tel fonoMvi l ), resulta intil definir una interfaz como :
que se muest ra en la figura. La i nt erfaz l l amada Tecl ado se muest ra como un este-
reotipo de i n t e r f a z o como un crculo pequeo y et i quet ado que se conecta :
la clase con una lnea. La interfaz se defi ne sin atributos y con el conj unt o de ope
raci ones necesar i as para lograr el compor t ami ent o de un teclado.
"Un error comn que comet en las per sonas cuando t rat an de di sear al go compl et ament e a pr ueba de t ont os es
subest i mar la i ngenui dad de los que son compl et ament e t ont os. "
Do u g l a s Ad a ms
La lnea punt eada con un tringulo abierto en su ext remo (figura 9.5) indica qu;
la clase Panel deCont rol proporci ona oper aci ones de Tecl ado como part e de su
comport ami ent o. En UML est o se caracteriza como una realizacin. Esto es, parte de
compor t ami ent o de Panel deCont rol se i mpl ement ar al realizar las operaci ones de
Tecl ado. Estas operaci ones se proporci onarn a ot ras cl ases que ent ren a la inter-
faz.
9.4.4 Elementos de diseo al nivel de componentes
El di seo al nivel de component es para el sof t war e equivale a un conj unt o de dibu
jos det al l ados (y especificaciones) para cada cuart o en una casa. Estos di buj os mues-
tran el al ambr ado y la instalacin sani t ari a dent ro de cada cuart o, la ubicacin de lo;
recept cul os elctricos e interruptores, llaves, lavabos, tinas, desag es y armari os
Tambin descri ben los pisos que se usarn, los mol des que se aplicarn, y cualquier
ot ro detalle asoci ado con el cuarto. El di seo al nivel de component es para softwa
re descri be por compl et o el detalle i nt erno de cada component e del soft ware. Para
TM
PDF Editor
267
a de
ite
para
-nsor.
lograrlo el di seo al nivel de component es defi ne est ruct uras de dat os para t odos los
obj et os de dat os locales, as como detalle algortmico para t odo el pr ocesami ent o
que ocurre dent ro de un component e y una interfaz que permi t e el acceso a t odas
las operaci ones de los component es (comportamientos).
" l os df italles no son los detalles. Ellos hacen el diseo. "
Char l es l a me s
Dentro del cont ext o de la ingeniera del soft ware ori ent ada a objetos, un compo-
nent e se represent a a maner a de di agrama en UML como se muest ra en la figura 9.6.
En esta figura se represent a un component e llamado Manej oSens or (parte de la
funcin de seguridad de HogarSeguro). El component e est conect ado a una clase
l l amada Sensor, la cual est asi gnada a st e medi ant e una flecha punt eada. El com-
ponent e Manej oSens or realiza t odas las funci ones asoci adas con los sensor es de
HogarSeguro, ent re las que se encuent r an su moni t oreo y configuracin. En el cap-
tulo 11 se present a una explicacin ms a fondo acerca de los di agr amas de com-
ponent e.
Los detalles de di seo de un component e se pueden model ar a muchos grados dis-
tintos de abstraccin. En la represent aci n del procesami ent o lgico se puede utilizar
un di agrama de actividad. El flujo detallado de procedi mi ent o para un component e
puede represent arse, ya sea medi ant e un pseudocdi go (una represent aci n del tipo
de l enguaj e de programaci n que se describe en el captulo 11), o de algn format o
diagramtico (por ejemplo, un di agrama de actividad o un di agrama de flujo).
9.4.5 Elementos de diseo al nivel del despliegue
Los el ement os de di seo al nivel del despliegue indican cmo se ubicarn la funcio-
nal i dad y los subsi st emas dent r o del ent or no comput aci onal fsico que soport ar al
soft ware. Por ej empl o, los el ement os del product o HogarSeguro est n confi gurados
para operar dent ro de tres ent or nos de comput aci n primarios: una PC domst i ca, el
panel de control de HogarSeguro y un servidor ubi cado en CP1 Corp. (lo que propor-
ciona acceso al si st ema a t ravs de Internet).
Durant e el di seo se desarrolla un di agrama de despliegue en UML y despus se
refina, como se muest ra en la figura 9.7. En st a se muest r an t res ambi ent es com-
put aci onal es (en realidad, deber a haber ms, si se incluyen sensores, cmar as y
otros). Se indican los subsi st emas (funcionalidad) que se al oj an dent ro de cada ele-
TM
PDF Editor
Di agrama de
despliegue
en UML par a
HogarSeguro.
Panel de control
Seguridad
/
Servidor de CP1
AccesoPropietario
V
7
Computadora persona|
Acceso externo >
Seguridad Vigilancia
, 4
'
AdministracinHogar Comunicacin
/
%.
CLAVE
Los diagramas de
despliegue comienzan
en un formato
descriptor, donde el
entorno de despliegue
se describe en
trminos generales.
Despus se utilizo un
formato de instancia y
se describen de
manera explcito los
ment de cmput o. Por ejemplo, la comput ador a personal aloja subsi st emas que
i mpl ement an seguridad, vigilancia, admi ni st raci n del hogar y caractersticas ce
comuni caci n. Adems, se ha di seado un subsi st ema de acceso ext erno para con-
trolar t odos los i nt ent os de acceso al si st ema HogarSeguro desde una f uent e exter-
na. Cada subsi st ema sera el aborado par a indicar los component es que implemento
El di agrama most rado en la figura 9.7 est en forma de descriptor. Esto significa
que el di agrama de despliegue muest ra el ent or no comput aci onal , pero no indica ce
maner a explcita det al l es de confi guraci n. Por ejemplo, no se identifica la "compu-
t adora personal". Podra ser una "Wintel" PC o una Macintosh, una est aci n de tra-
baj o Sun o una Linux-box. Estos detalles s e proporci onan cuando el di agrama de
despliegue se revisa en forma de instancia durant e et apas post eri ores del di seo o
cuando comi enza la const rucci n. Se identifica cada instancia del despliegue (una
confi guraci n de har dwar e con un nombr e especfico).
configuracin.
"Deja t odo y retrate, tomo una pequea relajacin. Cuando regreses al t rabaj o, t u juicio ser ms seguro. Toma algo
de distancio porque entonces el t rabaj o parece ms pequeo, una mayor port e del mismo puede ser capt urado en uno
mi rada y lo falta de armoni o y pr opor dn se observo con ms facilidad."
Leonar do DaVinci
TM
PDF Editor
269
Los mej or es di seador es en cualquier campo de t rabaj o tienen la misteriosa habi-
lidad de vi sl umbrar pat r ones que caract eri zan un probl ema y los pat r ones corres-
pondi ent es que pueden combi narse para crear una solucin. A t ravs del pr oceso de
di seo, un i ngeni ero de sof t war e debe buscar toda oport uni dad para reutilizar pat ro-
nes de di seo exi st ent es (cuando cumpl en las necesi dades de un diseo) en vez de
crear nuevos.
9.5.1 Descripcin de un patrn de diseo
Las disciplinas madur as de la ingeniera utilizan miles de pat r ones de diseo. Por
ejemplo, un ingeniero mecni co utiliza un eje de dos pasos como un pat rn de dise-
o clave. Los at ri but os (di met ros del eje, di mensi ones del orificio de las llaves, et c-
tera) y las oper aci ones (por ej empl o, la rotacin del giro y la conexi n del giro) son
i nherent es al pat rn. Un i ngeni ero elctrico utiliza un circuito i nt egrado (un pat rn
de di seo en ext r emo complejo) para resolver un el ement o especfico de un proble-
ma nuevo. Los pat r ones de di seo pueden describirse empl eando la plantilla [MAI03]
que se muest ra en el recuadro "Plantilla del pat rn de diseo".
INFORMACIN
Plantilla del patrn de diseo
Nombre del patrn: describe lo esencia del
patrn en un nombre corto, pero expresivo,
i: describe el patrn y lo que hace.
-conocido-como: lista los sinnimos para el
en: proporciona un ejemplo del problema.
lidad: anota situaciones especficas de diseo en
es aplicable el patrn.
: describe las clases que se requieren para
*tar el patrn.
Participantes: describe las responsabilidades de las clases
que se requieren para implementar el patrn.
Colaboraciones: describe cmo colaboran los participantes
para llevar a cabo sus responsabilidades.
Consecuencias: describe las "fuerzas de diseo" que
afectan al patrn y los intercambios potenciales que deben
considerarse cuando se implemento el patrn.
Patrones relacionados: patrones de diseo relacionados
mediante referencias cruzadas.
y
VE
de diseo
1 aquellos
lo solucin
i lo forma
se puede
el diseo.
Una descripcin del pat rn de di seo puede consi derar t ambi n un conj unt o de
f uer zas de diseo. Las fuerzas de diseo descri ben requisitos no funci onal es (por
ej empl o, facilidad de mant eni mi ent o, portabilidad) asoci ados con el sof t war e en el
que se aplicar el pat rn. Adems, las f uer zas defi nen las limitaciones que restrin-
gen la maner a en que se i mpl ement ar el diseo. En esenci a, las fuerzas de di seo
descri ben el ambi ent e y las condi ci ones que deben existir para que el pat rn del
di seo sea aplicable. Las caractersticas del pat rn (clases, responsabi l i dades y cola-
boraciones) indican los at ri but os aj ust abl es del di seo para permitir que el pat rn se
aj ust e a una variedad de pr obl emas (GAM95). Estos at ri but os represent an caract e-
rsticas del di seo que pueden buscarse (por ejemplo, a t ravs de una base de datos)
TM
PDF Editor
270
para que sea factible encont r ar un pat rn apropi ado. Por ltimo, la gua asocia i.i
con el us o de un pat rn de di seo indica las rami fi caci ones de las deci si ones 3=11
diseo.
Q u t i p o s
de p a t r o n e s
de d i s e o e s t n
d i s poni bl e s p a r a
el i nge ni e r o d e
s o f t wa r e ?
"Los pot rones estn o medi o hornear, lo que significo que siempre debes terminarlos y adapt arl os a tu propio
ent orno. "
Ma r t n Fo wf e t
Los nombr es de los pat r ones de di seo deben elegirse con cui dado. Uno de i a
probl emas t cni cos clave en la reutilizacin de sof t war e es la falta de habilidad p a a
encont r ar pat r ones reutilizables exi st ent es, a pesar de que existen ci ent os o miles x
pat rones. La bsqueda del pat rn "correcto" tiene un apoyo i nmenso si se cuerna
con un nombr e significativo del pat rn.
9.5.2 Utilizacin de patrones en el diseo
Los pat r ones de di seo pueden usarse durant e el di seo del soft ware. Una vez q j -
se ha desarrol l ado el model o de anlisis (captulo 8), el di seador puede exar r . - -
una represent aci n det al l ada del probl ema que debe resolver y las restricciones jjc
i mpone el probl ema. La descripcin del pr obl ema se exami na en varios grados
abstraccin para determinar si es flexible para uno o ms de los siguientes tipos de pas - j
nes de diseo.
Pat rones arqui t ect ni cos. Estos pat r ones defi nen la est ruct ura general del
ware, indican las rel aci ones ent re los subsi st emas y los component es del so
y defi nen las regl as par a especificar las rel aci ones ent re los el ement os (el
paquet es, component es, subsi st emas) de la arquitectura.
Pat rones de di s eo. Estos pat r ones se aplican a un el ement o especfico
di seo como un agregado de component es para resolver algn probl ema de di:
rel aci ones ent r e los component es o los mecani smos par a efect uar la comuni c
de component e a component e.
Idi omas. A veces l l amados patrones de cdigo, est os pat r ones especficos de
guaj e por lo general i mpl ement an un el ement o algortmico o un component e
prot ocol o de interfaz especfico o un mecani smo de comuni caci n ent re los coi rp: -
nent es.
Cada uno de los tipos de pat r ones difiere en el grado de abst racci n con e.
est r epr esent ado y con el grado en el que proporci ona una gua directa para la a a
vidad de const rucci n (en est e caso, codificacin) del pr oceso de sof t war e
9.5.3 Marcos de trabajo
En al gunos casos es necesari o proporci onar una i nfraest ruct ura esqueltica es r ^
fica de i mpl ement aci n, l l amada marco de trabajo, para el t rabaj o de diseo. Est:
el di seador puede seleccionar una "miniarquitectura reutilizable que ofrezca el
TM
PDF Editor
CAPITULO 9 INGENIERA DEL DISEO 271
por t ami ent o y la est ruct ura genri ca para una familia de abst racci ones de soft ware,
j unt o con un cont ext o. . . que especifique su col aboraci n y uso dent ro de un domi-
K V E nio dado" [APP98).
! trabajo es U n m a r c o de t rabaj o no es un pat rn arquitectnico, si no un esquel et o con una
> de cdigo coleccin de "punt os de conexi n" (tambin l l amados ganchos y ranuras) que le per -
miten adapt ar se a un domi ni o de un probl ema especfico. Los punt os de conexi n
; tJn c'oses permi t en al di seador integrar cl ases o funci onal i dad especficas del probl ema den-
tro del esquel et o. En un cont ext o ori ent ado al objeto, un mar co de t rabaj o es una
coleccin de cl ases que cooperan.
En esenci a, el di seador de un mar co de t rabaj o ar gument ar que una miniarqui-
t ect ura reutilizable se puede aplicar a t odo el soft ware que se desarrollar dent ro de
un domi ni o limitado de aplicacin. Para que sean ms efectivos, los mar cos de tra-
baj o se aplican sin cambi os. Se pueden agregar el ement os de di seo adicionales,
per o sl o a t ravs de los punt os de conexi n que permi t en que el di seador desa-
rrolle el esquel et o del mar co de trabajo.
La ingeniera de di seo comi enza cuando la pri mera iteracin de la ingeniera de
requisitos llega a su fin. La finalidad del di seo de sof t war e es aplicar un conj unt o
de principios, concept os y prct i cas que conducen al desarrol l o de un si st ema o pro-
duct o de alta calidad. La met a del di seo es crear un model o de soft ware que imple-
ment e t odos los requisitos del cliente de maner a correcta y compl azca a aquel l os
que lo usen. Los i ngeni eros de di seo deben exami nar por medi o de muchas alter-
nat i vas de di seo y converger en la solucin que mej or cumpl a las necesi dades de
los i nt eresados en el proyecto.
El proceso de di seo avanza de una visin general de soft ware a una visin m s
est recha que defi ne el detalle requeri do para i mpl ement ar un si st ema. El proceso
comi enza con un enf oque en la arquitectura. Se defi nen los subsi st emas; s e est abl e-
cen mecani smos de comuni caci n ent re los subsi st emas; se identifican los compo-
nent es; y se desarrolla una descripcin det al l ada de cada component e. Adems, se
di sean las i nt erfases i nt ernas, ext ernas y del usuari o.
Los concept os de di seo han evol uci onado en la pri mera mitad del siglo de tra-
baj o de la ingeniera del soft ware. Estos concept os descri ben at ri but os del soft ware
de comput ador a que deben est ar present es sin i mport ar el proceso de ingeniera del
sof t war e que se elija, los mt odos de di seo que se apliquen, o los l enguaj es de pro-
gramaci n que utilicen.
El model o de di seo abarca cuat ro el ement os diferentes. En la medi da en que s e
desarrolla cada uno de est os el ement os evol uci ona una visin ms compl et a del
diseo. El el ement o arqui t ect ni co utiliza i nformaci n derivada del domi ni o de apli-
caci n, el model o de anlisis y cat l ogos disponibles para pat r ones y estilos que
deriven una represent aci n estructural compl et a del soft ware, sus si st emas y com-
TM
PDF Editor
ponentes. Los el ement os de diseo de interfaz modelan interfaces internas y exter-
as y la interfaz del usuario. Los el ement os al nivel de component es definen caza
uno de los mdul os (componentes) que pueblan la arquitectura. Por ltimo, los t
ment os de di seo al nivel de despliegue asignan la arquitectura, sus componentes
las interfases a la configuracin fsica que albergar el software.
El diseo basado en pat rones es una tcnica que reutiliza el ement os de dis
que han probado ser exitosos en el pasado. Cada patrn arquitectnico, patrn
diseo o idioma se cataloga, se document a por completo y se considera cuidadc
mente cuando se evala para incluirlo en una aplicacin especfica. Los marcos
trabajo, una extensin de los patrones, ofrecen un esqueleto arquitectnico para
diseo de subsistemas completos dentro de un dominio de aplicacin especfica
[AMB01J Ambler, S.. The Objecl Primer. Cambri dge Univ. Press, 2a. ed., 2001.
[APP98] Appleton, B "Patterns and Soft ware: Essential Concept s and Termi nol ogy, pur x.
obt enerse en ht t p: / / www. ent er act . com/ ~br adapp/ docs/ pat t ems- i nt r o. ht ml .
[ARL02] Arlow,). e I. Neusdadt, UML and the Unified Process, Addison-Wesley, 2002.
[BEL81] Belady, L., prlogo de Software Design: Methods and Techniques (L. J. Peters, aut or), '
don Press, 1981.
FOWOO] Fowler, M. et ai, Re/aclorng. Improving the Design of Esting Code, Addison-We
2 0 0 0 .
[GAM951 Gamma, E. et al., Design Patterns, Addison-Wesley, 1995.
[GAR95] Garlan, D. y M. Shaw, "An lntroduction to Soft ware Architecture", en Advances
Software Engineering and Knowledge Engineering, vol. I (V. Ambriola y G. Tortora, eds. ) '
Scientific Publishing Company, 1995.
[GRA87] Grady, R. B. y D. L. Casswell, Software Metrics: Establishing a Company-Wide Program. ]
Prentice-Hall, 1987.
[JAC75] Jack son, M. A., Principies ofProgram Design, Academic Press, 1975.
[UE03] Lieberherr, K., "Demeter: Aspect-Oriented Programming", mayo de 2003, disponible i
ht t p: / / www. ccs. neu. edu/ home/ l i eber / LoD. ht ml .
[MA103) Maioriello, J., "What Are Design Pat t erns and Do 1 Need Them?", devel oper. com, ;
disponible en ht t p: / / www. devel oper . com/ desi gn/ ar t i cl e. php/ 147456l .
[MCG91 ] McGlaughlin, R., "Some Notes on Program Design". en Software Engineering Notes
16, nm. 4, oct ubre de 1991, pp. 53-54.
[MYE78] Myers, G Composite Structured Design, Van Nostrand, 1978.
[OMGOl] Object Management Group, OMG Unified Modeling Language Speciftcaon, versir
sept i embre de 2001.
IPAR721 Pamas, D. L., "On Criteria to be used in Decomposi ng Syst ems into Modules",
vol. 14, nm. 1, abril de 1972, pp. 221-227.
[ROS75] Ross, D., I Goodenough y C. Irvine, "Soft ware Engineering: Process, Principies
Goals", en IEEE Computer, vol. 8, nm. 5, mayo de 1975.
[SCH02] Schmul l er, ). , Teach YourseifUML, SAMS Publishing, 2002.
[SHA96] Shaw, M. y D. Garlan. Software Architecture, Prentice-Hall, 1996.
[STA02] "Metaphor", en The Stanford HCl Leammg Space, 2002, ht t p: / / hci . St anf or d. edu/ hcf cl
concept s/ met aphor . ht ml .
[STE74] Stevens, W G. Myers y L. Constantine, "Structured Design", en IBM Systems )ouma :
13, nm. 2, 1974. pp. 115-139.
[W1R71] Wirth, N., "Program Devel opment by Stepwise Refinement", en CACM, vol. 14, n u - -
1971, pp. 221-227.
TM
PDF Editor
PROBLEMAS Y PUNTOS A CONSI DERAR
9. 1. Se di sea un soft ware cuando se "escribe" un programa? Q u es lo que hace que el dise-
o de soft ware sea diferente a la generaci n de cdigo?
9. 2. Si un di seo de soft ware no es un programa (de hecho no lo es), ent onces, qu es?
9. 3. Cmo se eval a la calidad de un di seo de soft ware?
9. 4. Examinar el conj unt o de t areas pr esent adas par a un diseo. Cundo se eval a ia calidad
dent ro del conj unt o de tareas? Cmo se logra esto?
9. 5. Dar ej empl os de t res abst racci ones de dat os y abst racci ones procedi ment al es que puedan
utilizarse par a manipularlas.
9. 6. Describir con ar gument os propi os la arqui t ect ura de soft ware.
9. 7. Sugerir un pat rn de di seo rel aci onado con una categoria de cosas cot i di anas (por ej em-
plo, product os electrnicos, aut omvi l es, aparat os). Document ar el pat rn con ayuda de la
plantilla que se present a en la seccin 9.5.
9. 8. Existe algn caso en el que los probl emas compl ej os requieran de menos esf uer zo para
resolverse? Cmo afectara ese caso el ar gument o para la modul ari dad?
9. 9. se debe i mpl ement ar un di seo modul ar como soft ware monoltico? Cmo se puede
lograr esto? El desempeo es la nica justificacin par a la i mpl ement aci n del soft ware mono-
ltico?
9. 10. Explicar la relacin ent re el concept o de ocultacin de i nformaci n como un atributo de
modul ari dad efectiva y el concept o de i ndependenci a del mdulo.
9. 11. Cmo se relacionan los concept os de acopl ami ent o y portabilidad del soft ware? Dar
ej empl os que apoyen la explicacin.
9. 12. Aplicar un "enfoque de refi nami ent o paso a paso" para desarrollar t res gr ados di ferent es
de abstraccin procedi ment al par a uno o ms de los si gui ent es programas: a) Desarrollar una
mqui na que expida cheques que, al dar una cant i dad numri ca en dlares, imprima la canti-
dad en pal abras que por lo general se requiere en un cheque; b) resolver de maner a iterativa la
raiz de una ecuaci n t rascendent al ; c) desarrollar una t area simple que pl anee algoritmos para
un si st ema operativo.
9. 13. Realizar una pequea investigacin sobre programaci n ext rema y escribir un texto
breve acerca de la refabricacin para un proceso de desarrollo de soft ware gil.
9. 14. Visitar un depsito de pat r ones de di seo (en la web) y navegue por unos mi nut os a tra-
vs de los pat rones. Elegir uno y present arl o ant e los compaer os de clase.
Donald Norman ha escrito dos libros (The Design o/Eveiyday Things, Doubleday, 1990, y The
Psychology of Everyday Things, HarperCollins, 1988) que se han convertido en clsicos en la
bibliografa sobre di seo y "debe" leerlos cualquiera que di see cualquier cosa que usen los
humanos. Adams (Conceptual Blockbusting, 3a. ed., Addison-Wesley, 1986) ha escrito un libro
que es una lectura esencial para los di seadores que quieran ampl i ar su maner a de pensar. Por
ltimo, un texto clsico de Polya (How to Solve It, Princeton University Press, 2a. ed 1988) pro-
porci ona un proceso de resolucin de pr obl emas genri co que puede ayudar a los di seadores
de soft ware al enf r ent ar se con probl emas compl ej os.
Dentro de la mi sma tradicin, Winograd el al. (Bringing Design lo Software, Addison-Wesley,
1996) anal i za los di seos de soft ware que funci onan, los que no funci onan y por qu. Un libro
fasci nant e editado por Wixon y Ramsey (Field Methods Casebook for Software Design, Wiley,
TM
PDF Editor
274
1996) sugiere mt odos de investigacin de campo (muy pareci dos a los que utilizan los a n "
plogos) para ent ender cmo los usuari os finales hacen el t rabaj o que hacen, y despus ofirec;
una gua par a di sear el soft ware que sat i sfaga sus necesi dades. Beyer y Holtzblatt (Contextj-
Design: A Customer-Centered Approach to Systems Designs, Academi c Press, 1997) ofrecen o c i
visin del di seo de soft ware que i nt egra al cliente-usuario en cada aspect o del proceso e
di seo de soft ware.
McConnell (Code Complete, Microsoft Press, 1993) present a una excelente exposicin de );s
aspect os prcticos de di sear soft ware par a comput adora de alta calidad. Robertson (Siirc
Program Design, 3a. ed., Kboyd y Fraser Publishing, 1999) ofrece una til explicacin introdu;
toria del di seo de soft ware par a qui enes comi enzan su est udi o acerca del t ema. Fowler y s- s
col egas (Refactorng: Improving the Design ofExisting Code, Addison-Wesley, 1999) exponen t -
ni cas par a el mej or ami ent o i ncrement al de los di seos de soft ware.
En la dcada pasada se han escrito muchos libros sobre di seos basados en pat rones pa~
i ngeni eros de soft ware. Gamma y sus col egas [GAM95] han escrito el libro f undament al scc";
el t ema. Ot ros libros de Dougl ass (Real-Time Design Pattems, Addison-Wesley, 2002), Mets:-
(Design Pattems Applied, Wrox Press, 2002), Marinescu y Romn (EJB Design Pattems, Wiir
2001) sitan pat r ones de di seo en ambi ent es de aplicacin y l enguaj es especficos. Aderr ;
los libros cl si cos del arquitecto Christopher Al exander (Notes on the Synthesis o/Form, Har. r :
University Press, 1964, y A Pattem Language: Towns, Buildings, Construction, Oxford Uni versr
Press, 1977) debe leerlos el di seador de soft ware que pret enda compr ender a fondo los par-
ns de diseo.
En Internet se di spone de una amplia vari edad de f uent es de i nformaci n sobre ingenie-.*
de diseo. Una lista act ual i zada de referenci as en la red mundi al rel evant es par a el diseo :
soft ware y la ingeniera de di seo puede encont rarse en el sitio web de SEPA:
TM
PDF Editor
C A P T U L O
DI SEO
ARQ UITECTNICO
10
. 296
d e . . . 297
. . 288
fclo . . 287
i . .276
de . 294
de . . 284
. . 279
e datos 278
.281
. . . 3 0 2
.296
.294
E
l d i s e o s e h a d e s c r i t o c o mo u n p r o c e s o d e v a r i o s p a s o s e n el c ua l l as r e -
p r e s e n t a c i o n e s d e l a e s t r u c t u r a d e l os d a t o s y el p r o g r a ma , l as c a r a c t e r s -
t i c a s d e l a i n f o r ma c i n y el d e t a l l e p r o c e d i me n t a l s e s i n t e t i z a n a par t i r d e
l os r e qui s i t os . Es t a d e s c r i p c i n l a a mp l a F r e e ma n [FRE80]:
[D)ise es una act i vi dad rel aci onada con la t oma de deci si ones, a menudo de nat u-
ral eza est ruct ural . Compar t e con la pr ogr amaci n una pr eocupaci n rel aci onada con
abst r aer la r epr esent aci n de la i nformaci n y l as secuenci as del pr ocesami ent o, pe-
ro el gr ado de det al l es es muy di ferent e en los ext r emos. El di seo const ruye repre-
sent aci ones coher ent es y bien pl aneadas de los pr ogr amas, que se concent r an en las
i nt errel aci ones ent r e l as par t es al nivel m s el evado y las oper aci ones l gi cas e n los
ni vel es i nferi ores. . .
C o mo s e i nd i c e n el c a p i t u l o 9, el d i s e o e s t o r i e n t a d o a la i n f o r ma c i n . Los
m t o d o s d e d i s e o del s o f t wa r e s e d e r i v a n d e la c o n s i d e r a c i n d e c a d a u n o d e
l os t r e s d o mi n i o s del a n l i s i s de l mo d e l o . Lo s d o mi n i o s d e l a i n f o r ma c i n , la f u n -
c i n y el c o mp o r t a mi e n t o s i r ve n c o mo gu a p a r a el d i s e o del s o f t wa r e .
En e s t e c a p t ul o s e p r e s e n t a r n l os m t o d o s r e q u e r i d o s p a r a c r e a r " r e p r e s e n -
t a c i o n e s c o h e r e n t e s y bi e n p l a n e a d a s " d e l a s c a p a s d e l os d a t o s y la a r q u i t e c t u -
r a d e l mo d e l o d e d i s e o . El o b j e t i v o e s p r o p o r c i o n a r un e n f o q u e s i s t e m t i c o del
d i s e o a r q u i t e c t n i c o : l os p l a n o s p r e l i mi n a r e s q u e s e ut i l i zan.
Q u e s ? Ei diseo arquitectnico
r epr esent o l a est ruct ura d e dat os y
los component es del pr ogr a ma nece-
sari os p a r a construir un si st ema com-
put aci onal . As ume el estilo arqui t ec-
tnico q ue t omar el si st ema, la est ruct ura y l as
pr opi edades d e los component es que constituyen
e si st ema y l as i nt errel aci ones ent re t odos los
component es arqui t ect ni cos d e un sistema.
i n l o h a c e ? Aunque un i ngeni er o de soft-
ware pue de di s ear los dat os y la ar qui t ect ur a,
a menudo el t r a ba j o se as i gna a especi al i st as
cuando se const ruyen si st emas gr a nd e s y com-
ciejos. Un di s eador de ba s e d e dat os o d e al-
macn d e dat os cr ea la arqui t ect ura d e dat os del
sistema. El "arqui t ect o del si st ema" sel ecci ona un
estilo ar qui t ect ni co a pr opi a d o p a r a los requisi-
tos der i vados dur ant e la i ngeni er a del si st ema y
el anl i si s d e los requisitos del soft ware.
Por q u es i mpor t ant e? Nadie tratara de
construir una cas a sin un pl ano, ver dad? Tam-
poco e mpe z a r a a t r azar pi anos bos que j a ndo l a
distribucin d e la f ont aner a. Necesi t ar a un pa -
nor a ma gener al (la pr opi a cas a) ant es d e preo-
cupar s e por los detalles. Eso es lo q ue hace el di-
s eo arqui t ect ni co: pr opor ci ona una vista gene
ral y a s e gur a q ue se obt enga lo q ue se de s e a .
Cul es son los pa s os ? El diseo arquitectni-
co e mpi e z a con el di seo d e los da t os y l uego
pa s a a la deri vaci n d e una o m s r epr esent a-
ci ones de la est ruct ura ar qui t ect ni ca del siste-
ma. Se ancl z a r ' os estilos o pat r ones arqui t ec-
tnicos a: t emos pa r a der i var la est ruct ura q ue se
a mol da mej or c os requi si t os del cliente. En
275
TM
PDF Editor
cuant o se selecciona una opci n se el abor a la
arqui t ect ura empl eando un mt odo d e di seo
apr opi ado.
Cual e s el producto obt eni do? Un modelo
que a b a r c a la arqui t ect ura de los dat os y la es-
tructura del pr ogr a ma se cr ea dur ant e esta et a-
p a del di seo. Adems , se descr i ben las pr opi e-
dades de los componentes y sus relaciones interac-
ciones).
Cmo pue do est ar s eguro de que l o he
h e c h o c o r r e c t a me n t e ? En c a d a et apa se re-
visan los product os resultantes del di seo de:
soft ware par a verificar la cl ari dad, la cor r eo
cin, el gr a d o en q u e se han compl et ado y s.
consistencia con los requisitos y ent re unos
otros.
1 0 . 1 ARQ UI TECTURA DEL SOFTWARE
En su notable libro sobre el t ema, Shaw y Garlan [SHA96] analizan la arquitec:
del soft ware de la siguiente manera:
Desde la primera vez que un programa se dividi en mdulos, los si st emas de soft ware
han tenido arqui t ect uras, y los pr ogr amador es han sido responsabl es de las interacciones
ent re los mdul os y las propi edades globales del ensambl aj e. Histricamente, las arqu:-
tecturas han est ado implcitas (como acci dent es de i mpl ement aci n o si st emas heredades
del pasado). Los buenos desarrol l adores de soft ware han adopt ado con frecuenci a uno :
varios pat r ones arqui t ect ni cos como est rat egi a par a la organi zaci n del si st ema, pero los
empl ean de maner a informal y no tienen medi os para hacerl os explcitos en el sistema re-
sul t ant e.
Hoy, la arquitectura del soft ware efectiva y su representacin y diseo explcitos :
han vuelto t emas domi nant es en la ingeniera del software.
" l o ar qui t ect ur a d e un s i s t ema e s un mor co concept ual compl et o que descri be su f o r ma y est r uct ur a (sus component e:
y l a mone r o en que s e i nt e gr a n) . "
Jerrold Grochow
10.1.1 Q u es la arquitectura?
Cuando se analiza la arquitectura de un edificio vienen a la ment e muchos a tribu: J
diferentes. En el aspect o ms simple se considera la forma general de la est ruct ura
fsica. Pero, en realidad, la arquitectura es mucho ms, es la manera en que los d - j
versos component es de un edificio se integran para formar un t odo cohesionado, a
la manera en que el edificio se amol da a su ambi ent e y se combi na con otros e c - j
cios vecinos. Es el grado en el cual el edificio cumple con el propsito estableci:
en que satisface las necesi dades de su propietario. Es la percepcin esttica de la ~ |
tructura el i mpact o visual del edificio y la maner a en que las texturas, los coi :-J
res y los mat eri al es se combi nan para crear la fachada externa y el "entorno vivier-l
te" del interior. Son pequeos detalles: el diseo de la iluminacin, el tipo de piso, -a
colocacin de las cosas que cuelgan de las paredes, la lista es casi interminable - A
nalmente, se trata de un arte.
TM
PDF Editor
CAPTULO 10 DISEO ARQ UITECTNICO
277
KVE
del
model ar
de un
l i mo n e r a
0 5 Y los
irtres.
Pero qu pasa con la arquitectura del software? Bass, Cl ement y Kazman [BAS03]
defi nen est e t rmi no elusivo de la siguiente maner a:
La arquitectura del soft ware de un pr ogr ama o si st ema de cmput o es la est ruct ura o las
est ruct uras del si st ema, que incluyen los component es del soft ware, las propi edades visi-
bl es ext er nament e de esos component es y las rel aci ones ent re ellos.
La arqui t ect ura no es el sof t war e operativo. En cambi o, es una represent aci n que
permi t e que un i ngeni ero del soft ware: 1) anal i ce la efectividad del di seo para cum-
plir con los requisitos establecidos, 2) consi dere opci ones arqui t ect ni cas en una
et apa en que an resulta rel at i vament e fcil hacer cambi os al di seo, y 3) reduzca
los riesgos asoci ados con la const rucci n del soft ware.
"Csese t uont o ant es con s u ar qui t ect ur a y d e s pu s a r r e p i n t a s e a s u g u s t o . "
es tdes a
sde
N*l
IJ id.
*/
K
CLAVE
ICO
i una
] de Gestolt
s S e mo , lo que
i al ingeniero de
i exami nados
i un todo.
Esta definicin dest aca el papel de los "component es del soft ware" en cualquier
represent aci n arquitectnica. En el cont ext o del di seo arqui t ect ni co, un compo-
nent e de soft ware es al go t an simple como un mdul o del pr ogr ama o una clase
ori ent ada a objetos, per o t ambi n se ext i ende para incluir bases de dat os y middle-
ware que permi t a confi gurar una red de clientes y servidores.
En est e libro, el di seo de la arqui t ect ura del sof t war e consi dera dos niveles de la
pi rmi de del di seo (figura 9.1): el diseo de datos y el diseo arquitectnico. En el
cont ext o del anlisis anterior, el di seo de los dat os permi t e represent ar el compo-
nent e de dat os de la arqui t ect ura en si st emas convenci onal es y defi ni ci ones de cla-
se (atributos y oper aci ones de encapsul ami ent o) de los si st emas ori ent ados a obje-
tos. El di seo arqui t ect ni co se concent ra en la represent aci n de la est ruct ura de
los component es del soft ware, sus propi edades e interacciones.
10.1.2 Por qu es importante la arquitectura?
En un libro dedi cado a la arquitectura del soft ware, Bass y sus col egas IBAS03] iden-
tifican tres r azones clave por las cual es la arqui t ect ura del sof t war e es i mport ant e:
Las represent aci ones de la arqui t ect ura del sof t war e permi t en la comuni ca-
cin ent re t odas las part es (participantes) i nt eresadas en el desarrol l o de un
si st ema de cmput o.
La arqui t ect ura dest aca las deci si ones iniciales rel aci onadas con el di seo que
t endrn un i mpact o pr of undo en t odo el t rabaj o de la ingeniera del sof t war e
que le sigue y, lo que t ambi n resulta i mport ant e, en el xito final del si st ema
como ent i dad operaci onal .
La arqui t ect ura "constituye un model o rel at i vament e pequeo e intelectual-
ment e comprensi bl e de cmo est est ruct urado el si st ema y cmo t rabaj an
j unt os sus component es" [BAS03].
TM
PDF Editor
El model o de di seo arquitectnico y los pat rones arquitectnicos que contiene >JB
transferibles. Es decir, los estilos y pat rones arquitectnicos (seccin 10.3.1) se api :
al di seo de otros si st emas y represent an un conj unt o de abst racci ones que penr s r
a los ingenieros de soft ware describir la arquitectura de maner as predecibles.
I Q . 2 DI S E O PE PATOS
mm
-
La acci n de diseo de datos t raduce los obj et os de dat os definidos como parte ad
model o de anlisis (captulo 8) en est ruct uras gl obal es al nivel de component es x
soft ware y, cuando es necesario, una arqui t ect ura de base de dat os al nivel de a:
cacin. En al gunas si t uaci ones debe di searse y const rui rse una base de dat os esr-r jj
c fi cament e para un nuevo si st ema. Sin embargo, en ot ras, se empl ean una o
bases de dat os existentes.
10.2.1 Diseo de datos al nivel arquitectnico
Hoy los negoci os gr andes y pequeos est n i nundados de dat os. No resulta pocc ;
mn que incluso un negoci o de t amao moder ado t enga docenas de bases de
que sirven a muchas aplicaciones que abar can ci ent os de gigabytes de datos. E
to consi st e en ext raer i nformaci n til de est e ent or no de dat os, sobr e t odo
la i nformaci n deseada tiene funci onal i dad cr uzada (por ejemplo, informacin
sl o se obt i ene si los dat os especficos de mercadot ecni a est n rel aci onados de
era cruzada con los dat os de ingeniera del producto).
En el siguiente sitio
Web se obtiene
infonnMin ot ara de
almocn de dalos:
www.
datawurehouse.
com.
"ta calidad de los dat os mar ca lo di ferenci a ent r e un al mocn y un basur er o de dot os. "
J a r r e t t R o s e n b e u
Para resolver este desafio la comuni dad de empresas de la tecnologa de la info
cin (TI) ha desarrollado la tcnica de minera de datos, t ambi n denomi nada desc:.: --I
miento de conocimiento en bases de datos (DCBD), que recorre bases de datos existe r - e i
con el fin de extraer informacin apropiada en el mbi t o de los negocios. Sin embarp: I
la existencia de mltiples bases de datos, sus diferentes estructuras, el grado de d e ^ - |
lie que contienen y muchos otros factores hacen que la minera de dat os resulte dr ; . [ j
dentro de un ent orno existente de base de datos. Una solucin alterna, denomi nada .. -
macen de datos agrega una capa adicional a la arquitectura de datos.
Un al macn de dat os es un ent or no de dat os i ndependi ent e que no est dir: J -
ment e i nt egrado en las apl i caci ones cotidianas, per o que abarca t odos los dat os x - |
lizados en un negoci o [MAT96]. En cierto sentido, un al macn de dat os es una b ^ |
de dat os grande e i ndependi ent e que tiene acceso a los dat os al macenados en
bases de dat os que sirven al conj unt o de aplicaciones requeri das en un negocio.
Convi ene ms dej ar el anlisis detallado del di seo de est ruct uras de dat os, bas es !
de dat os y al macenes de dat os a los libros dedi cados a est os t emas (por ejemp : . l
[DATOOO], [PRE98], [KIM98]). El lector i nt eresado debe leer la secci n Otras / e e f u r J
y fuentes de informacin de est e cap t ul o como referenci a adicional.
TM
PDF Editor
CAPTULO 10 DISEO ARQ UITECTNICO 279
Minera y almacenamiento
de datos
Objeti vo: Los herramientas de la minera de
ayudan en la identificacin de relaciones entre
que describen un objeto de datos especfico o un
de objetos de datos. Las herramientas para el
-miento de datos ayudan en el diseo de modelos
un almacn de datos.
ica: Estas herramientas tienen diversas mecnicas.
-| , las herramientas de minera aceptan conjuntos
de datos como entrada y permiten que el usuario
ulte para tratar de comprender mejor las
s entre diversos elementos de datos. Las
entas de almacenamiento empleadas en el diseo
ionan vnculos con la entidad u otras opciones de
i ent as repres ent at i vas '
1 de datos:
Objects, desarrollada por Business Objects, SA
-ww.businessobjects.com), es un conjunto de
-erramientas de diseo de datos que apoya "la
integracin, la consulta, el informe, el anlisis y el
anlisis de datos".
SPSS, desarrollado por SPSS, Inc. (www.spss.com),
proporciona una amplia variedad de funciones
estadsticas que permiten el anlisis de conjuntos grandes
de datos.
Almacenamiento de datos:
Industry Warehouse Studio, desarrollada por Sybase
(www.sybase.com), proporciona uno infraestructura de
almacn de datos empaquetado que "sirve como
trampoln" para iniciar el diseo de un almacn de datos.
IFW Business Intelligence Suite, desarrollada por
Modelware (www.modelwarepl.com), es un conjunto de
modelos, herramientas de software y diseos de base
de datos que "proporcionan un camino rpido al
almacn de datos y al diseo y la implementacin de
centros de acopio de datos".
Una lista extensa de herramientas y recursos de minera y
almacenamiento de datos se encontrar en el Data
Warehousing Information Center (www.dwinfocenter.org).
Ca l e s
p r r a p i o s
q r f c a b l e s al
de d a t o s ?
10.2.2 Diseo de datos al nivel de componentes
El diseo de dat os al nivel de component es se concentra en la representacin de es-
tructuras de datos a las que se tiene acceso en forma directa mediante uno o ms
component es de software. Wasserman [WAS80] ha propuesto un conjunto de princi-
pios que se emplea para especificar y disear est as estructuras de datos. En realidad,
el diseo de dat os empieza durante la creacin del modelo de anlisis. Si se recuerda
que el anlisis y el diseo de requisitos suelen superponerse, se considerar el siguien-
te conjunto de principios (adaptado de [WAS80]) para la especificacin de datos:
1. Los principios del anlisis sistemtico aplicados a la Juncin y el comportamiento
tambin deben aplicarse a los datos. Tambin es necesari o desarrollar y revisar
las represent aci ones del flujo de datos y el contenido, identificar los obj et os
de datos, considerar organi zaci ones al t ernas de datos y evaluar el impacto de
los dat os que modelan el diseo del software.
2. Deben identificarse todas las estructuras de datos y las operaciones que se reali-
zarn. El diseo de una estructura de dat os eficiente debe t ener en cuent a las
operaci ones que se realizarn en la estructura de datos. Los atributos y opera-
ci ones encapsul ados dent ro de una clase satisfacen este principio.
1 El autor no respalda las herramientas expuestas; slo representan una muestra de esta categora.
En casi todos los casos los nombres son marcas registradas de sus respectivos desarrolladores.
TM
PDF Editor
3. Debe establecerse un mecanismo para la definicin del contenido de cada objei
de datos y usarlo para definir los datos y las operaciones que se les aplican. Los
di agramas de clase (captulo 8) defi nen los el ement os de dat os (atributos)
cont eni dos dent ro de una clase y el pr ocesami ent o (operaciones) que se api
ca a esos el ement os de dat os.
4. Las decisiones del diseo al nivel de datos deben posponerse hasta una de las i
timas etapas del proceso de diseo. Un proceso de refinacin paso a paso es
aplicable al di seo de datos. Es decir, la organi zaci n general de los dat os
puede definirse durant e el anlisis de los requisitos, refinarse durant e el tra
baj o de di seo de dat os y especificarse de maner a det al l ada dur ant e el diser
al nivel de component es.
5. La representacin de una estructura de datos slo debe conocerse para los m.<-
los que deben usar directamente los datos que contiene tal estructura. El concer
t o de ocultacin de la i nformaci n y el concept o rel aci onado del acopl ami er : :
(captulo 9) proporci onan conoci mi ent os i mport ant es sobre la calidad de ur.
di seo de soft ware.
6. Debe desarrollarse una biblioteca de estructuras de datos tiles y tambin las
operaciones que pueden aplicrseles. Esto se logra con una biblioteca de clase:
7. Un diseo de software y un lenguaje de programacin deben dar soporte a la es-
pecificacin y la realizacin de los tipos de datos abstractos. La i mpl ement aci "
de una sofisticada est ruct ura de dat os llega a volverse excesi vament e difcil s
no existen medi os para la especificacin directa de la est ruct ura en el lengLi
je de programaci n elegido para la i mpl ement aci n.
Estos principios f or man una base par a un enfoque de di seo de dat os, al nive!
component es, que se integre a las actividades de anlisis y diseo.
1 0 . 3 ESTI LOS Y PATRONES ARQ UI TECTNI COS
Cuando un const ruct or est adouni dense usa la frase "colonial con una sala al cent r:
(centre hall colonial) para describir una casa, la mayora de qui enes est n famili-
zados con las casas en Est ados Unidos evocar una i magen general del aspect o a:
la casa y de su pl ano general . El const ruct or ha usado un estilo arquitectnico core
mecani smo descriptivo para diferenciar la casa de ot ros estilos (por ejemplo, mar:
en A, r ancho elevado, Cape Cod). Pero al go ms i mport ant e es que el estilo arquite.
t ni co t ambi n es una plantilla par a la const rucci n. Resulta necesari o proporcior^r
mayores detalles de la casa. Se deben especificar s us di mensi ones finales, agrega-
caractersticas personal i zadas, det ermi nar los mat eri al es de const rucci n, pero t
estilo ("colonial con sala al centro") es el que gua el t rabaj o del constructor.
"En el f ondo d e lo me nt e de todo artista hay un pat rn o tipo de arqui t ect ura. *
G. K. Ch e s t e r t o r
TM
PDF Editor
El software que se construye para sistemas de cmput o tambin muestra uno o
muchos estilos arquitectnicos. Cada estilo describe una categora de sistemas que
abarca 1) un conjunto de component es (por ejemplo, una base de datos, mdul os
computacionales) que realizan una funcin requerida por el sistema; 2) un conj unt o
de conect ares que permiten la "comunicacin, coordinacin y cooperacin" entre los
component es; 3) restricciones que definen cmo se integran los component es para
formar el sistema, y 4) modelos semnticos que permiten a un diseador, mediante
el anlisis de las propiedades conocidas de las partes que lo integran (BAS03), com-
prender las propiedades generales de un sistema.
Un estilo arquitectnico es una transformacin impuesta al diseo de todo un sis-
tema. El objetivo es establecer una estructura para todos los component es del siste-
ma. En caso de que una arquitectura existente se vaya a somet er a reingenieria (ca-
ptulo 31), la imposicin de un estilo arquitectnico desembocar en cambi os funda-
mentales en la estructura del software, incluida una reasignacin de la funcionalidad
de los component es [BOSOO].
Un patrn arquitectnico, al igual que un estilo, impone una transformacin en el
diseo de una arquitectura. Sin embargo, un patrn difiere de un estilo en varios ele-
ment os fundamentales: 1) el alcance de un patrn es menor, ya que se concentra en
un aspecto en lugar de hacerlo en toda la arquitectura; 2) un patrn impone una re-
gla sobre la arquitectura, pues describe la manera en que el software manej ar al-
gn aspecto de su funcionalidad al nivel de la infraestructura (por ejemplo, concu-
rrencia) [BOSOO]; 3) los patrones arquitectnicos tienden a abarcar aspect os espec-
ficos del comportamiento dentro del contexto de la arquitectura (por ejemplo, cmo
manej a una aplicacin en tiempo real la sincronizacin o las interrupciones). Los pa-
trones se usan junto con un estilo arquitectnico para determinar la forma de la es-
tructura general de un sistema. En la siguiente seccin se expondrn estilos y patro-
nes arquitectnicos de uso comn en el software.
10.3.1 Una breve taxonoma de estilos arquitectnicos
Aunque se han creado millones de sistemas de cmput o en los ltimos 50 aos, la
gran mayora puede clasificarse (consltense ISHA96], [BUS96], [BAS03]) en un n-
mero relativamente pequeo de estilos arquitectnicos:
Arquitectura centrada en dat os. Un almacn de dat os (por ejemplo, un archivo o
una base de datos) se encuentra en el centro de esta arquitectura; otros componen-
tes tienen acceso a l y cuentan con la opcin de actualizar, agregar, eliminar o, por
otra parte, modificar los dat os de ese almacn. En la figura 10.1 se ilustra un estilo
tpico centrado en datos. El soft ware cliente tiene acceso a un almacn central. En
algunos casos st e es pasivo. Es decir, el soft ware cliente accede a los dat os inde-
pendi ent ement e de cualquier cambi o hecho a los datos o a las acciones de otro soft-
ware cliente. Una variacin de este enfoque transforma el depsito en un "pizarrn"
que enva notificaciones al soft ware cliente cuando cambian los datos de inters pa-
ra el cliente.
TM
PDF Editor
Arquitectura
cent rada en
datos.
Una arqui t ect ura cent rada en dat os pr omueve la capacidad de integracin [BAS::
Esto significa que es posible cambi ar component es exi st ent es y agregar nuevos <
ponent es cliente a la arquitectura sin preocuparse por otros clientes (ya que los i
ponent es cliente operan en forma independiente). Adems, es posible pasar datos e - - |
tre cl i ent es empl eando el mecani smo del pi zarrn (es decir, el component e pi zar : - i |
sirve para coordinar la t ransferenci a de i nformaci n ent re clientes). Los compor es I
tes cliente ej ecut an los procesos de maner a i ndependi ent e.
Arqui tectura de flujo de dat os . Esta arquitectura se aplica cuando los datos &
ent rada se habrn de transformar en datos de salida medi ant e una serie de compor es-
tes para el clculo o la manipulacin. Una estructura de tuberas y filtros (figura 1: 2
tiene un conj unt o de component es, denomi nados filtros, conect ados por tuberas ojc
t ransmi t en dat os de un component e al siguiente. Cada filtro funci ona sin t oma: t
C F F B I T W
Arquitectura
de flujo de
datos.
Tuberas
Tuberas y filtros
TM
PDF Editor
cuent a si los component es tienen flujo ascendent e o descendent e; est di seado pa-
ra esperar la ent rada de dat os con cierta forma y produci r su salida (al siguiente fil-
tro) de una forma especifica. Sin embargo, no es necesari o que el filtro conozca el
funci onami ent o de los filtros vecinos.
"En los disciplinas de lo ingeniera se usan ampl i ament e pot rones y estilos de diseo. "
Ma r y S h o w y Davi d Ga r l a n
Si el flujo de dat os degener a en una sola lnea de t ransformaci ones se denomi na
procesamiento por lotes secuencial. Esta est ruct ura acept a un pr ocesami ent o por lo-
tes de dat os y luego aplica una serie de component es secuenci al es (filtros) para
t ransformarl os.
Arqui tectura de l l amada y ret orno. Este estilo arqui t ect ni co permite que un di-
seador de soft ware (arquitecto del sistema) obt enga una est ruct ura de pr ogr ama
que resulta rel at i vament e fcil modificar y cambi ar de t amao. En est a cat egor a hay
dos subest i l os [BAS03]:
Arquitectura de programa principa/subprograma. Esta est ruct ura de pr ogr ama
clsica separa la funcin en una jerarqua de control donde un pr ogr ama
"principal" invoca a varios component es de programa, que a su vez pueden
invocar a ot ros component es. En la figura 10.3 se ilustra una arquitectura de
est e tipo.
Arquitectura de llamada de procedimiento remoto. Los component es de una ar-
quitectura de pr ogr ama pri nci pa / subprograma se distribuyen ent re vari as
comput ador as de una red.
TM
PDF Editor
C B E X F
Arquitectura
estratificada.
Arqui tectura ori ent ada a obj et os. Los component es de un si st ema encapsu 3-
los dat os y las oper aci ones que deben aplicarse para mani pul ar los dat os. La c o r
nicacin y coordinacin entre component es se consigue mediante el paso de mensa
Arqui tectura est rat i f i cada. En la figura 10.4 se lustra la est ruct ura bsica de
arqui t ect ura estratificada. Hay varias capas definidas; cada una de ellas realiza cor
raci ones que se acer can progresi vament e al conj unt o de i nst rucci ones de la m oj B
na. En la capa ext erna los component es sirven a las operaci ones de interfaz de US
rio. En la capa i nt erna los component es sirven como interfaz con el si st ema opert
tivo. Las capas i nt ermedi as proporci onan servicios de utilera y de sof t war e de ar -
caci ones.
Estos estilos arqui t ect ni cos sl o son un pequeo subconj unt o de los que disr >d
ne el di seador de soft ware. 2 Una vez que la ingeniera de requisitos defi ne las z r
ractersticas y restricciones del si st ema que habr de construirse, podrn elegrs; d
estilo arqui t ect ni co o la combi naci n de estilos que mej or combi nen con las carar-
tersticas y restricciones. En muchos casos ser apropi ado m s de un estilo y podr a
di searse y eval uarse distintas opciones. Por ejemplo, en muchas aplicaciones 2t
base de dat os se combi na un estilo por capas (apropiado par a casi t odos los s i s u l
mas) con una arqui t ect ura cent rada en datos.
10.3.2 Patrones arquitectnicos
Si el const ruct or deci de construir una casa colonial con sala al cent ro sl o p a a l
aplicar un estilo arquitectnico. Los det al l es del estilo (por ejemplo, nmer o de o f l
2 Consltese [BOSOO], [HOFOO], IBAS03], [SHA97], [BUS96] y [SHA96] para contar con un anliso j
(aliado de los estilos y patrones arquitectnicos.
TM
PDF Editor
2 8 5
-OGARSEGURO
Eleccin de un estilo arquitectnico
El es cenari o: Cubculo de Jamie,
J p s contina el modelado del diseo.
actores: Jamie y Ed, integrantes del equipo de
ieria del software HogarSeguro.
versaci n:
frunci endo el ceo): Hemos estado modelando la
1 con UML... ya sabes, clases, relaciones y ese tipo
As que supongo que lo adecuado ser aplicar la
i orientada a objetos.3
_. p_j Pero...
*k Pero... tengo problemas para visualizar lo que es la
* c t u r a orientada a objetos. Conozco la arquitectu-
Bamada y retorno, una tipo de jerarqua de proce-
r.cional, pero orientada a objetos... no s, me
amorfo.
( sonri endo) : Amorfo, eh?
lo que quiero decir es que no logro visualizar
. slo el diseo de clases flotando en
el espacio.
Jami e: Bueno, eso no es cierto. Hay jerarquas de
clase... piensa en la jerarqua (agregacin) que hicimos
para el objeto Pl anoCas a [figura 9.3]. Una arquitectu-
ra orientada a objetos es una combinacin de esa
estructura y las interconexiones (ya sabes, colaboracio-
nes) entre las clases. La mostraremos al describir por
completo los atributos y las operaciones, los mensajes
que se intercambian y la estructura de las clases.
Ed: Voy a dedicar una hora a correlacionar una arqui-
tectura de llamada y retorno, luego regresar aqu y
pensar en la arquitectura orientada a objetos.
Jami e: Doug no tendr problema con eso. l dijo que
debemos considerar arquitecturas alternas Por cierto, no
hay ninguna razn para no combinar ambas arquitectu-
ras.
Ed: Bueno, en eso estoy.
meneas, fachada de la casa, colocacin de puert as y ventanas) variarn considera-
blemente, pero una vez que se ha t omado la decisin de la arquitectura general de
la casa, el estilo se impondr al diseo.4
Los pat rones arquitectnicos difieren un poco.5 Por ejemplo, cada casa (y todo es-
tilo arquitectnico para casas) empl ea un patrn cocina, el cual define la necesidad
de colocar los artculos bsi cos de cocina, un fregadero, al acenas y, posiblemente,
3 Podra argumentarse que la arquitectura de HogarSeguro debe considerarse en un nivel ms elevado
que la arquitectura indicada. HogarSeguro tiene diversos subsistemas (funcionalidad de monitoreo
de la casa, el sitio de monitoreo de la compaa y el subsistema que se ejecuta en la PC del propie-
tario). Dentro de los subsistemas prevalecen los procesos concurrentes (por ejemplo, el monitoreo
de sensores) y el manejo de eventos. A este nivel, algunas decisiones arquitectnicas se toman du-
rante la ingeniera del sistema y el producto (captulo 6), pero el diseo arquitectnico dentro de la
ingeniera del software muy bien tendra que considerar estos aspectos.
4 Esto indica que tendr una sala central y un pasillo, que las habitaciones estarn colocadas a la iz-
quierda y la derecha de la sala, que la casa tendr dos (o ms) pisos, que los dormitorios estarn en
la planta alta, etc. Estas "reglas" se imponen una vez que se ha tomado la decisin de usar el estilo
colonial con sala al centro.
5 Es importante observar que no hay un acuerdo universal sobre la terminologa. Algunas personas
(por ejemplo, [BUS96]) usan los trminos estilos y patrones como sinnimos, mientras que otros ha-
cen la sutil distincin sugerida en esta seccin.
TM
PDF Editor
286
\
CLAVE
Uno arquitectura del
software tiene varios
patrones
arquitectnicos que
atienden temas como
la concurrencia, la
persistencia y lo
distribucin.
reglas para ubi car cosas rel aci onadas con el flujo de t rabaj o en la habitacin. Ade
ms, el pat rn podra especificar la necesidad de cubiertas y acabados, iluminacin,
i nt errupt ores de pared o una isla central, pisos, etc. Obvi ament e, hay ms de un di-
s eo de coci na, pero t odo di seo se concebi r dent r o del cont ext o de la "sol uci r'
que sugiere el pat rn cocina.
Como ya se indic, los pat rones arqui t ect ni cos para el sof t war e defi nen un e r
foque especfico para el manej o de al guna caracterstica de compor t ami ent o del S
t ema. Bosch [BOSOO] define vari os pat r ones arquitectnicos. En los si gui ent es p r n
fos s e pr esent an ej empl os represent at i vos.
Concurrenci a. Muchas apl i caci ones deben manej ar vari as t ar eas de maner a tal que
si mul en paral el i smo (es decir, est o ocurre cada vez que un solo procesador mane a
vari as t areas "paralelas" o component es) . Una aplicacin tiene varias maner as 2
manej ar la concurrenci a, y cada una se pr esent a medi ant e un pat rn arqui t ect ni :
diferente. Por ej empl o, un enf oque consi st e en usar un pat rn de manej o de proce
s os del si st ema operativo que ofrece caractersticas i nt egradas del si st ema opera 1
vo que permi t en la ejecucin concurrent e de los component es. El pat rn t ambi n ir
corpora funci onal i dad del si st ema operat i vo que manej a la comuni caci n entre 1 3
procesos, la cal endari zaci n y ot ras funci ones requeri das para al canzar la concu-
rrencia. Ot ro mt odo sera definir un cal endari zador de t areas al nivel de apl i cadc.
Un pat rn cal endari zador de t areas cont i ene un conj unt o de obj et os activos, y c a r a
uno de ellos incluye una operaci n t i c o [BOSOO]. El cal endari zador invoca perioc-
cament e t i cf) para cada objeto, que luego realiza las funci ones que debe realizar a* -
tes de regresar el control al cal endari zador, mi smo que invoca de nuevo la opera-
cin tice) para el siguiente obj et o concurrent e.
Persi st enci a. Los dat os persi st en si sobreviven despus de la ejecucin del p r e n -
so que los cre. Los dat os persi st ent es se al macenan en una base de dat os o un ar-
chivo; en un moment o posterior, ot ros pr ocesos t i enen la opcin de leerlos o mo a -
ficarlos. En los ent or nos ori ent ados a obj et os la idea de un obj et o persi st ent e extien-
de un poco ms el concept o de persistencia. Los valores de t odos los atributos del
objeto, el est ado general de st e y otra i nformaci n compl ement ari a s e al macer ^nj
para su aplicacin y recuperaci n posterior. En general, se empl ean dos pat rones ar
qui t ect ni cos par a lograr la persistencia: 1) un pat rn de sistema de administraos
de base de datos que aplica las capaci dades de al macenami ent o y recuperaci n de _~
si st ema de admi ni st raci n de base de dat os a la arquitectura de la aplicacin, : 2
un pat rn de persistencia al nivel de la aplicacin que const ruye caractersticas de pe-
sistencia en la arqui t ect ura de st a (por ej empl o, el sof t war e de procesami ent o j e
pal abras que manej a su propia est ruct ura de document o).
Di stri buci n. El probl ema de la distribucin dirige la maner a en que se comn: zar
ent re s los si st emas, o los component es de st os, en un ent or no distribuido Es-
probl ema incluye dos el ement os: 1) la maner a en que las ent i dades se conect an ca-
tre s, y 2) la nat ural eza de la comuni caci n. El pat rn arqui t ect ni co m s comr
TM
PDF Editor
287
tablecido para dirigir el problema de la distribucin es el de corredor. Un corredor ac-
ta como "intermediario" entre el component e cliente y un component e servidor. El
cliente enva un mensaj e al corredor (que contiene toda la informacin apropiada
para que se realice la comunicacin), el cual completa la conexin. CORBA (captu-
lo 30) es un ejemplo de una arquitectura de corredor.
Antes de elegir cualquiera de los pat rones arquitectnicos indicados en los prra-
fos anteriores, debe evaluarse si es apropiado para la aplicacin y el estilo arquitec-
tnico general, adems de evaluar su facilidad de mantenimiento, confiabilidad, se-
guridad y desempeo.
10.3.3 Organizacin y reinamiento
Debido a que el proceso de diseo suele dejar a un ingeniero de soft ware con varias
opciones arquitectnicas, es importante establecer un conj unt o de criterios de dise-
o para evaluar un diseo arquitectnico. Las siguientes preguntas [BAS03] propor-
cionan una visin especfica del estilo arquitectnico que se ha derivado.
Control. Cmo se manej a el control dentro de la arquitectura? Existe una jerar-
qua de control distintiva y, si es as, cul es la funcin de los component es dentro
de esta jerarqua de control? Cmo transfieren los campos el control dentro del sis-
t ema? Cmo se compart e el control entre los component es? Cul es la topologa
del control (es decir, cul es la forma geomtrica que asume el control)? Est sin-
cronizado el control o los component es operan asincrnicamente?
Dat os . Cmo se comunican los dat os ent re los component es? El flujo de dat os
es continuo o los objetos de datos se pasan espordi cament e al sistema? Cul es el
modo de transferencia de los datos (por ejemplo, los dat os se pasan de un compo-
nent e a otro o estn disponibles globalmente para compartirse entre los componen-
tes del sistema)? Existen component es de datos (por ejemplo, un pizarrn o al ma-
cn) y, de ser as, cul es su papel? Cmo interactan los component es funcionales
con los de datos? Los component es de dat os son pasivos o activos (es decir, inte-
ractan activamente con otros component es del sistema)? Cmo interactan los
dat os y el control dentro del sistema?
Estas pregunt as proporcionan al diseador una evaluacin temprana de la calidad
del diseo y sientan las bases para un anlisis ms detallado de la arquitectura.
Cuando empieza el diseo arquitectnico debe ponerse en contexto el software que
se habr de desarrollar; es decir, el diseo debe definir las entidades externas (otros
sistemas, otros dispositivos, otras personas) con las que interacta el software y tam-
bin la naturaleza de la interaccin. Esta informacin suele adquirirse del modelo de
anlisis y toda la dems informacin reunida durante la ingeniera de requisitos. Una
vez que se ha modelado el contexto y que se han descrito todas las interfaces exter-
TM
PDF Editor
as del soft ware, el diseador especifica la estructura del sistema al definir y refina-*
los component es del soft ware que i mpl ement an la arquitectura. Este proceso prosu
de manera iterativa hast a que se obtiene una estructura arquitectnica completa
"l)n doctor entierro sus errores, pero un arquitecto slo puede aconsejar o su cliente que plante vides.'
Frank Lbyd Wrigh-
.
10.4.1 Representacin del sistema en el contexto
En el captulo 6 se indica que un ingeniero del si st ema debe model ar el cont ext o
\
CLAVE
El contexto
arquitectnico
representa la manera
en que el software
interacta con los
entidades externas a
sus lmites.
Cmo i nt er-
actan los
si st emas ent r e s ?
di agrama de cont ext o del si st ema (figura 6.4) cumpl e con est e requisito al repn
tar el flujo de la i nformaci n dent r o y fuera del sistema, la i nformaci n del usuar
el pr ocesami ent o rel evant e de soport e. Al nivel de di seo arquitectnico, un arqu
tecto del sof t war e aplica un di seo de cont ext o arqui t ect ni co (DCA) para moce r r
la maner a en que el soft ware i nt eract uar con las ent i dades ubi cadas ms all de
lmites. La est ruct ura genrica de los di agr amas de cont ext o arquitectnico se
tran en la figura 10.5.
Si se t oma como referencia la figura, los si st emas que i nt eract an con el
de destino (el si st ema para el que se est desarrol l ando un di seo arqui t ect ni co'
represent an as:
Sistemas superordinados: los que empl ean el si st ema de dest i no como parte ;
algn esquema de pr ocesami ent o de nivel ms elevado.
Sistemas subordinados: los que utiliza el si st ema de dest i no y que proporcio-
nan los dat os o el pr ocesami ent o necesari os para compl et ar la funci onal i ds;
del si st ema de destino.
Di agi ama de
contexto
arquitectnico
(adapt ado de
[BOSOO]).
Sistemas superordinados
1 1 1
Usados
Sistemas subordinados
TM
PDF Editor
Sistemas al nivel de par: los que interactan de igual a igual (es decir, la infor-
macin la producen o consumen los pares y el sistema de destino).
Actores: las entidades (personas, dispositivos) que interactan con el sistema
de destino produciendo o consumi endo informacin necesaria para el proce-
sami ent o de requisitos.
Cada una de est as entidades externas se comunica con el sistema de destino me-
diante una interfaz (los pequeos rectngulos sombreados).
Para ilustrar la utilizacin del DCA considrese de nuevo la funcin de seguridad
casera del producto HogarSeguro. El controlador general y el sistema de Internet del
producto HogarSeguro son superdordinados a la funcin de seguridad y se muestran
arriba de la funcin en la figura 10.6. La funcin de vigilancia es un sistema par y em-
plea (es empl eado por) la funcin de seguridad en versiones posteriores del produc-
to. Los pnel es de propietario y control son actores que actan como productores y
consumi dores de la informacin utilizada, producida (o de ambos tipos) por el soft-
ware de seguridad. Por ltimo, el soft ware de seguridad emplea los sensores, que se
muestran como subordinados de ste.
Como parte del diseo arquitectnico tendran que especificarse los detalles de
cada interfaz mostrada en la figura 10.6. En esta etapa deben identificarse todos los
dat os que fluyen al interior o el exterior del sistema de destino.
10.4.2 Definicin de arquetipos
Un arquetipo es una clase o un patrn que representa una abstraccin central impor-
tantsima en el diseo de una arquitectura para el sistema de destino. En general, se
requiere un conj unt o relativamente pequeo de arquetipos para disear incluso sis-
t emas relativamente complejos. La arquitectura del sistema de destino la integran
Producto
HogarSeguro
Sistema basado 1
en Interne! 1
Funcin de 1
vigilancia 1
Usa
Pares
TM
PDF Editor
Relaciones
UML par a los
arquetipos de
la funcin de
seguridad de
HogarSeguro
(adapt ado de
[BOSOO]).
arquet i pos, que represent an el ement os est abl es de la arqui t ect ura pero que puede-
dar paso a i nst anci as de muchas maner as diferentes, con base en el comport arme-
to del si st ema.
En muchos casos, los arquet i pos se derivan al exami nar las cl ases de anlisis ct
finidas como part e del model o de anlisis. Si se cont i na el anl i si s de la funcin ir
seguri dad casera de HogarSeguro se definiran los si gui ent es arquetipos:
Nodo. Represent a una coleccin cohesi va de el ement os de ent rada y salida
en la funcin de seguri dad casera. Por ej empl o, un nodo est ar a integrado pe -
1) vari os sensor es y 2) varios i ndi cadores de al arma (salida).
Det ect or. Una abst racci n que abarca t odo el equi po de sensor es que ali-
ment a i nformaci n en el si st ema de destino.
Indi cador. Una abst racci n que represent a t odos los mecani smos (por ej e~
po, sirena de al arma, luces par padeant es, timbre) para indicar que est ocu-
rri endo una condicin de al arma.
Control ador. Una abstraccin que descri be el mecani smo que permite el ar
mado o desar mado de un nodo. Si los cont rol adores resi den en una red tiener
la capacidad de comuni car se ent re s.
Cada uno de est os arquet i pos se descri be con la not aci n UML, como se muest ra a
la figura 10.7.
Recurdese que los arquet i pos f or man la base de la arquitectura pero son abs t nc
ci ones que deben refinarse an m s a medi da que avanza el di seo arquitectr : :
Por ejemplo, Det ect or podra refi narse en una jerarqua de clase de sensores.
10.4.3 Refinamiento de la arquitectura en componentes
A medi da que se refina la arqui t ect ura del sof t war e en component es, la estrucr-ra-
del si st ema empi eza a emerger. Pero cmo se eligen est os component es? Para
Cont rol ador
1
Se comuni ca con
Nodo
3 1
Detector Indicador
TM
PDF Editor
291
*
te de
idel
i derivan
s: los
de la aplico-
i rrnxslrudvra
Debido o
)de
; cliende lo
i el tiempo
i liante el
a pensar en
j cuidado.
ponder, el di seador de la arqui t ect ura empi eza con las cl ases descritas como part e
del model o de anlisis. 6 Estas cl ases de anl i si s represent an ent i dades dent r o del do-
minio de la aplicacin (negocio) que deben at ender se dent r o de la arqui t ect ura del
soft ware. Por t ant o, el domi ni o de la aplicacin es una f uent e para la derivacin y el
refi nami ent o de los component es. Otra f uent e es el domi ni o de la infraestructura. La
arquitectura debe adecuar se a muchos component es de i nfraest ruct ura que habili-
tan los component es de la aplicacin, per o que no tienen conexi n de negoci os con
el domi ni o de la aplicacin. Por ejemplo, los component es de admi ni st raci n de me-
moria, de comuni caci n, de base de dat os y de admi ni st raci n de t areas suel en in-
t egrarse en la arqui t ect ura del soft ware.
La i nt erfaz descrita en el di agrama de cont ext o de la arquitectura (seccin 10.4.1)
indica que uno o m s component es especi al i zados procesan los dat os que fluyen por
la interfaz. En al gunos casos (por ejemplo, una i nt erfaz grfica de usuario) debe di-
sear se una arqui t ect ura compl et a de subsi st emas con muchos component es.
"Lo est r uct ur a de un s i s t ema de s of t war e pr opor ci ona la ecol og a en q u e nace, ma d u r a y mue r e el cdi go. Un habi t at
bi e n di s eado per mi t e el xi t o en la evol uci n de t odos los component es necesar i os d e un si st ema de s of t wa r e : '
R. P a t t i s
Cont i nuando con la funcin de seguridad casera de HogarSeguro, se definir el
conj unt o de component es de nivel superi or que at i enden la si gui ent e funcionalidad:
Administracin de comunicacin externa: coordi na la comuni caci n de la fun-
cin de seguridad con ent i dades ext ernas; por ejemplo, si st emas de Internet,
notificacin ext erna de al arma.
Procesamiento del panel de control: manej a t oda la funcionalidad del panel de
control.
Manejo del detector, coordi na el acceso a t odos los det ect ores conect ados al
si st ema.
Procesamiento de alarma: verifica t odas las condi ci ones de al arma y act a so-
bre ellas.
Cada uno de est os component es de nivel superior tendra que el aborarse iterativa-
ment e y luego posi ci onarse dent r o de la arqui t ect ura general de HogarSeguro. Para
cada uno se definiran cl ases de di seo (con los atributos y las operaci ones apropi a-
das). Sin embargo, es i mport ant e observar que los det al l es de di seo de t odos los
at ri but os y las oper aci ones sl o s e especificaran hast a la realizacin del di seo en
el nivel de component es (captulo 11).
En la figura 10.8 se ilustra la estructura arquitectnica general (representada como
un di agrama de component es UML). El component e Manejo de comunicacin externa
6 Si se elige un enfoque convencional (no orientado a objetos. es posible derivar los componentes del
modelo de tlujo de datos. En la seccin 10.6 se analizara este enfoque
TM
PDF Editor
Estructura general de la arquitectura de HogarSeguro con componentes de nivel
Seleccin
~ de funcin
Procesamiento
de panel
de control
Manejo de
detector
1 Procesamiento
de alarma
adquiere las t ransacci ones provenientes de los component es que procesan la inL-^z
grfica de usuario de HogarSeguro y la interfaz de Internet. El component e director dt - -
garSeguro manej a esta informacin y selecciona la funcin de product o apropiada rs
este caso, seguridad). El component e procesamiento de panel de control interacta
el propietario para armar o desarmar la funcin de seguridad. El component e marr.-M
de detector agrupa los sensores para detectar una condicin de al arma, y el compor s-
te procesamiento de alarma produce una salida cuando se detecta la alarma.
10.4.4 Descripcin de la creacin de instancias del sistema
El di seo arqui t ect ni co que se ha model ado hast a est e punt o a t odav a es de ur n
vel rel at i vament e alto. Se ha r epr esent ado el cont ext o del si st ema; se han def
los arquet i pos que indican las abst racci ones i mport ant es dent ro del domi ni o del ]
blema; es evi dent e la est ruct ura general del si st ema; y se han identificado los |
cipales component es del soft ware. Sin embargo, an se necesi t a mayor refinar
to (recurdese que t odo el di seo es iterativo).
Esto se logra desarrol l ando una instancia de la arquitectura. Es decir, la arqur. r:
t ura se aplica a un probl ema especfico con el propsi t o de demost r ar que la es t
tura y los component es son apropi ados.
En la figura 10.9 se ilustra una instancia de la arquitectura HogarSeguro para el i
t ema de seguri dad. Los component es que muest ra la figura 10.8 se retinan an
para mostrar detalles adicionales. Por ejemplo, el component e manejo de detector ir
racta con el component e de infraestructura calendarizador que implementa el as
mi ent o "concurrente" de cada objeto sensor del sistema de seguridad. Una elaborac
similar se realiza para cada uno de los component es represent ados en la figura IO S
TM
PDF Editor
CAPITULO 10 DISEO ARQ UITECTNICO
293
Instancia de la funcin de seguridad con elaboracin de componentes.
Director
HogarSeguro
Manej o de
comunicacin
externa
Procesamiento
de panel
de control
*
Manejo de
detector
Protocolo de
| teclado numrico
Funciones de
] despliegue CP
de alarma
y v
^ Calendarizador I S Comunicacin I \
1 telefnica I
Sensor
j
Alarma
Diseo arquitectnico
Obj et i vo: Las herramientas de diseo
arquitectnico modelan la estructura general del
i al representar interfases, dependencias,
es e interacciones de los componentes.
cani ca: Las herramientas cuentan con mecnicas
as. En casi todos los casos, la capacidad del diseo
nico es parte de la funcionalidad de las
nientas automatizadas para modelado de anlisis y
Herrami ent as repres ent at i vas 7
n, desarrollada por Synthis Corp.
(www.synthis.com), es una herramienta especializada
para el diseo y la construccin de arquitectura
especficas de componentes Web.
ObjectiF, desarrollada por microTOOL GmbH
(www.microtool.coml, es una herramienta de diseo
UML que lleva a arquitecturas (por ejemplo, Coldfusion,
J2EE, Fusebox) sensibles a la ingeniera de software
basada en componentes (captulo 30).
Rational Rose, desarrollada por Rational
(www.rational.com), es una herramienta de diseo
basada en UML que soporta todos los aspectos del
diseo arquitectnico.
7
Las herramientas expuestas slo representan una muestra de esta categora. En casi todos los ca-
sos los nombres son marcas registradas por sus respectivos desarrolladores.
TM
PDF Editor
1 0 . 5 EVALUACI N DE DI SEOS AP AMT E C T NI C OS ALTEEMOS
En el mej or de los casos, el di seo produce varias opci ones arqui t ect ni cas que
evalan para det ermi nar cul es la ms apropi ada respect o al probl ema que habn
de resolverse. En las siguientes secci ones se anal i zaran di seos arquitectnicos a.
t emos.
"Tal ve z s e o e n el s t a n o . D j a me ir escol er as ar r i ba y r evi s ar . '
M. C. Escher
10.5.1 Un mtodo de anlisis de compensacin par a la arquitectura
El Instituto de Ingeniera del Software (SEI, por sus siglas en ingls) ha desarrollad
un mtodo de anlisis de compensacin para la arquitectura (MACA) [KAZ98] que c
fine un proceso de evaluacin iterativo para las arqui t ect uras del soft ware. Las ;
guientes actividades de anlisis del di seo se realizan iterativamente:
1. Recopilar escenarios. Se desarrolla un conj unt o de casos de uso (captulos 7
8) para represent ar el si st ema desde el punt o de vista del usuario.
2. Deducir requisitos, restricciones y descripcin de entornos. Esta informacin se
requiere como parte de la ingeniera de requisitos y se usa para asegurarse ct
que se at i endan t odas las preocupaci ones de los participantes.
3 . Describir los estilos/patrones arquitectnicos que se han elegido para dirigir los
escenarios y requisitos.
4 . Evaluar los atributos de calidad al considerar cada atributo de manera aislada.
Entre los atributos de calidad para la evaluacin del di seo arquitectnico se
incluyen confiabilidad, desempeo, seguridad, facilidad de mant eni mi ent o,
flexibilidad, facilidad de prueba, portabilidad, facilidad de reutilizacin e interc-
perabilidad.
5 . Identificar la sensibilidad de los atributos de calidad respecto de varios atributos
arquitectnicos para un estilo arquitectnico especfico. Esto se logra haci endo
pequeos cambi os en la arquitectura y det ermi nando la sensibilidad al cam-
bio de un atributo de calidad, como el desempeo. Cualquier atributo al que
afect e significativamente la variacin en la arquitectura se consi derar un
punt o de sensibilidad.
6. Analizar las arquitecturas alternas (desarrolladas en el paso 3) empleando el anc
lisis de sensibilidad aplicado en el paso 5. El SEI describe este enfoque de la si-
guiente maner a [KAZ98]:
Una vez de t e r mi na dos l os punt os de sensi bi l i dad ar qui t ect ni ca s e e nc ue nt r a n l os punt os
en que se r equi er e c ompe ns a c i n con sl o i dent i fi car l os e l e me nt os ar qui t ect ni cos a los
Informon o fondo
sobre MACA se
obtendr en
www.sei.cirai.sdu/
ata/otajnethod.
html.
TM
PDF Editor
295
que son sensi bl es varios atributos. Por ejemplo, el desempeo de una arquitectura clien-
te-servidor sera muy sensi bl e al nmer o de servi dores (el desempeo aument ar , dent ro
de cierto rango, al aument ar el nmer o de servidores). . . Por tanto, el nmer o de servido-
res es un punt o de compensaci n par a esta arquitectura.
Estos seis pasos represent an la primera iteracin MACA. Con base en los resultados
de los pasos 5 y 6 ser posible eliminar al gunas opciones arquitectnicas, modificar
una o ms de las arquitecturas restantes y representarlas con ms detalle, y luego
aplicar de nueva cuenta los pasos de MACA.8
HOGARSEGURO
Evaluacin de la arquitectura
- j ' G n El es cenari o: Oficina de Doug
as contina el modelado del diseo
s : Vinod, Jame, Shak ira y Ed, integrantes
: de ingeniera del software HogarSeguro.
Doug Miller, jefe del grupo de ingeniera del
rsaci n:
S que estn derivando un par de arquitecturas
, para el producto HogarSeguro, y eso es
Supongo que mi pregunta es cmo elegiremos la
Estoy trabajando en un estilo de llamada y retorno, y
Jamie o yo vamos a derivar una arquitectura
: a objetos.
Muy bien, y cmo la elegiremos?
: Tom un curso de diseo en mis aos de
i , y recuerdo que hay varias maneras de
: Las hay, pero son un poco acadmicas. Mira,
que podemos hacer nuestra evaluacin y elegir la
> casos de uso y escenarios.
No es lo mismo?
: No cuando ests hablando de evaluacin
r-suitectnica. Ya tenemos un conjunto completo de
casos de uso. As que apliquemos cada una de las
arquitecturas y veamos cmo reacciona el sistema; es
decir, cmo funcionan los componentes y los conectares
en el contexto del caso de uso.
Ed: Es uno buena idea. Eso nos asegura que no
dejaremos nada fuera.
Vi nod: Cierto, pero tambin nos indica si el diseo
arquitectnico no es directo, si tiene que doblarse como
moo para hacer el trabajo, por decirlo as.
Jami e: No es lo mismo un escenario que un caso de
uso?
Vi nod: No, en este caso un escenario es algo diferente.
Doug: Ests hablando de un escenario de calidad o uno
de cambio, o no?
Vi nod: Si. Lo que hacemos es regresar con los
participantes y preguntarles cmo cambiar
HogarSeguro en los siguientes tres aos, por decir algo.
Ya sabes, nuevas versiones, caractersticas, ese tipo de
cosas. Construimos un conjunto de escenarios de cambio.
Tambin desarrollamos un conjunto de escenarios de
calidad que definen los atributos que nos gustara ver en
la arquitectura del software.
Jami e: Y los aplicamos a las opciones.
Vi nod: Exacto. El estilo que maneje mejor los casos de
uso y los escenarios es el que escogeremos.
8 El mtodo de anlisis de la arquitectura del software (MAAS) es una alternativa a MACA y vale la pena
que los lectores interesados en el anlisis arquitectnico lo examinen Un artculo sobre MAAS se
descarga de http://www.sei.cmu.edu/publications/artides/saam-metho-propert-sas.htm.
TM
PDF Editor
2 9 6 PAUTE DOS PRCTICA DE LA INGENIERA DEL SOFTWARE
10.5.2 Complejidad arquitectnica
Una tcnica til para evaluar la complejidad general de una arquitectura det erm: -;
da consiste en considerar las dependenci as entre component es dentro de la arc_
tectura. Estas dependenci as las orienta la informacin, el flujo de control, o ambas
dentro del sistema. Zhao [ZHA98] sugiere tres tipos de dependencias:
Dependencias compartidas que represent an rel aci ones de dependenci a ent re consumi do-
res que us an el mi smo recurso o los product ores que producen par a los mi smos consu-
midores. Por ej empl o, supnganse dos component es u y v que se refieren a los mi smo:
dat os globales. Ent onces existe una relacin de dependenci a compart i da ent re u y v .
Dependencias de finjo que represent an las rel aci ones de dependenci a ent re product ores
consumi dor es de recursos. Por ejemplo, par a dos component es u y v, si u debe comple-
t arse ant es de que el control pase a v (prerrequisito) o si u se comuni ca con v medi an! :
parmet ros, ent onces existe una relacin de dependenci a de flujo ent re u y v .
Dependencias restringidas que represent an restricciones al flujo relativo de control entre
un conj unt o de actividades. Por ej empl o, si dos component es u y u n o pueden ejecutarse
al mi smo t i empo (exclusin mutua), ent onces existe una relacin de dependenci a restrin-
gida ent re u y v .
Las dependenci as compartidas y de flujo que seala Zhao son similares al con
de acoplamiento descrito en el captulo 9. Acoplamiento es un concepto importante de
diseo que se aplica al nivel de arquitectura y de componentes. En el captulo 15
expondrn mtricas simples para evaluar el acoplamiento.
10.5.3 Lenguajes de descripcin arquitectnica
El arquitecto de una casa tiene un conjunto de herrami ent as estandarizadas y de
tacin que permite representar el diseo de una manera poco ambigua y fci.
comprender. Aunque el arquitecto del soft ware puede dibujar con notacin UML
necesitan otras formas de diagramacin, y unas cuant as herrami ent as relacin
para aplicar un enfoque ms formal a la especificacin de un diseo arquitect
El lenguaje de descripcin arquitectnica (LDA) proporciona una semntica y
sintaxis para describir una arquitectura del software. Hofmann y sus colegas [H
sugieren que un LDA debe proporcionar al diseador la capacidad de separar
ponent es arquitectnicos, de integrar component es individuales en bloques a
tectnicos mayores y de representar interfaces (mecanismos de conexin)
component es. Una vez que se hayan establecido las tcnicas descriptivas, ba
en el lenguaje para diseo arquitectnico, es ms probable que se establezcan
mt odos de evaluacin efectivos para la arquitectura a medida que el diseo evo--
ciona.
k . I
TM
PDF Editor
Lenguajes de descripcin arquitectnica
El siguiente resumen de varios LDA importantes
lo prepar Rick ard Land [LAN02] y se
i con el permiso del autor. Debe observarse que
> cinco LDA se han desarrollado con fines de
cin y no son productos comerciales,
t (poset.stanford.edu/rapide/) [LUC95] construye a
sartir de la nocin de conjuntos parciales ordenados.
i (www.cs.cmu.edu/-UniCon) [SHA96] define
arquitecturas de software desde el punto de vista de
distracciones tiles para los diseadores.
.cs.cmu.edu/~able/aesop/) [GAR94] atiende
el problema de reutilizacin del estilo.
Wrighl (www.cs.cmu.edu/~able/wright/) [ALL97]
formaliza los estilos arquitectnicos empleando
predicados, lo que permite comprobar la esttica
para determinar la consistencia y el grado en que se
ha completado una arquitectura.
Acm (www.cs.cmu.edu/~acme/)[GAROO] es un LDA de
segunda generacin.
UML (www.uml.org/) incluye muchos de los artefactos
necesarios para descripciones arquitectnicas; no es
tan completo como otros LDA.
Los estilos anal i zados en la seccin 10.3.1 represent an arqui t ect uras radi cal ment e
diferentes; por t ant o, no debe sorprender que no exista una compl et a correlacin (o
mapeo) que logre la transicin del model o de anlisis a di versos estilos arquitect-
nicos. En realidad, no hay correlacin prctica para al gunos estilos arquitectnicos.
El di seador debe abocar se a la traduccin de requisitos en di seo para est os esti-
los medi ant e las t cni cas anal i zadas en la secci n 10.4.
Ilustrar un enf oque de la correlacin arqui t ect ni ca requi ere t ener en cuent a una
tcnica de correlacin aplicada a la arqui t ect ura de llamada y retomo (una est ruct u-
ra muy comn en muchos tipos de sistemas). Esta tcnica de correlacin permi t e que
un di seador derive arqui t ect uras de l l amada y ret orno r azonabl ement e compl ej as a
partir de di agr amas de flujo de dat os dent r o del model o de anlisis. La t cni ca, a ve-
ces denomi nada diseo estructurado, se present a en libros de Myers [MYE78] y Your-
don y Constantin [YOU79].
El di seo est ruct urado suel e caract eri zarse como un mt odo de di seo ori ent ado
a flujo de dat os, ya que proporci ona una conveni ent e transicin de un di agrama de
flujo de dat os (captulo 8) a una arqui t ect ura del soft ware. El tipo de flujo de infor-
maci n es el cont rol ador para el enf oque de correlacin o mapeo.
10.6.1 Flujo de transformacin
La i nformaci n debe ent rar y salir del soft ware en una forma lgica para "la realidad
ext erna". Por ej empl o, los dat os escri t os en un teclado, los t onos de una lnea tele-
fnica y las i mgenes de video en una aplicacin multimedia son medi os de infor-
maci n de la realidad ext erna. Estos dat os ext ernos deben convertirse en una forma
i nt erna para el procesami ent o. La i nformaci n i ngresa en el si st ema por rut as que
TM
PDF Editor
2 9 8 PARTE DOS PRCTICA DE LA INGENIERA DEL SOFTWARE
t ransforman los dat os ext ernos en una forma i nt erna. Estas rut as se identifican c:
mo flujo de entrada. En el ncl eo del sof t war e ocurre una transicin. Los dat os en-
t rant es se pas an por un centro de transformacin y empi ezan a moverse por rutas que
ahora los llevan "fuera" del soft ware. Al despl azami ent o de los dat os por est as rutas
se le denomi na flujo de salida. El flujo general de dat os ocurre de maner a secuenc
y sigue una o unas cuant as rut as "en linea recta".9 Cuando un segment o de un <fcs-|
gr ama de flujo de dat os muest ra est as caract er st i cas est present e el flujo de trars
formacin.
10.6.2 Flujo de transaccin
AI flujo de i nformaci n suel e caracterizarlo un sol o el ement o de dat os, l l amado t r j r - l
saccin, que di spara ot ro flujo de dat os por una de muchas rutas. Cuando un diag-i |
ma de flujo de dat os (DFD) asume la forma most rada en la figura 10.10 est preser ca
el flujo de t ransacci n.
Al flujo de t ransacci n lo caract eri zan los dat os que s e despl azan por un carrr. ;
ent rant e que convierte la i nformaci n proveni ent e del exterior en una transacc: J
sta se evala y, con base en su valor, se inicia el flujo por una de muchas ruta: d
accin. Al el ement o que concent ra y distribuye el flujo de i nformaci n, del que e~
nan muchas rut as de accin, se le denomi na centro de transaccin.
Debe observarse que, dent ro del DFD de un si st ema grande, tienen que est ar :
sent es los flujos de t ransformaci n y t ransacci n. Por ejemplo, en una t r ans acor al
ori ent ada a flujo, el flujo de i nformaci n por un cami no de accin puede tener i r 4
ractersticas del flujo de t ransformaci n. .
9 Una correlacin obvia para este tipo de flujo de informacin es la arquitectura de flujo de datos a
crita en la seccin 10.3.1. Sin embargo, hay muchos casos en que esta arquitectura tal vez no st=
mejor eleccin para un sistema complejo. Entre los ejemplos se incluyen sistemas que expenTra-
tarn cambios sustanciales con el tiempo o sistemas en los cuales el procesamiento asociadc
el flujo de datos no necesariamente resulta secuencial.
Flujo de
transaccin.
TM
PDF Editor
C A P T U L O 1 0 DISEO ARQUITECTNICO
299
10.6.3 Correl aci n de t r ansf or maci ones
La correlacin de transformaciones es un conj unt o de pasos de diseo que permite
que un DFD con caractersticas de flujo de transformacin se correlacione con un es-
tilo arquitectnico especfico. Ilustrar este enfoque requiere considerar de nuevo la
funcin de seguridad HogarSeguro.'0 Un el ement o del model o de anlisis es un con-
junto de diagramas de flujo de datos que describen el flujo de informacin dentro de
la funcin de seguridad. Con el fin de correlacionar estos diagramas en una arqui-
tectura se llevan a cabo los siguientes pasos de diseo:
Paso 1. Revisar el model o fundamental del si st ema. El modelo fundament al
del sistema o diagrama de contexto describe la funcin de seguridad como una sola
transformacin, que representa a los productores y consumidores externos de los
dat os que fluyen al interior y hacia fuera de la funcin. En la figura 10.11 se descri-
be un modelo de nivel 0; en la 10.12 se muestra un flujo de datos refinado para la
funcin de seguridad.
Pas o 2. Revisar y refinar l os di agramas de flujo de dat os para el sof t ware.
La informacin obtenida de los modelos de anlisis se refina para producir mayor
detalle. Por ejemplo, se examina el DFD de nivel 2 para supervisar sensores (figura
10.13) y se deriva un diagrama de flujo de dat os de nivel 3, como se muestra en la
figura 10.14. En el nivel 3 cada transformacin del DFD muestra una cohesin rela-
tivamente alta (captulo 9). Es decir, el proceso implcito en una transformacin rea-
liza una funcin nica y distintiva que puede implementarse como un component e
del software HogarSeguro. Por tanto, el DFD de la figura 10.14 contiene suficiente de-
talle para un "primer corte" en el diseo arquitectnico del subsistema supervisar
sensores, y se sigue adelante sin mayor refinamiento.
Comandos y datos
de usuario
Informacin de
despliegue
Tipo de
alarma
Software
HogarSeguro
Tonos de nmero
telefnico
Despliegue
de panel de
control
Alarma
Estatus de
sensores
Sensores
10 Slo se considera una parte de la funcin de seguridad de HogarSeguro que usa el panel de control.
No se tendrn en cuenta otras caractersticas expuestas al principio de este libro y en este captulo.
TM
PDF Editor
Panel
de control
Comandos
leusuario
y dat os
Datos
de configuracin
Solicitud de
configuracin
Informacin de conl con
usuario
Datos de_
nfiguracin
Act i var/
desactivar
> sistema
\ Inicio
Cont rasea \ detencin
' activacin \
desactivacin
Mensaj e ID vlido
Datos de_ /
configuracin /
icion
liegue
Informacin
de sensores
Alarme
Tipo de al arma
Sensores
Estatus
de sensores
Tonos de
nmero telef nico
DFD d e ni vel 2
q u e ref i na l a
t rans f ormaci n
moni f or e ar
sensores.
Informacin
de sensores Formar
despl i egue
Gener ar
seal d e
al ar ma
Informacin de configuracin | ID, tipo,
" ^ ^ ^ ^ " ^ " ^ " u b i c a c i n
^ \ d e sensores
configuracin / c o n t [ a
Datos
de al ar ma
Nmero
telefnico
ID, tipo
de sensores
Leer
sensores
Mar car
telfono
Tipo
de al arma
Estatus
de sensores
Tonos de nmero"
telefnico
P a s o 3 . D e t e r mi n a r s i e l D F D t i e n e c a r a c t e r s t i c a s d e f l u j o d e t r a n s i
c i n o d e t r a n s a c c i n . En g e n e r a l , s i e mp r e e s p o s i b l e r e p r e s e n t a r el f l uj o d e :
ma c i n d e n t r o d e u n s i s t e ma c o m o u n a t r a n s f o r ma c i n . Si n e mb a r g o , c u a n d o s e en-
c u e n t r a u n a c a r a c t e r s t i c a o b v i a d e t r a n s a c c i n ( f i gur a 10. 10) , s e r e c o mi e n d a
c o r r e l a c i n d e d i s e o d i f e r e n t e . En e s t e p a s o el d i s e a d o r s e l e c c i o n a l a s c a r
DFD d e ni ve l
1 pa r a l a
f unci n d e
s e gur i dad d e
HogarSeguro.
TM
PDF Editor
C A P T U L O 1 0 DISEO ARQUITECTONICO 301
con format o
Datos de configuracin
Formar '
ispliegue
Leer
sensores
ID, tipo\
ubicacinX
de sensores
Gener ar
seal de
. al ar ma ,
/ Adqui r r \
informacin'
Datos
de al arma
lablecer >
idiciones
a l a r ma i
numero
nmeros
Generar
DFD de nivel 3 para monitorear sensores con lmites de flujo.
Informacin de confi guraci n! '
ID, tipo,
ubicacin
Informacin
de sensores
Estatus
del sensores i
ID, configuracin
de sensores
,VE
se encontro-
i posdef l u-
tienlTO del
: orienta-
o s flujos se
l c estructura
j se deriva
c correlacin

b ub icacin
: de flu o
! ex plotar
altemos de
E sto toma
tiempo y
informa-
Tipo
Ide al arma
Cdi go de
condicin de
al ar ma, ID de sensores,
informacin de cal endar i o
Nmero
telefnico
conexin
con red
niccy
Tono
listo par a
nmero
telefnico
Tonos de nmero
telefnico
ticas de flujo global (de t odo el soft ware) con base en la nat ural eza preval eci ent e del
DFD. Adems, se aislan las regi ones locales del flujo de t ransformaci n o t ransac-
cin. Estos sub flujos se aprovechan para refinar la arquitectura del programa deriva-
do de una caracterstica global descrita ant es. Por ahora, la at enci n se cent rar s-
lo en el flujo de dat os del subsi st ema monitorear sensor es descrito en la figura 10.14.
Al eval uar el DFD (figura 10.14) se apreci a que los dat os ent ran al soft ware por
una ruta de ent r ada y salen por t res rut as de salida. No participa un cent ro de t ran-
sacci n distintivo (aunque la t ransformaci n est abl ece condi ci ones de al arma que
podr an percibirse como tales). Por t ant o, se supondr una caracterstica general de
t ransformaci n para el flujo de la i nformaci n.
Pas o 4. Aisl ar el cent ro de t ransf ormaci n al es peci f i car l mi t es de flujo de
ent rada y sal i da. En la secci n anterior, el flujo de ent r ada se describi como un
cami no que convi ert e la i nformaci n con forma ext erna en i nformaci n interna; el
flujo de salida hace la conversin inversa. Los lmites de los flujos de ent r ada y sali-
da est n abi ert os a la interpretacin. Es decir, di ferent es di seadores sel ecci onarn
punt os l i gerament e di ferent es del flujo como posicin de los lmites. En realidad, las
sol uci ones al t ernas de di seo s e obt i enen al modificar la posicin de los lmites de
flujo. Aunque debe t enerse cui dado al sel ecci onar los lmites, la variacin en una
burbuj a a lo largo del cami no de flujo gener al ment e t endr poco i mpact o en la es-
tructura final del programa.
TM
PDF Editor

^ O N S U O i ^
N o se deb e odoptor
un enfoq ue dogm tico
en esto etapa. J al vez
seo necesario estab le-
cer dos o m s contro-
ladorespara
procesamiento o
c lculo de entrada,
con b ase en lo com-
plejidad del sistema
q ue h ab r de cons-
truirse. Si el sentido
com n dicta este en-
foq ue, sese/
Factorizacin
de primer
nivel para
supervisar
sensores.
Los lmites de flujo en est e ej empl o se ilustran como curvas sombr eadas que
rren vert i cal ment e por el flujo de la figura 10.14. Las t ransformaci ones (bur
que constituyen el cent ro de t ransformaci n caen dent ro de los dos lmites sombr t i -
dos que corren de arriba abaj o en la figura. Podra respal darse el ar gument o de
es posible reaj ust ar un lmite (por ejemplo, podra proponerse un lmite de flujo
ent rada que separe leer sensores y adq uirir informacin de respuesta). En este paso de r.
seo debe resaltarse la sel ecci n de lmites razonabl es, no la larga iteracin sobri
posicin de los lmites.
Pas o 5. Real i zar una "factori zaci n de pri mer nivel". La arquitectura del :~
gr ama que se ha deri vado a partir de los resul t ados de la correlacin lleva a una as-
tribucin descendent e del control. La factoriz acin gener a una est ruct ura de pror
ma en que los component es descendent es se encar gan de la t oma de decisin
los component es de baj o nivel realizan ms t rabaj o de ent rada, clculo y salida - -
component es de nivel i nt ermedi o se encar gan de part e del control y realizan
dades moder adas de trabajo.
Al encont rar el flujo de t ransformaci n se correlaciona un DFD con una e s t r uj a
ra especfica (una arqui t ect ura de l l amada y retorno) que proporci ona control para
procesami ent o de la i nformaci n de ent rada, de t ransformaci n y de salida. En U f
gura 10.15 se muest ra est a factorizacin de pri mer nivel par a el subsi st ema supt- m-
sar sensores. Un cont rol ador principal (llamado supervisar director de sensores) resi.^r
TM
PDF Editor
C A P T U L O 1 0 DISEO ARQUITECTNICO 303
en la parte superior de la estructura del programa y coordina las siguientes funcio-
nes subordi nadas de control:
Un controlador de procesamiento de informacin entrante, llamado controlador
de entrada de sensores, coordina la recepcin de todos los datos de entrada.
Un controlador de flujo de transformacin, llamado controlador de condiciones
de alarma, supervisa t odas las operaciones de los dat os en forma adecuada
para el trabajo interno (por ejemplo, un mdulo que invoca varios procedi-
mientos de transformacin de datos).
Un controlador de procesami ent o de informacin saliente, llamado controla-
dor de salida de alarma, coordina la produccin de informacin de salida.
Aunque una estructura de tres picos se desprende de la figura 10.15, flujos com-
plejos en si st emas grandes llegan a pedir dos o ms mdulos de control para cada
una de las funciones genricas de control descritas. El nmero de mdulos en el pri-
mer nivel debe limitarse al mnimo posible para realizar las funciones de control y
aun mant ener buenas caractersticas de independencia funcional.
Pas o 6. Real i ce una "factori zaci n de s egundo nivel". La factorizacin de se-
gundo nivel se logra al correlacionar las transformaciones individuales (burbujas) de
una DFD con los mdul os apropiados dentro de la arquitectura. Si se empi eza en el
lmite del centro de transformacin y se desplaza hacia fuera por rutas de entrada y
luego por rutas de salida, las transformaciones se correlacionarn en niveles subor-
dinados de la estructura del software. En la figura 10.16 se muestra el enfoque ge-
neral de la factorizacin de segundo nivel.
Aunque en la figura 10.16 se ilustra una correlacin uno a uno entre t ransforma-
ciones de DFD y mdul os de software, suelen ocurrir correlaciones diferentes. Es po-
sible combinar dos o hasta tres burbujas y representarlas como un component e, o
expandir una sola burbuja en dos o ms componentes. Consideraciones prcticas y
medidas de la calidad del di seo dictan el resultado de la factorizacin de segundo
nivel. La revisin y el refinamiento producen cambios en la estructura, pero sirven
como diseo de "primera iteracin"
La factorizacin de segundo nivel para el flujo de entrada se realiza de la misma
manera. La factorizacin se realiza nuevament e al desplazarse hacia fuera, desde el
lmite del centro de transformacin en el lado del flujo de entrada. El centro de trans-
formacin del software del subsistema monitorear sensores se correlaciona de mane-
ra un poco diferente. Cada conversin de dat os o transformacin de dat os de la par-
te de la transformacin del DFD se correlaciona con un mdulo que est subordina-
do al controlador de transformacin. En la figura 10.17 se muestra una arquitectura
de primera iteracin completa.
Los component es correlacionados de la manera anterior y most rados en la figu-
ra 10.17 representan un diseo inicial de la arquitectura del software. Aunque el
nombre de los component es indica una funcin, debe escribirse una breve explica-
TM
PDF Editor
Monitorear
director de
sensores
Cont rol ador
de salida
de al ar ma
Cont rol ador
de condi ci ones
de al ar ma
Controlador
de ent r ada
de sensores
Gener ar
seal de
al arma
Establecer
condi ci ones
de al ar ma
Configurar
conexi on cor
red telefnico
l ecci onar
nmero
telefnico
Formar
despl i egue
informacin
de respuesta
Gener ar
pulsos
3ara linea
Gener ar
despl i egue
Formar
seal de
. al arma j
conexin
con red
telefnica Supervisar
director
de sensores
Limite de f l u j o \
de transformacin
Generar
seal
de al arma
Formar
despliegue
conexion con
red telefnica
Controlador Controlador
Controlador
de ent rada de condiciones
de salida
de sensores de alarma
de alarma
Generar
despliegue
Estructura de primera iteracin para supervisar sensores.
Factorizacin
de segundo
nivel para
supervisar
sensores.
TM
PDF Editor
ilain-
<uninal
q uese
Hob je-
r m c o -
y un
bajo.
cin de su pr ocesami ent o (adapt ado de la especificacin creada durant e el model a-
do del anlisis).
Pas o 7. Refi nar l a arqui tectura de pri mera i t eraci n e mpl e ando di s eo heu-
rstico para mej orar la cal i dad del s of t ware. Siempre es posible refinar una ar-
quitectura de pri mera iteracin si se aplican concept os de i ndependenci a funci onal
(captulo 9). Los component es se expanden o cont r aen para producir una factoriza-
cin sensible, una buena cohesi n, un acopl ami ent o m ni mo y, lo que es ms i mpor-
t ant e, una est ruct ura que se i mpl ement e sin dificultades, se pruebe sin confusi n y
se mant enga sin probl emas.
Los refi nami ent os los det ermi nan los mt odos de anlisis y eval uaci n descritos
br evement e en la secci n 10.5, adems de las consi deraci ones prct i cas y el sent i do
comn. Por ejemplo, hay ocasi ones que el cont rol ador del flujo de dat os de ent r ada
resulta t ot al ment e innecesario, que se requiere algn pr ocesami ent o de ent r ada en
un component e subordi nado al cont rol ador de t ransformaci n, que no puede evitar-
se el acopl ami ent o el evado debi do a los dat os globales, o que no logran al canzarse
las caract er st i cas pt i mas de la est ruct ura. Los requisitos del soft ware, junto con el
juicio humano, deben servir par a t omar la decisin final.
El objetivo de los siete pasos pr ecedent es es desarrollar una represent aci n arqui-
tectnica del soft ware. Es decir, una vez definida la est ruct ura, es posible eval uar y
refinar la arqui t ect ura del sof t war e al t ener un panor ama general de l. Las modifi-
caci ones hechas en est e moment o requi eren poca i nformaci n adicional, per o t en-
drn un fuert e i mpact o en la calidad del soft ware.
El lector debe hacer una breve pausa y consi derar la diferencia ent re el enfoque
del di seo descrito y el proceso de "escribir programas". Si el cdi go es la nica re-
present aci n del soft ware, el desarrol l ador t endr gran dificultad para eval uar o re-
finar a voluntad, en un nivel global u holstico. En realidad, t endr dificultad para
"ver el bosque ent re los rboles".
-OGARSEGURO
Refinamiento de una arquitectura de primera iteracin
I B I El e s c e n a r i o : Cubculo de Jamie,
s se contina con el modelado del diseo,
a c t or e s : Jamie y Ed, integrantes del equipo de in-
-a del software HogarSeguro.
conversacin:
acaba de completar un diseo de primera iteracin
subsistema monitorear sensores. Se detiene para pe-
su opinin a Jamie.)
Ed: Mira, aqu est la arquitectura que he obtenido.
(Ed muestra a Jamie la figura 10.17, que ella estudia por
unos momentos.]
J a mi e : Est muy bien, pero creo que podemos hacer al-
gunas cosas para simplificarla y mejorarla.
Ed: Cmo cules?
J a mi e : Bueno, por qu usas el componente con trota-
dor de entrada de sensores?
TM
PDF Editor
Ed: Porque necesitas un sensor para b correlacin.
J a mi e : En realidad no. El controlador no hace mucho,
porque estamos manej ando un solo camino de flujo para
los datos de entrada. Podemos eliminar et controlador sin
exponernos a efectos colaterales.
Ed: Puedo vivir con eso. Har el cambio y...
J a mi e ( s onr i e nd o) : jEspera! Tambin podemos redu-
cir los componentes estab lecer condiciones de alarma y
seleccionar n mero telefnico. En realidad el controlador
de transformacin que muestras no es necesario, y la pe-
quea reduccin de la cohesin resulta tolerable.
Ed: Simplificacin, eh?
J a mi e : As es. Y mientras hacemos refinamientos, ser;;
buena idea reducir los componentes formar despliegue
generar despliegue. El formato del despliegue del pane
de control es simple. Podemos definir un nuevo mdulo
llamado producir despliegue.
Ed ( t r a z a n d o un boc e t o) : De modo que esto es le
que crees que podemos hacer?
Muestra a Jamie la figura 10.18.)
J a mi e : Es un inicio.
Estructura re-
finada del
programa
para
supervisar
sensores.
10.6.4 Correl aci n de t r ansacci ones
En muchas apl i caci ones de soft ware, un sol o el ement o de dat os di spara varios
jos de i nformaci n que afect an una funcin rel aci onada con el el ement o de
que dispara. El el ement o de dat os, l l amado transaccin, y sus correspondi ent es a
ractersticas de flujo se anal i zaron en la seccin 10.6.2. En est a secci n se consr f j
rarn los pasos de di seo empl eados para correl aci onar el flujo de t ransacci r rd
una arqui t ect ura de soft ware.
La correlacin de t ransacci ones se ilustrar si se consi dera el subsi st ema s
t eracci n con el usuari o de la funci n de seguridad de HogarSeguro. En la r J
10.12 se muest ra el flujo de dat os de nivel 1 para est e subsi st ema. Al refinar e ~nJ
se deriva un di agr ama de flujo de dat os de nivel 2, como se muest ra en la : r a
10.19. El obj et o de dat os c o ma ndo s de usuari o fluye dent ro del si st ema y gena
un flujo de i nformaci n adicional por una de t res rut as de accin. Un solo el er^Ti
Supervisar
aireclor
de sensores
Controlador
salida
de alarma
Establecer
condiciones
de alarma
informacin
de respuesta
Configurar
conexion con
red telefnica
Producir
despliegue
seal
de alarma
TM
PDF Editor
de datos, ti po de comando, hace que el flujo de dat os se expanda hacia fuera del
concentrador. Por tanto, la caracterstica general del flujo de dat os est orientada a
la transaccin.
Debe observarse que el flujo de informacin a lo largo de dos de las tres rutas de
accin acomoda el flujo de entrada adicional (por ejemplo, parmet ros y dat os del
si st ema son ent radas del cami no de accin "configurar"). Todas las rutas de accin
fluyen en una sola transformacin, desplegar mensajes y estatus.
Los pasos del diseo para la correlacin de transacciones son similares y en al-
gunos casos idnticos a los pasos para correlacin de transformaciones (seccin
10.6.3). Una diferencia importante se encuent ra en la correlacin del DFD con la es-
tructura del software.
Paso 1. Revisar el model o fundamental del si st ema.
Paso 2. Revisar y renar l os di agramas de flujo de dat os para el software.
Paso 3. Determi nar si el DFD ti ene caracter sti cas de flujo de transforma-
ci n o de transacci n.
Los pasos 1, 2 y 3 son idnticos a los correspondientes en la correlacin de trans-
formaciones. El DFD que se muestra en la figura 10.19 tiene una caracterstica de
flujo de transformacin clsico. Sin embargo, el flujo por las rutas de accin que
emanan de la burbuja invocar procesamiento de comandos parece contar con carac-
tersticas de flujo de transformacin. Por tanto, deben det ermi narse lmites de flujo
para ambos tipos.
Pas o 4. Identificar el centro de transacci n y l as caracter sti cas de flujo en
cada una de l as rutas de acci n. La ubicacin del centro de transaccin se des-
prende directamente del DFD. El centro de transaccin se encuent ra en el origen de
varias rutas de accin que fluyen de l de manera radial. En el caso del flujo mostra-
do en la figura 10.19, la burbuja invocar procesamiento de comandos es el centro de
transaccin.
El camino entrante (es decir, el camino del flujo en que se recibe la transaccin) y
todas las rutas de accin deben estar aislados. Es necesario evaluar la caracterstica de
flujo individual de cada camino de accin. Por ejemplo, el camino "contrasea" (mos-
trado dentro de un rea sombreada en la figura 10.19) tiene caractersticas de transfor-
macin. El flujo de entrada, de transformacin y de salida se indican con lmites.
Paso 5. Correl acionar el DFD con una estructura de programa sensi bl e al
proces ami ent o de la transacci n. El flujo de transaccin se correlaciona con una
arquitectura que contiene una rama entrante y una para despacho. La estructura de
la rama ent rant e se desarrolla de manera muy parecida a la correlacin de transfor-
maciones. Si se empieza en el centro de transaccin, las burbuj as ubicadas a lo lar-
go del cami no entrante se correlacionan con mdulos. La estructura de la rama para
despacho contiene un mdulo despachador que controla t odos los mdul os de ac-
TM
PDF Editor
Comandos
de usuario
Leer
comandos
de usuario
Inicio
detencin
Informacin d e confii uracion
Mensaj e
de act i vaci n/
desactivacin
Datos de
configuracin
Activar/
desactivai
sistema
Contrasea
' Datos de
configuracin
DesplegarX
mensajes I
y estatus Informador
v ^ ^ d e despliegue
Contrasea
Producir
mensaje
de que no
. es vlida .
Mensaj e
intntelo de nuevo'
Contrasea
no vlida
DFD de nivel 2 para el subsistema de interaccin con el usuario.
Datos de
configuracin
Parmetros y dat os sin trabajar
del sistema ~
Tipo de / J : T T L
comandos ( Leer \ V> ' a , c h , v o c e
^Configurar { datos del
sistema
Datos de
configuracin
con formato
cin subordi nados. Cada cami no de flujo de acci n del DFD se correl aci ona cor
est ruct ura que cor r esponde a s us caract er st i cas de flujo especficas. Este proces: j a
ilustra esquemt i cament e en la figura 10.20.
Si s e t oma en cuent a el flujo de dat os del subsi st ema de interaccin con el us . a J
rio, la factorizacin de pri mer nivel para el paso 5 se muest ra en la figura 10.21. _aH
bur buj as leer comandos del usuario y activar/ desactivar sistema se correlacionar. J-j
rect ament e con la arqui t ect ura sin necesi dad de mdul os de control i nmedi at : SI
cent ro de t ransacci n, invocar comando de procesamiento, se correlaciona di r e - r J
ment e con el mdul o despachador del mi smo nombre. Se crean consol ador es p a a
la configuracin del si st ema y el procesami ent o de la cont rasea, como se ilustra a
figura 10.21.
Pas o 6. Factori zar y ref i nar l a est ruct ura de t rans acci n y l a de cada cana-j
n o de acci n. Cada cami no de accin del DFD tiene sus propi as caractersticas M
flujo de informacin. Ya se ha observado que es posible encontrar los flujos de t rans
maci n o t ransacci n. La "subest ruct ura" rel aci onada con el cami no de acci t a
desarrolla empl eando los pasos de di seo anal i zados en esta secci n y en la i - s |
rior.
Como ej empl o, consi drese el flujo de i nformaci n de pr ocesami ent o de la : f l l
t r asea que se muest ra en la figura 10.19 (dentro del rea sombreada). El flujo r -
TM
PDF Editor
Leer
comandos
de usuario
Controlador d e |
configuracin I
de sistema
Activar/
desactivar
sistema
Controlador de
procesamiento
de contrasea
Director de
interaccin
con el usuario
Invocar
procesamiento
de comandos
tra caractersticas de transformacin clsicas. Se ingresa una cont rasea (flujo en-
trante) y se transmite a un centro de transformacin donde se compara contra las
cont raseas al macenadas. Si no se obtiene una coincidencia, se producen una alar-
ma y un mensaj e de precaucin (flujo saliente). El cami no "configurar" se dibuja de
manera similar empl eando correlacin de transformaciones. En la figura 10.22 se
muestra la arquitectura del software resultante.
Pas o 7. Refinar la arquitectura de primera i teraci n empl eando di seo heu-
rstico para mejorar la cal i dad del sof t ware. Este paso para la correlacin de
transacciones es idntico al de transformaciones. En ambos enfoques de diseo, cri-
TM
PDF Editor
310
Arquitectura
de primera
iteracin para
el subsistema
de interaccin
con el usuario.
leer
comandos
de usuario
Invocar
procesamiento
de comandos
Activar/ I Controlador
desactivar I procesamier
sistema I de contrasei
Comparar
contrasea
con archivo
Controlador
de salida
de contraser.;
Producir
mensaje de q.
no es vlicc
"Hogalo lo ms simple posible, pero no ms simple de lo necesorio. "
Al ber t Ei nst ;
10.6.5 Refi nami ent o del di seo ar qui t ect ni co
Cualquier anl i si s del refi nami ent o del di seo debe prol ogarse con el siguiente : M
ment ari o: recuerde que un "di seo pt i mo" que no funci ona tiene un mri t o cues:
nable. El di seador de sof t war e debe pr eocupar se por desarrollar una represer a
cin del sof t war e que cumpl a con t odos los requisitos funci onal es y de desempe-;
as como la acept aci n del mri t o basado en las medi das y la heurstica del dise" x j
Debe est i mul arse el refi nami ent o de la arquitectura del sof t war e durant e las p-
mer as et apas del diseo. Como se anal i z al principio de est e captulo, es posible os
rivar, refinar y eval uar estilos arqui t ect ni cos al t ernos par a det ermi nar cul es a
"mejor" enfoque. Este mt odo par a afront ar la opt i mi zaci n es uno de los verde j i -
r os benefi ci os que se obt i enen de desarrollar una represent aci n de la a r q u i t e c t o
del soft ware.
Es i mport ant e indicar que a menudo la simplicidad estructural refleja e l e g a n c i a
eficiencia. El objetivo del refi nami ent o del di seo debe ser el uso del menor nrr s a
de component es que permi t an una integracin efectiva de los mdul os y de la s |
terios como i ndependenci a del mdul o, factibilidad (eficacia de la i mpl ement ac: ; - f \
la prueba) y facilidad de mant eni mi ent o deben ponderarse cui dadosament e cuar a
se pr opongan modi fi caci ones est ruct ural es.
Construir
archivo de
configuracin
TM
PDF Editor
C A P T U L O 1 0 DISEO ARQUITECTNICO
311
tructura de datos menos compleja que sirva adecuadament e para los requisitos de
informacin.
La arquitectura del software proporciona un concepto holstico del sistema que ha-
br de construirse. Describe la estructura y la organizacin de los component es del
software, sus propiedades y la conexin entre ellos. Entre los component es del soft-
ware se incluyen los mdulos del programa y las diversas representaciones de dat os
que st e manipula. Por tanto, el diseo de dat os es una parte integral de la deriva-
cin de la arquitectura del software. La arquitectura destaca las decisiones iniciales
del diseo y proporciona un mecani smo para considerar los beneficios de estructu-
ras de sistema alternas.
El diseo de dat os traduce los objetos de dat os (definidos en el modelo de anli-
sis) a estructuras de dat os que residen dentro del software. Los atributos que descri-
ben el objeto, la relacin entre los objetos de datos y su utilizacin dentro del pro-
grama influyen en la eleccin de las estructuras de datos. En un grado ms elevado
de abstraccin, el diseo de dat os lleva a la definicin de una arquitectura para una
base de dat os o un almacn de datos.
El ingeniero del soft ware tiene a su disposicin varios estilos y patrones arquitec-
tnicos, Cada estilo describe una categora del sistema que abarca 1) un conjunto de
componentes que realizan una funcin requerida por un sistema, 2) un conjunto de co-
nectares que permiten la comunicacin, coordinacin y cooperacin entre compo-
nentes, 3) restricciones que definen la manera en que se integran los component es
para formar el sistema, y 4) model os semnticos que permiten a un diseador com-
prender las propiedades generales de un sistema.
En sentido general, el diseo arquitectnico se realiza aplicando varios pasos. En
primer lugar, el sistema debe estar represent ado en el contexto; es decir, el disea-
dor debe definir las entidades externas que interactan con el soft ware y la natura-
leza de la interaccin. Una vez que se ha especificado el contexto, el diseador de-
be identificar un conj unt o de abstracciones de nivel superior, llamadas arquetipos,
que representan el ement os centrales del comportamiento o la funcin del sistema;
despus de que se han definido las abstracciones, el diseo empieza a acercarse al
dominio de la implementacin. Se identifican los component es y se representan
dentro del contexto de una arquitectura que los soporta. Por ltimo, se crean instan-
cias especficas de la arquitectura para "probar" el diseo en un contexto real.
Como un simple ejemplo de diseo arquitectnico, el mt odo de correlacin o ma-
peo presentado en este captulo emplea las caractersticas del flujo de datos para de-
rivar un estilo arquitectnico de uso comn. Un diagrama de flujo de datos se corre-
laciona con una estructura del programa empl eando uno o dos enfoques de correla-
cin (correlacin de transformacin o de transaccin). Una vez que se ha derivado
una arquitectura, se elabora sta y luego se compara contra los criterios de calidad.
TM
PDF Editor
[AH083] Aho, A. V., J. Hopcrofl y J. Ul l mann. Data Structures and Algorith ms, Addi son-Wesj ;
1983.
[ALL97J Alien R., "A Formal Approach lo Software Architecture", tesis de doctorado, Camegie Me
University, Nmero de reporte tcnico: CMU-CS-97-144,1997.
[BAR001 Barroca. L. y P. Hall (eds.), Software Arch itecture- Advances and Applications, Sprir.: -.
Verlag, 2000.
[BAS03] Bass, L., P. Cl ement s y R. Kazman, Software Arch itecture in Practice, 2a. ed., Addis-:-
Wesley, 2003.
[BOSOO] Bosch, J., Design & Use o/ Software Arch itectures, Addison-Wesley, 2000.
[BUS96] Buschmann, F., Paltern- Oriented Software Arch itecture, Wiley, 1996.
[DAT00] Date, C. J., An Introduction lo Datab ase Sy stems, 7a. ed., Addison-Wesley, 2000.
[DIK00) Dikel, D., D. Kane y J. Wiison, Software Arch itecture: Organiz ational Principies and '
lems, Prentice-Hall, 2000.
[FRE80] Freeman, P ' The Context of Design", en Software Design Tech niq ues, 3a. ed. (P. Fre
y A. Wasserman, eds.), IEEE Comput er Society Press, 1980, pp. 2-4.
[GAR94] Garlan D.. R. Alien y J. Ockerbl oom, "Exploiting Style in Architectural Design I
ment s", en Proceedings of SIGSOFT '94 Sy mposium on th e Foundations of Software i
ring, 1994.
[GAR00] Garlan D.. R. T. Monroe y D. Wile, "Acm: Architectural Description of Componen:
sed Syst ems", en Foundations of Component- Based Sy stems, G. T. Leavens y M. Sit,
(eds.), Cambri dge University Press, 2000.
[HOFOO] Hofmeister, C., R. Nord y D. Soni, Applied Software Arch itecture, Addison-Wesley. ;
[HOFOl] Hofmann, C. et al., "Approaches t o Soft ware Architecture", se descarga de: ht t p: / / c
seer. nj . nec. com/ 84015. ht ml .
[KAZ98] Kazman, R. el al., Th e Arch itectural TTadeoJ f Analy sis Melh od, Sof t war e Engir
Institute, CMU/SEI-98-TR-008, julio de 1998.
[KIM98] Kimball, R L. Reeves, M. Ross y W. Thomt hwai t e, Th e Data Wareh ouse Lifecy cle '
kit: E x pert Meth ods for Designing, Developing, and Deploy ing Data Wareh ouses, Wiley
[LAN02] Land R., A Brief Survey of Soft ware Architecture, reporte tcnico, Depart ament o de l
nieria de Cmputo, Universidad Mlardalen, Suecia, febrero de 2002.
[LUC95] Luckham D. C. et al., "Specification and Analysis of System Architecture Using I
en IE E E TYansactions on Software E ngineering, ej empl ar "Special Issue on Soft ware ,
ture", 1995.
[MAT96] Mattison, R., Data Wareh ousing: Strategies, Tech nologies, and Tech niq ues, McGrav.
1996.
MYE78] Myers, G., Composite Slruclured Design, Van Nostrand, 1978.
[PRE98] Preiss, B. R., Data Structures and Algorith ms: With Ob ject- Oriented Design Pati
C++, Wiley, 1998.
[SHA96J Shaw, M. y D. Garlan, Software Arch itecture, Prentice-Hall, 1996.
[SHA97] Shaw, M. y P. Cl ement s. "A Field Guide to Boxoiogy: Preliminary Classificatior : 1
chitectural Styles for Soft ware Systems", en Proc. COMPSAC, Washington, DC, agosto de :
[WAS80] Wasser man. A., "Principies of Syst emat i c Data Design and Impl ement at i on". e
ware Design Tech niq ues (P. Fr eeman y A. Wasser man, eds.), 3a. ed. , IEEE Comput er
Press, 1980, pp. 287-293.
[YOU79] Yourdon, E. y L. Const ant i ne, Structured Design, Prentice-Hall, 1979.
[ZHA98] Zhao, ). , "On Assessing the Complexity of Soft ware Architectures", en Proc. Intl.
Arclvtecture Worksh op, ACM, Orlando, FL, 1998, pp. 163-167.
10. 1. Empl eando la arqui t ect ura de una casa o un edificio como met f or a, real i zar cc
ci ones con la arqui t ect ura del soft ware. En qu s on si mi l ares l as disciplinas de la ar
clsica y la del soft ware? En qu se diferencian?
TM
PDF Editor
10.2. Escribir un artculo de tres a cinco pginas que presente directrices para seleccionar es-
tructuras de datos basadas en la naturaleza del problema. Empezar delineando las estructuras
de datos clsicas encontradas en el trabajo del software y luego describir los criterios para se-
leccionar, a partir de stas, tipos particulares de problemas.
10. 3. Explicar la diferencia entre una base de datos que sirve a una o ms aplicaciones de ne-
gocios convencionales y un almacn de datos.
10. 4. Presentar dos o tres ejemplos de aplicaciones para cada uno de los estilos arquitectni-
cos indicados en la seccin 10.3.1.
10. 5. Algunos de los estilos arquitectnico indicados en la seccin 10.3.1 son de naturaleza je-
rrquica, otros no. Elaborar una lista de cada tipo. Cmo se implementaran los estilos arqui-
tectnicos que no son jerrquicos?
10. 6. Los trminos estilo arq uitectnico, patrn arq uitectnico y marco conceptual suelen encon-
trarse en el anlisis sobre la arquitectura del software. Investigar un poco (utilizar la Web) y des-
cribir la diferencia entre cada uno de estos trminos y sus contrapartes.
10. 7. Seleccionar una aplicacin con la que se est familiarizado. Responder cada una de las
preguntas planteadas para control y datos en la seccin 10.3.3.
10. 8. Investigar la MACA (visitar el sitio Web de SEI) y presentar un anlisis detallado de los
seis pasos presentados en la seccin 10.5.1.
10. 9. Algunos diseadores sostienen que todos los flujos de datos deben considerarse orienta-
dos a la transformacin. Analizar la manera en que esta convencin afectar la arquitectura
del software que se deriva cuando un flujo orientado a la transaccin se trata como transfor-
macin. Utilizar un flujo de ejemplo para ilustrar puntos importantes.
10.10. Si no se ha hecho, completar el problema 8.10. Emplear los mtodos de diseo descritos en es-
te captulo para desarrollar una arquitectura del software para el PHTRS.
10. 11. Empleando un diagrama de flujo de datos y una descripcin del procesamiento, descri-
bir un sistema de cmputo que tenga distintas caractersticas de flujo de transformacin. Defi-
nir los lmites del flujo y correlacionar el diagrama de flujo de dat os con la arquitectura del
software empleando la tcnica descrita en la seccin 10.6.3.
10. 12. Empleando un diagrama de flujo de datos y una descripcin del procesamiento, descri-
bir un sistema de cmput o que tenga distintas caractersticas de flujo de transaccin. Defina
los lmites del flujo y correlacione el diagrama de flujo de datos con la arquitectura del software
empleando la tcnica descrita en la seccin 10.6.4.
La literatura sobre arquitectura de software ha aumentado a lo largo de la dcada pasada, libros
de Fowler (Patterns of E nterprise Application Arch itecture, Addison-Wesley, 2003), Clementsy sus
colegas (Documentig Software Arch itecture: View and Bey ond, Addison-Wesley, 2002), Schmidt y
sus colegas (Pattern- Oriented Software Arch itectures, dos volmenes, Wiley, 2000), Bosch
[B0S00], Dikel y sus colegas [DIKOO], Hofmeister y sus colegas [HOFOO] Bass, Clements y
Kazman (BAS03], Shaw y Garlan [SHA96] y Buschmann e al. [BUS96] proporcionan un anlisis
a fondo del tema. Un trabajo previo de Garlan lAn ntroduction to Software Arch itecture, Software
Engineering Institute, CMU/SEI-94-TR-021,1994) Tiene una excelente introduccin. Clementsy
Northrop (Software Product Lines: Practices and Pattems, Addison-Wesley, 2001) trata el diseo
de arquitecturas que dan soporte a lneas de productos de sofware. Clements y sus colegas
(E vaiuating Software Arch itectures, Addison-Wesley 2002) considera los temas asociados con la
evaluacin de alternativas de arquitectura y la seleccin de la mejor arquitectura para un pro-
blema de dominio dado.
TM
PDF Editor
Libros especficos sobre implementacin de arquitectura tratan el diseo arquitectnico de-
tro de un ambiente de desarrollo o tecnologa especiales. Wallnau y sus colegas (Building Sy sters
from Commercial Componente, Addison-Wesley, 2001) presentan mtodos para construir arc_
tecturas basadas en componentes. Pritchard (COA and CORBA Side- b y - Side, Addison-Wesk*
1999), Mowbray (CORBA Design Patterns, Wiley, 1997) y Mark el al. (Ob jetet Manageme- :
Arch itecture Guide, Wiley , 1996) provee lineaminttos de diseo detallados para la estructura - -
soporte CORBA, Shanley (Protected Mode Software Arch itecture, Addison-Wesley 1996) proporc:
na asesoria sobre diseo arquitectnico para cualquier sistema operativo basado en tiempo T L.
para PC, sistemas operativos multiproposito o drvers.
La investigacin actual sobre arquitectura de software se documenta anualmente en 1 J
Proceedings of th e International Worksh op en Software Arch itecture, patrocinados por la ACM r
otras organizaciones de computacin, y los Proceedings of th e International Conference : n
Software E ngineering Barroca y Hall [BAR00] presentan un til estudio de investigacin recie- :
El modelado de datos es un requisito para un buen diseo en esta materia. Los libros JS:
Teory (Datab ase Modeling and Design, Academic Press. 1998); Schmidt (Data Modeling -r
Information Professionals, Prentice-Hall, 1998); Bobak (Data Modeling and Design for Toas s
Arch itectures, Artech House, 1997); Silverstone, Graziano e Inmon (Th e Data Model Resc u
Book, Wiley, 1997); Date [DAT00), y Reingruber y Gregoiy (Th e Data Modeling Handb ook: A Bes -
Practice Approach lo Building Quality Data Models, Wiley, 1994) contiene presentaciones de t a n -
das sobre notacin de modelado de datos, heuristic y aspectos del diseo de bases de dates El
diseo de almacenes de datos se ha vuelto ms importante en los ltimos aos. Los libres je
Humphreys, Hawkins y Dy (Data Wareh ousing: Arch itecture and Implementation, Prentice-
1999); Kimball el al. [K1M981 e lnmon (1NM95] tratan el tpico con mucho detalle.
El estudio general del diseo de software con discucin de aspectos de arquitectura y s - j
o de datos puede encontrarse en la mayora de los libros dedicados a la ingeniera de sofr -
re. Tratamientos ms rigurosos del tema se hallan en Feijs (A Formaliz ation of Design Met - .
Prentice-Hall, 1993) Witt etal. (Software Arch itecture and Design Principies, Thomson Publ
1994) y Budgen (Software Design, Addisson-Wesley, 1994).
Presentaciones completas de diseo orientado al flujo de datos pueden encontrarse en
[MYE78], Yourdon y Constantine [YOU79], y Page-Jones (Th e Practica! Cuide to Structured
Design, 2a. ed. Prentice Hall, 1998). Estos libros estn dedicados slo al diseo se in
extensos anlisis del flujo de datos.
Una amplia variedad de fuentes de informacin sobre el diseo arquitectnico estn
nibles en Internet. Una lista actualizada de referencias en la World Wide Web que son re
tes para el diseo arquitectnico puede encontrarse en el sitio Web de SEPA:
ht t p: / / www. mhhe. com/ pressman.
TM
PDF Editor
C A P T U L O
DI SEO AL NIVEL
DE COMPONENTES
11
r os
-329
327
318
317
321
325
325
340
322
331
338
-343
324
-340
322
E
l di seo al nivel de component es s e pr esent a despus de que se ha com-
pl et ado la pri mera iteracin del di seo arquitectnico. En est a et apa ya se
han est abl eci do los dat os general es y la est ruct ura del programa. El objeti-
vo es traducir el model o de di seo en un sof t war e operaci onal . Pero el gr ado de
abstraccin del model o de di seo exi st ent e es rel at i vament e elevado, y el del pro-
grama operacional, baj o. La traduccin llega a ser desafi ant e, abri endo la puerta
para el ingreso de errores sutiles que resultan difciles de encont rar y corregir en
et apas post eri ores del proceso de soft ware. En una f amosa conferenci a, Edsgar
Dijkstra, una de las per sonas que m s ha contribuido a nuest ra comprensi n del
di seo de soft ware, afi rm [DIJ72]:
Al par ecer , la di f er enci a e n t r e el s o f t wa r e y mu c h o s ot r os p r o d u c t o s e s q u e en s t os ,
c o mo r egl a gener al , ma y o r cal i dad r e pr e s e nt a pr eci o m s el evado. Qu i e ne s d e s e a n
s o f t wa r e r e a l me n t e conf i abl e de s c ubr i r n q u e d e b e n e n c o n t r a r un me d i o pa r a evi t ar
la ma y or pa r t e de los e r r or e s d e s d e el pr i nci pi o y, c o mo r es ul t ado, el p r o c e s o d e pr o
gr a ma c i n se vol ver mu c h o m s e c onmi c o. . . l os b u e n o s pr ogr a ma d or e s . . . no de -
be n des per di ci ar su t i e mpo d e pu r a nd o: d e b e n evi t ar l os e r r or e s d e s d e el pr i nci pi o.
Aunque est as pal abras fueron pr onunci adas hace muchos aos, an son v-
lidas. Cuando el model o de di seo se t raduce en cdi go fuent e deben segui rse
una serie de principios de di seo que no sl o realicen la traduccin, si no que
"eviten la introduccin de errores desde el principio".
Es posible represent ar el di seo al nivel de component es empl eando un len-
guaj e de programaci n. En esenci a, el pr ogr ama se crea con el model o de dise-
o arqui t ect ni co como gua. Un enf oque al t erno consi st e en represent ar el di-
seo al nivel de component es empl eando al guna represent aci n intermedia (por
ej empl o, grfica, tabular o basada en texto) que se t raduzca fci l ment e en cdi-
go fuent e. I ndependi ent ement e del mecani smo con que se represent e el di seo
al nivel de component es, las est ruct uras de dat os, las i nt erfaces y los algoritmos
definidos deben adecuar se a di versas lneas general es de di seo bien definidas,
que ayuden a evitar errores a medi da que evol uci ona el di seo procedi ment al .
En est e captulo se exami nar an esas l neas general es y los mt odos di sponi bl es
para seguirlas.
Qu e s ? Un conjunto completo de
componentes de software se defi-
ne durant e el diseo arquitectni-
co, pero las estructuras de datos
internas y el procesamiento de detalles de cada
componente no se representan en un gr ado de
abstraccin parecido al cdigo El diseo al ni-
vel de componentes define las estructuras de da-
3 1 5
TM
PDF Editor
los, los al gori t mos, l as caract er st i cas d e la inter-
f az y los mecani smos d e comuni caci n as i gna-
d os a c a d a component e d e soft ware.
Qui n l o hac e ? Un ingeniero de software rea-
liza el di s eo al nivel d e component es.
Por qu e s i mport ant e? Antes de construir el
sof t war e se d e b e t ener b c a pa c i d a d d e det ermi -
nar si f unci onar bi en. El di seo al nivel d e com-
ponent es r epr esent a el s of t war e d e tal ma ne r a
que permi t e revi sar si los det al l es del di seo son
correct os y consi st ent es con las r epr esent aci ones
iniciales del di seo (es decir, ios di seos d e da-
tos, ar qui t ect ur a e i nt er f azj Pr opor ci ona una
maner a d e eval uar si f unci onar n t as estructu-
ras, l as i nt erfaces y b s al gor i t mos.
Cul es son l os pa s o s ? Las representaciones
al nivel d e di seos d e dat os, ar qui t ect ur a e inter-
f az r epr esent an la bos e del di s eo af nivel d e
component es La defi ni ci n d e cl ase o b nar r a-
tiva d e pr oces ami ent o d e c a d a component e se
t r aduce en un di seo det al l ado que usa di a gr a -
ma s o f or mas d e texto q u e especi fi can estructu-
r as d e dat os i nt ernas, det al l e d e l a i nt erfaz local
y l gi ca d e pr ocesami ent o. La not aci n de dise-
o a b a r c a d i a gr a ma s UML y r epr esent aci one;
compl ement ar i as. El di seo pr ocedi ment al se es-
pec fica medi ant e un conj unt o d e const rucci ones
d e pr ogr amaci n est r uct ur ada.
Cul e s el product o obt eni do? El diseo d;
c a d a component e, r epr es ent ado en una noto
cin gr f i ca, t abul ar o textual, es el principo!
pr oduct o de t r a ba j o c r e a d o dur ant e el di seo d
nivel d e component es.
Cmo pue do est ar s eguro de que lo he
hecho correct ament e? Se realiza un recc
rri do o una i nspecci n del di seo. ste se exam
na p a r a det er mi nar si las est ruct uras d e dat o:
b s i nt erfaces, b s secuenci as y condi ci ones lgi
cas son cor r ect as y p a r a ver si ar r oj an b s dat e:
a pr opi a dos o la t r ansf or maci n d e control asi c
n a d a al component e dur ant e b s pr i mer as etc
pa s del di seo.
11 .i ftU ES
De maner a general, un component e es un bl oque de const rucci n modul ar para d
sof t war e de cmput o. De maner a m s formal, la especificacin unificada de l engua
je de model ado de OMG [OMGOl] defi ne un component e como "una part e modul a:
despl egabl e y reempl azabl e de un si st ema que encapsul a i mpl ement aci n y expeor
un conj unt o de interfaces".
Como se anal i z en el captulo 10, los component es puebl an la arquitectura x
sof t war e y, por t ant o, ayudan a cumplir con los objetivos y requisitos del si st ema tu
const rucci n. Debido a que los component es residen en el interior de la arqui t ect o
ra del soft ware, deben comuni car se y col aborar con ot ros component es y con enr -
dades (como ot ros si st emas, dispositivos, personas) que existen fuera de los l i mi t a
del soft ware.
Hi-
l o s detofles no son slo detcUes. Integran el diseo. "
Charles Eamts
El verdadero significado del t rmi no "component e" vari ar dependi endo del p je-
t o de vista del i ngeni ero de soft ware que lo usa. En la siguiente secci n se revisara-
t res concept os i mport ant es de lo que es un component e y la maner a en que se s
a medi da que se realiza el model ado del diseo.
TM
PDF Editor
C A P T U L O 1 1 DISEO AL NIVEL DE COMPONENTES 317
kVE
i unto de
10
e s un
i x dases que
i entre s.
*
tjuelosmo-
r x an lisis y
Micciones
. b prob ab le
in de
i x an lisis ori-
0 pasos
s adiciona-
1 seguidos
sdemo-
i dise o pa-
rla clase
: elab orada
$ del corn-
il. 1.1 Concept o or i ent ado a obj et os
En el cont ext o de la ingeniera del sof t war e ori ent ada a objetos, un component e con-
tiene un conj unt o de cl ases que col aboran ent re s.1 Cada clase de un component e
se ha el aborado compl et ament e para incluir t odos los atributos y las operaci ones re-
l evant es para su implementacin. Como parte de la elaboracin del diseo, tambin
deben definirse t odas las interfaces (mensajes) que permiten que las cl ases se comu-
niquen y colaboren con otras cl ases de diseo. Para lograrlo, el di seador empi eza
con el model o de anlisis y elabora clases de anlisis (en el caso de component es que
se relacionan con el dominio del problema) y cl ases de infraestructura (en el caso de
component es que proporcionan servicios de soport e para el dominio del problema).
Este proceso de el aboraci n del di seo se ilustra i magi nando que el sof t war e se
const rui r para una i mprent a sofisticada. El objetivo general del soft ware es recopi-
lar las necesi dades del cliente en el most rador, cot i zar un t rabaj o de impresin y pa-
sarl o a una pl ant a de producci n aut omat i zada. Durant e la ingeniera de los requi-
sitos se deriva una clase de anl i si s denomi nada Trabajol mprenta. Los at ri but os y
las oper aci ones definidos dur ant e el anlisis s e observan en la part e superi or iz-
qui erda de la figura 11.1. Durant e el di seo arqui t ect ni co se define Trabajol m-
prent a como un component e de la arquitectura de sof t war e y se represent a em-
pl eando la not aci n abrevi ada de UML que se muest ra en la part e central derecha de
la figura. Observe que Trabajol mprenta tiene dos i nt erfaces, cacularTrab ajo, que
proporci ona la capaci dad de cot i zar el t rabaj o, e iniciarTrab ajo, que pasa el t rabaj o a
la pl ant a de producci n. stas se represent an empl eando los s mbol os que se mues-
tran a la izquierda del recuadro del component e.
El di seo al nivel de component es empi eza en est e punt o. Deben el aborarse los
detalles del component e Trabaj ol mprent a para que proporci onen la i nformaci n
sufi ci ent e que gue la i mpl ement aci n. La clase de anlisis original se el abora para
dar forma a t odos los at ri but os y las oper aci ones requeri dos para i mpl ement ar la cla-
se como el component e Trabajol mprenta. Tomando como referencia la part e infe-
rior derecha de la figura 11.1, la clase de di seo Trabaj ol mprent a el aborada con-
tiene i nformaci n de atributos ms detallada, adems de una descripcin expandi da
de las oper aci ones requeri das para i mpl ement ar el component e. Las i nt erfaces ca-
cularTrab ajo e iniciaiTrab ajo llevan implcitas la comuni caci n y col aboraci n con
ot ros component es (que no se muest r an aqu). Por ejemplo, la operaci n calcular-
CostoPagina() (parte de la interfaz cacularTrab ajo) colaborara con un component e
Tabl aPreci os que cont i ene la i nformaci n de preci os de los t rabaj os. La operaci n
verificarPrioridadf) (parte de la interfaz iniciafTYab ajo) colaborara con el componen-
te Col aTrabajos para det ermi nar los tipos y las prioridades de los t rabaj os en espe-
ra (o en cola) que se encuent r an en produccin.
Esta actividad de el aboraci n se aplica a cada component e definido como part e
del di seo arquitectnico. Una vez compl et ado, se el abora an ms cada atributo,
1 En algunos casos un componente podra contener una sola clase
TM
PDF Editor
operaci n e interfaz. Deben especificarse las est ruct uras de dat os apr opi adas p i n
cada atributo. Adems, t ambi n se di sea el detalle algortmico que se requiere p:
ra i mpl ement ar la lgica de procesami ent o asoci ada con cada operaci n. Esta a:
vidad de di seo procedi ment al se anal i zar ms adel ant e, en est e mi smo cap:: -
Por ltimo, se di sean los mecani smos necesari os para implementar la interfaz. E" s
caso del soft ware orientado a objetos, est o abarca la descripcin de t odos los mera-i
jes que se requieren para realizar la comunicacin entre objetos dent ro del sistema
Elaboracin
de un
componente
de diseo.
11.1.2 El concept o convenci onal
En el cont ext o de la ingeniera del sof t war e convenci onal , un component e es un e
ment funci onal de un pr ogr ama que i ncorpora la lgica del procesami ent o, las r J
t ruct uras i nt ernas de los dat os necesari os para i mpl ement ar dicha lgica, y ur.a
t erfaz que permi t a la invocacin del component e y el paso de los dat os. Un co~rl
nent e convenci onal , t ambi n denomi nado mdul o, reside dent r o de la ar qui t er - -
cokul arCost odeTrabaj ol ( J
Imprmify posort robaj o( |
cakul or Tr aboj o
i n t e r f a z
cokul ar Tr obaj o
Trabo jolmprento
HpoPopd
p wo Po p d
x cokxPopel
* ampl i aci n
requisiiosColor
corocleristicasProduccion
I I opcionesDisIribucion
opci onesEncuader nado
por todaiAl macen
refine
por i dod
costoTotaTraboô
nomeroOT
i n t e r f a z
inictarTrabajo
col cul ai Cost oPogi no()
| cokul of Cos i oPop^| )
cokukj r Cosl oPr od( )
cal cul a rCosloTr a b a oToiol |
construrOrdenTrobajo( \
revi$afPrioridad( |
pasarTr a b a joAPr oducc on (
Componente
de dise o
TM
PDF Editor
C A P T U L O 1 1 DISEO AL NIVEL DE COMPONENTES
319
del sof t war e y represent a uno de t res papel es i mport ant es: I) como componente de
control que coordina la invocacin de t odos los dems component es del domi ni o del
probl ema, 2) como componente del dominio del probl ema que i mpl ement a una f un-
cin compl et a o parcial requerida por el cliente, o 3) como componente de infraes-
tructura responsabl e de funci ones que soport an el procesami ent o requeri do en el do-
minio del probl ema.
Como los component es ori ent ados a objetos, los component es del sof t war e con-
venci onal se derivan del model o de anlisis. Sin embargo, en est e caso el el ement o
de dat os ori ent ado al flujo del model o de anlisis sirve como base para la derivacin.
Cada t ransformaci n (burbuja) represent ada en los niveles inferiores del di agrama
de flujo de dat os (captulo 8) se correl aci ona di rect ament e (seccin 10.6) con una je-
rarqua de mdul os. Los component es de control (mdulos) residen cerca de la par-
te superior de la jerarqua (arquitectura) y los component es del dominio del problema
tienden a residir hacia la parte inferior de la jerarqua. Para lograr una modul ari dad
efectiva, se aplican concept os de di seo como la i ndependenci a funcional (captulo
9) a medi da que se el aboran los component es.
"Invari abl ement e se descubre que un sistemo complejo que funciona ha evolucionado a partir de un sistema simple
que t ambi n funci onaba.
John Goll
*
r se elab ora el
f coda
rrtede
t el punto
i desplaz a al
i x estructuras
! especficas y
i procedlmen-
: - nanipular las
s de datos.
, no deb e
tq uela
i q ue deb e
ros
sola
i glob al de
9 s e m a
s componentes.
Este proceso de el aboraci n del di seo de component es convenci onal es se ilus-
tra consi der ando de nuevo el sof t war e que se habr de construir para un sofisticado
cent ro de fot ocopi ado. Un conj unt o de di agr amas de flujo de dat os se derivara du-
rant e el model ado del anlisis. Se supondr que st os se correl aci onan (seccin
10.6) dent ro de la arquitectura que se muest ra en la figura 11.2. Cada recuadro re-
present a un component e de soft ware. Tmese en cuent a que los recuadros con pan-
talla gris t i enen una funcin equi val ent e a las operaci ones definidas en la clase Tra-
baj ol mprent a anal i zada en la secci n 11.1.1. Sin embargo, en est e caso cada ope-
racin se represent a como un mdul o separ ado que se invoca como se muest ra en
la figura. Con ot r os mdul os se controla el pr ocesami ent o y, por tanto, son compo-
nent es de control.
Durant e el di seo al nivel de component es, se el abora cada mdul o most r ado en
la figura 11.2. La interfaz del mdul o se define de maner a explcita. Es decir, se re-
present a cada obj et o de dat os o de control que fluye por la interfaz. El al gori t mo que
permi t e que el mdul o realice su funcin est di seado con el enfoque de refina-
mi ent o paso a paso anal i zado en el captulo 9. El compor t ami ent o del mdul o sue-
le represent arse con un di agrama de est ado.
Para ilustrar est e proceso consi drese el mdul o CalcularCostoPagina. Su objetivo
es calcular el cost o de impresin por pgina a partir de las especi fi caci ones del clien-
te. Los dat os necesar i os para realizar esta funci n son: nmero de pginas en el docu-
ment o, nmero total de document os que se producirn, impresin por una o ambas caras, color
TM
PDF Editor
o blanco y negro y tamao. Estos dat os se pasan a CalcularCostoPagina medi ant e la
t erfaz del mdulo. ste usa los dat os y det ermi na un cost o por pgi na que se ba5
en el t amao y la complejidad del t rabaj o (una funcin de t odos los dat os pasados a
mdul o con la interfaz). El cost o por pgi na es i nversament e proporcional al t arr
o del t rabaj o y di rect ament e proporcional a su complejidad.
Grfica de
estructura
de un siste-
ma conven-
cional.
Sistema de
] administracin
de t rabaj o
i Leer dat os
j de t rabaj o
l oe impresin
] Calcular costo
de pgi na
, Desarrollar
costo
de t rabaj o
HCalcular costo
de papel
Seleccionar
la funcin
I de manejo
de t rabaj o
T
] Calcular costo
de prod.
Revisar
prioridad
Pasar trabe
a producc
En la figura 11.3 se represent a el di seo al nivel de component es empl eand
not aci n UML modificada. El mdul o CalcularCostoPagina tiene acceso a l osd - ( |
invocar al mdul o ob tenerDatosTrab ajo, que permi t e el paso de t odos los datos - n e -
vant es al component e, y una interfaz de base de dat os, accesarBDCostos, que pe mf l
te que el mdul o t enga acceso a una base de dat os con t odos los cost os de :.
sin. A medi da que prosi gue el di seo se el abora el mdul o CalcularCostoPagir.. J
ra proporci onar el detalle del algoritmo y la interfase (figura 11.3). El detalle
gori t mo se represent a empl eando el texto de seudocdi go que se muest ra en la M
ra con un di agrama de actividad de UML. Las i nt erfaces se represent an como ur a a
leccin de obj et os o el ement os de dat os de ent r ada y salida. La elaboracin
seo cont i na hast a que s e proporci one detalle suficiente para guiar la const>
del component e.
TM
PDF Editor
C A P I T U L O 1 1 DISEO AL NIVEL DE COMPONENTES
3 2 1
al nivel
snentes
Calculaz-
a.
Mdulo elaborado
obtenerDatosTrabajo
o
Componente de diseo
accesarBDCostos
CostoPagina
entra: numeroPagnas
entra: numeroDocumentos
entra: lados= I, 2
entra: colon* I, 2, 3, 4
entra: tamaoPagina = A, B, C, D
sale: costo de pgi na
entra: tamaoTrabajo
entra: colora 1, 2, 3, 4
entra: tamaoPagina - A, B, C, D
sale: CBP
sale: SF
obtenerDatosTrabajo (numeroPagnas,
numeroDocumentos, lados, color,
tamaoPagina, costoPagina)
accesarBDCostosftamaoTrabajo, color,
tamaoPagina, CBP, SF)
calcularCostoPagina()
tamao de t rabaj o (TT)
numeroPagnas = numeroDocumentos;
buscar costo base de pgina (CBP) ->
accesarBDCostos (TT, color);
buscar factor de t amao (FT) ->
accesarBDCostos (TT, color, tamao)
factor de complejidad de trabajo (FCT) =
I + [(lados-l)*costolado + FT]
costoPagina CBP * FCT
11.1.3 Un concept o r el aci onado con el pr oceso
En los concept os ori ent ado a obj et os y convenci onal del di seo al nivel de compo-
nent es pr esent ados en las secci ones ant eri ores, se supone que los component es se
han di seado desde cero. Es decir, que el di seador debe crear un nuevo componen-
te basado en especi fi caci ones deri vadas del model o de anlisis. Hay, por supuest o,
ot ro enf oque.
En la dcada pasada, la comuni dad de la ingeniera del sof t war e ha dest acado la
necesi dad de construir si st emas que usen los component es de sof t war e exi st ent es.
En esenci a, un cat l ogo de component es pr obados al nivel de di seo o de cdi go
queda a disposicin del ingeniero de soft ware a medi da que avanza en el t rabaj o de
diseo. Mientras se desarrolla la arquitectura del soft ware, se eligen del cat l ogo los
component es o pat rones de di seo y se usan para poblar la arquitectura. Debido a que
est os component es se han creado con la reutilizacin en ment e, se encuent r a a dis-
posicin del di seador una descripcin compl et a de su interfaz, la funcin o las f un-
ci ones que realiza y la comuni caci n y col aboraci n que requiere. La ingeniera del
soft ware basada en component es se anal i zar de maner a muy det al l ada en el cap-
t ul o 30.
TM
PDF Editor
h
Middleware e ingeniera de software b asada en componentes
Uno de los elementos clave que lleva al xito o
el fracaso de la ingeniera del software basada
en componentes es la disponibilidad de middleware. sta
es una coleccin de componentes de infraestructura que
permiten que los componentes del dominio del problema
se comuniquen con otros en una red o dentro de un siste-
ma complejo. Quienes desean usar ingeniera del software
basada en componentes a medida que avanza el proceso
de software cuentan con tres estndares competidores:
OMG CORBA {http://www.corba.org/).
Microsoft COM
(http://www.microsoft.com/com/tech/complus.asp!
Sun J avaBeans (http://java. sun. com/products/ejb/).
Los anteriores sitios Web presentan una amplia variedcx:
de tutoriales, manuales, herramientas y recursos generae-
sobre estos importantes estndares de middleware. En e
captulo 30 se encontrar ms informacin acerca de la
ingeniera del software basada en componentes.
Como ya se ha observado, el diseo al nivel de component es se basa en info~
desarrollada como parte del model o de anlisis (captulo 8) y representada
part e del model o arquitectnico (captulo 10). Cuando se elige un mt odo de
niera de software b asado en componentes, el dise o al nivel de stos se cont-
en la elaboracin de las clases de anlisis (clases especficas del dominio del |
ma), y la definicin y la afinacin de las clases de infraestructura. La descripcir
tallada de los atributos, las operaci ones y las interfaces empl eados por estas
representa el detalle de diseo requerido como precursor de la actividad de a r s - l
truccin.
11.2.1 Principios bsi cos de di seo
Hay cuat ro principios bsicos de diseo aplicables al diseo al nivel de c o mp - : - -
tes y se han adopt ado ampl i ament e cuando se aplica ingeniera de soft ware or . enaj
da a objetos. La motivacin elemental para la aplicacin de est os principios es
di seos que sean ms sensibles al cambi o y reducir la propagacin de efect os:
darios cuando ocurren cambios. Estos principios pueden usarse para guiar al -
ador a medi da que desarrolla un component e de software.
El principio abi ert o- cerrado (PAC). "[E l componente de] un mdulo deb e
ab ierto para ex tensin, pero cerrado para modificacin" [MAROO]. Esta frase pareec
contradiccin, pero representa una de las caractersticas ms importantes i
buen di seo al nivel de component es. Para expresarlo de manera simple, el
dor debe especificar el component e de maner a que permita extenderlo (dentr;
domi ni o funcional que atiende) sin necesidad de modificaciones internas al
component e (al nivel de cdigo o lgica). Para ello, el diseador crea abstrae
que sirven como memori a intermedia entre la funcionalidad que tal vez habr oe
t enderse y la propia clase de diseo.
TM
PDF Editor
3 2 3
t o
PAC
i n t e r f a z
Sensor
leer()
habilitar!
inhabilitar!
pr obar ) )
4 V
i
Detector
sensorPuert as/
Ventanas
SensorHumo DeteclorMovimiento SensorCalor Sens or C02
Por ejemplo, suponga que la funci n de seguridad HogarSeguro usa la clase De -
t ect or que debe revisar el est at us de cada tipo de sensor de seguridad. Es probabl e
que con el t i empo aument en el nmer o y los tipos de sensor es de seguri dad. Si la l-
gica de procesami ent o i nt erno est i mpl ement ada como una secuenci a de const ruc-
ci ones si - ent onces- sLno (if-then-else), donde cada una at i ende un tipo de sensor di-
ferente, la adicin de un nuevo tipo de sensor requerir lgica de pr ocesami ent o in-
t erno adicional (un si -ent onces-si _no adicional). Esto es una violacin del PAC.
Una maner a de cumplir con el PAC en el caso de la cl ase Det ect or s e ilustra en
la figura 11.4. La i nt erfaz sensor present a una vista consi st ent e de sensor es para el
component e Det ect or. Si se agrega un nuevo tipo de sensor no se requieren cam-
bi os en la clase Det ect or (component e). Se preserva el PAC.
HOGARSEGURO
El PAC en accin
Lo e s c e n a : Cubculo de Vinod.
s: Vinod y Shakira, integrantes del equi po
ingeniera del software HogarSeguro.
conversacin:
Vi nod: Acabo de recibir una llamada de Doug (el ge-
- del equipo). Dice que marketing quiere agr egar un
i sensor.
=ki r a ( s o n r i e n d o ) : Otra vez!
J: S... y no vas a creer con lo que han salido aho-
nki r a : Sorprndeme.
Vi nod ( r i e ndo) : Lo llamaron sensor detector de ladridos.
S h a k i r a : Qu significa?
Vi n o d : Es par a la gent e que dej a sus mascotas en de-
part ament os o condominios o casas muy cercanas. S pe-
rro empi eza a ladrar. El vecino se enoja y se quej a. Con
este sensor, si el perro l adra durant e ms de un minuto,
por decir al go, el sensor detona una al ar ma especial que
llama al telfono celular del dueo.
S h a k i r a : No bromees.
Vi n o d : Es en serio. Doug qui ere saber cunt o tiempo
nos tomar agregarl o a la funcin de seguridad.
Shaki ra ( pensando por un moment o): No mu-
cho... mira [le muestra a Vinod la figuro 11.4]. Hemos
ai sl ado las clases de sensores reales tras la interfaz sen-
sor. Siempre y cuando t engamos especificaciones del
sensor de perros, se agr ega en un tris. Lo nico que ten-
TM
PDF Editor
324 P ART E D O S PRCTICA DE LA INGENIERA D A SOFTWARE
go que hacer es crear un componente apropi ado. . . o
sea, uno clase, para l. No hay ninguna necesidad de
cambiar el componente Detector.
Vi nod : Entonces le puedo decir a Doug que no hay mu-
cho problema,
S h a k i r a : Conociendo a Doug, nos tendr ocupados y
no enviar lo cosa esa contra perros hasta la prxima
versin.
Vi n o d : No est mal, pero lo podras implementar a!-:
ra mismo si l lo quisiera?
S h a k i r a : S, la manera en que diseamos la interfaz - i
permite hacerlo sin mucho esfuerzo.
Vinod (pensando por un moment o): Alguna
has odo hablar del "Principio Abierto-Cerrado"?
Shaki ra (encogiendo los hombros): Nunca
Vi nod ( sonr i endo) : No importa.
( CONSEJ O^
Si se prescinde del di-
se o y se pasa direc-
tamente al cdigo,
slo recurdese q ue
ste es la 'concre-
cin" final. As q ue se
estar violando el PID.
Pri nci pi o de sust i t uci n de Li skov (PSL). "Deb e tenerse la opcin de sustitu- i
sub clases con sus clases principales." [MAROO] Este principio del di seo, que orig
ment e pr opuso Barbara Liskov [LIS88], sugiere que un component e que use una
se principal debe seguir f unci onando apr opi adament e si, en cambi o, se pasa a! i
ponent e una clase derivada. El PSL exige que cualquier clase derivada de una
principal se apegue a cualquier cont rat o implcito ent r e la clase principal y los i
ponent es que la usan. En el cont ext o de esta explicacin, un "contrato" es una
dicin previa que debe ser verdad despus de que el component e usa una clase |
cipal y una condicin posterior que debe ser cierta despus de que el component e J
una cl ase principal. Cuando un di seador crea cl ases derivadas, t ambi n deben
tarse a las condi ci ones previ as y post eri ores.
Pri nci pi o de i nversi n de la dependenci a (PID). "Dependa de las ab straed: --r l
no de las concreciones." [MAROO] Como hemos visto en el anlisis del PAC, las a-5-1
t racci ones son el lugar donde un di seo se puede ext ender sin gr andes complica
nes. Cuant o m s dependa un component e de ot ros component es concret os (en - J
gar de abst ract os, como la interfaz), ms difcil ser ext enderl os.
Pri nci pi o de s egregaci n de la i nterfaz (PSI). "E s mejor tener much as inter: .
especficas del cliente q ue una interfaz de propsito general." [MAROO] Hay mucho; la-
sos en que varios component es de cliente usan las operaciones proporcionadas por
clase de servidor. El PSI sugi ere que el di seador debe crear una interfaz espec A-
zada par a servir a cada cat egor a i mport ant e del cliente. Slo las operaci ones i m:
t ant es para una cat egor a especial de cl i ent es deben especi fi carse en la interfaz o a l
ra esos clientes. Si vari os cl i ent es necesi t an las mi smas operaci ones, deben especi-
ficarse en cada una de las i nt erfaces especi al i zadas.
Por ejemplo, pi ense en la clase Pl anoCasa que se usa en HogarSeguro para -i
ci ones de seguridad y vigilancia. En el caso de las funci ones de seguridad, PlanoO-
s a slo se empl ea durant e las actividades de configuracin y utiliza las operaci : - as
colocarDispositivo(), mostrarDispositivo(), agruparDispositivo() y eliminarDisposic *
para colocar, mostrar, agrupar y eliminar sensores del plano. La funcin de vi gi l a- aB
de HogarSeguro usa las cuat ro operaci ones i ndi cadas para seguridad, pero sle t a l
quiere operaci ones espaci al es para manej ar las cmaras: mostrarPVf) y mostrarle : z - \
TM
PDF Editor
CAPTULO 11 DISEO AL NIVEL DE COMPONENTES
325
kVE
i * compo-
ne reutilizo-
! ms que
i i s eo tcni-
i requiere
n efec-
i mecanismos
i (captulo
positivo)). Por tanto, el PSI sugiere que los component es de cliente de las dos funcio-
nes de HogarSeguro tengan interfaces especializadas y definidas para ellas. La interfaz
de seguridad sl o abarcar a las operaci ones colocarDispositivof), mostrarDispositivo(),
agruparDispositivo() y eliminarDispositivof). La interfaz de vigilancia incorporara las
cuat ro operaci ones anteriores, adems de mostrarPV() y mostrar DDispositivo().
Aunque los principios de di seo al nivel de component es proporci onan una gua
til, los propi os component es no existen en el vaco. En muchos casos, los compo-
nent es o las cl ases individuales se organi zan en subsi st emas o paquet es. Es razona-
ble pregunt ar, cmo debe present arse esta actividad de empaquet ami ent o? Exacta-
ment e, cmo deben or gani zar se los component es a medi da que avanza el diseo?
Martin (MAROO] sugiere principios adi ci onal es de empaquet ami ent o que son aplica-
bles al di seo al nivel de component es.
Pri nci pi o de equi val enci a ent re reuti l i zaci n y versi n (PER). "La esencia de la
reutiliz acin es la misma q ue de la versin." |MAROO] Cuando las cl ases o componen-
tes se di sean para reutilizarlos, hay un cont rat o explcito ent re el desarrol l ador de
la ent i dad reutilizable y la persona que la usar. El desarrollador se compr omet e a
est abl ecer un si st ema de control de versi ones que d soport e y mant enga las versio-
nes ant eri ores de la entidad mi ent ras los usuari os actualizan l ent ament e la versin
ms actual. En lugar de at ender cada clase individualmente, lo aconsej abl e sera agru-
par las cl ases reutilizables en paquet es que pueden manej ar se y cont rol arse a medi-
da que evol uci onan nuevas versiones.
Pri nci pi o del ci erre c omn (PCC). "Las clases q ue camb ian juntas deb en permane-
cer juntas." [MAROO] Las cl ases deben empaquet ar se de maner a que sean un t odo co-
herent e. Es decir, cuando las cl ases se empaquet an como part e de un di seo, deben
at ender la mi sma rea de funci ones o comport ami ent os. Cuando al guna caracters-
tica de esa rea debe cambi ar, es probable que sl o deban modificarse las cl ases del
paquet e. Esto lleva a un control de cambi os y a un manej o de las versi ones ms efec-
tivos.
Pri nci pi o c o mn de l a reut i l i zaci n (PCR). "Las clases q ue no se reutiliz an juntas
no deb en agruparse juntas." [MAROO] Cuando una o m s cl ases cambi an en un pa-
quet e, t ambi n cambi a el nmer o de versin del paquet e. Todas las dems cl ases o
los dems paquet es que dependen de ese paquet e deben act ual i zarse ahora a la ver-
sin m s reci ent e del paquet e y probarse para asegur ar que la nueva versin funci o-
na sin incidentes. Si no hubo cohesi n al agrupar las clases, es posible que cambi e
una clase que no t enga relacin con las dems. Esto requerir un pr oceso i nnecesa-
rio de integracin y prueba. Por ello, sl o deben incluirse en un mi smo paquet e las
cl ases que se reutilizarn juntas.
11.2.2 L neas gener al es de di seo al ni vel de component es
Adems de los principios anal i zados en la secci n 11.2.1, es posible aplicar un con-
j unt o pragmt i co de lneas general es de di seo a medi da que avanza el di seo al ni-
TM
PDF Editor
326 PARTE D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
T :
J l Qu se
debe t omar
en cuent o cuando
se nombr an l os
component es?
vel de component es. Estas lneas general es se aplican a component es, s us i nt e- :
ees y las caractersticas de dependenci a y herenci as que i mpact an el di seo r es -
tante. Ambler [AMB02] sugiere las si gui ent es l neas general es:
Component es . Deben definirse convenci ones de asi gnaci n de nombr es para
component es especi fi cados como part e del model o arqui t ect ni co, y luego refin;--:1
y el aborarse como part e del di seo al nivel de component es. Los nombr es del -
dl o arqui t ect ni co deben ext raerse del domi ni o del pr obl ema y t ener algn sig-
cado par a los part i ci pant es que ven el model o arquitectnico. Por ejemplo, el
bre de clase Pl anoCasa tiene significado para qui enes lo leen, sin importar sus
t ecedent es tcnicos. Por ot ra part e, los component es de i nfraest ruct ura o las
el aboradas al nivel de component es deben t ener un nombr e que refleje el sign
do especfico de la i mpl ement aci n. Si se habr de manej ar una lista vinculada
mo part e de la i mpl ement aci n de Pl anoCasa, la operaci n manejarLista()
apropi ada, aunque una persona sin conoci mi ent os t cni cos podra malinterp:
Tambin val e la pena usar est ereot i pos para ayudar a identificar la na t ur a l e s
los component es al nivel de di seo detallado. Por ejemplo, infraestructura
usarse para identificar un component e de infraestructura; basededatos podra i
se para identificar una base de dat os que sirve a una o m s cl ases del di seo c
do el si st ema; t a bl a se usara para identificar una tabla dent r o de una base ce
tos.
Int erf aces. Las i nt erfaces proporci onan i nformaci n i mport ant e acerca de i
muni caci n y la col aboraci n (adems de ayudar a lograr el PAC). Sin embar g:
represent aci n libre de las i nt erfaces tiende a complicar los di agramas del cc
nent e. Ambler [AMB02] recomi enda que 1) cuando los di agr amas se vuel var
compl ej os se use la represent aci n de lnea y crculo para una interfaz, en lugi* .
Cohesin de
capa.
Panel de control
Detector Telfono
Modem
T-com
2 Es improbable que una persona de marcadotecnia o de la organizacin del cliente (un tipo
tecedentes tcnicos) examine el detalle de la informacin de diseo
TM
PDF Editor
C A P I T U L O 1 1 DISEO AL NIVEL DE COMPONENTES 327
[CONSEJO.
(tsulta instruc-
i ampiensin de
s grados de
.esmsim-
i estar cons-
i ' concepto
is medida q ue
i componen-
tcrtngase lo
r coh esin posi-
enfoque ms formal del recuadro UML y la flecha con lnea de guiones; 2) por razo-
nes de consistencia, las interfaces deben fluir desde la izquierda del recuadro del
component e; 3) slo deben mostrarse las interfaces relevantes del component e en
cuestin, aunque estn disponibles otras. Estas recomendaci ones pretenden simpli-
ficar la naturaleza visual de los diagramas de component es UML.
Dependenci as y herenci a. Para mejorar la legibilidad es buena idea modelar las
dependenci as de izquierda a derecha y la herencia de abaj o (clases derivadas) hacia
arriba (clases principales). Adems, las interdependencias entre los component es
deben representarse mediante interfaces, en lugar de hacerlo mediante la represen-
tacin de una dependencia de component e a componente. Siguiendo la filosofa del
PAC, est o ayudar a mejorar las opciones de mant eni mi ent o del sistema.
11.2.3 Cohesi n
En el captulo 9 se describi la cohesin como la "funcin nica" de un componen-
te. En el contexto del diseo al nivel de component es para si st emas orientados a ob-
jetos, la coh esin implica que un component e o una clase slo encapsula atributos y
operaciones relacionadas est rechament e ent re s y con la clase del propio compo-
nente. Lethbridge y Laganire [LET01] definen varios tipos diferentes de cohesin
(que aparecen en la lista ordenados segn su grado de cohesin):3
Funcional. Exhibido principalmente para operaciones, este grado de cohesin se
presenta cuando un mdulo realiza un solo clculo y luego devuelve un resultado.
De capa. Exhibido para paquetes, component es y clases, este tipo de cohesin
ocurre cuando una capa superior tiene acceso a los servicios de una inferior, pero
sta no tiene acceso a aqulla. Pinsese, por ejemplo, en la necesidad de que la fun-
cin de seguridad de HogarSeguro haga una llamada telefnica al exterior si se dis-
para una alarma. Sera posible definir un conjunto de paquet es en capas como se
muestra en la figura 11.5. Los paquet es con pantalla gris contienen component es de
infraestructura. El acceso se tiene del paquet e del panel de control hacia abajo.
De comuni caci n. Todas las operaciones con acceso a los mismos dat os se de-
finen dentro de una clase. En general, esa clase slo se concent ra en los dat os en
cuestin, accesndolos y almacenndolos.
Resulta relativamente fcil implementar, probar y mant ener las clases y los com-
ponent es que muestran cohesin funcional, de capa y de comunicacin. El disea-
dor debe luchar por alcanzar estos grados de cohesin. Sin embargo, hay muchos
casos en que se encuent ran los siguientes niveles inferiores de cohesin:
Secuenci al . Los component es o las operaciones estn agrupados de manera que
el primero permita la entrada al siguiente, y as sucesivamente. El objetivo es imple-
ment ar una secuencia de operaciones.
3 En general, mientras mayor sea el grado de cohesin, ms fcil ser implementar, probar y mante-
ner el componente.
TM
PDF Editor
Procedi ment al . Las component es o las oper aci ones est n agol pados de man;
ra que permi t en la invocacin de uno i nmedi at ament e despus de que s e invoque e
anterior, aunque no se hayan pasado dat os ent re ellos.
Temporal . Las operaci ones que se realizan reflejan un compor t ami ent o o e s U:
especfico, como una operaci n que se realiza al principio o t odas las operaciones
real i zadas cuando se det ect a un error.
Utilitaria. Se han agr upado component es, cl ases u operaci ones que existen de-
t r o de la mi sma categora, pero que no tienen otra relacin. Por ejemplo, una clase
l l amada Est ad st i ca muest ra cohesi n utilitaria si cont i ene t odos los atributos y .=
operaci ones necesari os para calcular sei s medi das est ad st i cas simples.
Estos grados de cohesi n son menos deseabl es y deben evi t arse cuando existe
ot r as opci ones de diseo. Sin embargo, es i mport ant e t omar en cuent a que a veres
los t emas pragmt i cos de diseo e implementacin obligan al diseador a opt ar por ka.
gr ados inferiores de cohesi n.
HOGARSEGURO
Cohesin en accin
' S UJ L ' I J B HJ ! El e s c e n a r i o : Cubculo de j ami e.
Los p e r s o n a j e s : Jamie y Ed, integrantes del equi po de
ingeniera del software que t r abaj an en la funcin de vi-
gilancia.
La conversacin:
Ed: Tengo un diseo preliminar del componente de cmara.
J a mi e : Puedo hacerle una rpi da revisin?
Ed: Supongo que s . p e r o en realidad quisiera tu opi-
nin sobre algo.
(Jamie le hace un gesto par a que siga habl ando. )
Ed: Originalmente definimos cinco operaciones par a c-
mara. Mi ra. . . {muestra la lista a Jamie].
determinarTpol I me dice el tipo de cmara.
tradu rUb icacionf I me permite mover la cmar a por
et pl ano de la caso
desplegarlo(j obtiene el ID de la cmar a y lo muestra
unto al icono de sta
desplegarVstal) me muestra grficamente el campo
de vista de la cmar a
aesplegarZooml I me muestra grficamente la am-
pliacin de la cmar a.
Ed: He di seado cada uno por separ ado, y son opere
clones muy simples. De modo que sera buena idea co_
binar t odas las operaci ones de despliegue en una soic
que se llamara desplegarC maral); mostrara el ID, la
visto y el zoom. Qu te parece?
J a mi e ( h a c i e n d o u n a mu e c a ) : No estoy segura c :
que sea una buena i dea.
Ed ( f r u n c i e n d o el c e o ) : Por qu? Todas estas pe
quenas operaci ones pueden causar dolores de cabeza
J a mi e : El problema de combinarlos es que perdemos
cohesin. T sabes, la operacin desplegarC maral I nd
tendra una sola funcin.
Ed ( un p o c o e x a s p e r a d o ) : Y eso qu? Todo este
tendr ms de cien lneas de cdigo. Creo que ser f;
implementarlo.
J a mi e : Y qu pasar a si mercadotecnia decide cam-
biar la manera en que representamos el campo de vis*r
Ed: Simplemente me meto en la operaci n desplegarC: -
mara() y el aboro el mdulo.
J a mi e : Y qu pasa con los efectos colaterales?
Ed: A qu te refieres?
TM
PDF Editor
C A P T U L O 1 1 DISEO AL NIVEL DE COMPONENTES 3 2 9
z : Bueno, digamos que haces el cambio pero, sin
cuenta, creas un problema con el despliegue del ID.
No sera tan descui dado.
: Tal vez no, pero qu pasar a si una persona de
tiene que hacer el mdulo dentro de dos aos,
tz no comprenda la operacin tan bien como t y,
sabe, podra ser descui dado.
Ed: De modo que ests en contra de l?
J ami e : T eres el di seador. . . es tu decisin... slo ase-
grat e de comprender las consecuencias de una baj a co-
hesin.
Ed (pensndolo por un momento): Tal vez
mos ir con diferentes operaci ones de despliegue.
J a mi e : Buena decisin.
E

#
i q ue se ero-
h r e ise o de codo
de sofl-
atencin se
al dise o de
m c u c s de dalos
sy alosdi-
E j cedimentales
m imputar las es-
tile datos. Sin
D, no deb en
_ _ _ M la orq uitectu-
I u eb e alb ergar
b moonentes o los
glob ales
q ue pueden
much os corn-
il.2.4 Ac o p l a mi e n t o
En exposiciones precedent es del anlisis y el diseo se observ que la comunicacin
y la colaboracin son el ement os esenciales de cualquier sistema orientado a obje-
tos. Sin embargo, hay un lado oscuro en esta importante (y necesaria) caractersti-
ca. A medida que aument a la cantidad de comunicacin y colaboracin (es decir, a
medida que crece el grado de "conectividad" ent re las clases), tambin aument a la
complejidad del sistema. Y a medida que sta aument a, la dificulta de implementar,
probar y mant ener el soft ware tambin lo hace.
El a c o p l a m i e n t o es una medida cualitativa del grado al que las clases se conectan
entre s. A medida que las clases (y los componentes) se vuelven ms interdepen-
dientes, el acoplamiento aument a. Un objetivo importante en el diseo al nivel de
component es consiste en mant ener el acoplamiento lo ms bajo posible.
El acoplamiento de clase se manifiesta de varias maneras. Lethbridge y Lagani-
re [LET01] definen las siguientes categoras de acoplamiento:
Acopl ami ent o del cont eni do. Ocurre cuando un component e "modifica su-
brepticiamente dat os internos de otro" [LET01]. Esto viola la ocultacin de la infor-
macin, que es un concept o bsico del diseo.
Acopl ami ent o comn. Ocurre cuando varios component es usan una variable
global. Aunque est o es necesario en algunas ocasi ones (por ejemplo, para estable-
cer valores predet ermi nados en toda una aplicacin), el acoplamiento comn puede
llevar a la propagacin incontrolable de errores y a efectos colaterales imprevisibles
cuando se hacen cambios.
Acopl ami ent o de control. Se present a cuando la o p e r a c i n A ( ) invoca la o p e r a -
c i n B ( ) y pasa una marca de control a 8. La marca de control "dirige" ent onces el
flujo lgico dentro de 8. El problema con esta forma de acoplamiento es que un cam-
bio no relacionado en 8 puede causar la necesidad de cambiar el significado de la
marca de control que pasa A . Si est o se omite, se presentar un error.
Acopl ami ent o de est ampa. Ocurre cuando Cl aseB se declara como tipo para
un argument o de una operacin de ClaseA Debido a que Cl aseB ahora es parte de
la definicin de ClaseA, la modificacin del sistema se vuelve ms compleja.
TM
PDF Editor
Acopl ami ent o de dat os . Ocurre cuando las oper aci ones pas an cadenas lar.-
de ar gument os de dat os. El "ancho de banda" de la comuni caci n ent re clase;
component es crece y la complejidad de la interfaz aument a. La prueba y el mar : ;
ni mi ent o son ms difciles.
Acopl ami ent o de l l amada a rutina. Ocurre cuando una operaci n invoca a
otra. Este grado de acopl ami ent o es comn y, a menudo, muy necesari o. Sin eme: -
go, aument a la conectividad de un si st ema.
Acopl ami ent o de us o de ti po. Ocurre cuando el component e A usa un tipc a:
dat os definido en el component e B (por ejemplo, est o ocurre cada vez que "una cl
declara una variable de instancia o una local como si tuviera otra clase para su t i re'
[LET01]). Si cambi a la definicin del tipo, t ambi n deben cambi ar t odos los cor r :
nent es que usan la definicin.
Acopl ami ent o de i ncl usi n o i mport aci n. Ocurre cuando el componen:-: A
importa o incluye un paquet e o el cont eni do del component e B.
Acopl ami ent o ext erno. Ocurre cuando un component e se comuni ca o colar-o-j
ra con component es de infraestructura (como las funci ones del si st ema de o p t ' r
cin, la capacidad de la base de datos, las funci ones de comunicacin). Aunque esrsl
tipo de acopl ami ent o es necesari o, debe limitarse a un pequeo nmer o de c o r -
nent e o cl ases dent r o de un si st ema.
El sof t war e debe comuni car se i nt erna y ext er nament e. Por t ant o, el acopl ami en: ; *
fundament al . Sin embargo, el di seador debe t rabaj ar para reducir el acoplam:e~ai
cada vez que sea posible y compr ender las rami fi caci ones de un acopl ami ent o t e-
vado cuando no pueda evitarse.
Acoplamiento en accin
El e s c e na r i o: Cubculo de Shakira.
Los a c t or e s : Vinod y Shakira, integrantes del equipo
de ingeniera del software HogarSeguro que trabajan en
la funcin de seguridad.
La conversacin:
Sh a k i r a : Tuve lo que consideraba una estupenda
idea... Luego lo pens un poco mejor y no me pareci
tan buena. Por ltimo, lo rechac, pero pens que sera
conveniente compartirla contigo.
Vi nod: Seguro, cul es la idea?
Sh a k i r a : Bueno, cada uno de los sensores reconoce
una condicin de alarma de cada tipo, verdad?
Vi nod ( sonr i endo) : Por eso los llamamos sensores,
Shakira. ' ' *
Sh a k i r a ( e x a s p e r a d a ) : No seas sarcstico, Viro;
Tienes que trabajar en tus habilidades interpersonale:-
Vi nod: Qu me estabas diciendo?
Sh a k i r a : Bien, de todas maneras, pensaba. . . Por que
no crear una operacin en cada objeto sensor denor- re
da h acerUamada(} que colaborara directamente con e:
componente Ll a ma da Sa l i e nt e , bueno, con una nter
faz al componente Ll amadaSal i ent e.
Vi nod ( pensat i vo) : En lugar de hacer que esa cc ;
boracin ocurra fuera de un componente como Pa ne l -
Cont r ol o algo asi?
Sh a k i r a : Claro... pero luego me dije, eso significa c.-i
cada objeto sensor estar conectado al componente Ua-
ma d a S a l i e n t e y que eso significa que est indirect;
TM
PDF Editor
CAPTULO 11 DISEO AL NIVEL DE COMPONENTE 331
copi ado al mundo exterior y. . . bueno, slo pen-
e compl i caba un poco las cosas,
: Estoy de acuerdo. En este caso, es mej or idea
aue la interfaz del sensor pas e informacin a P a -
>1 y hacer que inicie la l l amada saliente. Ade-
ciferentes sensores podr an dar diferentes nmeros
telefnicos. No quer r s que el sensor al macene es a infor-
macin por que si cambi a
S h a ki r a : No par ece muy adecuado.
Vi n o d : El di seo de la heurstica pa r a acopl ami ent o nos
indica que no es correcto.
S h a ki r a : De todos modos ..
1 1 . 3 C ONDUC C I N DEL P I SEQ AL NI VEL PE COMPONENTES
Al principio de este captulo se observ que el diseo al nivel de component es es de
naturaleza elaborativa. El diseador debe transformar la informacin del anlisis y
los modelos arquitectnicos en una representacin de diseo que proporcione sufi-
ciente detalle para guiar la actividad de construccin (codificacin y prueba). Los si-
guientes pasos representan un conjunto de t areas tpicas para el diseo al nivel de
component es, cuando se aplica a un sistema orientado a objetos.
Pas o 1. Identificar t odas l as cl ases de di seo que corresponden al domi ni o
del probl ema. Usando los model os de anlisis y arquitectnico, cada clase de an-
lisis y component e arquitectnico est elaborado como se describi en la seccin
11. 1. 1.

"ab ajando
: q ue no
' a ob / 'e-
meros tres
aocentran
uto de
de dolos y
nenio
(transfor-
denidos
delmode-
Pas o 2. Identificar t odas l as cl ases de di seo que corresponden al domi -
ni o de la infraestructura. Estas clases no se describen en el model o del anlisis y
a menudo faltan en el modelo arquitectnico, pero deben describirse en este punto.
Como ya se ha indicado, entre las clases y los component es de esta categora se in-
cluyen component es de interfaz grfica de usuario, del sistema operativo, de admi-
nistracin de objetos y datos, y otros.
Pas o 3. Elaborar t odas l as cl ases de di s eo que no s e adqui eran c omo
component es reutil izabl es. La elaboracin requiere que se describan de manera
detallada todas las interfases, los atributos y las operaciones necesarios para imple-
ment ar la clase. Al realizar esta tarea debe t omarse en cuenta el diseo de la heu-
rstica (por ejemplo, la cohesin y el acoplamiento de componentes).
Paso 3a. Especi fi car l os det al l es del mensaj e cuando l as cl ases o l os com-
ponent es col aboran. El model o del anlisis emplea el diagrama de colaboracin
para mostrar la manera en que las clases de anlisis colaboran entre s. A medida
que avanza el diseo al nivel de component es, a veces es til mostrar los detalles de
est as colaboraciones al especificar la estructura de mensaj es que se pasan ent re los
objetos de un sistema. Aunque esta actividad de diseo es opcional, puede usarse
como precursora de la especificacin de interfaces que muestran la manera en que
se comunican y colaboran los component es del sistema.
TM
PDF Editor
Diagrama de
colaboracin
con envo de
mensajes.
TrabajoProduccin
1: construirTrabajo
(nrneroOT)
2: remitirTrabajo
imeroOT)
En la figura 11.6 se ilustra un di agrama si mpl e de col aboraci n para el sistema dz
i mpresi n anal i zado ant es. Tres objetos, TrabajoProducci on, OrdenTrabajo
Col aTrabajo, col aboran para preparar el envo de un t rabaj o de impresin al i - o
de producci n. Los mens aj es se pasan entre obj et os como lo ilustran las flechas s
la figura. Durant e el model ado del anlisis los mensaj es se especifican comc st
muest ra en la figura. Sin embargo, a medi da que avanza el di seo, cada mensa -- -
el abora al expandi r su sintaxis de la siguiente maner a [BEN02],
[condicin guardia] expresin de secuencia (valor devueHo): =
nombre del mensaj e (lisia de argumentos)
donde una [condicin guardia] est escrita en l enguaj e de restriccin de obj et o (CC_
por sus siglas en ingls)4 y especifica cualquier conj unt o de condi ci ones que dehr-
cumplirse ant es de enviar el mensaj e; expresin de secuencia es un valor ent er o (u ccn
indicador de orden, como 3.1.2) que indica el orden secuencial en que se enva JT
mensaj e; (valor devuelto) es el nombr e de la i nformaci n que devuel ve la operacin n
vocada por el mensaj e; nombre del mensaje identifica la operaci n que se invoca y '*-
ta de argumentos) es la lista de los at ri but os que se pasan a la operaci n.
Pas o 3b. Identi fi car l as i nt erf aces apropi adas para cada c ompone nt e . E- =
cont ext o del di seo al nivel de component es, una interfaz UML es un "grupo de cce
raci ones ext er nament e visibles (es decir, pblicas). La interfase no cont i ene es t r _
tura interna; no tiene at ri but os ni asociaciones. . . " [BEB02], Definida de manera r j s
formal, una i nt erfaz es el equi val ent e a una cl ase abst ract a que proporci ona una .
nexin cont rol ada ent r e las cl ases de diseo. La el aboraci n de una interfaz se i -Sj
tra en la figura 11.1. En esenci a, las operaci ones definidas para la clase de di seo es-
t n or denadas en una o ms cl ases abst ract as. Cada operaci n dent ro de la d5e
abst ract a (la interfaz) debe t ener cohesi n; es decir, debe most rar procesamie" a>
que se concent ra en una funcin o subfunci n limitada.
Tomando como referenci a la figura 11.1, podra ar gument ar se que la interfaz rj
ciafTrab ajo no muest ra suficiente cohesi n. En realidad, realiza t res subfunci one? :
4 El OCL se analiza brevemente en la seccin 11.4 y en el captulo 28.
TM
PDF Editor
C A P T U L O 1 1 DI SEO A l NIVEL DE COMPONENTES 333
interfaz
iniciorTrobojo
pQsarTraboioAProduccin( J
Refactorizacin de definiciones de interfases y clases para ImprimiiTrabajo.
calculorTrobajo .
. . . - , . I ' ImprimirTroboio
i n i c i a r l r a b a j o |
pc i nTr a ba j o
ferentes: construir una orden de t rabaj o, revisar la prioridad del t rabaj o y pasar un
t rabaj o a produccin. El di seo de la interfaz debe refactorizar. Un enf oque seria ree-
xami nar las cl ases del di seo y definir una nueva clase OrdenTrabajo que s e ocupa-
ra de t odas las actividades asoci adas con la elaboracin de una orden de trabajo. La
operacin construirOrdenTrab ajo! ) s e vuelve una parte de esa clase. De igual manera,
se podra definir una clase FilaTrabajo que incorporara la operacin revisarPrioridadl).
Una clase TrabajoProducci on abarcara toda la informacin asociada con un t rabaj o
de produccin que se pasar a la planta de produccin. La interfaz iriciarTYab ajo to-
mara ent onces la forma most rada en la figura 11.7. Ahora esta interfase es cohesiva,
y se concent ra en una sola funcin. Las interfaces asoci adas con TrabajoProduc-
ci on, OrdenTrabajo y FilaTrabajo tienen una sola funcin.
Pas o 3c. El aborar atri butos y defi ni r l os t i pos y l as est ruct uras de dat os ne-
ces ari os para i mpl ement arl os. En general, las est ruct uras y los tipos de dat os con
que se descri ben atributos se definen dent ro del cont ext o del l enguaj e de programa-
cin que habr de usar se para la i mpl ement aci n. UML defi ne el tipo de dat os de un
at ri but o empl eando la siguiente sintaxis:
nombre : tipo-expresin = valor-inicial {propiedad cadena}
donde nombre es nombr e del atributo y tipo-expresin es el tipo de datos; valor-inicial es
el valor que t oma el at ri but o cuando se crea un obj et o y propiedad cadena defi ne una
propi edad o caracterstica del atributo.
Durant e la pri mera iteracin de di seo al nivel de component es, los atributos sue-
len describirse por nombre. Tomando como referencia una vez ms la figura 11.1, la
lista de at ri but os de Trabaj ol mprent a sl o incluye los nombr es de los atributos; sin
embar go, a medi da que avanza la el aboraci n del diseo, cada at ri but o se define
empl eando el format o de at ri but os UML indicado. Por ej empl o, Tipo-pesoPapel se de-
fine de la siguiente manera:
Tipo-pesopapel: sfring = "A"{contiene 1 de 4 valores: A, B, C o D}
TM
PDF Editor
que define Tipo-pesopapel como una variable de cadena variable inicializada con el . i
lor A y que t oma uno de cuat ro valores del conj unt o |A,B,C,D).
Si un atributo aparece varias veces en varias clases de diseo, y tiene una estru:
tura relativamente compleja, es mejor crear una clase separada para acomoda: s
atributo.
Pas o 3- D. Describir de manera detal l ada el flujo de proces ami ent o dentr:
de cada operaci n. Esto se logra empl eando un seudocdigo basado en un \t~-
guaje de programacin (seccin 11.5.5) o el diagrama de actividad UML. Cada c c a -
ponent e de soft ware se elabora medi ant e varias interacciones que aplican el e x-
cepto de refinamiento paso a paso (captulo 9).
La primera iteracin define cada operacin como parte de la clase de diseo, z x
cada caso, la operacin debe est ar caracterizada de manera que asegure una core-
sin elevada; es decir, la operacin debe realizar una sola funcin o sustitucin i r
finida. La siguiente iteracin hace poco ms que expandir el nombre de la oper ao :r
Por ejemplo, la operacin calcularCostoPapel() observada en la figura 11.1 se expar
dira de la siguiente manera:
calcularCostoPapel (peso, tamao, color): numrico
Esto indica que calcularCostoPapel/ ) requiere los atributos peso, tamao y cok*
ent rada y devuelve un valor numri co (en realidad un valor en pesos) como sa-ioi
"De hober t eni do m s t i empo, hobr i a escrito uno cari o m s cor t a. "
Bl as
( CONSEJ O^
La elab oracin se usa
paso a paso mientras
se refino el dise o del
componente. Siempre
deb e preguntarse:
"Hay una manera de
simplificar esto mien-
tras sigue arrojando el
mismo resultado? "
Si el algoritmo requerido para i mpl ement ar calcularCostoPapel() es simple i
comprende ampliamente, tal vez sea innecesario elaborar diseo adicional. Ei r d
niero de soft ware responsable de la codificacin proporcionar el detalle n e c e s a B
para implementar la operacin. Sin embargo, si el algoritmo es ms comple : a
creto, se requiere mayor elaboracin de diseo en esta etapa. En la figura I i
describe un diagrama de actividad UML para calcularCostoPapel(). Cuando se
plean di agramas de actividad para especificacin de diseo al nivel de coi
tes, suel en represent arse en un nivel de abstraccin un poco ms el evado que a a
digo fuente. Ms adelante, en est e mi smo captulo, se analizar un mt odo
el uso de seudocdigo para especificar el diseo.
1
Paso 4. Descri bi r f uent es de dat os persi st ent es ( bases de dat os y ;
e identificar l as cl as es neces ari as para manejarl as. Las bases de datos y - - a
chivos suelen trascender la descripcin del diseo de un component e indiv
casi t odos los casos estos al macenes de dat os persistentes suelen especifica
cialmente como parte del diseo arquitectnico. Sin embargo, a medida que ai
la elaboracin del diseo, a veces resulta til proporcionar detalles adicionales ai
estructura y organizacin de estas fuent es de dat os persistentes.
os y o *
livjcka_fl
f i c a n e f l
TM
PDF Editor
Pas o 5. Desarrol l ar y el aborar repres ent aci ones del c ompor t ami e nt o de
una c l as e o un c ompone nt e . Los di agr amas de est ado UML s e usaron como par-
te del model o de anl i si s para represent ar el compor t ami ent o del si st ema que se ob-
serva ext er nament e y el compor t ami ent o m s localizado de cl ases individuales de
anlisis. Durant e el di seo al nivel de component es, suele ser necesari o model ar el
compor t ami ent o de una clase de diseo.
Al compor t ami ent o di nmi co de un obj et o (la instanciacin de una clase de dise-
o mi ent ras se ej ecut a el programa) lo afect an event os ext ernos y el est ado act ual
del obj et o (modo o comport ami ent o). Para compr ender el compor t ami ent o dinmi-
co de un objeto, el di seador debe exami nar t odos los casos de uso rel evant es du-
rant e el peri odo de vida de la clase de diseo. Estos casos de uso proporci onan in-
formaci n que ayuda al di seador a del i near los event os que afect an al obj et o y a los
est ados en que reside st e mi ent ras pasa el t i empo y ocurren los event os. La transi-
Diagrama de actividad UML para calcutarCostoPapeH ).
TM
PDF Editor
cin ent re est ados (impulsados por los eventos) se represent an empl eando una g a
fica de est ado UML [BEN02] como se ilustra en la figura 11.9.
La transicin de un est ado (represent ado por un rect ngul o con esqui nas rec n
deadas) a ot ro ocurre como consecuenci a de un event o que t oma esta forma
nombre-evento (lista-parametros) [condicion-guardia] / expresin de accin
donde nombre-evento identifica el event o; lista-parametros i ncorpora dat os a
con el event o; condicin-guardia est escrita en l enguaj e de restriccin de obj et o
y especifica una condicin que debe cumplirse ant es de que pueda ocurrir el
to, y expres i n de acci n define una accin ant es de que ocurra cuando t i c t
gar la transicin.
Tomando como referencia la figura 11.9, cada est ado puede definir acciones
irada/ y salida/ que ocurren mi ent ras se pr esent an las t ransi ci ones de ent rada >
lida. En casi t odos los casos, est as acci ones corresponden a operaci ones rele\
para la clase que se est model ando. El indicador h acer/ proporciona un mecanisr-
ra indicar las actividades que ocurren mi ent ras se encuent r a en el est ado, y e -.mj
cador incluir/ proporci ona un medi o para el aborar el compor t ami ent o al i n e r v a
ms detalle en la grfica de est ado dent ro de la definicin de un est ado.
.
Fragmento de diagrama de estado para la clase Trabajolmprenta.
entradaDatosIncompletos
1
Comportamiento dentro del
estado construirDatosTrabao
construirDatosTrabajo
entrar/leerDatosTiabajof)
salir/desplegarDatosTrabao( |
hacer/revisarConsistenciaf)
. incluir/entradoDotos ..
entradaDatosCompletada (todos los elementos de datos T
consstentes)/desplegarOpconesUsuario T
calcula rCostoTrabajo
entrar/cacularTrabao
solir/guordar costoTotafTrabajo
costoTrabajoAceptado (el cliente est autorizado)
/oblenerFirmaElectronica
formarTrabojo
entrar/construirTrabajo
salir/guardar nmeroOT
hacer/
fechaEntregaAceptada (el cliente est autorizado)/
estimadoTrabajolmpresion
remitirTrabao
entrar/remitirTrabojo
salir/iniciarTrabajo
hacer/colocar en ColaTrabajo
trabajoRemitido (todas las autorizaciones adquiridas)/
imprimirOrdenTrabajo
TM
PDF Editor
Es importante observar que el model o de component es a menudo contiene infor-
macin que no resulta i nmedi at ament e obvia en otros de component es de diseo.
Por ejemplo, el cuidadoso examen de la grfica de estado de la figura 11.9 indica que
el comportamiento dinmico de la clusula Trabajol mprenta depende de dos apro-
baci ones del cliente, derivadas de los dat os de costos y la calendarizacin del traba-
jo de impresin. Sin aprobaci ones (la condicin guardia asegura que el cliente tiene
autorizacin para aprobar) no se remitir el t rabaj o de impresin porque no hay ma-
nera de alcanzar el est ado remitiiTrab ajo.
Pas o 6. Elaborar di agramas de despl i egue para proporci onar det al l es de la
i mpl ement aci n adicional . Los di agramas de despliegue (captulo 9) se usan co-
mo part e del diseo arquitectnico y se representan en forma de descriptor. As, se
representan las principales funciones del sistema (a menudo represent adas como
subsistemas) dentro del contexto del ent orno de cmput o que las albergar.
Durante el di seo al nivel de component es pueden elaborarse di agramas de des-
pliegue para representar la ubicacin de paquet es clave de component es. Sin embar-
go, por lo general los component es se representan individualmente dent ro de un
diagrama de component e. La razn de est o es evitar la complejidad del diagrama.
En algunos casos, los di agramas de despliegue se elaboraron en forma de instancias.
Esto significa que el hardware especfico y el o los ent ornos del sistema operativo
que se usarn son especficos y que se indica la ubicacin de los paquet es de com-
ponent es dentro de est e entorno.
Pas o 7. Factorizar t odas l as represent aci ones del di seo al nivel de compo-
nent es y si empre deben consi derarse al ternativas. A lo largo del libro se ha
dest acado que el di seo es un proceso iterativo. El primer modelo al nivel de com-
ponent es que se cree no ser tan completo, consistente o exacto como la ensima
iteracin que aplique al modelo. Es esencial usar la refactorizacin mientras se rea-
liza el trabajo de diseo.
Adems, un diseador no debe tener una visin estrecha. Siempre hay soluciones
opcionales para el diseo, y los mejores diseadores t oman en cuenta todas (o casi
todas) ant es de definir el modelo de diseo final. Desarrollan opciones y examinan
cada una de manera cuidadosa, empl eando los principios del diseo y los concept os
present ados en los captulos 5, 9 y 11.
La amplia variedad de diagramas disponible como parte de UML proporciona a un
diseador un rico conj unt o de formas de representacin para el model o de diseo.
Sin embargo, las representaciones grficas no suelen bastar. El diseador necesita
un mecani smo para representar explcita y formalmente la informacin que restringe
algn el ement o del modelo de diseo. Es posible, por supuesto, describir restriccio-
nes en un lenguaje natural, pero este mt odo lleva invariablemente a la inconsisten-
TM
PDF Editor
\
CLAVE
El OCL proporciono gra-
mtico y sintaxis for-
males paro descfibir los
elementos de diseo ol
nivel de componentes.
cia y la ambi gedad. Por t ant o, lo apropi ado par ece un l enguaj e ms formal, que la-
me en cuent a la teora de conj unt os y los l enguaj es formal es de especificacin (ca-
ptulo 28), per o que t enga una cant i dad menor de sintaxis mat emt i ca que un le~
guaj e de programaci n.
El lenguaje de restriccin de ob jetos (OCL) compl ement a al UML al permitir que
ingeniero de sof t war e use gramt i ca y sintaxis formal es para construir i nst rucci n; ;
sin ambi gedades rel aci onadas con varios el ement os del model o de di seo (p -
ej empl o, cl ases y objetos, event os, mensaj es, interfaces). En el OCL las instrucciones
se const ruyen en cuat ro partes: 1) un cont ext o que defi ne la situacin limitada
que es vlida la instruccin; 2) una propiedad que represent an al gunas caracters:
cas del cont ext o (por ejemplo, si el cont ext o es una clase, una propiedad sera
atributo); 3) una operacin (aritmtica, ori ent ada a conjuntos) que mani pul a o cal:
ca u na pr opi edad, y 4) palab ras clave ( como f, then, else, and, or, not, mples) con
se especi fi can expresi ones condicionales.
Como ej empl o simple de una expresi n OCL, consi drese la condicin guardia
l ocada en el event o costoTrab ajoAceptado que causa una transicin entre los es '
cal cul arCost oTrabaj o y formarTrabajo dent ro del di agrama de grfica de
para la clase Trabaj ol mprent a (figura 11.9). En el di agrama, la condicin gu
se expresa en l enguaj e nat ural y especifica que la aut ori zaci n sl o se presentara
el cliente est aut ori zado par a aprobar el cost o del trabajo. En el OCL, la expr
t omar a la forma:
cliente
tiene.autoridadAutorizacin = "si"
donde un at ri but o bool eano, autoridadAutorizacin, de la clase Cl i ente (en realidad
i nst anci a especfica de la clase) debe t ener el valor si para satisfacer la cond:
guardia.
Cuando se crea el model o de di seo suel e haber i nst anci as (consulte la sec
1 1 . 2 . 1 ) en que deben sat i sfacerse las condi ci ones previas y post eri ores ant es
compl et ar al guna opcin especificada en el diseo. El OCL proporci ona una
mi ent a poderosa para especificar condi ci ones previas y post eri ores de maner a
mal. Como ej empl o, pi ense en una ext ensi n al si st ema de la i mprent a (anal i za; :
lo largo de este captulo) en que el cliente proporci ona un lmite de cost o sup
para el t rabaj o de impresin y una fecha de ent r ega lmite, al mi smo t i empo que
especifican ot ras caract er st i cas del trabajo. Si el cost o y la ent rega est i mada
den esos lmites, el t rabaj o no se ent regar y debe notificarse al cliente. En el
un conj unt o de condi ci ones previas y post eri ores se especificara de la siguiente
era:
context Trabajolmprenta::validate(limiteSuperiorCosto : Integer, reqEnvioCliente :
Integer)
pre: limeSuperiorCosto > 0
TM
PDF Editor
339
and reqEnvioCliente > 0
and t i ene. aut ori zaci onTrabaj o = "no"
pos t : if t i ene. cost oTot al Trabajo < = l i mi t eSuperi orCost o
and t i ene. fechaEnvi o < = reqEnvioCliente
t hen
t i ene. aut ori zaci onTrabaj o = "si"
endif
Es t a d e c l a r a c i n OCL d e f i n e u n a i n v a r i a n t e ( c o n d i c i o n e s q u e d e b e n exi s t i r a n t e s [pre]
y d e s p u s [post ] d e a l g n c o mp o r t a mi e n t o ) . Al pr i nc i pi o, ia c o n d i c i n p r e v i a e s t a b l e c e
q u e el c l i e n t e d e b e e s p e c i f i c a r el c o s t o l mi t e y l a f e c h a d e e n t r e g a , y q u e l a a u t o r i z a -
c i n d e b e e s t a r e n " no" . De s p u s d e d e t e r mi n a r l o s c o s t o s y la f e c h a d e e n v o , s e a pl i -
c a l a c o n d i c i n p o s t e r i o r . T a mb i n d e b e t o ma r s e e n c u e n t a q u e l a e x p r e s i n t i ene. au-
torzacionTrabajo = "si" n o e s t a s i g n a n d o el v a l o r "s "; e n c a mb i o , e s t d e c l a r a n d o q u e
auforizacionTrabajo d e b e t e n e r el v a l o r "s " e n el m o m e n t o e n q u e t e r mi n e l a o p e r a c i n .
Un a d e s c r i p c i n c o mp l e t a de l OCL e s t m s a l l d e l a l c a n c e d e e s t e l i br o. 5 Lo s
l e c t o r e s i n t e r e s a d o s d e b e n c o n s u l t a r [ WAR98] y [ OMGOl ] p a r a c o n o c e r d e t a l l e s a d i -
c i o n a l e s .
HE RRAMI E NT AS DE SOFTWARE
UML/OCL
Obj e t i vo: Existe una amplia variedad de he-
rramientas UML par a ayudar al di seador en
las et apas del diseo. Algunas de estas herramientas
~cionan soporte al OCL.
ni c a: Las herramientas de esta categora permiten a
r seador crear todos los di agr amas de UML necesa-
para construir un modelo de diseo completo. Lo ms
ante es que muchas herramientas proporcionan una
s y una semntica slidas, verificacin y manej o de
de versin y cambios (captulo 27). Cuando se pro-
a capaci dad de OCL, las herramientas permiten
el di seador cree expresiones OCL y, en algunos ca-
os "compile" par a varios tipos de evaluacin y
:sis.
He r r a mi e nt a s r e pr e s e nt a t i v a s 6
ArgoUML, distribuido por Tigress.org (http://argouml. ti-
gris. org/), da soporte a UML y OCL completo, e inclu-
ye vari as herramientas de ayuda par a el diseo, que
van ms all de la generacin de di agramas UML y ex-
presiones OCL.
Dresden OCL toolkit, desarrollado por Frank Finger en la
Universidad Tecnolgica de Dresden (ht t p: / / dresden-
ocl-sourceforge.net/), es un juego de herramientas ba-
sada en un compilador OCL que abar ca varios
mdulos que anal i zan, revisan el tipo y normalizan las
restricciones OCL.
OCL parser, desarrollado por IBM (ht t p: / / www3. i bm. com-
/ soft ware/ ad/ l i brary/ st andars/ OCL-downl oad. ht ml ),
est escrito en Java y est disponible gratuitamente pa-
ra la comuni dad orientada a objetos con el fin de que
se estimule el uso de OCL con model adores UML.
5 Sin embargo, en el captulo 29 se present ara una exposicin m s amplia del OCL (present ada en el
cont ext o de los mt odos formales).
6 Las her r ami ent as menci onadas aqu represent an una muest r a de esta categora. En casi t odos los
casos los nombr es de l as mi smas son mar cas registradas de sus respect i vos desarrol l adores
TM
PDF Editor
340 PARTE DOS PRCTICA DE LA INGEMERA DEL SOFTWARE
\
CLAVE
Lo programacin es-
tiucturodo es una tcni-
ca de diseo que res-
tringe el flujo de la l-
gica a tres construccio-
nes: secuencia, condi-
cin y repeticin.
Los f undament os del di seo al nivel de component es para component es convena
nal es de soft ware7 se integraron a principios de la dcada de 1960 y adquirieron s o -
lidez con el t rabaj o de Edsgar Dijkstra y sus col egas ([BOH66], [DIJ65], [DIJ76]). A *
nal es de esos aos, Dijkstra y ot ros propusi eron el us o de un conj unt o de const ru:
ci ones lgicas restringidas, a partir de las cual es se pudi era formar cualquier prog-3
ma. Las const rucci ones dest acaban el "mant eni mi ent o del domi ni o funcional"
decir, cada const rucci n t en a una est ruct ura lgica predecible, a la que se ingresa-
ba en la part e superi or y se abandonaba en la inferior, lo que permita al lector s<
guir con mayor facilidad el flujo del procedi mi ent o.
Las const rucci ones son secuenci a, condicin y repeticin. Secuencia i mpl emer
los pasos de pr ocesami ent o esenci al es en la especificacin de cualquier a l gont -
Condicin proporci ona las f unci ones para el pr ocesami ent o sel ecci onado con basr
en algn event o lgico, y repeticin permi t e los bucles. Estas tres const rucci ones >
f undament al es para la programaci n est ruct urada, que es una i mport ant e tcnica
di seo al nivel de component es.
Las const rucci ones est ruct uradas se propusi eron para restringir el di seo pr cc^
dimental del soft ware a un nmer o pequeo de operaci ones. La complejidad de
mt ri cas (captulo 15) indica que el us o de las const rucci ones est ruct uradas
la complejidad del pr ogr ama y, por t ant o, mej ora las opci ones de lectura, pruebe
mant eni mi ent o. El us o de un nmer o limitado de const rucci ones lgicas tar
contribuye a un proceso de comprensi n humana que los psiclogos llaman
mentacin. Para compr ender est e proceso, pi nsese en la maner a en que est le
do esta pgina. No se leen l et ras individuales si no que se reconocen pat rones o \
pos de pal abras o frases f or mados por vari as letras. Las const rucci ones estruc
das son grupos lgicos que le permi t en a un lector reconocer el ement os pr
ment al es de un mdul o, en lugar de leer el di seo o cdi go lnea por lnea. La i
prensi n se mej ora cuando hay pat r ones lgicos fci l ment e reconocibles.
11.5.1 Notacin grfi ca del di seo
Ya se ha anal i zado el di agr ama de actividad UML en est e captulo y en los capir
7 y 8. El di agr ama de actividad permi t e a un di seador represent ar secuenci a,
dicin y repeticin (todos el ement os de la programaci n estructurada) y es el
cendi ent e de una represent aci n de di seo grfico ant eri or (an usado ampliar
te) l l amado diagrama de flujo.
Un di agrama de flujo, como uno de actividad, es muy si mpl e grfi cament e
di amant e represent a una condi ci n lgica, y las flechas muest r an el flujo de cc
Un component e de sof t war e convenci onal i mpl ement a un el ement o de pr ocesami ent o que <
una funci n o subfunci n en el domi ni o del probl ema, o al guna capacidad en el domi ni o de ; i
fraestructura. A menudo denomi nados mdulos, procedimientos o subrutinas, los component esc
venci onal es no encapsul an dat os de la mi sma maner a que los component es ori ent ados a ob| r
TM
PDF Editor
d e
Part e si no (else)
Secuencia
Seleccin
Par l e ent onces (then)
si-entonces-si_no (interfaz-then-else)
Mi ent r as hacer (do while) Repetir hast a ( r epeat until)
Repeticin
COMSCJO.
En la figura 11.10 se ilustran tres const rucci ones estructuradas. La secuencia se re-
present a como dos caj as de procesami ent o conect adas por una lnea (flecha) de con-
trol. La condicin, tambin llamada si-entonces-si_no, se describe como un di amant e
de decisin que, si es verdadero, causa que ocurra la part e-ent onces del procesa-
miento, y si es falso, invoca la part e si_no. La repeticin se represent a empl eando dos
formas ligeramente diferentes. La part e hacer mientras prueba una condicin y eje-
cuta una tarea de bucle de maner a repetitiva, si empre y cuando la condicin siga
si endo verdadera. Una part e repetir hasta ejecuta primero la tarea de bucle, luego
prueba una condicin y repite la tarea hast a que la condicin falla. La construccin
de seleccin (o seleccionar-caso) que muestra la figura es en realidad una extensin de
si-entonces-sLno. Sucesivas deci si ones prueban un parmet ro hast a que ocurre una
condicin verdadera y se ejecuta la ruta de procesami ent o de la parte de caso.
En general, el uso dogmt i co y exclusivo de las const rucci ones est ruct uradas in-
troduce ineficiencia cuando se requiere un escape de un conj unt o de bucl es ani da-
dos o de condi ci ones ani dadas. Lo que es ms importante, la complicacin adicional
de t odas las pruebas lgicas j unt o con la ruta de escape llega a oscurecer el flujo de
control del soft ware, aument a la posibilidad de error y tiene un impacto negativo en
la legibilidad y la capacidad de mant eni mi ent o. Qu podemos hacer?
Se le dej an dos opci ones al diseador: 1) se redisea la representacin procedi-
mental para que la "rama de escape" no sea necesari a en una ubicacin ani dada del
flujo de control, o 2) se violan las const rucci ones est ruct uradas de una maner a con-
trolada; es decir, se di sea una rama restringida fuera del flujo anidado. La opcin 1
es obvi ament e el enfoque ideal, pero la 2 puede acomodar se sin infringir el espritu
de la programaci n est ruct urada.
TM
PDF Editor
^ ONSEJ O ^
Debe iisorse una tobla
de decisin cuando un
conjunto complejo de
condiciones y acciones
se encuentran dentro
de un componente.
11.5.2 Notacin tabular del diseo
En muchas aplicaciones de software tal vez se requiera un mdulo para evaluar
combinacin compleja de condiciones y seleccionar las acciones apropiadas
das en esas condiciones. Las tablas de decisin [HUR83] proporcionan una n"
que traduce acciones y condiciones (descritas en una narrativa de procesamien:
una forma tabular. Es difcil malinterpretar una tabla, y hasta puede usarse como
trada legible para una mqui na a un algoritmo orientado a tablas.
Una tabla de decisin se divide en cuatro cuadrantes. El de la esquina superic
quierda contiene una lista de todas las condiciones. El cuadrante de la esquina :
izquierda contiene una lista de t odas las acciones posibles, basada en comb:
nes de condiciones. Los cuadrant es de la derecha forman una matriz que
combinaciones de condicin y las acciones correspondientes que ocurrirn para una
binacin especfica. Por tanto, cada columna de la matriz puede interpretarse
una regla de procesamiento. Los siguientes pasos se aplican para desarrollar u-3
bla de decisin.
1. Presentar una lista de t odas las acciones que puedan asociarse con un
dimiento (o mdulo) especfico.
2. Presentar una lista de todas las condiciones (o decisiones tomadas) du
ejecucin de un procedimiento.
3. Asociar conj unt os especficos con acciones especficas, eliminando c
ciones especficas de condiciones; como opcin, desarrllese cada posir s
permutacin de las condiciones.
4. Definir reglas al indicar cules acciones ocurren para un conjunto de
ciones.
Para ilustrar el uso de una tabla de decisin, pinsese en el siguiente ext rac. :
caso de uso informal que se ha propuesto para el sistema de la imprenta:
Tres tipos de clientes est n definidos: un cliente regular, uno de pl at a y uno de or
tipos se asi gnan segn la cantidad de negoci os que el cliente realiza con la i mprerzi
un peri odo de 12 meses). Un cliente regular recibe precios de impresin y fechas de
ga normal es. Un cliente de plata obtiene un descuent o de 8 por ci ent o sobre todas :
t i zaci ones y se coloca adel ant e de los clientes regul ares en la cola de impresin. Ur
de or o obt i ene una reduccin del 15 por ciento sobre los precios cot i zados y se coloca
lante de los clientes regulares y de plata en la cola de trabajo. Es posible aplicar i
cuent o especial de x por cent aj e adicional a los ot ros descuent os a la cot i za: r e
cualquier cliente, a discrecin de la administracin.
En la figura 11.11 se ilustra una representacin de una tabla de decisin
nada con el anterior caso de uso informal. Cada una de las seis reglas indica
las seis condiciones viables. Como regla general, la tabla de decisin se u; ;
era efectiva para complementar otras notaciones de diseo procedimenta.
TM
PDF Editor
Re g l a s
Co ndi c i o ne s 1 2 3 4 5 6
Cliente regular V( T) V (T)
Cliente plata V (T) V (T)
Cliente oro
V (T) V( T)
Cliente especi al
F V (T) F V (T) F V( T)
Ac c i one s
Sin descuent o

Aplicar 8 por ciento de descuent o
Aplicar 15 por ciento de descuent o
Aplicar x por cent aj e de descuent o
adi ci onal
dea usar su
de ptoy ama-
base pato
osepue-
. un esq ue-
cdigo
: con tex to
mientras se
el dise o.
11.5.3 Lenguaje de di seo de programas
El lenguaje de dise o de programas (PDL, por sus siglas en ingls), tambin denomi-
nado lenguaje comn estructurado o seudocdigo, es "un lenguaje rudimentario por-
que utiliza el vocabulario de un idioma (como el ingls) y la sintaxis general de otro
(es decir, un lenguaje estructurado de programacin)" [CAI75], En este captulo, PDL
se usa como referencia genrica para un lenguaje de diseo.
A primera vista, PDL parecera un lenguaje de programacin. La diferencia entre
PDL y un lenguaje de programacin real radica en el uso de texto narrativo (como el
ingls) incrustado directamente dentro de las instrucciones en PDL. Dado el uso de
texto narrativo incrustado directamente en una estructura sintctica, no es posible
compilar PDL. Sin embargo, al gunas herrami ent as pueden traducirlo en un "esque-
leto" de lenguaje de programacin, en una representacin grfica de diseo, o en
ambas (por ejemplo, un diagrama de flujo). Estas herramientas tambin producen
mapas de anidamiento, un ndice de operacin de diseo, tablas de referencia cru-
zada y otra informacin diversa.
Un lenguaje de diseo de programas puede ser una simple transposicin de un
lenguaje como Ada, C o Java. La sintaxis bsica de PDL debe incluir construcciones
para definicin de componentes, descripcin de interfaces, declaracin de datos, es-
tructuracin de bloques y construcciones de condiciones, de repeticin y de entra-
da/ sal i da. Debe t omarse en cuenta que PDL puede extenderse para incluir palabras
clave para multitareas, procesami ent o concurrente (o ambas opciones), manej o de
interrupciones, sincronizacin de interprocesos y muchas otras caractersticas. El di-
seo de la aplicacin para la que se est usando PDL debe dictar la forma final del
lenguaje de diseo. El formato y la semntica de algunas de estas construcciones de
PDL se presentan en el ejemplo siguiente.Para ilustrar el uso de PDL, consideramos
un diseo procedimental para la funcin de seguridad HogarSeguro analizada en ca-
ptulos anteriores. El sistema supervisa las al armas para detectar fuego, humo, robo,
TM
PDF Editor
344
agua y temperatura (por ejemplo, rompimiento del horno cuando el propietario esu
ausent e en el invierno), produce un timbre de alarma y llama a un sistema de mor
tores, generando un mensaj e de voz sintetizado. En el PDL siguiente ilustramos a
gunas de l as construcciones importantes anot adas en secciones anteriores.
Recuerde que PDL no es un lenguaje de programacin. El diseador puede adar
tarlo como se requiera sin preocuparse por errores de sintaxis. Sin embargo, el dise
o del soft ware de supervisin tendra que revisarse (se observa algn problema'
y refinarse ant es de que pueda escribirse el cdigo. El siguiente PDL8 proporci or.
una elaboracin del diseo procedimental para una versin anterior de un comp
nent e de manej o de alarmas.
component e manej oAl arma
El obj et i vo de e s t e component e e s manej ar los i nt errupt ores y las ent r adas del panel 3
cont rol a partir de los s ens or es por el t i po y act uar en cualquier condi ci n de alarma a.M
sea encont r ado.
est abl ecer val ores por def ect o para est at usSi st ema (valor devuel t o), t odos l os elemer-
t os de dat os
inicializar t odos l os puer t os del si st ema y reiniciar t odo el hardware
revisar i nt errupt oresPanel Cont rol (pe)
si ipc = "probar" ent onces invocar alarma fijar en "encendi do"
si ipc = "al armaApagado" ent onces invocar alarma fijar en "apagado"
valor por def ect o ipc = ni nguno
rest abl ecer t odo val oresSeal e i nt er r upt or es
hacer para t odos los s ens or es
invocar verificar-Sensor procedi mi ent o regresa valorSeal
si valorSeal > lmite [tipoAlarma]
ent onces t el ef ono. mens aj e = mens a j e [tipoAlarma]
fijar timbreAlarma en "encendi do" para al armaTi empoSegundos
fijar es t at us si st ema = "condicinAlarma"
parempi eza
procedi mi ent o alarma con "encendi do", al armaTi empoSegundos
invocar procedi mi ent o t el f ono fijar en tipoAlarma, nmeroTelfono
part ermi na
si no omitir
t ermi na si
t ermi na hacer par a
t ermi na manej oAl arma
8 El nivel de detalle que representa el PDL se define localmente. Algunas personas prefieren ur.;
cripcin orientada al lenguaje ms natural, mientras que otras prefieren algo ms parecido a
digo.
TM
PDF Editor
C A P T U L O 1 1 DISEO AL NIVEL DE COMPONENTES 3 4 5
Obsrvese que el diseador del component e de manej o de al arma ha usado las cons-
trucciones parempiezapartermina que especifica un bloque paralelo. Todas las t areas
especificadas en el bloque parempieza se ej ecut an en paralelo. En este caso, no se to-
man en cuent a los detalles de implementacin.
Lenguaje de diseo de programas
Obj e t i vo: Aunque la inmensa mayora de los
ingenieros de software que usa PDL o seudoc-
oesarrolla una versin que se adapt a del lenguaje de
cin que tratan de emplear par a la implemento-
existen varias herramientas de PDL.
i ca: En algunos casos, las herramientas aplican
i inversa al cdi go fuente (una triste realidad en
: donde algunos programas no tienen absoluta-
l i nguna documentacin). Otros permiten al disea-
r-sor PDL con una ayuda aut omat i zada.
entas represent at i vas9
desarrollado por Caine, Farber y Gordon
p: / / www. cfg. com/ pdl 81 /Ipd.html), da soporte a la
N
creacin de diseos con el uso de una versin definida
de PDL.
DocGen, distribuido por Software Improvment Gr oup
(ht t p: / / www. soft ware-i mprovers. com/ DocGen. ht m),
es una herramienta de ingeniera inversa que gener a
document aci n par eci da a PDL a partir de cdi go
Ada y C.
PowerPDL, desarrollado por Iconix (http://www.iconixsw.
com/SpecSheets/PowerPDL.html), le permite a un dise-
ador crear PDL basado en diseos y luego traducir el
seudocdigo a formas que puedan gener ar otras re-
presentaciones de diseo.
11.5.4 Comparaci n entre notaci ones de di seo
La notacin de diseo debe llevar a una representacin procedimental fcil de com-
prender y revisar. Adems, la notacin debe mej orar la capacidad de "codificar en" pa-
ra que el cdigo, en realidad, se convierta en un subproducto natural del diseo. Por
ltimo, la representacin de diseo debe tener la capacidad de darle mant eni mi ent o
fcilmente para que el diseo siempre represente el programa de manera correcta.
Una pregunta natural que surge en cualquier anlisis de la notacin de diseo se-
ra: Cul notacin es real ment e mejor, dados los atributos indicados lneas antes?
Cualquier respuesta es subjetiva y est abierta al debate. Sin embargo, parece que el
lenguaje de diseo de programas ofrece la mejor combinacin de caractersticas. El
PDL puede incrustarse directamente en los listados de cdigo fuente, mej orando la do-
cumentacin y facilitando ms el mant eni mi ent o del diseo. La edicin se hace en
cualquier editor de texto o sistema de procesami ent o de palabras, ya existen procesa-
dores automticos, y la posibilidad de "generacin aut omt i ca de cdigo" es buena.
Sin embargo, de est o no se desprende que cualquier otra notacin sea necesari a-
ment e inferior a PDL, o que "no sea buena" en atributos especficos. La nat ural eza
9 Las her r ami ent as expuest as aqu el aut or no las respal da: sl o represent an una muest r a de las he-
rrami ent as incluidas en est a categoria. En casi t odos los casos, los nombr es de l as her r ami ent as son
mar cas registradas de sus respect i vos desarrol l adores
TM
PDF Editor
346
grfica de los diagramas de actividad y los de flujo proporciona una perspectiva s
bre el flujo de control que muchos di seadores prefieren. El contenido tabular pre-
so de las tablas de decisin es una herramienta excelente para aplicaciones orierv:
das a tablas. Y muchas otras representaciones de diseo (por ejemplo, nidos de r :
tri), no presentados en este libro, ofrecen sus propios beneficios nicos. En el a r ;
sis final, la eleccin de una herramienta de diseo estar relacionada de manera
estrecha con factores humanos que con atributos tcnicos.
La accin de diseo al nivel de component es abarca una secuencia de t areas que
ducen lentamente el grado de abstraccin con que se representa el software E
seo al nivel de component es describe finalmente el soft ware en un grado de
traccin cercano al cdigo.
Es posible t omar dos enfoques distintos de diseo al nivel de componentes, i: .
depende de la naturaleza del soft ware que habr de desarrollarse. El concepto <
tado a objetos se enfoca en la elaboracin de clases de diseo que provienen
del problema como del dominio de la infraestructura. El concept o convenci n
fina tres tipos principales de component es o mdulos: de control, de domiir :
problema y de infraestructura. En ambos casos se aplican principios bsicos de
seo y conceptos que llevan a soft ware de mayor calidad. Cuando se considera
de un punt o de vista del proceso, el diseo al nivel de component es se basa er
ponent es de software reutilizables y en pat rones de diseo que son elementos ;
te de la ingeniera de software basada en componentes.
El diseo al nivel de component es orientado a objetos se basa en clases."
principios y conceptos importantes guan al diseador a medida que se elabora - J
clases. Principios como el principio abierto-cerrado y el de inversin de la dep
cia, adems de conceptos como acoplamiento y cohesin, guan al ingeniero dt :
ware en la construccin de component es de soft ware susceptibles de probars--.
plementarse y mant enerse. Para realizar diseo al nivel de component es e~
contexto, las clases se elaboran al especificar detalles de los mensajes, identif
terfaces apropiadas, elaborar atributos y definir estructuras de dat os para imp
tarlos, describir el flujo de procesamiento dentro de cada operacin y repres
comport ami ent o en un nivel de clase o componente. En t odo caso, la iteracir
seo es una actividad esencial.
El diseo al nivel de component es convencional requiere la representacin
tructuras de datos, interfaces y algoritmos para un mdulo de programa con i
lie suficiente para servir como gua en la generacin de cdigo fuente en leng
programacin. Para lograr esto, el diseador usa una de varias notaciones
o que representan detalles al nivel de component es en formatos grficos,
o de texto.
TM
PDF Editor
La programacin estructurada es una filosofa de diseo procedimental que res-
tringe el nmero y tipo de construcciones lgicas para representar el detalle del al-
goritmo. El objetivo de la programacin estructurada es ayudar al diseador a defi-
nir algoritmos que sean menos complejos y, por tanto, ms fciles de leer, probar y
mantener.
[AMB02] Ambler, S., "UML Component Diagramming Guidelines", disponible en ht t p: / / www. mo-
delingstyle. info/, 2002.
[BEN02] Bennett, S., S., McRobb y R. Farmer, Object-Oriented Analy sis and Design, 2a. ed., Mc-
Graw-Hill, 2002.
[BOH661 Bohm, C. y G. Jacopini, "Flow Diagrams, Turing Machines and Languages with Only
Two Formation Rules", en CACM, vol. 9, nm. 5, mayo de 1966, pp. 366-371.
[CAI75] Caine, S. y K. Gordon, "PDLA Tool for Soft ware Design", en Proc. National Computer
Conference, AF1PS Press, 1975, pp. 271-276.
[DIJ65J Dijkstra, E "Programming Considered a s a Human Activity", en Proc. 1965IFIP Congress,
North-Holland Publishing Co., 1965.
[D1J72] Dijkstra, E "The Humble Programmer", 1972 ACM Turing Award Lecture, CACM, vol. 15,
nm. 10, oct ubre de 1972, pp. 859-866.
[DIJ76] Dijkstra, E., "Structured Programming", en Software Engineerng, Concepts and Techniq ues
(J. Buxton et al., eds ), Van Nostrand-Reinhold, 1976.
[HUR83] Hurley, R. B., Decisin Tables in Software Engineerng, Van Nostrand-Reinhold, 1983.
[LET01] Lethbridge, T. y R. Laganiere, Object-Oriented Software Engineerng: Practical Software
Development using UML and Java, McGraw-Hill, 2001.
[LIS88] Liskov, B., "Data Abstraction and Hierarchy", en SIGPLAN Notices, vol. 23, nm. 5, mayo
de 1988.
[MAR00] Martin, R., "Design Principies and Design Patterns", descargado de ht t p: / / www. obj ect -
ment or. com, 2000.
[OMGOl] OMG Unifted Modeling Speciftcation, Object Management Group, versin 1.4, sept i em-
bre de 2001.
[WAR98] Warmer, J. y A. Klepp, Object Constrainl Language: Precise Modeling with UML, Addison-
Wesley, 1998,
11. 1. El t r mi no componente suel e ser difcil de definir. Primero proporci nese una definicin
genri ca y l uego defi ni ci ones m s explcitas par a sof t ware ori ent ado a obj et os y convenci onal .
Por ltimo, eljanse t res l enguaj es de pr ogr amaci n con los que se est fami l i ari zado e ilstre-
se la maner a en que cada uno define un component e.
11. 2. Por qu son necesari os los component es de control en el sof t ware convenci onal y no lo
son en el ori ent ado a objetos?
11. 3. Descrbase el paradigma orientado a objetos mediante argumentos propios. Por qu es impor
tante crear abstracciones que sirvan como interfaz entre componentes?
11. 4. Descr base el DIP medi ant e ar gument os propios. Qu pasar a si un di seador depende
excesi vament e de las concreci ones?
11. 5. Sel ecci nense t res component es que se hayan desarrol l ado r eci ent ement e y eval ense
los tipos de cohesi n de cada uno. Si se tuviera que definir el principal benef i ci o de una cohe-
sin elevada, cul sera?
11. 6. Sel ecci nense t res component es que se hayan desarrol l ado r eci ent ement e y eval ense
los t i pos de acopl ami ent o de cada uno. Si tuviera que definir el principal benefi ci o de un aco-
pl ami ent o elevado, cul seria?
TM
PDF Editor
11. 7. Es r azonabl e decir que los component es del domi ni o del pr obl ema nunca deben
trar acopl ami ent o externo? Si se est de acuerdo, cul es tipos de component e most rar an esi
tipo de acopl ami ent o?
11.8. Invest i gese y desarrl l ese una lista de cat egor as tpicas par a los component es d; -
fraestructura.
11. 9. Qu es una condicin guardia y cundo se usa?
11. 10. Cul es el papel de l as i nt er f aces en un di seo al nivel de component es basad
clases?
11. 11. Los t rmi nos atributos pblicos y privados suel en usarse en t rabaj o de di seo al ni\ t a
component es . Qu significa cada uno y cul es concept os de di seo t rat an de i mpc-t r"
11. 12. Qu es una fuent e de dat os persi st ent es?
11. 13. Desarrl l ese 1) una clase de di seo el abor ada; 2) descri pci ones de interfaz; 3) ur.
gr ama de act i vi dad par a una de l as oper aci ones dent r o de la cl ase; 4) un di agr ama de gr i ta
de es t ado det al l ado par a una de las cl ases de HogarSeguro que s e han anal i zado en cap -
anteriores.
11. 14. Es lo mi smo ref i nami ent o por pasos que factorizacin? Si no, cul es son sus
cias?
11. 15. Investigese un poco y descr banse t res o cuat ro const rucci ones OCL u operadores
no se hayan anal i zado en la seccin 11.4.
11. 16. Sel ecci nese una pequea par t e de un pr ogr ama exi st ent e (de unas 50 a 75 l;
"
: pr ogr amaci n i
const rucci ones de pr ogr amaci n est ruct urada. De lo contrario, qu not a en los recuadr: J
est di buj ando?
O T R A S L E C T U R A S Y F U E N T E S DE I N F O R M A C I N
Los principios de di seo, los concept os, las lneas general es y las t cni cas par a clases
ponent es ori ent ados a obj et os se revi san en muchos libros sobre ingeniera de soft ware _
lisis y di seo ori ent ados a objetos. Entre l as muchas f uent es de i nformaci n se e n c - c - a J
Bennett y sus col egas [BEN02], Larman (Apply ing UML and Patlems, Prentice-Hall, 2001) _ T
ridge y Laganiere [LET01] y Nicola y sus col egas (Streamlined Object ModeUng. Patterr-
and Implementation, Prentice-Hall, 2001), Schach (Object-Oriented and Classical so/twa-; - a
neering, quinta edicin, McGraw-Hill, 2001 ), Dennis y sus col egas (Systems Analysis src a
sign: An Object Oriented Approach with UML, Wiley, 2001), Graham [Object-Oriented fie
Principies and Practice, Addison-Wesley, 2000), Richter (Designing Flex ible Object-Oner --
tems with UML, Macmillan, 1999), St evens y Pooley (Using UML: Software Engineering i
jects and Components, edicin revisada, Addison-Wesley, 1999) y Riel (Object-Orientei:
Heuristics, Addison-Wesley, 1996).
El concept o de di seo por cont rat o es un til paradi gma de diseo. Libros de Mitche
Kim (Design by Contract by Ex ample, Addison-Wesley, 2001) y Jezequel y sus col egas
Pattems and Contracts, Addison-Wesley, 1999) anal i zan est e t ema en forma detallada '
(Design Pattems lava Workbook, Addison-Wesley, 2002) y Shalloway y Trott (Design RjGr
plained: A New Perspective on Object-Oriented Design, Addison-Wesley, 2001) t oman er
el i mpact o de los pat r ones en el di seo de component es de soft ware. La iteracin de d_> ri
esencial par a la creaci n de di seos de alta calidad. Fowler (Refactoring: Improving fe
of Ex isting Code, Addison-Wesley, 1999) proporci ona una gua til que puede aplicarse : I
da que evol uci ona el diseo.
El t rabaj o de nger , Milis y Witt (Stmctwed ProgrammingTheory and Practice ' *
Wesley, 1979) sigue si endo un t rat ado definitivo sobre el t ema. El texto cont i ene un
adems de explicaciones det al l adas de las rami fi caci ones de la programaci n e
i
TM
PDF Editor
C A P I T U L O 11 DISEO AL NIVEL DE COMPONENTES
349
Ot ros libros que se concent ran en los t emas de di seo procedi ment al para si st emas tradiciona-
les son los de Robertson (Simple Program Design, tercera edicin, Course Technology, 2000),
Farrell (A Guele to Programming Logic and Design, Course Technology, 1999), Bentley (Program-
ming Pearls, 2a. edicin, Addison-Wesley, 999) y Dahl (Structured Programming, Academic
Press, 1997).
Relativamente, pocos libros reci ent es se han dedi cado en exclusiva al di seo al nivel de
component es. En general, los libros de l enguaj e de programaci n at i enden el di seo procedi-
ment al con algn detalle, pero si empre en el cont ext o del l enguaj e que se introduce en el libro.
Hay disponibles ci ent os de ttulos.
Una ampl i a variedad de f uent es de i nformaci n sobre di seo al nivel de component es se
encuent r a en Internet. Una lista act ual i zada de referenci as en World Wide Web que resultan re-
l evant es para el di seo al nivel de component es se encuent r a en el sitio Web de SEPA:
ht t p: / / www. mhhe. com/ pressman
TM
PDF Editor
CAP TULO
1
1
i
C O N C E P T O S
C L A VE
accesibilidad . . , . 375
anfisis de
la tarea ..356
anlisis del
(lujo de trabaja .364
elaboracin de
tarea . . 363
facilidad de uso. 35S
funciones de
ayuda . . 373
nternacionali-
zacn
. . 376
interfaz . . . . . . 354
anlisis de . . . 354
consistencia . . 355
evaluacin . . . 377
modelos . . . . . 356
pasos de
diseo . .368
patrones . . . . . 371
reglas de oro . . 351
DI S E O DE LA I NTERFAZ
DE USUARI O
E
l p l a n o d e u n a c a s a ( s u d i s e o a r q u i t e c t n i c o ) n o e s t a d a c o mp l e t o s i n
r e p r e s e n t a c i n d e p u e r t a s , v e n t a n a s y c o n e x i o n e s d e a g u a , e l e c t r i c i d a d -
l f o n o ( s i n me n c i o n a r l a t e l e v i s i n p o r c a b l e ) . L a s " p u e r t a s , v e n t a n a s
n e x i o n e s " d e l s o f t w a r e d e c o m p u t a c i n i n t e g r a n e l d i s e o d e l a i n t e r f a T
u s u a r i o .
El d i s e o d e l a i n t e r f a z s e c o n c e n t r a e n t r e s r e a s : 1) el d i s e o d e n t e r ;
e n t r e c o m p o n e n t e s d e s o f t wa r e ; 2) el d i s e o d e i n t e r f a s e s e n t r e el s of t v. a
o t r o s p r o d u c t o r e s y c o n s u m i d o r e s d e i n f o r ma c i n q u e n o s o n h u m a n o s (ef
ci r , o t r a s e n t i d a d e s e x t e ma s ) , y 3) el d i s e o d e l a i n t e r f a z e n t r e u n s e r hur -
l e s d e c i r , el u s u a r i o ) y l a c o m p u t a d o r a . Es t e c a p t u l o s e c o n c e n t r a r e x c h
m e n t e e n l a t e r c e r a c a t e g o r a d e dise o de la in(eifaz: la del usuario.
En e l p r l o g o d e s u l i b r o c l s i c o a c e r c a d e l d i s e o d e i n t e r f a c e s d e u s u
B e n S h n e d e r m a n [ SHN9 0 ] a f i r ma :
La f r us t r aci n y a n s i e d a d s o n pa r t e d e l a vi da di ar i a d e mu c h o s us ua r i os de s i s t e r
d e i nf or ma c i n c omput a r i z a dos . Lucha n por a p r e n d e r el l e n gua j e d e c o ma n d o s o i
s i s t e ma s de s el ecci n de me n s que p r e s u n t a me n t e d e b e n a yuda r l e s a r eal i zar s u
ba j o. Al guna s p e r s o n a s s e e n c u e n t r a n c on c a s o s t an s er i os de c h o q u e d e c o mp u t a :
r a, t er r or t e r mi na l o ne ur os i s de r ed, q u e evi t a n el e mp l e o de s i s t e ma s d e cmpu' .
Lo s p r o b l e m a s q u e r e f i e r e S h n e d e r m a n s o n r e a l e s . Es c i e r t o q u e l a s r.:
e e s g r f i c a s d e u s u a r i o , l a s v e n t a n a s , l o s i c o n o s y l a s s e l e c c i o n e s h e c h a s ;
r a t n h a n e l i mi n a d o g r a n p a r t e d e l o s m s t e r r i b l e s p r o b l e m a s r e l a c i o n a d :=
l a s i n t e r f a s e s . P e r o a u n e n u n " m u n d o d e v e n t a n a s " , t o d o m u n d o h a e n c o r :
Qu e s ? El d i s e o d e l a i nt er f az d e
us ua r i o c r e a un me d i o d e c o mu n i c a -
ci n ef ect i va e nt r e un s e r h u ma n o y
u n a c o mp u t a d o r a . Si gui e n d o un c on -
j unt o d e pr i nci pi os d e d i s e o d e
i nt er f aces , el d i s e a d o r i dent i f i ca los obj e t os y
l as a c c i on e s d e l a i nt e r f a z y l ue go c r e a un f or -
ma t o d e pa n t a l l a q u e f o r ma t a b a s e d e un pr o-
t ot i po d e i nt er f az d e us ua r i o.
Qu i n l o h a c e ? Un i nge ni e r o d e s of t wa r e d i s e a
l a i nt e r f a z d e us ua r i o a i a pl i c a r u n p r o c e s o ite-
r at i vo b a s a d o e n pr i nci pi os d e d i s e o a mp l i a -
me n t e a c e p t a d o s .
Po r q u e s i mp o r t a n t e ? Si el us o del s o f t wa r e es
difcil, si l l eva al u s u a r i o a c ome t e r e r r or e s o si
f r us t r a sus e s f u e r z o s por a l c a n z a r sus obj e -
n o le g u s t a r , sin i mpor t a r su c a p a c i d a d - i
f unc i one s q u e o f r e z c a . La i nt er f az t i ene q . e i
c or r e c t a p o r q u e mo l d e a l a pe r c e pc i n dei
ri o a c e r c a del s of t wa r e .
Cu l e s s o n tes p a s o s ? El d i s e o d e l a i nt er f azi
us ua r i o e mp i e z a con l a i dent i f i caci n c-: i
r equi si t os d e st e, l a t a r e o y el a mb i e n t e
v e z i de nt i f i c a da s l as t a r e a s del us ua r i o, s e : -
y a n a l i z a n i os e s c e n a r i os d e s t e p a r a def i -
c o n j u n t o d e obj e t os y a c c i on e s p a r a l a int= - r
Est o cons t i t uye l a b a s e p a r a l a c r e a c i n c~ 4
ma t o s d e p a n t a l l a q u e r e pr e s e n t a n el d i s e : :
f i co y l a ubi c a c i n d e l os i conos ; l a def i ni ci r i
t ext o des cr i pt i vo e n pa nt a l l a ; l a es peci f i co:
TM
PDF Editor
C A P T U L O 1 2 DISEO DE LA INTERFAZ DE USUARIO 351
a s i gna ci n d e n o mb r e s a l as ve nt a na s , a d e m s
de la es peci f i caci n d e los el ement os pr i nci pal es
y s ecunda r i os d e los mens . Se r ecur r e a her r a -
r ent as p a r a c r e a r pr ot ot i pos y f i na l ment e
i mpl ement ar el mo d e l o d e di s eo; por l t i mo, s e
eva l a la c a l i da d del r esul t ado.
* Cu l e s el pr o d uc t o o b t e n i d o ? Se c r e a n los
I e s c e na r i os del us uar i o y se g e n e r a el f or ma t o d e
pant al l a. Se des ar r ol l o un pr ot ot i po d e la inter-
f a z y se modi f i ca d e ma n e r a i nt er act i va.
Cmo pue do est ar s e gur o d e que l o he he c ho
c o r r e c t a me nt e ? El us uar i o r eal i za una " p r u e b a
d e ma n e j o " del pr ot ot i po. La i nf or maci n q u e
pr opor c i ona est a p r u e b a se e mpl e a p a r a la
si gui ent e modi f i caci n i t erat i va del pr ot ot i po.
interfases de usuario difciles de aprender y usar, confusas, poco intuitivas, imperdo-
nabl es y, en muchos casos, t ot al ment e frustrantes. Sin embargo, alguien dedic
t i empo y energa a la construccin de tales interfaces, y es improbable que el cons-
tructor haya generado est os probl emas a propsito.
El di seo de la interfaz de usuario requiere el est udio de las personas y el cono-
cimiento tecnolgico adecuado. Quin es el usuario? Cmo aprende a interactuar
con un nuevo si st ema de cmput o? Cmo interpreta la informacin que produce el
sistema? Qu espera del sistema? stas son slo al gunas de las muchas pregunt as
que deben pl ant earse y responderse como part e del diseo de la interfaz de usuario.
1 2 . 1 L A S R E G L A S DE O R O
En su libro sobre el diseo de interfaces, Theo Mantel [MAN97] acu t res "reglas de
oro" para el di seo de la interfaz:
1. Dar el control al usuario.
2. Reducir la carga en la memori a del usuario.
3. Lograr que la interfaz sea consistente.
Estas reglas de oro forman la base de un conj unt o de principios de diseo de interfases
de usuario que servirn de gua en esta importante accin de diseo del software.
12.1.1 Dar el control al usuario
Se le pregunt a un usuario clave, durant e la sesi n de acopi o de requisitos para un
nuevo e i mport ant e si st ema de informacin, acerca de los atributos de la interfaz
grfica ori ent ada a vent anas. "Lo que en verdad me gustara", dijo el usuario sol em-
nement e, "es un si st ema que me lea la ment e. Que sepa lo que quiero hacer ant es
de que deba hacerl o y que me permi t a hacerl o fcilmente. Eso es todo, y nada ms".
Mi primera reaccin fue mover la cabeza y sonrer, pero me det uve por un mo-
ment o. No haba absol ut ament e nada de mal o en la solicitud del usuario. Quera un
sistema que reacci onara a sus necesi dades y que le ayudara a hacer las cosas. Que-
ra controlar la comput adora; no que sta lo controlara.
La mayor part e de las restricciones y limitaciones que i mpone el di seador a la
interfaz pret enden simplificar el modo de interaccin. Para quienes? En muchos ca-
TM
PDF Editor
352
sos, el diseador introduce limitaciones y restricciones para simplificar la implerr: -
tacin de la interfaz. As, tal vez se tenga como resultado una interfaz fcil de cc
truir, pero cuyo uso resulta frustrante.
Mandel [MAN97] define varios principios de diseo que permiten al usuario i
tener el control:
Definir l os modos de i nteracci n de forma que el usuari o no real i ce a
nes i nnecesari as o i ndeseabl es. Un modo de interaccin es el est ado acta
la interfaz. Por ejemplo, si se elige corrector ortogrfico en un men de un p
dor de palabras, el soft ware pasa a un modo corrector ortogrfico. No hay nint
razn para obligar al usuario a que permanezca en este modo si desea editar e!
to. Debe darse al usuario la opcin de entrar y salir de l sin esfuerzo.
Proporci onar una i nteracci n flexible. Debido a que diferentes usuarios
distintas preferencias de interaccin, deben ofrecerse las opciones correspon
Por ejemplo, tal vez el soft ware le permita al usuario interactuar mediante
miento del ratn, un lpiz digitalizador o comandos seleccionados con el ti
mediante reconocimiento de voz. Pero no t odas las acciones son adecuadas pan
dos los mecani smos de interaccin. Por ejemplo, imagine la dificultad de utiliza:
mandos seleccionados con el teclado (o entrada de voz) para dibujar una
compleja.
Incluir l as opci ones de interrumpir y deshacer la i nteracci n del
Aunque se encuentre en medio de una secuencia de acciones, un usuario debe
con la opcin de interrumpir la secuencia para hacer otra cosa (sin perder el
que haya hecho). Tambin debe contar con la opcin de "deshacer" cualquier
Depurar la i nteracci n a medi da que aument an l os grados de destreza
permitir que s e personal i ce la i nteracci n. Con frecuencia, los usuarios
nan repitiendo la misma secuencia de interacciones. Vale la pena disear un
ni smo de "macro" que permita a un usuario personalizar la interfaz para fa
interaccin.
Ocul te al usuari o ocasi onal l os el ement os t cni cos i nternos. La inten
be llevar al usuario al mundo virtual de la aplicacin; no es necesario que cc
el sistema operativo, las funciones de administracin de archivos u otros secre
la tecnologa de cmputo. En esencia, la interfaz nunca debe requerir que el i
interacte en el nivel "interno" del equipo (por ejemplo, nunca debe pedirse
usuario escriba comandos del sistema operativo desde el interior del sof
aplicacin).
Di sear i nteracci n di recta con l os obj et os que aparecen en la pantalla
usuario siente que tiene el control cuando manipula los objetos necesarios pan 1
lizar una tarea de manera parecida a como lo hara con un objeto material. Por
po, una interfaz de aplicacin que permita al usuario "alargar" un objeto (c
su tamao) es una implementacin de manipulacin directa.
TM
PDF Editor
"Siempre he deseado que mi comput adora sea t an fcil de monej or como mi t el fono. Mi (
Ya no s cmo usar mi t el f ono. "
B j arne St r ons t r up ( creador de C+ + )
12.1.2 Reducir l a carga en l a memori a del usuario
Cuant as m s cosas t enga que recordar un usuario, ms probabilidades habr de que
comet a errores al i nt eract uar con el si st ema. Por ello, una i nt erfaz de usuari o bien
di seada no depender de la memori a de ste. Siempre que sea posible, el si st ema
debe "recordar" la informacin pert i nent e y ayudar al usuari o con un escenari o de
interaccin que le facilite el uso de la memori a. Mandel [MAN97] defi ne los princi-
pios de di seo que logran que una interfaz reduzca la carga de memori a que recae
en el usuario:
Reduci r l a de manda de memori a a cort o pl azo. Cuando los usuari os partici-
pan en t areas compl ej as, la demanda de memori a a corto pl azo se t orna i mport an-
te. La interfaz se debe di sear para que reduzca la necesi dad de recordar acci ones y
resul t ados anteriores. Esto se logra al proporci onar pi st as visuales que permi t an al
usuari o reconocer acci ones ant eri ores sin t ener que recordarlas.
Defi ni r val ores por de f e c t o que t engan si gni f i cado. El conj unt o inicial de va-
lores por defect o debe t ener un sent i do para el usuari o promedi o, per o t ambi n con-
tar con la posibilidad de especificar s us preferencias. Sin embar go, debe di sponer de
una opci n "restablecer" que le permi t a volver a definir los val ores por def ect o ori-
ginales.
Def i ni r a c c e s o s di rect os i ntui ti vos. Cuando se empl ea la mnemot cni ca para
aplicar una funcin del si st ema (por ejemplo, alt-1 para solicitar la funcin de impri-
mir), debe est ar unida a una accin de maner a tal que resulte fcil de recordar (co-
mo la pri mera letra de la t area que se solicita)
El f ormat o vi sual de la i nterfaz de be bas ar s e en una met f ora t omada de la
real i dad. Por ejemplo, en un si st ema de pago de fact uras se debe utilizar la met -
fora de la chequera y el talonario de cheques para llevar al usuari o a recorrer el pro-
ceso del pago de fact uras. Esto permi t e que el usuari o dependa de pi st as vi sual es que
compr ende bien, en lugar de memor i zar una misteriosa secuenci a de i nt eracci ones.
De s gl os ar l a i nf ormaci n de manera progresi va. La i nt erfaz debe organi zar-
se j errqui cament e. Es decir, la i nformaci n sobre una t area, un obj et o o al gn com-
por t ami ent o debe present arse pri mero en un gr ado al t o de abst racci n. Despus de
que el usuari o se interese por seleccionar algo con el rat n, deben pr esent ar se ms
detalles. Un ej empl o comn en muchas aplicaciones de pr ocesami ent o de pal abras
es la funcin de subrayado. Se trata de una ent re varias f unci ones ubi cadas en el me-
n estilo de tex to. Sin embar go, no apar ecen t odas las posibilidades de subrayado. El
usuari o debe seleccionar subrayado para que se present en a cont i nuaci n t odas las
opci ones disponibles (como subrayado sencillo, doble, de guiones, etc.).
TM
PDF Editor
H O G A R S E G U R O
Violacin de una "regla de oro" de a interfaz de usuario
Vi nod: Eso no es lo importante. . . qu tal si lo olvido'
J a mi e : Oh, podemos proporcionarle una lista de las
cmar as en operacin / el lugar en que se encuentran
Vi no d: Eso es posible, pero por qu habr a de pedir
una lista?
Jami e : Muy bien, proporcionemos la lista, la pida o - :
Vi nod: Eso est mejor. Por lo menos no t endr que
recordar cosas que podemos ciarle.
J a mi e ( p e n s a n d o por un mo me nt o ) : Pero o t re
gusta el pl ano, o no?
Vi nod: A j .
J a mi e : Cul crees que le gustara c mercadotecnia?
Vi no d: Ests bromeando, verdad?
J a mi e : No.
Vi nod: Uh... el que tiene el flash... les encantan lo1,
funciones atractivas en los productos. . . a ellos no les
interesa cul es ms fcil de construir.
J a mi e ( s us pi r ando) : Muy bien, tal vez har un
prototipo de ambos.
Vi no d: Buena i dea. . luego dej aremos que el diente
decida.
La e s c e n a : Cubculo de Vinod,
cuando empi eza el diseo de la interfaz de usuario.
Los ac t or e s : Vinod y Jamie, integrantes del equi po de
ingeniera de software de HogarSeguro
La c o nv e r s a c i n:
J a mi e : He est ado pensando en la interfaz de la funcin
de vigilancia.
Vi no d ( s onr i e ndo) : Pensar es bueno.
J a mi e : Creo que podemos simplificar un poco las
cosas.
Vi nod: Lo que significa que. .
Jami e : Bueno, qu posar a si eliminamos por completo
el plono de la caso? Es ostentoso, pero requiere muchos
esfuerzos de desarrollo. En lugar de eso, pidamos al
usuario que especifique la cmara que desea ver y luego
despleguemos el video en una ventana de video.
Vi nod: Cmo recordar el propietario cuntas
cmaras estn funci onando y dnde se encuentran?
J a mi e ( un p o c o i rri t ada) : l es el dueo, debe
saberlo.
Vi nod: Pero qu pasari a si no?
J a mi e : Debe saberlo.
12.1.3 Logiar que la interfaz s ea consistente
La i n t e r f a z d e b e a d q u i r i r y p r e s e n t a r l a i n f o r ma c i n d e m a n e r a c o n s i s t e n t e . Est n
pl i c a q u e 1) t o d a l a i n f o r ma c i n v i s u a l e s t o r g a n i z a d a d e a c u e r d o c o n u n e s t a - . :
d e d i s e o q u e s e m a n t e n g a e n t o d a s l a s p r e s e n t a c i o n e s d e p a n t a l l a ; 2) l o s me c a . '
m o s d e e n t r a d a s e r e s t r i n j a n a u n c o n j u n t o l i mi t a d o q u e s e ut i l i c e d e ma n e r a c c r a
t e n t e e n t o d a l a a p l i c a c i n , y 3) l o s m e c a n i s m o s p a r a ir d e u n a t a r e a a o t r a s e 1 ; 3
d e f i n i d o e i mp l e me n t a d o d e ma n e r a c o n s i s t e n t e . Ma n d e l [ MAN97 ] d e f i n e u n c o r u
t o d e p r i n c i p i o s d e d i s e o q u e a y u d a n a c o n s t r u i r u n a i n t e r f a z c o n s i s t e n t e :
" La s c o s a s q u e t i e n e n a s p e c t o s d i f e r e n t e s d e b e n a c t u a r d e m a n e r a d i s t i n t a . Las q u e t i e n e n e l mi s mo a s p e c t o , d e b e -
a c t u a r i g u a l .
Lorry Mari*
P e r mi t i r q u e e l u s u a r i o i n c l u y a l a t a r e a a c t u a l e n u n c o n t e x t o q u e t e n g a ai
g n s i g n i f i c a d o . Mu c h a s i n t e r f a c e s i mp l e me n t a n c a p a s c o mp l e j a s d e i n t e r a : z n
n e s c o n d o c e n a s d e i m g e n e s e n p a n t a l l a . Es i mp o r t a n t e p r o p o r c i o n a r i n d i c a r s a
( por e j e mp l o , t t u l o s d e v e n t a n a , i c o n o s g r f i c o s , c d i g o s d e c o l o r c o n s i s t e n t e s a s
TM
PDF Editor
C A P I T U L O 1 2 DISEO DE LA INTERFAZ DE USUARIO
355
permitan al usuari o conocer el cont ext o del t rabaj o que realiza. Adems, el usuario
debe t ener la capacidad de det ermi nar de dnde viene y cul es son sus opci ones pa-
ra la transicin a una nueva tarea.
Mant ener la consi st enci a en t oda una fami l i a de apl i caci ones. Un conj unt o
de aplicaciones (o productos) debe i mpl ement ar las mi smas reglas de di seo para
mant ener la consi st enci a en t odas las interacciones.
Si mode l os i nt eract i vos ant eri ores han generado expect at i vas e n el usuari o,
no hacer cambi os a me no s que haya razones i nexcusabl es. Una vez que una
secuenci a interactiva se ha convertido en un est ndar de /acto (como el empl eo de
alt-G para guardar un archivo), el usuario espera est o en t odas las aplicaciones que
encuent re. Un cambi o (como el uso de alt-G para solicitar la funcin cambi ar de ta-
mao) creara confusi n.
Los principios del di seo de interfases expuest os aqu y en secci ones ant eri ores
proporcionan una gua para un ingeniero de soft ware. En la siguiente seccin se exa-
mi nar el proceso de di seo de la interfaz.
INFORMACIN
Facilidad de uso
En un brillante ensayo sobre la facilidad de
uso, Larry Constantine [ CON95] plantea una
que tiene una fuerte relacin con el tema: "Al
de cuentas, qu quieren los usuarios?" Responde as:
que los usuarios realmente quieren son buenas
ientas. Todos los sistemas de software, desde los
operativos y los lenguajes hasta la ent rada de
y las aplicaciones de apoyo a la toma de decisiones,
solo herramientas. Los usuarios finales esperan de las
ientas que construimos par a ellos lo mismo que
s esperamos de las herramientas que usamos.
sistemas fciles de apr ender y que les ayuden a
su t rabaj o. Quieren software que no los det enga,
o confunda, que no les lleve a cometer errores o
: ' cuite la terminacin del t rabaj o".
Constantine argument a que la facilidad de uso no se
: de mecanismos de interaccin estticos o modernos,
inteligencia integrada en la interfaz. En cambi o,
: cuando la arquitectura de la interfaz corresponde a
-ecesidades de las personas que la usarn,
. n a definicin formal de facilidad de uso es elusiva,
ue y sus colegas [ DON99] la definen de la siguiente
~: "Facilidad de uso es una medi da de la manera en
un sistema de cmputo. . . facilita el aprendi zaj e;
a quienes aprenden a recordar lo que han
ido; reduce la posibilidad de errores; les permite ser
tes y los dej a satisfechos con el sistema".
La nica manera de determinar si existe "facilidad de
uso" dentro de un sistema en construccin consiste en
realizar una evaluacin o una prueba de uso. Obsrvese a
los usuarios interactuando con el sistema y respndanse las
siguientes preguntas [CON95]:
Es posible usar el sistema sin ayuda ni enseanza
continua?
Las reglas de interaccin ayudan a un usuario
conocedor a t r abaj ar con eficiencia?
Los mecanismos de interaccin se vuelven ms flexibles
a medi da que los usuarios adquieren ms
conocimientos?
El sistema se ha adecuado al entorno fsico y social en
que habr de usarse?
El usuario est al tanto del estado del sistema? El
usuario sabe dnde se encuentra en cada momento?
La interfaz est estructurada de manera lgica y
consistente?
Los mecanismos de interaccin, iconos y
procedimientos son consistentes en t oda la interfaz?
La interaccin anticipa errores y ayuda al usuario a
corregirlos?
La interfaz tolera los errores que se cometen?
La interaccin es simple?
TM
PDF Editor
Si se responde afirmativamente a cada una de estas
preguntas, es probable que se haya al canzado la facilidad
de uso.
Entre los numerosos beneficios mensurables derivados de
un sistema con facilidad de uso se encuentran [DON99]:
\ ma y o r nivel de ventas y satisfaccin del usuario, ventaja
competitiva, mejores reseas en los medios, mejores
recomendaciones de boca en boca, costos de soporte
reducidos, mayor productividad del usuario final, menores
costos de capacitacin y documentacin, adems de
menos probabi l i dades de que los usuarios insatisfechos
entablen demandas.
1 2 . 2 ANL I S I S Y DI SEO DE LA I NTERFAZ DE USUARI O
El proceso general para anal i zar y di sear una i nt erfaz de usuari o empi eza con :
creaci n de di ferent es model os de funcin del si st ema (como se percibe desde el e i
tenor). Luego se del i nean las t areas ori ent adas al ser huma no y el equi po que se r ;
qui eren para lograr el f unci onami ent o del si st ema; se t oman en cuent a los t emas
di seo que se aplican a t odos los di seos de interfaces; se empl ean herrami ent as p
ra crear prototipos e implantar finalmente el model o de di seo, y los usuari os fir
les eval an la calidad del resultado.
Una excelente fuente
8f> w w w .useit.
com.
^CONSEJO^-
Hasta un usuario
principiante q uiere
accesos directos;
hasta los usuarios
espordicos y con
conocimiento suelen
necesitai una gua.
Hay q ue darles lo q ue
necesitan.
12.2.1 Modelos del anl isis y di seo de l a interfaz
Cuando se anal i za y di sea una interfaz de usuari o ent ran en j uego cuat ro modej -
diferentes. Un i ngeni ero huma no (o el ingeniero del soft ware) est abl ece un mos-
del usuario-, el i ngeni ero del sof t war e crea un modelo del dise o-, el usuari o final y .
sarrolla una i magen ment al que suele denomi nar se modelo mental del usuari o o ps
cepcin del sistema, y qui enes i mpl ement an el si st ema crean un modelo de la in :
mentacin. Por desgracia, es posible que est os model os difieran si gni fi cat i vame-.
ent re s. El papel del di seador de la i nt erfaz es reconciliar est as diferencias y ct --
var una represent aci n consi st ent e de la interfaz.
"Si hay que usar algn ' truco' , la interfaz de usuario no es consistente. "
Douglas Anderso
El model o del usuari o est abl ece el perfil de los usuari os finales del si st ema. Paa
construir una interfaz de usuari o efectiva, "todo di seo debe empezar por la c:n?i
prensi n de qui nes son los usuari os de destino, incluidos sus perfiles de edad <
xo, habi l i dades fsicas, educaci n, ant ecedent es cul t ural es o tnicos, mot i vackr ' 3
objetivos y personal i dad" [SCH90]. Adems, es posible distribuir a los usuari os er _a
si gui ent es cat egor as:
Principiantes. No t i enen conoci mi ent os de la sintaxis' del si st ema y cuent an .
escasos conoci mi ent os2 de la semnt i ca de la aplicacin o del uso de la comput aad
ra en general.
1 En este contexto, conocimiento de sintax is alude a los mecanismos de interaccin requeridos
usar la interfaz de manera efectiva.
2 Conocimiento de semntica alude al sentido inherente de la aplicacin (una comprensin de la<
dones que se realizan, el significado de entrada y salida, y las metas y los objetivos del sistc--; I
TM
PDF Editor
Usuarios espordicos y con conocimientos. Tienen conoci mi ent os razonabl es de
semnt i ca, per o muest ran una ret enci n rel at i vament e baj a de la i nformaci n sobre
sintaxis necesari a para utilizar la interfaz.
Usuarios frecuentes y con conocimientos. Cuent an con conoci mi ent os de sintaxis y
semnt i ca suficientes para llegar al "s ndrome del usuari o avanzado" (es decir, indi-
vi duos que buscan combi naci ones de t ecl as y mt odos abrevi ados para interactuar).
Un model o del di seo de t odo el si st ema i ncorpora dat os, arqui t ect ura, interfaz y
represent aci ones procedi ment al es del soft ware. La especificacin de requi si t os est a-
blece ciertas restricciones que ayudan a definir el usuari o del si st ema, per o el dise-
o de la i nt erfaz sl o suel e ser incidental en relacin con el model o del di seo. 1
El model o ment al del usuari o (percepcin del sistema) es la i magen del si st ema
que los usuari os finales llevan en la ment e. Por ej empl o, si se pidiera al usuari o de
un si st ema det er mi nado de di seo de pgi nas que describiera la operaci n, la per-
cepci n del si st ema det ermi nar a la respuest a. La precisin de la descripcin depen-
der del perfil del usuari o (por ejemplo, los principiantes dar an cuando mucho una
respuest a incompleta) y de la familiaridad general con el sof t war e en el domi ni o de
la aplicacin. Un usuari o que compr enda por compl et o el di seo de pgi nas, pero
que haya t r abaj ado con el si st ema una sola vez en realidad podra proporci onar una
descripcin m s compl et a de su f unci onami ent o que el principiante que ha pasado
s emanas t rat ando de apr ender el si st ema.
"[P]rest e atencin a lo que hocen los usuarios, no a lo que dicen."
J a k o b Ni el s en
El model o de la i mpl ement aci n combi na la mani fest aci n ext erna del si st ema de
cmput o (la apari enci a de la interfaz) y toda la i nformaci n de ayuda (libros, manua-
les, videocintas, archi vos de ayuda) que descri be la sintaxis y semnt i ca del si st ema.
Cuando coi nci den el model o de la i mpl ement aci n y el model o ment al del usuario,
los usuari os suel en sent i rse a gust o con el sof t war e y lo usan con efectividad. Para
lograr esta "combi naci n" de los modelos, el model o del di seo debi desarrol l arse
para incluir la i nformaci n del model o del usuario, y el model o de i mpl ement aci n
debe reflejar con exactitud la i nformaci n sintctica y semnt i ca de la interfaz.
Los model os descritos en est a seccin son "abst racci ones de lo que el usuari o es-
t haci endo o lo que pi ensa que est haci endo o lo que alguien ms pi ensa que de-
bera est ar haci endo cuando usa el si st ema interactivo". [MON84]. En esenci a, est os
model os permi t en que el di seador de la i nt erfaz satisfaga un el ement o clave del
principio ms i mport ant e del di seo de la interfaz de usuari o: Conoce al usuario y sus
tareas.
3 As no es como deben ser las cosas. En muchos casos, el diseo de la interfaz es tan importante
como el diseo arquitectnico y el nivel de componentes
TM
PDF Editor
358 P A R T E D O S PRCTICA DE LA INGENIERIA DEL SOFTWARE
12.2.2 El proceso
El proceso de anlisis y di seo de las i nt erfaces de usuari o es iterativo y s e repres: -
ta con un model o espiral pareci do al que se anal i z en el captulo 3. Tomando
referencia la figura 12.1, se observar que el pr oceso de anlisis y di seo de la ir r
faz de usuari o abarca cuat ro actividades distintas de mar co de t rabaj o [MAN97]
1. Anlisis y model ado de usuari os, t areas y ent ornos.
2. Di seo de la interfaz.
3. Construccin (implementacin) de la interfaz.
4. Validacin de la interfaz.
La espiral que se muest ra en la figura 12.1 indica que cada una de est as t areas
rrir m s de una vez, y cada pas ada por la espiral represent a la elaboracin adi : ir-
nal de los requisitos y el di seo resultante. En casi t odos los casos, la actividac a
const rucci n incluye la creaci n de prototipos (la nica maner a prctica de v l e -
lo que se ha di seado).
El anlisis de la i nt erfaz se concent r a en el perfil de los usuari os que i nt er a r -
rn con el si st ema. Se regi st rarn el grado de habilidad, la comprensi n del
y la disposicin general ant e el nuevo sistema; y se definirn di ferent es cat e
de usuarios.
"Es mejor disear b experiencia del usuorio que rectificarla."
J on
Una vez definidos los requisitos general es se realiza un anlisis ms detallad: fl
las t areas. Se identifican, descri ben y el aboran las t ar eas que el usuari o realiza :
El proceso de
diseo de la
interfaz de
usuario.
Validacin
de la interfaz
Anlisis del usuario,
la t area y el entorno
TM
PDF Editor
<k
e t e s i t o
I ent orno
i empi ece a
r l o i nt erf az
o?
al canzar los objetivos del si st ema (sobre un nmer o de pasadas iterativas por la es-
piral). El anlisis de t areas se expone de maner a ms detallada en la seccin 12.3.
El anlisis del ent orno del usuari o se concent ra en el ambi ent e fsico de trabajo.
Entre las pregunt as que deben responderse estn las siguientes:
Dnde se localizar fsicamente la interfaz?
El usuario est ar sent ado, de pie o realizar ot ras t areas sin relacin con la
interfaz?
El h a r d wa r e d e la i nt e r f a z t i e ne r e s t r i c c i one s d e e s p a c i o o i l umi na c i n, o l o
a f e c t a el r ui do?
Hay fact ores humanos especi al es det ermi nados por factores ambi ent al es?
La informacin reunida como part e de la actividad de anlisis se utiliza para crear
un model o del anlisis para la interfaz. Tomando este model o como base, se inicia
la actividad de diseo.
El objetivo del di seo de la interfaz es definir un conj unt o de obj et os y acci ones
(y sus represent aci ones en pantalla) que permitan que el usuari o realice t odas las ta-
reas definidas, de maner a tal que cumpl an t odos los objetivos de facilidad de uso que
define el sistema. El di seo de la interfaz se estudia con mayor detalle en la seccin
12.4.
Por lo general, la actividad de construccin empi eza al crear un prototipo que per-
mita evaluar los escenari os de uso. A medida que contina el proceso de di seo ite-
rativo, pueden usarse herrami ent as de desarrollo de la interfaz de usuario (consulte
el recuadro de la seccin 12.4) para compl et ar la construccin de la interfaz.
La validacin se concent ra en 1) la capacidad de la interfaz para i mpl ement ar co-
rrect ament e t odas las t areas del usuario, acomodar t odas las vari aci ones de las ta-
reas y cumplir t odos los requisitos general es del usuario; 2) la facilidad del uso y el
aprendi zaj e de la interfaz, y 3) la aceptacin por el usuario de que la interfaz es una
herrami ent a til para su trabajo.
Como ya se ha observado, las actividades descritas en est a seccin ocurren de
maner a iterativa. Por tanto, es innecesario t rat ar de especificar cada detalle (para el
model o de anlisis o de diseo) en el primer paso. Los siguientes pasos del proceso
dan lugar al detalle de la tarea, la informacin del di seo y las caractersticas opera-
tivas de la interfaz.
1 2 . 3 DE L A I N T E R F A Z
Un principio clave de t odos los model os de procesos de ingeniera del soft ware re-
za: es mejor comprender el problema antes de tratar de dise ar una solucin. En el ca-
4 Resulta razonable argumentar que esta seccin debi colocarse en el captulo 8, porque all se es-
tudia el anlisis de requisitos. Se ha incluido aqu porque el anlisis y el diseo de la interfaz estn
ntimamente relacionados, y porque el lmite entre ambos es muy difuso.
TM
PDF Editor
Cmo s l o
que l os
us uari os qui eren
de l a i nt e r f a z ?
^ CONSEJ O^
Sobretodo, dediq ese
tiempo a hablar con
las usuarios redes,
pero debe hoceise con
cuidoda. Una ophn
fuerte no necesaria-
mente signUka q ue la
may oro de os
usuorios est de
ocuerdo.
%
%
CLAVE
Cmo aprendemos
sobre la demografa y
las caractersticas de
los usuorios finales?
so del di seo de la i nt erfaz de usuario, compr ender el probl ema significa comp-;~
der 1) a las per sonas (los usuari os finales) que i nt eract uarn con el si st ema por r e ]
dio de la interfaz; 2) las t areas que los usuari os finales deben realizar para hace-
t rabaj o; 3) el cont eni do que se pr esent a como part e de la interfaz, y 4) el entorne
que se realizarn est as tareas. En las secci ones si gui ent es se exami nar cada un .
est os el ement os del anlisis de la i nt erfaz con el fin de est abl ecer una base
para el di seo de las t areas que siguen.
12.3.1 Anlisis del usuario
Ya se ha i ndi cado que cada usuari o tiene una i magen ment al del soft ware (o ]
cn del sistema) que podra ser di ferent e de la i magen ment al de otros. Adema;
probabl e que la i magen ment al del usuari o sea muy diferente del model o del >
que tiene el ingeniero. El di seador slo lograra que coi nci dan la i magen mer -_a.
el model o del di seo si t rabaj a para compr ender a los propi os usuarios, ademad-
la maner a en que ellos usar n el si st ema. Es posible usar i nformaci n de una ;
variedad de f uent es disponible para lograr esto:
Ent revi st as c on el usuari o. Es el enf oque ms directo. Represent ant es de:
po de soft ware se ent revi st an con usuari os finales para compr ender mejor sus i
sidades, mot i vaci ones, cultura de t rabaj o y gran cant i dad de t emas adicionales
t o se logra medi ant e reuni ones per sonal es o con gr upos de enfoque.
Inf ormaci n de vent as . El personal de vent as se r ene con clientes y i
de maner a regul ar y obt i ene i nformaci n que ayudar al equi po de soft ware a
ficar a los usuari os en cat egor as y a compr ender mej or sus necesi dades.
Inf ormaci n de mercadot ecni a. El anlisis de mercado es invaluable en la
nicin de los segment os del mercado, al tiempo que proporciona una comprer
la maner a en que cada segment o usara el soft ware de manera sutilmente dife
Inf ormaci n proveni ent e de s oport e. El personal de soport e habl a a
con los clientes. Esto los convierte en la f uent e de i nformaci n ms probable
lo que funci ona y lo que no, lo que le gust a a los usuari os y lo que les disgusta
caract er st i cas que gener an dudas y las que resultan fciles de usar.
El si gui ent e grupo de pr egunt as (adapt ado de [HAC98] ayudar al di seado:
interfaz a compr ender mej or a los usuari os de un si st ema.
Los usuari os son profesi onal es capaci t ados, tcnicos, t rabaj adores de i
u obreros?
Qu grado de educaci n formal tiene el usuari o promedi o?
Los usuari os son capaces de apr ender con mat eri al es escri t os o expre
su deseo de recibir capaci t aci n en el lugar?
Los usuari os son expert os para tipear o le tienen fobia al teclado?
Cul es la edad promedi o de la comuni dad de usuarios?
TM
PDF Editor
Los usuarios corresponden predomi nant ement e a algn gnero?
Qu compensacin reciben los usuarios por su trabajo?
Los usuarios trabajan en horas normal es de oficina, o siguen sus labores
hasta que hayan terminado lo que estn haciendo?
El soft ware ser una parte integral del trabajo de los usuarios, o se emplear
ocasionalmente?
Cul es el idioma mat erno de los usuarios?
Cules seran las consecuenci as si un usuario comet e un error mientras usa
el sistema?
Los usuarios son expertos en el tema que etiende el sistema?
Los usuarios quieren conocer la tecnologa que sustenta la interfaz?
Las respuest as a st as y ot ras pregunt as similares permitirn que el diseador com-
prenda quines son los usuarios finales, qu los motiva y complace, cmo se agru-
paran en diferentes clases o perfiles de usuarios, cules son sus model os mentales
del sistema, y cmo debe caracterizarse la interfaz de usuario para que satisfaga sus
necesidades.
12.3.2 Anlisis y model ado de tareas
El objetivo del anlisis de la tarea es responder las siguientes preguntas:
Qu t rabaj o har el usuario en circunstancias especficas?
Cules tareas y subtareas se realizarn mientras el usuario trabaja?
Cules objetos especficos del dominio del problema manipular el usuario
mientras se realiza el trabajo?
En qu secuencia se presentan tareas del trabajo (el flujo de trabajo)?
Cul es la jerarqua de las tareas?
Para responder est as preguntas, el ingeniero de software debe basarse en las tcni-
cas de anlisis expuestas en los captulos 7 y 8; pero en este caso las tcnicas se apli-
can a la interfaz del usuario.
Casos de uso. En captulos anteriores se indic que el caso de uso describe cmo
un actor (en el contexto del diseo de la interfaz, un actor siempre es una persona)
interacta con un sistema. Cuando se usa como parte del anlisis de tareas, el caso
de uso se desarrolla para que muestre la manera en que el usuario final realiza al-
guna tarea especfica relacionada con el trabajo. Casi siempre, el caso de uso se es-
cribe de manera informal (un solo prrafo) en primera persona. Por ejemplo, supn-
gase que una pequea empresa de software quiere construir un sistema de diseo
asistido por computadora explcitamente para di seadores de interiores. Para com-
prender mejor cmo hacen su trabajo, se pide a di seadores de interiores reales que
describan funciones especficas del diseo. Cuando se les pregunta: "cmo decide
TM
PDF Editor
el l ugar en que col ocar un muebl e en una habi t aci n?", un di s eador de inter:
escr i be el si gui ent e c a s o de us o i nf ormal :
Empiezo haciendo un borrador del plano de la habitacin, las dimensiones y la posicio-
de las ventanas y puertas. Me preocupo por la manera en que entra la luz, por la vista OLC
se tiene a travs de las ventanas (si es hermosa, me gustara llamar la atencin hacia ella
por el espacio que las paredes no tapan, por el flujo del movimiento en la habitacin. LU
go observo la lista de muebles que mi cliente y yo hemos elegido (mesas, sillas, sillones
vitrinas) y la lista de accesorios (lmparas, alfombras, cuadros, esculturas, plantas, peque
as piezas}, y tambin observo mis notas sobre la manera en que mi cliente desea que se
distribuyan. Luego dibujo cada elemento de mis listas empleando una plantilla que se "ri
dibujado a escala con el plano. Etiqueto cada elemento y uso lpiz porque siempre mu
vo cosas. Considero varias opciones de ubicacin y decido cul es la que me gusta mas.
Luego dibujo una representacin (una imagen tridimensional) del cuarto, para dar a ~ |
cliente una idea del aspecto que tendr.
Est e c a s o de us o pr opor ci ona una descr i pci n el ement al de un a t ar ea de trabai r J
por t a nt e par a el s i s t ema de di s eo asi st i do por comput a dor a . A part i r de l, el -
ni er o de s of t wa r e ext r aer t a r e a s y obj et os, a d e m s del flujo gener al de la i n t e n J
ci n. Adems , t a mbi n es posi bl e concebi r ot r a s car act er st i cas del si st ema I <I
agr adar an al di s eador de i nt eri ores. Por ej empl o, podr an t oma r s e f ot ograf as : qd
t al es del p a n o r a ma de c a da vent a na . As, c ua n d o s e ha ga un a r epr esent aci n ;T
i magen de la habi t aci n s e mos t r ar a la vista real e n ca da vent a na .
HOGARSEGURO
Casos de uso para el diseo de interfaces de usuario
I I i -
La e s c e n a : Cubculo de Vinod,
mientras se contina con el diseo de le interfaz.
Los a c t o r e s : Vinod y Jamie, integrantes del equi po de
ingeniera dei software de HogarSeguro.
La conversaci n:
Jami e: Fui a ver a mi contacto de mercadotecnia e hice
que escribiera un caso de uso par a la interfaz de vigilancia.
Vi nod: Desde el punto de vista de quin?
Jami e : Del propietario de la casa, de quin ms?
Vi nod: Tambin existe el enfoque del administrador.
Aunque el propietario desempee ese papel , tendr un
punto de vista diferente. El "administrador" habilita el
sistema, configura las cosas, disea el pl ano de la casa,
coloca las cmaras. .
Jami e : Lo que hice fue que mercadotecnia representara
e papei ce j n propietario que quiere ver un video.
Vi no d: Eso est bien. Es uno de los principales
comportamientos de la interfaz de la funcin de
vigilancia. Pero tendremos que exami nar tambin el
comportamiento del administrador del sistema.
Jami e (i rri tada): Tienes razn.
(Jamie sale a buscar a la persona de mercadotecnia
Regresa unas horas ms tarde.)
J a mi e : Tuve suerte. Encontr a nuestro contacto de
mercadotecnia y t rabaj amos untos el caso del
administrador. Bsicamente, definiremos
"administracin" como una funcin apl i cabl e a todas
funciones de HogarSeguro. He aqu lo que hicimos.
(Jamie muestra a Vinod el caso de uso informal.)
Cas o de us o i nf ormal : Quiero la capacidad de
configurar o editar el formato del sistema en cualquie-
momento. Cuando configure el sistema seleccionar 1c
funcin de administracin. Me pregunta si quiero de^- r
una nueva configuracin. Respondo afirmativamente :
TM
PDF Editor
C A P T U L O 1 2 DISEO DE LA INTERFAZ DE USUARIO
363
i una pontana de dibu| 0 que me permite
el plano de !a casa en una cuadrcula. Habr
par a paredes, vent anas y puert as que me
'n el dibujo. Solamente estiro los iconos par a que
la dimensin correcta. El sistema despl egar las
pies o metros (puedo seleccionar el sistema
). Tengo la opcin de seleccionar sensores y
de una biblioteca y de ubicarlas en el plano,
poner una leyenda a cada una, pero el sistema
lo puede hacer automticamente. Tengo la
' de definir los parmet ros de sensores y
liante mens especiales. Si selecciono editar,
mover los sensores o las cmar as, agr egar nuevos
o eliminar los que ya existen, editar el pl ano de la casa y
los valores de cmar as y sensores. En todos los casos,
espero que el sistema tenga consistencia y me ayude a
no cometer errores.
Vi nod ( des pus d e l eer el gui n) : Muy bien. Tai
vez haya algunos patrones de diseo tiles o al gunos
componentes reutilizables que podamos usar en las
interfaces grfi cas de usuario tomados de algn
programa de diseo. Te apuesto la comida a que, si los
usamos, podemos mplementar part e de la interfaz del
administrador, o casi toda ella.
J a mi e : Estoy de acuerdo, dj ame revisarlo.
<#
se ha
una torea no
q ue no
maneta de
y q ue se
. aplicar
e implemente
de usuario.
El aboracin de la tarea. En el captulo 9, se analiz la elaboracin paso a pa-
so (tambin denominada descomposicin funcional o refinamiento paso a paso) como
mecani smo para refinar las t areas de procesami ent o requeridas para que el soft wa-
re realice alguna funcin deseada. El anlisis de la tarea para el diseo de la inter-
faz emplea un enfoque elaborativo para apoyar la comprensin de las actividades
humanas a las que debe adecuarse la interfaz de usuario.
El anlisis de la tarea se aplica de dos maneras. Como ya lo hemos indicado, un
sistema interactivo, computacional, suele usarse para reemplazar una actividad ma-
nual o semiautomtica. Con el fin de comprender las tareas indispensables para al-
canzar el objetivo de la actividad, un ingeniero humano5 debe comprender las t areas
que las personas realizan act ual ment e (al usar un mt odo manual) y luego relacio-
narlas con un conjunto similar (pero no necesari ament e idntico) de tareas que se
implementan en el contexto de la interfaz de usuario. Como opcin, el ingeniero hu-
mano puede estudiar una especificacin existente para una solucin computarizada
y derivar un conj unt o de tareas de usuario que se adecuarn al modelo de ste, el
modelo del diseo y la percepcin del sistema.
Sin importar el enfoque general para el anlisis de la tarea, un ingeniero humano
debe definir y clasificar primero las tareas. Ya se ha indicado que un enfoque es la
elaboracin paso a paso. Por ejemplo, suponga que una pequea compaa de soft-
ware pretende construir un sistema de diseo asistido por computadora explcitamen-
te para diseadores de interiores. Al observar cmo trabaja uno de ellos, el ingeniero
nota que el diseo de interiores abarca varias actividades importantes: distribucin del
mobiliario (tome en cuenta el caso de uso que ya analizamos), seleccin de telas y ma-
teriales, seleccin de tapices para paredes y cortinas para ventanas, presentacin (pa-
ra el cliente), presupuesto y compras. Cada una de estas importantes t areas pueden
desglosarse en subtareas, Por ejemplo, de acuerdo con la informacin contenida en
5 En muchos casos, un ingeniero de software realiza las tareas descritas en esta seccin. Lo ideal es
que esta persona tenga capacitacin en ingeniera humana y eri diseo de interfaces de usuario.
TM
PDF Editor
364
P AE T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
^CONSEJO^.
Aunq ue lo elaboracin
del objeto sea til, no
debe usarse como un
enfoq ue indepen-
diente. Lo voz del
usuario debe tomarse
en cuenta durante el
anlisis de la tarea.
el caso de uso, la distribucin del mobiliario se retinara de las siguientes tareas: 1 ;
bujar un plano de la casa t omando como base las dimensiones de la habitacin
ubicar las vent anas y puertas en los lugares adecuados; 3a) usar las plantilla;
muebl es para dibujar cont omos a escala en el plano; 3b) usar las plantillas de
sorios para dibujarlos a escala en el plano; 4) mover los contornos de los mueble;
accesorios para obtener el mejor lugar; 5) rotular todos los contornos de muebles y
cesorios; 6) dibujar las dimensiones para mostrar la ubicacin; 7) generar la vista :
dimensinal en perspectiva para el cliente. Un enfoque similar se usara para
una de las ot ras tareas importantes.
Es posible retinar an ms de la subtareas I a 7. De la 1 a la 6 se realizarn al :
nipular la informacin y ejecutar acciones dentro de la interfaz de usuario. Por
parte, el soft ware tiene la capacidad de realizar aut omt i cament e la subtarea
que representara poca interaccin directa del usuario.6 El model o del diseo or
interfaz debe acomodar cada una de esas tareas para que sea consistente con e. :
dlo del usuario (el perfil de un diseador de interiores "tpico") y la percepcir
sistema (lo que el diseador de interiores espera de un sistema automatizado
El aboracin del obj et o. En lugar de concentrarse en las tareas que un
debe realizar, el ingeniero de soft ware examina el caso de uso y otra i nformador ;
tenida del usuario y obtiene los objetos fisicos que usa el diseador de interiores
tos objetos pueden ordenarse en clases. Los atributos de cada clase y una
cin de las acciones aplicadas a cada objeto proporcionan al diseador una hs-u
operaciones. Por ejemplo, la plantilla de muebl es se traduce en una clase lia
Mu e b l e c o n a t r i but os q u e p o d r a n i ncl ui r tamao, forma, ubicacin y ot r a s . El
dor de interiores seleccionara el objeto de la clase Mueble, lo movera a una |
en el pl ano (otro objeto en el contexto), dibujara el cont orno de los muebles, e: :
t areas seleccionar, mover y dibujar son operaciones. El model o del anlisis de .; i
terfaz de usuario no proporcionara una implementacin para cada una de
operaciones. Sin embargo, a medida que se elabore el diseo se definiran los ;
lies de cada operacin.
Anl isis del flujo de trabajo. Cuando distintos usuarios, cada uno repre
do diferentes papeles, utilizan una interfaz de usuario, a veces es necesario
all del anlisis de la tarea y la elaboracin de objetos y aplicar el anlisis delj
trabajo. Esta tcnica permite que un ingeniero de soft ware comprenda cmo se i
liza un proceso de t rabaj o cuando se involucran varias personas (y papeles),
en una compaa que pretende automatizar el proceso de prescribir y enviar:
cament os que se venden con receta. Todo el proceso7 girar alrededor de un;
Sin embargo, tal vez ste no sea el caso. Es probable que el diseador de Interiores quiera i
car la perspectiva del dibujo, el tamao o el uso del color y otra informacin. El caso de i
cionado con las representaciones de dibujos en perspectiva proporcionara la informacic:
necesita atender en esta tarea.
Este ejemplo se ha adaptado de (HAC98],
TM
PDF Editor
365
cacin Web disponible para mdicos (o sus asistentes), farmacuticos y pacientes. El
flujo de t rabaj o se representa de manera efectiva con un diagrama de linea de flota-
cin UML (una variante del diagrama de actividad).
Slo se considerar una pequea parte del proceso de trabajo: la situacin que se
presenta cuando un paciente pide que se le resurta una receta. En la figura 12.2 se pre-
senta un diagrama de lnea de flotacin que indica las tareas y decisiones de cada uno
de los tres papeles citados. Esta informacin podra obtenerse mediante entrevistas
o casos de estudio escritos por cada actor. Independientemente de esto, el flujo de
los event os (mostrados en la figura) permite que el diseador de la interfaz reconoz-
ca tres caractersticas clave:
1. Cada usuario implementa diferentes t areas con la interfaz; por tanto, el con-
cepto de la interfaz diseada para el paciente ser diferente del aplicado a los
farmacuticos o mdicos.
2. El diseo de la interfaz para farmacuticos y mdicos debe tener acceso a la
informacin de fuentes secundari as (como acceso a inventarios de farmacia y
a la informacin acerca de medi cament os alternos por parte del mdico), ade-
ms de desplegar esta informacin.
3. Es posible elaborar an ms muchas actividades indicadas en el diagrama de
lnea de flotacin medi ant e anlisis de la tarea, elaboracin de objetos, o am-
bas opciones (por ejemplo, prescripcin de resurtido podra relacionarse con
una entrega por correo, o una visita a la farmacia o a un centro especial de
distribucin de medicamentos).
Represent aci n jerrquica. Cuando se analiza una interfaz ocurre un proceso
de elaboracin. Una vez establecido el flujo de t rabaj o se define una jerarqua de ta-
rea para cada tipo de usuario. La jerarqua se deriva de una elaboracin paso a pa-
so de cada tarea que el usuario haya identificado. Por ejemplo, pinsese en la tarea
de usuario solicitar q ue se resurta una receta. Se desarrolla la siguiente jerarqua de
tareas:
Solicitar q ue se resurta una receta
Proporcionar informacin de identificacin
Especificar nombre
Especificar identidad de usuario
- Especificar NIPy contrase a
Especificar nmero de receta
Especificar fecha en q ue se req uiere el resurtido
Completar la tarea solicitar q ue se resurta una receta requiere definir tres subtareas.
Una de ellas, proporcionar informacin de identificacin, incluye tres subt areas adicio-
nales.
TM
PDF Editor
366
Diagrama de lnea de flotacin para la funcin de resurtido de recetas.
TM
PDF Editor
Cmo s e
> y l o
i del
i c omo
i de lo
: de
a?
"Es mucho mejor adapt ar la tecnologa al usuario que obligar o ste a adapt ar se a la tecnologa."
Larry Mari ne
12.3.3 Anlisis del contenido de la pantal l a
Las t areas del usuario identificadas en la seccin anterior llevan a la presentacin de
diferentes tipos de contenido. En el caso de aplicaciones modernas, el cont eni do de la
pantalla va de i nformes basados en caract eres (por ejemplo, hoj as de clculo), pan-
tallas grfi cas (por ejemplo, un hi st ograma, un model o 3-D, la fotografa de una per-
sona) o i nf ormaci n especi al i zada (como archi vos de audi o o video). Las t cni cas
de model ado del anlisis est udi adas en el captulo 8 identifican los obj et os de dat os de
salida que produce una aplicacin. Estos obj et os de dat os son: 1) generados por com-
ponent es (no relacionados con la interfaz) en ot ras part es de la aplicacin; 2) adquiri-
das de los dat os al macenados en una base de dat os a la que se tiene acceso desde la
aplicacin, o 3) transmitida de si st emas ext ernos a la aplicacin en cuestin.
En est e paso del anl i si s de la interfaz se consi deran el f ormat o y la esttica del
cont eni do (tal como se despliega en la interfaz). Entre las pregunt as que se habrn
de pl ant ear se encuent r an las siguientes:
Hay di ferent es tipos de dat os asi gnados a ubi caci ones consi st ent es en la
pantalla (por ej empl o, las fot os si empre apar ecen en la esqui na superi or dere-
cha de la pantalla)?
El usuari o puede personal i zar la distribucin del cont eni do en la pantalla?
Se ha asi gnado una apropi ada identificacin en pantalla a t odo el cont eni do?
Cmo se segment a un informe largo para facilitar su comprensi n?
Habr mecani smos disponibles para despl azar di rect ament e al r esumen de
i nformaci n en conj unt os gr andes de dat os?
Se cambi ar el t amao de la salida grfica para que quepa dent ro de los lmi-
tes de la pantalla o el moni t or que habr de usarse?
Cmo se usar el color para mej orar la compr ensi n?
Cmo se present arn al usuari o los mensaj es de error y los avi sos de precau-
cin?
A medi da que se responden est as (y otras) pregunt as se est abl ecern los requisitos
para la present aci n del cont eni do.
12.3.4 Anlisis del entorno de trabajo
Hackos y Redish [HAC981 anal i zan la importancia del anlisis del ent or no de traba-
jo cuando afi rman:
La gente no trabaja aislada; la afectan la actividad que se realiza a su alrededor, las carac-
tersticas fsicas del lugar de trabajo, el tipo de equipo que emplea y sus relaciones de tra-
bajo con los dems. Si los productos que se disean no se amoldan al entorno, es posible
que su uso resulte ditcil o frustrante.
TM
PDF Editor
368
En al gunas aplicaciones la interfaz de usuario para un sistema de cmput o se <
ca en un "lugar amigable para el usuario" (por ejemplo, iluminacin apropiada, I
na altura de la pantalla, fcil acceso al teclado), pero en otros (como el piso de i
fbrica o la cabina de un avin), la iluminacin es deficiente, el ruido es impor
un teclado o un ratn no son una opcin, la colocacin del monitor es menos i
ideal. Al diseador de la interfaz lo limitarn factores que atentan contra la fcil.,
de uso.
Adems de los factores del entorno fsico, la cultura del lugar de t rabaj o tar
incide. La interaccin del sistema se medir de alguna manera (por ejemplo,
po por transaccin o exactitud de sta)? Dos o ms personas tendrn que cc
tir informacin ant es de que se proporcione una entrada? Cmo se dar sop
los usuarios del sistema? Es necesario responder st as y muchas otras pregunta; -
lacionadas ant es de iniciar el diseo de la interfaz.
Una vez finalizado el anlisis de la interfaz, se han identificado con detalle te
tareas (objetos o acciones) que requiere el usuario final, y comenzar la activid
diseo de la interfaz. Esta etapa, como todo el diseo de la ingeniera del
es un proceso iterativo. Cada paso del diseo de la interfaz se da varias veces
cada uno de ellos se elabora y refina informacin desarrollada en los pasos <
res.
Aunque se han propuesto muchos modelos diferentes para el diseo de la i
faz de usuario (por ejemplo, [NOR86], [NIEOO]), todos sugieren alguna combii
de los siguientes pasos:
1. Con base en la informacin desarrollada durante el anlisis de la infor
(seccin 12.3), definir los objetos y las acciones de la interfaz (operacic
2. Definir event os (acciones del usuario) que cambiarn el est ado de la int
Modelar est e comportamiento.
3. Representar cada est ado de la interfaz tal como lo ver el usuario final
4. Indicar cmo interpreta el usuario el estado del sistema a partir de la i
proporcionada mediante la interfaz.
En algunos casos, el diseador de la interfaz puede empezar con borradores i
da estado de la interfaz (es decir, el aspect o de la interfaz en distintas circur
y luego trabajar hacia at rs para definir objetos, acciones y otra informacin
tante para el diseo. Independientemente de la secuencia de las tareas del
ste debe 1) seguir siempre las reglas de oro analizadas en la seccin 12.1; 2 :
lar la manera en que se implementar la interfaz, y 3) tomar en cuenta el
(por ejemplo, la tecnologa de despliegue, el sistema operativo, las herramii
desarrollo) en que habr de usarse.
TM
PDF Editor
"Ei diseo interortivo [ es] uno mezclo i nt egrada de artes grficas, tecnologa y psicologa."
B rad Wi eners
12.4.1 Apl i caci n de los pasos del di seo de la interaz
Un paso i mport ant e en el di seo de la interfaz es la definicin de los obj et os que s-
ta t endr y las acci ones que se les aplicarn. Para realizarlo se anal i zan los casos de
uso de maner a muy parecida a la descrita en el captulo 8. Es decir, se escribe una
descripcin de un caso de uso. Luego se aislan los nombr es (objetos) y los verbos
(acciones) para crear una lista de obj et os y acci ones.
Una vez definidos los obj et os y las acci ones, que se han el aborado de maner a ite-
rativa, se organi zan por tipo. Se identifican obj et os de destino, origen y aplicacin.
Un objeto de origen (como el icono de un informe) se arrast ra y coloca en un objeto
de destino (por ej empl o, un icono de impresora). La implicacin de est a accin es
crear un informe impreso. Un objeto de aplicacin representa dat os especficos de la
aplicacin que no se mani pul an di rect ament e como parte de la interaccin con la pan-
talla. Por ejemplo, en una lista de correo se al macenan nombr es para un envo de
correspondenci a. La propia lista podra ordenarse, combi narse o purgarse (acciones
de men), per o no arrast rarse ni col ocarse medi ant e interaccin del usuari o.
Una vez que el di seador queda sat i sfecho con un obj et o i mport ant e y que se han
defi ni do las acci ones (para una iteracin de diseo) se realiza el f ormat o de la pan-
talla. Como ot r as act i vi dades de di seo de la interfaz, el formato de la pantalla es un
proceso interactivo; en l se el abora el di seo grfi co y se colocan los iconos, la de-
finicin de texto descriptivo en pant al l a, la especificacin y la asi gnaci n de nom-
bres a las vent anas, a dems de la definicin de los el ement os pri mari os y secunda-
rios de los mens. Si una met fora de la realidad es apropi ada para la aplicacin, se
especifica en est e moment o, y el di seo se organi za de maner a tal que satisfaga la
met fora.
Un breve ej empl o de los pasos del di seo indicados ant er i or ment e se obt i ene
i magi nando el cont ext o en que s e sita un usuari o del si st ema HogarSeguro anal i za-
do en cap t ul os ant eri ores. A cont i nuaci n se present a un caso de est udi o prelimi-
nar (escrito por el propietario) para la interfaz.
Caso de uso prel i mi nar. Quiero tener acceso a mi sistema HogarSeguro desde cualquier
lugar remoto va Internet. Empleando software de navegador que opera en mi notebook
(mientras estoy trabajando o viajando) puedo determinar el estado del sistema de alarmas,
armar o desarmar el sistema, reconfigurar zonas de seguridad y ver diferentes habitacio-
nes de la casa con las cmaras de video preinstaladas.
Para tener acceso a HogarSeguro desde un lugar remoto proporciono una identificacin
y una contrasea. Estos elementos definen los niveles de acceso (por ejemplo, no todos
los usuarios pueden reconfigurar el sistema ni proporcionar seguridad). Una vez validado,
puedo revisar el estatus del sistema y cambiarlo al armar o desarmar HogarSeguro. Puedo
reconfigurar el sistema al desplegar un plano de la casa, ver cada uno de los sensores de
TM
PDF Editor
370
^ ONS EJ C ^
Aunq ue las
herramientas
automatizadas son
tiles en el desarrollo
de prototipos de
formato, en ocasiones
todo lo q ue se
necesita es lpiz y
papel.
seguridad, despl egar cada zona confi gurada act ual ment e y modificar zonas de acuerd
con las necesi dades. Puedo ver el interior de la casa con las cmar as de video colocada?
de maner a estratgica. Puedo hacer acercami ent os y despl azami ent os con las cmar ai
par a proporci onar di ferent es vi st as del interior.
Con base en este caso de uso se identifican las t areas del propietario, los objet -
los el ement os siguientes:
tiene acceso al sistema HogarSeguro
ingresa un ID y una cont rasea para acceso remot o
revisa el est at us del s i s t ema
arma o desarma el sistema HogarSeguro
despliega el pl ano de la cas a y las ubi caci ones de l os s ens ores
despliega zonas en el plano de la casa
cambia zonas en el plano de la casa
despliega ubi caci ones de l as cmaras de vi deo o el pl ano de la casa
selecciona visualmente una cmara de vi deo
ve i mgenes de vi deo
desplaza o acerca las cmaras de vi deo
Los objetos (en negritas) y las acciones (en cursivas) se extraen de la lista de
del propietario. La mayor parte de los objetos indicados son objetos de la ap
Sin embargo, ubi caci n de l as cmaras de vi deo (un objeto de origen) se
tra y coloca en cmara de vi deo (un objeto de destino) para crear una i
vi deo (una vent ana que contiene el despliegue de video).
Se crea un boceto preliminar del formato de la pantalla para el monitoreo
deo (figura 12.3).8 La imagen de video se solicita seleccionando un icono de
cin de las cmaras de video, C, localizado en el plano de la casa despleg:
ventana de monitoreo. En este caso se arrastra la ubicacin de una cmara de
en la sala, SA, y se coloca sobre el icono de cmara de video ubicado en la
perior izquierda de la pantalla. Aparecer la ventana de imagen de video,
do video de flujo continuo proveniente de la cmara ubicada en la sala (SA
troles deslizables de acercami ent o y despl azami ent o se empl ean para cr
ampliacin y la direccin de la imagen del video. Para seleccionar una vista
cmara, el usuario simplemente arrastra y coloca un icono de ubicacin ck
8 Considrese que esto difiere de la implementacin de estas caracteristicas en captulos
Esto podra considerarse un borrador del primer diseo y representa una opcin digna
en cuenta
TM
PDF Editor
371
Acceso Configurar Sistema Estatus Ver Supervisar
HogarSeguro
Cmoro de video.
Primer piso
D Detecto: de movimiento fray o mostradoj
C Ubicacin de cmaro de video
Acercar
I
| [ Zoom m i | | [ \ \ J A I e j a r
Dezplazar
diferente en el icono de la cmara empl azado en la esquina superior izquierda de la
pantalla.
El bocet o del formato que se muestra tendra que complementarse con una ex-
pansin de cada el ement o de men dentro de la barra de mens, indicando cules
acciones estn disponibles para el modo de monitoreo de video (estado). Durante la
etapa de diseo de la interfaz se creara un conjunto completo de bocet os para ca-
da tarea de propietario anotada en el escenario del usuario.
12.4.2 Patrones de diseo de la interfaz de usuario
Las interfaces grficas de usuario sofisticadas se han vuelto tan comunes que ha sur-
gido una amplia variedad de pat rones de diseo de interfaces de usuario. Como se
observ al principio de este libro, un patrn de diseo es una abstraccin que pres-
cribe una solucin de diseo a un problema de diseo especfico, bien delimitado.
Cada uno de los pat rones de ejemplo (y t odos los pat rones de cada categora) pre-
sent ados en el recuadro siguiente tambin tendra un diseo completo al nivel de
component es, incluidos clases, atributos, operaciones e interfaces de diseo.
Un anlisis completo de los pat rones de interfaz de usuario est ms all del al-
cance de est e libro. El lector interesado debe consultar IDUY02J, (BOROl], [WEL011 y
[TID02] para conocer ms informacin.
TM
PDF Editor
372
I N F O R MA C I N
Patrones de interfaz de usuario
En las ltimas dcadas se han propuesto cien-
tos de patrones de interfaz de usuario. Tidwell
[TID02] y Van Welie [WEL01] proporcionan taxonomas9
de los patrones de diseo de interfaz de usuario que se
han or gani zado en 10 categoras. En este recuadro se pre-
sentan patrones de ejemplo de cada una de estas catego-
ras.
I nt erf az d e us ua r i o c o mp l e t a . Proporciona lneas
generales de diseo par a estructura y navegacin de alto
nivel.
Pat r n: navegacin de alto nivel
Des cri pci n br e v e : Proporciona un men de alto nivel,
a menudo acopl ado a un logotipo o una imagen de
identificacin que permite la navegacin directa a cual-
quiera de las principales funciones del sistema.
Di s e o d e p g i n a . Atiende la organizacin general
de las pgi nas (para sitios Web) o distintos despliegues de
pantalla (para aplicaciones interactivas).
Pat r n: pila de carias
Des cri pci n br e v e : Proporciona el aspecto de una pila
de cart as con pestaas; par a seleccionarlas se hace di c
en cada una de ellas, que representa subfunciones es-
pecficas o categoras de contenido.
For mul ar i os y e nt r a d a . Toma en cuenta diversas
tcnicas de diseo par a completar ent radas al nivel de for-
mularios.
Pat rn: llene los espacios en blanco
Des cri pci n br e ve : Permite el ingreso de dat os alfanu-
mricos en un "cuadro de texto".
Tabl as . Proporciona gua de diseo par a la creacin y
manipulacin de todo tipo de datos tabulares.
Pat rn: lab/a que permite su ordenacin
Des cri pci n br e v e : Despliega una larga lista de regis-
tros que se ordenan al seleccionar un mecanismo inte-
rruptor par a cualquier etiqueta de la columna.
Ma ni pul a c i n di rect a d e d a t o s . Atiende la edi-
cin, modificacin y transformacin de datos.
i Pat r n: migas de pan
Des cri pci n br e ve : Proporciona una ruta completa de
navegacin cuando el usuario est trabajando con une
jerarqua completa de pginas o pantallas de despl i ega
Na v e g a c i n . Ayuda al usuario en el recorrido de rre
ns jerrquicos, pgi nas Web y pantalla de despliegue -
teractivo.
Pat r n: edicin en el lugar
Des cri pci n br e v e : Proporciona la capaci dad de e c
cin simple de textos par a ciertos tipos de conten de sr
el lugar en que se despliega.
B s q ue d a . Permite bsquedas de contenido e s p e d a
mediante la informacin mantenida en un sitio Web o zzr-,
tenida en al macenes persistentes de datos que estn
sibles par a una aplicacin interactiva.
Pat r n: bsq ueda simple
Des cri pci n br e ve : Proporciona la capaci dad de
car, en un sitio We b o una fuente de datos persiss
un elemento simple de dat os descrito por una cod
alfanumrica.
El e me nt os d e p g i n a Implemento elementos
eos de un pgi na Web o pantalla de despliegue.
Pat rn: asistente
Des cri pci n br e v e : Lleva al usuario paso a paso
una tarea compleja, proporci onando guas par e
pletar la tarea mediante una serie de ventanas
Come r c i o e l e c t r ni c o Especficos de sitios Web
patrones implementan elementos recurrentes de
nes de comercio electrnico.
Pat r n: carrito de compras
Des cri pci n br e v e : Proporciona una lista de
seleccionados en una compra.
Var i os Patrones que no caben fcilmente en las
ras anteriores. En algunos casos, estos patrones
del dominio u ocurren par a clases especficas de
Pat rn: indicador de programa
Des cri pci n br e v e : Proporciona una i ndi cados
greso cuando se est real i zando una operocicr
12.4.3 Temas de diseo
A medida que evoluciona el di seo de una interfaz casi siempre surgen cuat r: i
comunes: t i empo de respuest a del si st ema, funci ones de ayuda para el
nej o de informacin de error y rotulado de comandos. Por desgracia, m
9 En [T1D02] y [WEL01] se encont rarn descri pci ones de pat r ones compl et os (junto cor.
ot ros patrones).
TM
PDF Editor
C A P I T U L O 1 2 DISEO DE LA INTERFAZ DE USUARIO 373
fiadores no prest an at enci n a est os t emas hast a una et apa rel at i vament e tarda del
proceso de di seo (en ocasi ones el primer at i sbo de un probl ema se present a hast a
que se di spone de un prototipo operacional). Como resultado, a veces se tiene itera-
cin i nnecesari a, demor as del proyect o y frustracin del cliente. Es mucho mej or
abordar cada uno como el ement o de di seo y t omarl o en cuent a al principio del di-
seo de soft ware, cuando los cambi os son fciles y el cost o es baj o.
"Un error comn que comete lo gent e cuando t rat o de diseor al go o prueba de t ont os es subestimar la ingenuidad de
los ver dader ament e tontos."
D o u g k s Ada ms
Ti empo de res pues t a. El t i empo de respuest a del si st ema es la pri mera quej a so-
bre muchas apl i caci ones interactivas. En general, se mi de desde el punt o en que el
usuari o realiza al guna accin de control (como oprimir la tecla Return o hacer clic
con el ratn) hast a que el sof t war e responde con la salida o la accin deseada.
El t i e mpo de res pues t a del s i s t ema t i ene do s caract er st i cas i mport ant es:
duraci n y vari abi l i dad. Si la respuest a del si st ema s e demora mucho, la frustra-
cin y el est rs del usuari o son inevitables. Variabilidad es la desviacin del t i empo
de respuest a promedi o y, en muchos sent i dos, es la caracterstica ms i mport ant e
del t i empo de respuest a. Una baj a variabilidad permi t e que el usuari o est abl ezca un
ritmo de interaccin, aunque el t i empo de respuest a sea rel at i vament e largo. Por
ej empl o, una respuest a de 1 segundo a un comando a menudo ser preferible a una
respuest a que vara de 0.1 a 2. 5 segundos. Cuando la variabilidad es significativa, el
usuari o si empre se encont rar fuera de bal ance, si empre se pregunt ar si ha ocurri-
do al go "diferente" t ras bastidores.
Funci ones de ayuda. Casi t odos los usuari os de un si st ema de cmput o interac-
tivo necesi t an ayuda de vez en cuando. En al gunos casos, bast a con una si mpl e pre-
gunt a dirigida a un colega con experiencia. En ot ros, tal vez la nica opcin sea una
investigacin det al l ada en un conj unt o de varios vol menes de "manual es de usua-
rio". Sin embargo, en casi t odos los casos el soft ware moder no proporci ona funcio-
nes de ayuda en lnea que permi t en al usuari o obt ener una respuest a a sus pregun-
t as o resolver un probl ema sin dej ar la interfaz.
Deben at ender se varios t emas de di seo [RUB88] cuando s e t oma en cuent a una
opcin de ayuda.
La ayuda est ar disponible para t odas las f unci ones del si st ema y en t odo
moment o dur ant e la interaccin con ste? Entre las opci ones se incluye ayuda
slo para un subconj unt o de t odas las f unci ones y acci ones o ayuda para to-
das las funci ones.
Cmo necesi t ar la ayuda el usuari o? Entre las opci ones se incluyen men
de ayuda, una tecla especial de funcin o un comando AYUDA.
TM
PDF Editor
374
Cmo se represent ar la ayuda? Las opci ones son una vent ana separada,
una referencia a un document o i mpreso (menos que ideal) o una sugerencia
de una o dos lineas que aparece en un lugar fijo de la pantalla.
Cmo regresar el usuari o a la interaccin normal ? Entre las opci ones se ir-
cluyen un bot n de regreso despl egado en la pant al l a, una tecla de funcin :
una secuenci a de control.
Cmo se est ruct urar la i nformaci n de ayuda? Las opci ones son una estro;
tura "plana" en que se tiene acceso a toda la i nformaci n con el teclado, ur a
j erarqu a en capas de i nformaci n que proporci ona detalles creci ent es a me
dida que el usuari o la recorre, o el uso de hipertexto.
Manej o de errores. Los mensaj es de error y los avi sos de precauci n son
noticias" que se ent regan a los usuari os de si st emas interactivos cuando algo sale i
En el peor de los casos, los mensaj es de error y los avisos de precaucin ofrece-
formacin intil o que puede malinterpretarse y que sl o sirve para aument ar la
tracin del usuario. Algunos usuari os de comput adora han encont rado un error 3r i
forma "La aplicacin XXX se ha visto forzada a cerrarse porq ue se ha encontrado un
del tipo 1023". En algn lugar debe existir una explicacin del error 1023; de lo
rio, por qu habran asi gnado los di seadores ese identificador? Sin e mba ; : 4
mensaj e de error no proporciona una indicacin real de lo que est uvo mal ni de
de buscar la informacin adicional. Un mensaj e de error pr esent ado de esta
no hace nada por aliviar la ansi edad del usuario ni ayuda a corregir el problema
" Lo i n t e r f a z con el infierno: ' Poro corregir este error y seguir adelante, escribo cualquier nmero primo de 1 1 : :
l os . . . "
Aut or a o M
?
Qu
caract er s t i cas
de be t e ne r un
" bue n" me ns a j e
de error?
En general, t odo mensaj e de error o aviso de precauci n que produzca un s f l
ma interactivo debe t ener las si gui ent es caractersticas:
El mensaj e debe describir el probl ema en un l enguaj e que el usuari o er
El mensaj e debe proporci onar consej os const ruct i vos sobre la maner a JT -i
cuperarse del error.
El mensaj e debe indicar cualquier consecuenci a negativa del error (por e - t r J
la posibilidad de que se corrompan los archivos de datos) para que el USUL-J
asegure que no han ocurrido (o para que los corrija si ya ocurrieron).
El mensaj e debe acompaase de una pista visual o auditiva. Es decir c a J
nerarse un bip j unt o con el despliegue del mensaj e, o st e debe pa r pa cea r l
moment neament e o despl egarse en un color que se reconozca f c i l i r =*i
como "color de error".
El mensaj e no debe cont ener juicios. Es decir, la redacci n nunca debc . H
al usuari o.
TM
PDF Editor
CAP TULO 12 DISEO DE LA INTERFAZ DE USUARIO
3 7 5
Como a nadie le gust an las mal as noticias, a pocos usuari os le gust arn los mensa-
j es de error, sin importar lo bien di seados que est n. Pero un enf oque adecuado pa-
ra los mensaj es de error har mucho por mej orar la calidad de un si st ema interacti-
vo y reducir de maner a i mport ant e la frustracin del usuari o cuando ocurran ios
probl emas.
Rot ul aci n de me ns y c omandos . El comando de texto escrito f ue al guna vez
el modo ms comn de interaccin entre los usuari os y el soft ware del si st ema y se
usaba en aplicaciones de t odo tipo. Hoy el uso de i nt erfaces ori ent adas a vent anas,
con opcin de seal ar y elegir, ha reduci do la dependenci a de los comandos escri-
tos, pero muchos usuari os avanzados an prefieren est e tipo de interaccin. Varios
t emas de di seo surgen cuando s e proporci onan comandos de texto o et i quet as de
men como modo de interaccin:
e sitio
ranfrar l
des
www. 3.
/ obl e/
*/
/ J
o r s software.
Cada opcin de men tiene un comando correspondi ent e?
Qu forma t endrn los comandos? Entre las opci ones se incluyen una se-
cuenci a de control (como alt-P), teclas de funcin o pal abras escri t as por el
usuario.
Qu tan difcil ser apr ender y recordar los comandos? Qu puede hacerse
si se olvida un comando?
El usuari o tiene la opcin de personal i zar o abreviar los comandos?
Las et i quet as de los mens se explican por s sol as dent r o del cont ext o de la
interfaz?
Los s ubmens son consi st ent es con la funcin indicada en un el ement o prin-
cipal del men?
Como se indic al principio de est e captulo, es necesari o definir convenci ones para
usar comandos en t oda la aplicacin. Es conf uso para el usuari o y a menudo lo lle-
va a comet er errores escribir alt-D cuando desea duplicar un obj et o grfi co en una
aplicacin y alt-D cuando quiere deshacer una accin en otra. Es obvio que est o pro-
piciar errores.
Accesi bi l i dad de la apl i caci n. A medida que las aplicaciones de comput adora
se vuelven ubicuas, los i ngeni eros de soft ware deben asegurarse de que el di seo de
la i nt erfaz t enga mecani smos que permi t en un fcil acceso a qui enes tienen necesi-
dades especiales. La accesibilidad es un i mperat i vo moral , legal y comercial para los
usuari os (e i ngeni eros de soft ware) que t i enen probl emas fsicos. Diversas lneas ge-
neral es de accesibilidad (por ej empl o, [W3C03]), muchas di seadas para aplicacio-
nes Web, pero a menudo aplicables a cualquier soft ware, proporci onan sugerenci as
det al l adas para el di seo de i nt erfaces que al canzan di ferent es grados de accesibili-
dad. Otros (como [APP03], [MIC03]) proporci onan lineas general es espec fi cas para
"tecnologa asistencial" que at i ende las necesi dades de qui enes tienen di scapaci da-
des visuales, auditivas, de movilidad, del habl a o de aprendi zaj e.
TM
PDF Editor
3 7 6 P A S T E D O S PRCTICA DE LA INGENIERA DEL SOFTWARE
Internaci onal i zaci n. Los i ngeni eros de sof t ware y sus admi ni st radores subesti
man invariablemente el esf uerzo y las habilidades necesari as para crear interfases
de usuario que atiendan las necesi dades de usuari os de ot ras localidades o que ha
blan diferentes idiomas. Con demasi ada frecuencia, las i nt erfases se di sean para
una localidad y un idioma y luego se espera que funci onen en ot ros pases. El rete
para los di seos de interfases es crear sof t ware "globalizado"; las interfaces de usua
rio deben di searse para cont ener un ncl eo genri co de funci ones que se entreguer
a t odos los usuarios. Caractersticas adicionales de localidad permiten a la interfa:
personal i zarse para un mer cado especfico.
Los ingenieros de soft ware cuent an con varias paut as para la internacionaliza
cin (como [IBM03]). Estas paut as at i enden amplios probl emas de di seo (como la;
diferencias en format o de pantalla en varios mercados) y t emas discretos de imple
mentacin (por ejemplo, diferentes al fabet os pueden crear rotulacin y requisitos de
espaci o especiales). El est ndar Unicode [UNI03]) se ha desarrollado para at ender e
desal ent ador desafi o de manej ar docenas de idiomas nat ural es con ci ent os de cara;
t eres y smbolos.
Desarrollo de interfases de usuario

Obj e t i vo. Estas herramientas le permiten a un
ingeniero de software crear una sofisticada in-
terfaz grfica de usuario empl eando relativamente escaso
desarrollo de software personalizado. Las herramientas pro-
porcionan acceso a componentes reutilizables y convierte la
creacin de una interfaz en una seleccin entre opciones
predefinidas que se ensamblan mediante la herramienta.
Me c ni c a . Las interfases de usuario modernas estn
construidas con un conjunto de componentes reutilizables
acopl ados con algunos componentes personalizados desa-
rrollados par a proporci onar funciones especializadas. Ca-
si t odas las herramientas de desarrollo de interfases de
usuario permiten que el ingeniero de software cree una in-
terfaz empl eando opciones de "arrastrar y colocar"; es de-
cir, el desarrollador selecciona entre opciones predefinidas
(por ejemplo, constructores de formularios, mecanismos de
interaccin, capaci dad de procesamiento de comandos) y
coloca esas opciones en el contenido de la interfaz que ha-
br de crearse.
Herramientas de representacin1
Macromedia Authorware, desarrol l ado por Macromedia
Inc. (www. macromedi a. com/ soft ware/ ), se ha disea-
do par a la creacin de interfases y entornos de apren-
di zaj e electrnico. Emplea caractersticas sofisticadas
de construccin.
Motil Common Desklop Environment, desarrollado por The
Open Group (www. osf. org/ t ech/ deskt op/ cde/ ), es
una interfaz grfica de usuario integrada par a siste-
mas abiertos de computacin de escritorio. Entrega
una interfaz grfica simple, estndar, par a la adminis-
tracin de datos, archivos y aplicaciones.
PowerDesigner/PowerBuilder, desarrollado por Sybase
(www. sybase/products/internetappdevtools), es un
conjunto muy completo de herramientas CASE, que in-
cluyen muchas opciones par a el diseo y la construc-
cin de interfases grfi cas de usuario.
10 Las herramientas expuestas aqu slo representan una muestra de esta categora. En casi todos
casos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.
TM
PDF Editor
1 2 . 5 E V A L U A C I N PE , DI S E O
Una vez que se ha creado un prototipo de interfaz de usuari o operaci onal , debe eva-
l uarse y det ermi nar si sat i sface las necesi dades del usuario. La eval uaci n puede
abarcar un espect ro de grados de formalidad que va desde una "prueba de manej o"
informal, en la cual un usuari o proporci ona ret roal i ment aci n informal, hast a un es-
tudio di seado formal ment e, el cual empl ea mt odos est ad st i cos para la evaluacin
de cuest i onari os que llena una poblacin de usuari os finales.
El ciclo de eval uaci n de la interfaz de usuari o as ume la forma most r ada en la fi-
gura 12.4. Despus de compl et ado el di seo se crea un prot ot i po de pri mer nivel. A
cont i nuaci n, el usuari o evala est e pr ot ot i po" y hace coment ar i os di rect os al dise-
ador acerca de la eficacia de la interfaz. Adems, si se utilizan t cni cas formal es de
eval uaci n (por ejemplo, cuestionarios, hoj as de evaluacin), es probabl e que el di-
seador obt enga i nformaci n de est os dat os (por ej empl o, del 80 al 100 por ci ent o
de los usuari os rechaza el mecani smo para guardar archi vos de datos). Las modifi-
caci ones al di seo se hacen basndose en la i nformaci n que proporci ona el usua-
rio, y as se crea un prototipo de segundo nivel. El ciclo de la eval uaci n cont i na
hast a que ya sean i nnecesari as ms modi fi caci ones al di seo de la interfaz.
d e
Sn
~' erlqz.
Se real i zan
modificaciones
al di seo
Diseo
preliminar
Diseo de interfaz
completo
El di seador
estudia
la evaluacin
11 Es importante notar que los expertos en diseos ergonmomico y de interfaz tambin pueden diri-
gir revisiones de la interfaz. Dichas funciones se llaman evaluaciones heursticas o ensayos cogni-
tivos.
TM
PDF Editor
El enfoque de creacin de prototipos resulta eficaz, pero es posible evaluar la ca-
lidad de una interfaz de usuario ant es de construir un prototipo? Si se descubren po-
sibles problemas y se corrigen en las primeras etapas, se reducir el nmero de bu-
cles en el ciclo de evaluacin y se acortar el tiempo de desarrollo. Si se ha cread:
un modelo de diseo de la interfaz, es posible aplicar varios criterios de evaluacir
[MOR81) en las primeras revisiones del diseo:
1. La longitud y complejidad de la especificacin escrita del sistema y su interfaz
indican la cantidad de aprendizaje necesario para los usuarios del sistema.
2. El nmero especificado de tareas del usuario y el promedio de acciones por
tarea indican el tiempo de interaccin y la eficacia global del sistema.
3. La cantidad de acciones, tareas y est ados del sistema que indica el modelo
diseo se relaciona con la carga de memoria que recae en los usuarios del
sistema.
4. El estilo de la interfaz, las funciones de ayuda y el protocolo de manej o de
errores indican en forma general la complejidad de la interfaz y el grado de
aceptacin del usuario.
Una vez construido el primer prototipo, el diseador puede recopilar diversos dat
cualitativos y cuantitativos que ayudarn a evaluar la interfaz. Para recopilar los
t os cualitativos se pueden distribuir cuestionarios entre los usuarios del prototip:
con preguntas que arrojan: 1) respuesta simple si / no, 2) respuesta numrica, 3) re
puesta con escala de valoracin (subjetiva), 4) escala de Likert (por ejemplo, cor-
pletamente de acuerdo, un poco de acuerdo), 5) respuesta con porcentajes (subje:
va) o 6) respuesta abierta.
Si se desean datos cuantitativos, puede aplicarse una forma de anlisis de es: -
dio del tiempo. Se observa a los usuarios durante la interaccin y se usan los da::-;
(como el nmero de tareas completadas correctamente en un periodo estndar, fre
cuencia y secuencia de acciones, tiempo que pasa "mirando" la pantalla, nmer
tipo de errores, tiempo de recuperacin de errores, tiempo dedicado al uso de la a;
da y cantidad de referencias de ayuda por periodo estndar) como gua para la
dificacin de la interfaz.
Un anlisis completo de los mt odos de evaluacin de la interfaz de usuario :
basa el alcance de este libro. Se puede consultar ms informacin en [LEA&i]
[MAN97] y [HAC98J.
Es posible afirmar que la interfaz de usuario es el el ement o ms importante de
sistema o producto de cmputo. Si la interfaz est mal diseada la capacidad
usuario se ver muy reducida para aprovechar las vent aj as de una aplicacin
efecto, una interfaz dbil puede llevar al fracaso una aplicacin bien diseada y <
una implementacin slida.
TM
PDF Editor
Tres principios importantes guan el diseo de una interfaz de usuario efectiva: 1)
dar ei control al usuario, 2) reducir la carga en la memoria del usuario, y 3) lograr
que la interfaz sea consistente. Construir una interfaz que cumpla con est os princi-
pios requiere desarrollar un proceso de diseo organizado.
El diseo de la interfaz de usuario comienza con una serie de tareas de anlisis.
Entre st as se encuent ra identificacin del usuario, tarea y anlisis y modificacin de
la tarea y el entorno. El anlisis del usuario define los perfiles de varios usuarios fi-
nales y aplica informacin recopilada de diferentes fuent es de negocios y tcnicas.
El anlisis de t areas define las tareas y acciones del usuario empl eando un enfoque
elaborativo u orientado a objetos, aplicando casos de uso, elaboracin de tareas y
objetos, anlisis de flujo de t rabaj o y representaciones jerrquicas de t areas para
comprender pl enament e la interaccin ser humano-comput adora. El anlisis am-
biental identifica las estructuras fsica y social en que debe operar la interfaz.
Una vez identificadas las tareas, se crean y analizan los escenari os para definir un
conjunto de objetos y acciones de la interfaz. Esto proporciona la base para la crea-
cin del formato de pantalla, que representa el diseo grfico y la ubicacin de los
iconos, la definicin de un texto descriptivo en pantalla, la especificacin de las ven-
t anas y la asignacin de ttulos a stas, adems de la especificacin de los el emen-
tos primarios y secundarios del men. Mientras se refina el modelo de diseo, deben
t omarse en cuenta t emas relacionados con el diseo, como tiempo de respuesta, es-
tructura de comandos y acciones, manej o de errores y funciones de ayuda. El usua-
rio dispone de varias herrami ent as de implementacin para construir un prototipo
que l mismo puede evaluar.
IAPP031 Apple Computer, Pcople with Special Needs, 2003, disponible en ht t p: / / www. appl e. com/
disability/.
[BAR01] Borchers,)., A Pattern Approach to Interaction Design, Wiley 2001.
[CON95] Constantine, L. "What DO Users Want? Engineering Usability in Software", en Windows Tech
joumal, diciembre de 1995, disponible en http://www.forUse.com.
1DON99J Donahue, G., S. Weinschenck y J. Nowicki, "Usability is Good Business", Compuware
Corp., julio de 1999, disponible en ht t p: / / www. compuware. com.
[DUY021 vanDuyne, D., J. Landay y J. Hong, The design of Sites, Addison-Wesley, 2002.
[HAC98] Hackos, J. y J. Redish, User and Task Analysis for Interface Design, Wiley, 1998.
[1BM03] IBM, Overview ofSoftware Glohalization, 2003, disponible en http://oss. software. ibm. com
/ i cu/ usergui de/ 118n. ht ml .
[LEA88] Lea, M., "Eval uat i ng User Interfaces Designs", en User Interface Design for Computer
Systems, Halstead Press (Wiley), 1988.
[MAN97| Mandel, T The Elements of User Interface Design, Wiley, 1997.
IMIC03] Microsoft Accesability Technology for Eveiyone, 2003, disponible en ht t : / / www. mi cr o-
sofl . com/ enabl e/ .
[MON84] Monk, A. (ed), Fundamentis of Human Computer Interaction, Academic Press, 1984.
[MOR811 Moran, T. P., "The Command Language Grammar: A Representation for the User Interfa-
ce of Interactive Computer Systems", en Intl Joumal of Man-Machine Studies, vol. 15, pp. 3-50.
[NIEOO] Nielsen, Designing Web Usability, New Riders Publishing, 2000.
[NOR86| Norman, D. A., "Cognitive Engineering en User Centered Systems Design, Lawrence
Earlbaum Associates, 1986.
TM
PDF Editor
380
[RUB88] Rubin, T.. User Interface Design for Computer Systems, Haldstead Press (Wiley), 1988.
[SHN90] Shneiderman, B.. Designing the User Interface, Addison-Wesley, 3a. ed., 1990.
[TID991 Tidwel l , ). , "Common Ground A Pattern Language for HC1 Design ", disponible er
http://www.mit.edU/@jtidwell/interaction_pattems.html, mayo de 1999.
[TID02] Ti d we l l , " I U Patterns and Techniques", disponible en http://time. tripper. com/uip. ;
terns/index.html, mayo de 2002.
[UN103] Unicode Inc., The Unicode Home Page, 2003, disponible en ht t p: / / www. uni code. org
IW3C031 World Wide Web Consortium, Web Conten Accesability Guidelines, 2003, disponible er
http://www. w3. org/TR/2003/Word-WCAG20-20030624/.
[WEL01] vanWelle M., ' Interaction Design Patterns", disponible en ht t p: / / www. wel i e. com/ pi
t ems / , 2001.
12. 1. Describir la mejor y la peor interfaz con que se haya t rabaj ado al guna vez y critiquer - -
en relacin con los conceptos presentados en est e captulo.
12. 2. Desarrollar dos principios de diseo adicionales que "den el control al usuario".
12. 3. Desarrollar dos principios de diseo adicional es que "reduzcan la carga en la memor
del usuario".
12. 4. Desarrollar dos principios de diseo adi ci onal es que "logren una interfaz consisten:-.
12. 5. Se ha pedido desarrollar un sistema de banco en casa para Web; desarrollar los mode -i
del usuario, del diseo y mental y la implementacin.
12. 6. Realizar un anlisis detal l ado de t areas para el si st ema del probl ema 12.5. Utilizar
enfoque elaborativo u orientado a objetos.
12. 7. Agregar por lo menos cinco pregunt as adicionales a la lista desarrollada para el anSsa
de contenido de la seccin 12.3.5.
12. 8. Siguiendo con el problema 12.6, definir objetos y acciones de interfaz para la apl i cao \
Identificar cada tipo de objetos.
12. 9. Desarrollar un conjunto de formatos de pantalla con una definicin de el ement os pri r. -
pales y secundarios del men para el sistema del problema 12.5.
12. 10. Desarrollar un conjunto de formatos de pantalla con una definicin de los elemer -
principales y secundarios del men para el sistema HogarSeguro. Es posible aplicar un enfoque (fce-
rente del que se muestra para el formato de pantalla en la figura 15.3.
12. 11. Describir un enfoque propio de las funci ones de ayuda del usuario para el anlisis
tareas que se hayan realizado como parte del problema 12.5.
12. 12. Proporcionar algunos ejemplos que ilustren por qu debe tomarse en cuenta la var - aj
bilidad del tiempo de respuesta.
12. 13. Desarrollar un enf oque que integre aut omt i cament e los mensaj es de error y i
funcin de ayuda para el usuario. Es decir, que el si st ema reconozca aut omt i cament e el l
de error y proporcione una vent ana de ayuda con sugerencias para corregirlo. Realizar un <
o de soft ware razonabl ement e completo que tome en cuent a las estructuras de dat os y 1
goritmos apropiados.
12. 14. Desarrollar un cuestionario de eval uaci n de i nt erfaces que cont enga 20 pregur
genri cas aplicables a la mayor part e de l as interfaces. Pdase que 10 compaer os de cfc
completen el cuestionario para un sistema interactivo que todos usen. Resumir los resultadc -
informar de ellos a su clase.
Aunque su libro no se relaciona especficamente con interfaces ser humano-comput adora,
cho de lo que Donald Norman (The Design o/Eveiyday Things, edicin reimpresa, Currency/C
TM
PDF Editor
bleday, 1990) tiene que decir sobre la psicologa de un diseo efectivo se aplicar a las interfa-
ces de usuario. Es una lectura recomendada para cualquier persona que tome con seriedad el
diseo de interfaces de alia calidad.
Las interfaces grficas del usuario son ubicuas en el mundo moderno de la computacin. Ya
sea empleada por un cajero automtico, un telfono mvil, una PDA, un sitio Web o una apli-
cacin de negocios, la interfaz de usuario proporciona una vent ana al software. Por ello, abun-
dan los libros sobre el diseo de interfaces. Todos los siguientes libros tratan sobre facilidad de
uso, conceptos de interfaz de usuario, principios y tcnicas de diseo, adems de que contienen
muchos ejemplos tiles: Galitz (The Essential Guide to User interface Design, Wiley, 2002), Coo-
per (About Face 2.0: The Essentials of User Interface Design, 1DG Books, 2003), Beyer y Holtzblatt
(Contextual Design: A Costumer Centered Approach to Systems Design, Morgan-Kaufmann, 2002),
Raskin (The Human Interface, Addison-Wesley, 2000), Constantine y Lockwood (Softwarefor Use,
ACM Press, 1999) y Mayhew (The Usability Engineering Ufecyctc, Morgan-Kaufmann, 1999).
Johnson (GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers, Morgan-
Kaufmann, 2000) proporciona una gua til para qui enes aprenden mejor al examinar contrae-
jemplos. Un libro que se disfruta, de Cooper (The Inmates Are Running the Asylum, Sams Publis-
hing, 1999), analiza por qu los productos de alta tecnologa nos atraen y la manera de disear
unos que no lo hagan.
El anlisis y modelado de tareas son actividades fundament al es del diseo de interfaces.
Hackos y Redish [HAC98] han escrito un libro dedicado a estos t emas y proporcionan un mto-
do detallado para concentrarse en el anlisis de tareas. Wood (User Interface Design: Bridging the
Gap from User Requirements to Design, CRC Press, 1997) aborda la actividad de anlisis para in-
terfaces y la transicin a las tareas de diseo.
La actividad de evaluacin se concentra en la facilidad de uso. Los libros de Rubin (Hand-
book of Usability Testing; How to Plan, Design, and Conduct Effective Tests, Wiley, 1994) y Nielsen
(Usability Inspection Methods, Wiley, 1994) abordan el t ema con gran detalle.
En un libro nico, que podra parecer muy interesante a los diseadores de producto, Murphy
(Front Panel: Designing Softwarefor Embedded User Interfaces, R&D Books, 1998) ofrece una gua
detallada para el diseo de interfaces destinadas a sistemas incrustados y aborda los peligros
de seguridad inherentes a los controles, el manej o de maquinaria pesada y las inlerfaces para
si st emas mdicos o de transporte. El diseo de la interfaz para productos incrustados tambin
se estudia en el libro de Garrett (Advanced Instrumentation and Computer l/O Design: Real-Time
System Computer Interface Engineering, IEEE, 1994).
En Internet se encuentra una amplia variedad de fuentes de informacin sobre el diseo de
la interfaz de usuario. Una lista actualizada de referencias en la World Wide Web relevantes pa-
ra el diseo de la interfaz de usuario se encuentra en el sitio Web SEPA:
TM
PDF Editor
C A P T U L O
13
L
CONCEP TOS
CLAVE
cr i t er i os de
fi nal i zaci n . . . . 3 8 9
depur aci n . . . . 4 0 9
especi fi caci n
de pr ue ba . 401
e s t r a t e gi a
c o n v e n c i o n a l . . . 3 8 6
e s t r a t e gi a
or i e nt a da
a o b j e t a s . . 4 0 2
GIP . 3 8 6
pr ueba
d e humo . . 3 9 9
pr ue ba de
i nt egr aci n . . . . 3 9 4
pr ue ba de
r egr es i n . . . . . 3 9 8
pr ueba de
uni dad . . . . . . 3 9 2
pr ue ba de
val i daci n . . . . . 4 0 4
pr ue ba del
s i s t ema . . . . . . 4 0 6
p r u e b a s a l f a /
. . 4 0 5
VyV . . 3 8 4
ESTRATEGI AS DE PRUEBA
DEL SOFTWARE
U
na est r at egi a de pr ue ba del s of t wa r e i nt egr a l os m t odos de di s eo c :
c a s o de pr ue ba s del s of t war e en una seri e bi en pl a ne a da de pa s os que d :
s e mboc a r e n la ef i caz cons t r ucci n de s of t war e. La est r at egi a propc
ci ona un ma p a q u e descr i be l os pa s os que se dar n c o mo par t e de la pr uet -
i ndi ca c u ndo s e pl a ne a n y c u ndo s e dan e s t os pas os , a d e m s de c u nt o e-
f uer zo, t i empo y r ecur s os cons umi r n. Por t ant o, cual qui er est r at egi a de pr uer
debe i ncor por ar la pl aneaci n de pr uebas , el di s e o de c a s o de pr uebas , l a eje
cuci n de pr ue ba s y la r ecol ecci n y eval uaci n de l os da t os r esul t ant es.
Una est r at egi a de pr ue ba del s of t wa r e de be ser lo s uf i ci ent ement e flexit :
c o mo par a pr omover un enf oque per s onal i zado. Al mi s mo t i empo, debe ser
a de c ua da me nt e r gi do c o mo pa r a pr omove r u n a pl aneaci n r azonabl e y L-I
s egui mi ent o admi ni st r at i vo del a va nc e del pr oyect o. Sh o o ma n [SH083] ana!
es t os t emas :
En muchos sentidos, la prueba es un proceso autnomo, y el nmero de tipos dife-
rentes de pruebas varia tanto como los diferentes enfoques de desarrollo. Durante
muchos aos, la nica defensa contra los errores de programacin fueron el diseo
cuidadoso y la inteligencia natural del programador. Ahora estamos en la era en que
las tcnicas modernas de diseo (y las revisiones de las tcnicas formales] nos estar,
ayudando a reducir el nmero de errores iniciales inherentes al cdigo. De manera si-
milar, diferentes mtodos de prueba estn empezando a apilarse en varios mtodos
y filosofas distintos.
Est os " enf oques y filosofas" conf or man l o que s e de nomi na est r at egi a. En rl
cap t ul o 14 s e pr e s e nt a r la t ecnol og a de pr ueba del s of t war e. Ese cap t ul o s:
concent r ar en la est r at egi a de la pr ue ba del s of t war e.
Qu es? El software se prueba pa-
ra descubrir errores cometidos sin
darse cuenta al realizar su diseo y
construccin. Pero cmo se realizan
las pruebas? Debe desarrollarse un
plan formal para las pruebas? Debe probarse
el programa como un todo o s b deben aplicar-
se pruebas a una parte pequea? Deben volver
a realizarse las pruebas ej ecut adas a medida
que se agregan nuevos componentes a un sistema
de gran tamao? Cundo debe pedirse la par-
ticipacin del cliente? stas y muchas otras pre-
guntas se respondern cuando desarrolle una es-
trategia de prueba del software.
Qui n l o ha c e ? El efe de proyecto, los ingenie-
ros de software o b s especialistas en pruebe;
son quienes desarrollan la estrategia par a le
prueba del software.
Por q u e s i mpo r t a nt e ? Con frecuencia, b
prueba requiere una mayor cantidad del esfue-
zo dedi cado al proyecto que cualquier otra act
vidad de ingeniera del software. Si se realizc
3*2
TM
PDF Editor
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOFTWARE
383
n un plan, se desperdicia tiempo, se dedica un
esfuerzo innecesario y, an peor, es posible que
no se detecten errores. Por tanto, lo razonabl e
sera establecer una estrategia sistemtica par a
o-obar el software.
"les s o n l os p a s o s ? La prueba empieza
oor lo "pequeo" y avanzo hacia lo "grande".
Esto significa que, en las primeras etapas, la
: -ueba se concentra en un s ob componente o
TT un grupo pequeo de componentes relacio-
- xl os y se aplica par a descubrir errores en la
:gica de datos y del procesamiento que se ha
encapsul ado en el componente. Una vez proba-
: 3S los componentes, deben integrarse hasta
: j e todo el sistema se haya construido. En este
: jnto se ejecuta una serie de pruebas de alto ni-
-I para descubrir errores en la satisfaccin de
es requisitos del cliente. A medida que se des-
cubren. los errores deben diagnosticarse y corre-
girse empleando un proceso llamado depuracin.
Cul e s el product o obt eni do? Una Especi-
ficacin de la prueba documenta el enfoque que
aplic el equipo de software a la prueba al de-
finir un plan que detalla una estrategia general
y un procedimiento que describe los pasos espe-
cficos que se darn y las pruebas que habr n
de realizarse.
Cmo p u e d o es t ar s e g ur o de que l o he
he c ho c o r r e c t a me nt e ? Al revisar la Especi-
ficacin de la prueba antes de realizarla se eva-
la s estn completos los casos y las tareas de
prueba. Un plan y un procedimiento de prueba
efectivos llevarn a la construccin ordenada del
software y al descubrimiento de errores en cada
et apa del proceso de construccin.
1 3 . 1 U N ENF OQUE ESTRATGI CO PARA LA PRUEBA DEL SQFTWAPF.
La prueba es un conj unt o de act i vi dades que se pl anean con anticipacin y se reali-
zan de maner a si st emt i ca. Por t ant o, se debe definir una plantilla para l as pruebas
del soft ware (un conj unt o de pasos en que se puedan incluir t cni cas y mt odos
especficos del di seo de casos de prueba).
Se han propuest o vari as est rat egi as de prueba del sof t war e en distintos libros;
t odas proporci onan al desarrol l ador del soft ware una plantilla para pr uebas y t odas
tienen l as si gui ent es caract er st i cas genri cas:
sitio
ent rarn
s para lo
i aturare:
" . e d u /
Para realizar pr uebas efectivas un equi po de soft ware debe efect uar revi-
si ones t cni cas formal es y efectivas (captulo 26). Esto el i mi nar muchos
errores ant es de que empi ece la prueba.
La prueba comi enza al nivel de component es y t rabaj a "hacia fuera", hacia la
integracin de t odo el si st ema de cmput o.
Diferentes t cni cas de prueba son apr opi adas en di ferent es moment os.
La prueba la dirige el desarrol l ador del sof t war e y (en el caso de proyect os
grandes) un grupo i ndependi ent e de pruebas.
La prueba y la depuraci n son actividades diferentes, per o la segunda debe
incluirse en cual quier est rat egi a de prueba.
Una est rat egi a para la prueba del soft ware debe incluir pr uebas de baj o nivel (nece-
sari as para confi rmar la correct a i mpl ement aci n de un pequeo segment o de cdi-
go fuente) y de alto nivel (que validen las principal es funci ones del si st ema a partir
TM
PDF Editor
software. No lo son.
Debe ponetse especio!
cuidado en la calidad
y detecci n de errores
en todo el proceso de
la ingeniera del
software.
de los requisitos del cliente). Una estrategia debe servir como gua para el p r o e s
nal y fijar un conj unt o de gu as para el jefe de proyecto. Debido a que los pasos | "
la est rat egi a de prueba son si mul t neos, cuando empi eza a aument ar la presi cr :<
las fechas lmite debe t enerse la opcin de medi r los avances y buscar que los : r j
bl emas apar ezcan lo ant es posible.
13.1.1 Verificacin y validacin
La prueba del soft ware es un el ement o de un t ema ms ampl i o que suel e der
nar se verificacin y validacin (VyV). Verificaci n es el conj unt o de actividades - J J
asegur an que el sof t war e i mpl ement e cor r ect ament e una funcin espe: a i
Validaci n es un conj unt o diferente de actividades que aseguran que el
const rui do corresponde con los requisitos del cliente.1 Boehm [BOE81] lo e s t a r - ^
de otra manera:
Verificacin: "Estamos const ruyendo el product o correct ament e?"
Validacin: "Estamos const ruyendo el product o correcto?"
sgura i M
tulo 2c
^CONSEJO^.
No se deben tener
descuidos ni
considerar que las
pruebas son una " red
de segundad" que
atropar lodos los
errores que ocurron
debido a la aplicaci n
de prcticas d biles de
La definicin de VyV abarca muchas de las actividades incluidas en el aseg
to de la calidad del soft ware y se anal i za de maner a detallada en el cap t ul o.
La verificacin y la validacin abar can una ampl ia lista de actividades de a f o -
rami ent o de la calidad del soft ware: revisiones t cni cas formal es, auditoras de . d
dad y de configuracin, moni t oreo del desempeo, simulacin, factibilidad, r e - . a j
de la document aci n y la base de dat os, anlisis de algoritmos, pr uebas de
lio, de facilidad de uso, calificacin y de instalacin [WAL89]. Aunque las act i vkl
de prueba tienen un papel demasi ado i mport ant e en VyV, t ambi n se ne
muchas ot ras actividades.
"Probar es la part e inevitable de cualquier esfuerzo responsabl e por desarrol l ar un sistemo de soft ware. "
William I
Las pr uebas son el l t i mo bast i n para la eval uaci n de la calidad y, de n - . a i M
ms pragmt i ca, el descubri mi ent o de errores. Pero l as pr uebas no deben cor
rarse como una "red de seguridad". Como suel e decirse: "No es posibl e probar la J
dad. Si no est ah ant es de que empi ece la prueba, no est ar cundo se ter
La calidad se i ncorpora al sof t war e en t odo el pr oceso de ingeniera. La aplic
apropi ada de mt odos y herrami ent as, las revisiones t cni cas formal es y efe
Debe indicarse que hay una fuerte divergencia de opinin acerca de los tipos de prueba que c
tuyen una "validacin". Algunas personas creen que toda prueba es una verificacin, y que L=
dacin se realiza cuando el usuario revisa y aprueba los requisitos, y ms delante, cuando el
est en condiciones de operar. Otras personas consideran que la prueba de la unidad y la i
cin (secciones 13.3.1 y 13.3.2) constituyen la verificacin y que las pruebas de alto nivel (a
das ms adelante en este capitulo) son la validacin.
TM
PDF Editor
j unt o con una admi ni st raci n y una medicin sl idas aport an la calidad, que s e con-
firma durant e las pruebas.
Miller [MIL77] relaciona la prueba del soft ware con el asegur ami ent o de la cali-
dad al afirmar: "lo que motiva la prueba de los pr ogr amas es la confi rmaci n de la
calidad del sof t war e con mt odos que se puedan aplicar de maner a econmi ca y
efectiva en si st emas gr andes y pequeos".
13.1.2 Organizacin par a las pruebas del software
En cual quier proyect o de sof t war e se pr esent a un conflicto de i nt ereses cuando
comi enzan las pruebas. Ahora se pide a las per sonas que han const rui do el soft wa-
re que lo prueben. En s, est o parece inofensivo; despus de todo, quin conoce
mej or un pr ogr ama que la persona que lo desarrol l ? Por desgracia, a esos mi smos
desarrol l adores les interesa mucho demost r ar que el programa est libre de errores,
que funci ona de acuer do con l os requisitos del cliente y que se compl et ar a t i empo
y sin rebasar el presupuest o. Cada uno de est os i nt ereses mina las bondades de la
prueba.
" 0 optimismo es el peligro oupacionol de lo programaci n; la prueba, el t rat ami ent o. "
Kent Beck
Desde un punt o de vista psicolgico, el anl i si s y el di seo del soft ware (junto con la
codificacin) son t ar eas const ruct i vas. El ingeniero del sof t war e anal iza, model a y
l uego crea un programa de comput adora, j unt o con su document aci n. Como cual-
quier constructor, el ingeniero del sof t war e se sent i r orgul l oso del edificio que
acaba de construir y mirar con recelo a cual quiera que pret enda echarl o abaj o.
Cuando comi enza la prueba hay un intento sutil, per o definitivo, de "romper" lo que
ha const rui do el ingeniero del soft ware. Al poner se en los zapat os del const ruct or la
prueba parecer (psicolgicamente) destructiva. De modo que el const ruct or act ua-
r con cuidado, di seando y ej ecut ando pr uebas que demost r ar n el buen funci ona-
mi ent o del pr ogr ama en lugar de descubrir errores. Por desgracia, los errores segui-
rn present es. Y si el ingeniero del soft ware no los encuent ra, el cliente s lo har!
De las consi deraci ones precedent es suel en inferirse er r neament e vari as mal as
i nt erpret aci ones: 1) que el responsabl e del desarrol l o no deber a participar en el pro-
ceso de prueba, 2) que el sof t war e debe poner se a sal vo de ext raos que lo prueben
sin misericordia, y 3) que qui enes aplican las pr uebas sl o deben participar en el pro-
yect o cuando vayan a darse los pri meros pasos de esas pruebas. Todas est as afir-
maci ones son incorrectas.
El desarrol l ador del sof t war e si empre ser el responsabl e de probar las uni dades
individuales (component es) del programa y asegur ar que cada una realice la funcin
o muest re el compor t ami ent o para el que se dise. En muchos casos, el desarro-
llador t ambi n aplica la prueba de integracin (un paso que lleva a la const rucci n,
y la prueba, de toda la arqui t ect ura del software- Slo despus de que la arqui t ect u-
ra del sof t war e est compl et a participar un grupo i ndependi ent e de prueba.
C&VE
p p o
te de
no tiene el
de
" que
ntan los
zrsfiuctores del
TM
PDF Editor
^ O N S E J O ^
Si no existe un GIP
dentro de una
orgonizoci n, tendr
que odoptorse su
punto de visto propio.
Al aplicar lo pruebo se
debe trotar de destruir
el software.
Cul es ID
es t r at egi a
general par a la
pr ueba del
s of t wa r e ?
El papel de un grupo independiente de prueba (GIP) consi st e en eliminar los p' :
bl emas propi os de dej ar que el const ruct or pruebe lo que l mi smo ha constru :
La prueba i ndependi ent e elimina el confl icto de i nt ereses que, de otra maner a, e>. - J
ra present e. Despus de todo, al personal del GIP se le paga par a que encue- -
errores.
Sin embargo, el ingeniero del sof t war e no debe si mpl ement e ent regar el p r j i -
ma al GIP y al ejarse. El desarrol l ador y el GIP deben t rabaj ar uni dos en t odo el pr:-
yecto de soft ware para asegurar la realizacin de pr uebas exhaust i vas. Mier .
st as se real izan, el desarrol l ador debe est ar disponible para corregir los errores rr
se descubran.
' El pri mer error que comete lo gent e es pensor que el equipo de pruebos es responsabl e de asegurar
Br i an Ma r a
El GIP es parte del equi po del proyect o de desarrol l o del soft ware, ya que par>_
pa en el anl i si s y di seo y adems sigue part i ci pando (al pl anear y especificar :
cedi mi ent os de prueba) en t odos los pasos de un proyect o grande. Sin embar g: - j
muchos casos el GIP i nforma a la organi zaci n de asegur ami ent o de calidad de! > ]
ware, por lo que obt i ene un grado de i ndependenci a que sera imposible si
parte de la organi zaci n encar gada de la ingeniera del soft ware.
13.1.3. Estrategia de prueba par a arquitecturas convencionales
del software
Seria factible consi derar que el proceso de ingeniera del sof t war e es equiparar
la espiral que se ilustra en la figura 13. i. Al principio, la ingeniera del sistema
ne el papel del soft ware y lleva al anl i si s de los requisitos de ste, donde se esa- l
blecen el domi ni o de informacin, la funcin, el comport ami ent o, el desempee ,: |
restricciones y los criterios de validacin del soft ware. Al despl azar se hacia el r J
rior de la espiral se llega al di seo y, por ltimo, a la codificacin. El desarroi k
sof t war e de comput ador a requiere recorrer la espiral hacia dent ro, a lo largo de . n a
lnea bien definida que di smi nuye el grado de abst racci n tras cada vuelta.
Tambin es posibl e ver una estrategia para la prueba del sof t war e en el c o n t a l
de la espiral (figura 13.1). La prueba de uni dad comi enza en el vrtice de la esp:
se concent r a en cada unidad (componente) del soft ware, tal como se i mpl emen: :
el cdi go fuent e. La prueba avanza al despl azarse hacia fuera, a lo largo de la e s a l
ral, hast a llegar a la prueba de integraci n, donde s e at i ende el di seo y la con i J
cin de la arqui t ect ura del soft ware. Si se recorre otra vuelta hacia fuera en la e s *
ral, se encuent ra la prueba de validaci n, donde se validan los requisitos establee. J
como part e del anlisis de requisitos del soft ware, compar ndol os con el sofhi
que se ha construido. Por ltimo, se llega a la prueba del sistema, donde se p r u e :
como un t odo el sof t war e y ot ros el ement os del si st ema. El sof t war e de c omput a a B
ra se prueba recorriendo la espiral hacia fuera, por una lnea bien definida, de
que en cada vuelta s e ensancha el al cance de la prueba.
TM
PDF Editor
rueba del sistema
de unidad
Cdigo
Diseo
Requisitos
Ingeniera del sistema
sitio
cxfforcn
I i r t e paro
rsean el
Si se consi dera el proceso desde un punt o de vista procedi ment al , en realidad la
prueba dent r o del cont ext o de la ingeniera del soft ware consi st e en una serie de
cuat ro pasos que se i mpl ement an de maner a secuencial . Esos pasos se muest r an en
la figura 13.2. Al principio, la prueba se concent ra en cada component e individual,
asegur ando que funci ona de maner a apropi ada como unidad (por ello se le denomi -
na prueba de unidad). La prueba de unidad empl ea en forma recurrent e las t cni cas
de prueba que recorren cami nos especficos en una est ruct ura de control del com-
ponent e, lo que asegura una cobert ura compl et a y una det ecci n mxi ma de erro-
res. Enseguida deben ensambl ar se o i nt egrarse los component es para formar el
paquet e de sof t war e compl et o. La prueba de integracin at i ende t odos los aspect os
asoci ados con el doble probl ema de verificacin y const rucci n del programa. Las
t cni cas de di seo de casos de prueba que se concent ran en ent r adas y sal idas son
a d e
Pruebas
de alto nivel
d l a
d e l
a r e .
Requisitos
Diseo
Cdigo
"Direccin"
de la prueba
TM
PDF Editor
388
\
CLAVE
Como los pruebos
convencionoles, los
orientodos o objetos
empiezon por lo
"pequeo". Sin
emborgo, en casi todos
los cosos, el elemento
ms pequeo probado
es una clase o un
paquete de doses que
colaboran entre s.
ms domi nant es durant e la integracin, aunque podr an usar se t cni cas que re::--
rren r ut as especficas del pr ogr ama par a asegur ar la cobert ura de los principa e s ;
cami nos de control. Despus de que se ha i nt egrado (construido) el sof t war e se a r : - j
ca un conj unt o de pr uebas de alto nivel. Se deben eval uar los criterios de val ida: od
est abl eci dos dur ant e el anlisis de requisitos. La prueba de validacin pr opor c
un asegur ami ent o final de que el sof t war e cumpl e con t odos los requisitos frr>:--
nal es, de compor t ami ent o y desempeo.
El ltimo paso de la prueba de alto nivel queda fuera de los lmites de la ingentr -I
ra del soft ware, per o dent ro de un cont ext o ms ampl i o de la ingeniera de los s s J
t emas de cmput o. El soft ware, una vez validado, debe combi narse con otros s e -
ment os del si st ema (por ejempl o, hardware, personas, bases de datos). La prueba a d j
si st ema verifica que t odos los el ement os encaj en apr opi adament e y que se log-t
funcin y el des empeo general es del si st ema.
13.1.4 Estrategia de prueba del software para arquitecturas
orientadas a objetos
La prueba de si st emas ori ent ados a objetos pl ant ea un conj unt o diferente de d !
al ingeniero del soft ware. La definicin de prueba debe ampl i arse para incluir t e r J
cas de descubri mi ent o de errores (por ejempl o, revisiones t cni cas formales) que a
aplican para anal i zar y di sear model os. El gr ado al que se han compl et ado y la : y*U
sistencia de l as represent aci ones or i ent adas a obj et os deben eval uarse a medida aufl
se const ruyen. La prueba de unidad pierde part e de su significado, y las e s t r a t r r a i
de integracin cambi an de maner a i mport ant e. En r esumen, las est rat egi as y la j c i
ticas de prueba (captulo 14) deben ser responsabl es de l as caractersticas nicas J
soft ware ori ent ado a obj et os.
La estrategia general para el sof t war e ori ent ado a obj et os tiene una filosofa i j a l
tica a la que se aplica a las arqui t ect uras convenci onal es, per o pr esent a diferer : jm
en el enfoque. Se empi eza "probando lo pequeo" y se t rabaj a haci a el exterior
bando lo grande". Sin embargo, la at enci n cambi a cuando la prueba es pequer a
un mdul o individual (el concept o convencional ) a una cl ase que abarca a t r xs a
operaci ones y que, adems, requiere comuni caci n y col aboraci n. A medida r i
HOGARSEGURO
Preparacin para la prueba
l a escena: Oficina de Doug
Miller, mientras contina el diseo al nivel de
componentes y empieza la construccin de ciertos
componentes.
Los actores: Doug Miller, jefe de ingeniera del
software; Vinod, Jamie, Ed y Shakira, integrantes del
equipo de ingeniera del software de HogarSeguro.
La conversacin:
Doug: Me parece que no hemos dedicado el tiempo
suficiente a hablar de las pruebas.
Vinod: Tienes razn, pero todos hemos estado un
atareados. Y adems hemos pensado en ello..- en
realidad, hemos hecho ms que pensarlo.
TM
PDF Editor
CAPITULO 13 ESTRATEGIAS DE PRUEBA DEL SOFTWARE 389
(sonriendo): Lo s... tenemos exceso de
-. pero an tenemos que pensar en las cosas
-tes. " *
Me gusta la idea de disear pruebas de
antes de empezar a codificar cualquiera de los
ntes, de modo que eso es lo que hemos tratado
. Tengo un enorme archivo de pruebas que
ejecutar una vez que est completo el cdigo de
componentes.
"se es el concepto de Programacin Extrema (un
gil de desarrollo de software visto en el captulo
jno?
Asi es. Aunque no estamos usando, en s, la
acin Extremo, decidimos que sera una buena
disear pruebas de unidad antes de construir el
i (el diseo nos da toda ia informacin que
os). ' G i l
Jamie: Yo he estado haciendo lo mismo.
Vinod: Y he tomado el papel de integrador, de modo
que cada vez que uno de los muchachos me pase un
componente, lo integrar y ejecutar una serie de
pruebas de regresin en el programa parcialmente
integrado. He estado trabajando para disear un
conjunto de pruebas apropiado para cada funcin del
sistema.
Doug (a Vinod): Con cunta frecuencia ejecutars
las pruebas?
Vinod: Todos los das... hasta que se integre bien el
sistema. O sea, hasta que los incrementos de software
que planeamos entregar queden integrados.
Doug: Muchachos, van adelante de m!
Vinod (sonriendo): La anticipacin lo es todo en el
negocio del software, jefe.
integran cl ases dent ro de una arqui t ect ura ori ent ada a objetos, se ej ecut a una serie
de pr uebas de regresi n para descubrir errores debi dos a la comuni caci n y col abo-
racin ent r e cl ases (component es) y a los efect os col at eral es que origina la adicin
de nuevas cl ases (componentes). Por ltimo, se prueba el si st ema como un t odo para
asegurarse de que se descubran errores en los requisitos.
13.1.5 Criterios par a completar la prueba
Cada vez que se anal i zan las pruebas del sof t war e surge una pregunt a clsica:
cundo hemos t ermi nado las pr uebas (cmo s abemos que hemos pr obado lo sufi-
ciente)? Lo l ament abl e es que no hay una respuest a definitiva, si no que hay al gunas
r espuest as pr agmt i cas y al gunos i nt ent os iniciales de sent ar una gua emprica.
Una respuest a a la pregunt a es: "nunca se t ermi na de aplicar una prueba; la carga
si mpl ement e se despl aza de ust ed (el ingeniero del soft ware) a su cliente. Cada vez
que el cliente, el usuario, o ambos, ej ecut an un pr ogr ama de comput adora, st e se
est probando. Este hecho i ncuest i onabl e subraya la importancia de ot ras activida-
des del asegur ami ent o de la calidad del soft ware.
Otra respuest a (un poco cnica, pero correcta) es: "la prueba se t ermi na cuando se
agot a el t i empo o el dinero".
Aunque al gunos usarn esta respuest a como ar gument o, un ingeniero del soft-
war e necesita criterios ms rigurosos para det ermi nar que l as pruebas han sido sufi-
cientes. Musa y Ackerman [MUS89j sugieren una respuest a basada en criterios est a-
dsticos: "No, no podemos est ar compl et ament e seguros de que el sof t war e nunca
fallar, per o de acuer do con un model o estadstico t eri cament e slido y val i dado en
forma experi ment al , hemos real i zado las pr uebas suficientes como para afirmar, con
una confi anza del 95%, que l as probabil idades de t ener mil hor as de oper aci ones del
TM
PDF Editor
a n t e m
s t e J
CPU libres de fallas en un ent or no definido de forma probabilstica es por lo mena
de 0.995." Empl eando el model ado estadstico y la teora de la confiabilidad del
war e, pueden desarrol l arse model os de fallas del sof t war e (descubiertas durante a
prueba) como una funci n del t i empo de ej ecuci n (por ej empl o, cons;
[MUS89], [SIN99] O [IEE01]).
Al recopilar mt ri cas dur ant e la prueba del sof t war e y usar model os existentes
la confiabilidad del soft ware, es posibl e desarrol l ar directrices significativas para
ponder la pregunt a: Cundo hemos t ermi nado la prueba? Lo indiscutible es que j a|
falta mucho t rabaj o ant es de que puedan est abl ecerse regl as cuant i t at i vas pa n 1
prueba, per o los enfoques empricos exi st ent es son consi derabl ement e mejores OH
la simple intuicin.
1 3 . 2 AS P E CT OS ESTRATGI COS
9 Cles
! directrices
llevan o uno
estrategia de
prueba del
sof t ware que
tenga xi to?
Ms adelante, en este mi smo captulo, se explorar una estrategia sistemtica
prueba del software. Pero hast a la mejor estrategia fallara si no atiende una se r e
aspect os predominantes. Tom Gilb [G1L95] argument a que deben at enderse los si gi reB
tes t emas, si se desea impl ementar con xito una estrategia de prueba del software I
Especificar los requisitos del producto de manera cuantificable mucho antes ot
empiecen las pruebas. Aunque el objetivo primordial de la prueba es encont rar - - M
res, una buena estrategia de prueba t ambi n eval a ot ras caractersticas de la c J
dad, como l as opci ones de llevarla a ot ra pl at aforma, adems de la facilidad de T J
t eni mi ent o y uso (captulo 15). Esto debe especificarse de maner a tal que p e r ^
medirl o par a que l os resul t ados de la prueba no resul ten ambi guos.
Establecer explcitamente los objetivos de la prueba. Los obj et i vos especficos x m
prueba se deben est abl ecer en t rmi nos cuantificables. Por ejempl o, dent ro de! ~ m
de prueba deben est abl ecerse la efectividad y la cobert ura de la prueba, el t : s i J
medi o de falla, el cost o de encont r ar y corregir defectos, la densi dad o la f r eo- ei
de las fallas rest ant es, y l as hor as de t rabaj o por prueba de regresi n [GIL95].
Comprender cules son los usuarios del software y desarrollar un perfil pare M
categora de usuario. Los casos de uso que descri ban el escenari o de interacci" J
cada cl ase de usuari o reducen el esf uer zo general de prueba, ya que c o n c e n f a n B
prueba en la utilizacin real del producto.
Desarrollar un plan de prueba que destaque la " prueba de ciclo rpido" . Gilb | G
recomi enda que un equi po de ingeniera del sof t war e "aprenda a probar en z i f l
rpidos (2% del esf uer zo del proyecto) los i ncr ement os en el mej or ami ent o de a ifl
cionalidad, la calidad, o ambas, de maner a que sean tiles para el cliente y se
dan probar en el campo". La ret roal i ment aci n que gener an est as pruebas de s
rpido se utiliza para cont rol ar los grados de calidad y las correspondi ent es e s c ^
gias de prueba.
TM
PDF Editor
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOFTWARE
391
Construir un software 'robusto" diseado para probarse a s mismo. El sof t war e debe
di searse de maner a tal que use t cni cas antierror (seccin 13.3.1). Es decir, el soft -
war e debe t ener la capaci dad de diagnosticar ciertas cl ases de errores. Adems, el
di seo debe incluir pruebas aut omat i zadas y de regresin.
Usar revisiones t cnicas formales y efectivas como filtro previo a la prueba. Las revi-
si ones t cni cas formal es (captulo 26) llegan a ser tan efectivas como l as pr uebas
para descubrir errores. Por t ant o, l as revisiones reducen la cant i dad de esf uer zo de
prueba que se requi ere para producir sof t war e de alta calidad.
Realizar revisiones t cnicas formales para evaluar la estrategia de prueba y los pro-
pios casos de prueba. Las revi si ones t cni cas formal es posibilitan descubrir inconsis-
t enci as, omi si ones y errores evi dent es en el enf oque de la prueba. Esto ahorra tiem-
po y t ambi n mej ora la calidad del producto.
Desarrollar un enfoque de mejora continua para el proceso de prueba. Es necesari o
medi r la est rat egi a de prueba. Las medi das reuni das dur ant e la prueba deben usar-
se como part e de un enf oque est ad st i co de control del proceso para la prueba del
soft ware.
"Probar ni cament e los requisitos del usuari o final es como inspeccionar un edificio considerando ni cament e el
t rabaj o real izado por el diseador de interiores, a costa de los cimientos, las vigas y la pl omer a. "
Boris Beizer
1 3 . 3 ESTRATEGI AS DE PRUEBA PARA EL SOFTWARE CONVE NCI ONAL
En la prueba del sof t war e es posible aplicar muchas est rat egi as. En un ext remo, un
equi po de sof t war e podra esperar hast a que el si st ema est t ot al ment e const rui do y
l uego aplicar pr uebas al si st ema general esper ando encont r ar errores. Este enfoque,
aunque atractivo, si mpl ement e no funci ona. Arrojar un sof t war e pl agado de erro-
res, mol est o para el cliente y usuari o final. En el ot ro ext remo, un i ngeni ero de soft -
war e podra aplicar pr uebas di ari ament e, sin importar la part e del si st ema que se
const ruya. Este enfoque, aunque menos atractivo para muchos, es muy efectivo. Por
desgracia, la mayor a de l os desarrol l adores de sof t war e dudan en usarlo. Qu hay
que hacer?
La estrategia de prueba que elige la mayor part e de los equi pos de sof t war e se
ubica ent r e est os dos ext remos. Toma un enf oque i ncrement al de las pruebas; inicia
con la prueba de uni dades individuales del programa, pasa a pruebas di seadas para
facilitar la integracin de las uni dades, y cul mi na con pruebas que real izan sobr e el
si st ema construido. En l as si gui ent es secci ones se expone cada una de est as cl ases
de prueba.
a Web
b wwite sitio
Mi onlror uno
fefestode
B e pora pruebes:
MroJo.com/
/V/.
TM
PDF Editor
392 PARTE DOS PRCTI CA DE LA I NGENI ER A DEL SOFTWARE
13.3.1 Prueba de uni dad
7 Cules
errores se
encuentran
comnmente
durante la prueba
de unidad?
La prueba de unidad se concent ra en el esf uer zo de verificacin de la unidad mai
pequea del di seo del soft ware: el component e o mdul o de soft ware. Tomanc:
como gua la descripcin del di seo al nivel de component es, se pr ueban importar
t es cami nos de control para descubrir errores dent ro de l os lmites del mdulo. El
al cance restringido que se ha det er mi nado para l as pr uebas de unidad limita la rela-
tiva complejidad de las pruebas y los errores que st as descubren. Las pruebas de ur
dad se concent ran en la lgica del procesami ent o interno y en las estructuras de dat
dent ro de los lmites de un component e. Este tipo de prueba se puede aplicar ea
paral el o a vari os component es.
Consideraciones sobre la prueba de unidad. En la figura 13.3 se ilustran yt
maner a esquemt i ca las pruebas que se aplican como parte de la prueba de unidad. _J
interfaz del mdul o se prueba para asegurar que la informacin fluye apropi adamer
hacia dent ro y hacia fuera de la unidad de programa suj et a a prueba. Se exami nan i
estructuras de dat os locales para asegurar que los datos t emporal es mant i enen la ire; -
gridad durant e todos los pasos de la ejecucin de un algoritmo. Se recorren t odos 1 -
cami nos i ndependi ent es (cami nos de base) en t oda la est ruct ura para asegur ar que
t odas las i nst rucci ones de un mdul o se hayan ej ecut ado por lo menos una vez Se
pr ueban las condi ci ones lmite para asegurar que el mdul o opera apropi adamer
en los limites establ ecidos para restringir el procesami ent o. Y, por ltimo, se prue-
ban t odos l os cami nos de manej o de errores.
Es necesari o probar el flujo de dat os en la interfaz del mdul o ant es de inic^r
cualquier otra prueba. Si los dat os no ent ran ni sal en apropi adament e, t odas
dems pr uebas resul tarn intiles. Adems, dur ant e la prueba de uni dad deben rec >
rrerse l as est ruct uras de dat os l ocal es y eval uarse (si es posible) el i mpact o l oca
sobre los dat os globales.
Durante la prueba de unidad, una tarea esencial es la prueba selectiva de las rutas
ejecucin. Se deben disear casos de prueba para descubrir errores debidos a cl
incorrectos, compar aci ones er r neas o flujos de control i napropi ados. Entre los e r
Prueba de
unidad.
Interfaz
Estructuras de dat os locales
Condi ci ones lmite
Rulos independientes
Rutas de manej o de errores
TM
PDF Editor
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOmVAEE 393
res ms comunes en los clculos se encuent ran los siguientes: 1) aplicacin inco-
rrecta o mal entendida de la precedencia aritmtica, 2) operaciones de modo mez-
cladas, 3) inicializacin incorrecta, 4) falta de precisin, y 5) representacin simbli-
ca incorrecta de una expresin. La comparacin y el flujo de control estn estrecha-
ment e acopl ados ent re s (es decir, el flujo cambia con frecuencia despus de una
comparacin). Los casos de prueba deben descubrir errores como: 1) comparaci ones
ent re diferentes tipos de datos, 2) operadores lgicos o precedencia de st os aplica-
dos incorrectamente, 3) expectativa de igualdad cuando los errores de precisin
hacen que sea poco probable, 4) comparacin incorrecta de variables, 5) termina-
cin inapropiada o inexistente de bucles, 6) falla en la salida cuando se encuent ra
una iteracin divergente, y 7) variables de bucle modificadas de manera inapropiada.
La prueba de limites es una de las t areas ms importantes de la prueba de unidad.
Con frecuencia, el soft ware falla en sus lmites. Es decir, a menudo los errores ocu-
rren cuando se procesa el ensi mo elemento de una matriz de n dimensiones, cuan-
do se evoca la /-sima repeticin de un bucle con i pasos, cuando se encuent ra el
valor mximo o mnimo permisible. Es muy probable descubrir errores en los casos
de prueba que se ejercen sobre la estructura de datos, el flujo de control y los valo-
res de datos ubicados apenas abaj o de los mxi mos o mnimos, sobre st os y ape-
nas arriba de ellos.
Un buen diseo impone que se prevean las condiciones de error y que se confi-
guren rutas de manej o de errores para modificar la ruta o terminar limpiamente el
procesami ent o cuando ocurra un error. Yourdon [YOU75] llama a este enfoque antie-
rror. Por desgracia, existe la tendencia a incorporar el manej o de errores en el soft-
ware y, con ello, a no probarlo nunca. Una historia real servir como ejemplo:
Un sistema de diseo asistido por comput adora se desarroll baj o contrato . En un m-
dulo de procesami ent o de transacciones, un bromista prctico puso el siguiente mensaj e
de manej o de errores despus de una serie de pruebas condicionales que invocaban va-
rias ramas del flujo de control: ERROR! NO HAY FORMA DE QUE PUEDA LLEGAR
HASTA AQUl. Este "mensaj e de error" lo descubri un cliente durante la capacitacin
del usuario!
Entre los posibles errores que deben probarse cuando se evale el manej o de
errores se encuent ran los siguientes: 1) la descripcin del error es ininteligible, 2) el
error indicado no corresponde al encontrado, 3) la condicin de error causa la inter-
vencin del sistema operativo ant es de que se dispare el manej o de errores, 4) el pro-
cesamiento de la condicin de excepcin es incorrecto, 5) la descripcin del error no
proporciona informacin suficiente para ayudar a localizar la causa del error.
Procedi mi ent os de prueba de unidad. La prueba de unidad suele considerarse
adyacente al paso de la codificacin. El diseo de las pruebas de unidad puede rea-
lizarse ant es de que empiece la codificacin (un enfoque gil que suele preferirse) o
despus de que se ha generado el cdigo fuente. Una revisin de la informacin del
TM
PDF Editor
Entorno de
prueba de
unidad.
^ O N S E J O ^
Hoy situaciones en
que no se tendrn los
recursos para hacer
una prueba de unidad
muy completa.
Entonces deben selec-
cionarse m dulos
crticos y los que
tengan una elevado
complejidad en ciclos,
y s lo sos deben
probarse.
di seo proporci ona una gua para est abl ecer casos de prueba que probabl
descubri rn errores en cada una de l as cat egor as anal i zadas. Cada caso de
debe rel acionarse con un conj unt o de resul t ados esperados.
Debido a que un component e no es un pr ogr ama i ndependi ent e, para cada
ba de uni dad se debe desarrol l ar sof t war e controlados de resguardo, o de
tipos. En la figura 13.4 se ilustra el ent or no para la prueba de unidad. En casi
l as aplicaciones, un cont rol ador no es m s que un "programa principal" que
l os dat os del caso de prueba, pasa est os dat os al component e (que habr de
se) e i mpri me l os resul t ados i mport ant es. Los resguardos sirven para ree
mdul os subor di nados al component e que habr de probarse (o l l amados por
Un resguardo o "subprograma simul ado" usa la i nt erfaz del mdul o subor
realiza una mnima mani pul aci n de dat os, proporci ona verificacin de la en
devuel ve el control al mdul o de prueba.
Cont rol adores y resguardos represent an una sobrecarga de trabajo. Es
resulta necesari o escribir ambos tipos de sof t war e (sin que suel a apl icarse ur
o formal), per o no se ent regan con el product o. de sof t war e final. Si se les
ne en un nivel simple, la sobrecarga real es rel at i vament e pequea. Por d
no es posible aplicar adecuadament e una prueba de uni dad a muchos com
con un "simple" sof t war e de sobrecarga. En muchos casos es posible po'
prueba compl et a hast a el paso de prueba de integracin (donde t ambi n se
cont rol adores o resguardos).
La prueba de unidad se simplifica cuando se disea un component e co-
cohesi n elevada. Cuando sl o se at i ende una funcin de un component e, el
ro de casos de prueba se reduce y es m s fcil predecir y corregir los errores.
13.3.2 Prueba de integracin
Un nefi t o en el mundo del soft ware podra pl ant ear una pregunt a aparent
legtima, una vez que se haya apl i cado una prueba de unidad a t odos los m
"Si t odo funci ona bien individualmente, por qu dudan que funci one cua
TM
PDF Editor
*
nnfoquede
'paralo
e s una
: perezosa
i al fracaso,
irealizorla
i en incre-
s probar
s se avanza.
une?" El problema, por supuesto, consiste en "unir" (crear la interfaz). En una inter-
faz es posible perder datos, un mdul o podra tener un efecto adverso e inadvertido
sobre otro, la combinacin de subfunciones tal vez no produzca la funcin principal
deseada, la imprecisin aceptable en el ement os individuales podra ampliarse hasta
grados inaceptables y las estructuras globales de datos podran presentar problemas.
Es triste, pero la lista sigue y sigue.
La prueba de integraci n es una tcnica sistemtica para construir la arquitectu-
ra del soft ware mientras, al mismo tiempo, se aplican las pruebas para descubrir
errores asociados con la interfaz. El objetivo es tomar component es a los que se
aplic una prueba de unidad y construir una estructura de programa que determine
el diseo.
A menudo se tiende a intentar una integracin que no sea incremental; es decir,
a construir el programa mediante un enfoque de "big bang". Se combinan todos los
component es por anticipado. Se prueba todo el programa como un todo. Y se pro-
duce el caos! Se encuentra una gran cantidad de errores. La correccin es difcil, por-
que resulta complicado aislar las causas debido a la extensin del programa com-
pleto. Una vez corregidos esos errores, aparecen otros nuevos y el proceso contina
en un ciclo que parece interminable.
La integraci n incremental es la anttesis del enfoque del "big bang". El programa
se construye y prueba en pequeos incrementos, en los cuales resulta ms fcil ais-
lar y corregir los errores, es ms probable que se prueben por completo las interfa-
ces y se vuelve factible la aplicacin de un enfoque de prueba sistemtica. En los
siguientes prrafos se expondrn varias estrategias diferentes de integracin incre-
mental.
*
[ CONS E J O
s se desarrolla
ideun
b, tiene que
i la
i en que
i la integraci n,
i redo que los
tiles est n
s cuando se
ixcesite.
Integracin des cendent e. La prueba de integraci n descendente es un enfoque
incremental para la construccin de ia arquitectura del software. Los mdulos se
integran al descender por la jerarqua de control, empezando con el mdul o de con-
trol principal (programa principal). Los mdulos subordinados al mdulo de control
principal se incorporan en la estructura de una de dos maneras: primero-en-profun-
didad o primero-en-anchura.
Tomando como referencia la figura 13.5, la integraci n primero - en profundidad
integra t odos los mdulos de una ruta de control principal de la estructura del pro-
grama. La seleccin de una ruta principal es un poco arbitraria y depende de las
caractersticas especficas de la aplicacin. Por ejemplo, si se elige el cami no de la
izquierda, se integraran primero los mdulos M,, y M3. A continuacin, se inte-
grara Ms o (si es necesario para el adecuado funci onami ent o de M2) M(v Enseguida
se construyen las rutas de control central y a la derecha. La integraci n primero-en
anchura incorpora todos los component es directamente subordinados en cada nivel,
despl azndose horizontal mente por la estructura En el caso de la figura, se integra-
ran primero los component es M2, M3 y M.,. Y Ies seguiran M5, M6, etc. El proceso de
integracin se realiza en una serie de cinco pasos:
TM
PDF Editor
396 PARTE DOS PRCTICA RA LA INGENIERA DEL SOFTWARE
Integracin M,
descendente.
I
M7
Wm Cules son
P los pasos de
1. El mdul o de control principal se utiliza como cont rol ador de prueba, y se
sustituyen l os resguardos en t odos los component es di rect ament e subordina
dos al mdul o de control principal.
la integracin des-
cendente?
2. Dependi endo del enf oque de integracin sel ecci onado (es decir, pri mero-er
profundi dad o pri mero-en-anchura) se van r eempl azando los resguardos s i
bordi nados, uno por uno, con l os component es reales.
3. Se aplican pr uebas cada que se integra un nuevo mdul o.
4. Al compl et ar cada conj unt o de pruebas, se r eempl aza otro resguardo con e
mdul o real.
5. Se aplica la prueba de regresi n (que se anal i za ms adel ant e, en esta misr.2
seccin) para asegurarse de que no se han introducido nuevos errores.
El proceso cont i na a partir del paso 2 hast a la const rucci n total de la est r uct un
del programa.
La est rat egi a de integracin descendent e verifica los principal es punt os de carne
trol o decisin al principio del proceso de prueba. En una est ruct ura de prograna
bien el aborada, la t oma de deci si ones ocurre en l os nivel es superi ores de la j erarcua
y, por t ant o, se encuent r an primero. Si existen pr obl emas de control i mpor t an: ^
resulta esencial reconocerl os desde el principio. Si se sel ecci ona la integracin p~-
mero-en-profundi dad, es posible i mpl ement ar y demost r ar una funcin compl eta j d
soft ware. Por ejempl o, i mag nese una est ruct ura de t ransacci n clsica (captulo I
en que una serie compl ej a de ent r adas interactivas se solicita, adqui ere y valida
medi o de una ruta de ent rada. Tal vez ese cami no est i nt egrado en forma desc*
dent e. Todo el pr ocesami ent o de ent r ada (para el envo de las si gui ent es t r a ns a r a *
TM
PDF Editor
i Cules pro-
blemas se
irn cuan-
i elija la inte-
i descen-
I Cules son
los pasos
0 una integra-
1 ascendente?
CI?AVE
i ne ga c i n
ote elimino la
)d de
ecuar dos complejos.
nes) podra demost r ar se ant es de que ot ros el ement os de la estructura se hayan inte-
grado. La demost raci n t empr ana de la capaci dad funcional genera confi anza en el
desarrol l ador y en el cliente.
La est rat egi a descendent e no parece muy compl i cada, per o en la prctica llegan
a surgir probl emas de logstica. El ms comn se present a cuando se requiere pro-
cesami ent o en los niveles inferiores de la j erarqu a para probar de maner a adecua-
da los niveles superiores. Al principio de la prueba descendent e s e reempl azan los
mdul os de baj o nivel con resguardos; por t ant o, no fluirn dat os i mport ant es hacia
la part e superior de la est ruct ura del programa. Quien aplica la prueba cuent a con
tres opci ones; 1) ret rasar muchas de l as pr uebas hast a que los resguardos sean
r eempl azados con l os mdul os reales, 2) desarrol l ar r esguar dos que realicen fun-
ci ones limitadas que si mul en los mdul os real es, o 3) integrar el sof t war e de la part e
inferior de la j erarqu a haci a arriba.
El primer enf oque (retrasar l as pr uebas hast a no reempl azar los r esguar dos con
los mdul os reales) hace perder cierto control sobre la correspondenci a ent re prue-
bas espec fi cas y la incorporacin de mdul os especficos. Con est o se dificulta
det ermi nar la causa de los errores y se t i ende a violar la nat ural eza al t ament e res-
tringida del enf oque descendent e. Es posibl e t rabaj ar con el segundo enfoque, per o
puede llevar a un aument o i mport ant e de la sobrecarga de trabajo, a medi da que los
r esguar dos se vuel van ms y ms compl ej os. El tercer enfoque, denomi nado prueba
ascendente, se expondr en la siguiente seccin.
Int egraci n as c e nde nt e . La prueba de integraci n ascendente, como su nombr e lo
indica, empi eza la const rucci n y la prueba con mdul os at mi cos (es decir, com-
ponent es de los nivel es ms baj os de la est ruct ura del programa). Debido a que los
component es se integran de abaj o hacia arriba, si empre est disponible el procesa-
mi ent o requeri do para los component es subor di nados a un det er mi nado nivel y se
elimina la necesidad de resguardos. Una estrategia de integracin ascendent e se imple-
ment a medi ant e los si gui ent es pasos:
1. Se combi nan los mdul os de baj o nivel en grupos (tambin l l amados cons-
trucciones) que realicen una subfunci n especfica del soft ware.
2. Se escribe un cont rol ador (un pr ogr ama de control para pruebas) con el fin de
coordi nar la ent rada y la salida de los casos de prueba.
3. Se prueba el grupo.
4. Se el iminan los cont rol adores y se combi nan los gr upos ascendi endo por la
est ruct ura del programa.
La integracin sigue el patrn ilustrado en la figura 13.6. Los component es se
combi nan para formar los grupos 1, 2 y 3. Cada uno de ellos se prueba empl eando
un control ador (mostrado como un recuadro con guiones). Los component es de los
grupos 1 y 2 est n subordi nados a M. Los cont rol adores C, y C2 se eliminan y los gru-
pos i nt eracci onan di rect ament e con Ma. De igual maner a, se elimina el cont rol ador
TM
PDF Editor
3 9 8
Integracin
ascendente.
y p N S E J O ^
La prueba de
regresi n es uno estra-
tegia i m p o M e pora
reducir" electos
colaterales" . Deben
aplicarse pruebas de
regresi n codo vez
que se boga un
cambia importante al
software (incluida lo
integraci n de nuevos
componentes).
Cj del grupo 3 ant es de la integracin con el mdul o Mb. Ma y Mh se integrarn firll
ment e con el mdul o Mc, y as sucesi vament e.
A medi da que la integracin asci ende se reduce la necesi dad de controladores Jm
prueba separados. En realidad, si los dos niveles superi ores de la est ruct ura del pT>
grama se integran de maner a descendent e, se reducir de maner a i mport an: ; d
nmer o de cont rol adores y se simplificar enor mement e la integracin de grupos
Prueba de regresi n. Cada vez que se agrega un nuevo mdul o como par. : aa
una prueba de integracin, el soft ware cambia. Se est abl ecen nuevas rut as de - cj
de dat os, ocurren nuevas ent r adas y sal idas y se invoca una nueva lgica de cor. r
Estos cambi os llegan a causar probl emas con funci ones que ant es funci onaban b
En el cont ext o de una estrategia de prueba de integracin, la aplicacin de una p.-j?
ba de regresin consi st e en ej ecut ar nuevament e el mi smo subconj unt o de prueraJ
que ya se ha apl i cado para asegurarse de que los cambi os no han propagado e>
tos col at eral es i ndeseabl es.
En un cont ext o ms amplio, si l as pr uebas (de cual quier tipo) tienen xit:
resul t ado es el descubri mi ent o de errores, y st os deben corregirse. Cada vez que -
soft ware se corrige t ambi n cambi a al gn aspect o de la configuracin del sof
(el programa, su document aci n o l os dat os de soporte). La prueba de regresir
una actividad que ayuda a asegur ar que los cambi os (debidos a la prueba u co-
razones) no i nt roduzcan compor t ami ent o i ndeseabl e o errores adicionales.
La prueba de regresin se aplica manual ment e, al ej ecut ar de nueva cuenis
subconj unt o de t odos los casos de prueba o al empl ear her r ami ent as automticas
Grupo 1
Grupo 3
TM
PDF Editor
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOFTWARE 3 9 9
capt ura, reproducci n, o ambas. Las herramientas de captura, reproducci n, o de
ambos tipos, permi t en al i ngeni ero del sof t war e capt urar casos de prueba y resulta-
dos para reproducirl os y compararl os despus. El conj unt o de pr uebas de regresin
(el subconj unt o de pr uebas que se aplicarn) cont i ene tres cl ases di ferent es de casos
de prueba:
CVVi
i de humo
: caracterizarse
: uno estrategia
o. Se
i el software
r ne vos
I y se aplica
raba de humo
i los das.
Una muest ra represent at i va de pr uebas que ej ercern t odas las funci ones del
soft ware.
Pruebas adi ci onal es que se concent ran en las funci ones del sof t war e que
probabl ement e el cambi o afectara.
Pruebas que se concent ran en los component es del soft ware que han
cambi ado.
A medi da que avanza la prueba de integracin, la cant i dad de pruebas de regresin
llega a volverse muy grande. Por t ant o, el conj unt o de pr uebas de regresin debe
di searse para que sl o incluya las que at i enden una o ms cl ases de errores en cada
una de las funci ones principales del programa. Resulta poco prctico e ineficiente
repetir cada prueba para t odas l as funci ones del pr ogr ama despus de que se ha pre-
sent ado un cambi o.
Prueba de humo. La prueba de humo es un enf oque de prueba de integracin que
suel e utilizarse mi ent ras se desarrol l an product os de soft ware. Est di seado como
mecani s mo para mar car el ritmo en proyect os en los cual es el t i empo es crtico, lo
que permi t e que el equi po de sof t war e eval e su proyect o con frecuenci a. En esen-
cia, el enf oque de la prueba de humo abarca las si gui ent es actividades:
1. Los component es de sof t war e t raduci dos a cdi go se integran en una "cons-
truccin", la cual incluye t odos los archi vos de dat os, las libreras, l os mdu-
los reutilizables y los component es de ingeniera que se requieren para
i mpl ement ar una o ms funci ones del producto.
2. Se di sea una serie de pr uebas para exponer errores que i mpedi rn que la
const rucci n realice apr opi adament e su funcin. El objetivo es descubrir erro-
res "paral izantes" que t engan la mayor probabilidad de ret rasar el proyect o de
soft ware.
3. La const rucci n se integra con ot ras const rucci ones, y diariamente se aplica
una prueba de humo a t odo el product o (en su forma actual). El enf oque de la
integracin puede ser descendent e o ascendent e.
La aplicacin diaria de una prueba a t odo el product o sorprender a al gunos lecto-
res. Sin embargo, l as pruebas frecuent es dan a los jefes de proyect o y part i ci pant es
una eval uaci n realista del avance de las pr uebas de integracin. McConnell
[ M C 0 9 6 ] descri be as la prueba de humo:
TM
PDF Editor
4 0 0
La prueba de humo debe ejercitar todo el sistema de principio a fin. No debe ser exhaus-
tiva, pero debe tener la capacidad de exponer problemas importantes. La prueba de hume
debe ser tan completa que si la construccin la aprueba, puede suponerse que sta es
suficientemente estable como para probarla de manera ms completa.
La prueba de humo proporci ona vari os benefi ci os cuando s e aplica en proyectos
ingeniera del sof t war e compl ej os y que dependen en forma crtica del t i empo
Se minimiza el nesgo en la integraci n. Debido a que l as pr uebas de humo se
aplican diariamente, desde el principio se descubren l as incompatibilidad:-:
ot ros errores paral i zant es, por lo que se reduce la probabilidad de que t
un fuert e i mpact o en el cal endari o cuando se descubran errores.
Se mejora la calidad del producto final. Como el enfoque est ori ent ado a la
const rucci n (integracin), es probabl e que la prueba de humo descubra
errores funci onal es, arqui t ect ni cos y al nivel de component es. Si est os
errores se corrigen desde el principio, se obt endr una mayor calidad e -
producto.
Se simplifican el diagn stico y la correcci n de errores. Como t odos los e
de prueba de integracin, es probabl e que los errores no descubiertos er
prueba de humo est n asoci ados con "nuevos i ncr ement os de soft ware
sof t war e que se acaba de aadi r a la const rucci n es una posible causa i r
error recin descubierto).
El progreso es ms fcil de evaluar. Cada da que pasa se integra ms
y se demuest r a que funci ona. Esto mej ora la moral del equi po y brinda a ~
j efes de proyect o una buena indicacin de que se est n l ogrando avances I
"Trole la construccin diaria como si fuero el corazn del proyedo. Si no tiene corazn, el proyedo est mu - : '
J i m
Opci ones es t rat gi cas . Ha habi do mucha discusin (por ej empl o, (BEl-)
las vent aj as y desvent aj as relativas de las pruebas de integracin ascender : ; JJ
cendent e. En general, las vent aj as de una estrategia tienden a convertirse e r -*
t aj as para la otra. La principal desvent aj a del enfoque descendent e es la neo
resguardos y las dificultades de las pruebas asoci adas. Los probl emas re"~
con los resguardos se compensar an con la ventaja de probar l as principales .
nes de control en l as pri meras et apas. La principal desvent aj a de la in
ascendent e es que "el programa, como una entidad, no existe hast a que se tal
dido el ltimo mdul o" (MYE79]. Esta desvent aj a la at ena la mayor fcil
di sear casos de prueba y la falta de resguardos.
La sel ecci n de una estrategia de integracin depende de l as caract e
soft ware y, en ocasi ones, del cal endari o del proyecto. En general , la mejor
un enf oque combi nado (a veces denomi nado prueba sandwich) que usa p
R e f e r e n c i a We b
Apuntodotes o
comentarios sobre
estrategias de pruebo
se encontrarn en:
www. qal i nks. com.
TM
PDF Editor
cendent es para los niveles superiores de la estructura del programa, junto con prue-
bas ascendent es para los niveles subordinados.
A medida que se realiza la prueba de integracin, el responsable debe identificar
mdulos crticos. Un m dulo crtico tiene una o ms de las siguientes caractersticas:
1) atiende varios requisitos del software, 2) tiene un alto grado de control (se encuen-
tra en un lugar relativamente alto de la estructura del programa), 3) es complejo o
propenso a errores, o 4) tiene requisitos de desempeo bien definidos. Los mdul os
crticos deben probarse lo ant es posible. Adems, las pruebas de regresin se deben
concentrar en el funci onami ent o de los mdul os crticos.
Document aci n de la prueba de i ntegraci n. Un plan general para la integra-
cin del soft ware y una descripcin de pruebas especficas se document an en la
Especificaci n d la prueba. Este document o que contiene un plan de prueba, un pro-
cedimiento de prueba, es un producto de t rabaj o del proceso de soft ware y se vuel-
ve parte de la configuracin del software.
El plan de prueba describe la estrategia general de integracin. La prueba se divi-
de en fases y construcciones que atienden caractersticas especficas del funciona-
mi ent o y el comport ami ent o del software. Por ejemplo, la prueba de integracin para
un sistema de diseo asistido por computadora se dividira en las siguientes fases de
prueba:
Interaccin del usuario (seleccin de comandos, creacin de dibujos, repre-
sentacin del despliegue, procesami ent o de errores y representacin).
Manipulacin y anlisis de dat os (creacin de smbolos, asignacin de dimen-
siones, rotacin, clculo de propiedades fsicas).
Procesamiento y generacin de despliegue (despliegues bi y tridimensionales,
i mgenes y grficas).
Administracin de base de dat os (acceso, actualizacin, integridad,
desempeo).
Cada una de est as fases y subfases (denotadas ent re parntesis) delinean una amplia
categora funcional dentro del soft ware y suelen relacionarse con un dominio espe-
cfico dent ro de la arquitectura del software. Por tanto, las construcciones del pro-
grama (grupos de mdulos) se crean para que correspondan con cada fase. Los
siguientes criterios y las pruebas correspondientes se aplican para todas las fases de
prueba.
Integridad de la interfaz. Las interfaces internas y ext ernas se prueban a medida
que cada mdulo (o grupo) se incorpora en la estructura.
Validez funcional. Se realizan las pruebas di seadas para descubrir errores fun-
cionales.
Contenido d la informaci n. Se aplican las pruebas di seadas para descubrir erro-
res asociados con estructuras de datos locales o globales.
Ov es un
dul o critica
y por qu
identificarse?
TM
PDF Editor
Desempeo. Se real izan las pr uebas di seadas para verificar los lmites de desem-
peo est abl eci dos dur ant e el di seo del soft ware.
Un cal endari o para la integracin, el desarrollo de soft ware de sobrecarga \
t emas rel aci onados t ambi n se anal i zan como part e del pl an de prueba. Se detc
nan l as fechas de inicio y t rmi no para cada fase y se defi nen l as "vent anas de
ponibilidad" para los mdul os de prueba de unidad. Una breve descripcin del
war e de sobrecarga (resguardos y control adores) se concent ra en las caracte~
que requi eren esf uer zos especial es. Por ltimo, se descri ben el ent or no y los
sos de la prueba. Confi guraci ones poco comunes de hardware, si mul adores ex
y her r ami ent as especi al es de prueba son al gunos de los muchos t emas que ta
podr an anal i zarse.
A cont i nuaci n se describe el procedi mi ent o det al l ado de prueba que se r
para compl et ar el plan respectivo. Tambin se detalla el orden de integracin
pr uebas correspondi ent es en cada paso de integracin. Adems, se incluye-
lista de t odos l os casos de prueba (anot ados para referencia posterior) y los
dos esperados.
Una historia de resultados, probl emas o pecul iaridades de l as pr uebas rea. r
registra en el Informe de prueba que puede adj unt arse a la Especificaci n de
Si s e desea, la i nformaci n cont eni da en esta secci n ser vital dur ant e el
mi ent o del soft ware. Tambin se pr esent an referenci as y apndi ces apropiadc
Como t odos los dems el ement os de una confi guraci n de soft ware, el
de la especificacin de prueba puede amol darse a l as necesi dades locales ce
organi zaci n de ingeniera del soft ware. Sin embargo, es i mport ant e observa
una estrategia de integracin (contenida en el plan de prueba) y los detalles de
ba (descritos en el procedi mi ent o de prueba) son i ngredi ent es esenci al es y
aparecer.
"El mejor participante de uno pruebo no es el que encuentro ms er r or es. . . sino el que corrige la mayor conlidod de
Cem Kan
1 3 . 4 ESTRATEGI AS DE PRUEBA PARA SOFTWARE ORI ENTADO A QE.
El objetivo de probar, para definirlo de maner a simple, es encont rar la mayor
dad de errores apl i cando una cant i dad manej abl e de esfuerzo en un periodo
ta. Aunque est e objetivo f undament al sigue sin cambi o para el sof t war e orie
objetos, la nat ural eza de est e sof t war e cambi a la estrategia y la tctica de las
bas (captulo 14).
13.4.1 Prueba de unidad en el contexto orientado a objetos
Al pensar en el soft ware ori ent ado a obj et os cambi a el concept o de uni se
encapsul aci n orienta la definicin de cl ases. Esto significa que cada cl ase e ,
cia de una cl ase (objeto) empaquet a at ri but os (datos) y las operaci ones (fu
que mani pul an est os dat os. Una cl ase encapsul ada suel e ser el eje de las p
TM
PDF Editor
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOfT. VAKE 4 0 3
LAVE
] de dase
saftwore
a objetos es
a la prueba de
poro software
i No es
probar
de manera
unidad. Sin embargo, las uni dades de prueba m s pequeas son las oper aci ones
dent r o de la clase. Debido a que una cl ase puede cont ener varias oper aci ones dife-
rent es y a que una operaci n det ermi nada puede existir como part e de vari as cl ases
diferentes, deben cambi ar l as tcticas apl i cadas para la prueba de unidad.
No es posible probar una sola operaci n de maner a ai sl ada (el concept o conven-
cional de prueba de unidad) sino como part e de una clase. Para ilustrarlo, consi d-
rese una jerarqua de cl ase en que se defi ne una operaci n X para la supercl ase y que
her edan varias subcl ases. Cada una de st as usa la operaci n X , per o se aplica den-
tro del cont ext o de los at ri but os pri vados y l as operaci ones que se han definido para
la subcl ase. Dado que el cont ext o en que se empl ea la operaci n X vara en f or mas
sutiles, es necesari o probar la operaci n en el cont ext o de cada una de las subcl a-
ses. Esto significa que si se prueba la operaci n X de maner a i ndependi ent e (el enfo-
que de la prueba de uni dad convencional ) se podr usar de maner a deficiente en el
cont ext o ori ent ado a objetos.
La prueba de cl ase para el sof t war e ori ent ado a obj et os es el equi val ent e a la
prueba de uni dad para el sof t war e convenci onal . A diferencia de sta, que t i ende a
concent r ar se en el detal l e al gortmico de un mdul o y en los dat os que fluyen por la
interfaz del mdulo, la prueba de cl ase para el sof t war e ori ent ado a obj et os se ori en-
ta medi ant e las oper aci ones que encapsul a la cl ase y en el compor t ami ent o de est a-
do de la clase.
K
C L V B
estrategia
para la
de integracin
software orientado
n e t o s es la prueba
en
esos. Los
esos son
de clases
i responden a uno
i o un evento.
- 2 pruebas basadas
s e i u s o s e
centran en las
3 E ses q u e n o
-' oboron mucho con
uns clases.
13.4.2 Prueba de integracin en el contexto orientado a objetos
Debido a que el soft ware ori ent ado a obj et os no tiene una estrategia obvia de con-
trol jerrquico, tienen poco significado las est rat egi as de integracin descendent e y
ascendent e t radi ci onal es (seccin 13.3.2). Adems, integrar l as oper aci ones una por
una en una cl ase (el enf oque convenci onal de la integracin incrementa!) suel e
resultar imposible debi do a las "interacciones directas e indirectas de los compo-
nent es que integran la clase" [BER93],
Hay dos est rat egi as di ferent es para la prueba de integracin de los si st emas orien-
t ados a obj et os [BIN94]. La pri mera, la prueba basada en subprocesos, integra el con-
j unt o de cl ases requerido para responder a una ent r ada o un event o del si st ema.
Cada subproceso s e integra y prueba individualmente. La prueba de regresin se
aplica para asegurar que no se present en efect os col at eral es. El segundo enf oque de
integracin, la prueba basada en el uso, empi eza la const rucci n del si st ema con la
prueba de esas cl ases (l l amadas clases independientes) que usan muy pocas cl ases de
servidor (o ninguna). Despus de que se pr ueban las cl ases i ndependi ent es, se prue-
ba la si gui ent e capa de cl ases, l l amadas clases dependientes, que usan l as cl ases
i ndependi ent es. Esta secuenci a de capas de prueba de cl ases dependi ent es cont i na
hast a que se const ruye t odo el si st ema.
El uso de cont rol adores y r esguar dos t ambi n cambi a cuando s e apl i can pruebas
de integracin a los si st emas ori ent ados a obj et os. Con los cont rol adores se prueban
oper aci ones al nivel ms baj o y grupos compl et os de cl ases. Un cont rol ador t ambi n
TM
PDF Editor
404
se utiliza para reempl azar la interfaz de usuario, de modo que puedan aplicarse
pruebas de funci onal i dad del si st ema ant es de la i mpl ement aci n de la interfaz.
r esguar dos s e usan en si t uaci ones en que la col aboraci n ent r e cl ases es neces
per o en las cual es an no se han i mpl ement ado por compl et o una o ms de las
ses que col aboran.
La prueba de grupo es un paso en la prueba de integracin del sof t war e orie
do a obj et os. Aqu, un grupo de cl ases que col aboran ent r e si (det ermi nadas po-1
examen del CRC y el model o objeto-relacin) s e ejercita al di sear casos de pr
que tratan de descubrir errores en las col aboraci ones.
\
CLAVE
Como todos los demos
pasos de pruebo, en lo
validacin se trata de
descubrir errores, pero
el punto central est
en el nivel de los
requisitos (o las cosas
que sern
inmediatamente
evidentes pora el
usuario final).
Las pruebas de validaci n empi ezan t ras la cul mi naci n de la prueba de integra
cuando se han ej erci t ado los component es individuales, se ha t ermi nado de er
blar el sof t war e como paquet e y se han descubi ert o y corregido los errores de
faz. En el nivel de validacin o si st ema desapar ece la distincin ent re soft ware <
venci onal y ori ent ado a obj et os. La prueba se concent ra en l as acci ones visibles;
el usuario y en la salida del si st ema que st e puede reconocer.
La validaci n se defi ne de muchas formas, pero una definicin si mpl e (ai
vulgar) es que se al canza cuando el soft ware funciona de tal maner a que satisface i
expectativas razonabl es del cliente. En est e punt o, un desarrollador de soft ware t
ri ment ado protestara: "Qu o quin decide lo que es una expectativa r azonaba"
Las expect at i vas razonabl es se defi nen en la Especificaci n de requisitos de
ware (un document o que describe l os atributos del sof t war e visibles para el t
La especificacin cont i ene una secci n denomi nada Criterios de validaci n. La ;
maci n cont eni da en esa seccin i nt egra la base del enfoque de la prueba de
dacin.
13.5.1 Criterios de la prueba de validacin
La validacin del soft ware se logra medi ant e una serie de pr uebas que demi
que se cumpl e con los requisitos. Un plan de prueba del i nea la cl ase de pruebas i
se apl icarn, y un procedi mi ent o de prueba define los casos de prueba espe
Tant o el pl an como el procedi mi ent o se di sean para asegurar que se sat
t odos los requisitos funci onal es, que se al canzan t odas las caractersticas
port ami ent o, que se cumpl e con t odos los requisitos de desempeo, que la
ment aci n es correct a y que se cumpl e t ambi n con t odos los requi si t os de fa
de uso y ot ros requisitos especi fi cados (por ejempl o, portabilidad, compatib
recuperaci n de errores, facilidad de mant eni mi ent o).
Despus de que se ha dirigido cada caso de prueba de validacin, existir i
dos condi ci ones posibles: 1) la caracterstica de funci onami ent o o desempee
pie con la especificacin y se le acept a, o 2) se descubre una desviacin de
cificacin y se crea una lista de deficiencias. La desviacin o el error descubie
TM
PDF Editor
CAPITULO 13 ESTRATEGIAS DE PRUEBA DEL SOTTWASE
4 0 5
est a et apa de un proyecto rara vez se corrige ant es de la fecha de ent rega. A menu-
do es necesari o negociar con el cliente un mt odo para resolver las deficiencias.
13.5.2 Revisin de la configuracin
La revisi n de la configuraci n es un el ement o i mport ant e del proceso de validacin;
su objetivo es asegur ar que t odos los el ement os de la confi guraci n del sof t war e se
hayan desarrol l ado apropi adament e, est n cat al ogados y t engan el detalle suficien-
te para reforzar la fase de soport e del ciclo de vida del soft ware. La revisin de la
configuracin, a veces denomi nada auditoria, se anal i zar con ms detalle en el
captulo 27.
13.5.3 Pruebas alfa y bet a
En la prctica es imposible que un desarrol l ador de sof t war e prevea cmo utilizar
el usuari o real ment e el programa. Es posibl e que se mal i nt erpret en las i nst rucci ones
de uso, que se utilicen con regularidad ext raas combi naci ones de dat os, que una
salida en apari enci a clara para el responsabl e de las pr uebas sea ininteligible para
un usuari o en el campo.
Al construir sof t war e personal i zado para un cl iente se aplica una serie de prue-
bas de acept aci n que permiten al cliente validar t odos los requisitos. El usuari o final
conduce, no l os i ngeni eros del soft ware, las pr uebas de acept aci n, las cual es van
desde una "prueba de manej o" informal hast a una serie de pruebas pl aneadas y ej e-
cut adas de maner a si st emt i ca. En realidad, la prueba de acept aci n llega a durar
s emanas o meses, por lo que es posible descubrir errores acumul at i vos que degra-
dan el si st ema.
"Si se recurre a ojos suficientes, todos los errores sern superficiales (por ej empl o, si hay una base lo sufi ci ent ement e
gr ande de personos que realizan las pruebas bet a y de codesarrolladores, casi todos los probl emas se caract eri zarn
r pi dament e y la correccin ser obvia para al gui en). "
I . Ro y mo n d
Si el sof t war e se desarrolla como un product o que usarn muchos clientes, no es
prctico realizar pr uebas de acept aci n formal es para cada uno. La mayor a de los
const ruct ores de product os de sof t war e empl ean procesos l l amados prueba alfa y
prueba beta para descubrir errores que slo el usuari o final podra detectar.
Los usuari os finales son qui enes aplican la prueba alfa en el lugar de t rabaj o del
desarrollador. El sof t war e se utiliza en un ent or no natural mi ent ras el desarrol l ador
"mira sobre el hombro" de los usuari os tpicos y registra l os errores y los probl emas
de uso. Las pr uebas alfa se realizan en un ent or no cont rol ado.
Las pruebas beta se aplican en el lugar de t rabaj o de los usuari os finales. A dife-
rencia de la prueba alfa, por lo general el desarrol l ador no est . Por t ant o, la prueba
bet a es una aplicacin "en vivo" del sof t war e en un ent or no que no control a el desa-
rrollador. El usuari o final registra t odos los probl emas (reales o imaginarios) que
TM
PDF Editor
4 0 6
encuent r a dur ant e la pr ueba y l os i nf or ma de ma n e r a r egul ar al desar r ol l ador . CCTM
r esul t ado de l os pr obl emas i nf or mados dur a nt e l as pr ue ba s bet a, l os i ngeni er os : e |
s of t wa r e l o modi f i can y l uego pr epar an la l i beraci n del pr oduct o de s of t war e F^ a J
t oda la ba s e de cl i ent es.
HOGARSEGURO
Preparacin para validacin
Lo escena: Oficina de Doug
Milter, mientras contina el diseo al nivel de
componentes y empieza la construccin de ciertos
componentes.
Los actores: Doug Miller, jefe de ingeniera de
software, Vinod, Jamie, Ed y Shokira, integrantes del
equipo de ingeniera del software HogarSeguro.
La conversaci n:
Doug: El primer incremento estar listo para validacin
en... unas tres semanas?
Vinod: Es correcto, la integracin va bien. Estamos
realizando pruebas de humo a diario, encontrando
algunos errores, pero nada que no se pueda manejar.
As que hasta ahora todo va bien.
Doug: Cuntame un poco de la validacin.
Shakira: Bueno, emplearemos todos los casos de uso
como base para el diseo de nuestras pruebas. An no
he empezado, pero estar desarrollando pruebas para
todos los casos de uso de los que soy responsable.
Ed: Lo mismo yo.
Jamie: Yo tambin, pero tendremos que actuar juntos
para la prueba de aceptacin y tambin para las
pruebas alfa y beta, verdad?
Doug: S, en realidad he pensado que podramos
a un contratista que nos ayude con la validacin. Teogc
dinero en el presupuesto... y nos dara una perspecr ;
fresca.
Vinod: Creo que lo tenemos todo bajo control.
Doug: Estoy seguro de eso, pero un grupo
independiente de prueba nos dar un punto de vista
autnomo sobre el software.
Jamie: Estamos justos de tiempo aqu, Doug. Yo, e- ;
personal, no tengo tiempo para cuidar a nadie que
traigas a hacer el trabajo.
Doug: Lo s, lo s. Pero si un GIP trabaja a partir ir a
requisitos y casos de uso, no requerir mucha ayucc
ustedes.
Vinod: Todava pienso que lo tenemos todo bajo cc-ai
Doug: Ya te o, Vinod, pero me voy a imponer en
Planeemos el encuentro con el representante del Gl- i
adelante, esta misma semana. Dejemos que empiece y
veamos que nos trae.
Vinod: Muy bien, tal vez aligere un poco la carga
1 3 . 6 P R UE B A DEL S I S T E MA
En el i ni ci o de est e l i bro s e des t ac el he c ho de que el s of t wa r e s l o es un e l e
t o de un s i s t ema de c mput o m s gr ande. Al final, el s of t wa r e s e i ncor por a a ;
e l e me nt os del s i s t ema ( como har dwar e, per s onas , i nf or maci n) , y s e real iza a
seri e de pr ue ba s de i nt egr aci n del s i s t ema y de val i daci n. Est as pr uebas es t a- n
all del al cance del pr oc e s o del s of t war e y n o l as r eal i zan ni c a me nt e l os i r g- a
r os del s of t war e. Si n embar go, l os pa s os da dos dur ant e el di s eo y la pr ueba d e a
wa r e me j or a r n en gr an medi da la pr obabi l i dad de t ener xi t o en la i nt e gr a c
s of t war e en el s i s t ema mayor .
"Al igual que lo mue r t e y los i mpuest os, las pr uebas son des agr adabl es e i nevi t abl es. "
Ed Y
TM
PDF Editor
Un problema clsico de la prueba del sistema es "sealar con el dedo". Esto ocurre
cuando se descubre un error y el desarrollador de cada elemento del sistema culpa a
los dems. En lugar de caer en este absurdo, el ingeniero del software debe anticipar-
se a posibles problemas con la interfaz y 1) disear rutas de manej o de errores que
prueben toda la informacin proveniente de otros el ementos del sistema, 2) aplicar
una serie de pruebas que simulen datos incorrectos u otros posibles errores en la inter-
faz del software, 3) registrar los resultados de las pruebas como "evidencia" en el caso
de que se le culpe, y 4) participar en la planeacin y el diseo de pruebas del sistema
para asegurar que el software se ha probado adecuadamente.
En realidad, la prueba del sistema abarca una serie de pruebas diferentes cuyo pro-
psito principal es ejercitar profundament e el sistema de cmputo. Aunque cada
prueba tiene un propsito diferente, t odas trabajan para verificar que se hayan inte-
grado adecuadament e todos los el ement os del sistema y que realizan las funciones
apropiadas. En las siguientes secciones se exami narn los tipos de pruebas del sis-
tema [BEI84] que valen la pena para sistemas basados en software.
13.6.1 Prueba de recuperacin
Muchos sistemas de cmput o deben recuperarse de fallas y reanudar el procesa-
miento en un tiempo determinado. En algunos casos, un sistema debe ser tolerante
con las fallas; es decir, las fallas de procesami ent o no deben llevar a la cada del sis-
tema, en general. En otros casos, una falla del sistema debe corregirse dent ro de un
periodo especfico o se sufrir un fuerte dao econmico.
La prueba de recuperaci n es una prueba del sistema que obliga al software a
fallar de varias maner as y a verificar que la recuperacin se realice apropi adamen-
te. Si la recuperacin es automtica (la realiza el propio sistema) debe evaluarse que
sean correctos la reinicializacin, los mecani smos de respaldo del sistema, la recu-
peracin de dat os y el nuevo arranque. Si la recuperacin requiere intervencin
humana, se debe evaluar el tiempo medio de reparacin (TMR) para determinar si se
encuent ra dent ro de lmites aceptables.
13.6.2 Prueba de seguridad
Cualquier sistema de cmput o que manej e informacin confidencial o que desenca-
dene acciones que daen (o beneficien) inapropiadamente a los individuos es un
blanco para irrupciones impropias o ilegales. La irrupcin abarca un amplio rango
de actividades: hackers que tratan de entrar en los sistemas por juego, empl eados
disgustados que tratan de irrumpir como forma de venganza, e individuos desho-
nestos que buscan gananci as personal es ilcitas.
La prueba de seguridad comprueba que los mecani smos de proteccin integrados
en el sistema real mente lo protejan de irrupciones inapropiadas. Para citar a Beizer
[BE184J: "Por supuesto que debe probarse la seguridad del sistema para asegurar que
es invulnerable a los at aques frontales, pero tambin a los perpet rados por los flan-
cos o la retaguardia".
TM
PDF Editor
Durant e la prueba de seguridad, qui en la aplica des empea el papel del indivich.
que desea ent rar en el si st ema. Todo se vale! Debe tratar de obt ener cont rasea
por cualquier medi o externo; podra at acar el si st ema con sof t war e personal i zad
di seado para burlar cual quier def ensa que se haya construido; podra sat urar el s t
t ema, negando as el servicio a otros; podra producir errores intencionales en el siscr
ma para t rat ar de t ener acceso durant e la recuperaci n; podra revisar dat os sin pro-
teccin, con la idea de encont r ar la clave de acceso al si st ema.
Si se dan el t i empo y l os recursos suficientes, una buena prueba de seguridad
mi nar por irrumpir en el si st ema. El papel del di seador del si st ema es que el cc-s
de la irrupcin sea mayor que el valor de la i nformaci n que habr de obt enerse
13.6.3 Prueba de resistencia
Los pasos de prueba anal i zados ant es, en est e mi smo captulo, llevan a una evai ,
cin compl et a de l as funci ones y el des empeo nor mal es del programa. Las pr uer - sl
de resistencia est n di seadas para confront ar l os pr ogr amas con si t uaci ones ar .r-
males. En esenci a, la persona que realiza la prueba de resistencia se pregunt a-e
"Hasta dnde puedo llevar est o ant es de que falle?"
La prueba de resistencia ej ecut a un si st ema de tal maner a que requiera una canr-l
dad, una frecuenci a o un vol umen anormal de recursos. Por ejempl o: 1) se d i s e a
pr uebas especi al es que generen diez i nt errupci ones por segundo, cuando la u J
promedi o es de una o dos-, 2) se aument a la frecuenci a de ent r ada de dat os en JT
magni t ud que permi t a det ermi nar cmo r esponder n las funci ones de ent rada > a t
ej ecut an casos de prueba que requi eran el mxi mo de memori a u ot ros recurs -
se di sean casos de prueba que causen probl emas de admi ni st raci n de merr
5) se crean casos de prueba que produzcan bsquedas excesivas de dat os en el e s e *
En esenci a, la persona que aplica la prueba tratar de sobrecargar el programa.
"Si este t rot ando de encontrar verdaderos errores del si st ema y no ha sometido su soft ware a una ver dader a prueo:
de resistencia, entonces ste es el moment o de empezar ".
Boris Bc r i
Una vari ant e de la prueba de resi st enci a es una tcnica denomi nada pr uer ;
sensibilidad. En al gunas si t uaci ones (la ms comn de ellas ocurre con los
mos mat emt i cos), un r ango muy pequeo de dat os cont endi dos dent ro de los I BH
tes de los dat os vlidos par a un pr ogr ama puede causar pr ocesami ent o ext rema
incl uso errneo, o una fuert e degradaci n del desempeo. Las pr uebas de s er =H
dad t rat an de descubrir combi naci ones de dat os dent ro de l as cl ases de entrada
das que causen inestabilidad o pr ocesami ent o i napropi ado.
13.6.4 Prueba de desempeo
En si st emas en t i empo real e i ncrust ados es i nacept abl e el sof t war e que prop i o *
na la funci n requeri da per o que no cumpl e los requisitos de desempeo. La
de des empeo est di seada para probar el desempeo del sof t war e en t i e r r : - gH
TM
PDF Editor
ejecucin dent r o del cont ext o de un si st ema integrado. La prueba de des empeo se
aplica en t odos los pasos del pr oceso de la prueba. Incluso al nivel de la uni dad, el
desempeo de un mdul o individual debe eval uarse mi ent ras s e realizan las pruebas.
Sin embargo, no es sino hast a que se encuent ran total mente integrados t odos los ele-
ment os del si st ema que es posible asegurar el verdadero desempeo del si st ema.
Con frecuenci a las pruebas de des empeo se vinculan con pr uebas de resistencia
y suel en requerir i nst rument aci n de sof t war e y hardware. Es decir, a menudo resul-
ta necesari o medi r con exactitud la utilizacin de recursos (por ejempl o, los ciclos de
procesador). Medi ant e i nst rument aci n ext erna pueden vigilarse de maner a regular
los intervalos de ejecucin, los event os que se registran (como las interrupciones) y
los estados de muestra del equipo. Si se instrumenta un sistema, la persona que aplica la
prueba descubrir situaciones que lleven a la degradacin y posibles fallas del sistema.
Planeaci n y administraci n
de pruebas
Objetivo: Estas herramientas ayudan al
> de software a planear la estrategia de prueba que
- de elegirse y a manejar el proceso de prueba a
i que se aplica.
nica: Las herramientas de esta categora atienden
cin y el almacenamiento de la prueba, la
listracin y el control, el seguimiento de los
s, la integracin, el rastreo de errores y la
cin de informes. Los jefes de proyecto las usan
i complementar las herramientas de planeacin.
aplican las pruebas usan estas herramientas para
r actividades de prueba y controlar el flujo de
acin a medida que avanza el proceso de prueba.
Herramientas representativas2
OTF (Object Testing Frameworkl, desarrollado por MCG
Software Inc. (www.mcgsoft.com), proporciona un
marco conceptual para la administracin de conjuntos
de pruebas para objetos Smalltalk.
QADireclor, desarrollado por Compuware Corp.
(www.compuware.com/qacenter), proporciona un solo
punto de control para administrar todas las fases del
proceso de prueba.
TestWorks, desarrollado por Software Reasearch Inc.
(www.soft.com/Products/index, html), contiene un
conjunto plenamente integrado de herramientas de
prueba, incluidas algunas que sirven para el manejo y
la generacin de informes de las pruebas.
La prueba del sof t war e es un pr oceso que puede pl anearse y especificarse si st em-
t i cament e. Se di sea el caso de prueba, se defi ne una estrategia y se eval an los
resul t ados frent e a las expect at i vas prescritas.
La depuraci n ocurre como consecuenci a de una prueba realizada con xito. Es
decir, cuando un caso de prueba descubre un error, la depuraci n es la accin que
lo elimina. Aunque la depuraci n puede y debe ser un proceso ordenado, sigue sien-
do un arte. Un ingeniero del soft ware, al eval uar los resul t ados de una prueba, suel e
2 Las herramientas expuestas aqu slo representan una muestra de esta categora. En casi todos los
TM
PDF Editor
enfrent arse con una indicacin "sintomtica" de un probl ema de soft ware. Es den-
tal vez la mani fest aci n ext erna del error y su causa i nt erna no tienen una relac: :ir
obvia. La depuraci n es el proceso ment al que conect a un s nt oma con una causa
"En t uonl o empezomos la programaci n, descubrimos, par a nuestro sorpresa, que no ser fcil conseguir el p r o g r a r :
que tenemos en mente. Es necesario descubrir la depuracin. Recuerdo el moment o exacto en que me di cuenta de que
iba a gast ar gran part e de mi vida, a partir de ese moment o, en encontrar los errores de mis propios programas. "
Maurice Wi l kes, descubre l a depuracin en 194;
El proceso de
depuracin.

13.7.1 El proceso de depuracin
La depuraci n no es una prueba, pero si empre ocurre como consecuenci a de
Si se t oma como referencia la figura 13.7, el proceso de depuraci n comi enza cor.
ejecucin de un caso de prueba. Se eval an los resul t ados y se encuent r a una
de correspondenci a ent re el des empeo esper ado y el real. En muchos casos d
dat os que no corresponden son s nt oma de una causa que an no aparece. La deot - l
racin trata de rel acionar el s nt oma con la causa, lo que conduce a corregir el e mx l
La depuracin si empre arroja dos resultados: 1) se encuent ra y se corrige la ca-SJ
o 2) no se localiza la causa. En est e ltimo caso, la persona encargada de la d ^ - ^ J
cin debe sospechar la causa, di sear uno o ms casos de prueba que ayuden
validar esa sospecha y avanzar hacia la correccin del error de maner a iterativa
Pruebas
de regresin
Correcciones^ Causas
identificadas
Al hacer esta afirmacin se toma el concepto ms amplio posible de la prueba. No slo el desam
llador prueba el software antes de la liberacin, sino que el cliente, el usuario, o ambos, pr
software cada vez que lo usan!
pruerar |
TM
PDF Editor
CAPTULO 13 ESTRATEGIAS DE PRUEBA D a SOFTWARE 4 1 1
Por qu es tan difcil la depuraci n? Con toda probabilidad, la respuest a se rela-
ciona ms con la psicologa humana (consulte la siguiente seccin) que con la tec-
nologa del soft ware. Sin embargo, ciertas caract er st i cas de los errores ofrecen
al gunas pistas:
1. El s nt oma y la causa pueden est ar separ ados geogrfi cament e. Es decir,
aqul apar ece en una parte del pr ogr ama mi ent ras sta se ubica en un sitio
distante. Los component es con un fuert e acopl ami ent o (captulo 11) exacer-
ban est a situacin.
2. Es posible que el s nt oma desapar ezca (temporal mente) al corregir ot ro error.
3. Es probabl e que el s nt oma no lo cause al gn error (como en el caso de ine-
xact i t udes al r edondear cifras).
4. El s nt oma podra deber se a un error humano difcil de localizar.
5. El s nt oma podra deberse a probl emas de t i empo y no de procesami ent o.
6. Tal vez sea difcil reproducir con exactitud l as condi ci ones de ent r ada (por
ejempl o, una aplicacin en t i empo real en que no est definido el orden de
entrada).
7. El s nt oma podra present arse i nt ermi t ent ement e. Esto suel e ser comn en
si st emas empot r ados que acopl an el har dwar e y el sof t war e de maner a inex-
tricable.
8. Probabl ement e el s nt oma se debe a causas distribuidas ent re varias t areas
que se ej ecut an en di ferent es pr ocesador es [CHE90].
Durante la depuraci n se encuent r an errores que van de medi anament e mol est os
(como un format o de salida incorrecto) a cat ast rfi cos (por ejempl o, el si st ema falla
y causa seri os daos econmi cos o fsicos). A medi da que aument an l as consecuen-
ci as de un error, t ambi n se i ncrement a la presin para encont rar la causa. A menu-
do, debi do a la presin, un desarrol l ador del sof t war e i nt roduce dos errores ms al
tratar de corregir uno.
' !
"Todos soben que depurar es dos veces ms difcil que escribir el programo. Por tanto, si aplica t oda su inteligencia
poro escribirlo, cmo espera siquiera depurarl o?"
Br i an Ke r ni gha n
13.7.2 Consideraciones psicolgicas
Por desgracia, hay evidencia de que las dest rezas para la depuraci n son i nnat as en
el ser humano. Ciertas per sonas son buenas par a ella; ot r as no. Aunque la evidencia
experi ment al sobr e la depuraci n est abi ert a a muchas i nt erpret aci ones, se han
report ado gr andes vari aci ones en la habilidad para la depuraci n en pr ogr amador es
con educaci n y experi encia similares.
TM
PDF Editor
Al c o me n t a r l os a s p e c t o s h u ma n o s d e la de pur a c i n, Sh n e i d e r ma n [SHN80] i
La depuraci n es una de las part es m s frust rant es de la programaci n. Incluye el eme-
tos de resolucin de pr obl emas o de r et os ment al es, junto con el mol est o reconoci mi e-:
de que se ha comet i do un error. La creci ent e ansi edad y escasa vol unt ad de acept ar la e .-
tencia de errores aument an la dificultad de la tarea. Por fortuna, se present a un gran al -
vio y la t ensi n decrece cuando el error finalmente... se corrige.
Au n q u e s e a difcil " a pr e nde r " a de pur a r , s e p r o p o n e n va r i os e n f o q u e s p a r a e l :
b l e ma . Se e x a mi n a r n e n la s i gui e nt e s e c c i n.
HOGARSEGURO
r
Depuracin
- , La e s c e na: Cubculo de Ed
mientras se realizan la codificacin y la prueba de unidad.
Los act ores : Ed y Shakira, integrantes del equipo de
ingeniera del software de HogarSeguro.
La convers aci n:
Shaki ra ( a s o m ndo s e a i a ent rada del
cub cul o): Hey... dnde estabas a la hora del
almuerzo?
Ed: Justo aqu... trabajando.
Shaki ra: Te ves mal... qu es lo que pasa?
Ed ( s us pi rando con f uerza) : He estado trabajando
en este <bleep> error porque lo descubr a las 9:30 de la
maana, y son las 2: 45 y an no tengo una pista.
Shaki ra: Pens que estbamos de acuerdo en no
dedicar ms de una hora a depurar cosas por nuestra
cuenta. En ese caso, tendramos que buscar ayuda, o no?
Ed: S, pero...
Shaki ra ( ent rando e n el cub cul o): A ver, cuc =
el problema?
Ed: Es complicado. Y adems he estado revisando es-;
durante, cunto?, cinco horas. No vas a encontrarle
Shaki ra: Perdname... cul es el problema?
(Ed le explica el problema a Shakira, que lo mira dur cr *
30 segundos sin hablar.)
Shaki ra ( empi eza a pi nt arse una s onri s a en
su rostro): Mira, justo aqu, la variable
eslablecerCondicionAlarma. No debera ponerse er
"falso" antes de que inicie el bucle?
(Ed se queda viendo la pantalla sin creerlo, se indine
hacia delante y empieza a golpear su cabeza
gentilmente contra el monitor. Shakira, ahora sonrieno:
ampliamente, se levanta y sale.)
13.7.3 Estrategias de depuracin
Si n i mp o r t a r el e n f o q u e q u e s e a d o p t e , la d e p u r a c i n t i e ne u n obj e t i vo p r i mo r u l
e n c o n t r a r y c or r e gi r la c a u s a d e u n e r r or del s o f t wa r e . El obj e t i vo s e l ogr a c c n J
n a n d o la e va l ua c i n s i s t e m t i c a , la i nt ui ci n y la s ue r t e . Br adl ey [BRA85] des . ni
a s el e n f o q u e de la d e p u r a c i n :
La depuraci n es una aplicacin simple y directa del mt odo cientfico desarrol l ado ha: : I
2 500 aos. La esenci a de la depuraci n consi st e en ubicar la f uent e del probl ema : I
causa) medi ant e particin binaria, manej ando hiptesis de t rabaj o que predi gan nue \ :
val ores que habrn de exami narse.
Tomemos un ej empl o sencillo, sin rel acin al guna con el soft ware: en mi casa no fur ;
ciona una l mpara. Si no funci ona nada en la casa, la causa debe ser un fusible fundi d: I
una falla en el sumi ni st ro de energ a elctrica. Miro al rededor para ver si hay luz en el v;- I
TM
PDF Editor
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOFTWASE 4 1 3
tun
rejemplo,
.xrael
ise
:: Iralai de
i problema
linMuai
? as eso, es
jbuscar
cindario. Conecto la lmpara bajo sospecha en un enchufe que funcione y un aparato en
buen estado en el enchufe bajo sospecha Y as se siguen alternando hiptesis y pruebas.
En general , se han propuest o t res est rat egi as de depuraci n [MYE79I: 1) fuerza
brut a, 2) segui mi ent o hacia at rs y 3) eliminacin de la causa.
"El pri mer poso poro corregir un pr ogr amo es hocer que folie r epet i dament e (en el ej empl o ms simple posible), "
T. Duff

Tct i cas de depuraci n. La cat egor a de depuraci n por la fuerza bruta tal vez
sea el mt odo ms comn y menos eficiente para aislar la causa de un error del soft -
ware. Los mt odos de depuraci n por la fuerza bruta se aplican cuando t odo lo
dems falla. Al aplicar una filosofa de "dej emos que la comput ador a encuent r e el
error", se hacen descargas de memori a, se i nvocan seal es en t i empo de ejecucin
y se carga el pr ogr ama con instrucciones de salida. En al gn lugar del pant ano de
i nformaci n que se produce se espera encont r ar una pista que pueda conduci r a la
causa de un error. Aunque la gran cant i dad de i nformaci n produci da conduzca
finalmente al xito, lo ms frecuent e es que haga desperdi ci ar t i empo y esfuerzo.
El rastreo hacia atrs es un enf oque de depuraci n muy comn, que se utiliza con
xito en pequeos programas. Empezando en el sitio donde se ha descubi ert o un
s nt oma, se recorre hacia at r s el cdi go fuent e (manual ment e) hast a hallar el sitio
de la causa. Por desgracia, a medi da que aument a el nmer o de lneas del cdigo, la
cant i dad de cami nos hacia at rs se vuelve tan grande que resulta i nmanej abl e.
El tercer enf oque para la depuraci n (eliminaci n de causas) lo det ermi na la induc-
cin o deducci n e introduce el concept o de partici n binaria. Los dat os rel aci onados
con el error se organi zan para aislar las causas posibles. Se el abora una "hiptesis
de la causa" y se aprovechan los dat os ya menci onados para probar o desechar la
hiptesis. Como opcin, se el abora una lista de t odas l as causas posi bl es y s e apli-
can pr uebas para eliminar cada una de ellas. Si las pr uebas iniciales indican que
det ermi nada hiptesis de causa es promet edora, se refinan los dat os para tratar de
aislar el error.
Depuraci n aut omat i zada. Cada uno de los enf oques de depuraci n ant eri ores
compl ement an las her r ami ent as de depuraci n que proporci onan soport e semi aut o-
mat i zado al i ngeni ero de sof t war e mi ent ras se intentan est rat egi as de depuraci n.
Hailpern y Sant hanam (HAI02j r esumen el est ado de est as her r ami ent as cuando
indican: "...se han propuest o muchos nuevos enf oques y se di spone de muchos
ent or nos de depuraci n comerci al es. Los ent or nos de desarrol l o i nt egrado (EDI) pro-
porci onan una maner a de capt urar al gunos de l os errores por defect o especficos del
l enguaj e (por ej empl o, caract eres fal tantes de fin-de-instruccin, variabl es indefini-
das, etc.) sin requerir compilacin. " Un rea que ha at r apado la imaginacin de la
industria es la visualizacin de las const rucci ones de programaci n necesar i as como
medi o de anl i si s de pr ogr amas [BAE971. Se cuent a con una ampl ia variedad de
compi l adores de depuraci n, ayudas di nmi cas para la depuraci n ("trazadores"),
gener ador es aut omt i cos de casos de prueba y her r ami ent as de correlacin de refe-
TM
PDF Editor
Depuraci n
Objetivo: Estas herramientas proporcionan
ayuda automatizada a quienes deben depurar
problemas de software. El objetivo es proporcionar
conocimiento difcil de obtener si se afronta el proceso de
depuracin manualmente.
Mecnica: Casi todas las herramientas de depuracin son
especficas del lenguaje de programacin y del entorno.
Herramientas representativas:4
Jprobe ThreodAnalyzer, desarrollado por Sitraka
(www.sitraka.com), ayuda en la evaluacin de
problemas de subprocesos: bloqueos, detenciones y
condiciones de carrera que representan serios peligros
para el desempeo en aplicaciones de Java.
C++ Test, desarrollado por Parasoft (www.parasoft.com),
es una herramienta de prueba de unidad que soporta
un amplio rango de pruebas en cdigo C y C++. Las
caractersticas de depuracin ayudan al diagns-';:
los errores encontrados.
CcdeMedic, desarrollado por NewPlanet Dotware
(www.newplanetsoftw3re.com/medic/), proporciona.
interfaz grfica para el depurador UNIX estndar, gdfc ?
implemento sus caractersticas ms importantes.
gdb da soporte a C/C++, Java, PalmOS, varios sistema
incrustados, lenguaje ensamblador, FORTRAN yMoauc-1
BugCollector Pro, desarrollado por Nesbitt Software Cora
(www.nesbitt.com/), implemento una base de datos
multiusuario que ayuda al equipo de software regisfrc
errores reportados y otras solicitudes de mantenimienc
administracin de flujo de trabajo de depuracin.
GNATS, una aplicacin freeware
(www.gnu.org/software/gnats/), es un conjunto x
herramientas para registrar informes de error.
r e n d a s cr uzadas . Sin embar go, l as he r r a mi e nt a s n o s on un sust i t ut o de la
ci n cui dados a ba s a da e n un mode l o de di s eo compl et o y un cdi go f uent e
El f ac t or huma no . Ni ngn anl i si s de l os enf oques y l as he r r a mi e nt a s de
ci n est ar a compl et o sin me nc i ona r un poder os o al i ado: l os de m s ! Un p
vi st a f r esco, de s pe j a do de hor a s de f r ust r aci n, pue de hacer mar avi l l as. 5 Una
ma final pa r a la depur aci n ser a: " Cuando t odo lo d e m s falle, pida ayuda! "
13.7.4 Correccin del error
Cua ndo s e e nc ue nt r a un er r or debe corregi rse. Per o c o mo ya s e ha i ndi ca; :
cor r egi r un er r or pue de n i nt r oduci r se ot r os y, por lo t ant o, caus ar m s da :
sol uci onar el pr obl ema. Van Vl eck [VAN89] sugi er e t r es pr egunt as s i mpl es que
ra pl ant ear s e t odo i ngeni er o del s of t wa r e a nt e s de hacer la "cor r ecci n" que efe
ne la c a us a del error:
^ Cuando corri-
ja un error,
qu preguntas
debo hacerme?
I . La causa del error se repite en otra parte del programa? En mu c h a s si t uac
un er r or se pr oduce e n un pr ogr a ma debi do a un pat r n er r neo de lgica
podr a r epet i r se e n cual qui er l ugar. La cons i der aci n explcita del pat r n :
gi co pue de l l evar al des cubr i mi ent o de ot r os er r or es.
Las herramientas expuestas aqu representan una muestra de esta categora. En casi todos ks.-
sos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores
El concepto de programacin por pares (recomendada como parte del modelo de proceso ce
gramaci n extrema analizado en el captulo 4) proporciona un mecanismo para la depuracin
tras se disea y codifica el software
TM
PDF Editor
2. Cul es el " siguiente error" que podra introducirse con la correcci n que est a
punto de realizarse? Antes de la correccin se debe evaluar el cdigo fuente (o
mejor an, el diseo) para evaluar el acopl amiento entre las estructuras lgi-
cas y de datos. Si la correccin se realiza en una seccin del programa con un
acoplamiento elevado, debe tenerse mucho cuidado cuando se haga cualquier
cambio.
3. Qu debi hacerse para evitar este error desde el principio? Esta pregunta es el
primer paso hacia el establecimiento de un enfoque estadstico de asegura-
mi ent o de la calidad del soft ware (captulo 26). Si se corrige el proceso junto
con el producto, se eliminar el error del programa actual y de todos los pro-
gramas futuros.
La prueba ocupa el mayor porcentaje del esfuerzo tcnico en el proceso del soft wa-
re. Apenas se empiezan a comprender las sutilezas de la planeacin, la ejecucin y
el control sistemticos de las pruebas.
El objetivo de la prueba del soft ware es descubrir errores; se cumple pl aneando y
ejecutando una serie de pasos (pruebas de unidad, integracin, validacin y siste-
ma). Las pruebas de unidad e integracin se concentran en la verificacin funcional
de cada component e y en la incorporacin de component es en la arquitectura del
software. La prueba de validacin demuestra el cumplimiento con los requisitos del soft-
ware, y la prueba del sistema valida el software una vez que se ha incorporado a un
sistema mayor.
Cada paso de prueba se completa mediante una serie de tcnicas sistemticas de
prueba que ayudan a disear los casos de prueba. Cada paso de prueba ensancha el
grado de abstraccin con que se considera el software.
A diferencia de la prueba (una actividad sistemtica y planeada), la depuracin
debe considerarse un arte. La actividad de depuracin empieza con la indicacin sin-
tomtica de un problema y debe rastrear la causa del error. Entre los muchos recursos
disponibles durante la depuracin, el ms valioso es el consej o de otros integrantes
del equipo de ingeniera del software.
La necesidad de crear soft ware de la mayor calidad exige un enfoque de prueba
ms sistemtico. Para citar a Dunn y Ullman [DUN82]:
Lo indispensable es una estrategia general que abarque el espacio de prueba estratgico
con una metodologa tan deliberada como lo era el desarrollo sistemtico en que se ba-
saban el anlisis, el diseo y la codificacin.
En est e captulo se ha exami nado el espacio de prueba estratgico, t omando en
cuenta los pasos que tienen la mayor probabilidad de conseguir el principal objetivo
de la prueba: encontrar y eliminar errores de manera ordenada y efectiva.
TM
PDF Editor
4 1 6
PARTE DOS PRCn CA DE LA INGENIERA DEL SOFTWARE
[BAE971 Baecker, R., C. DiGiano y A. Marcus, "Software Visualization of Debugging
Communications of the ACM, vol. 40. nm. 4. abril de 1997 y otros ensayos en la misma t
(BE184] Beizer, B Software System Testing and Quality Assurance, Van Nostrand-Reinhold
[BER93] Berard, E Essays on Object-Oriented Software Engineering. vol. 1, Addison-Wesle> J
[BIN94] Binder, R., ' Testing Object-Oriented Systems: A Status Report", en American Pro,
vol. 7, nm. 4, abril de 1994. ruta crtica, pp. 23-28.
[BOE81] Boehm, B., Software Engineering Economics, Prentice-Hall, 1981, p. 37.
[BRA85] Bradley, J.H., "The science and Art of Debugging", en Computerworld, 19 de ag
1985, pp. 35-38.
[CHE90] Cheung, W. H., J. P. Black y E. Manning, "A Framework for Distributed Debuggir r
IEEE Software, enero de 1990, pp 106-115.
[DUN82] Dunn, R. y R Ullman, Quality Assurance for Computer Software, McGraw-Hill, 1982.:
[GIL951 Gilb, T., "What We Fail To Do In Our Current en Testing Culture", en Testing
Newsletter (edicin en linea, ttn@sofl.com), Software Research, Inc., ener o de
[HAI02] Hailpem, B. y P. Santhanam, "Software Debugging, Testing and Verification", en H
Systems Joumal , vol. 41, nm. 1,2002, disponible en http://www. research. ibm. com,
j oumal / sj / 411/ hai l pem. ht ml .
[IEEO11 Software Reiiabitity Engineering I2th International Symposium, IEEE, 2001.
[MC096] McConnell, S., "Best Practices: Daily Build and Smoke Test", en IEEE Software :
nm. 4, julio de 1996, pp. 143-144.
IMIL77] Miller, E., ' The Philosophy of Testing", en Program Testing Techniques, IEEE Ce
Society Press, 1977, pp. 1-3.
[MUS891 Musa, J. D. y A. F. Ackerman, "Quantifying Software Validation: When to Stop Te
en IEEE Software, mayo de 1989, pp. 19-27.
[MYE79] Myers, G., The Art of Software Testing, Wiley, 1979-
[SH083] Shooman, M. L., Software Engineering, McGraw- Hill, 1983.
(SHN80] Shneiderman, B., Software Psychology, Winthrop Publishers. 1980, p. 28.
[SIN99] Singpurwalla, N. y S. Wilson, Statistical Methods in Software Engineering: Reliab
Risk, Springer-Verlag, 1999.
|VAN891 Van Vleck, T ' Three Questions About Each Bug You find", en ACM Software l
Notes, vol. 14, nm. 5. julio de 1989, pp. 62-63.
[WAL89] Wallance, D. R. y R. U. Fujii, "Software Verification and Validation: An Overvie i
IEEE Software, mayo de 1989, pp. 10-17.
[YOU 75] Yourdon, E., Techniques of Program Structure and Design, Prentice-Hall, 1975.
13. 1. Con pal abras propias, describase la diferencia entre verificacin y validacin. L
mt odos de diseo de casos de prueba y estrategias de prueba?
13. 2. Elabrese una lista de algunos probl emas que pudieran estar asoci ados con la <
de un grupo i ndependi ent e de prueba. Lo integran las mi smas per sonas que el gn
aseguramiento de la calidad del software?
13. 3. Siempre es posible desarrol l ar una est rat egi a para probar sof t war e que
secuenci a de pasos de prueba descrita en la seccin 13.1.3? Cules son las
complicaciones que podran surgir para si st emas incrustados?
13. 4. Por qu es difcil aplicar pr uebas de unidad a un mdul o al t ament e acc
13. 5. El concept o de "antierror" (seccin 13.3.1) es una maner a ext r emadament e efec
proporcionar depuracin integrada cuando se descubre un error:
a) Desarrollar un conjunto de directrices antierror.
b) Analizar las ventajas de usar esta tcnica.
c) Analizar las desventajas de usar esta tcnica.
TM
PDF Editor
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOFT.VAKE 417
13. 6. Cmo afecta la calendarizacin la prueba de integracin?
13. 7. La prueba de unidad es posible (o incluso deseable) en todas las circunstancias?
Proporcionar ejemplos que justifiquen la respuesta.
13. 8. Quin debe aplicar la prueba de validacin: el desarrollador o el usuario del software?
Justifiqese la respuesta.
13. 9. Desarrollar una estrategia de prueba completa para el sistema HogarSeguro analizado
en todo el libro. Documntese en una Especificaci n de prueba.
13. 10. Como proyecto de clase, desarrollar una Gua de depuraci n para instalarla. Deben
proporcionarse consejos orientados al lenguaje y al sistema qu se hayan aprendido en la
escuela de la vida! Empezar con una descripcin esquemtica de los t emas que revisarn los
compaeros de clase y el profesor.
Casi todos los libros sobre la prueba del software analizan estrategias junto con mtodos para
el diseo de casos de prueba. Todos los siguientes libros analizan los principios, los conceptos,
las estrategias y los mtodos de prueba: Craig y Kaskiel (Systematic Software Testing, Artech
House, 2002), Tamres (Introducing Software Testing, Addison-Wesley, 2002), Whittaker (How To
Break Software, Addison-Wesley, 2002), Jorgensen (Software Testing: A Craftman's Approach, CRC
Press, 2002), Splaine y sus colegas (The Web Testing Handbook, Software Quality Engineering
Publishing, 2001), Patton (Software Testing, Sams Publishing, 2000), Kaner y sus colegas (Testing
Computer Software, segunda edicin, Wiley, 1999), Black (Managing the Testing Process, Microsoft
Press, 1999) y Perry (Surviving the Top Ten Challenges of Software Testing: A People-Oriented
Approach, Dorset House, 1997) tambin atienden las estrategias de prueba del software.
Para los lectores interesados en mtodos de desarrollo gil de software, Crispin y House
{Testing Extreme Programming, Addison-Wesley, 2002) y Beck (Test Driven Development: By
Exampie, Addison-Wesley, 2002) presentan estrategias y tcticas de prueba para Programacin
Extrema. Kamer y sus colegas (Lessons Learned in Software Testing, Wiley, 2001) presentan una
coleccin de ms de 300 "lecciones" pragmticas (directrices) que toda persona dedicada a la
prueba de software debe aprender. Watkins (Testing IT: An Off the Shetf Testing Process,
Cambridge University Press, 2001) establece un marco conceptual de prueba efectivo para todos
los tipos de software desarrollado y adquirido.
Lewis (Software Testing and Continuous Quality Improvment, CRC Press, 2000) y Koomen y sus
colegas (Test Process Improvment, Addison-Wesley, 1999) analizan estrategias para la mejora
continua del proceso de prueba.
Sykes y McGregor (Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001),
Bashir y Goel (Testing Object-Oriented Software, Springer-Verlag, 2000), Binder, Testing Object
Oriented Systems, Addison-Wesley, 1999), Kung y sus colegas (Testing Object Oriented Software,
1EE Computer Society Press, 1998) y Marick (The Craft of Software Testing, Prentice Hall, 1997)
presentan estrategias y mtodos para prueba de sistemas orientados a objetos.
Directrices para la depuracin se encuentran en libros de Agans (Debugging: The Nine
Indispensable Rules for Finding Even The Most Elusive Hardware and Software Problems, AM ACON,
2002), Tells y Hsieh (The Science of Debugging, The Coreolis Group, 2001), Robbins (Debugging
Applications, Microsoft Press, 2000) y Dunn (Software Defect Removal, McGraw-Hill, 1984).
Rosenberg (How Debuggers Work, Wiley, 1996) atiende la tecnologa de las herramientas de depu-
racin. Younessi (Object-Oriented Defect Management of Software, Prentice-Hall, 2002) presenta tc-
nicas para administrar los defectos que se encuentran en sistemas orientados a objetos. Beizer
[BEI84] presenta una interesante "taxonoma de los errores" que puede llevar a mtodos efectivos
para la planeacin de pruebas. Ball (Debugging Embedded Microprocessor Systems, Newnes
Publishing, 1998) atiende la naturaleza especial del software incrustado de microprocesador.
En Internet se encuentra una amplia variedad de fuentes de informacin sobre estrategias de
prueba del software. Una lista actualizada de referencias en la World Wide Web que resultan
relevantes para las estrategias de prueba del software se encuentran en el sitio Web SEPA:
ht t p: / / www. mhhe. com/ pressman.
TM
PDF Editor
C A P I T U L O
TCNI CAS DE PRUEBA
DEL SOFTWARE
CONCEP TOS
CLAVE
AVI 4 3 7
complejidad
(domt i ca . . . 4 2 6
i adt i dod de
pr ueba 4 1 9
gr f i cas de
fl uj o . 4 2 3
part i ci n
equi val ent e . . . 4 3 6
pat r ones 4 5 6
pr uebas
ba s a da s en el
escenar i o . . . 4 4 4
ba s a da s en
f al l as 4 4 3
d e b u d e s . . . . 4 3 2
de caja bl anca . 4 2 3
de caja negr a . 4 3 3
de la est r uct ur a
de c o n t r o l . . . 4 3 0
de nivel de
d o s e 4 4 7
de r ut a bsi ca . 4 2 3
L
a s pr ue ba s r epr es ent an un i nt er es ant e r et o par a l os i ngeni er os de se i
re, qui enes por nat ur al eza s on pe r s ona s const r uct i vas. Las pr uebas re ;B
r en que el desar r ol l ador des car t e noci ones pr econcebi das de lo r _ ;
"cor r ect o" e n el s of t war e y e nt onc e s di s ee di f ci l es c a s os de pr ueba par a
perl o". Beizer [BEI90] descr i be bi en es t a si t uaci n c ua ndo af i r ma:
Es un mito que si realmente furamos buenos para programar no tendramos que
purar errores. Si tan slo pudiramos concentrarnos, si todos usaran programa: a
estructurada, diseo descendente o tablas de decisin, si los programas se escr.r -s
ran en SQUISH, si tuviramos las balas plateadas correctas, entonces no habra e
res. se es el mito. Hay errores, dice el mito, porque somos malos en lo que hace- >
y si somos malos en eso, debemos sentimos culpables. Por tanto, el diseo de rraaj
bas y de casos de prueba es una admisin de la falla, que instila una buena do.- ; _
culpa. Y el tedio de probar slo es un castigo por nuestros errores. Castigo por ; -
Por ser seres humanos? Culpables de qu? De no alcanzar una perfeccin i nhur aj
na? Por no distinguir entre lo que otro programador piensa y lo que dice? Pe: -1
usar la telepata? Por no resolver los problemas de las comunicaciones humanas i
han estado presentes., durante cuarenta siglos?
Las pr ue ba s deben pr ovocar cul pa? Las pr ue ba s s on r e a l me nt e de s t r _: i
La r es pues t a e s no!
En es t e capi t ul o s e anal i zar n t cni cas par a el di s eo de c a s os de p n . r : ai
s of t war e. Est e t i po de di s eo s e concent r a en un conj unt o de t cni cas
cr eaci n de c a s os de pr ue ba q u e cumpl an con obj et i vos gener al es y c or ^
t r at egi as de pr ue ba anal i zadas e n el cap t ul o 13.
a obj et os . . . 441
Qu e s ? Una vez generado e! c-
digo fuente, es necesario probar el
software par a descubrir (y corregir) la
mayor cantidad de errores posible
antes de entregado al cliente. Su ob-
jetivo es disear una serie de casos de prueba que
tengan una alta probabilidad de encontrar erro-
res, pero cmo? Aqu es donde entran en escena
las tcnicas de prueba del software. Estas tcnicas
proporcionan directrices sistemticas par a prue-
bas de diseo que 1) comprueben la lgica ' *
na y las interfases de todo componente de ; r -
ware y 2) comprueben los dominios de er r r ox f
salida del programa par a descubrir errores en m
funcin, comportamiento y desempeo.
Qui n l o ha c e ? Durante las et apas inicile: J
proceso, un ingeniero de software realiza : :
ias pruebas. Sin embargo, a medida que c a l
za este proceso se irn incorporando espec r I
tas en pruebas.
4IB
TM
PDF Editor
C A P T U L O 1 4 TCNICAS DE PRUEBA DEL SOFTWARE 419
-_5or qu es i mportante? Con l as revi si ones y
erras a ct i vi da des d e a s e gur a mi e n t o d e la cali-
da d del s of t war e se pue de n y d e be n des cubr i r
er r or es, pe r o n o ba s t a con ello. El cl iente p r u e b a
d p r o g r a ma c a d a vez q u e lo ej ecut a. Por t ant o,
se t i ene q u e ej ecut ar el p r o g r a ma ant es d e q u e
fi egue al cliente, y el obj et i vo espec f i co s er en-
cont rar y el i mi nar t odos los er r or es. La l ocal i za-
c n d e la ma yor c a nt i da d d e er r or es r equi er e
apl i car pr ue ba s d e ma n e r a si st emt i ca y di s ea r
cas os de pr ue ba e mp l e a n d o t cni cas def i ni das.
Cules son l os pas os ? En apl i caci ones con-
venci onal es el s of t war e se p r u e b a d e s d e do s
per s pect i vas di f er ent es: 1) la l gi ca i nt er na del
p r o g r a ma se c o mp r u e b a me di a nt e t cni cas d e
di s eo d e c a s o s d e p r u e b a d e " c a j a bl a nc a " , 2)
los requi si t os del s of t wa r e s e c o mp r u e b a n e m-
p l e a n d o t cni cas d e di s e o d e c a s os d e p r u e b a
d e " c a j a ne gr a " . En el c a s o d e a pl i ca ci ones
or i e nt a da s a obj et os , la " p r u e b a " e mp i e z a a nt e s
de la exi st enci a del c d i g o f uent e, pe r o una ve z
g e n e r a d o st e, se d i s e a r una ser i e d e p r u e b a s
p a r a c o mp r o b a r o pe r a c i o n e s con una cl as e y
e xa mi na r si exi st en er r or es mi ent r as una cl as e
c o l a b o r a con ot r a. A me d i d a q u e l as cl as es s e
i nt egr an p a r a f o r ma r un subsi st ema, se a pl i c a la
p r u e b a de uso, j unt o con l os e n f o q ue s b a s a d o s
en f al l as, p a r a c o mp r o b a r l as cl as es q u e col a bo-
r an. Por ltimo, los cas os d e uso a y u d a n a di se-
a r p r u e b a s q u e per mi t an des cubr i r er r or es al ni-
vel d e val i daci n del sof t war e. En t odo cas o, el
obj et i vo e s encont r a r el nme r o m xi mo d e erro-
res con la m ni ma c a nt i da d d e es f uer zo y t i empo.
Cul es el producto obteni do? Se di s ea y
doc ume nt a un conj unt o d e c a s os d e p r u e b a di -
s e a d o p a r a c o mp r o b a r la l gi ca i nt er na, l as in-
t er f aces , l as c o l a bo r a c i o n e s ent r e c ompone nt e s
y los r equi si t os i nt ernos; s e def i nen los r es ul t ados
e s p e r a d o s y se r egi s t r an los r es ul t ados r eal es.
hecho correctamente? Cu a n d o se e mpi e c e
l a p r u e b a d e b e c a mb i a r s e d e punt o d e vi st a. El
obj et i vo e s " r omper " el s of t war e! Deben di s e-
a r s e c a s os d e p r u e b a en f or ma met i cul os a y re-
vi s ar s e q u e los c a s o s d e p r u e b a c r e a do s a b a r -
quen t odo l o di s e a do. Ad e m s , e s pr eci s o eva -
l uar la cober t ur a d e la p r u e b a y da r l e segui -
mi ent o a l as act i vi dades d e det ecci n d e er r or es .
1 1 4 . 1 FUNDAMENTOS DE I.AS PRUEBAS DEL SOFTWARE
En el captulo 5 se analizaron los objetivos y principios fundamentales de las prue-
bas. Se recordar que el objetivo de las pruebas es encontrar errores y que una bue-
na prueba es la que tiene una alta probabilidad de encontrar un error. Por tanto,
cuando un ingeniero de software disee e implemente un sistema o un producto de
cmputo, debe tener en mente la facilidad de prueba. Al mismo tiempo, las propias
pruebas deben mostrar un conjunto de caractersticas para alcanzar el objetivo de
encontrar la mayor cantidad de errores con un mnimo de esfuerzo.
Todo programo hoce algo bien; pero tal vez sea lo que no queremos que haga."
Anni mo
Facilidad de prueba. James Bach1 proporciona la siguiente definicin: "La facilidad
de prueba del software indica simplemente si es fcil o no probar (un programa de
computadora)." Las siguientes caractersticas propician la creacin de software que
tenga facilidad de prueba.
1 Los prrafos si gui ent es se usan con permi so de James Ba. n copyright, 1994) y se han adapt ado del
materia! que original mente apareci publ i cado en el grupo de noticias comp. soft ware-eng.
TM
PDF Editor
Cul es
s on l as
caract er s t k as de
la f aci l i dad de
pr ue ba?
Operatividad. "Cuanto mejor funcione, con mayor eficiencia podr probarse I
un sistema est diseado e impl ementado con la calidad en mente, sern relat -
ment e escasos los errores que bloquearn la ejecucin de las pruebas, lo que pe~-
tir el avance de stas sin correcciones ni reinicios.
Observabilidad. "Lo que se ve es lo que se prueba." Las ent radas proporcic *aj
das como parte de la prueba producen salidas distintas. Los est ados y las varia.*'csi
del sistema son visibles y pueden consultarse durante la ejecucin. La salida ir .
rrecta se identifica fcilmente. Los errores internos se detectan y reportan en f o r r a
automtica. El cdigo fuente es accesible.
Controlabilidad. "Cuanto mejor se controle el software, mejor se aut omat i za. '
y mejorarn las pruebas." El ingeniero de pruebas controla directamente los estad
las variables de soft ware y hardware. Las pruebas pueden ser conveni ent emer .; a
pecificadas, aut omat i zadas y reproducidas.
Capacidad para des componer. Al controlar el alcance de la prueba, se
rn los probl emas ms rpidamente y se aplicarn las pruebas nuevament e cor - J
yor inteligencia. El sistema de soft ware se construye a partir de mdulos i n d e r J
dientes que tambin se prueban independientemente.
Simplicidad. "Cuanto menos haya que probar, ms rpido se har." El p r o g r ^ l
debe mostrar simplicidad Juncional (por ejemplo, el conjunto de caractersticas e s M
mnimo necesario para satisfacer los requisitos), simplicidad estructural (la arc_ J
tura aparece en mdulos para limitar la propagacin de fallas) y simplicidad ck : <
go (se adapta un estndar de codificacin para facilitar la inspeccin y el m a n
miento.)
Estabilidad. "Cuantos menos cambios haya, menores alteraciones habr :T I
prueba." Los cambios ai soft ware son poco frecuentes, se controlan cuando o c - a J
y no invalidan las pruebas existentes. El soft ware se recupera bien de las fallas ]
Facilidad de comprensi n. "Cuanta mayor informacin se tenga, con ma;.
teligencia se aplicar la prueba." Se comprenden bien el diseo de la arquitec~_al
las dependenci as entre component es internos, externos y compartidos. Se t i e' t
ceso i nst ant neo a la documentacin tcnica, est bien organizada, es espe. Sp
detallada y exacta. Los cambios al diseo se comunican a quienes aplican las
bas.
Un ingeniero usar los atributos que sugiere Bach para desarrollar una configura*
de software (es decir, programas, datos y documentos) que sea sensible a la r ~ J f c
' Los errores son ms comunes en el sof tw ore, tienen ms copacidod de ex pandirse y representan ms problemas
en otras tecnolog as."
Davi d
Caracter sti cas de la prueba. Y qu hay con las propias pruebas? Kaner : M
Nguyen [KAN93] sugieren los siguientes atributos para una buena prueba:
TM
PDF Editor
0 es uno 1 Una buena prueba tiene una elevada probabilidad de encontrar un error. Alcan-
*Wno" zar este objetivo requiere que la persona que aplica la prueba comprenda el
software y trate de desarrollar una imagen mental de la manera en que puede
fallar. Lo ideal es probar los tipos de fallas. Por ejemplo, un tipo de falla posi-
ble en una interfaz grfica de usuario es la incapacidad de reconocer la posi-
cin correcta del ratn; por tanto, se diseara un conjunto de pruebas para
probarlo tratando de evidenciar un error en el reconocimiento de su posicin.
2. Una buena prueba no es redundante. El tiempo y los recursos destinados a las
pruebas son limitados. No hay razn para realizar una prueba que tenga el
mismo propsito que otra. Cada prueba debe tener un propsito diferente
(aunque las diferencias sean sutiles).
3. Una buena prueba debe ser "la mejor de su clase" [KAN93J. En un grupo de
pruebas con un objetivo similar y recursos limitados podra optarse por la eje-
cucin de un solo subconjunto de ellas. En este caso, debe usarse la prueba
que tenga la mayor probabilidad de descubrir un tipo completo de errores.
4. Una buena prueba no debe ser ni muy simple ni demasiado compleja. Aunque a
veces es posible combinar una serie de pruebas en un caso de prueba, los po-
sible efectos colaterales asociados con este enfoque podran enmascarar erro-
res. En general, cada prueba debe ejecutarse por separado.
HOGARSEGURO
Diseo de pruebas nicas
La e s c e n a : Cubculo de Vinod.
a c t o r e s : Vinod y Ed, integrantes del equipo de n-
i del software HogarSeguro
c o n v e r s a c i n :
: As que stos son los casos de prueba que pre-
> ejecutar con la operacin validacionConirasea.
: S, cubren muchos de los posibles tipos de contrase-
-c que podra ingresar un usuario.
V i n o d : Djame ver sealas que la contrasea correc-
to ser 8080, verdad?
I d : Aj .
V i n o d : Y especificas las contraseas 1234 y 6789 pa-
-a encontrar errores en el reconocimiento de contraseas
no vlidas?
Ed: Correcto, y tambin pruebo contraseas que son pa-
-ecidas a la correcta, como 8081 y 8180.
V i nod: Est bien, pero no veo mucho caso en ejecutar
los entradas 1234 y 6789. Son redundantes... prueban
lo mismo, o no?
Ed: Bueno, son valores diferentes.
V i nod: Es cierto, pero si 1234 no descubre un error...
en otras palabras. . . la operacin validanContrasea
detecta que la contrasea no es vlida, as que no es
probable que 6789 nos muestre algo nuevo.
Ed: Ya s lo que quieres decir.
V i nod: No estoy tratando de ser puntilloso... slo que
tenemos tiempo limitado para las pruebas, de modo que
es buena idea ejecutar pruebas que tengan una alta pro-
babilidad de encontrar nuevos errores.
Ed: No hay problema... Pensar un poco ms en esto.
TM
PDF Editor
1 4 . 2 PRUEBAS P S CAJ A NE S RA Y C AJ A BLANCA

\
CLV E
Los pruebos de cojo
blanco slo pueden
disearse despus del
diseo al nivel de
componentes (o
cdigo fuente), b
necesario que los
detalles lgicos del
programa estn
disponibles.
Hay una de dos maneras de probar cualquier producto construido (y casi cualc- iet
cosa): 1) si se conoce la funcin especfica para la que se dise el producto, se ar#-|
can pruebas, que demuest ren que cada funcin es pl enament e operacional, mi ert raa
se buscan los errores de cada funcin; 2) si se conoce el funci onami ent o interne a a
producto, se aplican pruebas para asegurarse de que "todas las pi ezas encajan -
decir, que las operaciones internas se realizan de acuerdo con las especificado-rs I
y que se han probado todos los component es internos de manera adecuada. Al rc-l
mer enfoque de prueba se le denomi na prueba de caja negra; al segundo, prueba : e|
caja blanca.2
Las pruebas de caja negra son las que se aplican a la interfaz del software
prueba de este tipo examina algn aspect o funcional de un sistema que tiene
relacin con la estructura lgica interna del software. La prueba de caja blanca .
software se basa en un examen cercano al detalle procedimental. Se prueban la;1
tas lgicas del software y la colaboracin entre componentes, al proporcionar
de prueba que ejerciten conj unt os especficos de condiciones, bucles o ambos
" Slo hoy una reglo poro dise ar cosos de pruebo: abarcor l odos las f unci ones, pero no dise or demasi ados caso-.
Tsuneo Yamou
A primera vista, parecera que toda prueba de caja blanca completa llevara :
programa 100 por ciento correcto. Todo lo que se necesita hacer es identificar
los cami nos lgicos, desarrollar casos de prueba para ejercitarlos y evaluar
dos; es decir, generar casos de prueba para comprobar exhaustivamente la 1c
programa. Por desgracia, la prueba exhaustiva presenta ciertos problemas de
tica (consltese el anlisis del recuadro). Sin embargo, la prueba de caja blar : i i
Prueba exhaustiva
*
Considrese un programa de cien lneas en
l enguaje C. Despus de al guna declaracin b-
sica de datos, el pr ogr ama contiene dos bucles ani dados
que se ejecutan de 1 a 20 veces cada uno, lo que depende
de la condicin especificada en la ent rada. Dentro del bu-
cle interno se requieren cuatro construcciones si-entonces-
si_no lf-then-else). jEl programa tendr al rededor de 1 0 u
posibles rutas de ejecucin!
Poner este nmero en perspectiva requiere suponer que
^se ha desarrol l ado un procesador de prueba mgico ("m-
gico" porque no existe) par a aplicar una prueba
va. El procesador desarrolla un caso de prueba, lo
y evala los resultados en un milisegundo. Si t r a ba j e -
horas diarias, 365 das al ao, necesitara 3 170 <
ra probar el programa. Esto causar a, i ndudabl eme"?
desastre en casi todos los calendarios de desarrollo
Por tanto, es razonabl e asegurar que resulta i"
aplicar una prueba exhaustiva en sistemas grandes os
2 Los t rmi nos prueba funcional y prueba estructurada suel en usar se en lugar de prueba de
y de caj a bl anca, respect i vament e.
TM
PDF Editor
C A P T U L O 1 4 TCNICAS DE PRUEBA DEL SOFT.VA3E 423
debe desechar se nunca como imprctica. Es posibl e sel eccionar y compr obar un n-
mer o limitado de rut as lgicas i mport ant es; adems de probar la validez de l as prin-
cipal es est ruct uras de dat os.
1 4 . 3 PRUEBAS PE C AJ A BLANCA
La prueba de caj a blanca, en ocasi ones l l amada prueba de caj a de cristal, es un m-
t odo de di seo que usa la est ruct ura de control descrita como parte del di seo al ni-
vel de component es para derivar los cas os de prueba. Al empl ear los mt odos de
prueba de caj a bl anca, el i ngeni ero del sof t war e podr deri var casos de prueba que
1) garant i cen que t odos l as rut as i ndependi ent es dent ro del mdul o se han ejercita-
do por lo menos una vez, 2) ejerciten l os l ados verdadero y falso de t odas las deci-
si ones lgicas, 3) ej ecut en t odos l os bucl es en sus lmites y dent ro de sus lmites ope-
raci onal es, y 4) ejerciten est ruct uras de dat os i nt ernos para asegur ar su validez.
"Los errores pululan en los rincones y se acumulan en los l mites."
B ori s B ei z er
1 4 . 4 PRUEBA P E LA RUTA BSI CA
La prueba de la ruta bsica es una tcnica de prueba de caj a bl anca que propuso ini-
cial mente Tom McCabe [MCC76]. El mt odo de la ruta bsica permite que el diseador
de casos de prueba obt enga una medida de complejidad lgica de un di seo procedi-
ment al y que use esta medida como gua para definir un conj unt o bsi co de rutas de
ej ecuci n. Los cas os de prueba deri vados para ejercitar el conj unt o bsi co deben ga-
rant i zar que se ej ecut a cada instruccin del pr ogr ama por lo menos una vez duran-
te la prueba.
14.4.1 Notacin de grfica de flujo
Antes de tratar el mt odo de la ruta bsica, debe present arse una not aci n simple
para la represent aci n del flujo de control, l l amado grfica de flujo [o grfica del pro-
grama).3 La grfica de flujo descri be un flujo de control lgico empl eando la notacin
ilustrada en la figura 14.1. Cada const rucci n est ruct urada (captulo 11) tiene su sm-
bol o correspondi ent e en la grfica de flujo.
El uso de una grfica de flujo se ilustra consi derando la represent aci n del dise-
o procedi ment al de la figura 14.2a. Aqu se descri be la estructura de control del pro-
gr ama medi ant e un di agrama de flujo. En la figura 14.2b se correl aci ona (o mapea)
el di agrama de flujo con su grfica de flujo correspondi ent e (suponi endo que no exis-
ten condi ci ones compuest as en l os di amant es de decisin del di agrama de flujo). To-
CONSEJO^
xbe dibujarse
jvJiode
cuando la
lgico de
~ n t e seo
.E l
de flujo
troz ar
del programa de
ms legible.
3 En realidad, el mtodo de la ruta bsica se aplica sin el uso de las grficas de flujo. Sin embargo, sir-
ven como notacin til para comprender el flujo de control e ilustrar el enfoque
TM
PDF Editor
mando como referencia la figura 14.2b, cada crculo, llamado nodo de grfica de fk.
jo, representa una o ms instrucciones procedimentales. Una secuencia de recu:
dros de proceso y un di amant e de decisin se correlaciona con un solo nodo. Las fe
chas en la grfica de flujo, l l amadas aristas o enlaces, representan el flujo de cort r:
y son anl ogos a las flechas de los di agramas de flujo. Una arista debe terminar ST
un nodo, aunque el nodo no represente ninguna instruccin procedimental (porl
ejemplo, vase el smbolo en la grfica de flujo para la construccin if-then-else de a
figura 14.1). Las reas que limitan aristas y nodos se denomi nan regiones. Cua- :
se cuentan las regiones se incluyen las reas ubicadas fuera de la grfica.4
Not aci n de
grf i ca de
f lujo.
Las construcciones estructuradas en forma de grfica de flujo:
Si Mientras Hasta
Donde cada circulo representa una o ms
instruccinen LDP sin ramificaciones o de cdigo fuente
4 Un anlisis ms detallado de las grflcas y su aplicacin se presentar en la seccin 14.6.1
TM
PDF Editor
Cuando se encuent ran condiciones compuest as en un diseo procedimental, la
generacin de una grfica de flujo se vuelve ligeramente ms complicada. Una con-
dicin compuest a ocurre cuando hay uno o ms operadores bool eanos (OR, AND,
NAND, OR) en una instruccin condicional. Tomando como referencia la figura
14.3, el segment o en LDP se traduce a la grfica de flujo mostrada. Obsrvese que se
crea un nodo separado para cada una de las condiciones a y b en la instruccin IF a
OR b. Cada nodo que contiene una condicin es un nodo predicado y se caracteriza
porque de l emanan dos o ms aristas.
14.4.2 Rutas independientes del programa
Una ruta independiente es cualquier ruta del programa que ingresa por lo menos un
nuevo conjunto de instrucciones de procesami ent o o una nueva condicin. Cuando
se explica desde el punt o de vista de una grfica de flujo, una ruta independiente de-
be recorrer por lo menos una arista que no se haya recorrido antes. Por ejemplo, a
continuacin se presenta un conjunto de rutas independientes en la grfica de (lujo
de la figura 14.2b:
ruta 1: 1-11
ruta 2: 1-2-3-4-5-10-1-11
ruta 3: 1-2-3-6-8-9-10-1-11
ruta 4: 1-2-3-6-7-9-10-1-11
Obsrvese que cada nuevo cami no ingresa una nueva arista. El cami no
1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
no se considera una ruta independiente porque se trata simplemente de una combi-
nacin de rutas ya especificadas y no recorre ninguna arista nueva.
Los cami nos 1, 2, 3 y 4 constituyen un conj unt o bsico para la grfica de flujo de
la figura 14.2b. Es decir, si se disean pruebas para forzar la ejecucin de esas rutas
esta.
IF a OR b
then procedimiento x
else procedimiento y
ENDIF
TM
PDF Editor
^CONSEJO^-
lo complejidad
ciclomtica es una
m trica q ue resulta
til poro predecir
cules mdulos tienen
ms probabilidad de
contener errores. Se
emplea paro lo plo-
neacin de pruebas
adems del diseo de
casos de prueba.
f Cmo se
* calcula la
complejidad ciclo-
mtica?
CIJA V E
Lo complejidad
ciclomtica proporciono
el limite superior del
nmero necesario de
casos de prueba para
garantizar que cada
instruccin del
programo se haya
ejecutado por lo menos
uno vez.
(un conj unt o bsico), se habrn ej ecut ado los l ados verdadero y fal so de cada i r - -
truccin del programa. Debe observarse que un conj unt o bsi co no es nico. En rea
lidad, es posible derivar varios conj unt os bsi cos di ferent es de un di seo proce--
ment al det ermi nado.
Cmo se sabe cunt as rut as buscar? El cl cul o de la complejidad ciclomtica p : ~
porci ona la respuest a. La compl ejidad ciclomtica es una mtrica de soft ware quej
proporci ona una medi da cuantitativa de la compl ej i dad lgica de un pr ogr a -
Cuando se empl ea en el cont ext o del mt odo de prueba de la ruta bsica, el vai i
cal cul ado medi ant e la compl ej i dad ciclomtica define el nmer o de rut as inder : - -
di ent es en el conj unt o bsi co de un programa, y proporci ona un lmite superior r ;
ra el nmer o de pr uebas que deben apl icarse para asegur ar que t odas las i nst r uco: - !
nes se hayan ej ecut ado por lo menos una vez.
La compl ejidad ciclomtica se basa en la teora grfica y se calcula de una de r a l
maner as:
1. El nmer o de regi ones corresponde a la complejidad ciclomtica.
2. La compl ejidad ciclomtica, V { G ) , de una grfica de flujo, G, se define coir
V ( C ) = E - N + 2
donde E es el nmer o de aristas, y N, el nmer o de nodos de la grfica de 3 u |
)-
3. La compl ejidad ciclomtica, V(G), de una grfica de flujo, G, t ambi n se de "' -si
como
V ( G ) = P + 1
donde P es el nmer o de nodos predi cado incluidos en la grfica de flujo C
Tomando como referenci a una vez ms la grfica de flujo de la figura \42t i.
compl ejidad ciclomtica se calcula empl eando cada uno de los al goritmos qut a
acaban de indicar.
1. La grfica de flujo tiene cuat ro regiones.
2. V(G) = 11 aristas - 9 nodos + 2 = 4
3. V(G) = 3 nodos predi cado + 1 = 4
HOGARSEGURO
Ut ilizacin de la complejidad ciclomt ica
La e s c e n a : Cubculo de Shakira. L a c o n v e r s a c i n :
Los ac t o r e s : Vinod y Shakira, integrantes del equi po
de ingeniera del software HogarSeguro que t rabaj a en
la planeacin de pruebas par a la funcin de seguridad.
S h a k i r a : Mira. . S que debemos aplicar pruebas de
unidad a los componentes de la funcin de seguridad
pero hay demasi ados, y si tomas en cuenta el nmero
operaci ones que deben ejercitarse, no s. . . tal vez det-e-
TM
PDF Editor
C A P T U L O 1 4 TCNICAS DE PRUEBA D A SOFTWARE 427
olvidarnos de la prueba de cajo blanca, integrar to-
? iiciar la ejecucin de las pruebas de caj a negra.
V i o d : Crees que el tiempo es insuficiente para probar
i i on ponentes, ejercitar las operaciones y luego inte-
? II I
i r a : La fecha lmite para el primer incremento est
cerca de lo que pensbamos.,, s, claro, estoy preo-
: Por qu no ejecutamos por lo menos pruebas
i s a blanca en las operaciones ms propensas a

i r a ( e x a s p e r a d a ) : Y exactamente cmo s
son las ms propensas a error?
V de G.
i r a : Qu?
V i n o d : La complejidad ciclomtica (V de G. Slo calcu
la V(G) para cada operacin dentro de cada componen-
te y vers cules tienen los valores ms elevados. Esos
son los que estn ms propensos a error.
S h a k i r a : Y cmo calculo V de G?
V i n o d : Es muy fcil. Aqu tienes un libro que describe
cmo hacerlo.
S h a k i r a ( h o j e n d o l o ) : Muy bien, no parece difcil.
Lo probar, las operaciones con la V(G) ms elevada se-
rn candidatos para las pruebas de caja blanca.
V i n o d : Slo recuerda que no hay garantas. Un compo-
nente con una V(G) baj a an puede estar propenso a
' III
S h a k i r a : Muy bien. Pero por lo menos esto me ayudar
a reducir el nmero de componentes que necesariamente
deben someterse a prueba de caja blanca.
Lo ms notable es que el valor de V(G) proporciona el lmite superior del nmer o
de rutas independientes que forman el conj unt o bsico; por implicacin, ofrece un
lmite superior del nmero de pruebas que debe disearse y ejecutarse para garanti-
zar la cobertura de t odas las instrucciones del programa.
14.4.3 Derivacin de casos de prueba
El mt odo de prueba de la ruta bsica se aplica a un diseo procedimental o al c-
digo fuente. En esta seccin se presentar la prueba de la ruta bsica como una se-
rie de pasos. Se emplear el procedimiento promedio (descrito en PDL en la figura
14.4) como ejemplo para ilustrar cada paso en el mt odo de diseo de casos de prue-
ba. Obsrvese que promedio, aun en el caso de un algoritmo ext remadament e sim-
ple, contiene condiciones compuestas y bucles. Los siguientes pasos se aplican para
derivar el conj unt o bsico:
1. Utiliz ando el di s e o o el cdi go c o mo bas e s e dibuja la grf i ca de f lu-
j o correspondi ent e. En la creacin de una grfica de flujo se empl ean los
smbolos y las reglas de construccin present adas en la seccin 14.4.1. To-
mando como referencia el PDL para obtener promedio en la figura 14.4, se
crea una grfica de flujo numerando esas instrucciones en PDL, que se corre-
lacionarn o mapearn en los nodos correspondientes de la grfica de flujo.
En la figura 14.5 se muestra la grfica de flujo resultante.
2. Det erm nes e la compl eji dad ci cl omt i ca de la grf i ca de f lujo resul-
tante. La complejidad ciclomtica, V ( C), se determina al aplicar el algoritmo
descrito en la seccin 14.4.2. Debe indicarse que podra determinarse V(G) sin
desarrollar una grfica de flujo, si se cuentan t odas las instrucciones condicio-
TM
PDF Editor
428
PROCEDI MI ENTO p r o me d i o :
PDL con
nodos * E 8 e f >roce*nier, to caled el promedio de 100 o menos
I dentif icados.
nmero que caen ent re valores lmite; tambin calcula la
s uma y el t ot al de nmer os vlidos
INTERFACE RETURN8 promedio, t ot al . ent rada, total-valido;
INTERFACE ACCEPT8 valor, minkno. mxi mo:
TYPE valor{1:100} 18 8CALAR ARRAY:
TYPE prome<fio. t ot al . ent rada, total, valido;
mnimo, ma dmo. suma 18 8CALAR;
TYPE i 18 INTEOER:
I = 1:
t ot al . ent rada = total, vafido = 0 : 2
suma = 0 ; - """
DO WHILE valor [i] < > - 9 9 9 AND t ot al . ent rada < 100 3
4 i ncrement ar t ot al . ent rada en I;
IF valorf] > = mnimo AND val orfl j < = mximo 6
/ THEN i ncrement ar total.vafido en 1:
suma = s suma + val orfl j
\ C1 OC
!<
EL8E omitir
ENDIF
, i ncrement ar i en 1:
9 ENDD0
IF total.valido > 0 10
11 THEN promedio = suma / total.valido;
u E18E promedio = - 9 9 9 :
ENDIF
END promedio
nal es en el PDL (para el procedimiento promedio, las condiciones c o mp u e - s J
cuentan como dos) y se suma 1 al resultado. Tomando como referencia ia - i
gura 14.5,
V(G) = 6 regiones
V(G) = 17 aristas - 13 nodos + 2 = 6
V(G) = 5 nodos predicado + 1 = 6
"Errar es de humanos, encontrar un error es de dioses.' '
Robert D
3. Det erm nes e un conjunto bs i co de rutas l i neal ment e i nde pe ndi e n- .
El valor de V ( G ) indica el nmero de rutas linealmente independientes de ai 1
estructura de control del programa. En el caso del procedimiento promec a
espera especificar seis caminos:
ruta 1: 1-2-10-11-13
ruta 2: 1-2-10-12-13
ruta 3: 1-2-3-10-11-13
ruta 4: 1-2-3-4-5-8-9-2-...
ruta 5: 1-2-3-4-5-6-8-9-2-...
ruta 6: 1-2-3-4-5-6-7-8-9-2-...
TM
PDF Editor
Los punt os suspensivos (...) que siguen a las rutas 4, 5 y 6 indican que es
aceptable cualquier ruta que se recorra en el resto de la estructura de control.
A menudo vale la pena identificar nodos predicado como apoyo para derivar
los casos de prueba. En este caso, los nodos 2, 3, 5, 6 y 10 son nodos predicado.
4. Preprense l os cas os de prueba que f orz arn la ej ecuci n de cada ru-
ta en el conj unto bsi co. Es necesario seleccionar los datos de manera tal
que se establezcan apropi adament e las condiciones de los nodos predicado, a
medida que se prueba cada ruta. Cada caso de prueba se ejecuta y compara
con los resultados esperados. Una vez compl etados todos los casos, la perso-
na que aplica la prueba puede estar segura de que t odas las instrucciones del
programa se han ejecutado por lo menos una vez.
Es importante observar que es imposible probar al gunas rutas independientes
(como la ruta 1 en nuestro ejemplo) por separado. Es decir, en el flujo normal del
programa no puede obt enerse la combinacin de los dat os requeridos para recorrer
la ruta. En tales casos, estas rutas se ejercitan como parte de otra prueba del camino.
G rfica de flujo Matriz de grfica
TM
PDF Editor
430
^ Q u e s una
* matri z de
grf i ca y cmo s e
e x t i e nde para
usarl a en la
prueba?
PARTE DOS PRonCA DE LA INGENIERA DEL SOFTWARE
14.4.4 Matrices de grficas
El procedi mi ent o para derivar la grfica de flujo e incl uso det ermi nar un conj unt o cc.
rut as bsi cas es sensi bl e a la mecani zaci n. Una est ruct ura de dat os d e n o mi n a n
matriz de grfica resul t a muy til para desarrol l ar una herrami ent a de sof t war e cv-1
ayude en la prueba de la ruta bsica.
Una matriz de grfica es una matriz cuadr ada cuyo t amao (es decir, el nrr e
de filas y col umnas) es igual al nmer o de nodos en la grfica de flujo. Cada fila r
col umna corresponde a un nodo identificado, y las ent r adas de la matriz corresp: *
den a las conexi ones (una arista) ent re nodos. En la figura 14.6 se muest ra un ej e- r -
po simple de una grfica de flujo y su matriz de grfica correspondi ent e [BEI90;
Tomando como referenci a la figura, cada nodo en la grfica est identificado
nmer os, mi ent ras que cada arista se identifica con letras. Una conexi n entre
nodos se indica cr eando una ent r ada de letra en la matriz. Por ejempl o, el nodo 3
conect a al nodo 4 con la arista b.
Hasta est e punt o, la matriz de grfica no es m s que una represent aci n
de una grfica de flujo. Sin embargo, al agregar un peso de enlace a cada una de
ent radas, la matriz de grfica se convierte en una herrami ent a poderosa para
luar la est ruct ura de control del pr ogr ama durant e la prueba. El pes o de enl ace
porciona i nformaci n adicional acerca del flujo de control. En su forma ms
el peso de enl ace es 1 (existe una conexin) o O (no existe una conexin). Perc
pesos de enl ace t ambi n se le asi gnan ot ras propi edades, ms i nt eresant es:
La probabilidad de que se ej ecut e un enl ace (arista).
El t i empo de pr ocesami ent o gast ado durant e el recorrido a un enlace.
La memori a requeri da durant e el recorrido de un enl ace.
Los recursos requeri dos dur ant e el recorrido de un enl ace.
Beizer [BEI90] proporci ona un t rat ami ent o compl et o de al gori t mos mat er
adicional es que son aplicables a una matriz de grfica. El empl eo de est as t
permi t e aut omat i zar parcial o t ot al ment e el anlisis requeri do para di sear cas-:* i
prueba.
" Un error clsico es prestor ms atencin a la ejecucin de los pruebas que a su dise o."
B rian I
i
1 4 . 5 PRUEBAS DE LA ESTRUCTURA DE CONTROL
La t cni ca de prueba de la ruta bsi ca descrita en la seccin 14.4 es una de
t cni cas para la prueba de est ruct uras de control. Aunque la prueba de la ruta ~ J
ca es simple y efectiva, no es suficiente por s mi sma. En esta secci n se ar
brevement e vari aci ones sobre la prueba de est ruct uras de control. stas er
la cobertura de l as pr uebas y mej oran la calidad de la prueba de caj a bl anca
TM
PDF Editor
> lgicas que
: mismo de
mes de
14.5.1 Prueba de condicin
La prueba de condicin [TAI89] es un mt odo de diseo de casos de prueba que ejer-
: LAV E cita las condiciones lgicas contenidas en un mdul o del programa. Una condicin
s son mucho simple es una variable booleana o una expresin relacional, tal vez precedida con un
; en las operador NOT (->). Una expresin relacional t oma la forma
s de las
, <operador relacional> E
donde E, y E son expresiones aritmticas y <operador relacional> es uno de los si-
guientes: < , < , = , # (desigual), > o a . Una condicin compuest a la integran dos o
ms condiciones simples, operadores bool eanos y parntesis. Se supone que entre
los operadores bool eanos permitidos en una condicin compuesta se incluyen OR (I),
AND (&) y NOT (-). Una condicin sin expresiones relacinales se considera una ex-
presin booleana. Por tanto, los posibles tipos de el ementos en una condicin inclu-
yen un operador booleano, una variable booleana, un par de parntesis (que encie-
rran una condicin bool eana simple o compuesta), un operador relacional o una ex-
presin aritmtica.
Si una condicin es incorrecta, ent onces por lo menos un component e de la con-
dicin es incorrecto. Por tanto, entre los tipos de errores en una condicin se inclu-
yen los present es en el operador booleano (operadores bool eanos incorrectos/fai-
tantes/adicionales), en la variable bool eana, en los parntesis booleanos, en los
operadores relacinales y en la expresin aritmtica. El mt odo de prueba de condi-
cin se concentra en la prueba de cada condicin del programa para asegurar que
no contiene errores.
14.5.2 Prueba del flujo de datos
El mt odo de prueba del flujo de datos selecciona rutas de prueba en un programa de
acuerdo con las ubicaciones de las definiciones y los usos de las variables en el pro-
grama. El enfoque de prueba del flujo de datos se ilustra suponi endo que a cada ins-
truccin de un programa se le asigna un nmero de instruccin, y que ninguna fun-
cin modifica sus parmet ros o variables globales. En el caso de una instruccin con
I como nmero de instruccin,
DEF(I) = {X I instruccin I contiene una definicin de X
USO(l) = {XI instruccin I contiene un uso de X)
Si la instruccin / es una instruccin if (si) o loop (bucle), su conj unt o DEF est vaco
y su conj unt o USO se basa en la condicin de la instruccin /. Se dice que la defini-
cin de la variable X en la instruccin / est viva en la instruccin /' si existe una ru-
ta de la instruccin I a la /' que no contiene otra definicin de X.
Una cadena definicin-uso ( DU) de la variable X es de la forma [X, /, /'], donde I e
/ ' son nmeros de instruccin, X est en DEF(I) y USO(I'), y la definicin de X en la
instruccin I est viva en la /' .
TM
PDF Editor
^ CONS J O^
N o es realista
asegurar q ue la
prueba del flujo de
datos se usar de
manera extenso
cuando se prueba un
sistemo grande.
Sin embargo, puede
usarse de una manera
orientada a un blonco
en reos de software
q ue estn bajo
sospecha.
Cl a s e s d e
b u c l e s .
Una est rat egi a simple de prueba de flujo de dat os consi st e en solicitar que c a a
cadena DU sea cubierta por lo menos una vez. Esta estrategia se denomi na estrB
gia de prueba DU. Se ha most r ado que st a no garant i za la cobert ura de t odas las >>]
mas de un programa. Sin embargo, sl o en raras si t uaci ones no se garant i za que
r ama est cubierta por una prueba DU, como en las const rucci ones if-then-else s - j
entonces-si_no) en que la part e then no tiene definicin de al guna variable y la w l
te else no existe. En est a situacin, la r ama else de la instruccin if no est necea- 1
ri ament e cubierta por la prueba DU. Se han est udi ado y compar ado varias e s t n c i
gi as de prueba de flujo de dat os (por ejempl o, [FRA88], [NTA88], [FRA93]). A los i J
tores i nt eresados se l es recomi enda que consi deren consul t ar es as referencias
bliogrflcas.
"Los personas que destacan en la aplicacin de pruebas son maestras en percibir que ' a
ello."
) es gracioso' y actuar
B rian I
14.5.3 Prueba de bucles
i p k n J Los bucl es son la piedra de t oque par a la gran mayor a de l os al gori t mos im
t ados en soft ware. Y aun as, a menudo se l es prest a poca at enci n mi ent ras s
lizan pr uebas de soft ware.
La prueba de bucles es una tcnica de prueba de caj a bl anca que se c o n c e n t r a
el usi vament e en la validez de la const rucci n de bucles. Es posible definir c u a t n f l
ferent es cl ases de bucl es [BEI90J: bucl es simples, concat enados, ani dados y i ^ i
fract urados (figura 14.7).
Bucles
no estructurados
TM
PDF Editor
C A P I T U L O 1 4 TCNICAS DE PRUEBA DEL SOFTWARE
433
B ucl es s i mpl es . El siguiente conj unt o de pr uebas se aplica a bucl es simples, don
de n es el nmer o mxi mo de pas os que permi t e el bucle.
1. Omitir por compl et o el bucle.
2. Slo un paso por el bucle.
3. Dos pasos por el bucle.
4. m pas os por el bucle, donde m<n.
5. n = 1, n, n + 1 pas os por el bucl e
B ucl es ani dados . Si se f uese a ext ender el enf oque de prueba de los bucl es si m-
pl es a los ani dados, el nmer o de pr uebas posi bl es crecera geomt r i cament e a me-
dida que aument e el nivel de ani dami ent o. Esto generar a un nmer o poco prct i co
de pruebas. Beizer [BEI90] sugiere un enf oque que ayudar a reducir el nmer o de
pruebas:
1.
( pONSEJ O^.
t oodr probar
r cocia los bucles
i volver o
iniciar en el bucl e ms i nt erno. Asignar a t odos los bucl es los val ores mni-
mos.
Aplicar pruebas de bucle simple al ms i nt erno mi ent ras se mant i enen los ex-
t ernos en los val ores m ni mos del par met r o de iteracin (como el cont ador
de bucles). Agregar ot ras pr uebas para los val ores fuera de rango o excluidos.
Trabajar haci a fuera, conduci endo pr uebas para el siguiente bucle, per o man-
t eni endo t odos los dems bucl es ext ernos en val ores m ni mos y ot ros bucl es
ani dados en val ores "tpicos".
Seguir mi ent ras no s e hayan pr obado t odos los bucl es.
B ucl e s c onc at e nados . Los bucles concat enados se pr ueban empl eando el enfo-
que definido para los bucles simples, si cada uno de los bucles es independiente. Sin
embargo, si dos bucles est n concat enados y el cont ador del bucle I se empl ea como
valor inicial para el bucle 2, ent onces los bucles no son independientes. Cuando los
bucles no lo son, ent onces se recomi enda el enfoque aplicado a los bucles anidados.
B ucl es no es t ruct urados . Si empre que sea posible, est a cl ase de bucl es debe di-
s ear s e nuevament e para reflejar el uso de las const rucci ones de programaci n es-
t ruct urada (captulo 11).
2.
3.
4.
< 1 !
Las pruebas de caja negra, t ambi n denomi nadas, pruebas de comportamiento, se
concent r an en los requisitos funci onal es del soft ware. Es decir, permiten al ingenie-
ro de sof t war e derivar conj unt os de condi ci ones de ent rada que ejercitarn por com-
pl eto t odos los requisitos funci onal es de un programa. La prueba de caj a negra no
es una opcin frent e a las t cni cas de caj a bl anca. Es, en cambi o, un enf oque com-
pl ement ari o que tiene probabi l i dades de descubrir una cl ase diferente errores de los
que se descubriran con los mt odos de caj a blanca.
TM
PDF Editor
Cu l e s
? p r e g u n t a s
r e s p o n d e n l a s
p r u e b a s d e caj a
n e g r a ?
CLAV E
Una grfica representa
las relaciones entre los
objetos de datos y los
de programa, lo que
permite derivar casos
de prueba que
busquen errores
asociados con estos
relociones.
Las pruebas de caja negra tratan de encontrar errores en las siguientes cates
ras: 1) funciones incorrectas o faltantes, 2) errores de interfaz, 3) errores en estro:
turas de dat os o en acceso a bases de dat os externas, 4) errores de comport ami er-
to o desempeo, y 5) errores de inicializacin y trmino.
A diferencia de las pruebas de caja blanca, que se realizan al inicio del procese
prueba, las de caja negra tienden a aplicarse durante las ltimas et apas de la \
ba (consltese el capitulo 13). Debido a que st as desatienden a propsito la estro:
tura de control, la atencin se concentra en el dominio de la informacin. Las
bas estn diseadas para responder las siguientes preguntas:
Cmo se prueba la validez funcional?
Cmo se prueban el comport ami ent o y el desempeo del sistema?
Cules clases de entrada sern buenos casos de prueba?
El sistema es particularmente sensible a ciertos valores de entrada?
Cmo se aislan los lmites de una clase de datos?
Cules t asas de dat os y cul vol umen tolera el sistema?
Qu efecto tienen combinaciones especficas de datos sobre la oper ador
sistema?
Al aplicar tcnicas de caja negra se deriva un conjunto de casos de prueba que
tisfacen los siguientes criterios [MYE79]: 1) casos de prueba que reducen, m
una cuenta mayor que uno, el nmero de casos de prueba adicionales que debe- I
searse para alcanzar una prueba razonable, y 2) casos de prueba que indicar sd
acerca de la presencia o ausencia de clases de errores, en lugar de un error
do slo con la prueba especfica a la mano.
14.6.1 Mtodos grficos de prueba
El primer paso en la prueba de caja negra es comprender los objetos5 modelac s
el software y la relacin entre ellos. Una vez que se ha logrado, el siguiente 3
consiste en definir la serie de pruebas que verifican que "todos los objetos t!
relacin esperada entre s" [BEI95J. Explicado de otra manera, la prueba de
re empieza al crear una grfica de objetos importantes y sus relaciones y luegc a
una serie de pruebas que cubran la grfica de tal manera que se ejercite cada : n
to y relacin y que se descubran los errores.
Para dar estos pasos, el ingeniero de software empieza creando una grfica
coleccin de nodos que representan objetos, enl aces que representan la rea
tre objetos, pesos de nodo que describen las propiedades de un nodo (como ur a
de dat os o un comportamiento de est ado especfico) y pesos de enlace que di
algunas caractersticas de un enlace.
5 En este caso el trmino "objetos" se considera en el contexto ms amplio posible. Abarca obie: - :
tos, component es (mdulos) tradicionales y el ement os orientados a objetos del software de c
TM
PDF Editor
C A P T U L O 1 4 TCNICAS DE PRUEBA DEL SOFTV/ARI 435
aci n
y w
'(tiempo de generacin < 1.0 seg)
Permite la edicin de
Es representada como Atributos:
Contiene Dimensin inicial: valor o
preferencias
predeterminados
Color de fondo: blanco
Color de texto: color o
' preferencias
En la figura 14.8a se muestra una representacin simblica de una grfica. Los
nodos se representan como crculos conect ados por enl aces que t oman un nmero
diferente de formas. Un enlace directo (representado por una flecha) indica que una
relacin se mueve en una sola direccin. Un enlace bidireccional, tambin denomi-
nado enlace sim trico, indica que la relacin se aplica en ambas direcciones. Los en-
laces paralelos se empl ean cuando se establece un nmer o diferente de relaciones
ent re los nodos de la grfica.
Como ejemplo simple, considrese una parte de la grfica para una aplicacin de
procesami ent o de pal abras (figura 14.8b) donde
Objeto ttl = nuevoArchi vo (men seleccin)
Objeto #2 = vent anaDocument o
Objeto #3 = t ex t oDocument o
Si se toma como referencia la figura, una seleccin del men en nuevoArchi vo ge-
nera una vent ana de documento. El peso del nodo de vent anaDocument o propor-
ciona una lista de los atributos de la vent ana que se esperaban cuando sta se ge-
ner. El peso del enl ace indica que la vent ana debe generarse en menos de 1.0 se-
gundos. Un enl ace indirecto establece una relacin simtrica entre la seleccin del
men nuevoArchi vo y t ex t oDocument o. y los enl aces paralelos indican las rela-
ciones entre vent anaDocument o y t ex t oDocument o. En realidad, tendra que ge-
nerarse una grfica mucho ms detallada como precursora del diseo de casos de
prueba. El ingeniero de soft ware deriva ent onces los casos de prueba al recorrer la
TM
PDF Editor
436
grfica y cubrir cada una de l as rel aci ones most radas. Estos cas os de prueba se
sear n en un i nt ent o de encont r ar errores en cual qui era de las rel aciones.
Beizer [BEI95] describe vari os mt odos de prueba de compor t ami ent o que
grficas:
M odel ado del f lujo de t ransacci n. Los nodos represent an pasos de al guna tran-
sacci n (por ejempl o, los pas os requeri dos par a hacer una reservaci n en una
lnea empl eando un servicio en lnea) y l os enl aces represent an la conexi n l
ent re l os pasos. El di agrama de flujo de dat os (captulo 8) se utiliza par a ayudar
la creaci n de grficas de est e tipo.
M odel ado de e s t ado f inito. Los nodos represent an los di ferent es est ados que
usuari o observa en el sof t war e (por ejempl o, cada una de las "pantallas" que ap
cen cuando un empl eado t oma un pedi do por telfono) y l os enl aces represent ar
t ransi ci ones que ocurren para ir de un est ado a otro. El di agrama de est ado (
lo 8) ayuda a crear grfi cas de est e tipo.
M odel ado del f lujo de dat os . Los nodos son obj et os de dat os, y l os enl aces
las t ransformaci ones que ocurren para traducir un obj et o de dat os en otro. Por <
po, el nodo i mpue s t o ret eni do por FI CA (I RF) se calcula a partir de sal ari o
t o (SN) empl eando la relacin I RF = 0 . 6 2 x SN.
M odel ado rel aci onado c on el t i empo. Los nodos son obj et os de programa, y 1
enl aces son l as conexi ones secuenci al es ent re es os obj et os. Con los pesos de
ce se especifican los t i empos de ejecucin requeri dos mi ent ras el programa se
cut a.
Un anlisis det al l ado de cada uno de est os mt odos grficos de prueba se en
tra ms all del al cance de est e libro. El lector i nt eresado debe consul t ar IBEI95]
ra t ener una cobert ura compl et a.
14.6.2 Particin equivalente
La particin eq uivalente e s un m t o do de prueba de caj a negra que divide el
nio de ent r ada de un pr ogr ama en cl ases de dat os a partir de l as cual es pueder
rivarse casos de prueba. Un caso de prueba ideal de manej o simple descubre
cl ase de errores (por ejempl o, pr ocesami ent o i ncorrect o de t odos los dat os de <
^ÔNSEJO^^ teres) que, de otra manera, requerira la ejecucin de muchos casos ant es de que
observe el error general . La particin equi val ent e se esf uer za por definir un cas :
prueba que descubra ciertas cl ases de errores, reduci endo as el nmer o total de
s os de prueba que deben desarrollarse.
El di seo de casos de prueba para particin equi val ent e se basa en una ev
cin de las cl ases de equival encia para una condicin de ent rada. Con el uso ce
concept os introducidos en la secci n anterior, si es posibl e enl azar un conj un: :
obj et os medi ant e rel aci ones simtricas, transitivas y reflexivas, ent onces existe
cl ase de equi val enci a [BEI95]. Una cl ase de equival encia represent a un conj un: :
est ados vl idos y no vlidos par a las condi ci ones de ent rada. Por lo general
Las condiciones de en-
trado son conocidos
en una etapa relativa-
mente temprono del
proceso de software.
Por esto, debe empe-
z ase a pensar en la
xrtian eq uivalente
e nt r a s e
TM
PDF Editor
Cmo s e
def i nen l as
; para
p r o b a s ?
\
CLAV E
ft extiende I
~trarse en los
de las "aristas"
E una clase de
ardenta.
Cmo
pue do crear
de prueba
AVI ?
condicin de ent r ada es un valor numri co especfico, un r ango de val ores, un con-
junto de val ores rel aci onados o una condicin bool eana. Las cl ases de equival encia
se defi nen de acuer do con l as si gui ent es directrices:
1. Si una condi ci n de ent rada especifica un rango, se definen una cl ase de equi-
valencia vlida y dos no vlidas.
2. Si una condi ci n de ent rada requi ere un valor especfico, se defi nen una cl ase
de equival encia vlida y dos no vlidas.
3. Si una condi ci n de ent r ada especifica un mi embr o de un conj unt o, se defi nen
una cl ase de equival encia vlida y otra no vlida.
4. Si una condicin de ent r ada es bool eana, s e definen una cl ase de equi val en-
cia vlida y otra no vlida.
Al aplicar .estas directrices para la derivacin de cl ases de equival encia, se desa-
rrollarn y ej ecut arn los cas os de prueba para cada obj et o de los dat os del domi ni o
de ent rada. Los casos de prueba s e sel ecci onan de modo que el mayor nmer o de
atributos de cl ase de equival encia se ejercita una vez.
14.6.3 Anlisis de valores lmite
Es mayor el nmer o de errores que s e present a en los lmites del domi ni o de ent ra-
da que en el "centro"; por ello se ha desarrol l ado el anlisis de valores lmite (AVL) co-
mo tcnica de prueba. El AVL lleva a una seleccin de casos que prueba l os val ores
lmite.
El anl i si s de val ores lmite es una tcnica de di seo de cas os de prueba que com-
pl ement a la particin equi val ent e. En lugar de sel ecci onar cual quier el ement o de
una cl ase de equival encia, el AVL lleva a la seleccin de casos de prueba en l as "aris-
tas" de la clase. En lugar de concent r ase excl usi vament e en l as condi ci ones de en-
t rada, el AVL t ambi n deriva cas os de prueba del domi ni o de salida [MYE79].
Las directrices para el AVL son muy simil ares a l as proporci onadas para la parti-
cin equival ente:
1. Si una condicin de ent r ada especifica un r ango limitado por los val ores a y b,
los casos de prueba deben di searse con esos valores, adems de los que se
encuent r an apenas arriba y abaj o de ellos.
2. Si una condicin de ent r ada especifica di versos valores, deben desarrol l arse
casos de prueba que ejerciten los nmer os mxi mo y mnimo. Tambin se
pr ueban los val ores ubi cados apenas arriba y abaj o de est os mxi mos y mni-
mos.
3. Aplicar l as directrices 1 y 2 a l as condi ci ones de salida. Por ejempl o, supnga-
se que una tabla que compar a presin y t emperat ura se requiere como salida
de un pr ogr ama de anlisis de ingeniera. Los casos de prueba deben di sear-
se para crear un i nforme de salida que produzca el nmer o mxi mo (y mni-
mo) permisible para l as ent r adas de la tabla.
TM
PDF Editor
4. Si la estructura interna de dat os del programa tiene lmites prescritos (por
ejemplo, una matriz que tiene un lmite definido de cien entradas) debe disc
arse un caso de prueba para ejercitar los lmites de la estructura de datos
La mayora de los ingenieros de soft ware realizan intuitivamente el AVL, hasta c e a
to grado. Al aplicar est as directrices, la prueba de lmites estar ms completa
tanto, tendr una mayor probabilidad de detectar errores.
"El cohete Arione 5 estall al despegar debido a un simple def ecto (error) del sof tw are que se relacionaba con la eos
versin de un valor de punto f lotante de 64 bits en un entero de 16 bits. El cohete y sus cuatro satlites carec an os
seguro y costaron 500 millones de dlares. Una prueba completa del sistema hubiere encontrado el error, pero f w *- I
f ado por raz ones de presupuesto."
I nf orme not i c
i
K
%
CLAV E
La prueba de toblo
ortogonal permite
disear casos de
prueba que
proporcionan la
mxima cobertura de
prueba con un nmero
razonable de casos de
prueba.
14.6.4 Prueba de tabl a ortogonal
Hay muchas aplicaciones en las cuales el dominio de entrada es relativamente r *
tado. Es decir, el nmero de parmet ros es pequeo y los valores que cada pa ~33*
tro puede t omar estn cl aramente limitados. Cuando est os nmeros son muy p e o H
os (por ejemplo, tres parmet ros de entrada t oman tres valores discretos cada -~ncfl
es posible considerar cada permutacin de entrada y probar exhaustivamente e n f l
cesami ent o del dominio de entrada. Sin embargo, a medida que crece el n m e i B
valores de entrada, junto con el nmero de valores discretos para cada elemeros I
prueba exhaustiva se vuelve poco prctica o imposible.
La prueba de tabla ortogonal se aplica en probl emas en los cuales el d o mr i :
entrada es relativamente pequeo, pero demasi ado grande para una prueba e r
tiva. El mt odo de prueba de tabla ortogonal resulta til sobre todo para enccr ^M
errores asociados con las fallas de regin (una categora de error asociada cor
fectos de la lgica en un component e de software).
Ilustrar la diferencia entre la prueba de tabla ortogonal y los enfoques ms
cionales de "un elemento de entrada a la vez" requiere imaginar un sistema C OH^ H
el ementos de entrada, X,YyZ. Cada uno de estos el ement os tiene tres val crt s( ^B
cretos asociados. Hay 33 = 27 casos de prueba posibles. Phadke [PHA97] sug>e-^B
concepto geomtrico, que se ilustra en la figura 14.9, para los posibles c a s ^ ^ H
prueba asociados con X, Y y Z. Si t oma como referencia la figura, slo un e!e-nd
de entrada podra variar a un mismo tiempo en la secuencia que sigue cada a s
entrada. Esto da como resultado un cobertura relativamente limitada del domin::
trada (que representa el cubo de la izquierda de la figura).
Cuando se present a una prueba de tabla ortogonal se crea una tabla ortogxm
de casos de prueba, la cual tiene una "propiedad de equilibrio" [PHA97]. Es Crr*|
casos de prueba (representados con punt os azul es en la figura) estn "unifor"
te dispersos por todo el dominio de la prueba", como se ilustra en el cubo de la
de la figura 14.9. La cobertura de prueba en el dominio de entrada es ms comnH
TM
PDF Editor
97],
de
O
Un e l e me nt o de e nt r ada a l a ve z Tabl a ort ogonal L9
Para ilustrar el uso de la tabla ortogonal L9, considrese la funcin enviar de una
aplicacin de fax. Se pasan cuatro parmetros, Pl , P2, P3 y P4 a la funcin enviar.
Cada uno toma tres valores discretos. Por ejemplo, Pl t oma los valores:
Pl = 1, enviarlo ahora
Pl = 2, enviarlo en una hora
Pl = 3, enviarlo a medi anoche
P2, P3 y P4 tambin podran t omar los valores 1, 2 y 3, represent ando otras funcio-
nes de enviar.
Si se eligiera una estrategia de prueba "un elemento de entrada a la vez", se es-
pecificaran las siguientes secuencias de prueba (Pl, P2, P3, P4): (1, 1, 1, 1), (2, 1, 1,
1), (3, I, 1, 1), (1, 2, 1, 1), (1, 3, I, 1), (1, 1, 2, 1), (1, 1, 3, 1), (1, 1, 1, 2) y (1, 1, 1, 3).
Phadke [PHA97] evala estos casos de prueba al afirmar:
Est os casos de prueba sl o son tiles cuando se est segur o de que los par met r os de
prueba no i nt eract an. Det ect arn fallas de lgica donde un solo valor de par met r o ha-
ce que el soft ware funci one mal. Se trata de fallas de modalidad simple. Este mt odo no de-
tecta fallas de lgica que provoquen un mal f unci onami ent o cuando dos o ms par met r os
t oman ciertos val ores si mul t neament e; es decir, no detecta interacciones. Por tanto, su
capaci dad par a det ect ar fallas est limitada.
Dado el nmero relativamente pequeo de parmet ros de entrada y valores discre-
tos es posible aplicar una prueba exhaustiva. El nmero de pruebas requeridas es 34 =
81 (grande, pero manejable). Se encontraran todas las fallas asociadas con permu-
tacin de elementos de datos, pero el esfuerzo requerido es relativamente alto.
El enfoque de prueba de tabla ortogonal permite proporcionar buena cobertura de
prueba con un nmero considerablemente menor de casos de prueba que la estra-
tegia exhaustiva. En la figura 14.10 se muestra una tabla ortogonal L9 para la fun-
cin enviar de fax.
A continuacin se presenta la evaluacin de Phadke [PHA97] acerca de las prue-
bas aplicadas con la tabla ortogonal:
TM
PDF Editor
Tabl a
ortogonal L9.
Caso
de prueba
Parmetros de prueba
De t e ct a y ai sl a t odas l as f al l as de modal i dad s i mpl e. Una falla de modalidad sr r h
pie es un probl ema consi st ent e con cualquier nivel de cualquier par met r o simple. ~ -
ej empl o, si t odos los casos de prueba del factor Pl = 1 causan una condicin de error -r
trata de una falla de modal i dad simple. En est e ej empl o, las pr uebas 1, 2 y 3 (figura 14
most rarn errores. Al anal i zar la i nformaci n acerca de cul es pr uebas muest ran err: *i i
se identifican cul es val ores de par met r os causan la falla. En est e ej empl o, al not ar cj
las pr uebas 1,2 y 3 causan errores, se aisla [el pr ocesami ent o lgico asoci ado con "e
lo ahora" (Pl = 1)] como la f uent e del error. Este ai sl ami ent o de la falla es i mport ant e:
ra corregirla.
De t e ct a t odas l as f al l as de modal i dad dobl e. Si existe un probl ema con
cuando se pr esent an niveles especficos de dos par met r os al mi smo tiempo, se le i
mi na falla de modalidad doble. Por supuest o, se trata de una indicacin de incomp
dad de un par de val ores o de i nt eracci ones dai nas ent re dos par met r os de prueba
Fallas mul t i modal es . Las t abl as ort ogonal es (del tipo most rado) slo asegur an 1=
teccin de fallas de modal i dad simpl e y doble. Sin embargo, est as pr uebas t ambi n (
tan muchas fallas mul t i modal es.
Un anlisis detallado de las pruebas de tabla ortogonal se encontrar en
HERRAMI ENTAS DE SOFTWARE
Diseo de casos de prueba
1 ^ 1 Obj eti vo: Ayudar al equipo de software a de-
sarrollar un conjunto completo de casos de
prueba de caja blanca y negra.
M ecni ca: Estas herramientas caen en dos amplias cate-
goras: pruebas estticas y dinmicas. Se emplean tres ti-
pos diferentes de herramientas de prueba esttica er i
herramientas de prueba basadas en cdigo, lenguc :
prueba especializados y herramientas de prueba i
en requisitos. Las herramientas de prueba basadas <
digo aceptan cdigo fuente como entrada y realizar i
rios anlisis que llevan a la generacin de casos de
TM
PDF Editor
CAP TULO 1 4 TCNICAS DE PRUEBA DA SOFTWARE 441
. Los lenguajes de prueba especializados (como
i permiten que un ingeniero de software escriba es-
iones detalladas que describen cada caso de
y la logstica para su ejecucin. Las herramientas
z rjeba basadas en requisitos aislan requisitos especfi-
oel usuario y sugieren casos de prueba (o clases de
) que ejercitarn los requisitos. Las herramientas
licas de prueba interactan con un programa de eje-
; revisando la cobertura del camino, probando las
iones relacionadas con el valor de variables espec-
e instrumentando de otra manera el flujo de ejecucin
irograma,
mi ent as repres ent at i vas 6
Test, desarrollada por McCabe & Associates
-Avw.mccabe.com), implemento diversas tcnicas de
enjeba de la ruta derivadas de una evaluacin de la
complejidad ciclomtica y de otras mtricas de software.
\
Panorama, desarrollada por International Software Auto-
mation, Inc. (www.softwareautomation.com), abarca un
juego completo de herramientas para desarrollar soft-
ware orientado a objetos, incluidas herramientas que
a y u d a n a di s e a r c a s os d e p r u e b a y pl a n e a r pr ue ba s .
TestWorks, desarrollada por Software Research Inc. (www.
soft.com/Products), es un juego completo de herramien-
tas automatizadas de prueba que ayudan al diseo de
casos de prueba para software desarrollado en C/C++ y
Java y proporcionan soporte a pruebas de regresin.
T-Vec Test Generation System, desarrollado por T-VEC
Technologies (www.t-vec.com), es un conjunto de herra-
mientas que da soporte a pruebas de unidad, integra-
cin y validacin al ayudar en el diseo de casos de
prueba empleando informacin contenida en una espe-
cificacin de requisitos orientada a objetos. J
J *5 vi l fA F THbSTO$ I f fe
La arquitectura del soft ware orientado a objetos genera una serie de subsi st emas se-
parados en capas que encapsul an las cl ases que colaboran entre s. Cada uno de es-
tos el ement os del sistema (subsistemas y clases) realiza funci ones que ayudan a
cumplir con los requisitos del sistema. Es necesario probar un sistema orientado a ob-
jetos en diferentes niveles para descubrir errores que podran ocurrir a medida que
las cl ases colaboran entre s y los subsi st emas se comuni can ent re las capas de la
arquitectura.
En el aspect o estratgico, la prueba orientada a objetos es similar a la de los sis-
t emas convencionales, pero es diferente en el aspect o tctico. Debido a que los mo-
del os de anlisis y diseo orientados a obj et os tienen una estructura y un cont eni do
similares al programa orientado a obj et os resultante, la "prueba" podra empezar con
la revisin de est os modelos. Una vez que se ha generado el cdigo, la prueba orien-
tada a obj et os real empi eza por lo "pequeo", con una serie de pruebas di seadas
para ejercitar las operaci ones de clase y exami nar si existen errores a medida que
una clase colabora con otra. Cuando las cl ases se integran para formar un subsiste-
ma, se aplica la prueba basada en el uso, junto con los enfoques basados en fallas,
para ejercitar pl enament e las clases que col aboran entre s. Por ltimo, se empl ean
los casos de uso para descubrir errores al nivel de validacin del soft ware.
El diseo convencional de casos de prueba lo det ermi na el concept o ent rada-pro-
ceso-salida del soft ware o el detalle algortmico de mdul os individuales. La prueba
6 Las herramientas expuestas aqu slo representan una muestra de esta categora. En casi todos los
TM
PDF Editor
442
Uno excelente colec-
cursos sobfe praebos
oiientodos o objetos se
encontrar en
www. r b s i . c a m.
orientada a objetos se concentra en el diseo de secuencias apropiadas de oper acm
para ejercitar los est ados de una clase.
14.7.1 Implicaciones del concepto orientado a objetos en el diseo
de casos de prueba
A medida que la clase evoluciona medi ant e los modelos de anlisis y diseo se VJ~
ve un destino para el diseo de casos de prueba. Debido a que los atributos y las :cu-
raciones estn encapsulados, las operaciones de prueba fuera de la clase sueler s e
improductivas. Aunque el encapsul amiento es un concepto de diseo esenc:
orientacin a objetos, representa un obstculo menor cuando se prueba, como .:
dica Binder [BIN94]: "La prueba debe informar sobre el estado concreto y abst r â
de un objeto". Sin embargo, el encapsul ami ent o llega a dificultar la adquisicicr. m
esta informacin. A menos que se proporcionen operaciones integradas para
tar los valores de los atributos de clase, ser difcil obtener una instantnea Ge s i
t ado de un objeto.
La herencia tambin plantea desafios adicionales para el diseador de cas: s
prueba. Ya se ha observado que cada nuevo contexto de uso requiere una nueva m | H
ba, aunque se haya al canzado la reutilizacin. Adems, la herencia mltiple' : . KM
plica la prueba ms all de aument ar el nmero de contextos que requierer
prueba [B1N94]. Si las subclases que se convierten en instancias a partir de
perclase se usan dentro del mismo dominio del problema, es posible usar el c c | ^ |
to de casos de prueba derivado de la superclase cuando se prueba la subclase 9 r
embargo, si sta se emplea en un contexto compl etamente nuevo, los casos de r r of l
ba de la superclase no sern aplicables y ser necesario disear un nuevo c o - ' - Hl
de pruebas.
J 14.7.2 Aplicabilidad de mtodos convencionales de diseo de
de prueba
Los mt odos de prueba de caja bl anca descritos en secciones anteriores puede-
carse a las operaciones definidas para una clase. Las tcnicas de flujo de dat os al
prueba de la ruta bsica o de bucle ayudan a asegurar que se han probado t c c a a H
instrucciones de una operacin. Sin embargo, la estructura concisa de muchas
raciones de clase hace que algunos argument en que el esfuerzo aplicado a 1
ba de caja blanca podra redirigirse mejor para probar un nivel de clase.
Los mt odos de prueba de caja negra son tan apropiados para los sistema?
tados a objetos como los sistemas que se desarrollan con mt odos conver
de ingeniera de software. Como ya se indic en este mismo captulo, los >
uso proporcionan informacin til para el diseo de pruebas de caja negra y a
das en el estado [AMB95].
7 Uri concepto de orientacin a objetos que debe usarse con extremo cuidado.
TM
PDF Editor
14.7.3 Prueba basada en fallas8
KVE
i para lo
loen
3 en crear
s sobre un
i de follas
s y luego deor
s oora probar
i Q u t i pos
4c f al l os s e
ron e n l as
; a opera-
i y en l as co-
e s ent re
El objetivo de la prueba basada en fallas dentro del sistema orientado a objetos es
disear pruebas que tengan una alta probabilidad de descubrir posibles fallas. Debi-
do a que el producto o sistema debe cumplir con los requisitos del cliente, la planea-
cin preliminar requerida para realizar la prueba basada en fallas empieza con el mo-
delo del anlisis. La persona que aplica la prueba busca fallas posibles (es decir, as-
pectos de la implementacin del sistema que generen defectos). Determinar si exis-
ten est as fallas requiere disear casos de prueba que revisen el diseo o el cdigo.
Por supuesto, la efectividad de estas tcnicas depende de la manera en que las
personas que aplican las pruebas adviertan una falla posible. Si las fallas reales en
un sistema orientado a objetos se consideran poco posibles, ent onces est e mt odo
en realidad no es mejor que cualquier tcnica de prueba al azar. Sin embargo, si los
modelos de anlisis y diseo arrojan luz sobre lo que tal vez est mal, ent onces la
prueba basada en fallas encontrar una cantidad importante de errores con gastos
relativamente mnimos de esfuerzo.
La prueba de integracin (cuando se aplica en un contexto orientado a objetos)
busca fallas en l l amadas a operacin o en conexiones ent re mensaj es. Tres tipos de
fallas se encuentran en este contexto: resultado inesperado, operacin incorrecta/
mensaj e empleado, invocacin incorrecta. Para determinar las fallas a medida que
se invocan las funciones (operaciones), debe examinarse el comport ami ent o de la
operacin.
La prueba de integracin se aplica a los atributos y a las operaciones. Los "com-
portamientos" de un objeto los definen los valores que se asignan a sus atributos. La
prueba debe ejercitar los atributos para determinar si ocurren valores apropiados pa-
ra distintos tipos de comport ami ent o de objeto.
Es importante observar que las prueba de integracin tratan de encont rar errores
en el objeto cliente, no en el servidor. Explicado en trminos convencionales, el eje
de la prueba de integracin es determinar si existen errores en el cdigo que llama,
no en el cdigo llamado. La llamada a la operacin se usa como una pista, una ma-
nera de encontrar los requisitos de prueba que ejercitan el cdigo que llama.
"Si s e quiere y espero que un programo funcione, lo ms probable es que se vea un programa funcionando (y que se
pasen por alto las follas)."
Cem Kaner et oL
De la seccin 14.7.3 a la 14.7.6 se ha adaptado de un articulo de Brian Marick publicado en el gru-
po de noticias de Internet componente. testi ng Esta adaptacin se incluye con el permiso del au-
tor. Para conocer mayor informacin sobre estos t emas consltese (MAR94|. Debe observarse que
las tcnicas analizadas de las secciones 14.7.3 a 14 7 6 son aplicables al software convencional.
TM
PDF Editor
%
CLAV E
Aunque se hoyo
probodo por completo
uno dose de bose, on
se tendr que probar
todos los clases
derivados de ello.
CIJA V E
La prueba basado en
escenarios descubrir
errores que ocurren
) cualquier octor
i con el
14.7.4 Casos de prueba y jerarqua de clase
La herencia no obvia la necesidad de una prueba completa de t odas las clases
vadas. En realidad, llega a complicar el proceso de prueba. Imagnese la Siguiente
tuacin. Una clase Base contiene las operaciones heredado( ) y redeJinido( ). Una
se Der i vado define redefinidof) para que sirva en un contexto local. Hay pocas
das de que debe probarse Dervado::redefindo() porque representa un nuevo d:
un nuevo cdigo. Pero debe probarse de nuevo Derivado: :heredado()?
Si Derivado: :heredado( ) llama a redefinido( ) y el comportamiento redefinida ,
cambiado, es posible que Derivado::heredado( ) manej e errneament e el nuevo
portamiento. Por tanto, se necesitan nuevas pruebas aunque no hayan cambi
diseo ni el cdigo. Sin embargo, es importante observar que slo es posible :
zar un subconj unt o de todas las pruebas de Derivado: :heredado(). Si parte del i
el cdigo de heredado( ) no depende de redefinido( ) (es decir, no lo llama a e.
ningn cdigo que lo llame indirectamente), es innecesario probar de nuevo ese
digo en la clase derivada.
Base.-.-redefinidoU y Dervado::redefinido son operaciones distintas con diferentes
cificaciones e implementaciones. Cada una tendra un conj unt o de requisitos
prueba derivados de la especificacin y la implementacin. Esos requisitos de ;
ba revisan fallas posibles: fallas de integracin, de condicin, de lmites, etc. Sir
bargo, es probable que las operaciones sean similares; sus conj unt os de req
de prueba se superpondrn. Mientras mejor sea el diseo orientado a objetos,
yor ser la superposicin. Es necesario derivar nuevas pruebas exclusivamente
los requisitos de DeHvado::redefinido( ) que no se satisfagan con las pruebas de
: : redefi ni do( ).
En resumen, las pruebas de Base::redefindo() se aplican a objetos de la clase i
vado. Las ent radas de prueba son apropiadas para las clases de base y derivada;
ro los resultados esperados podran diferir en la clase derivada.
14.7.5 Prueba bas ada en escenarios
La prueba basada en fallas soslaya dos tipos importantes de errores: 1) es
ciones incorrectas y 2) interacciones entre subsistemas. Cuando ocurren errores i
ciados con especificaciones incorrectas, el producto no hace lo que el cliente
re. Podra hacer lo incorrecto, u omitir funcionalidad importante. En cualquier
se merma la calidad (el cumplimiento de los requisitos). Los errores asociadc;
las interacciones entre subsistemas ocurren cuando el comport ami ent o de ur
sistema crea circunstancias (como eventos o flujo de datos) que causan la ft
otro subsistema.
La prueba basada en escenarios se concentra en lo que hace el usuario, no e.
ducto. Esto significa que se deben capturar las tareas (mediante casos de uso)
usuario tiene que realizar y luego aplicarlas, junto con sus variantes, como p
Los escenari os descubren los errores de interaccin. Pero esto se logra si
sos de prueba son ms complejos y realistas que las pruebas basadas en falla;
TM
PDF Editor
^CONSEJO^^
la prueba
i en escenarios
: m ritos, se
? mejores
s por tiempo
a si se revisan
5 de uso cuando
i xsarrollan como
del modelo de
pruebas bas adas en escenari os t i enden a ejercitar varios subsi st emas en una sol a
prueba (los usuari os no se limitan al uso de un subsi st ema a la vez).
Como ej empl o, consi drese el di seo de pr uebas bas adas en escenari os para un
editor de texto medi ant e la revisin de los si gui ent es casos de uso informal es:
Caso de uso: Corregir el borrador final.
Antecedentes: Es comn que se imprima el borrador "final", se lea y se descubran algu-
nos errores molestos y confusos en la imagen en pantalla. Este caso de uso describe la se-
cuencia de eventos que se presenta cuando ocurre esto.
1. Se imprime todo el documento.
2. Se recorre el documento, cambiando ciertas pginas.
3. A medida que se hacen cambios, se imprime pgina por pgina.
4. A veces se imprime una serie de pginas.
Este escenari o describe dos cosas: una prueba y necesi dades espec fi cas del usuario.
Las necesi dades del usuari o son obvias: I) un mt odo para imprimir pgi nas indivi-
duales, y 2) un mt odo para imprimir un r ango de pginas. A medi da que se aplica
la prueba, debe probarse la edicin des pus de imprimir (y a la inversa). La persona
que aplica la prueba espera descubrir que la funcin de impresin causa errores en
la funcin de edicin; es decir, que l as dos funci ones del soft ware no tienen la inde-
pendenci a apropi ada.
Caso de uso: Imprimir una nueva copia.
Antecedentes: Alguien pide al usuario una nueva copia del documento. Debe impri-
mirse.
1. Se abre el documento.
2. Se imprime.
3. Se cierra el documento.
Una vez ms, el enf oque de la prueba es rel at i vament e obvio, con la excepcin de
que est e document o no apar ece de la nada. Se cre en una t area inicial. Aquella ta-
rea afecta a sta?
En muchos edi t ores moder nos, los document os recuerdan cmo se imprimieron
por ltima vez. Como opcin predet ermi nada, se imprimen de la mi sma maner a la
siguiente ocasi n. Despus del escenari o Corregir el borrador final, con slo seleccio-
nar "Imprimir" en el men y hacer clic en el bot n Imprimir del cuadr o de dil ogo se
imprimir de nuevo la ltima versin corregida. De modo que, de acuer do con el edi-
tor, el escenari o correct o debe t ener est e aspect o:
Caso de uso: Imprimir una nueva copia
1. Se abre el documento.
2. Se selecciona "Imprimir" en el men.
TM
PDF Editor
446 P A R T E D O S PRCTCA DE LA INGENIERA DEL SOFTWARE
CLAV E
Lo prueba de
estructura de superficie
es anlogo a lo pruebo
de cojo negra. Lo de
estructuro de fondo es
similor a la de cojo
blanco.
3. Se revisa si est i mpri mi endo un r ango de pgi nas; si es as, se hace clic para
mir t odo el document o.
4. Se hace clic en el bot n Imprimir.
5. Se cierra el document o.
Pero este escenario indica un posible error de especificacin. El editor no hace 1
el usuario espera razonabl ement e que haga. Los clientes con frecuencia o mr
revisin indicada en el paso 3. Se sentirn mol estos cando vayan a la i mpr
encuent ren una pgina cuando queran 100. Los clientes mol estos sealarn
de especificacin.
Un diseador de casos de prueba podra pasar por alto esta dependencia al
ar la prueba, pero es probable que el problema surja durante la prueba. El r
sable de sta tendra ent onces que enfrentarse a la probable respuesta: "asi
pone que deba funcionar!"
14.7.6 Estructuras de superficie y de fondo en pruebas
E structura de superficie es la estructura observable ext ernament e de un p
orientado a objetos. Es decir, la estructura que resulta i nmedi at ament e obvia
usuario final. En lugar de realizar funciones, se le dan objetos determinados al
rio de muchos sistemas orientados a objetos para que los manipule. Pero
ra que sea la interfaz, las pruebas an se basan en tareas de usuario. La c
est as t areas requiere comprensin, observacin y comunicacin con usuarios
sentativos (y con todos los usuarios que no lo son que valga la pena tomar en
Segurament e habr algunas diferencias en los detalles. Por ejemplo, en li-
ma convencional con una interfaz orientada a comandos, el usuario podra
dos los comandos como lista de verificacin de una prueba. Si no existen e r
de prueba para ejercitar un comando, es probable que la prueba soslaye al
reas del usuario (o que la interfaz tenga comandos intiles). En una interfar
tada a objetos el responsable de la prueba podra emplear todos los objetos
una lista de verificacin de una prueba.
Las mej ores pruebas se derivan cuando el diseador observa el sistema
manera nueva o poco convencional. Por ejemplo, si el sistema o el product
una interfaz basada en comandos, las pruebas ms compl etas se derivarn
seador del caso de prueba pretende que las operaciones sean independiente;
objetos. Deben plantearse pregunt as como: "El usuario desear usar esta
(que slo se aplica al objeto escner) mientras trabaja con la impresora?
portar cul sea el estilo de la interfaz, el diseo de casos de prueba que ej
estructura de superficie debe usar objetos y operaciones como pistas que c
a t areas omitidas.
La estructura a fondo representa los detalles tcnicos internos de un
orientado a objetos. Es decir, la estructura que se comprende al examinar ei
el cdigo, o ambos. La prueba de estructura de fondo est diseada para ej e'
pendencias, comport ami ent os y mecani smos de comunicacin que se han
TM
PDF Editor
cido como part e del model o de di seo (captulos 9-12) para el sof t war e ori ent ado a
obj et os.
Los model os de anlisis y di seo son la base de la prueba de est ruct ura de fondo.
Por ejempl o, el di agr ama de col aboraci n UML o el model o de despl iegue describe
las col aboraci ones ent r e obj et os y subsi st emas que tal vez no sean visibles ext erna-
ment e. El di seador de casos de prueba pregunt a ent onces: hemos capt urado (co-
mo prueba) al gunas t ar eas que ejercitan la col aboraci n indicada en el di agr ama de
col aboraci n? Si no es as, por qu?
" No se overgi lience de los errores ni los convierto en cr menes."
Conf uci o
1 4 . 8 M T OD OS DE PRUEBA APLI CABLES AL NI VEL DE CLASE
En el captulo 13 se indic que la prueba del sof t war e empi eza por lo "pequeo" y
l ent ament e avanza hacia lo "grande". Se prueba en el pequeo ent or no de una sol a
cl ase y los mt odos que est n encapsul ados en la clase. La prueba al eat ori a y la par-
ticin son mt odos que se empl ean para ejercitar una cl ase durant e una prueba
ori ent ada a obj et os [KIR94].
14.8.1 Prueba aleatoria para clases orientadas a objetos
Para ilustrar br evement e est os mt odos, i mag nese una aplicacin bancari a en que
una clase C u e n t a tiene las siguientes operaciones: abrirf >, configurar( ), depositar( ), re-
tiran ), saldar( ), sumarf), IimiteCredito( ) y cerraf) [KIR94]. Cada una de est as opera-
ci ones se aplica a C u e n t a , pero hay ciertas restricciones (por ejemplo, la cuent a debe
abrirse ant es de aplicar ot ras operaci ones, y debe cerrarse despus de que se han com-
pl etado todas las operaciones) rel aci onadas con la natural eza del problema. Aun con
est as restricciones, hay muchas permut as en las operaci ones. El historial de compor-
t ami ent o m ni mo de una instancia de C u e n t a incluye l as siguientes operaciones:
abrir configurar depositar retirar cerrar
Esto represent a la secuenci a de prueba mnima para C u e n t a . Sin embargo, po-
dra pr esent ar se una amplia variedad de compor t ami ent os distintos dent r o de esta
secuenci a.
abrir configurar depositar (depositar | retirar | saldar | sumar | limiteCredito]"-retirar "ce-
rrar
Es posible generar al azar varias secuenci as diferentes de operaciones. Por ejemplo:
Caso de prueba r: abrir configurar' depositar* depositar saldar sumar retirar' cerrar
Caso de prueba r2: abrirconfigurardepostarretrardepositarsaldar*limiteCredi-
to retirar cerrar
stas y ot ras pr uebas de orden al eat ori o se aplican para ejercitar di ferent es histo-
riales de i nst anci as de clase.
CONSEJO^
de posibles
en uno
z ieatoro llega
se muy
ln eficiencia
meba mejorara
triz ara una
similor o la
de tabla
TM
PDF Editor
HOGARSEGURO
Prueba de clase
l a e s c e na: Cubculo de Shakira.
Los act ores : Jamie y Shakira, integrantes de! equipo
de ingeniera del software HogarSeguro que estn traba-
jando en el diseo de casos de prueba para lo funcin
de seguridad.
La convers aci n:
Shak i ra: He desarrollado algunas pruebas para la cla-
se Detector [figura 11.4], ya sabes, la que permite ac-
ceso a todos los objetos de Se ns or para la funcin de
seguridad. Ests familiarizada con ella?
Jami e ( sonri endo) : Claro, es la que te permite agre-
gar el sensor antiperros".
Shak i ra: Esa misma. De cualquier manera, tiene una in-
terfaz con cuatro operaciones: leerQ, activar!), desactivarI)
y probarfj. Antes de que un sensor tenga la posibilidad de
leer, debe activarse. Una vez cctivado, puede leerse y pro-
barse. Es posible desactivarte en cualquier momento, a
menos que se haya procesado una condicin de alarma.
De modo que defin una secuencia simple de prueba que
ejercitar su historial de comportamiento.
(Muestra a Jamie la siguiente secuencia.)
#1: activar' probar-leer-desactivar
Jami e: Eso funcionar, pero tienes que probar ms
que eso! ' ". . r' '
Shak i ra: Lo s, lo s. He aqu otras secuencias que he
elaborado. ti
(Muestra a Jamie las siguientes secuencias.)
# 2 : activar probar* [leer]" desactivar
# 3 : Peer]"
#4: activar desactivar* [probar | leer]
Jami e: Djame ver si comprendo tu intencin. #1 reco-
rre el historial completo, lo que representa una es pe: e
de uso convencional. #2 repite la operacin leer n
y ese es un escenario probable. #3 trata de leer e:
antes de que se active... eso debe producir algn cc
mensaje de error, verdad? #4 activa y desactiva e .-i
sor y luego trata de leerte. No es lo mismo que le
ba 3?
Shak i ra: En realidad no. En #4 el sensor se ha
do. Lo que realmente pruebo #4 es si la operador- -:
var funciona como debera. Si se presentan ieer] o
probar() despus de desactivar!), debe generarse
mensaje de error. Si no lo hace, entonces tenemos . -
error en la operacin desactivar.
Jami e: Estupendo. Slo recuerda que las cuatro
bas tienen que aplicarse a cada tipo de sensor,
coda operacin puede tener diferencias sutiles,
diendo del tipo de sensor.
Shak i ra: No te preocupes. se es el plan.
^ Cul es
'w opci ones de
prueba e s t n
di s poni bl es al
ni vel de c l as e ?
14.8.2 Prueba de particin al nivel de clase
La prueba de particin reduce el nmero de casos de prueba requeridos para si
tar la clase de manera muy parecida a la particin equivalente (seccin 14.6 j
el soft ware convencional. La ent rada y la salida se ordenan en categoras y -e ;
an casos de prueba para ejercitar cada categora. Cmo se derivan las c a t r ?
de particin?
La particin basada en el estado ordena en categoras las operaci ones de
partir de su capacidad para cambi ar el est ado de la clase. Si se piensa una vez
en la cl ase Cuenta, las operaci ones de est ado incluyen depositar( ) y retiran 1 ni
tras que las que no son de est ado incluyen saldar( ), sumar( ) y limiteCrediu i
pruebas est n di seadas de maner a que ejercitan por separado las oper ado- a
cambi an de est ado y las que no lo hacen. Por tanto,
Caso de prueba p,: abrir configurar depositar depositar retirar retirar cerrar
Caso de prueba P abrirconfigurardepositarsumarlimiteCredtoretirarcerrar
TM
PDF Editor
El caso de prueba p, cambia de estado, mientras que el caso de prueba p2 e j e r c i t a
operaciones que no cambian de est ado (aparte de las que se encuent ran en la se-
cuencia de prueba mnima).
La particin basada en atributos ordena en categoras las operaciones de clase ba-
sadas en los atributos que utilizan. En el caso de la clase Cuenta, los atributos sal-
dar y limfeCredifo se empl ean para definir particiones. Las operaciones se dividen en
tres particiones: 1) operaciones que usan limiteCredifo, 2) operaciones que modifican
limifeCredito, y 3) operaciones que no usan ni modifican limiteCredito. Entonces se dise-
an secuencias de prueba para cada particin.
La particin basada en categoras ordena en categoras las operaciones de clase
con base en la funcin genrica que cada una realiza. Por ejemplo, las operaciones
de la clase Cuenta se organizan en operaciones de inicializacin [abrirf), configu-
rar( )], operaciones comput aci onal es \depositar( ), retirarf)], consultas Isaldar)), su-
mar( ), UmiteCreditof )\ y de terminacin (cerrar( j\
El di seo de casos de prueba se vuelve ms complicado cuando empieza la integra-
cin del sistema orientado a objetos. En esta etapa debe empezar la prueba de cola-
boracin ent re clases. Para ilustrar la "generacin de casos de prueba de interclase"
[KIR94], se expande el ejemplo del sistema bancario present ado en la seccin 14.8
para que incluya las clases y colaboraciones indicadas en la figura 14.11. La direc-
cin de las flechas en la figura indica la direccin de los mensaj es. Y las etiquetas in-
dividuales indican las operaciones que se invocan como consecuencia de la colabo-
racin indicada por los mensaj es.
Como en la prueba de clases individuales, la prueba de colaboracin entre clases
se lleva a cabo al aplicar mt odos aleatorios y de particin, adems de pruebas ba-
sadas en el escenari o y de comportamiento.
14.9.1 Prueba de clases mltiples
Kirani y Tsai [KIR94] sugieren la siguiente secuencia de pasos para generar varios
casos de prueba aleatorios de clases mltiples:
1. En cada clase cliente use la lista de operaciones de clase para generar una se-
rie de secuencias de pruebas aleatorias. Las operaciones enviarn mensaj es a
otras clases del servidor.
2. En cada mensaj e generado, determnese la clase colaboradora y la operacin
correspondiente en el objeto servidor.
3. En cada operacin del objeto servidor (invocada por los mensaj es enviados
desde el objeto cliente) determnense los mensaj es que transmite.
4. En cada uno de los mensajes, determnese el siguiente nivel de operaciones
invocadas e incorprelos en la secuencia de prueba.
TM
PDF Editor
Di agrama de
col aboraci n
de cl as es
para una
apl i caci n
bancari a
( adapt ado de
[KI R94]) .
Interfaz de
usuario de
cajero automtico
tarjetolnsertada
contrasea
depositar
retirar
estatusCuenta
terminar
verificarCuenta
verilicarNIP
verificarPolitica
solicitarRetiro
solicitarDeposito
infoCuenta
verificarEstatus
estatusDeposito
despocharEfectivo
imprimirEstadoCuenta
leerlnfoTarjeta
obtenerMontoEfectivo
labrirCuenta
depositolnicia
autorizarTarjeta
desautorizar
cerrarCuenta
limiteCredito
tipoCuenta
saldar
retirar
depositar
cerrar
Cajero Cuenta
ln(o
Validacin
Como ejemplo [KIR94], considrese una secuencia de operaciones para la
B anco relacionada con una clase CajeroAutomati co (figura 14.11):
verificarCuenta verificarNIP [[verificarPolitica solict udRet iro] | solicitarDeposito |
Cuenta]"
Un caso de prueba aleatoria para la clase B anco sera:
Caso de prueba r3 = verificarCuenta-verificarNIP* solicitarDeposito
Considerar a los colaboradores que participan en la prueba requiere tomar er
ta los mensajes asociados con cada una de las operaciones indicadas en el
prueba r. B anco debe colaborar con inf oV alidacion para ejecutar viriji
verfcarN IP( ). B anco debe colaborar con Cuenta para ejecutar solicitarDepos:
tanto, se tiene un nuevo caso de prueba que ejercita estas colaboraciones:
Caso de prueba r4 = verificarCuentaBanco[valdarCuentalnfoValidacon]
verificarNIPBanco* [validarNIPInfovalidacion] solicitarDeposito [depositarcuentaj
El enfoque para la prueba de particin de clases mltiples es similar al
empl eado para la de clases individuales. Como se anal iz en la seccin 14.8^
mete a particin una sola clase. Sin embargo, se expande la secuencia de
para incluir las operaciones invocadas medi ant e mensaj es a las clases que ~
ran. Un enfoque alterno lleva a cabo la particin de las pruebas con base i
terfaces de una clase determinada. Si se t oma como referencia la figura 14.1:
se B anco recibe mensaj es de las clases CajeroAutomati co y Cajero Por!
mt odos dentro de B anco se prueban al particionarlas entre las que sirven ;
roAutomati co y a Cajero. La particin basada en el estado (seccin 14.8.2
para refinar an ms las particiones.
TM
PDF Editor
14.9.2 Pruebas derivadas de modelos de comportamiento
En el captulo 8 se analiz el uso del diagrama de est ado como model o para repre-
sentar el comportamiento dinmico de una clase. El diagrama de est ado de una cla-
se ayuda a derivar una secuencia de pruebas que revisa el comport ami ent o dinmi-
co de la clase (y las clases que colaboran con ella). En la figura 14.12 [K1R94] se
muestra un diagrama de est ado para la clase Cuenta que ya se analiz. Si se obser-
va, las transiciones iniciales recorren los est ados vaciar Cuenta y configurar Cuenta.
Un retiro final y un cierre de la cuenta causan que la clase Cuenta haga transicio-
nes a los est ados cuentalnactiva y cuentaMuerta, respectivamente.
Las pruebas que se diseen deben cubrir todos los est ados [KIR94]. Es decir, las
secuencias de operacin deben lograr que la clase Cuenta haga una transicin a to-
dos los est ados permisibles:
Caso de prueba S,: abrir configurCuenta depositar(inicial) ' retirar(final) cerrar
Debe not arse que esta secuencia es idntica a la secuencia de la prueba mnima tra-
tada en la seccin 14.9.1. La secuencia de la prueba adicional se agrega a la suce-
sin mnima,
Caso de prueba S,: abrir configurarCuenta depositar(incial) ' deposi t ar saldar acre-
ditar retirar(final) cerrar
Caso de prueba Sy. abrir configurarCuenta deposi t ar (inicial) deposi t ar retirar info-
Cuenta retirar(final) cerrar
Es posible derivar an ms casos de prueba para asegurar que todos los comporta-
mi ent os de la clase se hayan ejercitado adecuadament e. En situaciones en que el
comportamiento de la clase da como resultado la colaboracin con una o ms cla-
ses, se utilizan varios diagramas de est ado para registrar el flujo del comportamien-
to del sistema.
Di agrama de
es t ado para
ia cl as e
Cuenta
adapt ado de
nOR94]).
configurar j
Cuenta
saldar
Crdito
infoCuenta
depositar (inicial)
depositar
t r abaj ando|
Cuenta
retirar
r
retirar (final)
Cuenta
Cerrar 1 i n a c t i v a
TM
PDF Editor
452
El model o de est ado puede recorrerse de una maner a "pr i mer o- en- anch- i
[MGR94]. En est e cont ext o, pr i mer o- en- anchur a indica que un caso de prueba
ejercita una transicin. Cuando debe probarse una nueva transicin sl o s e u
t ransi ci ones pr obadas previ ament e.
Imag nese que el obj et o TarjetaCredi to es part e del si st ema bancari o. El
inicial de TarjetaCredi to es indefinido (es decir, no se ha proporci onado un n
ro de tarjeta de crdito). Tras leer la t arj et a durant e una vent a, el obj et o t oma un
t ado definido-, es decir, se defi nen l os at ri but os numero, tarjeta y fecha vencimiento
to con los identificadores especficos del banco. La tarjeta de crdito es r
cuando se le enva para aut ori zaci n, y es aprobada cuando se recibe la au
cin. La transicin de TarjetaCredi to de un est ado a ot ro se prueba derivant J
sos de prueba que causen la transicin. Un mt odo pri mero-en-anchura para esr.r
de prueba no ejercitara remitida ant es de indefinida o definida. En este caso, usara
siciones que no se han probado y, por tanto, violara el criterio primero-en-anch^-i.
^CONSEJO^.
sese una estrategia
de prueba similar a la
aleatoria o de
particin ( seccin
1 4.8 ) poro disear
pruebas de interfoz de
usuario.
se encontrorfin
informacin y recursos
l f e s p
c enl e/ ser vi dor :
w.csst-
Los mt odos de prueba anal i zados en secci ones ant eri ores suel en aplicarse
dos los ent ornos, l as arqui t ect uras y l as apl icaciones, pero en ocasi ones se
ci onan directrices y enf oques ni cos para las pruebas. En esta secci n se a'
l as directrices para prueba de los ent ornos, l as arqui t ect uras y las aplicaciones
ci al i zadas que suel en encont rar los i ngeni eros de soft ware.
14.10.1 Pruebas de interfaces grficas de usuario
Las interfaces grficas de usuario (GUI, por sus siglas en ingls) pl ant ean d
t er esant es a l os i ngeni eros de soft ware. Debido a los component es reutiliza
porci onados como part e de los ent ornos de desarrol l o de la GUI, la creacin ce
terfaz de usuari o consume menos t i empo y es m s preci sa (captulo 12). Pero <
mo t i empo ha crecido la complejidad de las GUI, lo que dificulta m s el di
ejecucin de casos de prueba.
Debido a que muchas GUI moder nas tienen un aspect o y un modo de uso
res, es posibl e derivar una serie de pr uebas est ndar. Las grfi cas de mod
est ado finito se usan para derivar una serie de pr uebas que ejerciten obj et os
fieos de dat os y pr ogr amas que resul tan rel evant es para la GUI.
Debido al gran nmer o de per mut aci ones asoci adas con l as operaci ones
GUI, la prueba debe reducirse empl eando her r ami ent as aut omat i zadas. En
mos a os ha apareci do en el mer cado una ampl ia serie de herrami ent as de
de GUI. Para un mayor anlisis al respect o consul t e el captulo 12.
14.10.2 Prueba de arquitecturas cliente/servidor
La arqui t ect ura cl i ent e/ servi dor represent a un i mport ant e desafi o para q
pr ueban el soft ware. La nat ural eza distribuida de los ent or nos cl i ent e/ s en

TM
PDF Editor
aspect os de desempeo relacionados con el proceso de transaccin, la posible pre-
sencia de varias plataformas de hardware diferentes, la complejidad de la comuni-
cacin en red, la necesidad de servir a varios clientes desde una base de dat os cen-
tralizada (o, en algunos casos, distribuida) y los requisitos de coordinacin impues-
tos al servidor se combinan para que la prueba de las arquitecturas de soft ware
cliente/servidor resulte considerablemente ms difcil que la prueba de aplicaciones
independientes. En realidad, estudios recientes de la industria indican un aument o
importante en el tiempo y costo de la prueba cuando se desarrollan ent ornos clien-
te/servidor.
"En el temo de los pruebas existe una buena dosis de similitud entre los sistemas tradicional y diente/servidor."
Ke l l e y B o u me
En general, la prueba del soft ware cliente/servidor se presenta en tres niveles di-
ferentes: 1) aplicaciones de cliente individuales se prueban en una modalidad "des-
conectada"; la operacin del servidor y la red no se t oman en cuenta; 2) el software
de cliente y las aplicaciones asociadas del servidor se prueban en conjunto, pero las
operaciones de red no se ejercitan de manera explcita; 3) se prueba toda la arqui-
tectura cliente/servidor, incluida la operacin y el desempeo de la red.
Aunque muchos tipos diferentes de prueba se conducen en cada uno de estos ni-
veles de detalle, los siguientes enfoques de prueba suelen encontrarse para aplica-
ciones cliente/servidor:
Pruebas de f unci onal i dad de la apl i caci n. La funcionalidad de las aplica-
ciones de cliente se prueba empl eando los mt odos anal izados en est e captu-
lo. En esencia, la aplicacin se prueba de manera independiente.
Pruebas de servidor. Se prueban las funciones de coordinacin y manej o de
dat os del servidor. Tambin se considera el desempeo del servidor (tiempo
de respuesta y procesami ent o total de los datos).
Pruebas de bas e de dat os. Se prueba la exactitud e integridad de los dat os
al macenados en el servidor. Se examinan las transacciones que realizaron las
aplicaciones de cliente para asegurar que los datos se al macenan, actualizan
y recuperan apropiadamente. Tambin se prueba la funcin de archivado.
Pruebas de transacci n. Se crea una serie de pruebas para asegurar que
cada clase de transacciones se procesa de acuerdo con sus requisitos. Las
pruebas se concentran en determinar si es correcto el procesami ent o y en as-
pectos del desempeo (por ejemplo, tiempos de procesami ent o de las tran-
sacciones y volumen de stas).
Pruebas de comuni caci ones de red. Con est as pruebas se verifica que la
comunicacin ent re los nodos de la red ocurre de manera correcta y que el
paso de mensaj es, las transacciones y el trfico de la red relacionado se reali-
za sin errores. Tambin es posible realizar pruebas de seguridad de la red co-
mo parte de est as pruebas.
TM
PDF Editor
Para completar estos enfoques de prueba, Musa [MUS93] recomienda el desarroi
de perfiles operaonales derivados de escenarios de uso de cliente/servidor.9 Un per
fil operacional indica la manera en que diferentes tipos de usuarios interoperan ccri
el sistema cliente/servidor. Es decir, los perfiles proporcionan un "patrn de us
aplicable al diseo y ejecucin de las pruebas.
14.10.3 Prueba de la documentacin y las funciones de ayuda
El trmino prueba del software evoca i mgenes de grandes cantidades de casos ix|
prueba preparados para ejercitar los programas de cmput o y los dat os que manir -
an. Si se recuerda la definicin de soft ware present ada en el primer captulo de es-
te libro, es importante observar que la prueba tambin debe extenderse al tercer e e
ment de la configuracin del software: la documentacin.
Los errores en la documentacin son tan devast adores para la aceptacin del pr : -
grama como los errores en los dat os o el cdigo fuente. Nada es ms frustrante
seguir una gua de usuario o una funcin de ayuda en lnea con toda pulcritud >
tener resultados o comportamiento que no coinciden con los descritos en la
mentacin. Por eso la prueba de la documentacin debe ser una parte signifi
de cualquier plan de prueba del software.
La prueba de la documentacin se aborda en dos fases. En la primera, reviste -
inspeccin (captulo 26), se examina la claridad editorial del documento. En la
gunda fase, prueba en vivo, se emplea la documentacin junto con el programa
M ' I H ' M - I I
El diseo del documento (formato, tipo de letra, sar-
gras, imgenes) es apropiado para comprender y a
milor rpidamente la informacin?
Todos los mensajes de error del software que se d e
pliegan para el usuario estn descritos con ms
en el documento? Las acciones que deben em-
se como consecuencia de un mensaje de error i
ramente delineadas?
Si se usan los vnculos de hipertexto, son exactos
completos?
Si se usa el hipertexto, el diseo de la navegado1- s
apropiado para la informacin requerida?
La nica manera viable de responder a estas pregu^T.
hacer que un tercero (por ejemplo, algunos usuarios i
donados) pruebe la documentacin en el contexto de ,
del programa. Se habrn de indicar todas las discr
cias y definirse las reas dbiles o ambiguas del
to para una posible reescritura.
Prueba de documentacin
V, Las siguientes preguntas deben responderse
durante la prueba de documentacin, de fun-
cin de ayuda, o ambas:
La documentacin describe con exactitud la manera en
que se realiza cada modalidad de uso?
Es exacta la descripcin de cada secuencia de interac-
ciones?
Los ejemplos son exactos?
La terminologa, las descripciones de men y las res-
puestas del sistema son consistentes con el programa
real?
Es realmente fcil localizar una gua dentro de la do-
cumentacin?
El uso de la documentacin facilita la deteccin y reso-
lucin de errores?
El contenido y el ndice del documento son exactos y
completos?
9 Debe observarse que los perfiles operacionales pueden aplicarse para probar todos los tipos
quitecturas del sistema, no slo la cliente/servidor.
TM
PDF Editor
Cul e s una
e s t r at e gi a
i para la
i de un s i s -
i en t i e mpo
14.10.4 Prueba de sistemas de tiempo real
La natural eza asincrnica, dependiente del tiempo, de muchas aplicaciones en tiem-
po real agrega un elemento nuevo (y difcil en potencia) a la mezcla de pruebas: el
tiempo. El diseador del caso de prueba no slo debe considerar los casos de prue-
ba convencionales, sino tambin el manej o de event os (es decir, el procesami ent o
de interrupciones), la temporizacin de los dat os y el paralelismo entre las t areas
(procesos) que manej an los datos. En muchas situaciones, los datos de prueba pro-
porcionados cuando el sistema en tiempo real est en un est ado producirn un pro-
cesami ent o apropiado, mientras que los mi smos datos proporci onados cuando el
sistema est en un est ado diferente provocarn un error.
Por ejemplo, el soft ware en tiempo real que controla una nueva fotocopiadora
acepta interrupciones del operador (es decir, el operador del equipo oprime teclas
como RE1NICIAR u OSCURECER) sin error cuando el equipo hace copias (en el est a-
do copiar). Si est as mi smas interrupciones del operador se ingresan cuando el equi-
po se encuent ra en el est ado atasco, se perder la pantalla de visualizacin del cdi-
go de diagnstico (indicando la ubicacin del atasco), lo que representa un error.
Adems, la ntima relacin entre el software en tiempo real y su ent orno de hard-
ware llegan a causar probl emas en la prueba. Las pruebas del software deben con-
siderar el impacto de las fallas del hardware en el procesami ent o del software. Re-
sulta ext remadament e difcil simular est as fallas de manera realista.
Los mt odos exhaustivos de di seo de casos de prueba para sistemas en tiempo
real siguen evolucionando. Sin embargo, es posible proponer una estrategia de cua-
tro pasos:
Prueba de tareas. El primer paso en la prueba del soft ware en tiempo real
consiste en probar cada tarea de manera independiente. Es decir, se disean y
ejecutan pruebas convencionales para cada tarea. (Cada tarea se ejecuta de
manera independiente durant e est as pruebas.) La prueba de tareas descubre
errores de lgica y funcionamiento, pero no de tiempo ni de comportamiento.
Prueba de comport ami ent o. Con el empleo de model os del sistema crea-
dos con herramientas automatizadas es posible simular el comportamiento de
un sistema en tiempo real y examinarlo como una consecuencia de eventos ex-
ternos. Estas actividades de anlisis sirven como base para el diseo de casos
de prueba que se realizan cuando se ha construido el software en tiempo real.
Prueba i ntertareas. Una vez que se hayan aislado los errores en t areas indi-
viduales y en el comportamiento del sistema, la prueba se desplaza hacia los
errores relacionados con el tiempo. Se prueban las t areas asincrnicas de las
cuales se sabe que se comunican entre s, empl eando diferentes t asas de da-
t os y cargas de procesami ent o para determinar si ocurrirn errores de sincro-
nizacin intertareas. Adems, se prueban las t areas que se comunican por
medio de la cola de mensaj es o el al macn de dat os para descubrir errores en
el t amao de est as reas de al macenami ent o de datos.
TM
PDF Editor
456 P A R T E D O S P Rc n c A DE LA INGENIERA DEL SOFTWARE
* Prueba del si st ema. El soft ware y el hardware estn integrados, de moc
que se aplica un rango completo de pruebas del sistema (captulo 13) para
tar de descubrir errores en la interfaz soft ware/ hardware. Casi todos los
mas en tiempo real procesan interrupciones. Por tanto, resulta esencial la
prueba del manej o de estos event os booleanos. Por medio del diagrama a s
est ado y la especificacin de control (captulo 8), el responsable de la pi
desarrolla una lista de t odas las interrupciones posibles y el procesamier '
que ocurre como consecuencia de las interrupciones. Entonces se disea-
pruebas para evaluar las siguientes caractersticas del sistema.
Se han asignado y manej ado apropiadamente las propiedades de in
cin?
Se ha manej ado correctamente el procesami ent o de cada interrupci: -
El desempeo de cada procedimiento de manej o de interrupciones
ejemplo, el tiempo de procesamiento) cumple con los requisitos?
Un elevado volumen de interrupciones que llega en moment os crtic:;
probl emas en la funcin o el desempeo?
Adems, deben probarse reas de dat os globales que se empl ean para t
informacin como parte de un procesamiento de interrupciones, con el fin ce
luar la posibilidad de generacin de efectos colaterales.
1 4 . 1 1 PATRONES PE PRUEBA
En captulos anteriores se analiz el uso de pat rones como mecani smo para
bir los bloques de construccin del software o situaciones de ingeniera del
Estos bloques de construccin o situaciones se repiten a medida que se co"
diferentes aplicaciones o que se realizan diferentes proyectos. Como sus c*
t es en el anlisis y el diseo, los patrones de prueba describen bloques de c
cin o situaciones frecuentes y que los responsables de probar el software
reutilizar al afrontar la prueba de algn sistema nuevo o revisado.
Los patrones de prueba no slo proporcionan a los ingenieros del software
directriz til cuando empiezan las actividades de prueba, tambin pr opor c i -
beneficios adicionales descritos por Marick [MAR02]:
1. Proporcionan una terminologa a los encargados de la resolucin de los problen^s|
"Hey, sabes?, debemos usar un Objeto Nulo."
2. Concentran la atencin en las fuerzas que se encuentran detrs del problema. Esc
mite a los diseadores |de casos de prueba] comprender mejor cundo se aplic
solucin, y por qu.
3. Estimulan el razonamiento iterativo. Cada solucin crea un nuevo contexto para
ver nuevos problemas.
Apuntodores ms de
70 pollones de prueba
se encontran en
wwwj-bsc.com.
\
CLAV E
l o s p o d o n e s de pr ue bo
ay udan o un e q u i p o d e
s o f t wa r e a
c o mu n i c a r s e me j o r
s o b r e l a p r u e b a y
tambin a c o mp r e n d e r
me j o r te f u e r z a s q u e
l e w n o un e n f o q u e
e p e c o d e p r u e b a .
TM
PDF Editor
/
Aunque estos beneficios sean "leves", no deben perderse de vista. Buena parte de la
prueba del software, incluso durante las ltimas dcadas, ha sido una actividad ad
. efcien- ftoc gj | QS p a t r o n e s prueba ayudan a un equipo de soft ware a comunicarse de
manera ms efectiva, a comprender las fuerzas motivadoras que llevan a un enfo-
encontroii) que especfico de prueba y a considerar el diseo de los casos de prueba como una
.ogts.com/ actividad en evolucin, se habr logrado mucho.
y Los patrones de prueba se describen de manera muy parecida a los de anlisis y
/ diseo (captulos 7 y 9). Se han propuesto docenas de pat rones de prueba (por ejem-
plo, [B1N99], [MAR02]). Los siguientes tres pat rones (presentados en forma resumi-
da), proporcionan ejemplos representativos:
N ombre del patrn: t es t i go par
Resumen: Patrn ori ent ado a procesos, t es t i go par describe una tcnica anl oga a la pro-
gramaci n par (captulo 4), en la cual dos responsabl es de una pr uebas t rabaj an de mane-
ra conj unt a para di sear y ej ecut ar una serie de pr uebas aplicables a actividades de prueba
de unidad, integracin o validacin.
N ombre del patrn: i nterf az de prueba s eparada
Resumen. En si st emas ori ent ados a obj et os es necesari o probar cada clase, incluidas las
"clases internas" (es decir, las cl ases que no exponen ni nguna interfaz fuera del compo-
nent e que las utiliza). El pat rn i nterf az de prueba s eparada describe la maner a de
crear "una interfaz de prueba que permita describir pr uebas especficas en cl ases que s-
lo son visibles i nt ernament e para un component e" [LANOI].
N ombre del patrn: prueba de e s ce nar i o
Resumen: Una vez que se ha apl i cado una prueba de uni dad o de integracin es necesa-
rio det ermi nar si el soft ware se comport ar de maner a tal que satisfaga al usuario. El pa-
trn prueba de e s c e nar i o descri be una tcnica par a ejercitar el soft ware desde el punt o
de vista del usuario. Una falla en est e nivel indica que el soft ware no sat i sface los requisi-
t os de un usuari o visible [KAN01].
Un anlisis completo de los pat rones de prueba est ms all del alcance de este li-
bro. El lector interesado debe consultar [BIN99] y [MAR02] para conocer mayor in
formacin sobre este importante tema.
1 4 . 1 2 RESUMEN
El objetivo principal del diseo de casos de prueba consiste en derivar un conj unt o
de pruebas que tenga la mayor probabilidad de descubrir errores en el software. Al-
canzar este objetivo requiere empl ear dos categoras diferentes de tcnicas de dise-
o de casos de prueba (aplicables a sistemas convencionales y orientados a objetos):
las pruebas de caj a negra y de caja blanca.
Las pruebas de caj a blanca se concent ran en la estructura de control del progra-
ma. Los casos de prueba se derivan para asegurar que t odas las instrucciones del
programa se ejecuten por lo menos una vez durante la prueba, y que t odas las con-
diciones lgicas se ejerciten. La prueba de la ruta bsica, una tcnica de caja blan-
TM
PDF Editor
ca, aprovecha las grficas de! programa (o matrices de grficas) para derivar un
junto de pruebas linealmente independientes que aseguren una cobertura. La
ba de condicin y de flujo de datos ejercitan an ms la lgica del programa
prueba de bucle compl ement a ot ras tcnicas de caja bl anca al proporcionar un
cedimiento para ejercitar bucles con grados diversos de complejidad.
Las pruebas de caja negra estn di seadas para validar requisitos funcionales
importar el funcionamiento interno de un programa. Estas tcnicas de prueba
concent ran en el dominio de la informacin del software, derivando casos de
ba medi ant e particin de los dominios de entrada y salida de un programa en
tal que proporcione cobertura completa. La particin equivalente divide el d
de entrada en clases de datos que probabl emente ejercitarn una funcin es
del software. El anlisis de valores lmite prueba la capacidad del programa para
nejar datos en los lmites de aceptabilidad. La prueba de tabla ortogonal prc
na un mt odo eficiente y sistemtico de probar sistemas con nmeros peque^
parmet ros de entrada.
Aunque el objetivo general de la prueba orientada a objetos (encontrar el
ro mximo de errores con una cantidad mnima de esfuerzo) es idntico al
prueba del soft ware convencional, la tctica para la prueba orientada a objet
fieren un poco. El concepto de prueba se ensancha para incluir la revisin
dlo de anlisis y diseo. Adems, el eje de la prueba se desplaza del comp
procedimental (el mdulo) hacia la clase. El diseo de pruebas para una clase
diversos mtodos: prueba basada en fallas, aleatoria y de particin. Cada uno
tos mt odos ejercita las operaciones encapsul adas por la clase. Las secue-
prueba estn di seadas para asegurar que se ejerciten operaciones relevar,"
examina el est ado de la clase, representado por los valores de sus atributos,
terminar si existen errores.
La prueba de integracin se realiza medi ant e una estrategia basada en el
te tipo de prueba construye el sistema en capas, empezando con las clases
usan clase de servidor. Los mt odos de diseo de casos de prueba de int"
tambin pueden empl ear pruebas aleatorias y de particin. Adems, se utilizar
bas basadas en el escenario y derivadas de modelos de comportamiento para
una clase y sus colaboradores. Una secuencia de prueba da seguimiento al
las operaciones entre las colaboraciones de clases.
Los mt odos de prueba especializados abarcan una amplia serie de opc
software y reas de aplicacin. La prueba para interfaces grficas de usuario,
quitecturas cliente/servidor, de la document aci n y funciones de ayuda y de
mas en tiempo real requieren directrices y tcnicas especializadas.
Los desarrolladores de soft ware con experiencia suelen decir: "La prueba
termina, slo se transfiere del ingeniero del soft ware al cliente. Cada vez
usa el programa, est realizando una prueba". Al aplicar el diseo de casos i
ba, el ingeniero de soft ware logra pruebas ms compl etas y, por tanto, d
corrige el mayor nmero de errores ant es de que empiecen las "pruebas del
TM
PDF Editor
CAPTULO 14 TCNI CAS DE PRUEBA DEL SOFTWARE 4 5 9
[AMB95] Ambl er, S., "Using Use Cases", en Software Development, julio de 1995, pp. 53-61.
[BE1901 Beizer, B., Software Testing Techniques, s egunda edicin, Van Nost rand-Rci nhol d, 1990.
[BE195] Beizer, B., Black-Box Testing, Wiley, 1995.
[B1N94] Binder, R. V., "Testing Obj ect -Ori ent ed Syst ems: A St at us Report", en American Program-
mer; vol. 7, nm. 4, abril de 1994, pp. 23-28.
[B1N99] Binder, R., Testing Object-Oriented Systems: Models, Patterns, and Tools, Addison-Wesley,
1999.
[DEU79] Deut sch, M "Verification a nd Validation", en Software Engineering (R. Jensen y C. To-
nies, e ds ) , Prentice-Hall, 1979, pp. 329-408.
[FRA88] Frankl, P. G. y E. J. Weyuker, "An Applicable Family of Dat a Flow Testing Criteria", en
IEEE Trans. Software Engineering, vol. SE-14, nm. 10, oct ubre de 1988, pp. 1483-1498.
(FRA93] Frankl, P. G. y S. Weiss, "An Experi ment al Compar i son of t he Effect i veness of Branch
Testing and Dat a Flow", en IEEE Trans. Software Engineering, vol. SE-19, nm. 8, agost o de
1993, pp. 770-787.
[KAN93] Kaner, C., J. Falk y H. Q. Nguyen, Testing Computer Software, segunda edi ci n, Van Nos-
t rand-Rei nhol d, 1993.
[KANOi] Kaner, C "Pattern: Scenar i o Testing" (borrador), 2001, di sponi bl e en ht t p: / / www. t es -
t i ng. com/ t est - pat t ems/ pat t er ns/ pat t em- scenar i o- t est i ng- kaner . ht ml .
[K1R94] Kirani, S. y W. T. Tsai, "Specification and Verification of Obj ect -Ori ent ed Programs",
Technical Report TR 94-64, Comput er Sci ence Depar t ment , University of Mi nnesot a, di ci em-
bre de 1994.
[LAN0II Lange, M., "It's Testing Ti me! Pat t erns for Testing Soft ware", junio de 2001, di sponi bl e
par a descar ga en ht t p: / / www. t es t i ng. com/ t es t - pat t er ns / pat t er ns / i ndex. ht ml .
[L1N94] Lindland, O. I. e al., "Underst andi ng Quality in Concept ual Modeling", en IEEE Software,
vol. 11, nm. 4, julio de 1994, pp. 42-49.
[MAR941 Marick, B., The Craft of Software Testing, Prentice-Hall, 1994.
[MAR02] Marick, B., "Soft ware Testing Patterns", 2002, ht t p: / / www. t es t i ng. com/ t es t - pat t ems /
i ndex. ht ml .
[MCC76] McCabe, T., "A Sof t war e Complexity Measure", en IEEE Trans. Software Engineering, vol.
SE-2, di ci embre de 1976, pp. 308-320.
[MGR94] McGregor, J. D. y T. D. Korson, "Integrated Obj ect -Ori ent ed Testing and Devel opment
Processes", CACM, vol. 37, nm. 9, sept i embr e de 1994, pp. 59-77.
[MUS93] Mu s a , " Op e r a t i o n a l Profiles in Sof t war e Reliability Engineering", en IEEE Software,
ma r z o de 1993, pp. 14-32.
[MYE79J Myers, G., The Art of Software Testing, Wiley, 1979-
[NTA88] Nt afos, S. C., "A Compar i son of Some St ruct ural Testing Strategies", en IEEE Trans. Soft-
ware Engineering, vol. SE-14, nm. 6, junio de 1988, pp. 868-874.
[PHA89] Phadke, M. S., Quality Engineering Using Robust Design, Prentice-Hall, 1989.
[PHA97] Phadke, M. S., "Pl anni ng Efficient Soft ware Tests", Crosstalk, vol. 10, nm. 10, oct ubre
de 1997, pp. 11-15.
[TA1891 Tai, K. C., "What to Do Beyond Branch Te s t i n g ACM Software Engineering Notes, vol. 14,
nm. 2, abri l de 1989, pp. 58-61.
14. 1. Myers [MYE79] aplica el si gui ent e pr ogr ama c omo aut oeval uaci n de la capaci dad pr o-
pia para especi fi car pr uebas adecuadas: un pr ogr ama lee t res val ores ent eros. Los t res val or es
se i nt erpret an como si r epr esent ar an l as l ongi t udes de los l ados de un tringulo. El pr ogr ama
i mpri me un mens aj e que indica si el t ri ngul o es escal eno, i sscel es o equi l t ero. Desarrl l ese
un conj unt o de cas os de pr ueba que se consi dere que pr ueben adecuadament e est e pr ogr ama.
1 4 . 2 . Di sear e i mpl ement ar el pr ogr ama (con ma ne j o de er r or es cuando sea apropi ado) espe-
cificado en el pr obl ema 14.1. Derivar una grfi ca de flujo par a el pr ogr ama y apl i car la pr ueba
de la rut a bsi ca par a desarrol l ar casos de pr ueba que garant i cen que se han pr obado t odas l as
i nst rucci ones del pr ogr ama. Ej ecut ar l os cas os y most r ar los resul t ados.
TM
PDF Editor
460
PARTE DOS PRCTI CA DE LA INGENIERA DEL SOFTWARE
14. 3. Al lector le es posi bl e pens ar en al guna pr ueba adi ci onal de caract er st i cas que r.
anal i zar on en la secci n 14.7?
14. 4. Sel ecci onar un component e de sof t war e que el l ect or haya di seado e i mpl ement adc
ci ent ement e. Di sear un conj unt o de cas os de pr ueba que asegur en que t odas l as instrucc
se hayan ej ecut ado con la pr ueba de la rut a bsi ca.
14. 5. Especificar, di sear e i mpl ement ar una her r ami ent a de sof t war e que cal cul e la cor
dad ci cl omt i ca par a el l enguaj e de pr ogr amaci n que se elija. Aplicar la mat ri z de grfica
mo est ruct ura operat i va de dat os en el di seo.
14. 6. Lase Beizer [BE195] y det er m nese la maner a e n que el pr ogr ama que se desarro,
el pr obl ema 14.5 puede ext ender se par a acomodar var i os pesos de enl ace. Ext i ndase la 1
mi ent a par a pr ocesar probabi l i dades de ej ecuci n o t i empos de pr oces ami ent o de enl aces
14. 7. Di sese una her r ami ent a aut omat i zada que r econozca bucl es y los or dene en ca
ras, como se i ndi ca en la secci n 14.5.3.
14. 8. Ext i ndase la her r ami ent a descri t a en el pr obl ema 14.7 par a gener ar casos de pr ue r s :
ra cada cat egor a de bucle, una vez encont r ada. Ser necesar i o desarrol l ar est a funci n de i
er a i nt eract i va con el encar gado de la pr ueba.
14. 9. Of r zcanse por lo me n o s t res ej empl os en que la pr ueba de caj a negr a dari a la in
de que "todo est bien", mi ent r as que l as pr uebas de caj a bl anca descubri r an un error
por lo me n o s t res ej empl os en que suceda lo cont rari o: la pr ueba de caj a bl anca dar a la i
sin de que "todo est bien", mi ent r as que l as pr uebas de caj a negr a descubri r an un errcr
14. 10. La pr ueba exhaust i va (en cas o de que sea posi bl e e n pr ogr amas muy pequeos]
tiza que el pr ogr ama es t ot al ment e correct o?
14. 11. En pal abr as propi as, descr base por qu la cl ase es la menor uni dad r azonabl e
pr ueba dent r o de un si st ema or i ent ado a obj et os.
14. 12. Por qu se t i enen que volver a pr obar subcl ases que cr ean i nst anci as a partir
cl ase exi st ent e si st a ya se ha pr obado por compl et o? Es posi bl e usar l os cas os de pn
s eados par a la cl ase exi st ent e?
14. 13. Apl i qense pr uebas al eat ori as y de part i ci n a t res cl ases defi ni das e n el di seo
t ema HogarSeguro. Pr odzcanse casos de pr ueba que i ndi quen las secuenci as de opera
se i nvocarn.
14. 14. Apl i qense pr uebas de cl ase mltiple y pr ubense deri vados del model o de
mi ent o para el di seo HogarSeguro.
14. 15. Prubese un manual de usuar i o (o una nci n de ayuda) de una apl i caci n que i
con frecuenci a. Encunt r ese por lo me nos un error e n la document aci n.
Ent re docenas de libros que pr esent an mt odos de di seo de cas os de pr ueba se
Craig y Kaskiel (Systematic Software Testing, Artech House, 2002), Tamr es (Introducing :
Testing, Addison-Wesley, 2002), Whi t t aker (How to Break Software, Addison-Wesley,
gensen ( Sof t ware Testing: A Craftman's Approach, CRC Press, 2002), Spl ai ne y s us co
Web Testing Handbook, Soft ware Quality Engi neeri ng Publishing, 2001), Pat t on (So/fw
Sa ms Publishing, 2000), Kaner y s us col egas (Testing Computer Software, segunda i
ley, 1999). Adems, Hut cheson (Sof t ware Testing Methods and Metrics: The Most Imp
McGraw-Hll, 1997) y Marick (The Craft of Software Testing: Subsyslem Testing Includirj I
Based and Object-Oriented Testing. Prentice-Hall, 1995) pr esent an t r at ami ent os de m
t rat egi as de pr ueba.
Myers [MYE79] sigue si endo un t ext o clsico, que anal i za l as t cni cas de caj a negra
det al l e. Beizer [BE 190] pr opor ci ona una ampl i a cobert ura de l as t cni cas de caj a bla
TM
PDF Editor
CAPTULO 14 TCNI CAS DE PRUEBA DEL SOFTWARE 461
duce un nivel de rigor mat emt i co que a me nudo se omi t e en ot r os t r at ami ent os de pr uebas. Su
ltimo libro [BEI95] pr esent a un t r at ami ent o conci so de mt odos i mport ant es. Perry (EJfective
Methods for Software Testing, Wiley-QED, 1995) y Fri edman y Voas (Software Assessment: Reliabi-
liy Safety, Testabitity, Wiley, 1995) pr esent an buenas i nt roducci ones a las est r at egi as y t ct i cas
de pr ueba. Mosley (The Handbook of MIS Application Software Testing, Prentice-Hall, 1993) a na -
liza t emas de pr ueba para s i s t emas de i nformaci n grandes, y Marks (Testing Vety Big Systems,
McGraw-Hill, 1992) anal i za los aspect os especi al es que deben t omar s e en cuent a cuando se
pr ueban s i s t emas de pr ogr amaci n i mport ant es.
Sykes y McGregor (Practica! Guide for Testing Object Oriented Software, Addison-Wesley,
2001), Bashir y Goel (Testing Object-Oriented Software, Springer-Verlag. 2000), Bi nder (Testing
Object-Oriented Systems, Addison-Wesley, 1999), Kung y s us col egas (Testing Object-Oriented
Software, IEEE Comput er Soci et y Press. 1998), Marick (The Craft ofSofhvare Testing, Prent i ce-
Hall, 1997) y Siegel y Muller (Object-Oriented Software Testing: A Hicrarchical Approach, wiley,
1996) pr esent an est r at egi as y mt odos para probar si st emas or i ent ados a obj et os.
La pr ueba del sof t war e e s una actividad que ocupa muchos recursos. Por ello, muc ha s orga-
ni zaci ones aut omat i zan par t es del pr oceso de pr ueba. Libros de Dustin, Rashka y Post on (Auto-
mated Software Testing: Introduction, Management, and Performance, Addison-Wesley, 1999),
Gr aham y s us col egas (Software Test Automation, Addison-Wesley, 1999), y Post on (Automating
Specification-Based Software Testing, IEEE Comput er Society, 1996) anal i zan her r ami ent as, est r a-
t egi as y mt odos par a pr uebas aut omat i zadas.
Varios libros consi der an los mt odos y l as est r at egi as de pr ueba en r eas de apl i caci n es-
peci al i zadas. Gardi ner (Testing Safety-Related Software: A PracticaI Handbook, Springer-Verlag,
1999) ha edi t ado un libro que aborda la pr ueba de si st emas de seguri dad crtica. Mosley (Client/
Server Software Testing on the Desk Top and the Web, Prentice-Hall, 1999) anal i za el pr oceso de
pr ueba par a cl i ent es, servi dores y component es de red. Rubin (Handbook of Usability Testing, Wi-
ley, 1994) ha escri t o una gu a til para qui enes deben ejercitar i nt er f aces humanas .
Binder IBIN991 describe casi 70 pat r ones de pr ueba que cubren mt odos de prueba, cl ases/
grupos, subsi st emas, component es reutilizables, mar cos concept ual es y si st emas, a de m s de
aut omat i zaci n de pr uebas y pr ueba de base de dat os especi al i zada. Una lista de es t os pat ro-
nes se encont r ar en www. r bsc. com/ pages/ Test Pat t er nLi st . ht m.
Una ampl i a vari edad de f uent es de i nformaci n sobr e los mt odos de di seo de casos de
pr ueba est di sponi bl e en Internet. Una lista act ual i zada de referenci as en la World Wide Web
que t i enen rel evanci a par a l as t cni cas de pr ueba se encuent r a en el sitio Web SEPA:
TM
PDF Editor
C A P I T U L O
1 5
CONCEPTOS
CLAVE
c a lid a d 4 6 4
f a c t o r e s
d e McCall 4 6 4
i n d i c a d o r e s . . . . 4 6 7
m e d i c i n . . . . . . 4 7 1
a t r i b u t o s . . . . 4 7 1
p rin cip ios 4 6 9
m e d i d a s 4 6 7
de c d i g o 4 9 3
d e m a n t e -
n im ie n to 4 9 6
d e m o d e l o
d e a n l i s i s . . 4 7 4
d e m o d e l o
d e d i s e o . . . 4 7 9
o r i e n t a d a s
a o b j e t o s . . . 4 8 1
prueba d e . . . . 4 9 4
paradigm a
OPM 4 7 0
p u n t o s
d e funcin . . . . 4 7 4
MTRI CAS DEL PRODUCTO
PARA EL SOFTWARE
L
a medicin es un el ement o clave en cualquier proceso de ingeniera
medi das se empl ean para compr ender mej or los atributos de los mocfc
que se crean y eval uar la calidad de los product os de la ingeniera o de
si st emas que se const ruyen. Pero a diferencia de ot r as disciplinas de la inge-
ra, la del sof t war e n o se basa en las leyes cuant i t at i vas bsi cas de la fsica
medi das directas, como el voltaje, la masa, la velocidad o la t emperat ura r.
comunes en el mundo del soft ware. Debido a que las medi das y mtricas
soft ware suel en ser indirectas est n expuest as al debat e. Fenton [FEN91] a :
est e t ema cuando afirma:
La medi ci n e s el pr oceso medi ant e el cual se asi gnan nmer os o s mbol os a los c ^
but os de ent i dades real es para definirlas de acuer do con regl as cl ar ament e est abl e: i
das. . . En l as ci enci as fsicas, la medi ci na y, m s r eci ent ement e, l as ci enci as s o d a es
ahor a podemos medi r at ri but os que se consi der aban i mposi bl es de medi r. . Por s -
puest o, es t as medi ci ones no t i enen el mi s mo r ef i nami ent o que casi t odas l as de -
ci enci as fsicas. . . per o exi st en [y muchas deci si ones i mpor t ant es se t oman con
en ellas]. Sent i mos que l a obl i gaci n de t rat ar de "medir lo i nmedi bl e" para me; ; -
nuest r a compr ensi n de ent i dades part i cul ares es t an i mpor t ant e e n la ingeniera i
sof t war e como en cual qui er ot ra disciplina.
Pero al gunos mi embr os de la comuni dad de soft ware siguen ar gument anc i
el sof t war e "es inmedible", o que deben posponerse los i nt ent os de medir! I
ta que se compr enda mej or el propio sof t war e y los at ri but os que deben ut -
se para describirlo. Esto es un error.
Qu e s ? Por su naturaleza, la in-
geniera es una disciplina cuantitati-
va. Los ingenieros usan nmeros co-
mo apoyo para el diseo y la evalua-
cin del producto que construirn.
Hasta hace poco, los ingenieros de software con-
taban con escasas guas cuantitativas en su tra-
bajo, pero eso est cambiando. Las mtricas del
producto los ayudan a conocer mejor el diseo y
la construccin del software que elaboran. A di-
ferencia de las mtricas del proceso y el proyec-
to que se aplican al proyecto (o ai proceso) co-
mo un todo, las mtricas del producto se corar- 4
tran en atributos especficos de los productes ti
trabajo de la ingeniera del software y se r e: : : M
lan a medida que se realizan las tareas tc- :
(anlisis, diseo, codificacin y prueba).
Qui n l o h a c e ? Los ingenieros de software r H
las mtricas del producto como apoyo : H
construir software de mayor calidad.
Por q u es i mp o r t a n t e ? Siempre inte
drn elementos cualitativos en la creaci-
software. El problema es que no basta a:"
evaluacin cualitativa. Un ingeniero de soi
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO P ARA EL SOFTWARE
4 63
-ecesita criterios objetivos para orientar el dise-
io de los datos, la arquitectura, las interfaces y
tos componentes. El responsable de la prueba
equiere una gua cuantitativa que le ayude a
aleccionar los casos de prueba y sus objetivos.
-Qs mtricas del producto proporcionar, una ba-
e para que el anlisis, el diseo, la codificacin
' la prueba se realicen con mayor objetividad y
se evalen de manera ms cuantitativa.
C j l es son l os p a s os ? El primer paso del
oroceso de medicin consiste en derivar, a par-
r del software, las medidas y mtricas apropia-
aas para la representacin del software que se
est considerando. A continuacin se renen los
datos para derivar las mtricas formuladas. Una
'ez calculadas, se analizan las mtricas apro-
piadas con base en directrices preestablecidas y
en datos anteriores. Los resultados del anlisis se
interpretan para conocer ms acerca dejj la cali-
dad del software; los resultados desembocan en
la modificacin de los modelos de anlisis y di-
seo, de cdigo fuente o los casos de prueba. En
algunos casos, tal vez se llegue a la modifica-
cin del propio proceso del software.
Cul es el pr oduct o obt eni do? Las mtricas
del producto que se calculan a partir de tos da-
tos recopilados de los modelos de anlisis y di
seo, de cdigo fuente y casos de prueba.
Cmo p u e d o es t ar s egur o d e q u e lo he
hecho cor r ect ament e? Deben determinarse
los objetivos de b medicin antes de iniciar lo
recopilacin de datos, definiendo cada mtrica del
producto sin ambigedades. Defnanse unas
cuantas mtricas y luego utilcense para recono-
cer la calidad de un producto de trabajo de la in-
geniera del software.
Aunque las mtricas del producto para el software de computadora no suelen ser
absolutas, proporcionan una manera sistemtica de evaluar la calidad a partir de un
conjunto de reglas definidas con claridad. Tambin proporcionan al ingeniero de
software informacin inmediata y en el sitio; no posterior al hecho. Esto permite al
ingeniero descubrir y corregir problemas potenciales antes de que se conviertan en
defectos catastrficos.
En este captulo se analizarn las mediciones con que se evala la calidad del pro-
ducto mientras se disea o construye. Estas medidas de atributos internos del produc-
to proporcionan al ingeniero de software una indicacin en tiempo real de la efica-
cia de los modelos de anlisis, diseo y cdigo; tambin aportan indicativos de la
efectividad de los casos de prueba y la calidad general del software que habr de cons-
truirse.
1 5 . 1 CALI DAD g e n e r a l _ _ _ _ _ . . . .
Hasta los desabolladores de software exhaustos estn de acuerdo en que es impor-
tante crear software de alta calidad. Pero, cmo se define la calidad? En el sentido
ms amplio, calidad del software es el cumplimiento de los requisitos de funcionalidad
y desempeo explcitamente establecidos, de los estndares de desarrollo explcitamen-
te documentados y de las caractersticas implcitas que se esperan de todo software de-
sarrollado profesionalmente.
Es indudable que esta definicin podra modificarse o extenderse y debatirse in-
terminablemente. En cuanto a los objetivos de este libro, la definicin sirve para des-
tacar tres puntos importantes:
TM
PDF Editor
1. Los requisitos del soft ware son la base de las medidas de calidad. La falta J I
concordancia con estos requisitos es una falta de calidad.'
2 - Los est ndares especificados definen un conj unt o de criterios de desarrol !
que guan la ingeniera dei software. Si no se siguen los criterios, el r esul t aar !
ser, casi seguramente, la falta de calidad.
3 - A menudo se soslaya un conjunto de requisitos implcitos (por ejemplo, e
seo de alcanzar la facilidad de uso). Si el soft ware cumple con sus requisr ~ I
explcitos pero no con los implcitos, la calidad del soft ware estar en duc_. I
La calidad del software es una compleja combinacin de factores que variarn - * J
diferentes aplicaciones y los distintos clientes que las solicitan. En las siguientes s a i
ciones se identifican los factores que afectan la calidad del soft ware y se des cr i oa
las actividades humanas que deben desarrollarse para alcanzarla.
15.1.1 Factores de calidad de McCall
Los factores que afectan la calidad del software se dividen en dos grandes grup i l
los que se miden directamente (por ejemplo, defectos descubiertos durante la
ba), y 2) los que slo se miden indirectamente (por ejemplo, facilidad de uso >
mantenimiento). En cada caso debe present arse una medicin. Se debe c ompa r ^ H
soft ware (programa, datos, documentos) con algn conjunto de dat os y o b t e n s H
algn indicio sobre la calidad.
McCall, Richards y Walters [MCC77] propusieron una clasificacin til de los fl
tores que afectan la calidad del software. Estos factores, que se muest ran en la
ra 15.1, se concentran en tres aspectos importantes de un producto de software
caractersticas operativas, su capacidad para experimentar cambi os y su capa
para adaptarse a nuevos entornos.
Si se t oman como referencia los factores indicados en la figura 15.1, McCall
colegas proporcionan las siguientes descripciones:
Correccin Facilidad de uso Eficiencia
Confiabilidad Integridad
1 Es importante indicar que la calidad se extiende a las caractersticas tcnicas de los modelos
lisis y diseo, as como a la realizacin del cdigo fuente de stos. Modelos de alta calida;
sentido tcnico) darn lugar a software de alta calidad, desde el punt o de vista del cliente
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO P ARA EL SOFTWARE 4 65
KVE
observar
i ioctores de
i McCall son
s hoy como
i en lo dcada
Por tanto, es
afirmar que
s que
: calidad del
s no cambian
i wn p o .
Correccin. El gr a do en q u e el p r ogr a ma c umpl e con s u especi f i caci n y s at i s f ace l os ob-
j et i vos que p r op us o el cl i ent e.
Conflabilidad. El gr a do en que s e es per ar a que un pr ogr a ma d e s e mp e e su f unci n con la
pr eci si n r equer i da. [Debe obs er var s e que s e ha n pr opue s t o ot r a s def i ni ci ones de cont i a-
bi l i dad m s c ompl e t a s ( consl t ese el cap t ul o 26)].
Eficiencia. La cant i dad de cdi go y de r ecur s os de c mput o ne c e s a r i os par a q u e un pr ogr a-
ma real i ce s u f unci n.
Integridad. El gr ado de cont r ol s obr e el acces o al s of t wa r e o l os dat os por par t e de l as per -
s ona s n o aut or i zadas .
Facilidad de uso. El e s f ue r z o neces ar i o par a apr ender , oper ar y pr e pa r a r l os dat os de e n-
t r ada de un pr ogr ama e i nt er pr et ar la sal i da.
Facilidad de mantenimiento. El e s f ue r z o neces ar i o par a l ocal i zar y cor r egi r un er r or en un
pr ogr ama. (Una def i ni ci n muy l i mi t ada. )
Flexibilidad. El e s f ue r z o neces ar i o pa r a modi f i car un pr ogr a ma en oper aci n.
Facilidad de prueba. El e s f ue r z o q u e d e ma n d a pr obar un pr ogr a ma c on el fin de a s e gur a r
q u e r eal i za su f unci n.
Portabilidad. El e s f ue r z o neces ar i o par a t r ansf er i r el pr ogr a ma de un e nt or no de ha r d wa -
re o s of t wa r e a ot ro.
Facilidad de reutilizacin. El gr a do en que un pr ogr a ma (o par t es de l) pue de r eut i l i zar se
en ot r a s apl i caci ones (en r el aci n con el e mp a q ue t a mi e nt o y el al cance de l as f unci ones
q u e r eal i za el pr ogr ama) .
Interoperabilidad. El e s f ue r z o neces ar i o par a acopl ar un si st ema con ot r o.
[CONSEJO.
? uno listo
r de verificacin
) estos
5. Primero
i o codo uno
t mportoncia
pora su
L uego
i una grodua-
i poro sus
s de trabajo
i el fin de evaluar
t dad del software
f se est constru-
y a calidad de un producto es una funcin del bien que hace ol mundo. "
Totn D e M a r c o
Es difcil, y en al gunos casos imposible, desarrollar medi das directas7 de est os fac-
t ores de la calidad. En realidad, muchas de las mt ri cas que defi nen McCall et al. s-
lo se mi den subj et i vament e. Es comn que las mt ri cas adqui eran la forma de una
lista de comprobaci n que se empl ea para "asi gnar una graduaci n" a at ri but os es-
pecficos del sof t war e [CAV78],
15.1.2 Factores de calidad del estndar ISO 9126
El est ndar ISO 9126 se desarroll como un intento por identificar los at ri but os de
calidad para el soft ware de comput adora. El est ndar identifica seis at ri but os clave
de la calidad:
2 Una medida directa indica que sl o e s posible cont ar un valor que proporciona una indicacin di-
recta del atributo que se exami na. Por ejemplo, el "t amao" de un programa se mi de di rect ament e
al cont ar el nmer o de lneas de cdi go
TM
PDF Editor
466
Funcionalidad. El grado en que el sof t war e sat i sface las necesi dades que in
los si gui ent es subat ri but os: idoneidad, exactitud, interoperabilidad, cumpl i mi er: <
seguridad.
Contabilidad. La cant i dad de t i empo en que el sof t war e est disponible para
lo segn los si gui ent es subat ri but os: madur ez, tolerancia a fallas y facilidad de
peracin.
Facilidad de uso. La facilidad con que se usa el soft ware de acuer do con te
gui ent es subatributos: facilidad de comprensi n, facilidad de aprendi zaj e y o]
lidad.
Eficiencia. El grado en que el soft ware empl ea en forma ptima los recursos a
sistema, como lo indican los si gui ent es subatributos: compor t ami ent o en el ti
compor t ami ent o de los recursos.
Facilidad de mantenimiento. La facilidad con que s e repara el soft ware de a
con los si gui ent es subat ri but os: facilidad de anlisis, facilidad de cambi o, est a
y facilidad de prueba.
Portabilidad. La facilidad con que se lleva el sof t war e de un ent or no a otro
los si gui ent es subatributos: adaptabilidad, facilidad para instalarse, cumpli
facilidad para reempl azarse.
Al igual que otros fact ores de calidad del soft ware anal i zados en el captulo 9 *
seccin 15.1.1, los fact ores ISO 9126 no necesar i ament e se pr est an a la medicic - d
recta. Sin embargo, proporci onan una base valiosa para las medi das indirectas \
lista de verificacin excel ent e para eval uar la calidad de un si st ema.
"Cualquier actividad se vuelve aeot i va cuando la persona que hace las cosos los hoce bien, o mej or. "
Jo h n
I
rJ
15.1.3 La transicin a un concepto cuantitativo
En las secci ones ant eri ores se anal i z un conj unt o de fact ores cualitativos
"medicin" de la calidad del soft ware. El esfuerzo por desarrollar medi das p
de la calidad del sof t war e en ocasi ones se frustra por la nat ural eza subjetiva
actividad. Cavano y McCall [CAV78] anal i zan est a situacin:
La det er mi naci n de la calidad es un fact or clave en t odas l as act i vi dades di ari as ( c o n a r - 1
sos de cat a de vi nos, compet enci as deport i vas [como la gi mnasi a), concur s os de t al e- : fl
etc.). En es t as si t uaci ones la calidad se j uzga de la ma ne r a m s bsi ca y directa: cor r : r 1
r ando obj et os que se encuent r an j unt os e n condi ci ones i dnt i cas y con concept os p r e j t I
t er mi nados. El vi no se j uzga de acuer do con su claridad, color, bouquet , sabor, etc. S e
embar go, est e t i po de juicios es muy subj et i vo; par a que t enga al gn val or debe haceii-:
un expert o.
La subj et i vi dad y la especi al i zaci n t ambi n se apl i can par a det er mi nar la calidad J*'
soft ware. Se necesi t a una defi ni ci n m s preci sa de la cal i dad del s of t war e par a resc a
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO P ARA EL SOFTWARE 467
est e pr obl ema, a de m s de un medi o par a deri var medi das cuant i t at i vas, a partir de la ca-
lidad del sof t war e, para real i zar un anl i si s obj et i vo. . .
En las secci ones siguientes se exami na un conj unt o de mt ri cas que se aplican en
la eval uaci n cuantitativa de la calidad del soft ware. En t odos los casos las mt ri cas
represent an medi das indirectas; es decir, nunca se mi de r eal ment e la calidad, si no
al guna mani fest aci n de st a. El factor que complica las cosas es la relacin precisa
ent re la variable que se mide y la calidad del soft ware.
"As como la medicin de la t emperat ura empi eza con un dedo ndi ce. . . y da lugar a escalas, herrami ent as y tcnicas
sofisticadas, asi sucede t ambi n con la madur ez en la medicin del soft ware. "
Shan Pfieeger
1 5 . 2 UN MARCO CONCEPTUAL PARA LAS MTRICAS DEL PRODUCTO
Como se indic en la introduccin de est e captulo, la medicin asi gna nmer os o
s mbol os a at ri but os de ent i dades reales. Esto requiere un model o de medicin que
abar que un conj unt o consi st ent e de reglas. Aunque la teora de la medicin (por
ejemplo, [KYB84)) y su aplicacin al sof t war e de comput ador a (por ejemplo,
[DEM81], [BR196], [ZUS97]) son t emas que rebasan el al cance de est e libro, vale la
pena establecer un marco conceptual y un conj unt o de principios bsicos para la me-
dicin de mt ri cas para el product o de soft ware.
15.2.1 Medidas, mtricas e indicadores
Aunque medida, medicin y mtrica son t rmi nos que suel en utilizarse de maner a in-
tercambiable, es i mport ant e observar las sutiles diferencias ent r e ellos. En el cont ex-
to de la ingeniera del sof t war e una medi da proporci ona una indicacin cuantitativa
de la extensin, la cantidad, la di mensi n, la capaci dad o el t amao de algn atribu-
to de un product o o proceso. Medicin es el act o de det ermi nar una medida. El Glo-
sario de estndares del IEEE [IEE93] define mtrica como una "medida cuantitativa del
grado en que un sistema, component e o proceso posee un atributo det ermi nado".
Cuando se ha recopilado un solo tipo de dat os (por ejemplo, el nmer o de errores
descubiertos dent ro de un solo component e del software) s e ha establecido una me-
dida. La medicin ocurre como resultado de la recopilacin de uno o m s punt os de
dat os (por ejemplo, se investigan varias revisiones de component es y pruebas de uni-
dad para reunir medi das del nmer o de errores encont rados en cada uno). Una mtri-
ca de soft ware relaciona de al guna manera las medi das individuales (por ejemplo, el
nmer o promedi o de errores encont r ados en cada revisin o prueba de unidad).
Un i ngeni ero de sof t war e recopila medi das y desarrolla mt ri cas para obt ener los
indicadores. Un indicador es una mt ri ca o una combi naci n de mt ri cas que pro-
porci onan conoci mi ent os acerca del proceso del soft ware, un proyect o de sof t war e
o el propio product o. Un indicador proporci ona conoci mi ent os que permi t en al jefe
TM
PDF Editor
468 PARTE DOS PRCTI CA DE LA INGENIERA DEL SOFTWARE
de proyect o o los i ngeni eros de sof t war e aj ust ar el proceso, el proyect o o el proc.c-1
to para que las cosas mej oren.
]
"Una t i endo tiene la misma madur ez que sus herrami ent as de me di c i n'
Luis P
Horst Zuseho
recopilado gran
cantidod de
informocin sobre
mtricas de producto
en irb.cs.tubeHin.
de/~iuse/.
15.2.2 El reto de las mtricas del producto
En las ltimas tres dcadas, muchos i nvest i gadores han t rat ado de desarrolla- J
sola mt ri ca que proporci one una medi da compl et a de la compl ej i dad del s o f h r a B
Fent on [FEN94] caract eri za est a investigacin como una bsqueda del "santc e n
imposible". Aunque se han propuest o docenas de medi das de complejidad [ Z l ' 5 V
cada una tiene un concept o diferente de la complejidad y de los atributos de un
ma que llevan a la complejidad. Por analoga, considrese una mtrica para e v a l ua r
automvil atractivo. Algunos observadores destacaran el diseo de la carrocena T
tomar an en cuent a caractersticas mecni cas y otros ms podran considerar e:
el desempeo, la econom a de combustible o la capacidad de reciclarlo cuandc
to sea inservible. Como cualquiera de est as caractersticas estara en desvent an
ot ras, resulta difcil derivar un solo valor de "atractivo". El mi smo problema
con el soft ware de comput ador a.
Pero existe la necesi dad de medi r y controlar la complejidad del soft ware a f l
difcil derivar un sol o valor de est a mt ri ca de calidad, debe t enerse la posibi
desarrollar medi das de di ferent es atributos i nt ernos del pr ogr ama (por ejempk: a l
dularidad efectiva, independencia funcional y otros atributos anal i zados del c a p MB
al 12). Estas medi das y las mt ri cas deri vadas de ellas se utilizan como indicac
dependi ent es de la calidad de los model os de anlisis y diseo. Pero aqu t amt
gen problemas. Fenton [FEN94] observa est o cuando afirma: "El peligro de t r s i ^ H
encont rar medi das que caractericen t ant os atributos diferentes es que inevitar
te las medi das tienen que satisfacer objetivos que ent ran en conflicto entre s
opone a la teora de que cada medicin debe ser representativa. " Aunque la
cin de Fenton es correcta, muchas personas argument an que la medicin del
realizada durant e las pri meras et apas del proceso del soft ware proporciona a 1
geni eros un mecani smo consi st ent e y objetivo para eval uar la calidad.
Sin embargo, vale la pena pregunt arse sobr e la validez de las mt ri cas 3
duct o. Es decir, qu t ant o concuer dan las mt ri cas del product o, la conf at
largo plazo y la calidad de un si st ema de cmput o? Fent on [FEN91] aborda t s H
quietud de la siguiente maner a:
A pesar de l as conexi ones intuitivas ent r e la est ruct ura i nt erna de l os pr oduct os de a
war e [mt ri cas del product o] y los at ri but os de su pr oduct o y su pr oceso ext er nos
lidad s e ha n r eal i zado muy pocos i nt ent os cientficos por est abl ecer rel aci ones e s pe c i ^ B
Esto es as por vari as r azones: la que se cita con m s f r ecuenci a es que resul t a pocc
tico real i zar exper i ment os rel evant es.
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO PARA EL SOFTWARE 469
i C s l e s s o n
' t e s p o s o s d e
i d e
i e f e t t i v o ?
*
Cada uno de los "retos" i ndi cados aqu debe t omar se con caut el a, pero no hay ra-
zn para restarle mri t os a las mt ri cas tcnicas. 3 La medicin es esencial si se de-
sea al canzar la calidad.
15.2.3 Principios de medicin
Antes de introducir una serie de mtricas del product o que 1) ayuden a eval uar los mo-
delos de anl i si s y di seo, 2) ofrezcan una indicacin de la complejidad de los dise-
os procedi ment al es y el cdi go fuent e, y 3) faciliten el di seo de pruebas ms efec-
tivas, es i mport ant e compr ender los principios bsi cos de la medicin. Roche
[ROC94] sugiere un proceso de medicin al que caract eri zan cinco actividades:
Formulacin. La derivacin de medi das y mt ri cas apr opi adas para la repre-
sent aci n del soft ware que se consi dera.
Recoleccin. El mecani smo con que se acumul an los dat os necesari os para
deri var las mt ri cas formul adas.
Anlisis. El clculo de las mtricas y la aplicacin de herrami ent as mat emt i cas.
Interpretacin. La eval uaci n de las mt ri cas en un esf uer zo por conocer me-
jor la calidad de la represent aci n.
Retroal mentacin. Recomendaci ones deri vadas de la interpretacin de las m-
tricas del product o t ransmi t i das al equi po del soft ware.
Las mt ri cas del soft ware sl o sern tiles si est n caract eri zadas de manera efectiva
y se validan para probar su valor. Los siguientes principios [LET03] son representati-
vos de muchos otros que podran proponerse para caracterizar y validar las mtricas:
Una mtrica debe tener propiedades matemticas deseables. Es decir, el valor de la
mtrica debe est ar en un rango significativo (por ejemplo, de cero a uno, donde
cero realmente significa ausencia, uno indica el valor mxi mo y 0.5 representa
el "punto medio"). Adems, una mtrica que pret ende est ar en una escala racio-
nal no debe contar con component es que slo se miden en una escala ordinal.
Cuando una mtrica representa una caracterstica de software que aumenta cuando
se presentan rasgos positivos o que disminuye al encontrar rasgos indeseables, el
valor de la mtrica debe aumentar o disminuir en el mismo sentido.
Cada mtrica debe validarse empricamente en una amplia variedad de contextos
antes de publicarse o aplicarse en la toma de decisiones. Una mt ri ca debe me-
dir el factor de inters, i ndependi ent ement e de ot ros factores. Debe "crecer"
para aplicarse en si st emas gr andes y funci onar en di versos l enguaj es de pro-
gramaci n y domi ni os de si st emas.
3 Aunque la crtica de mtricas especficas es comn en la bibliografa, muchas de esas criticas se con-
centran en aspect os esotricos y pierden de vista el principal objetivo de las mtricas en la realidad:
ayudar al ingeniero de software a establecer una manera sistemtica y objetiva de conocer a fondo
su trabajo y, como resultado, mejorar la calidad de! producto
TM
PDF Editor
470
PARTE DOS PRCnCA DE LA INGENIERA D A SOFTWARE
il sofaie I
OPM se encontrar en
w w w . t h e d a c s .
r a m / G o l d P r o c t i c e s /
p r o c t k e s / g q m a .
h t m l .
Aunque la formulacin, caract eri zaci n y validacin son crticas, la recopilacin 11
anlisis son las actividades que dirigen el proceso de medicin. Roche [ROC94]
giere las si gui ent es directrices para est as actividades: 1) si empre que sea posible
ben aut omat i zar se la recopilacin de dat os y su anlisis; 2) deben aplicarse t
est ad st i cas vlidas para est abl ecer rel aci ones ent re los atributos i nt ernos de!
duct o y las caract er st i cas de calidad ext emas (por ej empl o, si el grado de corrr rjfl
dad de la arqui t ect ura se correl aci ona con el nmer o de defect os i nformados
aplicarla en produccin), y 3) para cada mt ri ca deben est abl ecerse directrices \
comendaci ones para la interpretacin.
15.2.4 Medicin del software orientado a objetivos
Basili y Weiss [BAS84] desarrollaron el paradi gma objetivo/pregunta/mtrica
como una tcnica para identificar mt ri cas significativas aplicables en cualqu
t e del proceso del soft ware. El OPM dest aca la necesi dad de 1) est abl ecer un i
vo de medicin explcito que sea espec fi co para la actividad del pr oceso o las i
tersticas del product o que se est eval uando, 2) definir un conj unt o de pregu
deben responderse con el fin de al canzar el objeto, y 3) identificar mtricas I
mul adas que ayuden a responder esas pregunt as.
Es posible empl ear una plantilla de definicin de objetivos [BAS94] para >
da objetivo de medicin. La plantilla t oma esta forma:
Anal i zar [el nombr e de la actividad o el at ri but o que se medi r] c o n el p r o p s i t o <
objetivo gener al del anlisis4] e n r e l a c i n c o n (el aspect o de la actividad o at ri bu : ;
s e en consi dera] d e s d e el p u n t o d e vi s t a d e [la gent e que t i ene i nt ers en la i
e n el c o n t e x t o d e [el ent or no en que t i ene l ugar la medi ci n].
Como ej empl o, consi drese una plantilla de definicin del objetivo para I
Seguro:
Anal i zar la arqui t ect ura del sof t war e HogarSeguro c o n el p r o p s i t o d e eval uar I: ; :
ponent es arqui t ect ni cos e n r e l a c i n c o n la capaci dad par a lograr que Hogar
m s ext ensi bl e d e s d e el p u n t o d e vi s t a d e los i ngeni eros de sof t war e que re
t r abaj o e n el c o n t e x t o d e la mej or a del pr oduct o en l os si gui ent es tres aos.
Una vez definido expl citamente el objetivo de la medi ci n, se desarroi:31
j unt o de pregunt as. Las r espuest as a st as ayudan al equi po de soft ware
ot ros participantes) a det ermi nar si s e ha al canzado el objetivo de med
las pregunt as que se r esponden est n las siguientes:
P,: Los component es arqui t ect ni cos est n caract eri zados de mar
apar ecen por separ ado la funcin y los dat os rel aci onados?
4 Van Solingen y Berghout [SOL99] sugieren que el objetivo es casi siempre "comprender a
mejorar" la actividad del proceso o el atributo del producto.
TM
PDF Editor
CAPTULO 15 MTRI CAS D A PRODUCTO P ARA EL SOFTWARE
471
C m o
d e b e m o s
r i M r l a c a l i d a d
i m n m t r i c a
r *p e s t a d e l
s o f t w a r e ?
^CONSEJ ^
j experiencia indico
ue slo se usoi uno
' f f i c o del producto si
* intuitiva y fcil
atufar. Si deben
K cerse docenas de
'cuentas" , es improba-
x que la mtrico se
xopte ampliamente.
P / . La complejidad de cada component e se encuent r a dent ro de los lmites que
facilitarn su modificacin y ext ensi n?
Cada una de est as pr egunt as debe r esponder se de maner a cuantitativa, empl ean-
do una o ms medi das y mtricas. Por ejemplo, una mtrica que proporci ona una in-
dicacin de la cohesi n (captulo 9) de un component e arqui t ect ni co sera til para
responder P,. La complejidad ciclomtica y las mt ri cas anal i zadas en la secci n
15.4.1 o 15.4.2 proporci onar an conoci mi ent os a fondo para P 2 .
En realidad, tal vez haya di versos obj et i vos de medicin con pr egunt as y mt ri cas
rel aci onadas. En cualquier caso, las mt ri cas el egi das (o derivadas) deben cumplir
con los principios de medi ci n anal i zados en la seccin 15.2.3 y los atributos de me-
dicin anal i zados en la seccin 15.2.5. Si se desea obt ener mayor i nformaci n sobre
OPM, el lector i nt eresado debe consul t ar [SHE98] o [SOL99].
15.2.5 Los atributos de las mtricas efectivas del software
Se han propuest o ci ent os de mt ri cas para el sof t war e de comput adora, per o no t o-
das proporci onan soport e prct i co para el ingeniero de soft ware. Algunas exigen
medi ci ones demasi ado compl ej as; ot ras son tan esot ri cas que pocos profesi onal es
podr an comprenderl as, y ot r as ms violan las noci ones intuitivas bsi cas de lo que
es el soft ware de alta calidad.
Ejiogu [EJ191] defi ne un conj unt o de at ri but os que toda mtrica efectiva del soft-
war e debe abarcar. La mt ri ca derivada y las medi das que llevan a ella deben ser:
Simples y calculables. Debe ser relativamente fcil aprender a derivar la mtrica,
y su clculo no debe exigir cant i dades anormal es de t i empo o esfuerzo.
Emprica e intuitivamente persuasivas. La mtrica debe sat i sfacer las noci ones
intuitivas del i ngeni ero acerca del at ri but o del product o que se est const ru-
yendo.
Consistentes y objetivas. La mtrica si empre debe arrojar resul t ados que no
permitan ambi gedad al guna.
Consistentes en el uso de unidades y dimensiones. El clculo mat emt i co de la
mtrica debe empl ear medi das que no lleven a combi naci ones ext r aas de
uni dades.
Independientes del lenguaje de programacin. Las mt ri cas deben basar se en el
model o de anlisis o diseo, o en la est ruct ura del propi o programa.
Mecanismos efectivos para la retroalimentacin de alta calidad. Es decir, la m-
trica debe llevar a un product o final de la ms alta calidad.
Aunque casi t odas las mtricas de soft ware satisfacen est os atributos, al gunas m-
tricas de uso comn no cumpl en con una o dos de ellas. Un ej empl o es el punt o de
funcin (el cual se estudia en la seccin 15.3.1), que es una medida de la ent rega de
"funcionalidad" por parte del software. Se puede ar gument ar ' que el atributo consis-
TM
PDF Editor
tente y objetiva falla porque tal vez un tercero, que sea independiente, no logre den. ir
el mismo valor del punt o de funcin que un colega que utilice la misma i nformador i
acerca del software. Debemos rechazar entonces la medida de punt o de funcin-
respuesta es por supuesto que no! El punt o de funcin proporciona conocimier -
tiles y, por tanto, valores distintos, aunque no satisfaga algn atributo a la perfecc -
15.2.6 Panorama de las mtricas del producto
Aunque se ha propuesto una amplia variedad de t axonom as mtricas, el sgu ~ B
esquema atiende las reas ms importantes de las mtricas:
M t r i c a s p a r a e l m o d e l o d e a n l i s i s . Estas mtricas atienden varios aspectos o H
modelo de anlisis e incluyen:
Funcionalidad entregada: proporciona una medida indirecta de la funcin
que se empaquet a con el software.
Tamao del sistema: mide el t amao general del sistema, definido desde el
de vista de la informacin disponible como part e del model o de anlisis.
Calidad de la especificacin: proporciona una indicacin de la especificidac
grado en que se ha completado la especificacin de los requisitos.
M t r i c a s p a r a e l m o d e l o d e d i s e o . Estas mtricas cuantifican los atribu:
diseo de manera tal que le permiten al ingeniero de software evaluar la cal
diseo. La mtrica incluye:
Mtricas arquitectnicas: proporcionan un indicio de la calidad del diseo a
tnico.
Mtricas al nivel de componente: miden la complejidad de los componer. -^ j
soft ware y otras caractersticas que impactan la calidad.
Mtiicas de diseo de la interfaz-. se concentran principalmente en la facilidad de
Mtricas especializadas en diseo orientado a objetos: miden caractersticas
ses, adems de las correspondientes a comunicacin y colaboracin.
M t r i c a s p a r a e l c d i g o f u e n t e . Estas mtricas miden el cdigo fuente y se
para evaluar su complejidad, adems de la facilidad con que se mantiene y
entre otras caractersticas:
Mtricas de Halstead: controversiales pero fascinantes, est as mtricas p
nan medidas nicas de un programa de cmputo.
Mtricas de complejidad: miden la complejidad lgica del cdigo fuente
se consideran mtricas de diseo al nivel de componentes).
Mtricas de longitud: proporcionan un indicio del t amao del software.
5 Podra usarse un contraargumento igualmente vigoroso. sa es la naturaleza de las
software.
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO P ARA A SOFTWARE 473
M t r i c a s p a r a p r u e b a s . Estas mtricas ayudan a disear casos de prueba efectivos
y a evaluar la eficacia de las pruebas:
Mtricas de cobertura de instrucciones y ramas: lleva al diseo de casos de prueba
que proporcionan cobertura del programa.
Mtricas relacionadas con los defectos: se concent ran en encont rar defectos y no
en las propias pruebas.
Efectividad de la prueba: proporcionan un indicio en tiempo real de la efectividad
de las pruebas aplicadas.
Mtricas en el proceso: mtricas relacionadas con el proceso que se det ermi nan a
medida que se aplican las pruebas.
En muchos casos las mtricas de un modelo pueden aplicarse en actividades post e-
riores de la ingeniera del software. Por ejemplo, las mtricas de diseo se utilizan pa-
ra estimar el esfuerzo requerido para generar cdigo fuente. Adems, las mtricas de
diseo se aprovechan para planear pruebas y el diseo de casos de prueba.
HOGARSEGURO
Debate sobre mtricas del producto
El e s c e n a r i o : Cubculo de Vinod.
a c t o r e s : Vinod, Jamie y Ed, integrantes del equipo
ngeniera del software de H o g a r S e g u r o , que siguen
trabajando con el diseo al nivel d componentes y de
Vi nod: Doug [Doug Miller, jefe de ingeniera del
ctware] me dijo que todos deberamos usar mtricas del
r' oducto, pero lo hizo de manera vaga. Tambin dijo
; j e no presionara... su uso dependera de nosotros.
J a mi e : Eso est bien, porque no tenemos tiempo para
empezar a medir cosos. Estamos esforzndonos por
cjmplir con el calendario de trabajo.
Ed: Estoy de acuerdo con Jamie. Estamos contra ellas,
:qu... no hoy tiempo.
Vi nod: S, lo s. pero tal vez por alguna razn sea
importante que las usemos.
J a mi e : No discuto eso, Vinod. Es cosa de tiempo, y y o
- o tengo tanto como para desperdiciarlo
Vi nod: Y si las mediciones nos ahorraran tiempo?
Ed: Ests equivocado. Requieren tiempo y, como dice
jamie,;,
Vi n o d : No, espera... y si nos ahorran tiempo?
Ja m i e : Cmo?
Vi n o d : Evitando retrabajar... Si una mtrica nos ayuda
a evitar un problema importante o incluso uno
moderado, y eso nos evita retrabajar una parte del
sistema, ahorraremos tiempo, o no?
Ed : Es posible, supongo, pero nos garantizas que
alguna mtrica del producto nos ayudar a encontrar un
problema?
Vi n o d : Y t me garantizas que no lo har?
Ja m i e : Bueno, qu ests proponiendo?
Vi n o d : Creo que debemos seleccionar unas cuantas
mtricas de diseo, tal vez orientadas a clases, y
aplicarlas como parte de nuestro proceso de revisin
para todos los componentes que desarrollemos.
Ed : No estoy muy familiarizado con las mtricas
orientadas a objetos.
Vi n o d : Voy a dedicar un poco de tiempo a revisarlas y
a hacer algunas recomendaciones... estn de acuerdo?
(Ed y Jamie asienten sin mucho entusiasmo.)
TM
PDF Editor
474
P A R T E D O S PRCTI CA DE LA INGENIERA DEL SOFTWARE
1 5 - 3 M T P I C A S PARA ET. MODELO DE ANLI SI S
En los siguientes sitios
Web se encontrar
nforoiocin abundcnte
y til acetca lie los
puntos de funcin:
w w w . f f p o g .
o r g y w w w .
fu n c tio n p o in ts .to m .
n a o X-,
r |
:ara
Aunque existen en la bibliografa rel at i vament e pocas mt ri cas de anl i si s y espec
ficacin, es posible adapt ar mt ri cas que se utilizan en la est i maci n de pr oyect : ;
aplicarlas en est e cont ext o. Estas mt ri cas exami nan el model o de anlisis con la
t enci n de predecir el "t amao" del si st ema resul t ant e. El t amao es, en ocas
(pero no siempre), un indicador de la complejidad del di seo y casi si empre r~
un indicador de un mayor esfuerzo de codificacin, integracin y prueba.
15.3.1 Mtricas basadas en la funcin
La mtrica de punt o de funcin (PF), propuest a inicialmente por Albretch [ALB79" m
usa de maner a efectiva como medi o para medi r la funci onal i dad que ent rega ur.
t ema. 6 Empl eando dat os histricos, el PF s e usa para 1) est i mar el cost o o el
zo requeri do para di sear, codificar y probar el soft ware; 2) predecir el nmer : i ]
errores que se encont r ar n durant e la prueba, y 3) pronost i car el nmer o de cc
nent es, de lneas de cdigo proyect adas, o ambas, en el si st ema i mpl ement ac:
Los punt os de funcin se derivan empl eando una relacin emprica ba s a ; i d
medi das cont abl es (directas) del domi ni o de la i nformaci n del soft ware y las J
l uaci ones de la complejidad de ste. Los valores del domi ni o de la i nformaci n se f
finen de la siguiente manera: 7
Nm e r o d e e n t r a d a s e xt e r n a s (EE). Cada entrada extema se origina
usuari o o es t ransmi t i da desde otra aplicacin y proporci ona distintos dat os
dos a la aplicacin o i nformaci n de control. Las ent r adas suelen empl earse
tualizar archi vos lgicos i nt ernos (AU). Las ent r adas deben distinguirse de ia~ l
sultas, que se cuent an por separado.
Nm e r o d e s a l i d a s e xt e r n a s (SE). Cada salida extema se deriva en el -
de la aplicacin y proporci ona i nformaci n al usuari o. En est e cont ext o,
t erna al ude a i nformes, pantallas, mens aj es de error, etc. Los el ement os de
dividuales dent r o de un i nforme no se cuent an por separado.
Nm e r o d e c o n s u l t a s e xt e r n a s (C E). Una consulta extema se define : a
ent r ada en lnea que lleva a la generaci n de al guna respuest a i nmedi at a p>:r j
del soft ware, en la forma de salida en linea (a menudo recuperada de un
Nm e r o d e a r c h i v o s l g i c o s i n t e r n o s (ALI). Cada archivo lgico in
agr upami ent o lgico de dat os que reside dent r o de los lmites de las apli
que se mant i ene medi ant e ent r adas ext ernas.
Desde que Albrecht dio a conocer su trabajo original, se han escrito cientos de libros,
tculos sobre PF. En [IEP03] se encontrar una bibliografa muy valiosa.
En realidad, la definicin de los valores del dominio de la informacin y la manera en c j t
tan son un poco ms complejas. El lector interesado deber consultar [IFP01] para c
talles.
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO PARA EL SOFTWARE 475
Val or del domi ni o
d e i nf or maci n
Entradas externas (EE)
Salidas externas (SE)
Consultas externas (CE)
Archivos de lgica interna (ALI)
Archivos de interfaz externa (AIE)
Total de conteos
Cont eo
a
a
a
a
a
Fact or d e p ond e r a c i n
Si mpl e Pr ome di o Compl ej o
4
5
4
1 0
7
6
7
6
15
10
Nm e r o d e a r c h i v o s d e i n t e r f a z e xt e r n o s (AIE). Cada archivo de interfaz ex-
terno es un agrupami ent o lgico de dat os externo a la aplicacin pero que propor-
ciona dat os que podran usarse en sta.
p Una vez que se han recolectado los datos, se completa la tabla de la figura 15.2 y
se asocia un valor de complejidad con cada conteo. Las organizaciones que usan
mt odos de punt o de funcin desarrollan criterios para determinar si una entrada
determinada es simple, promedio o compleja. No obstante, la determinacin de la
complejidad es un poco subjetiva.
Para calcular los punt os de funcin (PF) se usa la siguiente relacin:
PF = conteo total x [0.65 + 0.01 x I (F ) ] (15.1)
donde conteo total es la suma de todas las entradas de PF obtenidas de la figura 15.2.
F (j = l a 1 4 ) son factores de ajuste de valor basados en las respuest as a las siguien-
tes preguntas [LON02J:
1. El sistema requiere respaldo y recuperacin confiables?
2 . Se requieren comuni caci ones de dat os especializadas para transferir infor-
macin a la aplicacin, u obtenerla de ella?
3. Hay funciones distribuidas de procesamiento?
4. El desempeo es crtico?
5. El sistema se ejecutar en un ent orno existente que tiene un uso pesado de
operaciones?
6 . El sistema requiere entrada de dat os en linea?
7. La entrada de dat os en lnea requiere que la transaccin de entrada se cons-
truya en varias pantallas u operaciones?
8 . Los ALI se actualizan en lnea?
9. Las entradas, las salidas, los archivos o las consultas son complejos?
10. Es complejo el procesamiento interno?
11. El cdigo diseado ser reutilizable?
TM
PDF Editor
Uno
en kb.cs.
iminragdeburg.
de/sw-eng/
us/jova/fp/.
12. Se incluyen la conversi n e instalacin en el diseo?
13. Est di seado el si st ema para i nst al aci ones mltiples en di ferent es or ga mo- ]
ciones?
14. La aplicacin est di seada para facilitar el cambi o y para que el usuari o 1: j
use fci l ment e?
Cada una de est as pregunt as se responde empl eando una escal a que va de 0 (no
port ant e o aplicable) a 5 (absol ut ament e esencial). Los valores const ant es de I
ecuacin (15.1) y los factores de peso que se aplican a los cont eos del dominio de la r - l
formaci n se det ermi nan emp ri cament e.
Para ilustrar el empl eo de la mtrica del PF en est e cont ext o se ide la r epr esen^ I
cin simple del model o de anlisis, que se muest ra en la figura 15.3. Ah se r epr es**!
ta un di agrama de flujo de datos (captulo 8) dent ro del soft ware HogarSeguro. La r j * l
cin manej a la interaccin con el usuario acept ando una cont rasea de st e para a: -l
tivar o desactivar el sistema, y permite consul t as sobre el est ado de las zonas de se-l
guridad y varios sensores de seguridad. La funcin despliega una serie de mensa es r|
enva seal es de control apropi adas a varios component es del si st ema de segur, cao. 1
Se eval a el di agrama de flujo de dat os para det ermi nar un conj unt o de me d i c a l
clave del domi ni o de i nformaci n que se requi eren para calcular la mt ri ca del p- ^- l
t o de funci n. En la figura se muest r an t res ent r adas ext ernas ( c o n t r a s e a , b o t a n ;
d e p n i c o y a c t i v a r / d e s a c t i v a r ) j unt o con dos consul t as ext ernas (c o n s u l t a j e ;
zo n a y c o n s u l t a d e s e n s o r ) . Se muest ra un ALI (a r c h i v o d e c o n f i g u r a c i n As i
s i s t e m a ) . Tambi n est n present es dos sal i das de usuari os ( m e n s a j e s y e s t a o s
d e l s e n s o r ) y cuat ro AIE ( s e n s o r d e p r u e b a , c o n f i g u r a c i n d e zo n a , a c t i v a r / - !
d e s a c t i v a r y a l e r t a d e a l a r m a ). En la figura 15.4 se muest r an est os datos, ' - ~ J
con la complejidad apropi ada.
El cont eo total que se muest ra en la figura 15.4 debe aj ust arse empl eando la e c J
cin (15.1):
PF = cont eo total x [0.65 +0. 01 x (F,) ]
M o d e l o d e f l u j o
d e d a t o s p a r a
e l s o f t w a r e
HogarSeguro.
Usuario
Sensor de prueba
Contrasea
Consulto de zona / F u n c l o n e ' ^
Consulto de sensor /interaccin de'
usuario en
Sensofes
Configuracin de zona
Botn de pnico
Activar/desactivar
Contrasea, sensores...
\ Mensajes
JÊslatus del sensor
Usuario
JÊslatus del sensor
Activar/desactivar
Alerta
de alarma
_Dot o^l ônf i gur aci ndehsi st em^
Subsistema
t monitoreo
y respuesta
TM
PDF Editor
4 7 7
Va l o r d e l d o m i n i o
Fa c t o r d e p o n d e r a c i n
d e i n f o r m a c i n
C o n t e o Si m p l e P r o m e d i o C o m p l e j o
Entrados externas (EE)
a i
X
<3 ) 4
6 = U J
Salidas externas (SE)
a i
X ( 4 ) 5
7 =
Consultas externas (CE)
a i
X
(3 > 4 6 = [ _ 4 J
Archivos de lgica interna (ALI)
a i
X
O
10 15 = 1: .7 1
Archivos de interfaz externa (AIE)
a i
X 7
10 = [_2 0 J
Total de conteos
1 50 1
donde cont eo total es la suma de t odas las ent r adas de PF obt eni das de la figura 15.4,
y F (;' = 1 a 14) son fact ores de aj ust e de valor. Para los objetivos de est e ej empl o, su-
pngase que I (F ) es 46 (un product o moder adament e complejo). Por t ant o:
PF = 50 x [0.65 + (0.01 x 46)1 = 56
Con base en el valor proyect ado del PF deri vado del model o de anlisis, el equi-
po del proyect o puede est i mar el t amao i mpl ement ado general de la funcin de in-
t eracci n del usuari o de HogarSeguro. Supngase que los dat os del pasado indican
que un PF se t raduce a 60 lneas de cdigo (se va a usar un l enguaj e ori ent ado a ob-
jetos) y que se producen 12 PF por cada per sona- mes de esfuerzo. Estos dat os his-
tricos proporci onan al jefe del proyect o i nformaci n i mport ant e que sirve para la
pl aneaci n y que se basa en el model o de anlisis m s que en est i mados prel i mi na-
res. Supngase, adems, que los proyect os ant eri ores han encont r ado un promedi o
de tres errores por punt o de funcin durant e las revisiones del anlisis y el diseo, y de
cuat ro errores por punt o de funcin dur ant e las pruebas de unidad e integracin. Es-
tos dat os ayudarn a los i ngeni eros de sof t war e a eval uar el grado en el que han
compl et ado sus act i vi dades de revisin y prueba.
Uemura y sus col egas [UEM99] sugi eren que los punt os de funcin t ambi n pue-
den calcularse a partir de di agr amas UML de clase y secuenci a (captulos 8 y 10). El
lector i nt eresado debe consul t ar [UEM99] para conocer m s detalles.
"En luga r de slo musi t ar nt er t a de cul ' nuevo mtrico' podrio apl i car se. . . de
lemos pl ant earnos la pregunt a bsica:
' qu he remos con las mt ri cos?"'
Michaei Mah y larry Putnam
15.3.2 Mtricas par a la calidad de la especificacin
Davis y s us col egas [DAV93] proponen una lista de caract er st i cas con las cual es
puede eval uarse la calidad del model o de anlisis y la correspondi ent e especificacin
TM
PDF Editor
478
\
CLAVE
Al medir las
caractersticas de la
especificacin es
posible obtener un
conocimiento
cuantitativo de la
especificidad y el grado
de avance.
de requisitos: especificidad (falta de ambi gedad), grado de avance, correccin, faah
dad de comprensin, facilidad de verificacin, consistencia interna y externa, facilkkt
para alcanzar los objetivos, concisin, facilidad para darle seguimiento, facilidad per:
modificarse, precisin y facilidad de reutilizacin. Adems, los aut or es [DAV93] obse-
van que las especi fi caci ones de alta calidad deben est ar al macenadas electrnica
ment e, ser ejecutables o por lo menos interpretables, est ar anot adas por i mpor t anci
relativa, ser estables, t ener indicada la versin, est ar organi zadas, incluir r ef er enci a
cr uzadas y especificarse con el grado de detalle correcto.
Aunque, al parecer, muchas de est as caracter sticas tienen una nat ural eza CL
tativa, Davis et al. [DAV93] sugi eren que cada una puede represent arse emplea
una o m s mtricas. Por ejemplo, supngase que hay nr requisitos en una es
caci n, de modo que
n r = r i f + Rnf
donde nf es el nmer o de requisitos funci onal es y nnf el de no funci onal es (con-: e
desempeo) .
Para det ermi nar la especificidad (falta de ambi gedad) de los requisitos, Dar. &
al. sugi eren una mt ri ca basada en la consi st enci a de la interpretacin de los rev.
res de cada requisito:
Qi = nu/nr
donde nw es el nmer o de requisitos que t odos los revisores i nt erpret aron de la
ma maner a. Cuant o ms cer cano est el valor de Q a 1, menor ser la ambi
de la especificacin.
El grado de avance de los requisitos funci onal es se det ermi na al calcular la -2
cin
Q2 = n /[n, x ns]
donde nu es el nmero de requisitos de funcin nica; n el nmero de ent radas (e
los) definidos o implcitos en la especificacin, y ns, el nmero de estados especi f i cad
La relacin Q2 mi de el porcent aj e de funci ones necesari as que se han especificac: f f l
ra un sistema. Sin embargo, no se at i enden requisitos que no son funcionales. P n l l
corporarlos a una mtrica general del grado de avance, se debe considerar el g r a a r . ^
validacin de los requisitos:
Qj = nc/[nc + n j
donde n: es el nmer o de requisitos que se han validado como correctos, y r
requisitos que an no se validan.
"Mido lo que seo mensurabl e, y lo que no lo sea, vulvalo mensurabl e. "
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO P ARA A SOFTWARE
4 7 9
15.4 EL MQDELQ P E P I S E Q
icos pueden
r discernimiento
l os datos
es y la
Idel
i asociados con
l s t o
nico.
Sera inconcebible que el di seo de un nuevo avin, un nuevo chip de comput ador a
o un nuevo edificio de oficinas se realizara sin definir las medi das del di seo, sin de-
t ermi nar las mt ri cas de di versos aspect os de la calidad del di seo y sin usarl as pa-
ra guiar la maner a en que evoluciona el diseo. Sin embargo, a menudo el di seo de
si st emas de sof t war e compl ej os suel e avanzar casi sin medicin. La irona es que se
di spone de mt ri cas de di seo para el soft ware, pero la gran mayora de los desarro-
lladores siguen i gnorando su existencia.
Las mt ri cas de di seo para el sof t war e de comput adora, como t odas las dems
mt ri cas del soft ware, no son perfect as. Sigue abierto el debat e sobre su eficacia y
la maner a en que deben aplicarse. Muchos expert os ar gument an que se necesita
m s experi ment aci n ant es de empl ear las medi ci ones en el diseo. Sin embargo,
un di seo sin medicin es inaceptable.
15.4.1 Mtricas del diseo arquitectnico
Las mt ri cas de di seo arquitectnico se concent r an en las caract er st i cas de la ar-
quitectura del pr ogr ama (captulo 10), y se dest acan la est ruct ura arqui t ect ni ca y la
efectividad de mdul os o component es dent ro de la arquitectura. Estas mt ri cas son
de "caja negra", en el sent i do de que no requi eren ningn conoci mi ent o del funci o-
nami ent o i nt erno de un component e de sof t war e en particular.
Card y Glass |CAR90] defi nen tres medi das de la complejidad del di seo del soft-
ware: estructural, de dat os y del si st ema.
En el caso de las arqui t ect uras j errqui cas (por ejemplo, las arqui t ect uras de lla-
mada y retorno), la complejidad estructural de un mdul o i se defi ne de la siguiente
manera-.
S ( i ) = / 2 u t ( )
(15.2)
CVVE
donde/ o u t ( / ) es la dependenci a hacia fuera8 del mdul o i.
La complejidad de datos proporci ona una indicacin de la complejidad de la inter-
faze i nt erna de un mdul o i y se defi ne como:
>(/) = v()/[/oUt(/) + 1] (15.3)
donde v(/') es el nmer o de variables de ent r ada y salida que se pasan al mdul o i o
se reciben de ste.
Por ltimo, complejidad del sistema se defi ne como la s uma de las compl ej i dades
est ruct ural y de dat os, especificada como:
C(J) = S(i) 4 D[i) (15.4)
8 Dependencia hacia Juera se define como el nmero de mdulos inmediatamente subordinados al
mdulo i; es decir, el nmero de mdulos invocados directamente por i. Lo contrario, dependencia
hacia dentro, seria una variable f, que indique el nmero de mdulos que invocan directamente al
mdulo i.
TM
PDF Editor
4 8 0 PARTE DOS PRCTI CA DE LA INGENIERA D A SOFTWARE
A medida que aument an est os valores, la complejidad arquitectnica general del s s j 1
tema tambin lo hace. Esto lleva a una mayor probabilidad de que aument en los
fuerzos de integracin y prueba.
Fenton [FEN91] sugiere varias mtricas simples de morfologa (es decir, de forr-. I
que permiten la comparacin entre diferentes arquitecturas de programas empl ea-
do un conjunto de dimensiones directas. Si se toma como referencia la a r qui t e c t o I
de llamada y retorno de la figura 15.5, se definirn las siguientes mtricas:
t amao = n + a
donde n es el nmero de nodos y a, el de arcos. En el caso de la arquitectura rr Te-
trada en la figura 15.5,
t amao = 17 + 18 = 35
profundidad = 4, el cami no ms largo desde el nodo raz (superior) a un neo:
hoja.
anchura = 6, nmero mxi mo de nodos en cualquier nivel de la arquitectura
relacin arco-a-nodo, r = a/n,
que mide la densidad de las conexiones y proporciona una simple indicacin t
acoplamiento de la arquitectura. En el caso de la arquitectura mostrada en la figura
15.5, r = 18/17 = 1.06.
El Comando de Sistemas de la Fuerza Area de Estados Unidos [USA87] ha desa-
rrollado varios indicadores de la calidad del soft ware que se basan en las caracters-
ticas de diseo que pueden medirse en un programa de computadora. Empleanc:
conceptos similares a los propuestos en el IEEE Std. 982.1-1988 [IEE94], la Fuerza
Area est adouni dense emplea informacin obtenida del diseo de dat os y arquitec-
tnico para derivar un ndice de calidad de la estructura de diseo (ICED) que va te
0 a 1. El clculo del ICED requiere determinar los siguientes valores [CHA891.
S, = el nmero total de mdulos definidos en la arquitectura del programa
M/vJo
Mt r i cas d e
mor f ol og a.
Profundidad
1h 1 1m 11n miq 11 r 1
Ancho
TM
PDF Editor
CAPTULO 15 MTRI CAS DHL PRODUCTO P ARA EL SOFTWARE
4 8 1
52 = el nmer o de mdul os cuya (uncin correcta depende de la f uent e de en-
t rada de dat os o que pr oduce dat os que se usarn en ot ro lugar (en gene-
ral, ios mdul os de control, ent r e otros, no se cont ar an como part e de S2)
53 = el nmer o de mdul os cuya funci n correcta depende del pr ocesami ent o
ant eri or
54 = el nmer o de el ement os de base de dat os (incluye obj et os de dat os y t o-
dos los at ri but os que definen objetos)
55 = el nmer o total de el ement os ni cos de base de dat os
56 = el nmer o de segment os de base de dat os (registros di ferent es u obj et os
individuales)
57 = el nmer o de mdul os con una sola ent r ada y salida (con excepci n del
procesami ent o, no s e consi dera una salida mltiple)
Una vez que se han det ermi nado los valores del S, al S7 para un programa de compu-
t adora, es posible calcular los si gui ent es val ores intermedios:
Estructura del programa: Du donde D se defi ne como sigue: si el di seo arquitec-
t ni co s e desarrol l empl eando un mt odo distinto (por ejemplo, di seo ori ent ado al
flujo de dat os u objetos), ent onces D, = 1; de lo contrario, D, = 0.
Independencia del mdulo. D2 = 1 - (S2/S,)
Mdulos no dependientes del procesamiento anterior: D3 = 1 - (S3/S,)
Tamao de la base de datos: D4 = 1 - (S5/S4)
Divisin en compartimientos de la base de datos: Ds = 1 - (S6/S4)
Caracterstica de entrada/salida del mdulo: D6 = 1 - (S7/S,)
Una vez det er mi nados los val ores intermedios, se calcula el ICED de la si gui ent e ma-
nera:
ICED=2i V(D (15.5)
donde i = 1 a 6, w es el peso relativo de la i mport anci a de cada uno de los valores
intermedios, y Y w = 1 (si t odo D, tiene pesos iguales, ent onces w, = 0.167).
Se det ermi na el valor de ICED para los di seos ant eri ores y se compar a con un di-
seo que est en desarrollo. Si el ICED es significativamente menor que el promedi o,
lo indicado es realizar t rabaj o de di seo y revisin adicionales. De igual maner a, si se
van a realizar cambi os i mport ant es en un di seo existente, podr calcularse el efec-
to de esos cambi os sobr e el ICED.
"Es posible considerar que la medicin es un desvo. Un desvio necesario, porque la mayor a de los ser es humanos no
son capaces de t omor decisiones claras y objetivos (sin apoyo cuantitativo). "
Ho r s t Z u s e
15.4.2 Mtricas par a el diseo orientado a objetos
Gran part e del di seo ori ent ado a obj et os es subjetivo (un di seador experi ment ado
"sabe" cmo caract eri zar un si st ema ori ent ado a obj et os para que i mpl ement e efec-
TM
PDF Editor
4 8 2 PARTE DOS PRCTI CA DE LA INGENIERA DEL SOFTWARE
C u l e s
c a r a c t e r s t i -
c a s p u e d e n m e d i r -
s e c u a n d o s e e v a -
l a un d i s e o
o r i e n t a d o a o b j e -
t o s ?
t i vament e los requisitos del cliente). Pero, a medi da que aument a el t amao \ -
compl ej i dad del model o de di seo ori ent ado a objetos, un concept o ms objetivo a
las caract er st i cas del di seo beneficiar a al di seador exper i ment ado (que obt endr
conoci mi ent os adicionales) y al principiante (que obt endr a una indicacin de la ca-
lidad que de otra maner a no estara disponible).
En un t rat ami ent o det al l ado de las mt ri cas del soft ware para si st emas ori ert a
dos a objetos, Whitmire |WHI97] descri be nueve caract er st i cas distintivas y mensu-
rables de un di seo ori ent ado a objetos:
T a m a o . El t amao se define a partir de cuat ro concept os: poblacin, volurr.e-
longitud y funcionalidad. Poblacin se mi de al t omar un cont eo est t i co de entidad
ori ent ada a obj et os como cl ases u operaci ones. Las medi das de volumen son idr :
cas a l as de la poblacin, per o se recopilan di nmi cament e (en un moment o dete-
mi nado). La longitud es una medi da de una cadena de el ement os de di seo nter;
nect ados (por ejemplo, la profundi dad de un rbol de herencia es una medi da de lor-i
gitud). Las mt ri cas de funcionalidad proporci onan una indicacin indirecta del va. : r
ent regado al cliente en una aplicacin ori ent ada a objetos.
C o m p l e j i d a d . Como el t amao, hay muchos concept os di ferent es de la comp ;
jidad del sof t war e [ZUS97]. Whitmire consi dera la complejidad desde el punt o de v ;
ta de las caracter sticas est ruct ural es, al exami nar la maner a en que se i nt errel ac -
nan las cl ases de un di seo ori ent ado a objetos.
Ac o p l a m i e n t o . Las conexi ones fsicas ent re los el ement os de un di seo ori enu
do a obj et os (por ejemplo, el nmer o de col aboraci ones ent re cl ases o el de mensa
jes pas ados ent re objetos) represent an el acopl ami ent o dent ro de un si st ema orier-
t ado a obj et os.
Su f i c i e n c i a . Whitmire defi ne suficiencia como "el grado en que una abstracc;: -
posee las caracter sticas que se le pi den, o el gr ado en que un component e de dst
o posee caracter sticas en su abstraccin, desde el punt o de vista de la aplicad:*'
actual". Expresado de otra maner a, se pregunt a: Cules propi edades debe t ener es-
ta abst racci n (clase) par a que sea til? [WH197]. En esenci a, un component e de c
seo (por ejemplo, una clase) es suficiente si refleja pl enament e t odas las propi ec;
des del obj et o de domi ni o de la aplicacin que se est model ando (es decir, que :
abst racci n, o clase, posee las caracter sticas que debe tener).
"Muchas d e la s d e c i s i o n e s para las que tenia que depender del fol dore o los m itos p u e d o t o m a r la s a h o r a e m p le a n d o
d a t o s cuantitativos."
St o t t W h i t m i r e
G r a d o d e a v a n c e . La ni ca diferencia ent re el grado de avance y la sufi ci enca
es "el conj unt o de caracter sticas cont ra las que compar amos el component e de abs
traccin o di seo" [WHI97]. La suficiencia compar a la abstraccin desde el punt o c:
vista de la aplicacin actual. El grado de avance consi dera varios punt os de vist:
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO PARA EL SOFTWARE 4 8 3
pl ant eando la pregunta: Cules propiedades se requieren para representar plena-
mente el objeto del dominio del problema? Debido a que los criterios para el grado
de avance consideran diferentes punt os de vista, indican indirectamente el grado en
que puede reutil izarse el component e de abstraccin o diseo.
C o h e s i n . Como su contraparte en el software convencional, un component e
orientado a objetos debe disearse de manera que todas las operaciones trabajen en
combinacin para alcanzar un solo propsito, bien definido. El grado de cohesin de
una clase se determina al examinar el grado en que "el conj unt o de propiedades que
posee es parte del dominio del problema o el diseo" [WHI97].
P r i m i t i v i s m o . Una caracterstica similar a la simplicidad, el grado de primitivis-
mo (aplicado a operaciones y clases) es el grado en que una operacin es atmica
(es decir, la operacin no puede construirse a partir de una secuencia de otras ope-
raciones contenidas dentro de una clase). Una clase que muestra un alto grado de
primitivismo slo encapsula operaciones primitivas.
Si m i l i t u d . Esta medida indica el grado en que dos o ms clases son similares en
cuant o a su estructura, funcin, comport ami ent o o propsito.
Vo l a t i l i d a d . Como ya se ha visto en este libro, los cambi os de di seo ocurren
cuando los requisitos se modifican o cuando las modificaciones se present an en otra
parte de una aplicacin, lo que produce una adaptacin obligatoria del component e
del diseo en cuestin. La volatilidad de un component e de diseo orientado a ob-
jetos mide la probabilidad de que ocurra un cambio.
En realidad, las mtricas del producto para si st emas orientados a objetos no slo
se aplican al modelo de diseo, sino tambin al de anlisis. En las secciones que si-
guen se explorarn las mtricas que proporcionan una indicacin de la calidad al ni-
vel de clase orientada a objetos y al nivel de operacin.
15.4.3 Mtricas orientadas a clases: la coleccin de mtricas de CK
La clase es la unidad fundament al de un sistema orientado a objetos. Por tanto, las
medidas y mtricas de una clase individual, la jerarqua de clase y las colaboracio-
nes de clase sern invaluables para un ingeniero de soft ware que debe valorar la ca-
lidad del diseo. En captulos anteriores se vio que la clase encapsula operaciones
(procesamiento) y atributos (datos). La clase suele ser el "predecesor" de las subcla-
ses (a veces denomi nadas descendientes) que heredan sus atributos y operaciones.
Con frecuencia, la clase colabora con otras clases. Cada una de estas caractersticas
se utiliza como base de la medicin.9
Chidamber y Kemerer [CHI94] propusieron uno de los conjuntos de mtricas de
software orientado a objetos al que se hace referencia con mayor frecuencia. A me-
9 Debe observarse que an se debate en la bibliografa tcnica la validez de algunas de las mtricas
analizadas en este capitulo. Quienes defienden la teoria de la medicin, exigen un grado de forma-
lismo que algunas mtricas orientadas a objetos no proporcionan Sin embargo, es razonable deter
minar que las mtricas indicadas proporcionan conocimientos tiles para el ingeniero de software.
TM
PDF Editor
CLAVE
El nmero de mtodos
y su complejidad estn
directo mente
correlacionados con el
esfuerzo requerido
pora probor una clase.
^ O N S U O ^
L o herencia es uno
caracterstica
extremadamente
poderoso que puede
cousar problemas si se
empleo sin cuidado.
sese el APH y otros
mtricas pora obtener
una lectura de lo
complejidad de las
jerarquas de cise.
nudo denomi nadas coleccin de mt ri cas de CK, los aut or es pr oponen seis mt r i ca
de di seo basado en cl ases para si st emas ori ent ados a objetos. 10
M t o d o s p o n d e r a d o s p o r c l a s e (M P C ). Suponga que n mt odos de compl ej i di :
c, c...,c est n definidos por la clase C . La mt ri ca de complejidad especfica q j t
se elija (por ejemplo, la complejidad ciclomtica) debe normalizarse con el fin de que ^
complejidad nomi nal de un mt odo t ome un valor de 1.0.
MPC = I
par a i = 1 a n. El nmer o de mt odos y su complejidad son i ndi cadores razonabi --
de la cant i dad de esf uer zo requeri do para i mpl ement ar y probar una clase. Ademar-
cuant o mayor sea el nmer o de mt odos, ms compl ej o ser el rbol de her enca
(todas las subcl ases her edan los mt odos de sus predecesores). Por ltimo, confir-
me crece el nmer o de mt odos de una clase det ermi nada, es probabl e que se vu;
va m s y m s especfica de la aplicacin, lo que limita sus posibilidades de reutiliz-
cin. Por t odas las r azones menci onadas, MPC debe mant ener se lo m s baj o que s r i
posible.
Aunque par ezca rel at i vament e simple desarrollar un cont eo del nmer o de mea-
dos en la clase, en realidad el pr obl ema es m s compl ej o de lo que parece. Debe ot
sarrollarse un enf oque de cont eo consi st ent e par a los mt odos [CHU95].
r b o l d e p r o f u n d i d a d d e l a h e r e n c i a (AP H). Esta mt ri ca es "la longitud ma--:
ma desde el nodo hast a la raz del rbol" [CHI94], Si t oma como referencia la figur
15.6, el val or de APH para la j erarqu a de clase most r ada es 4. A medi da que cre:
la APH, es probabl e que las cl ases de nivel inferior her edar n muchos mt odos Es-
J e r a r q u a
d e u n a
cl as e.
10 Chidamber y Kemerer usan el trmino mtodos en lugar de operaciones. La forma en que emplear -
trmino se refleja en esta seccin.
TM
PDF Editor
4 8 5
[CONSEJO,
iceptos de
uto y
i se aplican al
i convencional
i orientado o
is. Mantngase
el acoplamiento
7 fe cohesin de
s y operaciones.
to se presta a posibles dificultades cuando se trata de predecir el comport ami ent o de
una clase. Una jerarqua de clase profunda (su APH es mayor) tambin se presta a una
mayor complejidad de diseo. Por el lado positivo, valores grandes de APH indican
que se podran reutilizar muchos mtodos.
Nm e r o d e d e s c e n d i e n t e s (ND D ). Un descendiente es una subclase que se en-
cuentra i nmedi at ament e subordinada a otra en la jerarqua de clases. Si se toma co-
mo referencia la figura 15.6, la clase C2 tiene tres descendi ent es (las subclases C2 | ,
C 22 y C 2 3 ). A medida que crece el nmero de descendientes, se incrementa la reuti-
lizacin, pero podra diluirse la abstraccin que representa la clase predecesora si al-
guno de los descendientes no es un mi embro apropiado de la clase predecesora. A
medida que aument a el NDD, tambin lo hace la cantidad de pruebas (requeridas pa-
ra ejercitar cada descendiente en su contexto operacional).
Ac o p l a m i e n t o e n t r e c l a s e s d e o b j e t o s (AEC O ). El modelo de conj unt o de res-
puesta de una clase (CRC), expuest o en el captulo 8, se emplea para determinar el
valor de AECO. En esencia, AECO es el nmero de colaboraciones enlistadas, para
una clase, en su tarjeta de ndice CRC." A medida que AECO aument a, es probable
que disminuya la facilidad de reutilizacin de una clase. Valores elevados de AECO
tambin complican las modificaciones y la prueba que asegura que esas modifica-
ciones se han hecho. En general, para cada clase deben mant enerse los valores de
AECO en el valor ms baj o que sea razonable. Esto es consistente con la directriz
general para reducir el acoplamiento en el soft ware convencional.
Re s p u e s t a p a r a u n a c l a s e (RP C ). El conj unt o de respuesta para una clase es un
"conjunto de mt odos que tiene la posibilidad de ejecutarse como respuesta a un men-
saje que recibe un objeto de esa clase" [CH194]. La RPC es el nmero de mt odos en
el conjunto de respuesta. A medida que la RPC aument a, el esfuerzo requerido para
probar tambin lo hace, debido a que crece la secuencia de prueba (captulo 14).
Tambin se desprende que, a medida que la RPC aument a, se incrementa la comple-
jidad del diseo general de la clase.
Fa l t a d e c o h e s i n e n m t o d o s (FC M ). Cada mt odo dentro de una ciase, C , tie-
ne acceso a uno o ms atributos (tambin denominados variables de instancia) . La
FCM es el nmer o de mt odos que acceden a uno o ms de los mi smos atributos.12
Si ningn mt odo accede a los mismos atributos, ent onces FCM = 0. Para ilustrar el
caso donde FCM * 0, imagnese una clase de seis mtodos. Cuatro de ellos tienen
uno o ms atributos en comn (es decir, acceden a atributos comunes). Por tanto,
FCM = 4. Si la FCM es alta, los mt odos pueden acoplarse ent re s medi ant e atribu-
tos. Esto aument a la complejidad del diseo de clase. Aunque hay casos en que re-
11 Si las tarjetas de ndice CRC se desarrollan manualmente, el grado de avance y la consistencia de-
ben evaluarse ant es de determinar el AECO de manera confiable
12 La definicin formal es un poco ms compleja. Consltese [CHI94] para conocer ms detalles.
TM
PDF Editor
sulta justificable un valor elevado para la FCM. Lo deseable es mant ener alta la co-
hesin; es decir, conservar baja la FCM.13
Aplicacin de mtricas de
El e s c e n a r i o : Cubculo de Vinod.
Lo s a c t o r e s : Vinod, Shakira y Ed, integrantes del
equipo del software H o g a r S e g u r o , que siguen
trabajando en el diseo al nivel de componentes y de
casos de prueba. -SI ' i ^
t a c o n v e r s a c i n :
Vi nod: Tuvieron oportunidad de leer la descripcin de
lo coleccin de mtricas de CK que les envi el mircoles
y de hacer esas mediciones?
Sh a k i r a : No fue muy complicado. Regres a mis
diagramas de clase y de secuencia UML, como sugeriste, y
obtuve conteos elementales de APH, FPC y FCM. No pude
encontrar el modelo CRC, de modo que no cont AECO.
j a m i e ( s o n r i e n d o ) : No pudiste encontrar el modelo
CRC porque yo lo tena.
Sh a k i r a : Eso es lo que me encanta de este equipo, la
gran comunicacin.
Vi n o d : Yo hice mis conteos.,, desarrollaron cifras para
las mtricas de CK? | | | j
(Jamie y Ed asienten.)
Ja m i e : Como tena las tarjetas CRC, ech un vistazo al
AECO y pareca muy uniforme en casi todas las clases.
Hubo una excepcin, y la anot.
CK
Ed : Hay unas cuantas clases donde la RPC es muy
elevada, comparada con las asociaciones verdaderas...
tal vez debemos echar un vistazo para simplificarlas.
Ja m i e : Tal vez s, tal vez no. Todava estoy preocupada
por el tiempo, y no quiero corregir cosas que realmente
no estn mal.
Vi n o d : Estoy de acuerdo con eso. Tol vez debemos
buscor clases que tengan malos nmeros en al menos do>
o ms mtricas de CK. Digamos que si le pasan dos
slrikes, hay que modificarlas.
Sh a k i r a ( m i r a n d o l a l i s t a d e c l a s e s d e Ed c o n
a l t a RP C ): Mira, ves esta clase? Tiene una FCM alto,
adems de una RPC alta. Dos s l r i k e s ?
Vi n o d : S, as lo creo... por lo mismo, ser difcil de
implementar debido a la complejidad y dificultad de
probar. Tal vez valga la pena disear dos clases
separadas para alcanzar el mismo comportamiento.
Ja m i e : Crees que la modificacin nos ahorrar
tiempo?
Vi n o d : A la larga, s.
15.4.4 Mtricas orientadas a objetos: la coleccin de mtricas para el
diseo orientado a objetos
Harrison, Counsell y Nithi [HAR98] proponen un conjunto de mtricas para di sef :
orientado a objetos que proporcionan indicadores cuantitativos para las caracters-
ticas del diseo orientado a objetos. A continuacin se present e una pequea mues-
tra de est as mtricas:
13 La mtrica FCM proporciona conocimientos tiles en algunas situaciones, pero puede malinterpr-
tarse en otras. Por ejemplo, mantener el acoplamiento encapsulado dentro de una clase aumenta s
cohesin del sistema como un todo. Por tanto, por lo menos en un sentido importante, un FCM rr :
elevado en realidad sugiere que una clase puede tener una mayor cohesin, no una menor.
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO P ARA EL SOFTWARE 4 8 7
M t o d o d e l f a c t o r d e h e r e n c i a (M FH). El grado en que la arqui t ect ura de cl ases
de un si st ema ori ent ado a obj et os usa la herencia para mt odos (operaciones) y atri-
but os se defi ne como
MFH = IM, (C,)/X Ma{C )
donde la sumat ori a se present a desde i = 1 hast a Tc. Tc se define como el nmer o t o-
tal de cl ases en la arquitectura; C, es una clase dent ro de la arqui t ect ura y
M(C,) = MAC,) + M, (Q
donde
Ma(C ) = el nmer o de mt odos que pueden i nvocarse en asociacin con C .
MafCj) = el nmer o de mt odos decl arados en la clase C .
M(C ) = el nmer o de mt odos heredados (y no redefinidos) en C,.
El valor de MFH (el atributo de factor de herencia, AFH, se defi ne de maner a anl o-
ga) es un indicativo del i mpact o de la herenci a en el sof t war e ori ent ado a obj et os.
"El anlisis del soft ware ori ent ado a obj et os par a eval uar su calidad se est volviendo cada vez m s i mport ant e o
medido que el par adi gma [ori ent ado a obj et os] sigue ganando popul ari dad. "
;; ! , Ro c h e l Ha r r i s o n el al.
Fa c t o r d e a c o p l a m i e n t o (FA). Al principio de est e captulo se indic que el aco-
pl ami ent o es una indicacin de las conexi ones ent re el ement os de un di seo orien-
t ado a objetos. El conj unt o de mt ri cas del di seo ori ent ado a obj et os define el aco-
pl ami ent o de la siguiente maner a:
FA = S, I , es_cliente (C q) /{Tc2 - Tc)
donde las sumat ori as van desde i = 1 hast a Tc y desde j = 1 hast a Tc. La funcin
es_diente = 1, si y sl o si existe una relacin ent re la clase cliente, Cr, y la cla-
se servidor, Cs, y Cc # Cs
= 0, en cualquier ot ro caso
Aunque muchos fact ores afect an la complejidad, la facilidad de comprensi n y el
mant eni mi ent o del soft ware, resul t a razonabl e concluir que, a medi da que aument a
el valor de FA, t ambi n aument ar la complejidad del soft ware ori ent ado a obj et os
y, como consecuencia, es posible que resulten afect adas la facilidad de comprensi n y
mant eni mi ent o, junto con la posibilidad de reutilizacin.
Harrison y sus col egas [HAR98] present an una anlisis det al l ado de MFH y FA,
j unt o con ot ras mtricas, y exami nan su validez para empl earl os en la evaluacin de
la calidad del diseo.
TM
PDF Editor
4 8 8
( CONSEJ O^
Durante lo revisin del
modelo de anlisis,
las tarjetas de ndice
CHC proporcionarn
uno indicacin
razonable de los
valores esperados
para el tamao de la
clase. Sise encuentro
una cise con un
n mero grande de
responsabilidades,
pinsese en i
15.4.5 Mtricas orientadas a objetos propuestas por Lorenz y Kidd
En su libro sobre mtricas ori ent adas a objetos, Lorenz y Kidd [LOR94] dividen las
mtricas basadas en cl ases en cuat ro amplias categoras, cada una con un diseo al
nivel de component es: t amao, herencia, valores internos y valores externos. Las
mtricas ori ent adas al t amao aplicadas a una clase de di seo orientado a objetos
se concent ran en el cont eo de atributos y operaci ones de una clase individual, as;
como en valores promedi o para el sistema orientado a obj et os como un todo. Las
mtricas basadas en la herencia se concent ran en la manera en que las operaciones
se reutilizan en la jerarqua de clases. Las mtricas para los valores internos buscar
cohesin y aspect os ori ent ados al cdigo, y las mtricas de valores ext ernos exami
nan el acopl ami ent o y la reutilizacin. A continuacin se presenta una muest ra de
las mtricas propuest as por Lorenz y Kidd:
T a m a o d e l a c l a s e (T C ). El t amao general de una clase se determina con las
siguientes medidas:
El nmero total de operaci ones (de instancia heredada y privada) que estn
encapsul adas dent ro de la clase.
El nmero de atributos (de instancia heredada y privada) que est n encapsu
lados por la clase.
La mtrica MPC que propusieron Chi damber y Kemerer (seccin 15.4.3) tambie-
es una medi da ponderada de t amao de clase. Como ya se indic, los valores gran-
des de TC indican que tal vez una clase tenga demasi ada responsabilidad. Esto re-
ducir la posibilidad de reutilizacin de la clase y complicar la implementacin \
prueba. En general, debe drsele ms peso a las operaci ones y los atributos her eda!
dos o pblicos para determinar el t amao de la clase [LOR94]. Las operaci ones y ', :<
atributos privados permiten la especializacin y est n ms focalizados en el diser :
Tambin deben calcularse los promedi os para el nmero de atributos y operacior
de clase. Cuanto menor es sean los valores promedi o para el TC, ms probable ser
que las cl ases dent ro del sistema puedan reutilizarse ampl i ament e.
Nm e r o d e o p e r a c i o n e s a a d i d a s p o r u n a s u b c l a s e (NO A). Las subclases
especializan al agregar operaci ones y atributos. A medida que el valor de NOA a. *|
ment a, la subclase se aparta de la abstraccin implcita en la superclase. En gene
a medida que la profundidad de la jerarqua de clase aument a (APH se vuelve
yor), debe caer el valor de NOA en los niveles inferiores de la jerarqua.
15.4.6 Mtricas de diseo al nivel de componentes
Las mtricas de diseo al nivel de component es del soft ware convencional se c
centran en las caractersticas internas de un component e de soft ware e incluyen
didas de cohesin, acopl ami ent o y complejidad del mdulo. Estas medi das ayuda-
un ingeniero de soft ware a j uzgar la calidad de un diseo al nivel de component
TM
PDF Editor
CAPITULO 15 MTRI CAS DEL PRODUCTO P ARA EL SOFTWARE 489
Las mtricas present adas en esta seccin son de "caja de cristal", en el sentido de
que requieren conocimiento del funci onami ent o interno del mdulo que se est con-
siderando. Las mtricas de diseo al nivel de component es se aplican una vez que
se ha desarrollado el diseo procedimental. Como opcin, pueden demorarse hasta
que el cdigo fuente est disponible.
M t r i c a s d e c o h e s i n . Bieman y Ott 1B1E94] definen una coleccin de mtricas
que proporcionan una indicacin del grado de cohesin (captulo 9) de un mdulo.
Las mtricas se definen a partir de cinco concept os y medidas:
Porcin de datos. Definido simplemente, una porcin de dat os es un recorrido
hacia at rs por un mdulo; busca valores de dat os que afectan el est ado del mdu-
lo cuando comienza el recorrido. Debe indicarse que es posible definir las porcio-
nes del programa (que se concentran en instrucciones y condiciones) y las porcio-
nes de datos.
Muestras de datos. Las variables definidas para un mdulo se definen como
muest ras de dat os para el mdulo.
Seales de unin. Este conj unt o de muest ras de dat os cae en una o ms porcio-
nes de datos.
Seales de superunin. Estas muest ras de dat os son comunes a todas las porcio-
nes de datos de un mdulo.
Capacidad de unin. La capacidad de unin relativa de una seal de unin es di-
rectamente proporcional al nmer o de porciones de dat os que une.
Bieman y Ott desarrollan mtricas para cohesin funcional fuerte, cohesin funcional
dbil y adhesividad (que se relaciona con el grado en que las seales de unin integran
las porciones de datos). Estas mtricas se interpretan de la siguiente manera [BIE94]:
Todas es t as mt r i cas de cohesi n abar can val ores de 0 a 1. Tienen un val or de 0 cuando
un pr ocedi mi ent o cuent a con m s de una salida y no muest r a at ri but o al guno de cohesi n
i ndi cado por una mt ri ca part i cul ar. Un pr ocedi mi ent o sin s eal es de super uni n (es de-
cir, sin muest r as comunes a t odas las por ci ones de dat os), t i ene 0 cohesi n funci onal fuer-
te (no hay mues t r as de dat os que cont ri buyan a t odas las salidas). Un pr ocedi mi ent o sin
s eal es de uni n (es decir, sin mues t r as comunes a m s de una porci n de dat os, en pro-
cedi mi ent os con m s de una por ci n de datos) muest r a 0 cohesi n funci onal dbil y 0 ad-
hesi vi dad (no hay mues t r as de dat os que cont ri buyan a ms de una salida).
La cohesin funcional fuerte y la adhesividad se encuent ran cuando las mtricas de
Bieman y Ott toman un valor mximo de 1.
M t r i c a s d e a c o p l a m i e n t o . El acoplamiento del mdulo proporciona una indica-
cin de la "conectividad" de un mdulo con otros mdulos, con datos globales y con
el ent orno exterior. En el captulo 9 se analiz el acoplamiento desde el punt o de vis-
ta cualitativo.
TM
PDF Editor
Dhama [DHA95] ha propuesto una mtrica para el acoplamiento del mdulo que
abarca el acoplamiento de flujo de dat os y de control, el global y el de entorno. Lai
medi das necesarias para calcular el acoplamiento del mdulo se definen a partir ce |
cada uno de los tres tipos de acoplamiento indicados antes. En el caso del acopla-
miento de flujo de dat os y de control,
de = nmero de parmetros de dat os de entrada
ce = nmero de parmet ros de control de entrada
ds = nmero de parmetros de dat os de salida
cs = nmero de parmet ros de control de salida
En el caso del acoplamiento global:
gd = nmero de variables globales usadas como datos
gc = nmero de variables globales usadas como control
En el caso del acoplamiento de entorno:
w = nmero de mdulos llamados (dependencia hacia fuera)
r = nmero de mdulos que llaman al mdulo en cuestin (dependencia
dentro)
Con est as medi das se define un indicador de acoplamiento del mdulo, ma, de la
guiente manera:
m = k/M
donde k es una const ant e de proporcionalidad y
M = dc + (a x ce) + ds + (> x cs) + gd+ (c x gc) + w + r (15.
Los valores de k, a, b y c deben derivarse empricamente.
A medida que el valor de ma aument a, disminuye el acoplamiento general del
dulo. Para lograr que la mtrica de acoplamiento suba a medida que aument a el
do de acoplamiento, se define una mtrica de acoplamiento revisada
C = 1 - ma
donde el grado de acoplamiento aument a a medida que lo hacen las medidas
ecuacin (15.6).
M t r i c a s d e c o m p l e j i d a d . Es posible calcular diversas mtricas del soft
para det ermi nar la complejidad del flujo de control del programa. Muchas de
se basan en la grfica de flujo. Como se anal i z en el captulo 14, una grfica
una representacin compuest a de nodos y enl aces (tambin denomi nados ari
Cuando los enl aces (aristas) estn dirigidos, la grfica de flujo es una grfica
gida.
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO P ARA EL SOFTWARE 4 9 1
:LAVE
McCabe y Watson [MCC94] identifican varios usos importantes para las mtricas
de complejidad:
Las mt r i cas de compl ej i dad s e ut i l i zan par a pr edeci r la i nf or maci n cr tica acer ca de la
conf i abi l i dad y la faci l i dad de ma nt e ni mi e nt o de s i s t emas de s of t wa r e a par t i r del anl i si s
aut omt i co del cdi go f uent e [o la i nf or maci n del di s eo pr occdi mcnt al ] . Las mt r i cas de
compl ej i dad t ambi n of r ecen r et r oal i ment aci n dur a nt e el pr oyect o de s of t wa r e pa r a ayu-
dar a cont r ol ar [la act i vi dad del di seo) . Dur ant e l as pr ue ba s y el ma nt e ni mi e nt o, of r ecen
una i nf or maci n det al l ada acer ca de l os mdul os de s of t wa r e pa r a a yuda r a det ect ar r e a s
de posi bl e i nest abi l i dad.
La mtrica de complejidad cuyo uso es el ms extendido (y debatido) para el
soft ware de comput adora es la complejidad ciclomtica, originalmente desarrolla-
da por Thomas McCabe [MCC761, [MCC89], y que se anal i z con t odo detalle en el
captulo 14.
, Ci Zuse ([ZUS90], [ZUS97]) presenta un anlisis enciclopdico de no menos de 18
] solo GS uno
categoras diferentes de las mtricas de complejidad del software. El autor presenta
i de mtricas las definiciones bsicas de mtricas en cada categora (por ejemplo, hay distintas va-
t ::nplejidad. riaciones de la mtrica de complejidad ciclomtica) y luego analiza y critica cada
una. El t rabaj o de Zuse es el ms completo publicado a la fecha.
15.4.7 Mtricas orientadas a la operacin
Debido a que la clase es la unidad domi nant e en los sistemas orientados a objetos,
se han propuesto pocas mtricas para operaciones que residen dentro de la clase.
Churcher y Shepperd [CHU95] analizan est o cuando afirman: "Los resultados de es-
tudios recientes indican que los mt odos tienden a ser pequeos en cuant o al nme-
ro de instrucciones y a complejidad lgica [W1L93], lo que sugiere que la estructura
de conectividad de un sistema es ms importante que el contenido de los mdulos
individuales". Sin embargo, se apreciarn mejor las cosas si se exami nan las consul-
tas promedio de mt odos (operaciones). Tres mtricas simples, propuestas por Lo-
renz y Kidd [LOR94], resultan apropiadas:
T a m a o p r o m e d i o d e o p e r a c i n (T O p r o m ). Aunque las lneas de cdigo po-
dran usarse como indicador del t amao de operacin, la medida de lneas de c-
digo adolece de una serie de probl emas anal i zados en el captulo 22. Por ello, el
nmer o de mensaj es que enva la operacin proporciona una opcin al t amao de
operacin. A medida que aument a el nmero de mensajes enviados por una sola ope-
racin, es probable que las responsabilidades no se hayan asi gnado bien dent ro de
la clase.
C o m p l e j i d a d d e l a o p e r a c i n (C O ). La complejidad de una operacin se calcu-
la empl eando cualquier mtrica de complejidad propuesta para el soft ware conven-
cional [ZUS90], Debido a que las operaciones deben limitarse a una responsabilidad
especfica, el diseador debe esforzarse por mant ener la CO lo ms baja posible.
TM
PDF Editor
L os mtricas de
diseo de lo interfaz
son adecuadas, peco
sobie todo lo dems,
es necesario osegu-
rarse plenamente de
que la Interfaz le
gusto a los usuarios
finales y de que stos
se sienten cmodos
con los interacciones
requeridas.
PARTE DOS PRCTI CA DE LA I NGENI ER A DEL SOFTWARE
Nm e r o p r o m e d i o d e p a r m e t r o s d e l a o p e r a c i n (NP O p r o m ). Mientras ma
yor sea el nmer o de par met r os de la operacin, m s compl ej a ser la col aboraci c-
ent re los obj et os. En general, el NPOprom debe mant ener se lo ms baj o posible.
15.4.8 Mtricas de diseo de la interfaz de usuario
Aunque hay obras importantes que tratan el diseo de interfaces ser humano/ mqui r j
(captulo 12), se ha publicado relativamente poca informacin sobre mtricas que pr >
porcionen conocimientos profundos sobre la calidad y la facilidad de uso de la interfaz.
Sears [SEA93] sugiere que lo apropiado del formato (AF) es una mtrica de diseo va-
liosa para interfaces ser humano/ mqui na. Una GUI comn aplica entidades de forma-
to (iconos grficos, texto, mens, vent anas, etc.) para ayudar al usuario a completar t J
reas. Para realizar una tarea determinada con una GUI, el usuario debe pasar de uca
entidad de presentacin a la siguiente. La posicin absoluta y relativa de cada entidad
de presentacin, la frecuencia con que se emplea y el "costo" de la transicin de ui
entidad de format o a la siguiente contribuirn a determinar lo apropiado de la interis*|
"Aprender por lo menos un principio del di seo de interfaces de usuari o si echa la ropa en una l avadora. Si pone
demasi ada r opa, nado quedar limpio."
An n i i r :
Kokol y s us col egas [KOK95] defi nen una mt ri ca de cohesi n para las pant al l a
de la i nt erfaz de usuari o que mi de la conexi n relativa ent r e el cont eni do de u J
pant al l a y el de otra. Si los dat os (o el cont eni do adicional) pr esent ados en una paaj
talla pert enecen a un sol o obj et o i mport ant e de dat os (como se defini dent ro j a
model o de anlisis), la cohesi n de la interfaz para esa pantalla ser alta. Si se p
sent an muchos tipos di ferent es de dat os o cont eni dos y esos dat os se relacionan a a
di ferent es obj et os de dat os, la cohesi n de la i nt erfaz de usuari o ser baj a. Los aw
tores proporci onan model os emp ri cos para la cohesi n [KOK95].
Adems, las medi das di rect as de la interaccin con la i nt erfaz de usuari o se
cent ran en la medicin del t i empo requeri do para al canzar un escenari o o una
racin especficos, el t i empo requeri do para recuperarse de una condicin de e r - J
los cont eos de oper aci ones o t ar eas espec ficas requeri das para al canzar un casc a
uso, el nmer o de obj et os de dat os o cont eni do pr esent ados en una pantalla, la fem
sidad y el t amao del texto y muchos otros. Sin embargo, est as medidas directas denoi
est ar or gani zadas para crear mt ri cas de interfaz de usuari o que t engan un sigr a
cado y que lleven a mej orar la calidad, la facilidad de uso, o ambos el ement os de a
interfaz de usuario.
Es i mport ant e observar que la seleccin de un di seo de i nt erfaz grfica de u s J
rio puede det ermi narse a partir de mt ri cas como AF o la cohesi n de pantalla de a
interfaz de usuario, pero el rbitro final debe ser la ent rada del usuari o basada J
prot ot i pos de interfaz grfica de usuari o. Nielsen y Levy [NIE94] report an que "se : n
ne una probabilidad r azonabl ement e grande de xito si s e elige ent re las i n t e r f a ^
TM
PDF Editor
4 9 3
[diseos] basadas excl usi vament e en las opi ni ones de los usuarios. El des empeo
promedi o de las t ar eas de los usuari os y su satisfaccin subjetiva con una interfaz
grfica de usuari o tienen una el evada correlacin".
: de la interfoz
is, pero
-odo lo dems,
) asegu-
f Unamente de
r irteraz le
: 3 los usuarios
Y de que stos
i cmodos
s interacciones
La teora de Halstead de la "ciencia del soft ware" [HAL771 propuso las pri meras "le-
yes" anal t i cas para el sof t war e de comput adora. 14 Halstead asi gn leyes cuantitati-
vas al desarrol l o de est e sof t war e empl eando un conj unt o de medi das primitivas que
s e derivan despus de que se ha gener ado el cdigo, o se est i man una vez que el di-
seo est compl et o. Las medi das son:
n, = el nmer o de oper ador es distintos que apar ecen en un programa.
n 2 = el nmer o de oper andos distintos que apar ecen en un programa.
= el nmer o total de veces que apar ece el operador.
N 2 = el nmer o total de veces que apar ece el operando.
Halstead aplica est as medi das primitivas para desarrollar expresi ones relacionadas
con la longitud global del programa, el volumen m ni mo posible para un algoritmo, el
vol umen real (nmero de bits requeridos para especificar un programa), el nivel del
programa (una medi da de la complejidad del software), el nivel del lenguaje (una
const ant e para un l enguaj e det ermi nado) y ot ras caractersticas como esfuerzo de de-
sarrollo, t i empo de desarrollo y hast a el nmer o proyectado de fallas en el software.
Halstead demuest r a que la longitud N se puede est i mar as:
N = n , log2 n , + n 2 log2 n 2
y que el vol umen de pr ogr ama s e puede definir como:
V = N log2 (r?i + n 2 )
Se debe observar que V variar de acuerdo con el l enguaj e de programaci n y que re-
present a el vol umen de informacin (en bits) necesari o para especificar un programa.
rl 1 1
El conjunto de regios que sigue el cerebro hume
no Lpara el desarrollo de algoritmos] es mas rgido de lo que suele
pensarse. "
M a u r c e Ha l s t e a d
En teora, debe existir un vol umen m ni mo para un al gori t mo det ermi nado. Hals-
tead defi ne una relacin de vol umen, L, como la relacin ent r e el vol umen de la for-
ma m s compact a de un pr ogr ama y el vol umen real del programa. En realidad, L
si empre debe ser menor que 1. Desde el punt o de vista de las medi das primitivas, la
relacin de vol umen s e expresa como
14 Debe observarse que las "leyes" de Halstead han generado gran controversia, y muchos creen que
la teora tiene fallas Sin embargo, se ha realizado la verificacin experimental de lenguajes de pro-
gramacin seleccionados (por ejemplo, [FEL8911
TM
PDF Editor
4 9 4 PARTE DOS PRCTI CA DE LA INGENIERA DEL SOFTWARE
L = 2 /n, x n2 /N2
El t rabaj o de Halstead es sensible a la verificacin experi ment al , y s e ha realiza-
do una gran cant i dad de investigacin sobre la ciencia del soft ware. Para obt ener
ms informacin, consl t ense [ZUS90], [FEN91] y [ZUS97].
<s*
CLAVE
Los mtricos de pruebo
se agrupan en dos
amplias categoras:
1) las que tratan de
predecli el nmero
probable de pruebas
que se requieren a
varios niveles de
prueba, y 2) las que
se concentran en la
cobertura de la prueba
para un componente
determinado.
Aunque se ha escrito mucho sobr e las mt ri cas del sof t war e para pr uebas (por ejem-
plo, [HET93]), casi t odas las mt ri cas propuest as s e concent r an en el proceso de
prueba, no en las caract er st i cas t cni cas de las propi as pruebas. En general, quie-
nes apl i can las pr uebas deben depender de las mt ri cas de anlisis, di seo y cdigc
como gua para el di seo y la ejecucin de los casos de prueba.
Las mt ri cas basadas en la funci n (seccin 15.3.1) se aplican para predecir el es-
fuerzo general de la prueba. Es posible recopilar vari as caracter sticas al nivel de.
proyect o (como el esf uer zo y el t i empo para las pruebas, los errores descubiertos, e.
nmer o de casos de prueba producidos) de proyect os ant eri ores y correlacionarlas
con el nmer o de punt os de funcin que pr oduce un equi po de proyecto. Este equi-
po tiene la opcin posterior de proyectar "valores esper ados" de est as caractersticas
para el proyect o actual.
Las mt ri cas del di seo arqui t ect ni co proporci onan i nformaci n sobr e la facili-
dad o la dificultad asoci ada con la prueba de integracin (captulo 13) y la necesi da:
de cont ar con sof t war e especi al i zado en pr uebas (por ejemplo, r esguar dos y cont r; -
ladores). La complejidad ciclomtica (una mtrica de di seo al nivel de componer -
tes) cae en el eje de las pr uebas de cami no bsico, un mt odo de di seo de casos de
prueba pr esent ado en el captulo 14. Adems, la complejidad ciclomtica se emplea
para det ermi nar los mdul os que sern candi dat os a pruebas de unidad m s ext er
sas. Los mdul os con el evada complejidad ciclomtica son ms pr opensos a errcr
que los que tienen una menor complejidad. Por ello, la per sona responsabl e de -a
prueba debe realizar un esf uer zo superi or al promedi o para descubrir errores en es-
tos mdul os ant es de integrarlos en un si st ema.
15.6.1 Mtricas de Halstead apl i cadas a las pruebas
Tambin es posible est i mar el esf uer zo que requi eren las pr uebas medi ant e mtricas
deri vadas de las medi das de Halstead (seccin 15.5). Si se aplican las definiciones ddi
vol umen, V, y el nivel de un programa, NP, el esf uer zo de Halstead, e, se calculaba
as:
NP = l / [(7 i , / 2 ) x (N2 /n2 ) ]
e = V/NP
(15. 7a|
(15.7bJ
El por cent aj e del esf uer zo general de prueba que se debe asi gnar a un k se estima -]
ra con la siguiente relacin:
porcent aj e de esf uer zo de prueba {k) = e( k) / ê( i ) (15.8
donde e(k) se calcula par a el mdul o k empl eando las ecuaci ones (15.7), y donde
TM
PDF Editor
CAPTULO 15 MTRI CAS DEL PRODUCTO P ARA EL SOFTWARE 495
*
[CONSEJO
i orientada a
i a ser
1 :3 7 ipiejo. L os
s ayudarn a
ros recursos
: xuebo a subpro-
, escenarios y
s de closes
'sospe-
s'con base en
s znxtersticos
. Es recomen-
i usados.
sumatoria en el denomi nador de la ecuacin (15.8) es la suma del esfuerzo de Hals-
tead en todos los mdulos del sistema.
15.6.2 Mtricas para pruebas orientadas a objetos
Las mtricas del diseo orientado a objetos expuest as en la seccin 15.4 proporcio-
nan una indicacin de la calidad del diseo. Tambin proporcionan una indicacin
general de la cantidad de esfuerzo necesario en la prueba para ejercitar un sistema
orientado a objetos.
Binder [B1N94] sugiere una amplia serie de mtricas de diseo que tienen una in-
fluencia directa sobre la "facilidad de prueba" de un sistema orientado a objetos. Las
mtricas toman en cuenta aspect os de encapsul ami ent o y herencia. A continuacin
se presenta una muestra:
Fa l t a d e c o h e s i n e n m t o d o s (FC M ). ' 5 Mientras mayor sea el valor de FCM, deben
probarse ms estados para asegurar que los mtodos no generen efectos colaterales.
P o r c e n t a j e p b l i c o y p r o t e g i d o (P YP ). Esta mtrica indica el porcentaje de atri-
butos de clase que son pblicos o estn protegidos. Valores elevados de PYP aumen-
tan la probabilidad de efectos colaterales entre clases porque los atributos pblicos
o protegidos conllevan una alta probabilidad de acoplamiento (captulo 9).16 Deben
disearse pruebas para asegurar el descubrimiento de est os efectos colaterales.
In t e g r a n t e s d e a c c e s o p b l i c o a d a t o s (AP D ). Esta mtrica indica el nmer o
de clases (o mtodos) al que tienen acceso otros atributos de clase, lo que es una
violacin del encapsulamiento. Valores elevados de APD conllevan la posibilidad de
efectos colaterales entre clases. Deben disearse pruebas para asegurar el descubri-
miento de est os efectos colaterales.
Nm e r o d e c l a s e s r a z (NC R). Esta mtrica es un conteo de las distintas jerar-
quas de clase descritas en el model o de diseo. Deben desarrollarse conj unt os de
prueba para cada clase raz y para la jerarqua de clases correspondiente. A medida
que aument e el NCR, tambin aument ar el esfuerzo de la prueba.
D e p e n d e n c i a h a c i a d e n t r o (FIN). Cuando se aplica en el contexto orientado a
objetos, la dependencia hacia dentro para la jerarqua de herencia es un indicador
de herencia mltiple. FIN > 1 indica que una clase hereda sus atributos y operacio-
nes a partir de una clase raz. Debe evitarse que FIN > 1 a toda costa.
Nm e r o d e d e s c e n d i e n t e s (ND D ) y r b o l d e p r o f u n d i d a d d e h e r e n c i a (AP H). 1 7
Como se analiz en el captulo 14, es necesario volver a probar los mt odos de la
superclase de cada subclase.
15 Consltese la seccin 15.4.3 para conocer una descripcin de FCM.
16 Algunas personas promueven diseos en que ninguno de los atributos es pblico o privado; es decir,
PYP = 0. Esto indica que todos los atributos deben accederse en otras clases por medio de mtodos.
17 Consltese la seccin 15.4.3 para conocer una descripcin de NDD y APH.
TM
PDF Editor
Todas las mtricas del soft ware present adas en est e captulo se aplican tambin a
desarrollo de nuevo soft ware y al mant eni mi ent o del existente. Sin embargo, se har
propuest o mtricas di seadas explcitamente para actividades de mant eni mi ent o
El IEEE Std. 982.1-1988 [IEE94] sugiere un ndice de madurez del soft ware (IMS
que proporciona una indicacin de la estabilidad de un product o de soft ware (basa
da en los cambi os que ocurren con cada versin del producto). Se determina la s
guente informacin:
MT = el nmero de mdulos en la versin actual
Fc = el nmero de mdulos cambi ados en la versin actual
Fa = el nmero de mdul os aadi dos a la versin actual
Fd = el nmero de mdulos de la versin anterior que se eliminaron en la acta
El ndice de madurez del soft ware se calcula de la siguiente manera:
IMS = [MT-(Fa + Fc + Fd) ]/ Mr
A medida que el IMS se acerca a 1.0, el producto empi eza a estabilizarse. El IMS tam
bin se aplica como mtrica para la planeacin de actividades de mant eni mi ent o de
software. El tiempo medio para producir una versin de un producto de software
puede correlacionarse con el IMS, y pueden desarrollarse modelos empricos para e-,
esfuerzo de mantenimiento.
Mtricas del producto
O b j e t i v o : Ayudar a los ingenieros de
software en el desarrollo de mtricas
significativas que evalen los productos del trabajo
generados durante el modelado de anlisis y diseo, la
generacin de cdigo fuente y la prueba.
M e c n i c a : Las herramientas de esta categora abarcan
una amplia serie de mtricas y se implementan como
aplicaciones independientes o (con mayor frecuencia)
como funcionalidad que existe dentro de las herramientas
para anlisis y diseo, codificacin o prueba. En la mayor
parte de los casos, la herramienta de mtrica analiza una
representacin del software (por ejemplo, un modelo UML
o el cdigo fuente) y desarrolla una o ms mtricas.
He r r a m i e n t a s r e p r e s e n t a t i v a s ' 8
K rakatau Metrics, desarrollada por Power Software
(www.powersoftware.com/products), calcula mtricas
de complejidad, Halstead y otras relacionadas para
C/C++ y Java.
Metrics4C, desarrollada por +1 Software Engineering
(www.plus-one.com/Metrics4C-fact_sheet.html), calcula
varias mtricas arquitectnicas, de diseo y orientadas
a cdigo, adems de otras orientadas a proyecto.
Rationol Rose, desarrollada por Rational Corporation
(www.rational.com), es un conjunto de herramientas
completas para el modelado UML que incorpora varias
caractersticas de anlisis de mtricas.
RSM, desarrollada por M-Squared Technologies
(msquaredtechnologies.com/m2rsm/index.html),
calcula una amplia variedad de mtricas orientadas a
configuracin para C, C++ y Java.
Understand, desarrollada por Scientific Toolworks, Inc.
(www.scitools.com), calcula las mtricas orientadas a
cdigo para diversos lenguajes de programacin.
18 Las herramientas expuestas representan una muestra de esta categora. En casi todos los casos los
nombres de las mismas son marcas registradas de sus respectivos desarrolladores.
TM
PDF Editor
Las mtricas del software proporcionan una manera cuantitativa de evaluar la cali-
dad de los atributos internos de un producto, lo que permite que un ingeniero de
soft ware evale la calidad ant es de construirlo. Las mtricas proporcionan los cono-
cimientos necesarios para crear modelos efectivos de anlisis y diseo, un cdigo
slido y pruebas exhaustivas.
Para que resulte til en la realidad, una mtrica del soft ware debe ser simple y cal
culable, persuasiva, consistente y objetiva. Debe ser independiente del lenguaje de
programacin y proporcionar retroalimentacin efectiva al ingeniero del software.
Las mtricas para el modelo de anlisis se concentran en la funcin, los datos y el
comportamiento (los tres componentes del modelo de anlisis). Las mtricas para el di-
seo consideran los aspectos del diseo de la arquitectura, al nivel de component es
y de la interfaz. Las mtricas del diseo de la arquitectura consideran los aspectos es-
tructurales del model o de diseo. Las mtricas de diseo al nivel de component es
indican la calidad del mdulo al establecer medidas indirectas para la cohesin, el
acoplamiento y la complejidad. Las mtricas de diseo de la interfaz de usuario pro-
porcionan un indicio de la facilidad con que se usa la interfaz grfica del usuario.
Las mtricas para los sistemas orientados a objetos se concent ran en la medicin
que puede aplicarse a las caractersticas de clase y diseo (localizacin, encapsula-
miento, ocultamiento de informacin, herencia y tcnicas de abstraccin de objetos)
que convierten a la clase en nica.
Halstead proporciona un conjunto interesante de mtricas al nivel de cdigo fuen-
te. Empleando el nmer o de operadores y operandos presentes en el cdigo, se de-
sarrolla una variedad de mtricas para evaluar la calidad del programa.
Pocas mtricas del producto se han propuesto para emplearlas directamente en
las pruebas del soft ware y en el mantenimiento. Sin embargo, muchas otras mtri-
cas del producto pueden aplicarse para guiar el proceso de prueba y como mecanis-
mo para evaluar la facilidad de mantenimiento de un programa de cmputo. Una
amplia variedad de mtricas orientadas a objetos se ha propuesto para evaluar la fa-
cilidad de prueba de un sistema orientado a objetos.
: #l | l l !| | j
[ALB79] Albrecht, A. ). , "Measuri ng Application Devel opment Productivity", en Proc. IBM Appli-
cation Development Symposium, Monterey, CA, oct ubr e de 1979, pp. 83-92.
[ALB83] Albrecht, A. J. y ) . E. Gaffney, "Soft ware Function, Source Lines of Code and Devel op-
ment Effort Prediction: A Soft ware Sci ence Validation". en IEEE Trans. Software Engineering,
novi embr e de 1983, pp. 639-648.
[BAS84] Basili, V. R. y D. M. Weiss, "A Met hodol ogy for Collecting Valid Sof t war e Engi neeri ng
Data", en IEEE Trans. Software Engineering, vol. SE-10. 1984, pp. 728-738.
[BER95) Berard, E., "Metrics for Obj ect -Ori ent ed Sof t war e Engineering", publ i caci n de Internet
en comp. sof t war e- eng, 28 de enero, 1995
[BIE94] Bi eman, J. M. y L. M. Ott, "Measuri ng Functional Cohesi on". en IEEE Trans. Software En
gineering, vol. SE-20, nm. 8, agost o de 1994, pp 308-320.
TM
PDF Editor
4 9 8
PARTE DOS PRCTI CA DE LA INGENIERA D A SOFTWARE
[BIN94] Binder, R. V., "Obj ect -Ori ent ed Sof t war e Testing", en CACM, vol. 37, nm. 9, sept i embre
de 1994, p. 29.
[BRI96] Briand, L. C S. Morasca y V. R. Basili, "Propert y-Based Sof t war e Engi neeri ng Measure-
ment ", en IEEE Trans. Software Engineering, vol. SE-22, nm. 1, ener o de 1996, pp. 68-85.
[CAR90] Card, D. N. y R. L. Glass, Measuring Software Design Quality, Prentice-Hall, 1990.
[CAV78] Cavano, J. P. y J. A. McCall, "A Framework for t he Measur ement of Sof t war e Quality
Proc. ACM Software Quality Assurance Workshop, novi embr e de 1978, pp. 133-139.
[CHA891 Charet t e, R. N., Software Engineering Risk Analysis and Management, McGraw-Hill/Inte--
text, 1989.
[CH194] Chi damber, S. R. y C. F. Kemerer, "A Metrics Suite for Obj ect -Ori ent ed Design", en /
Trans. Software Engineering, vol. SE-20, nm. 6, j uni o de 1994, pp. 476-493.
[CH198] Chi damber, S. R., D. P. Darcy y C. F. Kemerer, "Management Use of Metrics for Obj ec- :
Ori ent ed Soft ware: An Exploratory Analysis", en IEEE Trans. Software Engineering, vol. SE-2- J
nm. 8, agost o de 1998, pp. 629-639.
[CHU95] Churcher, N. I. y M. J. Shepperd, "Toward a Concept ual Fr amewor k for Object-Orie-
Metrics", en ACM Software Engineering Notes, vol. 20, nm. 2, abril de 1995, pp. 69-76.
[CUR80] Curts, W., "Management a nd Experi ment at i on in Sof t war e Engineering", en Proc. I.
vol. 68, nm. 9, sept i embr e de 1980.
[DAV93] Davis, A. el al., "Identitying and Measuri ng Quality in a Sof t war e Requi r ement s S~
fication", en Proc. First Intl. Software Metrics Symposium, IEEE, Baltimore, MD, mayo de 1
pp. 141-152.
[DEM8I] DeMillo, R. A. y R. J. Lipton, "Soft ware Project Forecasting", en Software Metrics (A
Perlis, F. G. Sayward y M. Shaw, eds.), MIT Press, 1981, pp. 77-89.
| DEM82j DeMarco, T., Controlling Software Projects, Yourdon Press, 1982.
[DHA95] Dhama, H "Quant i t at i ve Model s of Cohesi on and Coupling in Soft ware", en Journal
Systems and Software, vol. 29, nm. 4, abril de 1995.
[EJI91] Ejiogu, L., Software Engineering with Foimal Metrics, QED Publishing, 1991.
[FEL89J Felican, L. y G. Zal at eu, "Validating Hal st ead' s Theory for Pascal Programs", en f
Trans. Software Engineering, vol. SE-15, nm. 2, di ci embre de 1989, pp. 1630-1632.
[FEN91] Fent on, N., Software Metrics, Chapman and Hall, 1991.
[FEN94] Fent on, N "Sof t war e Measur ement : A Necessary Scientific Basis", en IEEE Trans.
ware Engineering, vol. SE-20, nm. 3, ma r z o de 1994, pp. 199-206.
[GRA87] Grady, R. B. y D. L. Caswell, Software Metrics: Establishing a Company-Wide
[HAL77] Halstead, M., Elements of Software Science, North-Holland, 1977.
[HAR98J Harrison, R S. J. Counsell y R. V. Nithi, "An Eval uat i on of t he MOOD set of Ob;~
Ori ent ed Sof t war e Metrics", en IEEE Trans. Software Engineering, vol. SE-24, nm. 6, junio
1998, pp. 491-496.
[HET93] Hetzel, B., Making Software Measurement Work, QED Publishing, 1993.
[IEE93] IEEE Standard Glossaiy of Software Engineering Terminology, IEEE, 1993.
[IEE94] Software Engineering Standards, edi ci n 1994, IEEE, 1994.
[IFPOl] Function Point Counting Practices Manual, versi n 4.1.1, Int ernat i onal Funct i on
Users Group, 2001, di sponi bl e en ht t p: / / www. i f pug. or g/ publ i cat i ons / manual . ht m.
[IFP03] Funct i on Point Bi bl i ography/ Reference Library, Int ernat i onal Funct i on Point U
Group, 2003, di sponi bl e en ht t p: / / www. i f pug. or g/ about / bi bl i ogr aphy. ht m.
[KOK95] Kokol, P l. Rozman y V. Venuti, "User Int erface Metrics", ACM SIGPL AN Notices, vol
nm. 4, abril de 1995, puede descar gar se de: ht t p: / / por t al . acm. or g/ .
[KYB84J Kyburg, H. E Theoiy and Measurement, Cambri dge University Press, 1984.
[LET03] Lethbridge, T comuni caci n pri vada sobr e mt r i cas de sof t war e, junio de 2003.
LON02] Longst reet , D., "Fundament al of Funct i on Point Analysis", Longst reet Consulting,
2002, di sponi bl e en ht t p: / / www. i f pug. com/ f paf und. ht m.
[LOR94] Lorenz, M. y J. Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994.
[MCC76] McCabe, T. J "A Sof t war e Complexity Measure", en IEEE Trans. Software Engin
vol. SE-2, di ci embre de 1976, pp. 308-320.
|MCC77) McCall, J., P. Ri chards y G. Walters, "Factors in Sof t war e Quality", t res vol menes,
AD-A049-014, 015, 055, novi embr e de 1977.
TM
PDF Editor
C A P T U L O 1 5 MTRICAS DEL PRODUCTO PARA EL SOFTWARE 499
[MCC89I McCabe, T. J. y C. W. Butler, "Design Complexity Measur ement and Testing", en CACM,
vol. 32, nm. 12, di ci embre de 1989, pp. 1415-1425.
[MCC94] McCabe, T. J. y A. H. Wat son, "Soft ware en Complexity", en Crosstalk, vol. 7, nm. 12,
di ci embre de 1994, pp. 5-9.
[NIE94] Nielsen, J. y J. Levy, "Measuri ng Usability: Preference vs. Performance", en CACM, vol. 37,
nm. 4, abril de 1994, pp. 65-75.
[ROC94) Roche, J. M., "Sof t war e Metrics and Measur ement Principies", e n Software Engineering
Notes, ACM, vol. 19, nm. 1, ener o de 1994, pp. 76-85.
[SEA93] Sears, A., "Layout Appropri at eness: A Metric for Eval uat i ng User Int erface Widget La-
yout", en lEEETTans. Software Engineering, vol. SE-19, nm. 7, julio de 1993, pp. 707-719.
(SHE98) Sheppard, M Goal, Question, Metric, 1998, disponible en ht t p: / / dec. bour nemout h. ac. uk/
ESERG/ mshepperd/ SEMGQM .html
ISOL99] Van Sol i ngen, R. y E. Berghout , The Goal/Queston/Metric Method, McGraw-Hili, 1999.
[UEM99] Uemura, T., S. Kusumot o y K. Inoue, "A Funct i on Point Measur ement Tool for UML De-
sign Specifications", en Proc. Of Sixth International Symposium on Software Metrics, IEEE, no-
vi embr e de 1999, pp. 62-69.
[USA87] Management Quality Insight, AFCSP 800-14 (U.S. Air Forc), 20 de ener o de 1987.
[WHI97] Whitmire, S Object Oriented Design Measurement, Wiley, 1997.
[WIL93] Wilde, N. y R. Huitt. "Maintaining Obj ect -Ori ent ed Soft ware", en IEEE Software, ener o de
1993, pp. 75-80.
[ZUS90] Zuse, H., Sofhvare Complexity: Measures and Methods, DeGruyter, 1990.
[ZUS97] Zuse, H., A Framework of Software Measurement, DeGruyter, 1997.
15. 1. La teora de la medi ci n es un t ema avanzado que tiene una fuert e influencia sobr e l as
mt r i cas del sof t war e. Utilizando [ZUS97], [FEN91], [KYB84) u ot r as fuent es, escribir un breve
ens ayo que del i nee los pri nci pal es pri nci pi os de la teora de la medi ci n. Proyect o individual: de-
sarrol l ar una pr esent aci n sobr e el t ema y pr esent ar l a ant e la cl ase.
15. 2. Los fact ores de calidad de McCall se desarrol l aron dur ant e la dcada de 1970. Casi t odos
l os aspect os de la comput aci n han cambi ado dr st i cament e desde que se desarrol l aron; sin
embar go, los fact ores de McCall si guen apl i cndose al sof t war e moder no. Podra llegarse a al-
gunas concl usi ones a part i r de est e hecho?
15. 3. Por qu no se puede desarrol l ar una sola mt ri ca que lo abar que t odo para la compl ej i -
dad o la calidad de un pr ogr ama?
15. 4. Trt ese de desarrol l ar una medi da o una mt ri ca t omada de la vida real que viole los atri-
but os de l as mt r i cas efect i vas del sof t war e que se defi ni eron en la secci n 15.2.5
15. 5. Un si st ema t i ene 12 ent r adas ext ernas, 24 sal i das ext ernas, c a mpos para 30 consul t as ex-
t ernas di ferent es, manej a cuat r o ar chi vos l gi cos ext er nos y t i ene i nt erfaces con sei s si st emas
her edados di f er ent es (6 A1E). Todos est os dat os t i enen una compl ej i dad promedi o, y el si st ema
general es r el at i vament e si mpl e. Cal cl ese el punt o de funci n par a el si st ema.
15. 6. El sof t war e para el Si st ema X t i ene 24 requi si t os f unci onal es i ndi vi dual es y 14 no funci o-
nal es. Cul es la especificidad de los requi si t os? En qu gr ado se ha compl et ado?
15. 7. Un i mpor t ant e si st ema de i nformaci n t i ene 1140 mdul os; 96 mdul os real i zan f unci o-
nes de control y coordi naci n, y 490 dependen de un pr ocesami ent o anterior. El si st ema procesa
al rededor de 220 obj et os de dat os, cada uno con un pr omedi o de t res at ri but os. Hay 140 el e-
ment os ni cos de la bas e de dat os y 90 s egment os di f er ent es de st a. Por ltimo, 600 mdul os
t i enen punt os ni cos de ent r ada y sal i da. Calclese el 1CED del si st ema.
15. 8. Una clase, X, t i ene 12 oper aci ones. Se ha cal cul ado la compl ej i dad ci cl omt i ca para t o-
das l as oper aci ones del si st ema or i ent ado a obj et os, y el valor pr omedi o de la compl ej i dad del
mdul o es de 4. Para la cl ase X, la compl ej i dad de la oper aci n 1 a la 12 es 5, 4, 3, 3, 6, 8, 2, 2,
5, 5, 4 y 4, r espect i vament e. Cal cl ense los mt odos ponder ados por clase.
TM
PDF Editor
Hay un nmer o s or pr endent ement e gr ande de libros dedi cados a l as mt r i cas del sof t war e,
que la mayor part e de el l os se concent r a en l as mt r i cas del pr oceso y el proyect o, por lo
excl uyen l as mt r i cas del product o. Kan (Metrics and Models in Software Quality Engineering,
dison-Wesley, s egunda edi ci n, 2002), Fent on y Plleeger (Sof t ware Metrics: A Rigourous and
tical Approach, Brooks-Cole Publishing, 1998) y Zuse ZUS97] han escri t o t r at ami ent os co
t os de l as mt r i cas del product o.
Libros de Ca r dy Gl ass 1CAR90], Zuse [ZUS90], Fent on (FEN91], Ejiogu (EJI91], Moel l er y
lish (Software Metrics, Chapman y Hall, 1993) y Hetzel [HET93] at i enden l as mt r i cas del pr~
t o con al gn det al l e. Or nan y Pfleeger (Applyig Software Metrics, IEEE Comput er Society "
1997) han edi t ado una ant ol og a de art cul os i mpor t ant es sobr e l as mt r i cas del sof t war e
ms, val e la pena exami nar l os si gui ent es libros:
Cont, S. D., H. E. Dunsmor e y V. Y. Shen, Software Engineering Metrics and Models,
mi n- Cummi ngs, 1984.
Grady, R. B Practica! Software Metrics for Project Management and Process Improvement,
tice-Hall, 1992. Sheppard, M Software Engineering Metrics, McGraw-Hill, 1992.
Denvir, Her mn y Whitty pr esent an la t eor a de la medi ci n del s of t war e en una col"
edi t ada de art cul os (Proceedings of the International BCS-FACS Workshop: Formal Aspects of
surement, Springer-Verlag, 1992). Shepper d (Foundations of Software Measurement, Prer
Hall, 1996) t ambi n at i ende con ci ert o det al l e la t eor a de la medi ci n. El es t ado act ual de !a
vest i gaci n se pr esent a en los Proceedings of the Symposium on Software Metrics (IEEE, p
dos anual ment e) .
Un r es umen muy compl et o de docenas de mt r i cas de s of t war e tiles s e pr esent a en [I
En general , un anl i si s de cada mt ri ca s e ha r educi do a los "primitivos" (las medi das) es
les necesar i os para cal cul ar la mt ri ca y l as r el aci ones apr opi adas para real i zar el clculc
apndi ce pr opor ci ona un anl i si s y muc ha s referenci as.
Whitmire [WHI97] pr esent a el t r at ami ent o m s compl et o y mat emt i cament e sofistic
l as mt r i cas or i ent adas a obj et os que se haya publ i cado a la fecha. Lor enzy Kidd [LOR94] y
dersen-Sel l ers (Object-Oriented Metrics: Measures ofComplexity, Prentice-Hall, 1996) of r c:
ni co libro adi ci onal dedi cado a l as mt r i cas or i ent adas a obj et os. Hut cheson (Software Te
Fundamentis: Methods and Metrics, Wiley, 2003) pr esent a una gua til par a la aplicacin
us o de mt r i cas par a la pr ueba del sof t war e.
Una ampl i a vari edad de f uent es de i nformaci n sobr e mt r i cas del sof t war e se en
di sponi bl e e n Internet. Una lista act ual i zada de referenci as en la World Wide Web rel evant es
ra l as mt r i cas del s of t war e se encont r ar en el sitio Web de SEPA:
ht t p: / / www. mhhe. com/ pr es s man.
TM
PDF Editor
Tres
APLI CACI N
DE LA I NGENI ER A WE B
E
n esta parte de Ingeniera del software: un enfoque prctico,
se aprendern los principios, conceptos y mtodos con que
se crean aplicaciones Web de alta calidad. Las siguientes
preguntas se abordan en los captulos posteriores:
Las aplicaciones Web (WebApps) son diferentes de otros
tipos de software?
Qu es la ingeniera Web y qu elementos de la prctica de
la ingeniera del software puede adoptar?
Cules son los elementos de un proceso de ingeniera Web?
Cmo se formula y planea un proyecto de ingeniera Web?
Cmo se analizan y modelan los requisitos de las WebApps?
Qu conceptos y principios guan la prctica en el diseo de
las WebApps?
Cmo se dirigen la arquitectura, la interfase y el diseo de
navegacin de las WebApps?
Qu tcnicas de construccin se pueden aplicar para imple-
mentar el modelo del diseo?
Qu conceptos, principios y mtodos de prueba son aplica-
bles a la ingeniera Web?
Una vez respondidas estas preguntas se estar mejor prepara-
do para realizar la ingeniera de aplicaciones Web de alta calidad.
501
TM
PDF Editor
C A P I T U L O
A
CONCEPTOS
C L A V E
criterios
de calidad 513
ingeniera Web
herramientas .508
mtodos 507
proceso 507
marco de trabajo
del proceso . . . .509
mejores
prcticas 512
preguntas
bsicas SU
WebApps
atributos . . . .504
(alegoras . . . 506
I NGENI ER A
WE B
L
a World Wide Web y la Internet que la alimentan son, posiblemente, los de
sarrollos ms i mport ant es en la historia de la computacin. Estas tecnolc
gas han llevado a todos (con cientos de millones ms que eventualmem
seguirn) a la era de la informtica; adems, se han convertido en parte integn
de la vida diaria en la primera dcada del siglo xxi.
Para qui enes pueden recordar un mundo sin la Web, el crecimiento cat:;
de la tecnologa tiene su origen en otra era: los primeros das del software. Er
una poca de poca disciplina pero enorme ent usi asmo y creatividad. Eran tierr
pos en que los programadores a menudo ingresaban a sistemas en conjunto, a ve
ees para bien, a veces para mal. La actitud prevaleciente pareca ser: "hazlo ra
pido y entra en el campo; nosot ros lo limpiaremos (y mejor ent i ende qu es i
que realmente se necesita construir) conforme avancemos". Suena familiar -
En una mesa redonda virtual publicada en IEEE Sofhvare [PRE98], mantuv
firme mi posicin en relacin con la ingeniera Web:
Me parece que cualquier producto o sistema importante vale la pena una ingeniera
Antes de comenzar a construirla es mejor que entienda el problema, disee una so-
lucin factible, la implemente en una forma slida y la ponga a prueba ampliamente
Tal vez tambin tenga que controlar los cambios conforme el trabajo avance y dispo-
ner de algn mecanismo para asegurar la calidad del resultado final. Muchos desa-
rrolladores de Web no estn de acuerdo con esto; ellos piensan que su mundo
realmente es diferente y que los enfoques convencionales de ingeniera del software
simplemente no se aplican.
Q u e s ? Los si st emas y apl i caci o-
nes b a s a d o s en We b ( We bApps )
of r ecen un c ompl e j o a r r e gl o d e con-
t eni do y f unc i ona l i da d a u n a a mpl i a
pobl aci n d e us uar i os f i nal es. La
i ngeni er a We b ( I Web) e s el p r o c e s o con el q u e
se c r e a n We b Ap p s d e al t a c a l i da d. La ! We b no
e s un cl on per f ect o d e la i ngeni er a del sof t wa-
re, p e r o t o ma pr e s t a d os muchos c onc e pt os y
pr i nci pi os f unda me nt a l e s d e el l a. Ad e m s , el
pr oc e s o I We b a c e n t a act i vi dades t cni cas y
admi ni s t r at i vas si mi l ar es. Existen sutiles di f er en-
ci as en la ma n e r a c o mo s e di r i gen di chas activi-
d a d e s , p e r o el m t o d o pr i mor di al di ct a un enf o-
q u e di s ci pl i nado p a r a el des ar r ol l o d e un siste-
ma b a s a d o en la c o mp u t a d o r a .
Qui n l o ha c e ? Los ingenieros Web y los desa-
bol l a dor e s del cont eni do q u e n o e s t cni co cr ean
l as We b Ap p s .
Por q u e s i mp o r t a n t e ? Conforme las Web-
Apps s e i nt egr an c a d a ve z m s en l as est r at e-
gi a s de negoci os p a r a p e q u e a s y g r a n d e s
e mp r e s a s ( por ej empl o, en el c ome r c i o el ect rni -
co) , cr ece en i mpor t anci a l a ne c e s i da d d e cons-
TM
PDF Editor
CAP TULO 16 INGENIERA WEB 503
ruir si st emas confi abl es, prct i cos y adapt abl es .
Por t ant o, es necesar i o un enf oque di sci pl i nado
en cuant o al desar r ol l o d e We bApps .
Cules son los pa s os ? Al igual que cualquier
di sci pl i na d e i ngeni er a, la I Web apl i ca un enf o-
q ue genr i co q ue se suavi za medi ant e est rat e-
gi as, t ct i cas y mt odos especi al i zados. El pr o-
ceso I Web comi enza con una formul aci n del
pr obl ema que se resol ver con la We bApp. Se
pl anea el pr oyect o I Web y se model an los requi -
sitos y el di seo de la We b Ap p El si st ema se
const ruye con t ecnol og as y her r ami ent as espe-
ci al i zadas as oci adas con la We b . Entonces se
ent r ega a los usuari os fi nal es y se eval a
medi ant e criterios t ant o t cni cos como empr es a-
riales Da do que las We b Ap p s evol uci onan con-
t i nuament e, se deben est abl ecer mecani smos
pa r a el control d e conf i gur aci ones, el as egur a
mi ent o d e la cal i dad y el sopor t e cont i nuo.
Cul es el pr oduct o obt eni do? Se producen
muchos pr oduct os d e t r a ba j o IWeb. El r esul t ado
final es la We b Ap p oper at i va,
hecho correctamente? En ocasi ones es difcil
estar seguro, hast a q ue los usuari os finales ejecu-
t an la We bApp. Sin embar go, se apl i can prcti-
cas de asegur ami ent o d e la cal i dad del soft ware
pa r a val orar l a cal i dad d e los model os IWeb, el
cont eni do y la funcin gl obal es del sistema, la
faci l i dad d e uso, l de s e mpe o y la segur i dad.
Esto conduce a una pregunta clave: se pueden aplicar principios, conceptos y mto-
dos de la ingeniera del software al desarrollo Web? Es posible aprovechar muchos de
ellos, pero su aplicacin puede requerir un giro un tanto diferente.
Pero qu ocurre si persiste un enfoque sin disciplina respecto al desarrollo Web?
En ausencia de un proceso disciplinado dirigido a desarrollar sistemas basados en
Web, existe una creciente preocupacin de que se enfrenten serios problemas en su
desarrollo, despliegue y mantenimiento exitosos. En esencia, la infraestructura de
aplicacin que se est creando en la actualidad puede conducir a una "Web enma-
raada" conforme se adentra ms este nuevo siglo. Esta frase entraa un cmulo de
aplicaciones basadas en Web mal desarrolladas y que tienen muy altas probabilida-
des de fracaso. Peor an, conforme los sistemas basados en Web crecen con mayor
complejidad, una falla en uno puede propagar y propagar amplios problemas por
medio de muchos. Cuando esto ocurra, la confianza en toda la Internet ser sacudi-
da. Peor an, podra conducir a una regulacin gubernamental innecesaria y mal
concebida, lo que provocar un dao irreparable a estas tecnologas nicas.
Para evitar una Web enmaraada y lograr mayor xito en el desarrollo y la apli-
cacin de sistemas basados en Web complejos y a gran escala, existe una apremian-
te necesidad de enfoques disciplinados y nuevos mtodos y herramientas con que
desarrollar, desplegar y evaluar los sistemas y aplicaciones basados en Web. Tales
enfoques y tcnicas deben considerar las caractersticas especiales de los nuevos
medios, los ambientes y escenarios operativos, y la multiplicidad de perfiles de usua-
rio que colocan desafos adicionales al desarrollo de aplicaciones basadas en Web.
La ingeniera Web (IWeb) aplica "slidos principios cientficos, de ingeniera y de
administracin, y enfoques disciplinados y sistemticos para el desarrollo, desplie-
gue y mantenimiento exitosos de sistemas y aplicaciones basados en Web de alta ca-
lidad" [MUR99J.
TM
PDF Editor
504 PARTE TRES APLICACIN DE LA INGENIERA WEB
1 6 . 1 ATRIBUTOS PE LOS SISTEMAS Y APLICACIONES BASADOS EN WEB
En los primeros das de la World Wide Web (rea 1990 a 1995) los "sitios Web" con-
sistan en poco ms de un conjunto de archivos de hipertexto ligados que presenta-
ban informacin mediante texto y grficos limitados. Conforme el tiempo pas, el
HTML aument al desarrollar herrami ent as (por ejemplo, XML, Java) que permitie-
ron a los ingenieros Web ofrecer capacidades de clculo junto con informacin. Na-
cieron los si st emas y aplicaciones1 basados en Web (se les referir de manera colec-
tiva como WebApps). En la actualidad, las WebApps han evolucionado en sofistica-
das herrami ent as de computacin que no slo proporcionan funcin por s misma;
al usuario final, sino que tambin se han integrado con bases de dat os corporativa;
y aplicaciones de negocios.
"En el moment o en que veamos cierto especie de estabilizacin, la Web se habr convertido en algo completamente
diferente. "
Loui s Moni er
^CONSEJ O^
Se puede argumenta/
que uno aplicaci n
tradicional dentro de
cualquiera de los
dominios de software
trotados en el captulo
1 puede mostrar esta
lista de atributos. Sin
embargo, las
WebApps casi siempre
lo hacen.
Existe poco debat e en cuant o a que las WebApps son diferentes a las mucha;
ot ras categoras de soft ware informtico anal i zadas en el captulo 1. Powell resuma
las diferencias principales cuando establece que los si st emas basados en Web "inv
lucran una mezcla entre publicacin impresa y desarrollo de software, ent re marke-
ting e informtica, entre comuni caci ones internas y relaciones externas, y entre ar-J
te y tecnologa" [POW98J. En la gran mayora de las WebApps se encuent ran los se-
guientes atributos.
I nt ens i dad d e r ed. Una WebApp reside en una red y debe satisfacer las neces-j
dades de una variada comunidad de clientes. Una WebApp puede residir en la Inte-J
net (y, en consecuencia, permitir una comunicacin mundial abierta). Alternativa]
mente, una aplicacin puede colocarse en una Intranet (lo que implementa la com
nicacin en una organizacin) o en una Extranet (comunicacin inter-red).
Concur r enci a. Un gran nmero de usuarios puede tener acceso a la WebApp al
mismo tiempo. En muchos casos, los pat rones de uso entre los usuarios finales YM
riarn enormement e.
Car ga i mpr edeci bl e. El nmer o de usuarios de la WebApp puede variar en cr-l
denes de magnitud de da con da. El lunes pueden mostrarse 100 usuarios; el mar!
t es pueden usar el sistema 10 000.
1 En el contexto de este captulo, el trmino "aplicacin Web" (WebApp) abarca todo, desde una
pie pgina Web que puede ayudar al consumidor a calcular el pago de arrendami ent o de un ssm
mvil, hasta un amplio sitio Web que proporcione servicios de viaje completos para gente I
negocios y vacacionistas. Dentro de esta categora se incluyen los sitios Web completos, la t u r c a
nalidad especializada dentro de los sitios Web y las aplicaciones de procesamiento de i nformar-J
que residen en la Internet o en una Intranet o Extranet.
TM
PDF Editor
De s e mp e o . Si un usuario de WebApp debe esperar demasi ado (para ingresar,
para procesami ent o en el lado del servidor, para formateo y despliegue en el lado del
cliente) puede decidir irse a cualquier otra parte.
Di sponi bi l i dad. Aunque la expectativa de una disponibilidad del total es poco ra-
zonable, los usuarios de las WebApps populares con frecuencia demandan acceso
sobre una base de "24/7/365". Los usuarios en Australia o Asia pueden demandar
acceso durante moment os cuando las tradicionales aplicaciones de soft ware doms-
tico en Norteamrica pueden estar fuera de lnea por mantenimiento.
Gobe r na da por l os da t os . La funcin primordial de muchas WebApps es usar
hipermedia para presentar contenido de texto, grficos, audio y video al usuario fi-
nal. Adems, por lo general, las WebApps se utilizan para tener acceso a informa-
cin que existe en bases de dat os que originalmente no eran parte integral del am-
biente basado en Web (por ejemplo, comercio electrnico o aplicaciones financie-
ras).
Sensi bi l i dad al cont eni do. La calidad y naturaleza esttica del contenido sigue
siendo un importante determinante de la calidad de una WebApp.
Evol uci n cont i nua. A diferencia del soft ware de aplicacin convencional, que
evoluciona a lo largo de una serie de pl aneadas liberaciones espaciadas cronolgi-
cament e, las aplicaciones Web evolucionan de manera continua. No es raro que al-
gunas WebApps (especficamente, su contenido) se actualicen sobre una agenda mi-
nuto a minuto, o que el contenido sea calculado de manera independiente para ca-
da solicitud. Algunos argument an que la evolucin continua de las WebApps hace
que el trabajo realizado sobre ellas sea anl ogo a la jardinera. Lowe [LOW991 co-
ment a esto cuando escribe:
La i ngeni er a t rat a de adopt ar un enf oque consi st ent e y cientfico, suavi zado por un con-
t ext o prct i co espec fi co, par a el desarrol l o y comi si onado de s i s t emas o apl i caci ones. Con
frecuenci a, el desarrol l o de sitios Web se rel aci ona mucho con la creaci n de una i nfraes-
t ruct ura (sembrar el jardn) y l uego con "cultivar" la i nformaci n que crece y r et oa den-
tro de est e jardn. A lo largo del t i empo, el jardn (es decir, el sitio Web) cont i nuar
evol uci onando, cambi ando y creci endo. Una buena arqui t ect ura inicial debe permitir que
est e creci mi ent o ocurra en una f or ma cont rol ada y consi st ent e. . .
El cuidado continuo y la alimentacin permiten que un sitio Web crezca (en ro-
bust ez e importancia). Pero, a diferencia del jardn, las aplicaciones Web deben sa-
tisfacer (y adaptarse a) las necesi dades de alguien ms que el jardinero.
I nmedi at ez. Aunque la inmediatez la apremiante necesidad de poner software
en el mercado rpidamente es una caracterstica de muchos dominios de aplica-
cin, las WebApps con frecuencia muestran un tiempo para comercializar que pue-
de ser cuestin de unos cuant os das o semanas. 2 Los ingenieros Web deben aplicar
2 Con las herramientas modernas se pueden producir elaboradas pginas Web en cuestin de unas
cuantas horas.
TM
PDF Editor
mt odos de planeacin, anlisis, diseo, implementacin y puesta a prueba que han
sido adapt ados a los apretados tiempos requeridos para el desarrollo de WebApps
Segur i dad. Puesto que las WebApps estn disponibles mediante el acceso a la
red, es difcil, si no imposible, limitar la poblacin de usuarios finales que pueden te-
ner acceso a la aplicacin. Con la finalidad de proteger el contenido confidencial y
ofrecer modos seguros de transmisin de datos, se deben implementar fuertes me-
didas de seguridad a lo largo de la infraestructura que sustenta una WebApp y den-
tro de la aplicacin misma.
Est t i ca. Una parte innegable de la apariencia de una WebApp es su presenta-
cin y la disposicin de sus elementos. Cuando una aplicacin se disea para comer-
cializar o vender productos o ideas, la esttica puede tener tanto que ver con el x
to como el diseo tcnico.
Estos atributos generales se aplican a t odas las WebApps, pero con diferentes gra
dos de influencia.
Pero qu hay de las WebApps por ellas mismas? Qu probl emas abordan? En e
trabajo IWeb es usual encont rar las siguientes categoras de aplicaciones [DAR99].
Qu catego- Informativo: se proporciona contenido de slo lectura con navegacin y enla-
ras de Web- e e s s i mp l e s .
Apps se encuentran
en el trabajo * D e s c a r a - u n usuario descarga informacin del servidor apropiado.
Web? Personalizare: el usuario personaliza el contenido segn sus necesidades es-
pecficas.
Interacci n: la comunicacin entre una comunidad de usuarios ocurre por me-
dio de cuartos de charla, tableros de anunci os o mensajera instantnea.
Entrada del usuario: la entrada con base en formularios es el principal meca-
ni smo para las necesidades de comunicacin.
Orientada a transacciones: el usuario hace una solicitud (por ejemplo, realiza
un pedido) que ejecuta la WebApp.
Orientada a servicios: la aplicacin proporciona un servicio al usuario; por
ejemplo, lo asesora en la determinacin del pago de una hipoteca.
Portal: la aplicacin canaliza al usuario hacia otro contenido o servicios Web
fuera del dominio del portal de la aplicacin.
Acceso a una base de datos: el usuario consulta una gran base de dat os y ex-
trae informacin.
Almacn de datos: el usuario consulta una coleccin de grandes bases de da-
tos y extrae informacin.
Los atributos coment ados en esta seccin, y las categoras de aplicacin destaca-
das lneas arriba, representan importantes hechos de vida para los ingenieros Web
La clave es vivir dentro de las restricciones que imponen dichos atributos y aun as:
producir una WebApp exitosa.
TM
PDF Editor
C A P T U L O 1 6 INGENIERA WEB 507
6 . 2 ESTRATOS P E LA I HS ENI ER A m WE B A P P

[ CONS EJ O.
ebcon
i es gil y
esincre-
' Sin embargo,
i que el modelo
i k puede elegirse
: c mayora de los
s de inge-
m .
El desarrollo de sistemas y aplicaciones basados en Web incorpora model os de pro-
ceso especializados, mt odos de ingeniera del soft ware adapt ados a las caracters-
ticas del desarrollo de WebApps y un conjunto de importantes tecnologas habilita-
doras. Los procesos, mt odos y tecnologas (herramientas) proporcionan un enfoque
en estratos de la IWeb que es concept ual ment e idntico a los estratos de la ingenie-
ra del soft ware descritos en la figura 2.1.
"La ingeniera Web trata can enfoques disciplinados y sistemticos para el desarrollo, despliegue y mantenimiento de
los sistemas y aplicaciones basados en Web."
16.2.1 Proceso
Los modelos de procesos IWeb (que se tratan con detalle en la seccin 16.3) adop-
tan la filosofa del desarrollo gil (captulo 4). El desarrollo gil enfatiza un enfoque
de desarrollo riguroso que incorpora rpidos ciclos de desarrollo. Aoyama [AOY98]
describe la motivacin para el enfoque gil en la siguiente forma:
Internet cambi la pri ori dad principal del desarrol l o de sof t war e de qu a cundo. El redu-
ci do t i empo para el mer cado se ha conver t i do en el lmite compet i t i vo por el que l uchan
l as compa as lderes. En consecuenci a, reducir el ciclo de desarrol l o es ahor a una de l as
mi si ones m s i mpor t ant es de la ingeniera del sof t war e.
Aun cuando rpidos ciclos de tiempo dominan la reflexin acerca del desarrollo, es
importante reconocer que el problema todava debe analizarse, debe desarrollarse
un diseo, la implementacin debe proceder en una forma incremental y se debe ini-
ciar un enfoque organizado de prueba. Sin embargo, dichas actividades del marco
de trabajo se deben definir dentro de un proceso que 1) adopt e el cambio, 2) aliente
la creatividad y la independencia del equipo de desarrollo y fortalezca la interaccin
con los accionistas de la WebApp, 3) construya si st emas que utilicen pequeos equi-
pos de desarrollo, y 4) subraye el desarrollo evolutivo o incremental medi ant e el uso
de cortos ciclos de desarrollo [MCD01],
16.2.2 Mtodos
El panorama de los mt odos de IWeb abarca un conjunto de labores tcnicas que
permiten al ingeniero Web comprender, caracterizar y luego construir una WebApp
de alta calidad. Los mt odos de IWeb (que se tratan con detalle en los captulos 18
al 20) se pueden categorizar de la siguiente manera:
M t odos d e comuni caci n: definen el enfoque con que se facilita la comuni-
cacin entre ingenieros Web y los dems participantes de la WebApp (por ejemplo,
usuarios finales, clientes de negocios, expertos en problemas de dominio, diseadores
de contenido, lderes de equipo, gestores de proyecto). Las tcnicas de comunicacin
son particularmente importantes durant e la recoleccin de requisitos y siempre que
sea evaluado un incremento en la WebApp
TM
PDF Editor
^ O N S E J O ^
Es importante notar
que muchos mtodos
IWeb se han adoptado
directamente de sus
contrapartes de inge-
niera del software.
Otros estn en sus
etapas lormativos.
Algunos de estos
sobrevivirn; otros
sern descartados
conforme se sugieran
mejores enfogues.
Se encuentran
excelentes recutsos
pora tecnologa IWeb
en webdeveloper.
lom y en www.
eborcom.com/
webmaker.
M t od os de anl i s i s de r equi s i t os : proporcionan una base para comprender
el cont eni do que ent regar una WebApp, la funcin que proporcionar al usuario fi-
nal y los modos de interaccin que cada clase de usuario requerir mi ent ras ocurra
la navegacin por medi o de la WebApp.
M t o d o s de di s eo: abarcan una serie de tcnicas de diseo que abordan e.
contenido, la aplicacin y la arquitectura de informacin, as como el diseo de in-
terfase y la estructura de navegaci n de la WebApp.
M t od os d e pr ue ba : incorporan revisiones tcnicas formales tanto del cont- j
nido y el modelo de diseo como de una amplia variedad de tcnicas de prueba que
abordan conflictos al nivel de component e y arquitectnicos, pruebas de la nave-
gacin, pruebas de facilidad de uso, pruebas de seguridad y pruebas de configuracin, j
Es importante seal ar que, aunque los mt odos IWeb adoptan muchos de los mis-
mos concept os y principios subyacent es a los mt odos de ingeniera del software
descritos en la parte 2 de este libro, los mecani smos de anlisis, diseo y prueba de-
ben adapt arse para acomodar las caractersticas especiales de las WebApps.
Adems de los mt odos tcnicos que se han subrayado, es esencial una serie ce
actividades sombrilla (con mt odos asociados) para la ingeniera Web exitosa. sa
incluye tcnicas de gestin de proyecto (por ejemplo, estimacin, cal endari zaci cr\ j
anlisis de riesgo), tcnicas de gestin de configuracin de soft ware y de revisin
16.2.3 Herramientas y tecnologa
A lo largo de la dcada pasada ha evolucionado un amplio conj unt o de herramien-
tas y tecnologa conforme las WebApps se han vuelto ms complejas y extendidas
Dichas tecnologas abarcan un amplio conj unt o de descripcin de contenido y len-
guaj es de modelacin (por ejemplo, HTML, VRML, XML), l enguaj es de programacin
(por ejemplo, Java), recursos de desarrollo basados en component es (por ej empl :
CORBA, COM, ActiveX, .NET), navegadores, herrami ent as multimedia, herramientas
de autora de sitio, herrami ent as de conectividad de bases de datos, herrami ent as oe
seguridad, servidores y utilidades de servidor, y herrami ent as de administracin 11
anlisis de sitio.
Un t rat ami ent o compl et o de las herrami ent as y tecnologa para la ingeniera Web s
est ms all del mbito de este libro. El lector interesado puede visitar uno o mas
de los siguientes sitios Web: Web Developer' s Virtual Encyclopedia (www.wdlv.corr.
WebDeveloper (www. webdeveloper. com), Developer Shed (www.devshed.com), Web-1
knowhow.net (www.webknowhow.net) o WebReference (www.webreference.com).
1 6 . 3 EL PRQCESQ PE I NGENI ER A WE B
Los atributos de los si st emas y aplicaciones basados en Web tienen una profunda in-
fluencia sobre el proceso de IWeb que se elija. En el captulo 3 se hizo notar que ual
ingeniero de soft ware elige un model o de proceso basado en los atributos del so-|
TM
PDF Editor
CAPTULO 16 INGENIERA WEB
509
ware que habr de desarrollarse. Esta premisa tambin es cierta para un ingeniero
Web.
Si la inmediatez y la evolucin continua son atributos principales de una WebApp,
un equipo de ingeniera Web debe elegir un modelo de proceso gil (captulo 4) que
produzca liberaciones de WebApp a un ritmo vertiginoso. Por otra parte, si una WebApp
ser desarrollada durante un largo periodo (por ejemplo, una gran aplicacin de co-
mercio electrnico) puede elegirse un model o de proceso incremental (captulo 3).
"El desarrollo Web es un adol escent e. . . al igual que lo mayora de los adolescentes, quiere ser acept ado como un
adulto conforme intenta alejarse de sus padres. Si quiere alcanzar todo su potencial, debe tomar unas cuant as leccio-
nes del ms experimentado mundo del desarrollo de software. "
La intensa naturaleza de las aplicaciones de la red en est e dominio sugiere una
diversa poblacin de usuarios (que, por lo tanto, realizan demandas especiales acer-
ca de respuesta y model ado de requisitos) y una arquitectura de aplicacin que pue-
de ser altamente especializada (que en consecuencia realiza demandas acerca del
diseo). Puesto que con frecuencia las WebApps son conductoras de contenido, con
nfasis en la esttica, es probable que se proyecten actividades de desarrollo para-
lelas dent ro del proceso IWeb e involucren un equipo de personal tanto tcnico co-
mo lego (por ejemplo, publicistas, di seadores grficos).
16.3.1 Definicin del marco de trabajo
Cualquiera de los modelos de proceso gil (por ejemplo, Programacin Extrema, De-
sarrollo de Software Adaptativo, SCRUM) presentados en el captulo 4 se pueden
aplicar de manera exitosa como un proceso IWeb. El marco de trabajo del proceso
que se presenta aqu es una amal gama de los principios e ideas tratados en dicho
capitulo.
La efectividad de cualquier proceso de ingeniera depende de su adaptabilidad.
Esto es, la organizacin del equipo de proyecto, los modos de comunicacin entre
miembros del equipo, las actividades de ingeniera y las tareas que deben realizar-
se, la informacin que se recolecte y cree, y los mt odos empl eados para producir un
producto de alta calidad deben estar adapt ados a la gent e que realiza el trabajo, el
plazo y las restricciones del proyecto, y al problema que se quiere resolver. Antes de
definir un marco de trabajo de proceso para IWeb se debe reconocer que:
V E 1. Las WebApps con frecuencia se entregan de manera incremental. Esto es, las ac-
x proceso tividades del marco de trabajo ocurrirn de manera repetida conforme cada
f p o n e en incremento se somet a a ingeniera y se entregue.
Doug Wnlloce el al.
; entrego
, cambio
y plazos
2. Los cambios ocurrirn frecuentemente Estos cambios pueden ocurrir como re-
sultado de la evaluacin de un incremento ent regado o como consecuencia
de cambiar las condiciones de los negocios.
TM
PDF Editor
%
CLAVE
El model o de proceso
genrico (introducido
en el capitulo 2 ) e s
aplicable a la
ingeniera Web.
3. Los plazos son cortos. Esto ami nora la creaci n y revisin de vol umi nosa do-
cument aci n de ingeniera, per o no excluye la simple realidad de que el anli-
sis crtico, el di seo y la prueba deben regi st rarse en al guna forma.
Adems, se deben aplicar los principios definidos como part e del "Manifiesto para el
desarrollo de sof t war e gil" (captulo 4). Sin embar go, los principios no son los die;
mandami ent os. A veces es razonabl e adopt ar el espritu de di chos principios sin que
sea necesari o at ener se a la letra del mani fi est o.
Con est os conflictos en ment e s e aborda el proceso de IWeb dent ro del proces:
genri co de mar co de t rabaj o pr esent ado en el cap t ul o 2.
Comuni c a c i n c on el cl i ent e. Dent ro del proceso IWeb la comuni caci n con e
cliente se caract eri za por medi o de dos gr andes tareas: el anlisis del negoci o y
formul aci n. El anlisis del negocio defi ne el cont ext o empresari al -organi zat i vo ]
la WebApp. Adems, se identifican los participantes, se predi cen los potenci
cambi os en el ambi ent e o los requisitos del negocio, y se defi ne la integracin en
la WebApp y ot ras apl i caci ones de negoci os, bases de dat os y funci ones. La forrr. -
aci n es una actividad de recopilacin de requisitos que involucra a t odos los p
cipantes. El intento es describir el probl ema que la WebApp habr de resolver (j
con los requisitos bsi cos para la WebApp) con el apr ovechami ent o de la mejor
formaci n disponible. Adems, se i nt ent a identificar r eas de incertidumbre y
de ocurrirn cambi os pot enci al es.
Pl a ne a c i n. Se crea el plan del proyect o para el i ncrement o de la WebApp.
plan consi st e de una definicin de t areas y un cal endari o de pl azos respect o al
riodo (usual ment e medi do en semanas) proyect ado para el desarrol l o del incre
to de la WebApp.
Mod e l a d o. Las l abores convenci onal es de anlisis y di seo de ingeniera
soft ware se adapt an al desarrol l o de la WebApp, se mezcl an y luego se funden en
actividad de model ado IWeb (captulos 18 y 19). El i nt ent o es desarrollar anlisis
pidos" y model os de di seo que defi nan requisitos y al mi smo t i empo represen
una WebApp que los satisfar.
Cons t r uc c i n. Las her r ami ent as y la tecnologa IWeb se aplican para construir
WebApp que se ha model ado. Una vez que se const ruye el i ncr ement o de Web/
se dirige una serie de pruebas rpi das para asegur ar que se descubran los errores
el di seo (es decir: cont eni do, arqui t ect ura, interfase, navegaci n). Pruebas adi
nal es abor dan ot ras caractersticas WebApp.
De s pl i e gue . La WebApp se confi gura para su ambi ent e operativo, s e entrega
los usuari os finales y l uego comi enza un peri odo de evaluacin. La retroalime
cin acerca de la eval uaci n se present a al equi po de IWeb y el i ncrement o se
difica conf or me s e requiera.
Estas cinco act i vi dades del mar co de t rabaj o IWeb se aplican empl eando un
de proceso i ncrement al , como s e muest ra en la figura 16.1.
TM
PDF Editor
Pr ue ba d e a c e p t a c i n
Us o de l c o n s u mi d o r
Eval uac i n de l c o ns umi do r
Co d i f i c a c i n
Pr ue ba d e c o mp o n e n t e s
Li be r ac i
Anl i s i s de l n e g o c i o
For mul ac i n
Pl an d e i t eraci n
Mo d e l o d e anl i s i s
Co n t e n i d o
It eraci n
Funci n
Co n f i g u r a c i n
Mo d e l o d e d i s e e
Co n t e n i d o
Arqui t ect ura
N a v e g a c i n
I nt erf az
Ingeniera Web: preguntas bsicas
INFORMACIN
La ingeniera de cualquier producto involucra suti-
que no advierten inmediatamente quienes carecen de
ia sustancial. Las caractersticas de las WebApps
a los ingenieros Web a responder una diversidad
preguntas que deben abordarse durante las primeras
es del marco de trabajo. Las preguntas estratgi-
relacionadas con las necesidades del negocio y los
os del producto, se tratan durante la formulacin,
oreguntas acerca de los requisitos, relacionadas con
caractersticas y funciones, deben considerarse durante
anlisis de modelado. Las preguntas especficas de dise-
base, relacionadas con la arquitectura de la WebApp,
caractersticas de la interfaz y los conflictos de navega-
, se consideran conforme evoluciona el modelo de d-
tro. Finalmente, un conjunto de conflictos humanos,
r aci onados con la forma en la que un usuario realmente
rract a con la WebApp, se abordan en forma continua.
Susan Weinshenk [WEI02] sugiere un conjunto de pregun-
s que se deben considerar conforme progresan el anlisis y el
3 seo. Aqu se anota un pequeo subconjunto (adaptado):
Cun importante es la pgina de inicio (home page)
de un sitio Web? Debe contener informacin til o una
simple lista de enlaces que conduzcan al usuario a ma-
yores detalles en niveles inferiores?
Cul es la plantilla de pgina ms efectiva (por ejem-
plo, men arriba, a la derecha, a la izquierda) y sta
variar segn el tipo de WebApp que se desarrollar?
Qu opciones de medios audiovisuales tienen ms im-
pacto? Los grficos son ms efectivos que el texto? El
video (o el audio) es una opcin efectiva? Cundo se
deben elegir varias opciones de medios audiovisuales?
Cunto t rabaj o se puede esperar que realice un usua-
rio cuando busca informacin? Cuntos clics desea ha-
cer la gente?
Cun importantes son los auxiliares de navegacin
cuando las WebApps son complejas?
Cun complejas pueden ser las entradas de formulario
antes de que se vuelvan irritantes para el usuario? C-
mo se pueden expedir las entradas de formulario?
Cun importantes son las capacidades de bsqueda?
Qu porcentaje de usuarios navega y qu porcentaje
usa bsquedas especficas? Cun importante es estruc-
turar cada pgina en una forma que suponga un enlace
desde alguna fuente externa?
La WebApp se disear en una forma que sea accesi-
ble a quienes tengan discapacidades fsicas o de algn
otro tipo?
No existen respuestas absolutas a preguntas como stas, e
incluso<NingurK deben abordarse conforme avance la
IWeb. En los captulos 17 al 20 se considerarn respuestas
potenciales.
TM
PDF Editor
16.3.2 Refinamiento del marco de trabajo
Ya se ha advertido que el model o del proceso IWeb debe ser adaptable. Esto es, la
definicin de las t areas de ingeniera requeridas para retinar cada actividad del mar-
co de trabajo se dej an a discrecional juicio del equipo de ingeniera Web. En algunos
casos, una actividad del marco de t rabaj o se dirige de manera informal; en otros, se
definir una serie de distintas t areas y las dirigirn mi embros del equipo. En todo ca-
so, el equipo es responsable de producir un i ncrement o WebApp de alta calidad den-
tro del peri odo acordado.
Es importante destacar que las t areas asociadas con las actividades del marco de
trabajo IWeb pueden modificarse, eliminarse o extenderse con base en las caracters-
ticas del problema, el producto, el proyecto y la gente en el equipo de ingeniera Web
"Existen al gunos de nosotros que creen que los mej ores prcticas para el desarrollo de software son prcticas y mere-
cen mplementacin. Y luego existen algunos de nosotros que creen que las mej ores prcticas son interesantes en ciei
ta formo acadmica, mas no lo son para el mundo real, muchas gracias."
Warren Keuffel
1 6 . 4 ME J OB E S P RCTI CAS EN I NGENI ER A WE B
^CONSEJO^-
Aseg rese de que
alguien hoyo enunciado
ion claridad los nece-
sidades del negocio
pato una WebApp. Si
n es as, el proyecto
lWebesten
Todo desarrollador de WebApp utilizar el mar co de trabajo y el conj unt o de tareas
del proceso IWeb definido en la seccin 16.3? Probabl ement e no. En ocasiones, las
equipos de ingeniera Web est n somet i dos a enorme presin respecto del tiempc rj
t rat arn de t omar at aj os (incluso si st os son i mprudent es e implican ms esfuerza
de desarrollo, en lugar de menos). Pero se debe aplicar un conj unt o fundament al i r
mej ores prcticas adopt ado de las prcticas de ingeniera del soft ware tratadas
lo largo de la Parte 2 de est e libro si se han de construir WebApps con calidad in-
dustrial.
1 . Tomar tiempo para entender las necesidades del negocio y los objetivos del pro-
ducto, incluso si los detalles de la WebApp son vagos. Muchos desarrolladores
de WebApps creen er r neament e que los requisitos vagos (que son bastante I
comunes) los liberan de la necesidad de asegurarse de que el sistema que es - 1
tn a punt o de somet er a ingeniera tenga un propsito empresarial legtimo
El resultado final es (tambin con frecuencia) un buen trabajo tcnico que c o o l
duce a la construccin del sistema equivocado por las razones equivocadas
para el pblico equivocado. Si los accionistas no pueden enunciar una neces - 1
dad empresarial para la WebApp, debe procederse con extrema precaucin. S I
los accionistas luchan por identificar un conj unt o de objetivos claros para el
producto (WebApp), no debe procederse mientras ellos no concluyan.
2. Describir c mo interactuarn los usuarios con la WebApp aplicando un enfoque I
basado en escenarios. Se debe convencer a los accionistas para desarrollar c- |
sos de uso (tratados a lo largo de la Parte 2 de este libro) para reflejar cmo |
los diversos act ores interactuarn con la WebApp. Ent onces se pueden aprc- I
TM
PDF Editor
vechar dichos escenari os 1) para la planeacin y el rastreo del proyecto, 2) pa-
ra guiar el anlisis y el model ado del diseo, y 3) como una entrada importan-
te para el diseo de pruebas.
3. Desarrollar un plan del proyecto, incluso si es muy breve. El plan debe basarse
en un proceso de marco de trabajo predefinido aceptable para todos los parti-
cipantes. Puesto que los plazos del proyecto son muy cortos, la dosificacin
del programa debe ser exacta; es decir, en muchas instancias el proyecto debe
planearse y rastrearse diariamente.
4. Utilizar alg n tiempo para modelar lo que se construir. Por lo general, el anli-
sis total y los model os de di seo no se desarrollan durant e la ingeniera Web.
Sin embargo, la clase UMLy los di agramas de secuencia, j unt o con otra nota-
cin UML seleccionada (por ejemplo, di agramas de estado), pueden propor-
cionar una visin invaluable.
5. Revisar la consistencia y calidad de los modelos. Las revisiones tcnicas forma-
les (captulo 26) se deben dirigir a lo largo del proyecto IWeb. El tiempo em-
pleado en las revisiones paga i mport ant es dividendos porque usual ment e
elimina reelaboraciones y resulta en una WebApp que exhibe alta calidad, lo
que aument a la satisfaccin del cliente.
6. Utilizar herramientas y tecnologa que permitan construir el sistema con tantos
componentes reutilizables como sea posible. Un amplio conj unt o de herrami en-
t as WebApp est n a disposicin virtualmente para cada aspect o de la cons-
truccin WebApp. Muchas de dichas herrami ent as permiten que un ingeniero
Web construya porciones significativas de la aplicacin empl eando compo-
nent es reutilizables.
7. No apoyarse en usuarios anteriores para depurar la WebApp; disense pruebas
amplias y ejec tense antes de liberar el sistema. Los usuari os de una WebApp
con frecuencia le dan una oportunidad. Si falla en su ejecucin se mueven a
cualquiera otra parte: nunca regresan. Por esta razn, el "pruebe primero,
despus despliegue" debe ser un sistema primordial, incluso si los pl azos se
deben prolongar.
INFORMACIN
Criterios de calidad/directrices para WebApps
La IWeb se esfuerzo en la produccin de
de alta calidad. Pero, en este contexto, qu es
y qu directrices estn disponibles para lograrla?
i artculo acerca de aseguramiento de la calidad en si-
Web, Quibeldey-Cirkel [QUI01 ] sugiere un amplio
-to de recursos en lnea que abordan estos conflictos:
W3C: gua de estilo para hipertexto en lnea
www.w3.org/Provider/Style
La Gua Sevioid para el diseo Web
www. sev. com. au/webzone/design/guide. asp
Pginas Web que Apestan
www.webpagestfiatsuck.com/index.html
Y
TM
PDF Editor
514
PARTE TEES APLICACIN DE LA INGENIERA WEB
Recursos acerca de estilo Web
www. westegg. com/unmaintained/bodpoges
Herramienta de evaluaci n Web de Gartner
www.gartner.com/ebusiness/website-ings
IBM Corp: directrices Web
www-3. ibm. com/ibm/easy/eou_ext. nsf/Publish/572
Facilidad de uso en la World Wide Web
ijhcs.open.ac.uk
Interfaz Sal n de la Vergenza
www.iarchitect.com/mshame.htm
El arte y el zen de los sitios Web
www. tic -systems.com/webtips. shtml
Diseo para la Web: estudios empricos
www.microsoft.com/usability/webconf.htm
useit.com de Nielsen
www.useit.com
Calidad de experiencia
www.qualityofexperience.org
Creaci n de sitios Web asesinos
www.killersites.com/core.html
Todas las cosas en la Web
www.pantos.org/atw
Nuevo diseo Web de SUN
www. sun. com/980113/sunonnet
Tognazzini, Bruce: homepage
www.asktog.com
Webmonkey
hotwi red.lycos.com/webmonkey/design/?tw=design
Los mejores sitios Web del mundo
www.worldbestwebsites.com
Yale University: guia de estilo Web de Yale
info. med. yale. edu/caim/manual
>
Es posible argumentar que el impacto de los sistemas y aplicaciones basados en Wer
es el suceso ms significativo en la historia de la computacin. Conforme la impo:
tancia de las WebApps crece ha comenzado a evolucionar un enfoque IWeb discipl -
nado (adaptado de los principios, conceptos, procesos y mt odos de la ingeniera dt
software).
Las WebApps son diferentes de ot ras categoras de soft ware informtico; son em.
nent ement e de red, las gobiernan los dat os y se encuent ran en evolucin continua
La inmediatez que dirige su desarrollo, la necesidad apremi ant e de seguridad en s_
operacin y la demanda de esttica, as como la entrega de contenido funcional, s e- i
factores diferenciales adicionales. Al igual que otros tipos de software, las WebApp-5
pueden valorarse medi ant e una diversidad de criterios de calidad que incluyen fac-l
lidad de uso, funcionalidad, confiabilidad, eficiencia, capacidad de mantenimient
seguridad, disponibilidad, escalabilidad y tiempo para comercializacin.
La IWeb se describe en tres estratos; proceso, mt odos y herramientas/tecnolc~|
ga. El proceso IWeb adopta el enfoque de desarrollo gil que subraya un punt o ce
vista de ingeniera "magro", riguroso, que conduce a la entrega incremental del sis-
tema que ser construido. El proceso genrico del marco de trabajo comunicacir
planeacin, modelado, construccin y despliegue es aplicable a la IWeb. Dichas
actividades del marco de t rabaj o se refinan en un conjunto de t areas IWeb que se
adaptan a las necesi dades de cada proyecto. A todos los proyectos IWeb se les apli-l
ca un conjunto de actividades sombrilla similar al aplicado durant e el t rabaj o de in-l
geniera del software: SQA, SCM, gestin del proyecto.
TM
PDF Editor
CAP TULO 16 INGENIERA WEB
515
[AOY98] Aoyama, M "Web-Based Agile Soft ware Devel opni ent ", en IEEE Computer, novi embr e-
di ci embre, 1998, pp. 56-65.
[DAR99] Dart, s "Containing t he Web Crisis Using Confi gurat i on Management ", en Proc, First
ICSE Workshop on Web Engineering, ACM, Los ngel es, mayo de 1999. (The Proceedings ofthe
First CSE Workshop on Web Engineering se publican en l i nea en ht t p: / / f i st ser v. macar t hur .
uws. edu. au/ san/ i cse99- WebE/ l CSE99- WebE- Pr oc/ def aul t . ht m) .
[FOWOl] Fowler, M. y J. Highsmith, "The Agile Manifest", en Software Development Magazine.
agost o de 2001, ht t p: / / www. s dma ga z i ne . c om/ doc ume nt s / s s 844/ s dm0l 08a / 0l 08a . ht m.
[MCD01) McDonal d, A. y R. Welland, Age Web Engineering (AWE) Process, Depar t ment of Com-
put er Science, University of Glasgow, Technical Report TR-2001-98, 2001, se puede descar-
gar desde ht t p: / / www. dcs. gl a. ac. uk/ ~andr ew/ TR- 200l - 98. pdf .
(MUR99] Mur ugesan, S., WebE Home Page, ht t p: / / f i st ser v. macar t hur . uws. edu. au/ san/ WebEHo-
me, julio de 1999.
INOR99] Norton, K., "Applying Cross Functional Evolutionary Met hodol ogi es to Web Develop-
ment ", en Proc. First ICSE Workshop on Web Engineering, ACM, Los ngeles, mayo de 1999.
[POW98] Powell, T. A., Web Site Engineering, Prentice-Hall, 1998.
[PRE98] Pressman, R. S. (moderador), "Can Int ernet -Based Appl i cat i ons Be Engi neered?", IEEE
Software, sept i embr e de 1998, pp. 104-110.
[QUI01] Quibeldey-Cirkel, K., "Checklist for Web Site Quality Assurance", en Quality Week Euro-
pe, 2001, se puede descar gar desde www. f bi . f h- dar mst adt . de/ ~qui bel dey/ Pr oj ekt e/ QWE-
2001 /Paper_Quibeldey_Cirkel. pdf.
[WEI02] Wei nschenk, S., "Psychology and t he Web: Designing for People", 2002, ht t p: / / www-
. wei ns chenk. com/ l ear n/ f act s . as p.
16. 1 Existen ot r os at ri but os genri cos que di ferenci en a l as WebApps de l as apl i caci ones de
sof t war e m s convenci onal es? Int nt ese menci onar dos o tres.
16. 2 Cmo j uzga el lector la "calidad" de un sitio Web? Hgase una lista, en or den des cenden-
t e de prioridad, de 10 at ri but os de cal i dad que consi der en los m s i mport ant es.
16. 3 Realizar un poco de investigacin y escribir un art i cul o de dos a tres pgi nas que r esuma
una de l as t ecnol og as a not a da s en la secci n 16.2.3.
16. 4 Empl eando un sitio Web real c omo ej empl o, ilustrar las di ferent es mani f est aci ones del
"cont eni do" de la WebApp.
16. 5 Revisar l os pr ocesos de i ngeni er a del sof t war e descri t os en los cap t ul os 3 y 4. Existe(n)
algn(os) otro(s) proceso(s) -di st i nt o(s) al model o de pr oceso gil- que pueda(n) ser aplicable(s)
a la i ngeni er a Web? Si la r espuest a es afi rmat i va, i ndi car cul(es) proceso(s) y por qu.
16. 6 Revisar la exposi ci n del "Mani fi est o para desarrol l o de sof t war e gil" pr es ent ado en el
cap t ul o 4. Cul de l os 12 pri nci pi os funci onar a bien para un proyect o de dos aos (que invo-
lucra a docenas de personas) que const rui r un gr an si st ema de comer ci o el ect rni co para una
compa a aut omot r i z? Cul de los 12 pri nci pi os funci onar a bien par a un proyect o de dos me-
ses que const rui r un sitio i nformat i vo para una pequea firma de bi enes ra ces?
16. 7 El aborar una lista de "riesgos" que seri an pr obabl es dur ant e el desarrol l o de una nueva
apl i caci n de comerci o el ect rni co que s e di sea para vender t el f onos cel ul ares y servi ci os di-
r ect ament e por medi o de la Web.
TM
PDF Editor
PARTE TRES APLICACIN DE LA INGENIERA WEB
En aos r eci ent es se han publ i cado ci ent os de libros que anal i zan uno o m s t emas de ingenie-
ra Web, aunque r el at i vament e pocos abor dan t odos los aspect os de la IWeb. Sarukkai (Found-
tions o/Web Technology, Kl uwar Academi c Publishers, 2002) pr esent a una val i osa compi l ador-
de t ecnol og as que s e requi eren para la IWeb. Mur ugusan y Deshpande (Wef> Engineering: M;
naging Diversity and Complexity of Web Development, Springer-Verlag, 2001) han edi t ado una c:
leccin de tiles art cul os acer ca de IWeb. Las act as de conf er enci as i nt er naci onal es acerca a e
ingeniera Web y de i ngeni er a de s i s t emas de i nformaci n Web las publica anual ment e el IEEE
Comput er Soci et y Press.
Flor (Web Business Engineering, Addison-Wesley, 2000) anal i za el anl i si s de negoci os y las
pr eocupaci ones r el aci onadas que per mi t en al i ngeni ero Web compr ender mej or l as necesi dades
de los clientes. Bean (Engineering Global E-commerce Sites, Morgan Kauf man, 2003) pr esent a c
rect ri ces par a el desarrol l o de WebApps gl obal es. Lowe y Hall (Hypermedi a and the Web: An
gineering Approach, Wiley, 1999) y Powell [POW98] of r ecen una cober t ur a r azonabl ement e c
pl et a. Umar (Application Re engineering: Building Web-Based Applications and Dealing with Le
Systems, Prentice-Hall, 1997) abor da uno de los m s difciles confl i ct os en la IWeb: la reinge
ra de l os si st emas her edados par a hacer l os compat i bl es con los s i s t emas bas ados en Web. I
Std. 2001-1999 def i ne prct i cas bsi cas de IWeb.
Er Internet hay di sponi bl e una gr an vari edad de f uent es de i nformaci n acerca de ingei
ra Web. En el sitio Web de SEPA se puede encont r ar una lista act ual i zada de referenci as en
World Wide Web que son rel evant es para la ingeniera Web:
ht t p: / / www. mhhe. com/ pr es s man.
TM
PDF Editor
C A P I T U L O
FORMULACI N Y PLANEACI N
PARA I NGENI ER A WE B
17
K28AS
. . 523
. . .526
. . . . 530
acosa . . 533
.520
.536
. . 539
-. 530
. . 519
. . 525
. . 521
530
. . 524
D
urante la t empest uosa dcada de 1990, el boom de la Internet gener ms
arrogancia que cualquier otro event o en la historia de las comput adoras
Los desarrolladores de WebApps en cientos de j venes compa as punt o-
com argument aban que haba surgido un nuevo paradigma para el desarrollo de
software, que las viejas reglas ya no se aplicaran ms, que el tiempo para el mer-
cado domi naba todas las dems preocupaciones. Se rieron de la nocin de que la
formulacin y la planeacin cui dadosas deban ocurrir ant es de que comenzar a
la construccin. Y quin pod a rebatirlos? El dinero estaba en todas partes, los
j venes de 24 aos se volvieron multimillonarios (al menos en el papel); tal vez
las cosas real ment e haban cambiado. Y ent onces el suelo se vino abajo.
Conforme comenzaba el siglo xxi empez a ser dol orosament e evidente que
un enfoque de "construyelo y ellos vendrn" simplemente no funci onaba, que la
formulacin del problema es esencial para garantizar que una WebApp en ver-
dad es necesaria, y que la planeacin vale el esfuerzo, aun cuando el calendario
de desarrollo sea apretado. Constantine y Lockwood [CONQ2] advierten esta
situacin cuando escriben:
A pes ar de l as decl ar aci ones r adi cal es de que la Web r epr es ent a un nue v o pa r a di gma
def i ni do por r egi as nuevas , l os d e s a bol l a d or e s pr of es i onal es s e e s t n d a nd o cuent a
de que l as l ecci ones acer ca del desar r ol l o de s of t war e, a pr e ndi da s en l os d as pr evi os
al Int ernet , t odav a se apl i can. Las pgi nas Web son i nt er f aces de usuar i o, la pr ogr a-
maci n HTML e s pr ogr amaci n, y l as apl i caci ones de s pl e ga da s en el na ve ga dor son
s i s t emas de s of t wa r e que pue de n benef i ci ar s e de l os pr i nci pi os bs i cos de la i ngeni e-
ra del s of t war e.
Entre los principios fundament al es de la ingeniera de soft ware dest aca el de:
comprender el problema antes de comenzar a resolverlo, y estar seguro de que la
soluci n concebida es aquella que la gente realmente quiere. Esta es la base de la
formulacin, la primera gran actividad en la ingeniera Web. Otro principio fun-
dament al de la ingeniera de soft ware es: planear el trabajo antes de comenzar a
realizarlo. Este es el enfoque que subyace a la pl aneaci n de proyectos.
a ! . Por una pa r t e , exi st e u n a t enden-
ci a a di feri r, a e s pe r a r ba s t a q u e
t o d a t es t c r u z a d o y t o d a i t e nga
p u n t o a nt e s d e q u e c omi e nc e el tra-
ba j o. Por ot r a pa r t e , h a y un d e s e o d e sal t ar ya,
d e c o me n z a r a const r ui r i ncl uso a nt e s d e q u e en
r e a l i da d se c o n o z c a q u s e necesi t a hacer .
Amb o s e nf oque s son i na pr opi a d os y p o r el l o l as
dos pr i me r a s act i vi dades del ma r c o d e t r a b a j o
d e la i ngeni er a We b d e s t a c a n la f or mul aci n y
la pl a ne oc i n Lo f or mul aci n val or a la necesi -
d a d s ubyacent e de la We b Ap p , l as car act er st i
c a s y f unci ones gl oba l e s q u e d e s e a n los us uar i os
517
TM
PDF Editor
y el mbi t o del esf uer zo d e desarrol l o. La pl anea-
cin a b o r d o los el ement os que d e b e n defi ni rse
pa r a est abl ecer un flujo d e t r abaj o y un pr ogr a-
ma , y a r ast r ear el t r a ba j o conf or me a v a n z a el
pr oyect o.
Qui n lo hace? Los ingenieros Web, sus admi-
ni st r ador es y los par t i ci pant es sin funci ones tc-
ni cas; t odos par t i ci pan en l a formul aci n y la
pl aneaci n.
Por qu es i mpor t ant e? Es difcil viajar a un
l ugar q ue nunca se ha vi si t ado sin di r ecci ones o
un ma pa . Event ual ment e se llega (o tal vez no),
per o con s egur i dad el vi aj e ser frust rant e y
l ar go en f or ma i nnecesar i a. La f or mul aci n y l a
pl aneaci n pr opor ci onan un ma pa p a r a un
equi po d e i ngeni er a We b .
Cul es son l os p a s o s a s egui r ? La formula-
cin comi enza al est abl ecer comuni caci n con et
consumi dor (acci oni st a) q ue pl ant ea l as r azones
pa r a la We b Ap p : cul es la neces i dad del
negoci o, cul es usuari os finales son el obj et i vo,
q u caract er st i cas y funci ones se des ean, q u
si st emas y bas es d e dat os exi st ent es van a t ener
acces o, el concept o es r eal i zabl e, cmo se medi -
r el xi t o? La pl aneaci n est abl ece un pl an de
t r abaj o, desar r ol l a est i maci ones pa r a val or ar la
fact i bi l i dad d e las f echas d e ent r ega de s e a da s ,
consi der a ri esgos, def i ne un pr ogr a ma y est a-
bl ece mecani smos p a r a r ast r eo y control,
Cul es el pr oduct o obt eni do? Puesto que el
t r a ba j o d e i ngeni er a We b con f r ecuenci a adop-
t a una filosofa gi l , los pr oduct os obt eni dos
pa r a la formul aci n y la pl aneaci n usual ment e
son par cos , per o existen y de be n regi st rarse en
f or ma escri t a. La recopi l aci n d e i nformaci n
dur ant e la formul aci n se regi st ra en un docu-
ment o escrito en el cual se ba s a n la pl aneaci n
y el mode l a do d e anlisis. El pl an del proyect o
ext i ende el pr ogr a ma d e ste y pr esent a cual-
qui er ot r a i nf or maci n q ue sea neces ar i o comu-
ni car a los mi embr os del e qui po d e i ngeni er a
We b y al per sonal ext erno.
Cmo p u e d o es t ar s egur o de q u e lo he
hecho cor r ect ament e? Es necesario desa-
rrollar con suficiente det al l e p a r a est abl ecer un
ma p a slido, pe r o n o t ant o como p a r a quedar
e mpa nt a na d o. La i nformaci n d e la formul aci n
y ta pl aneaci n d e b e revi sarse con los clientes
pa r a gar ant i zar q ue las i nconsi st enci as y las
omi si ones se identifiquen en una et apa t empr ana.
1 7 . 1 FORMULACI N DE SI STEMAS BASADOS EN WE B
La formulaci n de sistemas y aplicaciones basados en Web representa una secuen-
cia de acciones de ingeniera Web que comienza con la identificacin de las necesi
dades del negocio, se mueve hacia una descripcin de los objetivos de la WebApp
define grandes caractersticas y funciones y realiza la recopilacin de requisitos que
conducen al desarrollo de un modelo de anfisis. La formulacin permite que los
clientes y el equipo de ingeniera Web establezcan un conjunto comn de metas \
objetivos para la construccin de la WebApp. Tambin identifica el mbito de
esfuerzo de desarrollo y proporciona un medio para determinar un resultado xito
so. El anlisis una actividad tcnica que es una continuacin de la formul aci n-
identifica los requisitos funcionales, de comportamiento y de datos para la WebApp
Antes de considerar la formulacin con ms detalle, es razonable pregunta:
dnde termina la formulacin y dnde comienza el anlisis de requisitos. No exist
una respuesta sencilla para esta pregunta. La formulacin se enfoca sobre el "grar
cuadro": en las necesidades y objetivos del negocio y en la informacin relacionada
Sin embargo, virtualmente es imposible mantener este grado de abstraccin. Los
clientes y los ingenieros Web quieren definir el contenido requerido, discutir la fun
TM
PDF Editor
C A P I T U L O 1 7 FORMULACIN Y PLANEACIN PARA INGENIERA WEB
519
I (PTONSEJO^
s comienzo la
i del
, intntese
birlo WebApp
; pretende
uren un solo
fe. Si no es
, no se estn
ilas
s globales del
cionalidad especfica, enumerar caractersticas especficas e identificar la forma en
que los usuarios finales interactuarn con la WebApp. Esto es formulacin o reco-
pilacin de requisitos? Ambos es la respuesta.
17.1.1 Preguntas de formulacin
Powell [POW98] sugiere un conj unt o de preguntas que deben formularse y respon-
derse al comi enzo de la etapa de formulacin:
Cul es la principal motivacin (necesidades del negocio) para la WebApp?
Cules son los objetivos que debe satisfacer la WebApp?
Quin usar la WebApp?
La respuesta a cada una de est as simples preguntas debe establecerse tan sucinta-
ment e como sea posible. Por ejemplo, supngase que el fabricante de HogarSeuro[
ha decidido establecer un sitio Web de comercio electrnico para vender sus pro-
ductos directamente a los consumidores. Un enunci ado que describa la motivacin
para la WebApp puede ser:
HogarSegurol nc. com permi t i r a los consumi dor es confi gurar y compr ar t odos l os com-
ponent es r equer i dos para i nst al ar un si st ema de admi ni st raci n en su hogar o empr esa.
Es importante advertir que en est e enunci ado no se proporcionan detalles. El objeti-
vo aqu es acotar la intencin global de la WebApp y colocarla en un contexto
empresarial legtimo.
Despus de platicar con varios clientes se establece una respuesta a la segunda
pregunta:
HogarSeguroInc. com nos permi t i r vender di r ect ament e a l os consumi dor es, lo que eli-
mi nar los cost os de i nt ermedi aci n y mej or ar los mr genes de utilidad. Tambi n nos
permi t i r aument ar l as vent as en un pr oyect ado 25 por ci ent o sobr e l as vent as anual es ac-
t ual es y penet r ar en r egi ones geogr f i cas donde en la act ual i dad no t enemos punt os de
vent a.
Finalmente, la compaa define la demografa para la WebApp: "Los usuarios pro-
yectados de HogarSeguroInc.com son los propietarios de viviendas y los dueos de
pequeos negocios."
Las respuest as establecidas lneas arriba implican met as especficas para el sitio
Web de HogarSeguroInc.com. En general, se identifican dos categoras de met as
[GNA99]:
Metas informativas: indican una intencin de proporcionar contenido informa-
cin especficos al usuario final.
Metas aplicables: indican la habilidad para realizar alguna tarea dentro de la
WebApp.
1 El producto HogarSeguro ya se us como ejemplo a lo largo de las partes I y 2 de este libro
TM
PDF Editor
520
En el contexto de la WebApp HogarSegurolnc.com, una meta informativa puede ser
El si t i o pr opor ci onar a l os us uar i os es peci f i caci ones de pr oduc t o det al l adas, q u e inclui-
r n des cr i pci ones t cni cas, i nst r ucci ones de i nst al aci n e i nf or maci n de pr eci os.
El examen de las respuest as a las pregunt as planteadas puede conducir al estableci-
miento de una meta aplicable:
Hogar Segur ol nc. com cons ul t ar al us uar i o acer ca de la i nst al aci n (es deci r: cas a, ofi ci na,
es paci o de vent a al me nude o) que ser pr ot egi da y r eal i zar r e c ome nd a c i one s per sonal i -
z a d a s acer ca del pr oduc t o y la conf i gur aci n que s e ut i l i zar.
Una vez identificadas t odas las met as informativas y aplicables, se desarrolla un per-
fil de usuario. El perfil de usuario captura "caractersticas relevantes relacionadas
con los usuarios potenciales, que incluye sus ant ecedent es, escolaridad, preferencias
e incluso ms" (GNA99]. En el caso de HogarSegurolnc.com, un perfil de usuario
identificara las caractersticas de un comprador tpico de sistemas de seguridad
(esta informacin la suministrara el depart ament o de mercadotecnia).
t
Qu pasos
""Si ests hot keondo [WebApps], probablemente tu enfoque es ' preparen, fuego, apunt en' . Si ests comprometido
t on hacerlas funcionar, debe ser ' preparen, apunt en, fuego' . "
Autor desconocido
Una vez que se han desarrollado las met as y perfiles de usuario, la actividad de
formulacin se enfoca sobre una afirmacin del mbi t o para la WebApp. En muchos
casos, las met as ya desarrolladas se integran en la afirmacin del mbito. Adems,
es til, no obstante, indicar el grado de integracin esperado de la WebApp. Esto es
con frecuencia es necesario integrar los sistemas de informacin existentes (por
ejemplo, una aplicacin existente de base de datos) con un planteamiento basado en
Web. Los t emas de conectividad se consideran en esta etapa.
17.1.2 Recopilacin de requisitos par a WebApps
Los mt odos para la recopilacin de requisitos se trataron en el captulo 7. Aunque
esta actividad puede abreviarse para la ingeniera Web, los objetivos globales de la
recopilacin de requisitos propuestos para la ingeniera de soft ware permanecen
inalterados. Adaptados para las WebApp, dichos objetivos se convierten en:
Identificar requisitos de contenido.
Identificar requisitos funcionales.
Definir escenari os de interaccin para diferentes clases de usuarios.
Los siguientes pasos de la recopilacin de requisitos se dirigen para lograr estos
objetivos:
de recopila- j _ P e d i r a i o s c i i e n t es que definan las categoras de usuario y describan cada ca-
ri* de requisitos
tegoria.
se apicaa para
I* WebApps? 2. Comunicarse con los clientes para definir los requisitos bsicos de la WebApp.
TM
PDF Editor
C A P T U L O 1 7 FORMULACIN Y PLANEACIN PARA INGENIERA WEB
521
3. Analizar la informacin recopilada y utilizar la informacin para realizar un
seguimiento con los clientes.
4. Definir casos de uso (captulo 8) que describan escenarios de interaccin para
cada clase de usuario.
Defi ni ci n de l as cat egor as de us uar i o. Se puede argumentar que la comple-
jidad de la WebApp es directamente proporcional al nmero de categoras de usua-
rio para el sistema. La definicin de una categora de usuario requiere formular un
conjunto de preguntas fundamentales:
Cul es el objetivo global del usuario cuando usa la WebApp? Por ejemplo, un
usuario del sitio de comercio electrnico de HogarSeguroInc.com puede estar
interesado en recopilar informacin acerca de productos de administracin del
hogar. Otro usuario tal vez desee comparar precios. Un tercer usuario quiere
comprar el producto HogarSeguro. Cada uno representa una clase o categora
diferente de usuario; cada uno tendr diferentes necesidades y navegar a travs
de la WebApp de manera diferente. Un cuarto usuario ya posee HogarSeguro y
busca soporte tcnico o quiere comprar sensores o accesorios adicionales.
Cules son los antecedentes y la pericia del usuario en relaci n con el contenido
y la Juncionalidad de la WebApp? Si un usuario tiene un antecedente tcnico y
una pericia significativa el contenido o la funcionalidad elementales ofrecern
poco beneficio. De manera alternativa, un nefito demanda contenido y
funcionalidad elementales y estara confundido si se perdiese.
C mo llegar el usuario a la WebApp? El arribo ocurrir a travs de un enlace
desde otro sitio Web (probablemente hacia contenido o funcionalidad dentro
de la WebApp), o llegar en una forma ms controlada?
Qu caractersticas genricas de la WebApps le gustan o disgustan al usuario?
Diferentes tipos de usuarios pueden tener distintos y predecibles gustos y
aversiones. Vale la pena el intento de determinar si los tienen o no. En
muchas situaciones la respuesta se puede averiguar preguntndoles cules
son sus WebApps favorita y menos favorita.
Al aprovechar las respuestas a estas preguntas se debe definir el ms pequeo con-
junto razonable de clases de usuario. Conforme se avanza en la recopilacin de
requisitos, cada diferente clase de usuario debe encuestarse para obtener datos.
Recopilaci n de requisitos para WebApps
El e s c e n a r i o : la oficina de Doug Los act ores : Doug Miiler, gerente del equipo de
ingeniera del software; Vinod Raman, i
TM
PDF Editor
522 PAETE TRES APLICACIN DE LA INGENIERA WEB
equipo de ingeniera del software HogarSeguro; ms
tarde, tres personas de mercadotecnia.
La conversacin:
Doug: La gerencia ha decidido que construyamos un
sitio de comercio electrnico para vender HogarSeguro.
Vi n o d : | Guau, Doug! No tenemos tiempo para hacer
eso. . . estamos empantanados con el t rabaj o de software
de producto.
Doug: l o s, lo s... subcontrafaremos el desarrollo con
una compaa especializada en la construccin de sitios
de comercio electrnico. Ellos nos dirn que lo tendrn
listo y corriendo en menos de un mes... muchos
componentes reutilizables.
Vi nod: Mmmmm. Bien... entonces por qu estoy aqu?
Doug: Para facilitar las cosos: quieren que nos
encarguemos de ta recopilacin de requisitos para el
sitio. Quiero que te entrevistes con los diversos clientes
pera comprender, aunque sea en forma mnima, los
requisitos bsicos.
Vi nod ( e x a s pe r a do ) : Doug... no me ests
escuchando... estamos apretados de tiempo y esto...
Doug ( i nt errumpe) : Slo dale un da de tu tiempo,
Vinod. Entrevstate con los tipos de mercadotecnia y
hazlos que especifiquen el contenido bsico, ta funcin;
t sabes, el procedimiento usual.
Vi nod ( res i gnado) : Est bien, los llamar y
concertar algo para maana, pero no me facilitas la
vida.
Doug ( sonr e) : Por eso te llevas tas billetes grandes.
Vi nod: Cierto.
(Vinod se entrevista con tres personas de mercadotecnia
al da siguiente.)
Vi nod: Me decan acerca de tas objetivos y
antecedentes de tas usuarios.
Pe r s ona d e me r c adot e c ni a # 1 : Como dije,
pretendemos que el usuario seo capaz de personalizar
todo el sistema HogarSeguro. T sabes: escoger
sensores, paneles de control, caractersticas y Funciones,
luego obtener una "cuenta de materiales" generada
automticamente, obtener la cotizacin y luego comprar
el sistema a travs del sitio Web.
Pe r s ona d e me r c adot e c ni a # 2 : Suponemos que el
usuario es propietario de una casa, no un tcnico, as
que necesitamos guiarlo a travs del proceso paso a
paso.
Pe r s ona de me r c adot e c ni a # 3 : Yo no soy tcnico,
pero me preocupan tas elementos especializados que
necesitamos elaborar adems de tas factores bsicos de
comercio electrnico.
Vi nod ( e nf r e nt ando al #3) : Qu quieres decir?
Pe r s ona de me r c adot e c ni a # 3 : La parte difcil ser
guiar al usuario a travs del "proceso de
personalizacin" en una forma simple y completa. El
asunto del comercio electrnico real es bastante directo.
Pe r s o na de me r c adot e c ni a # 1 : Tendremos que
ofrecer un nmero 800 para tas personas que no estn
dispuestas a realizar ta personalizacin por s mismas.
Pe r s o na d e me r c adot e c ni a # 2 : Estoy de acuerdo
Vi nos : Muy bien, tendremos que hablar acerca de
cmo les gustara exactamente hacer ta personalizacin
del producto como una actividad de prevenas, pero
dejemos eso por un momento. Tengo otras cuantas
preguntas fundamentales.
Vinod (ve a la persona de mercadotecnia #2):
Dijiste que queras guiar a tas usuarios a travs del
proceso. Algn enfoque especial?
Pe r s ona de me r c adot e c ni a # 2 : Quisiera ver un
proceso paso a paso, con espacios en blanco para
responder preguntas de requisitos bsicos, mens
desplegables, ese tipo de cosas. Cada paso es una
ventana, y tas datos de cada ventana se validan antes de
moverse al paso siguiente.
Vi nod: Has comprobado eso con usuarios
representativos?
Pe r s ona de me r c adot e c ni a #2: No, pero ta har
Vi nod: Una cosa ms. .. cmo encontrar nuestro sitio
un usuario?
Pe r s ona de me r c adot e c ni a #1: Estamos
t rabaj ando en una campaa publicitaria que colocar
www.HogarSegurolnc.com en anuncios de revistas,
correo dirigido a objetivos, anuncios sensibles a
contenido que aparecen en tas motores de bsqueda, y
tal vez incluso algunos spots de radio y televisin.
Vi nod: Lo que quiero decir es... tas usuarios siempre
entran a travs de ta pgina inicial.
Persona de mercadotecnia #3: Eso es ta que nos
gustara.
Vi nod: Muy bien, ahora tenemos que ponernos a
trabajar. Exploremos tas detalles de cmo quieren
personalizar tas sistemas en lnea.
TM
PDF Editor
C A P T U L O 1 7 FORMULACIN Y PLANEACIN PARA INGENIERA WEB 523
i meto-
de
i es
i emplear
[CONSEJO
i demora/la
i de los
; i operaciones
3 mientras
Keel
) del anlisis,
punto es ms
? la recopila-
i informaci n,
i ? valuaci n.
Comuni caci n con l os cl i ent es y us uar i os f i nal es. La mayora de las WebApps
tiene una amplia poblacin de usuarios finales. Aunque la creacin de categoras o
clases de usuario hace que una evaluacin de los requisitos de usuario sea ms
manejable, no es recomendable emplear informacin recopilada slo de una o dos
personas como la base para la formulacin o el anlisis. Se deben considerar ms per-
sonas (y ms opiniones y punt os de vista).
La comunicacin se puede lograr aprovechando uno o ms de los mecani smos
siguientes |FUC02a]:
Grupo muestraI tradicional. Un moderador ent renado se rene con un pequeo
(usualmente menos de 10 personas) grupo representativo de usuarios finales
(o participantes internos que los representan). El propsito es discutir la
WebApp que se desarrollar y, fuera de la discusin, comprender mejor los
requisitos del sistema.
Grupo muestraI electr nico. Un debate electrnico moderado dirigido con un
grupo de usuarios finales y participantes representativos. El nmero de parti-
cipantes puede ser mayor. Puesto que t odos los usuarios pueden participar al
mismo tiempo, es posible recopilar ms informacin en un periodo ms corto.
Dado que todo el debate se basa en texto es automtico un registro cont em-
porneo.
Entrevistas iterativas. Una serie de entrevistas breves, dirigida a usuarios repre-
sentativos y en la que se solicitan respuestas a preguntas especificas acerca de
la WebApp, se dirige a travs del sitio Web o mediante correo electrnico. Las
respuestas se analizan y aprovechan para afinar la entrevista siguiente.
Entrevistas de exploraci n. Encuesta basada en Web y ligada a una o ms
WebApps con usuarios similares a los que usarn la WebApp que se desarro-
llar. Los usuarios se enlazan a la entrevista y responden una serie de
preguntas (usualmente reciben alguna recompensa por participar).
Construcci n de escenarios. A usuarios seleccionados se les pide crear casos
de uso informales que describan interacciones especficas con la WebApp.
Anl i si s de l a i nf or maci n r ecopi l ada. Conforme se recopila informacin se
categoriza en clase de usuario y tipo de transaccin, y luego se valora segn su rele-
vancia. El objetivo es desarrollar listas de objetos de contenido, operaciones que se
aplican a los objetos de contenido dentro de una transaccin de usuario especfica,
funciones (por ejemplo, informativa, computacional, lgica y orientada a la ayuda)
que la WebApp proporciona a los usuarios finales, y otros requisitos no funcionales que
se advierten durant e las actividades de comunicacin.
Fuccella y Pizzolato [FUC02b] sugieren un mt odo simple (de baja tecnologa:
low-tech) para comprender cmo se deben organizar el contenido y la funcionalidad.
Se crea un paquet e de "cartas" para los objetos de contenido, las operaciones apli-
cadas a los objetos de contenido, la funciones WebApp y otros requisitos no funcio-
TM
PDF Editor
nales. Se baraj an las cart as y luego se distribuyen a las personas representativas de
cada categora de usuario. Se pide a los usuarios que ordenan las cart as en grupos
que reflejan cmo les gustara que se organi zara el cont eni do y la funcionalidad den-
tro de la WebApp. Luego se solicita a los usuarios que describan cada agrupamien-
to y las r azones por las que son i mport ant es para ellos. Una vez que cada usuar. :
realiza est e ejercicio, el equipo de ingeniera Web busca agrupami ent os comunes
entre diferentes cl ases de usuarios y otros agrupami ent os que sean nicos para ur.i
clase de usuari o especfica.
El equipo IWeb desarrolla una lista de etiquetas que se usarn para apunt ar la
informacin dentro de cada uno de los agrupamientos derivados con el uso de los paque -
tes de cartas. Entonces, a los diferentes usuarios representativos se les dan los
paquet es de cart as y se les pide ubicar el contenido y la funcionalidad a cada una r
las etiquetas. Aqu el prposito es det ermi nar cundo las etiquetas (enlaces de nt r j
de la WebApp real) implican de manera adecuada el acceso al cont eni do y las fun -
ci ones que los usuarios esperan encont rar det rs de la etiqueta. Este paso se apli:=
de manera iterativa hast a que se al canza el consenso.
^ O N S E J O ^
En lo Paite 2 de este
libio se trataron con
detalle los casos de
uso. Aunque muchos
abogan por el desa-
rrollo de casos de uso
muy largos, incluso
una nairoci n informal
proporciona alg n
beneficio. Convenza a
los usuarios paro que
escriban cosos de uso.
"Si IB que estos haciendo no lo puedes describir como un proceso, entonces no sabes lo que ests haciendo, "
W. L Deming
Des ar r ol l o de c a s os d e us o. Los casos de uso2 describen cmo interactuar con]
la WebApp una categora de usuario especifica (llamada actor) para lograr ur.a
accin especfica. La accin puede ser tan simple como adquirir cont eni do definid: ,
o tan compleja como que el usuario realice un anlisis detallado de registros sel ecJ
ci onados que se mant i enen en una base de dat os en lnea. Los casos de uso desce-
ben la interaccin desde el punt o de vista del usuario.
Aunque desarrollarlos y analizarlos toma tiempo, los casos de uso 1) ayudan U
desarrollador a ent ender cmo perciben los usuarios su interaccin con la WebApr J
2) proporcionan el detalle necesario para crear un model o de anlisis efectivo: ;-H
ayudan a dividir en compartimientos el trabajo de IWeb; y 4) ofrecen una gua impc - -I
tante para qui enes deben probar la WebApp.
CONJUNTO DE TAREAS
La comunicaci n con el cliente (Anlisis/Formulaci n)
1 . Identifiq ense a los clientes del
negocio. Exactamente quin es el
"cliente" de la WebApp? Qu
personas de negocios pueden funcionar como
expertos y usuarios finales representativos? Quin
participar como miembro activo del equipo?
2. Form lese el contexto del negocio. Cmo encaj a lo
WebApp en una estrategia de negocios ms ampl e'
3. Defnanse las metas y objetivos clave del negocio
para la WebApp. Cmo se medir el xito de la
WebApp, tanto en trminos cualitativos como
cuantitativos?
2 En los cap t ul os 7 y 8 se present aron con detalle las t cni cas par a desarrol l ar los casos de uso
TM
PDF Editor
C A P T U L O 1 7 FORMULACIN Y PLANEACIN PARA INGENIERA WEB 5 2 5
Defnanse las metas informativas y aplicables. Qu
das e de contenido se proporci onar a los usuarios
anales? Qu funci ones/ t areas se l ograrn cuando
se use la WebApp?
identifiq ese el problema. Qu problema especfico
resuelve la WebApp?
\
6. Recoplense requisitos. Qu t areas del usuario se
l ograrn mediante el uso de la WebApp? Qu
contenido se desarrollar? Qu metfora de
interaccin se usar? Qu funciones
computacionales proporci onar la WebApp? Cmo
se configurar la WebApp par a su utilizacin en
red? Qu esquema de navegacin se desea?
proyectos
se puede
una simple
a datos de
' (con la
de uno hoja
' en lugar
UML Esto
todos los
del equipo
losrequi-
e contenido
' entregado
mejor el
ujode
que ocurrir.
17.1.3 El puente hacia el modelado de anlisis
Como ya se ha seal ado en este captulo, las actividades que conducen a un equipo
de ingeniera Web de la formulacin al model ado de anlisis representa un continuo.
En esencia, el grado de abstraccin considerado durante las primeras et apas de la
formulacin es la estrategia del negocio. Sin embargo, conforme la formulacin se
lleva a cabo, se analizan los detalles tcticos y se abordan los requisitos especficos
de la WebApp. Finalmente, est os requisitos se modelan (con la utilizacin de casos de
uso y notacin UML).
Los concept os y principios tratados para el anlisis de requisitos de soft ware
(captulos 7 y 8) se aplican sin revisin para la actividad de anlisis de ingeniera
Web. Durante el anlisis se elabora el mbi t o definido durante la actividad de for-
mulacin para crear un modelo de anlisis completo para la WebApp. En la IWeb se
realizan cuatro tipos diferentes de anlisis: del contenido, de la interaccin, de la
funcin y de la configuracin. En el captulo 18 se exponen las tareas y tcnicas de
model ado asoci adas con cada uno de estos anlisis.
"Al fracasar para preparar, se prepara para el fracaso. "
Benjamn Frankfin
1 7 . 2 P L ANE ACI N PE PROYECTOS PE I NGENI ER A WE B
Dada la inmediatez de las WebApps es razonable preguntar: en realidad se necesi-
ta gastar tiempo en la planeacin y administracin de un esfuerzo WebApp? No slo
se debera dejar evolucionar naturalmente a la WebApp, con poca o ninguna gestin
explcita? Ms de un desarrollador Web optara por poca o ninguna gestin, pero
eso no hace que estn en lo correcto!
La figura 17.1 presenta un cuadro adapt ado de Kulik y Samuelson [KULOO] que
indica cmo los "proyectos electrnicos" (e-projects, su trmino para los proyectos
WebApp) se comparan con los proyectos de soft ware tradicionales. Al consultar la
figura, los proyectos de soft ware tradicionales y los grandes proyectos electrnicos
tienen similitudes sustanciales. Dado que la gestin del proyecto se indica para los
proyectos tradicionales, parecera razonable argumentar que tambin estara indi-
cada para los grandes proyectos electrnicos. Los pequeos proyectos electrnicos
tienen caractersticas especiales que los diferencian de los proyectos tradicionales.
Sin embargo, incluso en el caso de los pequeos proyectos electrnicos, la pl anea-
TM
PDF Editor
P AR T E T RE S APLICACIN DE LA INGENIERA WEB
Di f er enci as ent r e pr oyect os t r adi ci onal es y el ect r ni cos (e-proj ect s) [ a d a p t a d o de KULOO]
Proyectos tradicionales
Pequeos proyectos
electrnicos
Grandes proyectos
electrnicos
Recopilacin
de requisitos
Ri gur oso Li mi t ada Ri gur osa
Especificaciones
tcnicas
Robust as: model os ,
e s pe c i f i c a c i one s
Pa n o r a ma des cr i pt i vo
Robust a: mod e l os UMl ,
e s pe c i f i c a c i one s
Duracin del proyecto
Me d i d a en mes es
o a o s
Me d i a d a e n d i a s ,
s e ma n a s o mes es
Me d i d a e n me s e s
o a o s
Prueba y aseguramiento
de la calidad
Enf oc a d a en l ogr ar
bl a nc os d e c a l i da d
En f o c a d a s obr e cont r ol
d e r i e s go
As e gur a mi e nt o d e la
c a l i d a d del s of t war e c o mo
se d e s c r i be en el capi t ul o 2 6
Gestin de riesgos Expl ci t a I nher ent e Explcita
Vida media
de los entregables
8 me s e s o m s
De 3 a me s e s
o m s cor t o
De 6 a 12 mes es
o m s cor t o
Proceso de liberacin Ri gur oso Expedi t o Ri gur oso
Retroalimentacin
del cliente despus
de la liberacin
Requi er e e s t ue r z o
pr oact i vo
S e o b t i e n e
a ut om t i c a me nt e d e l a
i nt er acci n c o n el us uar i o
Se obt i e ne t a nt o d e
ma n e r a a ut om t i c a c o mo
por me d i o d e sol i ci t ud
d e r et r oal i ment aci n
cin se debe realizar, se deben considerar los riesgos, se debe establecer un prog:
ma y se deben definir controles de modo que eviten la confusin, la frustracin y
fracaso.
1 7 . 3 E l E Q. UI P Q DE I N G E N I E R A W E B i
Un equipo de ingeniera Web exitoso mezcla una amplia variedad de talentos c J !
deben trabajar como equipo en un ambi ent e de proyecto con alta presin. Los p I
zos son cortos, los cambios son inexorables y la tecnologa contina cambiando
creacin de un equipo que se consolide (vase el captulo 21) no es asunt o sene, a
"En el mundo actual, alimentado por la Web y centrado en lo red, uno necesita saber mucho de muchos temos. "
Scot Tilley y Shihoog Huanj
17.3.1 Los actores
La creacin de una aplicacin Web exitosa demanda un amplio abanico de hbil: l
des. Tilley y Huang (TIL99] abordan este tema cuando afirman: "Existen tantos m
rentes aspectos del software de aplicacin [a la Web] que se ha dado el (re)surgi mi er*
del renacentista, aquel que se siente cmodo t rabaj ando en varias disciplinas . a
Aunque los autores estn en lo correcto, los "renacentistas" son r el at i vame- *
pocos, y dadas las demandas asoci adas con los grandes proyectos de desarrolle M
WebApps, el conjunto de diversas habilidades requeridas puede ser mejor d i s t r i t o
do entre un equipo de ingeniera Web.
Los equipos de ingeniera Web se pueden organizar, en gran medida, en la mi s r J
forma que los equipos de soft ware tradicionales (captulo 21). Sin embargo, los and
5 2 6
TM
PDF Editor
res y sus papeles usual ment e son bast ant e diferentes. Entre las muchas habilidades
que se deben distribuir entre los miembros del equipo IWeb se encuentran: ingenie-
ra del soft ware basada en component es, realizacin de redes, diseo arquitectni-
co y de navegacin, l enguaj es/ est ndares de Internet, diseo de interfase humana,
diseo grfico, disposicin del contenido y pruebas de las WebApps.
Los siguientes papeles3 se deben distribuir ent re los miembros del equipo IWeb:
De s a r r ol l a dor e s / pr ove e dor e s de cont eni do. Dado que el contenido contro-
iesempe- a i nherent ement e las WebApps, una funcin del equipo IWeb se debe enfocar en la
generacin o recopilacin del contenido. Recurdese que el contenido abarca un
amplio abanico de objetos de datos, por ello los desarrolladores/proveedores de
contenido pueden provenir de diversos mbitos (no de software).
Edi t or es d e web. El variado contenido que generan los respectivos desarrolla-
dores/ proveedores se debe organizar para incluirlo en la WebApp. Adems, alguien
debe actuar como conexin entre el equipo tcnico que disea la WebApp y los desa-
rrolladores/proveedores de contenido sin conocimientos tcnicos. Este papel lo
satisface el editor de Web, quien debe entender tanto el contenido como la tecnolo-
ga de la WebApp.
I ngeni er o Web. El ingeniero Web se involucra en un amplio rango de activida-
des durante el desarrollo de una WebApp, que incluyen la obtencin de requisitos, el
model ado de anlisis, el diseo arquitectnico, de navegacin y de interfase, la
implementacin de la WebApp y las pruebas. El ingeniero Web tambin debe tener
una slida comprensin de las tecnologas de component es, de las arquitecturas
cliente/servidor, de HTML/XML y de tecnologas de bases de datos, y un conoci-
mi ent o prctico de los conceptos multimedia, de las plataformas hardware/ soft wa-
re, de la seguridad de redes y de cuestiones de apoyo a sitios Web.
Exper t os en domi ni os empr es ar i al es . Un experto en dominio empresarial
debe ser capaz de responder todas las preguntas relacionadas con metas, objetivos
y requisitos empresariales relacionados con la WebApp.
Especi al i st a d e s opor t e. Este papel se asigna a la persona (personas) que es
(son) responsable(s) del apoyo continuo a la WebApp, Puesto que las WebApps evolu-
cionan continuamente, el especialista de soporte es responsable de las correcciones,
adaptaciones y mejoras al sitio, que incluyen actualizaciones de contenido, imple-
mentacin de nuevos procedimientos y formas, y cambios al patrn de navegacin.
Admi ni s t r ador . Usualmente llamado "web master", esta persona tiene la res-
ponsabilidad de la operacin diaria de la WebApp, lo que incluye: desarrollo e imple-
mentacin de polticas para la operacin de la WebApp, establecimiento de procedi-
mi ent os de soporte y retroal i mentacin, implementacin de seguridad y derechos de
acceso, medicin y anlisis de trfico del sitio Web, coordinacin de los procedi-
mientos de control de cambios (captulo 27) y coordinacin con el especialista de
3 Estos papeles se han adapt ado de Hansen y sus colegas |HAN99]
TM
PDF Editor
^ O H S E J O ^
Estos caractersticas
son usuales en los
equipos de colabora-
dores outoorganizodos
que bar adoptado un
enfoque gil (capitulo
4 ). Mientras mejor
sea el equipo, mejor
ser el producto de
software que se
produzca.
soporte. El administrador tambin puede estar involucrado en las actividades tcni-
cas que realizan los ingenieros Web y los especialistas de soporte.
17.3.2 Construccin del equipo
En el captulo 21 se tratarn con cierto detalle los lincamientos para la construccin
exitosa de los equipos de ingeniera del software. Pero, estos lincamientos se apli-
can en el apretujado mundo de los proyectos WebApp? La respuesta es s.
Hace algn tiempo, en su xito de librera acerca de la industria de la compu-
tacin, Tracy Kidder [KIDOO] cuenta la historia del heroico intento de una compa a
de computacin por construir una computadora para enfrent ar el reto de un nuevo
producto que fabric un competidor ms grande.4 La historia es una metfora del equi-
po de trabajo, del liderazgo y del aplastante estrs que todos los tecnlogos encuer
tran cuando los proyectos crticos no avanzan tan suavement e como se plane.
Un resumen del libro de Kidder difcilmente le hace justicia, pero los siguiente;
punt os clave [PICO 1 ] tienen particular relevancia cuando una organizacin const r j
ye un equipo de ingeniera Web:
Se d e b e es t abl ecer un c onj unt o d e di r ect r i ces d e equi po. Dichas directr.-]
ees abarcan lo que se espera de cada persona, cmo se lidiar con los probl ema; ;
qu mecani smos existen para mejorar la efectividad del equipo conforme avanza i
proyecto.
El l i der azgo f ue r t e e s una obl i gaci n. El lder del equipo debe guiar mee
te el ejemplo y el contacto. Debe mostrar un grado de ent usi asmo que impulse a
otros mi embros del equipo "a endosarse" psicolgicamente al t rabaj o que enfrent,
El r e s pe t o haci a l os t al ent os i ndi vi dual es e s cr uci al . Nadie es bueno
todo. Los mej ores equipos utilizan las fortalezas individuales. Los mej ores lderes:
equipo permiten que los individuos tengan libertad para seguir una buena idea.
Cada mi e mb r o del equi po s e d e b e c ompr ome t e r . El protagonista princ
en el libro de Kidder le llama a est o "endoso".
Es fcil comenzar , l o difcil e s ma nt e ne r el mpet u. Los mejores equipos ni
dejan que un problema "insuperable" los detenga. Los miembros del equipo de
lian una solucin "lo suficientemente buena" y proceden, con la esperanza de
mpetu del progreso pueda conducirlos a una solucin todava mejor en el largo pU
Una vez realizada la formulacin y que se han identificado los requisitos bsico; i
la WebApp, la empresa debe elegir una de dos opciones de ingeniera Web: 1|
WebApp es subcontratada (outsourced): la ingeniera Web la realiza un tercer prc
4 El libro de Kidder, The Soul of a New Machine, originalmente publicado en 1981, es una lectura i
t ament e recomendable para cualquiera que intente realizar una carrera en la computacin y |
quienes ya la tienen!
TM
PDF Editor
dor con experiencia, talento y recursos con los cual es no cuent e la empr esa; o 2) la
WebApp la desarrollan en casa i ngeni eros Web que sean empl eados de la empresa.
Una t ercera opci n (hacer al gn t rabaj o de ingeniera Web en casa y subcont rat ar
ot ro trabajo) t ambi n es una posibilidad.
"Como observ Thomns Hobbs en el siglo xvu, lo vido bajo las reglas de las pandillas es solitario, pobre, peligroso,
cruel y corta, l a vida en un proyecto de soft ware que corre pobrement e; es solitario, pobre, peligrosa, cruel y con
dificultad al guna vez es lo sufi ci ent ement e cort a. "
Sfsven McConnell
El t rabaj o que debe real i zarse sigue si endo el mi smo sin importar si una WebApp
es subcont r at ada, desarrol l ada en casa o distribuida ent r e un proveedor ext erno y el
equi po de casa. No obst ant e, s cambi an los requisitos de comuni caci n, la distribu-
cin de actividades tcnicas, el grado de interaccin ent re clientes y desarrol l adores,
y una diversidad de ot ros conflictos cruci al ment e i mport ant es.
La figura 17.2 ilustra, respect o a las WebApps, la diferencia organi zaci onal ent r e
subcont rat aci n y desarrol l o en casa. ste (figura 17.2a) integra di rect ament e t odos
los mi embros del equi po de ingeniera Web (el crculo punt eado implica integracin).
La comuni caci n se est abl ece medi ant e los cami nos de la organi zaci n. En cuant o
a la subcont rat aci n (figura 17.2b), es i mprct i co y desaconsej abl e que cada el e-
ment o de casa (por ejemplo, desarrol l adores de cont eni do, accionistas, i ngeni eros
Web internos) t enga comuni caci n directa con el subcont rat i st a sin que exista algn
el ement o de conexi n para coordi nar y cont rol ar la comuni caci n. En las secci ones
que siguen s e exami nar n con ms detalle las pl aneaci ones para la subcont rat aci n
y el desarrol l o en casa.
t e me r o s
Es p e c i a l i s t a s
d e s o p o r t e ^
I vendedor De s ar r ol l ador e s '
\ d c o n t e n i d o /
/ Ad mi n i s t r a d o r ;
S u b c o n t r a t i s t a
Ge r e n t e s
n e g o c i o s / Cl i e n t e s
Me r c adot e c ni a
U s u a r i o s
f i n a l e s
v e n t a s
I n g e n i e r o s
Es p e c i a l i s t a s
l d e s o p o r t e ^
De s ar r ol l ador e s .
' Admi ni st rador^
c ont e ni do.
Edi t or
W e b
Ge r e n t e s
n e g o c i o s
Cl i e n t e s
Mercadot ecni
Us u a r i o s
f i n a l e s
v e n t a s
a s
" v a s
s ubcont r at a-
y desar r ol l o
casa.
a) De s a r r o l l o e n c a s a b) De s a r r o l l o s u b c o n t r a t a d o
TM
PDF Editor
^ O N S t J O ^
No se supongo que,
puesto que se ha
subconliatado una
WebApp, las responsa-
bilidades son
mnimas. De hecho,
es probable que se
requieran ms, no
menos, supervisi n y
gesti n.
17.4.1 Planeacin de WebApp: subcontratacin
Un porcent aj e sustancial de las WebApps se subcontrata con proveedores que
(supuestamente) se especializan en el desarrollo de si st emas y aplicaciones basados
en Web.5 En tales casos, un negocio (el cliente) pide un precio fijo para desarrollar la
WebApp de uno o ms proveedores, evala los precios competitivos y luego elige un
proveedor para efectuar el trabajo. Pero, qu busca la organizacin contratante?
Cmo se determina la competencia de un proveedor de WebApps? Cmo se sabe
si una cotizacin es razonable? Qu grado de planeacin, programa de trabajo y
valoracin de riesgo se pueden esperar conforme una organizacin (y su subcontra-
tista) se embarca en un esfuerzo por desarrollar una gran WebApp?
"Muchos empresas de Fortune 500 hon descubierto al software como un modelo de servicio [subcontratado] y estn
contratando modelos similares interna o ext ernament e. "
Nkk Evans
^CONSt J O^.
Algunos personas
argumentan que " el
diseo aproximado"
es innecesario. Vase
como una " primero
oferta" que el
proveedor subcontro-
tisto puede modificar
y mejorar. Al menos
est comunicando sus
ideas acerca de a qu
se debe parecer el
resultado final.
Estas preguntas no siempre son fciles de contestar, pero vale la pena considerar
algunos lincamientos.
Ini ci o del pr oyect o. Si la subcontratacin se elegir como la estrategia para desa-
rrollar la WebApp, la organizacin debe realizar una serie de tareas ant es de
buscar una empresa subcontratista que haga el trabajo:
1 . Realizar, internamente, muchas de las labores de anlisis tratadas en la secci n
1 7.1 .3 (y en el captulo 1 8). Se identifica el pblico para la WebApp; se hace
una lista con los accionistas internos interesados en la WebApp; se definen y
revisan las met as globales para la WebApp; se especifican la informacin y
servicios que habr de proporcionar la WebApp; se dest acan los sitios Web
competidores; y se identifican las "medidas" cualitativas y cuantitativas de
una WebApp exitosa. Esta informacin deber document arse en una especifi-
cacin de producto que se entregar al subcontratista.
2. Desarrollar internamente un diseo aproximado de la WebApp. Obviamente, un
desarrollador Web experto crear un diseo completo, pero es posible ahorrar
tiempo y costo si la visin y el sentido general de la WebApp se identifican
para la empresa subcontratista (esto siempre puede modificarse durant e las
et apas preliminares del proyecto). El diseo debe incluir una indicacin del
tipo y volumen de contenido que se presentar en la WebApp y los tipos de
procesami ent o interactivo (por ejemplo, formatos, entrada de pedidos) que se
llevarn a cabo. Esta informacin deber agregarse a la especificacin del
producto.
5 Aunque es difcil encont rar dat os industriales confiables, puede afi rmarse que est e porcent aj e es
consi derabl ement e mayor que el que s e observa en el t rabaj o de sof t war e convenci onal . En el cap- -I
tulo 23 se ofrece una exposicin adicional acerca de la subcont rat aci n.
TM
PDF Editor
C A P I T U L O 1 7 FORMULACIN Y PLANEACIN PARA INGENIERA WEB 531
3. Elaborar un programa aproximado que incluya no s lo las fechas finales de en-
trega, sino tambin fechas clave. Las fechas clave se deben adj unt ar a las ver-
siones de entrega (incrementos) de la WebApp conforme sta evolucione.
4. Crear una lista de responsabilidades para la organizaci n interna y el subcontra-
tista. En esencia, esta tarea aborda qu informacin, contactos y otros recur-
sos se requieren de ambas organizaciones.
5. Identificar el grado de supervisi n e interacci n de la organizaci n contratante
con el subcontratista. Esto debe incluir el nombre del contacto del vendedor y
la identificacin de las responsabilidades y autoridad del contacto, la defini-
cin de los punt os de revisin de calidad conforme avance el desarrollo, y las
responsabilidades del subcontratista en relacin con la comunicacin entre
las organizaciones.
i l i r e c - Toda la informacin generada durante estos pasos deber organizarse en una
deben solicitud de presupuesto que se entrega las empresas candidatas. 6
ido se
varios Sel ecci n e nt r e l os s ubc ont r a t i s t a s candi dat os . En los ltimos aos han sur-
tas? gido miles de compa as de "diseo Web" dedicadas a ayudar a las empresas que
desean establecer una presencia Web o aventurarse en el comercio electrnico.
Muchas se han vuelto adictas al proceso de IWeb, pero muchas otras son poco ms
que hackers (intrusos informticos). Con la finalidad de elegir desarrolladores Web
candidatos, el cont rat ant e debe realizar al gunas diligencias obligadas: 1) entrevistar
a los clientes antiguos para determinar el profesionalismo del vendedor Web, as
como su habilidad para cumplir con compromisos de plazos y costos, y su destreza
para comunicarse efectivamente; 2) determinar el nombre del ingeniero(s) Web jefe
de la empresa subcontratista para buscar proyectos anteriores exitosos (y, despus,
asegurarse de que est a persona tenga la obligacin contractual de estar involucrada
en su proyecto); y 3) exami nar cui dadosament e ejemplos del t rabaj o del subcontra-
tista que sean similares en apariencia y sentido (y rea de negocios) a la WebApp que
ser contratada. Incluso ant es de que se ofrezca una solicitud de presupuesto, una
entrevista personal puede ofrecer un discernimiento sustancial de la "conexin"
ent re el cont rat ant e y el subcontratista.
"Si pagas cacahuates, obtienes monos. "
George Peppard en el papel del coronel John "Hannibol" Smith en The A-Team
(serie televisiva de tos ochenta)
Val oraci n d e l a val i dez d e l as cot i zaci ones y l a conf abi l i dad de l as est i -
ma c i one s . Puesto que existen relativamente pocos dat os histricos y que el mbi -
to de las WebApps es fluido en forma notoria, la estimacin es i nherent ement e ries-
6 Si el t rabaj o de desarrol l o de la WebApp lo dirigir un grupo interno, no cambi a nada! El proyect o
se inicia de la mi sma maner a.
TM
PDF Editor
\
CLAVE
En lo gestin del
mbito se congelo el
trabajo que voyo o
realizarse en un
incremento. Los
cambios se demoran
hasta el siguiente
memento d e l a
gosa. Por esta razn, algunos proveedores incorporarn mrgenes de seguridad sus-
tanciales en cotizaciones para un proyecto. Esto es comprensible y apropiado. La
pregunta no es si se ha obtenido la mejor solucin por la inversin. Ms bien, las pre
gunt as deben ser:
La cotizacin de la WebApp ofrece un rendimiento sobre la inversin, direct :>
o indirecto, que justifique el proyecto?
La empresa emisora de la cotizacin tiene el profesionalismo y la expe-
riencia que se requieren?
Si las respuest as a est as pregunt as son afirmativas la cotizacin es justa.
Compr e ns i n del gr a d o d e ges t i n del pr oyect o q u e pue d e e s pe r a r o real?
zar . La formalidad asociada con las labores de gestin del proyecto (que realizan d
proveedor y la organizacin contratante) es directamente proporcional al t amar :
cost o y complejidad de la WebApp. Respecto a proyectos complejos y grandes
necesario elaborar un programa del proyecto que defina las t areas del trabajo,
punt os de comprobacin, el asegurami ent o de la calidad del software, los produ
de t rabaj o de ingeniera, los punt os de revisin del cliente y los hitos importantes,
proveedor y el contratante tendrn que valorar el riesgo conj unt ament e y elat
planes para mitigar, monitorear y manejar los riesgos considerados important
Los mecani smos para asegurar la calidad y el control de cambios se debern def
explcitamente por escrito. Se debern establecer mt odos para la comunica"
efectiva entre el cont rat ant e y el proveedor.
Eval uaci n del pr ogr a ma del pr oyect o. Dado que los programas de desan-
de WebApps abarcan un periodo relativamente corto (por lo general menos de
o dos meses para que se entregue el incremento), el programa para el desarr
debe tener una dosificacin muy precisa. Es decir: las tareas de trabajo y los hi
menor es se deben programar en un cronograma diario. Esta dosificacin pre'
permite, t ant o a la organizacin cont rat ant e como al subcontratista, reconocer
hoja suelta de la agenda ant es de que amenace la fecha de finalizacin.
Ges t i n del mbi t o. Como es enormement e probable que el mbi t o cambiar c
forme avance el proyecto de la WebApp, el modelo de proceso IWeb es adaptable
incremental. Esto permite que el equipo de desarrollo del subcontratista "congele"
mbi t o para un incremento, de modo que se pueda crear una liberacin operativa
la WebApp. El siguiente incremento puede abordar cambi os en el mbito que
sugerido una revisin del incremento precedente, pero una vez que comience
segundo incremento el mbito nuevament e se "congela" de manera temporal,
enfoque permite que el equipo de la WebApp trabaje sin tener que acomodar
corriente continua de cambios, pero al mismo tiempo reconoce la evolucin co
nua caracterstica de la mayora de las WebApps.
Los lineamientos sugeridos lneas at rs no intentan ser un recetario a prueba
tontos para la produccin a tiempo de WebApps de baj o costo. Sin embargo, a
TM
PDF Editor
CAPTULO 17 FORMULACIN Y PLANEACIN PARA INGENIERA WEB 5 3 3
rn t ant o a la organi zaci n cont rat ant e como al subcont rat i st a a iniciar el t rabaj o de
maner a flexible con un m ni mo de mal as i nt erpret aci ones.
Preliminares para la subcontrataci n
0 escenari o: la oficina de Doug Miller.
i Doug Miller (gerente del equi po de
del software HogarSeguro) y Sharon Woods,
e-CommerceSystems, el proveedor
par a el sitio Web de comercio electrnico
y gerente del equi po de ingeniera Web
el t rabaj o.
rsacin:
Sharon, qu bueno que por fin nos encontramos.
al go de t rabaj o que realizar en el
mes, ms o menos.
( s onr e ) : Tenemos, pero parece que ustedes se
debidamente. Vinod ya nos ha da do un
de especificaciones par a el sitio y tambin ho
la mayor part e de los objetos de contenido
y de la funcionalidad del sitio.
Bien. Qu ms necesitan?
La funcionalidad de comercio electrnica es
l o que me preocupa es la f achada el t rabaj o
requiere par a que los usuarios personalicen el
ant es de la compra.
Vinod te di o el procedimiento bsico, no es as?
S, lo hizo; per o quiero validarlo con algunos
Bales. Tambin necesitamos contactar a sus
de contenido par a obtener descripciones
par a cada sensor, di buj o, lista de precios,
interfase/interconexin, ese tipo de cosas.
Vinod tiene tiempo par a hacerles un sloryboard
proceso de personalizacin?
Shar on: Est t r abaj ando en l mientras platicamos. Dijo
que tena que poner un seguro en el l ado del producto.
Sabe que es crucial,.. di jo que me lo enviara por correo
electrnico maana en la maana.
Do ug : Muy bien. . . mira, me gustara estar en el
trayecto de este proyecto. Podemos establecer al gunas
reglas bsi cas par a supervisar desde nuestra parte. No
quiero entrometerme en tu cami no, pero. . .
Shar on: No hay probl ema, nos gusta tener
involucrados a nuestros clientes.
Do ug : Yo t r abaj ar como contacto par a este proyecto.
Toda comunicacin vendr a travs mo o de alguien
como Vinod, a quien yo cite. Puesto que estamos en un
calendario apret ado, me gustara establecer una agenda
que tenga una dosificacin di ari a y habl ar contigo o
enviarte correos electrnicos todos los d as acerca de los
logros, los problemas, etctera. S que es mucho, pero
creo que eso es lo adecuado.
Shar on: Est bien.
Doug (toma al gunas hojas de papel de su
escritorio y las entrega a Sharon): Escrib una
agenda apr oxi mada con fechas lmite... qu opi nas?
Sharon (luego de estudiar ta agenda):
Mmmmm, no estoy segura de que esto funcionar par a
nosotros. Dj ame t r abaj ar una alternativa y hoy en la
t arde te la envo por correo electrnico.
Do ug : Claro.
17.4.2 Planeacin de WebApp: ingeniera Web en casa
Conforme las WebApps se vuel ven ms ext ensas y est rat gi cas para los negocios,
muchas compa as han opt ado por cont rol ar el desarrol l o en casa. No sorprende que
la IWeb en casa se gest i one de maner a un poco diferente a un esf uer zo de subcon-
tratacin.
"Qu haces cuando necesitas t ener listo un sitio Web paro ayet?"
James lewin
TM
PDF Editor
^ N S I J O ^
Es importanle
reconoce/que los
pasos analizados en
esto secci n se
pueden realizar rpi-
damente. En ning n
coso la planeaci n
IWeb pora proyectos
de este tamao tomo
ms del 5 por ciento
del esfuerzo del
proyecto global.
La gestin de proyectos IWeb pequeos y de t amao moderado (es decir: me
de 3-5 meses de duracin) requiere un enfoque gil que quite el nfasi s en la ges
del proyecto pero no elimine la necesi dad de planear. Todava se aplican los pri
pos bsicos de gestin de proyectos (captulo 21), pero el enf oque global es
parco y menos formal. Sin embargo, conforme crece el t amao del proy
WebApp, la gestin del proyecto de ingeniera Web se vuelve ms y ms como
gestin de proyectos de ingeniera del soft ware (Parte 4 de est e libro). Los
siguientes se recomi endan para proyectos IWeb pequeos y de t amao moderado
Ent e nde r el mbi t o, l as d i me ns i one s de c a mb i o y l as r es t r i cci ones del
yect o. Ningn proyecto, sin importar cun apretada sea la restriccin del tie.
puede comenzar mi ent ras el equipo del proyecto no entienda qu debe construir
recopilacin de requisitos y la comunicacin con el cliente son precursores esenci)
les para la planeacin efectiva de la WebApp.
Def i ni r una es t r at egi a d e pr oye c t o i nc r e me nt a l . Ya se ha seal ado que '
WebApps evolucionan con el tiempo. Si la evolucin es descontrolada y catica
probabilidad de un resultado exitoso es pequea. Sin embargo, si el equipo est
ce una estrategia de proyecto que defina i ncrement os (liberaciones) de WebApp
proporcionen contenido til y funcionalidad a los usuari os finales, el esfuerzo
ingeniera puede enfocarse con mayor facilidad.
Real i zar anl i si s d e r i es go. En el captulo 25 se present a una exposicin
liada del anlisis de riesgo para proyectos tradicionales de ingeniera del software
Todas las labores de gestin de riesgo se realizan para proyectos IWeb, pero su en
que se abrevia.
Los riesgos que ent raan el programa y la tecnologa domi nan la preocupaa
de la mayora de los equipos de ingeniera Web. Entre las muchas preguntas re:
nadas con el riesgo que el equipo debe formular y responder estn: Los incremer"
WebApp pl aneados pueden ent regarse en los plazos definidos? Estos i ncremer:
proporcionarn valor subsecuente para los usuarios finales mientras se realiza
ingeniera de incrementos adicionales? Cmo impactan las fechas de entrega
solicitudes de cambios? El equipo comprende los mtodos, tecnologas y
mi ent as de ingeniera Web requeridos? La tecnologa disponible es adecuada para
trabajo? Los cambi os probables requieren la introduccin de nueva tecnologa?
Des ar r ol l ar una e s t i ma c i n r pi da . El ej e de la estimacin para la mayora
los proyectos de ingeniera Web lo representan los conflictos macroscpicos, OT
que los microscpicos. El equipo IWeb valora si los i ncrement os WebApp plan
pueden desarrollarse con los recursos disponibles de acuerdo con las restriccior
del programa definido. Esto se logra consi derando el cont eni do y la funcin de i
7 Aquellos lectores que no estn familiarizados con la terminologa y las prcticas bsicas de la
tin de riesgos debern consultar en este moment o el capitulo 25.
TM
PDF Editor
incremento como un todo. Normalmente no se realizan rompimientos "microscpi-
cos", funcionales o de trabajo, del incremento que sean seguidos por el clculo de
estimaciones puntuales de mltiples dat os (vase el captulo 23).
Elegir un c onj unt o d e t a r e a s ( descr i pci n del pr oces o) . Empleando un marco
de t rabaj o del proceso (capitulo 16) se elige un conjunto de tareas de ingeniera Web
que sean adecuadas para las caractersticas del problema, el producto, el proyecto y
la gente en el equipo de ingeniera Web. Reconzcase la posibilidad de adaptar el
conjunto de t areas para que encaj e en el desarrollo de cada incremento.
Es t abl ecer un pr ogr a ma . El programa de un proyecto IWeb tiene una dosifica-
cin relativamente precisa respecto de las tareas que se realizarn en el corto plazo,
y luego una mucho ms flexible durante periodos posteriores (cuando vayan a entre-
garse los incrementos adicionales). Esto es, las t areas de ingeniera Web se distribu-
yen a lo largo de la lnea de tiempo del proyecto para el incremento que se desarro-
llar. La distribucin de t areas para subsecuent es incrementos WebApp se demora
hasta la entrega del incremento programado.
Def i ni r me c a n i s mo s de r a s t r e o del pr oyect o. En un ambiente de desarrollo
gil, la entrega de un incremento operativo de soft ware con frecuencia es la medida
primaria del progreso. Pero mucho ant es de que el software liberable est disponi-
ble, el ingeniero Web enfrent ar inevitablemente la pregunta: dnde estamos? En el
trabajo convencional de ingeniera del soft ware el progreso se mide det ermi nando
qu objetivos se han logrado (por ejemplo, la revisin exitosa de un producto de tra-
bajo). Respecto a proyectos de ingeniera Web pequeos y de t amao moderado, los
objetivos pueden estar menos definidos, y las actividades formales de aseguramien-
to de la calidad pueden perder fuerza. En consecuencia, es posible derivar una res-
puesta si se entrevista al equipo de ingeniera Web para determinar qu actividades
del marco de trabajo se han completado. No obstante, este enfoque puede ser poco
fiable. Otro enfoque es determinar cunt os casos de uso se han implementado y
cunt os (para un incremento dado) permanecen sin implementarse. Esto proporcio-
na una indicacin aproximada del grado relativo en que se ha completado el incre-
ment o del proyecto.
"El progreso se logro corrigiendo los errores resultantes de lograr el progreso".
Claude Gibb
Es t abl ecer un e nf oq ue d e ges t i n del cambi o. La gestin del cambi o se facili-
ta mediante la estrategia de desarrollo incremental que se recomend para las
WebApps. Puesto que el tiempo de desarrollo para un incremento es corto, con fre-
cuencia es posible demorar la introduccin de un cambio hasta el siguiente incre-
ment o, con la consiguiente reduccin de los efectos de demora asociados con los
cambi os que se deben implementar "al vuelo". En el captulo 27 se present a la ges-
tin de la configuracin y el contenido para las WebApps.
TM
PDF Editor
Gesti n de proyectos IWeb

Obj et i vo: Auxiliar al equipo de ingeniera
Web en la planeacin, gestin, control y rastreo
de proyectos de ingeniera Web.
Mecni ca: Las herramientas de gestin de proyectos le
permiten a un equipo IWeb establecer un conjunto de
tareas de trabajo, asignar esfuerzo y especificar
responsabilidad a cada tarea, establecer dependencia de
tareas, definir un programa y rastrear y controlar las
actividades del proyecto. Muchas herramientas en esta
categora estn basadas en Web.
Herramientas representativas8
Business Engine, desarrollado por Business Engine
(www.businessengine.com), es una suite de
herramientas basadas en Web que ofrecen facilidades
de gestin para proyectos completos de IWeb y
proyectos de software convencionales.
Ileamwork, desarrollado por iTeamwork.com
(www.iteamwork.com), "es una aplicacin de equipo de
gestin de proyecto gratuita, en lnea y basada en
Web, que puede usar con su navegador web".
OurProject, desarrollado por Our Project
(www.ourproject.com), es una suite de herramientas de
gestin de proyecto que son aplicables a la IWeb y a
los proyectos de software convencionales.
Proj-Nel, desarrollado por Ratonal Concepts, Inc.
(www.rationalconcepts.com), "implementa una oficina
de proyecto virtual (VPO, virtual project office) para
colaboracin y comunicacin".
StartWright (www.startwright.com/projectl .htm) ha
desarrollado uno de los recursos ms completos de la
Web para herramientas e informacin, tanto para
IWeb como para gestin de proyectos de software
convencional.
Es necesario observar que muchas de las herramientas de
gestin de proyecto convencional (Parte 4 de este libro)
tambin se pueden aprovechar de manera efectiva en los
proyectos IWeb.
^CONSEJO^-
f n general, eln meio
de medidas IWeb que
se debe recopilar, y su
complejidad global,
debe ser directamente
proporcional al
tamao de la WebApp
que se construir.
Los i ngeni eros Web desarrollan si st emas compl ej os y, al igual que ot ros t ecnol og a
que realizan esta t area, deben usar medi ci ones para mej orar el proceso de ingenie-
ra Web y el product o. En el captulo 15 se anal i zaron los usos est rat gi cos y tcticos
para la medicin de soft ware en un cont ext o de ingeniera del soft ware. Dichos use;
t ambi n se aplican en la ingeniera Web.
En resumen, la medicin de sof t war e ofrece una base para mej orar el pr oceso de
soft ware, lo que aument a la precisin de las est i maci ones del proyecto, incrementa
el rast reo del proyect o y mej ora la calidad del soft ware. La medicin de i ngeni era
Web, si se caract eri za de maner a adecuada, podra lograr t odos est os beneficios y
t ambi n mej orar la facilidad de uso, el des empeo de la WebApp y la satisfaccin de
usuari o.
En el cont ext o de la ingeniera Web, las medi ci ones tienen tres met as principales:
1) proporci onar un indicador de la calidad de la WebApp desde el punt o de vista tc-
nico, 2) proporci onar una base para la est i maci n del esfuerzo, y 3) proporci onar ur.
indicacin del xito de la WebApp desde el punt o de vista empresari al .
8 Las herramientas expuestas slo representan una muestra de esta categora. En casi todos los ca-
sos los nombres de las mi smas son marcas registradas de sus respectivos desarrolladores.
TM
PDF Editor
En esta seccin se r esume un conj unt o de medi ci ones de esf uer zo comn y com-
plejidad9 para las WebApps. Este conj unt o puede dest i narse al desarrol l o de una
base de dat os histrica para la est i maci n del esfuerzo. Adems, la medicin de la
compl ej i dad puede conduci r a final de cuent as a una incapacidad para valorar cuan-
t i t at i vament e uno o m s at ri but os t cni cos de las WebApps di scut i dos en el captu-
lo 16.
17.5.1 Mediciones para esfuerzo de ingeniera Web
Los i ngeni eros Web dedi can esf uer zo humano al realizar una diversidad de t areas de
t rabaj o conf or me evoluciona una WebApp. Mendes y sus col egas | MEN0l] sugieren
al gunas posibles medi das de esf uer zo para WebApps. Algunas de (o todas) ellas
podra registrarlas un equi po de ingeniera Web y luego aprovecharse en una base
de dat os histrica con fines de est i maci n (captulo 23).
Aplicacin de las tareas de autora y diseo
Medida sugerida
esfuerzo de estructuracin
esfuerzo de intervinculacin
planeacin de interfaz
construccin de interfaz
esfuerzo de prueba de vnculos
esfuerzo de prueba de los
medios audiovisuales
esfuerzo total
Descripcin
tiempo para estructurar la WebApp y / o la arquitectura derivada
tiempo para intervincular pginas y as construir la estructura de las
WebApp
tiempo en que se planea la interfaz de la WebApp
tiempo en que se implemento la interfaz de la WebApp
tiempo en que se prueban todos los vnculos en la WebApp
tiempo en que se prueban todos los medios audiovisuales en la
WebApp
esfuerzo de estructuracin + esfuerzo de intervinculacin + planeacin
de interfase + construccin de interfase + esfuerzo de prueba de vncu-
los + esfuerzo de prueba de los medios audiovisuales
Esfuerzo de autora
Medida sugerida
esfuerzo de texto
esfuerzo de vinculacin
de pgina
esfuerzo de estructuracin
de pgina
esfuerzo de pgina total
Descripcin
tiempo en que se crea o reutilza texto en una pgina
tiempo en que se crean vnculos en la pgina
tiempo en que se estructura la pgina
esfuerzo de texto + esfuerzo de vinculacin de pgina + esfuerzo de
estructuracin de pgina
9 Es importante notar que las mediciones IWeb todava estn en su infancia.
TM
PDF Editor
Autora de medios audiovisuales
Uno excelente referencia
acerco de muchas
materias r e t o a d a s
wnwwjntsriiet.com.
Medida sugerida
esfuerzo de medio audiovisual
esfuerzo de digitalizacin de
esfuerzo total de medios
audiovisuales
Descripcin
tiempo en que se crean o reutlizan archivos de medios audiovisuote i
tiempo en que se digitalizan medios audiovisuales
esfuerzo de medio audiovisual + esfuerzo de digitalizacin de
Autora de programas
Medida sugerida Descripcin
esfuerzo de programacin tiempo en que se crean HTML, Java o implementaciones de leng. ' De
relacionado
esfuerzo de reutilizacin tiempo par a reutilizar/modificar la programacin existente
17.5.2 Medicin del valor de negocios
Es i nt eresant e advertir que la gent e de negoci os ha llegado consi derabl ement e a nt e s
que la ingeniera Web al desarrollo, la recopilacin y el empl eo de la medicin p-T|
las WebApps (por ejemplo, [STE02], [NOBOl]). Al ent ender la demograf a de : d
usuari os finales y sus pat r ones de uso, una compa a u organi zaci n puede des-l
rrollar la ent r ada i nmedi at a para ms cont eni do WebApp significativo, vent as
esf uer zos de mercadot ecni a ms efectivos, y mej orar la rentabilidad de los negoc: s i
Los mecani smos requeri dos con que s e recopilan dat os val i osos para la empresa!
usual ment e los i mpl ement a el equi po de ingenien' a Web, pero eval uarl os y las aca: - l
nes resul t ant es las realizan ot r os participantes. Por ej empl o, supngase la posi' r J:-l
dad de det ermi nar el nmer o de vi st as de la pgi na para cada visitante nico. Ce a
base en la medicin recopilada, los vi si t ant es que llegan desde el mot or de bus que!
da X promedi an nueve vistas de pgi na, mi ent ras que los visitantes desde el portal
sl o dos. Estos promedi os los puede empl ear el depar t ament o de mercadot ec- J
par a ubicar un anunci o publicitario (banner) donde promueva pr esupuest os (la p u r f l
cidad en el mot or de bsqueda X proporci ona mayor exposicin, con base en
medicin recolectada, que la publicidad en el portal Y ) .
Mediciones Web
Obj et i vo: Valorar la forma en la que se utiliza
una WebApp, las categoras de usuarios y la
facilidad de uso de la WebApp.
Me c ni c a : La gran mayora de las herramientas de
medicin Web capt ura la informacin de uso una vez qi e
la WebApp est en lnea. Dichas herramientas
proporcionan una amplia vari edad de datos con los c u d |
se valora qu elementos de la WebApp se utilizan ms,
cmo se utilizan y quin los utiliza.
\
TM
PDF Editor
CAPTULO 17 FORMULACIN Y PLANEACIN PARA INGENIERA WEB 539
lientas representativas10
s, desarrollada por clicktracks.com
/.dicktracks.com), es una herramienta de anlisis
; archivos de acceso (log) que muestra el
niento del visitante al sitio We b directamente
Dogmas de ste.
e, desarrollada por Coremetrics
w.Coremetrics.com), es representativa de muchas
amientas que recopilan datos con los cuales se
valora el xito de las WebApps de comercio
electrnico.
Web Mefrics Testbed, desarrollada por NIST
(zing.ncsl.nist.gov/WebTools/), es una suite de
herramientas basadas en Web que valoran la facilidad
de uso de una WebApp.
WebTrends, desarrollada por netlQ (www.NetlQ.com),
recopila un amplio rango de datos de uso par a
W e b A p p s d e t o d o s l os t i p o s .
Una revisin compl et a de la recopilacin y el empl eo de las medi ci ones con valor
en los negoci os (que incluya el debat e act ual acerca de la privacidad personal) est
ms all del mbi t o de est e libro. El lector i nt eresado deber exami nar [INA02],
[EIS02], [PAT02] O [RIG01],
En ocasi ones, la mej or forma de apr ender cmo hacer algo cor r ect ament e es exa-
mi nar cmo no hacerl o! Durant e la dcada pasada, muchas WebApps fracasaron
porque 1) un descui do del proyect o y el cambi o en los principios de gest i n (de cual-
qui er maner a informales) result en un equi po de ingeniera Web que "rebot en las
paredes"; 2) un enf oque ad hoc para el desarrol l o de la WebApp fall y no produj o un
si st ema operabl e; 3) un enf oque desdeoso hacia la recopilacin y anlisis de requi-
sitos fracas en producir un si st ema que satisfaciera las necesi dades del usuario; 4)
un enf oque i ncompet ent e para el di seo f r acas al intentar producir un desarrol l o de
la WebApp que f uese utilizable, funcional, extensible (sustentable) y verificable; 5) un
enf oque equi vocado para las pr uebas fracas para producir un si st ema que funcio-
nase ant es de su introduccin.
Con est as si t uaci ones en ment e, tal vez valga la pena consi derar un conj unt o de
las "peores prcticas" en la ingeniera Web, adopt adas de un artculo de Tom Bragg
[BRAOO]. Si su proyect o el ect rni co muest ra cualquiera de ellas, es necesari a una
accin correctiva i nmedi at a.
Peor prcti ca # 1: Se tiene una gran idea, as que se puede comenzar a construir
la WebApp ahora. No es necesari o pr eocupar se en consi derar si la WebApp est j us-
tificada por el negocio, si los usuari os real ment e querrn usarla, si se compr enden
los requisitos del negocio. El t i empo es corto, tiene que comenzar se.
Real i dad: Tmense unas cuant as hor as o di as y el abrese un caso de negoci os
para la WebApp. Asegrese de que la idea la apoyan qui enes la financiarn y quie-
nes la usarn.
10 Las herrami ent as expuest as el aut or no l as respalda, slo represent an una muest r a de las herra-
mi ent as incluidas en est a categora. En casi t odos l os casos, los nombr es de l as her r ami ent as son
mar cas registradas de s us respectivos desarrol l adores
TM
PDF Editor
540
Peor prcti ca #2: Las cosas cambiarn constantemente, as que no tiene caso tr-
tar de comprender los requisitos de la WebApp. Nunca se escriba algo (prdida de tien
po). El apoyo debe basarse exclusivamente en la palabra oral.
Realidad: Es cierto que los requisitos de la WebApp evolucionan conforme cc
tinan las actividades de ingeniera Web. Tambin es ms rpido y simple obter
informacin de manera verbal. Sin embargo, un enfoque desdeoso respecto de
recopilacin y el anlisis de requisitos es un catalizador para ms cambi o (innec
sario) todava.
Peor prcti ca #3: Los desarrolladores cuya experiencia dominante se relaciona i
el desarrollo de software tradicional pueden desarrollar WebApps inmediatamente. No <
requiere un nuevo entrenamiento. Despus de todo, el software es software, o no?
Realidad: Las WebApps son diferentes. Se debe aplicar de manera experta
amplio abani co de mtodos, tecnologas y herramientas. El ent renami ent o y la ex
ri enda con ellos es esencial. "
Peor prcti ca #4: Burocratizarse. Insista en modelos de proceso pesados, he
rios, muchas e innecesarias reuniones "de progreso" y en lderes de proyecto
nunca han gestionado un proyecto WebApp.
Realidad: Aliente un proceso gil que resalte la competencia y la creatividad
un equipo de ingeniera Web experimentado. Luego salga de su cami no y permit
trabajar. Si se deben recopilar dat os relacionados con el proyecto (por razones le
les o el clculo de la medicin), el ingreso/recopilacin de dat os debe ser tan no i
tructivo y simple como sea posible.
Peor prcti ca #5: Pruebas? Por qu molestarse? Se le dar a unos cuant os i
rios finales y se dejar que ellos digan qu funciona y qu no.
Realidad: Con el tiempo, los usuarios finales s realizan "pruebas" exhaustiv
pero estn tan enoj ados por la falta de confiabilidad y el pobre desempeo que
dejan mucho ant es de que los problemas sean corregidos (nunca regresan).
En los captulos que siguen se considerarn los mt odos de ingeniera Web
ayudarn a evitar estos errores.
La formulacin, una actividad de comunicacin con el cliente, define el problema
resolver una WebApp. Se identifican las necesidades del negocio, la met as y objett
del proyecto, las categoras de usuario final, las funciones y caractersticas princip
y el grado de interoperabilidad con otras aplicaciones. Mientras ms informacin <
liada y tcnica se adquiera, la formulacin se convierte en anlisis de requisitos.
11 Muchos grandes proyectos IWeb requieren integracin con aplicaciones y bases de dat os cc
cionales. En tales casos, los individuos slo con experiencia convencional pueden y deben ser c
volucrados.
TM
PDF Editor
C A P T U L O 1 7 FORMULACIN Y PLANEAON PARA INGENIERA WEB 5 4 1
El equipo lWeb lo integra un grupo de mi embros tcnicos y no tcnicos organiza-
dos en una forma que les brinda considerable aut onom a y flexibilidad. Durante la
ingeniera Web se requiere gestin del proyecto, pero las t areas correspondientes
estn abreviadas y son considerablemente menos formales que las aplicadas en los
proyectos convencionales de ingeniera del software. Muchos proyectos WebApp se
subcontratan, pero existe una tendencia creciente hacia el desarrollo de WebApps en
casa. La gestin del proyecto para cada enfoque difiere t ant o en estrategia como en
tcticas.
Las mediciones de la ingeniera Web estn en desarrollo, pero tienen el potencial
para ofrecer una indicacin de la calidad de la WebApp, proporcionar una base para
la estimacin del esfuerzo y permitir vislumbrar el xito de la WebApp desde el punt o
de vista de los negocios.
[BRAOO] Bragg, T., "Worst Practices for e-Business Projects: We Have Met the Enemy and He Is
Us!", Cutter IT Journal, vol. 13, nm. 4, abril de 2000, pp. 35-39.
[CON02] Constantine, L. y L. Lockwood, "User-Centered Engineering for Web Applications", en
IEEE Software, vol. 19, nm. 2, marzo-abril de 2002, pp. 42-50.
[EIS02] Eisenberg, B "How to Interpret Web Metrics", en ClickZToday, marzo de 2002, dis-
ponible en http://www.clickz.com/sales/traffic/article.php/992351.
[FUC02a] Fuccel l a, J. Pizzolato y J. Franks, "Finding Out What Users Want from your Web
Site", IBM developerWorks, 2002, http://www-l06.ibm.com/developerworks/library-
/moderator-guide/requirements.html.
[FUC02b] Fuccella, J. y J. Pizzolato, "Giving People What They Want: How to Involve Users in
Site Design", IBM developerWorks, 2002, http://www-106.ibm.com/developerworks/
library/design-by-feedback/expectations. htm 1.
[GNA99] Gnado, C. y F. Larcher, "A User-Centered Methodology for Complex and
Customizable Web Applications Engineering", en Proc. First ICSE Workshop in Web
Engineering, ACM, Los ngeles, mayo de 1999.
[HAN991 Hansen, S Y. Deshpande y S. Murugesan, "A Skills Hierarchy for Web
Information System Development", en Proc. First ICSE Workshop on Web Engineering,
ACM, Los ngeles, mayo de 1999.
[INA02] Inan, H. yM. Kean, Measuring the Success o/Your Web Site, Longman Publishing,
2002.
[KIDOO] Kidder, T., The Soul o/a New Machine, Back Bay Books (edicin reimpresa), 2000.
[KUL001 Kulik, P. y R. Samuelsen, "e-Project Management for a New e-Reality", Project
Management Institute, diciembre de 2000, http://www.seeprojects.com/e-Projects/e-
projects.html.
[LOW98] Lowe, D. y W. Hall (eds.), Hypertextand the Web-An Engineering Approach, Wiley,
1998.
[MEN01] Mendes, E., N. Mosley y S. Counsell, "Estimating Design and Authoring Effort",
en IEEE Multimedia, enero-marzo de 2001, pp. 50-57.
[NOBOl] Nobles, R. y K. Grady, Web Site Analysis and Reporting, Premier Press, 2001.
[PAT02] Patton, S., "Web Metrics That Matter", en CIO, 15 de noviembre de 2002, disponi-
ble en http://www. computerworld. com/developmenttopics/websitemgmt/story/
0,10801,76002.00.html.
[PIC01] Pickering, C., "Building an Effective E-Project Team", en E-Project Management
Advisoiy Service, Cutter Consortium, vol. 2, nm. I, 2001, http://www.cutter.com/
consortium.
[POW981 Powell, T A., Web Site Engineering. Prentice Hall, 1998.
L
TM
PDF Editor
[RIG01] Riggins, F. y S. Mitra, "A Framework for Developing E-Business Metrics Through functic-
nality Interaction", ener o de 2001, s e puede descar gar de ht t p: / / di gi t al ent erpri se
or g/ met r i cs / met r i cs . ht ml .
[STE02] Sterne,)., Web Metrics: Proven Methods for Measuring Web Site Success, Wilev
2002.
1TIL99] Tilley, S. y S. Huang, "On t he Emer gence of t he Renai s s ance Sof t war e Engi neer
Proc. IstICSE Workshop on Web Engineering, ACM, Los ngeles, mayo de 1999.
17. 1. En qu difiere la formulacin de la recopilacin de requisitos? En qu difiere la forrr u - j
lacin del anlisis de requisitos y del model ado de anlisis?
17. 2. En la secci n 17.1.1 se encuent ran t res pregunt as f undament al es acerca de la f or ma I
cin. Existen al gunas ot ras pregunt as que se consi dere posi bl es de pl ant ear en est e punt o' i]
es as, cul es son y por qu deber an hacerse?
17. 3. En el cont ext o de la recopilacin de requisitos, qu es una "categora de usuario"?
ej empl os de t res cat egor as de usuari o para un vendedor de libros en lnea.
17. 4. Considrese el sitio de comerci o el ect rni co de HogarSeguro t rat ado en est e captu. :
Qu mecani smo de comuni caci n con el usuari o podr a usarse para obt ener requisitos del Si -
t ema y por qu?
17. 5. Con pal abras propias, exponga cmo se "analiza" la i nformaci n recopilada durant e
comuni caci n con el cliente y cul es el resul t ado de esta actividad.
17. 6. Qu beneficios se pueden derivar de requerir el desarrollo de casos de uso como para^
de la actividad de recopilacin de requisitos?
17. 7. Revsese la tabla presentada en la figura 17.1. Agrguense tres hileras ms que ulterio
distinguirn los proyectos tradicionales de los electrnicos.
17. 8. Con pal abras propias, describa el papel del editor Web.
17. 9. Revsense las caractersticas de los equi pos de desarrollo gil anal i zados en el captulo >
Se advierte que una organizacin en equipo gil es apropiada para la IWeb? El lector re
algn cambi o a la organizacin para el desarrollo de la WebApp?
17. 10. Descr banse ci nco riesgos asoci ados con la subcont rat aci n del desarrol l o de WebApps
17. 11. Descrbanse ci nco riesgos asoci ados con el desarrol l o en casa de las WebApps.
17. 12. Consi drense las medi ci ones para el esf uer zo de ingeniera Web t rat adas en la sec
17.5.1. Int nt ese desarrollar ci nco o ms medi ci ones adicionales para una o ms cat egor as
17. 13. La facilidad de navegacin a travs de un sitio Web es un indicador importante de la <
de la WebApp. Desarrllense dos o tres mediciones con las cuales pudiera indicarse la facilidad
navegaci n.
17. 14. Aprovechando una de las referenci as sugeri das en la seccin 17.5.2, coment e cmo
pueden aprovechar las medi ci ones con valor en los negoci os para apoyar la t oma de decisi
pragmt i ca en st os.
Los mt odos para la formulacin de WebApps y la recopilacin de requisitos se pueden a
de anlisis de mt odos similares para el soft ware de aplicacin convenci onal . Las ot ras
r as r ecomendadas en los captulos 7 y 8 cont i enen mucha i nformaci n til para el ingen
Web.
TM
PDF Editor
C A P T U L O 1 7 FORMULACIN Y PLANEACIN PARA INGENIERA WEB
543
Flor (Web Business Engineering, Addison-Wesley, 2000) abor da el anl i si s de negoci os y las
pr eocupaci ones r el aci onadas que per mi t en al i ngeni ero Web compr ender mej or l as necesi dades
del cliente. La facilidad de us o de la WebApp e s un concept o que subyace a mucha de la infor-
maci n definida como part e de la formul aci n y la recopi l aci n de requi si t os. Krug y Black
(Don't Make me Think: A Common Sense Approach to Web Usabiiity, Que Publishing, 2000) con-
t i ene muchas di rect ri ces y ej empl os que pueden ayudar al i ngeni ero Web a t raduci r l os requisi-
t os del usuar i o en una WebApp efect i va.
La gest i n de pr oyect o par a los proyect os lWeb part e de muchos de l os mi smos pri nci pi os y
concept os apl i cabl es en proyect os de sof t war e convenci onal . Sin embar go, agilidad e s un l ema.
Wal l ace (Extreme Programmingfor Web Projects, Addison-Wesley, 2003) descri be cmo se puede
apr ovechar el desarrol l o gil para la lWeb y cont i ene anl i si s tiles de confl i ct os de gest i n de
proyect os. Shel ford y Remillard (Real Web Project Management, Addi son-Wesl ey, 2003),
O' Connel l ( How to Run SuccessfuI Projects in Web Time, Art hec House, 2000), Freidlein (Web
Project Management, Morgan Kaufman, 2000) y Gilbert (90 Days to Launch: Internet Projects on
Time and on Budget, Wiley, 2000) t r at an una ampl i a vari edad de t emas de gest i n de proyect os
para lWeb. Whitehead (Leading a Software Development Team, Addison-Wesley, 2001) presenta
muchos l i ncami ent os tiles que pueden adapt ar los equi pos de i ngeni er a Web.
Las t cni cas para usar medi ci ones Web en la t oma de deci si ones empr esar i al es se pr esen-
t an en libros como los de St er ne [STE02], Inan [1NA02], Nobles [NOBOU y Menasce y Almeida
(Capacity Planning for Web Services: Metrics, Models and Methods, Prentice-Hall, 2001). Las "peo-
res prcticas" son consideradas por Ferry y Ferry (77 Sure-Fire Ways to Kill a Software Project,
i Uni verse. com, 2000).
En Internet est di sponi bl e una ampl i a vari edad de f uent es de i nformaci n acerca de formu-
lacin y pl aneaci n par a ingeniera Web. Una lista act ual i zada de referenci as en la World Wide
Web, r el evant e par a la formul aci n y la pl aneaci n, se encuent r a en el sitio Web de SEPA:
TM
PDF Editor
C A P I T U L O
18
MODELADO DE ANLI SI S PARA
APLI CACI ONES WE B
C ON C E P T OS
CL AVE
anlisis
de navegacin . 561
anlisis
de relacin . . . . 5 6 0
rbol de dal os . 552
ARN 560
casos de uso . . . 547
jerarqua
de usuario . . . . 546
de anlisis . . . . 5 4 5
modelo de
configuracin . . 559
modelo
de contenido . . . 551
modelo
de interaccin . . 554
funcional 557
relaciones de
contenido 552
A
pri mera vista, existe una apar ent e contradiccin cuando se consi dera ri
model ado de anlisis dent ro del cont ext o de la ingeniera Web. Despu: 5
de todo, se ha not ado (captulo 16) que las WebApps tienen una inme-
diatez y una volatilidad cont rari a al model ado detallado, ya sea en la et apa ce!
anlisis o en la del diseo. Y si se realiza algn tipo de model ado, la filosofa ga
(un model o de proceso adecuado para muchos proyect os de ingeniera Web) s ol
giere que el model ado del anl i si s s e mi ni mi ce en favor del model ado de disef. ca
limitados. Franklin [FRA02] advierte est a situacin y escribe:
Los si t i os Web, por lo gener al , s on compl ej os y e n o r me me n t e di nmi cos, Requi eren
f as es de desar r ol l cor t as con la finalidad de t ener listo el pr oduct o y ej ecut ar l o rpi-
da me nt e . Con f r ecuenci a, los desar r ol l ador es van di rect o haci a la f ase de codi fi caci n
sin compr ender qu es t n t r at ando d e const r ui r o c mo qui er en const rui rl o. La cod:
ficacin r espect o del ser vi dor con f r ecuenci a s e ha c e ad hoc, l as t abl as de bas es de
da t os s e agr egan c onf or me se neces i t an y la ar qui t ect ur a evol uci ona en una f or ma a
veces no i nt enci onal . Per o al guna i ngeni er a de s of t war e mode l a da y di sci pl i nada lo
gr ar que el pr oces o de desar r ol l o de s of t war e sea mu c ho m s s ua ve y as egur ar que
el si st ema Web s ea m s s us t ent abl e e n lo f ut ur o.
Es posible t enerl o en las dos formas? Se puede hacer "alguna ingeniera
soft ware model ada y disciplinada" y todava as t rabaj ar efect i vament e er.
mundo donde rei nan la i nmedi at ez y la volatilidad? La respuest a es un califi
do s.
Qu e s ? El anlisis de una poten-
cial aplicacin Web se enfoca en tres
preguntas importantes: 1) qu infor-
macin o contenido se presentar o
manipular?; 2) qu funciones reali-
zar el usuario final?; y 3) qu comportamientos
exhibir la WebApp conforme presente contenido
y realice funciones? Las respuestas se representan
como parte de un modelo de anlisis que abarca
una diversidad de representaciones UML.
Qui n lo hace? Los ingenieros Web, los desa-
rrolladores de contenido que no son tcnicos y
los clientes participan en la creacin del modelo
de anlisis.
Por qu e s i mport ant e? A lo largo de e r ;
libro se ha resaltado la necesidad de compre-
der el problema antes de comenzar a resolverle
El modelado de anlisis es importante no porqt e
permita que un equipo de ingeniera Web desa-
rrolle un modelo concreto de requisitos WebAp:
(las cosas cambian muy frecuentemente corr :
para que esto sea una expectativa realista), sir:
que, ms bien, permite que un ingeniero We:
defina aspectos fundamentales del problema
elementos cuyo cambio no es probable (en u-
futuro cercano). El diseo y la construccin se
facilitan cuando se comprenden el contenido, :
funcin y el comportamiento fundamentales.
5 4 4
TM
PDF Editor
C A P T U L O 1 8 MODELADO DE ANLISIS PARA APLI CACI ONES WEB
545
s s on l os pa s o s ? El modelado de anli-
ie enfoca en los aspectos fundamentales del
a: contenido, interaccin, funcin y con-
n. El anlisis de contenido identifica las
y colaboraciones de contenido. El anlisis
a interaccin describe los elementos bsicos
a interaccin del usuario, la navegacin y los
pcrtamientos del sistema que ocurren. El
.sis de las funciones define las funciones de
WebApp que realizar el usuario y la secuen-
de procesamiento que ocurre como conse-
cuencia. El anlisis de la configuracin identifica
el ambiente(s) operativo en ei cual reside la
WebApp.
Cul e s el product o obt eni do? El modelado
de anlisis lo integran un conjunto de diagramas
y textos UML que describen el contenido, la inte-
raccin, la funcin y la configuracin.
Cmo p u e d o es t ar s e gur o d e que l o he
he c ho correct ament e? los productos obteni-
dos del modelado de anlisis se deben revisar para
corregirlos, completarlos y darles consistencia.
Un equi po de ingeniera Web debe empr ender el model ado de anl i si s cuando s e
cumpl en la mayor a o t odas las condi ci ones siguientes:
La WebApp que se construir es gr ande o compl ej a.
El nmer o de clientes es grande.
El nmer o de i ngeni eros Web y ot ros col aboradores es grande.
Las met as y los objetivos (det ermi nados durant e la formulacin) para la
WebbApp afect arn la lnea de referencia del negocio.
El xito de la WebApp t endr una fuert e conexi n con el del negoci o.
Si est as condi ci ones no est n present es, lo que le rest a importancia al model ado de
anlisis, aprovechar la i nformaci n obt eni da dur ant e la formul aci n y la recopilacin
de requisitos (captulo 17) sirve como base par a la creaci n de un model o de di seo
para la WebApp. En t al es ci rcunst anci as, tal vez se obt enga un model ado de anl i -
sis limitado, per o que t ermi nar incluido en el diseo.
1 8 . 1 REQUI SI TOS PARA EL ANL I SI S DE L AS WE B AP P S
El anlisis de requisitos para las WebApps abarca tres gr andes t areas: formulacin,
recopilacin de requisitos,1 y model ado de anlisis. Durant e la formul aci n s e iden-
tifican la motivacin (metas) y los objetivos bsi cos para la WebApp, y t ambi n se de-
finen las cat egor as de usuarios. Cuando comi enza la recopilacin de requi si t os se
intensifica la comuni caci n ent re el equi po de ingeniera Web y los acci oni st as (por
ej empl o, clientes, usuari os finales). Los requisitos de cont eni do y funci onal es s e en-
listan y se desarrollan los escenar i os de interaccin (casos de uso) escri t os desde el
punt o de vista del usuari o final. La i nt enci n es est abl ecer una comprensi n bsica
de por qu se const rui r la WebApp, quin la usar y qu problema) resolver a sus
usuarios.
1 En el captulo 17 se abordan con detalle la formulacin y la recopilacin de requisitos.
TM
PDF Editor
P A R T E T R E S APLICACIN DE LA INGENIERA WEB
"Los pr i nci pi os d e i ngeni er a a c e r c a d e p l a n e a r a n t e s d e di s e a r y di s e a r a n t e s d e cons t r ui r h a n r esi st i do c a d a t r ans i -
ci n t ecnol gi ca pr e vi a ; t a mb i n s obr e vi vi r n a es t a t r a ns i c i n. "
Wa t t s Hu mp h r e y
^ ONS E J O^ .
f s bueno idea cons-
truir una jerarqua de
usuario. Ofrece una
visi n instantneo de
la poblaci n de usua-
rios y uno morca de
verificaci n que ayu-
darn o asegurar que
se han abordado las
necesidades de cada
usuario.
18.1.1 La jerarqua de usuario
Las cat egor as de usuari os finales que i nt eract uarn con la WebApp se identifican
como part e de las t ar eas de formul aci n y de recopilacin de requisitos. En la may: - ]
ra de los casos, las cat egor as de usuari o son rel at i vament e limitadas y no neces. - j
tan una represent aci n UML. Sin embargo, cuando crece el nmer o de cat egor as ae
usuario, a veces es aconsej abl e desarrollar una jerarqua de usuarios, como se mues-
tra en la figura 18.1. La figura muest ra a los usuari os del sitio de comerci o electrr -I
co de HogarSeguroInc. com t rat ada en los captulos 16 y 17.
Las cat egor as de usuari o (con frecuenci a l l amados actores) que se muest ran e i ]
la figura 18.1 indican la funcionalidad que ofrecer la WebApp; adems, seal an
necesi dad de que se desarrollen casos de uso para cada usuari o final (actor) anot a-]
do en la jerarqua. En la mi sma figura, el usuari o de HogarSeguroI nc. com en .al
parte superior de la j erarqu a represent a la clase (categora) de usuari o ms generi l l
y se refina niveles abaj o. Un vi si t ant e es un usuari o que visita el sitio per o no se re J
gistra. Tales usuari os usual ment e buscan i nformaci n general, compar an compras n
de al guna otra forma est n i nt eresados en cont eni do o funci onal i dad "gratuitos" 11J
usuari o regi st rado dedica t i empo para ofrecer i nformaci n y se le consi dera _ J
cont act o (junto con otros dat os demogrfi cos que solicitan las ent r adas de los f e - I
mularios). Las subcat egor as para los us uari os regi st rados incluyen:
J e r a r q u a d e
us uar i os p a r a
Hogar Segu-
rolnc.com.
Usuario de
HogarSegurolnc.com
O
X
Visitante Usuario
registrado
Personal
de servicio
al cliente
Cliente
nuevo
Cliente
existente
TM
PDF Editor
C A P T U L O 1 8 MODELADO DE ANLI SE PARA APUCACI ONES WEB 547
Cliente nuevo: usuario registrado que quiere personalizar y luego comprar
component es de HogarSeguro (y, por tanto, debe interactuar con la WebApp
de funcionalidad de comercio electrnico).
Cliente exi stente: un usuario que ya posee component es de HogarSeguro y
usa la WebApp para 1) comprar component es adicionales; 2) adquirir infor-
macin de soporte tcnico; o 3) contactar con el soporte al cliente.
Los miembros del personal de servi ci o al cl i ent e son usuarios especiales que
tambin pueden interactuar con el cont eni do y la funcionalidad de HogarSegu-
rolnc.com conforme asisten a los clientes que han establecido contacto con el so-
porte al cliente de HogarSeguro.
18.1.2 Desarrollo de casos de uso
Franklin [FRA01] se refiere a los casos de uso como "haces de funcionalidad". Esta
descripcin captura la esencia de esta importante tcnica de model ado de anlisis.2
Los casos de uso se desarrollan para cada categora de usuario descrita en la jerar-
qua de usuario. En el contexto de la ingeniera Web, el caso de uso en s mismo es
relativamente informal: un prrafo narrativo que describe una interaccin especfica
entre un usuario y la WebApp.3
2 Las tcnicas para desarrollar casos de uso se analizaron con detalle en capilulos anteriores de este
libro (vanse los captulos 7 y 8).
3 Aunque es posible desarrollar descripciones ms formales de casos de uso, la necesidad de agilidad
para la lWeb con frecuencia excluye este enfoque
1
_L
Func t onol i dod c o me r c i o el ect r ni co
TM
PDF Editor
La figura 18.2 representa un diagrama UML de caso de uso para la categora de
usuario cl i ente nuevo (figura 18.1). Cada valo en el diagrama representa un caso
de uso que describe una interaccin especfica entre el cl i ent e nuevo y la WebApp
Por ejemplo, la primera interaccin se describe con el caso de uso pedir acceso (log-
ir) a HogarSeguroInc.com. No se requerira ms de un solo prrafo para describir e~
ta interaccin comn.
La funcionalidad de las grandes WebApp (y los casos de uso relevantes para ella
se anot an adent ro de recuadros con lneas punt eadas en la figura 18.2. Tales recua
dros se conocen como "paquetes" en UML y representan funcionalidad especfica. Se
advierten dos paquetes: personalizaci n y comercio electr nico.
Como ejemplo, considrese el paquet e personalizaci n de casos de uso. Un nue-
vo cliente debe describir el ambi ent e domstico en el cual se instalar HogarSegur:
Para lograrlo, cl i ente nuevo inicia los casos de uso describir plano de la casa, selec-
cionar componentes HogarSeguro y guardar configuraci n. Considrense los sigui
tes casos de uso preliminares escritos desde el punt o de vista de un cl i ente nuevo
^ O N S E J O ^
Contorne crece el
tama o de una
WebApp, y el
modelado de anlisis
se vuelve ms
riguroso, los casos de
uso preliminares
presentados aqu
sern expandidos para
ajustarse de manera
ms cercana al
formato sugerido en
la secci n 8 .5 del
captulo 8 .
Caso de uso: describir plano de la casa
La WebApp f or mul ar al gunas pr egunt as gener al es acerca del ambi ent e en el cual se pla-
nea i nst al ar HogarSeguro: nmer o de habi t aci ones y su t amao, t i po de habi t aci n, nme-
ro de pisos, nmer o de puer t as ext eri ores y vent anas. La WebApp permi t i r const rui r un
pl ano de la casa apr oxi mado al conj unt ar f or mas del i neadas de l as habi t aci ones para ca-
da piso. El usuar i o ser capaz de nombr ar al pl ano de la casa y guar dar l o para una refe-
renci a fut ura (vase cas o de uso: guardar configuraci n).
Caso de uso: seleccionar componentes HogarSeguro
Ent onces la WebApp r ecomendar component es de pr oduct o (por ej empl o: panel es de
cont rol , sensor es, cmar as) y ot r as caract er st i cas (por ej empl o, funci onal i dad basada er.
PC i mpl ement ada en sof t war e) para cada habi t aci n y la ent r ada exterior. Si el usuar i o so-
licita opci ones, la WebApp las pr opor ci onar si exi st en. El usuar i o obt endr i nf or mado"
descriptiva y de preci os para cada component e de product o. La WebApp cr ear y most ra-
r una factura de mat eri al es conf or me se sel ecci onen vari os component es . El u s u a r :
t ambi n podr nombr ar la fact ura de mat er i al es y guardarl a para referenci a fut ura (vas<r
caso de uso: guardar configuraci n).
Caso de uso: guardar configuraci n
La WebApp permitir guar dar l os dat os de personal i zaci n de modo que el usuari o pue- =
r egr esar despus. Podr guar dar el pl ano de la casa y la fact ura de mat er i al es HogarSeg.
ro que eligi para l. Lograr est o requi ere que el usuari o pr opor ci one un identificador "
co para el pl ano de la casa y la fact ura de mat eri al es. Tambi n pr opor ci onar u - =
cont r asea (password) de conf i gur aci n especial que debe val i darse a nt e s de que puecs
t ener acceso a la i nf or maci n guar dada.
TM
PDF Editor
C A P T U L O 1 8 MODELADO DE ANLISIS PARA APLI CACI ONES WEB
549
GARSEGURO
Reflnar casos de uso para WebApps
El es cenari o: Oficina de Doug Sharon: Tiene sentido.
Doug Miller (gerente del grupo de inge-
software HogarSeguro), Sharon Woods, geren-
: de ingeniera Web del proveedor
sta para el sitio Web de comercio electrnico
-uro, y Sam Chen, gerente de la organiza-
soporte al cliente de HogarSegurolnc.com.
rsacin:
Sharon, me da gusto escuchar que las cosas van
bien. El modelado de anlisis est casi
( sonr e) : Estamos progresando. El nico con-
> de uso que falta por desarrollar de la je-
de usuario [figura 18.1 ] es la categora personal
-:o al cliente.
( mi r ando a Sam) : Sam, ahora t tienes esos
de uso?
Los tengo. Se los envi por correo electrnico a
. con copia para ti. Aqu est la versin impresa,
a Doug y Sharon unas hojas de papel.)
: Como lo vemos, queremos usar el sitio Web de
rSegurolnc.com como una herramienta de soporte
los clientes ordenen por telfono. Nuestros repre-
ndi ent es telefnicos completarn todos los formularios
-e-iesarios, etc., y procesarn el pedido por el cliente,
j : Por qu no slo remitir al cliente al sitio Web?
i (sonr e): Los tcnicos piensan que todos se sien-
i cmodos con la Web. jNo es as! Hay mucha gente a
fc que todava le gusto el telfono, as que les tenemos que
: c- esa opcin. Pero no queremos construir un sistema de
ôcesamiento de solicitudes por separado cuando la ma-
jara de las piezas ya estn en el lugar de la Web.
(Todas las partes leen los casos de uso [a continuacin se
presenta un ejemplo]):
Cas o d e us o: describir plano de la casa [note que esto
difiere del caso de uso del mismo nombre para la cate:
g o r a cliente n u e v o ]
Sa m: Pedir al cliente [va telef nica 1 que describo cada
habitaci n de la casa e ingresar las dimensiones de la
habitaci n y otras caractersticas en un gran formulario
dise ado especficamente para el personal de soporte al
cliente. Una vez que se hayan ingresada los datos de la
casa podr guardar los datos con el nombre o nmero
de telfono del cliente.
Sharon: Sam, has sido un tanto lacnico en tus descrip-
ciones preliminares de caso de uso. Creo que tendremos
que detallarlas un poco.
Do ug ( as i nt i endo c on l a c abe z a) : Estoy de acuer-
do.
S a m ( mal humor ado) : Por qu?
Sharon: Bueno... mencionas "un gran formulario dise-
ado especficamente para el personal de soporte al
cliente". Vamos a necesitar ms detalles.
Sam: Lo que quise decir fue que no necesitamos llevar a
nuestros representantes por todo el proceso como ustedes
lo hacen para un cliente en lnea. Un gran formulario re-
solvera el problema.
Sharon: Bosquejemos cmo se vera el formulario.
Las partes trabajan para proporcionar suficiente detalle
que permita al equipo de Sharon emplear en forma efec-
tiva el caso de uso.
Aunque es posible ofrecer consi derabl ement e ms detalle para cada uno de los
casos de uso, la descripcin textual informal ofrece una visin til. Descripciones si-
mi l ares se desarrollaran para cada val o en la figura 18.2.
18.1.3 Afinacin del modelo de caso de uso
A la par que se crean los di agr amas de caso de uso para cada cat egor a de usuario,
se desarrolla una vista superior de los requi si t os de la WebApp observabl es de ma-
TM
PDF Editor
550
?
Cmo s e
v a l o r a n l os
p a q u e t e s d e c a s o s
d e u s o a g r u p a d o s
por l a f unc i n
u s u a r i o ?
era externa. Los casos de uso se organizan en paquet es funcionales, y cada paque
te se valora [CONOO] para garantizar que es:
Comprensible: todos los clientes entienden el propsito del paquete.
Cohesivo: el paquet e aborda funciones relacionadas cercanament e una con
otra.
Libremente acoplados: las funciones o clases dentro del paquet e colaboran
una con otra, pero la colaboracin exterior del paquet e se mant i ene en un m-
nimo.
Jerrquicamente superficial: las jerarquas funcionales profundas son difciles
de navegar y ent ender para los usuarios; en consecuencia, el nmero de nive-
les dentro de una jerarqua de casos de uso debe reducirse siempre que sea
posible.
Puesto que el anlisis de requisitos y el model ado son actividades iterativas, es pr : -
bable que se sumen nuevos casos de uso a los paquet es que se han definido, que :&
casos de uso existentes sean refinados y que casos de uso especficos puedan reufcw
carse en paquet es diferentes.
Qu t i p os
' d e a c t i vi da -
d e s de a n l i s i s
oc ur r e n d u r a n t e el
mo d e l a d o d e una
We b Ap p ?
El model ado de anlisis para una WebApp se basa en la informacin que conti
los casos de uso desarrollados para la aplicacin. Las descripciones de los casos
uso se analizan gramaticalmente para identificar potenciales clases de anlisis y i
operaciones y atributos asoci ados con cada clase. Se identifica el contenido que ;
sentar la WebApp y se extraen las funciones que se desarrollarn a partir de las i
cripciones de caso de uso. Finalmente, los requisitos especficos de la i mpl ement a: -^
se deben desarrollar de modo que el ambiente y la infraestructura que apoyan la V. d
Apps puedan construirse.
Cuatro actividades de anlisis, cada una con su aporte a la creacin de un moa
lo de anlisis completo, son:
Anlisis de contenido: identifica todo el espectro del contenido que ofrece-a I
WebApp. El contenido incluye texto, grficas e imgenes, as como datos a ]
video y audio.
Anlisis de interaccin: describe cmo interacta el usuario con la WebApo
Anlisis de funciones: define las operaciones que se aplicarn al conteni:
la WebApp y describe ot ras funciones de procesamiento, independientes j a
contenido pero necesari as para el usuario final.
Anlisis de configuracin: describe el ambi ent e y la infraestructura en la - J
reside la WebApp.
TM
PDF Editor
C A P T U L O 1 8 MODELADO DE ANLISIS PARA APLICACIONES WEB
551
La informacin recopilada durant e las t areas de est os cuat ro anlisis se debe re-
visar, modificar cuando se requiera y luego organi zarse en un model o que pueda pa-
sarse a los di seadores de WebApp.
El model o en si mi smo cont i ene el ement os est ruct ural es y di nmi cos. Los elemen-
tos estructurales identifican las clases de anlisis y los obj et os de cont eni do que se
requieren para crear una WebApp que satisfaga las necesi dades de los clientes. Los
elementos dinmicos del model o de anlisis describen cmo interactan los el emen-
tos estructurales, ent re ellos y con los usuari os finales.
"[Los WebApps] exi t osas per mi t en que los di ent es s at i s f agan mej or sus necesi dades, m s r pi do o m s ba r a t o por s
mi smos, que el t r a ba j a r a t r avs del e mpl e a do [ de una compa a] par a los usuar i os f i nal es. "
Ma r k McDonal d
1 8 . 3 EL MODEL O DE CONT E NI DO
El modelo de contenido cont i ene el ement os est ruct ural es que proporcionan una im-
port ant e visin de los requisitos de cont eni do para una WebApp. Dichos el ement os
est ruct ural es incluyen obj et os de cont eni do (por ejemplo: texto, i mgenes grficas,
fotograas, i mgenes de video, audio) que se present an como part e de la WebApp.
Adems, el model o de cont eni do incluye t odas las cl ases de anlisis: ent i dades visi-
bles para el usuario que se crean o manipulan conforme ste interacta con la WebApp.
Una clase de anlisis incluye atributos que la describen, operaci ones que afect an el
comport ami ent o requerido de la clase y col aboraci ones que permiten la comuni ca-
cin de la clase con ot ras clases.
Al igual que ot ros el ement os del model o de anlisis, el model o de cont eni do se
deriva a partir de un examen cui dadoso de los casos de uso desarrol l ados para la
WebApp. Los casos de uso se analizan gramat i cal ment e para extraer obj et os de con-
tenido y cl ases de anlisis.
18.3.1 Definicin de objetos de contenido
Las aplicaciones Web present an informacin preexistente llamada contenido a
un usuario final. El tipo y forma del cont eni do abarca un ampl i o espect ro de elabo-
racin y complejidad. El cont eni do puede desarrollarse ant es de la implementacin
de la WebApp, mi ent ras st a se construye o mucho despus de que la WebApp se en-
cuent ra en operacin. En cada caso, se incorpora por medi o de referenci as de nave-
gacin en la estructura global de la WebApp. Un objeto de contenido puede ser una
descripcin textual de un producto, un artculo que describa un event o noticioso,
una fotografa de accin t omada en un cotejo deportivo, una representacin ani ma
da de un logotipo corporativo, un breve video de un discurso o un recubrimiento de
audi o para una coleccin de diapositivas Powerpoint.
Los objetos de cont eni do se extraen de los casos de uso al exami nar la descrip-
cin del escenari o para referenci as directas e indirectas al contenido. Por ej empl o,
en el caso de uso seleccionar componentes HogarSeguro, se encuent ra la oracin:
%
CLAVE
objeto de contenido
cualquier artculo de
formaci n cohesivo
a se presentar o un
. sj ori o final. Usual-
- e nt e , los objetos de
a t e n i d o s e extraen
los casos de uso.
TM
PDF Editor
Ser capaz de obt ener informacin descriptiva y de precios para cada componen-
te de producto.
Aunque no existe referencia directa al contenido, est implcita. El ingeniero Wer
podra reunirse con el autor del caso de uso y comprender en forma ms detallada
lo que significa "informacin descriptiva y de precios". En este caso, el autor del caso
de uso puede indicar que "informacin descriptiva" incluye 1) una descripcin gene-
ral del component e en un prrafo; 2) una fotografa del component e; 3) una descrip-
cin tcnica del component e en varios prrafos; 4) un diagrama esquemtico de-
component e que muestre cmo encaj a en un sistema HogarSeguro tpico; y 5) un
breve video que muest re cmo instalar el component e en una configuracin doms
tica tpica.
Es importante advertir que cada uno de est os objetos de contenido debe desarro-
llarse (con frecuencia a travs de desabol l adores de contenido que no son ingeni;
ros Web) o adquirirse para integrarlo en la arquitectura de la WebApp (analizada er
el captulo 19).
" l o We b: t a n t o t ot i f eni do, t a n p o c o t i e mp o . "
Anni mo
%
CLAVE
Un rbol de dot os
r epr esent o uno
jerarqua de obj et os d e
cont eni do.
18.3.2 Relaciones y jerarqua de contenido
En muchas instancias, una simple lista de objetos de contenido, pareadas con ur a
breve descripcin de cada objeto, es suficiente para definir los requisitos para el con-j
tenido que deben disearse e implementarse. Sin embargo, en al gunos casos, el mo-
delo de contenido puede contener di agramas de relacin de entidades (captulo 8 v
rboles de datos [SR10I] que bosquejan las relaciones ent re los objetos de contenic:
o la jerarqua de st e que mant i ene una WebApp.
Considrese el rbol de dat os creado para el component e HogarSeguro que
muestra en la figura 18.3. El rbol representa una jerarqua de informacin con que
Arbol de
datos para un
componente
HogarSeguro.
p a r t e N me r o
p a r t e No mb r e
c o mp o n e n t e p a r t e Ti p o c o mp o n e n t e p a r t e Ti p o
d e s c r i p c i n
De s c r i p c i n De Ma r k e t i n g
Fot og r a f a
De s c r i p c i n T c n i c a
Es q u e ma
Vi d e o
pr e c i o
Pr e c i oMa y or i s t a
Pr e c i oMi nor i s t a
TM
PDF Editor
C A P T U L O 1 8 MODELADO DE ANLISIS PARA APLICACIONES WEB 553
se descri be el component e (ms adel ant e se ver que, en realidad, un component e
HogarSeguro es una clase de anlisis para est a aplicacin). Los artculos de dat os
si mpl es o compuest os (uno o m s val ores de datos) se represent an como rect ngu-
los sin sombr eado. Los obj et os de cont eni do se represent an como rect ngul os som-
breados. En la figura, descri pci n se defi ne por medi o de ci nco obj et os de cont eni -
do (los rect ngul os sombreados). En al gunos casos, uno o ms de di chos obj et os se
retinar ms t odav a conf or me s e expanda el rbol de dat os.
18.3.3 Clases4 de anlisis par a WebApps
Como ya se ha seal ado, las cl ases de anlisis se derivan al exami nar cada caso de
uso. Por ej empl o, consi drese el caso de uso preliminar: seleccionar componentes Ho-
garSeguro que se present en la seccin 18.1.2.
Caso de uso: seleccionar componentes HogarSeguro
Ent onces la WebApp r ecomendar c ompone nt e s de pr oduct o (por ej empl o: panel es de
cont rol , sensor es, cmar as) y ot r as car act er st i cas (por ej empl o, f unci onal i dad bas ada en
PC i mpl ement ada en sof t war e) par a cada habi t aci n y la ent r ada ext eri or. Si el usuar i o s o-
licita opci ones, la WebApp las pr opor ci onar si exi st en. El usuar i o obt endr i nf or maci n
descri pt i va y de pr eci os par a cada c ompone nt e de pr oduct o. La WebApp cr ear y most r a-
r una fact ura de mat er i al es conf or me se sel ecci onen vari os component es . El usuar i o
t ambi n podr nombr ar la fact ura de mat er i al es y guardarl a par a r ef er enci a fut ura (vase
caso de uso: guardar configuraci n).
Un rpi do anlisis gramatical del caso de uso identifica dos cl ases candi dat as (subra-
yadas): Compone nt e De Pr oduc t o y Fact uraDeMat eri al es En la figura 18.4 s e
muest ra una pri mera descripcin de cada clase.
La clase Compone nt e De Pr oduc t o abarca t odos los component es de HogarSe-
guro que se pueden compr ar para personal i zar el product o dest i nado a una instala-
cin particular. Es una represent aci n general i zada de Sensor, Cmara, Panel de-
Control y Caract er st i cadeSof t ware Cada obj et o de Compone nt e De Pr oduc t o
cont i ene i nformaci n que corresponde al rbol de dat os que se muest ra en la figura
18.3 para la clase. Algunos de est os at ri but os de clase son artculos de dat os senci-
llos o compuest os, y ot ros son obj et os de cont eni do (vase la figura 18.3). Tambi n
se muest r an las oper aci ones rel evant es para la clase.
La cl ase Fact uraDeMat eri al es abarca una lista de component es que cl i ent e
nue vo ha sel ecci onado. Fact uraDeMat eri al es es en realidad un agr egado de Ar-
t cul oFdM ( muchas i nst anci as de ArtculoFdM compr enden una Fact uraDeMat e-
riales): una cl ase que const ruye una lista compuest a de cada component e que se
compr ar y de at ri but os especficos acerca del component e, como se muest ra en la
figura 18.4.
4 En el captulo 8 se presentaron en forma detallada los mecanismos para identificar y representar las
clases de anlisis. Si todava no se ha hecho, el capitulo 8 debe revisarse en este momento.
TM
PDF Editor
5 5 4 P A R T E T R E S APLICACIN DE LA INGENIERA WEB
C l a s e s d e
a n l i s i s p a r a
e l c a s o d e
u s o : s e l e c c i o -
n a r c o m -
p o n e n t e s
HogcaSeguro.
C o m p o n e n t e d e P r o d u c t o
par t eNr ner o
por l eNombr e
parfeTi po
descri pci n
pr eci o
crearNuevoArt cul oj )
abt ener Descr i pci nQ
obt en erEspecTcni ca ()
S e n s o r C m a r a P o n e l Do Co til-rol
F a c t u r a De Ma t e r i a l e s
i dent i fi cador
precioTotal
agr egar Enr ada( }
bor r ar Ent r ada( )
ed t arEnfrada( )
nombre( )
guar dar j )
calcuIarPrecio{)
Ar t c u l o F d M
cant i dad
preci o
a g r e ga r a Lista 0
borrardeLista(j
Cada caso de uso identificado para HogarSeguroInc.com se analiza gramatical!
mente para objetos de anlisis. Respecto a cada caso se uso se desarrollan mod
de clase similares al descrito en esta seccin.

^COKSEJO^.
Es posible utilizar las
tcnicas asociadas con
el anlisis de toreas
(capitulo 12 ) poto
ayudarse a definir los
modos de interacci n
del usuario.
La gran mayora de las WebApps permite una "conversacin" entre un usuario fina
y la funcionalidad, el contenido y el comport ami ent o de una aplicacin. Este motp?!
lo de interacci n lo componen cuatro elementos: 1) casos de uso, 2) diagramas de s-r-l
cuencia, 3) di agramas de estado,5 y 4) un prototipo de interfaz de usuario. Ade~
de est as representaciones, la interaccin tambin se representa dent ro del cont
del model o de navegacin (seccin 18.7).
Casos de uso. Los casos de uso son el elemento domi nant e del modelo de inieJ
raccin para las WebApps. No es raro describir 100 o ms casos de uso cuando
analizan, disean y construyen grandes y complejas WebApps. Sin embargo, un pcc-j
centaje relativamente bajo de est os casos de uso describe las principales interaca :-f
nes entre las categoras de usuario final (actores) y el sistema. Otros casos de uso r
finan las interacciones y proporcionan el detalle de anlisis necesario para guiar
diseo y la construccin.
Di agramas de secuenci a. Los di agramas de secuencia UML ofrecen una re
sentacin abreviada de la forma en la cual las acciones del usuario (los element:
dinmicos de un sistema que definen los casos de uso) colaboran con las clases
5 C a d a u n o d e s t o s e s u n a i m p o r t a n t e n o t a c i n U ML q u e s e d e s c r i b i e n el c a p i t u l o 8.
TM
PDF Editor
C A P I T U L O 1 8 MODELADO DE ANLISIS PARA APLICACIONES WEB
555
i d e
i el c a s o
at es
[CONSEJO
*
anlisis (los el ement os estructurales de un sistema que definen los diagramas de cla-
se). Dado que las clases de anlisis se extraen de las descripciones de caso de uso,
existe la necesidad de garantizar que hay una forma de realizar un seguimiento en-
tre las clases definidas y los casos de uso que describen la interaccin del sistema.
En captulos anteriores se apreci que los diagramas de secuencia proporcionan
un vnculo entre las acciones descritas en el caso de uso y las clases de anlisis (en-
tidades estructurales). Conallen |CONOO] seala esto cuando escribe: "La mezcla de
el ement os dinmicos y estructurales del modelo [de anlisis] es el vnculo clave en
la capacidad de seguimiento del modelo y se debe considerar muy seriamente."
En la figura 18.5 se muestra un diagrama de secuencia para el caso de uso selec-
cionar componentes HogarSeguro. El eje vertical del diagrama muestra las acciones
que se definen dent ro del caso de uso. El eje horizontal identifica las clases de an-
lisis que se usan conforme procede el caso de uso. Por ejemplo, un cliente nuevo pri-
mero debe describir cada habitacin de la casa (el asterisco a continuacin de "des-
cribir habitacin" indica que la accin es iterativa). Para lograr esto, el cliente nuevo
responde preguntas acerca del t amao de la habitacin, puertas y ventanas, etcte-
ra. Una vez definida una habitacin, se coloca en un plano de la casa. Entonces el
cliente nuevo describe la siguiente habitacin o procede a la siguiente accin (guar-
dar la configuracin del plano de la planta). El movimiento a travs y hacia abaj o del
diagrama de secuencia enlaza cada clase de anlisis con las acciones del caso de
uso. Si en el diagrama se pierde una accin de caso de uso, el ingeniero Web debe
reevaluar la descripcin de las clases de anlisis para determinar si una o ms cla-
ses se han perdido. Es posible crear diagramas de secuencia para cada caso de uso
una vez que se definen las clases de anlisis para el caso de uso.
Di agramas de est ado. El diagrama de est ado UML (captulo 8) ofrece otra repre-
sentacin del comport ami ent o dinmico de la WebApp conforme sucede una inter-
TM
PDF Editor
Di a g r a ma d e e s t a d o p a r c i a l p a r a i nt er acci n c on cl i ent e nue vo.
O
A
C lenlo
nuevo
Sel ecci onar
*occes o"
Val i dar mu or i o
Es t a do s i s t ema - " ent r ada lisio"
Muest r a mj j - " i ngl e s a r i d d e usuar i o*
Mues t r a msj - "i ngr esar cont r as ea"
e n f r o d o / o c c e s o sol i ci t ado
hoc e ; c or r e r val i daci n d o us uar i o
s a l i da / e s t a b l e c e r i nt errupt or a c c e s o
us uar i o
us uar i o
va t . doda
c ont r a s e o vol i doda
Per sonal i zaci n compl et a
Sel ecci onar a c c i n us uar i o
Es t ado si st ema "v ncul o l i st a"
Mues t r o: " e l e c don e s de n a v e g a r i n "
e n t r odo/ u s u a r i o va l i dodo
ha c e : vi ncul ar c o mo s e sol i ci t a
s a l i d a / a c c i n us uar i o s e l e c c i ona da
Sel ecci onar ot r os ( unci ones
Sel ecci onar f unci onal i dad comer ci o el ect r ni co ( compr a!
C
Sel ecci onar f unci onal i dad per s onal i zaci n
Per soooEzor
Si gui ent e sel ecci n
Es t ado si st emo - " ent r ado lista"
Mues t r a: i nst rucci ones b s i c a s
Sel ecci onar c ont e ni do
I descr i pt i vo
e n t r a d a / u s u a r i o va l i da do
ha c e : pr oc e s o sel ecci n us uar i o
s a l i da / p e r s on a l i z a c i n t e r mi na da
Defi n , ha b
Sel ecci onar cont eni do
^ d e s c r i p t i v o
Est ado si st ema " e n t r a d a l i st a'
Mues t r a: v e n t a n a def. habi t aci n
e n t r a d a / d e f . habi t aci n s el ecci onado
ha c e : cor r o consul t a habi t aci n
ha c o: a l ma c e n a var i abl es habi t aci n
s a l i da / ha b i t a c i n c omp l e t a da

Sel ecci onar g u a r d a r p l a n o d e la pl ant a
Gu a r d a r pl ano d e l o c o s o
Es t ado si st ema - " ent r ado lista"
Mues t r a: i ndi cador a l ma c e na mi e nt o
e n t r a d a / g u a r d a r hobi l aci n
s e l e c c i ona da en pl a no d e la pl ant a
hoc e , a l ma c e n a p l a n o d o la pl ant a
s a l i d o / g u a r d a d o c omp l e t a do
Sel ecci onar i ngr esar hobi t oci n en pl ono d e la pl ont o
Inserci n habi t aci n c omp l e t a da
Const rui r pl a no d e b c o s a
^vdescr&m
Est ado si st ema - " e nt r a da lista*
Muest r a: vent ana p l a n o d e la pl ant a
e n t r a d a / p l a n o de l o c a s a s e l e c c i ona do
ha c e : i nsert ar habi t aci n en l ugar
ha c o: gua r da r var i abl es p l a n o d e la pl ont o
s al i do/ i ns er ci n habi t aci n c omp l e t a da
accin. Al igual que la mayor a de las represent aci ones de model ado utilizadas i
ingeniera Web (o en la ingeniera del soft ware), el di agrama de est ado puede
sent arse en di ferent es gr ados de abst racci n. La figura 18.6 muest ra la vista su~
(mayor grado de abstraccin) de un di agrama de est ado parcial para la i nt e r
ent re un cliente nuevo y la WebApp de HogarSegurolnc. com.
En el di agrama de est ado que se muest ra se identifican sei s est ados obse~
ext ernament e: validar usuario, seleccionar acci n del usuario, personalizar, dejir,ir .-
bitaci n, construir plano de la casa y guardar plano de la casa. El di agrama de
indica las acci ones que se requi eren para mover al cliente nuevo de un est ado a
la i nformaci n que se muest ra conf or me se ingresa un est ado, el procesami ent o >
ocurre dent ro de un est ado y la condicin de salida que provoca una transicin
un est ado a otro.
Puest o que los casos de uso, los di agr amas de secuenci a y los di agramas de
t ado muest r an i nformaci n rel aci onada, es razonabl e pregunt ar por qu son
s anos los tres. En al gunos casos no lo son. Los casos de uso tal vez sean sufic
en al gunas situaciones. Sin embargo, los casos de uso proporci onan una visir
bien uni di mensi onal de la interaccin. Los di agramas de secuenci a pr esent ar
segunda di mensi n que en esenci a es ms de procedi mi ent o (dinmica). Los
ma s de est ado proporci onan una t ercera di mensi n que se refiere ms al co
mi ent o y cont i ene i nformaci n acerca de los pat r ones de navegaci n pot e
TM
PDF Editor
C A P I T U L O 1 8 MODELADO DE ANLISIS PARA APLI CACI ONES WEB 557
que no proporcionan los casos de uso o el diagrama de secuencia. Cuando se usan
las tres dimensiones, las omisiones o inconsistencias que pueden escapar en una di-
mensin se vuelven obvias cuando se examina una segunda (o tercera) dimensin.
Por esta razn, los grandes WebApps complejas pueden beneficiarse de un modelo
de interaccin que abarque las tres representaciones.
Prototi po de la interfaz de usuari o. La plantilla de la interfaz de usuario, el con-
tenido que presenta, los mecani smos de interaccin que implementa y la esttica
global de las conexiones usuario-WebApp, tienen mucho q u e ver con la satisfaccin
del usuario y la aceptacin global de la WebApp. Aunque se puede argument ar que
la creacin de un prototipo de interfaz de usuario es una actividad de diseo, es una
buena idea realizarla durant e la creacin del modelo de anlisis. Mientras ms rpi-
do se pueda revisar la representacin fsica de una interfaz de usuario, mayor ser
la probabilidad de que los usuarios finales obtengan lo que quieren. En el captulo 12
se aborda el anlisis de la interfaz de usuario y su diseo.
Puesto que las herrami ent as de desarrollo de la WebApp son abundantes, relati-
vament e baratas y funcionalmente poderosas, es mejor crear el prototipo de la inter-
faz mediante tales herramientas. El prototipo debe implementar los principales vncu-
los de navegacin y representar la plantilla de pantalla global en gran parte como se-
r construida.
El modelo funcional aborda dos el ement os de procesami ent o de la WebApp y cada
uno representa un grado diferente de la abstraccin de procedimiento: 1) funciona-
lidad observable respecto al usuario y que entrega al usuario final la WebApp, y 2)
las operaciones dentro de las clases de anlisis que implementan comport ami ent os
asociados con la clase.
La funcionalidad observable para el usuario comprende cualesquiera funciones
de procesami ent o que ste inicia directamente. Por ejemplo, un sitio Web financiero
puede implementar una variedad de funciones financieras (como una calculadora
para fondo de matricula universitaria o una calculadora para fondo de retiro). Dichas
funciones en realidad pueden implementarse mediante operaciones dent ro de las
clases de anlisis, pero, desde el punt o de vista del usuario final, la funcin (ms pre-
cisamente, los dat os que proporciona la funcin) es el resultado visible.
En un grado inferior de abstraccin procedimental, el modelo de anlisis descri-
be el procesamiento que realizarn las operaciones de la clase de anlisis. Dichas
operaciones manipulan atributos de la clase y estn involucradas como clases que
colaboran entre s para lograr algn comportamiento requerido.
Sin importar el grado de abstraccin procedimental, con el diagrama de actividad
UML se representan detalles de procesamiento. La figura 18.7 muestra un diagrama
de actividad para la operacin calcularPreciot < que forma parte de la clase de anli-
TM
PDF Editor
558
Di a g r a ma d e
a c t i vi da d p a -
r a l a oper a-
ci n calculai-
Precio().
Ni n g n c o mp o n e n t e p e r ma n e c e en l i st aFdM
(
co&f ol neo <* |
pr eci o c a n t i d a d J
f f Suma r c oi l oUnoa \ _
w V a cost oTot al 1
> / c o a t o To t o l . \
' \ cosi oTot ol - d e s c u e n t o !
( impuesto Jo lot - \
ycosloTotol V tosaimpuGsloJ
^ O N S E J O ^
Como alternativa,
tambin es posible
escribir uno simple
narraci n del procesa-
miento o representa-
ci n en lengua/e de
programaci n de
dise o (capitulo 11).
Sin embargo, muchas
personas prefieren
una representaci n
grfica.
pr eci oTat al
I coi t oTo' o
I 4 c o s t o Emb a r q u e

sis FacturaDeMateri al es6 Como se anot en el captulo 8, el diagrama de activi
es similar al diagrama de flujo, el cual ilustra el flujo de procesami ent o y las deci-
nes lgicas del flujo. Debe not arse que, dent ro del flujo procedimental, se i n v
dos operaciones adicionales: ca!cCostoEmbarque(), que calcula el costo de embar
dependiendo del mtodo que haya elegido el cliente, y determiriarDescuento(), que
termina cualquier descuent o especial para los component es HogarSeguro elegi
para comprar. Los detalles de construccin que indican cmo se solicitan estas
raciones y los detalles de la interfaz para cada operacin no se consideran sino
ta que comienza el diseo WebApp.
6 Una revisin de la clase de anlisis FacturaDeMateriales puede determinar que, con la nter
de cohesionar, la operacin calcularPreo() puede colocarse mejor en una clase Facturas. Esta
gerencia tiene mrito. Sin embargo, permanece dentro de la clase de anlisis FacturaDeMat
l es para los propsitos de este ejemplo.
TM
PDF Editor
C A P T U L O 1 8 MODELADO DE ANLISIS PARA APLICACIONES WEB
559
*
fimpor-
rtodos
r r t o l i l i -
r .rizadas,
una
ssome-
3 por a
r:sususuo-
i no a lo
i de un na-
rxnkular.
Las WebApps se deben disear e implementar de forma que se acomoden a una di-
versidad de ambientes, tanto en lado del servidor como en el del cliente.7 La WebApp
puede residir en un servidor que proporcione acceso va Internet, una Intranet o una
Extranet. Se deben especificar el hardware del servidor y el ambi ent e del sistema
operativo. Adems, se deben considerar aspect os de interoperabilidad en el lado del
servidor. Si la WebApp debe t ener acceso a una gran base de datos o interoperar con
las aplicaciones corporativas existentes en el lado del servidor, se deben especificar las
interfaces apropiadas, los protocolos de comunicacin y la informacin compl emen-
taria necesaria.
El soft ware del lado del cliente proporciona la infraestructura que permite el ac-
ceso a la WebApp desde la ubicacin del usuario. En general, el soft ware de nave-
gacin se utiliza para entregar el contenido y la funcionalidad de la WebApp que se
descargan del servidor. Aunque existen est ndares, cada navegador tiene sus pro-
pias peculiaridades. Por esta razn, la WebApp debe somet erse a una amplia prue-
ba en cada configuracin de navegador que se especifique como parte del modelo de
configuraci n.
En algunos casos, el modelo de configuracin no es ms que una lista de atributos
tanto del lado del servidor como del cliente. Sin embargo, para WebApps ms elabo-
radas, varias complejidades de configuracin (por ejemplo: distribucin de carga en-
tre mltiples servidores, arquitecturas de cach, bases de datos remotas, mltiples ser-
vidores que sirven a varios objetos en la misma pgina Web) pueden impactar el an-
lisis y el diseo. Es factible aprovechar el diagrama de despliegue UML (captulo 10) en
situaciones en las cuales se deban considerar arquitecturas de configuracin complejas.
Los el ement os del modelo de anlisis descritos en las secciones previas identifican
los elementos de contenido y funcionalidad, junto con la forma en que se utilizan para
i mpl ement ar la interaccin con el usuario. Conforme el anlisis evoluciona en dise-
o, dichos el ement os se vuelven parte de la arquitectura de la WebApp. En el con-
texto de las aplicaciones Web, cada el ement o arquitectnico tiene el potencial de
vincularse con todos los otros el ement os arquitectnicos. Pero, conforme aument a
el nmero de vnculos, la complejidad de navegacin a travs de la WebApp tambin
crece. Entonces, la pregunta es cmo establecer los vnculos apropi ados entre los
objetos de contenido y las funci ones que proporcionan las capaci dades que requie-
re el usuario.
El lado del servidor hospeda la WebApp y todas las caractersticas de sistema relacionadas que per-
miten a mltiples usuarios tener acceso a la WebApp va una red. El lado del cliente proporciona un
ambiente de software (por ejemplo, navegadores) que permite a los usuarios finales interactuar con
la WebApp en el escritorio del usuario.
TM
PDF Editor
"[ La n a v e g a c i n ] no sl o e s l a acci n d e s al t ar d e p g i n a a p g i n a , si no la i d e a d e mo v e r s e a t r a v s d e un es paci o d e
i n f o r ma c i n . "
A. Rei na y J . Tor r es
El anlisis relaci n-navegaci n (ARN) proporciona una serie de pasos de anlis. 1
que luchan por identificar relaciones entre los el ement os descubiertos como parte ce I
la creacin del modelo de anlisis. Yoo y Bieber [YOOOO] describen un ARN del m< -
do siguiente:
El ARN proporci ona a los anal i st as de si st emas una tcnica si st emt i ca para det ermi nar la
est ruct ura de relacin de una aplicacin, lo que les ayuda a descubri r las rel aci ones po-
t enci al ment e tiles en los domi ni os de la aplicacin y que se pueden i mpl ement ar como
vnculos m s adel ant e. El ARN t ambi n ayuda a det ermi nar las est ruct uras de navegacin
apropi adas sobre est os vnculos. El ARN foment a la comprensi n de los desarrol l adores
de si st emas en t omo a los domi ni os de la aplicacin al ampl i ar y profundi zar su model e
concept ual del dominio. Ent onces los desarrol l adores pueden mej orar su i mpl ement aci n
al incluir vnculos, met ai nformaci n y navegaci n adicionales.
El enfoque ARN se organiza en cinco pasos:
Anlisis de los participantes: identifica las diversas categoras de usuario (co i
mo se describe en la seccin 18.1) y establece una apropiada jerarqua de par-I
ticipantes.
Anlisis de elementos: identifica los objetos de contenido y los elementos f ur - l
dnal es de inters para los usuarios finales (como se describe en las seccio- l
nes 18.3 y 18.5).
Anlisis de relaciones: describe las relaciones ent re los el ement os WebApp.
Anlisis de navegacin: examina cmo los usuarios pueden acceder a ele-
ment os individuales o grupos de elementos.
Anlisis de evaluacin: considera t emas pragmticos (por ejemplo: cost o/ be I
neficio) asociados con la implementacin de las relaciones definidas con an-
terioridad.
Los primeros dos pasos en el enfoque ARN se trataron en prrafos anteriores de e - l
te captulo. En las siguientes secciones se consideran mt odos para establecer asi
relaciones entre los objetos de contenido y las funciones.
18.7.1 Anlisis de relaciones: pregunt as cl ave
Yoo y Bieber [YOOOO] sugieren una lista de pregunt as que un ingeniero Web o an=-l
lista de sistemas deben responder acerca de cada el ement o (objeto de contenido
8 Se debe sealar que el ARN es aplicable a cualquier sistema de informacin y originalmente se o d
sarroll para los sistemas hipermedia en general. Sin embargo, es posible adaptarlo muy bien ; | l
ingeniera Web.
TM
PDF Editor
C A P I T U L O 1 8 MODELADO DE ANLISIS PARA APLI CACI ONES WEB
561
Cmo s e
c l o r a n l os
del
fa a n f i s i s
i r ender
funcin) identificado dent ro del model o de anlisis. La siguiente lista, adaptada pa-
ra WebApps, es representativa [YOOOO]:
El elemento es mi embro de una categora de elementos ms amplia?
. Qu atributos o parmet ros se han identificado para el elemento?
Ya existe informacin descriptiva acerca del elemento? Si es as, dnde est?
El el ement o aparece en diferentes ubicaciones dentro de la WebApp? Si es
as, dnde?
El elemento lo componen otros pequeos elementos? Si es as, cules son?
. El el ement o es miembro de una coleccin de el ement os mayor? Si es as,
cul es y cul es su estructura?
Al el ement o lo describe una clase de anlisis?
Otros el ement os son similares al el ement o considerado? Si es as, es posible
que pudieran combinarse en un elemento?
El elemento se usa en un ordenami ent o especfico de otros elementos? Su
aparicin depende de otros elementos?
Otro el ement o siempre sigue a la aparicin del el ement o considerado?
Qu condiciones previas y posteriores se deben satisfacer para utilizar el ele-
mento?
Categoras de usuario especficas aprovechan al elemento? Las diferentes
categoras de usuario emplean de manera diferente al elemento? Si es as,
cmo?
El el ement o puede estar asociado con una meta u objetivo de formulacin
especfico? Con un requisito WebApp especfico?
Este el ement o siempre aparece al mismo tiempo que aparecen otros el emen-
tos? Si es as, cules son los otros elementos?
Este el ement o siempre aparece en el mismo lugar (por ejemplo, misma ubi-
cacin de la pantalla o pgina) que otros elementos? Si es as, cules son los
otros elementos?
Las respuest as a st as y ot ras preguntas ayudan al ingeniero Web a posicionar el ele-
ment o en cuestin dentro de la WebApp y a establecer relaciones entre elementos.
Es posible desarrollar una relacin taxonmica y categorizar cada relacin iden
tificada debido a las preguntas anotadas. El lector interesado debe remitirse a
[YOOOO] para ms detalles.
18.7.2 Anlisis de navegacin
Una vez que entre los el ement os se han desarrollado relaciones definidas dentro del
model o de anlisis, el ingeniero Web debe considerar los requisitos que dictan cmo
navegar cada categora de usuario de un el ement o (por ejemplo, objeto de cont-
TM
PDF Editor
Qu p r e -
g u n t a s s e
d e b e n p l a n t e a r
p a r a c o mp r e n d e r
me or l os r equi s i -
t o s d e n a v e g a -
ci n?
^ O N S E J O ^
Mientras se onalizan
los requisitos de nave-
gaci n, recurdese
que el usuario siempre
debe saber d nde
est y o d nde va.
Para lograrlo el
usuario necesito un
" mapa" .
nido) a otro. Los mecani smos de navegacin se definen como parte del diseo. En
esta et apa, los desarrolladores deben considerar requisitos de navegacin globales
Las siguientes preguntas se deben plantear y responder:
Ciertos el ement os deben ser ms fciles de alcanzar (es decir, requieren me-
nos pasos de navegacin) que otros? Cul es la prioridad de presentacin?
Ciertos el ement os deben resaltarse para forzar a los usuarios a navegar en
su direccin?
Cmo se manej arn los errores de navegacin?
La navegacin hacia grupos de el ement os relacionados debe ser prioritaria
sobre la navegacin hacia un elemento especfico?
La navegacin se debe lograr por medio de vnculos, de acceso basado en
bsqueda o por otros medios?
Ciertos el ement os se deben present ar a los usuarios con base en el contexto
de acciones de navegacin previas?
El acceso a la navegacin debe mant enerse para los usuarios?
En cada punt o de la interaccin del usuario debe estar disponible un mapa o
men de navegacin completo (en oposicin a un simple vnculo de "retroce-
so" o puntero dirigido)?
El di seo de la navegacin debe nutrirse de los comport ami ent os de usuario
ms comnment e esperados o mediante la importancia percibida de los ele-
ment os WebApp definidos?
Un usuario puede "almacenar" su navegacin previa a travs de la WebApp
para un uso futuro expedito?
Para qu categora de usuario se debe disear una navegacin ptima?
Cmo se manej arn los vnculos externos a la WebApp? Superponiendo la
vent ana de navegador existente? Cmo una nueva vent ana de navegador?
Cmo un marco separado?
stas y muchas ot ras preguntas se deben plantear y responder como part e del an-
lisis de navegacin.
El equipo de ingeniera Web y sus participantes tambin deben determinar los re
quisitos globales para la navegacin. Por ejemplo, se proporcionar un "mapa de
sitio" para brindar a los usuarios un panorama integral de la estructura de la WebApp"
El usuario puede realizar un "recorrido" que subraye los el ement os ms importan-
t es (objetos de contenido y funciones) disponibles? Un usuario tendr la capacidac
de acceder a los objetos de contenido o funciones con base en los atributos defini-
dos de dichos el ement os (por ejemplo, un usuario tal vez desee acceder a t odas la:
fotografas de una construccin especfica o a t odas las funciones que permitan e!
clculo del peso)?
TM
PDF Editor
C A P T U L O 1 8 MODELADO DE ANLISIS PARA APLICACIONES WEB 563
' : '
La formulacin, la recopilacin de requisitos y el model ado de anlisis se llevan a ca-
bo como parte del anlisis de requisitos para las WebApps. El propsito de dichas ac-
tividades es 1) describir la motivacin bsica (metas) y objetivos para la WebApp; 2)
definir las categoras de usuarios; 3) sealar los requisitos de contenido y de funcin
para la WebApp; y 4) establecer una comprensin bsica de por qu se construir la
WebApp, quien la usar y qu problema(s) les resolver a los usuarios.
Los casos de uso son los catalizadores para todos los anlisis de requisitos y ac-
tividades de modelado. Adems, pueden organizarse en paquetes funcionales, y cada
paquet e se valora para garantizar que es comprensible, cohesivo, libremente acopla-
do y jerrquicamente superficial.
Cuatro actividades de anlisis contribuyen a la creacin de un modelo de anlisis
completo: el anlisis de contenido identifica t odo el espectro de contenido que pro-
porcionar la WebApp; el anlisis de interaccin describe la forma en la que el usua-
rio interacta con la WebApp; el anlisis de funciones define las operaciones que se
aplicarn al contenido de la WebApp y describe otras funciones de procesami ent o
independientes del contenido, pero necesarias para el usuario final; y el anlisis de
la configuracin describe el ambiente de la infraestructura en la que reside la WebApp.
El model o de contenido describe el espectro de los objetos correspondientes que
sern incorporados en una WebApp. Dichos objetos de contenido se deben desarro-
llar o adquirir para integrarlos en la arquitectura de la WebApp. Es factible utilizar un
rbol de dat os para representar la jerarqua de un objeto de contenido. Las clases de
anlisis (derivadas de los casos de uso) proporcionan otros medios para representar
los objetos clave que manipular la WebApp.
El model o de interaccin se construye con casos de uso, di agramas de secuencia
UML y di agramas de est ado UML para describir la "conversacin" entre el usuario y
la WebApp. Adems, se construye un prototipo de la interfaz que auxilie en el desa-
rrollo de la plantilla y los requisitos de navegacin.
El model o funcional describe las funciones observables para el usuario y las ope-
raciones de clase que emplean el diagrama de actividad UML. El model o de configu-
racin describe el ambi ent e que requerir la WebApp, t ant o en el lado del servidor
como en el del cliente del sistema.
El anlisis de relacin-navegacin identifica las relaciones entre el contenido y los
el ement os funcionales, definidos en el model o de anlisis, y establece requisitos pa-
ra definir vnculos de navegacin apropiados a travs del sistema. Una serie de pre-
gunt as ayudan a establecer relaciones e identificar caractersticas que influirn so-
bre el diseo de navegacin.
[CONOO] Conal l en, ). , Building Web Applications mth UML. Addison-Wesley, 2000.
[F..A01] Franklin, S., "Planning Your Web Site wi t h UML", webReview, di sponi bl e en
ht t p: / / www. webr evi ew. com/ 2001 / 05_18/ deveIopers/ i ndexO I shtml.
TM
PDF Editor
564
[SRI01] Sridhar, M. y N. Mandyam, "Effective Use of Data Models in Building Web Applications' '
2001, di sponi bl e en ht t p: / / www2002. or g/ CDROM/ al t er nat e/ 698/ .
[Y00991 Yoo, J. y M. Bieber, "A Syst emat i c Relationship Analysis for Model i ng Informat i on Do-
mai ns", 1999, se puede descar gar de ht t p: / / ci t eseer . nj . nec. com/ 312025. ht ml .
[YOOOO] Yoo, J. y M. Bieber, "Toward a Relationship Navigation Analysis", en Proc. 33rd Hawai
Conf. On System Sciences, vol. 6, IEEE, ener o de 2000, se puede descar gar de www. cs. nj i t . e-
du/ ~bi eber / pub/ hi css00/ I NWEB02. pdf .
18. 1 Con bas e en el gr an abani co de r ecur sos acerca del desarrol l o de s of t war e gil disponible
en la Web, i nvest i gese un poco y est abl zcase un r azonami ent o en cont r a del model ado de
anl i si s par a l as WebApps. Se consi der a que la ar gument aci n r esul t ant e se aplica en t odos los
casos?
18.2 Si f uese f or zoso a llevar a cabo un "model ado de anl i si s ligero" (es decir, model ado de
anl i si s mi ni mo), qu r epr esent aci ones, di agr amas e i nformaci n se defi ni r an dur ant e est a ac-
tividad de i ngeni er a Web?
18. 3 Medi ant e un di agr ama similar al mos t r ado en la figura 18.1, est abl zcase una j erarqu a de
usuari o par a (a) un sitio Web de servi ci os financieros o (b) un sitio Web de vent a de libros.
18. 4 Qu r epr esent a un paquet e de cas o de uso?
18. 5 Los cas os de uso o l os paquet es de cas o de us o s e val oran par a gar ant i zar que son co.r-
prensibles, cohesivos, libremente acoplados y jerrquicamente superficiales. Describase con pala-
br as pr opi as qu significan es t os t rmi nos.
Eljase una WebApp que se visite r egul ar ment e de una de l as si gui ent es cat egor as: (a) noticias
o deport es, (b) ent r et eni mi ent o, (c) comer ci o el ect rni co, (d) j uegos, (e) rel aci onados con
comput aci n, (0 una WebApp que r ecomi enden los profesores. Real cense l as act i vi dades ir
cadas en los pr obl emas del 18.6 al 18.12:
18.6 Desarrl l ense uno o m s cas os de us o que descr i ban un compor t ami ent o de usuari o es
pecfico para la WebApp.
18. 7 Repr esnt ese una j erarqu a de cont eni do parcial y def nanse al me nos t res cl ases de an-
lisis par a la WebApp.
18.8 Desarrl l ese un di agr ama de secuenci a UML y un di agr ama de es t ado UML que descr
una i nt eracci n espec fi ca con la WebApp.
18. 9 Consi drese la i nt erfaz exi st ent e de la WebApp. Hgase un prot ot i po de cambi o a la i nt f - j
faz que s e consi dere suscept i bl e de mej orar.
1 8. 1 0 Eljase una funci n obser vabl e para el usuari o que of r ezca la WebApp y modl ese i
di ant e un di agr ama de act i vi dad UML.
18. 11 Eljase un obj et o de cont eni do o funci n que sea par t e de la arqui t ect ura de la Web/
y r es pndans e l as pr egunt as rel aci n- navegaci n menci onadas en la secci n 18.7.1.
18.12 Consi drese la WebApp exi st ent e y r es pndans e las pr egunt as rel aci n- navegac
menci onadas en la Secci n 18.7.2.
Mu c h o s libros dedi cados al model ado de anl i si s para sof t war e convenci onal (con partic
nf asi s en los cas os de us o y la not aci n UML) cont i enen mucha i nformaci n til susceptible :
adapt ar s e fci l ment e a la ingeniera Web. Los cas os de us o f or man los ci mi ent os del modei;
TM
PDF Editor
C A P T U L O 1 8 MODELADO DE ANLISIS PARA APLI CACI ONES WEB 565
de anl i si s par a l as WebApps. Los l i bros de Kulak y s us col egas (Use Cases.- Requrements in Con
text, s egunda edi ci n, Addison-Wesley. 2004). BiUner y Spence (Use Case Modeling, Addi son-
Wesley, 2002), Cockburn (Wrting Effective Use Cases, Addison-Wesley, 2001), Ar mour y Miller
(Advanced Use-Case Modeling: Software Systems, Addison-Wesley, 2000), Rosenberg y Scott (Use
Case Driven Object Modeling with UML: A Practical Approcah, Addison-Wesley, 1999) y Schneider,
Wi nt er s y Jacobson (Applying use Cases. A practical Guide, Addison-Wesley, 1998) of r ecen una
guia valiosa en la creaci n y empl eo de est e i mpor t ant e mecani s mo de r epr esent aci n de requi-
sitos. Valiosas di scusi ones de UML han escri t o Arlow y Neust adt (UML and the Unifled Process,
Addison-Wesley, 2002), Schmul l er (Teach YourselfUML, Sams Publishing, 2002), Booch y s us co-
l egas (The UML User Guide, Addison-Wesley, 1998), y Rumbaugh y s us col egas (The Unified Mo-
deling Language Reference Manual, Addison-Wesley, 1998).
Los libros dedi cados al di seo de sitios Web con frecuenci a cont i enen uno o dos cap t ul os
que abor dan t emas de anl i si s ( aunque usual ment e son di scusi ones superficiales). Los siguien-
t es libros cont i enen uno o m s aspect os del anl i si s dent r o del cont ext o de la ingeniera Web:
Van Duyne y s us col egas (The Design of Sites, Addison-Wesley, 2002), Rosenfeld y Morville (In-
formation Architecturefor the World Wide Web, O'Reilly & Associates, 2002), Wodtke (Information
Architecture, New Riders Publishing, 2002), Garret (The Elements of User Experience: User Cente-
red Design for the Web, New Riders Publishing, 2002), Niederst (Web Design in a Nulshell, O' Reilly
& Associ at es, 2001), Lowe y Hall (Hypertext and the Web: An Engineerng Approach, Wilev 1999),
y Powell (Web Site Engineerng, Prentice-Hall, 1998) of r ecen una cobert ura r azonabl ement e
completa. Norris, West y Watson (Media Engineerng: A Guide lo Developing Information Products,
Wiley, 1997), Navarro y Khan (Effective Web Design: Master the Essentials, Sybex, 1998) y Fleming
y Koman (Web Navigation: Designing the User Experience, O'Reilly & Associates, 1998) proporcio-
nan gua adi ci onal par a anl i si s y di seo.
En Internet hay di sponi bl e una gran vari edad de f uent es de i nformaci n acer ca del model a-
do de anl i si s para i ngeni er a Web. Una lista act ual i zada de referenci as en la World Wide Web
se encuent r a baj o "sof t war e engi neer ng r esour ces" en el sitio Web de SEPA:
TM
PDF Editor
C A P I T U L O
19
MODELADO DE DI SEO PARA
APLI CACI ONES WE B
C O N C E P T O S
CL AVE
arquitectura de
coatenida . 586
arquitectura
MVC
atributos
de calidad . 569
diseo al nivel de
componentes . . 593
diseo
arqui t ect ni co. . 585
diseo
de cont eni do. . . 584
diseo
de la i nt erfaz . . 5 7 3
diseo
de navegacin . 590
diseo esttico . 582
MDHOO . . . . , 595
m t r i c a s . . . . 5 9 8
pat r ones . . . . . 5 9 4
E
n su aut ori zado libro acerca del di seo Web, Jakob Nielsen [N1E00] afirrr
"En esenci a, existen dos enf oques bsi cos del diseo: el ideal artstico c
expresarse uno mi smo y el ideal de ingeniera de resolver un probl ema p
ra un cliente". Durante la pri mera dcada del desarrol l o Web, la idea artstica fi
el enf oque que eligieron muchos desarrolladores. El di seo ocurri en una forir
ad hoc y usual ment e era dirigido conf or me se gener aba el HTML. El di seo ew
lucion de una visin artstica que en s mi sma evol uci on conf or me ocurr >:
const rucci n de la WebApp.
Incluso en la actualidad, los def ensor es "radicales" del desarrol l o de soft wa
gil (captulo 4) utilizan las aplicaciones Web como cartel de ni os para "dise"
limitado". Argument an que la i nmedi at ez y la volatilidad de las WebApps 2:
nan el di seo formal, que el di seo evol uci ona conf or me se const ruye (codi
ca) una aplicacin y que se debe gast ar rel at i vament e poco t i empo en la ere
cin de un model o de di seo detallado. Este ar gument o tiene mrito, per o SQ
para WebApps rel at i vament e simples. Cuando el cont eni do y la funcin son co
piejos, cuando el t amao de la WebApp abarca ci ent os de obj et os de c o n t e n
funci ones y cl ases de anlisis, cuando el xito de la WebApp t endr un i mpa:
directo sobre el xito del negocio, el di seo no puede ni debe ser t omado a la
gera.
Esta realidad conduce al segundo enf oque de Nielsen: "el ideal de ingen:e:
de resolver un probl ema para un cliente". La ingeniera Web adopt a esta filos
fia, y un enfoque ms riguroso del di seo WebApp permi t e a los desar r ol l ada
lograrlo.
Qu e s ? El diseo de WebApps
abarca actividades tcnicas y otras
que no (o son. La visin y el sentido
dei contenido se desarrollan como
parte del diseo grfico; l a pl ant i l l a
esttica de la interfaz de usuario se crea como
parte del diseo de la interfaz; y la estructura
tcnica de la WebApp se modela como parte del
diseo arquitectnico y de navegacin. En toda
instancia se debe crear un modelo de diseo
antes de que comience la construccin, pero un
buen ingeniero Web reconoce que el diseo evo-
lucionar mientras ms se conozca acerca de l os
requisitos de los participantes conforme se cons-
truya la WebApp.
Qui n l o hac e ? tos ingenieros Web, diseade
res grficos, desarrolladores de contenido
otros participantes colaboran en la creacin c
un modelo de diseo para la ingeniera Web
Por qu e s i mport ant e? El diseo permite
un ingeniero Web crear un modelo que pueo
valorarse en calidad y mejorarse antes de que <
generen el contenido y el cdigo, se realice
pruebas y se involucren muchos usuarios finle
El diseo es el lugar donde se establece la ca
dad de la WebApp.
Cul es s on l os pa s o s ? El diseo WebAf
abarca seis grandes pasos a los cuales alime-
la informacin obtenida durante el modelado :
anlisis.
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PARA APLICACIONES WEB 5 6 7
i: : seo de contenido utiliza informacin conte-
- ; a dentro del modelo de anlisis como una
pese para establecer el diseo de los objetos de
| .: - enido y sus relaciones. El diseo esttico
I c-ibin llamado diseo grfico) establece la
i- won y el sentimiento que observa el usuario
n i . El diseo arquitectnico se enfoca sobre la
es-uctura hipermedia global de todos los obje-
1 : de contenido y funciones. El diseo de la
----faz establece la plantilla global y los meca-
nismos de interaccin que definen la interfaz del
. oario. El diseo de navegacin define cmo
-cvega el usuario final a travs de la estructuro
- :ermedia, y el diseo de componentes repre-
s a la estructura interna detallada de los ele-
mentos funcionales de la WebApp.
Cul e s el product o obt eni do? Un modelo
de diseo que abarque temas de diseo de con-
tenido, esttica, arquitectura, interfaz, navega-
cin y al nivel de componente es el producto de
trabajo primario del diseo de ingeniera Web
Cmo pue do es t ar s eguro de que Jo he
he c ho correct ament e? El equipo de inge-
niera Web (y algunos participantes selecciona-
dos) revisa cada elemento del modelo de diseo
con la finalidad de descubrir errores, inconsis-
tencias u omisiones. Adems, se consideran
soluciones alternativas, y tambin se valora el
grado en el que el modelo de diseo actual con-
ducir a una implementacin efectiva.
1 9 . 1 TEMAS DE DI SEO PARA I NGENI ER A WEB
Cuando se aplica el di seo dent ro del cont ext o de la ingeniera Web, se deben con-
si derar cuest i ones t ant o genri cas como especficas. Desde un punt o de vista gen-
rico, el diseo resulta en un model o que gua la construccin de la WebApp. El model o
de diseo, sin i mport ar su forma, debe cont ener suficiente i nformaci n para reflejar
cmo habrn de t raduci rse los requisitos de los part i ci pant es (definidos en un mode-
lo de anlisis) en cont eni do y cdi go ejecutable. Pero el di seo t ambi n debe ser es-
pecfico. Debe abordar at ri but os clave de una WebApp en una forma que permi t a al
i ngeni ero Web construir y ponerl a a prueba de maner a efectiva.
19.1.1 Diseo y calidad de una WebApp
En captulos ant eri ores se seal que el di seo es la actividad de ingeniera que con-
duce a un product o de gran calidad. Esto conduce a una pregunta recurrente que se
presenta en toda las disciplinas de ingeniera: qu es calidad? En esta seccin se exa-
minar la respuesta en el cont ext o de la ingeniera Web.
Toda persona que haya navegado en la Web o usado una Intranet corporat i va tie-
ne una opinin acerca de lo que hace una "buena" WebApp. Los punt os de vista in-
dividuales varan enor mement e. Algunos usuari os disfrutan los grfi cos que bailan,
ot ros qui eren texto simple. Algunos solicitan i nformaci n copiosa, ot ros desean una
presentacin abreviada. A al gunos les gustan las herrami ent as analticas sofisticadas o
los accesos a las bases de datos, a otros les gustan las cosas simples. De hecho, la per-
cepci n del usuari o de lo que es "bueno" (y la resul t ant e acept aci n o r echazo de la
WebApp como consecuenci a) puede ser ms i mport ant e que cualquier discusin tc-
nica de la calidad de la WebApp.
TM
PDF Editor
568 P AR T E T RE S APLICACIN DE LA INGENIERA WEB
Pero cmo se aprecia la calidad de la WebApp? Qu atributos debe exhibir pa-
ra lograr ser buena a los ojos de los usuarios finales y al mi smo tiempo mostrar las
caractersticas tcnicas de calidad que permitirn a un ingeniero Web corregir, adap-
tar, mejorar y apoyar la aplicacin a largo plazo?
En realidad, t odas las caractersticas generales de la calidad de soft ware tratadas
en los captulos 9, 15 y 26 se aplican a la WebApps. Sin embargo, las ms relevan
t es de dichas caractersticas facilidad de uso, funcionalidad, confiabilidad, eficien-
cia y facilidad de mantenimiento proporcionan una base til para valorar la calidac
de los sistemas basados en Web.
"Si l os pr oduc t os s e di s e a n p or a e nc a j a r me j or e n l as t e n de n c i a s n a t u r a l e s del c o mp o r t a mi e n t o h u mo n o , e n t on c e s lo
g e n t e e s t a r m s s a t i s f e c ha , m s c omp l e t a y s e r m s pr oduc t i va . "
Olsina y sus colegas [OLS99] han preparado un "rbol de requisitos de calidac
que identifica un conj unt o de atributos tcnicos facilidad de uso, funcionalidac
confiabilidad, eficiencia y facilidad de mantenimiento que conducen a WebApps c;
gran calidad.1 La figura 19.1 resume su trabajo. Los criterios anot ados en la figura
son de particular inters para los ingenieros Web que deben disear, constru -
mant ener las WebApps a largo plazo.
Offutt [OFF02] extiende los cinco principales atributos de calidad anot ados en i
figura 19.1 al agregar los atributos siguientes:
Sus a n We i ns c he nk
rbol d e
r equi si t os d e
c a l i da d [OLS9"1
Facilidad de uso
- Caractersticas de la interfaz y esttica
- Caractersticas especiales
Comprensibilidad global del sitio
Caractersticas de retroalimentacin en lnea y ayuda
Funcionalidad
Capacidades de bsqueda y recuperacin
Caractersticas de navegacin y visualizacin
Caractersticas de la aplicacin relacionadas con el dor - : I
Calidad
de la Confiabilidad
Correcto procesamiento de vnculos
Recuperacin de errores
Validacin y recuperacin de entrada de usuario aplicacin Web
Desempeo en tiempo de respuesta
Rapidez de generacin de pgina
Rapidez de generacin de grficos
Fcil de corregir
Adaptabilidad
Extensibilidad
1 Estos atributos de calidad sori muy similares a los que se presentan en los captulos 9, 15 y 26
lo tanto, se deduce que las caractersticas de calidad son universales para todo el software.
TM
PDF Editor
C A P I T U L O 1 9 MODELADO DE DISEO PARA APLI CACI ONES WEB 5 6 9
Seguri dad. Las WebApps se han convertido en una parte integral de las bases de
pr i nci pa- dat os cruciales del gobierno y las empresas. Las aplicaciones de comercio electrni-
co extraen y luego al macenan informacin confidencial de los clientes. Por st as y
muchas ot ras razones, la seguridad de las WebApps es primordial en muchas situa-
ciones. La medida clave de la seguridad es la habilidad de la WebApp y su ambi ent e
de servidor de rechazar el acceso no autorizado e impedir un franco at aque malvo-
lo. Un anlisis detallado de la seguridad WebApp est ms all del al cance de est e
libro. El lector interesado debe consultar [MCC01], [NOR02] o [KAL03].
Disponibilidad. Incluso la mejor WebApp no satisfar las necesidades de los
usuarios si no est disponible. En un sentido tcnico, la disponibilidad es la medida
del porcent aj e del tiempo que una WebApps est disponible para usarla. El usuario
final comn espera que las WebApps estn disponibles las 24 horas de t odos los das
del ao. Algo menos es considerado inaceptable.2 Pero "a tiempo" no es el nico in-
dicador de disponibilidad. Offutt [C)FF02j sugiere que "usar caractersticas disponi-
bles slo en un navegador o una plataforma" hace que la WebApp no est disponi-
ble para quienes tengan una configuracin de navegador y plataforma diferente. El
usuario invariablemente se ir a otra parte.
Escalabilidad. La WebApp y su ambi ent e de servidor pueden escalarse para ma-
nejar 100, 1 000, 10 000 o 100 000 usuarios? La WebApp y los sistemas con los cua-
les est conectada manej an variaciones significativas en el volumen o la capacidad
de respuesta caer catastrficamente (o cesar por completo)? No es suficiente
construir una WebApp exitosa. Es igualmente importante construir una WebApp que
pueda acomodar el peso del xito (significativamente ms usuarios finales) y volver-
se todava ms exitosa.
Ti empo en el mercado. Aunque en sentido tcnico el tiempo en el mercado no
es un verdadero atributo de calidad, es una medida de calidad desde un punt o de vis-
ta de los negocios. La primera WebApp en el mercado usual ment e captura un nme-
ro desproporcionado de usuarios finales.
Cientos de miles de pginas Web estn disponibles para qui enes busquen informa-
cin en la World Wide Web. Incluso las bsquedas Web mejor dirigidas resultan en
una aval ancha de contenido. Con t ant as fuentes de informacin de las cuales elegir,
cmo valora el usuario la calidad (por ejemplo, veracidad, precisin, integridad,
oportunidad) del contenido que se present a dentro de una WebApp? Tillman |TIL00]
sugiere un conjunto de criterios til para valorar la calidad del contenido:
El mbito y la profundidad del contenido se pueden determinar con facilidad
para asegurar que satisfacen las necesi dades del usuario?
2 Desde luego, esta expectativa es irreal Las grandes WebApps deben planificar el "periodo de inac-
tividad" para reparaciones y actualizaciones.
TM
PDF Editor
INFORMACIN
Lista de verificaci n de la calidad
, La siguiente lista de verificacin, adaptada de
la informacin presentada en Webreference.
com, proporciona un conjunto de preguntas que ayudarn
tanto a los ingenieros Web como a los usuarios finales a
valorar la calidad global de una WebApp:
El contenido, la funcin o las opciones de navegacin
pueden ajustarse a las preferencias del usuario?
El contenido o la funcionalidad se pueden personalizar
al ancho de banda en el cual se comunica el usuario?
Las grficas y los otros medios que no son textuales se
han usado de manera apropiada? El tamao de los ar-
chivos grficos est optimizado para que se desplie-
guen con eficiencia?
del dise o de la WebApp
Las tablas estn organizadas y dimensionadas en una
forma que las hace comprensibles y que se desplieguen
eficientemente?
El HTML est optimizado para eliminar ineficiencias?
El diseo global de la pgina facilita la lectura y la na-
vegacin?
Todos los punteros (vnculos) proporcionan vnculos cor
informacin interesante para los usuarios?
Es probable que la mayora de los vnculos persistan
en la Web?
La WebApp est instrumentada con utilidades de ges
tn del sitio que incluyan herramientas para rastrear >.
uso, prueba de vnculos, bsqueda local y seguridad?
/
7 Qu s e
w d e b e r a
c ons i de r a r cuan-
do s e v a l o r e el
c ont e ni do d e ca-
l i da d?
Adems de est as pregunt as rel aci onadas con el contenido, se pueden aadir las a
guientes:
El cont eni do es creble?
El cont eni do es nico? Esto es, la WebApp proporciona algn beneficio u n
co a qui enes la usen?
El cont eni do es valioso para la comuni dad de usuari os a que se dirige?
El cont eni do est bien organi zado? Est en un ndice? Es fcilmente ac:
sible?
La lista de verificacin anot ada en esta seccin slo represent a una pequea m j d
tra de los asunt os que deben abordarse conforme evolucione el diseo de una WebAj J
Una met a i mport ant e de la ingeniera Web es desarrollar si st emas en los que se r r j
porci onen respuest as afi rmat i vas a t odas las pr egunt as rel aci onadas con la c a l i i J
"Solo porque puedes, no significo que debes. "
Jean Ksv
Los ant ecedent es y la jerarqua de los aut ores del cont eni do se pueden iden-
tificar fcilmente?
Es posible det ermi nar la precisin del contenido, la ltima actualizacin y
que fue actualizado?
El cont eni do y su ubicacin son est abl es (es decir, per manecer n en la UR_
de referencia)?
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PARA APLICACIONES WEB 571
19.1.2 Metas de diseo
En su columna regular acerca del diseo Web, Jean Kaiser [KAI02] sugiere las si-
guientes met as de diseo, que son aplicables virtualmente a toda WebApp sin im-
portar el dominio, t amao o complejidad de la aplicacin:
Simplicidad. Aunque pueda parecer pasada de moda, la expresin "todo con mo-
deracin" se aplica a las WebApps. Existe una tendencia entre algunos diseadores
a proporcionar al usuario final "demasiado": contenido exhaustivo, efectos visuales
extremos, animacin entrometida, enormes pginas Web, la lista es larga. Es mejor
luchar por la moderacin y la simplicidad.
Consi stenci a. Esta meta de diseo se aplica virtualmente a cada el ement o del
modelo de diseo. El contenido se debe construir de manera consistente (por ej em-
plo, el formato del texto y los estilos de fuente deben ser los mi smos a lo largo de to-
dos los document os de texto; el arte grfico debe tener una apariencia consistente,
esquema de color y estilo). El diseo grfico (esttica) debe presentar una aparien-
cia consistente en todas las partes de la WebApp. El diseo arquitectnico debe es-
tablecer plantillas que conduzcan a una estructura hipermedia consistente. El diseo
de interfaz debe definir modos consistentes de interaccin, navegacin y despliegue
de contenido. Los mecani smos de navegacin deben usarse de manera consistente
a travs de todos los el ement os de la WebApp.
Identidad. La esttica, la interfaz y el diseo de navegacin de una WebApp de-
ben ser consistentes con el dominio de la aplicacin para la cual se va a construir.
Un sitio Web para un grupo hip-hop indudablemente tendr una apariencia y un sen-
tido diferente al de una WebApp diseada para una compaa de servicios financie-
ros. La arquitectura de WebApp ser completamente diferente, las interfases se
construirn para acomodar diferentes categoras de usuarios, la navegacin estar
organizada para lograr diferentes objetivos. Un ingeniero Web (y otros contribuyen-
t es de diseo) deber trabajar para establecer una identidad para la WebApp por me-
dio del diseo.
Robust ez. Con base en la identidad establecida, usual ment e una WebApp hace
una "promesa" implcita al usuario. El usuario espera contenido y funciones robus-
tas que sean relevantes para sus necesidades. Si dichos el ement os estn perdidos o
son insuficientes es probable que la WebApp fracase.
Navegabilidad. Ya se ha seal ado que la navegacin debe ser simple y consisten-
te. Tambin debe estar diseada de modo que sea intuitiva y predecible. Esto es, el
usuario debe ent ender cmo moverse por la WebApp sin tener que buscar vnculos
o instrucciones de navegacin.
Apariencia visual. De todas las categoras de software, las aplicaciones Web son
incuestionablemente las ms visuales, las ms dinmicas y sin duda las ms estti-
cas. Es indudable que la belleza (apariencia visual) est en el ojo del observador, pero
muchas caractersticas de diseo (por ejemplo, la apariencia y sentido del conten-
TM
PDF Editor
do, la plantilla de la interfaz, la coordi naci n del color, el equilibrio del texto, los gna I
fieos y ot ros medi os audiovisuales, los mecani smos de navegacin) s contribuyen i I
aspect o visual.
Compati bi l i dad. Una WebApp se utilizar en una diversidad de ambi ent es (pc*|
ejemplo, diferentes equipos, tipos de conexin a Internet, si st emas operativos, nave-I
gadores) y se debe di sear para que sea compatible con cada uno.
- - - " ~
" P o r a a l gunos , el d i s e o We b s e e n f o c a e n la a p a r i e n c i a y s e n t i do v i s u a l e s . . . p or a ot r os , el di s e o We b t r a t a d e la es
t r uc t ur a c i n d e i nf or ma c i n y l a n a ve g a c i n a t r a v s del es poci o de l d o c u me n t o . Ot r os i ncl us o p u e d e n c ons i de r a r q u e
el di s e o We b t r a t a a c e r c o d e la t ecnol og a e mp l e a d o p a r a cons t r ui r apl i caci ones We b i nt er act i vas . En r e a l i da d, el di se
o i ncl uye t o d a s est os f a c t or e s y oc a s o m s . "
Th o ma s P o w e l
1 9 . 2 P I R MI D E DEL D I S E O I W E B
Qu es di seo en el cont ext o de la ingeniera Web? Esta pregunt a simple es ms J
ficil de responder de lo que uno puede creer. El di seo conduce a un model o q J
cont i ene la mezcla adecuada de esttica, cont eni do y tecnologa. La mezcla var aba
dependi endo de la nat ural eza de la WebApp, y, como consecuenci a, las a c t i v i d a d
de di seo t ambi n variarn.
La figura 19.2 muest ra una pirmide de di seo para la ingeniera Web. Cada r va
de la pirmide represent a una de las siguientes actividades de diseo.-
Diseo de la interfaz: describe la estructura y organi zaci n de la interfaz de
usuario. Incluye una represent aci n de la plantilla de pantalla, una defi ni d : r
de los modos de interaccin y una descripcin de los mecani smos de navega-)
cin.
Diseo esttico: t ambi n l l amado diseo grfico, describe la "apariencia y
sentimiento" de la WebApp. Incluye es quemas de color, plantilla geomtrica |
t amao de texto, fuent e y ubicacin, uso de grficos y deci si ones estticas n
lacionadas.
Diseo de contenido: define la plantilla, la est ruct ura y el bosquej o de todc d
cont eni do que se present a como part e de la WebApp. Establece las relacio"<a
ent re los obj et os de cont eni do.
Diseo de navegaci n: represent a el flujo de navegaci n ent re los objetos d a
cont eni do y para t odas las funci ones de la WebApp.
Di seo arqui t ect ni co: identifica la est ruct ura hi permedi a global para la I
WebApp.
Diseo de component es: desarrolla la lgica de procesami ent o detallado c j q
se requiere para i mpl ement ar component es funcionales.
En las secci ones que siguen se consi deran con mayor detalle cada una de
actividades de diseo.
CLAVE
lo IWeb abarca seis
diferentes tipos de
diseo. Cada uno
contribuye o la calidad
global de la WebApp.
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PARA APLI CACI ONES WEB 573
1 9 . 3 DI S EO PE L A INTERFAZ PE L A WE B A P P 3
Toda interfaz del usuario ya sea di seada para una WebApp, una aplicacin de
soft ware tradicional, un product o de consumo o un dispositivo industrial debe pre-
sent ar las siguientes caractersticas: fcil de usar, fcil de aprender, fcil de navegar,
intuitiva, consistente, eficiente, libre de errores y funcional. Debe ofrecer al usuario
final una experiencia satisfactoria y gratificante. Los conceptos, principios y mt odos
de di seo de la interfaz brindan al ingeniero Web las herrami ent as requeri das para
lograr esta lista de atributos.
En el captulo 12 se observ que el di seo de la interfaz comi enza no con una
consideracin de la tecnologa, sino ms bien con un cui dadoso examen del usuario
final. Durante el model ado de anlisis para la ingeniera Web (Captulo 18), se desa-
rrolla una jerarqua de usuario. Cada categora de usuario puede tener necesi dades
sutilmente diferentes, tal vez quiera interactuar con la WebApp en diferentes formas
y quiz requiera funcionalidad y cont eni do nicos. Esta informacin se deriva duran-
te el anlisis de requisitos, pero se revisa como el primer paso en el di seo de la in-
terfaz.
"Si u n si t i o es p e r f e c t a me n t e ut i i i zobl e p e r o cor ece d e un est i l o d e di s eo e l e g a n t e y a d e c u a d o , f r a c a s a r . "
Cur t Cl oni nger
Dix [DIX99] ar gument a que un ingeniero Web debe di sear una interfaz de modo
que responda tres pregunt as primarias para el usuario final:
3 La mayora de, si no es que todas, las directrices presentadas en el capitulo 12 se aplican igualmen-
te al diseo de interfases WebApp. Si todava no lee ei capitulo 12, hgalo en este momento.
TM
PDF Editor
( CONSEJO^
Si es probable que los
usuarios puedon en-
trar a su WebApp en
varios ubicaciones y
niveles en la jerarqua
de contenido, aseg-
rese de dise ar cada
pgina con caracters-
ticas de navegaci n
que conduzcan al
usuario a los otros
puntos de inters.
\
CLAVE
Uno buena i nt er f az
WebApp es comprensi -
ble e i ndul gent e, y
ofrece al usuari o una
sensaci n de cont rol .
D nde estoy? La interfaz debe 1) ofrecer una indicacin de que se ha tenido ac-
ceso a la WebApp4 y 2) informar al usuario de su ubicacin en la jerarqua de conte-
nido.
Qu puedo hacer ahora? La interfaz si empre debe ayudar al usuario a entender
sus opci ones actuales: qu funci ones est n disponibles, qu vnculos estn vivos,
qu cont eni do es relevante.
D nde he estado, a d nde voy? La interfaz debe facilitar la navegacin. En conse-
cuencia, debe proporcionar un "mapa" (implementado en una forma fcil de entender;
de dnde ha est ado el usuario y qu rutas puede t omar para moverse a cualquie:
part e dent ro de la WebApp.
La interfaz de una WebApp efectiva debe proporci onar respuest as a cada una de es-
tas pregunt as conforme el usuario final navega a travs del cont eni do y la funciona-
lidad.
19.3.1 Principios y directrices del diseo de la interfaz
Bruce Tognozzi [TOGOl] define un conj unt o de caractersticas fundament al es
deben present ar t odas las interfaces y, al hacerlo, est abl ece una filosofa que
seguir todo di seador de interfaz de WebApp:
Las i nt erfaces efect i vas son vi sual ment e apar ent es e indulgentes, e implantan en sus
usuarios una sensacin de control. Los usuarios ven rpi dament e la envergadura de sus op-
ciones, compr enden cmo lograr sus met as y hacen su trabajo.
Las interfaces efectivas no preocupan al usuario con los t rabaj os i nt ernos del si st ema
El t rabaj o se guarda de maner a cui dadosa y cont i nua, con la opcin total de que el usua-
rio deshaga cualquier actividad en cual qui er tiempo.
Las apl i caci ones y servicios efectivos realizan un mxi mo de t rabaj o mi ent ras deman-
dan un m ni mo de i nformaci n a los usuarios.
Con la finalidad de disear interfaces que muest ren dichas caractersticas, T.
nozzi [TOGOl] identifica un conj unt o de principios de di seo primordiales:5
Anticipaci n: una WebApp se debe dise ar de modo que anticipe el siguiente
miento del usuario. Por ejemplo, considere una WebApp de soporte al cliente
rrollada para un fabricante de impresoras para comput adora. Un usuario ha solic:
un objeto de cont eni do que present a informacin acerca de un controlador de
pr esor a par a un si st ema operat i vo l anzado r eci ent ement e. El di seador tie
WebApp debe anticipar que el usuario pueda solicitar una descarga del contro
Todas las personas han marcado alguna pgina de un sitio Web, slo para volver a visitarla ma
de y no tener que dar indicaciones del sitio Web o del contexto de la pgina (asi como para
moverse hacia otra ubicacin dentro del sitio).
Los principios originales de Tognozzi se han adaptado y extendido con el fin de aprovech
este libro. Vase TOGOl] para mayores detalles acerca de estos principios.
TM
PDF Editor
C A P T U L O 1 9 MODELADO d e d e e o p a e a a p l i c a c i o n e s we b 575
y debe proporcionar facilidades de navegacin que permitan hacerlo sin solicitarle al
usuario una bsqueda de esta capacidad.
V E Comunicaci n: la interfaz debe comunicar el estado de cualquier actividad que haya
de una iniciado el usuario. La comunicacin puede ser obvia (por ejemplo, un mensaj e de
estar di- texto) o sutil (por ejemplo, una hoja de papel que se mueva a travs de una impre-
sora para indicar que la impresin est en camino). La interfaz tambin debe comu-
nicar el est ado del usuario (por ejemplo, la identificacin del usuario) y la ubicacin
dent ro de la jerarqua de contenido de la WebApp.
Consistencia: el uso de los controles de navegaci n, mens, iconos y esttica (por
ejemplo, color, forma, plantilla) deben ser consistentes a travs de toda la WebApp. Por
ejemplo, si el texto subrayado de azul implica un vnculo de navegacin, el conteni-
do nunca debe incorporar texto subrayado en azul que no implique un vnculo. To-
da caracterstica de la interfaz debe responder en una forma que sea consistente con
las expectativas del usuario.6
Autonoma controlada: la interfaz debe facilitarle al usuario el movimiento a travs de
toda la WebApp, pero lo debe hacer en una forma que refuerce las convenciones de na-
vegaci n establecidas para la aplicaci n. Por ejemplo, la navegacin hacia porciones
seguras de la WebApp se deben controlar con la identificacin del usuario y su con-
trasea, y no debe existir mecani smo de navegacin que permita al usuario dar la
vuelta a dichos controles.
Eficiencia: el dise o de la WebApp y su interfaz deben optimizar la eficiencia laboral
del usuario, no la eficiencia del ingeniero Web que la dise a y la construye o el ambien-
te cliente-servidor que la ejecuta. Tognozzi [TOGOl] seala est o cuando escribe: "Es-
ta simple verdad es por lo que es importante para todos los involucrados en un pro-
yecto de soft ware el apreciar la importancia de hacer propia la meta de productivi-
dad del usuario y entender la diferencia vital entre construir un sistema eficiente y
fortalecer a un usuario eficiente."
Flexibilidad: la interfaz debe ser lo suficientemente flexible como para permitir que al-
gunos usuarios realicen tareas directamente y otros exploren la WebApp en una forma
un tanto aleatoria. En todo caso, debe permitirle al usuario ent ender dnde est y
ofrecerle la funcionalidad para que pueda deshacer los errores y volver a trazar las
rutas de navegacin mal elegidas.
Enfoque: la interfaz de la WebApp (y el contenido que presenta) debe enfocarse en
la(s) tarea(s) importante(s) para el usuario. En toda hipermedia existe una tendencia
para dirigir al usuario hacia contenido mal relacionado. Por qu? Porque es muy
fcil hacerlo! El problema es que el usuario rpidamente se puede perder en muchas
capas de informacin de apoyo y perder el sitio del contenido original que quera en
primer lugar.
6 Tognozzi [TOGOl] seala que la nica forma de garantizar que las expectativas del usuario se com-
prendan adecuadamente es mediante una amplia prueba r or parte del usuario (captulo 20)
TM
PDF Editor
576 P A R T E TRES APLICACIN DE LA INGENIERA WEB
Web d e s a t e muchos
API en ava. s ui uom
o COt, DCOM y
msdn.Microsoft.
caai.
Ley de Fitt: " El tiempo para adquirir un objetivo es una Junci n de la distancia a la que
se halla y de su tama o" [TOGOl). Con base en un estudio realizado en la dcada de
1950 [F1T54], la ley de Fitt "es un mt odo efectivo de modelar rpidos movimientos
dirigidos, donde un apndice (como una mano) parte del reposo en una posicin de
inicio especfica y se mueve hacia el reposo dentro de una rea establecida como ob-
jetivo" [ZHA02], Si una tarea del usuario define una secuencia de selecciones o entradas
estandarizadas (con muchas opciones diferentes dentro de la secuencia), la primer;
seleccin (por ejemplo, seleccin de ratn) debe estar fsicamente cerca de la siguien
te seleccin. Por ejemplo, considere la interfaz de la pgina de inicio de una WebApp
en un sitio de comercio electrnico que vende aparatos electrodomsticos.
Cada opcin del usuario implica un conjunto de elecciones o acciones de segui-
miento del usuario. Por ejemplo, una opcin "comprar un producto" requiere que e
usuario ingrese una categora de producto seguida por el nombre de ste. La cate-
gora del producto (por ejemplo, equipo de audio, televisores, reproductores de D\ Ti |
aparece como un men desplegable tan pronto como se selecciona "comprar un pro-
ducto". En consecuencia, la siguiente eleccin es i nmedi at ament e obvia (est cercaij
y el tiempo para adquirir es despreciable. Si, por otra parte, la eleccin aparece en
un men ubicado en el otro lado de la pantalla, el tiempo para que el usuario lo s i -
quiera (y luego realice la eleccin) ser demasiado.
Objetos de interfaz humana: Se ha desarrollado una gran librera de objetos de intt'
faz humana reutilizables para WebApps. selas. Es posible adquirir, de varias libreras
de objetos, cualquier objeto de interfaz que pueda ser "visto, escuchado, tocado o x
algn otro modo percibido" [TOGOl] por un usuario final.
Reducci n de latencia: Ms que obligar al usuario a esperar el fin de alguna operj*
ci n interna (por ejemplo, descargar una imagen grfica compleja), la WebApp debe usJ
la multitarea en una forma que permita al usuario proceder con el trabajo como s.
operaci n hubiese sido completada. Adems de reducir la latencia, las demoras debea
reconocerse de modo que el usuario comprenda lo que est ocurriendo. Esto inc. j l
ye 1) proporcionar retroalimentacin de audio (por ejemplo, un "clic" o c a mp a n a c J
cuando una seleccin no genera una accin inmediata de la WebApp; 2) despl et aB
un reloj ani mado o barra de progreso para indicar que el procesami ent o est en m a n
cha; 3) ofrecer algn entretenimiento (por ejemplo, una animacin o presentacin l
texto) mientras ocurra un procesami ent o largo.
]
"El me j o r vi aj e es el q u e t i e n e el me n o r n me r o d e p a s o s . Acor t e l a di s t anci a e n t r e el u s u a r i o y s u me t a . "
Facilidad de aprendizaje: La interfaz de una WebApp se debe dise ar para minirr .: J
el tiempo de aprendizaje y, una vez aprendido, reducir el reaprendizaje requerido cun>|
do se vuelve a visitar la WebApp. En general, la interfaz debe acentuar un diseo s i J
pie e intuitivo que organice el contenido y la funcionalidad en categoras obvias : J
ra el usuario.
TM
PDF Editor

i son una
poique
r faenando
S lo
ique
queseeli-
lanodo
usuarios
Metforas: una interfaz que utilice una metfora de interacci n es ms fcil de apren-
der y de usar, en tanto la metfora sea apropiada para la aplicaci n y el usuario. Una
met fora debe llamar i mgenes y concept os de la experiencia del usuario, per o no
necesita ser una reproduccin exact a de una experiencia del mundo real. Por ejemplo,
un sitio de comerci o electrnico que i mpl ement a el pago de cuent as aut omat i zado pa-
ra una institucin financiera usa una metfora de lista de verificacin (no de maner a
sorprendente) para asistir al usuario en la especificacin y la calendarizacin de los
pagos de cuent as. Sin embargo, cuando un usuario "escribe" un cheque, no necesita
ingresar el nombre compl et o del pagador sino que puede elegir de una lista de paga-
dores o hacer que el si st ema seleccione con base en las pri meras letras escritas. La
met fora per manece intacta, per o el usuario obt i ene asistencia de la WebApp.
Mantener la integridad del producto de trabajo. Un producto de trabajo (por ejemplo,
una forma completada por el usuario, una lista especificada por el usuario) debe guardar-
se de manera automtica de modo que no se perder si ocurriese un error. Todo mundo
ha experi ment ado la frustracin asoci ada con el hecho de completar un gran formu-
lario WebApp slo para que el cont eni do se pierda debido a un error (que comet e el
usuario, la WebApp o la transmisin de cliente a servidor). Para evitar est o la WebApp
se debe di sear para aut oguardar t odos los dat os especificados por el usuario.
Legibilidad: toda la informaci n presentada a travs de la interfaz debe ser legible pa-
ra j venes y viejos. El di seador de la interfaz debe enfat i zar los estilos de letra legi-
ble, t amaos de f uent e y opci ones de fondo de color que mej oren el cont rast e.
Estado de rastro: Cuando sea adecuado, el estado de la interacci n del usuario debe
rastrearse y almacenarse de modo que un usuario pueda salir y regresar ms tarde al lu-
gar de donde sali . En general, las cookies se pueden di sear para al macenar infor-
maci n de est ado. Sin embargo, las cookies son una tecnologa controvertida, y ot r as
sol uci ones de di seo pueden ser ms acept abl es para al gunos usuari os.
Navegaci n visible: una interfaz de WebApp bien dise ada proporciona " la ilusi n de
que los usuarios estn en el mismo lugar, y que se les lleva el trabajo hasta sus lugares"
[TOGOl]. Cuando se usa est e enf oque la navegaci n no es preocupaci n del usuari o.
En lugar de eso, el usuari o recupera obj et os de cont eni do y sel ecci ona funci ones que
se despl i egan y ej ecut an por medi o de la interfaz.
i act ores : Doug Miller (gerente del grupo de inge
n en'a del software de HogarSeguro) y Vinod Raman,
-embro del equipo de ingeniera del software del pro
wcto HogarSeguro.
La c onve r s ac i n:
Doug: Vinod, el equipo y t tuvieron oportunidad de
reviso' el prototipo de la interfaz de comercio electrnico
de HogorSegurolnc.com?
Vi nod: S . todos lo experimentamos desde un punto
TM
PDF Editor
5 7 8 PARTE TRES APLICACIN DE LA INGENIERA WEB
de vista tcnico y yo tengo un montn de notas. Ayer se
los envi por correo electrnico a Sharon [gerente del
equipo de ingeniera Web de lo empresa subcontratista
para el sitio Web de comercio electrnico de HogarSe-
grl- !('
Doug: Sharon y t se pueden reunir y discutir los peque-
os detalles.. dame un resumen de los conflictos impor-
t ant e. < ' "-V ' ' I t
Vi nod: En general, hicieron un buen trabajo, nada de
labor profunda, pero es una tpica interfaz de comercio
electrnico, esttica decente, plantilla razonable. Han
considerado todas las funciones importantes...
Doug (sonre tristemente): Pero?
Vi nod: Bueno, existen algunas cositas...
Doug: Como cules?
Vinod (muestra a Doug una secuencia de bos-
quejos para el prototipo de la interfaz): Aqu
est el men de funciones principales que se despliega en
!a pgina de inicio:
Aprenda acerca de HogarSeguro
Describa su casa
Obtenga recomendaciones de componentes
de HogarSeguro
Compre un sistema HogarSeguro
Obtenga soporte tcnico
El problema no es con estas funciones, todas estn bien,
pero el nivel de abstraccin no es el correcto.
Doug: Todas son funciones principales, no es as?
Vi nod: Lo son, pero este es el punto... t puedes com-
prar un sistema al ingresar una lista de componentes.,
en realidad no necesitas describir la casa, si no quieres
Yo suger slo cuatro opciones de men en la pgina de
inicio:
Aprenda acerca de HogarSeguro
Especifique el sistema HogarSeguro que nece-
sita
Cuando selecciones especifique el sistema Hogar-
Seguro que neces i t a, entonces tendrs las Siguiente:-
opciones:
Seleccione componentes HogarSeguro
de HogarSeguro
Si eres un usuario avanzado, seleccionars componente:
de un conjunto de mens desplegabies categorizados pe
ra sensores, cmaras, paneles de control, etctera. Si ne-
cesitas ayuda, pedirs una recomendacin y sta
requerir que describas tu casa. Creo que es un poco
ms lgico.
Doug: Estoy de acuerdo. Ya hablaste con Sharon acer-
ca de esto?
Vi nod: No, primero quiero discutir esto con los de
mercadotecnia; luego le hablar por telfono.
Nielsen y Wagner [NIE96] sugi eren unas cuant as directrices pr agmt i cas en el di
seo de i nt erfases (basados en su redi seo de una gran WebApp) que proporci or a
un buen compl ement o a los principios sugeri dos prrafos at r s en esta seccin:
La rapidez de lectura en un moni t or de comput ador a es apr oxi madament e 25
por ci ent o ms lenta respect o de la lectura en i mpresos. En consecuenci a, no
fuerce al usuari o a leer vol umi nosas cant i dades de texto, en particular cuandi
se explica la operaci n de la WebApp o se ofrece ayuda en la navegaci n.
Evite los signos de "en construccin", crean expectativas y provocan un vncu.-:
i nnecesari o que es seguro para la decepci n.
Los usuari os prefieren no despl azarse. La i nformaci n i mport ant e debe est a:
dent ro de las di mensi ones de una vent ana tpica de navegador.
Los mens de navegaci n y los encabezados deben est ar di seados de mane
ra consi st ent e y deben est ar disponibles en t odas las pgi nas que est n dispe-
TM
PDF Editor
nibles para el usuario. El di seo no debe descansar en las funci ones del nave-
gador para asistir en la navegaci n.
La esttica nunca debe sustituir la funcionalidad. Por ejemplo, un si mpl e bo-
tn puede ser una mej or opci n de navegaci n que una i magen o un i cono
est t i cament e pl acent eros per o vagos, cuya intencin no es clara.
Las opci ones de navegaci n deben ser obvias, incluso para el usuari o casual .
El usuari o no debe t ener que buscar en la pant al l a para det ermi nar cmo vin-
cul arse con ot r o cont eni do o servicio.
Una i nt erfaz bien di seada mej ora la percepcin del usuari o del cont eni do o servi-
cios que proporci ona el sitio. No necesar i ament e tiene que ser ost ent osa, si no que
si empre debe est ar bien est ruct urada y er gonmi cament e saludable.
"Lo gente tiene muy poco paciencia con los sitios WWW pobremente diseados"
p;-.
J a k o b N i e l s e n y An n e t t e W a g n e r
smos
i suonibles
; diseadores
c?
19.3.2 Mecanismos de control de la interfaz
Los objetivos de la interfaz de una WebApp son 1) est abl ecer una vent ana consi st en-
te con el cont eni do y la funci onal i dad que proporci ona, 2) guiar al usuari o a t ravs
de una serie de i nt eracci ones con la WebApp, y 3) organi zar las opci ones de nave-
gaci n y el cont eni do disponible para el usuario. Lograr una interfaz consi st ent e re-
qui ere que el di seador use pri mero el di seo est t i co (seccin 19.4) con el fin de es-
t abl ecer una "apariencia" coher ent e para la interfaz. Esto abarca muchas caracters-
ticas, per o debe subrayar la plantilla y la forma de los mecani smos de navegaci n.
Para guiar la interaccin del usuario, el di seador de la i nt erfaz puede empl ear una
met fora apropi ada7 que permi t a al usuari o adquirir una comprensi n intuitiva de la
interfaz. Las opci ones de navegaci n las i mpl ement a el di seador sel ecci onando de
ent re vari os mecani smos de interaccin:
Merts de navegacin: mens clave (organi zados vertical u hori zont al ment e)
que menci onan cont eni do o funcionalidad clave. Dichos mens se pueden im-
pl ement ar de modo que el usuari o pueda elegir de una jerarqua de subt emas
que se despliegan cuando se selecciona la opcin de men primario.
conosgrficos: botn, i nt errupt ores e i mgenes grficas similares que permi-
ten al usuari o sel ecci onar al guna propi edad o especificar una decisin.
Imgenes grficas: al guna represent aci n grfica que el usuari o pueda selec-
ci onar y que i mpl ement e un vnculo hacia un obj et o de cont eni do o funci ona-
lidad de la WebApp.
7 En est e cont ext o, una metfora es una represent aci n (extrada de la experiencia del mundo real del
usuario) que puede model arse dent r o del cont ext o de la i nt erfaz Un ej empl o simple puede ser un
i nt errupt or deslizable con que se controla el vol umen auditivo de un archivo , mp3
TM
PDF Editor
Es importante anot ar que uno o ms de dichos mecani smos de control debe propcF]
cionarse en cada nivel de la jerarqua de contenido.
19.3.3 Flujo de trabajo en el diseo de la interaz
Aunque un anlisis detallado del diseo de la interfaz para WebApps es mejor de ; - l
lo a libros de texto que se dedican a la materia (por ejemplo, [GAL02], [RASOOS
[NIE00]), vale la pena echar un vistazo a las tareas de di seo clave. En el captulo : J
se seal que el diseo de la interfaz del usuario comienza con la identificacin :
ste, la tarea y los requisitos ambientales. Una vez que se han identificado las tar
del usuario, se crean y analizan sus escenari os (casos de uso) para definir un co a }
junto de objetos y acci ones de interfaz. Este trabajo se representa como parte
modelo de anlisis de la WebApp tratado en el captulo 18.
Las siguientes t areas representan un flujo de trabajo rudimentario para el di
de la interfaz WebApp.
1. Revi sar l a i nf or maci n cont eni da en el mode l o d e anl i si s y ret i narl a
c o n f o r me s e r equi er a.
2. Des ar r ol l ar un bos q ue j o a pr oxi ma do de la pl ant i l l a d e la i nt er f az de
WebApp. Como part e de la actividad de model ado del anlisis se pudo haber
desarrollado un prototipo de la interfaz (que incluya la plantilla). Si ya exis.e
la plantilla, debe revisarse y refinarse conforme se requiera. Si no se ha desa-
rrollado la plantilla de la interfaz, el equipo de ingeniera Web debe trabajar
con los participantes para desarrollarla en este moment o. En la figura 19.3 se
muestra una primera versin de un bosquejo de plantilla.
Co r r e l a ci n
de l o s o b je t i -
v o s de l us ua -
r i o e n l a s a c -
c i o n e s d e l a
i n t e r a z.
Lisia de objetivos
del usuario
Objetivo #1
Objetivo #2 N
Objetivo #3
Objetivo #4
Objetivo #5
Objetivo #n
Barra de men
de funciones principle: I
/
Men de
navegacin
Grfico, logotipo y nombre de la compa a
3 !
Grfico
; Texto de la pgina inicial
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PARA APLICACIONES WEB 581
3. Cor r el aci onar l os obj et i vos del us uar i o con a c c i one s es pec f i cas d e la
i nt er f az. Para la gran mayora de las WebApps, el usuario tendr un conj unt o
relativamente primario de objetivos primarios (usualmente ent re cuat ro y sie-
te). stos deben correlacionarse con acciones especficas de la interfaz, como
se muestra en la figura 19.3.
4. Def i ni r un c onj unt o d e t a r e a s de us uar i o que e s t n a s oc i a da s c on ca-
da acci n. Cada accin de la interfaz (por ejemplo, "comprar un producto")
est asociada con un conj unt o de t areas de usuario. Dichas tareas se identifi-
caron durant e el model ado de anlisis. Durante el diseo deben correlacio-
narse interacciones especficas que abarquen asunt os de navegacin, objetos
de contenido y funciones WebApp.
5. El abor ar bos q ue j os c on i m ge ne s d e la pant al l a par a c a da acci n de
la i nt er f az. Conforme se considera cada accin, se debe crear una secuencia
de imgenes en bosquejo (imgenes de pantallas) para esbozar cmo responde
la interfaz a la interaccin del usuario. Se deben identificar los objetos de con-
tenido (incluso si todava no se disean ni desarrollan), se debe mostrar la
funcionalidad de la WebApp y se deben indicar los vnculos de navegacin.
6. Ref i nar la pl ant i l l a de la i nt er f az y l os bos q ue j os con el u s o d e ent r a-
d a s d e s d e el di s e o es t t i co. La plantilla aproximada y los bosquejos los
completan los ingenieros Web, pero la apariencia y la percepcin esttica para
un gran sitio comercial con frecuencia los desarrolla un artista, en lugar de
profesionales tcnicos.
7. I dent i f i car l os obj e t os d e la i nt er f az del us uar i o q u e s e r equi er an par a
i mpl ement ar l a. Esta tarea puede requerir una bsqueda en una librera de
objetos existente para encont rar aquellos objetos reutilizables (clases) apro-
piados para la interfaz de la WebApp. Adems, en est e moment o se especifi-
can cualesquiera clases de personalizacin.
8. Des ar r ol l ar una r epr es ent aci n de pr ocedi mi ent o de la i nt er acci n
del us uar i o con la i nt er f az. Esta labor opcional usa di agramas de secuen-
cia UML o di agramas de actividad (estudiados en el captulo 18) para esbozar
el flujo de actividades (y decisiones) que ocurren conforme el usuario interac-
ta con la WebApp.
9. Des ar r ol l ar una r e pr e s e nt a c i n del c ompor t a mi e nt o d e l a i nt er f az. Es-
ta tarea opcional utiliza di agramas de est ado UML (estudiados en el captulo
18) para representar las transiciones de est ado y los eventos que las causan.
Se definen los mecani smos de control (es decir, los objetos y acciones dispo-
nibles con que el usuario altera el est ado de una WebApp).
10. Descr i bi r la pl ant i l l a de l a i nt er f az par a cada e s t a do. Con el uso de la
informacin de diseo desarrollada en las tareas 2 y 5, se asocia una plantilla
especfica o imagen de pantalla con cada est ado de la WebApp descrito en la
tarea 9.
TM
PDF Editor
11. Ref i nar y r evi s ar el mo d e l o d e d i s e o de l a i nt er f az. La revisin de la in-
t erfaz se debe enf ocar en la facilidad de uso (captulo 12).
Es i mport ant e not ar que el conj unt o de t areas finales que haya elegido un equi po de
ingeniera Web se debe adapt ar a los requisitos especi al es de la aplicacin que se va
a construir.
1 9 . 4 DI S E O
^ O N S E J O ^ -
N o todo ingeniero W eb
( o ingeniero efe softw are)
tiene talento art stico
( est tico) . S i se est en
esto cotegorio, contrtese
anse adorgik o
esttico.
El di seo esttico, t ambi n l l amado diseo grfico, es un esf uer zo artstico que com-
pl ement a los aspect os t cni cos de la ingeniera Web. Sin l, una WebApp puede ser
funcional, per o sin atractivo. Con l, una WebApp lleva a sus usuari os a un munde
que los incluye en un mbi t o t ant o emoci onal como intelectual.
Pero, qu es esttica? Existe un viejo dicho: "la bel l eza existe en los oj os de quier
la ve". Esto es part i cul arment e apropi ado cuando se consi dera el di seo esttico pa-
ra las WebApps. Para realizar un di seo est t i co efectivo, de nuevo se regresa a la
j erarqu a de usuari os desarrol l ada como part e del model o de anlisis (captulo 18> :
s e pregunt a qui nes son los usuari os de la WebApp y qu "apariencia" desean.
"Encontramos que la gente rpidamente evala un sitio slo por su diseo visual."
D i r e ct r i ce s St a n f o r d p a r a l a cr e di b i l i da d e n t a W e b
19.4.1 Cuestiones de la plantilla
Toda pgi na Web tiene una cant i dad limitada de "bien i nmuebl e" que puede usars-r
para dar soport e a la esttica no funcional, caractersticas de navegaci n, cont ent :
de i nformaci n y funci onal i dad dirigida al usuari o. El "desarrollo" de est e bien in-
muebl e se pl anea dur ant e el di seo esttico.
Al igual que las cuest i ones estticas, no existen reglas absol ut as cuando se dise- j
a una plantilla de pantalla. Sin embar go, vale la pena consi derar al gunos linea-i
mi ent os general es de plantilla:
N o temerle al espacio vac o. No es aconsej abl e rellenar cada cent met ro cuadr ad: I
de una pgi na Web con i nformaci n. El amont onami ent o resul t ant e dificulta que e:l
usuari o identifique la informacin o caract er st i cas necesari as y crea un caos visua
desagradabl e.
Resaltar el contenido. Despus de todo, st a es la razn por la cual el usuari o es
t aqu. Nielsen [NIEOO] sugiere que la tpica pgina Web debe ser 80 por ci ent o cor-
t eni do con el rest o del bien i nmuebl e dedi cado a navegaci n y ot r as caractersticas.
Organizarlos elementos de plantilla de arriba a la izquierda hacia abajo a la derechc
La gran mayor a de los usuari os expl orarn una pgi na Web en gran part e de la mis-l
ma forma en que exploran las pgi nas de un libro: de arriba a la izquierda hacia aba-j
TM
PDF Editor
C A P I T U L O 1 9 MODELADO DE DISEO PARA APLI CACI ONES WEB 583
jo a la derecha.8 Si los el ement os de plantilla tienen prioridades especficas, los ele-
ment os de mayor prioridad deben colocarse en la porcin superior izquierda de la
pgina bien inmueble.
Agrupar navegacin, contenido y Juncin geogrficamente dentro de la pgina. Los
humanos buscan pat rones virtualmente en t odas las cosas. Si no existen pat rones
discernibles dent ro de una pgina Web, es probable que aument e la frustracin del
usuario (debido a la bsqueda innecesaria de la informacin requerida).
N o extender el bien inmueble con la barra de desplazamiento. Aunque con frecuen-
cia el despl azami ent o es necesario, la mayora de los estudios indican que los usua-
rios preferiran no desplazarse. Es mejor reducir el contenido de la pgina o presen-
tar el contenido necesari o en varias pginas.
Considerar la resolucin y el tama o de la ventana de navegador cuando dise e planti-
llas. En vez de definir t amaos fijos dentro de una plantilla, el diseo debe especificar
todos los artculos de la plantilla como un porcentaje del espacio disponible [N1E00].
19.4.2 Cuestiones de diseo grfico
El dise o grfico consi dera cada aspect o de la present aci n y percepcin de una
WebApp. El proceso de diseo grfico comi enza con la plantilla (seccin 19.4.1) y
procede hacia la consideracin de esquemas de color globales, tipos de fuentes, ta-
maos y estilos, el uso de medios audiovisuales compl ement ari os (por ejemplo, au-
dio, video, animacin) y todos los dems el ement os estticos de una aplicacin. El
lector interesado puede obtener sugerenci as y directrices de diseo en muchos sitios
Web que se dedican al tema (por ejemplo, www.graphic-design.com, www. grant as-
ticdesigns.com, www. wpdfd. com) o de una o ms fuent es i mpresas (por ejemplo,
[BAG01], [CLOO1 ] o [HEI02]).
INFORMACIN
S itios W eb bien dise ados
En ocasiones, la mejor forma de comprender el
buen diseo de las WebApps es observar unos
ejemplos. En su artculo "The Top Twenly We b De-
Tips" (Las mejores 20 sugerencias par a el diseo
, Marcelle Toor (http://www.graphic-design.com/
ure/tips.html) sugiere los siguientes sitios Web
ejemplos de buen diseo grfico:
primo.com: firma de diseo encabezada por Primo
Angel.
workbook.com: este sitio sirve como apar ador par a
el t rabaj o de ilustradores y diseadores.
www. pbs. org/ riverofsong: serie de televisin par a la radi o
y la televisin pblicas acerca de la msica
estadounidense
www.RKDINC.com: firma de diseo con un portafolios en
lnea y buenas sugerencias de diseo.
www. commart s. com/ career/ i ndex. ht ml: revista Communi-
cation Arts, una publicacin peridica par a di seado-
res grficos. Una buena fuente par a otros sitios bien
diseodos.
www.btdnyc.com: firma de diseo encabezada por Beth
Toudreau.
8 Existen excepci ones basadas en la cultura y el idioma, per o est a regla se aplica a la mayora de los
usuari os.
TM
PDF Editor
1 9 . 5 DI S E O PEE CONT E NI DO
El dise o del contenido se enf oca en dos asunt os de di seo diferentes, cada uno :
abordan individuos con distintos conj unt os de habilidades. El di seo del cont eni J
desarrolla una represent aci n de di seo para los obj et os de cont eni do y represer al
los mecani smos que se requi eren para que est abl ezcan s us rel aci ones uno con ot r: J
Esta actividad de di seo la dirigen los i ngeni eros Web.
Adems, el di seo de cont eni do se ocupa de la represent aci n de la i nformaci c-J
dent ro de un obj et o de cont eni do especfico: actividad de di seo que dirigen los r - J
blicistas, los di seador es grficos y ot ros que gener an el cont eni do de una WebAppl
"Los buenos diseadores pueden crear normalidad a partir del caos; pueden comunicar las ideas con claridad por me-
dio de la organizacin y el manejo de las palabras y los dibujos."
m -< " J e f f e r y V e e r
19.5.1 Objetos de contenido
La relacin ent re obj et os de cont eni do, definida como part e del model o de a n i i s J
WebApp (por ejemplo, figura 18.3), y los obj et os de di seo que represent an cont enn
do es anl oga a la relacin ent re las cl ases de anlisis y los component es de di se*
descritos en el captulo 11. En el cont ext o de la ingeniera Web un objeto de coniam
do est al i neado de maner a ms cer cana con un obj et o de dat o para sof t war e c c e l
Re p r e s e n t a c i n
de l di s e o d e
l o s o b j e t o s d e
c o n t e n i do .
Component edeProduct o
par l eNmer o
par t eNombr e
part e Tipo
descripcin
preci o
crea rN uevo Artc u lo j)
desplegarDescripcn()
despl egar EspecTcnica
Es part e d e
Sensor Cmor a Panel d e Control Car act Sof t war e
I
1
Descr i pe i ndeCompon ent e
0 . 1
n
1 . . * | 0. . 1 0. . 11 l |
Desc r i pe inDeMarketi ng Fotografa Esquema Video Descr i pci nTcr c;
color lexto
es t i b fuent e
t amao fuent e
es paci ado lnea
tamao texto uso
color fondo
dimensin horizontal
dimensin vertical
estilo bor de
dimensin horizontal
dimensin vertical
estilo bordo
dimensin horizontal
dimensin vertical
estilo bor de
volumen audi o
color texto
estilo fuente
t amao fuente
espac ami ent o lire=
t amao texto imoger
color f ondo
color lexto
es t i b fuent e
t amao fuent e
es paci ado lnea
tamao texto uso
color fondo
dimensin horizontal
dimensin vertical
estilo bor de
volumen audi o
color texto
estilo fuente
t amao fuente
t amao texto imoger
color f ondo
color lexto
es t i b fuent e
t amao fuent e
es paci ado lnea
tamao texto uso
color fondo
color texto
estilo fuente
t amao fuente
t amao texto imoger
color f ondo
color texto
estilo fuente
t amao fuente
t amao texto imoger
color f ondo
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PARA APLI CACI ONES WEB
585
! tienden o
r el esplazo-
i * rtk al ms
que el
tiento hori-
. vitelos
s de pgina
vencional. Un objeto de contenido tiene atributos que incluyen informacin especi-
fica de contenido (normalmente definida durant e el model ado de anlisis WebApp)
y atributos especficos de implementacin que se especifican como part e del diseo.
Como ejemplo, considrese la clase de anlisis que se desarroll para el sistema
de comercio electrnico HogarS eguro llamado Compone nt e de Pr oduc t o que se de-
sarroll en el captulo 18 y se representa como aparece en la figura 19.4. En el cap-
tulo 18 se mencion un atributo descr i pci n que aqu se representa como una clase
de diseo llamada De s c r i pc i nde Compone nt e , compuest a de cinco objetos de
contenido: Des cr i pci nDeMar ket i ng, Fot ogr af a, Descr i pci nTcni ca, Esque-
ma y Vi deo, que se muestran como objetos sombreados en la figura. La informacin
que contiene el objeto de contenido se registra como atributos. Por ejemplo, Fot o-
gr af a (una imagen .jpg) tiene los atributos di mens i n hor i zont al , di mens i n
ver t i cal y est i l o d e bor de
Mediante una asociacin UML y un agregado9 se pueden representar relaciones
entre los objetos de contenido. Por ejemplo, la asociacin UML que se muestra en la
figura 19.4 indica que se emplea una De s c r i pc i nde Compone nt e para cada ins-
tancia de la clase Compone nt e de Pr oduc t o. De s c r i pc i nde Compone nt e est
integrado por los cinco objetos de contenido mostrados. Sin embargo, la multiplici-
dad de notacin que se muestra indica que Es q ue ma y vi deo son opcionales (es po-
sible que se presenten cero ocurrencias), se requieren una Des cr i pci nDeMar ke-
t i ng y Descr i pci nTcni ca, y se aplican una o ms instancias de Fot ogr af a.
19.5.2 Cuestiones del diseo de contenido
Una vez modelados t odos los objetos de contenido, la informacin que cada objeto
entregar debe crearse y luego formatearse para satisfacer mejor las necesidades del
cliente. La creacin del contenido es el trabajo de los especialistas que disean el ob-
jeto de contenido al proporcionar un esbozo de la informacin que se ent regar y
una indicacin de los tipos de los objetos de contenido genricos (por ejemplo, tex-
to descriptivo, i mgenes grficas, fotografas) mediante los cuales se entregar la in-
formacin. Tambin se puede aplicar el diseo esttico (seccin 19.4) para represen-
tar la apariencia y percepcin adecuados para el contenido.
Conforme se disean, los objetos de contenido se "despedazan" [POWOO] para
formar pgi nas de la WebApp. El nmero de objetos de contenido que se incorporan
en una sola pgina es en funcin de las necesi dades del usuario, de las restricciones
impuestas por la rapidez de descarga de las conexiones de Internet y debido a las
restricciones que impone la cantidad de despl azami ent o que el usuario tolerar.
El dise o arquitectnico est enl azado con las met as establecidas para la WebApp, el
contenido que se presentar, los usuarios que la visitarn y la filosofa de navega-
9 Ambas represent aci ones se discuten en el capi t u: : 8
TM
PDF Editor
cin que se est abl ezca. El di seador arquitectnico debe identificar la arquitectura
de cont eni do y la arquitectura de la WebApp. La arquitectura de contenido10 se cen-
tra en la forma en la que los obj et os de cont eni do (u obj et os compuest os como las
pgi nas Web) se est ruct uran para su present aci n y navegaci n. La arquitectura de
W ebApp aborda la forma en la que la aplicacin se est ruct ura para gestionar la inte-
raccin del usuario, manej ar las t ar eas de pr ocesami ent o internas, efect uar la nave-
gacin y present ar el cont eni do.
"[l]o estructura arquitectnico de un sitio bien diseado no siempre es aparente para el usuario... ni lo debe ser."
Thomas Powell
l 3
En la mayor a de los casos, el di seo arqui t ect ni co se dirige en paral el o con e
di seo de la interfaz, el esttico y el de cont eni do. Puest o que la arquitectura Web-
App puede t ener una fuert e influencia sobre la navegaci n, las deci si ones t omadas
durant e est a actividad de di seo influirn en el t rabaj o dirigido durant e el di seo ce
navegaci n.
19.6.1 Arquitectura de contenido
El di seo de la arquitectura de contenido se cent ra en la definicin de la estructura h> j
permedi a global de la WebApp. El di seo se puede elegir de cuat ro di ferent es estruc-
t uras de cont eni do [POWOO]:
Las estructuras lineales (figura 19.5) se encuent r an cuando es comn una secuer -
cia predecible de i nt eracci ones (con al guna variacin o desviacin). Un ej empl o ca-1
sico puede ser una present aci n tutorial en la que las pgi nas de i nformaci n j unt :
con grficos rel aci onados, vi deos cort os o audi o se present an sl o despus de que
se ha pr esent ado informacin de prerrequisitos. La secuenci a de la present aci n ce
cont eni do est predefinida y, por lo general, es lineal. Otro ej empl o puede ser una j
secuenci a de ent r adas para comprar un product o, en la cual se debe detallar infor- J
maci n especfica en un orden especfico. En tales casos, son apr opi adas las estruc-
t uras most r adas en la figura 19.5. Conforme el cont eni do y el pr ocesami ent o se vue. -j
ven ms compl ej os, el flujo mer ament e lineal most r ado a la izquierda de la figura ca
paso a est ruct uras lineales ms compl ej as en las que se puede llamar cont eni do a -:
ternativo u ocurre una desviacin para adquirir cont eni do compl ement ari o (estruc-
tura most r ada a la derecha de la figura 19.5).
Las estructuras en ret cula (figura 19.6) son una opcin arquitectnica aplicafc r:
cuando el cont eni do de la WebApp est organi zado cat egri cament e en dos (o m= i]
di mensi ones. Por ejemplo, consi drese una situacin en la cual un sitio de c ome r : !
electrnico vende pal os de golf. La di mensi n horizontal de la retcula represent a r j
tipo de pal o que se vende (por ejemplo, mader a, hierro, w edges, putters) . La dimer
10 El t rmi no arquitectura de informacin t ambi n se utiliza para sugerir est ruct uras que conducen ;
una mej or organi zaci n, etiquetado, navegaci n y bsqueda de obj et os de cont eni do.
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PARA APLICACIONES WEB
587
sin vertical representa las ofertas de varios fabricantes de pal os de golf. En conse-
cuencia, un usuario puede navegar la retcula horizontalmente para encont rar la co-
lumna putters y luego verticalmente para examinar las ofertas de aquellos fabricantes
que venden putters. Esta arquitectura de WebApp slo es til cuando se encuent ra
contenido al t ament e regular [POWOO],
Las estructuras jerrquicas (figura 19.7) son indudablemente las arquitecturas WebApp
ms comunes. A diferencia de las jerarquas de software factorizadas que se estu-
diaron en el captulo 10, que alinean el flujo de control slo a lo largo de las ramas
verticales de la jerarqua, una estructura jerrquica WebApp se puede disear en una
forma que permita (va ramificaciones de hipertexto) el flujo de control horizontal-
mente, a travs de las ramas verticales de la estructura. Por lo tanto, el contenido
present ado en la rama de la extrema izquierda de la jerarqua puede tener vnculos
TM
PDF Editor
1
Es t r uct ur a
j e r r qui ca .
de hipertexto que conduzcan a contenido que existe en la rama de en medio o a
derecha de la estructura. Sin embargo, se debe sealar que, aunque tales ramifica-
ciones permiten la navegacin rpida a travs del contenido de la WebApp, pue
conducir a confusin en la parte del usuario.
Una estructura en red o "W eb pura" (figura 19.8) es similar en muchos sentidos
la arquitectura que evoluciona para los si st emas orientados a objetos. Los compc
nent es arquitectnicos (en este caso, pginas Web) estn di seados de modo
pueden pasar el control (va vnculos de hipertexto) virtualmente a cualquier
component e en el sistema. Este enfoque permite una considerable flexibilidad en
navegacin, pero al mismo tiempo puede ser confusa para el usuario.
Las estructuras arquitectnicas coment adas en los prrafos precedent es se pue-
de combinar para formar estructuras compuestas. La arquitectura global de una W
App puede ser jerrquica, pero part e de la estructura puede mostrar caractersti
lineales, mientras que otra parte puede estar en red. La meta para el diseador
quitectnico es emparejar la estructura WebApp con el contenido que se present
y el procesami ent o que se llevar a cabo.
19.6.2 Arquitectura de WebApp
La arquitectura de W ebApp describe una infraestructura que permite a un sistema
aplicacin basados en Web lograr sus objetivos de negocios. Jacyntho y sus col
[JAC02] describen las caractersticas bsicas de esta infraestructura en la forma
guente:
Las apl i caci ones de be n cons t r ui r s e c on el us o de c a pa s en l as que s e t ome n en cuent a l as
di f er ent es pr eocupaci ones ; en par t i cul ar , l os dat os de la apl i caci n s e de be n s e pa r a r de l os
cont eni dos de la pgi na ( nodos de navegaci n) , y di chos cont eni dos , a s u vez, de be n es-
t ar cl ar ament e s e pa r a dos de la apar i enci a y la per cepci n de la i nt er f az (pgi nas).
TM
PDF Editor
Los aut ores sugieren una arquitectura de di seo en tres capas que desacople la
interfaz de la navegacin y del comport ami ent o de la aplicacin, y argument an que
mant ener la separacin de la interfaz, aplicacin y navegacin simplifica la imple-
mentacin y mejora la reutilizacin.
La arquitectura de modelo vista controlador (MVC) [KRA88]11 es uno de varios mo-
delos de infraestructura WebApp sugeridos para desacoplar la interfaz del usuario de
V E la funcionalidad y el contenido de informacin de la WebApp. El modelo (a veces 11a-
MC mado "objeto modelo") contiene t odo el contenido especfico de la aplicacin y la l-
terfaz gica de procesamiento, e incluye todos los objetos de contenido, el acceso a fuent es
de dat os/ i nformaci n externas y toda la funcionalidad de procesami ent o que son es-
WebApp pecficos de la aplicacin. La vista contiene t odas las funciones especficas de la in-
terfaz y habilita la presentacin del contenido y la lgica de procesamiento, e inclu-
ye t odos los objetos de contenido, acceso a fuent es de dat os/ i nformaci n externas
y a toda la funcionalidad de procesami ent o requerida por el usuario final. El contro-
lador gestiona el acceso al modelo y a la vista y coordina el flujo de dat os ent re ellos.
En una WebApp, "la vista la actualiza el controlador con dat os provenientes del mo-
delo con base en la entrada del usuario" [WMT02], En la figura 19.9 se muestra una
representacin esquemtica de la arquitectura MVC.
En referencia a la figura, las solicitudes o dat os del usuario se manej an mediante
el controlador. ste tambin selecciona el objeto vista que es aplicable con base en
la solicitud del usuario. Una vez que se determina el tipo de solicitud, se transmite
una solicitud de comport ami ent o al modelo, que implementa la funcionalidad o re-
cupera el contenido requerido para acomodar la solicitud. El objeto modelo puede
tener acceso a dat os al macenados en una base de dat os corporativa, como parte de
11 Se debe dest acar que MVC es en realidad un pat rn de di seo arqui t ect ni co desarrol l ado por el am
bi ent e Smalltalk (vase ht t p: / / www. cet us-l i nks. org oc_sm.alltalk html) y se puede usar para cual
quier aplicacin interactiva.
TM
PDF Editor
KM La a r qui t e ct ur a MV C ( a d a p t a d a d e [ J AC02] ) .
un al macn de dat os local o como una coleccin de archi vos i ndependi ent es
dat os que desarrolla el model o debe format earl os y or gani zados el obj et o vista a m
cuado y luego transmitirlo del servidor de la aplicacin de vuelta al navegador b a s a
do en el cliente para que se despliegue en la mqui na de st e.
En muchos casos, la arquitectura de WebApp se define dent ro del cont ext o
ambi ent e de desarrol l o en el que la aplicacin habr de i mpl ement arse (por ej emr-i J
ASP.net, JWAA o J2EE). El lector i nt eresado debe ver [FOW03] para una e xpos i a i
ulterior acerca de los ambi ent es de desarrol l o moder nos y de su papel en el disc-i^
de las arqui t ect uras de apl i caci ones Web.
1 9 . 7 DI S E O DE NAVEGACI N
Una vez establecida la arquitectura de WebApp y la identificacin de los compore
t es (pginas, guiones, applets y ot r as funci ones de procesami ent o), el diseador de
be definir las rutas de navegaci n que habiliten para los usuari os el acceso al c
nido y las funci ones de la WebApp. Para lograr est o el di seador debe 1) i denf
la semnt i ca de navegaci n para di ferent es usuari os del sitio y 2) definir la m
ca (sintaxis) que logra la navegaci n.
"Slo espera, Gretel, hasta que la luna se eleve, entontes veremos los trozos de pan que he desparramado, ellos nos
mostrarn de nuevo el camino a tasa."
To m a do de H a n s e l y
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PARA APLI CACI ONES WEB
591
IVE
describe los
de
: paro cada
350. En
.laUSN
cmo un actor
- entre los
3e contenido o
dla
19.7.1 Semntica de navegacin
Al igual que muchas actividades de ingeniera Web, el diseo de navegacin comien-
za con una consideracin de la jerarqua de usuario y los casos de uso relacionados
(captulo 18) desarrollados para cada categora de usuario (actor). Cada actor puede
usar la WebApp de manera un poco diferente y, por tanto, tener diferentes requisitos
de navegacin. Adems, los casos de uso desarrollados para cada actor definirn un
conj unt o de clases que abarcan uno o ms objetos de contenido o funciones de la
WebApp. Conforme cada usuario interacta con la WebApp, encuent ra una serie de
unidades semnticas de navegacin (USN), "un conjunto de estructuras de informa-
cin y navegacin relacionadas que colaboran en el cumplimiento de un subconj un-
to de requisitos de usuario relacionados" [CAC02].
Gnaho y Larcher [GNA99] describen la USN en la forma siguiente:
La es t r uct ur a de una USN es t c ompue s t a de un c onj unt o de s ubes t r uct ur as de navega-
ci n que se l l amar n formas de navegacin (FdN). Una FdN r epr es ent a la mej or f or ma o
r ut a de navegaci n par a l os us uar i os con ci er t os perfi l es pa r a l ogr ar s u met a o s ubme t a
de s e a da . En cons ecuenci a, el c onc e pt o de FdN es t as oci ado con el concept o de Perfil de
Usuari o.
La est r uct ur a de una FdN est i nt egr ada con un c onj unt o de nodos de navegacin (NN)
r el evant es c one c t a dos por v nculos de navegacin, que en oc a s i one s i ncl uyen ot r as FdN.
Est o si gni fi ca que l as FdN pueden, en s mi s ma s , s er a gr e ga da s pa r a f or mar una FdN de
nivel super i or , o pueden ani dar s e en cual qui er pr of undi dad.
Par a i l ust rar el desar r ol l o de una FdN, cons i dr es e el c a s o de us o seleccionar compo-
nentes HogarS eguro descr i t o en la secci n 18.1.2 y que s e r epr oduce a cont i nuaci n:
Ca s o d e us o : seleccionar componentes HogarS eguro
Ent onces la WebApp r e c ome nda r c ompone nt e s de pr oduct o (por ej empl o, panel es de
cont r ol , s ens or es , cmar as ) y ot r as car act er st i cas (por ej empl o, f unci onal i dad ba s a da en
PC i mpl ement ada en s of t war e) pa r a cada habi t aci n y la ent r ada ext er i or . Si el us uar i o
solicita opci ones , la WebApp l as pr opor ci onar si exi st en. El us uar i o obt endr i nf or ma-
ci n descr i pt i va y de pr eci os par a cada c ompone nt e de pr oduct o. La WebApp cr ear y
mos t r ar una f act ur a de mat er i al es c onf or me s e sel ecci onen var i os c ompone nt e s . El
us uar i o t ambi n podr nombr a r la f act ur a de mat er i al es y guar dar l a pa r a r ef er enci a f ut u-
r a ( vase cas o de uso: guardar configuracin) .
Los artculos subrayados en la descripcin del caso de uso representan clases y ob-
jetos de contenido que sern incorporados en una o ms FdN que permitirn a un
nuevo cliente realizar el escenario descrito en el caso de uso seleccionar componen-
tes HogarS eguro.
La figura 19.10 bosqueja un anlisis semntico parcial de la navegacin que im-
plica el caso de uso seleccionar componentes HogarS eguro. Con la aplicacin de la
terminologa introducida anteriormente, la figura tambin representa una FdN para
la WebApp HogarSegurolnc.com. Se muestran importantes problemas en las clases
de dominio junto con objetos de contenido seleccionados (en este caso, el paquet e
TM
PDF Editor
v ncul o de navegaci n *I
recomendar componenle(s) ComponentedeProducto
Habitacin
vi ncul o de navegaci n
\ regresar a Habitacin
comprar ComponentedeProducto
inculo de navegaci n
mostrar descripcin
FacturaDeMateriales
v ncul o de na ve ga c i n
ver FacturaDeMateriales
DescripcinDeComponente
Descripcin DeMarketing
fotografa
DescripcinTcnica
esquema
Creacin de una USN.
v ncul o de navegaci n
solicitar alternativa
v ncul o de navegaci n
seleccionar Habitacin
mostrar ComponentedeProducto
v ncul o de na ve ga c i n
comprar ComponentedeProducto
"El problema de ta navegacin en el sitio Web es conceptual, tcnico, espacial, filosfico y logstico. Consecuentemente
los soluciones tienden a pedir combinaciones de arte, ciencia y psicologa organizacional improvisadas y complejos.'
TimHorgai
19.7.2 Sintaxis de navegacin
Conforme el diseo se lleva a cabo se define la mecnica de navegacin. Entre ir J
chas posibles opciones estn:
V nculo de navegacin individual: vnculos basados en texto, iconos, botones t j
interruptores, y met foras grficas.
de objetos de contenido llamado Des cr i pci nComp, un atributo de la clase Com-
ponent edePr oduct o) . Dichos artculos son nodos de navegacin. Cada una de l a s
flechas representa un vnculo de navegacin12 y est etiquetado con la accin quel
inicia el uso que causa que el vnculo ocurra.
El diseador de la WebApp crea una unidad semntica de navegacin (USN) paral
cada caso de uso asoci ado con cada papel de usuario [GNA99]. Por ejemplo, u d
cl i ent e nue vo (figura 18.1) puede tener tres diferentes casos de uso, y t odos res j l
tan en acceso a diferente informacin y funciones de la WebApp. Para cada meta sel
crea una USN.
Durante las et apas iniciales del diseo de navegacin se valora la arquitectura d a
contenido de la WebApp para determinar una o ms FdN para cada caso de uso. C
mo se anot anteriormente, una FdN identifica los nodos de navegacin (por ejeT-J
po, contenido) y los vnculos que permiten la navegacin ent re ellos. Entonces . a l
FdN se organizan en USN.
12 Eri ocasi ones, a st os se les conoce como v nculos semnticos de navegacin (VSN) [CAC02]
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PARA APUCACI ONES WEB 593
i d las
l frise
5 *
r "mortal
no
*
Barra de navegacin horizontal: lista de las principales cat egor as de cont e-
ni do o funci onal es en una barra que cont i ene vnculos adecuados. En general,
se menci onan entre cuat ro y siete categoras.
Columna de navegacin vertical: 1) lista de las principales cat egor as de cont e-
ni do o funci onal es, o 2) lista de vi rt ual ment e todos los principales obj et os de
cont eni do dent ro de la WebApp. Si se elige la segunda opcin, tales col umnas
de navegaci n se pueden "expandir" para present ar obj et os de cont eni do co-
mo parte de una jerarqua.
Pesta as: una met fora que no es ms que una variacin de la barra o col um-
na de navegaci n, que represent a las cat egor as de cont eni do o funci onal es
como mar cas que se sel ecci onan cuando se requiere un vnculo.
Mapas de sitio: proporci onan una tabla de cont eni do incluyente para la nave-
gacin haci a t odos los obj et os de cont eni do y funcionalidad cont eni dos en la
WebApp.
Adems de elegir los mecani smos de navegaci n, el di seador t ambi n debe est a-
blecer convenci ones y auxiliares de navegaci n adecuados. Por ejemplo, i conos y
vnculos grficos que deben parecer "oprimibles" medi ant e el bi sel ado de los bordes
par a que la i magen t enga una apari enci a tridimensional. Debe di sear ret roal i men-
tacin visual o de audi o para ofrecer al usuari o un indicador de que ha elegido una
opcin de navegaci n. En la navegaci n basada en texto debe usarse color para in-
dicar los vnculos de navegacin y proporcionar un indicador de los vnculos ya reco-
rridos. stas son slo al gunas de las docenas de convenci ones de di seo que hacen la
navegaci n ami gabl e al usuario.
Las moder nas aplicaciones Web ent regan funci ones de pr ocesami ent o cada vez ms
el aboradas que 1) realizan pr ocesami ent o localizado para generar capacidad de
cont eni do y navegaci n en una forma di nmi ca; 2) ofrecen capaci dades de compu-
tacin o procesami ent o de dat os que son adecuadas para el domi ni o de negoci os de
la WebApp; 3) proporci onan cuest i onami ent os y acceso sofi st i cados a bases de da-
tos, 4) est abl ecen i nt erfases de dat os con si st emas corporat i vos externos. Para lograr
est as (y muchas otras) capaci dades, el ingeniero Web debe di sear y construir com-
ponent es de pr ogr ama que sean idnticos en forma a los component es de soft ware
para el sof t war e convenci onal .
En el captulo 11 se consi dera con cierto detalle el di seo al nivel de componen-
tes. Los mt odos de di seo est udi ados en el captulo 11 se aplican a los component es
WebApp con poca, si acaso, modificacin. El ambi ent e de i mpl ement aci n, los len-
guaj es de programaci n y los pat r ones de reutilizacin, mar cos de t rabaj o y sof t wa-
re pueden variar un poco, per o el enfoque de di seo global per manece igual.
TM
PDF Editor
5 9 4 PAUTE TRES APLICACIN DE LA INGENIERA WEB
1 9 . 9 P ATRONES DE DI SEO HI PERMEDI A
Los pat r ones de di seo apl i cados en ia ingeniera Web abar can dos gr andes clasesJ
1) patrones de dise o gen rico que son aplicables a t odos los tipos de soft ware lp:rl
ej empl o, [BUS96] y |GAM95]) y 2) patrones de dise o hipermedia que son especficcsl
de las WebApp. En el captulo 9 se trataron los pat r ones de di seo genrico. A tra-l
vs de Internet se puede t ener acceso a varios cat l ogos y al macenes de pat rones o d
hipermedia. 13
"Cada potrn es una regla de tres partes que expresa una relacin entre cierto contexto, un problema y una solucin
Ch r i s t o p h e r Al e x a n de r
L_ i : '' " riir; " _3|
Como se apunt ant es en est e libro, los pat rones de di seo son un enfoque genr -
co para resolver algn pequeo probl ema de di seo que se puede adapt ar a una va-
riedad mucho ms amplia de probl emas especficos. En el cont ext o de los si st ema; |
basados en Web, Germn y Cowan [GER001 sugi eren las si gui ent es cat egor as de pa-1
trones:
Pa t r o n e s a r q ui t e c t ni c os . Estos pat r ones auxilian en el di seo del cont eni do y s
arqui t ect ura de la WebApp. Las secci ones 19.6.1 y 19.6.2 pr esent an pat r ones arqui-
t ect ni cos para el cont eni do y la arqui t ect ura de la WebApp. Adems, est n disponi-
bles muchos pat rones arquitectnicos rel aci onados (por ejemplo, Java Blueprints e- j
j ava. sun. com/ bl uepri nt s/ ) para los ingenieros Web que deben di sear WebApps en
una diversidad de domi ni os de negoci os.
Pa t r o n e s de c ons t r uc c i n de c o mp o n e n t e s . Estos pat r ones recomi endan mto-
dos para combi nar component es WebApp (por ejemplo, obj et os de cont eni do, fur I
*
ciones) en component es compuest os. Cuando se requiere la funci onal i dad de proce-l
Sarniento de dat os en una WebApp, son aplicables los pat r ones de di seo arquitec-
tnico y al nivel de component e que proponen [BUS96], 1GAM95] y otros.
Pa t r o n e s d e na ve ga c i n. Estos pat rones auxilian en el di seo de USN, vnculos tie
navegaci n y el flujo global de navegaci n de la WebApp.
Pa t r o n e s de p r e s e n t a c i n . Estos pat r ones auxilian en la present aci n del conte-
nido como se present a al usuari o va la interfaz correspondi ent e. Los pat r ones en es-
ta categora abordan cmo organi zar las funci ones de control de la interfaz del usua-
rio para una mej or facilidad de uso; cmo most rar la relacin ent re una accin de la
interfaz y los obj et os de cont eni do que afecta; cmo est abl ecer j erarqu as de conte-
nido efectivas; y muchas otras.
Pa t r o n e s d e i nt e r a c c i n c o mp o r t a mi e n t o / u s u a r i o . Estos pat r ones auxilian en
el di seo de la interaccin usuari o-mqui na. Los pat r ones en est a categora abordan
13 Vase la barra lateral al final de est a seccin.
TM
PDF Editor
cmo la interfaz informa al usuario de las consecuencias de una accin especfica; c-
mo un usuario expande el cont eni do con base en el contexto de uso y sus deseos;
cmo describir mejor el destino que implica un vnculo; cmo informar al usuario
acerca del est ado de una interaccin en marcha y otros.
Las fuent es de informacin acerca de los pat rones de diseo hipermedia se han
expandido en forma sustancial en aos recientes. Los lectores i nt eresados deben
consultar [GAR97], [PER991 y [GEROO],
Almacenes de patrones de dise o hipermedia
El sitio Web lAWiki (http://iowiki. net/Website-
Patterns) es un espaci o de discusin conjunto
l nformacin de los arquitectos y que contiene muchos
i tiles. Entre ellos estn vnculos a varios catlogos
es de patrones hipermedia tiles. Estn represen-
; entos de patrones de diseo:
n de p a t r o n e s de di s e o h i p e r m e di a
' www.designpattern.lu.unisi.ch/
l i o n Pa t t e r n s de To m Er i ck s o n
, ' www.pliant.org/personal/Tom__Erickson/lnterac-
ns.html
e s de di s e o W e b de Ma r t i jn va n W e l i e
' www. wel i e. com/ pat t erns/
Me jo r a de l o s s i s t e m a s de i n f o r m a ci n W e b
co n p a t r o n e s de n a ve g a ci n
ht t p: / / www8. org/ w8-papers/ 5b-hyper1ext -medi a/ i mpro-
ving/improving.html
Un p a t r n de l e n g ua j e HTML 2. 0
ht t p: / / www. anamorph. com/ docs/ pat t erns/ defaul t . ht ml
Te r r e n o co m n
http://www.mit.edu/~itidwell/interaction_patterns.html
Pa t r o n e s p a r a s i t i o s W e b p e r s o n a l e s
http:/ / www. rdrop. com/ --half/ Creations/ WriHngs/ Web.
patterns/index.html
In di ce de l e n g ua j e s p a t r n
ht t p: / / www. es. brown. edu/ ~rms/ l nformat i onSt ruct ures/
Indexing/Overview.html
DO A OBJETOS ( M D H O O )
Durante las pasadas dcadas se propusieron varios mt odos de diseo para aplica-
ci ones Web. A la fecha, ningn mtodo es el domi nant e. En esta seccin se presen-
ta un breve panor ama de uno de los mt odos de diseo WebApp ms ampl i ament e
analizados: MDHOO.H
El m todo de dise o hipermedia orientado a objetos (MDHOO) lo propusieron origi-
nalmente Daniel Schwabe y sus colegas [SCH95, SCH98J. El MDHOO est compuest o
de cuat ro diferentes actividades de diseo: diseo conceptual, diseo de navegacin,
diseo abstracto de la interfaz e implementacin. En la figura 19.11 se muestra un
resumen de est as actividades de diseo, y en las secci ones que siguen se discuten
brevement e.
19.10.1 Diseo conceptual por el MDHOO
El dise o conceptual medi ant e el MDHOO crea una representacin de los subsiste-
mas, clases y relaciones que definen el domi ni o de aplicacin para la WebApp. Se
14 Koch [KOC99] ha desarrollado una amplia compar a; : - de los ciez mtodos de diseo hipermedia.
TM
PDF Editor
596 C A P T U L O 1 9 MODELADO DE DISEO PARA APLI CACI ONES WEB
Re s um e n de l m t o do MD H OO ( a d a p t a d o d e [SCH 95]).
T ~

r B
Diseo conceptual Diseo de navegaci n
Diseo abst ract o
de la interfaz Implementacin
Productos de t r abaj o
Cl ases, subsistemas,
relaciones, atributos
Nodos, vnculos,
estructuras
de acceso, contextos
de navegaci n,
transformaciones
de navegaci n
Obj et os abst ract os
de la interfaz, | | -
respuest as a eventos
externos,
t ransformaci ones
WebApp
ej ecut abl e
Mecani smos de di seo
Clasificacin,
composicin,
agr egaci n,
general i zaci n,
especi al i zaci n
Correlacin entre
obj et os concept al es
y de navegaci n
Correlacin entre
obj et os de
navegaci n
y perceptibles V.
Recurso
pr opor ci onado
por ambi ent e
objetivo
Preocupaci ones de di seo
Model ado de la
semntica del
dominio
de apl i caci n
Toma en cuent a
el perfil del usuario
y la t ar ea. Resalta los
aspect os cognitivos.
Model ado de los
obj et os perceptibles,
implementacin de las
met foras el egi das.
Descripcin de la
interfaz par a los
obj et os de navegaci n
Exactitud;
desempeo
de la apl i cado'
integridad
puede usar15 UML para crear diagramas de clase adecuados, agregados y represen-
taciones de clase compuestas, diagramas de colaboracin y otra informacin que
describe el dominio de la aplicacin (vase la Parte 2 de este libro para ms detalles-.
Como un ejemplo simple de diseo conceptual del MDHOO, considrese de nue-
vo la aplicacin de comercio electrnico de HogarSegurolnc.com. En la figura 19.12
se muestra un "esquema conceptual" parcial para HogarSeguroInc.com. Los diagra-
mas de clase, agregados e informacin relacionada desarrollados como parte de.
anlisis de la WebApp se reutilizan durante el diseo conceptual para representar re-
laciones entre clases.
19.10.2 Diseo de navegacin medi ant e el MDHOO
El dise o de navegacin identifica un conjunto de "objetos" que se derivan de las cla-
ses definidas en el diseo conceptual. Se define una serie de "clases de navegacin'
o "nodos" para encapsular dichos objetos. Se puede usar UML para crear casos ct
uso adecuados, grficos de estado y di agramas de secuencia, todos ellos auxilian al
diseador a comprender mejor los requisitos de navegacin. Adems, es posib.r
aplicar los pat rones de diseo para el diseo de navegacin conforme el diseo se
desarrolle. El MDHOO utiliza un conjunto predefinido de clases de navegacin: no-
15 El MDHOO no prescribe una notacin especfica; sin embargo, el uso de UML e s comn cuando se
aplica est e mt odo.
TM
PDF Editor
pa r t e Nme r o
pa r f e Nombr e
par l eTi po
descr i pci n
pr eci o
Fact ur aDeMat er i al es
Ident i fi cado'
ListaFdM
Nmer oAr t cui os
precioTotal
Habi t aci n
cr ear NuevoAr t i cul o{)
obt ener Des cr i pci n( )
obt ener Es pec cni ca
Kabi t aci nNombr e
di mensi ones
ext eri orVent anas
ext eri orPuert as
a gr e ga r Ent r a da j ]
nombr {}
cal cul orPreci o(
Art cul oFdM
c a nt i da d
par t eNmer o
pa r t e Na mbr e
par t eT po
pr eci o
cliente contina seleccin
componentes
cliente
solicita compra
a gr e ga r a Ut a l j
bor r a r de l i s t a | )
obt ener Si gui ent e
Ef t f r odol i st a( )
Sensor C ma r a Panel Cont r ol Ca r a c t SoRwa r e
pe di doNme r o
ci i ent el nfo
f acl ur aDeMat er i al es
e mba r que l nf o
cobr an zol nf o
CAP T UL O 1 9 MODELADO DE DISEO PAEA APLICACIONES WEB 5 9 7
Es que m a c o n c e p t ua l p a r c i a l p a r a H o g a r Se g ur o I n c . c o m .
cliente selecciona componente
recomendacin de componente
solicitada
dos, vnculos, ancl as y estructuras de acceso [SCH98]. Las estructuras de acceso son
ms elaboradas e incluyen mecani smos como un ndice de la WebApp, un mapa de
sitio o un paseo guiado.
Una vez definidas l as clases de navegacin, el MDHOO "estructura el espacio de
navegacin mediante el agrupamiento de los objetos de navegacin en conj unt os
llamados contextos" [SCH98], Schwabe describe un contexto en los trminos siguien-
tes:
Cada defi ni ci n de cont ext o i ncl uye, a d e m s de l os e l e me nt os q u e es t n i ncl ui dos en l,
la especi f i caci n de su es t r uct ur a de navegaci n i nt er na, un punt o de ent r ada, rest ri cci o-
ne s de a c c e s o en t r mi nos de cl as es de us uar i o y oper aci ones , y una es t r uct ur a de a c c e -
s o as oci ada.
Se desar r ol l a una pl ant i l l a de cont ext o ( anl oga a l as t ar j et as CRC e s t udi a da s e n el ca-
p t ul o 8) y se empl ea par a r ast r ear l os r equi si t os de navegaci n de cada cat egor a de us ua-
ri o a t r avs de var i os cont ext os def i ni dos en el MDHOO. Al hacer es t o s ur gen r ut as
espec f i cas de navegaci n (que s e l l amar on FdN en la secci n 19.7.1).
19.10.3 Diseo abstracto de la interfaz e implementacin
La actividad de dise o abstracto de la interfaz especifica los objetos de la interfaz que
el usuario ve conforme interacta con la WebApp. Un modelo formal de objetos de
la interfaz, llamado visin abstracta de datos (VADi se utiliza para representar la re-
TM
PDF Editor
Iacin entre objetos de la interfaz y objetos de navegacin, y las caractersticas
comport ami ent o de los objetos de la interfaz.
El modelo VAD define una "plantilla esttica" [SCH98] que representa la metfo
de la interfaz e incluye una representacin de los objetos de navegacin dentro i
la interfaz y la especificacin de los objetos de la interfaz (por ejemplo, mens,
tones, iconos) que auxilian en la navegacin y la interaccin. Adems, el mode |
VAD contiene un component e relacionado con el comport ami ent o (similar al diagr;
ma de est ado UML) que indica cmo los event os externos "disparan la navegacin
qu transformaciones de la interfaz ocurren cuando el usuario interacta con la ap
cacin" [SCHOIJ. Una exposicin detallada del VAD el lector interesado puede halla-
la en [SCH98] y [SCH01],
La actividad implementacin del MDHOO representa una interaccin de dis
que es especfica al ambiente en el que operar la WebApp. Las clases, la nave
cin y la interfaz son caracterizadas en una forma que puede construirse para el;
biente cliente/servidor, sistemas operativos, soft ware de soporte, lenguajes de
gramacin y otras caractersticas del ent orno relevantes respecto del problema.
Las mtricas de diseo se deben caracterizar en una forma que proporcione a lo; :
genieros Web un indicador de calidad en tiempo real. En esencia, un conjunto til i
medidas y mtricas ofrece respuest as cuantitativas a las siguientes preguntas:
La interfaz del usuario promueve la facilidad de uso?
La esttica de la WebApp es apropiada para el dominio de la aplicacin y
confortable para el usuario?
El contenido est diseado en una forma que proporciona la mayor informa-1
cin con el menor esfuerzo?
La navegacin es eficiente y directa?
La arquitectura de la WebApp se ha di seado para acomodar las met as y <
jetivos especiales de los usuarios de la WebApp, la estructura de contenido y
funcionalidad, y el flujo de navegacin requerido para usar el sistema de ma
era efectiva?
Los component es estn diseados en una forma que reduce la complejidad
de procedimientos y aument a la exactitud, la confiabilidad y el desempeo'
En la actualidad, cada una de est as pregunt as se puede abordar de manera cua:
tiva,16 pero todava no existe un conj unt o validado de mtricas que ofrezcan
puest as cuantitativas.
16 Vase el cap t ul o 16 (seccin 16.4) y la seccin 19.1 l para una exposicin cualitativa de la ca
de una WebApp
TM
PDF Editor
C A P I T U L O 1 9 MODELADO DE DISEO PAEA APLICACIONES WEB
599
Las mtricas para el diseo de WebApps est n en desarrollo y pocas se han vali-
dado ampl i ament e. El lector i nt eresado debera consultar [IVOOl] y [MENO!] para
una muest ra de las mtricas propuest as para el diseo de WebApps.
M tricas t cnicas para W ebApps
Ob j e t i vo : Apoyar a los ingenieros Web en el
desarrollo de mtricas WebApp significativas
ofrezcan una visin acerca de la calidad global de
aplicacin.
" i i ca : Las herramientas mecnicas varan.
- m i e n t a s r e p r e s e n t a t i va s 1 7
-hanic Toots, desarrollada por Netmechanic (www.
-etmechanic.com), es una coleccin de herramientas
que ayudan a mejorar el desempeo de un sitio Web;
se enfoca sobre los temas especficos de la implementa-
cin.
W eb Metrics Teslbed, desarrollado por The National
-istitute of Standards and Technology (zing.ncsl.nist.
gov/ WebTools/ ), abar ca la siguiente coleccin de he-
rramientas tiles que estn disponibles par a descargar-
We b S lalic Analyzer Tool W ebS ATj: verifica el HTML de
la pgi na web contra los lineamientos de facilidad de
uso tpicos.
W eb Colegory Anolysis Tool ( W ebCAT) : permite al inge-
niero de facilidad de uso construir y dirigir un anlisis
de categora Web.
We b Variable Instrumenter Program ( W ebVIP) : instrumen-
ta un sitio Web par a capturar un registro de interac-
cin de usuario.
Framew ork for Logging Usability Dala fFLUD) : implemen-
to un formateador y anal i zador gramatical de archivos
par a representar los registros de interaccin de usua-
rio.
VisVIP Tool: produce una visualizacin tridimensional de
las rutas de navegacin del usuario a travs de un sitio
Web.
TreeDec: agr ega auxiliares de navegacin a las pgi nas
de un sitio Web.
La calidad de una WebApp definida en trminos de facilidad de uso, funcionalidad,
confiabilidad, eficiencia, facilidad de mantenimiento, seguridad, escalabilidad y tiem-
po en el mercado se introduce durant e el diseo. Para lograr dichos atributos de
calidad, un buen diseo WebApp debe posser simplicidad, consistencia, identidad, ro-
bustez, navegabilidad y apariencia visual.
El diseo de la interfaz describe la estructura y organizacin de la interfaz del
usuario. Incluye una representacin de la plantilla de pantalla, una definicin de los
modos de interaccin y una descripcin de los mecani smos de navegacin.
El diseo esttico, tambin llamado diseo grfico, describe la "apariencia y la
percepcin" de la WebApp e incluye esquemas de color, plantilla geomtrica, tama-
o de texto, fuente y ubicacin, el uso de grficos y decisiones estticas relaciona
das. Un conj unt o de lineamientos de diseo grfico proporciona la base para un en-
foque de diseo.
17 Las her r ami ent as anot adas son una muest ra de est a categora
TM
PDF Editor
El diseo de contenido define la plantilla, la estructura y el subrayado de todo ei
contenido que se presenta como parte de la WebApp; adems, establece las relacio-
nes ent re objetos de contenido. El diseo de contenido comienza con la representa-
cin de los objetos de contenido, sus asociaciones y relaciones. Un conjunto de cor-
sideraciones el ement al es establece las bases para el diseo de navegacin.
El diseo de arquitectura identifica la estructura hipermedia global para la Web
App y abarca tanto la arquitectura de contenido como la de WebApp. Los estilos ar
quitectnicos para el contenido incluyen estructuras lineal, en retcula, jerrquica >
en red. La arquitectura de la WebApp describe una infraestructura que permite a un
sistema o aplicacin basado en Web lograr sus objetivos de negocios.
El diseo de navegacin representa el flujo de navegacin entre los objetos ce
contenido y para todas las funciones de la WebApp. La navegacin se define al des
cribir un conjunto de unidades semnt i cas de navegacin. Cada unidad est coir
puesta de formas de navegacin y de vnculos y nodos de navegacin. Los mecani-
mos de sintaxis de navegacin se aplican para afectar la navegacin descrita corr
parte de la semntica.
El diseo de component es desarrolla la lgica de procesami ent o detallada que se
requiere para implementar los component es funcionales de la WebApp. Las tcnicas
de diseo descritas en el captulo 11 se aplican a la ingeniera de componentes Web
App.
Los pat rones para el diseo de WebApps abarcan patrones de diseo genric:
que se aplican a todos los tipos de soft ware y pat rones hipermedia especialmente re
levantes para las WebApp, Se han propuesto pat rones de diseo arquitectnico, de
navegacin, de component es, de presentacin y de comport ami ent o/ usuari o.
El mt odo de diseo hipermedia orientado a objetos (MDHOO) es uno de varic?
mt odos propuestos para el diseo WebApp. El MDHOO sugiere un proceso de dise-
o que incluye diseo conceptual, diseo de navegacin, diseo abstracto de la ir-
terfaz e implementacin.
Las mtricas de diseo para ingeniera Web estn en desarrollo y todava tienen
que validarse por completo. Sin embargo, se han propuesto varias medidas y mtri-
cas para abordar cada una de las actividades de diseo reanalizadas en este captulo
[AME96] Ament o, B. e al. , "Fitt's Law", CS 5724: Models and Theories of Human Computer Inte
ractions, Virginia Tech, 1996, di sponi bl e en ht t p: / / ei . cs . vt . edu/ ~cs 5724/ gl / .
[BAG01] Bagger man, L., y S. Bowman, W eb Design That W ork s, Rockport Publishers, 2001.
[BUS96] Buschmann, F. e al. , Pattern-Oriented S oftw are Architecture, Wiley, 1996.
(CAC02] Cacher o, C. et al. , "Concept ual Navigation Analysis: a Devi ce and Pl at form Independen!
Navigation Specification", Proc. 2nd Intl. W ork shop on W eb-Or ented Technology, j uni o de
2002, s e puede descar gar de www. ds i c. upv. es / - wes t / i wwos t 02/ paper s / cacher o. pdf .
[CLOOl] Cloninger, C., Fresh S tyles for W eb Designers, New Riders Publishing, 2001.
[D1X99] Dix, A., "Design of User Interfaces for t he Web", Proc. OfUser Interfaces to Data S ystems Con-
ference, sept i embre de 1999, se puede descargar de ht t p: / / www. comp. l ancs. ac. uk/ comput i ng/
us er s / di xa/ t opi cs / webar ch/ .
TM
PDF Editor
C A P T U L O 1 9 MODELADO DE DISEO PAEA APLICACIONES WEB 601
(FIT54] Fitts, P., "The Informat i on Capaci t y of t he Human Motor Syst em in Controlling t he Am-
piitude of Movement ", en Journal of Experimental Psychology, vol. 47, 1954, pp. 381-391.
[FOW03] Fowler, M. et al. , Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.
[GAL02) Galitz, W., The Essential Guide to User Interface Design, Wiley, 2002.
1GAM95] Gamma, E. etal. , Design Pattems, Addison-Wesley, 1995.
[GAR97] Garrido, A., G. Rossi y D. Schwabe, "Pat t ems Syst ems for Hypermedia", 1997, se puede
descar gar de www. i nf . puc- r i o. br / - schwabe/ paper s/ Pl oP97. pdf .
[GEROO] Ger mn, D. y D. Cowan, "Toward a Unified Cat al og of Hypermedi a Desi gn Pat t ems",
Proc. 33rd Haw aii Intl. Conf. on S ystem S ciences, IEEE, vol. 6, Maui, Hawaii, j uni o de 2000, se
puede descar gar de www. t ur i ngmachi ne. or g/ - - dmg/ r esear ch/ paper s/ dmg_hi css2000. pdf .
[GNA99] Gnaho, C. y F. Larcher, "A User-Cent ered Met hodol ogy for Compl ex and Cust omi zabl e
Web Engineering", Proc. Ist ICS E W ork shop on W eb Engineering, ACM, Los Angel es, mayo de
1999.
[HEI02] Heinicke, E Layout: Fast S olutions for Hands-On Design, Rockport Publishers, 2002.
[IVOOl] Ivory, M., R. Sinha y M. Hearst, "Empirically Validated Web Page Design Metrics", ACM
S1GCHI ' 01, Seattle, WA, abril de 2001, disponible en ht t p: / / www. r ashmi si nha. com/ ar t i cl es/
WebTangoCHIOl .html.
[IAC02] Jacynt ho, D., D. Schwabe y G. Rossi, "An Architecture for Structuring Compl ex Web Ap-
plications", 2002, di sponi bl e en ht t p: / / www2002. or g/ CDROM/ al t emat e/ 478/ .
[KAI02] Kaiser, J., "Element of Effective Web Design", About, Inc., 2002, disponible en ht t p: / / web-
desi gn. about . com/ l i br ar y/ weekl y/ aa091998. ht m.
[KAL03] Kal man, S., W eb S ecurity Field Guide, Cisco Press, 2003.
[KOC99] Koch, N., "A Compar at i ve Study of Met hods for Hypermedi a Devel opment ", Technical
Report 9905, Ludwi g-Maxi mi l i ans Universitat, Munich, Al emani a, 1999, se puede descar gar
de h t t p : / / www. d s i c . u p v . e s / ~we s t 2 0 0 1 / i wwo s t 0 l / f i l e s / c o n t r i b u t i o n s / No r a Ko c h / h y p -
dev.pdf.
[KRA88] Krasner, G. y S. Pope, "A Cookbook for Using t he Model-View Controller User Interfa-
ce Paradi gm in Smalltalk-80", Journal of Object-Oriented Programming, vol. I, nm. 3, agos-
t o- sept i embr e de 1988, pp. 26-49.
[LOW981 Lowe, D., y W. Hall (eds.), Hypertext and the W ebAn Engineering Approach, John Wiley
& Sons, 1998.
[MCC01] McClure, S. ]. Scambr ay y G. Kurtz, Hack ing Exposed, McGraw-Hi l l / Osbome, 2001.
[MEN01) Mendes, E N. Mosley y S. Counsell, "Eslimating Design and Aut hori ng Effort", en IEEE
Multimedia, ener o- mar zo de 2001, pp. 50-57.
[MILOO] Miller, E., "The Websi t e Quality Challenge", Sof t war e Research, Inc., 2000, ht t p: / / www.
sof t . com/ eVal i d/ Technol ogy/ Whi t e. Paper s/ websi t e. qual i t y. chal l enge. ht ml .
[NIE96] Nielsen, J. y A. Wagner, "User Int erface Design for t he WWW", Proc. CHI '9 6 Conf. On Hu-
man Factors in Computing S ystems, ACM Press, 1996, pp. 330-331.
[NIEOO] Nielsen, J., Designing W eb Usability, New Riders Publishing, 2000.
[NOR02J Northcutt, S. y J. Novak, N etw ork Intrusin Detection, New Riders Publishing, 2002.
[OFF02) Offutt, J., "Quality Attributes of Web Soft ware Applications", en IEEE S oftw are, mar zo-
abril de 2002, pp. 25-32.
[OLS98] Olsina, L "Building a Web-Based Informat i on Syst em Applying t he Hypermedi a Flexi-
ble Process Model i ng Strategy", Proc. Ist Intl. W ork shop on Hypermedia Development, 1998.
[OLS99] Olsina, L. et al. , "Specifying Quality Charact eri st i cs and At t ri but es for Web Sites", Proc.
Ist ICS E W ork shop on W eb Engineering, ACM, Los ngel es, mayo de 1999.
[PER99] Perzel, K. y D. Kane, "Usability Pat t ems for Appl i cat i ons on t he World Wide Web", 1999,
se puede descar gar de ht t p: / / j er r y. cs . ui uc. edu/ - pl op/ pl op99/ pr oceedi ngs / Kane/ per zel _
kane. pdf.
[POWOO] Powell, T W eb Design, McGraw-Hi l l / Osbome, 2000.
(RASOO] Raskin, J The Humane Interface, Addison-Wesley, 2000.
[RH098] Rho, Y. y T. Gedeon, "Surface St ruct ures in Browsi ng t he Web", Proc. Australasian Com
puter Human Interaction Conference, IEEE, di ci embre de 1998.
[SCH95] Schwabe, D. y G. Rossi, "The Obj ect -Ori ent ed Hypermedi a Desi gn Model", en CACM, vol.
38, nm. 8, agost o de 1995, PP. 45-46.
TM
PDF Editor
[SCH98] Schwabe, D. y G. Rossi, "Devel opi ng Hypermedi a Appl i cat i ons Usi ng OOHDM", Proc
W ork shop on Hypermedia Development Process, Methods and Models, Hypertext '9 8, 1998, se
puede descar gar de ht t p: / / ci t eseer . nj . nec. com/ schwabe98devel opi ng. ht ml .
1SCH01] Schwabe, D., G. Rossi y S. Bar bosa, "Syst emal i c Hypermedi a Application Design Using
OOHDM", 2001, di sponi bl e en ht t p: / / www- di . i ni . puc - r i o. br / ~s c hwa be / HT96WWW,
sect i onl . html.
[TILOO] Tillman, H. N., "Eval uat i ng Quality On t he Net", Babson College, 30 de mayo de 2000, dis-
poni bl e en ht t p: / / www. hopet i l l man. eom/ f i ndqual . ht ml #2
[TOGOI] Tognozzi , B "First Principies", ask TOG, 2001, di sponi bl e en ht t p: / / www. as kt og. com
basi cs/ fi rst Pri nci pl es. hl ml .
[WMT02] Web Mappi ng Test bed TUtorial, 2002, di sponi bl e en ht t p: / / www. we bma ppi ng
or g/ vcgdocument s / vcgTut or i al / .
[ZI1A02] Zhao, H "Fitt' s Law: Model i ng Movement Time in HC1", Theories in Computer Humar.
Interaction, University of Maryland, oct ubr e de 2002, di sponi bl e en ht t p: / / www. cs . umd. edu
cl ass/ f al l 2002/ cmsc838s/ t i chi / f i t t s. ht ml .
19. 1. Por qu el "ideal art st i co" es una filosofa de di seo i nsufi ci ent e cuando se const r uye-
l as WebApps moder nas ? Existe un cas o en el que el ideal art st i co sea la filosofa que debe se
gui rse?
19. 2. En es t e cap t ul o se anal i z una ampl i a vari edad de at ri but os de cal i dad par a las Wer
Apps. Eljanse las t r es que se consi der e c o mo las m s i mpor t ant es y el abr es e un ar gumen: :
que expl i que por qu cada uno debe r esal t ar se en el t r abaj o de di seo de i ngeni er a Web.
19. 3. Agr guense al me nos ci nco pr egunt as adi ci onal es a la "Lista de verificacin de la cal i da:
del di seo de la WebApp" pr es ent ada en una bar r a lateral en la secci n 19.1.1.
19. 4. Revisar los pri nci pi os de di seo de la i nt erfaz de Tognozzi t r at ados en la secci n 19.3.
Consi derar cada pri nci pi o par a una WebApp operat i va con la cual se est fami l i ari zado. Calir
car la WebApp ( sense cal i fi caci ones A, B, C, D o F) en rel aci n con el gr ado en el cual ha : -
gr ado el principio. Explicar la r azn par a cada calificacin.
19. 5. Di sear una i nt erfaz pr ot ot i po par a la WebApp de Hogar Segur ol nc. com. Int nt ese ser ir
novador pero, al mi s mo t i empo, se debe as egur ar que la i nt erfaz se aj ust a a los pri nci pi os
el buen di s eo de la i nt erfaz.
19. 6. Se han encont r ado mecani s mos de cont rol de la i nt erfaz que sean di f er ent es a los a
t ados en la Secci n 19.3.2? Si e s as, descr banse br evement e.
19. 7. El l ect or es el di seador WebApp par a una compa a de e ns e a nz a a larga di st anci a
i nt enci n e s i mpl ement ar un "mot or de apr endi zaj e" bas ado en Int ernet que le permi t i r en"
gar cont eni do del cur s o a los est udi ant es. El mot or de apr endi zaj e of r ece la i nf r aest r uct ur a
sica par a ent r egar cont eni do de apr endi zaj e de cual qui er mat er i a ( di seador es de cont en1
pr epar ar n el cont eni do adecuado) . Desarrl l ese un di seo de i nt erfaz pr ot ot i po par a el m
de apr endi zaj e.
19. 8. Cul es el sitio Web est t i cament e m s agr adabl e que el lector haya ha vi si t ado y por
19. 9. Consi derar el obj et o de cont eni do p e d i d o , gener ado una vez que un usuar i o de Ho
Segur ol nc. com ha compl et ado la sel ecci n de t odos los component es y est listo par a final
su compr a. Desarrol l ar una descri pci n UML de p e d i d o j unt o con t odas l as r epr esent aci ones
di seo apr opi adas.
19. 10. Cul e s la di ferenci a ent r e ar qui t ect ur a de cont eni do y ar qui t ect ur a de WebApp?
19. 11. Reconsi dr ese el "mot or de apr endi zaj e" descri t o en el pr obl ema 19.7, sel ecci nese
ar qui t ect ur a de cont eni do que ser a apr opi ada par a la WebApp. Ccomnt es e por qu s e hizo
cha el ecci n.
TM
PDF Editor
1 9 . 1 2 . Con UML des ar r l l ens e t res o c ua t r o r epr es ent aci ones de di s eo par a obj et os de con-
t eni do que podr an e nc ont r a r s e c onf or me s e di s ea el "mot or de apr endi zaj e" des cr i t o en el pr o-
bl ema 19.7.
1 9 . 1 3 . Hacer un poco de i nvest i gaci n adi ci onal acer ca de la ar qui t ect ur a MVC y deci di r si se-
ria una ar qui t ect ur a WebApp apr opi ada pa r a el " mot or de apr endi zaj e" me nc i ona do en el pr o-
bl ema 19.7.
1 9 . 1 4 . Cul e s la di f er enci a ent r e si nt axi s de navegaci n y s e m nt i c a de navegaci n?
1 9 . 1 5 . Defi ni r dos o t res USN par a la WebApp de Hogar Segur oI nc. com. Describir c a da una con
ci er t o det al l e.
1 9 . 1 6 . Hacer al guna i nvest i gaci n y pr es ent ar a s u cl ase dos o t r es pa t r one s de di s e o hi per-
medi a compl et os .
Aunque s e ha n escr i t o ci ent os de l i bros acer ca del "di seo Web", muy pocos a bor da n al gunos
m t odos t cni cos si gni f i cat i vos par a r eal i zar el t r abaj o de di seo. Cua ndo muc ho, s e pr es ent an
var i os l i ncami ent os t i l es par a el di s eo de la WebApp, e j e mpl os val i osos de p gi na s Web y s e
mues t r a pr ogr amaci n j ava, y se anal i zan l os det al l es t cni cos i mpor t ant es par a i mpl ement ar
WebApps mode r na s . Ent re l os mu c h o s que s e of r ecen en est a cat egor a, val e la pe na cons i de-
rar la di scusi n enci cl opdi ca de Powel l [POWOO], Adems , l os libros de Gal i t z [GAL02], Hei ni c-
ke |HE102], Schmi t t (Designing CS S W eb Pages, New Ri ders Publ i shi ng, 2002), Donnel l y ( Desig-
ning Easy-toUse W ebsitcs, Addi son-Wesl ey, 2001) y Ni el sen [N1E00] pr opor ci onan una gu a til.
La visin gil del di s eo (y ot r os t pi cos) par a WebApps la pr es ent an Wal l ace y s u s col egas
{Extreme Programmingfor W eb Projects, Addi son-Wesl ey, 2003). Conal l en ( Building W eb Applica
tions w ith UML, s e gunda edi ci n, Addi son-Wesl ey, 2002) y Ros enber g y Scot t ( Appf y i ng Use Ca
se Driven Object Modeling w ilh UML, Addi son- Wesl ey, 2001) pr es ent an e j e mpl os det al l ados de
WebApps mode l a da s con la apl i caci n de UML.
Van Duyne y s us col egas ( The Design of S ites: Pattems, Principies and Processes, Addi son- Wes-
ley, 2002) escr i bi er on un libro excel ent e q u e c ubr e l os a s pe c t os m s i mpor t ant es del pr oces o de
di s e o en la i ngeni er a Web. Se cubr en en det al l e l os mode l os de pr oces o de di s eo y l os pat r o-
ne s de di seo. Wodt ke [Information Architecture, New Ri ders Publ i shi ng, 2003), Rosenf el d y Mor-
ville ( Information Architecturefor the W orld W ide W eb, O' Reilly & Associ at es, 2002), y Rei ss ( Prac
tical Information Architecture, Addi son-Wesl ey, 2000) abor dan la ar qui t ect ur a de c ont e ni do y
ot r os t pi cos.
Las t cni cas de di s eo t ambi n s e me nc i ona n en l i bros escr i t os acer ca de a mbi e nt e s de de-
sarrol l o espec fi cos. Los l ect ores i nt er esados deben e xa mi na r libros acer ca de J2EE, Java, ASP.NET,
CSS, XML, Perl y una di ver si dad de apl i caci ones de cr eaci n de WebApps ( Dreamw eaver, Home
Page, Frontpage, GoLive, MacroMedia Flash, etc.) par a c ome nt a r i os de di s eo t i l es.
En Int ernet est di sponi bl e una gr an var i edad de f ue nt e s de i nf or maci n acer ca de di s e o
par a i ngeni er a Web. Una lista act ual i zada de r ef er enci as en la World Wi de Web s e encuent r a en
el si t i o Web de SEPA:
h t t p : / / www. m h h e . c o m / p r e s s m a n .
TM
PDF Editor
C A P I T U L O
CMO PROBAR
APLICACIONES WE B
C O N C E P T O S
CLAVE
caract er st i cas
de er r or 6 0 6
di mensi ones
de calidad 6 0 5
es t r at egi a . . . . 6 0 7
pr uebas
de base de
dat os 6 1 3
de carga 6 3 3
de configuracin 628
de c ont e ni do. . 6 1 2
de desempeo 631
de facilidad
de uso 6 2 0
de i nt erfaz
de usuari o . . 6 1 6
de navegaci n 6 2 5
de nivel de
component es 6 2 3
de pr ueba de com-
patibilidad . . . 6 2 2
de t ensi n . . . 6 3 3
E
xiste una urgencia que siempre permea el proceso de ingeniera Web. Con
forme se dirigen la formulacin, la planeacin, el anlisis, ei diseo y i
construccin, los participantes preocupados acerca de la competencia o
otras WebApps, fustigados por las demandas de los clientes e intranquilos porq _
perdern una vent ana en el mercado presi onan para poner la WebApp en lir.-r
Como consecuenci a, las actividades tcnicas que usual menl e ocurren en las lt
mas et apas del proceso de ingeniera Web, como la prueba de la WebApp, en oc
si ones reciben poca atencin. Esto puede ser un error catastrfico. Para evitar
el equipo de ingeniera Web debe asegurarse de que cada product o de trabajo c
IWeb muest re alta calidad. Wallace y sus colegas [WAL03] advierten est o cuanc
afirman:
Llevar a c a bo la pr ueba n o de be es per ar has t a que t er mi ne el pr oyect o. Comi ence a
pr obar ant es de escri bi r una l nea de cdi go. Pr uebe c ons t a nt e y ef ect i vament e y de-
sar r ol l ar un si t i o Web mu c h o m s dur abl e.
Dado que los modelos de anlisis y diseo no pueden ponerse a prueba en
sentido clsico, el equipo de ingeniera Web debe dirigir revisiones tcnicas 1c
mal es (captulo 26), as como pruebas ejecutables. El objetivo es descubrir y c:
rregir errores ant es de que la WebApp se ponga a disposicin de sus usuarios f
nales.
Qu e s ? El proceso de someter o
prueba la WebApp es una suma de ac-
tividades relacionadas con una sola me-
ta: descubrir errores en el contenido, la
funcin, la facilidad de uso, a navega-
bilidad, el desempeo, la capacidad y la seguridad
de la WebApp. Esto se logra a lo largo de todo el
proceso de ingeniera Web mediante la aplicacin
de una estrategia de prueba que abarca tanto revi-
siones como pruebas ejecutables. :
Qui n l o h a c e ? Los ingenieros Web y otros par-
ticipantes del proyecto (gerentes, clientes, usua-
rios finales) toman parte en el proceso de probar
la WebApp.
Por q u e s i mpor t a nt e ? Si los usuarios fina-
les encuentran errores que afecten su confianza
en la WebApp, se irn a cualquier otra parte
por el contenido y la funcin que necesitan, y la
WebApp fracasar. Por esta razn, los ingenie-
ros Web deben trabajar para eliminar tantos
errores como sea posible antes de que la Web-
App est en linea
Cul es s on l os p a s o s ? El proceso de prueba
de la WebApp comienza al enfocarse sobre
aquellos aspectos de sta que son visibles para
el usuario y procede a probar dicha tecnologa
e infraestructura. La prueba consta de siete eta-
pas: contenido, interfaz, navegacin, compo-
nente, configuracin, desempeo y prueba de
seguridad.
Cul es el producto obtenido? En algunos
casos se produce un plan de prueba de la Web-
App. En todos los casos se desarrolla un conjun-
to de casos prueba para cada etapa de la prue-
604
TM
PDF Editor
C A P T U L O 2 0 CMO PROBAR APLI CACI ONES WEB 605
: c y se conserva un archivo de resultados de
pruebas para uso futuro.
^ r i o p u e d o es t ar s e gur o de q u e lo he
l echo cor r ect ament e? Aunque nunca se
;<jede estar seguro de que han llevado a cabo
: -3s las pruebas que se necesitan, puede tener-
se la seguridad de que la puesta en prueba ha
descubierto errores (y que stos se han corregi-
do). Adems, si se ha establecido un plan de
prueba, puede verificarse para asegurar que se
han realizado todas las pruebas planeadas.
2 0 . 1 PRUEBA DE CONCEPTOS PARA WE BAP P S
En el captulo 13 se seal que la prueba es el proceso de ejercitar al software con
la finalidad de encontrar (y a final de cuentas corregir) errores. Esta filosofa funda-
mental no cambia para las WebApps. De hecho, puesto que los sistemas y aplicaciones
basados en Web residen en una red e interoperan con muchos sistemas operativos
diferentes, navegadores (u otros dispositivos de interfaz como PDA o telfonos celu-
lares), plataformas de hardware, protocolos de comunicaciones y aplicaciones "de
cuarto trasero", la bsqueda de errores representa un desafo significativo para los
ingenieros Web.
La comprensin de los objetivos de las pruebas dentro de un contexto de ingenie-
ra Web requiere considerar las diversas dimensiones de la calidad WebApp.' En el
contexto de esta exposicin se consideran las dimensiones de calidad que son par-
ticularmente relevantes en cualquier debate de las pruebas para el trabajo de inge-
niera Web. Tambin se considera la naturaleza de los errores que se encuentran co-
mo consecuencia de las pruebas, y la estrategia de poner a prueba aplicable para
descubrir dichos errores.
20.1.1 Dimensiones de calidad
La calidad se incorpora en una aplicacin Web como consecuencia de un buen dise-
o. Se evala al aplicar una serie de revisiones tcnicas que valoran varios elemen-
tos del modelo de diseo y al aplicar un proceso de prueba que se trata a lo largo de
este captulo. Tanto las revisiones como las pruebas examinan una o ms de las si-
guientes dimensiones de calidad [MIL00]:
El contenido se evala tanto en el mbito sintctico como semntico. En el
mbito sintctico, la ortografa, la puntuacin y la gramtica se valoran para
los documentos basados en texto. En el mbito semntico se valoran la exac-
titud (de la informacin presentada), la consistencia (a travs de todos los ob-
jetos de contenido y objetos relacionados) y la falta de ambigedad.
La funcin se prueba para descubrir errores que indiquen que no hay concor-
dancia con los requisitos del cliente. Cada funcin de la WebApp se valora en
s e
l a
t r o de l
de un a
y s u
1 En el capitulo 19 t ambi n se consi der la calidad de a WebApp
TM
PDF Editor
6 0 6
cuant o a exactitud, inestabilidad y concordanci a general con los est ndar es de
implementacin apropi ados (por ejemplo, est ndares de l enguaj e Java o XML).
La estructura se valora para asegurarse de que ent rega adecuadament e conte-
nido y funcin de la WebApp, que es extensible y puede sost enerse conforme
se aade nuevo cont eni do o funcionalidad.
La facilidad de uso se prueba para garant i zar que a cada cat egor a de usuario
la soport a la interfaz; puede apr ender y aplicar toda la sintaxis y semnt i ca de
navegaci n requerida.
La navegabiiidad se pone a prueba para garant i zar que toda la sintaxis y se-
mnt i ca de navegaci n se ej ercen para descubrir cualquier error de navega-
cin (por ejemplo, vnculos rot os, vnculos i nadecuados, v ncul os errneos).
El desempe o se prueba en una diversidad de condi ci ones operat i vas, confi gt
raci ones y car gas para asegur ar que el si st ema responde a la interaccin del
usuari o y manej a cargas ext r emas sin que haya una degradaci n operat i va
inaceptable.
La compatibilidad se prueba al ej ecut ar la WebApp en vari as confi guraci ones
husped, en los l ados t ant o del cliente como del servidor. El objetivo es en-
cont rar errores especficos respect o a sl o una configuracin husped.
La interoperabilidad se prueba para asegur ar que la WebApp realiza interfaces
adecuadas con ot ras apl i caci ones o bases de dat os.
La seguridad se prueba al valorar las vulnerabilidades pot enci al es e intentar
explotar cada una de ellas. Cualquier i nt ent o de penet raci n exi t oso se cons.
dera una falla en la seguridad.
En est e captulo se est udi an, ms adel ant e, una estrategia y al gunas t ct i cas que
han desarrol l ado para poner a pr ueba cada una de las ant eri ores caractersticas ce
calidad de una WebApp.
"La innovacin es un asunt o agridulce para quienes ponen a pr ueba el soft ware. Justo cuando parece que se sabe
cmo probar una tecnologa particular, llega una nueva [WebApp] y t odas las apuest as se pi erden. "
J a m e s B a ch
20.1.2 Errores dentro de un ambiente WebApp
Ya se ha seal ado que el intento primario de realizar pruebas en cualquier contexto
de sof t war e es descubrir errores (y corregirlos). Los errores encont r ados como cor -
secuenci a de la prueba exitosa de la WebApp tienen varias caract er st i cas nicas
[NGUOOJ:
1. Puest o que muchos tipos de pr uebas de WebApp descubren probl emas que se
evi denci an pri mero en el lado del cliente (es decir, a t ravs de una interfaz
i mpl ement ada en un navegador especfico, una PDA o un t el fono celular), d I
i ngeni ero Web ve un s nt oma del error, no el error en s.
TM
PDF Editor
C A P T U L O 2 0 CMO PROBAR APLI CACI ONES WEB 607
i vil
l es de
Isaft ware
kVE
i global
i la WebApp
asumir en
> anotados
2. Puest o que una WebApp se i mpl ement a en varias confi guraci ones di ferent es y
dent ro de distintos ambi ent es, puede ser difcil o imposible reproducir un
error afuera del ambi ent e en el que el error se encont r ori gi nal ment e.
3. Aunque al gunos errores son resul t ado de un di seo incorrecto o una codifica-
cin HTML impropia (o al gn ot ro l enguaj e de programaci n), muchos errores
pueden rast rearse haci a la confi guraci n de la WebApp.
4. Puesto que las WebApp residen dent ro de una arqui t ect ura cl i ent e/ servi dor, el
rast reo de los errores puede ser difcil a t ravs de las tres capas arqui t ect ni -
cas: el cliente, el servidor o la red en s.
5. Algunos errores se deben al ambi ent e operativo est t i co (es decir, la configu-
racin especfica en la que se desarrolla la prueba), mi ent ras que ot ros son
atribuibles al ambi ent e operat i vo di nmi co (es decir, la carga i nst ant nea de
recursos o los errores rel aci onados con el tiempo).
Estos cinco at ri but os de error sugieren que el ambi ent e desempea un i mport ant e
papel en el di agnst i co de t odos los errores descubi ert os dur ant e el proceso de in-
geniera Web. En al gunas si t uaci ones (por ej empl o, prueba de contenido), el sitio del
error es obvio, pero en muchos ot ros tipos de pr uebas de WebApp (por ejemplo,
pr uebas de navegaci n, de desempeo, de seguridad) la causa subyacent e del error
tal vez sea consi derabl ement e ms difcil de det ermi nar.
20.1.3 Estrategias de pruebas
La est rat egi a para probar una WebApp adopt a los principios bsi cos para t odas las
pr uebas de sof t war e (captulo 13) y aplica una estrategia y las t ct i cas que se reco-
mendar on respect o de los si st emas ori ent ados a obj et os (captulo 14). Los siguien-
tes pasos r esumen el enfoque:
1. Se revisa el model o de cont eni do de la WebApp para descubrir errores.
2. Se revisa el model o de la interfaz para asegurarse que t odos los casos de uso
pueden acomodar se.
3. Se revisa el model o de di seo de la WebApp para descubrir errores de nave-
gacin.
4. Se prueba la i nt erfaz del usuari o para descubrir errores en la present aci n o
los mecani smos de navegaci n.
5. Component es funci onal es sel ecci onados se prueban en forma individual.
6. Se prueba la navegaci n a t ravs de t oda la arquitectura.
7. La WebApp se i mpl ement a en di versas confi guraci ones ambi ent al es y se
prueba su compatibilidad con cada configuracin.
8. Se realizan pr uebas de seguridad con el objetivo de explotar vul nerabi l i dades
en la WebApp o dent ro de su ambi ent e.
TM
PDF Editor
www. l i t kymi nds .
com/ t es t l ng- as p.
C&VE
El plan de prueba
identifica un conj unt o
de t areas de pr ueba,
los product os de
trabojo que se
desarrollarn y la
f or ma en lo cual los
resul t ados s e eval an,
registran y reutilizan.
9. Se llevan a cabo pr uebas de desempeo.
10. La WebApp se prueba en una poblacin cont rol ada y moni t oreada de usuan as
finales; los resul t ados de su interaccin con el si st ema s e eval an para busca.-]
errores de cont eni do y navegaci n, rel aci onados con la facilidad de uso, cor
la compatibilidad y con la confiabilidad y el des empeo de la WebApp.
Puest o que muchas WebApps evol uci onan cont i nuament e, la prueba de la We bAr J
es una actividad de segui mi ent o que dirige el equi po de soport e Web, que u t n a l
pr uebas de regresin deri vadas de las pr uebas desarrol l adas cuando la WebApp s J
somet i a ingeniera por pri mera ocasi n.
20.1.4 Planeacin de las pruebas
El empl eo de la pal abra pl aneaci n (en cualquier contexto) es anat ema para al gur : J
desabol l ador es Web. Como se anot en captulos ant eri ores, di chos profesiona em
sl o comi enzan, pues t emen el surgi mi ent o de al gn sabot eador de WebApps. Un r - |
geni ero Web reconoce que la pl aneaci n est abl ece un mapa vial para t odo el trar.^J
j o que sigue. Vale la pena el esfuerzo.
En su libro acerca de las pruebas de las WebApps, Splaine yj aski el [SPL01] af i r mad
Except o por el m s si mpl e de l os si t i os Web, r pi da me nt e se vuel ve a pa r e nt e q u e e s ne-
ces ar i a ci ert a es peci e de pl aneaci n de pr uebas . Con de ma s i a da f r ecuenci a, el n me r o ini-
cial de er r or es que s e e nc ue nt r a n a par t i r de una pr ueba a de c ua da e s lo suf i ci ent ement e
gr ande c o mo par a que n o t odos s e fijen la pr i mer a vez q u e s e det ect an. Est o p o n e una pre
si n adi ci onal s obr e la gent e que pr ue ba l os si t i os y apl i caci ones Web. No s l o de be n cor
j ur ar n u e v a s pr ue ba s i magi nat i vas, t ambi n de be n r ecor dar c mo s e ej ecut ar on l as
pr ue ba s ant er i or es con la finalidad de vol ver a pr obar c on conf i abi l i dad el s i t i o/ l a aplica
ci n Web, y a s e gur a r s e de que l os er r or es conoci dos s e ha n r e movi do y que n o s e han in-
t r oduci do ot r os nuevos .
La pregunt a para t odo i ngeni ero Web es: cmo "conj uro nuevas pruebas i
nativas" y en qu se deben enfocar di chas pruebas? La respuest a se encuent r a
tro de un plan de pruebas.
Un plan de pruebas WebApp identifica 1) un conj unt o de tareas2 que se apli
cuando comi ence la prueba, 2) los product os de t rabaj o que se gener ar n con
se ej ecut e cada t area de prueba, y 3) la forma en la que los resul t ados de las
bas se eval an, regi st ran y reutilizan cuando s e realicen pr uebas de regresin. E"-
gunos casos, el plan de pr uebas se integra con el plan del proyecto; en otros, el
de pr uebas es un document o separ ado.
2 Los conj unt os de t areas se est udi an en el captulo 2. En est e libro t ambi n se ha empl eado un
mi no relacionado flujo de trabajo para describir la serie de t ar eas necesari a para compl et a:
actividad de ingeniera del soft ware.
TM
PDF Editor
C A P T U L O 2 0 CMO PROBAR APLICACIONES WEB 6 0 9
2 0 . 2 EL PROCESO DE PRUEBA: UN P ANORAMA
Los procesos de prueba para ingeniera Web comi enzan con pruebas que ejercitan
el cont eni do y la funcionalidad de la interfaz que es i nmedi at ament e visible para los
usuari os finales. Conforme se realizan las pruebas, se ejercitan los aspect os de la ar-
quitectura de diseo y la navegacin. El usuari o puede o no conocer est os el emen-
t os de la WebApp. Finalmente, el foco se cambia a las pruebas que ejercitan las ca-
paci dades tecnolgicas que no si empre son aparent es para los usuarios finales: la in-
fraestructura de la WebApp y cuestiones de i nst al aci n/ i mpl ement aci n.
" n general, as tcnicos de prueba de software [captulos 13 y 14] que se utilizan con otras i
mismas que las empleadas en las aplicaciones basadas en Web... La diferencia entre los dos tipos de pruebas es que
se multiplican las variables de tecnologa en el ambiente Web."
La figura 20.1 yuxt apone el proceso de prueba WebApp con la pirmide de dise-
o exami nada en el captulo 19. Ntese que, conforme se desarroll el flujo de prue-
bas, de izquierda a derecha y de arriba abajo, los el ement os del diseo WebApp vi-
sibles para el usuari o (elementos superi ores de la pirmide) se prueban primero, se-
guidos por los el ement os de diseo de infraestructura.
Prueba
Prueba de
la interfaz
usuario
Prueba de
navegaci n
Diseo de
la interfaz
Diseo esttico
Prueba de
componentes
Diseo de contenido
Diseo de navegaci n
Diseo arquitectnico
Diseo de component es
Prueba de
configuracin
tecnolog a
Prueba de
desempeo
Prueba de
seguridad
TM
PDF Editor
\
CLAVE
Lo estrategia para la
prueba de integracin
depende de la
arquitectura de la
WebApp elegido
durante el diseo.
La prueba de contenido (y las revisiones) i nt ent an descubrir errores en el cont -
do. Esta actividad de prueba es similar en muchos aspect os a la copia-edicin de
document o escrito. De hecho, un gran sitio Web puede reclutar los servicios de un
rrector de estilo profesi onal para descubrir errores tipogrficos, equ vocos grama"
cales, errores en la consi st enci a del cont eni do, i nexact i t udes en las represent aci cr
grfi cas y fallas en las referenci as cr uzadas. Adems de exami nar el cont eni do
tico en busca de errores, esta et apa de las pr uebas t ambi n consi dera el cont en:
di nmi co deri vado de los dat os conser vados como part e de un si st ema de base
dat os i nt egrado a la WebApp.
La prueba de la interfaz ejercita los mecani smos de interaccin y valida los aspe:
tos est t i cos de la interfaz del usuari o. El objetivo es descubrir los errores que re
tan de mecani smos con una pobre implementacin de interaccin, u omisiones, r
sistencias o ambi gedades que se han introducido a la interfaz en forma inadvertida
La prueba de navegacin aplica casos de uso, deri vados como part e de la act r
dad de anlisis, en el di seo de casos de prueba que ejerciten cada escenari o de
cont ra el di seo de navegaci n.
Los mecani smos de navegaci n (por ej empl o, barras de men) i mpl ement a
dent ro de la plantilla de la i nt erfaz se pr ueban cont ra casos de uso y USN (capi
19) para garant i zar que los errores que impiden compl et ar un caso de uso se ide
fiquen y corrijan.
La prueba de componentes ejercita el cont eni do y las uni dades funci onal es de-
de la WebApp. Cuando se consi deran las WebApps, cambi a el concept o de un:
(introducido en el captulo 13). La "unidad" de eleccin dent ro de la arqui t ect ura
cont eni do (captulo 19) es la pgi na Web. Cada pgi na Web encapsul a cont er
vnculos de navegaci n y el ement os de pr ocesami ent o (formatos, gui ones, app'
Una "uni dad" dent ro de la arqui t ect ura WebApp puede ser un component e funci
definido que proporci ona servicio di rect ament e a un usuari o final o un compon
de i nfraest ruct ura que posibilita que la WebApp desarrolle t odas sus capaci da
Cada component e funci onal se prueba, en gran parte, en la mi sma forma que
prueba un mdul o individual en el sof t war e convenci onal . En la mayor a de los
sos, las pr uebas est n ori ent adas a las caj as negras. Sin embar go, si el pr ocesam
to es compl ej o, t ambi n se pueden usar pr uebas de caj as bl ancas. 3 Adems de
prueba funcional, t ambi n se ejercitan las capaci dades de bases de datos.
Conforme se const ruye la arqui t ect ura de la WebApp, las pr uebas de la nav-
cin y los component es s e utilizan como pruebas de integracin. La estrategia
la prueba de integracin depende del cont eni do y la arqui t ect ura WebApp que se
ya elegido (captulo 19). Si la arqui t ect ura de cont eni do se di sea con estructura
neal, retcula o jerrquica simple, es posible integrar pgi nas Web en gran parte
la mi sma forma como se integran mdul os para el sof t war e convenci onal . Sin
bargo, si se usa una est ruct ura de jerarqua mixta o de red (Web), la prueba de i
3 Las t cni cas de pr uebas de caj a negra y caj a bl anca se exami nan en el captulo 14.
TM
PDF Editor
CAP TULO 2 0 CMO PROBAR APLICACIONES WEB
611
gracin es similar al enfoque usado para los si st emas OO. Las pruebas basadas en
ligas (captulo 14) se pueden aprovechar para integrar el conj unt o de pgi nas Web
(se puede usar una USN para definir el conj unt o apropiado) requerido para respon-
der a un event o de usuario. Cada liga se integra y pone a prueba individualmente.
Mediante las pruebas de regresin se asegura que no ocurran efect os colaterales.
Las pruebas de agrupami ent o integran un conj unt o de pgi nas asoci adas (determi-
nadas medi ant e el examen de los casos de uso y la USN). Los casos de prueba se de-
rivan para descubrir los errores en las colaboraciones.
Cada el ement o de la arquitectura WebApp se prueba de manera unitaria en la me-
dida de lo posible. Por ejemplo, en una arquitectura MVC (captulo 19), los compo-
nent es modelo, vista y controlador se prueban cada uno de manera individual. Des-
pus de la integracin, el flujo de control y dat os a travs de cada uno de est os ele-
ment os se valora en detalle.
Las pruebas de configuracin intentan descubrir los errores que son especficos
respecto de un cliente o ambi ent e de servidor particulares. Se crea una matriz de re-
ferencia cruzada que define todos los probabl es si st emas operativos, navegadores, 4
pl at aformas de hardware y protocolos de comunicacin. Entonces las pruebas se en-
cami nan a descubrir los errores asoci ados con cada posible configuracin.
La prueba de seguridad incorpora una serie de pruebas di seadas para explotar las
vulnerabilidades en la WebApp y su ambiente. El objetivo es demost rar la posibilidad
de una brecha en la seguridad.
La prueba de desempe o abarca una serie de pr uebas di seadas para valorar 1)
cmo afecta el aument o del trfico de usuarios la respuesta en tiempo y confiabili-
dad de la Web, 2) cules component es de la WebApp son responsabl es de la degra-
dacin del desempeo y qu caractersticas de uso provocan que ocurra la degrada-
cin, y 3) cmo la degradacin del desempeo impacta los objetivos y requisitos glo-
bales de la WebApp.
CONJUNTO DE TAREAS
Prueba de Ja W ebApp
I. Revisar los requisitos de los
participantes. Identificar las metas y
objetivos de los usuarios. Revisar los
casos de uso respecto de cada
categora de usuario.
Establecer prioridades par a asegur ar que cada meta
objetivo de usuario se probarn de manera
adecuada.
Definir la estrategia de prueba de la WebApp al
describir los tipos de pruebas (seccin 20. 2) que se
realizarn.
Desarrollar un plan de prueba.
Definir un calendario de pruebas y asi gnar
responsabilidades a cada prueba.
Especificar herramientas aut omat i zadas par a
realizar las pruebas.
y
4 Los navegador es son not abl es porque i mpl ement ar sus propios "estndares", sut i l ment e di ferent es
en las i nt erpret aci ones de HTML y javascript
TM
PDF Editor
/ "
5.
Definir criterios de aceptacin par a cada clase
de prueba.
Especificar mecanismos de rastreo de defectos.
Definir mecanismos de reporte de problemas.
Realizar pruebas "unitarias".
Revisar el contenido par a errores de sintaxis
y semntica.
Revisar el contenido par a clarificaciones y permisos
adecuados.
Probar los mecanismos de la interfaz par a una
operacin correcta.
Probar cada componente (por ejemplo, guin) para
asegurar el funcionamiento adecuado,
. Realizar pruebas de "integracin".
Probar la semntica de la interfaz respecto de los
casos de uso.
Dirigir pruebas de navegacin.
7. Realizar pruebas de configuracin.
Valorar la compatibilidad de configuracin en el
lado del cliente.
Valorar configuraciones en el lado del servidor.
8. Dirigir pruebas de desempeo.
9. Dirigir pruebas de seguridad.
^ C O N S E J O ^
Aunque los revisiones
t cnicas formales no
son porte de una
prueba, se deben
llevar a cabo revi-
siones de contenido
para garantizar lo
calidad del contenido.
CLAVE
Los objetivos de lo
pruebo de cont eni do
son 1) descubrir errores
sintcticos en el
contenido, 2) descubrir
ei rores semnt i cos y 3 )
encontrar errores
est ruct ural es.
Los errores en el cont eni do de la WebApp pueden ser tan triviales como errores I
pogrfi cos menor es o t an significativos como i nformaci n incorrecta, organi zaci :
impropia o violacin de las leyes de propi edad intelectual. La prueba del cont er
i nt ent a descubrir st os y muchos otros probl emas ant es de que el usuari o los
cuent re.
La prueba del cont eni do combi na t ant o revisiones como la generaci n de casos :
prueba ejecutables. La revisin se aplica para descubrir errores semnt i cos en el cc
tenido (examinados en la seccin 20.3.1). La prueba ejecutable se aprovecha para i
cubrir errores de cont eni do susceptibles de rastrear hacia cont eni do di nmi camer
derivado que hayan suministrado los datos adquiridos de una o ms bases de datos ]
20.3.1 Objetivos de la prueba de contenido
La prueba del cont eni do tiene t res objetivos importantes: 1) descubrir errores sinta:-
ticos (por ejemplo, errores tipogrficos, equ vocos gramaticales) en los document
basados en texto, represent aci ones grfi cas y ot ros medi os audiovisuales, 2) des
brir errores semnt i cos (es decir, errores en la precisin de la i nformaci n o que i
ta sea incompleta) en cualquier obj et o de cont eni do pr esent ado conf or me ocurra !
navegaci n, y 3) hallar errores en la organi zaci n o est ruct ura del cont eni do que i
present a al usuari o final.
El primer objetivo se logra empl eando verificadores de ortografa y gramt i ca i
t omat i zados. Sin embargo, muchos errores sintcticos evaden la deteccin media
te tales her r ami ent as y debe descubrirlos un revisor humano (examinador). Como j
anot en la seccin anterior, la correccin de estilo es el mej or enf oque para encc
trar errores sintcticos.
La prueba semnt i ca se cent ra en la i nformaci n pr esent ada dent ro de cada
jeto de cont eni do. El revisor (examinador) debe responder las si gui ent es pregunt
La informacin real ment e es precisa?
La i nformaci n es conci sa y exact a?
TM
PDF Editor
CAPTULO 20 CMO PROBAR APLICACIONES WEB 6 1 3
La plantilla del objeto de contenido es fcil de entender para el usuario?
La informacin anidada en un objeto de contenido se encuentra con facilidad?
Se han ofrecido referencias adecuadas para toda la informacin derivada de
otras fuentes?
La informacin presentada es consistente i nt ernament e y con la informacin
que presentan otros objetos de contenido?
El contenido es ofensivo, engaoso o abre la puerta a litigios?
El contenido infringe derechos de autor o marcas registradas existentes?
El contenido contiene vnculos internos que compl ement an el contenido
existente? Los vnculos son correctos?
El estilo esttico del contenido entra en conflicto con el estilo esttico de la
interfaz?
La obtencin de respuestas a cada una de est as preguntas en una WebApp grande
(que contiene cientos de objetos de contenido) puede ser una labor atemorizante.
Sin embargo, el fracaso para descubrir errores semnt i cos alterar la fe del usuario
en la WebApp y puede conducir a fallas de la aplicacin basada en Web.
Los objetos de contenido existen dentro de una arquitectura que tiene un estilo
especfico (captulo 19). Durante la prueba del contenido, la estructura y organiza-
cin de la arquitectura del contenido se prueba para garantizar que el contenido re-
querido se presenta al usuario final en el orden y las relaciones adecuados. Por ejem-
plo, la WebApp HogarSeguroInc.com5 presenta una variedad de informacin acerca
de sensores que se utilizan como parte de productos de seguridad y vigilancia. Los
objetos de contenido proporcionan informacin descriptiva, especificaciones tcni-
cas, una representacin fotogrfica e informacin relacionada. Las pruebas de la ar-
quitectura de contenido de HogarSeguroInc.com se esfuerzan por descubrir errores
en la presentacin de esta informacin (por ejemplo, una descripcin del Sensor X
se present a con una fotografa del Sensor V).
20.3.2 Prueba de las bases de datos
Las modernas aplicaciones Web hacen mucho ms que presentar objetos de conte-
nido estticos. En muchos dominios de aplicacin, la interfaz de las WebApps con
bases de dat os sofisticados gestionan si st emas y construyen objetos de contenido di-
nmi cos que se crean en tiempo real aprovechando dat os adquiridos de una base de
datos.
Por ejemplo, una WebApp de servicios financieros puede producir compleja infor-
macin basada en texto, tabular y grfica acerca de una participacin accionaria es-
pecfica (por ejemplo, fondos de acciones o de inversin colectiva). El objeto de con-
tenido compuest o que presenta esta informacin se crea di nmi cament e despus de
pr e -
itos se
antear y
p a r a
errores
en el
7
5 La WebApp HogarSeguroInc. com se ha utilizado c omo ei empl o a lo largo de la Parte 3 de est e libro.
TM
PDF Editor
Qu conf l i c-
t o s compl i can
l a p r u e b a d e
b a s e s de d a t a s
p a r a We b Ap p s ?
que el usuario ha consultado informacin acerca de una participacin accionaria es-
pecfica. Esto se logra mediante los siguientes pasos: 1) se consulta una gran base
de datos de participaciones accionarias, 2) se extraen dat os relevantes de la base de
datos, 3) los datos extrados se deben organizar como un objeto de contenido, y 4
este objeto de contenido (que representa informacin personalizada solicitada po:
un usuario final) se transmite al ambi ent e del cliente para su despliegue. Los errores
pueden ocurrir, y de hecho lo hacen, como consecuencia de cada uno de est as eta-
pas. El objetivo de probar la base de dat os es descubrir dichos errores.
La prueba de la base de datos para las WebApps es complicada por varios factores
1. La solicitud original de informacin en el lado del cliente rara vez se presenta en
la forma ( por ejemplo, lenguaje de consultas estructurado, [S QL, por sus siglas er.
ingl s]) que pueda introducirse en un sistema gestor de bases de dat os (DBMS
por sus siglas en ingls). En consecuencia, las pruebas se deben disear para
descubrir errores cometidos al traducir la solicitud del usuario en una forma
que puedan procesar dichos DBMS.
2. La base de datos quiz sea remota al servidor que hospeda la W ebApp. Por lo
tanto, se deben desarrollar las pruebas que descubran los errores en la comu-
nicacin entre la WebApp y la base de dat os remota.6
3. Los datos brutos adquiridos de la base de datos se deben transmitir al servidor de
la W ebApp y formatearse adecuadamente para su transmisin subsecuente al
cliente. En consecuencia, se deben desarrollar pruebas que demuest ren la va-
lidez de los dat os brutos que recibe el servidor WebApp, y tambin se deben
crear pruebas adicionales que demuest ren la validez de las transformaciones
aplicadas a los dat os brutos para crear objetos de contenido vlidos.
4. Los objetos de contenido dinmico se deben transmitir al cliente en una forma
que se pueda desplegar al usuario final. Por lo tanto, se debe disear una serie
de pruebas para a) descubrir errores en el formato de objeto de contenido, y
b) probar la compatibilidad con diferentes configuraciones de ambiente de
cliente.
Al considerar est os cuatro factores, se deben aplicar los mt odos de diseo de ca-
sos de prueba para cada uno de los "estratos de interaccin" [NGU01] anot ados er
la figura 20.2. Las pruebas deben asegurar que 1) informacin vlida pasa entre e.
cliente y el servidor desde el estrato de la interfaz; 2) la WebApp procese los guiones
correct ament e y extraiga o formatee adecuadament e dat os del usuario; 3) los dato;
del usuario pasen correctamente a una funcin de transformacin de dat os en el la-
do del servidor para formatear consultas apropiadas (por ejemplo, SQL); 4) las con
6 Dichas pr uebas se vuelven compl ej as cuando se encuent r an bases de dat os distribuidas o cuand:
se requi ere el acceso a un al macn de dat os (capitulo 10).
TM
PDF Editor
C A P T U L O 2 0 CMO PROBAR APLICACIONES WEB 615
sultas pasen a un estrato de gestin de datos7 que se comuni que con rutinas de ac-
ceso a bases de dat os (potencialmente ubicadas en otra mquina).
Los estratos de transformacin de datos, gestin de dat os y acceso a bases de da-
tos, que se muest ran en la figura 20.2, usualmente se construyen con component es
reutilizables que se han validado por separado y como paquete. Si st e es el caso,
las pruebas de la WebApp se centran en el diseo de casos de prueba para ejerci-
tar las interacciones entre el estrato del cliente y los primeros dos estratos del servi-
dor (WebApp y transformacin de datos) most rados en la figura.
El estrato de la interfaz del usuario se prueba para garantizar que los guiones
HTML estn construidos de manera adecuada para cada solicitud de usuario y se
transmiten adecuadament e al lado del servidor. La capa WebApp en el lado del ser-
vidor se prueba para asegurar que los dat os del usuario se extraen adecuadament e
de guiones HTML y se transmiten de manera adecuada al estrato de transformacin de
datos en el lado del servidor.
Las funciones de transformacin de dat os se prueban para asegurar que se crea
el SQL correcto y que pasa a component es apropiados de gestin de datos.
Una exposicin detallada de la tecnologa subyacente que se debe ent ender para
disear apropi adament e dichas pruebas de bases de dat os est ms all del alcance
de est e libro. El lector interesado debe consultar [SCE02], [NGU01] y [BROOl],
7 La capa de gestin de dat os por lo general incorpora una interfase SQL al nivel de llamada (SQL
CL1) como puede ser Microsoft OLE/ADO o ia Conectr. i Jad de Bases de Datos Java (Java Dat abase
Connectivity, JDBC)
TM
PDF Editor
"Como clientes electrnicos ( ya sea de negocios o consumo) es improbable que t engamos confi anza en un sitio Web
que sufre de frecuent es periodos de inactividad, cuelga a la mitad de una transaccin o t i ene un mal sentido de la
facilidad de uso. Las pruebas, por lo tanto, tienen un popel importantsimo en el proceso de desarrollo gl obal . "
'5, ' , W i n g Lam
2 0 . 4 PRUEBA DE LA I NTERFAZ DEL USUARI O
La verificacin y validacin de la interfaz del usuari o de una WebApp ocurre en tre
punt os distintos dur ant e el proceso de ingeniera Web. Durante la formul aci n y el
anlisis de requisitos (captulos 17 y 18) se revisa el model o de la interfaz para ga-
rantizar que se aj ust a a los requisitos del cliente y a otros el ement os del model o de
anlisis. Durant e el di seo (captulo 19) se revisa el model o de di seo de la interfaz
para garantizar que se han al canzado los criterios genricos de calidad establecidos pa-
ra t odas las i nt erfaces de usuario, y que los conflictos en el di seo de la interfaz es-
pecficos de la aplicacin se han abordado adecuadament e. Durante las pruebas, e-
enfoque se cambi a a la ejecucin de los aspect os especficos de la aplicacin de la in-
teraccin del usuario segn se manifiestan medi ant e la sintaxis y la semnt i ca de la
interfaz. Adems, las pruebas proporcionan una valoracin final de la facilidad de use.
20.4.1 Estrategia de prueba de la interfaz
La est rat egi a global para la prueba de la interfaz es 1) descubrir los errores relacio-
nados con mecani smos especficos de la i nt erfaz (por ejemplo, errores en la ejecu-
cin adecuada de un vnculo de men o la forma en que los dat os i ngresan en ur
formulario), y 2) descubrir los errores en la forma en que la interfaz i mpl ement a la
semnt i ca de navegaci n, la funcionalidad de la WebApp o el despliegue de conte-
El cumpl i mi ent o de esta estrategia requi ere lograr varios objetivos:
Las caracter sticas de la interfaz se prueban para asegurar que las reglas del dise-
o, la est tica y el contenido visual relacionado estn a disposicin del usuario sir
error alguno. Las caract er st i cas incluyen tipo de fuent es, us o de color, mar-
cos, i mgenes, bordes, t abl as y el ement os rel aci onados que se gener an con-
forme procede la ejecucin de la WebApp.
Los mecanismos individuales de la interfaz se prueban en una forma anloga a la
prueba unitaria. Por ejemplo, las pruebas est n di seadas par a ejercitar todas
las formas, creaci n de gui ones en el l ado del cliente, HTML dinmico, guio-
nes CGI, clasificacin por niveles de cont eni do y mecani smos de interfaz es-
pecficos de la aplicacin (por ejemplo, un carrito de compr as para una
aplicacin de comerci o electrnico). En muchos casos, las pruebas se pueden
enf ocar excl usi vament e en uno de di chos mecani smos (la "unidad") para ex-
cluir ot ras caractersticas y funci ones de la interfaz.
Cada mecanismo de la interfaz se prueba dentro del contexto de un caso de uso o
US N ( cap tulo 19 ) para una categor a de usuario espec fica. Este enf oque de
nido.
^ O N S E J O ^
Con excepcin de
especificidades orien-
tados a la W ebApp, la
estrategia de la
interfaz anotada oqu
es aplicable a todos
los tipos de softw are
cliente/ servidor.
TM
PDF Editor
CAPTULO 20 CMO PROBAR APLICACIONES WEB 6 1 7
pruebas es anl ogo a las pruebas de integracin (captulo 13) en que las prue-
bas se llevan a cabo conforme los mecani smos de la interfaz se integran para
permitir la ejecucin de un caso de uso o una USN.
La interfaz completa se prueba frente a los casos de uso y las US N seleccionadas
para descubrir errores en su semntica. Este enfoque de pruebas es anlogo a
las pruebas de validacin (captulo 13), ya que el propsito es demostrar con-
formidad con la semnt i ca especfica del caso de uso o la USN. En el curso de
esta etapa se lleva a cabo una serie de pruebas de facilidad de uso.
La interfaz se prueba dentro de una diversidad de ambientes ( por ejemplo, nave-
gadores) para asegurar que ser compatible. En la actualidad, esta serie de
pruebas tambin se puede considerar como parte de las pruebas de configura-
cin.
[ CONSEJO
j de los
sexternos
-ealizorse o lo
je roda la vida
r W ebApp. Paite
debe ser la
regular y
i de los
20.4.2 Prueba de mecanismos de la interfaz
Cuando un usuario interacta con una WebApp, la interaccin ocurre por medi o de
uno o ms mecani smos de la interfaz. En el prrafo siguiente se present a un breve
panorama de las consideraciones de prueba para cada mecani smo de la interfaz
[ SPL01] .
V ncul os. Cada vnculo de navegacin se prueba para asegurar que se alcance el
objeto de contenido o funcin adecuado.8 El ingeniero Web construye una lista de to-
dos los vnculos asociados con la plantilla de la interfaz (por ejemplo, barras de men,
artculos ndice) y luego ejecuta cada uno de manera individual. Adems, se deben
ejercitar los vnculos dentro de cada objeto de contenido para descubrir mal as URL
o vnculos hacia objetos de contenido o funciones impropios. Finalmente, se deben
probar los vnculos con WebApps externas para tener precisin y tambin deben eva-
luarse para determinar el riesgo de que se volvern invlidos con el tiempo.
For ma t os . En el mbito microscpico las pruebas se realizan para garantizar que 1)
las etiquetas identifican correct ament e los campos dentro del format o y que los cam-
pos obligatorios estn identificados visualmente para el usuario; 2) el servidor recibe
toda la informacin contenida en el format o y ningn dat o se pierde en la transmi-
sin entre cliente y servidor; 3) se usan los valores por defecto adecuados cuando el
usuario no selecciona de un men desplegable o conjunto de botones; 4) las funcio-
nes del navegador (por ejemplo, la flecha "retroceso") no corrompen los datos ingre-
sados en un formato; y 5) los guiones que realizan verificacin de error en los dat os
ingresados funcionan de manera adecuada y ofrecen mensaj es de error significati-
vos.
En un nivel ms dirigido, las pruebas deben garantizar que 1) los campos del for-
mat o tienen ancho y tipos de dat os adecuados; 2) el formato establece sal vaguardas
apropiadas para evitar que el usuario ingrese cadenas de texto ms largas que cier-
8 Dichas pruebas se pueden llevar a cabo como ps-t e de pruebas o de la interfaz o de navegacin
TM
PDF Editor
^ O H S U O ^ -
Los pruebas de
creacin de guiones
en el lado del cliente
y las pruebes
asociadas con el
HTML dinmico se
deben repetir siempre
que se libere uno
nuevo versin de un
navegador popular.
to mximo predefinido; 3) t odas las opciones apropiadas para mens desplegables
estn especificadas y ordenadas en una forma significativa para el usuario final; 4
las caractersticas de "autollenado" del navegador no conducen a errores en la en-
trada de datos; 5) la tecla de tabulador (o alguna otra) inicia el movimiento adecua-
do entre campos de formato.
Cr eaci n d e gui ones en el l ado del cl i ent e. Las pruebas de caja negra se llevar
a cabo para descubrir los errores en el procesami ent o conforme se ejecuta el guin
(por ejemplo, Javascript). Dichas pruebas usual ment e se acoplan con pruebas de for-
matos, ya que la entrada del guin por lo general se deriva de los dat os proporcio-
nados como parte del procesamiento de los formatos. Se debe realizar una prueba
de compatibilidad para garantizar que el lenguaje de guin elegido funci onar ade-
cuadament e en la configuracin ambiental que soporta la WebApp. Adems de po-
ner a prueba el guin mismo, Splaine y Jaskiel [SPL01] sugieren que "debe asegurarse
que los est ndares de su compaa [WebApp] establecen el lenguaje preferido y la
versin del lenguaje de creacin de guiones que se usar para la creacin de guio-
nes en el lado del cliente (y en el lado del servidor)".
HTML di nmi co. Cada pgina Web que contenga HTML dinmico se ejecuta para
garantizar que el despliegue dinmico es correcto. Adems, se debe llevar a cabc
una prueba de compatibilidad para garantizar que el HTML dinmico funciona ade-
cuadament e en la(s) configuracin (es) ambiental(es) que soporta la WebApp.
Vent anas pop- up. 9 Una serie de pruebas garantizan que 1) la pop-up est ubicada
de manera adecuada y tiene un t amao apropiado; 2) la pop-up no cubre la ventana
original de la WebApp; 3) el diseo esttico de la pop-up es consistente con el dise-
o esttico de la interfaz; y 4) las barras de despl azami ent o y otros mecani smos de
control agregados a la pop-up funcionan, estn ubicados adecuadament e y trabajar
como se requiere.
Gui ones CGI. Las pruebas de caja negra se dirigen cent rndose en la integridad de
los dat os (conforme los dat os pasan al guin CGI) y en el procesami ent o del guir
una vez que los dat os validados se han recibido. Adems, se pueden llevar a cabc
pruebas de desempeo para asegurarse de que la configuracin del lado del servi-
dor se puede ajustar a las demandas de procesami ent o de invocaciones mltiples de
los guiones CGI [SPL01].
Cl asi f i caci n por ni vel es del cont eni do. Las pruebas deben demostrar que la ca
sificacin por niveles de los dat os est actualizada, se despliega adecuadament e y se
puede suspender sin error y volver a comenzar sin dificultad.
Cookies. Se requieren pruebas tanto del lado del servidor como del lado del cliente
En el lado del servidor, las pruebas deben garantizar que una cook ie est construida
de manera adecuada (contiene dat os correctos) y se transmite de modo apropiado al
9 La utilizacin de las pop-up se ha ext endi do mucho y son uno de los principales mot i vos de irrita-
cin para muchos usuarios. Deben usarse j ui ci osament e o evitarlas por compl et o.
TM
PDF Editor
CAPTULO 20 C MO PROBAR APLI CACI ONES WEB
619
l ado del cliente cuando se solicita cont eni do o funcionalidad especficos. Adems, se
prueba la propia persistencia de la cooki e para garant i zar que su fecha de expiracin
es correcta. En el l ado del cliente, las pr uebas det ermi nan si la WebApp une adecua-
dament e las cookies exi st ent es a una solicitud especfica (enviada al servidor).
Mecani s mos de l a i nterfaz e s pe c c os a l a apl i caci n. Las pr uebas conf or man
una lista de verificacin de funcionalidad y caract er st i cas que se defi nen medi ant e
el mecani smo de la interfaz. Por ejemplo, Splaine y Jaskiel [SPL01] sugieren la si-
gui ent e lista de verificacin para la funcionalidad carrito de compr as definido para
una aplicacin de comerci o electrnico:
La front era (captulo 14) prueba los nmer os m ni mo y mxi mo de artculos
que pueden col ocarse en el carrito.
Probar una solicitud de "verificacin" para un carrito vaco.
Probar el bor r ado adecuado de un artculo del carrito.
Det ermi nar medi ant e prueba si el cont eni do del carrito se vaca con una com-
pra.
Det ermi nar medi ant e prueba la persistencia del cont eni do del carrito de com-
pr as (esto se debe especificar como part e de los requisitos del cliente).
Det ermi nar medi ant e prueba si la WebApp puede recuperar el cont eni do del
carrito en al guna fecha futura (suponi endo que no se ha realizado compra al-
guna) si el usuari o solicita que el cont eni do se guarde.
20.4.3 Prueba de la semntica de la interfaz
Una vez que cada mecani smo de la interfaz se ha pr obado de maner a "unitaria", el
enf oque de la prueba de la interfaz cambi a para consi derar la semnt i ca de st a. La
prueba de la semnt i ca de la i nt erfaz "evala cun bien el di seo se ocupa de los
usuari os, ofrece direccin clara, ent rega ret roal i ment aci n y mant i ene consistencia
de l enguaj e y enfoque" [NGU01].
Una revisin exhaust i va del model o de di seo de la i nt erfaz puede ofrecer res-
puest as parci al es a las pregunt as implcitas en el prrafo anterior. Sin embargo, s e
debe probar cada escenari o de cas o de uso (para cada categora de usuario) una vez
i mpl ement ada la WebApp. En esenci a, un caso de us o s e convi ert e en la ent rada pa-
ra el di seo de una secuenci a de pruebas. La finalidad de la secuenci a de pr uebas es
descubrir ios errores que le i mpedi rn al usuari o lograr el objetivo asoci ado con el
caso de uso.
Conforme s e prueba cada caso de uso, el equi po de ingeniera Web mant i ene una
lista de verificacin para asegurarse de que t odo artculo del men se ha ejercido al
menos una vez, y que t odo vnculo ani dado dent r o de un obj et o de cont eni do ha si-
do empl eado. El objetivo es det ermi nar si la WebApp ofrece un efectivo manej o del
error y recuperaci n.
TM
PDF Editor
620 PARTE TRES APLI CACI N DE LA INGENIERA WEB
probarlo facilidad de
uso se encuentra en
w w w . a h r e f . c o m/
g u i d e s / d e s i g n /
199806/ 0615$.
ht ml . i
Q u carac-
t er i st i cas de
faci l i dad de us o se
vuel ven el f ot o de
l as pr ue ba s , y qu
obj et i vos espec f i -
cos s e a b o r d a n ?
20.4.4 Prueba de la facilidad de uso
La prueba de la facilidad de uso e s si mi l ar a la pr ueba de la s e mnt i ca de la i nt erfaz
(secci n 20. 4. 3) en el s ent i do de que t ambi n eval a el gr a do en el cual l os us uar i os
pue de n i nt er act uar ef ect i vament e con la WebApp, as c o mo el gr ado e n el cual U
WebApp gu a l as acci one s de l os us uar i os , pr opor ci ona r et r oal i ment aci n si gni fi c -|
tiva y f or t al ece un e nf oque de i nt er acci n cons i s t ent e. Ms que e nf ocar s e fijamer:*
e n la s e mnt i ca de al gn obj et i vo i nt er act i vo, l as r evi s i ones y pr ue ba s de la facilidad
de us o s e di s ean pa r a de t e r mi nar el gr ado en el cual la i nt er f az de la WebApp fac -J
lita la vi da del usuar i o. 1 0
Las pr ue ba s de faci l i dad de us o puede di s ear l as un e qui po de i ngeni er a Wet vl
App, pe r o l as pr ue ba s mi s ma s l as l l evan a c a b o l os us uar i os finales. Se apl i ca la si-
gui ent e s ecuenci a de pa s os [SPL01]:
1. Definir un c onj unt o de cat egor as de pr ueba de faci l i dad de us o e i dent i fi car
l as me t a s par a c a da una.
2. Di sear pr ue ba s que per mi t i r n eval uar cada met a.
3 . Sel ecci onar l os par t i ci pant es que di ri gi rn l as pr uebas .
4. I ns t r ument ar la i nt er acci n de l os par t i ci pant es con la WebApp mi e nt r as se 1
lleva a c a bo la pr ueba.
5 . Desar r ol l ar un me c a ni s mo par a val or ar la faci l i dad de us o de la WebApp.
La pr ueba de la faci l i dad de u s o pue de l l evarse a c a bo en var i os gr ados de abstrc-J
ci n: I) s e pue de val or ar la facilidad de us o de un me c a ni s mo de la i nt er f az e s p e c * j
co (por ej empl o, un formul ari o); 2) s e pue de eval uar la faci l i dad de us o de u n a 1
na Web compl et a ( abar cando me c a ni s mos de la i nt erfaz, obj et os de da t os y f-
ne s r el aci onadas) ; o 3) s e pue de cons i der ar la faci l i dad de us o de la WebApp
pl et a.
El pr i mer p a s o en la pr ueba de la faci l i dad de us o e s i dent i fi car un conj unt o de
t egor i as de faci l i dad de us o y es t abl ecer obj et i vos de pr ueba par a cada cat egor a f
s i gui ent es obj et i vos y cat egor as de pr ue ba (escri t os e n f or ma de pr egunt a) il"
es t e e nf oq ue : "
Irteractividad: l os me c a ni s mos de i nt er acci n (por ej empl o, me n s despl eg
bot ones , punt er os ) s on f ci l es de e nt e nde r y us ar ?
Plantilla: l os me c a ni s mos de navegaci n, cont e ni do y f unci ones e s t n col
en una f or ma que per mi t en al us uar i o encont r ar l os r pi dame nt e ?
10 En este contexto se ha usado el trmino "amigable para el usuario". Desde luego, el problema es
la percepcin de un usuario de lo que es una interfaz "amigable" puede ser radicalmente di
de la de otras.
11 Para preguntas adicionales acerca de la facilidad de uso, vase "Facilidad de uso" en el cap
TM
PDF Editor
CAPTULO 20 CMO PROBAR APLI CACI ONES WEB
621
Legibilidad: el t ext o est bi en escri t o y e s comprensi bl e? 12 Las r epr esent aci ones
grfi cas son fci l es de ent ender ?
Esttica: ia plantilla, el color, los car act er es y l as caract er st i cas r el aci onadas
conducen a un us o m s sencillo? Los usuar i os "se si ent en cmodos " con la apar i en-
cia y la percepci n de la WebApp?
Caractersticas de despliegue-, la WebApp utiliza en f or ma pt i ma el t a ma o y la
resol uci n de la pant al l a?
Sensibilidad del tiempo: l as caract er st i cas, f unci ones y cont eni do i mpor t ant es
pueden utilizarse o adqui ri rse de maner a opor t una?
Personalizacin: la WebApp se aj ust a por s mi sma a las necesi dades espec fi cas
de l as di f er ent es cat egor as de usuar i o o usuar i os individuales?
Accesibilidad: la WebApp e s accesi bl e a las per s onas con di scapaci dades?
Dent ro de cada una de es t as cat egor as se di sea una seri e de pr uebas. En al gunos
casos, la "prueba" puede ser una revisin visual de una pgi na Web. En ot ros, se
puede ej ecut ar de nuevo la pr ueba de s emnt i ca de la i nt erfaz, per o en est a ocasi n
son m s i mpor t ant es l as pr eocupaci ones por la facilidad de uso.
Como ej empl o, consi dr ese la val oraci n de la facilidad de us o para la i nt eracci n
y los mecani s mos de la i nt erfaz. Const ant i ne y Lockw ood [CC>N03] sugi eren que se
revi se y pr uebe la facilidad de us o de la si gui ent e lista de caract er st i cas de la inter-
faz: ani maci n, bot ones, color, control, di l ogos, campos , formul ari os, marcos, gr-
ficos, et i quet as, vnculos, mens , mens aj es , navegaci n, pgi nas, sel ect ores, t ext o y
bar r as de her r ami ent as. Conf or me se valora cada caract er st i ca, los usuar i os que
real i zan la pr ueba la califican en una escal a cualitativa. La figura 20. 3 muest r a un
12 Se pueden aprovechar el fndice de Legibilidad FOG y otros para proporcionar una valoracin cuan-
titativa de la legibilidad. Vase para ms detalles http / / developer.gnome.org/ documents/ usability/
usability-readability.html
TM
PDF Editor
CLAVE
Los WebApps se
ejecutan dentro de una
variedad de ambientes
en el lado del cliente.
El objetivo de los
pruebas de
compatibilidad es
descubrir errores
asociados con un
ambiente especfico
(por ejemplo,
navegador).
posible conj unt o de "calificaciones" de val oraci n que pueden sel ecci onar los usua-
rios. Est as cal i fi caci ones se aplican a cada caracterstica i ndi vi dual ment e, a una pa-
gi na Web compl et a o a la WebApp c omo un todo.
20.4.5 Pruebas de compatibilidad
Las WebApps deben oper ar dent r o de ambi ent es que difieren uno de otro. Diferer-
t es comput ador as, dispositivos de despl i egue, si st emas operat i vos, navegador es
velocidad en las conexi ones de red t i enen una influencia significativa en las ve l e i -
dades de pr ocesami ent o en el l ado del cliente, la resolucin de despl i egue y l as vel
cidad de conexi n. Las vari aci ones en el si st ema operat i vo pueden provocar conf l : -
t os en el pr ocesami ent o de la WebApp. En ocasi ones, los di ferent es navegadores
pr oducen resul t ados l i gerament e diferentes, sin i mport ar el grado de est andari za-
cin HTML dent r o de la WebApp. Los plug-in requeri dos pueden o no ser f ci l mene
accesi bl es par a una confi guraci n particular.
En al gunos casos, los pequeos conflictos de compatibilidad no represent an pro-
bl emas significativos, per o en ot ros se pueden encont r ar serios errores. Por e j e mp . r j
las vel oci dades de descar ga pueden volverse i nacept abl es; la falta de un plug-in re-
queri do puede hacer que el cont eni do no sea disponible; la di ferenci as en cuant o a l
navegador pueden cambi ar drst i cament e la plantilla de pgina; l os estilos de f u e - J
t es se pueden alterar y volverse ilegibles, o los f or mat os pueden est ar organizad : al
de maner a i nadecuada. La prueba de compatibilidad se esf uer za par a descubrir c - 1
chos pr obl emas ant es de que la WebApp est en lnea.
El pri mer pas o en la prueba de compatibilidad e s definir un conj unt o de confi e_-
raci ones de comput ador as "encont rado comnment e" en el l ado del cliente y sus v a l
ri ant es. En esenci a, se crea una est ruct ura de rbol que identifica cada plataforma
de comput ador a, los dispositivos de despl i egue tpicos, los si st emas operat i vos s.:-J
por t ados en la pl at aforma, los navegador es disponibles, las probabl es velocidad-=
de conexi n a Internet e i nformaci n similar. A cont i nuaci n, el equi po de i ngen: e3
ra Web pr oduce una seri e de pr uebas de validacin de compatibilidad, deri vadas
las pr uebas de la i nt erfaz existentes, pr uebas de navegaci n, pr uebas de desem-' r-i
o y pr uebas de seguri dad. La finalidad de est as pr uebas es descubrir errores o pr : - i
bl emas de ej ecuci n que se pueden rast rear hast a las di ferenci as de configuraci". I
Prueba de la WebApp
El es cenari o: Oficina de Doug
Los act ores: Doug Miller (gerente del grupo de ingeniera
del softw are de HogorSeguro) y Vinod Raman, miembro del
J po de ingeniera del softw are del producto.
La conversacin:
Doug: Q u piensas de la WebApp VO.O de c
electrnico de HogarSegurolnc.com?
TM
PDF Editor
CAPTULO 20 C MO PROBAR APLI CACI ONES WEB 623
s.bcontrotista hizo un buen trabajo. Sharon
aesarrollo de la empresa] me dicen que la
. mientras t y yo conversamos.
gastara que t y el resto del equipo hicieran
prueba informal del sitio de comercio
mue c as ) : Creo que tendramos
j na compaa de prueba para validar la
ccav a nos estamos matando al intentar que
; ' oduct o salga a ta callo.
iremos una empresa de prueba para las
desempeo y seguridad, y nuestro
. ya est haciendo pruebas. Slo creo que
oe .ista sera til y, adems, no gusta
e:- costos en lnea, as que...
: ra): Q u buscas?
estar seguro de que la interfaz y toda la
son slidos.
> que podemos comenzar con los casos
cada una de las principales funciones de la
acerca de HogarSeguro
el sistema HogarSeguro que
Doug: Bien. Pero sigue las rutas de navegacin hasta su
conclusin. >
Vinod (observa los casos de uso en una
comput adora porttil): S, cuando eliges
Especifique el sistema HogarSeguro que
neces i t a eso te llevar hasta
Seleccione componentes HogarSeguro
de HogarSeguro
Podemos ejercitar la semntica de cada ruta.
Doug: Mientras ests en eso, verifica el contenido que
aparece en cada nodo de navegacin.
Vi nod: Desde luego... y los elementos funcionales
tambin. Q uin est probando la facilidad de uso?
Doug: Oh. . . la empresa de pruebas coordinar las
pruebas de facilidad de uso. Hemos contratado una
firma de investigacin de mercado que reclutar 20
usuarios tpicos para el estudio de facilidad de uso, pero
si ustedes descubren algn conflicto al respecto...
Vi nod: Ya s: dnselos a ellos.
Doug: Gracias, Vinod.
5 P RUEBA AL P E COMP ONE NT E S
Las pruebas al nivel de componentes, t ambi n l l amadas pr uebas de funcin, se enfo-
can sobr e un conj unt o de pr uebas que i nt ent an descubrir errores en las funci ones de
la WebApp. Cada funcin WebApp es un mdul o de sof t w ar e (i mpl ement ado en al-
gn l enguaj e de programaci n o guiones) y se puede probar empl eando las t cni cas
de caj a negra (y, en al gunos casos, de caj a blanca) exami nadas en el captulo 14.
Los cas os de prueba al nivel de component es con frecuenci a se al i ment an con en-
trada al nivel de formularios. Una vez definidos los dat os de los formularios, el usua-
rio sel ecci ona un bot n u ot ro mecani smo de control para iniciar la ej ecuci n. Son
comunes los si gui ent es mt odos de di seo de casos de prueba (captulo 14):
Particin de equivalencia. El domi ni o de ent r ada de la funcin se divide en ca-
t egor as o cl ases de ent r ada a partir de las cual es se derivan los cas os de
prueba. La forma de ent rada se valora par a det ermi nar qu cl ases de dat os
son rel evant es para la funci n. Los casos de prueba para cada cl ase de ent ra-
da se derivan y ej ecut an mi ent ras ot ras cl ases de ent r ada se mant i enen cons-
t ant es. Por ejemplo, una aplicacin de comerci o el ect rni co puede
i mpl ement ar una funcin que calcule los cargos de embar que. Entre la diver-
TM
PDF Editor
si dad de i nformaci n de embar que pr opor ci onada medi ant e un formul ari o,
est el cdi go post al del usuari o. Los cas os de pr ueba se di sean con la fin
dad de descubri r er r or es en el pr oces ami ent o del cdi go post al al especificar
val or es de cdi go post al que puedan descubri r di f er ent es cl ases de errores
(por ej empl o, un cdi go post al i ncompl et o, un cdi go post al correct o, un c
go post al i nexi st ent e, un f or mat o de cdi go post al errneo).
Anlisis de valores lmite. Los dat os de los formul ari os se pr ueban en s us lm:
tes. Por ej empl o, la funci n de cl cul o de embar que s eal ada ant er i or ment e
solicita el nme r o mxi mo de d as requeri do par a la ent r ega del product o,
el formul ari o s e anot an un m ni mo de 2 d as y un mxi mo de 14. Sin emba
go, l as pr uebas de val or de lmite pueden i ngresar val or es de 0, 1, 2, 13, 14
15 par a det er mi nar cmo r eacci ona la funci n frent e a los dat os en y fuera
los lmites de l as ent r adas vl i das. 13
Pruebas de ruta. Si la compl ej i dad lgica de la funci n es al t a, ' 4 s e puede i
pl ear la pr ueba de rut a ( mt odo caj a bl anca de di seo de cas o de prueba)
gar ant i zar que se ha ej erci t ado t oda rut a i ndependi ent e en el pr ogr ama.
Adems de est os mt odos de di seo de cas os de prueba, se utiliza una t cni ca
mada pr ueba de error f or zado [NGU01] par a produci r cas os de pr ueba que deli
dament e conducen los compone nt e s de la WebApp haci a una condi ci n de error
propsi t o es descubri r los er r or es que ocurren dur ant e el manej o de los er r or es
ej empl o, me ns aj e s de er r or es i ncorrect os o i nexi st ent es, falla de la WebApp
consecuenci a del error, salida er r nea produci da por ent r ada er r nea, ef ect os c
t eral es r el aci onados con el pr ocesami ent o del component e) .
Cada cas o de pr ueba al nivel de component es especi fi ca t odos los val ores de
t rada y la salida es per ada que pr opor ci onar el component e. La salida real pn
da como consecuenci a de la pr ueba se regi st ra par a referenci a fut ura dur ant e el
port e y el mant eni mi ent o.
En muchas si t uaci ones la ej ecuci n correct a de la funci n de una WebApp esta
gada a una interfaz adecuada con una base de dat os que puede ser ext erna a la
App. En consecuenci a, la pr ueba de la bas e de dat os se vuel ve una par t e integral
rgi men de pr ueba de component es . How er [HOW97] exami na es t o cuando esc
Los sitios Web al i ment ados con bas es de dat os pueden i nvol ucrar una i nt eracci n com
pleja ent r e navegador es Web, si st emas operat i vos, apl i caci ones plug-in, prot ocol os de co-
13 En este caso, un mejor diseo de entrada puede eliminar errores potenciales. El mximo nm
das se podra seleccionar de un men desplegable, con lo que se evita que el usuario espec
una entrada fuera de los lmites.
14 La complejidad lgica se puede determinar al calcular la complejidad ciclomtica del alg
Vase el captulo 14 para detalles adicionales.
TM
PDF Editor
625
muni caci n, servi dores Web, bases de dat os, pr ogr amas [lenguaje de guin]..., mej or as a
j ! | I la seguridad y cort afuegos.
Tal complejidad imposibilita probar t odas las posibles dependenci as y t odo lo que po-
dra ir mal con un sitio. El tpico proyecto de desarrollo de un sitio Web t ambi n est ar en
un cal endari o agresivo, de modo que el mej or enfoque de prueba empl ear anlisis de
riesgo para det ermi nar dnde enfocar los esf uer zos de prueba. Los anlisis de riesgo de-
be incluir consi deraci n de cunt o coincidir el ambi ent e de prueba con el ambi ent e de
producci n real... Ot ras consi deraci ones tpicas en el anlisis de riesgo incluyen.
Cul f unci onal i dad en el si t i o Web e s m s cruci al par a su pr ops i t o?
Cul es r e a s del sitio r equi er en la m s dur a i nt er acci n con la ba s e de dat os?
Cul es a s pe c t os de l os CGI, appl et s, c ompone nt e s ActiveX, etc., del si t i o s on
l os m s compl ej os ?
Q u t i pos de pr obl e mas caus ar a la mayor a de l as que j a s o la peor publ i ci -
dad?
Q u r e a s del si t i o s e r n l as m s popul ar es ?
Q u a s pe c t os del si t i o t i enen l os ma yor e s r i esgos de s egur i dad?
Cada u n o de l os a s unt os r e l aci onados con el r i esgo que e xa mi na How er deben c on-
s i der ar s e c ua ndo s e di s een c a s os de pr ue ba par a c ompone nt e s WebApp y f unci o-
n e s de ba s e s de da t os r el aci onadas .
2 0 . 6 P R U E B AS HE N A V E G A C I N
Un usuar i o vi aj a a t r avs de una WebApp e n gr an medi da c o mo lo ha c e un vi si t ant e
al cami nar por una t i enda o un mus eo. Existen mu c h a s r ut as que s e pue de n t omar ,
muc ha s par adas que s e pueden realizar, mu c h a s cos as que apr ender y ver, act i vi dades
por iniciar y deci s i ones por t omar . Como ya s e ha come nt ado, es t e pr oce s o de nave-
gaci n e s pr edeci bl e en el s ent i do en que t odo vi si t ant e t i ene un c onj unt o de obj et i -
vos c ua ndo llega. Al mi s mo t i empo, el pr oces o de navegaci n puede ser i mpredeci bl e
por que el vi si t ant e, i nfl ui do por al go que ve o apr ende, pue de el egi r una rut a o i ni ci ar
una acci n que n o e s tpica par a el obj et i vo original. El t r abaj o de pr obar la nave ga-
cin e s 1) gar ant i zar que t odos l os me c a ni s mos que per mi t en al us uar i o de la Web-
App vi aj ar a t r avs de ella s on f unci onal es, y 2) val i dar que cada uni dad s e mnt i ca de
navegaci n (USN) pue da ser a l c a nz a da por la cat egor a de us uar i o adecuada.
"No estamos perdidos. En f r e n t a mo s un r e t o d e ubi caci n. "
John M. Ford
20.6.1 Prueba de la sintaxis de navegacin
La pr i mer a f as e de la pr ueba de navegaci n e n r eal i dad c omi e nz a dur ant e la pr ueba
de la i nt er f az. Los me c a ni s mos de navegaci n s e pr ue ba n par a as e gur ar q u e cada
TM
PDF Editor
uno real i za la funci n que se busca. Spl ai ne y Jaskiel [SPL01] sugi eren que se d
pr obar cada uno de los mecani s mos de navegaci n si gui ent es:
Vnculos de navegacin. Se deben pr obar los v ncul os i nt er nos dent r o de la
WebApp, l os v ncul os ext er nos haci a ot r as WebApps y l as ancl as dent r o de
una pgi na Web espec fi ca par a gar ant i zar que se al canzar n el cont eni do o
la funci onal i dad adecuados cuando el v ncul o s e elija.
Redirigir. Dichos v ncul os ent r an en j uego cuando un usuar i o solicita una URL
i nexi st ent e o sel ecci ona un v ncul o cuyo dest i no se ha r emovi do o cuyo nom-
br e ha cambi ado. Se despl i ega un me ns aj e al usuar i o y la navegaci n se redi-
rige haci a ot ra pgi na (por ej empl o, la pgi na de inicio). La redi recci n se
debe pr obar al solicitar v ncul os i nt er nos i ncorrect os o URL ext er nas y valora:
c mo manej a la WebApp di chas solicitudes.
Bookmarks. Aunque l os bookmar ks son f unci n del navegador , se debe pro-
bar la WebApp par a asegur ar que s e puede ext r aer un ttulo de pgi na signifi-
cat i vo cuando se cree el bookmar k.
Marcos y conjuntos de marcos. Cada mar co cont i ene el cont eni do de una pgj -
na Web especfica; un conj unt o de mar cos cont i ene ml t i pl es mar cos y perm -
te el despl i egue de ml t i pl es pgi nas Web al mi s mo t i empo. Puest o que es
posi bl e ani dar mar cos y conj unt os de mar cos uno dent r o de ot ro, se deben
pr obar di chos mecani s mos de navegaci n y despl i egue para un cont eni do co-
rrecto, plantilla y t a ma o adecuados , de s e mpe o de descar ga y compatibili-
dad de navegador .
Mapas de sitio. Las ent r adas se deben pr obar par a gar ant i zar que el v ncul o
lleva al usuar i o haci a el cont eni do o la funci onal i dad adecuados .
Motores de bsqueda internos. Las WebApps compl ej as us ual ment e cont i ener
ci ent os o i ncl uso miles de obj et os de cont eni do. Un mot or de bs queda inter-
no per mi t e al usuar i o real i zar una bs queda por pal abra cl ave dent r o de la
WebApp para encont r ar el cont eni do necesar i o. La pr ueba del mot or de bs-
queda valida la precisin y qu t an compl et a es la bsqueda, las propi edades
de manej o de er r or es del mot or de bs queda y l as caract er st i cas de bsqueca
avanzada (por ej empl o, el us o de oper ador es bool eanos en el campo de bs-
queda).
Al gunas de est as pr uebas pueden desarrol l arse medi ant e her r ami ent as aut omat i za- ]
das (por ej empl o, veri fi cador de vnculos), mi ent r as que ot r as s e di s ean y ej ecut an
de mane r a manual . La finalidad de t odo est o es asegur ar que los er r or es en las me-
cni cas de navegaci n se encuent r en ant es de que la WebApp est en lnea.
20.6.2 Prueba de la semntica de navegacin
En el cap t ul o 19 se defi ni una uni dad s emnt i ca de navegaci n (USN) como un
conj unt o de est r uct ur as de i nf or maci n y navegaci n r el aci onadas que col abor an en
TM
PDF Editor
CAPTULO 20 C MO PROBAR APLI CACI ONES WEB 627
el cumpl i mi ent o de un s ubconj unt o de requi si t os de usuar i o rel aci onados" [CAC02].
Cada USN se defi ne medi ant e un conj unt o de r ut as de navegaci n (l l amadas "f or mas
de navegar") que conect an nodos de navegaci n (por ej empl o, pgi nas Web, obj et os de
cont eni do o funci onal i dad). Tomada como un t odo, cada USN per mi t e al usuar i o lo-
grar requi si t os espec fi cos defi ni dos por medi o de uno o m s cas os de us o para una
cat egor a de usuari o. La pr ueba de navegaci n ej erci t a cada USN par a as egur ar que
di chos requi si t os son asequi bl es.
Conf or me se pr ueba cada USN, el equi po de ingeniera Web debe r esponder las si-
gui ent es pr egunt as:
La USN se logra en su totalidad sin error?
Todo nodo de navegaci n (definido para una USN) es asequi bl e dent r o del
cont ext o de las rut as de navegaci n que defi ne la USN?
Si la USN puede al canzar se empl eando m s de una ruta de navegaci n, se
ha pr obado cada rut a rel evant e?
Si la i nt erfaz del usuar i o proporci ona una gu a par a ayudar en la navegaci n,
las di recci ones son cor r ect as y compr ensi bl es conf or me se real i za la navega-
cin?
Existe un mecani s mo (distinto a la flecha "ret roceso" del navegador ) par a re-
gr esar al nodo de navegaci n pr ecedent e y haci a el comi enzo de la ruta de
navegaci n?
Los mecani s mos de navegaci n dent r o de un gran nodo de navegaci n (es
decir, una gran pgi na Web) f unci onan adecuadament e?
Si una funci n se ha de ej ecut ar en un nodo y el usuar i o elige no pr opor ci onar
ent r ada, se puede compl et ar el rest o de la USN?
Si una funci n se ej ecut a en un nodo y ocur r e un error en el pr oces ami ent o
de la funci n, se puede compl et ar la USN?
Existe una f or ma para descont i nuar la navegaci n ant es de que se hayan al-
canzado t odos los nodos, per o ent onces r egr esar a donde se des cont i nu la
navegaci n y proceder des de ah ?
Todo nodo se al canza desde el mapa de sitio? Los nombr es de los nodos
son significativos par a los usuar i os finales?
Si un nodo dent r o de una USN se al canza des de al guna f uent e ext erna, es
posi bl e pr oceder haci a el si gui ent e nodo en la ruta de navegaci n? Es posi bl e
regresar al nodo previ o en la rut a de navegaci n?
El usuar i o ent i ende su ubi caci n dent r o de la arqui t ect ura de cont eni do con-
f or me se ej ecut a la USN?
La pr ueba de navegaci n, como l as pr uebas de la i nt erfaz y facilidad de uso, se
debe dirigir en t ant os part i ci pant es di f er ent es c omo sea posible. Las pr i mer as et apas
TM
PDF Editor
de l as pr ue ba s l as di ri gen l os i ngeni er os Web, per o e t a pa s ul t er i or es l as deben <fi|
gir ot r os par t i ci pant es del pr oyect o, un e qui po de pr ueba i ndependi ent e y, a final x
cuent as , us uar i os si n cal i fi caci n t cni ca. La finalidad e s ej er ci t ar a mpl i a me nt e >
navegaci n de la WebApp.
2 0 . 7 P R U E B A DE LA C O N F I G U P A C I M
La vari abi l i dad y la i nest abi l i dad de la conf i gur aci n s on f act or es i mpor t ant e s qj t ffl
hace n de la i ngeni er a Web un des af o. Har dw ar e, s i s t e ma s oper at i vos , navegador es ,1
capaci dad de a l ma c e na mi e nt o, r api dez de comuni caci n de la r ed y una d i v e r s i d a J
d e ot r os f act or es del l ado del cl i ent e s on difciles de pr edeci r pa r a cada usuar i o. A e J
ms , la conf i gur aci n par a un us uar i o da do pue de cambi ar (por ej empl o, act ual i z J
ci ones de s i s t ema oper at i vo, nue vo ISP y r api dez de conexi n) con r egul ar i dad. El i e- J
s ul t ado pue de ser, e n el l ado del cl i ent e, un a mbi e nt e procl i ve a er r or es, t ant o su J
l es c o mo si gni fi cat i vos. La i mpr es i n q u e un us uar i o t e nga d e la WebApp y la f o n - a l
en la q u e i nt er act a con ella pue de diferir s i gni f i cat i vament e de la exper i enci a J
ot r o us uar i o, si a mb o s n o t r abaj an dent r o de la mi s ma conf i gur aci n del l ado G J
cl i ent e.
La l abor de pr obar la conf i gur aci n no e s ej er ci t ar t oda posi bl e conf i gur aci n a
l ado del cl i ent e. Ms bi en, e s pr obar un conj unt o de pr obabl es conf i gur aci ones de I
l ados del cl i ent e y del ser vi dor par a gar ant i zar que la exper i enci a del us uar i o ser al
mi s ma e n t odos el l os y par a ai sl ar er r or es q u e pue da n s e r es pec f i cos de una con- 1
gur aci n part i cul ar.
20.7.1 Conflictos en el lado del servidor
En el l ado del servi dor, l os c a s os d e pr ue ba de conf i gur aci n s e di s ean par a ver i l -
ear que la conf i gur aci n de ser vi dor pr oyect ada (es deci r: ser vi dor WebApp, servid cr
de ba s e de dat os , s i s t e mas oper at i vos , s of t w a r e cor t af uegos , apl i caci ones concu-
rrent es) pue de n s opor t ar la WebApp sin error. En es enci a, la WebApp s e i nst al a den-
t ro del a mbi e nt e del l ado del s er vi dor y s e pr ue ba con la i nt enci n de encont r ar erro-
r e s r el aci onados con la conf i gur aci n.
Conf or me s e di s e a n la pr ue ba s de conf i gur aci n del l ado del servi dor, el inge-
ni er o Web de be cons i de r ar cada c o mp o n e n t e de la conf i gur aci n del servi dor. Entre
l as pr e gunt as que e s pr eci so pl ant ear y r e s ponde r dur ant e la pr ue ba de confi gura-
ci n del l ado del ser vi dor s e e ncue nt r an:
La WebApp e s t ot al ment e compat i bl e con el s i s t ema oper at i vo del servi dor? 1
Los ar chi vos d e s i s t ema, di r ect or i os y da t os d e s i s t ema r el aci onados s e cr ear
c or r e c t a me nt e c ua ndo la WebApp e s oper at i va?
Las me di da s de s egur i dad del s i s t ema (por ej empl o, cor t af ue gos o encr i pt a-
do) per mi t en a la WebApp ej ecut ar s e y dar servi ci o a l os us uar i os si n i nt erfe-
r enci a o me nos c a bo del de s e mpe o?
Q u pr e-
g u n t a s se
deben pl a nt e a r y
r es ponder conf or -
me se lleva a
cabo la pr ue ba de
confi guraci n en
el l ado del s er vi -
d o r ?
TM
PDF Editor
CAPTULO 20 C MO PROBAR APLI CACI ONES ' ATE
629
La WebApp s e ha pr obado con la confi guraci n de servi dor distribuido15 (si
exi st e uno) que se haya elegido?
La WebApp est ade cuadame nt e i nt egrada con s of t w ar e de bas e de dat os?
La WebApp e s sensi bl e a di f er ent es ver si ones del s of t w ar e de bas e de dat os?
Los gui ones de la WebApp en el l ado del servidor se ej ecut an adecuadament e?
Los er r or es del admi ni st r ador del si st ema se han exami nado par a ver su
efect o s obr e l as oper aci ones de la WebApp?
Si se usan servi dores proxy, las di ferenci as en s us conf i gur aci ones se han
abor dado con pr uebas en el sitio?
20.7.2 Conflictos en el lado del cliente
En el l ado del cliente las pr uebas de confi guraci n se cent r an pri nci pal ment e en la
compat i bi l i dad de la WebApp con l as conf i gur aci ones que cont i enen una o m s per -
mut aci ones de los si gui ent es compone nt e s [NGU01]:
Hardware. CPU, memor i a, al macenami ent o y di sposi t i vos de i mpresi n.
Sistemas operativos. Linux, Macintosh, Microsoft Wi ndow s, un si st ema operat i -
vo con bas e mvil.
Software de navegacin. Int ernet Explorer, Mozi l i a/ Net scape, Opera, Safari y
ot ros.
Componentes de la interfaz del usuario. ActiveX, appl et s Java y ot ros.
Plug-ins. Q uickTime, RealPlayer y muchos otros.
Conectividad. Cable, DSL, mdem regular, TI.
Adems de es t os component es , ot r as vari abl es incluyen el s of t w ar e de red, l as va-
ri aci ones del ISP y apl i caci ones que cor r en al mi s mo t i empo.
Al di sear pr uebas de confi guraci n en el l ado del cliente el equi po de i ngeni er a
Web debe reduci r el nme r o de vari abl es de confi guraci n haci a un nme r o mane-
jable. 16 Por t ant o, se valora cada cat egor a de usuar i o par a det er mi nar l as pr obabl es
conf i gur aci ones que s e encont r ar n dent r o de la cat egor a. Adems, se pueden ut i -
lizar l os dat os compar t i dos en el mer cado industrial para predeci r l as combi naci o-
ne s m s pr obabl es de component es . Ent onces la WebApp se pr ueba dent r o de es t os
ambi ent es.
15 Por ejemplo, se puede usar un servidor de aplicacin y uno de base de dat os por separado. La co-
municacin entre las dos mqui nas ocurre por medio de una conexin de red.
16 Ejecutar pruebas en toda posible combinacin de component es de configuracin consume dema-
siado tiempo.
TM
PDF Editor
630 PARTE TRES APLI CACI N DE LA I NGENI ER A WEB
2 Q . 8 P R U E B AS P E S E< 5 VRI P AP
La s egur i dad de l as WebApps e s una mat er i a compl ej a que de be ent ender s e
compl e t o a nt e s de que s e pue da l ograr una pr ueba de s egur i dad efect i va. 17 Las V.
Apps y l os a mbi e nt e s e n el l ado del cl i ent e y en el l ado del ser vi dor en l os que i
hos pe da da s r epr es ent an un bl anco at r act i vo par a hackers, e mpl e a dos d e s c o n t e r d
compe t i dor e s de s hone s t os y cual qui er a ot r o que de s e e r obar i nf or maci n s er
modi f i car cont e ni do mal i ci os ament e, di smi nui r el de s e mpe o, deshabi l i t ar la f ur a
nal i dad o pone r en a pur os a una pe r s ona, or gani zaci n o negoci o.
"El Int ernet es un f ugar ri esgoso por o llevar a t obo negoci os o al macenar act i vos. Hackers, cr acker s, snoops,
s poof e r s , . . l adr ones, vndal os , l anzador es d e vi rus y pr oveedor es de pr ogr a ma s delictivos se pa s e a n l i br ement e
Dor ot hy y Pe t e r D e n g
^ CONS E J O^
Silo WebApp es cru-
cial en el negocio,
conservo datos sensi-
bles o es un probable
blanco de hackers, es
bueno idea subcontra-
tar las pruebas de se-
guridad con una
empresa especializado
en esto labor.
Las pr ue ba s de s egur i dad e s t n di s e adas par a pr obar l as vul ner abi l i dades en
ambi e nt e del l ado del cl i ent e, l as comuni caci one s de red que ocur r en mi ent r as i J
da t os pa s a n del cl i ent e al ser vi dor y de vuel t a, y el a mbi e nt e del l ado del serv
Cada uno d e es t os domi ni os pue de recibir at aques , y e s l abor de qui en pr ue ba la s e l
gur i dad des cubr i r l as debi l i dades q u e pue de n expl ot ar qui e ne s t engan la i n t e n o H
de hacer l o.
En el l ado del cl i ent e, l as vul ner abi l i dades con f r ecuenci a s e pue de n r ast r ear h a s l
t a er r or es pr eexi s t ent es e n l os nave gador e s , pr ogr a ma s d e cor r eo el ect r ni co o s e n
w a r e de comuni caci n. Nguyen [NGU01] des cr i be un hoyo de s egur i dad tpico:
Uno de los errores mencionados comnmente es el desbordamiento del buffer. Esto per-
mite que un cdigo malicioso se ejecute en la mquina cliente. Por ejemplo, al ingresar
una URL en un navegador que es mucho mayor que el tamao del buffer alocado para la
URL provocar un error de sobreescritura de memoria (desbordamiento de buffer) si el na-
vegador no tiene cdigo de deteccin de error para validar la longitud de la URL ingresa-
da. Un hacker estacional puede explotar astutamente este bug al escribir una URL grande
con cdigo ejecutable que puede provocar que el navegador reviente o altere las opciones
de seguridad (de mayor a menor) o, peor an, corrompa los datos del usuario.
Ot r a vul ner abi l i dad pot enci al e n el l ado del cl i ent e e s el a c c e s o no aut or i zade
cooki es col ocadas de nt r o del navegador . Los si t i os Web c r e a dos con i nt enci ones
mal i ci os as pue de n adqui r i r i nf or maci n cont eni da de nt r o de cooki e s l eg t i mas y usar
est a i nf or maci n en f or ma s que pone n en j uego la pr i vaci dad del usuar i o, o peor, es-
t abl ecen el e s ce nar i o pa r a el r obo d e i dent i dad.
Los da t os c omuni c a dos ent r e el cl i ent e y el ser vi dor s on vul ner abl es a la si mul a-
ci n (spoofirtg). st a ocur r e c ua ndo un e xt r e mo de la r ut a de comuni caci n lo sub-
17 Los libros de Trivedi [TRE03], McClure y sus colegas [MCC03] y Garfinkel y Spafford [GAR02] ofre-
cen informacin til acerca del tema.
TM
PDF Editor
631
IVE
s de seguri-
i estar dise-
5 s o ejercitar
s , autentifi-
! cr i pt odo y
vi ert e una ent i dad con i nt enci ones mal i ci osas. Por ej empl o, a un usuar i o puede e nga -
arl o un sitio Web mal i ci oso que act a c omo si f uese el l eg t i mo servi dor de la Web-
App ( i dnt i cos e n apar i enci a y per cepci n) . La i nt enci n e s r obar cont r as e as , i nfor-
maci n de pr opi edad o da t os de crdi t o.
En el l ado del servi dor, l as vul ner abi l i dades i ncl uyen a t a q ue s de negaci n de s er -
vicio y gui one s mal i ci os os que pue de n pa s a r al l ado del cl i ent e o e mpl e a dos par a
deshabi l i t ar l as ope r aci one s del servi dor. Ade ms , s e pue de t ener acces o, sin aut o-
r i zaci n, a ba s e s de dat os en el l ado del ser vi dor (robo de dat os) .
La pr ot ecci n cont r a s t a s (y mu c h a s ot ras) vul ner abi l i dades r equi er e i mpl e me n-
t ar u n o o m s d e l os s i gui ent es e l e me nt os de segur i dad [NGU01J:
Cor t af uegos : me c a ni s mo d e filtrado combi naci n de ha r dw a r e y s of t w ar e
que e xa mi na cada pa que t e de i nf or maci n e nt r ant e par a gar ant i zar que llega
de una f uent e l eg t i ma y bl oquea cual qui er dat o s os pe chos o.
Aut ent i f i caci n: me c a ni s mo de veri fi caci n que val i da la i dent i dad de t odos
l os cl i ent es y ser vi dor es, y per mi t e que l a comuni caci n ocur r a s l o c ua ndo
a mb o s l ados s on ver i f i cados.
Encr i pt ado: me c a ni s mo de codi f i caci n que pr ot ege l os dat os s ens i bl es me -
di ant e s u modi f i caci n en una f or ma q u e i mposi bi l i t a la l ect ura de qui e ne s
t e ngan i nt enci ones mal i ci osas. El encr i pt ado s e f or t al ece e mp l e a n d o cert i fi ca-
dos di gi t al es que per mi t en al cl i ent e veri fi car el des t i no al cual se t r ans mi t en
l os dat os .
Aut or i zaci n: me c a ni s mo de filtrado que per mi t e el a c c e s o al a mbi e nt e del
cl i ent e o el ser vi dor sl o a aquel l os i ndi vi duos con cdi gos de aut or i zaci n
apr opi ados (por ej empl o, i dent i fi caci n del us uar i o y cont r as ea) .
La finalidad de l as pr ue ba s de s egur i dad e s e xpone r l os hoyos en di chos e l e me n-
t os de s egur i dad q u e podr an expl ot ar qui e ne s t engan i nt enci ones mal i ci osas. El di-
s e o act ual de l as pr ue ba s de segur i dad r equi er e un conoci mi e nt o pr of undo de l os
t r abaj os i nt er nos de cada e l e me nt o de s egur i dad, as c o mo una e xt e ns a c ompr e n-
si n de un ampl i o r a ngo de t ecnol og as de red. En mu c h o s cas os , l as pr ue bas d e s e-
gur i dad s e s ubcont r at an con firmas que s e es peci al i zan en di chas t ecnol og as.
Nada e s m s f r us t r ant e que una WebApp que t ar da mi nut os e n car gar cont e ni do
c ua ndo l os si t i os de la compe t e nci a de s car gan cont eni do si mi l ar en s e gundos . Nada
e s m s agr avi ant e que el i nt ent o de ent r ar en una WebApp y recibir un me ns a j e de
"servi dor ocupado", que s e a c o mp a a con la s uger enci a de i nt ent ar l o m s t ar de. Na-
da e s m s de s conce r t ant e que una WebApp que r e s ponde i ns t a nt ne a me nt e en al -
guna s si t uaci ones, y l uego, e n ot r as ocas i ones , par ece i rse a un e s t a do de e s pe r a i n-
finita. Todos e s t os he c hos s uc e de n en la Web t odos l os d as, y t odos e s t n rel aci o-
na dos con el de s e mpe o.
TM
PDF Editor
Las pr uebas del de s e mpe o se apl i can par a descubri r pr obl emas de des empeo
que se pr es ent an debi do a falta de r ecur sos en el l ado del servidor, ancho de banda
de red i napropi ado, capaci dades i nadecuadas de bas e de dat os, def ect uosas o dbi-
les capaci dades del si st ema operat i vo, f unci onal i dad WebApp mal di seada y otros
confl i ct os de har dw ar e o sof t w ar e que pueden conduci r a un pobr e des empeo
cliente-servidor. La finalidad es dobl e: 1) compr ender cmo r esponde el si st ema a la
carga (es decir, nme r o de usuari os, nme r o de t r ansacci ones o vol umen de dat os
global), y 2) recol ect ar mt r i cas que conduci rn a modi fi caci ones de di seo par a me-
j orar el des empeo.
20.9.1 Objetivos de las pruebas del desempeo
Las pr uebas del de s e mpe o se di sean con el fin de si mul ar si t uaci ones de carga de!
mundo real. Conf or me crece el nme r o de usuar i os si mul t neos de la WebApp, o au
ment a el nme r o de t r ansacci ones en lnea, o se i ncr ement a la cant i dad de dat os
(descargados o cargados), las pr uebas de de s e mpe o ayudar n a r esponder las si-
gui ent es pregunt as:
El t i empo de r espuest a del servi dor se reduce hast a un punt o donde es apre-
ci abl e e i nacept abl e?
En qu punt o (en t r mi nos de usuari os, t r ansacci ones o carga de dat os) el
de s e mpe o se vuel ve i nacept abl e?
Q u compone nt e s del si st ema son r esponsabl es de la reducci n del des em-
peo?
Cul es el t i empo de respuest a pr omedi o par a l os usuari os en una vari edad
de condi ci ones de carga?
La reducci n del des empeo t i ene i mpact o sobr e la seguri dad del si st ema?
La confiabilidad o la precisin de la WebApp se afect an conf or me crece la
carga del si st ema?
Q u ocur r e cuando se aplican car gas que r ebas an la capaci dad mxi ma del
servidor?
Para desarrol l ar r es pues t as a est as pregunt as, se dirigen dos pr uebas de desem-
peo di ferent es:
Prueba de carga: la carga en el mundo real se pr ueba en una diversidad de ni-
veles de carga y en una vari edad de combi naci ones.
Prueba de t ensi n: la carga se aume nt a hast a el punt o de rupt ura par a det er-
mi nar cunt a capaci dad puede manej ar el ambi ent e de la WebApp.
Cada una de est as est r at egi as de pr ueba se consi der a en l as secci ones siguientes.
^ ONS E J O^ -
Algunos aspectos del
desempe o de la Web-
App, al menos como
los peiciben los usua-
rios finales, son difci-
les de probar, incluso
lo cargo de red, las
variaciones del hard-
ware que establece
uno interfaz con lo red
y tpicos similores.
TM
PDF Editor
633
3 utiliza
unidores
reo-
ja se
t e n un
f x muhiser-
kVE
3 de las
. y tensin es
r mejor c-
i sistema
e se presiona
t ie sus lmites
20.9.2 Pruebas de carga
El obj et i vo de las pr uebas de carga e s det er mi nar cmo la WebApp y su ambi ent e del
l ado del servi dor r esponder n a vari as condi ci ones de carga. Conf or me pr oceden las
pr uebas, l as per mut aci ones a l as si gui ent es vari abl es defi nen un conj unt o de condi-
ci ones de pr ueba:
N , el nme r o de usuar i os concur r ent es
T , el nme r o de t r ansacci ones en lnea por usuar i o por uni dad de t i empo
D, la carga de dat os pr oces ada por el servi dor por t r ansacci n
En cada caso, est as vari abl es s e defi nen dent r o de los lmites oper at i vos nor ma-
les del si st ema. Conf or me se cor r e cada condi ci n de pr ueba, se recopilan una o m s
de l as si gui ent es medi das: la r espuest a de usuar i o promedi o, el t i empo pr omedi o pa-
ra descar gar una uni dad de dat os est andar i zada o el t i empo pr omedi o para pr ocesar
una t ransacci n. El equi po de i ngeni er a Web exami na es t as medi das par a det ermi -
nar si una di smi nuci n preci pi t ada en el de s e mpe o se puede r ast r ear hast a una
combi naci n espec fi ca de N , T y D .
La pr ueba de carga t ambi n se aplica par a val orar la velocidad de conexi n reco-
me ndada par a l os usuar i os de la WebApp. La cant i dad de i nformaci n global pr oce-
sada en una uni dad de tiempo, P, s e calcula de la f or ma siguiente:
P = N x T x D
Como ej empl o, consi dr ese un popul ar sitio de not i ci as deport i vas. En un mome n-
to dado, 20 000 usuari os concur r ent es real i zan una solicitud (una t ransacci n, T) una
vez cada dos mi nut os en promedi o. Cada t ransacci n requi ere que la WebApp des-
cargue un nuevo artculo que pr omedi a 3 Kbytes de longitud. En consecuenci a, la
cant i dad de i nformaci n pr ocesada en una uni dad de t i empo se puede cal cul ar como:
P = [20 000 x 0. 5 X 3 K b ] / 6 0 = 500 Kbyt es/ seg
= 4 megabi t s por s egundo
Por lo t ant o, la conexi n de red par a el servi dor t endr a que sopor t ar est a t asa de
dat os y se deber a pr obar par a gar ant i zar que la tiene.
20.9.3 Pruebas de tensin
La pr ueba de t ensi n (captulo 13) es una cont i nuaci n de la pr ueba de carga, per o
en est a i nst anci a l as vari abl es N , T y D se f uer zan par a al canzar y l uego super ar los
lmites operat i vos. La finalidad de es t as pr uebas es r esponder cada una de las pr e-
gunt as si gui ent es:
El si st ema se degr ada "gent i l ment e" o el servi dor se desconect a cuando se
r ebasa su capaci dad?
El s of t w ar e del servi dor gener a me ns aj e s de "servidor no di sponi bl e"? De
mane r a m s general : a los usuar i os se les advi ert e que no pueden al canzar
el servidor?
TM
PDF Editor
El servidor pone en cola las solicitudes de recursos y vaca la cola una vez
que la capaci dad demanda di smi nuci n?
Las t r ansacci ones se pierden conf or me se r ebasa la capaci dad?
La integridad de los dat os se afect a cuando se rebasa la capaci dad?
Q u valores de N , T y D f uer zan el fallo del ambi ent e del servidor? Cmo se
mani fi est a la falla en s mi sma? Las not i fi caci ones aut omt i cas se env an al
equi po de soport e t cni co en el sitio del servidor?
Si el si st ema falla, cunt o t ardar en est ar en lnea de nuevo?
Ciertas f unci ones de la WebApp (por ej empl o, calcular funci onal i dad inte
capaci dades de flujo de datos) se descont i nan cuando la capaci dad alcanza
el nivel de 80 o 90 por ciento?
A una vari aci n de la prueba de t ensi n a veces se le refiere como prueba
rebote [SPLOI ]. En est e rgi men de pr uebas la carga se lleva hast a su punt o m r :
de capaci dad, luego se baj a r pi dament e hast a condi ci ones de oper aci n nor m
y luego se sube de nuevo al pico. Al rebot ar la carga del si st ema un exami nador
de det er mi nar cun bien el servi dor puede poner en orden l os recursos par a sati
cer la demanda muy el evada y l uego liberarlos cuando r eapar ecen l as condici
nor mal es (de modo que est n listas par a el si gui ent e pico).
T ax onoma de herramientas para pruebas de WebApp
En su artculo acerca de la prueba de los siste-
mas de comercio electrnico, Lam [LAM01 ]
presenta una til taxonoma de las herramientas automati-
zadas que tienen aplicabilidad directa en la realizacin
de pruebas en un contexto de ingeniera Web. En cada
categora se indican herramientas representativas.18
Las herramientas de configuracin y de gestin
del c ont e ni do gestionan la versin y cambian el control
de los objetos de contenido y de los componentes funcio-
nales de la WebApp.
Herramienlalsl representativa(sl:
En w w w .daveeaton.com/ scm/ CMTools.html se encuen-
tra una extensa lista.
Las herramientas de desempeo de bases de
da t o s miden, por ejemplo, el tiempo para realizar con-
sultas a boses de datos seleccionadas. Estas herramientas
facilitan el mejoramiento de la base de datos.
V
Herramienta(s) representativas(s): BMC Softw are
(w w w .bmc.com)
Los programas depuradores (debuggers) son herramientas
de programacin comunes que encuentran y resuelven de-
fectos de softw are en el cdigo. Forman parte de la mayo-
ra de los ambientes modernos de desarrollo de aplicacio-
nes.
Herramienlalsl representah'va(s):
Accelerated Technology (w w w .acceleratedtechnology.com
IBM VisualAge Environment (w w w .ibm.com)
JD ebug T ool (w w w .debugtools.com)
Los sistemas de gestin de defectos registran los
defectos y rastrean su estatus y resolucin. Algunos inclu-
yen herramientas de reporte para ofrecer informacin de
gestin acerca del defecto esparcido y las tasas de resolu-
cin de defectos.
Herramienlalsl representativa/ s):
EXCEL Quickbugs (w w w .excelsoftw are.com)
18 Las herramientas expuestas aqu slo representan una muestra de esta categora. Adems, los norr -
bres de las mi smas son marcas registradas de las compaas mencionadas.
TM
PDF Editor
635
T RUET rack (w w w .mccabe.com)
ClearQuest (w w w .rational.com)
ami ent as de s upervi s i n de red vigilan el
trfico de la red. Son tiles para identificar los
de botella" de la red y probar los vnculos entre
i de entrada y de salida.
ienta(s represenloliva(sj:
.slac.stanford.edu/ xorg/ nmtf/ nmtf-tools.html se
una extensa lista.
ami ent as d e pr ue ba s d e r e gr e s i n al-
i casos y datos de prueba y se pueden volver a
oara casos de prueba despus de cambios de soft-
I sjcesivos.
nienta(s) representativa(s):
are QARun (w w w .compuw are.
producs/ qacenter/ qarun)
VisualT est (w w w .rational.com)
i Softw are (w w w .seque.com)
i herrami ent as de s upervi s i n de si ti o vigilan
eo de un sitio, usualmente desde una perspecti-
! usuario. sense para compilar estadsticas como el
: de respuesta de extremo a extremo y la cantidad
acin procesada en una unidad de tiempo, as
i cara verificar peridicamente la disponibilidad de
nienta(s) represenlaHva(s):
Systems (w w w .keynote.com)
i herrami ent as d e t e ns i n ayudan a los desarro-
t a explorar el comportamiento del sistema en con-
i de niveles elevados de uso operativo y a encon-
; puntos de quiebre de un sistemo.
nienta(s) representativa/ s):
1 Interactive (w w w .merc-int.com)
i Technologis (w w w .scapatech.com)
s i s t emas de s upervi s i n d e recurs os son par-
! a mayora de los sistemas operativos de los servido-
res y del softw are de servidores Web; vigilan los recursos ta
les como el espacio de disco, el uso del CPU y la memoria.
Herramienta(s) representativa(s):
Successful Hosting.com (w w w .successfulhosting.com)
Q uest Softw are Foglight (w w w .quest.com)
Las he r r ami e nt as de ge ne r ac i n de da t o s de
pr ue ba auxilian a los usuarios en dicha tarea.
Herramienta(s representativa(s):
En w w w .softw areqatest.com/ qatw ebl.html se encuentra
una extensa lista.
Los c o mpa r a d o r e s de r e s ul t ados de pr ue ba s
ayudan a comparar los resultados de un conjunto de prue-
bas con los de otro conjunto. sense para verificar que los
cambios de cdigo no han introducido cambios adversos
en el comportamiento del sistema.
Herramientals/ representativa(s):
En w w w .aptest.com/ resources.html se encuentra una lis-
ta til.
Los moni t or e s d e t rans acci n miden el desempeo
de los sistemas de procesamiento de transacciones de alto
volumen.
Herramienta(s representativa/ si:
QuotiumPro (w w w .quotium.com)
Softw are Research eValid (w w w .soft.com/ eValid/ in-
dex.html)
Las he r r ami e nt as d e s e gur i dad de si ti os We b
ayudan a detectar potenciales problemas de seguridad.
Con frecuencia pueden configurar herramientas de prueba
y supervisin de la seguridad para que corran sobre una
base calendarizada.
Herramienta(s) representativa(s):
En w w w .timberlinetechnologies.com/ products/ w w w .html
se encuentra una extensa lista.
La me t a d e p r o b a r l as We b Ap p e s e j e r c i t a r c a d a u n a d e l as mu c h a s d i me n s i o n e s d e
l a c a l i d a d We b Ap p c o n la finalidad d e e n c o n t r a r e r r o r e s o d e s c u b r i r c onf l i c t os q u e
p u d i e r a n c o n d u c i r a f al l as e n l a c a l i da d. Las p r u e b a s s e c e n t r a n e n c o n t e n i d o , f u n -
c i n , e s t r u c t u r a , f aci l i dad d e us o, n a v e g a b i l i d a d , d e s e mp e o , c o mp a t i b i l i d a d , i n t e r o -
p e r a b i l i d a d , c a p a c i d a d y s e g u r i d a d . Las p r u e b a s t a mb i n i n c o r p o r a n r e v i s i o n e s q u e
o c u r r e n c o n f o r me s e d i s e a l a We b Ap p .
La e s t r a t e g i a d e p r u e b a d e la We b Ap p e j e r c i t a c a d a u n a d e l as d i me n s i o n e s d e c a -
l i dad al e x a mi n a r i n i c i a l me n t e " u n i d a d e s " d e c o n t e n i d o , f u n c i o n a l i d a d o n a v e g a c i n .
Una v e z q u e l as u n i d a d e s i ndi vi dua l e s h a n s i d o v a l i d a d a s , el e n f o q u e s e c a mb i a a
TM
PDF Editor
PARTE TRES APLI CACI N DE LA INGENIERA WEB
pr uebas que ejerciten la WebApp como un todo. Est o se logra deri vando muchas prue-
bas de las perspect i vas de los usuar i os y se al i ment an con la i nformaci n cont eni da
en los cas os de uso. Se desarrol l a un plan de pr ueba de ingeniera Web y se identifi-
can los pas os de prueba, los pr oduct os de t r abaj o (por ej empl o, cas os de prueba) .
los mecani s mos par a la eval uaci n de los r esul t ados de pr ueba. El pr oceso de prue-
ba abar ca si et e tipos di ferent es de pr uebas.
La pr ueba del cont eni do (y l as revisiones) se cent r a en vari as cat egor as de con-
tenido. La finalidad es descubri r er r or es t ant o s emnt i cos como si nt ct i cos que afec-
t en la precisin del cont eni do o la f or ma en la que se pr esent a al usuar i o final. La
pr ueba de la i nt erfaz ejercita los mecani s mos de i nt eracci n que per mi t en que
usuar i o se comuni que con la WebApp y valida los as pect os est t i cos de la interfaz
El obj et i vo es descubri r er r or es que resul t en de mecani s mos de i nt eracci n mal irr.-
pl ement ados , u omi si ones, i nconsi st enci as o ambi gedades en la s emnt i ca de la ir -
t erfaz.
La pr ueba de navegaci n aplica cas os de uso, deri vados como par t e de la activ.
dad de anl i si s, en el di seo de cas os de pr ueba que ej erci t an cada uno de l os esce-
nar i os de uso f r ent e al di seo de navegaci n. Los mecani s mos de navegaci n se
pr ueban par a gar ant i zar que se identifican y corri gen los er r or es que i mpi den e
compl et ar un cas o de uso. La pr ueba de compone nt e s ejercita las uni dades de con-
t eni do y f unci onal es dent r o de la WebApp. Cada pgi na Web encapsul a cont eni dc
v ncul os de navegaci n y el ement os de pr oces ami ent o que f or man una "unidad"
dent ro de la arqui t ect ura de la WebApp. Se deben pr obar di chas uni dades.
La pr ueba de confi guraci n i nt ent a descubri r ios er r or es o l os pr obl emas de corr
patibilidad espec fi cos de un ambi ent e part i cul ar de cliente o servidor. Ent onces s e
llevan a cabo pr uebas par a descubri r l os er r or es asoci ados con cada posi bl e confi-
guraci n. La pr ueba de la segur i dad i ncorpora una serie de pr uebas di seadas para
expl ot ar las vul nerabi l i dades en la WebApp y en su ambi ent e. La finalidad es encor
t rar hoyos de seguri dad. La pr ueba de de s e mpe o abar ca una serie de pr uebas que
se di sean par a val orar el t i empo de r espuest a de la WebApp y la confiabilidad cor -
f or me aume nt a la de manda en la capaci dad de r ecur sos en el l ado del servidor.
[BROOI | Brow n, B., Oracle9i Web D evelopment, McGraw -Hill, 2a. ed 2001.
[CAC02] Cachero, C. et al., "Conceptual Navigation Analysis: A Device and Platform Inde
pendent Navigation Specification", Proc. 2nd Intl. Workshop on web-oriented technolog?.
junio de 2002, se puede descargar de w w w . dsi c. upv. es/ ~w est / i w w ost 02/ papers
cachero.pdf
[CON03J Constantine, L. y L, Lockw ood, Software for Use, Addison-Wesley, 1999; vesr
tambin ht t p: / / w w w . foruse. com/ .
[GAR02] Garfinkel, S. y G. Spafford, Web Security, Prvacy and Commerce, O'Reilly & Assc-
ciates, 2002.
[HOW97] How er, Rick, "Beyond Broken Links", Internet Systems, 1997, disponible er
ht t p: / / w w w . dbmsmag. com/ 9707i 03. ht ml .
[LAMO 1 ] Lam, W "Testing E-Commerce Systems: A Practical Guide", en IEEE IT Pro, mar-
zo-abril de 2001, pp. 19-28.
TM
PDF Editor
CAPTULO 2 0 CMO PROBAR APiiCACICNtS WtS
637
[ MCC03| McCI ur e, S., S. S h a h y S. Sh a h . Web Hacking. Attacks and D efense, Ad d i s o n - We s -
ley, 2003.
| MIL00] Mi l l er, E., " We bSi t e Tes t i ng", 2000, di s poni bl e e n h t t p : / / w w w . s o f l . c o m/ e Va l i d /
Te c h n o l o g y / Wh i t e . P a p e r s / w e b s i t e. t es t i ng. ht ml .
[NGUOO] Nguye n, H., "Tes t i ng We b - Ba s e d Appl i cat i ons " , e n Software T esting and Quality
Engineering, ma y o - j u n i o de 2000, di s poni bl e e n h t t p : / / w w w . s t q e ma g a z i n e . c o m.
[NGU0I1 Nguye n, H., T esting Applications on the Web, Wi l ey, 2001.
[SCE02] Sc e p p a , D Microsoft AD O.N ET , Mi cr os of t Pr es s , 2002.
[SPL01] Spl a i ne , S. y S. Jaski el , T he Web T esting Handbook, STQ E Publ i s hi ng, 2001.
[TRE03] Tr i vedi , R Professional Web Services Security, Wr ox Pr e s s , 2003.
[WAL03] Wal l ace , D., 1. Ragget t y J. Auf ga ng, Ex treme Programmingfor Web Projects, Addi -
s on- We s l e y, 2003.
20. 1. Exi st en al gunas s i t uaci ones e n l as cual es l as pr ue bas de la WebApp de ba n i gnor ar s e por
compl et o?
20. 2. Con a r g u me n t o s pr opi os, c o m n t e n s e l os obj et i vos de la r eal i zaci n de pr ue ba s e n el
cont ext o de la i ngeni er a Web.
20. 3. La compat i bi l i dad e s una i mpor t ant e di me ns i n de cal i dad. Q u de be p o n e r s e a pr ue ba
pa r a gar ant i zar que exi s t e compat i bi l i dad par a una WebApp?
20. 4. Q u er r or es t i enden a s er m s ser i os: l os er r or es del l ado del cl i ent e o l os er r or es del l a-
d o del ser vi dor ? Por qu?
20. 5. Q u e l e me nt os de la WebApp pue de n "pr obar s e de ma n e r a uni t ar i a"? Q u t i pos de
pr ue ba s s e de be n l l evar a c a b o s l o de s pu s de que es t n i nt egr ados l os e l e me nt os de la Web-
App?
20.6. Si empr e e s neces ar i o des ar r ol l ar un pl an de pr ueba escr i t o de ma n e r a f or mal ? Expl i qe-
s e la r es pues t a.
20. 7. Es j ust o deci r q u e la es t r at egi a gl obal de pr ue bas de la WebApp c omi e nz a con l os el e-
me nt os vi si bl es par a el us uar i o y s e mu e v e haci a l os e l e me nt os de t ecnol og a? Exi st en excep-
c i one s a est a es t r at egi a?
20. 8. La pr ueba del cont e ni do realmente e s una pr ue ba e n el s ent i do convenci onal del t rmi -
no? Expl i car la r es pues t a.
20.9. Descri bi r l os pa s os a s oc i a dos c on la pr ue ba de l as ba s e s de dat os pa r a una WebApp. La
pr ueba de l as ba s e s de dat os e s una act i vi dad pr e domi na nt e me nt e del l ado del cl i ent e o del la-
d o del ser vi dor ?
20. 10. Cul e s la di f er enci a e nt r e l as pr ue bas q u e e s t n a s oc i a da s con l os me c a n i s mo s de la
i nt er f az y l as pr ue ba s que a bor da n la s e m nt i c a de la i nt er f az?
20. 11. Suponer que s e est e n el desarrol l o de una f ar maci a e n lnea (Farmaci adel aEsqui na. com)
que i nt ent a s at i s f acer l os de s e os de paci e nt e s ger i t r i cos. La f ar maci a pr opor ci ona l as f unci o-
ne s us ual es , pe r o t ambi n ma nt i e ne una bas e de dat os par a cada cl i ent e de mo d o que pue de
of r e ce r i nf or maci n de me di c a me nt os y adver t enci as de pot enci al es i nt er acci ones r e s pe ct o de
me di c a me nt os . Come nt a r a l guna s pr ue ba s es peci al es de faci l i dad de us o par a e s t a WebApp.
20. 12. Supone r que s e ha i mpl e me nt a do una f unci n de veri fi caci n de i nt er acci n de me di -
c a me n t o s par a Far maci adel aEs qui na. com ( pr obl ema 20. 11). Exami ne l os t i pos pr ue ba s al ni vel
de c o mp o n e n t e q u e t endr an que l l evarse a c a bo pa r a gar ant i zar que est a f unci n t r abaj a de
ma n e r a a de c ua da . [Nota: Se t endr a que us ar una ba s e de da t os pa r a i mpl e me nt a r e s t a funci n. )
TM
PDF Editor
638 PAETE TRES APLICACIN DE LA INGENIERA WEB
20. 13. Cul e s la di f er enci a ent r e pr obar la si nt axi s de nave gaci n y pr obar la s e m nt i c a de
navegaci n?
20. 14. Es posi bl e pr obar cada conf i gur aci n que pr oba bl e me nt e e nc ue nt r e la WebApp en e. 1
l ado del ser vi dor ? En el l ado del cl i ent e? Si no, c mo un i ngeni er o Web sel ecci ona un conj ur - J
t o si gni f i cat i vo de pr ue ba s de conf i gur aci n?
20. 15. Cul e s el obj et i vo de l as pr ue ba s de segur i dad? Q ui n lleva a c a bo est a act i vi dad e \
pr ueba?
2 0 . 1 6 . Far maci adel aEs qui na. com ( pr obl ema 20. 11) s e ha vuel t o exi t osa y el n me r o de USL ]
ri os ha a u me n t a d o de ma n e r a si gni fi cat i va e n l os pr i mer os dos me s e s de oper aci n. Di buj e i
gr f i ca que mue s t r e el t i e mpo de r e s pue s t a pr obabl e c o mo f unci n del n me r o de us uar i os i
ra un c onj unt o fijo de r e cur s os e n el l ado del servi dor. Rot ul e la gr f i ca p a r a i ndi car punt os ;
i nt er s e n la "cur va de r espuest a".
20. 17. En r e s pue s t a a su xi t o, Far maci adel aEqui na. com ( pr obl ema 20. 11) ha i mpl ement i
un servi ci o especi al excl us i vament e pa r a ma ne j a r el r es ur t i do de r ecet as . En pr omedi o, 1
us uar i os concur r e nt e s gi ran una sol i ci t ud de r es ur t i do una vez cada dos mi nut os . La Web
des car ga un bl oque de dat os de 500 byt es c o mo r es pues t a. Cul e s la cant i dad de i nf or mac
apr oxi mada q u e s e neces i t a pr oces ar por una uni dad de t i empo par a es t e servi dor, en mega
por s e gundo?
2 0 . 1 8 . Cul e s la di f er enci a ent r e pr ue ba de car ga y pr ueba de t ens i n?
La l i t erat ura pa r a l as pr ue ba s de WebApps t odav a est e n evol uci n. Los l i bros de Ash (T he i
T esting Companion, Wiley, 2003), Dust i n y s us col e gas (Qualily Web Systems, Addi son- We
2002), Nguyen [NGU01| y Spl ai ne y Jaskiel (SPL01) s e e nc ue nt r a n ent r e l os que, publ i cados I
ta la f echa, pr e s e nt an l os t r at ami e nt os m s compl e t os del t e ma . Mosl ey (Cl ient-Server!
T esting on the D esklop and Ihe Web, Prent i ce-Hal l , 1999) a bor da a s unt os de pr ue ba t ant o en
l ado del cl i ent e c o mo e n el l ado del ser vi dor .
St ot t l emeyer (Aulomated Web T esting T oolkit, Wiley, 2001) pr e s e nt a i nf or maci n til acer ca :
l os m t odos y es t r at egi as e n la pr ueba de l as WebApps, asi c o mo un val i oso anl i si s de l as I
r r ami e nt as de pr ueba a ut oma t i z a da s . Gr aham y s us col e gas ( Sof t war e T est Aulomation, Addn
Wesley, 1999) pr e s e nt a n mat er i al adi ci onal acer ca de l as he r r a mi e nt a s a ut oma t i z a da s .
Nguyen y s us col egas (T esting Applications for the Web, s e gunda edi ci n, Wiley, 2003) i
r r ol l ar on u n a gr an act ual i zaci n [NGU01] y of r ecen una gu a ni ca pa r a pr obar aplicacic
mvi l es. Aunque Mi crosoft ( Perf ormance T esting Microsoft .N ET Web Applications, Mi cr
Pr ess, 2002) s e enf oca pr e domi na nt e me nt e e n su a mbi e nt e .NET, s us c ome nt a r i os ace r ca de .
pr ue ba s de d e s e mp e o pue de n s er t i l es pa r a cual qui er i nt er es ado e n la mat er i a.
Spl ai ne (T esting Web Security, Wiley, 2002), Kl evi nsky y s us col e gas (Hack I.T .:
T hrough Penelration T esting, Addi son- Wesl ey, 2002) , Chirillo (Hack Attacks Revealed, s eg
edi ci n, Wiley, 2003) y Skoudi s {Counter Hack, Prent i ce-Hal l , 2001) of r e ce n muc ha i nf or ma
til par a qui e ne s de be n di s ear pr ue ba s de s egur i dad.
En I nt er net est di sponi bl e una gr an var i edad de f ue nt e s de i nf or maci n ace r ca de l as |
ba s par a i ngeni er a Web. En el sitio Web de SEPA s e e nc ue nt r a una lista act ual i zada de refer
ci as en la World Wide Web:
ht t p: / / w w w . mhhe. com/ pr es s man
TM
PDF Editor
GESTI N DE PROYECTOS
DE SOFTWARE
E
n esta parte de Ingeniera del software: un enfoque prctico se
consideran las tcnicas de gestin necesarias para planear,
organizar, supervisar y controlar los proyectos de softw are.
En los captulos que siguen se abordan las siguientes preguntas:
Cmo se deben gestionar el personal, el proceso y los pro-
blemas durante un proyecto de softw are?
Cmo pueden emplearse las mtricas de softw are para ges-
tionar un proyecto de softw are y el respectivo proceso?
Cmo se estiman el esfuerzo, el costo y la duracin del pro-
yecto?
Q u tcnicas pueden aplicarse para evaluar formalmente los
riesgos que pueden incidir en el xito del proyecto?
Cmo selecciona un gestor de proyectos un conjunto de ta-
reas de trabajo de ingeniera del softw are?
Cmo se crea el programa cronolgico de un proyecto?
Q u es la gestin de calidad?
Por qu son tan importantes las revisiones tcnicas forma-
les?
Cmo se gestionan los cambios durante el desarrollo del
softw are de computadora y despus de entregarlo al cliente?
Una vez que se respondan estas preguntas se estar mejor pre-
parado para gestionar proyectos de sortw are en una forma que
conducir a la entrega puntual de un producto de alta calidad.
639
TM
PDF Editor
C A P I T U L O
~ k .
2
1
L
1
C O N C E P T O S
CL AVE
mbi to del
af t w ar e . . 6 5 1
coordinacin . . . 6 S 0
descomposi ci n
del probl ema . . 6 5 2
e q u i p a d .
s o f t w a r e . . . . . 6 4 5
equi pos
gi l es . . 6 4 9
l deres de
EQUIPO . . 6 4 4
parti ci pantes . . 6 4 4
personal . . 6 4 3
prcticas
. . 6 5 8
principio
WSHH . . 6 5 /
proceso . . . . . . 6 5 3
proyect o . . . . . 6 8 6
CONCEPTOS DE
GESTIN DE PROYECTOS
E
n el prefaci o de su libro acerca de la gestin de proyect os de soft w are, Me
ler Page-Jones [PG85J hace una afi rmaci n a la que pueden sumar se mu
chos asesor es en ingeniera del sof t w ar e:
He vi si t ado doc e na s de t i endas comer ci al es , t ant o b u e n a s c o mo mal as , y h e obser -
va do r egi st r os de ge r e nt e s de pr oc e s a mi e nt o de dat os , de nue vo t ant o b u e n o s com
mal os . Con mu c h a f r ecuenci a h e vi st o c on hor r or c o mo di chos ge r e nt e s l uchabar
i nt i l ment e c on pr oyect os de pesadi l l a, s uf r i e ndo por f e c ha s l mi t es i mposi bl es o sis-
t e ma s e nt r e ga dos q u e i ndi gnar on a s us us ua r i os y de vor ar on e n o r me s c a nt i da de s de
t i empo de mant e ni mi e nt o.
Lo que Page-Jones descri be son s nt omas que resul t an de una serie de prob
mas de gest i n y tcnicos. Sin embar go, si se realizara una aut opsi a de cac
proyect o, es muy probabl e que se encont r ar a un t ema consi st ent e: la gestin
proyect o fue dbil.
En est e captulo, y en l os seis si gui ent es, se consi deran los concept os ca i
que conducen a una gestin efectiva de proyect os de soft w are. Este cap:
consi dera concept os y pri nci pi os bsi cos de gestin de proyect os de sof t w a re-
capitulo 22 pr esent a mt ri cas del pr oceso y del proyecto, la bas e par a una e:V
tiva t oma de deci si ones de gest i n. En los cap t ul os 23 y 24 se anal i zan las t e
ni cas con que se est i man, s e defi ne un cal endari o realista y se est abl ece un r :
efect i vo par a el proyecto. En el captulo 25 se pr esent an l as act i vi dades de ge
tin que conducen a una efectiva supervi si n, reducci n y gestin del riesgo. F
nal ment e, en los captulos 26 y 27 se consi deran t cni cas par a asegur ar la c*
dad conf or me un proyect o se lleva a cabo y se gest i onan los cambi os a lo lar
de la vida de una aplicacin.
Qu e s ? Aunque muchos (en sus
momentos ms oscuros) toman la
visin de "gestin" de Dilberl, sigue
siendo una actividad muy necesaria
cuando se construyen sistemas y
productos basados en computadoras. La ges-
tin de proyectos involucra la planificacin,
supervisin y control del personal, el proceso y
los eventos que ocurren mientras el softw are
evoluciona desde un concepto preliminar hasta
una implementacin operativa.
Qui n l o hac e ? Todos "gestionan" en cierta
medida, pero el mbito de las actividades de
gestin vara entre las personas involucradas
en un proyecto de softw are. Un ingeniero de
softw are gestiona sus actividades diarias, y
planifica, supervisa y controla las labores tcni
cas. Los gestores de proyecto planifican, super-
; visan y controlan el trabajo de un equipo de
:: ingenieros de softw are. Los gestores ejecutivos
coordinan la relacin entre el negocio y los
profesionales del softw are.
Por qu e s i mport ant e? La construccin de
softw are de computadora es una empresa com
pleja, en particular si involucra a mucha gente
que trabaja durante un tiempo relativamente
TM
PDF Editor
CAP TULO 2 1 CONCEPTOS DE GESTIN DE PROYECTOS
641
largo. Por esto los proyectos de softw are nece-
sitan ser gestionados. |
. Cul es s on l os p a s o s ? Comprender las cua-
ro P: personal, producto, proceso y proyecto.
El personal debe estar organizado para reali-
zar el trabajo de softw are con efectividad. La
comunicacin con el cliente y otros participan-
tes debe ocurrir de modo que sean comprensi-
bles el mbito y los requisitos del producto. Se
debe seleccionar un proceso adecuado para el
personal y el producto. El proyecto se debe
planificar para estimar el esfuerzo y el tiempo
para cumplir las labores del trabajo: definir
productos de trabajo, establecer puntos de con-
trol de calidad e identificar mecanismos para
supervisar y controlar el trabajo definido al
planificar.
Cul es el producto obteni do? Cuando
comienzan las actividades de gestin se produ-
ce un plan del proyecto. El plan define el pro-
ceso y las labores que se llevarn a cabo, el
personal que har el trabajo y los mecanismos
para valorar los riesgos, controlar los cambios
y evaluar la calidad.
Cmo puedo estar seguro de que l o he
he c ho correct ament e? Nunca se est
completamente seguro de que el plan del proyec-
to es correcto hasta que haya entregado un pro-
ducto de alta calidad a tiempo y dentro del presu-
puesto. Sin embargo, un gestor de proyecto hace
lo correcto cuando alienta al personal de softw are
a trabajar en conjunto como un equipo efectivo, y
enfoca su atencin tanto en bs necesidades del
cliente como en b calidad del producto.
2 1 , 1 EL ESPECTRO DE LA GESTI N
La gestin efi caz de la gestin de proyect os de sof t w ar e se enf oca sobr e l as cuat r o
P: personal, producto, proceso y proyecto. El orden no es arbitrario. El gest or que ol-
vida que el t rabaj o de ingeniera del sof t w ar e e s una empr esa i nt ensament e huma-
na nunca t endr xito en la gestin de proyect os. Un gest or que fracasa en al ent ar
la comuni caci n amplia con l os part i ci pant es en et apas t empr anas de la evolucin
de un proyect o se arriesga a const rui r una solucin el egant e para el pr obl ema equi-
vocado. El gest or que prest a poca at enci n al pr oceso corre el riesgo de colocar m-
t odos y her r ami ent as t cni cos compet ent es en el vaco. El gest or que se embar ca sin
un pl an de proyect o slido arri esga el xito del product o.
21.1.1 El personal
La formaci n de personal de sof t w ar e mot i vado y al t ament e calificado se ha debati-
do desde los aos 60 del siglo pas ado (por ej empl o, [COU80], [WIT94], [DEM98]). De
hecho, el "factor humano" es tan i mport ant e que el Soft w are Engineering Institute ha
desarrol l ado un model o de madur ez de la capaci dad de gestin de personal (MMCGP)
par a "aument ar la rapi dez con la cual l as organi zaci ones de sof t w ar e acomet en las
apl i caci ones cada vez ms compl ej as al ayudar a atraer, aument ar , motivar, despl e-
gar y ret ener el t al ent o necesari o par a mej orar su capaci dad de desarrol l o de sof t w a-
re" [CUR94].
El model o de madur ez de gestin de personal defi ne l as si gui ent es r eas cl ave
prct i cas par a el per sonal de sof t w ar e recl ut ami ent o, seleccin, gest i n del des em-
TM
PDF Editor
642 PARTE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
^ O H S E J O ^
En este contex to, el
trmino producto se
emplea para ahorcar
cualquier software
que se construye a
solicitud de otros. N o
slo incluye productos
de software estandari-
zado, sino tambin
sistemas basados en
computadoras, soft-
ware anidado, Web-
Apps y software de
resolucin de proble-
mas (por ejemplo,
programas para reso-
lucin de problemas
de ingeniera y cient-
ficos).
^ O N S E J O ^
Quienes se adhieren o
la filosofa del proceso
gil (captulo 4 ) argu-
mentan que sus proce-
sos son ms magros
que otros. Esto puede
ser cierto, pero ellos
todava tienen un pro-
ceso, y la ingeniera
de software gil toda-
a requiere disciplino.
peo, ent r enami ent o, retribucin, desarrol l o de la carrera, di seo de la organi zaci n
y el t rabaj o, y desarrol l o de la cul t ura de equi po. Las or gani zaci ones que l ogran al-
t os ni vel es de madur ez en el r ea de gest i n de per sonal t i enen una mayor probabi-
lidad de i mpl ement ar efect i vas prct i cas de i ngeni er a del sof t w ar e.
El MMCGP e s compaer o de la Int egraci n del Model o de Madurez de la Capaci-
dad de Sof t w ar e (captulo 2) que gua a l as or gani zaci ones en la creaci n de un pr o
ceso de sof t w ar e madur o. Ms adel ant e en est e captulo se consi deran t pi cos asocia-
dos con la gest i n del per sonal y la est ruct ura de los proyect os de sof t w ar e.
21.1.2 El producto
Ant es de pl anear un proyect o se deber an est abl ecer los obj et i vos y el mbi t o de
product o, consi der ar sol uci ones al t ernat i vas e identificar las rest ri cci ones t cni cas y
de gestin. Sin est a i nformaci n es i mposi bl e definir est i maci ones r azonabl es (y pre-
cisas) del cost o, una val oraci n efectiva del riesgo, una divisin real i st a de l as t ar ea;
del proyect o o un cal endar i o de proyect o manej abl e que of r ezca una i ndi caci n fia
ble del progreso.
El desarrol l ador del sof t w ar e y el cliente se deben reunir para definir l os objetivos
y el mbi t o del product o. En muchos casos, est a actividad comi enza como par t e de
la i ngeni er a del si st ema o de la i ngeni er a del pr oceso de negoci o (captulo 6) y con-
t i na como el pri mer pas o en la i ngeni er a de requi si t os de s of t w ar e (captulo 7). Los
obj et i vos identifican las met as gl obal es del pr oduct o (desde el punt o de vista de.
cliente) sin consi derar cmo se l ograrn. El mbi t o identifica los dat os pri mari os, las
f unci ones y los compor t ami ent os que car act er i zan al pr oduct o y, m s i mport ant e, los
i nt ent os por enl azar t al es caract er st i cas en una f or ma cuant i t at i va.
Una vez ent endi dos los obj et i vos y el mbi t o del pr oduct o se consi der an solucio-
nes al t ernat i vas. Aunque se t rat a r el at i vament e poco detalle, l as al t ernat i vas posibi-
litan que los gest or es y pract i cant es sel ecci onen un "mej or" enf oque, cumpl an las
rest ri cci ones que i mponen las f echas l mi t es de ent r ega, las rest ri cci ones pr esupues-
tarias, la disponibilidad del personal , las i nt er f ases t cni cas y mi l es de fact ores ms.
21.1.3 El proceso
Un pr oceso de sof t w ar e (captulos 2, 3 y 4) proporci ona el mar co de t r abaj o desde e!
cual se puede est abl ecer un plan det al l ado para el desarrol l o del sof t w ar e. Un peque-
o nme r o de act i vi dades del mar co de t r abaj o e s apl i cabl e a t odos los proyect os de
sof t w ar e, sin i mport ar su t a ma o o compl ej i dad. Al gunos conj unt os de t ar eas dife-
r ent es (tareas, hitos, pr oduct os de t r abaj o y punt os de cont rol de calidad) permi t en
que las act i vi dades del mar co de t r abaj o se adapt en a l as caract er st i cas del proyec-
to de softw are, as como a los requisitos del equi po del proyecto. Finalmente, las activi-
dades prot ect oras (como el control de calidad del softw are, la gestin de configuracin
del soft w are y la medicin) cubren el model o del proceso. Las actividades prot ect oras
son i ndependi ent es de cual qui er actividad del mar co de t r abaj o y ocurren dur ant e to-
do el pr oceso.
TM
PDF Editor
CAP TULO 21 CONCEPTOS DE GESTIN DE PSCYECTOS 643
21.1.4 El proyecto
Los pr oyect os de s of t w a r e s e r eal i zan de ma ne r a pl ani f i cada y cont r ol ada por una
r azn pri nci pal : e s la ni ca f or ma conoci da de ges t i onar la compl ej i dad. I ncl uso l os
e s f ue r z os cont i nuar n. En 1998, l os da t os i ndust r i al es i ndi car on que el 26 por ci en-
t o de l os pr oyect os de s of t w a r e f r acas ar on por compl et o, y que el 46 por ci ent o re-
ba s a r on s us c os t os y y t i empos de ent r ega [REE99]. Aunque la t asa de xi t o par a l os
pr oyect os de s of t w a r e ha me j or a do un poco, la t as a de f r acas o de pr oyect os pe r ma-
ne c e m s el evada de lo que debi er a. '
"Un pr oyect o e s c omo un vi aj e por car r et er o. Al gunos pr oyect os son si mpl es y r ut i nar i os, como conducir haci a la t i en-
da a pl eno luz del d a. Per o la mayor a d e los pr oyect os que val e la pe na r eal i zar son m s par eci dos o conducir un ca-
mi n n So car r et er a, en la mont a a , d e noche. "
Cent Koner, J o me s Bach y Br et Pet t i chor d
Para evi t ar el f r acas o del pr oyect o, un gest or de pr oyect o de s of t w a r e y l os i nge-
ni er os de s of t w ar e que cons t r uyen el pr oduct o de be n el udi r un c onj unt o de s e a l e s
de adver t enci a c omune s , c ompr e nde r l os f act or es de xi t o cr t i cos q u e c onduc e n a
una bue na gest i n del pr oyect o y desar r ol l ar un e nf oque de s e nt i do c o m n par a pl a-
ni fi car, s uper vi s ar y cont r ol ar el pr oyect o. Cada u n o de es t os t pi cos s e t r at an en la
secci n 21. 5 y en l os cap t ul os si gui ent es.
En un e s t udi o que publ i c el IEEE [CUR88] s e l es pr e gunt a l os vi cepr es i dent es de
i ngeni er a de t r es gr a nde s c ompa a s t ecnol gi cas cul er a el cont r i buyent e m s im-
por t ant e pa r a un pr oyect o de s of t w a r e exi t oso. Res pondi er on de la s i gui ent e f or ma:
VP I: Supongo que si tienes que escoger alguna cosa que sea la ms importante en nues-
tro ambiente, yo dira que no son las herramientas que utilizamos, es la gente.
VP 2: El ingrediente ms importante que fue exitoso en este proyecto fue el tener gente
inteligente... en mi opinin, muy pocas cosas importan ms. . . La cosa ms importante que
puedes hacer por un proyecto es seleccionar al equipo. .. El xito de la organizacin de de-
sarrollo de softw are est muy asociado con la habilidad de reclutar buen personal
VP 3: La nica regla que tengo en la gestin es asegurarme que tengo buen personal, ver-
dadero buen personal, y que hago crecer al buen personal, y que proporciono un ambien-
te en el que el buen personal puede producir
1 Dadas estas estadsticas, es razonable preguntar cmo el impacto de las computadoras contina
creciendo exponencialmente. El autor considera que parte de la respuesta es que un nmero sus-
tancial de estos proyectos "fallidos" estuvo, en pnmer lugar, mal concebido Los clientes pierden in-
ters rpidamente (porque el producto solicitado - o tue en realidad tan importante como lo que
pensaron primero) y los proyectos se cancelar
TM
PDF Editor
644 PARTE CUATRO GESTI N DE PROYECTOS DE SOFTWARE
De hecho, st e es un t est i moni o convi ncent e acerca de la importancia del personal
en los pr ocesos de ingeniera del soft w are. Y sin embargo, t odos, desde los vicepre-
si dent es de ingeniera hast a el profesi onal m s modest o, usual ment e no prest an
at enci n al personal . Los gest ores ar gument an (como lo hace el grupo anterior) que
las per sonas son lo principal, pero sus acci ones con frecuenci a cont radi cen s us pa-
labras. En est a secci n se exami nan los part i ci pant es en el proceso de sof t w ar e y la
forma en que se les organi za para realizar una ingeniera de sof t w ar e efectiva.
21.2.1 Los participantes
El proceso de sof t w ar e (y cualquier proyect o de soft w are) lo integran participantes
que pueden clasificarse dent r o en una de ci nco cat egor as:
1. Gestores ejecutivos, que defi nen los aspect os del negoci o que usual ment e tie-
nen una influencia significativa en el proyecto.
2. Gestores (tcnicos) del proyecto, qui enes planifican, mot i van, organi zan y con-
trolan a los profesi onal es que realizan el t rabaj o de soft w are.
3. Profesionales, qui enes proporci onan las habi l i dades t cni cas necesar i as para
realizar la ingeniera de un product o o aplicacin.
4. Clientes, qui enes especifican los requisitos para la ingeniera del sof t w ar e y
ot ros el ement os que tienen un inters m ni mo en el resul t ado.
5. Usuarios finales, qui enes i nt eract an con el sof t w ar e una vez que se libera pa-
ra su uso productivo.
Todo proyect o de sof t w ar e lo integran per sonas que se clasifican en est a t axono-
ma. 2 Para ser eficaz, el equi po de proyect o debe est ar or gani zado en una forma que
maxi mi ce las capaci dades y habi l i dades de cada persona. Y esta es la labor del lde-
del equipo.
21.2.2 Lderes de equipo
La gestin del proyect o es una actividad i nt ensament e humana; por tanto, los profe-
sionales compet ent es con frecuencia no son buenos lderes de equipo. Simplemente r. :e
tienen la mezcl a correcta de habi l i dades con el personal . Adems, como Edgemcnj
afirma: "Desafort unadament e, y con demasi ada frecuenci a, los individuos simple
ment e caen en un papel de gest or de proyect o y se vuel ven gest ores de proyect o a:-l
cidentales" [EDG95],
En un excel ent e libro acerca del liderazgo tcnico, Jerry Weinberg [WE186] sugie-l
re un model o MOI de liderazgo:
Mot i vaci n. La habilidad para al ent ar (medi ant e "empuj e o jaln") al per so
tcnico para que pr oduzca segn su mej or capaci dad.
2 Cuando se desarrollan las aplicaciones Web (Parte 3 de este libro), en la creacin de contenido
den involucrarse otras personas no tcnicas.
TM
PDF Editor
C A P T U L O 2 1 CONCEPTOS DE GESTIN DE PROYECTOS 645
M buj. Organi zaci n. La habilidad para adecuar los procesos exi st ent es (o inventar
D unos nuevos) que permitirn que el concept o inicial sea t raduci do en un product o fi-
i alguien n a [
ra
2 Ideas o i nnovaci n. La habilidad para al ent ar a la gent e a crear y sentir creati-
vament e, incluso cuando deben t rabaj ar dent r o de los lmites est abl eci dos por un
product o o aplicacin de sof t w ar e particular.
Weinberg sugiere que los lderes de proyect o exi t osos apl i can un estilo de gestin
de resolucin de probl emas. Esto es: un gest or de proyect o de sof t w ar e debe con-
cent rarse en ent ender el probl ema que ser resuelto, gest i onar el flujo de ideas y, al
mi s mo tiempo, hacer que t odos los que forman el equi po conozcan (con pal abras y,
mucho ms i mport ant e, con acciones) que la calidad es rel evant e y que no ser com-
promet i da.
"En los trminos ms simples, un lder es aquel que sobe odnde qui ere ir, y se levanta y va. "
John Erskine
Otra visin [EDG95] de las caract er st i cas que defi nen un gest or de proyect o efi-
ci ent e resalta cuat ro rasgos clave:
Res ol uci n de probl emas . Un gest or de sof t w ar e eficiente puede di agnost i car
los conflictos t cni cos y organi zat i vos ms relevantes, est ruct urar de maner a siste-
mtica una solucin o motivar adecuadament e a ot ros profesi onal es par a desarro-
llar la solucin, aplicar en las nuevas si t uaci ones las l ecci ones apr endi das en proyec-
tos pasados, y mant ener se lo sufi ci ent ement e flexible como para cambi ar de direc-
cin si los i nt ent os iniciales en la solucin del probl ema son infructuosos.
Dot e s de ges t i n. Un buen gestor de proyect o debe encabezar l o y dirigirlo. De-
be t ener la confi anza de asumi r el control cuando es necesari o y la seguridad para
permitir que los buenos profesi onal es t cni cos sigan sus instintos.
Incent i vos. Para opt i mi zar la productividad de un equi po de proyecto, un gestor
debe r ecompensar la iniciativa y los logros; adems, demost rar con s us propi as ac-
ci ones que la t oma de riesgos cont rol ada no ser penal i zada.
Infl uenci a y f ome nt o de l a cul tura de equi po. Un gest or de proyect o efi caz
debe ser capaz de "leer" a la gente; de ent ender las seal es verbal es y no verbal es y
reacci onar a las necesi dades de la gent e que las enva. El gest or debe mant ener el
control en si t uaci ones de alta t ensi n emoci onal .
21.2.3 El equipo de softw are
Existen casi t ant as est ruct uras organi zaci onal es de profesi onal es para el desarrol l o
de sof t w ar e como organi zaci ones que tiene el mi smo fin. Para bien o para mal, la
est ruct ura organi zaci onal no puede ser fci l ment e modificada. Las pr eocupaci ones
acerca de las consecuenci as prct i cas y polticas del cambi o organi zaci onal no es-
TM
PDF Editor
6 4 6 PARTE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
t n dent r o del mbi t o de r es pons abi l i dad del gest or del pr oyect o de s of t w ar e. S " |
e mbar go, la or gani zaci n de la ge nt e di r ect ament e i nvol ucr ada en un pr oyect o o? I
s of t w a r e est dent r o del mbi t o del gest or del pr oyect o.
"No todo grupo es un equipo, y no todo equipo es eficiente."
Gl enn Par ker
9 Q u
w t act or e s se
de be n cons i der ar
cuando se el i ge la
es t r uct ur a de un
equi po de
s o f t w a r e ?
La "mej or " es t r uct ur a de equi po de pe nde del est i l o de gest i n de cada o r g a n i z a !
ci n, del n me r o de pe r s ona s que i nt egr ar n el equi po y de s us gr ados de habi l i dadl
as c o mo de la di fi cul t ad gl obal del pr obl ema. Mant ei [MAN81] descr i be si et e f act : - l
r es de pr oyect o que deber an cons i der ar s e c ua ndo s e pl ani fi ca la es t r uct ur a de 1: J
e qui pos de i ngeni er a del s of t w ar e:
La di fi cul t ad del pr obl e ma que s e r esol ver .
El " t amao" del pr ogr ama( s ) r esul t ant e( s) en l neas de cdi go o punt os de f u n l
cin (cap t ul o 22).
El t i empo que el equi po es t ar j unt o (vida del equi po) .
El gr ado en el que el pr obl e ma puede s e par ar s e en mdul os .
La cal i dad y confi abi l i dad r equer i dos del s i s t e ma que s e const r ui r .
La rigidez de la f echa de ent r ega.
El gr a do de soci abi l i dad ( comuni caci n) que r equi er e el pr oyect o.
"Si quiere ser codo vez mejor: seo competitivo. Si quiere ser exponenciolmente mejor: seo cooperativo."
Annimo
9 ! 0
opci ones s e
t i enen cuando
se def i ne la
e s t r uct ur a de un
equi po de
s o f t w a r e ?
Cons t ant i ne [CON93] sugi er e cuat r o "par adi gmas or gani zaci onal es " par a l os e q i i l
p o s de i ngeni er a del s of t w ar e:
1. Un paradigma cerrado es t r uct ur a un equi po a lo l argo de una j er ar qu a tradi-
ci onal de aut or i dad. Est os e qui pos pue de n t r abaj ar me j or c ua ndo pr oducen
s of t w a r e muy si mi l ar a l os pr oyect os ant er i or es , pe r o s er me n o s pr obabl e
que s e an i nnovador e s c ua ndo t r abaj en dent r o del par adi gma cer r ado.
2. Un paradigma aleatorio es t r uct ur a un equi po l i br ement e y de pe nde de la ini- I
ci at i va i ndi vi dual de los mi e mbr os del equi po. Cuando s e r equi er en i nnova-
ci n o ade l ant os t ecnol gi cos, los equi pos que s i guen el par adi gma a l e a t on: I
s er n excel ent es . Pero es t os e qui pos pue de n l uchar c ua ndo s e r equi er e "de-
s e mp e o or denado".
3. Un paradigma abierto i nt ent a es t r uct ur ar un equi po e n u n a f or ma que l ogre aC|
gunos d e l os cont r ol es as oci ados con el par adi gma cer r ado, per o t ambi n
muc ha de la i nnovaci n que ocur r e c ua ndo s e apl i ca el par adi gma al eat or i : I
TM
PDF Editor
CAPITULO 21 CONCEP TOS DE GESTI N DE PROYECTOS 647
El t r abaj o s e desar r ol l a en col abor aci n. La sl i da comuni caci n y la t oma de
deci s i ones bas ada en el c ons e ns o s on l as ma r c a s car act er s t i cas de l os equi -
pos de par adi gma abi ert o. Las es t r uct ur as de equi po de par adi gma abi er t o s e
a de c a n bi en a la sol uci n de pr obl e ma s compl ej os , pe r o no pue de n de s e m-
pe a r s e de ma ne r a t an ef i ci ent e c o mo ot r os equi pos .
4 . Un paradigma sincrnico s e apoya en la compar t i ment al i zaci n nat ur al de un
pr obl ema y or gani za a l os mi e mbr os del equi po par a t r abaj ar en par t es del pr o-
bl ema con poca comuni caci n act i va ent r e el l os.
"Trab ajar con la g ante es difi cil, mas no imposible."
Pe l e r Drucker
Como not a hi st ri ca, una de l as pr i me r as or gani zaci ones de l os equi pos de sof t -
w a r e f ue una est r uct ur a de par adi gma ce r r ado or i gi nal ment e l l amada equipo progra-
mador jefe. Esta est r uct ur a la pr opus o or i gi nal ment e Har an Mills y la descr i bi Baker
[BAK72]. El ncl eo del equi po lo c ompone un ingeniero ejecutivo (el pr ogr amador je-
fe), qui en pl ani fi ca, coor di na y revi sa t odas l as act i vi dades t cni cas del equi po; perso-
nal tcnico (por lo gener al , de dos a ci nco per s onas ) , qui e ne s di ri gen l as act i vi dades
de anl i si s y desar r ol l o; y un ingeniero de respaldo, qui en apoya al i ngeni er o ej ecut i -
vo en s u s act i vi dades y pue de r eempl azar l o con m ni ma pr di da en la cont i nui dad del
proyect o.
Al pr ogr amador j ef e pue de n asi st i rl o u n o o m s especialistas (por ej empl o, exper -
t os en t el ecomuni caci ones , di s eador de ba s e s de dat os) , personal de apoyo (por
ej empl o, es cr i t or es t cni cos, per s onal admi ni st r at i vo) y un bibliotecario de software.
Como cont r apar t e a la es t r uct ur a de equi po pr ogr a ma dor j efe, el par adi gma al ea-
t ori o de Cons t ant i ne [CON93] sugi er e un e qui po de s of t w a r e con i nde pe nde nci a
cr eat i va cuyo e nf oque par a t r abaj ar pue de de nomi na r s e me j or c o mo anarqua inno-
vadora. Aunque s e ha a pe l a do al e nf oque de libre esp ri t u par a el t r abaj o d e s of t w a-
re, la canal i zaci n de la ener g a cr eat i va haci a un equi po d e al t o r endi mi ent o de be
s er una me t a cent r al en una or gani zaci n de i ngeni er a del s of t w ar e . Para l ograr un
equi po de al t o r endi mi ent o:
Los mi e mbr os del e qui po de be n t ener s e mut ua conf i anza.
La di st ri buci n de l as habi l i dades de be ade cuar s e al pr obl ema.
Tal ve z l os di s i dent es de ba n s er excl ui dos del e qui po si ha de cons e r var s e s u
cohes i n.
Sin i mpor t ar la or gani zaci n del equi po, el obj et i vo de cual qui er ge r e nt e de pr oyec-
t o e s apoyar la cr eaci n de un e qui po q u e mue s t r e cohes i n. En su libro, Peoplewa
re, DeMar co y Lister [DEM98] e xa mi na n es t e t pi co:
Tendemos a usar la palabra equipo con bastante libertad en el mundo de los negocios, y
llamamos "equipo" a cualquier grupo de personas asignadas a trabajar juntas. Pero mu-
chos de estos grupos no parecen equipos No tienen una definicin comn de xito o al-
Q u e s un
equi po
"?
TM
PDF Editor
PARTE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
gn espritu de equipo identificable. Lo que s e ha perdi do es un f enmeno que l l amamos
cuajar (jell).
Un equi po cuaj ado es un grupo de per sonas tan f uer t ement e uni do que el t odo es ma-
yor que la s uma de las partes. . .
Una vez que un equi po comi enza a cuaj ar, la probabilidad de xito aument a. El equi-
po puede volverse imparable, un monst r uo destructivo para lograr el xito... No necesita
ser gest i onado en la forma tradicional, y ci ert ament e no necesita ser motivado. Tiene m-
petu.
DeMar co y Lister s os t i enen que l os mi e mbr os de l os e qui pos c ua j a dos s on significa-
t i vament e m s pr oduct i vos y e s t n m s mot i vados que el pr omedi o. Compar t en una
me t a c omn, una cul t ur a c omn y, en mu c h o s cas os , un "s ent i mi ent o elitista" que
l os ha c e ni cos.
Per o no t odos l os equi pos cuaj an. De hecho, mu c h o s e qui pos s uf r en de lo que
J ackman [JAC98] de nomi na "t oxi ci dad de equi po". Ella def i ne ci nco f act or es que "fo-
me nt a n un a mbi e nt e de equi po pot e nci al me nt e txico": 1) una a t ms f e r a de traba] :
f r ent i ca, 2) al t a f r ust r aci n que pr ovoca fri cci n ent r e l os mi e mbr os del equi po, 3)
un pr oce s o de s of t w a r e " f r agme nt ado o pobr e me nt e coor di nado", 4) una defi ni ci n
poc o cl ar a de los pape l e s del e qui po de s of t w ar e, y 5) "cont i nuas y r epet i das expos:
ci ones al f r acaso".
Para evi t ar un a mbi e nt e de t r abaj o f r ent i co, el gest or del pr oyect o de be t ener la
cer t eza de que el e qui po t i ene a c c e s o a t oda la i nf or maci n r equer i da par a real i zar
el t r abaj o y que l as me t a s y obj et i vos, una vez def i ni dos, n o de be n modi f i car s e a me-
nos que s ea a bs ol ut a me nt e neces ar i o. Un equi po de s of t w ar e pue de evi t ar la frust ra-
cin (y el est r s) si s e le da t ant a r es pons abi l i dad en la t oma de deci s i ones c o mo s ea
posi bl e. Un pr oces o i na de c ua do (por ej empl o, t ar eas de t r abaj o i nneces ar i as o abr u-
ma dor a s o pr oduct os de t r abaj o mal el egi dos) s e pue de evi t ar si s e c ompr e nde el
pr oduct o que se const r ui r y al per s onal que r eal i za el t r abaj o, y al per mi t i r al equi -
po s el ecci onar s u pr opi o mode l o de pr oces o. El equi po de be es t abl ecer por s mi s mo
me c a ni s mos par a s u r es pons abi l i dad (revi si ones t cni cas f or mal e s y la pr ogr ama-
ci n por par es s on excel ent es f or ma s de l ograrl o) y defi ni r una seri e de e nf oq ue s co-
rrect i vos c ua ndo un mi e mbr o del e qui po falle en s u de s e mpe o. Y, finalmente, la cla-
ve par a evi t ar una at ms f e r a de f r acas o e s es t abl ecer t cni cas b a s a d a s en el equi po
par a la r eal i ment aci n y r esol uci n de pr obl emas .
"Hacer o no hacer. No exi st e i nt ent ar . "
Yo d a , d e Star Wors
Ade m s de l as ci nco t oxi nas que descr i be J ackman, un equi po de s of t w ar e usual -
me nt e e nf r e nt a l os di f er ent es r as gos h u ma n o s de s us mi e mbr os . Al gunos mi embr os
del equi po s on ext r over t i dos; ot r os, i nt rovert i dos. Al gunas pe r s ona s r ecopi l an infor-
maci n i nt ui t i vament e; s e pa r a n l os conce pt os ampl i os de l os he c hos di spar at ados.
TM
PDF Editor
C A P T U L O 2 1 CONCEPTOS DE GESTIN DE PROYECTOS 649
Ot r os pr ocesan la i nf or maci n Ii neal ment e, r enen y or gani zan det al l es mi nuci osos
de los dat os pr opor ci onados. Al gunos mi embr os del equi po se si ent en cmodos al
t omar deci si ones sl o cuando se pr es ent a un or denado ar gument o lgico. Ot ros son
intuitivos, por lo que des ean t omar deci si ones con bas e en el "sent i mi ent o". Al gunos
pr of esi onal es prefi eren una pl ani fi caci n det al l ada que incluya t ar eas or gani zadas
que l es per mi t an lograr el ci erre de al gn el ement o del proyect o. Ot r os prefi eren un
ambi ent e m s es pont neo en el que los t e mas abi er t os s on bien vistos. Al gunos t ra-
baj an dur o par a hacer que l as cos as est n listas mucho ant es de una f echa lmite, y
por consi gui ent e evitan la t ensi n conf or me la fecha se aproxi me, mi ent r as que
ot r os se si ent en vi gori zados por la prisa de lograrlo en el l t i mo mi nut o del pl azo.
Un examen det al l ado de la psicologa de es t os r asgos y las f or mas en l as cual es el l-
der exper i ment ado del equi po puede ayudar a la gent e con r asgos opues t os par a t ra-
baj ar en conj unt o est m s all del mbi t o de es t e libro.3 Sin embar go, es i mpor t an-
te des t acar que el r econoci mi ent o de l as di ferenci as huma na s es el pri mer pas o ha-
cia la creaci n de equi pos que cuaj an.
21.2.4 Equipos giles
En aos reci ent es se ha pr opuest o el desarrol l o del s of t w ar e gil (captulo 4) como
ant dot o par a muc hos de los pr obl emas que perj udi can el t r abaj o de l os proyect os de
sof t w ar e. En sntesis, la filosofa gil al i ent a la sat i sfacci n del cliente y la t empr ana
ent r ega i ncrement al de sof t w ar e; pequeos equi pos de t r abaj o e nor me me nt e moti-
vados; mt odos i nformal es; m ni mos pr oduct os de t r abaj o de ingeniera del sof t w a-
re; y simplicidad global de desarrol l o.
El pequeo equi po de t r abaj o e nor me me nt e mot i vado, t ambi n l l amado equipo
gil, adopt a muchas caract er st i cas de los equi pos de pr oyect o de s of t w ar e exi t osos
t r at ados en la secci n pr ecedent e y evi t an muchas de l as t oxi nas que crean probl e-
mas. Sin embar go, el enf oque gil subr aya la compet enci a individual (mi embros del
equi po) en conj unci n con la col aboraci n del gr upo como f act or es de xito cruci a-
les para el equi po. Cockburn y Highsmith [COCOl] des t acan es t o cuando escri ben:
Si el pe r s onal e n el pr oyect o e s l o s uf i ci ent ement e bue no, pue de n us ar casi cual qui er pr o-
ce s o y l ogr ar s u comet i do. Si n o e s lo s uf i ci ent ement e bueno, ni ngn pr oce s o r epar ar s u
i ncapaci dad: "per s ona ma t a pr oces o" e s una f or ma de deci r est o. Sin e mba r go, la fal t a de
apoyo del us uar i o y el ej ecut i vo pue de n ani qui l ar un pr oyect o: "poltica mat a per s ona". El
apoyo i na de c ua do pue de i ncl uso evi t ar que el bue n per s onal l ogr e la t ar ea. . .
Para apr ovechar en f or ma efi ci ent e las compet enci as de cada mi embr o del equi-
po y f oment ar la col abor aci n efi caz a lo l argo de un proyect o de sof t w ar e, los equi -
pos giles son autoorganizados. Un equi po aut oor gani zado no neces ar i ament e man-
3 Una excel ent e introduccin a es t os t emas, r e l a t a d por equi pos de proyect o de soft w are, se puede
encont rar en [FER98].
TM
PDF Editor
6 5 0 PARTE CUATRO GESTI N DE PROYECTOS DE SOFTWARE
t i ene una sol a es t r uct ur a de equi po, s i no que m s bi en apr ove cha e l e me nt os de l a
pa r a di gma s al eat or i o, abi er t o y s i ncr ni co de Cons t ant i ne t r at ados e n la s e c c i c ^
21. 2. 3.
" t a pr opi edad colectiva no e s ms que una partk ularizacin de la i deo de que los pr oduct os de be n ser at r i bui bl es al
e q u i p o [ g i l ] , n o a i os i ndi vi duos que integraron el equipo."
Ji m Hi ghsmi t h
CLAVE
Un equipo gil es un
equipo autoorganizodo
que tiene autonoma
poro ploneor y tomar
decisiones tcnicas.
Muchos mode l os de pr oce s o gil (por ej empl o, Ser um) br i ndan al e qui po gil una
a ut onom a si gni fi cat i va par a r eal i zar la gest i n del pr oyect o y t omar l as deci si ones
t cni cas r equer i das par a cumpl i r el t r abaj o. La pl ani fi caci n s e ma nt i e ne en el m r -
mo, y al equi po s e le per mi t e s el ecci onar s u pr opi o e nf oque (por ej empl o, pr oceso
mt odos , her r ami ent as ) , sl o r est r i ngi do por l os r equi s i t os del ne goci o y l os e s t r -
dar es or gani zaci onai es . Conf or me el pr oyect o a va nz a el e qui po s e aut oor gani za pa-
ra e nf ocar la compet enci a i ndi vi dual en una f or ma que s ea m s benf i ca par a el pro-
yect o e n un punt o da do en el t i empo. Para l ograrl o, un e qui po gil pue de dirigir bre
ves r e uni one s de e qui po di ar i as par a coor di nar y s i ncr oni zar el t r abaj o que s e d e t e |
l ograr e s e da.
Con ba s e en la i nf or maci n obt eni da dur a nt e e s t a s r euni ones , el equi po adapt a
s u e nf oque d e f or ma tal que l ogra un i ncr e me nt o de t r abaj o. Conf or me pas a c a a
d a, la aut oor gani zaci n cont i nua y la col abor aci n mue ve n al e qui po haci a la con-
cl usi n de un i nc r e me nt o de s of t w ar e.
21.2.5 Conflictos de coordinacin y comunicacin
Existen mu c h a s r a z one s por l as cual es l os pr oyect os de s of t w a r e s e vuel ven probl e- ]
mt i cos. La escal a de mu c h o s e s f ue r z os de des ar r ol l o e s gr ande, lo que conduce a
compl ej i dad, conf us i n y di f i cul t ades si gni fi cat i vas en la coor di naci n de l os mi e r
br os del equi po. La i ncer t i dumbr e e s c omn, lo que ge ne r a una cor r i ent e cont i nua |
de cambi os que mue ve gr adual me nt e en una sol a di r ecci n al e qui po del pr oyeci :
La i nt er oper abi l i dad s e ha conver t i do en una car act er st i ca cl ave de mu c h o s si st e
mas . El n u e v o s of t w a r e de be c omuni c a r s e con el ant er i or y ade cuar s e a l as restric-
ci ones pr edef i ni das que i mpone el s i s t e ma o pr oduct o.
Est as car act er st i cas del s of t w a r e mode r no escal a, i ncer t i dumbr e e i nt er oper a
bi l i dad son as pe ct os de la vi da. Para lidiar con el l os en f or ma ef i caz, un equi po t
i ngeni er a de s of t w a r e debe es t abl ecer m t odos ef i ci ent es par a coor di nar al per s o
nal que r eal i za el t r abaj o. Para l ograrl o se de be n es t abl ecer me c a ni s mos par a la co |
muni caci n f or mal e i nf or mal ent r e l os mi e mbr os del equi po y ent r e ml t i pl es equ:
pos . La comuni caci n f or mal s e l ogra por me di o de "escri t os, r e uni one s est ruct ura-
da s y ot r os c a na l e s de comuni caci n r el at i vament e no i nt er act i vos e i mper s onal es
[KRA95]. La comuni caci n i nf or mal e s m s per sonal . Los mi e mbr os de un equi po de
s of t w a r e c ompa r t e n i deas s obr e una ba s e ad hoc, pi den ayuda c ua ndo s ur gen pr o
bl e ma s e i nt er act an u n o s con ot r os di ar i ament e.
TM
PDF Editor
CAP TULO 2 1 CONCEPTOS DE GESTIN DE PROYECTOS 6 5 1
EOGARSEGURO
Estructura de equipo
El e s c e nar i o: La oficina de Doug
el inicio del proyecto de softw are HogarSe-
res: Doug Miller (gerente del equipo de inge-
B del softw are HogarSeguro! y Vinod Romn, Jamie
f otros miembros del equipo de ingeniera de soft-
I producto.
conversacin:
g: Ustedes han tenido oportunidad de echar un
fcc o la informacin preliminar de HogarSegvro que
pero mercadotecnia? ' ' l '
d afirma con la cabeza y mira a sus
pae r os d e e qui po) : S. Pero tenemos muchas
g: Dejemos eso por el momento. Q uiero hablar
: ae cmo vamos a estructurar el equipo, quin es
r - s abl e de qu...
: Yo realmente estoy con la filosofa gil, Doug
i debemos ser un equipo autoorganizado.
Estoy de acuerdo. Dados el ceido periodo de
i y algo de ncertidumbre, y al hecho de que todos
; somos competentes [risas], me parece que ese
- el que debemos ir.
Doug: Est bien por m, pero ustedes conocen el proce-
dimiento.
Jamie (sonre y habla como si recitara algo):
Tomamos decisiones tcticas, acerca de quin hace qu y
cundo, pero es nuestra responsabilidad tener el produc-
to listo a tiempo.
Vinod: V con calidad.
Doug: Exactamente. Pero recuerda que existen restric-
ciones. Mercadotecnia define los incrementos de softw are
que se producirn... con nuestra asesora, desde luego.
Jamie: Y?
Doug: Y, vamos a usar UML como nuestro enfoque de
modelado.
Vi nod: Pero manten la documentacin extraa en un
mnimo absoluto.
Doug: Q uin va a ser mi contacto?
Jami e: Decidimos que Vinod ser el lder tcnico. l tie-
ne ms experiencia, as que Vinod es tu contacto, pero
sintete en libertad de hablar con cualquiera de nosotros.
Doug (re): No te preocupes, lo har.
2 1 , 3 EL P R P P V C T Q
El gest or de un proyect o de sof t w ar e se enfrent a con un dilema desde el principio
mi smo de un proyect o de ingeniera del soft w are. Se requieren est i maci ones cuanti-
tativas y un plan organi zado, per o no se di spone de i nformaci n slida. Un anlisis
det al l ado de los requisitos de sof t w ar e proporci onar a la i nformaci n necesari a pa-
ra las est i maci ones, pero, con frecuenci a, el anl i si s t oma s e manas o mes es en com-
pletarse. Peor an, los requi si t os pueden ser fluidos, y cambi an regul arment e con-
forme el proyect o avanza. Ms todava, se necesita un plan "ahora"!
En consecuenci a, se deben exami nar el product o y el probl ema que se i nt ent a re-
solver al inicio del proyecto. Como m ni mo, se debe est abl ecer y acot ar el mbi t o del
product o.
21.3.1 mbito del softw are
La pri mera actividad de gest i n de un proyect o de sof t w ar e es la det ermi naci n del
mbito del software. El mbi t o se define al r esponder las si gui ent es pregunt as:
TM
PDF Editor
( C O N S E J O ^ .
Si no puede acotar
una caracterstica del
software que intenta
construir, anote la ca-
racterstica como un
riesgo del proyecto
(captulo 25 ).
^ O N S E J O ^
B desarrollo de un
plan de proyecto razo-
nable requiere des-
componer el
problema. Estose
puede lograr emplean-
do una lista de funcio-
nes o de casos de uso
o, en el traba o gil,
historias de usuario.
Cont ext o. Cmo encaj a el sof t w ar e que se desarrol l ar en un si st ema ms gr
de, product o o cont ext o de negocios, y qu restricciones se i mponen como resul
do del cont ext o?
Obj et i vos de i nf ormaci n. Q u obj et os de dat os visibles al usuari o (captulo
se pr oducen como resul t ado del soft w are? Q u obj et os de dat os se requi eren de
t rada?
Funci n y de s e mpe o. Q u funci ones realiza el sof t w ar e para t ransformar
dat os de ent rada en salida? Existen al gunas caract er st i cas de des empeo espe
les que deban abordarse?
El mbi t o del proyect o de sof t w ar e no debe ser ambi guo ni i ncomprensi bl e a niv
de gest i n y tcnico. Se debe acot ar un enunci ado del mbi t o del soft w are. Esto
se est abl ecen de maner a explcita los dat os cuantitativos (por ejemplo, nmer o
usuari os si mul t neos, t amao de la lista de correo, t i empo de respuest a mxi
permitido); se anot an las restricciones o limitaciones (por ejemplo, el cost o del
duct o restringe el t amao de la memori a) y se describen los fact ores que red"
riesgos (por ejemplo, los al gori t mos deseados se compr enden bien y est n dis
bl es en C++).
21.3.2 Descomposicin del problema
La descomposi ci n del probl ema, a veces l l amada particin o elaboracin del p
ma, es una actividad que se asi ent a en el ncl eo del anlisis de requisitos de so
re (captulos 7 y 8). Durante la actividad de fijacin del mbi t o no se realiza int
al guno por descomponer compl et ament e el probl ema. Ms bien, la descomposi
se aplica en dos gr andes reas: 1) la funcionalidad que debe ent regarse y 2) el
ceso que s e empl ear para ent regarl a.
Los seres humanos t i enden a aplicar una estrategia de divide y vencers cu
enf r ent an un probl ema compl ej o. Dicho con simplicidad, un probl ema compl ejo
divide en probl emas menor es que resul t an m s manej abl es. sta es la estrategia
se aplica cuando comi enza la planificacin del proyecto. Las funci ones de softw
descritas al enunci ar el mbi t o, se eval an y refinan para proporci onar m s de
ant es del comi enzo de la est i maci n (captulo 23), Puest o que las est i maci ones
cost o y planificacin temporal est n f unci onal ment e ori ent adas, con frecuenci a
til cierto grado de descomposi ci n.
Por ejemplo, consi dr ese un proyect o que const rui r un nuevo procesador de
tos. Entre las caract er st i cas ni cas del product o est n la ent r ada cont i nua mer
te voz, as como por teclado, funci ones muy sofi st i cadas de "edicin aut omt i ca
copia", capaci dad de di seo de pgi na, ndice y tabla de cont eni do aut omt i cos
ot ras. El gest or del proyect o pri mero debe est abl ecer un enunci ado del mbi t o
acot e es t as caract er st i cas (as como ot ras funci ones m s usual es como la edi
la gestin de archivos, la producci n de document os y ot r as parecidas). Por ej em
la ent r ada cont i nua de voz requi ere que el usuari o del product o lo "entrene"?
TM
PDF Editor
CAP TULO 21 CONCEPTOS DE GESTIN DE PROYECTOS 6 5 3
c fi cament e, qu capaci dades pr opor ci onar la caract er st i ca de edi ci n de copi a?
Cun sofi st i cada ser la capaci dad de di seo de pgi na?
Conf or me evol uci ona el enunci ado del mbi t o ocurre nat ur al ment e un pri mer ni-
vel de part i ci n. El equi po del proyect o apr ende que el depar t ament o de mer cado-
tecnia ha habl ado con los cl i ent es pot enci al es y encont r que las si gui ent es funci o-
nes deben i nt egr ar se a la edicin aut omt i ca de copia: 1) compr obaci n ort ogrfi ca,
2) compr obaci n gramat i cal , 3) compr obaci n de r ef er enci as par a document os
gr andes (por ej empl o, la referenci a a una ent r ada bibliogrfica se encuent r a en la
lista de ent r adas en la bibliografa? ) y 4) val i daci n de referenci as de secci n y cap -
t ul o par a document os gr andes. Cada una de es t as caract er st i cas r epr esent a una
subf unci n que debe i mpl ement ar se en el sof t w ar e. Cada una t odav a puede refi nar-
se m s si la descomposi ci n simplifica la pl ani fi caci n.
*
7 de una
veas" puede
heiramien-
kocin de
s outomalizo-
24 ). La
f :* ga con esti-
de requisi-
t tarsos,
i e inicio/ fin y
spertinen-
tces puede
testo red cor-
i recursos poro
ntoy
t el proyecto.
Las act i vi dades del mar co de t r abaj o (captulo 2) que car act er i zan al pr oceso de soft -
w ar e son apl i cabl es a t odos los proyect os de sof t w ar e. El pr obl ema e s sel ecci onar el
model o de pr oceso apr opi ado par a que un equi po de proyect o s omet a al s of t w ar e a
ingeniera.
El gest or del proyect o debe decidir cul model o de pr oceso e s m s adecuado pa-
ra 1) los cl i ent es que han sol i ci t ado el pr oduct o y el per sonal que har el t rabaj o; 2)
las caract er st i cas del pr oduct o mi smo, y 3) el ambi ent e del proyect o en el que t r a-
baj a el equi po de sof t w ar e. Cuando se ha sel ecci onado un model o de pr oceso, en-
t onces el equi po defi ne un plan de proyect o prel i mi nar con bas e en el conj unt o de
act i vi dades del mar co de t r abaj o del proceso. Una vez que se est abl ece el plan pre-
liminar, comi enza la descomposi ci n del pr oceso. Est o es, se debe crear un pl an
compl et o, que refleje l as t ar eas de t r abaj o r equer i das para cubrir l as act i vi dades del
mar co de t rabaj o. Est as act i vi dades se expl oran br evement e en l as secci ones si-
gui ent es, y en el cap t ul o 24 se pr esent a una visin m s det al l ada.
21.4.1 Combinacin del producto y el proceso
La pl aneaci n del proyect o comi enza con la combi naci n del pr oduct o y el proceso.
Cada funci n que el equi po de s of t w ar e s omet er a ingeniera debe pasar a t ravs
del conj unt o de act i vi dades del mar co de t r abaj o defi ni das par a una or gani zaci n de
sof t w ar e. Supngase que la or gani zaci n ha adopt ado el si gui ent e conj unt o de acti-
vi dades del mar co de t r abaj o (captulo 2): comuni caci ones, pl ani fi caci n, model ado,
const r ucci n y despl i egue.
Los mi embr os del equi po que t r abaj an en una funci n de pr oduct o le apl i carn
cada una de l as act i vi dades del mar co de t rabaj o. En esenci a, s e crea una mat r i z si-
milar a la mos t r ada en la figura 21. 1. Cada f unci n de pr oduct o principal (en la figu-
ra se anot an f unci ones par a el sof t w ar e del pr ocesador de t ext os come nt ado ant e-
ri orment e) se menci ona en la col umna i zqui erda Las act i vi dades del mar co de tra-
TM
PDF Editor
Combi naci n
del pr obl ema
y el proceso.
A/ / /
ACTIVIDADES C OMU NE S DEL MAR C O / / ^ / v
DE TRABAIO DEL P ROCES O / / / ^ / g
z
/ /
z
Funci ones del pr oduct o
Ent r ada d e texto
Edicin y f or mot e ado
Edicin aut omt i ca d e copi a
Ca p a c i d a d d e plantilla d e p a i n a
ndi ce y t abl a d e cont e ni do aut omt i cos
Ges t i n d e ar chi vos
Pr oducci n d e document o
%
CLAVE
El marco de trabajo del
proceso estoblece un
esquel et o pon la ploni-
f koon del proyecto.
Se odopta al ubicar un
conjunto de treos ade-
cuodos paro el pro-
yecto.
baj o se me nc i ona n en la hi l era super i or . Las l abor es de t r abaj o de i ngeni er a del
w a r e (para cada act i vi dad del ma r c o de t r abaj o) se i ngr esar an en la hi l era sigu;~
te. 4 El t r abaj o del gest or del pr oyect o (y de ot r os mi e mbr os del equi po) cons i s t e
es t i mar l os r equi si t os de r e cur s os par a cada cel da de la mat r i z, f e chas de inicio y
nal par a l as t ar eas as oci adas con cada cel da, y l os pr oduct os de t r abaj o que p r :
ei r cada t ar ea. Di chas act i vi dades s e cons i der an en el cap t ul o 24.
21.4.2 Descomposicin del proceso
Un e qui po de s of t w ar e de be t ener un gr ado si gni fi cat i vo de flexibilidad al elegir
mode l o de pr oce s o de s of t w ar e que s e a me j or par a el pr oyect o y l as t ar eas de i""
ni er a del s of t w ar e que i nt egr en el mode l o de pr oc e s o una vez el egi do. Un pro"
r el at i vament e pe q ue o si mi l ar a ot r os que s e hayan r eal i zado pue de l ogr ar se
si s e utiliza el e nf oque s ecuenci al lineal. Si s e i mpone n r est r i cci ones de t i empo
cei das y el pr obl ema s e pue de compar t i ment al i zar mucho, tal ve z el mode l o de
sarrol l o r pi do de apl i caci ones (DRA) s ea la opci n cor r ect a. Si la f echa l mi t e e s
cei da que la f unci onal i dad compl et a n o pue da al canzar s e, tal vez s ea mej or una
t r at egi a i ncr ement al . De igual modo, l os pr oyect os con ot r as car act er st i cas
ej empl o, r equi s i t os i nci er t os, a va nc e s en la t ecnol og a, cl i ent es difciles, si gni
t i vo pot enci al de reut i l i zaci n) conduci r n a la s el ecci n de ot r os mode l os de
ces o. 5
Una vez el egi do el mode l o de pr oces o, el ma r c o de t r abaj o r espect i vo se a
a l. En cual qui er c a s o s e pue de apl i car el ma r c o de t r abaj o genr i co c ome nt a do
4 Se debe destacar que las tareas de trabajo tienen que adaptarse a las necesidades especficas
proyecto.
5 Recurdese que las caractersticas del proyecto tambin tienen una fuerte influencia en la
ra del equipo de softw are (seccin 21.2.3).
TM
PDF Editor
CAP TULO 2 1 CONCEPTOS DE GESTIN DE PROYECTOS 655
vi ament e: comuni caci n, planificacin, model ado, const r ucci n y despl i egue. Fun-
ci onar para model os lineales, iterativos e i ncr ement al es, as como evol ut i vos e in-
cl uso par a model os concur r ent es o de ens ambl e de component es . El mar co de t ra-
baj o del pr oceso es invariable y sirve como bas e par a t odo el t r abaj o de s of t w ar e que
realiza una organi zaci n de sof t w ar e.
Pero las t ar eas de t r abaj o real var an. La descomposi ci n del pr oces o comi enza
cuando el ger ent e de proyect o pregunt a: " Cmo l ogr amos est a actividad del mar co
de trabajo? ". Por ej empl o, un proyect o pequeo y r el at i vament e si mpl e puede reque-
rir l as si gui ent es t ar eas de t r abaj o para la actividad de comuni caci n:
1. Desarrol l ar una lista de confl i ct os que deben clarificarse,
2. Reuni rse con los cl i ent es par a abor dar los confl i ct os que deben clarificarse.
3. Desarrol l ar en conj unt o un enunci ado del mbi t o.
4. Revisar el enunci ado del mbi t o con t odos los i mpl i cados.
5. Modificar el enunci ado del mbi t o segn se requi era.
Est os s uces os pueden ocurrir en un peri odo menor a 48 horas. Repr esent an un pro-
ce s o de descomposi ci n adecuado par a el proyect o pequeo y r el at i vament e simple.
Ahora, consi dr ese un pr oyect o m s compl ej o, el cual t i ene un mbi t o m s a m-
plio y un i mpact o comerci al m s significativo. Este proyect o puede requeri r l as si-
gui ent es t ar eas de t r abaj o par a la actividad de comuni caci n:
1. Revisar la peticin del cliente.
2. Planificar y pr ogr amar una reuni n formal con el cliente.
3. Llevar a cabo i nvest i gaci ones par a especi fi car la sol uci n pr opuest a y los en-
foques exi st ent es.
4. Preparar un "document o de t rabaj o" y una agenda par a la reuni n formal.
5. Cel ebrar la reuni n.
6. Desarrollar en conj unt o mi ni pr ospect os que refl ej en los dat os, funci n y ca-
ract er st i cas de compor t ami ent o del sof t w ar e. Al t ernat i vament e, se desarro-
llan cas os de us o que descri ben al s of t w ar e des de el punt o de vista del
usuari o.
7. Revisar cada mi ni pr ospect o o cas o de us o para val orar su correcci n, consi s-
t enci a y falta de ambi gedad.
8. Ensambl ar los mi ni pr ospect os en un document o m s ampl i o.
9- Revisar el document o m s ampl i o o col ecci n de cas os de us o con t odos los
implicados.
10. Modificar el document o m s ampl i o o cas os de us o segn se requi era.
Ambos proyect os real i zan la actividad del mar co de t r abaj o que se l l ama "comu-
nicacin", per o el pr i mer equi po de proyect o ef ect u la mi t ad de las t ar eas de t raba-
jo de ingeniera de s of t w ar e que real i z el segundo.
TM
PDF Editor
2 1 . 5 EL P R OY E C T O
La gest i n de un pr oyect o de s of t w a r e exi t oso r equi er e e nt e nde r qu pue de salir rr all
(de mo d o que s ea fact i bl e evi t ar l os pr obl emas ) . En un excel ent e art cul o acer ca d
pr oyect os de s of t w ar e, John Reel [REE99] def i ne 10 s e al e s que i ndi can que un pr - ]
yect o de s i s t e mas de i nf or maci n est e n peligro:
El per s onal de s of t w ar e no ent i ende l as ne ce s i dade s d e s us cl i ent es.
El mbi t o del pr oduct o est mal defi ni do.
Los c a mbi os s e ges t i onan mal .
La t ecnol og a el egi da cambi a.
Las ne c e s i da de s comer ci al es c a mbi a n [o e s t n mal def i ni das] .
Los pl azos de ent r ega no s on real i st as.
Los us uar i os s e r esi st en.
Se pi er de el pat r oci ni o [o nunc a s e obt uvo de ma n e r a adecuada] .
El e qui po de pr oyect o car ece de per s onal con l as habi l i dades apr opi adas .
Los ge s t or e s [y l os pr of esi onal es] evi t an l as me j or e s pr ct i cas y l as l ecci ones
apr endi das .
Los pr of es i onal es i ndust r i al es muy e xpe r i me nt a dos con f r ecuenci a se refi eren (rre-J
di o f r i vol ament e) a la regl a 90- 90 c ua ndo es t udi an pr oyect os de s of t w a r e part i cul ar-
me nt e difciles. El pr i mer 90 por ci ent o de un s i s t ema abs or be el 90 por ci ent o del e>-|
f ue r z o y el t i empo as i gnados . El l t i mo 10 por ci ent o t oma el ot r o 90 por ci ent o c a l
e s f ue r z o y el t i empo as i gnados (ZAH94J. Las c a us a s que c onduc e n a la regl a del 9 ^ 1
90 es t n cont e ni das en l as s e al e s a n o t a d a s en la lista pr ecedent e.
"No t e ne mos t i empo por o de t e ne r nos por combust i bl e, yo vamos t a r de . "
M. Cl er o'
Pero bas t a de negat i vi dad! Cmo act a un ges t or par a evi t ar l os pr obl emas re-j
cin s eal ados ? Reel [REE99] sugi er e un e nf oque de s e nt i do c omn de ci nco par . es j
par a pr oyect os de s of t w ar e:
1. Comience con el pie derecho. Est o s e l ogra t r a ba j a ndo dur o (muy duro) par a
e nt e nde r el pr obl e ma que ser r es uel t o y e nt onc e s es t abl ecer obj et i vos y ex-
pect at i vas r eal i st as par a t odos l os que e s t ar n i nvol ucr ados en el proyect o.
Est o s e r ef uer za me di ant e la cons t r ucci n del equi po cor r ect o (secci n 21.2 3 I
y al dar l e al equi po la aut onom a, aut or i dad y t ecnol og a neces ar i os par a ha-
cer el t r abaj o.
2 . Mantenga el mpetu. Muchos pr oyect os t i enen un bue n c omi e nz o y l uego len
t a me nt e s e des i nt egr an. Para ma nt e ne r el mpet u, el gest or del pr oyect o debe
pr opor ci onar i ncent i vos par a cons er var los r eves es del per s onal en un m ni -
Cu l e s s o n 1 .
l a s s e a l e s ^
d e q u e u n
p r o y e c t o d e 3 .
s o f t w a r e e s t e n ^
p e l i g r o ?
5 .
6.
7 .
8 .
9 .
10.
TM
PDF Editor
CAP TULO 2 1 CONCEPTOS DE GESTIN DE PROYECTOS
6 5 7
mo abs ol ut o; el e qui po de be r es al t ar la cal i dad en cada t ar ea que real i za, y l os
ges t or es ej ecut i vos de be hace r t odo lo posi bl e por ma nt e ne r s e f uer a del cami -
no del equi po. 6
3 . Rastree el progreso. En un pr oyect o de s of t w a r e el pr ogr e s o se r as t r ea conf or -
me s e el abor an l os pr oduct os de t r abaj o (por ej empl o, model os , cdi go f uen-
te, c onj unt os de c a s os de pr ueba) y s e a pr ue ba n ( medi ant e r evi si ones t cni cas
f or mal es) c o mo par t e de una act i vi dad de a s e gur a mi e nt o de la cal i dad. Ade-
ms , s e pue de n recopi l ar y apl i car pr oce s os del s of t w a r e y me di das del pr o-
yect o (cap t ul o 22) par a val or ar el pr ogr e s o cont r a l os pr ome di os es t abl eci dos
por la or gani zaci n que desar r ol l a s of t w ar e.
4 . T ome decisiones inteligentes. En es enci a, l as deci s i ones del ges t or del pr oyect o
y del equi po de s of t w ar e de be n e nc a mi na r s e a " mant e ne r l o si mpl e". Si empr e
q u e s ea posi bl e, dec das e a empl ear s of t w a r e comer ci al ya des ar r ol l ado o
c ompone nt e s de s of t w ar e exi st ent es, dec das e a evi t ar i nt er f as es per s onal i za-
da s c ua ndo es t n di sponi bl es e nf oque s es t ndar , dec das e a i dent i fi car y l ue-
go evi t ar r i esgos obvi os, y dec das e a as i gnar m s t i empo que el que
cons i der e neces ar i o a l as t a r e a s compl e j as o r i es gos as ( necesi t ar a cada mi nu-
to).
5 . Realice un anlisis de resultados. Est abl ezca un me c a n i s mo cons i s t ent e par a
ext r aer l ecci ones apr e ndi das por cada pr oyect o. Eval e la pl ani fi caci n real y
la previ st a, r ecol ect e y anal i ce mt r i cas de pr oyect o de s of t w ar e, obt enga r ea-
l i ment aci n de l os mi e mbr os del equi po y de l os cl i ent es, y regi st re l os hal l az-
gos en f or ma escri t a.
W 5 H H
i Cmo se
defi nen los
t i t a s
i del
o?
En un excel ent e art cul o acer ca de l os pr oce s os y pr oyect os de s of t w ar e, Barry
Boehm [BOE96] est abl ece: "Ust ed neces i t a un pri nci pi o or gani zador que es cal e ha-
cia a ba j o par a pr opor ci onar pl a ne s [de proyect o) s i mpl es par a pr oyect os si mpl es".
Boehm sugi er e un e nf oque que abor de l os obj et i vos del pr oyect o, l os hi t os y pl ani fi -
caci n, r es pons abi l i dades , gest i n y e nf oque s t cni cos y r ecur s os r equer i dos. Boehm
l o l l ama el pri nci pi o W6HH, en honor a una ser i e de pr e gunt as que c onduc e n a una
def i ni ci n de l as car act er st i cas cl aves del pr oyect o y al pl an de pr oyect o r esul t ant e:
Por qu se desarrolla el sistema? La r es pues t a a est a pr egunt a per mi t e a t odas l as
pa r t e s eval uar la val i dez de l as r a z one s del negoci o par a el t r abaj o de s of t w ar e. Di-
c ho de ot ra f or ma: el pr ops i t o del ne goci o justifica el gas t o de per s onal , t i e mpo y
di ner o?
6 La implicacin de este enunciado es que la burocracia se reduce al mnimo, las reuniones extraas
se eliminan y la adherencia dogmtica a los procesos y reglas del proyecto se eliminan. El equipo
debe ser autoorganizado y autnomo.
TM
PDF Editor
Qu se har? La r espuest a a est a pr egunt a est abl ece el conj unt o de t ar eas que i
requeri r par a el proyect o.
Cundo se har? La r espuest a a est a pregunt a ayuda al equi po a est abl ecer i
planificacin del proyect o al identificar cundo se real i zarn las t ar eas del pro>
y cundo se al canzar n los objetivos.
Quin es el responsable de una Juncin? Prrafos at r s se anot que el papel y i
responsabi l i dad de cada mi embr o del equi po de s of t w ar e deben est ar definidos,
r espuest a a est a pr egunt a ayuda a lograrlo.
D nde estn ubicados en la organizacin? No t odos los papel es y responsabilii
des resi den en el equi po de sof t w ar e. El cliente, los usuar i os y ot r os participan!]
t ambi n tienen responsabi l i dades.
Cmo se har el trabajo desde los puntos de vista tcnico y de gestin? Una vez i
t abl eci do el mbi t o del pr oduct o se debe definir una est rat egi a de gest i n y tcr
para el proyect o.
Cunto de cada recurso se necesita? La r espuest a a est a pr egunt a se deriva al i
sarrollar est i maci ones (captulo 23) con base en l as r es pues t as a l as pr egunt as ar
riores.
El principio WSHH de Boehm se aplica si n i mport ar el t amao o la compl ej i dad de ;
proyect o de sof t w ar e. Las pr egunt as anot adas pr opor ci onan un excel ent e linearme
to de planificacin para el gest or del proyect o y el equi po de sof t w ar e.
El Airlie Council7 ha el abor ado una lista de "prct i cas crticas de sof t w ar e para
gest i n bas ada en el des empeo". Di chas prct i cas son "empl eadas consi st ent eme
te por, y consi der adas crticas por, pr oyect os de s of t w ar e muy exi t osos y por orga
zaci ones cuya ' lnea bas e' de de s e mpe o es mucho mej or que los pr omedi os de 1
industria" [AIR99].
Las prct i cas crticas8 incluyen: gest i n de proyect o bas ado en mt ri cas (captii
22), cost o emp ri co y est i maci n de la pl ani fi caci n (captulos 23 y 24), seguimienti
del val or ganado (captulo 24), gest i n del riesgo formal (captulo 25), segui mi ent o <
def ect os f r ent e a obj et i vos de cal i dad (captulo 26) y gest i n al t ant o del person
(seccin 21.2). Cada una de es t as prct i cas criticas se abor da a lo largo de la par t e1
de es t e libro.
7 El Airlie Council es un equipo de expertos en ingeniera de softw are que reclut el Departamento de |
Defensa de los Estados Unidos de Amrica para ayudar a desarrollar lineamientos para mejores
prcticas en la gestin de proyectos de softw are y de ingeniera del softw are.
8 Aqu slo se anot an las prcticas crticas asociadas con la "integridad del proyecto".
TM
PDF Editor
CAPTULO 21 CONCEPTOS DE GESTIN DE PROYECTOS
659
Herramientas de sotware para gestores de proyectos
Las "herramientas" menci onadas aqu son ge-
nricas y se aplican a un amplio rango de acti-
s que realizan los gestores de proyecto. En los
i captulos se consideran herramientas de gestin
i especficas (por ejemplo, herramientas de
cin, estimacin, de anlisis de riesgo).
nientas representati vas9
are Program Manager' s Network (www.spmn.com)
- c desarrollado una herramienta simple llamada Pro-
r je-:' Control Panel que ofrece a los gestores de proyec-
l un aviso directo del estado del proyecto. La
herramienta tiene "calibradores" muy parecidos a un
tablero y est implementada con Microsoft Excel. Est
disponible par a descarga en ht t p: / / www. spmn. com/
products_software.html.
Ganlbead.com ha desarrollado un conjunto de tiles lisias
de verificacin para gestores de proyecto que se puede
descargar de ht t p: / / www. gant t head. com/ .
lttoolkit.com (www.ittoolkit.com) ofrece "una coleccin de
guas de planificacin, plantillas de proceso y hojas de
clculo inteligentes" disponibles en CD-ROM.
La gest i n de pr oyect os de s of t wa r e es una act i vi dad pr ot ect or a de nt r o de la i nge-
ni er a del s of t war e. Comi enza a nt e s de iniciar cual qui er act i vi dad t cni ca y cont i na
a lo l ar go de la defi ni ci n, el des ar r ol l o y el s opor t e del s of t wa r e de comput a dor a .
Las cuat r o P que t i enen u n a i nf l uenci a sust anci al e n la gest i n de pr oyect os de
s of t war e: per s onal , pr oduct o, pr oces o y pr oyect o. El per s onal de be es t ar or ga ni za do
en equi pos efi ci ent es, mot i vados par a ha cer un t r abaj o de s of t war e de al t a cal i dad y
coor di na dos par a l ograr una comuni ca ci n efi caz. Los r equi si t os del pr oduct o se de-
ben c omuni c a r del cl i ent e al desar r ol l ador , s er di vi di dos ( des compues t os ) en s us
par t es const i t ut i vas y di st ri bui rse par a que t r abaj e el equi po de s of t war e. El pr oces o
de be a da pt a r s e al per s onal y al pr obl ema. Se s el ecci ona un ma r c o de t r abaj o de pr o-
c e s o c omn, s e apl i ca un pa r a di gma de i ngeni er a de s of t war e a de c ua do y s e el i ge
un conj unt o de t a r e a s de t r a ba j o par a l l evar a c a bo el t r abaj o. Fi nal ment e, el pr oyec-
t o debe es t ar or ga ni za do en una f or ma que per mi t a t r i unf ar al equi po de s of t war e.
El e l e me nt o cent r al en t odos l os pr oyect os de s of t war e es el per s onal . Los i nge-
ni er os de s of t wa r e pue de n or gani zar s e en di f er ent es es t r uct ur as de equi po, que van
des de l as j er ar qu as de cont rol t r adi ci onal es ha s t a l os equi pos de " par adi gma abi er -
to". Se pue de n apl i car var i as t cni cas de coor di naci n y comuni ca ci n par a apoyar
el t r a ba j o del equi po. En gener al , l as r evi s i ones f or mal es y la comuni ca ci n i nf or mal
de pe r s ona a pe r s ona s on l as m s val i osas pa r a l os pr of es i onal es .
La act i vi dad de gest i n del pr oyect o a ba r ca medi da s y mt r i cas, est i maci n y pl a-
ni fi caci n, anl i s i s de ri esgos, s egui mi ent o y cont r ol . Cada uno de e s t os t pi cos s e
cons i der a en l os cap t ul os si gui ent es.
9 Las herramientas registradas aqu son una muestra de est a categora. En la mayora de los casos los
nombres de las mi smas son marcas registradas pe- s us respectivos desarrolladores.
TM
PDF Editor
[AIR99] Airlie Council, "Per f or mance Based Management : The Program Manager ' s Guide Bas
on t he 16-Point Plan and Related Metrics", Dra Report, 8 de mar zo, 1999.
[BAK72] Baker, F. T "Chief Pr ogr ammer Team Management of Product i on Programmi ng", i
IBM Systems Journal, vol. 11, nm. I, 1972, pp. 56-73.
[BOE96] Boehm, B., "Anchori ng t he Sof t war e Process", e n IEEE Sojbvare, vol. 13, nm. 4,
de 1996, pp. 73-82.
[COCO 1 ] Cockburn, A. y J. Highsmith, "Agile Sof t war e Devel opment : The Peopl e Factor", en /
Computer, vol. 34, nm. 11, novi embr e de 2001, pp. 131-133.
[CON93] Const ant i ne, L "Work Organi zat i on: Paradi gms for Project Management and Orga
zation", en CACM, vol. 36, nm. 10, oct ubre de 1993, pp. 34-43.
[COU8O] Cougar, J. y R. Zawacki, Managing and Motivating Computer Personnel, Wiley, 1980.
[CUR88] Curts, B. el al., "A Field St udy of t he Soft ware Design Process for Large Systems",
EEETrans. Sojlware Engineering, vol. SE-31, nm. 11, novi embr e de 1988, pp. 1268-1287
[CUR94] Curts, B. el al., People Management Capability Maturity Model, Sof t war e Engi neeri ng I
titute, 1994.
[DEM98] DeMarco, T. y T. Lister, Peopleware, 2a. ed., Dorset House, 1998.
[EDG95] Edgemon, ) . , "Right Stuff: How to Recogni ze It When Selecting a Project Ma na ger i
Application Development Trends, vol. 2, nm. 5, mayo de 1995, pp. 37-42.
[FER98] Ferdinandi, P. L "Facilitating Communi cat i on", en IEEE Sofhvare, sept i embr e de 1S
pp. 92-96.
UAC98] Jackman, M "Homeopat hi c Remedi es for Team Toxicity", en IEEE Sojlware, julio
1998, pp. 43-45.
IKRA95] Kraul, R. y L. Streeter, "Coordi nat i on in Sof t war e Devel opment ", en CACM, vol. 38, n
3, ma r z o de 1995, pp. 69-81.
[MAN81J Mantei, M "The Effect of Pr ogr ammi ng Team St ruct ures on Pr ogr ammi ng Tasks" i
CACM, vol. 24, nm. 3, mar zo de 1981, pp. 106-113.
[PAG85] Page-Jones, M., Practical Project Management, Dorset House, 1985, p. vii.
[REE99] Reel, J. S., "Critical Success Fact ors in Sof t war e Projects", en IEEE Sojlware, mayo
1999, pp. 18-23.
[WE186] Wei nberg, G., On Becoming a Technical Leader, Dorset House, 1986.
[WIT94] Whitaker, K., Managing Sojhvare Maniacs, Wiley, 1994.
[ZAH94] Zahni ser, R., "Ti meboxi ng for Top Team Performance", en Sojlware Development, i
z o d e 1994, pp. 35-38.
21.1. Con bas e en la i nformaci n cont eni da en est e capi t ul o y la experi enci a propia, des ar
llar "10 mandami ent os " para al ent ar el pot enci al de los i ngeni eros de sof t war e. Est o es: ela
rar una lista de 10 l i ncami ent os que conduci r n al personal que desarrol l a s of t war e a ej ercer s
pot enci al compl et o.
21.2. El model o de madur ez de la capaci dad de gest i n de personal (MMCGP) del Soft ware I
gi neeri ng Institute real i za un est udi o or gani zado de l as "reas prct i cas clave" (APC) que i
va el buen personal de sof t war e. El i nst ruct or asi gnar una APC para anal i zar y resumi r.
21.3. Describir tres si t uaci ones de la vida real en las cual es el cl i ent e y el usuari o final son <
mi smo. Describir tres si t uaci ones en l as cual es s on di ferent es.
21.4. Las deci si ones que t oman l os ges t or es ej ecut i vos pueden t ener un i mpact o significati
en la eficacia de un equi po de i ngeni er a del sof t war e. Proporci onar ci nco ej empl os que ilusti
que est o es cierto.
2 1 . 5 . Repasar el libro de Wei nberg [WEI86] y escribir un r es umen de dos o tres pgi nas de
t pi cos que deben consi der ar se al aplicar el model o MOI.
TM
PDF Editor
CAPTULO 21 CONCEP TOS DE GEETIC D - : R ; YBOS
661
21.6. Ust ed ha si do nombr a do ges t or de pr oyect o dent r o de una or gani zaci n de s i s t ema s de
i nf or maci n. Su l abor e s cons t r ui r una apl i caci n q u e s ea ba s t a nt e si mi l ar a ot r as que ha c ons -
t rui do su equi po, a unque st a e s ma yor y m s compl ej a. El cl i ent e ha doc ume nt a do a mpl i a me n-
t e l os r equi si t os. Qu es t r uct ur a de equi po el egi r a y por qu? Qu model o( s) de pr oces o de
s of t wa r e el egi r a y por qu?
21. 7. Usted ha si do nombr a do ges t or de pr oyect o en una p e q u e a c ompa a de pr oduct os de
s of t war e. Su l abor e s const r ui r un pr oduct o de a v a n z a d a q u e combi ne ha r dwa r e de real i dad vir-
t ual con s of t wa r e de l t i ma gener a ci n. Pues t o q u e la c ompe t e nc i a en el me r c a d o del ent r et e-
ni mi ent o c a s e r o e s i nt ens a, exi st e una pr es i n si gni fi cat i va par a compl et a r el t r abaj o. Qu es -
t r uct ur a de equi po el egi r a y por qu ? Qu model o( s) de pr oces o de s of t wa r e el egi r a y por qu?
2 1 . 8 . Usted ha si do n o mb r a d o ges t or de pr oyect o en una gr an c ompa a de pr oduct os de s of t -
war e. Su l abor e s ges t i onar el des ar r ol l o de la ver s i n de s i gui ent e gener a ci n de su s of t wa r e
de pr oc e s a mi e nt o de t ext os a mpl i a me nt e ut i l i zado. Pues t o que s e de be n ge ne r a r nue vos i ngr e-
s os , s e ha n es t abl eci do y a nunc i a do f echas lmite pr eci sas. Qu es t r uct ur a de equi po el egi r a y
por qu? Qu model o( s) de pr oces o de s of t wa r e el egi r a y por qu?
21. 9. Ust ed ha si do n o mb r a d o ges t or de pr oyect o de s of t wa r e par a una c ompa a que at i ende
al mu n d o de la i ngeni er a gent i ca. Su l abor e s ges t i onar el desar r ol l o de un nue vo pr oduct o de
s of t wa r e que acel er ar el r i t mo de la cl asi fi caci n de genes . El t r abaj o est or i ent ado l+D, per o
la met a es el abor ar un pr oduct o de nt r o del s i gui ent e a o. Qu es t r uct ur a de equi po el egi r a y
por qu? Qu model o( s) de pr oces o de s of t wa r e el egi r a y por qu?
2 1 . 1 0 . A us t ed s e le pi de des ar r ol l ar una p e q u e a apl i caci n q u e anal i ce l os cur s o q u e of r ece
una uni ver s i dad y r epor t e la cal i fi caci n pr ome di o obt eni da en el cur s o ( para un per i odo det er -
mi nado) . Escri ba un e nunc i a do del mbi t o que a ba r c a es t e pr obl ema .
2 1 . 1 1 . Real i ce una des compos i ci n f unci onal de pr i mer ni vel de la f unci n pl ant i l l a de p gi na
t r at ada br e ve me nt e en la s ecci n 21. 3. 2.
OTRAS L E C T U R A S Y F U E N T E S P E INFORMACIN
El Proj ect Ma na g e me nt Inst i t ut e ( Gui det o the Project Management Body ofKnowledge, PMI, 20011
cubr e t odos l os a s pe c t os i mpor t a nt e s de la gest i n de pr oyect os . Murch (Project Management
Best Practicesfor IT Professionals, Prent i ce-Hal l , 2000) e ns e a habi l i dades bs i cas y pr opor ci ona
una gu a det al l ada par a t oda s l as f as es de un pr oyect o de TI. Lewi s (Project Managers Desk Re
ference, McGraw-Hill, 1999) pr es ent a un pr oces o de 16 pa s os par a pl ani fi car, s uper vi s ar y con-
t rol ar cual qui er t i po de pr oyect o. McConnel l (ProfessionaI Software Development, Addi son- Wes-
ley, 2004) of r ece c ons e j os pr a gm t i c os par a "l ograr pl anes m s cor t os, pr oduct os de ma yor ca-
lidad y pr oyect os m s exi t osos".
Una excel ent e ser i e de cuat r o vol me ne s es cr i t os por Wei nber g (Qual i t y Software Manage-
ment, Dor s e t Hous e , 1992, 1993, 1994, 1996) i nt r oduce c onc e pt os bs i cos de pe ns a mi e nt o y ges -
tin de s i s t emas ; expl i ca c mo us a r medi ci ones ef ect i vament e; y abor da la "acci n c ongr ue n-
t e", la habi l i dad de es t abl ecer "acopl ami ent o" ent r e l as ne c e s i da des del gest or, l as ne c e s i da des
del equi po t cni co y l as ne c e s i da des del negoci o. El libro br i ndar i nf or maci n til a l os gest o-
r es t ant o nue vos c o mo exper i ment ados . Futrell y s us col ega s (Quality Software Project Manage
ment, Prent i ce-Hal l , 2002) pr e s e nt a n un vol umi nos o t r a t a mi ent o de la gest i n de pr oyect os.
Phillips (IT Project Management: On TTack f,rom Start to Finish, McGr aw- Hi l l / Os bor ne, 2002).
Char vat {Project Management Nation, Wiley, 2002), Schwal be ( I nf or mat i on Technology Project Ma
nagement, 2a. ed. , Cour s e Technol ogy, 2001) y Hol t sni der y Jaffe {ITManager's Handbook, Mor-
gan Ka uf ma nn Publ i sher s, 2000) s on r epr es ent at i vos de l os mu c h o s l i bros q u e s e han escr i t o
a cer ca de la gest i n de pr oyect os de s of t war e. Br own y s us col egas (AntiPatterns in Project Ma
nagement, Wiley, 2000) e xa mi na n q u n o ha c e r dur a nt e la gest i n de un pr oyect o de s of t war e.
Br ooks (The Mythical Man-Month, Anni ver s ar y Edition, Addi son- Wesl ey, 1995) h a act ual i za-
d o s u libro cl s i co par a of r ecer u n a nue va vi si n en l os t e ma s de pr oyect o de s of t wa r e y ges-
t i n. McConnel l (Software Project Surviva! Cuide, Mi crosoft Press, 1997) pr e s e nt a una excel ent e
gu a pr agmt i ca par a qui enes de be n ges t i onar pr oyect os de s of t war e. Pur ba y Sha h (How to Ma-
TM
PDF Editor
nage a Successful Software Project, 2a. ed., Wiley, 2000) pr esent an varios casos de estudio que in-
dican por qu al gunos proyect os tienen xito y otros fracasan. Bennat an (On Time Within Bud-
gel, 3a. ed., Wiley, 2000) present a sugerenci as y l i ncami ent os tiles para gest ores de proyectos
de soft ware.
Se puede ar gument ar que el aspect o ms i mport ant e de la gestin de proyect os de soft ware
es la gestin de personal. Cockburn {Age Software Development, Addison-Wesley, 2002) presen-
ta uno de los mej or es anlisis del personal de soft ware escrito hast a la fecha. DeMarco y Lister
[DEM98] han escrito el libro definitivo acerca del personal de soft ware y los proyect os respecti-
vos Adems, en aos reci ent es se han publ i cado los si gui ent es libros en esta mat eri a y vale la
pena exami narl os:
Beaudouin-Lafon, M., Computer Supported Cooperative Work, Wiley-Liss, 1999.
Carmel, E., Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall.
1999.
Const ant i ne, L., Peopleware Papers: Notes on the Human Side of Software, Prentice-Hall, 2001
Humphrey, W. S Managing Technical People: Innovation, Teamwork and the Software Process.
Addison-Wesley, 1997.
Humphrey, W. S., Introduction to the Team Software Process, Addison-Wesley, 1999.
Jones, P. H Handbook ofTeam Design: A Practitioner's Guide to Team Systems Development,
McGraw-Hill, 1997.
Karolak, D. S Global Software Development: Managing Virtual Teams and Environments, IEEE
Comput er Society, 1998.
Ensworth (The Accidental Project Manager, Wiley, 2001) ofrece pr of usament e gu as tiles a
qui enes deben sobrevivir "la transicin de tcnico a gest or de proyecto". Otro excelente libro ce
Weinberg [WE186] es una lectura obligada para t odo gestor de proyecto y t odo lder de equipe
Este libro le brindar el conoci mi ent o y la gua que le permitirn hacer su t rabaj o de manera
ms eficiente.
Aun cuando no se rel aci onan espec fi cament e con el mundo del soft ware, y en ocasi ones so-
bresimplifican y general i zan en ext remo, los libros de "gestin" ms vendi dos de Bossidy (>.e
cution: The Discipline of Getting Things Done, Crown Publishing, 2002), Drucker (Managemer:
Challengesfor the 2lst Century, Harper Business, 1999), Buckingham y Coffman (First, Break.-S
the Rules: What the World's Greatest Managers Do Differently, Simn and Schuster, 1999) y Chris-
t ensen (The Innovator's Dilemma, Harvard Business School Press, 1997) resal t an "nuevas reglas1
que define una econom a rpi dament e cambi ant e. Los ttulos viejos como Who Moved My Chcr
se?, The One-Minule Manager e In Search ofExcelience cont i nan ofreci endo valiosa informacin
que pueden ayudarl e a gest i onar per sonas y proyect os de maner a ms eficaz.
En Internet est disponible una amplia variedad de fuent es de i nformaci n acerca de la ges-
tin de proyect os de soft ware. Una lista act ual i zada de referenci as en la World Wide Web se en-
cuent ra en el sitio Web de SEPA:
TM
PDF Editor
C A P T U L O
MTRI CAS DE PROCESO
Y PROYECTO
22
CEPTOS
STE
. . . . 677
"o
. . . 679
6 6 7
. . . 6 7 6
. . 6 7 4
. 667
. 670
. . 6 7 3
al
. . . 669
. . . 666
. . . . 666
. . 6 7 4
de
L
a medi ci n permi t e obt ener una visin del proceso y el proyect o pues pro-
porci ona un mecani smo para lograr una eval uaci n objetiva. Lord Kelvin
dijo una vez:
. 6 8 4
Cua ndo pue de medi r aquel l o de lo que es t ha bl a ndo y expr es ar l o e n n me r o s s a be
a l go a cer ca de el l o; per o c ua ndo n o pue de medi r , c u a n d o n o p u e d e expr es ar l o en n-
me r os , s u conoci mi ent o e s es cas o, def i ci ent e p u e d e s e r el c omi e nz o del conoci mi en-
to, per o, en s us pe ns a mi e nt os , a p e n a s es t a v a n z a d o al mbi t o de la ci enci a.
La comuni dad de la ingeniera del sof t war e ha t omado en serio las pal abras de
lord Kelvin Mas no sin frustracin y algo ms que un poco de controversia!
La medicin se aplica al proceso de soft ware con la finalidad de mej orarl o de
maner a cont i nua. La medi ci n se utiliza a lo largo de un proyect o de sof t war e
como apoyo en la est i maci n, el control de calidad, la valoracin de la producti-
vidad y el control del proyecto. Finalmente, la medicin la aplican los i ngeni eros
de soft ware como auxiliar en la evaluacin de la calidad de los product os de tra-
baj o y para apoyar la t oma de deci si ones tctica conf or me avanza un proyecto
(captulo 15).
En su gua acerca de la medicin de soft ware, Park, Goethert y Florac [PAR96:
apunt an l as r azones por las que se mide: 1) para caracterizaren un esf uer zo por
compr ender acerca "de los procesos, product os, recursos y ent ornos, y para es-
t abl ecer l neas ba s e par a compar aci ones con eval uaci ones fut uras"; 2) para
evaluar "det ermi nando el est ado con respect o a los planes"; 3) para predecir me-
di ant e "la comprensi n de rel aci ones ent re pr ocesos y product os y construir mo-
Qu e s ? El proceso de software y
las mtricas del proyecto son medi-
das cuantitativas que permiten a los
ingenieros de software obtener una
visin de la eficacia del proceso de
oftware y los proyectos que llevan a cabo utili-
zando e! proceso como marco de trabajo. Se
ecopilan datos bsicos de calidad y productivi-
dad. Luego dichos datos se analizan, comparan
:on promedios pasados y valoran para determi-
nar si han ocurrido mejoras en la calidad y la
productividad. Las mtricas tambin se emplean
para marcar las reas problema de modo que se
ouedan desarrollar remedios y mejorar el proce-
so de software.
Qui n l o hoc e ? Los gestores de software anali-
zan y evalan las mtricas del software. Con fre-
cuencia, los ingenieros ele software recopilan las
medidas.
Por q u e s i mp o r t a n t e ? Si no se realizan
mediciones el juicio slo se basa en evaluacin
subjetiva. La medicin permite- destacar las ten-
dencias (ya sean buenas o malas) y hacer mejo-
res estimaciones, y con el tiempo se puede lograr
una verdadera mejora.
Cul es s on los p a s o s ? Se comienza definien-
do un conjunto limitado de medidas del proceso
y del proyecto que puedan recopilarse con faci-
lidad Dichas medidas por io general s norma-
lizan emplenado mtricas orientadas al tamao
663
TM
PDF Editor
o la funcin. El resultado se analiza y compara
con promedios pasados para proyectos simila-
res realizados dentro de la organizacin. Se
valoran las tendencias y se generan conclusio-
nes H H r a | |
Cul e s el product o obt eni do? Un conjunto
de mtricas del software que proporcionan
amplia visin del proceso y un conocimiento
detallado acerca del proyecto.
Cmo pue do es t ar s e gur o d e que l o he
hecho correct ament e? Al aplicar un esque-
ma de medicin consistente pero simple con el
cual no se valora, recompensa o castiga el
desempeo individual. MlllS
dlos de di chas relaciones"; y 4) para mejorar al "identificar barri cadas, caus as ra ; I
ineficiencias y ot ras oport uni dades para mej orar la calidad del product o y el deserr-j
peo del pr oces o".
La medicin es una herrami ent a de gestora. Si se lleva a cabo adecuadament e
proporci ona visin al gestor del proyecto. Y, como resultado, apoya al gestor del pro-l
yect o y al equi po de sof t war e a t omar deci si ones que conduci rn a un proyect o ex.-|
toso.
2 2 . 1 M T R I C AS EN LOS DOMI NI OS DEL P ROCES O Y EL PROYECTO
\
CLAVE
Los mtricos del
proceso tienen impocto
o largo plazo. Su
objetivo es mejorar el
proceso en s. Con
frecuencia, las mtricas
del proyecto
contribuyen al
desarrollo de mtricos
del proceso.
Las mtricas del proceso se recopilan en el curso de t odos los proyect os y durant e !a:-l
gos periodos. Su objetivo es proporci onar un conj unt o de i ndi cadores de proceso q u a
conduzcan a la mej ora de los procesos de sof t war e de largo plazo. Las mtricas tiJ
proyecto permi t en que un gestor de proyect o de soft ware 1) valore el est ado de - ni
proyecto en curso; 2) rastree los riesgos potenciales; 3) descubra las r eas problema
ant es de que se vuelvan "crticas"; 4) aj ust e el flujo de t rabaj o o las t areas, y 5) eva-
le la habilidad del equi po del proyect o para cont rol ar la calidad de los product os : a
t rabaj o del soft ware.
Las medi das que recopila un equi po de proyect o y las que convierte en mt ri cas
para empl earl as durant e un proyect o t ambi n se pueden transmitir a qui enes t i enes!
la responsabilidad de mej orar el proceso de soft ware. Por est a razn, muchas de i d
mi smas mt ri cas se usan t ant o en el domi ni o del proceso como en el del proyecto i
22.1.1 Mtricas del proceso y mejora del proceso de software
La ni ca forma racional de mej orar cualquier pr oceso es medi r s us at ri but os e s p e d
fieos, desarrollar un conj unt o de mt ri cas significativas con bas e en di chos at r i but as
y luego empl ear las mt ri cas para ofrecer i ndi cadores que conduci rn a una est ra: e-j
gia de mej ora. Pero ant es de est udi ar las mt ri cas de sof t war e y su i mpact o en la rre-l
jora del proceso de sof t war e es i mport ant e dest acar que el pr oceso sl o es uno ral
varios "factores cont rol abl es en la mej ora de la calidad del sof t war e y el desempe- d
organi zaci onal " [PAU94],
En la figura 22.1 el proceso se asi ent a en el cent ro de un tringulo que conect a
tres fact ores con una profunda influencia en la calidad del sof t war e y el de s e mpe -
organi zaci onal . La dest reza y la mot i vaci n del personal [BOE81] se muest r an coi r :
TM
PDF Editor
CAPITULO 22 MTRI CAS DE PROCESO Y PROYECTO 665
" i t e s
la calidad
software y la
'a
acional
ado de
D -
Producto
Car act er s t i cas
del cl i ent e
Condi c i one s
del ne goc i o
Personal Tecnol og a
CLAVE
y
del
de software
el trabajo
factores ms
que
en la calidad
el factor individual ms influyente en la calidad y el desempeo. La complejidad del
product o puede t ener un i mpact o sustancial sobre la calidad y el desempeo del equi-
po. La tecnologa (es decir, los mt odos y her r ami ent as de la ingeniera del soft wa-
re) que reside en el pr oceso t ambi n tiene un impacto.
Adems, el tringulo de pr oceso existe dent r o de un crculo de condi ci ones am-
bi ent al es que incluyen el ent or no de desarrol l o (por ejemplo, herrami ent as CASE),
condi ci ones del negoci o (por ejemplo, fechas lmite, reglas comerciales) y caracters-
ticas del cliente (por ej empl o, facilidad de comuni caci n y colaboracin).
La eficacia de un proceso de sof t war e se mi de i ndi rect ament e. Esto es, se deduce
un conj unt o de mt ri cas bas adas en los resul t ados que se derivan del proceso. Los
resul t ados incluyen medi das de errores descubi ert os ant es de liberar el soft ware, los
defect os que det ect an y report an los usuari os finales, los product os de t rabaj o ent re-
gados (productividad), el esf uer zo huma no gast ado, el t i empo de la planificacin
consumi do, concordanci a con la planificacin y ot ras medi das. Tambin se deducen
mt ri cas de proceso al medir las caract er st i cas de t ar eas especficas de ingeniera
del soft ware. Por ejemplo, se mi de el esf uer zo y el t i empo utilizados al realizar las
act i vi dades genri cas de la ingeniera del sof t war e descritas en el captulo 2.
"Las mtricas de soft ware le permiten conocer cundo rer y cundo llorar."
Grady [GRA92] ar gument a que existen usos "privados y pblicos" para di ferent es
tipos de dat os de proceso. Como es natural que los i ngeni eros de sof t war e especi a-
les sean sensi bl es al uso de las mt ri cas recopi l adas sobre una bas e particular, di-
TM
PDF Editor
7 Cu l e s
la di ferenci a
e nt r e us os
pr i va dos y
pbl i cos de l as
mt r i cas de
s o f t wa r e ?
9 | Q
* l i neami ent os
s e deben apl i car
cuando se
recopi l an mt r i cas
de s o f t wa r e ?
c hos da t os deben s er pr i vados par a el i ndi vi duo y f unci onar c o mo un i ndi cador s ol :
par a l. Los ej empl os de mtricas privadas i ncl uyen ndi ces de def ect o por i ndi vi de.
ndi ces de def ect o por c ompone nt e de s of t wa r e y er r or es e nc ont r a dos dur a nt e el de-
sarrol l o.
La filosofa de "dat os de pr oces o pri vados" s e aj ust a bien al enf oque de pr oces o pe-
sonal del s of t war e (captulo 2) que pr opone Humphr ey [HUM95]. Humphr ey r econoce
que la mej or a en el pr oces o de s of t war e puede y debe c ome nz a r en el nivel i ndi vi dua.
Los dat os de pr oces o pr i vados pue de n f unci onar c omo un i mpor t ant e pr omot or para
que el t r abaj o i ndi vi dual del i ngeni er o de s of t war e mej or e.
Al gunas mt r i cas de pr oc e s o s on pr i vadas par a el equi po del pr oyect o de sof t wa-
re, per o pbl i cas par a t odos los mi e mbr os del equi po. Los ej empl os i ncl uyen defec-
t os que r epor t an l as gr a ndes f unci ones de s of t wa r e (las cual es des ar r ol l ar on vari :<
pr of esi onal es) , er r or es det ect ados dur a nt e l as r evi si ones t cni cas f or mal es y l neas
de cdi go o punt os de f unci n por mdul o o funci n. 1 Di chos da t os l os revi sa ei
equi po par a des cubr i r i ndi cador es que mej or en s u de s e mpe o.
Las mt r i cas pbl i cas por l o gener al asi mi l an i nf or maci n que or i gi nal ment e era
pr i vada par a l os i ndi vi duos y equi pos . Los ndi ces de def ect o al nivel del pr oyec: :
(que no s e at r i buyen por ni ngn mot i vo a un i ndi vi duo), es f uer zo, pl ani f i caci n y ca-
t os r el aci onados s e r ecopi l an y eval an con la fi nal i dad de des cubr i r i ndi cador es que
pueden mej or a r el d e s e mp e o del pr oces o or gani zaci onal .
Las mt r i cas del pr oces o de s of t wa r e of r ecen benef i ci os si gni fi cat i vos conf or me
una or gani zaci n t r abaj a e n mej or ar s u gr ado gl obal de ma dur e z del pr oces o. S:r
emba r go, c o mo t oda s l as mt r i cas , s t a s pue de n empl ea r s e mal y cr ear m s probl e-
ma s de l os que sol uci onan. Grady [GRA92] sugi er e un "conj unt o de r egl as de etqueva
par a l as mt r i cas de s of t war e", a de c ua do t ant o par a ges t or es c o mo par a pr of esi ona-
l es c onf or me i nst i t uyen un pr ogr a ma d e mt r i cas del pr oces o:
Apl i que s ent i do c omn y sensi bi l i dad or gani zat i va c ua ndo i nt er pr et e dat os
mt r i cos.
Of r ezca r et r oal i ment aci n r egul ar a l os i ndi vi duos y equi pos que r ecopi l an
medi da s y mt r i cas .
No utilice l as mt r i cas par a eval uar a l os i ndi vi duos.
Tr abaj e con l os pr of es i onal es y equi pos par a es t abl ecer me t a s cl ar as y l as m-
t r i cas que se e mpl e a r n par a cons egui r l as .
Nunca us e mt r i cas par a a me n a z a r a l os i ndi vi duos o equi pos.
Los da t os mt r i cos que i ndi can una r ea pr obl ema no deben cons i der ar s e
"negat i vos". Di chos da t os s l o s on un i ndi cador de la mej or a del pr oces o.
No se obs es i one con una sol a mt r i ca y excl uya ot r as mt r i cas i mpor t a nt es
1 Las mtricas de lineas de cdigo y punt o de funcin se estudian en las secciones 22.2.1 y 22.2.2
TM
PDF Editor
CAPTULO 22 MTRI CAS DE PROCESO Y PROYECTO
667
Conforme una organi zaci n se si ent e m s cmoda con la recopilacin y el empl eo
de las mt ri cas de proceso, la deducci n de indicadores simples da la paut a para un
enf oque m s ri guroso l l amado mejora estadstica del proceso de software (MEPS). En
esenci a, el MEPS aplica el anlisis de falla de soft ware para recopilar i nformaci n
acerca de t odos los errores y defect os2 que se encuent r an al desarrollar y utilizar una
aplicacin, si st ema o product o.
22.1.2 Mtricas del proyecto
A diferencia de las mt ri cas del proceso de soft ware que se utilizan con propsitos
estratgicos, las mt ri cas del proyect o de sof t war e son tcticas. Es decir, un gerent e
de proyect o y un equi po de sof t war e empl ean las mt ri cas del proyect o y los indica-
dores que se deducen de ellas para adapt ar el flujo de t rabaj o del proyect o y las ac-
tividades tcnicas.
La primera aplicacin de las mtricas del proyecto en la mayora de los proyectos de
sof t war e ocurre dur ant e la estimacin. Las mt ri cas recopi l adas de los proyect os
previos se aprovechan como base desde la cual se realizan est i maci ones de esfuer-
zo y t i empo para el t rabaj o de sof t war e actual. Conforme el proyecto avanza, la me-
di das de esf uer zo y t i empo utilizados se compar an con las est i maci ones originales
(y la planificacin del proyecto). El gestor del proyect o empl ea di chos dat os para su-
pervi sar y controlar el progreso.
Mientras comi enza el t rabaj o tcnico, las ot ras mt ri cas del proyect o comi enzan
a t ener significado. Se mi den los ndices de produccin r epr esent ados en t rmi nos
de model os creados, hor as de revisin, punt os de funcin y lneas fuent e ent regadas.
Adems, se les da segui mi ent o a los errores descubi ert os durant e cada t area de in-
geniera del soft ware. Conforme el soft ware evoluciona desde los requisitos hast a el
diseo, se recopilan mt ri cas t cni cas para valorar la calidad del di seo y mej orar
los i ndi cadores que influirn en el enf oque que se adopt e para la generaci n y prue-
ba del cdigo.
Cmo se La finalidad de las mt ri cas del proyect o es doble. Primero, se empl ean para mi-
mpleon las
ni mi zar el t i empo de desarrol l o haci endo los aj ust es necesari os para evitar demor as
y reducir los probl emas y riesgos pot enci al es. Segundo, se utilizan para valorar la ca-
lidad del product o sobre una base actual y, cuando es necesari o, modificar el enfo-
que tcnico para mej orar la calidad.
Conforme la calidad mej ora los defect os se minimizan, y mi ent ras est o sucede
t ambi n se reduce la cantidad de reel aboraci n requerida durant e el proyecto. Esto
conduce a una reducci n en el cost o global del proyecto.
dur ant e
o?
2 En este libro, un error se define como algn fallo en un producto de trabajo de ingeniera del soft
ware que se descubre antes de que el software se entregue al usuario final. Un defecto es un fallo
que se descubre despus de la entrega al usuario final. Se debe advertir que otros no hacen esta dis-
tincin. En el captulo 26 se presenta un mayor anlisis
TM
PDF Editor
HOGARSEGURO
e l
f i f i
Establecimiento de un enfoque de mtricas
' El e s c e na r i o : La oficina de Doug
Miller cuando se est a punto de iniciar el proyecto de
software HogarSeguro.
Los ac t or e s : Doug Miller (gerente del equi po de inge-
niera del software HogarSeguro} y Vinod Raman y Ja-
mi e Lazar, miembros del equi po ci ingeniera de
software del producto.
La conversaci n:
Do ug : Antes de comenzar a t r abaj ar en este proyecto
me gustara que definieran y reunieran un conjunto de
mtricas simples. Pora comenzar, tendrn que definir sus
metas.
Vi nod ( c e udo) : Nunca antes hemos hecho eso, y. . .
J a mi e ( i nt e r r umpe ) : Y con bas e en la administracin
del tiempo de la que se ha estado habl ando, nunca ten-
dremos el tiempo. Adems, qu tan buenas son las m-
tricas?
Doug (el eva l as manos para detener el ata-
que) : Cal ma. . . reljense, chicos. El hecho de que nunca
ant es lo hayamos hecho es la principal razn par a co-
menzar ahor a, y el t rabaj o de las mtricas de las que es-
toy habl ando no deber a tomar mucho tiempo. . . de
hecho, puede ahorrarnos tiempo.
Vi no d: Cmo?
Doug: Mira, haremos mucha ingeniera de software en
caso conforme nuestro producto se vuelve ms inteligen-
te, llegue a estar habilitado en la Web, todo eso. . . y ne-
cesitamos entender el proceso que utilizamos par a
construir software. . . y mejorarlo de modo que construya-
mos mejor software. La nica formo de hacer esto es mi-
diendo.
J a mi e : Pero tenemos presin de tiempo, Doug. No es-
toy en favor de ms presin de papel eo. . . necesitamos el
tiempo par a hacer nuestro t rabaj o, no recopilar datos.
Do u g ( c a l ma d a me n t e ) : Jami e, el t r abaj o de un inge-
niero involucra recopilar datos, evaluarlos y aprovechar
los resultados par a mej orar el producto y el proceso.
Me equivoco?
J a mi e : No, pero. . . 9
Do u g : Qu tal si dej amos el nmero de medidas que
deben reunirse en no ms de cinco o seis y nos enfoca-
mos en la cal i dad?
Vi nod: Nadi e puede estar en contra de la alta cali-
dad. . .
J a mi e : Cierto... pero, no s, todava creo que esto no
es necesario.
Do ug : Esta vez les pedir que me complazcan. Cunto
saben acerca de las mtricas de software?
Jami e (voltea y ve a Vinod): No mucho.
Do ug : Aqu tienen algunas referencias de la Web. . . pe
sen algunas horas organi zndose par a aument ar la vele
ci dad,
J a mi e ( s onr e) : Pens que dijiste que esto no nos to-
mara tiempo.
Do ug : El tiempo que pasan aprendi endo nunca es tiem-
po perdi do. . . vayan a hacerlo y luego estableceremos al-
gunas metas, plantearemos al gunas preguntas y
definiremos las mtricas que necesitamos reunir.
2 2 . 2 MEDI CI N BEL SOFTWARE
En el cap t ul o 15 se i ndi c que la medi ci n de s of t war e s e cl asi fi ca en dos cat ego-
ras: 1) medidas directas del pr oces o de s of t wa r e (por ej empl o, cos t o y e s f ue r z o apli-
cados) y del pr oduct o (por ej empl o, l neas de cdi go |LDC] pr oduci das , r api dez de
ej ecuci n y def ect os r epor t ados a lo l argo de ci er t o per i odo est abl eci do) y 2) mea:-
das indirectas del pr oduct o que i ncl uyen f unci onal i dad, cal i dad, compl ej i dad, efi ci er
cia, confi abi l i dad, faci l i dad de ma nt e ni mi e nt o y mu c h a s ot r as "habi l i dades" t r a t a d a
e n el cap t ul o 15.
TM
PDF Editor
CAPTULO 22 MTRICAS DE PROCESO Y PROYECTO 669
"No t odo lo que puede ser cont ado cuent a, y no t odo o que cuent a pu i de ser cont odo. "
Al berl E' mstein
muchos
ttel
software,
es mtricas
: eq uipos.
Las mt r i cas del pr oyect o s e cons ol i dan con el fin de cr ear mt r i cas del pr oces o
que s ea n pbl i cas par a la or gani zaci n de s of t wa r e c o mo un t odo. Pero, c mo com-
bi na una or gani zaci n l as mt r i cas pr oveni ent es de di f er ent es i ndi vi duos o pr oyec-
t os?
Con fines i l ust rat i vos, cons i dr es e un ej empl o si mpl e. Los i nt egr ant es de dos di-
f er ent es equi pos de pr oyect o regi st ran y cat egor i zan l os er r or es que e nc ue nt r a n du-
r ant e el pr oc e s o del s of t war e. Luego, l as medi ci ones i ndi vi dual es se c ombi na n par a
desar r ol l ar me di da s de equi po. El equi po A e nc ont r 342 er r or es dur a nt e el pr oces o
del s of t wa r e pr evi o al l anzami ent o. El equi po B encont r 184 er r or es. Si t oda s l as de-
m s c os a s s e ma nt i e ne n i gual es, qu equi po e s m s ef i ci ent e al des cubr i r er r or es a
lo l argo del pr oces o? Pues t o que no s e c onoc e n ni el t a ma o ni la compl ej i dad de l os
pr oyect os , no s e pue de r es ponder est a pr egunt a. Sin emba r go, si l as medi ci ones s e
nor mal i zan, es posi bl e cr ear mt r i cas de s of t wa r e que posi bi l i t en la compa r a ci n a
pr ome di os or ga ni za ci ona l es m s ampl i os. De est a f or ma, l as mt r i cas or i ent a da s
t a nt o al t a ma o c o mo a la f unci n es t n nor mal i zadas .
22.2.1 Mtricas orientadas al t amao
Las mt r i cas del s of t wa r e or i ent a da s al t a ma o pr eceden de la nor mal i zaci n de l as
me di da s de cal i dad o pr oduct i vi dad cons i der a ndo el t a ma o del s of t wa r e que s e ha
pr oduci do. Si una or gani zaci n de s of t wa r e ma nt i e ne r egi st r os s i mpl es es fact i bl e
cr ear una t abl a de medi da s or i ent a da s al t a ma o, c o mo la que s e mues t r a en la fi-
gur a 22. 2. En la t abl a s e me nc i ona ca da pr oyect o de des ar r ol l o de s of t wa r e q u e s e
ha c ompl e t a do en a o s pa s a dos , as c o mo l as medi da s cor r es pondi ent es par a di chos
pr oyect os. Como s e advi er t e en la ent r ada de t abl a (figura 22.2) par a el pr oyect o al-
fa: 12 100 l neas de cdi go s e des ar r ol l ar on con 24 pe r s ona s - me s de e s f ue r z o a un
cos t o de 168 000 dol ar es. Se debe not ar que el e s f ue r z o y el cos t o r egi s t r ados en la
t abl a r epr es ent an t odas l as act i vi dades de i ngeni er a del s of t wa r e (anl i si s, di seo,
cdi go y pr ueba) , n o s l o codi f i caci n. I nf or maci n adi ci onal del pr oyect o alfa i ndi -
ca q u e s e des ar r ol l ar on 365 pgi na s de document a ci n, s e r egi st r ar on 134 er r or es
a nt e s de q u e el s of t wa r e f ues e l i ber ado y s e e nc ont r a r on 29 def ect os de s pu s de la
l i beraci n al cl i ent e dent r o del pr i mer a o de oper aci n. Tr es pe r s ona s t r abaj ar on e n
el des ar r ol l o del s of t war e par a el pr oyect o al fa.
El des ar r ol l o de mt r i cas que s e asi mi l en con mt r i cas si mi l ar es pr oc e de nt e s de
ot r os pr oyect os r equi er e el egi r lneas de cdigo c o mo val or de nor mal i zaci n. A par -
tir de l os dat os r udi ment ar i os de la t abl a s e desar r ol l a un c onj unt o de mt r i cas si m-
pl es or i ent adas al t a ma o par a c a da pr oyect o: er r or es por KLDC (mi l es de l neas de
cdi go), def ect os por KLDC, c os t o por KLDC. pgi na s de doc ume nt a c i n por KLDC.
Adems , s e pue de n cal cul ar ot r a s mt r i cas i nt er es ant es : er r or es por pe r s ona - me s ,
KLDC por pe r s ona - me s , cos t o por pgi na de document a ci n.
TM
PDF Editor
Mtricas
orientadas al
tamao.
Proyecto LDC Esfuerzo $ ( 0 0 0 ) Pag. D<K. Errores Defectos Personal
alfa 12 100 24 168 365 134 29
3
beta 27 200 62 440 1 224 321 86 5
gamma 2 0 200 43 314 1 050 256 6 4 6
I I !
' , % l .

. '
CLAVE
Las mtricas orientadas
al t amao son
ampliamente
utilizados, pero
contina el debat e
acerca de su val i de; y
aplicabilidad.
Las mt r i cas or i ent a da s al t a ma o n o s e a cept a n uni ver s al ment e c o mo la mej or
f or ma de medi r el pr oces o del s of t wa r e [JON86]. La mayor par t e de la c ont r ove r s a
gira en t or no al u s o de l neas de cdi go c o mo medi da cl ave. Los par t i dar i os de la me-
di da LDC a f i r ma n que s t a s s on un "ar t ef act o" de t odos l os pr oyect os de desar r o: . :
de s of t wa r e que pue de n f ci l ment e cont ar s e, que mu c h o s mode l os de es t i maci n de
s of t wa r e exi s t ent es us a n LDC o KLDC c o mo ent r a da cl ave, y que ya exi st e un gr a-
cuer po de bi bl i ograf a y dat os publ i cados par a LDC. Por ot r a par t e, l os det r act or es ar-
g u me n t a n que l as medi da s LDC de pe nde n del l enguaj e de pr ogr amaci n, que, cuar
do s e cons i der a la pr oduct i vi dad, cast i gan l os pr ogr a ma s bi en di s eados , per o ma ;
cor t os, que n o pue de n amol dar con faci l i dad l enguaj es q u e n o pr ovi enen del proce
s o y cuyo e mpl e o en la es t i maci n r equi er e un nivel de det al l e que ser a difcil de le-
gr ar (es decir, el pl ani f i cador de be es t i mar que l as LDC s e pr oduci r n muc ho ant e;
de q u e el anl i si s y el di s eo s e hayan compl et ado) .
22.2.2 Mtricas orientadas a la funcin
Las mt r i cas de s of t wa r e or i ent a da s a la f unci n e mpl e a n c o mo un val or d e norma-
l i zaci n una medi da de la f unci onal i dad que ent r ega la apl i caci n. La mt r i ca or i e-
t ada a la f unci n ut i l i zada con ma yor ampl i t ud es el punto de Juncin (PF). El cl cu-
l o del punt o de f unci n s e bas a n car act er s t i cas del domi ni o de i nf or maci n y 3
compl ej i dad del s of t wa r e. La me c ni c a del cl cul o del PF s e t r at e n el Cap t ul o 15 1
El punt o de f unci n, al igual que la medi da LDC, es cont r over si al . Los par t i dar i o;
af i r man que el PF es i ndependi ent e del l enguaj e de pr ogr amaci n, car act er st i ca que
lo ha c e i deal par a apl i caci ones que ut i l i zan l enguaj es convenci onal es y no proced -
ment al es , y que s e ba s a en da t os que es m s pr obabl e q u e s e c onoz c a n t empr ano
en la evol uci n de un pr oyect o, lo q u e ha c e al PF m s at r act i vo c o mo e nf oque de es-
3 Vase ta seccin 15.3.1 para una detallada exposicin del clculo de PF.
TM
PDF Editor
CAPITULO 22 MTRI CAS DE PROCESO Y PROYECTO 671
l i maci n. Los det r act or es af i r man que el mt odo requi ere cierta "prestidigitacin" en
cuant o a que el cl cul o se basa en dat os subj et i vos m s que objetivos, que el cont eo
del domi ni o de i nformaci n (y ot r as di mensi ones) puede ser difcil de recopilar des-
pus del hecho, y que el PF no t i ene si gni fi cado fsico directo.- e s sl o un nmer o.
22.2.3 Reconciliacin de las mtricas LDC y PF
La rel aci n ent r e l neas de cdi go y punt os de funci n depende del l enguaj e de pro-
gr amaci n en que se i mpl ement an el s of t war e y la cal i dad del di seo. Varios est u-
di os han i nt ent ado rel aci onar las medi das de PF y LDC. Por ej empl o Albrecth y Gaff-
ney [ALB83]:
La tesis de este trabajo es que la cantidad de funcin que se ofrecer por medio de la apli-
cacin (programa) se puede estimar a partir de pormenorizar los grandes componentes4
de datos que se emplearn o proporcionarn. Ms an, esta estimacin de la funcin de-
be estar correlacionada tanto con la cantidad de LDC que se desarrollar como con el es-
fuerzo de desarrollo necesario.
La t abl a5 si gui ent e [QSM02] of r ece est i maci ones bur das del nmer o pr omedi o de l-
nea s de cdi go que se requi eren para const rui r un punt o de funci n en vari os len-
guaj es de pr ogr amaci n:
Una revisin de es t os dat os indica que una LDC de C++ proporci ona apr oxi mada-
ment e 2.4 veces la "funci onal i dad" (en promedi o) de una LDC de C. Ms an, una
LDC de Smalltalk proporci ona al me nos cuat r o veces la funci onal i dad de una LDC de
un l enguaj e de programaci n convenci onal como Ada, COBOL o C. La utilizacin de la
i nformaci n cont eni da en la t abl a per mi t e "t omar como cont r af uego" [ION98] el soft -
wa r e exi st ent e para est i mar el nmer o de punt os de funci n, una vez que s e conoz-
ca el nmer o total de enunci ados del l enguaj e de pr ogr amaci n.
Se ha encont r ado que l as mt r i cas bas adas en punt os de f unci n y LDC son indi-
cador as r el at i vament e preci sos del es f uer zo y el cost o del desarrol l o de sof t war e. Sin
embar go, empl ear LDC y PF en la est i maci n (captulo 23) requi ere est abl ecer una l-
nea de referenci a histrica de i nformaci n.
En cont ext o del pr oceso y las mt ri cas del proyect o, la pr eocupaci n principal la
gener an la product i vi dad y la calidad: medi das de la "salida" de desarrol l o de soft -
war e como funci n del es f uer zo y el t i empo apl i cados y medi das de la "aptitud par a
el uso" de l os pr oduct os de t r abaj o obt eni dos. Respect o a pr opsi t os de mej or a del
pr oceso y pl aneaci n del proyect o, el i nt ers es histrico. Cul fue la product i vi dad
4 Es importante notar que "pormenorizar los grandes componentes" se puede interpretar en varias
formas. Los ingenieros de software que trabajan en un entorno de desarrollo orientado a objetos
usan el nmero de clases u objetos como el t amao de mtrica dominante. Una organizacin de man
tenimiento puede considerar el t amao del proyecto en trminos del nmero de pedidos de cambios
de ingeniera (captulo 27). Una organizacin de s a e ma s de informacin quiz vea el nmero de
procesos comerciales que afecta una aplicacin-
5 Utilizado con permiso de Quantitative Sotlv. are Mar,ag-smen: www.qsm.com), copyright 2002
TM
PDF Editor
d e de s a r r ol l o del s o f t wa r e e n l os pr oy e c t os p a s a d o s ? Cul f u e la ca l i da d del s o f t wa r e
q u e s e p r o d u j o ? C mo s e p u e d e n e xt r a pol a r al p r e s e n t e la pr oduc t i vi da d y la cal i -
da d p a s a d a s ? C mo p u e d e a y u d a r a me j or a r el p r o c e s o y pl ani f i car n u e v o s pr oyect os
c on ma y o r pr e c i s i n?
Lenguaje de
programacin LDC por punto de funcin
Promedi o Me di ana Bajo Alto
Access
35 38 15 4 7
Ada 154
104 205
APS 86 83 20 184
ASP 69 62
32 127
Ensamblador 337 315 91 694
C 162 109
33 704
C+ +
6 6 53 29 178
Clipper
38 39 27 70
COBOL 77 77 14 400
Cool:Gen/IEF
38 31 10 180
Culpril 51
DBase IV
52

Easytrievel 33 34 25 41
Excel47 46
31 63
Focus
43 42
32 56
FORTRAN
FoxPro
32 35 25 35
Ideal
6 6 52 34 203
IEF/Cool:Gen
38 31 10 180
Informix
42 31 24 57
Java 6 3 53 77
1
JavaScript 58 63 4 2 75
JCl 91 123 26 150
JSP 59
Lotus Notes 21 22 15 25
AAanlis 71 27 22 250
Mapper 118 81
16 245
Natural 6 0 52 22 141
Oracle
30 35 4 217
PeopleSofl
33 32 30 40
Perl
6 0
PL/I 78
67 22 263
Powerbuilder 32 31 11 105
REXX
6 7

RPG ll/lll
61 4 9 24 155
SAS 40 41
33 4 9
Smalltalk
26 19 10 55
SQL 40 37 7 110
VBScript3
34 27 5 0

Visual Basic 4 7 42 16 158
TM
PDF Editor
CAPTULO 22 MTRI CAS DE PROCESO Y PROYECTO 673

i t e
escenario
ta
1 u
los. En
, tengo
> utilice
t guin.
*
pueden
r m o o y
I Por lo
i b pena
rio dosific-
l a s conteos de
r mo o y
22.2.4 Mtricas orientadas a objetos
Las mt ri cas de proyect os de soft ware convenci onal es (LDC o PF) se aplican en la
est i maci n de proyect os de sof t war e ori ent ados a obj et os. Sin embargo, est as mtri-
cas no proporci onan suficiente granul ari dad para la planificacin y los aj ust es de es-
f uer zo que se requi eren conf or me se itera a lo largo de un proceso evolutivo o incre-
ment al . Lorenz y Kidd [LOR94] sugieren el siguiente conj unt o de mt ri cas para pro-
yect os OO:
Nmero de gui one s de es cenari o. Un guin de escenari o (anlogo a los casos
de uso est udi ados a t ravs de las part es 2 y 3 de est e libro) es una secuenci a det a-
llada de pasos que descri ben la interaccin ent re el usuari o y la aplicacin. El nme-
ro de gui ones de escenari o est di rect ament e correl aci onado con el t amao de la
aplicacin y con el nmer o de casos de prueba que se deben desarrollar para ejerci-
t ar el si st ema una vez que se const ruya.
Nmero de c l as e s cl ave. Las clases clave son los "component es enor mement e in-
dependi ent es" [LOR94] definidos con ant el aci n en el anlisis ori ent ado a obj et os
(captulo 8).6 Puesto que las cl ases clave son cent ral es respect o del domi ni o del pro-
bl ema, su nmer o indica la cant i dad de esf uer zo necesari o para desarrollar el soft-
ware. Tambin indican la potencial cantidad de reutilizacin que se aplicar dur an-
te el desarrollo del si st ema.
Nmero de c l as e s de apoyo. Las clases de apoyo son necesari as en la i mpl emen-
tacin del sistema, per o no est n i nmedi at ament e rel aci onadas con el domi ni o del
probl ema. Los ej empl os pueden ser las cl ases 1U, los accesos a bases de dat os y las
cl ases de mani pul aci n y las de clculo. Adems, las cl ases de apoyo se pueden de-
sarrollar para cada una de las cl ases clave. El nmer o de cl ases de apoyo es un in-
dicio de la cant i dad de esf uer zo i ndi spensabl e para desarrollar el soft ware, as como
un indicio de la potencial cant i dad de reutilizacin que se aplicar dur ant e el desa-
rrollo del si st ema.
Nmero promedi o de c l as e s de apoyo por c l as e cl ave. En general, las cl ases
clave se conocen en et apas iniciales del proyecto. Las cl ases de apoyo se defi nen a
lo largo del curso de ste. Si se conoci ese el nmer o promedi o de cl ases de apoyo
por clase clave respect o de un domi ni o de probl ema dado, la est i maci n (con bas e
en el nmer o total de clases) se simplificara mucho. Lorenz y Kidd sugieren que las
aplicaciones con una GUI tienen ent re dos y t res veces el nmer o de cl ases de apo-
yo que las cl ases clave. Las aplicaciones sin GUI tienen ent re una y dos veces el n-
mer o de cl ases de apoyo que las cl ases clave.
Nmero de s ubs i s t e mas . Un subsistema es un agr egado de cl ases que apoyan
una funcin visible para el usuario final de un si st ema. Una vez identificados los sub-
6 En la parte 2 de este libro a las clases clave se les refino como clases de anlisis.
TM
PDF Editor
si st emas e s m s fcil ext ender una pl ani fi caci n r azonabl e en la cual s e haya he
la particin del t rabaj o ent r e el equi po del proyecto.
La utilizacin eficiente en un ent or no de ingeniera de sof t war e or i ent ada a o
t os requi ere recopilar mt ri cas si mi l ares a las anot adas l neas arriba, j unt o con
di das del proyect o t al es como es f uer zo gast ado, er r or es y def ect os descubi ert os
model os o pgi nas de document aci n produci dos. Conf or me la ba s e de dat os cr
( despus de compl et ados vari os proyectos), las rel aci ones ent r e medi das ori ent a
a obj et os y medi das de proyect o pr opor ci onar n mt ri cas que auxilien en la est i -
cin del proyect o.
22.2.5 Mtricas orientadas a casos de uso
Parecera r azonabl e apl i car el cas o de uso7 como una medi da de normal i zaci n
milar a la LDC o PF. Como el PF, el cas o de us o se defi ne en et apas t empr anas
proceso de soft ware, lo que permi t e empl earl o en la est i maci n ant es de iniciar las
tividades significativas de model ado y const rucci n. Los cas os de us o describen
menos indirectamente) funci ones y caract er st i cas visibles al usuari o que son r eq"
t os bsi cos para un sistema. El caso de uso es i ndependi ent e del l enguaj e de pi
maci n. Adems, el nmer o de cas os de us o es di rect ament e proporci onal al t am
de la aplicacin en LDC, as como al nmer o de cas os de prueba que t endrn que
sear se par a ejercitar compl et ament e la aplicacin.
Puest o que los cas os de us o pueden cr ear se con gr ados de abst racci n amp'
ment e di ferent es, no existe t a ma o es t ndar par a ellos. Sin una medi da est ndar,
apl i caci n como medi da de normal i zaci n (por ej empl o, es f uer zo empl eado por
so de uso) es sospechosa. Aunque vari os i nvest i gadores (por ej empl o, [SMI99])
i nt ent ado obt ener mt ri cas de cas o de uso, todava queda mucho t r abaj o por ha
22.2.6 Mtricas de proyectos de ingeniera Web
El obj et i vo de t odos los proyect os de ingeniera Web (parte 3 de est e libro) es c
truir una apl i caci n Web (WebApp) que pr opoci one una combi naci n de cont
y funci onal i dad al usuar i o final. Las medi das y mt r i cas que se empl ean en los
yect os de ingeniera de sof t war e t radi ci onal es son difciles de t raduci r di rect ame
a la WebApp. Incluso, una organi zaci n de i ngeni er a Web debe desarrol l ar una '
se de dat os que le permi t a val orar su product i vi dad y calidad i nt er nas a lo largo
vari os proyect os. Entre las medi das que se pueden recopi l ar est n:
Nme r o de pgi nas Web es t t i cas . Las pgi nas Web de cont eni do est t i co
decir, el usuar i o final no cont rol a el cont eni do despl egado en la pgi na) son las
c omune s de t odas las caract er st i cas WebApp. Estas pgi nas r epr esent an una c
plejidad relativa baj a y por lo general requi eren me nos es f uer zo al const rui rl as
7 Los casos de uso se estudian a travs de las partes 2 y 3 de este libro.
TM
PDF Editor
las pgi nas di nmi cas. Esta medi da proporci ona un indicio del t amao global de la
aplicacin y el esf uer zo que se requiere para desarrollarla.
Nmero de pgi nas Web di nmi cas. Las pgi nas Web de cont eni do di nmi co
(es decir, las acci ones del usuari o final gener an cont eni do personal i zado que s e des-
pliega en la pgina) son esenci al es en t odas las aplicaciones de comerci o electrni-
co, mot ores de bsqueda, aplicaciones financieras y muchas otras categoras de Web-
App. Estas pgi nas represent an una mayor compl ej i dad relativa y requi eren m s es-
fuerzo al construirlas que las pgi nas estticas. Esta medida proporci ona un indicio
del t amao global de la aplicacin y el esf uer zo requeri do para desarrollarla.
Nmero de v ncul os i nt ernos de pgi na. Los vnculos i nt ernos de pgi na son
punt eros que ofrecen un hipervnculo hacia alguna otra pgina Web dentro de la Web-
App. Esta medi da proporciona un indicio del gr ado de acopl ami ent o arqui t ect ni co
dent r o de la WebApp. Conforme aument a el nmer o de vnculos de la pgi na, t am-
bin lo hace el esf uer zo empl eado en el di seo y const rucci n de la navegaci n.
Nmero de obj e t os de dat os pers i s t ent es . Una WebApp puede t ener acceso
a uno o m s obj et os de dat os persi st ent es (por ej empl o, una base de dat os o archi-
vo de datos). Conforme el nmer o de obj et os de dat os persi st ent es crece, t ambi n lo
hace la complejidad de la WebApp y el esf uer zo para i mpl ement arl a aument a pro-
porci onal ment e.
Nmero de s i s t e mas ext ernos e n i nterfaz. Con frecuenci a las WebApps de-
ben hacer i nt erfaz con aplicaciones comerci al es "de cuart o trasero". Conforme cre-
ce el requisito para hacer interfaz, la compl ej i dad del si st ema y el esf uer zo de desa-
rrollo t ambi n aument an.
Nmero de obj et os de cont eni do es t t i co. Los obj et os de cont eni do est t i co
abar can i nformaci n esttica basada en texto, grfica, video, ani maci n y audi o que
se i ncorporan dent ro de la WebApp. En una pgi na Web sencilla pueden apar ecer
mltiples obj et os de cont eni do esttico.
Nmero de obj e t os de cont eni do di nmi co. Los obj et os de cont eni do din-
mi co se gener an con base en las acci ones del usuari o final y abar can i nformaci n
gener ada i nt er nament e basada en texto, grfica, video, ani maci n y audi o que se in-
corporan dent ro de la WebApp. En una pgi na Web sencilla pueden apar ecer mlti-
ples obj et os de cont eni do dinmico.
Nmero de f unci ones ej ecut abl es . Una funcin ej ecut abl e (por ej empl o, un
guin o applet) ofrece cierto servicio comput aci onal al usuari o final. Conforme au-
ment a el nmer o de funci ones ejecutables, t ambi n aument an los esf uer zos de mo-
del ado y construccin.
Cada una de est as medi das s e puede det ermi nar en una et apa rel at i vament e t empra-
na del proceso de ingeniera Web.
Por ej empl o, es posible definir una mt ri ca que refleje el grado de personal i zaci n
de usuari o final que se requiere para la WebApp y correlacionarla con el esf uer zo
TM
PDF Editor
e mp l e a d o e n el p r o y e c t o d e I We b o l o s e r r o r e s d e s c u b i e r t o s c o n f o r me s e l l e va n a ca-
b o r e v i s i o n e s y p r u e b a s . P a r a l o g r a r e s t o , s e d e f i n e
Nsp = n m e r o d e p g i n a s We b e s t t i c a s
Ndp = n m e r o d e p g i n a s We b d i n mi c a s
E n t o n c e s ,
n d i c e d e p e r s o n a l i z a c i n , C = Ndp/(Ndp + Nsp)
El v a l o r d e C va r i a d e 0 a 1. Co n f o r me C c r e c e , el ni ve l d e p e r s o n a l i z a c i n d e la We b-
Ap p s e v u e l v e u n c o n f l i c t o t c n i c o s i g n i f i c a t i v o .
Es p o s i b l e c a l c u l a r y c o r r e l a c i o n a r m t r i c a s s i mi l a r e s d e a p l i c a c i o n e s We b c o r
me d i d a s de l p r o y e c t o , t a l e s c o m o el e s f u e r z o e mp l e a d o , l o s e r r o r e s y d e f e c t o s de s -
c u b i e r t o s y l o s mo d e l o s o p g i n a s d e d o c u me n t a c i n p r o d u c i d o s . C o n f o r me l a b a s e
d e d a t o s c r e c e ( d e s p u s d e q u e v a r i o s p r o y e c t o s s e h a n c o mp l e t a d o ) , l a s r e l a c i o n e s
e n t r e l a s me d i d a s We b Ap p y l a s me d i d a s de l p r o y e c t o p r o p o r c i o n a r n i n d i c a d o r e s
q u e a u x i l i e n e n l a e s t i ma c i n del p r o y e c t o .
HE RRAMI E NT AS DE S OF TWARE
Mtricas del proyecto y el proceso
Obj e t i vo: Ayudar en la definicin, recopila-
cin, evaluacin y reporte de medi das y mtri-
cas de software.
Me c ni c a : Cada herramienta vara en cuant o a su apli-
cacin, pero todas ofrecen mecanismos par a recopilar y
evaluar dat os que conduzcan al clculo de mtricas de
software.
Funclion Point WORKBENCH, desarrollada por Charisma-
tek (www.charismatek.com.au), ofrece una amplia va-
riedad de mtricas orientadas a PF.
MetricCenter, desarrollada por Distributive Software
(www.distributive.com), soporta recopilacin automati-
zada de datos, anlisis, formateo de grficos, genera-
cin de reportes y otras t areas de medicin.
PSM Insight, desarrollada por Practical Software and Sys-
tems Measurement (www.psmsc.com), auxilia en la
creacin y subsiguiente anlisis de una base de datos
de medicin del proyecto.
SUM lool sel, desarrollado por QSM (www.q sm.com), pro-
porciona un completo conjunto de mtricas y herra-
mientas de estimacin.
SPR lool sel, desarrol l ado por Software Productivity Re-
search (www.spr.com), ofrece una coleccin detallada
de herramientas ori ent adas a PF.
TychoMelrics, desarrollado por Predcate Logic, Inc. (www
predicate.com), es una suite de herramientas par a ges-
tionar recopilacin de mtricas y reportes.
La me t a p r i mo r d i a l d e la i n g e n i e r a d e l s o f t wa r e e s p r o d u c i r u n s i s t e ma , a p l i c a d o - !
o p r o d u c t o d e a l t a c a l i d a d d e n t r o d e u n ma r c o t e mp o r a l q u e s a t i s f a g a u n a n e c e s i d a ;
8 Las her r ami ent as anot adas aqu son una muest ra de est a categora. En la mayora de los casos tas]
nombr es de las mi smas son mar cas regi st radas por sus respectivos desarrolladores.
TM
PDF Editor
i oielenle Instile ..
nocen
c cridad d. g |
y tpicos
5 (incluso
) se encuentro
www.
prft yworl d. com.
del mercado. El logro de est a met a requiere que los i ngeni eros de sof t war e apliquen
mt odos efi caces acopl ados con her r ami ent as moder nas dent ro del cont ext o de un
pr oceso de sof t war e maduro. Adems, un buen ingeniero de sof t war e (y los buenos
gest ores de ingeniera del soft ware) debe medi r si se lograr la alta calidad.
Las mt ri cas pri vadas reuni das por los i ngeni eros de sof t war e individuales se asi-
milan con los resul t ados ofreci dos en el mbi t o del proyecto. Aunque se pueden reu-
nir muchas medi das de calidad, el impulso pri mari o en el mbi t o del proyect o es me-
dir los errores y defectos. Las mt ri cas deri vadas de est as medi das proporci onan un
indicio de la efectividad de la garant a de la calidad del sof t war e y de las act i vi dades
de control t ant o de los individuos como del grupo.
Las mt ri cas como los errores en el product o de t rabaj o (por ejemplo, requisitos
o diseo) por punt o de funcin, errores descubi ert os por hora de revisin, y los erro-
r es descubi ert os por hora de prueba ofrecen una visin de la eficacia de cada una de
las act i vi dades i mpl i cadas en la mtrica. Los dat os de error t ambi n se pueden em-
plear en el clculo de la eficacia en la eliminacin de defectos (EED) para cada activi-
dad del mar co de t rabaj o del proceso. La EED se estudia en la seccin 22.3.2.
22.3.1 Medicin de la calidad
Aunque existen muchas medi das de la calidad del soft ware, 9 la correccin, la facili-
dad de mant eni mi ent o, la integridad y la facilidad de uso ofrecen i ndi cadores tiles
para el equi po del proyecto. Gilb (GIL88] sugiere defi ni ci ones y medi ci ones para ca-
da una de ellas.
Correcci n. Un pr ogr ama debe operar correct ament e o proporci onar poco va-
lor para sus usuari os. La correccin es el gr ado en que el sof t war e desempea la fun-
cin para la que fue creado. La medi da m s comn para la correccin es defect os
por KLDC, donde un defect o se define como una falta compr obada de concordanci a
con los requisitos. Cuando se consi dera la calidad global de un product o de sof t wa-
re, los defect os son los pr obl emas que report a un usuari o del pr ogr ama despus de
que st e se liber para el uso general. Para los propsi t os de la evaluacin de la ca-
lidad, los defect os se cuent an sobre un peri odo est ndar, usual ment e un ao.
Faci l i dad de mant eni mi ent o. El mant eni mi ent o del sof t war e justifica m s es-
fuerzos que cualquier otra actividad de la ingeniera del soft ware. La facilidad de
mant eni mi ent o es la sencillez con la que un pr ogr ama puede corregirse si se en-
cuent ra un error, adapt ar se si su ent or no cambi a, o mej orar si el cliente desea un
cambi o en los requisitos. No existe forma de medi r di rect ament e la facilidad de man-
t eni mi ent o; en consecuenci a, se deben empl ear medi das indirectas. Una si mpl e me-
dida ori ent ada al t i empo es el tiempo medio de cambio (TMC), el t i empo que t oma
anal i zar el cambi o solicitado, di sear una modificacin apropi ada, i mpl ement ar el
9 En el capi t ul o 15 se pr esent una discusin detallada de los fact ores que influyen en la calidad del
sof t war e y las mt ri cas que se pueden usar para valorar la calidad del soft ware.
TM
PDF Editor
cambi o, probarl o y distribuir el cambi o a t odos los usuarios. En promedi o, los pro-
gr amas susceptibles de mant eni mi ent o t endrn un TMC baj o (para tipos de cambi os
equivalentes) que los pr ogr amas que no lo son.
Integri dad. La integridad del sof t war e se ha vuelto cada vez m s i mport ant e en
la edad de los ciberterroristas y hackers. Este at ri but o mide la habilidad de un siste-
ma para resistir at aques (tanto acci dent al es como intencionales) a su seguridad. Los
at aques se pueden realizar en los t res component es del soft ware: programas, datos
y document os.
La medicin de la integridad requi ere definir dos at ri but os adicionales: amenaza
y seguri dad. Amenaza es la probabilidad (que puede est i marse o deduci rse de eviden-
cia emprica) de que un at aque de un tipo especfico ocurrir dent ro de un t i empo
dado. Seguridad es la probabilidad (que puede est i marse o deduci rse de evidencia
emprica) de que se repela el at aque de un tipo especfico. Ent onces, la integridad de
un si st ema se puede definir como:
integridad = 1 - ( amenaza x (1 seguridad))
Por ej empl o, si la amenaza (la probabilidad de que un at aque ocurrir) es 0.25 \
la seguridad (la posibilidad de repel er un ataque) es 0.95, la integridad del si st ema es
0.99 (muy elevada). Si, por otra part e, la probabilidad de amenaza es 0.50 y la posi-
bilidad de repeler un at aque es slo 0.25, la integridad del si st ema es 0.63 (inacepta-
bl ement e baja).
Faci l i dad de u s o . Con frecuenci a, un pr ogr ama que no es fcil de usar est con-
denado al fracaso, incluso si las funci ones que realiza son valiosas. La facilidad de
uso es un i nt ent o por cuantificar la sencillez de la aplicacin al utilizarla y se puedr
medi r en t rmi nos de las caractersticas pr esent adas en el captulo 12.
Los cuat ro fact ores apenas descri t os sl o represent an una muest ra de los que se
han propuest o como medi das para la calidad del soft ware. El captulo 15 considera
est e tpico con mayor detalle.
22.3.2 Eficacia en la eliminacin de defectos
Una mtrica de calidad que ofrece benefi ci os t ant o en el mbi t o del proyect o como
en el del proceso es la eficacia en la eliminacin de defectos (EED). En esenci a, la EEI
es una medi da de la habilidad de filtrar las actividades de la garant a de cualidad y
de control conforme se aplica a t ravs de t odas las actividades del mar co de traba;:
del proceso.
Cuando se consi dera un proyecto como un todo, la EED se define de la manera
siguiente:
EED = / ( + D)
donde es el nmer o de errores encont r ados ant es de ent regar el sof t war e al usua-
rio final, y D es el nmer o de defect os encont r ados despus de la ent rega.
TM
PDF Editor
CAPTULO 22 MTRICAS DE PROCESO y PROYECTO 6 7 9
s baja
t avanza en
el dise o,
ims
mejorarlo
'.se
los revi-
El val or i deal de la EED es 1. Est o es: n o s e encuent r a def ect o a l guno e n el s of t wa -
re. En real i dad, D ser ma yor que 0, per o el val or de EED t odav a pue de acer car s e a
1. Conf or me E a u me n t a (para un val or d a d o de D), el val or gl obal de EED c omi e nz a
a acer car s e a I. De hecho, c onf or me E a ume nt a , es pr obabl e que el val or final de D
di s mi nuya (los er r or es s e filtran a nt e s de que s e convi er t an en def ect os) . Si se utili-
za c o mo una mt r i ca que pr opor ci ona un i ndi cador de la habi l i dad de filtrado de l as
act i vi dades de cont rol y a s e gur a mi e nt o de la cal i dad, EED al i ent a a un equi po de
pr oyect o de s of t war e a instituir t cni cas par a encont r a r t ant os er r or es c o mo s ea po-
si bl e a nt e s de la ent r ega.
La EED t ambi n s e pue de apl i car en el pr oyect o par a val or ar la habi l i dad de un
equi po de encont r a r er r or es a nt e s de que pa s e n a la si gui ent e act i vi dad del ma r c o de
t r abaj o o a la si gui ent e t ar ea en la i ngeni er a del sof t war e. Por ej empl o, la t ar ea de an-
lisis de r equi si t os pr oduce un model o de anl i si s que s e revi sa par a encont r ar y co-
rregi r er r or es. Aquel l os er r or es que no s e e nc ue nt r a n dur a nt e la revi si n del mode -
lo de anl i si s pa s a n al di s eo ( donde pue de n o n o encont r ar s e) . Cua ndo se apl i ca e n
es t e cont ext o la EED s e r edef i ne c o mo
EED,- = / ( , + / + l )
donde E es el n me r o de er r or es encont r a do dur a nt e la act i vi dad i de i ngeni er a de
s of t wa r e y E , , es el n me r o de er r or es e nc ont r a do dur a nt e la act i vi dad / + 1 de i n-
geni er a del s of t war e que s e pue de segui r par a l l egar a er r or es que no f uer on des cu-
bi er t os en la act i vi dad i de i ngeni er a del s of t war e.
Un obj et i vo de cal i dad par a un equi po de s of t wa r e (o un i ngeni er o de s of t war e in-
dividual) es l ograr una EED, que s e a cer que a 1. Est o es: los er r or es deben filtrarse
a nt e s de que pa s en a la si gui ent e act i vi dad.
HOGARSEGURO
Establecimiento de un enfoque de mtricas
El e s c e n a r i o : Of i ci na d e Doug
dos d as des pus d e la reuni n inicial a c e r c a de
- as d e sof t war e. ;
e s : Doug Miller ger ent e del equi po d e i nge-
s of t war e d e HogarSeguro) y Vi nod Raman y
t ozar , mi embr os del equi po d e i ngeni er a d e soft-
del pr oduct o.
ersacin:
Ust edes dos t i enen opor t uni dad de a pr e nde r un
acer ca d e mt ri cos del pr oces o y el proyect o?
1 y J a mi e : [ Ambos asi ent en con la c a be z a . ]
Si empr e es una bue na i dea est abl ecer met as cuan
a dopt a n a l guna mt ri cas. Cul es son las suyas?
Vi n o d : Nuest r as mt ri cas se deben enf ocar en la cali-
da d. De hecho, nuest ra met a gl obal es mant ener en un
m ni mo absol ut o el nmer o d e errores que pasamos, d e
una act i vi dad d e i ngeni er a del s of t war e a l a siguiente.
Do u g : Y as egr ens e muy bi en d e que el nmer o d e de-
fectos l i ber ados con el pr oduct o se ma nt enga t an cer ca
d e cer o c omo sea posi bl e.
Vi n o d ( a s i e n t e c o n l a c a b e z a ) : Desde l uego.
J a mi e : Me gust a la EED c omo mtrica,, y erijo que po-
demos empl ear l a en todo el proyect o. Ade m s , pode mos
apl i coHa conf or me nos movamos d e une act i vi dad del
mor co d e t r a ba d a le si gui ent e. Eso nos al ent ar p a r o
encortror errores en c odo paso.
TM
PDF Editor
Vi nod: Tambin me gustara reunir el nmero de horas
que pasamos en las revisiones
Jami e: Y el esfuerzo global que pasamos en cada tarea
de ingeniera del software.
Doug: T puedes calcular una razn de revisin a desa-
rrollo... podra ser interesante.
Jami e: Me gustara seguir tambin algunos datos de ca-
so de-uso, Como la cantidad de esfuerzo requerido para
desarrollar un caso de uso, la cantidad de esfuerzo re-
querido para construir software para implementar un ca-
so de uso y. . .
Doug (sonr e): Creo que tendremos que conservar ed
simple.
Vi nod: Deberamos, pero una vez que te metes en e
asunto de las mtricas, existen muchas cosas i nt erese = t
que observar.
Doug: Estoy de acuerdo, pero caminemos antes de cc
rrer, y apegumonos a nuestra meta. Limiten los datos
que recopilen a cinco o seis elementos, y estamos listo;
para despegar. ^
2 2 . 4 I NTEGRACI N DE LAS MTRI CAS DENTRO DEL PROCESO DE SOFTV. AI
La mayor a de l os des ar r ol l ador es de s of t wa r e t odav a no mi de n y, por d e s g r a r J
muc hos t i enen poc o de s e o de c ome nz a r . Como s e ha s e a l a do e n es t e cap t ul : M
pr obl ema es cultural. El i nt ent o de recopi l ar medi das donde nadi e lo ha he c ho en e: J
s a do con f r ecuenci a gener a r esi st enci a. "Por qu t e n e mo s que hacer est o?" p r e r _ r J
ta un ges t or de pr oyect o a cos a do. "No le veo el caso", s e quej a un pr of esi onal : xm
exces o de t r abaj o.
En es t a s ecci n s e cons i der an a l gunos a r g ume nt os par a l as mt r i cas de softv, 2 J
y s e pr es ent a un e nf oque par a i nst i t ui r un pr ogr a ma de r ecopi l aci n de mt r i cas
una or gani zaci n de i ngeni er a del s of t wa r e. Per o a nt e s de c ome nz a r , convi ene
si der ar [GRA87] a l guna s pa l a br a s de cor dur a de Gr ady y Caswel l :
Algunas de las cosas que descri bi mos aqu sonarn bast ant e sencillas. En realidad, sir
embargo, el est abl eci mi ent o de un programa de mt ri cas de soft ware exitoso en el mt
to de la compa a es un t rabaj o duro. Cuando deci mos que se debe esperar al menos tres
aos ant es de que est n disponibles t endenci as organi zaci onal es amplias, se obt i ene a
guna i dea del mbi t o de tal esfuerzo.
Vale la pe na pr es t ar at enci n a la adver t enci a que s ugi er en es t os aut or es, pe r o J :
benef i ci os de la medi ci n s on t an convi ncent es que el t r abaj o dur o val e la pena
22.4.1 Argumentos para las mtricas del software
Por qu e s i mpor t ant e medi r el pr oc e s o de i ngeni er a del s of t wa r e y el produc
( soft ware) que el abor a? La r es pues t a es r el at i vament e obvi a. Si n o s e mi de, no exs *
t e una f or ma real de det er mi nar si s e est me j or a ndo. Y si no se mej or a, s e est pe-'
di do.
Al cues t i onar y eval uar la pr oduct i vi dad y l as medi da s de cal i dad, un equi po
s of t wa r e (y su gest i n) pue de es t abl ecer me t a s si gni fi cat i vas par a mej or a r el proce-J
s o del s of t war e. En el cap t ul o 1 s e a punt que el s of t wa r e es un t e ma comer ci al e s J
TM
PDF Editor
CAPTULO 22 MTRI CAS DE PROCESO Y PSOYECTO 68 1
t r at gi co par a mu c h a s c ompa a s . Si el pr oces o con el cual se desar r ol l a puede me-
j or ar se, s e pr oduci r un i mpa ct o di r ect o en lo s us t anci al . Per o par a es t abl ecer obj e-
t i vos de mej or a es pr eci so c ompr e nde r el e s t a do act ual del des ar r ol l o de s of t war e
Por lo t ant o, la medi ci n s e e mpl e a par a es t abl ecer una l nea ba s e de pr oces o a par-
tir de la cual se eval an l as mej or as .
"Gest i onamos l as cosas me di a nt e los nme r os en muchos aspect os de nues t r as v i d a s . . . Estos nme r os nos br i ndan
par i dad d e juicio y nos a yuda n a dirigir nues t r as acci ones. "
Mf chael Ma h y Larry
Los r i gor es cot i di anos del t r abaj o del pr oyect o de s of t wa r e dej a n poc o t i empo pa-
ra ej erci t ar el pe ns a mi e nt o es t r at gi co. Los ges t or es de pr oyect os de s of t war e e s t n
pr e oc upa dos con t e ma s m s concr et os ( aunque i gual ment e i mpor t ant es ) : des ar r o-
llar es t i maci ones de pr oyect o si gni fi cat i vas, pr oduci r s i s t ema s de al t a cal i dad, t ener
el pr oduct o en ci rcul aci n a t i empo. Si s e e mpl e a la medi ci n par a es t abl ecer una li-
ne a bas e del pr oyect o, ca da uno de di chos t e ma s s e vuel ve m s manej abl e. Ya s e ha
me nc i ona do que la l nea ba s e si rve c o mo f u n d a me n t o par a la est i maci n. Adi ci onai -
ment e, la r ecopi l aci n de mt r i cas de cal i dad per mi t e que una or gani zaci n "si n: :
ni ce" s u pr oc e s o de s of t wa r e par a r emover l as c a us a s "poco vi t al es" de l os def ect o;
que t i enen el ma yor i mpact o sobr e el desar r ol l o del s of t war e. 1 0
22.4.2 Establecimiento de una lnea base
I Qu e s una Con el es t abl eci mi ent o de una l nea ba s e de mt r i cas s e obt i enen benef i ci os en l os
11*1 mbi t os del pr oces o, del pr oyect o y del pr oduct o (t cni co). I ncl uso la i nf or maci n
l e " 6 q u e S e r e c o P " ' a n o ^ c e s i t a ser f unda me nt a l me nt e di f er ent e. Las mi s ma s mt r i cas
irciona a un pue de n servi r a mu c h o s maes t r os . La l nea ba s e de mt r i cas cons i s t e de dat os r eco-
i d e pi l ados en pr oyect os pr evi os de desar r ol l o de s of t wa r e y pue de n s er t an s i mpl es co-
Ire- mo la t abl a pr es ent a da e n la figura 22. 2 o t an compl ej os c o mo una ba s e de da t os de-
t al l ada q u e cont i ene doc e na s de medi da s de pr oyect os y l as mt r i ca s der i vadas de
st os.
Para s er un auxi l i ar efi caz en el pr oces o de mej or a o de cost o y es f uer zo, l os dat os
de la l nea ba s e deben t ener l os s i gui ent es at r i but os: 1) l os da t os deben s er r azona-
bl ement e pr eci sos: s e deben evi t ar l as "conj et ur as " acer ca de l os pr oyect os pa s a dos
2) l os dat os deben r ecopi l ar se par a t a nt os pr oyect os c o mo s ea posi bl e; 3) l as medi -
da s deben s er cons i s t ent es , por ej empl o: una l nea de cdi go de be i nt er pr et ar s e con-
s i s t ent ement e a t r avs de t odos l os pr oyect os par a l os que s e r ecopi l an los dat os; 4)
l as apl i caci ones de be n s er si mi l ar es al t r abaj o que se es t i mar : t i ene poc o s ent i do
e mpl e a r una l nea ba s e en un t r abaj o de s i s t ema s de i nf or maci n en bl oque par a es-
t i mar una apl i caci n a ni da da en t i e mpo real .
10 En el capitulo 26 se tratan con detalle est as :deas. formalizadas en un enfoque denomi nado garan-
ta estadstica de calidad del software.
TM
PDF Editor
68 2 PARTE CUATRO GESTI N DE PROYECTOS DE SOFTWARE
Proceso de
recopilacin
de mtricas
de software.
de mtricas I Indicadores
\
CLAVE
Los dat os de mtricos
de lineo base deben
recopilarse de uno gran
muestra representativa
de proyectos de
soft ware previos.
22.4.3 Recopilacin, clculo y evaluacin de mtricas
En la figura 22. 3 s e i l ust ra el pr oces o con el que s e es t abl ece una l nea ba s e de m-
tricas. De ma n e r a ideal, l os da t os neces ar i os par a ha cer l o s e ha n r ecopi l ado confor-
me s e a va nz a . Por desgr aci a, es t o rara vez e s el cas o. En cons ecuenci a , la recopi l a-
ci n de da t os r equi er e una i nvest i gaci n hi st ri ca de l os pr oyect os pr evi os par a re-
const r ui r l os dat os r equer i dos. Una vez que s e han r ecopi l ado l as medi da s (incues-
t i ona bl ement e el pa s o m s difcil) es posi bl e cal cul ar l as mt r i cas. Dependi endo de
la ampl i t ud de l as me di da s r ecopi l adas, l as mt r i cas pue de n a ba r ca r una ampl i a ga
ma de mt r i cas or i ent a da s a la apl i caci n (por ej empl o, LDC, PF, or i ent ada a obj et os,
WebApp), as c o mo ot r as or i ent adas a la cal i dad y al pr oyect o. Fi nal ment e, l as m-
t ri cas deben eval uar s e y apl i car se dur a nt e la es t i maci n del t r abaj o t cni co, el con-
trol del pr oyect o y la mej or a del pr oces o. La eval uaci n de l as mt r i cas s e cent r a er
l as r a z one s s ubya c e nt e s d e l os r es ul t ados obt eni dos y pr oduce un c onj unt o de indi-
c a dor e s que gu an el pr oyect o o pr oces o.
^ O N S f J O ^
Sise est comen-
zando o recopilar
datos de mtricas,
recurdese mante-
nerlos simples. Silos
dalos abruman los
esfuerzos de mtricos
k a / s o t o .
La gr an mayor a d e l as or ga ni za ci ones de des ar r ol l o de s of t wa r e t i ene me n o s de 2C
empl ea dos . Es i rraci onal , y en la mayor a de l os c a s os irreal, es per a r que t al es orga-
ni zaci ones des ar r ol l ar n pr ogr a ma s det al l ados de mt r i cas de s of t war e. Sin embar -
go, es r a zona bl e suger i r que l as or gani zaci ones de s of t wa r e de t odos l os t amaos
mi den y l uego e mpl e a n l as mt r i cas r es ul t ant es par a ayudar a mej or a r s u s pr ocesos
de s of t wa r e l ocal es y la cal i dad y la punt ual i dad de l os pr oduct os que el abor an.
Un e nf oque de s ent i do c omn r es pect o de la i mpl ement aci n de cual qui er activi-
dad r el aci onada con el pr oces o de s of t war e es mant ener l o si mpl e, personal i zarl o para
sat i sf acer l as neces i da des l ocal es y a s egur a r s e de que agr ega val or. En l os pr r af os
TM
PDF Editor
68 3
Cmo se
te un
de
de s of t -
* s i mpl e" ?
que s i guen se exami na c mo e s t os l i ncami ent os s e r el aci onan con l as mt r i cas pa-
r a pe que os ne goc i os . "
"Mant ener l o si mpl e" es una di rect ri z que f unci ona r a z ona bl e me nt e bi en en mu-
c ha s act i vi dades. Pero, c mo s e deduce un conj unt o "si mpl e" de mt r i cas de sof t -
wa r e que aun as pr opor ci one val or, y c mo s e gar ant i za que di chas mt r i cas si m-
pl es s at i s f ar n l as ne c e s i da de s de una or gani zaci n de s of t war e par t i cul ar ? Un buer .
c omi e nz o cons i s t e e n enf oca r s e no s obr e l as medi ci ones si no m s bi en sobr e l os re-
sul t ados. Al gr upo de s of t wa r e s e le ent r evi st a pa r a defi ni r un obj et i vo senci l l o que
r equi er e mej or a. Por ej empl o, "reduci r el t i empo par a eval uar e i mpl ement ar l os
c a mbi os sol i ci t ados". Una or gani zaci n pe que a pue de s el ecci onar el si gui ent e c o r -
j unt o de me di da s que s e r ecopi l an con facilidad:
Ti empo ( hor as o d as) t r ans cur r i do de s de el mo me n t o en que s e hi zo una sol i -
ci t ud ha s t a que la eval uaci n est compl et a, tcola.
Es f uer zo ( per sona- hor as) par a r eal i zar la eval uaci n, Tmal.
Ti empo ( hor as o das) t r ans cur r i do des de que s e compl et a la eval uaci n has t a
la as i gnaci n del pedi do de c a mbi o al per s onal , /
Es f uer zo ( per s ona- hor as ) r equer i do par a ha cer el cambi o, Tcamh0.
Ti empo r equer i do ( hor as o d as) par a ha cer el cambi o, tClimhi0.
Errores des cubi er t os dur a nt e el t r abaj o par a ha cer el cambi o, Ecambio.
Def ect os des cubi er t os de s pu s de que el ca mbi o es l i berado a la ba s e de
cl i ent es, Dcambio.
Una vez que se han r ecopi l ado di chas medi da s par a var i os c a mbi os sol i ci t ados
es posi bl e cal cul ar el t i empo t r anscur r i do total pr omedi o des de que el ca mbi o se sol i -
ci t has t a la i mpl ement aci n del cambi o y el por cent aj e del t i empo t ranscurri do a b-
s or bi do por la cola de es per a inicial, la eval uaci n y la asi gnaci n y la i mpl ement aci xi
del cambi o. De igual modo, es posi bl e det er mi nar el por cent aj e del es f uer zo que re-
qui er en la eval uaci n y la i mpl ement aci n. Est as mt r i cas se eval an en el cont ext o
de los dat os de cal i dad, Ecambto y Dcambio. Los por cent aj es pr opor ci onan conoci mi er t
det al l ado de dnde s e vuel ve l ent o el pr oces o de solicitud de ca mbi o y conduce a pa-
s os de mej or a del pr oces o par a reduci r Tavl, fmJ/ , Tcambi0 o Ecambk> . Adems, la efi ca-
cia en la de el i mi naci n de def ect os s e puede cal cul ar c o mo
EED = EamMg/(Ecamt,io + Dcarnb)
EED s e c ompa r a con el t i empo t r ans cur r i do y el e s f ue r z o total par a det er mi nar el i m-
pact o de l as act i vi dades de a s e gur a mi e nt o de la cal i dad en el t i empo y el es f uer zc
r equer i dos par a r eal i zar un cambi o.
11 Esta exposicin es igualmente relevante para ios equipos de software que han adoptado un proce-
so de desarrollo de software gil (capitulo 4
TM
PDF Editor
68 4 PARTE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
2 2 . 6 ES TABLECI MI ENTO DE UN P ROGRAMA DE MTRI CAS DE SOFTWAT
AGMefwGoolDtmi
Software Meosviement
se puede descargor de:
www. s e i . a n i i . e d u .
CLAVE
l a s mt r i cas de
s of t wa r e que s e el i j an
de be n est ar b a s a d o s
en l a s me t a s de
negoci os y t cni cas
que s e de s e on lograr.
El Sof t war e Engi neer i ng Inst i t ut e (SE1) ha el a bor a do una gu a det al l ada [PAR96] pa-
ra es t abl ecer un pr ogr a ma de mt r i cas de s of t war e "dirigido por met as". La gu a su-
gi ere l os s i gui ent es pas os :
1. i dent i fi car l os obj et i vos de la empr es a .
2 . Ident i fi car lo que se qui er e conocer o apr ender .
3. Ident i fi car l os s ubobj et i vos .
4. Ident i fi car l as ent i dades y at r i but os r el aci onados con l os obj et i vos secundar i os.
5. For mal i zar l os obj et i vos de la medi ci n.
6. Ident i fi car pr egunt a s cuant i f i cabl es y l os i ndi cador es r el aci onados que s e em-
pl ear n c o mo apoyo par a l ogr ar l os obj et i vos de s us medi ci ones .
7. Ident i fi car l os e l e me nt os de dat os que s e r ecopi l ar n par a const r ui r l os indi-
c a dor e s que a yuda r n a r es ponder l as pr egunt as .
8 . Definir l as medi da s que s e e mpl e a r n y ha cer que es t as def i ni ci ones s ea n
oper at i vas .
9 . Ident i fi car l as acci ones que s e t oma r n par a i mpl ement a r l as medi das .
10. Pr epar ar un pl an par a i mpl ement ar l as medi das .
Una exposi ci n det al l ada de e s t os pa s os mej or s e dej a par a el l i bro del SEI. Sin em-
bar go, bi en val e la pe na dar un br eve vi st azo a l os punt os cl ave.
Puest o que l as f unci ones comer ci al es de apoyo del s of t war e di f er enci an l os si st e
ma s o pr oduct os ba s a dos en comput a dor a , o a ct a n c omo un pr oduct o en s mi s mo,
l as me t a s def i ni das par a l as e mpr e s a s casi s i empr e pue de n s egui r s e haci a a ba j o ha s
ta me t a s espec f i cas al nivel de la i ngeni er a del s of t war e. Por ej empl o, cons i dr es e
una c ompa a que fabri ca a va nz a dos s i s t ema s de s egur i dad par a el hoga r que t i ene
cont eni do de s of t war e sust anci al . Al t r abaj ar c o mo equi po, la i ngeni er a del s of t wa-
re y l os ges t or es del negoci o pue de n conf ecci onar una lista de me t a s pr i or i zadas dei
negoci o:
1. Mej or ar la sat i sf acci n de l os cl i ent es con l os pr oduct os .
2. Hacer que l os pr oduct os s ea n m s f ci l es de usar .
3 . Reduci r el t i empo que t oma pone r un pr oduct o e n el mer ca do.
4 . Si mpl i fi car el s opor t e par a l os pr oduct os .
5. Mej or ar la obt enci n gl obal de ut i l i dades.
La or gani zaci n de s of t wa r e e xa mi na c a da met a de negoci os y pr egunt a: Qu act i -
vi dades s e ges t i onan o ej ecut an y qu s e qui er e mej or a r de di chas act i vi dades? Para
r es ponder e s t a s pr egunt a s el SEI r ecomi enda la cr eaci n de una "lista ent i dad- pr e-
gunt a" e n la que s e a not en t odas l as c os a s (ent i dades) dent r o del pr oces o de s of t wa-
TM
PDF Editor
CAPTULO 22 MTRI CAS DE PROCESO Y PROYECTO 68 5
re que s e gest i onan o en las que influye la organi zaci n de soft ware. Los ej empl os
de ent i dades incluyen recursos de desarrollo, product os de t rabaj o, cdi go fuent e,
casos de prueba, solicitudes de cambi o, t areas de ingeniera del sof t war e y planifica-
ciones. Para cada ent i dad en la lista el personal de sof t war e desarrolla un conj unt o
de pregunt as que eval an caract er st i cas cuant i t at i vas de la ent i dad (por ejemplo, ta-
mao, cost o, t i empo de desarrollo). Las pregunt as que se deri van de la creaci n de
una lista ent i dad-pregunt a conducen a la derivacin de un conj unt o de subobj et i vos
que se rel aci onan di rect ament e con las ent i dades creadas y las act i vi dades realiza-
das como part e del proceso del soft ware.
Consi drese la cuart a met a: "Simplificar el soport e para los product os". Para est a
met a se puede derivar la siguiente lista de pregunt as [PAR96]:
La solicitud de cambi o del cliente cont i ene la i nformaci n requeri da para
eval uar adecuadament e el cambi o y luego i mpl ement arl o en una forma opor-
t una?
Cun grande es el registro de peticin de cambi o?
El t i empo de respuest a para fijar los bugs es acept abl e con bas e en las nece-
si dades del cliente?
Se sigue el proceso de control de cambi os (captulo 27)?
Los cambi os de alta prioridad se i mpl ement an en forma oport una?
Con base en est as pregunt as la organi zaci n de soft ware puede deducir el siguiente
subobjetivo: mejorar el desempe o del proceso de gestin de cambio. Se identifican las
ent i dades y los at ri but os del proceso de sof t war e rel evant es respect o del subobjeti-
vo, y se del i nean las met as de medicin asoci adas con ambos el ement os.
El SEI [PAR96] proporciona una gua det al l ada para los pasos 6 al 10 de su enfo-
que de medicin ori ent ado a objetivos. En esenci a, se aplica un proceso de refina-
mi ent o pas o a pas o en el que los objetivos s e retinan en pregunt as que posterior-
ment e se refinan en ent i dades y at ri but os que ent onces se retinan en mtricas.
\
Establecimiento de un programa de mtricas
El Software Productivity Center (www.spc.ca) Se definen las tareas asociadas con cada
actividad.
Se anotan las funciones de aseguramiento de la
calidad.
Se hoce una lista con los productos de t rabaj o
producidos.
sugiere un enfoque de ocho pasos para
r un programa de mtricas dentro de una
izacin de software y que se puede emplear como
va al enfoque del SEI descrito en la seccin 22..
enfoque se resume a continuacin.
Entender el proceso de software existente.
Se definen las actividades del marco de t rabaj o
(captulo 2).
Se describe la informacin de entrada para cada
actividad.
2. Definir los objetivos que se lograrn mediante el
establecimiento de un programa de mtricas.
Ejemplos: mejorar la precisin de la estimacin,
mejorar lo colidod del producto.
y
TM
PDF Editor
r
3.
4.
5.
Identificar las mtricas requeridas para lograr los
objetivos.
Se definen las preguntas que deben responderse;
por ejemplo, cuntos errores encontrados en
una actividad de marco de trabajo pueden
seguirse hasta la actividad del marco de trabajo
precedente?
Crear medidas y mtricas que sern recopiladas y
calculadas.
Identificar las medidas y mtricas que sern
recopiladas y calculadas.
Establecer un proceso de recopilacin de medidas
respondiendo las siguientes preguntas:
Cul es la fuente de las mediciones?
Las herramientas se pueden emplear en la
recopilacin de los datos?
Quin es responsable de la recopilacin de
datos?
Cundo se recopilan y registran los datos?
Cmo se almacenan los datos?
Qu mecanismos de validacin se aplican para
garantizar que los datos sean correctos?
6. Adquirir herramientas adecuadas para apoyar la
recopilacin y evaluacin.
7. Establecer una base de datos de mtricas.
Se establece la complejidad relativa de la base de
datos.
Se explora el empleo de herramientas
relacionadas (por ejemplo, un almacn SCM,
captulo 27).
Se evalan los productos de base de datos
existentes.
8. Definir mecanismos de realimentacin adecuados.
Quin requiere informacin de mtricas en
marcha?
Cmo se entregar la informacin?
Cul es el formato de la informacin?
Una descripcin considerablemente ms detallada de esto;
ochos pasos se puede descargar de
http://www. spc. ca/resources/metrics/.
Las medi ci ones per mi t en que los gest or es y pr of esi onal es mej or en el pr oceso
soft ware; auxilien en la pl ani fi caci n, segui mi ent o y cont rol de un proyect o de s<
ware; y eval en la calidad del pr oduct o (software) que se produce. Las medi das
at ri but os espec fi cos del pr oceso, proyect o y pr oduct o se utilizan para cal cul ar i
t ri cas de sof t war e. Di chas mt ri cas se pueden anal i zar par a of r ecer i ndi cadores i
gu en las acci ones de gest i n y tcnica.
Las mt r i cas del pr oceso per mi t en que una or gani zaci n adopt e una visin estr
tgica al pr opor ci onar i nformaci n det al l ada de la efi caci a de un pr oceso de softv
re. Las mt r i cas de proyect o son tcticas; per mi t en que un gest or de pr oyect o ada
te el flujo de t rabaj o del proyect o y un enf oque t cni co realista en t rmi nos de tiemp
Las mt ri cas or i ent adas t ant o al t a ma o como a la funci n se apl i can a lo lar
de t oda la i ndust ri a. Las mt ri cas or i ent adas al t a ma o empl ean la l nea de cdi j
como un fact or de normal i zaci n para ot r as medi das como per s ona- mes o defecto
El punt o de funci n se deduce de las medi das del domi ni o de la i nformaci n y de i
val oraci n subj et i va de la compl ej i dad del probl ema. Adems, se pueden utilizar I
mt r i cas or i ent adas a obj et os y las mt r i cas de apl i caci n Web.
Las mt r i cas de cal i dad del sof t war e, como l as mt ri cas de product i vi dad, se er
f ocan sobr e el proceso, el proyect o y el product o. Al desarrol l ar y anal i zar una lne
TM
PDF Editor
68 7
b a s e d e m t r i c a s p a r a l a c a l i da d, u n a o r g a n i z a c i n p u e d e c or r e g i r a q u e l l a s r e a s del
p r o c e s o d e s o f t wa r e q u e c a u s a n d e f e c t o s d e s o f t wa r e .
La me d i c i n r e s ul t a e n c a mb i o s c ul t ur a l e s . La r e c opi l a c i n d e d a t o s , el c l c u l o y
el a n l i s i s d e m t r i c a s s o n l os t r e s p a s o s q u e p r e c i s o i mp l e me n t a r p a r a c o me n z a r u n
p r o g r a ma d e m t r i c a s . En g e n e r a l , u n e n f o q u e o r i e n t a d o a o b j e t i v o s a y u d a a q u e u n a
o r g a n i z a c i n s e e n f o q u e e n l a s m t r i c a s c o r r e c t a s p a r a s u n e g o c i o . Al c r e a r u n a l-
n e a b a s e d e m t r i c a s u n a b a s e d e d a t o s q u e c o n t i e n e me d i c i o n e s d e p r o c e s o y
p r o d u c t o l os i n g e n i e r o s d e s o f t wa r e y s u s g e s t o r e s p u e d e n c o mp r e n d e r me j o r el
t r a b a j o q u e h a c e n y el p r o d u c t o q u e e l a b o r a n .
[ALB831 Albrecht, A. J. y J. E. Gaffney, "Soft ware Function, Sour ce Lines of Code and Devel op-
ment Effort Prediction. A Sof t war e Sci ence Validation", e n IEEE Ttans. Software Ertgirccring,
novi embr e de 1983, pp. 639-648.
[BOE81] Boehm, B Software Engineering Economics, Prentice-Hall, 1981.
[GRA87| Grady, R. B. y D. L. Caswell, Software Metrics: Establishing a Company-Wide Program,
IGRA92] Grady, R. G., Practical Software Metrics for Project Management and Process Improvement,
[G1L88] Gilb, T Principies of Software Project Management, Addison-Wesley, 1988.
[HET93] Hetzel, W., Making Software Measurement Work, QED Publ i shi ng Group, 1993.
[HUM95] Humphrey, W., A Discipline for Software Engineering, Addison-Wesley, 1995.
[1EE93] IEEE Software Engineering Standards, St andard 610. 12-1990, pp. 47-48.
[JON86] Jones, C., Programming Productivity, McGraw-Hill, 1986.
[JON9I] Jones, C., Applied Software Measurement, McGraw-Hill, 1991.
UON98] Jones, C., Estimating Software Costs, McGraw-Hill, 1998.
[LOR94] Lorenz, M. y j . Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994.
[PAR96] Park, R. E., W. B. Goet hert y W. A. Florac, Goal Driven Software MeasurementA Guide-
book, CMU/SE1-96-BH-002, Sof t war e Engi neeri ng Institute, Carnegi e Mellon University,
agos t o de 1996.
[PAU94] Paulish, D. y A. Carl et on, "Case St udi es of Sof t war e Process Improvement Measure-
ment ", en Computer, vol. 27, nm. 9, sept i embr e de 1994, pp. 50-57.
[QSM02] "QSM Funct i on Point Language Geari ng Factors", Versin 2.0, Quant i t at i ve Sof t war e
Management , 2002, ht t p: / / www. qs m. com/ FPGear i ng. ht ml .
IRAG95] Ragland, B "Measure, Metric or Indicator: What ' s t he Difference?", en Crosstalk, vol. 8,
nm. 3, ma r z o de 1995, pp. 29-30.
|SMI99] Smith, J., "The Est i mat i on of Effort Based on Use-Cases", un art cul o de Rational Corpo-
rat i on, 1999, se puede des car gar de ht t p: / / www. r a t i ona l . com/ pr oduct s / r up/ whi t epa -
pers. jsp.
2 2 . 1 . Describir con pal abras propi as la di ferenci a ent r e mt r i cas del pr oceso y del proyect o.
22.2. Por qu al gunas mt r i cas de s of t war e deben conser var se "privadas"? Ofrecer ej empl os
de t res mt r i cas que deban ser pr i vadas Ofrecer ei empl os de t res mt r i cas que deban ser pbli-
cas.
22.3. Qu es una medi da indirecta y por que t al es medi das s on c omune s en el t r abaj o de m-
tricas del sof t war e?
22.4. Grady sugi ere un conj unt o de regl as de et i quet a r a r a l as mt r i cas de sof t war e. El lector
puede agr egar t res regl as m s a l as me nc i or a - 35 e - 2 seccin 22.1.1?
TM
PDF Editor
22. 5 El equi po A encont r 342 errores dur ant e el pr oceso de ingeniera del sof t war e previ o a
la liberacin. El equi po B encont r 184 errores. Qu medi das adi ci onal es t endr an que realizar
los proyect os A y B par a det ermi nar cul de los equi pos elimin los errores de maner a ms efi-
ciente? Qu mt ri cas podr an pr oponer se par a ayudar a realizar la det ermi naci n? Qu dat os
histricos pueden ser tiles?
22.6. Present ar un ar gument o cont ra las lneas de cdi go como medi da par a la productividad
de soft ware. El cas o se sost i ene cuando se consi deran docenas o ci ent os de proyect os?
22.7. Calcular el valor de punt o de funci n par a un proyect o con las si gui ent es caractersticas
de domi ni o de i nformaci n:
Nmer o de ent r adas ext ernas: 32
Nmer o de sal i das ext emas: 60
Nmer o de consul t as ext ernas: 24
Nmer o de archi vos lgicos i nt ernos: 8
Nmer o de archi vos de i nt erfaz ext ernos: 2
Suponer que t odos l os val ores de aj ust e de compl ej i dad son promedi os. Utilizar el algoritmc
anot ado en el capitulo 15.
22.8 . Empl ear la tabla pr esent ada en la secci n 22. 2. 3 para el aborar un ar gument o contra la
utilizacin del l enguaj e ensambl ador basado en la funci onal i dad ent r egada por enunci ado de
cdigo. Vase de nuevo la tabla y coment ar por qu C++ present ar a una mej or alternativa que C
22.9. El sof t war e utilizado para cont rol ar una fot ocopi adora requi ere 32 000 LDC de C y 4 20:
lneas de Smalltalk. Estimar el nmer o de punt os de funci n para el sof t war e dent ro de la co- I
pi adora.
22.10. Un equi po de ingeniera Web ha const rui do una WebApp de comerci o electrnico que
cont i ene 145 pgi nas individuales. De est as pgi nas 65 son di nmi cas: est o es, se gener an i r
maner a i nt erna con bas e en la ent r ada del usuari o final. Cul es el ndice de personal i zaci n
para est a apl i caci n?
2 2 . 1 1 . Una WebApp y su ent or no de soport e no han sido compl et ament e reforzados contra
at aques. Los i ngeni eros Web est i man que la probabilidad de repel er un at aque slo es del 30 por
ciento. El si st ema no cont i ene i nformaci n sensi bl e o controversial, as que la probabilidad de
a mena za es de 25 por ci ent o. Cul es la integridad de la WebApp?
2 2 . 1 2 . En la concl usi n de un proyect o que utiliz el Proceso Unificado (Captulo 3) se dete-
mi n que 30 errores se encont r ar on dur ant e la fase de el aboraci n, y 12 errores hal l ados dui
t e la fase de const rucci n pod an segui rse hast a errores que no fueron descubi ert os en la f
de el aboraci n. Cul es la EED par a est as dos fases?
22.13. Un equi po de sof t war e ent rega un i ncr ement o de sof t war e a los usuar i os finales,
descubren ocho def ect os dur ant e el pri mer mes de uso. Ant es de la ent rega, el equi po de :
war e encont r 242 errores dur ant e las revi si ones t cni cas formal es y t odas las t ar eas de pr
ba. Cul es la EED global par a el proyect o?
La mej or a del proceso de soft ware (MPS) ha recibido una cant i dad significativa de atencin i
rant e las dos dcadas pasadas. Dado que la medi ci n y las mt ri cas de sof t war e son clave |
mej orar exi t osament e el pr oceso de soft ware, muchos libros acerca de la MPS t ambi n tratan
mtricas. Las f uent es valiosas de i nformaci n acerca de las mt ri cas de procesos incluyen:
Burr, A. y M. Owen, Statistical Methods for Software Quaity, Int ernat i onal Thomson Pub
hing, 1996.
El Emam, K. y N. Madhavj i (eds.), Elements of Software Process AssessmenC and Impr
IEEE Comput er Society, 1999.
TM
PDF Editor
CAPTULO 22 MTRI CAS DE PROCESO Y PROYECTO 68 9
Florac, W. A. y A. D. Carleton, Measuring the Software Process: Statistical Process Control for
Software Process lmprovemenl, Addison-Wesley, 1999.
Garmus, D. y D. Herrn, Measuring the Software Process: A Practcal Cuide to Functional Mea-
surements, Prentice-Hall, 1996.
Humphrey, W Introduction to the Team Software Process, Addi son-Wesl ey/ Longman, 2000.
Kan, S. H., Metrics and Models in Software Quality Engineering, Addison-Wesley, 1995.
McGarry y sus col egas (Practica! Software Measurement, Addison-Wesley, 2001) present an con-
sej os a profundi dad para valorar el proceso de soft ware. Haug y sus col egas (Software Process
Improvement: Metrics, Measurement, and Process Modeling, Springer-Verlag, 2001) han editado
una coleccin de artculos valiosos. Florac y Carlton (Measuring the Software Process, Addison-
Wesley, 1999) y Fenton y Pfleeger (Software Metrics: A Rigorous and Practical Approach, revisado,
Brooks/ Col e Publishers, 1998) tratan cmo se pueden empl ear las mt ri cas de soft ware par a
proporci onar los indicadores necesari os para mej orar el proceso de soft ware.
Put nam y Myers (Five Core Metrics, Dorset House, 2003) estudian una base de dat os de ms
de 6 000 proyect os de soft ware par a demost rar cmo ci nco mt ri cas cent ral es tiempo, esfuer-
zo, t amao, confiabilidad y productividad de proceso se pueden empl ear par a controlar los
proyect os de soft ware. Maxwell (Applied Statistics for Software Managers, Prentice-Hall, 2003)
present a t cni cas par a anal i zar dat os del proyecto de soft ware. Munson (Software Engineering
Measurement, Auerbach, 2003) est udi a un amplio abani co de t emas de medicin de ingeniera
del soft ware. Jones (Software Assessments, Benchmarks and Best Pracces, Addison-Wesley,
2000) describe t ant o medi das cuant i t at i vas como fact ores cualitativos que ayudan a una orga-
nizacin a valorar sus procesos y prcticas de soft ware. Garmus y Herrn (Function PointAnaly-
sis: Measurement Practices for Successful Software Projects, Addison-Wesley, 2000) exami nan las
mt ri cas de proceso con nfasi s en el anlisis de los punt os de funci n.
Lorenze y Kidd [LOR94] y DeChampeax (Object-Oriented Development Process and Metrics,
Prentice-Hall, 1996) consi deran el proceso OO y describen un conj unt o de mt ri cas para valo-
rarlo. Whitmire (Object-Oriented Design Measurement, Wiley, 1997) y Henderson-Sel i ers (Object-
Oriented Metrics: Measures of Complexity, Prentice-Hall, 1995) se enf ocan en las mt ri cas tcni-
cas para el t rabaj o OO, pero t ambi n consi deran medi das y mt ri cas que se pueden aplicar en
el mbi t o del proceso y del producto.
Se ha publ i cado rel at i vament e poco acerca de las mt ri cas para el t rabaj o de ingeniera Web.
Sin embargo, Stern (Web Metrics: Proven Methods for Measuring Web Site Success, Wiley, 2002),
Inan y Kean (Measuring the Success ofYour Website, Longman, 2002) y Nobles y Grady (Web Site
Analysis and Reporting, Premier Press, 2001) abordan las mt ri cas Web desde una perspectiva de
negoci os y de market i ng.
Lo m s reciente en la investigacin en el rea de mtricas lo resume el IEEE (Symposium on
Software Metrics, publ i cado anual ment e). En Internet est disponible una amplia vari edad de
fuent es de informacin acerca de las mtricas de proceso y proyecto. Una lista actualizada de re-
ferencias en la World Wide Web se encuent ra en el sitio Web SEPA:
TM
PDF Editor
C A P I T U L O
23
ESTIMACIN PARA
PROYECTOS DE SOFTWARE
C O N C E P T O S
CLAVE
mbito 693
complejidad . . . 70 3
estimacin
basada
en LDC . . . . 7 0 0
basada en PF 702
basada
en procesos 704
casos de uso . 705
conceptos. . . 698
reconciliacin 7 0 8
factibilidad . . . . 693
planificacin de
proyecto 6 9 2
recursos 694
t a
del s of t war e . . 698
L
a gest i n del proyect o de sof t war e comi enza con un conj unt o de activida-
des que en grupo se denomi nan planificacin del proyecto. Antes de que el
proyect o comi ence el gest or del proyecto y el equi po de sof t war e deben e;
timar el t rabaj o que habr de realizarse, los recursos que se requeri rn y el tiempc
que transcurrir desde el principio hast a el final. Una vez que se compl et en est a;
actividades, el equi po de soft ware debe est abl ecer un plan del proyect o que de
fina las t ar eas y fechas clave de la ingeniera del soft ware, que identifique quic-
es responsabl e de dirigir cada tarea y especi fi que l as dependenci as ent r e t area;
que pueden ser det er mi nant es en el progreso.
En una excelente gua para "sobrevivir el proyecto de software", Steve McConneE
[MCC98] presenta una visin del mundo real de la planificacin del proyecto:
Muchos t r abaj ador es t cni cos preferi rn real i zar el t r abaj o t cni co en l ugar de pa-
sar el t i empo en la pl ani fi caci n. Muchos gest ores t cni cos no t i enen sufi ci ent e en-
t r enami ent o en la gestin tcnica para sent i rse s egur os de que su planificacin
mej or ar el r esul t ado de un proyecto. Puest o que ni nguna part e qui ere hacer la pla-
nificacin, con frecuencia no se real i za.
Pero las fallas par a pl ani fi car es uno de l os mayor es er r or es que un proyect o pueda
comet er . . . se necesi t a la planificacin efi caz para resol ver los pr obl emas corri ent e
arri ba [ t empr ano en ei proyecto] a baj o cost o, m s que corri ent e abaj o [tarde en el
proyect ol a alto cost o. El proyect o pr omedi o gast a 80 por ciento de su t i empo en ree-
l aboraci n: corri gi endo er r or es que se comet i er on en et apas t empr anas del proyecto.
Qu e s ? Se ha establecido una
necesidad real para el software; los
participantes estn a bordo; los inge-
nieros de software estn listos para
comenzar; y el proyecto est a punto
de arrancar. Pero, cmo se proceder? La pla-
nificacin del proyecto de software abarca cinco
grandes actividades: estimacin, programa de
trabajo, anlisis de riesgos, planificacin de la
gestin de la calidad y planificacin de la ges-
tin del cambio. En el contexto de este captulo
slo se considera la estimacin: su intento por
determinar cunto dinero, esfuerzo, recursos y
tiempo tomar construir un sistema o producto
especfico basado en software.
Qui n l o ha c e ? Los gestores de proyecto del
software, con base en la informacin solicitada
de los participantes e ingenieros de software y
los datos de las mtricas de software recopilados
en proyectos previos.
Po r q u e s i mp o r t a n t e ? Se construira una
casa sin saber cunto dinero est a punto de
gastarse, las tareas que se deben realizar y el
tiempo para que ei trabajo se haga? Desde
luego que no, y puesto que la mayora de los siste-
mas y productos basados en computadora son con-
siderablemente ms caros que construir una gran
casa, parecera razonable desarrollar una
estimacin antes de comenzar a crear el software.
Cu l e s s on l os p a s o s ? La estimacin comien-
za con una descripcin del mbito del producto.
Entonces el problema se descompone en un con-
junto de problemas ms pequeos, y cada uno
de stos se estima empleando datos histricos y
TM
PDF Editor
CAPTULO 23 ESTI MACI N PARA PROYECTOS DE SOFTWARE
691
r perienetet como guas. La complejidad y el
esgo del problema se consideran antes de rea-
izar una estimacin final,
el e s el product o obt eni do? Se genero
.na simple tabla en la que se delinean las fa-
ros que deben realizarse, las funciones que
- :brn de implementarse y el costo, esfuerzo y
:impo involucrados para cada uno.
r.o pue do es t ar s e gur o d e que l o he
hecho correct ament e? Eso es difcil, porque
en reclidad no se sabr sino hasta que el pro-
yecto se haya completado. Sin embargo, si se
tiene experiencia y se sigue un enfoque sistem
tico, se generan estimaciones empleando datos
histricos slidos, se crean puntos de datos de
estimacin mediante al menos dos mtodos dife-
rentes, se establece un calendario realista y con-
tinuamente se adapta conforme el proyecto
avanza, se puede estar segur de que se est
haciendo lo mejor.
McConell ar gument a que cualquier proyect o puede encont r ar el t i empo para pla-
nificar (y adapt ar el plan a lo largo del proyecto) si mpl ement e t omando un pequeo
por cent aj e del t i empo que se habra gast ado en la reel aboraci n que ocurre debi do
a que no se planific.
2 3 . 1 OBS ERVACI ONES ACERCA DE LA ES TI MACI N
La planificacin requiere que los gest ores t cni cos y los mi embros del equi po de
sof t war e est abl ezcan un compromi so inicial, aun cuando sea probable que est e
"compromi so" pruebe est ar equi vocado. Si empre que se realizan est i maci ones se
atisba al fut uro y se acept a aut omt i cament e algn grado de incertidumbre. Para
citar a Frederick Brooks (BR075]:
[NJuestras t cni cas de est i maci n est n pobr ement e desarrolladas. Ms seri ament e, re-
flejan una suposi ci n no expresada que es bast ant e incierta, es decir: que t odo ir bien...
Puest o que no es t amos seguros de nuest r as est i maci ones, con frecuenci a los gest ores de
soft ware carecen de la cort s t est arudez para hacer que la gent e espere un buen product o.
Aunque la est i maci n es t ant o un art e como una ciencia, esta i mport ant e actividad
no necesita realizarse en una forma improvisada. Existen t cni cas tiles para la esti-
maci n de t i empo y esfuerzo. Las mt ri cas del proceso y del proyect o ofrecen la
perspectiva histrica y la energ a para la generaci n de est i maci ones cuant i t at i vas.
La experiencia (de toda la gent e involucrada) puede auxiliar enor mement e conf or me
se desarrollan y revisan las est i maci ones. Puesto que la est i maci n coloca los
ci mi ent os para las dems actividades de planificacin del proyecto, y sta propor-
ci ona la ruta para la ingeniera del sof t war e exitosa, se estara mal aconsej ado si se
embar car a sin ella.
" l os buenos enf oques de estimacin y los dol os histricos s i dos of r ecen io mej or esper anza de que en realidad se
t ri unfar sobre demandas imposibles."
Capers i ones
TM
PDF Editor
La est i maci n de recursos, cost o y pr ogr ama de t r abaj o par a una t area de inge-
niera de s of t war e requi ere experi enci a, acces o a buena i nf or maci n histrica
(mtricas) y el valor par a compr omet er s e con predi cci ones cuant i t at i vas cuando la
i nf or maci n cualitativa es t odo lo que existe. La est i maci n implica ri esgo i nheren-
te, 1 y st e conduce a la i ncert i dumbre.
La disponibilidad de i nformaci n histrica t i ene una fuert e influencia en el riesgo
de la est i maci n. Al mi rar en ret rospect i va, se pueden emul ar las cos as que funci o-
naron y mej or ar l as r eas donde surgi eron pr obl emas. Cuando hay di sponi bl es
ampl i as mt r i cas de s of t war e (captulo 22) de proyect os previ os, l as est i maci ones se
hacen con mayor seguri dad, los pr ogr amas de t r abaj o se pueden est abl ecer par a evi-
t ar di fi cul t ades pa s a da s y el ri esgo global se reduce.
" t a caracterstica de una ment e instruida es descansar sat i sfecha con el gr ado de precisin que la nat ur al eza del
asunt a admi t e, y no buscar la exactitud cuando slo es posible una aproxi maci n de la ver dad. "
Ar i st t el es
El ri esgo de la est i maci n se mi de por el gr ado de i ncert i dumbre en l as est i ma-
ci ones cuant i t at i vas est abl eci das par a recursos, cost os y pr ogr ama de t rabaj o. Si el
mbi t o del pr oyect o se compr ende en forma defi ci ent e o los requi si t os del pr oyect :
est n suj et os a event ual es cambi os, la i ncer t i dumbr e y el ri esgo de la est i maci n se
i ncr ement an pel i gr osament e. El pl ani fi cador y, en f or ma m s i mport ant e, el cliente
deben r econocer que la variabilidad en l os requi si t os del s of t war e significa inestabi-
lidad en cost o y pr ogr ama de t rabaj o.
Sin embar go, un gest or de proyect o no debe obs es i onar s e con las est i maci ones.
Los moder nos enf oques de i ngeni er a del s of t war e (por ej empl o, model os de proce-
s o i ncrement al ) a s umen una visin iterativa del desarrol l o. En t al es enf oques es
posible, aunque no si empr e acept abl e pol t i cament e, r eexami nar las est i maci ones
(cuando se conozca m s i nformaci n) y modi fi carl as cuando el cliente cambi a los
requisitos.
2 3 . 2 EL P ROCE S O DE P L ANI F I C AC I N DEL P ROYECTO
El obj et i vo de la pl ani fi caci n del proyect o de s of t war e es pr opor ci onar un mar co de
t r abaj o que per mi t a al gest or est i mar r azonabl ement e r ecur sos, cos t o y pr ogr ama
de t rabaj o. Adems, las est i maci ones deben i nt ent ar definir los escenar i os de mej or y
peor cas o de modo que l os r esul t ados del proyect o se puedan acot ar. Aunque exi st
un gr ado i nher ent e de i ncert i dumbre, el equi po de s of t war e se embar ca en un piar
est abl eci do como consecuenci a de las t areas de planificacin. Por lo t ant o, el plan se
debe adapt ar y act ual i zar conf or me avance el proyect o. En l as secci ones siguientes
se est udi ar cada una de las act i vi dades as oci adas con la planificacin del proyec;
de sof t war e.
^ O N S E J O ^ .
Mientras ms
conozco, mejor
estimar. En
consecuencia,
actualice sus
estimaciones
conforme avance el
pioyecto.
1 En el captulo 25 se presentan tcnicas sistemticas para el anlisis del riesgo.
TM
PDF Editor
CAPTULO 23 ESTI MACI N PARA PROYECTOS DE SOFTWARE 693
CONJ UNTO DE TAREAS
Conjunto de tareas para la planificacin del proyecto
1. Establecer el mbito del proyecto.
2. Determinar la factibilidad.
3. Analizar los riesgos (captulo 25).
Definir los recursos requeridos.
a. Determinar los recursos humanos requeridos.
b. Definir los recursos de software reutilizables.
c. Identificar los recursos del entorno.
Estimar costo y esfuerzo.
a. Descomponer el problema.
b. Desarrollar dos o ms estimaciones empleando
tamao, puntos de funcin, tareas de proceso o
casos de uso.
c. Reconciliar las estimaciones.
6. Desarrollar un plan del proyecto (captulo 24).
a. Establecer un conjunto de tareas significativo.
b. Definir una red de tareas.
c. Usar herramientas de planificacin para
desarrollar un cronograma.
d. Definir mecanismos de seguimiento del
programa de trabajo.
2 3 . 3
I RA DEL S OF TWARE V F ACTI BI LI DAD
CLAVE
d i s t e n
i z o n e s para
i i ncompl et o
> requisitos
El mbito del software descri be l as f unci ones y caract er st i cas que se ent r egar n a los
usuar i os finales, los dat os que son ent r ada y salida, el "cont eni do" que se pr esent a a
los usuar i os como consecuenci a de empl ear el sof t war e, as como el des empeo, las
rest ri cci ones, las i nt erfases y la confiabilidad que acotan el si st ema. El mbi t o se defi-
ne al usar una de l as dos t cni cas si gui ent es:
1. Despus de una comuni caci n con t odos los part i ci pant es se desarrol l a una
descri pci n narrat i va del mbi t o del soft ware.
2. Los usuar i os finales desarrol l an un conj unt o de cas os de uso. 2
Las f unci ones descri t as en el enunci ado del mbi t o (o dent r o de los cas os de uso) se
eval an y en al gunos cas os se refi nan para pr opor ci onar m s det al l es ant es de
comenzar la est i maci n. Puest o que las est i maci ones de cost o y pr ogr ama de t rabaj o
est n f unci onal ment e ori ent adas, con frecuenci a es til ci ert o gr ado de des compo-
sicin. Las consi der aci ones del des empeo abar can los requi si t os de pr oces ami ent o
y t i empo de r espuest a. Las rest ri cci ones identifican los l mi t es col ocados en el soft -
war e por el har dwar e ext erno, la memor i a di sponi bl e u ot r os si st emas exi st ent es.
Una vez i dent i fi cado el mbi t o (con la part i ci paci n del cliente) es r azonabl e pre-
gunt ar: es posi bl e const rui r s of t war e par a sat i sfacer es t e mbi t o? El pr oyect o e s
factible? Con mucha frecuenci a los i ngeni eros de s of t war e sosl ayan es t as pr egunt as
(o gest or es o cl i ent es i mpaci ent es los pr esi onan para hacerl o), sl o para ver se enr e-
dados en un proyect o condena do al fracaso. Put nam y Myers [PUT97a] abor dan es t e
confl i ct o cuando escri ben:
2 Los casos de uso se discutieron con detalle en las partes 2 y 3 de este libro. Un caso de uso es una
descripcin basada en escenario de la interaccin del usuario con el software, desde el punto de
vista del usuario.
TM
PDF Editor
^ ONS EJ O^
La foctibilidad del
proyecto es impor-
tante, pero uno consi-
deracin de los
necesidades del
negocio es incluso
ms importante. No
es bueno construir un
sistema o producto de
alto tecnologa q ue
nadie q uiere.
| N]o t odo lo i magi nabl e e s factible, i ncl uso ni en s of t war e, t an e va ne s c e nt e c o mo pue de
par ecer a l os ext r aos . Por el cont r ar i o, la fact i bi l i dad del s of t wa r e t i ene c ua t r o di mens i o-
ne s sl i das: Tecnologa: el pr oyect o e s t c ni c a me nt e fact i bl e? Est dent r o del t e r r e no de
la di sci pl i na? Los def ect os se pue de n reduci r a tal gr a do q u e s e e mpa r e j e n con l as nece-
s i da des de la apl i caci n? Finanzas: es f i na nci er a ment e fact i bl e? Se pue de compl et ar el
des ar r ol l o a un cos t o que la or gani zaci n de s of t war e, su cl i ent e o el me r c a do pue da n en-
f r ent ar ? Tiempo: el pr oyect o l l egar al me r c a do a nt e s y vencer a la compet enci a ? Re-
cursos: la or gani zaci n t i ene l os r ecur s os neces ar i os par a t r i unf ar ?
Put nam y Myers sugieren, acer t adament e, que el mbi t o no es suficiente. Una vez
que el mbi t o se comprende, el equi po de soft ware y ot ros deben t rabaj ar para deter-
mi nar si se puede hacer dent ro de las di mensi ones anot adas lneas arriba. sta es
una part e crucial, aunque con frecuenci a ignorada, del pr oceso de est i maci n.
Herramientas
i de software.
Nmer o
[Habilidade: Har dwar e
Personal
Entorno
Recursos
de red
Ubicacin
Proyecto
Software
reutilizqble
Component es
OTS
Nuevos
component es
Componentes d1
experi enci a
parcial /
Componentes de
experi enci a
. completa S
23. 4
Recursos del
proyecto.
RECURSOS
La segunda tarea de la planificacin es la est i maci n de los recursos necesari os para
compl et ar el esfuerzo de desarrollo del soft ware. La figura 23.1 muest ra las tres
gr andes cat egor as de los recursos de ingeniera del soft ware: personal , componer
tes de sof t war e reutilizables y el ent or no de desarrollo (hardware y herrami ent as de
soft ware). Cada recurso se especifica con cuat ro caractersticas: descripcin de
recurso; un i nforme de disponibilidad; cundo se requerir el recurso; t i empo durar -
te el cual el recurso se aplicar. Las ltimas dos caract er st i cas se pueden ver coi r o
TM
PDF Editor
CAPTULO 23 ESTI MACI N PARA PROYECTOS DE SOFTWARE
695
i olvide q ue
r varios compo-
! de reutilizacin
! ser un reto
nte. El
7 de lo inte-
i con frecuencia
iconfrmese
i varios
zryonentes.
una ventana de tiempo. La disponibilidad del recurso para una vent ana especfica
debe est abl ecerse lo ms pront o posible.
23.4.1 Recursos humanos
El planificador comi enza eval uando el mbi t o del sof t war e y sel ecci onando las habi-
lidades requeri das para compl et ar el desarrollo. Se especifican t ant o la posicin
organi zaci onal (por ej empl o, gestor, ingeniero de sof t war e ejecutivo) como la espe-
cialidad (por ejemplo, t el ecomuni caci ones, base de dat os, cl i ent e/ servi dor). En pro-
yect os rel at i vament e pequeos (unos pocos persona- meses) un sol o individuo puede
realizar t odas las t ar eas de ingeniera del sof t war e y consul t ar con especi al i st as con-
forme se requiera. En proyect os mayores el equi po de sof t war e puede est ar geogr-
ficamente di sperso en varios sitios. Aqu se especifica la ubicacin de cada recurso
humano.
El nmer o de per sonas que requi ere un proyect o de sof t war e sl o se det ermi na
des pus de que se ha hecho una est i maci n del esf uer zo de desarrol l o (por ej empl o,
personas-mes). Las t cni cas para est i mar el esf uer zo se t rat arn m s adel ant e en
est e captulo.
23.4.2 Recursos de software reutilizables
La ingeniera del sof t war e basada en component es (captulo 30) enfat i za la reutili-
zaci n; es decir, la creaci n y reutilizacin de bl oques de const rucci n de sof t war e
[H0091]. Tales bloques, usual ment e l l amados componentes, deben catalogarse para
consul t arl os con facilidad, est andar i zar se para facilitar su aplicacin y val i darse
para integrarlos fcilmente.
Bennat an [BEN92] sugiere cuat r o cat egor as de recursos de sof t war e que deben
consi derarse conf or me avanza la planificacin:
Componentes ya desarrollados. El soft ware exi st ent e se puede adquirir de un ter-
cero o se desarrol l i nt er nament e para un proyecto previo. Los CCYD (componen-
tes comerciales ya desarrollados) se compran de un tercero, est n listos para empl ear-
los en el proyect o act ual y han si do ampl i ament e validados.
Componentes experimentados. Especificaciones, diseos, cdi go o dat os de prue-
ba existentes que se desarrollaron para proyectos previos son similares al soft ware que
se const rui r para el proyect o actual. Los mi embr os del equi po de sof t war e actual ya
t i enen experiencia en el r ea de aplicacin que represent an di chos component es. En
consecuenci a, las modi fi caci ones que requi eran los component es exper i ment ados
sern rel at i vament e de baj o riesgo.
Componentes de experiencia parcial. Especificaciones, diseos, cdi go o dat os de
prueba exi st ent es que se desarrol l aron para proyect os previos est n rel aci onados
con el sof t war e que se const rui r para el proyect o act ual per o requerirn modi fi ca-
ci ones sust anci al es. Los mi embros del equi po de sof t war e act ual sl o tienen expe-
riencia limitada en el r ea de aplicacin que represent an di chos component es. Por
TM
PDF Editor
lo t ant o, las modi fi caci ones que requi eren los component es de experi encia p a r a ; i
tienen un gr ado consi derabl e de riesgo.
Componentes nuevos. El equi po de sof t war e debe construir los component es c; J
sof t war e espec fi cament e para las necesi dades del proyect o actual.
Irnicamente, con frecuenci a los component es de sof t war e reutilizables son despre-
ci ados durant e la planificacin, slo para convertirse en una preocupaci n i mpc:
tante dur ant e la fase de desarrol l o del proceso de soft ware. Es mej or especifica."!
cuant o ant es los requisitos de recursos de soft ware. De esta forma se puede llevar a I
cabo la evaluacin tcnica de las alternativas y puede ocurrir la adquisicin oportuna '
23.4.3 Recursos del entorno
El ent or no que soport a un proyecto de soft ware, con frecuencia denomi nado e/ i t o/ roj
de ingeniera del software (E1S), i ncorpora har dwar e y soft ware. El har dwar e propor-
ci ona una pl at aforma que soport a las her r ami ent as (software) con que se prodce-
los product os de t rabaj o basados en una buena prctica de la ingeniera del softwa-
re.3 Puest o que la mayor part e de las organi zaci ones de sof t war e tienen mltiple;, i
const i t uyent es que requi eren acces o al EIS, el planificador de proyect o debe prescr -
bir la vent ana de t i empo requerida por el har dwar e y el soft ware, y verificar que es:os;
recursos est ar n disponibles.
Cuando un si st ema bas ado en comput ador a (que incorpora har dwar e y soft wa-r
especializados) se somet er a ingeniera, el equi po de sof t war e qui z requiera acce-
s o a el ement os de har dwar e que est n desarrol l ando ot ros equi pos de ingeniera
Por ejemplo, el sof t war e de un cont ador numri co (CN) utilizado en un tipo ce
mqui nas- herrami ent a tal vez requiera una mqui na- her r ami ent a especfica (per]
ejemplo, un CN de torno) como parte del pas o de prueba de validacin; un pr oyecr i
de sof t war e para plantilla de pgi na avanzada quiz necesi t e una i mpresora de at i aj
calidad en al gn punt o dur ant e el desarrollo. El planificador del proyect o de softwa-
re debe especificar cada el ement o de hardware.
2 3 . 5 E S T I MACI N DE PROYECTOS DE SOFTWARE
El sof t war e es el el ement o ms caro de vi rt ual ment e t odos los si st emas basados en
comput ador a. En si st emas complejos, personal i zados, un gran error en la estima
cin del cost o puede hacer la diferencia ent re beneficio y prdi da. Rebasar el eos: :
puede ser desast roso para el desarrollador.
"En unn ero de subcontrotacin y competencia creciente, lo habilidad par a estimar con mayor pr eci si n. . . ha surgido
como un factor de xito crucial par o muchos grupos de TI."
Rob Thofflsett
3 Otro hardware el entorno objetivo es la computadora en la que el software se ejecutar cuar; >
haya sido liberado al usuario final.
TM
PDF Editor
CAPTULO 23 ESTI MACI N P ARA PROYECTOS DE SOFTWARE 6 9 7
La est i maci n del cost o y el esf uer zo nunca ser una ciencia exacta. 4 Demasi adas
variables humanas, tcnicas, ambi ent al es, polticas pueden afect ar el cost o final
del sof t war e y el esf uer zo apl i cado a desarrollarlo. Sin embargo, la estimacin del
proyecto de software se puede transformar de una prctica oscura en una serie de
pasos si st emt i cos que proporci onan est i maci ones con riesgo acept abl e. Para lograr
est i maci ones confi abl es de cost o y esf uer zo se tienen vari as opci ones:
1. Demorar la est i maci n hast a ms t arde en el proyect o (obviamente, se puede
lograr 100 por ci ent o de est i maci ones preci sas despus de que el proyect o
est t ermi nado!)
2. Basar las est i maci ones en proyect os similares que ya hayan sido compl et ados.
3. Emplear t cni cas de descomposi ci n rel at i vament e simples para generar esti-
maci ones de cost o y esf uer zo del proyecto.
4. Utilizar uno o ms model os emp ri cos en la est i maci n de cost o y esfuerzo.
Desgraci adament e, la pri mera opcin, aunque atractiva, no es prctica. Las est i ma-
ci ones de cost os se tienen que proporci onar "por adel ant ado". No obst ant e, se debe
reconocer que, mi ent ras m s se espere ms se conocer, y mi ent ras ms se conoz-
ca menos probable es que se comet an seri os errores en las est i maci ones.
La segunda opcin puede funci onar r azonabl ement e bien si el proyect o en curso
es muy similar a los previos y a ot r as influencias del proyect o (por ejemplo, el equi-
po de soft ware, el cliente, las condi ci ones del mercado, el EIS, las fechas limite) son
apr oxi madament e equivalentes. Por desgracia, la experiencia no si empre ha sido un
buen indicador de los resul t ados futuros.
Las opci ones rest ant es son enf oques viables para la est i maci n del proyect o de
soft ware. Idealmente, las t cni cas menci onadas para cada opcin deben aplicarse
j unt as, cada una empl eada como una mar ca de verificacin para la otra. Las tcni-
cas de descomposi ci n as umen un enf oque de "divide y vencers" respect o de la
est i maci n del proyect o de soft ware. Al descomponer un proyect o en funci ones prin-
cipales y actividades de ingeniera del sof t war e rel aci onadas, las est i maci ones de
cost o y esf uer zo se pueden realizar en forma escal onada. Los model os de est i ma-
cin emprica son tiles par a compl ement ar las t cni cas de descomposi ci n y ofre-
cer un enf oque de est i maci n pot enci al ment e valioso por su propio derecho. Estos
model os se est udi an en la secci n 23.7.
Cada una de las opci ones viables de est i maci n de costo del sof t war e ser tan
buena como lo sean los dat os histricos en que se basa la estimacin. Si no existen
dat os histricos, la est i maci n del cost o se bas ar en un f undament o muy t amba-
l eant e. En el captulo 22 se exami nan las caract er st i cas de al gunas de las mt ri cas
de sof t war e que proporci onan la bas e para los dat os histricos de estimacin.
4 Bennatan [BEN03] reporta que 40 por ciento de los desarrolladores de software continan luchando
con las estimaciones y que el t amao del software y el t empo de desarrollo son muy dificiles de es-
timar con precisin.
TM
PDF Editor
6 9 8 PARTE CUATRO GESTI N DE PROYECTOS DE SOFTWARE
CLAVE
El "tamao" del
software que se
construir puede
estimorse empleando
uno medido directo,
LDC, o uno indirecta,
PE.
Cmo s e
mide el
t amao del
s of t war e que s e
planea const rui r?
La est i maci n del proyect o de sof t war e es una forma de resolver probl emas; en la
mayor a de los casos, el probl ema que debe resolverse (es decir, el desarrol l o de una
est i maci n de cost o y esf uer zo para un proyecto de soft ware) es muy compl ej o comc
para considerarlo una sola pieza. Por est a razn se descompone el probl ema, reca-
ract eri zndol o como un conj unt o de probl emas m s pequeos (y, esperanzadora-
ment e, ms manej abl e).
En el captulo 21 se exami n el enfoque de descomposi ci n desde dos diferente;
punt os de vista: descomposi ci n del probl ema y descomposi ci n del proceso. L
est i maci n empl ea una o ambas formas de particin. Pero ant es de que pueda rea-
lizarse una est i maci n, el planificador del proyect o debe ent ender el mbi t o del soft-
war e que se construir y generar una est i maci n de su "t amao".
23.6.1 Tamao del software
La precisin de la est i maci n de un proyect o de soft ware se mani fi est a en varios fac-
tores: 1) el grado con el cual el planificador ha est i mado adecuadament e el t amaf . :
del product o que se const rui r; 2) la habilidad para traducir la est i maci n del tama-
o en esfuerzo humano, programa de t rabaj o y di nero (una funcin de la disponibi-
lidad de las mt ri cas de sof t war e confi abl es a partir de proyect os previos); 3) el gr ac:
en el cual el plan del proyect o refleja las habilidades del equi po de soft ware; y 4) .a
estabilidad de los requisitos del product o y el ent or no que soport a el esfuerzo de
ingeniera del soft ware.
En esta secci n se consi dera el probl ema del tama o del software. Puest o que
est i maci n de un proyect o slo es t an buena como la est i maci n del t amao del
baj o para realizarlo, el t amao represent a el pri mer gran desafi o del planificador
proyecto. En el cont ext o de la planificacin del proyecto, tama o se refiere a
resul t ado cuantificable del proyect o de soft ware. Si se as ume un enfoque directo,
t amao se puede medir en lneas de cdi go (LDC). Si se elige un enf oque indir
el t amao se represent a como punt os de funcin (PF).
Put nam y Myers [PUT92] sugi eren cuat ro di ferent es enf oques al probl ema
t amao:
Tama o de "lgica dijusa". La aplicacin de est e enf oque requi ere que el pi ar:
ficador identifique el tipo de aplicacin, est abl ezca su magni t ud en una e
cualitativa y luego retine la magni t ud dent ro del rango original.
Tama o de punto de funcin. El planificador desarrolla est i maci ones de las
caract er st i cas del domi ni o de la i nformaci n t rat adas en el captulo 15.
Tama o de componentes estndar. El soft ware se compone de varios "cpmpc -
nent es est ndar", los cual es son di ferent es y genri cos de una rea particular
de la aplicacin. Por ejemplo, los component es est ndar de un si st ema de
informacin son subsi st emas, mdulos, pantallas, reportes, programas inter-
TM
PDF Editor
C A P T U L O 2 3 ESTIMACIN PARA PROYECTOS DE SOFTWARE
699
i Q u t i e n e n
e n c o m n l a s
e s
e n LDC y
f cONSEJ O^-
; r e c o p i l e
c a s d e p r o d u c t . t
t i p a r a p r o y e c t o s ,
i d e e s t o -
t u n a t a x o n o m a
. s t o l e
) c a l c u l a r
s e s p e c f i c o s
i d o m i n i o , l o q u e
r e a l i z a r e s t t
| l o c i o n e s m s
j R s a s .
activos, pr ogr amas por lotes, archivos, LDC e i nst rucci ones al nivel de objeto.
El planificado!" del proyecto est i ma el nmer o de ocurrenci as de cada compo-
nent e est ndar y luego aplica dat os de proyectos histricos para det ermi nar el
t amao de ent rega por component e est ndar.
Ta m a o d e l c a m bi o . Este enf oque se aplica cuando un proyect o incluye la utili-
zacin de sof t war e exi st ent e que debe modificarse en cierta forma como part e
de un proyecto. El planificador est i ma el nmer o y tipo (por ejemplo, reutiliza-
cin, cdigo de adicin, cdi go de cambi o, cdigo de borrado) de las modifi-
caci ones que se deben lograr.
Put nam y Myers sugieren que los resul t ados de cada uno de est os enf oques de t ama-
o se combi nen est ad st i cament e para crear una est i maci n de t r e s p u n t o s o del va l o r
e s p e r a d o . Esto se logra desarrol l ando valores opt i mi st as (bajos), ms probabl es y
pesi mi st as (altos) para el t amao y combi nndol os con la ecuaci n (23-1) descrita
en la siguiente seccin.
23.6.2 Estimacin bas ada en el problema
En el captulo 22, las lneas de cdigo y los punt os de funcin se describieron como
medi das a partir de las cual es se calculan las mt ri cas de productividad. Los dat os
de las LDC y los PF se utilizan en dos formas al est i mar el proyect o de soft ware: I)
como una variable de la est i maci n para el "t amao" de cada el ement o del soft wa-
re, y 2) como mt ri cas de lnea base recol ect adas a partir de proyect os previos y uti-
lizados en conj unci n con variables de est i maci n para desarrollar proyecciones de
cost o y esfuerzo.
Las est i maci ones de LDC y PF son distintas t cni cas de est i maci n, aunque ambas
tienen varias caractersticas en comn. El planificador del proyect o comi enza con un
enf oque acot ado del mbi t o del soft ware y a partir de ah intenta descomponer el
sof t war e en funci ones probl ema que puedan est i marse individualmente. Ent onces se
est i man las LDC o PF (las variables de estimacin) para cada funcin. De maner a
alternativa, el planificador puede elegir ot ro component e para t amao, como cl ases
u objetos, cambi os o procesos de negoci os afect ados.
Entonces se aplican las mt ri cas de la lnea base de productividad (por ejemplo,
LDC/pm o PF/pm5) a la variable de estimacin apropiada, y se deriva el costo o esfuer-
zo de la funcin. Las estimaciones de funcin se combi nan para producir una estima-
cin global del proyecto completo.
Sin embargo, es i mport ant e not ar que con frecuenci a existe una dispersin sus-
tancial en las mt ri cas de productividad de una organi zaci n, lo que hace sospe-
choso el uso de una sola mtrica de lnea base de productividad. En general, el dominio
del proyect o debe calcular los promedi os de LDC/pm o PF/ pm. Es decir, los proyec-
tos deben agruparse por t amao de equipo, rea de aplicacin, complejidad y ot ros
5 Las siglas p m significan persona-mes de esfuerzo
TM
PDF Editor
\
C L A V E
En las est i maci ones PF
la descomposicin se
enfoca sobre las
caractersticos del
dominio de
informacin.
7 Cr ao s e
c a l c u l a e l
" v a l o r e s p e r a d o "
p a r a e l t a m a o d e
s o f t w a r e ?
par met r os relevantes. Luego se t i enen que calcular los promedi os de domi ni o local.
Cuando se est i ma un nuevo proyect o pri mero debe ubi carse en un dominio, y luegc
aplicar el promedi o del domi ni o apropi ado para la productividad y as generar la esti-
macin.
Las t cni cas de est i maci n LDC y PF difieren en en cuant o al detalle requeridc
para descomposi ci n y el objetivo de la particin. Al empl ear LDC como variable de
est i maci n la descomposi ci n es absol ut ament e esencial y con frecuenci a se lleva
grados consi derabl es de detalle. Mientras mayor sea el gr ado de particin es ms
probable que se desarrolle una est i maci n r azonabl ement e precisa de LDC.
En las est i maci ones de PF la descomposi ci n funci ona de maner a diferente. Ms
que enf ocar se sobre la funcin, se est i ma cada una de las cinco caract er st i cas de
domi ni o de informacin, as como los 14 valores de aj ust e de complejidad estudia-
dos en el captulo 15. Ent onces se pueden utilizar las est i maci ones resul t ant es par
derivar un valor de PF que se pueda ligar a dat os previos y empl eados para generar
una est i maci n.
Sin i mport ar la variable de est i maci n que se utilice, el planificado!- del proyect;
comi enza est i mando una gama de val ores para cada funcin o valor de domi ni o de
i nformaci n. Al empl ear dat os histricos o (cuando t odo lo dems falla) intuicin, e:
planificador est i ma un valor de t amao optimista, m s probable, y pesi mi st a para
cada funcin o cuent a para cada valor de domi ni o de i nformaci n. Cuando se espe-
cifica un r ango de val ores se proporci ona un indicio implcito del grado de incerti-
dumbre.
Ent onces se puede calcular un valor de t res punt os o uno esperado. El va l o r e s p e
r a d o para la variable de est i maci n (tamao), S, se calcula como un promedi o pon-
der ado de las est i maci ones optimista (Sop,), ms probable (Sm) y pesimista (Spes). Po-
ejemplo,
S (S0p[ + 4Sm + SpesJ/6 (23-1)
brinda la credibilidad m s fuert e a la est i maci n "ms probabl e" y sigue una distri-
bucin de probabilidad bet a. Se s upone que existe una probabilidad muy pequea de
que el t amao real resul t ant e se ubi que fuera de los valores optimista y pesimista.
Una vez det er mi nado el valor esper ado para la variable de est i maci n se aplicar,
los dat os de productividad histrica de LDC o PF. Son correct as las estimaciones?
La ni ca respuest a razonabl e a esta pregunt a es: no se puede est ar seguro. Cualquier
tcnica de estimacin, no i mport a cun sofisticada sea, debe cont rast arse con otro
enfoque. Incluso ent onces deben preval ecer el sent i do comn y la experiencia.
23.6.3 Un ejemplo de estimacin basada en LDC
Como ej empl o de t cni cas de est i maci n de LDC y PF bas adas en el probl ema, con-
si drese un paquet e de soft ware que ser ent regado para una aplicacin de diseo
asistido por comput ador a (CAD, por s us siglas en ingls) dest i nado a component es
mecni cos. El sof t war e se ej ecut ar en una est aci n de t rabaj o de ingeniera y debe
TM
PDF Editor
C A P T U L O 2 3 ESTIMACIN PARA PROYECTOS DE SOFTWARE 701
*
CONSEJO
a p l i c a c i o n e s
r e s i d e n e n
r e d o s o n p a r t e
i a r q u i t e c t u r a
i r . P o r l o
a s e g r e s e d e
s u s e s t i m a c i o n e s
i e l e s f u e r z o
: p o r a d e s a -
s o l t w a r e d e
^ ONS E J O^
s u a m ba a l a
i d e u t i l i z a r
< e s u l t o d o c o m o l a
i d e s u
. U s t e d d e be
o t r o r e s u l t a d o
u n e n f o q u e
tener interfaz con varios perifricos que incluyen ratn, digitalizador, monitor de
color de alta resolucin e impresora lser. Se puede elaborar una descripcin preli-
minar del mbito del software:
El sof t war e CAD mecni co acept ar del i ngeni ero dat os geomt ri cos de dos y t res di men-
siones. El i ngeni ero i nt eract uar y cont rol ar el si st ema CAD a t ravs de una interfaz del
usuari o que exhibir caractersticas de buen di seo de interfaz humano- mqui na. Todos
los dat os geomt ri cos y otra i nformaci n de soport e se conservarn en una base de dat os
CAD. Se desarrollarn mdul os de anlisis de di seo para producir la salida requerida, la
cual se despl egar en una diversidad de dispositivos grficos. El soft ware s e di sear para
controlar e i nt eract uar con dispositivos perifricos que incluyen rat n, digitalizador, im-
presora lser y plotter.
Esta descripcin del mbi t o es preliminar, no est acotada. Se tendra que expandir
cada oracin para ofrecer detalle concreto y acotacin cuantitativa. Por ejemplo,
ant es de que comience la estimacin, el planificador debe determinar qu significa
"caractersticas de buen diseo de interfaz humano-mqui na" o cules sern el
t amao y la complejidad de la "base de dat os CAD".
En cuant o a los propsitos actuales, se supone que se ha llevado a cabo ms refi-
nami ent o y que estn identificadas las grandes funciones de soft ware menci onadas
en la figura 23.2. Al continuar con la tcnica de descomposicin para LDC se elabo-
ra una tabla de estimacin, la cual se muestra en la figura 23.2. En cada funcin se
desarrolla un rango de estimaciones LDC. Por ejemplo, el rango de las est i maci ones
LDC para la funcin de anlisis geomtrico 3D es: optimista, 4 600 LDC; ms proba-
ble, 6 900 LDC; y pesimista, 8 600 LDC. Al aplicar la ecuacin 23-1 el valor esperado
para la funcin de anlisis geomtrico 3D es 6 800 LDC. Otras estimaciones se deri-
van en forma similar. Al sumar verticalmente en la columna de LDC estimadas, se
establece una estimacin de 33 200 lneas de cdigo para el sistema CAD.
Ta bl a d e
e s t i m a c i n
p a r a m t o d o s
LDC.
Fu n c i n LDC e s t i m a d a s
Facilidades de interfaz del usuario y control (FIUC) 2 300
Anlisis geomtrico bidmensional (AG2D) 5 300
Anlisis geomtrico tridimensional (AG3D) 800
Gestin de base de datos (GBDj 3 350
Facilidades de presentacin grfica de 4 950
computadora (FPGC)
Funcin de control perilr co -CP 2 100
Mdulos de anlisis de a se-o Z 8 400
Lneas de cdigo estimabas 33 200
TM
PDF Editor
Una revisin de los dat os histricos indica que el promedi o organizacional de prc-
ductividad para si st emas de est e tipo es de 620 LDC/pm. Con base en una t ana
laboral de 8 000 dlares por mes, el costo por lnea de cdigo es aproximadamer. ::
de 13 dlares. Con base en la estimacin de LDC y los datos histricos de producti-
vidad, el costo total est i mado del proyecto es de 431 000 dlares y el esfuerzo es::
mado es de 54 personas-mes. 6
HOGARSEGURO
Es t i m a c i n
Vi n o d ( a s i e n t a c o n l a c a be za ) : Muy bien, pero no
hemos definido ningn incremento todava.
D o u g: Cierto, pero es por eso por lo que necesitamos
estimar. |
Ja m i e ( m a l hu m o r a d a ) : Quieres saber cunto nos
tomar? ' /.,
Oo u g: He aqu lo que necesito. Primero, necesitamos
descomponer funcionalmente el software de
Ho g a r Se g u r o . . . a un nivel elevado... luego tenemos que
estimar el nmero de lineas de cdigo que tomar cada
funcin... luego...
1 e s c e n a r i o : t a oficina de Doug
Miller cuando comienza la planificacin del proyecto,
l o s a c t o r e s : Doug Miller (gerente del equipo de
ingeniera del software de Ho g a r Se g u r o ) y Vinod Raman,
Jamie l azar y otros miembros del equipo de ingeniera
de software del producto.
Oo u g: Necesitamos desarrollar una estimacin del
esfuerzo para el proyecto, y luego tenemos que definir un
microprograma de trabajo pora el primer incremento y
un macroprograma de trabajo para los incrementos
Ja m i e : Vaya! Cmo se supone que lo haremos?
Vi n o d : Yo lo he hecho en proyectos previos. Utilizas
casos de uso, determinas la funcionalidad requerida
para implementar cada uno, supones el conteo de LDC
para cada pieza de la funcin. La mejor aproximacin e:
que cada uno lo haga de manera independiente y luego
comparamos los resultados.
D o u g: O puedes hacer una descomposicin funcional
de todo el proyecto.
Ja m i e : Pero eso tomar toda la vida, y ya tenemos que
comenzar.
Vi n o d : No.., se puede hacer en pocas horas... esto
maana, de hecho.
D o u g: Estoy de acuerdo... no podemos esperar
exactitud, slo una idea aproximado de cul ser el
tamao de Ho g a r Se g u r o .
Ja m i e : Creo que slo debemos estimar el esfuerzo...
eso es todo.
D o u g: Tambin haremos eso. Luego usaremos ambas
estimaciones como comprobacin mutua.
Vi n o d : Vamos a hacerlo...
23.6.4 Un ejemplo de estimacin bas ada en PF
La descomposicin de la estimacin basada en PF se centra en los valores de dominio
de informacin ms que en las funci ones de software. Al consultar la tabla presen-
tada en la figura 23.3 el planificador del proyecto estima ent r adas externas, salidas
externas, consul t as externas, archivos lgicos internos y archivos de interfaz exter-
nos para el soft ware CAD. Los PF se calculan usando la tcnica estudiada en el capi-
6 Las estimaciones estn redondeadas a 1 000 dlares y a la persona-mes ms cercanos. Mayor pre-
cisin es innecesaria e irreal, dadas las limitaciones de precisin de la estimacin.
TM
PDF Editor
C A P T U L O 2 3 ESTI MACI N PARA PROYECTOS DE SOFTWARE 703
Es t i m a c i n d e v a l o r e s d e d o m i n i o d e i n f o r m a c i n .
Va l o r d e d o m i n i o d e Co n t e o Co n t e o
i n f o r m a c i n Op t i m . Pr o ba bl e Pe s i m . e s t i m . Pe s o PF
Nmero de entradas externas 20 24 30 24 4 9 7
Nmero de salidas externas 12 15 22 16 5 78
Nmero de preguntas externas 16 22 28 22 5 88
Nmero de archivos lgicos internos 4 4 5 4 10
- i'--
42
Nmero de archivos de iriterfase externos 2 2 3 15
Conteo total
i i i l W l i i
320
tulo 15. En cuant o a los propsitos de esta estimacin se supone que el factor pon-
derado de complejidad es el promedio. La figura 23.3 present a los resultados de esta
estimacin.
Se estima cada uno de los factores ponderados de complejidad y el valor del fac-
tor aj ust ado se calculan como se describe en el captulo 15:
Fa c t o r Va l o r
1. Respaldo y recuperacin 4
2. Comunicaciones de datos 2
3. Procesamiento distribuido 0
4. Desempeo crtico 4
5. Entorno operativo existenle 3
6. Entrada de datos en lnea 4
7. Transaccin de entrada sobre pantallas mltiples 5
8. ILF actuolizado en lnea 3
9. Complejo de valores de dominio de informacin 5
10. Complejo de procesamiento interno 5
11. Cdigo diseado para reutilizacin 4
12. Con versin/instalacin en diseo 3
13. Instalaciones mltiples 5
14. Aplicacin diseada para cambio 5
Fa c t o r d e a j u s t e d e v a l o r 1. 17
Finalmente, se deriva el nmero estimado de PF:
PFe s t i ma d o = C O n t e O t o t a l X [ 0 . 6 5 + 0 . 0 1 X X ( F . ) ]
PFesUmado = 375
La productividad organizacional promedio para sistemas de est e tipo es 6.5 PF/pm.
Con base en una escala salarial de 8 000 c . .ares por mes, el costo por PF es aproxi-
madament e I 230 dlares. Con base en ia estimacin de PF y los dat os de producti-
TM
PDF Editor
704 PASTE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
vidad histricos, el costo total est i mado del proyecto es de 461 000 dlares, y el
esfuerzo estimado es de 58 personas-mes.
23.6.5 Estimacin bas ada en el proceso
La tcnica ms comn para estimar un proyecto es basar la estimacin en el proce-
so que se emplear. Esto es, el proceso se descompone en un conjunto relativa-
mente pequeo de tareas y se estima el esfuerzo requerido para lograr cada tarea
Al igual que las tcnicas basadas en el problema, la estimacin basada en el pro-
ceso comienza con un bosquejo de las funciones del soft ware obtenidas a partir de
mbito del proyecto. Cada funcin requiere realizar una serie de actividades del maree
de trabajo. Las funciones y actividades7 del marco de trabajo relacionadas se pre
sent an como parte de una tabla similar a la presentada en la figura 23.4.
Ta bl a d e
e s t i m a c i n
CC
OUmf i f - . c i An
r lanmcatiori
de ri esgo
Ingeni er a
construccin
EC Totales
Ta r e a - - Anl i si s Di seol C d i g o Pr ueba
Funcin
Y M
FIUC 0 . 5 0 2 . 5 0 0 . 4 0 5 . 0 0 n / a 8 . 4 0
AG2 D 0 . 7 5 4 . 0 0 0 . 6 0 2 . 0 0 n / a 7 . 3 5
AG3 D 0 . 5 0 4 . 0 0 1 . 0 0 3 , 0 0 n / a 8 . 5 0
FPGC 0 . 5 0 3 . 0 0 1 . 0 0 1 . 5 0 n / a 6 . 0 0
GBD 0 . 5 0 3 . 0 0 0 . 7 5 1 . 5 0 n / a 5 . 7 5
FCP 0 . 2 5 2 . 0 0 0 . 5 0 1 . 5 0 n / a 4 . 2 5
MAD 0 . 5 0 2 . 0 0 0 . 5 0 2 . 0 0 n / a 5 . 0 0
Tot al es 0 . 2 5 0 . 2 5 0 . 2 5 3 . 5 0 2 0 . 5 0 4 . 7 5 1 6 . 5 0 4 6 . 0 0
% es f uer zo 0 . 5 % 0 . 5 % 0 . 5 % 8 % 4 5 % 10% 3 6 %
CC = comuni caci n del cl i ent e EC eval uaci n del cl i ent e
Una vez que se combinan las funciones del problema y las actividades del proce-
so, el planificador estima el esfuerzo (por ejemplo, personas-mes) que se requerir;
para lograr cada actividad del proceso de software en cada funcin. Estos dat o;
constituyen la matriz central de la tabla en la figura 23.4. Entonces se aplican la
tasas de trabajo promedi o (es decir, cost o/ uni dad de esfuerzo) al esfuerzo est i mac:
para cada actividad del proceso. Es muy probable que la tasa de t rabaj o vare er
cada tarea. El equipo veterano est enormement e involucrado en las actividadef
^CONSEJcffi
Si e l t i e m p o l o
p e i m i l e , use l a g r a n a -
l a r i d a d f i n a c u a n d o
e s p e c i f i q u e l a s t a r e a s
e n l a f i g u r a 23. 4 . P o r
e j e m p l o , d i vi d a e l
a n l i s i s e n s u s t o r e a s
p r i n c i p a l e s y e s t i m e
c a d a u n a p o r
s e p a r a d o .
7 Las act i vi dades del mar co de t rabaj o que se eligen para est e proyecto difieren un poco de la activ
dades genri cas t rat adas en el captulo 2, que son la comuni caci n con el cliente (CC), la planifica-
cin, el anlisis de riesgos, la ingeniera y la construccin-liberacin.
TM
PDF Editor
705
t empr anas del mar co de t rabaj o y gener al ment e es ms cost oso que el equi po menos
exper i ment ado involucrado en la const rucci n y liberacin.
Los cost os y el esf uer zo para cada funci n y actividad del mar co de t rabaj o se cal-
cul an como el ltimo paso. Si la estimacin basada en el proceso se realiza inde-
pendi ent ement e de la est i maci n de LDC o PF, ahora se tienen dos o t res est i maci o-
nes para cost o y esf uer zo que se pueden compar ar y armoni zar. Si ambos conj unt os
de est i maci ones muest r an una concordanci a razonabl e, existe una buena razn
para creer que las est i maci ones son confiables. Si, por otra parte, los resul t ados de
di chas t cni cas de descomposi ci n muest r an poca concordanci a, se debe llevar a
cabo mayor investigacin y anlisis.
"Es mejor com prender e l t r a s f o n d o d e uno estimacin antes de utilizarlo."
B a r r y B o e hm y Ri c ha r d Fa i r l e y
23.6.6 Un ejemplo de estimacin bas ada en el proceso
Para ilustrar el us o de la est i maci n basada en el proceso consi drese de nuevo el
sof t war e CAD introducido en la secci n 23.6.3. La confi guraci n del si st ema y las
funci ones del sof t war e per manecen invariables y las indica el mbi t o del proyecto.
En la tabla basada en el proceso que se muest ra en la figura 23.4 las est i maci o-
nes del esf uer zo (en personas-mes) para cada actividad de ingeniera del sof t war e s e
proporci onan para cada funcin del sof t war e CAD (abreviadas para mayor rapidez).
Las act i vi dades de ingeniera y de liberacin de const rucci n se subdividen en las
principales t ar eas de ingeniera del sof t war e que se muest r an. Las pri meras est i ma-
ci ones de esf uer zo corresponden a comuni caci n con el cliente, planificacin y an-
lisis de riesgos, las cual es se registran en la hilera total al final de la tabla. Los totales
horizontal y vertical ofrecen un indicio del esf uer zo est i mado que se requiere para
anlisis, diseo, cdi go y prueba. Se debe seal ar que 53 por ci ent o del esf uer zo s e
empl ea en las t areas de ingeniera del si st ema de salida (anlisis de requisitos y dise-
o), lo que indica la importancia relativa de est e trabajo.
Con base en la escala salarial promedi o de 8 000 dl ares por mes, el cost o total
est i mado del proyecto es de 368 000 dl ares , y el esf uer zo est i mado es de 46 perso-
nas-mes. Si se desea, los promedi os de t rabaj o pueden asoci arse con cada actividad
del mar co de t rabaj o o t area de ingeniera del soft ware y calcularse por separado.
23.6.7 Estimacin con casos de uso
Como se ha seal ado a lo largo de las par t es 2 y 3 de est e libro, los cas os de uso per-
miten que un equi po de sof t war e compr enda el mbi t o del sof t war e y los requisitos.
Sin embar go, desarrollar un enf oque de est i maci n con casos de uso es problemti-
co por las si gui ent es r azones [SM199]:
Los casos de uso se descri ben empl eando muchos format os y estilos dife-
rentes; no existe un format o est ndar
^ Po r q u e s
d i f c i l d e s o -
lar u n o t c n i c a
i t e s t i m a c i n c o n
s o s d e u s o ?
TM
PDF Editor
Los casos de uso representan una visin externa (la visin del usuario) del
software y con frecuencia estn escritos con diferentes grados de abstraccin.
Los casos de uso no abordan la complejidad de las funciones ni de las carac-
tersticas que se describen.
Los casos de uso no describen el comportamiento complejo (por ejemplo,
interacciones) que involucran muchas funciones y caractersticas,
A diferencia de las LDC o un punt o de funcin, el "caso de uso" de una persona ta
vez requiera meses de esfuerzo mientras que el de otra quiz se implemente en lu-
dia o dos.
Aunque varios investigadores han considerado los casos de uso como una entra-
da a la estimacin, a la fecha no ha surgido ningn mt odo de estimacin probad:
Smith [SMI99] sugiere el empl eo de los casos de uso en la estimacin, pero slo s
se consideran dentro del contexto de la "jerarqua estructural" que los casos de us :
describen.
Smith argumenta que cualquier nivel de esta jerarqua estructural se describe cor
no ms de 10 casos de uso. Cada uno de st os abarcara no ms de 30 escenarios
distintos. Obviamente, los casos de uso que describen un sistema grande estn escr
tos con un grado mucho mayor de abstraccin (y represent an considerablemente
ms esfuerzo de desarrollo) que aquellos que describen un solo subsistema. En con-
secuencia, ant es de que los casos de uso se empleen en la estimacin, se establece
el nivel en la estructura jerrquica, se determina la longitud promedio (en pginas
de cada caso de uso, se define el tipo de soft ware (por ejemplo, tiempo real, de negc
cios, de ingeniera/cientfico, anidado) y se considera una arquitectura comn del
sistema. Una vez establecidas dichas caractersticas, los datos empricos se aprove-
chan para establecer el nmero estimado de LDC o de PF por caso de uso (para caca
nivel de la jerarqua). Entonces se utilizan los dat os histricos para calcular el esfuer-
zo necesario para desarrollar el sistema.
Enseguida se ilustra cmo realizar este clculo; por tanto, considrese la siguier
te relacin:8
LDC estimada = Nx LDCprom + [(S/Sh - 1) + {P /P h - 1)] x LDCa|uslc (23-2)
donde
N = nmero real de casos de uso
LDCprom = promedio histrico de LDC por caso de uso para este tipo de subsis-
t ema
8 Es importante sealar que la expresin (23-2) se emplea slo con propsitos ilustrativos. Al igual
que todos los modelos de estimacin, debe validarse localmente ant es de que se le pueda utiliza-
con seguridad.
TM
PDF Editor
C A P T U L O 2 3 ESTIMACIN PARA PROYECTOS DE SOFTWARE 7 0 7
LDCajUSte = representa un ajuste con base en n por ciento de LDCprom donde n
se define [ocalmente y representa la diferencia entre este proyecto
y los proyectos "promedio"
Sa = escenarios reales por caso de uso
Sh = escenarios promedio por caso de uso para este tipo de subsistema
P a = pginas reales por caso de uso
P h = pgina promedio por caso de uso para est e tipo de subsistema
Con la expresin (23-2) se desarrolla una estimacin comn del nmero de LDC con
base en el nmero real de casos de uso aj ust ado medi ant e el nmer o de escenari os
y la longitud de la pgina de los casos de uso. El ajuste representa hasta n por cien-
to del promedio histrico de las LDC por caso de uso.
23.6.8 Un ejemplo de estimacin bas ada en casos de uso
El soft ware CAD presentado en la seccin 23.6.3 est compuest o de tres grupos de
subsistemas:
Subsistema de interfaz del usuario (incluye FIUC).
Grupo de subsistema de ingeniera (incluye el subsistema AG2D, subsistema
AG3D y el subsistema MAD).
Grupo de subsistema de infraestructura (incluye el subsistema FPCG y el
subsistema FCP).
Seis casos de uso describen el subsistema de interfaz del usuario. Cada caso de uso
lo describen no ms de 10 escenarios y tiene una longitud promedio de seis pginas.
El grupo de subsistema de ingeniera lo describen 10 casos de uso (considerados en
un nivel ms alto de la jerarqua estructural). Cada uno de los casos de uso no tiene
ms de 20 escenarios asociados y tiene una longitud promedio de ocho pginas.
Finalmente, el grupo de subsistema de infraestructura lo describen cinco casos de uso
con un promedio de slo seis escenarios y una longitud promedio de cinco pginas.
Con la relacin anotada en la expresin (23-2) y n = 30 por ciento se elabora la
tabla de la figura 23.5. Si se considera la primera hilera de la tabla, los dat os histri-
cos indican que el soft ware IU requiere un promedio de 800 LDC por caso de uso
cuando ste no tiene ms de 12 escenarios y est descrito en menos de cinco pgi-
Es t i m a c i n d e c a s o d e u s o .
Subsistema de interfaz del usuario
Grupo de subsistema de ingeniera
Grupo de subsistema de infraestructura
Total LDC estimadas
casos
de uso
6
10
5
escenarios pginas
1 0 6 12 5 5 6 0 3 3 6 6
2 0 8 8 3100 3 1 2 3 3
6 5 6 1650 7 9 7 0
4 2 5 6 8
LDC LDC estimadas
TM
PDF Editor
as. Estos dat os se aj ust an r azonabl ement e bien para el si st ema CAD. As pues, la
est i maci n de LDC para el subsi st ema de interfaz del usuari o se calcula medi ant e la
expresi n (23-2), Si se aplica el mi s mo enfoque, se realizan est i maci ones para los
grupos de subsi st emas de ingeniera e infraestructura. La figura 23. 5 r es ume las esti-
maci ones e indica que el t amao global del sof t war e CAD se est i ma en 42 500 LDC
Si se utilizan 620 LDC/pm como la productividad promedi o en los si st emas de
est e tipo y una escala salarial de 8 000 dl ares por mes, el cost o por lnea de cdigo
es apr oxi madament e de 13 dlares. Con base en la est i maci n de caso de uso y lo?
dat os histricos de productividad, el cost o total est i mado del proyecto es de 552 OOC
dlares, y el esf uer zo est i mado es de 68 per sonas- mes.
23.6.9 Reconciliacin de estimaciones
Las tcnicas de estimacin est udi adas en las secciones precedent es dan por resultado
mltiples est i maci ones que deben reconciliarse para producir una sola est i mador,
de esfuerzo, duracin del proyect o o costo. Este procedi mi ent o de reconciliacin se
ilustra consi der ando de nuevo el sof t war e CAD pr esent ado en la secci n 23.6.3.
"Tai vez los mt odos compl i cados no pr oduzcan una est i maci n m s preci sa, par t i cul ar ment e cuando los
de s a bol l a dor e s pueden i ncor por ar su pr opi a intuicin en la est i maci n. " ;
Phi l i p Jo hn s o n e l a l .
El esf uer zo est i mado total para el soft ware CAD vara desde un baj o de 46 persc-
nas - mes (obtenido empl eando el enfoque de la est i maci n bas ada en el pr oces:
hast a un alto de 68 per sonas- mes (derivado con la est i maci n de caso de uso). L
estimacin promedi o (que utiliza los cuat ro enfoques) es de 56 personas-mes. La varia-
cin de la est i maci n promedi o es apr oxi madament e 18 por ci ent o en el lado baj :
y de 21 por ci ent o en el lado alto.
Qu ocurre cuando la concordanci a ent re las est i maci ones es insuficiente-
Responder est a pregunt a requiere reevaluar la i nformaci n con que se hicieron las
est i maci ones. Las est i maci ones ampl i ament e di vergent es con frecuenci a puede-
rast rearse hast a una de dos causas:
1. El planificador no ha comprendi do adecuadament e o ha mal i nt erpret ado el
mbi t o del proyecto.
2. Los dat os de productividad que utilizan las t cni cas de est i maci n bas adas er
el probl ema son napropi ados para la aplicacin, obsol et os (pues ya no refle-
j an con precisin la organi zaci n de ingeniera de soft ware) o se han aplicad ;
mal.
El planificador debe det ermi nar la causa de la divergencia y luego reconciliar las
est i maci ones.
TM
PDF Editor
709
INFORMACIN
Tc n i c a s d e e s t i m a c i n a u t o m a t i z a d a p a r a p r o y e c t o s d e s o f t w a r e
\
Las herramientas de estimacin automatizadas
permiten que planificador estime costo y
y realice anlisis "si... entonces" respecto de
ntes variables del proyecto, como la fecha de
o la plantilla de personal. Aunque existen muchas
lientas de estimacin automatizada (vase el
Iro ms adelante en este captulo), todas presentan
mismas caractersticas generales y realizan las
tes seis funciones genricas [JON96]:
Ta m a o d e l o s e n t r e g a bl e s d e l p r o y e c t o . Se estima el
"tamao" de uno o ms productos de trabajo del
software. Los productos de trabajo incluyen la
representacin externa del software (por ejemplo,
pantallas, reportes), el software en s mismo (por
ejemplo, KLDC), funcionalidad entregada (por
ejemplo, puntos de funcin) e informacin descriptiva
(por ejemplo, documentos).
2. Se l e c c i n d e l a s a c t i vi d a d e s d e l p r o y e c t o . Se
selecciona el marco de trabajo del proceso
adecuado y se especifica el conjunto de tareas de
3. P r e d i c c i n d e l o s n i ve l e s d e l p e r s o n a l . Se especifica el
nmero de personas que estar disponible para realizar
el trabajo. Puesto que la relacin entre el personal
disponible y el trabajo (esfuerzo predicho) es
enormemente no lineal, sta es una entrada importante.
4 . P r e d i c c i n d e i e s f u e r z o d e s o f t w a r e . La s
herramientas de estimacin emplean uno o ms
modelos (seccin 23.7) que relacionan el tamao de
los entregables del proyecto con el esfuerzo
requerido para producirlos.
5. P r e d i c c i n d e l c o s t o d e l s o f t w a r e . Dados los
resultados del paso 4, los costos se calculan
relacionando los ndices de trabajo con las
actividades del proyecto anotadas en el paso 2.
6. P r e d i c c i n d e l p r o g r a m a d e t r a ba j o d e l s o f t w a r e .
Cuando se conocen el esfuerzo, el nivel del personal
y las actividades del proyecto es posible producir un
anteproyecto de programa al ubicar el trabajo a
travs de las actividades de ingeniera del software
con base en los modelos recomendados para la
distribucin del esfuerzo estudiados en el captulo 24.
La aplicacin de diferentes herramientas de estimacin a
los mismos datos de proyecto permite encontrar una
variacin relativamente grande en los resultados
estimados. Ms importante todava, en ocasiones los
valores predichos son significativamente diferentes de los
valores reales. Esto refuerza la nocin de que las salidas
de las herramientas de estimacin se deben emplear como
un "punto de datos" a partir del cual se derivan las
estimaciones, no como la nica fuente para una
estimacin.
\
C L A V E
fc model o de
s t i ma c i n refl ej a la
xl aci a de proyect os
: es de la que s e ha
j eri vado. Por lo t ant o,
model o es sensi bl e
d domi ni o.
Un model o de estimacin para soft ware de comput adora utiliza frmulas obtenidas
emp ri cament e para predecir el esfuerzo como una funcin de LDC o PF.9 Los valo-
res de LDC o PF se estiman medi ant e el enfoque descrito en las secci ones 23.6.3 y
23.6.4. Pero, en lugar de empl ear las tablas descritas en dichas secciones, los valo-
res resultantes para LDC o PF se colocan en el model o de estimacin.
Los dat os empricos que apoyan la mayora de los model os de estimacin proce-
den de una muest ra limitada de proyectos. Por esta razn, ningn model o de esti-
maci n es apropi ado para t odas las clases de soft ware ni en todos los ent ornos de
desarrollo. En consecuenci a, los resultados obtenidos a partir de tales model os se
deben emplear juiciosamente.
9 En la seccin 23.6.7 se sugiere un modelo emprico que utiliza casos de uso como la variable inde-
pendiente. Sin embargo, a la fecha han aparecido relativamente pocos en la respectiva bibliografa.
TM
PDF Editor
( CONSEJ O^
Ni n g u n o d e e s t o s
m o d e l o s s e d e be
e m p l e a r s i n u n o c o l i -
br a c i n c u i d a d o s a a
s u e n l o m o .
En s u n s e t .u s t .
e d u / r e s e o r /
C 0 C 0 M0 I I / -
c o c o m o -m o i n .htm l
se puede obtener |
comtodn detolloda
acerca de COCOMO' II,
j dus os of t wme
Un model o de est i maci n debe calibrarse para reflejar las condi ci ones locales,
model o debe probarse medi ant e la aplicacin de los dat os recopi l ados a partir
proyect os compl et ados, colocar los dat os en el model o y luego compar ar los r~
t aos real es con los predichos. Si la concordanci a es insuficiente, el model o debe
narse y poner se a prueba nuevament e ant es de que se pueda utilizar.
23.7.1 La estructura de los modelos de estimacin
Un model o de est i maci n tpico se deriva medi ant e el anlisis de regresin de
dat os recopi l ados de proyect os de sof t war e previos. La est ruct ura global de
model os t oma la forma [MAT94]
E = A + B x (ev)c
(23-3
donde A , B y C son const ant es obt eni das emp ri cament e, E es el esf uer zo en pers: -
na- mes y ev es la variable de est i maci n (ya sea LDC o PF). Adems de la relacin
anot ada en la ecuaci n (23-3), la mayor a de los model os de est i maci n tiene algu-
na forma de component e de aj ust e del proyect o que permite aj ust ar por
caract er st i cas del proyect o (por ejemplo, complejidad del probl ema, experiencia
personal , ent or no de desarrollo). Entre los muchos model os de est i maci n orienta-
dos a LDC propuest os en la bibliografa se encuent r an
E = 5.2 x (KLDC)09'
E = 5.5 + 0.73 x (LDC)116
E = 3.2 x (KLDC)105
E = 5.288 x (KLDC)10457
model o Walston-Felix
model o Bailey-Basili
model o simple de Boehm
model o Doty para KLDC > 9
Tambi n se han propuest o model os ori ent ados a PF. Entre st os se incluyen:
E = - 91. 4 + 0.355 PF
E = - 3 7 + 0.96 PF
E = - 12. 88 + 0.405 PF
model o de Albrecht y Gaffney
model o de Kemerer
model o de regresin para proyect o pequeo
Un rpi do examen de est os model os indica que cada uno produci r un resultad:
diferente para los mi smos val ores de LDC o PF. La implicacin es clara. Los mode-
los de est i maci n deben calibrarse para las necesi dades locales!
23.7.2 El modelo COCOMO II
En su libro clsico acerca de "econom a de la ingeniera del soft ware", Barry Boehm
[BOE81] introduce una j erarqu a de model os de est i maci n de sof t war e que lleva rl
nombr e de COCOMO, por COn s t r u c t i ve COst M Od e l (Modelo Constructivo de Costo;
El model o COCOMO original se volvi uno de los ms ampl i ament e utilizados y estu-
di ados model os de estimacin de cost o de sof t war e en la industria. Adems, ha evo-
l uci onado a un model o de estimacin ms amplio, l l amado COCOMO II [BOE9f.
BOEOO]. Al igual que su predecesor, COCOMO II es en realidad una jerarqua de
model os de est i maci n que aborda las r eas siguientes:
TM
PDF Editor
C A P T U L O 2 3 ESTIMACIN PARA PROYECTOS D E SOFTWARE 711
M o d e l o d e c o m p o s i c i n d e l a a p l i c a c i n . Se empl ea durant e las pri meras et apas
de la ingeniera del soft ware, cuando son primordiales la elaboracin de
prototipos de las i nt erfases de usuario, la consi deraci n de la interaccin del
sof t war e y el sistema, la valoracin del des empeo y la eval uaci n de la
madur ez de la tecnologa.
M o d e l o d e e t a p a d e d i s e o t e m p r a n o . Se utiliza una vez que se han estabili-
zado los requisitos y se ha est abl eci do la arqui t ect ura bsica del soft ware.
M o d e l o d e e t a p a p o s t e r i o r a l a a r q u i t e c t u r a . Se empl ea dur ant e la const rucci n
del soft ware.
Al igual que los model os de est i maci n del soft ware, los model os COCOMOII requie-
ren i nformaci n de t amao. Como part e de la jerarqua del model o hay disponibles
t res opci ones di ferent es de t amao: punt os objeto, punt os de funcin y lneas de
cdi go fuente.
El model o COCOMO II de composi ci n de la aplicacin empl ea punt os objeto, una
medi da indirecta de sof t war e que s e calcula medi ant e cont eos del nmer o de 1) pan-
tallas (en la i nt erfaz del usuario), 2) report es y 3) component es que pr obabl ement e
se requi eran par a construir la aplicacin. Cada instancia de obj et o (por ejemplo, una
pant al l a o reporte) se clasifica en uno de t res niveles de complejidad (es decir, si m-
ple, medi o o difcil) apl i cando criterios sugeri dos por Boehm [BOE96]. En esenci a, la
complejidad es una funcin del nmer o y origen de las t abl as de dat os del cliente y
el servidor que se requi eren para generar la pant al l a o reporte, y el nmer o de vis-
tas o secci ones pr esent adas como part e de la pant al l a o el informe.
Q u e s Una vez que se ha det er mi nado la complejidad, el nmer o de pantallas, i nformes
M p u n t o y component es se pondera de acuer do con la tabla ilustrada en la figura 23.6.
Ent onces se det ermi na la cuent a de punt os obj et o al multiplicar el nmer o original
de i nst anci as de obj et o por el factor de ponderaci n en la figura y se s uma para obt e-
ner una cuent a total de punt os objeto. Al aplicar el desarrol l o bas ado en compo-
nent es o la reutilizacin general de soft ware se est i ma el porcent aj e de reutilizacin
(%reut) y se aj ust a la cuent a de punt os objeto:
NPO = (puntos objeto) x [(100 - %reut)/100]
donde NPO se define como nuevos punt os objeto.
Para obt ener una est i maci n del esf uer zo con bas e en el valor NPO calculado, se
debe calcular una "tasa de productividad". La figura 23.7 present a la tasa de produc-
tividad
PROD = NPO/ per sona- mes
para di ferent es niveles de experi encia del desarrollador y madur ez del ent or no de
desarrollo. Una vez det ermi nada la tasa de productividad se puede obt ener una esti-
maci n del esf uer zo del proyect o del modo siguiente:
esf uer zo est i mado = NPO/PROD
TM
PDF Editor
Po n d e r a c i n d e
c o m p l e j i d a d
p a t a t i p o s d e
o bje t o [B OE96].
Ti p o d e
o bj e t o
Pe s o d e c o m p l e j i d a d
Ti p o d e
o bj e t o
Si m p l e Me d i o D i f c i l
Pa n t a l l a 1 2 3
Re p o r t e 2 5 8
C o mp o n e n t e 3 GL 1 0
Ta s a d e p r o d u c t i v i d a d p o r p u n t o s o bje t o [B OE96],
Exp e r i e n c i a / c a p a c i d a d d e l
d e s a r r o l l a d o r
Muy
baj a
Boja Nominal Alta
Muy
alta
Ma d u r e z/ c a p a c i d a d d e l e n t o r n o
Muy
baj a
Baja Nominal Alta
Muy
alta
TASA PRODUCTIVIDAD (PROD) 4 7 13 2 5 50
9 www. q s m. c o g i
infamacin ocer t ode
Miramientos de
estimacin de costo de
software que hon
evolucionado a poitir
de lo ecuacin
softwoie.
En modelos COCOMO II ms avanzados10 se requieren varios factores de esca a.
controladores de costo y procedimientos de ajuste. El lector interesado debe leer
[BOEOO] o visitar el sitio Web de COCOMO II.
23.7.3 La ecuaci n del sof t war e
La ecuacin de soft ware [PUT92] es un model o multivariable que supone una distr
bucin especfica del esfuerzo a lo largo de la vida de un proyecto de desarrollo ce
software. El modelo procede de dat os de productividad recopilados de casi 4 OC>:
proyectos de soft ware cont emporneos. Con base en estos datos, un model o de esv
macin de la forma
E = [LDC x B "3 / Pj 3 x (1/4)
( 2 3 - 4 i
donde
E = esfuerzo en personas-mes o personas-ao
t = duracin del proyecto en meses o aos
B = "factor especial de habilidades"1'
10 Como se anot anteriormente, estos modelos utilizan conteos de PFy KLDC para la variable tamaft:
11 B aumenta lentamente conforme "crecen la necesidad de integracin, las pruebas, la garanta de ca-
lidad, la documentacin y las habilidades de gestin" [PUT92]. Para programas pequeos (KLDC
a 15), B = 0.16. Para programas ms grandes que 70 KLDC, B = 0.39.
TM
PDF Editor
713
P = "parmetro de productividad" que refleja: madurez global del proceso y
prcticas de gestin, la medida en la que se emplean las buenas prcticas
de ingeniera del software, el nivel de los lenguajes de programacin utili-
zados, el est ado del ent orno del software, las habilidades y experiencias
del equipo de software, y la complejidad de la aplicacin.
Los valores tpicos pueden ser P = 2 000 para desarrollo del soft ware anidado de
tiempo real; P = 10 000 para soft ware de telecomunicaciones y sistemas; P = 28 000
para aplicaciones de sistemas de negocios. El parmet ro de productividad se puede
calcular para condiciones locales si se emplean datos histricos recopilados de
esfuerzos de desarrollo previos.
Es importante notar que la ecuacin del software tiene dos parmet ros indepen-
dientes: 1) una estimacin del t amao (en LDC) y 2) una estimacin de la duracin
del proyecto en meses o aos calendario.
Putnam y Myers [PUT92] sugieren un conj unt o de ecuaciones derivadas de la
ecuacin del software para simplificar el proceso de estimacin y emplear una forma
ms comn para su model o de estimacin. El tiempo mnimo de desarrollo se defi-
ne como
tmjn = 8.14(LDC/P)043 en meses para tmin > 6 meses (23-5a)
E = 180B3 en personas-mes para E > 20 personas-mes (23-5b)
Ntese que t se representa en aos en la ecuacin (23-5b).
Al utilizar las ecuaci ones (23-5) con P = 12 000 (el valor recomendado para soft-
ware cientfico) para el software CAD estudiado previamente en este captulo,
mln = 8.14(33 200/ 12 000)"43
tmin = 12.6 meses calendario
= 180 X 0.28 X (1.05)3
E = 58 personas-mes
Los resultados de la ecuacin del soft ware corresponden favorablemente con las
estimaciones desarrolladas en la seccin 23.6. Al igual que el model o COCOMO
seal ado en la seccin precedente, la ecuacin del soft ware ha evolucionado duran-
te la dcada pasada. En [PUT97b] se puede encont rar una detallada exposicin de
una versin extendida de est e enfoque de estimacin.
Vale la pena compl ement ar los mt odos convencionales de estimacin de costo del
software con un enfoque diseado explcitamente para soft ware OO. Lorenz y Kidd
[LOR94] sugieren el enfoque siguiente
1. Desarrollar estimaciones aplicando la descomposicin de esfuerzo, anlisis de
PF y cualquier otro mt odo que sea aplicable en aplicaciones convencionales.
TM
PDF Editor
2. Aplicar el model ado de anlisis orientado a objetos (captulo 8), desarrollar
casos de uso y determinar un conteo. Reconocer que el nmero de casos de
uso puede cambiar conforme avance el proyecto.
3. A partir del modelo de anlisis, determinar el nmero de clases clave (llama-
das c l a s e s d e a n l i s i s en el captulo 8).
4. Categorizar el tipo de interfaz para la aplicacin y desarrollar un multiplicad
para las clases de soporte:
Ti p o d e i n t e r f a z
Sin IUG
Interfaz del usuario basada en texto
IUG
IUG com pleia
Mu l t i p l i c a d o r
2. 0
2. 25
2. 25
3. 0
5.
6.
Multiplicar el nmero de clases clave (paso 3) por el multiplicador para obte-
ner una estimacin del nmero de clases de soporte.
Multiplicar el nmero total de clases (clave + soporte) por el nmero prome-
dio de unidades de trabajo por clase. Lorenz y Kidd sugieren de 15 a 20 persc-
nas-da por clase.
Comprobar de manera cruzada la estimacin basada en clase al multiplicar e
nmero promedio de unidades de trabajo por caso de uso.
Las tcnicas de estimacin estudiadas en las secciones 23.6, 23.7 y 23.8 se pue
aplicar en cualquier proyecto de software. Sin embargo, cuando un equipo de :
ware encuent ra una duracin de proyecto ext remadament e corta (semanas ms que 1
meses) que probablemente tengan una continua corriente de cambios la piar
cacin del proyecto en general y la estimacin en particular se deben abreviar.12 Ea |
las secciones siguientes se examinan dos tcnicas de estimacin especializadas.
23.9.1 Estimacin par a desarrollo gil
Puesto que los requerimientos para un proyecto gil (captulo 4) se definen como un ]
conjunto de escenarios de usuario (por ejemplo, "historias" en programacin extre-
ma) es posible desarrollar un enfoque de estimacin informal, aunque razonaba
ment e disciplinado y significativo dentro del contexto de la planificacin del proye:-
to para cada incremento de software.
La estimacin para los proyectos giles aplica un enfoque de descomposicin que
abarca los pasos siguientes:
12 "Abreviar" no significa eliminar. Incluso los proyectos de corta duracin deben planificarse, y la e s - |
limacin es el fundamento de la planificacin slida.
TM
PDF Editor
C A P I T U L O 2 3 ESTIMACIN PARA PROYECTOS DE SOFTWARE
715
Cm o s e
' d e s a r r o l l a n
i c i o n e s
i s e a p l i c a
i gi l ?
[CONSEJO
I - r i e x l o d e l o
i p a r o u n
> .
' e s u n a
7 d e l
: g l o ba l d e u n
i u s u a r i o
r . o P f .
1. Cada escenari o de usuari o (el equi val ent e de un mi ni caso de us o cr eado en el
comi enzo mi s mo de un proyect o por los usuari os finales u ot ros participantes)
se consi dera por separ ado respect o de propsi t os de est i maci n.
2 . El escenari o se descompone en el conj unt o de funci ones y las t ar eas de inge-
niera del sof t war e que se requeri rn para desarrollarlo.
3a. Cada tarea se est i ma por separado. Nota: la est i maci n se puede basar en da-
tos histricos, en un model o emp ri co o en la "experiencia".
3b. Alternativamente, el "vol umen" (tamao) del escenari o se puede est i mar en
LDC, PF o al guna otra medi da ori ent ada a vol umen (por ejemplo, punt os ob-
jeto).
4a . Las est i maci ones de cada tarea se s uman par a crear una est i maci n para el
escenari o.
4b. Alternativamente, el vol umen est i mado para el escenari o se t raduce en es-
fuerzo medi ant e la aplicacin de dat os histricos.
5. Las est i maci ones de esf uer zo acerca de t odos los escenar i os que se imple-
ment ar n para un i ncrement o de soft ware dado se s uman con el fin de desa-
rrollar el esf uer zo est i mado para el i ncrement o.
Puest o que la duracin del proyect o requeri do para el desarrol l o de un i ncr ement o
de soft ware es bast ant e corta (usual ment e de 3-6 semanas) , est e enf oque de esti-
maci n tiene dos propsitos: 1) asegurar que el nmer o de escenari os que se inclui-
rn en el i ncrement o se integra con los recursos disponibles, y 2) est abl ecer una base
par a ubicar el esf uer zo conf or me se desarrolla el i ncrement o.
23.9.2 Estimacin par a proyectos de ingeniera Web
Como se asent en el captulo 16, los proyect os de ingeniera Web con frecuenci a
adopt an el model o de proceso gil. Es factible empl ear una medicin de punt o de
funcin modificada, en conj unt o con los pasos subrayados en la seccin 23.9.1, con
el fin de desarrollar una est i maci n para la WebApp.
Roet zhei m (ROEOOj sugiere los si gui ent es valores de domi ni o de i nformaci n
cuando se adapt an punt os de funcin (captulos 15 y 22) para la est i maci n WebApp:
En t r a d a s son cada pantalla o format o de ent rada (por ejemplo, CGI o Java),
cada pantalla de mant eni mi ent o y, si en al guna part e utiliza una etiqueta de
met fora de cuaderno, cada etiqueta.
Sa l i d a s son cada pgi na Web esttica, cada guin de pgi na Web di nmi ca
(por ejemplo, ASP, ISAPI u ot ro guin DHTML) y cada reporte (ya sea que est
bas ado en Web o sea del t odo administrativo).
Ta bl a s son cada tabla lgica en la bas e de dat os ms, si empl ea XML para
al macenar dat os en un archivo, cada obj et o XML (o coleccin de at ri but os
XML).
TM
PDF Editor
Las i n t e r f a c e s retienen su definicin como archivos lgicos (por ejemplo,
format os de registro nicos) en las fronteras exteriores del sistema.
Co n s u l t a s son cada interfaz publicada ext ernament e o utiliza una interfaz
orientada al mensaj e. Un ej empl o tpico son las referencias ext ernas DCOM o
COM.
Los punt os de funcin (calculados empl eando los valores de dominio de informacin
anotados) son un indicador razonable del volumen para una WebApp.
Mendesy sus colegas [MEN011 sugieren que el volumen de una WebApp se deter-
mina mejor medi ant e la recopilacin de medi das (llamadas "variables predictoras
asoci adas con la aplicacin (por ejemplo, cont eo de pgina, cont eo de medios
audiovisuales, cont eo de funcin), las caractersticas de su pgina Web (por ejemplo,
complejidad de pgina, complejidad de vinculacin, complejidad grfica), sus carac-
tersticas de medios audiovisuales (por ejemplo, duracin de los clips) y caractersti-
cas funcionales (por ejemplo, longitud de cdigo, longitud de cdigo reutilizado)
Dichas medi das se pueden emplear en el desarrollo de modelos de estimacin emp:-
Es t i m a c i n d e e s f u e r z o y c o s t o
Obj e t i v o : El objetivo de las herramientas de
estimacin de esfuerzo y costo es proporcionar
al equipo del proyecto una estimacin del esfuerzo
requerido, de la duracin del proyecto y del costo en una
forma que aborde las caractersticas especficas del
proyecto inmediato y el entorno en el que se construir.
Me c n i c a : En general, las herramientas de estimacin de
costo utilizan una base de datos histrica procedente de
proyectos locales, datos recopilados a travs de la
industria y un modelo emprico (por ejemplo, COCOMO II)
que se emplea para calcular estimaciones de esfuerzo,
duracin y costo, tas caractersticas del proyecto y el
entorno de desarrollo son entradas, y la herramienta
proporciona un rango de estimacin de salidas.
He r r a m i e n t a s r e p r e s e n t a t i v a s 1 3
Costar, desarrollado por Softstar Systems
(www.softstarsystems.com), emplea el modelo
COCOMO II para desarrollar estimaciones de
software.
Co s t Xp e r t , desarrollado por Cost Xpert Group, Inc.
(www.costxpert.com), integra modelos de estimacin
. mltiples y una base de datos histrica de proyectos,
Es t m a t e P r o f e s s i o n a l , desarrollado por el Software
Productivity Center, Inc. (www.spc.com), est basado en
COCOMO II y en el Modelo SUM.
Kn o w l e d g e P l a n , desarrollado por Software Productivity
Research (www.spr.com), utiliza la entrada de punto de
funcin como el controlador primario para un paquete
de estimacin completo.
P r i c e 5, desarrollado por Price Systems
(www.pricesystems.com), es una de las herramientas
ms viejas y ampliamente utilizadas en proyectos de
desarrollo de software a gran escala.
SEER /SEM , desarrollado por Galorath Inc.
(www.galorath.com), proporciona una capacidad de
estimacin completa, anlisis de sensibilidad,
valoracin de riesgo y otras caractersticas.
SU M - Es t i m a t e , desarrollado por QSM (www.qsm.com),
echa mano de "bases de conocimiento industrial"
detalladas para ofrecer una "verificacin sanitaria" de
las estimaciones obtenidas empleando datos locales.
13 Las herramientas anotadas aqu son una muestra de esta categora. En la mayora de los casos
nombres de las mismas son marcas registradas por sus respectivos desarrolladores.
TM
PDF Editor
717
rica para esf uer zos de proyect o total, de creacin de pgi na, de creaci n de medi os
audi ovi sual es y de creaci n de gui ones. Sin embargo, todava falta realizar ms tra-
baj o ant es de que t al es model os puedan empl earse con confi anza.
2 3 . 1 0 LA DECI SI N DES ARROLLAR- COMP RAR
A menudo, en muchas r eas de aplicacin de sof t war e es ms rent abl e adquirir que
desarrollar sof t war e de comput ador a. Los gest ores de ingeniera del soft ware
enf r ent an una decisin de desarrol l ar-comprar que tal vez se compl i que an ms por
varias opci ones de adquisicin: 1) el sof t war e se puede compr ar (o adquirir la licen-
cia) ya desarrol l ado, 2) los component es de soft ware de "experiencia compl et a" o
"experiencia parcial" (vase la secci n 23.4.2) se pueden adquirir y luego modificar
e integrar para sat i sfacer necesi dades especficas, o 3) el sof t war e se puede construir
de maner a personal i zada por medi o de un contratista ext erno para satisfacer las
necesi dades del comprador.
Los pasos involucrados en la adquisicin los defi nen lo crucial de! soft ware que
se compr ar y el cost o final. En el anlisis final, la decisin desarrol l ar-comprar se
realiza bas ndos e en las si gui ent es condiciones: 1) El product o de sof t war e est ar
disponible ant es que el soft ware desarrol l ado de maner a interna? 2) El cost o de
adquisicin ms el cost o de personal i zaci n ser menor que el cost o de desarrollar
el soft ware de maner a interna? 3) El cost o del soport e ext erno (por ej empl o, un con-
trato de mant eni mi ent o) ser menor que el cost o del soport e interno? Estas condi-
ci ones se aplican a cada una de las opci ones de adquisicin.
23.10.1 Creacin de un rbol de decisin
Los pasos recin descri t os se pueden aument ar medi ant e t cni cas est ad st i cas tales
como el a n l i s i s d e l r bo l d e d e c i s i n [BOE89]. Por ejemplo, la figura 23.8 bosquej a un
rbol de decisin para un si st ema bas ado en soft ware, X. En est e caso, la organi za-
cin de ingeniera del soft ware puede 1) construir el si st ema X desde cero, 2) reuti-
lizar component es exi st ent es de "experiencia parcial" para construir el si st ema, 3)
comprar un product o de soft ware disponible y modificarlo para sat i sfacer las nece-
si dades locales, o 4) cont rat ar el desarrol l o de soft ware con una empr esa ext erna.
Si el si st ema se construir desde cer o existe un 70 por ci ent o de probabilidad de
que el t rabaj o sea difcil. Al empl ear las t cni cas de est i maci n est udi adas ant es en
est e captulo, el planificador del proyect o est i ma que un esf uer zo de desarrol l o dif-
cil costar 450 000 dlares. Un esfuerzo de desarrollo "simple" se estima que costar
380 000 dlares. El va l o r e s p e r a d o para el cost o, cal cul ado a lo largo de cualquier
rama del rbol de decisin, es
Exi s t e u n a
f o r m a
(a d e
l a s
c o n l a
o l l a r -
7
cost o esper ado = I (probabilidad de la ruta x (costo est i mado de la ruta),
donde i es la trayectoria del rbol de decisin. Para la trayectoria de const rucci n,
cost o esperadoconst r ul I = 0.30(380K c . are - 0.70(450K dlares) = 429K dlares
TM
PDF Editor
Ar bo l d e d e c i s i n
p a r a a p o y a r l a
d e c i s i n
d e s a r r o l l a r -
c o m p r a r .
Si mpl e ( 0. 30)
3 8 0 0 0 0 dol or es
4 5 0 0 0 0 dl a r e s
2 7 5 0 0 0 dl a r e s
3 1 0 0 0 0 dl a r e s
4 9 0 0 0 0 d l a r e s
2 1 0 0 0 0 dl a r e s
4 0 0 0 0 0 dl a r e s
3 5 0 0 0 0 dl a r e s
5 0 0 0 0 0 dl a r e s
Al seguir otras trayectorias del rbol de decisin tambin se muestran, en una
diversidad de circunstancias, los costos proyectados para reutilizacin, compra y
contratacin. Los costos esperados para dichas trayectorias son
costo esperadoIeul i |zar = 0.40(275K dlares) = 0.60(0.20(310K dlares) + 0.80(490K
costo esperadOcomprar = 0.70(210K dlares) + 0.30(400Kdlares) = 267K dlares
costo esperadomn,r al ar = 0.60(350K dlares) + 0.40(500K dlares) = 410K dlares
Con base en la probabilidad y los costos proyectos que se han anot ado en la figura
23.8, el costo esperado ms bajo es la opcin "comprar".
Sin embargo, es importante sealar que se deben considerar muchos criterios no
slo costo durante el proceso de toma de decisin. Disponibilidad, experiencia del
desarrollador-vendedor-contratista, concordancia con los requisitos, "polticas"
locales y la probabilidad de cambiar son slo algunos de los criterios que pueden
incidir en la decisin final de construir, reutilizar, comprar o contratar.
23.10.2 Subcontratacin
Tarde o t emprano, cualquier compaa que desarrolla soft ware de computadora se
plantea una pregunta fundamental: existe una forma de conseguir los sistemas y
soft ware necesarios a un precio ms bajo? La respuesta no es tan simple, y los deba-
tes emocionales que genera la pregunta siempre conducen a una sola palabra: s u b-
c o n t r a t a c i n .
Como concepto, la subcontratacin es ext remadament e simple. Las actividades
de ingeniera del soft ware se contratan con una tercera parte que realiza el trabajo
dlares)] = 382K dlares
TM
PDF Editor
C A P T U L O 2 3 ESTIMACIN PARA PROYECTOS DE SOFTWARE 719
a un cost o ms baj o y, as se espera, mayor calidad. El t rabaj o de sof t war e llevado a
cabo dent ro de una compa a se reduce a una actividad de gest i n de cont rat os. 14
" Co mo r egl a, l a s ubc ont r a t a c i n r e qui e r e i n d u s o m s ges t i n e x p e r t a q u e el des ar r ol l o e n c a s a . "
St e v e Mc Ca n n e l l
La decisin de subcont rat ar puede ser estratgica o tctica. En el mbi t o est rat -
gico, los gest ores comerci al es consi deran si una porcin significativa de t odo el tra-
baj o de sof t war e se puede cont rat ar con otros. En el pl ano tctico, un gest or de pro-
yect o det ermi na si part e o t odo un proyect o puede lograrse mej or al subcont rat ar el
t rabaj o de soft ware.
Sin i mport ar la amplitud de la visin, la decisin de subcont rat ar usual ment e es
financiera. Una exposicin det al l ada del anl i si s financiero de la subcont rat aci n
est ms all del mbi t o de est e libro y mej or se deja a ot ros (por ej empl o, [MIN95]).
Sin embargo, vale la pena una breve revisin de los pros y cont ras de la decisin.
En el lado positivo, usual ment e es factible ahorrar en el cost o reduci endo el
nmer o de personal de soft ware y las i nst al aci ones (por ejemplo, comput ador as,
infraestructura) que los soport an. En el lado negativo, una compa a pi erde cierto
control sobre el sof t war e que necesita. Dado que el sof t war e es una tecnologa que
diferencia sus si st emas, servicios y productos, una compa a corre el riesgo de poner
el dest i no de su competitividad en las manos de una t ercera parte.
HOGARSEGURO
- S AI IP
Su bc o n t r a t a c i n
El e s c e n a r i o : Sala de juntas de
a c t o r e s : Mal Golden, gerente ejecutivo, desarrollo
producto; l ee Warren, gerente de ingeniera; Joe
VP ejecutivo, desarrollo comercial; Doug
. gerente de proyecto, ingeniera de software,
c o n v e r s a c i n :
Jo e : Estamos considerando subcontratar la porcin de
del software del producto Ho g a r Se g u r o .
( i m p r e s i o n a d o ) : Cundo sucedi esto?
Le e : Obtuvimos un presupuesto de un desarrollador
= tierno. Presupuesta un 30 por ciento por debajo de lo
que tu grupo parece creer que costar. Aqu. [Extiende el
presupuesto a Doug, quien lo lee.]
Ma l : Como sabes, Doug, estamos tratando de mantener
los costos bajos, y 30 por ciento es 30 por ciento.
Adems, estas personas vienen muy bien recomendadas.
D o u g ( t o m a u n r e s p i r o e i n t e n t a r e c u p e r a r l a
c a l m a ) : Me tomaron por sorpresa, pero antes de que
tomen una decisin final, algunos comentarios?
Jo e ( a s i e n t a c o n l a c a be z a ) : Seguro, adelante
D o u g: No hemos trabajado con esta empresa
subcontratista antes, cierto?
Ma l : Ci e r t o , p e r o ..
14 La subcontratacin se puede considerar, der r . ar e' s general, como cualquier actividad que con-
duce a la adquisicin de software o algunos de sus componentes con una fuente externa a la orga-
nizacin de ingeniera del software.
TM
PDF Editor
Doug: Y ellos anotan que cualquier cambio a las
especificaciones ser cobrado a una tasa adicional,
jcierto2
Jo e (f r u n c e e l e n t r e c e j o ) ; Cierto, pero esperamos
que las cosas sern razonablemente estables.
D o u g: Una mala suposicin, Joe.
Jo e ! B u e n o . . . . " 1 > 1 <
D o u g: Es probable que liberemos nuevas versiones de
este producto durante algunos aos. Y es razonable
suponer que el software proporcionar muchas de las
nuevas caractersticas, cierto?
[Todos afirman con la cabeza.]
Doug: Alguna vez hemos coordinado un proyecto
internacional?
Le e ( s e v e p r e o c u p a d o ) : No, pero me dijeron...
D o u g (i n t e n t a s u p r i m i r s u e n o j o ) : sf que lo que
me estft diciendo es: 1) estamos a punto de trabajar con
una empresa desconocida, 2) los costos para hacer esto
no son tan bajos cmo parecen, 3) de facto nos estamos
comprometiendo a trabajar con ellos durante muchas
liberaciones de producto, sin importar qu hagan en la
primera, y 4) aprenderemos en e) camino lo relativo a un
proyecto internacional.
[Todos guardan silencio.]
D o u g: Muchachos... creo qu"esto es un error, y me
gustara que tomaran un da para reconsiderar.
Tendremos ms control si hacemos el trabajo en casa.
Tenemos la experiencia y puedo garantizar que no nos
costar mucho ms... el riesgo ser ms bajo y yo s que
todos tienen aversin por el riesgo, como yo.
Jo e ( c e u d o ) : Has anotado buenos puntos, pero t
tienes un inters personal en mantener este proyecto en
CaSa, \ ';f i.:;: '
D o u g: Es cierto, pero eso no cambia los hechos.
Jo e (c o n u n s u s p i r o ) : Muy bien, pospongamos esto
un da o dos, pensemos en ello un poco ms y
reunmonos de nuevo para una decisin final. Doug,
puedo hablar contigo en privado?
D o u g: Claro... Realmente quiero estar seguro de que
hacemos las cosas correctas.
2 3 . 1 1 RESUMEN 2 ?I
El planificador del proyecto de soft ware debe estimar tres factores ant es de que un
proyecto comience: cunt o tiempo tomar, cunt o esfuerzo requerir y cunt o pe:
sonal estar involucrado. Adems, el planificador debe predecir los recursos (har:
ware y software) que se requerirn y el riesgo involucrado.
La descripcin del mbito ayuda al planificador a desarrollar estimaciones emplear -
do una o ms tcnicas que se clasifican en dos amplias categoras: descomposicicn
y model ado emprico.
Las tcnicas de descomposicin requieren un bosquejo de las principales funci:
nes del software, seguido por estimaciones de 1) el nmero de LDC, 2) valores selec-
cionados dentro del dominio de informacin, 3) el nmero de casos de uso, 4) el
nmero de personas-mes requerido para implementar cada funcin, o 5) el nmer:
de personas-mes requerido para cada actividad de ingeniera del software. Las tc-
nicas empricas usan expresiones para esfuerzo y tiempo obtenidas empricamen:;
para predecir est as cantidades del proyecto. Se pueden utilizar herrami ent as a u t o
matizadas para implementar un modelo emprico especfico.
Por lo general, las estimaciones precisas de proyecto emplean al menos dos de
las tres tcnicas anotadas. Al comparar y reconciliar las estimaciones obtenidas cor
la aplicacin de diferentes tcnicas, el planificador tiene ms probabilidad de calcu-
TM
PDF Editor
721
lar una estimacin precisa. La estimacin del proyecto de soft ware nunca ser una
ciencia exacta, pero una combinacin de buenos datos histricos y tcnicas siste-
mt i cas puede mejorar la precisin de la estimacin.
REFERENCI AS
[BEN92] Bennatan, E. M., s o f t w a r e P r o j e c t M a n a g e m e n t : A P r a c t i o n e r ' s A p p r o a c h, McGraw-Hill,
1992.
[BEN03] Bennat an, E. M "So What is t he State of Soft ware Estimation?" en The Cu t t e r Ed g e (hoja
informativa en lnea), 11 de febrero de 2002, disponible en ht t p: / / www. cut t er . com.
[BOE81] Boehm, B., So f t w a r e En g i n e e r i n g Ec o n o m i c s , Prentice-Hall, 1981.
[BOE89] Boehm, B., R i s k M a n a g e m e n t , IEEE Comput er Society Press, 1989.
1BOE96J Boehm, B., "Anchoring the Soft ware Process", en I EEE So f t w a r e , vol. 13, nm. 4, julio
de 1996, pp. 73-82.
[BOEOO] Boehm, B. e t a l . , So f t w a r e Co s t Es t i m a t i o n i n COCOM O I I , Prentice-Hall, 2000.
[BR0751 Brooks, F The M y t hi c a l M a n - M o n t h, Addison-Wesley, 1975.
[GAU89I Gause, D. C. y G. M. Weinberg, Ex p l o r i n g R e q u i r e m e n t s : Qu a l i t y B e f o r e De s i g n , Dorset
House, 1989.
| H00911 Hooper, J. y R. O. Chester, So f t w a r e R e u s e Gu i d e l i n e s a n d M e t ho d s , Plenum Press, 1991.
[JON96] Jones, C., "How Soft ware Estimation Tools Work", e n A m e r i c a n P r o g r a m m e r , vol. 9, nm.
7, julio de 1996, pp. 19-27.
[LOR94] Lorenz, M. y j . Kidd, Obj e c t - Or i e n t e d So f t w a r e M e t r i c s , Prentice-Hall, 1994.
[MAT94] Mat son, J., B. Barrett y J. Mellichamp, "Soft ware Development Cost Estimation Using
Function Points", en I EEE Tr a n s . So f t w a r e En g i n e e r i n g , vol. SE-20, nm. 4, abril de 1994, pp.
275-287.
[MCC98] McConnell, S So f t w a r e P r o j e c t Su r vi va ! Gu i d e , Microsoft Press, 1998.
[MEN01] Mendes, E., N. Mosley y S. Counsell, "Web Metrics-Estimating Design and Authoring
Effort", I EEE M u l t i m e d i a , ener o- mar zo de 2001, pp. 50-57.
[MIN95] Minoli, D. , A n a f y z i n g Ou t s o u r c i n g , McGraw-Hill, 1995.
[PHI98] Phillips, D The So f t w a r e P r o j e c t M a n a g e r ' s Ha n d bo o k, IEEE Comput er Society Press,
1998.
[PUT78] Putnam, L., "A General Empirical Solution to the Macro Soft ware Sizing and Estimation
Problem", en I EEE Tr a n s . So f t w a r e En g i n e e r i n g , vol. SE-4, nm. 4, julio de 1978, pp. 345-361.
[PUT92] Put nam, L. y W. Myers, M e a s u r e s f o r Ex c e l l e n c e , Yourdon Press, 1992.
[PUT97a] Put nam, L. y W. Myers, "How Solved Is the Cost Estimation Problem?", en I EEE
So f t w a r e , novi embre de 1997, pp. 105-107.
[PUT97b] Putnam, L. y W. Myers, I n d u s t r i a l St r e n g t h So f t w a r e : Ef f e c t i ve M a n a g e m e n t U s i n g
M e a s u r e m e n t , en IEEE Comput er Society Press, 1997.
[ROEOO] Roetzheim, W., "Estimating Internet Development", en So f t w a r e De ve l o p m e n t , agost o de
2000, disponible en ht t p: / / www. sdmagazi ne. com/ document s/ s=741/ sdm0008d/ 0008d. ht m.
SMI99] Smi t h, ). , "The Estimation of Effort Based on Use Cases", Rational Soft ware Corp., 1999,
se puede descargar de ht t p: / / www rat i onal . com/ medi a/ whi t epapers/ fi nal TP171. PDF.
PROBLEMAS Y PUNTOS A CP NS I P ERAR ,
23. 1. Suponga que es el gestor de proyect o de una compa a que const ruye sof t war e par a
robot s caseros. Se le ha cont rat ado par a construir el soft ware dest i nado a un robot que corta el
past o. Describa por escrito el mbi t o del soft ware. Asegrese de que la descripcin del mbi t o
est acot ada. Si no est familiarizado con los robots, investigue un poco ant es de comenzar a
escribir. Adems, est abl ezca s us suposi ci ones acer ca del har dwar e que se requeri r.
Alternativa: sustituya el robot que cort a el past o por ot ro probl ema robtico que le interese.
2 3 . 2 . La compl ej i dad del proyecto de sof t war e influye en la precisin de la est i maci n.
Desarrollar una lista de caractersticas de soft ware <jr ejemplo, operaci n concurrent e, salida
grfica) que afect en la complejidad de un pr ovee: : l >: arecer prioridades en la lista.
TM
PDF Editor
2 3 . 3 . El des empeo es una consi deraci n i mpor t ant e dur ant e la planificacin. Coment ar c
se puede i nt erpret ar de maner a di ferent e el des empeo, dependi endo del r ea de apl i caci n
soft ware.
2 3 . 4 . Haga una descomposi ci n funci onal del s of t war e robt i co que descri bi en el probl
23.1. Est i me el t a ma o de cada funci n en LDC. Suponga que su organi zaci n pr oduce
LDC/ pm con una escal a salarial de 7 000 dl ar es por per s ona- mes . Est i me el es f uer zo y c
r equer i dos para const rui r el s of t war e empl eando la tcnica de est i maci n bas ada en LDC
crita en est e cap t ul o.
2 3 . 5 . Emplear el model o COCOMO II en la est i maci n del esf uer zo que requiere la const ru
del s of t war e para una si mple ATM que pr oduce 12 pant al l as, 10 report es y requerir aproxi m
ment e 80 component es de soft ware. Suponer compl ej i dad pr omedi o y madur ez desarrol '
ent or no promedi o. Empl ear el model o de composi ci n de aplicacin con punt os obj et o.
2 3 . 6 . Utilizar la ecuaci n del s of t war e par a est i mar el s of t war e del robot que cort a past o
pr obl ema 23.1. Suponer que las ecuaci ones (23-5) s on apl i cabl es y que P = 8000.
2 3 . 7 . Compar ar las est i maci ones de es f uer zo obt eni das en l os pr obl emas 23.4 y 23.6. Cul es
la desvi aci n es t ndar y cmo afect a el gr ado de cer t i dumbr e acerca de la est i maci n?
2 3 . 8 . Utilizar los r esul t ados obt eni dos en el pr obl ema 23. 7 par a det er mi nar si es r azonar
esper ar que el s of t war e se const r uya dent r o de l os si gui ent es sei s me s e s y cunt o personal e
tendra que empl ear para real i zar el t rabaj o.
2 3 . 9 . Desarrollar un model o de hoj as de cl cul o que i mpl ement e una o m s de l as t cni cas
est i maci n descri t as en est e capi t ul o. Al t ernat i vament e, adqui ri r de f uent es bas adas en v. e:
uno o m s model os en lnea para la est i maci n de proyect os de sof t war e.
2 3 . 1 0 . Para un equi po de proyecto, desarrol l ar una her r ami ent a de s of t war e que i mpl emer. i
cada una de las t cni cas de est i maci n desar r ol l adas en est e cap t ul o.
2 3 . 1 1 . Parece ext r ao que las est i maci ones de cost o y pr ogr ama de t r abaj o se desarrol l e-
dur ant e la pl ani fi caci n del proyect o de soft ware, ant es de que se haya l l evado a cabo un dise-
o o un anl i si s det al l ado de los requi si t os de sof t war e. Por qu cr ee que se haga est o? Existe-
ci r cunst anci as en las cual es no se deba hacer ?
2 3 . 1 2 . Vuelva a cal cul ar l os val or es anot ados par a el rbol de deci si n en la figura 23 :
Suponga que cada r ama t i ene una probabi l i dad de 50-50. Esto cambi ar a su deci si n final?
La mayor a de los libros de gestin de proyect os de s of t war e incluyen anl i si s de la est i mac cr
de proyect os. El Project Management Institute (P M B OK Gu i d e , PMI, 2001), Wysoki y s us colegas
(. Ef f e c t i ve P r o j e c t M a n a g e m e n t , Wiley, 2000), Lewis (P r o j e c t P l a n n i n g Sc he d u l i n g a n d Co n t r o l , ter-
cera edicin, McGraw-Hill, 2000), Bennatan (On Ti m e , Wi t hi n B u d g e t : So f t w a r e P r o /e ":
M a n a g e m e n t P r a c t i c e s a n d Te c hn i q u e s , t ercera edicin, Wiley, 2000) y Phillips [PHI98] ofrecen u:
les di rect ri ces de est i maci n.
Jones (ESt i m a t i n g So f t w a r e Co s t s , McGraw-Hill, 1998) ha escri t o uno de los t r at ami ent os mas
compl et os de la mat er i a publ i cados a la f echa. Su libro cont i ene model os y dat os apl i cabl es a
est i maci ones de s of t war e en cual qui er domi ni o de aplicacin. Coombs (I T P r o j e c t Es t i m a t i c -
Cambri dge University Press, 2002), Roet zhei m y Beasl ey ( So f t w a r e P r o j e c t Co s t a n d Sc he d u *
Es t i m a t i n g : B e s t P r a c t i c e s , Prentice-Hall, 1997) y Wellman (So f t w a r e Co s t i n g , Prentice-Hall, 1992
pr esent an muchos model os tiles y sugi eren directrices pas o a pas o para gener ar las mej ores
est i maci ones posibles.
El det al l ado t r at ami ent o de Put nam y Myers de la est i maci n de cost o del s of t war e ([PUT91
y [PUT97b]) y los libros de Boehm acer ca de econom a de i ngeni er a del s of t war e ([BOE811 y
COCOMO II [BOEOO]) descr i ben model os de est i maci n emp ri cos. Estos libros pr opor ci onan un
anl i si s det al l ado de dat os deri vados de ci ent os de proyect os de sof t war e. Un libro excel ent e de
TM
PDF Editor
C A P T U L O 2 3 ESTIMACIN PARA PRO YE ~ O S DE SOFTWARE
723
DeMarco (Co n t r o l l i n g So f t w a r e P r o j e c t s , Yourdon Press, 1982) ofrece un valiosa visin de gestin,
medicin y est i maci n de proyect os de soft ware. Lorenz y Kidd (Obj e c t - Or i e n t e d So f t w a r e
M e t r i c s , Prentice-Hall, 1994) y Cockbum (Su r vhi n g Obj e c t - Or i e n t e d P r o j e c t s , Addison-Wesley,
1998) consi deran la est i maci n para si st emas ori ent ados a objetos.
En Internet hay disponible una ampl i a variedad de f uent es de i nformaci n acerca de esti-
maci n de soft ware. Una lista act ual i zada de referenci as en la World Wide Web se encuent ra en
el sitio Web de SEPA:
ht t p : / / w w w . m hhe . c o m / p r e s s m a n .
TM
PDF Editor
C A P I T U L O
24
C O N C E P T O S
CL AVE
anfisis
del t rabaj o . . . . 7 3 7
cr onogr amas . . . 738
curvoPNR . . . . 7 3 0
demora 725
distribucin de
esf uer zo . . . . . 732
personal y
esf uer zo 7 2 9
principios
bsicos 7 2 8
red de t ar eas . . 735
refinamiento de
t or eas 734
seguimiento . . . 7 3 9
t i m e - bo x i n g . . .740
a do . 7 4 2
CALENDARI ZACI N
DE PROYECTOS DE SOFTWARE
A
fnales de los de los aos 60, un joven y brillante ingeniero fue elegidc
para "escribir" un pr ogr ama de comput ador a para una aplicacin indus
trial aut omat i zada. La razn por la cual se le eligi fue simple: era la n:
ca persona en el grupo tcriico que haba asistido a un semi nari o de programa
cin de comput adoras. l conoc a las ent r adas y salidas del l enguaj e ensambl a
dor y de FORTRAN, pero nada acerca de ingeniera del soft ware, e incluso me
nos acerca de cal endari zaci n y segui mi ent o de proyectos.
Su jefe le dio los manual es apropi ados y una descripcin verbal de lo que te
na que hacer. Se le i nform que el proyect o deb a t ermi narse en dos meses.
El ingeniero ley los manual es, consi der su enf oque y comenz a escribir e
cdigo. Despus de dos semanas, el jefe lo llam a su oficina y le pregunt c
mo iban l as COSaS. - : '
"Real ment e bien", dijo el joven ingeniero con ent usi asmo juvenil. "Esto fu-
mucho m s simple de lo que pens. Probabl ement e he t ermi nado cerca del 7;
por ciento. "
El j efe sonri y al ent al joven i ngeni ero a seguir t rabaj ando bien. Planeare-
reuni rse de nuevo en una s emana.
Una s emana despus, el jefe llam al ingeniero a su oficina y le pr egunu
"Dnde est amos?".
' Todo marcha bien", dijo el joven, "pero me he encont rado con al gunos pequr
os obstculos. Los solucionar y regresar al ritmo de t rabaj o muy pronto."
"Cmo ves la fecha lmite?", pr egunt el jefe.
Q u e s ? Usted seleccion un
modelo de proceso apropiado; ic
tfic las tareas de ingeniera del
software que es preciso realizar;
estim la cantidad de trabajo y el
nmero de personas; conoce la fecha lmite;
incluso consider los riesgos. Ahora es tiempo
de unir los puntos. Esto es, tiene que crear una
red de tareas de ingeniera del software que le
permitirn tener el trabajo sto a tiempo. Una
vez creada la red, tiene que asignar responsa-
bilidades a cada tarea, asegurarse de que se
realice y adaptar la red conforme los riesgos se
vuelvan realidad. En resumen, esto es la calen-
darizacin y el seguimiento del proyecto de
software.
Q u i n l o ha c e ? En el mbito del proyecto los
gestores del proyecto de software emplean la
informacin solicitada a los ingenieros de soft-
ware. En el plano individual, los mismos inge-
nieros de software
Po r q u e s i m p o r t a n t e ? En la construccin
de un sistema complejo muchas tareas de inge-
niera del software ocurren en paralelo, y el
resultado del trabajo realizado durante una
tarea puede tener un profundo efecto en el tra-
bajo llevado a cabo en otra tarea. Estas inter-
dependencias son muy difciles de comprender
sin una calendarizacin. Tambin es virtual-
mente imposible evaluar el progreso de un pro-
yecto de software moderado y grande sin una
calendarizacin detallada.
724
TM
PDF Editor
C A P T U L O 2 4 CALENDAREACI N DE PROYECTOS DE SOFTWARE
725
Cu l e s s o n l o s p a s o s ? Las Jareas de inge-
niera del software que dicta el modelo de pro-
ceso de software se refinan para la funcionali-
dad que se construir. A cada tarea se le asig-
nan esfuerzo y duracin, y se crea una red de
tareas (tambin llamada una "red de activi-
dad") de tal forma que permita al equipo de
software cumplir con la fecha lmite de entrega
establecida.
..Cu l e s e l p r o d u c t o o bt e n i d o ? La calendari-
zactn del proyecto y la informacin relacionada.
Cm o m e p u e d o a s e gu r a r q u e l o he
he c ho c o r r e c t a m e n t e ? La calendariza-
cin adecuada requiere que 1} todas las tareas
aparezcan en la red, 2) el esfuerzo y el tiempo
estn asignados de manera inteligente en cada
tarea, 3) las interdependencias entre tareas
estn indicadas adecuadamente, 4 ) los recursos
estn asignados para el trabajo que se realiza-
ra y 5) los Hitos estn espaciados de modo cer-
cano para que se pueda seguir el progreso.
"No hay problema", dijo el ingeniero. "Estoy cerca de t ermi nar el 90 por ciento."
Si se ha t rabaj ado en el mundo del sof t war e durant e unos cuant os aos se es ca-
paz de t ermi nar la historia. No ser sorpresa que el joven ingeniero1 haya per mane-
cido en el 90 por ci ent o dur ant e t odo el proyect o y t ermi nado (con la ayuda de otros)
un mes despus.
Esta historia se ha repetido decenas de miles de veces con desarrol l adores de
sof t war e dur ant e las pas adas cuat ro dcadas. La gran pregunt a es por qu.
2 4 . 1 C ONC E P T OS BSI COS
Aunque existen muchas r azones por las cual es el sof t war e s e ent rega con retraso, la
mayora se encuadr a en una o ms de las si gui ent es causas:
Una fecha lmite irrealizable establecida por alguien ext erno al grupo de inge-
niera del sof t war e e i mpuest a a los gest ores y profesi onal es del grupo.
Cambi o en los requisitos del cliente que no se reflejan en modi fi caci ones a la
cal endari zaci n.
Una subest i maci n razonabl e de la cant i dad de esf uer zo o de recursos que se
requerirn para realizar el t rabaj o.
Riesgos predecibles o impredecibles que no se consi deraron cuando comenz
el proyecto.
Dificultades t cni cas que no pudi eron preverse.
Dificultades humanas imprevisibles.
Falta de comuni caci n ent re el personal del proyecto, lo que genera demoras.
Una falla en la gestin del proyect o porque no reconoci el ret raso ni empr en-
di una accin para corregir el probl ema
1 En caso de que el lector se lo pregunte la histona es autobiogrfica.
TM
PDF Editor
"Los cal endor i zaci ones excesi vas o i rraci onal es pr obabl ement e son la f ue r z a part i cul ar ms dest ruct i va en t odo el
s of t war e. "
Ca p e r s Jo n e s
Las fechas lmite muy audaces (lase "irrealizables") son un hecho de la vida en e
negoci o del soft ware. En tales ocasi ones las fechas lmite se demandan por razones
legtimas, desde el punt o de vista de la persona que las est abl ece. Pero el sent i do co-
mn est abl ece que la legitimidad t ambi n la deben advertir las per sonas que hacer,
el trabajo.
Napolen dijo al guna vez: "Cualquier comandant e en jefe que pret enda llevar a
cabo un plan que consi dera defect uoso comet e un error; debe exponer sus razones
insistir en que el plan debe cambi arse y finalmente pr esent ar su renunci a en luga:
de ser el i nst rument o de la dest rucci n de su ejrcito". Estas son pal abras fuert es que
muchos gest ores de proyect os de sof t war e deben considerar.
Las actividades de est i maci n est udi adas en el captulo 23 y las t cni cas de calen
darizacin descri t as en st e con frecuenci a se i mpl ement an at endi endo la restric-
cin de una fecha lmite definida. Si las mej or es est i maci ones indican que la f ech;
lmite es irrealizable, un gest or de proyect o compet ent e debe "proteger a su equi po
de la presi n excesiva [de la calendarizacin]. . . [y] devolver la presi n a qui enes i3
originan" [PAG85].
Para ilustrarlo, supngase que a un equi po de ingeniera del sof t war e se le ha pe-
dido construir un cont rol ador en t i empo real para un i nst rument o de diagnstico
mdi co que ser introducido al mer cado en nueve meses. Despus de una estima-
cin y un anlisis de riesgo cui dadosos (captulo 25), el gest or del proyect o llega a la
conclusin de que el soft ware, como se solicit, requerir 14 mes es para crearlo cor
el personal disponible. Cmo procede el gestor del proyecto?
"Adoro l as f echas l i mi t e. Me gust o que pas an como una exhal aci n cuando s e al ej an. "
D o u gl a s Ad a m s
Es irreal pr esent ar se en la oficina del cliente (en est e caso el probabl e cliente es
mercadot ecni a-vent as) y demandar l e que cambi e la fecha de ent rega. Las presi ones
ext ernas del mer cado han dictado la fecha, y el product o debe liberarse. Es igual-
ment e t orpe r echazar el t rabaj o (desde el punt o de vista profesional). As que, que
hacer? En esta situacin se recomi endan los si gui ent es pasos:
1. Realizar una est i maci n det al l ada empl eando dat os histricos de proyectos
previos. Determinar el esf uer zo y la duraci n est i mados para el proyecto.
2. Aplicar un model o de proceso i ncrement al (captulo 3) y desarrollar una estra-
tegia de ingeniera de sof t war e que ent regar la funci onal i dad crtica en la fe-
cha lmite i mpuest a, per o demor ar otra. Document e el plan.
TM
PDF Editor
C A P T U L O 2 4 CALENDAREACI N DE PROYECTOS DE SOFTWARE 727
3. Reunirse con el cliente y, con la est i maci n detallada, explicarle por qu la fe-
cha lmite i mpuest a es irrealizable. Asegrese de seal ar que t odas las est i ma-
ci ones est n bas adas sobre el des empeo en proyectos previos. Tambin
asegrese de indicar el porcent aj e de mej or a que se requerira para lograr la fe-
cha lmite vigente.2 Son apropi ados los si gui ent es coment ari os:
"Creo que podemos t ener un probl ema con la fecha de ent rega para el soft wa-
re cont rol ador XYZ. Le he dado a cada uno de ust edes un anlisis abrevi ado de
las t asas de producci n en proyectos previos y una est i maci n que hemos he-
cho en al gunas formas diferentes. Not arn que he supuest o un 20 por ci ent o de
mej ora respect o de ri t mos de producci n precedent es, pero t odav a t enemos
una fecha de ent rega que est a 14 mes es en lugar de 9."
4. Ofrezca la estrategia de desarrol l o i ncrement al como alternativa:
"Tenemos unas cuant as opci ones y me gustara que t omase una decisin con
bas e en ellas. Primero, podemos aument ar el pr esupuest o y consegui r recur-
sos adi ci onal es de modo que t endr emos mucho xito en lograr que est e t raba-
jo est hecho en nueve meses. Pero compr enda que est o aument ar el riesgo
de una calidad deficiente debi do a la apr et ada fecha lmite.3 Segundo, podemos
remover varias de las funci ones y capaci dades de sof t war e que est solicitan-
do. Esto har que la versin preliminar del product o sea un poco menos fun-
cional, pero podemos anunci ar t oda la funcionalidad y luego entregarla en el
peri odo de 14 meses. Tercero, podemos prescindir de la realidad y esperar que
el proyect o se compl et e en nueve meses. Termi naremos con nada que se pue-
da ent regar a un cliente. La tercera opcin, esper o que est de acuerdo, es ina-
ceptable. La historia y nuest r as mej or es est i maci ones indican que es irreal y un
bol et o hacia el desast re. "
Habr al gunos gruidos, per o si se pr esent an est i maci ones slidas bas adas en
buenos dat os histricos es probable que se elegirn versi ones negoci adas de las op-
ci ones 1 o 2. La fecha lmite irreal se evapora.
A Fred Brooks, el bien conoci do aut or de The M y t hi c a l M a n - M o n t h [BR095], se le pre-
gunt una vez cmo se ret rasaban los proyect os de sof t war e en la cal endari zaci n.
Su respuest a fue tan simple como profunda: "Un da a la vez."
2 Si la mejora requerida es de 10 a 25 por ciento de hecho tal vez sea posible tener listo el trabajo.
Pero, con mayor probabilidad, la mejora requerida en el desempeo del equipo ser mayor que el
50 por ciento. Esta es una expectativa irreal
3 Tambin puede agregar que el aumento en t rumero de personas no reduce proporcionalmente
el tiempo.
Q u s e
d e be ha c e r
s o n d o l a ge s t i n
Ma n d a q u e s e
p a c o n u n a
h a l i m i t e q u e
i m p o s i bl e ?
TM
PDF Editor
^ O N S E J O ^ ^
l a s t o r e o s r e q u e r i d o s
p a r o l o g r a r e l o bj e t i vo
d e u n a g e s t i n d e
p r o y e c t o n o s e d e be n
l l e va r o c a bo m a n u a l -
m e n t e . Cx i s t e n
m u c ha s e x c e l e n t e s
he r r a m i e n t a s d e
c a l e n d a r i z a c i n .
s e l o s .
La realidad de un proyect o t cni co (ya sea que involucre la const rucci n de una
pl ant a hidroelctrica o el desarrol l o de un si st ema operativo) es que ci ent os de pe-
queas t ar eas deben realizarse para lograr una met a mayor. Algunas de tales tareas
est n fuera de la corriente principal y se pueden compl et ar sin pr eocupar se acerca
de su i mpact o sobre la fecha de t ermi naci n del proyecto. Otras t areas se encuen-
tran en la "trayectoria critica". Si est as t ar eas "criticas" se ret rasan en la calendari-
zacin, la fecha de t ermi naci n del proyect o se pone en riesgo.
El objetivo del gestor es definir t odas las t areas del proyecto, construir una red que
bosquej e sus interdependencias, identificar las t areas cruciales dent ro de la red y lue-
go seguir su progreso para garant i zar que la demor a se reconoce "un da a la vez"
Para lograrlo el gestor debe t ener una calendarizacin que se haya definido en un
grado de resolucin que permi t a supervisar el progreso y controlar el proyecto.
La c a l e n d a r i z a c i n d e l p r o y e c t o d e s o f t w a r e es una actividad que distribuye estima-
ci ones de esf uer zo a t ravs de la duraci n planificada del proyect o al asi gnar el es-
fuerzo a t ar eas especficas de ingeniera del soft ware. Sin embar go, es importante
seal ar que la cal endari zaci n evol uci ona a lo largo del tiempo. Durant e las prime
ras et apas de la planificacin del proyect o se desarrolla una cal endari zaci n macros-
cpica. Este tipo de cal endari zaci n identifica las principales act i vi dades del marco
de t rabaj o del proceso y las f unci ones de product o a las que se aplican. Conforme e;
proyect o transcurre, cada ent rada en la cal endari zaci n macroscpi ca se refina er
una cal endari zaci n detallada. Aqu se identifican y cal endari zan t ar eas especficas
del sof t war e (requeridas para compl et ar una actividad).
" Una c a l e nda r i z a c i n d e ma s i a d o opt i mi s t a no g e n e r a una c a l e nda r i z a c i n r e a l m s c or t a , s i no u n a ma y o r . "
Sl e v e Mt Co n n e l l
La calendarizacin para proyectos de ingeniera de soft ware se puede ver desde dos
perspectivas ms bien diferentes. En la primera ya se ha establecido (irrevocablemente)
una fecha final para la liberacin de un sistema basado en comput adora. La organiza-
cin de software est restringida a distribuir esfuerzo dentro del marco temporal pres-
crito. La segunda visin de la calendarizacin de software supone que se han comentado
lmites cronolgicos aproximados, pero que la fecha final la establece la organizacin
de ingeniera del software. El esfuerzo se distribuye para utilizar mejor los recursos y la
fecha final se define despus de un anlisis cuidadoso del software. Por desgracia, la pri-
mera situacin se encuent ra con mucha ms frecuencia que la segunda.
24.2.1 Principios bsicos
Al igual que ot ras r eas de ingeniera del soft ware, vari os principios bsi cos guan la
cal endari zaci n de los proyectos:
Co m p a r t i m e n t a c i n . El proyect o debe dividirse en compar t i ment os en varias acti-
vi dades, acci ones y t ar eas manej abl es. Lograrlo requi ere decomponer t ant o el pro-
duct o como el proceso.
TM
PDF Editor
C A P T U L O 2 4 CALENDAREACIN DE PROVECTOS TE SOFTWARE 729
iVE
! desorrolle
izocin,
r t e s e el
f l t e n s e los
d os d e
6 , as gnens e
i y t i empo o
, def nonse
ahi t os .
I n t e r d e p e n d e n c i a . Se debe determinar la interdependencia de cada actividad, ac-
cin o tarea compartimentada. Algunas t areas deben ocurrir en secuencia mientras
que otras pueden ocurrir en paralelo. Algunas acciones o actividades no pueden co-
menzar mientras no est disponible el producto de trabajo producido por otros.
Otras acciones o actividades pueden ocurrir de manera independiente.
A s i g n a c i n d e t i e m p o . A cada tarea por calendarizar se le debe asignar cierto n-
mero de unidades de trabajo (por ejemplo, personas-da de esfuerzo). Adems, a ca-
da tarea se le debe asignar una fecha de inicio y una otra de terminacin que sean
funcin de las interdependencias, y ya sea que el t rabaj o sea realizado con base en
tiempo completo o parcial.
Va l i d a c i n d e l e s j u e r z o . Todo proyecto tiene un nmero definido de personas en el
equipo de software. Conforme ocurre la asignacin de tiempo, el gestor de proyecto
debe asegurarse de que, en un tiempo dado, no se han asignado ms que el nme-
ro de personas calendarizadas. Por ejemplo, considere un proyecto que tiene tres in-
genieros de soft ware asignados (por ejemplo, tres personas-da estn disponibles
por da de esfuerzo asignado).4 En un da dado se deben completar siete tareas al
mi smo tiempo. Cada tarea requiere 0.50 personas-da de esfuerzo. Se ha asignado
ms esfuerzo que el nmero de personas para hacer el trabajo.
De f i n i c i n d e r e s p o n s a bi l i d a d e s . Toda tarea caiendarizada se le debe asignar a un
miembro especfico del equipo.
De f i n i c i n d e r e s u l t a d o s . Toda tarea caiendarizada debe tener un resultado defini-
do. En proyectos de software el resultado normal ment e es un producto de trabajo
(por ejemplo, el diseo de un mdulo) o una parte de l. Los productos de trabajo
usualmente se combinan en los entregables.
De f i n i c i n d e hi t o s . Cualquier tarea o grupo de t areas debe estar asociado con un
hito del proyecto. Un hito se logra cuando se ha revisado la calidad de uno o ms
productos de trabajo (captulo 26) y se han aprobado.
Cada uno de est os principios se aplica conforme evoluciona la calendarizacin del
proyecto.
24.2.2 Relacin entre el personal y el esfuerzo
En un pequeo proyecto de desarrollo de soft ware una sola persona puede analizar
los requisitos, realizar el diseo, generar el cdigo y dirigir las pruebas. Conforme
aument a el t amao de un proyecto, ms gente resulta involucrada. (Rara vez se
puede dar el lujo de acometer un esfuerzo de 10 personas-ao con una persona que
trabaje durante 10 aos!)
4 En realidad, hay disponibles menos de tres personas-dia de esfuerzo debido a las reuniones no re-
lacionadas, enfermedades, vacaciones y una diversidad de otras razones. Sin embargo, para los pro-
psitos del texto, se supone una disponibilidad de X por ciento
TM
PDF Editor
ÔNSEJ c f f i .
Si s e d e be n a g r e g a r
p e r s o n a s o u n
p r o y e c t o r e bo s a d o ,
a s e g r e s e d e q u e s e
l e s ha a s i g n a d o
t r a ba j o e n o r m e m e n t e
c o m p a r l i m e n t a d o .
Existe un mito comn que todava creen muchos gestores responsables del es-
fuerzo de desarrollo del software: "Si nos ret rasamos en la calendarizacin, siempre
podemos incorporar ms programadores y recuperarnos ms adelante en el proyec-
to". Desgraciadamente, agregar ms personas en et apas tardas de un proyecto con
frecuencia tiene un efecto perturbador sobre ste, lo que provoca que la calendar
zacin se desfase an ms. Las personas que se agregan deben aprender el sistema
y la gente que les ensea es la misma que estaba haciendo el trabajo. Durante la en-
seanza no se realiza trabajo y el proyecto experimenta mayores retrasos.
Adems del tiempo que tarda en aprender el sistema, ms personal aument a e
nmero de rutas de comunicacin y la complejidad de sta a lo largo de un proyec-
to. Aunque la comunicacin es absolutamente esencial para el xito del des ar r ol :
de software, cada nueva ruta de comunicacin requiere un esfuerzo adicional y, pee
lo tanto, tiempo suplementario.
A lo largo de los aos, los dat os empricos y el anlisis terico han demost rac:
que las calendarizaciones de proyecto son elsticas. Es decir, es posible comprim -
en cierta medida la fecha de terminacin deseada del proyecto (al aadir recursos,
adicionales). Tambin es posible extender la fecha de terminacin (al reducir el nu
mero de recursos).
La Cu r va P u t n a m - No r d e n - R a y l e i g h (P NR ) 5 proporciona un indicio de la relacin er-
tre el esfuerzo aplicado y el tiempo de entrega para un proyecto de software. En =
figura 24.1 se muestra una versin de la curva, que representa el esfuerzo del pro-
yecto como funcin del tiempo de entrega. La curva indica un valor mnimo, que
indica el tiempo de entrega de menor costo (es decir, el tiempo de entrega que ge-
nerar el menor gasto de esfuerzo). Conforme se mueve a la izquierda de t 0 (es de
cir, conforme intenta acelerar la entrega), la curva se eleva en forma no lineal.
Re l a c i n e n t r e e s u e r zo y t i e m p o d e e n t r e ga .
Co s t o
d e
e s f u e r z o
' o
Ti e m p o d e d e s a r r o l l o
Tmi - 0. 75Td
5 En [NQR70] y [PUT78) se puede encontrar investigacin original.
TM
PDF Editor
C A P T U L O 2 4 CALENDAMZACIN DE PROYECTOS DE SOFTWARE
731
\
C L AVE
o ent r ego puede
orse, la curvo
' indica q u e los
del proyect o s e
reducir
i al ment e.
(CONSEJO^.
l a l e c ha
l p r o y e c t o s e
c o d o ve z m s ,
x o n z a u n p u n t o
i q u e e l t r a ba j o
x e d e c o m p l e t a r s e
e l c a l e n d a r i o ,
n p o r t a r e l
; d e p e r s o n a s
l o g a n e l t r a ba j o ,
l o r e o l i d o d
u n a n u e vo
d e e n t r e g a .
Como ejemplo, supngase que un equipo de proyecto ha est i mado un nivel de es-
fuerzo E a que se requerir para lograr un tiempo de entrega nominal, t d , que es p-
timo en trminos de calendarizacin y recursos disponibles. Aunque es posible ace-
lerar la entrega, la curva se eleva muy pronunci adament e hacia la izquierda de t d . De
hecho, la curva PNR indica que el tiempo de entrega del proyecto no se puede com-
primir ms all de 0.75 t d . Si se intenta una mayor compresin, el proyecto se mue-
ve hacia "la regin imposible" y el riesgo de fracaso se eleva mucho. La curva PNR
tambin indica que la opcin de entrega de menor costo, t = 2 t d . La implicacin aqu
es que la demora en la entrega del proyecto puede reducir los costos significativa-
ment e. Desde luego, est o debe sopesarse frente al costo del negocio asoci ado con la
demora.
La ecuacin del soft ware [PUT92], introducida en el captulo 23, se obtiene de la
curva PNR y demuest ra la relacin enor mement e lineal entre el tiempo cronolgico
para completar un proyecto y el esfuerzo humano aplicado a ste. El nmero de l-
neas de cdigo ent regadas (enunciados fuente), L, se relaciona con el esfuerzo y el
tiempo de desarrollo medi ant e la ecuacin:
L = P x E W 3 t A / i
donde E es el esfuerzo de desarrollo en personas-mes; P, un parmet ro de producti-
vidad que refleja una diversidad de factores que conducen a trabajo de ingeniera del
soft ware de alta calidad (los valores tpicos de P varan ent re 2 000 y 12 000); y t , la
duracin del proyecto en meses calendario.
Al reordenar esta ecuacin del soft ware se puede llegar a una expresin para el
esfuerzo de desarrollo E:
E = LV( PJ f ) (24-1)
donde E es el esfuerzo utilizado (en personas-ao) durant e el ciclo de vida para el
desarrollo y mant eni mi ent o de software, y f es el tiempo de desarrollo en aos. La
ecuacin para el esfuerzo de desarrollo se puede relacionar con el costo del desarro-
llo al incluir un factor de escala salarial (cost o/ persona-ao).
Esto conduce a unos resultados i nt eresant es. Considrese un compl ej o proyect o
de soft ware de tiempo real est i mado en 33 000 LDC, 12 personas-ao de esfuerzo.
Si se asi gnan ocho personas al equipo del proyecto, ste se puede completar en
aproxi madament e 1.3 aos. Sin embargo, si se extiende la fecha final a 1.75 aos,
la nat ural eza enor mement e no lineal del model o descrito en la ecuacin (24-1) pro-
duce:
E = L3 / ( P3 f ) - 3.8 personas-ao
Esto implica que, al extender la fecha final seis meses, se puede reducir el nmero
de personas de ocho a cuatro! La validez de tales resultados est abierta al debate,
pero la implicacin es clara: se pueden obt ener beneficios al emplear menos perso-
nal durant e un periodo un poco ms largo para lograr el mi smo objetivo.
TM
PDF Editor
24.2.3 Distribucin del esfuerzo
O Cm o s e
d e be d i s t r i -
bu ir e l e s f u e r zo a
l o l a r go d e l f l u jo
d e t r a ba jo d e l
p r o c e s o d e s o f t -
w a r e ?
Cada una de las t cni cas de est i maci n de proyect os de sof t war e est udi adas en ei
captulo 23 conduce a est i maci ones de uni dades de t rabaj o (por ejemplo, personas-
mes) requeri das para compl et ar el desarrol l o del soft ware. Una distribucin reco-
mendada del esfuerzo a travs del proceso de software con frecuencia se conoce como
la r e g l a 4 0- 20- 4 0. Cuarent a por ciento de t odos los esf uer zos se asi gnan al anlisis y
el di seo de si st emas de ent rada. Un porcent aj e similar se aplica en poner a prueba
los si st emas de salida. Usted puede inferir correct ament e que la codificacin (20 por
ci ent o del esfuerzo) no tiene t ant o nfasis.
Esta distribucin del esf uer zo se debe usar sol ament e como gua.6 Las caracters-
ticas de cada proyect o deben dictar la distribucin del esfuerzo. El t rabaj o realizado
en la pl aneaci n del proyect o rara vez explica ms de 2- 3 por ciento del esfuerzo, a
menos que el plan compr omet a a una organi zaci n a grandes gast os con al t o ries-
go. Los anlisis de requisitos pueden compr omet er 10-25 por ci ent o del esf uer zo de.
proyecto. El esf uer zo empl eado en el anlisis o elaboracin de prot ot i pos debe au-
ment ar en proporci n directa con el t amao y la compl ej i dad del proyecto. Un inter-
valo del 20 al 25 por ciento de esfuerzo normal ment e se aplica al di seo de soft ware
Tambi n se debe consi derar el t i empo utilizado en la revisin del di seo y la subsi-
guiente iteracin.
Debido al esf uer zo apl i cado al di seo de soft ware, el cdigo debe seguir con re-
l at i vament e poca dificultad. Se puede lograr un rango de 15-20 por ci ent o del esfuer-
zo global. Las pruebas y la subsiguiente depuraci n explican el 30-40 por ci ent o de!
esfuerzo de desarrollo del soft ware. El carct er crucial del sof t war e con frecuencia
dicta la cantidad de pr uebas que se requieren. Si el soft ware se clasifica desde el
punt o de vista humano (es decir, la falla del sof t war e puede resultar en prdida de
vidas), son usual es porcent aj es todava ms altos.
En la part e 1 de est e libro se describieron vari os model os de proceso diferentes. Sin
importar si un equi po de soft ware elige un model o secuenci al lineal, un model o in-
crement al , un model o evolutivo o al guna combi naci n, el model o de proceso est
pobl ado de un conj unt o de t ar eas que le permi t en a un equi po de sof t war e definir,
desarrollar y, a final de cuent as, brindar soport e al sof t war e de comput adora.
Ningn conj unt o de t areas es apropi ado por s solo para t odos los proyectos. El
conj unt o de t areas que sera apropi ado par a un si st ema compl ej o y grande probable-
6 En la actualidad, la regla 40-20-40 enfrenta una ofensiva. Algunos creen que ms del 40 por ciento
del esfuerzo global se debe utilizar durante el anlisis y el diseo. Por otra parte, algunos partida-
rios del desarrollo gil (captulo 4) argumentan que se debe emplear menos tiempo frontal "directo"
y que un equipo se debe mover rpidamente hacia la construccin.
TM
PDF Editor
C A P T U L O 2 4 CALENDARIZACIN DE PROYECTOS ES SOFTWARE 733
i lio desmolido un
adapt abl e (APM, por
ussigtOsa
Dnjuntos de toreos
j i ro orios (Moveclos
* sotlwore. Uno
.-esaiptifa completo
l wwwjspa.
:om/apm.
ment e se apreciara como demasi ado destructivo para un producto de soft ware pe-
queo y relativamente simple. En consecuencia, un proceso de soft ware eficaz debe
definir una coleccin de conj unt os de tareas, cada una diseada para satisfacer las
necesidades de diferentes tipos de proyectos.
Como se menci on en el captulo 2, un conj unt o de tareas es una coleccin de ta-
reas de trabajo de ingeniera del software, hitos y productos de t rabaj o que se deben
terminar para completar un proyecto particular. El conjunto de tareas debe propor-
cionar suficiente disciplina para lograr alta calidad de software. Pero, al mi smo tiem-
po, no debe abrumar al equipo del proyecto con t rabaj o innecesario.
El desarrollo de una calendarizacin del proyecto requiere distribuir un conjunto
de t areas a lo largo de la lnea de tiempo del proyecto. El conjunto de t areas variar
segn el tipo de proyecto y el grado de rigor con el que el equipo de software deci-
de realizar su trabajo. Aunque es difcil desarrollar una taxonoma completa de tipos de
proyecto de software, en la mayora de las organizaciones del ramo se encuent ran
los siguientes proyectos:
1.
2.
P r o y e c t o s d e d e s a r r o l l o d e l c o n c e p t o , los cuales se inician para explorar algunas
aplicaciones o conceptos de negocios de alguna nueva tecnologa.
Proyectos de d e s a r r o l l o d e n u e va s a p l i c a c i o n e s , los cuales se llevan a cabo co-
mo consecuencia de una solicitud especfica del cliente.
3. Proyectos de m e j o r a d e l a a p l i c a c i n , st os ocurren cuando el soft ware exis-
tente experimenta grandes modificaciones en la funcin, el desempeo o las
interfases visibles para el usuario final.
4. P r o y e c t o s d e m a n t e n i m i e n t o d e a p l i c a c i n , los cuales corrigen, adaptan o ex-
tienden el soft ware existente en formas que no sean obvias i nmedi at ament e
para el usuario final.
5. P r o y e c t o s d e r e i n g e n i e r a , st os se llevan a cabo con la finalidad de reconstruir
un sistema existente (heredado), en todo o en parte.
Incluso dentro de un solo tipo de proyecto, muchos factores influyen en la eleccin
del conj unt o de tareas. Por ejemplo [PRE99]: t amao del proyecto, nmero de usua-
rios potenciales, lo crucial de la misin, duracin de la aplicacin, estabilidad de los
requisitos, facilidad de comunicacin con el usuario o desarrollador, madurez de la
tecnologa aplicable, restricciones del desempeo, caractersticas ani dadas y no ani-
dadas, equipo del proyecto y factores de reingeniera. Cuando se consideran en con-
junto, estos factores ofrecen un indicio del g r a d o d e r i g o r que se debe aplicar al proceso
de software.
24.3.1 Ejemplo de conjunto de tareas
Cada uno de los tipos de proyecto descritos puede abordarse medi ant e un model o de
proceso lineal, secuencial, iterativo (por ejemplo, los modelos de elaboracin de pro-
totipo o incrementales) o evolutivo (por ejemplo el modelo espiral). En algunos casos,
TM
PDF Editor
un tipo de proyecto fluye suavement e hacia el siguiente. Por ejemplo, los proyect
de desarrollo del concepto que triunfan con frecuencia evolucionan en proyectos c t
desarrollo de nuevas aplicaciones. Cuando termina un proyecto de desarrollo de nue-
vas aplicaciones, en ocasiones comienza un proyecto de mejora de una aplicacir
Esta progresin es t ant o natural como predecible y ocurrir sin importar el mode::
de proceso que adopte la organizacin. En consecuencia, las principales tareas dt
ingeniera del soft ware descritas en las secciones que siguen son aplicables a todos
los flujos de modelo de proceso. Como ejemplo, considrense las tareas de ingenie-
ra del soft ware para un proyecto de desarrollo del concepto.
Los proyectos de desarrollo del concepto se inician cuando se debe explorar el poten-
cial para alguna nueva tecnologa. No existe certeza de que la tecnologa ser aplicable
pero un cliente (por ejemplo, marketing) cree que existen beneficios potenciales. Los pro -
yectos de desarrollo del concepto se enfocan en aplicar las siguientes tareas principales
1. 1 La de t e r mi na c i n del mbi t o del c onc e pt o precisa el mbito global del
proyecto.
1. 2 La pl aneaci n pr el i mi nar del c onc e pt o establece la habilidad de la orga-
nizacin para acomet er el t rabaj o que entraa el mbito del proyecto.
1. 3 La val or aci n del r i es go d e la t ecnol og a evala el riesgo asociado con
la tecnologa que se implementar como parte del mbito del proyecto.
1.4 La pr ue ba del c onc e pt o demuestra la viabilidad de una nueva tecnologa
en el contexto del software.
1. 5 La i mpl ement aci n del concept o pone en prctica la representacin del con-
cepto en una forma que pueda revisarla un cliente y se utiliza para propsitos de
"mercadotecnia" cuando se debe vender un concepto a otros clientes o gestores.
1. 6 La r eacci n del cl i ent e al concepto solicita realimentacin acerca de un con-
cepto de nueva tecnologa y se dirige a aplicaciones especficas de los clientes.
Una rpida exploracin de estas tareas debe producir pocas sorpresas. De hecho, el
flujo de ingeniera del soft ware para los proyectos de desarrollo del concepto (y tam-
bin para todos los otros tipos de proyectos) es poco ms que sentido comn.
24.3.2 Refinamiento de las tareas principales
Las t areas principales descritas en la seccin precedente se pueden utilizar para de-
finir la calendarizacin macroscpica de un proyecto. Sin embargo, esta calendari-
zacin se debe refinar para crear una calendarizacin detallada del proyecto. El re-
finamiento comienza al tomar cada tarea principal y descomponerla en un conjunto
de subt areas (con productos de trabajo e hitos relacionados).
Como ejemplo de descomposicin de tarea, considrese la tarea 1.1, "determinacin
del mbito del concepto". El refinamiento de la tarea se puede lograr empleando un bos-
quejo de formato, pero en este libro se aplica un enfoque de lenguaje en el diseo del
proceso para ilustrar el flujo de la actividad de determinacin del mbito del concepto.
TM
PDF Editor
C A P T U L O 2 4 CALENDARIZACIN DE PROYECTOS DE SOFTWARE 735
Definicin t area: Tarea 1.1 Determinacin del mbito del concept o
1.1.1 Identificar necesi dades, beneficios y clientes potenciales;
1.1.2 Definir event os de salida/control y entrada deseados que
impulsen la aplicacin;
Comienza Tarea 1.1.2
1.1.2.1 RTF: Revisar la descripoin escrita de la necesidad7
1.1.2.2 Derivar una lista de sal i das/ ent radas visibles al cliente
1.1.2.3 RTF: Revisar salidas/entradas con el cliente y modificar conforme se requiera
fintarea Tarea 1.1.2
1.1.3 Definir la funcionalidad/comportamiento para cada funcin principal;
Comienza Tarea 1.1.3
1.1.3.1 RTF: Revisar los obj et os de dat os de salida y entrada derivados en la tarea
1.1.2;
1.1.3.2 Derivar un modelo funci ones/ comport ami ent os;
1.1.3.3 RTF: Revisar funci ones/ comport ami ent os con el cliente y modificar confor-
me se requiera:
fintarea Tarea 1.1.3
1.1.4 Aislar aquellos el ement os de la tecnologa que se implementar en el soft ware;
1.1.5 Disponibilidad de investigacin del soft ware existente;
1.1.6 Definir factibilidad t cni ca:
1.1.7 Realizar estimacin rpida del t amao;
1.1.8 Crear una Definicin del mbito;
fintarea definicin: Tarea 1.1
Las t areas y subt areas anot adas en el proceso de refi nami ent o del l enguaj e de dise-
o forman la bas e de una pl aneaci n detallada de la actividad de det ermi nar el
mbi t o del concept o.
2 4 . 4 DE F I NI C I N PE UNA REP P E TAREAS
Las t ar eas y subt areas individuales tienen i nt erdependenci as bas adas en su secuen-
cia. Adems, cuando ms de una persona est involucrada en un proyect o de inge-
:VVE niera del soft ware, es probabl e que las actividades y t areas de desarrol l o se realicen
e n paralelo. Cuando est o ocurre, las t ar eas concurrent es deben est ar coor di nadas
[ s t ar eas es un r
I paro
de modo que se completarn cuando las t areas posteriores requieran sus productos de
ros trabajo.
ent re
: . det ermi nar la
Una r e d d e t a r e a s , t ambi n denomi nada r e d d e a c t i vi d a d , es una represent aci n
grfica del flujo de t ar eas en un proyecto. En ocasi ones se utiliza como el mecani s-
mo medi ant e el cual la secuenci a y dependenci as de t areas son la ent rada a una he-
rrami ent a aut omat i zada de cal endari zac: :r. del proyecto. En su forma ms simple
7 RTF indica que se debe realizar una r eus >n ; i : : ~ = I capitulo 26)
TM
PDF Editor
Re d d e t a r e a s p a r a d e s a r r o l l o d e l c o n c e p t o .
1.1
Determinacin
mbito
concepto
1. 2
Planeacin
concepto
J
1.3c
Evolua<
riesgo
1.5c
Implementocin
concepto j
1.6
Reaccin
cliente
(empleada cuando se crea una calendarizacin macroscpica), la red de tareas
muest ra las principales t areas de la ingeniera del software. La figura 24.2 muestra
una red de t areas esquemtica para un proyecto de desarrollo del concepto.
La nat ural eza concurrent e de las actividades de ingeniera del soft ware conduce
a varios requisitos i mport ant es de la calendarizacin. Puesto que las t areas parale-
las ocurren de manera asincrona, el planificador debe det ermi nar dependenci as ir.-
tertareas para asegurar el progreso cont i nuo hacia la finalizacin. Adems, el gestor
del proyecto debe est ar at ent o a est as t areas que se encuent ran en la r u t a c r t i c a . Es-
to es, las t areas que se deben completar en la calendarizacin si el proyecto como
un todo se debe completar a tiempo. Ms adel ant e en este captulo se tratan con ms
detalle est os t emas.
Es importante not ar que la red de t areas most rada en la figura 24.2 es macrosc-
pica. En una red de t areas detallada (un precursor de una calendarizacin detallada)
cada actividad que muestra la figura se debe expandir. Por ejemplo, la tarea 1.1 se
expandira para most rar todas las t areas detalladas en el refinamiento de las tareas
1.1. most radas en la seccin 24.3.2.
La calendarizacin de un proyecto de soft ware no difiere enor mement e de la de
cualquier esfuerzo de ingeniera multitarea. En consecuenci a, las tcnicas y herra-
mi ent as general i zadas de calendarizacin de proyecto se pueden aplicar, poco mo-
dificadas, en proyectos de software.
La t c n i c a d e e va l u a c i n y r e vi s i n d e p r o g r a m a (PERT, por sus siglas en ingls) y el
m t o d o d e r u t a c r t i c a (CPM, p o r s u s s i g l a s e n i n g l s ) son dos mt odos de calendari-
zacin de proyecto que se pueden aplicar al desarrollo de software. Ambas tcnicas
2 4 . 5 CAL ENDARI ZACI N
TM
PDF Editor
C A P T U L O 2 4 CALENDARIZACIN DE PROYECTOS DE SOFTWARE
737
reciben impulso de la i nformaci n ya desarrol l ada en act i vi dades t empr anas de la
pl aneaci n del proyecto:
Estimacin del esfuerzo.
Descomposi ci n de la funcin del producto.
Seleccin del model o de pr oceso y conj unt o de t ar eas apropi ados.
Descomposi ci n de t areas.
Las i nt erdependenci as ent r e las t ar eas se pueden definir empl eando una red de t a-
reas. Las t areas, en ocasi ones l l amadas la e s t r u c t u r a d e a n l i s i s d e l t r a ba j o (EAT, por
s us siglas en ingls), se defi nen para el product o como un t odo o para funci ones i n-
dividuales.
"Todo l o q u e t e n e mo s q u e deci di r es q u h a c e r con el t i e mp o q u e nos h o n d a d o . "
G a n d a l f e n El s e o r d e l o s a n i l l o s : l a he r m a n d a d d e l a n i l l o

Tanto PERT como CPM ofrecen her r ami ent as cuant i t at i vas que permi t en al plani-
ficador de sof t war e 1) det ermi nar la trayectoria critica: la cadena de t areas que de-
t ermi nan la duraci n del proyecto; 2) est abl ecer las est i maci ones de t i empo "ms
probabl es" para t areas individuales al aplicar model os estadsticos; y 3) calcular los
"t i empos lmite" que defi nen una "vent ana" de t i empo para una t area particular.
OHM Ca l e n d a r i z a c i n d e p r o y e c t o s
Obj e t i v o : El objetivo de las herramientas de
calendarizacin de proyectos es permitir que un
gestor defina las tareas de trabajo, establezca sus depen-
dencias, asigne recursos humanos a las tareas y desarrolle
una variedad de grficas, diagramas y tablas que auxilian
en el seguimiento y el control del proyecto de software.
Me c n i c a : En general, las herramientas de calendariza-
cin de proyectos requieren la especificacin de una es-
tructura de anlisis de trabajo o la generacin de una red
be tareas. Una vez que se define el anlisis de la tarea (un
bosquejo) o red, a cada tarea se ligan fechas de inicio y fin,
ecursos humanos, fechas lmite duras y otros datos. Enton-
ces la herramienta genera una variedad de cronogramas y
otras tablas que le permiten a un gestor valorar el flujo de
oreas de un proyecto. Dichos datos pueden actualizarse de
-lanera continua conforme el proyecto se lleva a cabo.
V
He r r a m i e n t a s r e p r e s e n t a t i v a s 8
AMS R e a l t i m e , desarrollada por Advanced Management
Systems (www.amsusa.com), ofrece capacidades de ca-
lendarizacin para proyectos de todos los tamaos y ti-
pos.
M i c r o s o f t P r o j e c t , desarrollada por Microsoft (www.micro-
soft.com), es la herramienta de calendarizacin de pro-
yectos basada en PC ms ampliamente usada.
Vi e w p o i n t , desarrollada por Artemis Internation Solutions
Corp. (www.atemispm.com), soporta todos los aspectos
de la planificacin del proyecto, incluso la calendariza-
cin.
Una lista detallada de empresas y productos de software
de gestin de proyectos se puede encontrar en www.in-
fogool .cam/pmc/pmcswr.htm.
8 Las herramientas expuestas representan una rr esra 2e esta categora En casi todos los casos los
nombres de las mismas son marcas registrada? ci -espectivos desarrolladores.
TM
PDF Editor
738
PAETE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
\
C L V E
Un cronogromo
permi t e det ermi nar
qu t oreos se
realizarn en un punt o
dado en el t i empo.
24.5.1 Cronogramas
Cuando s e crea una cal endari zaci n de proyect o del soft ware, el planificador
mi enza con un conj unt o de t areas (la est ruct ura de anlisis del trabajo). Si se
plean her r ami ent as aut omat i zadas, el anlisis del t rabaj o se introduce como una i
de t ar eas o esbozo de tareas. Ent onces se i nt roduce el esfuerzo, la duraci n y 1
cha de inicio de cada t area. Adems, las t areas se pueden asi gnar a individuos t
cficos.
Como consecuenci a de est a ent rada, se genera un c r o n o g r a m a , t ambi n llama
g r f i c o Ga n t l . Es posible desarrollar un cr onogr ama para t odo el proyecto. De ma
ra alternativa, se pueden desarrollar cr onogr amas separ ados para cada funcin i
proyect o o para cada individuo que t rabaj e en l.
La figura 24.3 ilustra el format o de un cr onogr ama. Muestra una part e de la
lendarizacin de un proyect o de sof t war e que resalta la t area de det ermi naci n i
mbi t o del concept o para un product o de soft ware procesador de pal abra (PP).
das las t areas del proyecto (para la determinacin del mbi t o del concepto) se ci t an;
la col umna de la izquierda. Las barras hori zont al es indican la duraci n de cada
Eje m p l o d e c r o n o gr a m a
Semana 1 S e ma n a 2 Semana 3 Semana 4 Semana 5
1. 1. 1 I dent i f i car n e c e s i d a d e s y be ne f i c i os
Reuni r se c o n cl i ent es
I dent i f i car n e c e s i d a d e s y r es t r i cci ones del pr oye c t o
Es t abl ecer e n u n c i a d o del p r o d u c t o
Hi t o e n u n c o d o del p r o d u c t o d e f i ni d o
I 1 2 Defi ni r s a l i d a s / c o n t r o l / e n t r a d o s | SCE| d e s e a d a s
Al c a n c e d e l as f unc i one s del t e c l a d o
Al c a n c e d e l as f unc i one s d e e n t r a d a d e voz
Al c a n c e d e l os mo d o s d e nter a c c i n
Al c a n c e del d i a gns t i c o d e d oc ume nt os
Al c a nc e d e ot r as f unc i one s del PP
SCE del d o c u me n t o
RTF Revi si n d e SCE c o n el cl i ent e
Mod i f i c a r SCE c o n f o r me s e r e q u i e r a
Hifo: SCG de f i ni da *
1. 1. 3 Def i ni r l a f u n c i n / c o mp o r t a mi e n t o
Def i ni r f unc i one s d e t e c l a do
Defi ni r f unci ones d e e n t r a d a d e v o z
Descr i bi r mo d o s d e i nt er acci n
Descr i bi r ver i f i caci n o r t o g r f i c a / g r a ma t i c a l
Descr i bi r o t r a s f unc i one s del PP
RTF Revi sar def i ni ci n SCE c o n eJ d i e n t e
Mod i f i c a r c o n f o r me s e r e q u i e r a
Hi t o: def i ni ci n c o mp l e t a d e SCE
1. 1. 4 Ai s l ami ent o d e e l e me nt os d e s of t wa r e
Hi t o e l e me nt os d e s of t wa r e d e f i ni d os
1. 1. 5 I nvest i gar di s poni bi l i da d d e s of t wa r e exi s t ent e
I nvest i gar c o mp o n e n t e s d e e d i c i n d e t ext o
I nvest i gar c o mp o n e n t e s d e e n t r a d a d e v o z
I nvest i gar c o mp o n e n t e s d e a dmi ni s t r a c i n d e a r c hi vos
I nvesi i gor c o mp o n e n t e s d e ver i f i caci n o r t o g r f i c a /
gr a ma t i c a l
1.1 Hito: i dent i f i car c o mp o n e n t e s r eut i l i zabl es
Defi ni r f act bi l i dad t cni ca
Eval uar e n t r a d a d e v o z
Eval uar ver i f i caci n gr a ma t i c a l
1. 1. 7 Hito: f oct i bi l i dad t cni ca v a l o r a d a
1 . 1 8 Es t i maci n r p i d a d e t a ma o
Cr e a r u n a de f i ni c i n d e mb i t o
Revi sar d o c u me n t o d e mbi t o c o n el cl i ent e
Mod i f i c a r el d o c u me n t o c onf or me se r e qui e r a
Hito: d o c u me n t o d e mbi t o c o mp l e t o
T
=
TM
PDF Editor
CAPTULO 24 CALENDARIZACIN DE PROYE CTC6 DE SOFTWARE 739
rea. Cuando en el cal endari o s e pr esent an al mi s mo t i empo mltiples barras, se im-
plica la concurrenci a de la t area. Los di amant es indican hitos.
Una vez i ngresada la i nformaci n necesari a para gener ar el cr onogr ama, la ma-
yora de l as her r ami ent as de cal endari zaci n de proyect os de soft ware producen ta-
blas de proyecto: una lista tabular de t odas las t areas del proyecto, sus fechas de inicio
y concl usi n, pl aneadas y reales, y una variedad de i nformaci n rel aci onada (figura
24.4). Si se utilizan en conj unt o con el cr onogr ama, las t abl as de proyect o permi t en
que el gest or del proyect o d segui mi ent o al progreso.
24.5.2 Seguimiento de la calendarizacin
La cal endari zaci n del proyect o proporci ona un mapa de carret eras al gest or del
proyect o de soft ware. Si se ha desarrol l ado de maner a adecuada, la cal endari zaci n
del proyect o defi ne las t ar eas e hitos que se deben seguir y control ar conf or me avan-
ce el proyecto. El segui mi ent o se puede hacer de di ferent es maner as:
Con la realizacin peridica de r euni ones para valorar el est ado del proyect o
en las cual es cada uno de los mi embr os del equi po informa del progreso y los
probl emas.
Con la eval uacin de los resul t ados de t odas las revi si ones real i zadas a lo lar-
go del pr oceso de ingeniera del soft ware.
Con la det ermi naci n de si s e han l ogrado los hitos formal es del proyect o en
la fecha pr ogr amada (los di amant es que se muest ran en la figura 24.3).
Al compar ar la fecha de inicio real con la fecha de inicio prevista para cada
t area del proyect o menci onada en la tabla de recursos (figura 24.4).
Ejemplo de t abl a de recursos.
Tar eas de t r a ba j o
Inicio
pr evi st o
Inicio
r eal
Terminacin
pr evi st a
Terminacin
r eal
Per s onas
a s i gna da s
Esfuerzo
a s i gna do
<) ent } ear n e c e s i d a d e s y b e n e f i c i o s
Re u n i r s e c o n l os c l i e n t e s
i d e n t i f i c a r n e c e s i d a d e s y r e s t r i c c i o n e s d e l p r o y e c t o
Es a b l e c e r e n u n c i a d o d e l p r o d u c t o
Hi t o: e n u n c i a d o d e l p r o d u c t o d e f i n i d o
De f i ni r s a l i d a s / c o n t r o l / e n t r a d a s | SCE) d e s e a d a s
Al c a n c e d e l a s f u n c i o n e s d e l t e c l a d o
Al c a n c e d e l a s f u n c i o n e s d e e n t r a d a d e v o z
Al c a n c e d e l o m o d o s d e i n t e r a c c i n
A l c a n c e d e l d i a g n s t i c o d e d o c u me n t o s
Al c a n c e d e o t r a s f u n c i o n e s d e l P P
D o c u me n t o S CE f - ! y
RTF: r e v i s i n d e S CE c o n e l c l i e n t e
Mo d i f i c a r S CE c o n f o r me s e r e q u i e r a
Hi t o: S CE d e f i n i d a s
De f i ni r l a f u n c i n / c o mp o r t a mi e n t o
s e m 1, d i
s e m 1, d 2
s e m 1, d 3
s e m 1, d 3
s e m I , d 4
s e m I , d 3
s m 2 , d i
s e m 2 , d i
s e m I , d 4
s e m 2, d i
s e m 2 . d 3
s e m 2 , d 4
s e m 2 , d 5
s e m , d i
s e m I , d 2
s e m I , d 3
s e m 1 ; d 3
s e m 1, d 4
s e m 1, d 3
s e m 1, d 4
s e m I , d 2
s e m I , d 2
s e m I, d 3
s e m 1, d 3
s e m 1, d 2
s e m 1, d 2
s e m 1, d 3
s e m 1, d 3
JPP
s e m.
sem:
s e m
s e m
s e m
s e m
s e m
s e m
s e m
2 , d 2
2,<2
2 , d 3
2 , d 2
2, d 3
2, d 3
2. d 3
2. d 4
2 , d 5
m
MIL
Mli
2p-d
V;P"d
1 . 5 p d
2 p d
1 p<f
1 . 5 p d
2Pd
3 p d
3 p d
3 p d
TM
PDF Editor
^ O N S i i O ^
E l mej or i n di cador de
pi og i eso es la termi -
n aci n y rev i si n
ex i tosa de u n
produ cto de trabaj o de
sof tw are def i n i do.
Al reuni rse de maner a i nformal con los t r abaj ador es para obt ener su evalua-
cin subjetiva del progreso hast a la fecha y los probl emas que se vislumbran
Con el uso del anlisis del valor obt eni do (seccin 24.6) para eval uar el pro-
greso cuant i t at i vament e.
En realidad, t odas est as t cni cas de segui mi ent o l as utilizan los gest ores de proye;
to experi ment ados.
"La regl o bsico del r epor t e del est ado del soft war e se puede resumir en una sola frase: no hay sorpresas. "
El control lo empl ea el gestor del proyect o para admi ni st rar los recursos del pr c- B
yecto, lidiar con l os pr obl emas y dirigir al personal del proyecto. Si l as cosas van bien I
(es decir, el proyecto est dent ro del cal endari o y del presupuest o, l as revisiones r - I
dican que se est real i zando un progreso real y que los hitos se han al canzado! d I
control es ligero. Pero cuando ocurren probl emas, el gest or del proyect o debe ejer- I
cer control para sol uci onarl os tan pr ont o como sea posible. Cuando se haya diag- I
nost i cado el probl ema se dest i nan recursos adi ci onal es al rea correspondi ent e r e. I
bi cando personal o redefi ni endo la cal endari zaci n.
Cuando enf r ent an sever as pr esi ones por la fecha lmite, los gest ores de pr oyeca
exper i ment ados en ocasi ones empl ean una cal endari zaci n de proyecto y tcnica ct\
control l l amada ti me-box i n g (encaj onami ent o de tiempo) [ZAH95]. Esta estrategia re - I
conoce que el pr oduct o compl et o no podr ent r egar se en la fecha lmite pr ogr a ~; I
da. Por lo tanto, se elige un paradi gma de soft ware i ncrement al (captulo 3) y se eia- I
bora una cal endari zaci n para cada ent rega i ncrement al .
Ent onces se encaj onan en el t i empo las t ar eas asoci adas con cada incre
Esto significa que la cal endari zaci n para cada t area se aj ust a al t rabaj ar haci
desde la fecha de ent r ega para cada i ncrement o. Se col oca una "caja" alrededor ae
cada t area. Cuando una t area se acerca al lmite de su caj a de t i empo (ms o me - s
10 por ciento), el t rabaj o se det i ene y comi enza la siguiente t area.
La reaccin inicial al enfoque del encaj onami ent o de t i empo usual ment e es ne : ;
tiva: si el t rabaj o se termina, cmo se proceder? La r espuest a se encuent r a e r l a
forma en se realiza el t rabaj o. Cuando se llegue al lmite de la caj a de tiempo, es pro-j
babl e que se haya compl et ado9 90 por ci ent o de la t area. El r est ant e 10 por cier : i J
aunque i mport ant e, puede 1) demor ar se hast a el siguiente i ncr ement o o 2) comp ci-
t arse ms tarde si se requiere. Ms que quedar se "empant anado" en la t area, el pror
yect o avanza hacia la fecha de ent rega.
Capers Jones
9 Un cnico puede recordar el dicho: el 90 por ciento del sistema toma 10 por ciento del tiempo; e
tante 10 por ciento del sistema toma 90 por ciento del tiempo.
TM
PDF Editor
CAPTULO 24 CALENDARIZACIN DE PROYECTOS DE SOFTWARE
741
^ CONSCI Q^
L o depu raci n y
yu eba son si mu lt -
os. C on f recu en ci a,
ti estodo de lo depu -
-x i n se ev al o al
con si derar el ti po y
n mero de errores
i bu g s) " abi ertos" .
24.5.3 Seguimiento del progieso en un proyecto OO
Aunque un model o iterativo es el mej or mar co de t r abaj o para un proyect o OO, el
paral el i smo de las t ar eas dificulta el segui mi ent o del proyecto. El gestor del proyec-
to puede t ener dificultades al est abl ecer hitos significativos para un proyect o OO de-
bido a vari as cos as di ferent es que ocurren a la vez. En general, los si gui ent es hitos
principal es se pueden consi derar "compl et ados" cuando se al canzan l os criterios
anot ados.
Hitos tcnicos: anlisis OO completado
Se han definido y revi sado t odas l as cl ases y la jerarqua de clase.
Se han definido y revi sado los at ri but os de cl ase y las oper aci ones asoci adas
con una clase.
Se han est abl eci do y revi sado las rel aci ones de cl ase (captulo 8).
Se ha cr eado y revi sado un model o de compor t ami ent o (captulo 8).
Se han anot ado l as cl ases reutilizables.
\
Hitos tcnicos: diseo OO completado
Se ha defi ni do y revi sado el conj unt o de subsi st emas (captulo 9).
Las cl ases se han revi sado y asi gnado a los subsi st emas.
Se ha est abl eci do y revi sado la asi gnaci n de t areas.
Se han identificado l as responsabi l i dades y col abor aci ones (captulos 8 y 9).
Se ha cr eado y revi sado el di seo de l as clases.
Se ha cr eado y revi sado el model o de comuni caci n.
Hitos tcnicos: programacin OO completada
Cada nueva clase se ha i mpl ement ado en cdigo a partir del model o de diseo.
Se han i mpl ement ado l as cl ases obt eni das (de una librera de reutilizacin).
Se ha const rui do el prot ot i po o i ncrement o.
Hitos tcnicos: prueba OO
Se han revi sado la correccin y que est n compl et os el anlisis OO y los mo-
del os de diseo.
Se ha desarrol l ado y revi sado una red cl ase-responsabi l i dad-col aboraci n (ca-
ptulo 8).
Se han di seado casos de pr ueba y se han llevado a cabo pr uebas al nivel de
cl ase (captulo 14) para cada clase.
Se han di seado casos de prueba, se han compl et ado pr uebas de agr upa-
mi ent os (captulo 14) y se han i nt egrado l as clases.
Se han compl et ado l as pr uebas al nivel de si st ema.
TM
PDF Editor
742 PAUTE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
Recur des e que el mode l o de pr oc e s o OO e s i t erat i vo, c a da u n o de e s t os hi t os p u r l
de r evi sar se c onf or me di f er ent es i nc r e me nt os s e e nt r e gue n al cl i ent e.
Seguimiento de la calendarizacin
1
El es cenari o: Oficina de Doug
Miller, ontes del inicio del proyecto de software Hog arSe-
gwa- '' , i f e ' ' <" :
Los act ores : Doug Miller gerente del equipo de inge-
niera del software de Hog arSeg u ro) y Vinod Raman, Ja-
mieLazar y otros miembros del equipo de ingeniera del
software del producto.
La conversaci n:
Doug {mira una di aposi ti va PowerPoint): La ca-
lendarizacin para el primer incremento de Hog arSeg u ro
parece razonable, pero tendremos problemas para darle
seguimiento al progreso.
Vi nod {su rostro s e nota preocupado): Por qu?
Hemos calendarizado las tareas en una base diaria, lle-
na de productos de trabajo, y nos hemos asegurado que
nos estamos asignando recursos de ms.
Doug: Todo est bien, pero cmo sabemos cundo es-
t completo el modelo de anlisis para el primer incre-
Jami e: Las cosas son iterativas, por eso es difcil.
Doug: Entiendo eso, pero... bueno, por ejemplo, tome-
mos an li si s de clases def i n i do. T indicaste esto como u -
hito.
Vinod: As es. ! H
Doug: Quin hizo esa determinacin?
Jami e (irritada): Estn hechas cuando estn hechos
Doug: Eso no es suficientemente bueno, Jamie. Tenemos
que calendarzar RTF [revisiones tcnicas formales, capi-
tulo 26] y no lo han hecho. La conclusin exitosa de una
revisin en el modelo de anlisis, por ejemplo, es un hito
razonable. Entendido?
Jami e ( mal humorada) : Est bien, de vuelta o la me-
sa de dibujo.
Doug: No les debe tomar ms de una hora hacer las
correcciones. . todos los dems pueden comenzar aore
2 4 . 6 A M L S I S DEL VALOR G A MA D O
%
C L V E
El val or ga na do of r ece
un indicio cuant i t at i vo
del pr ogr es o.
En la s ecci n 24. 5 s e t r at ar on a l gunos e nf oque s cual i t at i vos e n c ua nt o al segui mi en-
t o del pr oyect o. Cada uno of r ece al gest or del pr oyect o un i ndi ci o del pr ogr eso, perr-
una eval uaci n de la i nf or maci n pr opor ci ona da e s un poc o subj et i va. Es r azonab. e
pr egunt ar si exi st e una t cni ca cuant i t at i va par a eval uar el pr ogr e s o c onf or me el
equi po de s of t wa r e a va nz a a t r avs de l as t ar eas de t r abaj o a s i gna da s en la cal en-
dar i zaci n del pr oyect o. De hecho, exi st e una t cni ca par a r eal i zar anl i si s cuant i t a-
t i vos del pr ogr eso. Se l l ama an li si s del v alor g an ado (AVG). Humphr ey [HUM95"
c ome nt a el val or ga na do en la f or ma si gui ent e:
El sistema de valor ganado proporciona una escala de valor comn para cualquier tarea
[de proyecto de software], sin importar el tipo de trabajo que se realiza. Se estiman las ho-
ras totales para realizar todo el proyecto y a cada tarea se le da un valor ganado con ba-
se en su porcentaje estimado del total.
Enunci ado en una f or ma m s si mpl e, el val or ga na do e s una medi da del pr ogr es o
Per mi t e val or ar el " por cent aj e r eal i zado" de un pr oyect o r e e mpl e a ndo el anl i si s
cuant i t at i vo e n l ugar de a poya r s e en una opi ni n per s onal . De hecho, Fl emi ng y Kop-
TM
PDF Editor
CAPTULO 24 CALENDARIZACIN DE PROYECTOS DE SOFTWARE 743
Cmo se
calcula el
ganado y
i t e utiliza
i evaluar el
o?
i vtiriedod de
s ocefco del
|BM)
crsoien
.a<q.(
ri/p/.
pl eman [FLE98] ar gument an que el anl i si s del valor ganado "ofrece l ect uras preci-
sas y confi abl es del desempeo desde un moment o t an t empr ano del proyect o co-
mo el 15 por ci ent o realizado. "
Para det er mi nar el valor ganado se real izan los si gui ent es pasos:
1. Se det ermi na el costo presu pu estado para el trabaj o calen dari zado (CPTC) res-
pect o de cada tarea de t r abaj o represent ada en la cal endari zaci n. Durant e la
est i maci n se planifica el t rabaj o (en per sonas- hor a o personas-d a) de cada
t area de ingenieria. Por lo t ant o, CPTC, es el esf uer zo pal nificado para la t area
de t rabaj o i . Para det ermi nar el progreso en un punt o dado en la cal endari za-
cin del proyecto, el valor de CPTC es la suma de los val ores CPTC, para t odas
la t areas de t rabaj o que deben est ar compl et adas en dicho punt o en el t i empo
en la cal endari zaci n del producto.
2. Los val ores CPTC para t odas l as t ar eas de t rabaj o se resumen para obt ener el
presu pu esto a la termi n aci n , PAT. Por lo t ant o,
PAT = I (PTCO para t odas l as t ar eas k.
3. A cont i nuaci n se calcula el costo presu pu estado del trabaj o reali zado (CPTR).
El valor de CPTR es la s uma de l os val ores CPTC para t odas l as t areas de tra-
baj o que en realidad se han compl et ado en un punt o en el t i empo en la cal en-
darizacin del proyecto.
Wilkens [WIL99] seal a que "la distincin ent r e CPTC y CPTR es que la pri mera re-
present a el pr esupuest o de l as actividades que s e pl anearon compl etar, y la ltima,
el pr esupuest o de las actividades que en real idad se compl et ar on". Dados los valo-
res de CPTC, PAT y CPTR, se pueden calcular i mport ant es i ndi cadores del progreso:
ndice de des empeo en la cal endari zaci n, IDCa = CPTR/CPTC
Varianza en la cal endari zaci n, VC = CPTR - CPTC
IDCa es un indicador de la eficiencia con la que el proyect o utiliza los r ecur sos ca-
l endari zados. Un valor IDCa cer cano a 1.0 indica una ejecucin eficiente del proyec-
to cal endari zado. VC si mpl ement e es un indicador absol ut o de la variacin a partir
de la cal endari zaci n pl aneada.
Porcent aj e cal endari zado para terminacin = CPTC/PAT
ofrece un indicador del porcentaje de t rabaj o que debe est ar compl etado en el tiempo t.
Porcent aj e de compl et ado = CPTR/PAT
ofrece una indicacin cuantitativa del por cent aj e de avance del proyect o en un pun-
to dado en el tiempo, t.
Tambin es posibl e calcular el costo real del trabaj o reali zado, CRTR. El valor para
CRTR es la s uma del esf uer zo r eal ment e utilizado en l as t areas de t rabaj o que se han
compl et ado en un punt o en el t i empo en ia cal endari zaci n del proyecto. Ent onces
es posible calcular
TM
PDF Editor
ndi ce de d e s e mp e o del cos t o, IDCo = CPTR/CRTR
Var i anza del cos t o, VC = CPTR - CRTR
Un val or de IDCo ce r ca no a 1.0 of r ece un f uer t e i ndi cador de que el pr oyect o esta
dent r o de s u pr e s upue s t o defi ni do, VC e s un i ndi cador a bs ol ut o del a hor r o e n cos t i
(cont r a l os cos t os pl aneados ) o r ecor t es e n una e t a pa par t i cul ar de un pr oyect o.
Al i gual que un r adar en el hor i zont e, el anl i si s del val or ga na do i l umi na l as c:-
ficultades en la cal endar i zaci n a nt e s de que pue da n adver t i r s e de al guna ot r a for-
ma . Est o per mi t e que el ges t or del pr oyect o de s of t war e t ome me di da s cor r ect i vas
a nt e s de que s e desar r ol l e una cri si s en el pr oyect o.
La cal endar i zaci n e s la cul mi naci n de una act i vi dad de pl ani fi caci n que e s un
c ompone nt e pr i nci pal de la gest i n del pr oyect o de s of t war e. Cua ndo s e combi r i
con m t odos de est i maci n y anl i si s de riesgo, la cal endar i zaci n est abl ece un mapa
de car r et er as par a el ges t or de pr oyect os.
La cal endar i zaci n c omi e nz a con el pr oc e s o de des compos i ci n. Las car act er i st -
ca s del pr oyect o s e utilizan par a adapt ar un conj unt o de t ar eas apr opi ado al t r aba :
que s e r eal i zar . Una r ed d e t a r e a s bos quej a ca da t ar ea de i ngeni er a, s u de pe nde r
cia de ot r as t a r e a s y s u dur aci n pr oyect ada. La r ed d e t a r e a s s e utiliza par a calcu-
lar la t r ayect or i a crtica, un c r onogr a ma y una var i edad de i nf or maci n del proyect :
Al us ar la cal endar i zaci n c o mo gu a, el ges t or del pr oyect o pue de dar s egui mi en: c
y cont r ol ar c a da p a s o en el pr oce s o del s of t war e.
[BR095] Brooks, M., The Mythi cal Man -Mon th, edicin de aniversario, Addison-Wesley, 1995
[FLE98] Fleming, Q. W., y J. M. Koppelman, "Earned Valu Project Management", C rosstalk, ve.
11, nm. 7, julio de 1998, p. 19.
[HUM95] Humphrey, W., A Di sci pli n e f or Sof tw are E n g i n eeri n g , Addison-Wesley, 1995.
[NOR70] Norden, P., "Useful Tools for Project Management", en Man ag emen t of Produ cti on , M.
Starr (ed.), Penguin Books, 1970.
[PAG85] Page-Jones, M., Practcal Proj ect Man ag emen t, Dorset House, 1985, pp. 90-91.
[PRE99] Pressman, R. S., Adaptable Process Model, R. S. Pressman & Associates, 1999.
[PUT78] Putnam, L., y W. Myers, Measu res f or E x cellen ce, Yourdon Press, 1992.
[W1L99] Wilkens, T. T., "Earned Valu, Clear and Simple", Primavera Systems, 1 de abril de 1999, p. 2
[ZAH95] Zahniser, R., "Time-boxing for Top Team Performance", en Sof tw are Dev elopmen t, mar
zo de 1995, pp. 34-38.
P R O B L E MA S V P UNT OS A C ONS I DE R AR
24. 1. Las fechas lmite "irracionales" son un hecho de la vida en el negocio del software. Ce-
rno se debe proceder si se enfrenta con una?
24. 2. Cul es la diferencia entre una calendarizacin macroscpica y una calendarizacin de-
tallada? Es posible gestionar un proyecto si slo se desarrolla una calendarizacin macrosc-
pica? Por qu?
TM
PDF Editor
CAPITULO 24 CALENDARIZACIN DE PROYECTOS DE SOFTWARE 745
24. 3. Existe algn caso donde un hito de un proyecto de software no est ligado a una revi-
sin? Si es as, ofrecer uno o ms ejemplos.
24. 4. La "sobrecarga de comunicacin" puede ocurrir cuando muchas personas trabajan en un
proyecto de software. El tiempo empleado en la comunicacin con otros reduce la productivi-
dad individual (LDC/persona-mes) y el resultado es menor productividad para el equipo. Ilus-
trar (cuantitativamente) cmo los ingenieros versados en las buenas prcticas de ingeniera del
software y que usan revisiones tcnicas formales pueden aumentar la tasa de produccin de un
equipo (cuando se compara con la suma de las tasas de produccin individuales). Sugerencia:
se puede suponer que las revisiones reducen la reelaboracin y que sta puede explicar el 20-
40 por ciento del tiempo de una persona.
24. 5. Aunque agregar personal a un proyecto de software retrasado puede retrasarlo ms,
existen circunstancias en las cuales esto no es cierto. Descrbanse.
24. 6. La relacin entre personal y tiempo es enormemente no lineal. Mediante la ecuacin del
software de Putnam (descrita en la seccin 24.2.2), desarrollar una tabla que relacione el nme-
ro de personas con la duracin del proyecto para un proyecto de software que requiera 50 000
LDC y 15 personas-ao de esfuerzo (el parmetro de productividad es 5 000). Supngase que el
software debe entregarse en un mximo de 24 meses o en un mnimo de 12.
24. 7. Suponga que una universidad lo ha contratado para desarrollar un sistema de registro en
lnea a cursos (SRELC). Primero, acte como el cliente (si es estudiante, esto debe ser sencillo!)
y especifique las caractersticas de un buen sistema. (Alternativamente, su instructor le propor-
cionar un conjunto de requisitos preliminares para el sistema.) Por medio de los mtodos de
estimacin tratados en el captulo 23, desarrolle una estimacin del esfuerzo y la duracin pa-
ra el SRELC. Sugiera cmo:
a) Definira las actividades de trabajo paralelas durante el proyecto de SRELC.
b) Distribuira el esfuerzo a lo largo del proyecto.
c) Establecera hitos para el proyecto.
24. 8. Seleccione un conjunto de tareas apropiado para el proyecto del SRELC.
24. 9. Defina una red de tareas para el SRELC o, alternativamente, para otro proyecto de soft-
ware que le interese. Asegrese de mostrar las tareas e hitos y de vincular las estimaciones de
esfuerzo y duracin a cada tarea. Si es posible, utilice una herramienta automatizada de calen-
darizacin para realizar este trabajo.
24. 10. Si est disponible una herramienta automatizada de calendarizacin, determine la tra-
yectoria crtica para la red definida en el problema 24.9.
2 4 . 1 1 . Mediante una herramienta de calendarizacin (si est disponible) o papel y lpiz (si es
necesario), desarrolle un cronograma para el proyecto del SRELC.
2 4 . 1 2 . Suponga que es gestor de proyectos de software y que se le ha pedido calcular las es-
tadsticas del valor ganado de un pequeo proyecto El proyecto tiene planeadas 56 tareas de
trabajo que se estima requerirn 582 personas-da para completarse. En el momento en que se
le pide realizar el anlisis del valor ganado. 12 tareas se han completado. Sin embargo, la ca-
lendarizacin del proyecto indica que se tenan que haber completado 15. Estn disponibles los
siguientes datos de la calendarizacin (en personas-da):
Tarea Esfuerzo previ st o E s t e r r e d
1 12.0 12.5
TM
PDF Editor
Toreo Es f ue r z o pr e vi s t o Es f uer zo r eal
2 15.0 11.0
3 13.0 17.0
4 8.0 9.5
5 9.5 9.0
6 18.0 19.0
7 10.0 10.0
8 4.0 4.5
9 12.0 10.0
10 6.0 6.5
11 14.0 4.0
12 14.0 14.5
13 16.0
14 6.0
15 8.0

Calcule el IDCa, la varianza de calendarizacin, el porcentaje calendarizado para terminacin
el porcentaje completado, IDCo y la varianza de costo para el proyecto.
Casi cualquier libro acerca de gestin de proyectos de software contiene una exposicin de la
calendarizacin. El Project Management Institute (PMBOK Gu i de, PM1, 2001), Wysoki y sus co-
legas (E f f ecti v e Proj ect Man ag emen t, Wiley, 2000), Lewis (Proj ect Plan n i n g Schedu li n g an d C on -
trol, 3a. ed McGraw-Hill, 2000), Bennatan (On Ti me, Wi thi n Bu dg et: Sof tw are Proj ect
Man ag emen t Practi ces an d Techn i qu es, 3a. ed., Wiley, 2000), McConnell (Sof tw are Proj ect C ost
Su rv i v al Gu i de, Microsoft Press, 1998) y Roetzheim y Beasley (Sof tw are Proj ect C ost an d Schedu le
E sti mati n g : Best Practi ces, Prentice-Hail, 1997) contienen anlisis valiosos del tema. Boddie
(Crunch Mode, Preniice-Hall, 1987) ha escrito un libro para todos los gestores que "tienen 90
das para hacer un proyecto de seis meses".
McConnell (Rapi d Dev elopmen t, Microsoft Press, 1996) presenta una excelente exposicin de
los conflictos que conducen a calendarizaciones de proyectos de software demasiado optimis-
tas y qu puede hacer acerca de ello. O'Connell (How to Ru n Su ccessJu I Proj ects II: The Si lv er
Bu llet, Prentice-Hall, 1997) presenta un enfoque paso a paso para la gestin de proyectos que
le ayudar a desarrollar una calendarizacin realista para sus proyectos.
Webb y Wake (Usi n g E arn ed Valu : A Proj ect Man ag er's Gu i de, Ashgate Publishing, 2003) y
Fleming y Koppelman (E arn ed Valu Proj ect Man ag emen t, Project Management Institute Publi-
cations, 1996) examinan con considerable detalle el uso de las tcnicas del valor ganado para
planificacin, seguimiento y control de proyectos.
En Internet hay disponible una gran variedad de fuentes de informacin acerca de la calen-
darizacin de proyectos de software. Una lista actualizada de referencias de la World Wide
Web se puede encontrar en el sitio Web de SEPA:
TM
PDF Editor
C A P I T U L O
GESTI N
DEL RI ESGO
C O N C E P T O S
CLAVE
alegoras
:eriesgos . . . . 749
trategin
rooctiva 748
Ktrotegia
ctivo 748
tratacin . . . . 7 57
exposicin
riesgo 757
fcitificocin . .750
vincipios 750
inyeccin 754
-ffinomiento.. .762
KG 761
Hgsridad
i riesgos 763
ta
e riesgos 755
E
n su libro acer ca del anl i si s y la gest i n del riesgo, Robert Char et t e
(CHA891 pr es ent a una definicin concept ual de riesgo:
En primer lugar, el riesgo se relaciona con ios acontecimientos futuros. El hoy y el
ayer estn ms all de esta relacin, pues ya se ha cosechado lo que previamente se
sembr con nuestras acciones pasadas. La pregunta es: podemos, por tanto, al cam-
biar nuestras acciones presentes, crear en lo futuro una oportunidad para una situa-
cin diferente, y esperanzadoramente mejor, para nosotros mismos? Esto significa,
en segundo lugar, que el riesgo implica cambio, como cambios de mentalidad, opi-
nin, acciones o lugares... [en tercer lugar] el riesgo implica eleccin y la incertidunv
bre que sta conlleva. Por ende, paradjicamente, el riesgo, al igual que la muerte y
los impuestos, es una de las pocas certezas en la vida.
Cuando el ri esgo s e consi der a en el cont ext o de la i ngeni er a del sof t war e, l as
t res bas es concept ual es de Char et t e si empr e se evi denci an. El f ut ur o es una
pr eocupaci n de pr i mer or den: qu ri esgos caus ar an que el pr oyect o de soft -
war e sal ga mal ? El cambi o es una pr eocupaci n cent ral : cmo af ect ar n la
act ual i dad y el xi t o gl obal los cambi os en los requi si t os del cliente, las t ecnol o-
g as de desarrol l o, los ent or nos que s e t i enen c omo obj et i vo y t odas las ot r as en-
tidades vi ncul adas con el proyecto? Por ltimo, es necesar i o enfr ent ar las opci ones:
qu mt odos y her r ami ent as s e deben usar, cunt a s pe r s ona s deben est ar in-
vol ucr adas, cunt o nf asi s sobr e la cal i dad es "suficiente"?
Peter Drucker [DRU75] dijo una vez: "Aunque es vano i nt ent ar el i mi nar el
riesgo, y cuest i onabl e i nt ent ar mi ni mi zarl o, e s esenci al que los riesgos t oma dos
s e a n los riesgos correct os". Ant es de i dent i fi car l os "ri esgos cor r ect os" que s e to-
mar n dur ant e un pr oyect o de sof t war e, es i mpor t ant e i dent i fi car los r i esgos que
son obvi os par a l os ges t or es y pr of esi onal es.
Q u e s ? El anl i s i s y la gest i n del
r i esgo s on una ser i e d e pa s os q u e
a y u d a n a un e q u i p o de s of t war e o
c ompr e nde r y ma n e j a r la i ncer t i dum-
br e. Muc hos pr obl e ma s pue de n des-
b o r d a r un pr oyect o d e s of t war e. Un r i es go es un
p r o b l e ma pot enci al : p u e d e ocur r i r o no. Pero,
sin i mpor t ar el r es ul t ado, en r e a l i da d es J- C
b u e n a i de a i dent i fi car l o, e va l ua r la pr obabi l i -
d a d d e q u e oc ur r a , es t i mar su i mpact o y es t abl e-
cer un pl an d e cont i ngenci a e n c a s o d e q u e el
pr obl e ma se pr es ent e.
Qui n l o ha c e ? Todos los involucrados en el
pr oc e s o d e s of t war e ( gest or es, i ngeni er os y pa r -
t i ci pant es) i nt er vi enen e n el anl i s i s y la gest i n
del r i esgo.
Por qu e s i mpor t ant e ? Pinsese en el lema
d e los boy scou t: "est ar p r e p a r a d o " . El s of t war e
e s u n a e mp r e s a difcil. Muc ha s c os a s p u e d e n s a-
lir rrio: y. Ronc a me nt e , c on mu c h a f r ecuenci a lo
747
TM
PDF Editor
hacen. Por esta r azn estar pr e pa r a dos (al com-
pr ender los riesgos y t omar medi das proact i vas
pa r a evitarlos o gestionarlos) es un el ement o cla-
ve de una buena gestin d e proyecto de software.
Cul es s on l os pa s o s ? Reconocer qu puede
salir mal es el pri mer pas o, l l amado "identifica-
cin del riesgo". A cont i nuaci n $e anal i za ca-
d a r i esgo pa r a det er mi nar la pr obabi l i dad de
que ocurri r y el d a o que caus ar si en efect o
ocurre. Una vez est abl eci do esta i nformaci n,
los riesgos se clasifican segn su pr obabi l i dad e
i mpact o. Finalmente, se desarrol l a un pl an pa r a
gest i onar aquel l os riesgos con gr an probabi l i -
d a d y al t o impacto.
Cul e s el product o obt e ni do? Se produce
un pl an de reducci n, supervisin y gestin del
ri esgo (RSGR) o un conj unt o de hoj as informati-
vas de riesgo.
he c ho correct ament e? Los riesgos que se
anal i zan y gest i onan deben pr oceder de un es-
t udi o ampl i o del per sonal , el product o, el proce-
so y el proyecto. El pl an RSGR de be revisarse
conf or me el proyect o a va nz a pa r a as egur ar s e
de que los riesgos est n act ual i zados. Los pl anes
de cont i ngenci a pa r a la gest i n del riesgo deben
, ser realistas.
2 5 . 1 ESTRATEGI AS PE RI ESGO REACTI YAS Y P RP ACTI YAS
Las est rat egi as de riesgo react i vas han si do j ocosament e denomi nadas la "escuela
Indiana Jones de gestin del riesgo" [TH092]. En l as pelculas de la dcada de 1980
que l l evaban su nombre, Indiana Jones, cuando enf r ent aba al guna dificultad abru-
mador a, i nvari abl ement e deca: "No te preocupes, pensar en algo!". Al no preocu-
parse nunca por los probl emas, si no hast a que ocurr an, Indy r eacci onaba en algu-
na forma heroica.
"Si usted no at et a act i vament e los riesgos, ellos lo at acar n ort i vament e. "
Tom Gilb
Tristemente, el gest or pr omedi o de proyect os de sof t war e no es Indiana Jones, .
los mi embr os del equi po de proyect o de sof t war e no son s us confi abl es compae-
ros. Ms an, la mayora de los equi pos de soft ware se apoya excl usi vament e en las
est rat egi as de riesgo reactivas. Los riesgos se apar t an para tratarlos, lo que puede
convertirlos en pr obl emas reales. Ms usual ment e, el equi po de sof t war e no hace
nada acerca de los riesgos hast a que algo sal e mal. Ent onces el equi po se precipita
en la accin con la finalidad de corregir el probl ema rpi dament e. Con frecuencia a
est o s e le llama el modo bombero. Cuando est o falla, la "gestin de crisis" [CHA92
as ume el control y el proyect o est en un verdadero peligro.
Una estrategia consi der abl ement e m s inteligente para la gestin del riesgo es ser
proactivo. Una est rat egi a proactiva comi enza mucho ant es de que se inicie el traba-
jo tcnico. Se identifican los riesgos pot enci al es, s e val oran su probabilidad e impac-
to, y se les clasifica segn su importancia. Luego, el equi po de sof t war e est abl ece ur
plan para gest i onar el riesgo. El objetivo principal es evitar el riesgo, per o debi do a
que no t odos los ri esgos pueden evitarse, el equi po t rabaj a para desarrol l ar un plan
TM
PDF Editor
de contingencia que le permitir responder en una forma controlada y efectiva. A lo lar-
go del resto del captulo se exami na la estrategia proactiva para la gestin del riesgo.
Qu tipos
de riesgos
s probable
cont r ar
f or me se
oNKtruye
soft ware?
Aunque hay un consi derabl e debat e en t orno a la definicin propia para el riesgo de
soft ware, existe un acuer do general en que el riesgo si empr e involucra dos caract e-
rsticas [HIG95] :
In certi du mbre: el riesgo puede o no ocurrir; est o es, no existen riesgos 100%
probables. 1
Prdi da: si el riesgo se convi ert e en realidad, ocurrirn consecuenci as o prdi-
das i ndeseabl es.
Cuando se anal i zan los riesgos es i mport ant e cuantificar el grado de i ncert i dumbre
y el grado de prdi da asoci ado con cada riesgo. Esto se logra consi der ando diferen-
t es cat egor as de riesgos.
Los ri esg os del proyecto a me na z a n el plan del proyecto. Es decir, si los riesgos del
proyect o se vuelven real es es probabl e que la cal endari zaci n del proyect o se altere
y que los cost os aument en. Los riesgos del proyect o identifican pot enci al es probl e-
ma s en presupuest o, cal endari zaci n, personal (plantillas y organi zaci n), recursos,
part i ci pant es y requisitos, y su i mpact o sobr e un proyect o de soft ware. En el captu-
lo 23 la compl ejidad, t amao y gr ado de i ncert i dumbre estructural del proyect o t am-
bin se definieron como fact ores de riesgo del proyect o (y de la estimacin).
Los ri esg os tcn i cos a me na z a n la calidad y actual idad del sof t war e que s e produ-
cir. Si un riesgo t cni co se vuelve real, la i mpl ement aci n se t orna difcil o imposi-
ble. Los riesgos t cni cos identifican pot enci al es pr obl emas en di seo, i mpl ement a-
cin, interfaz, verificacin y mant eni mi ent o. Adems, t ambi n son fact ores de ries-
go la ambi gedad de la especificacin, la i ncert i dumbre tcnica, la obsol escenci a
t cni ca y la t ecnol og a "de punta". Los riesgos t cni cos ocurren porque el probl ema
es ms difcil de resolver de lo que en un principio se pens que sera.
Los ri esg os de n eg oci os a me na z a n la viabilidad del sof t war e que se construir. Es-
tos riesgos con frecuencia ponen en peligro el proyecto o el producto. Los candi dat os
para los cinco mayor es riesgos de negoci os son 1) la const rucci n de un pr oduct o o
si st ema excel ent e que en realidad nadi e qui ere (riesgo de mercado), 2) la const ruc-
cin de un product o que ya no encaj a en la est rat egi a comerci al global de la compa-
a (riesgo de estrategia), 3) la const rucci n de un product o que la fuerza de vent as
no sabe cmo vender (riesgo de vent as 4) la prdida del apoyo de los al t os ejecuti-
vos debi do a un cambi o en el enf oque o en el personal (riesgo administrativo), y 5)
la prdida presupuest ari a o del per sonal asi gnado (riesgo presupuesta!).
1 Un riesgo 100 por ciento probable es una socre e! proyecto de software
TM
PDF Editor
Es ext r emadament e i mport ant e dest acar que la si mpl e clasificacin de los riesgos
no si empr e funci ona. Al gunos riesgos si mpl ement e son impredecibles.
Charette [CHA89] ha pr opuest o otra cat egori zaci n general de los riesgos. Los
ri esg os con oci dos son aquel l os susceptibl es de descubri rse despus de una evalua-
cin cui dadosa del pl an del proyecto, del ent or no de negoci os y tcnico dent r o de los
cual es se desarrol l ar el proyecto, y ot ras fuent es de i nformaci n confi abl es (por
ejemplo, fechas de ent rega irreales, falta de requisitos document ados o de mbi t c
del soft ware, pobre ent or no de desarrollo). Los ri esg os predeci bi es se ext rapol an de
la experiencia con proyect os previos (por ejempl o, cambi os en el personal , mal a co-
muni caci n con el cliente, disminucin del esf uer zo del personal conf or me se atien-
den las solicitudes de mant eni mi ent o). Los ri esg os i mpredeci bles son el comod n de
la baraj a. Pueden y de hecho ocurren, per o son ext r emadament e difciles de identi-
ficar con antel acin.
INFORMACIN
Si ete pri n ci pi os de la g esti n de ri esg os
' El Software Engineering Institute (SEI) (www.
sei.cmu.edu) identifica siete principios que "ofre-
cen un marco de trabajo para lograr una gestin de ries-
gos efectiva". Dichos principios son:
Mantenimiento de una perspectiva global: ver
los riesgos de software dentro del contexto del sistema en
el que est un componente y el problema de negocios que
se intenta resolver.
Tener una visin previsora: pensar en los riesgos
que pudieran surgir en lo futuro (por ejemplo, debido a
cambios en el software); establecer planes de contingencia
de modo que los eventos futuros sean manejables.
Alentar la comunicacin abierta: si alguien estable-
ce un riesgo potencial, no lo descarte. Si un riesgo se pro-
pone de una manera informal, considrelo. Aliente a todos
los participantes y usuarios a sugerir riesgos en cualquier
momento.
Integraci n: en el proceso del software debe estar inte-
grada una consideracin de los riesgos.
Enfatizar un proceso continuo: el equipo debe estar
atento a lo largo de todo el proceso de software, modificar
los riesgos identificados conforme se tenga ms informa-
cin y agregar unos nuevos a medida que se logre un me-
jor criterio.
Desarrollo de una visin conjunta del producto:
si todos los participantes comparten la misma visin del
software, es probable que ocurra mejor identificacin y
evaluacin de riesgos.
Alentar el trabajo en equipo: los talentos, habilida-
des y conocimiento de los participantes se deben mezclar
cuando se lleven a cabo actividades de gestin de riesgos.
La identificacin de los riesgos es un intento si st emt i co encami nado a especificar
las a me na z a s al plan del proyect o (estimaciones, cal endari zaci n, carga de recursos,
etc.). Al identificar los riesgos conoci dos y predecibies, el gest or del proyect o da un
pri mer paso para evitarlos cuando es posible y a control arl os cuando es necesari o.
Existen dos tipos distintos de riesgos para cada una de las cat egor as que se han
pr esent ado en la secci n 25.2: los riesgos genri cos y los riesgos especficos del pro-
ducto. Los ri esg os g en ri cos son una amenaza potencial para t odo el proyect o de
soft ware. Los ri esg os especf i cos del produ cto los pueden identificar slo aquel l os con
TM
PDF Editor
CAPTULO 25 GESTIN DEL RIESGO
751
un cl aro conoci mi ent o de la tecnologa, el personal y el ent or no especfico del soft wa-
re que se construir. Los riesgos especficos del product o se identifican exami nando el
pl an del proyect o y la decl aracin del mbi t o del soft war e, as como desarrol l ando
una respuest a para la siguiente pregunt a: "Qu caract er st i cas especi al es de est e
product o podran amenazar el pl an del proyecto?".
"Los proyectos sin riesgos reoles son perdedores. Estos proyectos cosi si empre est n desprovistos de beneficios; por
ello no fuer on real izados aos ot ras. "
Tom DeMarco y Tim Uster
^CONSEJO^-
krqu e es i mpoi tan te
:ysi deror los ri esg os
en ti cos, los ri esg os
i sx cUkos del
:mdu cto son los qu e
j o m a n lo mayora
i los dolores de
ateza. Aseg rese de
rmpfeflf ti empo pora
efenlifkar ton tos
v sg os especf i cos del
mdu cto como sea
x sMe.
Un mt odo para identificar riesgos consi st e en crear una lista de verificacin de
riesgos. Con sta se pueden identificar riesgos y enfocarse en algn subconj unt o de ries-
gos conoci dos y predecibl es en las si gui ent es subeat egor as genri cas:
Tamao del produ cto: riesgos asoci ados con el t amao global del soft ware que
se const rui r o modi fi car.
Impacto en el n eg oci o: riesgos asoci ados con l as restricciones que i mpone la
gerencia o el mer cado.
C aractersti cas del cli en te: riesgos asoci ados con la sofisticacin del cliente y la
habilidad del desarrol l ador para comuni car se con l en una forma opor t una.
Def i n i ci n de! proceso: riesgos asoci ados con el grado en el que se ha definido
el pr oceso de sof t war e y en que le da segui mi ent o la organi zaci n que lo de-
sarrolla.
E n torn o de desarrollo: riesgos asoci ados con la disponibilidad y calidad de las
her r ami ent as que se usar n en la const rucci n del producto.
Tecn olog a qu e con stru i r: riesgos asoci ados con la compl ejidad del si st ema que
se const rui r y la "novedad" de la tecnologa que est empaquet ada en el sis-
t ema.
Tamao y ex peri en ci a de la plan ti lla de person al: riesgos asoci ados con la expe-
riencia global tcnica y en el proyect o de l os i ngeni eros de soft ware que har n
el t rabaj o.
La lista de verificacin de riesgos se puede organi zar en di ferent es formas. Las pre-
gunt as relevantes respect o de cada uno de los tpicos se pueden responder para
cada proyect o de soft ware. Las r espuest as a est as pr egunt as permi t en que el plani-
ficador est i me el i mpact o del riesgo. Un for mat o di ferent e de lista de verificacin de
riesgos si mpl ement e menci ona l as caractersticas rel evant es para cada subeat egor a
genrica. Finalmente, se menci ona un conj unt o de "component es y cont rol adores de
riesgo" [AFC88] junto con su probabilidad de ocurrencia. Los cont rol adores del de-
sempeo, soporte, cost o y cal endari zaci n se est udi an como respuest a a las l t i mas
pregunt as.
TM
PDF Editor
El proyecto
de soft war e
en el que actual-
mente trabaja
enfrenta riesgos
serios?
B j g g g a g g
| M radares uno b a s e !
henami ent ns que
ayudan o los gestores :
o identificar, dosificar y
comunico! los riesgos
de proyecto. 5B puede
encont raren '<<
www.fpmn.com. |
En la bi bl i ograf a s e ha n pr opue s t o var i as l i st as de ver i fi caci n det al l adas par a
r i esgos del pr oyect o de s of t wa r e (por ej empl o, [SEI93], [KAR96]), l as cual es pr opor -
ci onan una vi si n til de l os r i esgos genr i cos par a pr oyect os de s of t war e, y s e de-
ben us a r s i e mpr e que s e i nst i t uyan anl i si s y ges t i n del r i esgo. Si n e mba r go, s e pue-
de e mpl e a r una lista r el at i vament e cor t a de pr e gunt a s [KE198] par a pr opor ci onar un
i ndi ci o pr el i mi nar de si un pr oyect o est "en r i esgo".
25.3.1 Evaluacin del riesgo global del proyecto
Las s i gui ent es pr e gunt a s s e b a s a n en l os dat os de r i esgo obt eni dos al ent r evi st ar , en
di f er ent es par t es del mundo, a ge s t or e s de pr oyect o de s of t wa r e e xpe r i me nt a dos
[KEI98]. Las pr e gunt a s e s t n or de na da s s e gn s u i mpor t anci a r el at i va e n el xi t o de
un pr oyect o.
1. Los al t os ej ecut i vos de s of t wa r e y del cl i ent e s e han c ompr ome t i do f or mal -
M
pa r a apoyar el pr oyect o?
s uar i os finales e s t n c ompr ome t i dos con el pr oyect o y el s i s t e ma / pr o-
duct o q u e s e cons t r ui r ?
3 . Los r equi si t os l os ha n ent endi do c ompl e t a me nt e el equi po de i ngeni er a de
s of t wa r e y s us cl i ent es?
4 . Los cl i ent es es t uvi er on c ompl e t a me nt e i nvol ucr ados en la def i ni ci n de l os
r equi si t os?
5. Los us uar i os finales t i enen expect at i vas r eal i st as?
6. El mbi t o del pr oyect o e s es t abl e?
7. El e qui po de i ngeni er a del s of t wa r e t i ene la mezcl a cor r ect a de habi l i dades?
8. Los r equi si t os del pr oyect o s on est abl es?
9 . El e qui po del pr oyect o t i ene exper i enci a con la t ecnol og a que s e i mpl e me n-
t ar ?
10. El n me r o de pe r s ona s en el equi po de pr oyect o e s a de c ua do par a r eal i zar e'.
t r abaj o?
11. Todos los vot a nt e s del cl i e nt e / us ua r i o e s t n de a cue r do en la i mpor t anci a
del pr oyect o y e n l os r equi si t os par a el s i s t e ma / pr oduc t o que s e const r ui r ?
"La gest i n d e ri esgos e s la gest i n de pr oyect os pa r a adul t os . "
Ti m Li s t e r
Si la r es pues t a a a l guna de e s t a s pr e gunt a s e s negat i va s e de be n i nst i t ui r si n de mo-
ra l os pa s os de r educci n, super vi si n y gest i n. El gr ado en el que el pr oyect o est
en r i esgo e s di r e ct a me nt e pr opor ci onal al n me r o de r e s pue s t a s negat i vas a es t as
pr egunt as .
TM
PDF Editor
753
25.3.2 Componentes y controladores del riesgo
La Fuerza Area de Estados Unidos [AFC88] escribi un folleto con excel ent es direc-
trices para la identificacin y supresi n del riesgo de soft war e. Este enf oque requie-
re que el gest or del proyect o identifique los cont rol adores del riesgo que afect an l os
component es de riesgo del soft ware: desempeo, costo, soport e y cal endari zaci n.
En el cont ext o de est e est udi o los component es de riesgo se defi nen en la forma si-
guiente:
Ri esg o de desempeo: gr ado de i ncert i dumbre de que el pr oduct o sat i sfaga los
requisitos y se aj ust e al uso que se pr et ende darle.
Ri esg o de costo: gr ado de i ncert i dumbre de que s e mant enga el pr esupuest o
del proyecto.
Ri esg o de soporte: grado de i ncert i dumbre de que el soft ware resul t ant e ser
fcil de corregir, adapt ar y mej orar.
\ ^Compone nt e s
Categora N .
Desempeo Soporte Costo Calendarizacin
Catastrfico
T
El f r acaso en la satisfaccin d e los
requisitos resultara en un f r acas o d e
la misin
El f r acaso resulta en el aument o d e costos
y en de mor a s en la cal endar i zaci n con
valores es per ados que super an 50QK dls.
Catastrfico
2
Ci ert a reducci n
en el des empeo
t cni co
Soft war e que no
r esponde o no se
puede soportar
Recortes fi nanci eros
significativos,
pr obabl e superaci n
del pr esupuest o
COI
i nal canzabl e
Crtica
1
El f r acas o p a r a sat i sfacer los requisitos
resultara en un de s e mpe o de gr a da do
del sistema hast a un punt o donde el xito
d e to misin es cuest i onabl e
El f r acas o resulta en de mor a s operat i vos
o i ncrement o de costos con valor espe-
r ado d e 100K a 500K dl ar es
Crtica
2
Ci ert a reducci n
en el des empeo
t cni co
Demor as menor es en
las modi fi caci ones
del soft ware
Cierto recorte d e
recursos fi nanci eros,
posi bl es excesos
Posible
desl i zami ent os
en la COI
Marginal
1
El f r acas o p a r a satisfacer los requisitos
resultara en degr adaci n de la misin
secundar i o
Deslizamiento d e costos, i mpact os o
cal endar i zaci n re cuper abl e con valor
e s pe r a do d e 1K a 100K dl ar es
Marginal
2
Mnima a pe que a
reducci n en el
des empeo tcnico
Respuesta d e
soporte d e
soft ware
Suficientes recursos
fi nanci eros
Cal endar i zaci n
a l ca nz a bl e
y realista
Despreciable
1
El f r acas o al sat i sfacer los requisitos
cr ear a inconvenientes o i mpact os no
operat i vos
El error resulta en cost o menor o
i mpact o en la cal endar i zaci n con
valor e s pe r a do d e menos d e 1K dl ar es
Despreciable
2
Ni nguna reducci n
en el des empeo
tcnico
Soft war e al que
fcil mente se le
da soport e
Posible supervit
presupuest a!
COI
fcilmente
al canzabl e
Nota: 1 . Consecuencia potencial de errores o (ollas de software no deteclados.
2. Consecuencia potencial si el resultado des eado no s e al canzo.
TM
PDF Editor
Ri esg o de calen dari zaci n . - grado de i ncert i dumbre de que se mant enga la ca-
l endarizacin del proyect o y de que el product o se ent r egue a tiempo.
El i mpact o de cada cont rol ador de riesgo sobre el component e de riesgo se divide en
cuat ro cat egor as de i mpact o: despreciable, margi nal , crtico o catastrfico. En la fi-
gura 25.1 [BOE89] se descri be una caract eri zaci n de las consecuenci as potencial es
de los er r or es (hileras et i quet adas 1) o una falla que no permi t e lograr un resul tado
deseado (hileras et i quet adas 2). La categora de i mpact o se escoge con bas e en la ca-
racterizacin que mej or encaj e con la descripcin en la tabla.
La proyecci n del ri esg o, t ambi n l l amada esti maci n del ri esg o, i nt ent a clasificar ca-
da riesgo en dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real, j
2) las consecuenci as de los pr obl emas asoci ados con el riesgo, en caso de que ocu-
rra. El planificador del proyecto, j unt o con ot ros gest ores y personal tcnico, realizar,
cuat ro pas os en la proyeccin del riesgo:
1. Establ ecimiento de una escal a que refleje la posibilidad percibida de un ries-
2 5 . 4 P BOYE CC M RE . P I ES GO
go.
2. Del ineado de las consecuenci as del riesgo.
Ejemplo de
t abl a de ries-
gos antes de
l a clasifica-
cin.
La estimacin del tamao puede ser
significativamente baj a
Mayor nmero de usuarios de los previstos
Menos reutiltzacin que la prevista
Los usuarios finales se resisten al sistema
La fecha lmite de entrega estar muy ajustada
Prdida de fondos
El cliente cambiar requisitos
La tecnologa no satisfar las expectativas
Falta de entrenamiento acerca de las herramientas
Personal inexperto
Elevada movilidad del personal
Riesgos Categora Probabilidad Impacto RSGR
TP
TP
CO
CO
CL
TP
RT
ED
PE
PE
TP
3 0 %
7 0 %
4 0 %
5 0 %
4 0 %
80%
3 0 %
80%
3 0 %
60%
60% 2
3
2
3
2
2
3
2
2
Valores de impacto:
1: catastrfico
2: critico
3: marginal
4: despreciable
TM
PDF Editor
[ CONSEJO
! mu cho acerca
i aforare qu e est
i de con stru i r y
j u sted
o : qu pu ede
r v d? C ree su
l s t o y pi da o
s mi embros del
i qu e hag an lo
\
CLAVE
i toblo de ri esgos
or denada por
I yxobi l i da d e i mpact o
m s dosificar l os
s gos .
3. Estimacin del i mpact o del riesgo en el proyect o y el producto.
4. Tomar nota de la precisin global de la proyeccin del ri esgo de modo que no
haya mal as i nt erpret aci ones.
La finalidad de est os pas os es consi derar los riesgos en tal forma que conduzcan al
est abl eci mi ent o de prioridades. Ningn equi po de sof t war e tiene los recursos par a
enfr ent ar t odos los riesgos pot enci al es con el mi smo gr ado de rigor. Al priorizar los
ri esgos el equi po puede asi gnar los recursos donde t engan el mayor i mpact o.
25.4.1 Desarrollo de una tabl a de riesgos
Una tabla de riesgos ofrece al gest or de un proyect o una tcnica si mpl e para la pro-
yeccin de riesgos. 2 En la figura 25.2 se ilustra un ej empl o de tabla de riesgos.
Un equi po de proyect o comi enza una lista de t odos los riesgos (sin importar cun
r emot os sean) en la pri mera col umna de la tabla. Esto s e logra con la ayuda de la lis-
ta de verificacin de riesgos menci onada en la seccin 25.3. Cada riesgo s e clasifica
en la segunda col umna (por ejempl o, TP implica un riesgo de t amao del proyecto,
NE implica un riesgo de negocios). En la siguiente col umna de la tabla se registra la
probabilidad de que ocurra cada riesgo. El valor de la probabilidad de cada riesgo lo
pueden est i mar i ndi vi dual ment e los mi embr os del equipo. stos s e encuest an en una
forma de "todos cont ra todos" hast a que su eval uaci n de la probabilidad del riesgo
comi ence a convergir.
A cont i nuaci n se eval a el i mpact o de cada riesgo. Cada component e de riesgo
se eval a medi ant e la caracterizacin pr esent ada en la figura 25.1, y se det ermi na
una cat egor a de i mpact o. Las cat egor as para cada uno de los cuat ro component es
de riesgo (desempeo, soporte, cost o y cal endarizacin) se pr omedi an3 para deter-
mi nar un valor de i mpact o global.
Una vez compl et adas las cuat ro pr i mer as col umnas de la tabla de riesgos, sta se
or dena segn la probabilidad y el impacto. Los riesgos de al ta probabilidad y alto i m-
pact o se filtran hacia lo alto de la tabla, y los riesgos de baj a probabilidad caen al
fondo. Esto logra una priorizacin del riesgo de pri mer orden.
El gest or del proyect o est udi a la tabla or denada resul t ant e y defi ne una lnea de
corte. La ln ea de corte (dibujada hor i zont al ment e en al gn punt o en la tabla) impli-
ca que sl o los riesgos ubi cados sobre la lnea t endrn una at enci n posterior. Los
riesgos debaj o de la lnea se reeval an para lograr una priorizacin de s egundo or-
den. En la figura 25. 3 el i mpact o y la probabilidad de ri esgo influyen de maner a dis-
tinta en la gestin. Un factor de riesgo que tiene un alto impacto, pero una probabi -
lidad de que suceda muy baj a, no debe absor ber una cant i dad significativa de tiem-
2 Es posible implementar la tabla de nesgc-s como un modelo en hoja de clculo. Esto permite una
manipulacin sencilla y el ordenamiento de las er -.radas
3 El empleo de un promedio ponderado es facerle ; aign componente de riesgo tiene mayor rele-
vancia para un proyecto.
TM
PDF Editor
po de gestin. Sin embar go, l os riesgos de al t o i mpact o con moder ada a alta proba-i
bilidad y los riesgos de baj o i mpact o con alta probabilidad deben t rasl adarse a I on
pas os de anl i si s de riesgo que siguen.
Todos los riesgos ubicados sobre la lnea de corte deben gestionarse. La columr. i I
rotulada RSGR cont i ene una referencia que apunt a hacia un Plan de redu cci n , supe-
v i si n y g esti n de ri esg o o, al ternativamente, una coleccin de hoj as de i n f ormaci n de:
ri esg o desarrol l adas para todos los riesgos que est n sobre el corte. En las secciones;
25. 5 y 25.6 se exami nan el plan RSGR y las hojas de informacin de riesgo.
"[En la act ual i dad] nadi e t i ene el lujo de llegar a conocer una t ar ea t an bien que no se lleve sorpresas, y l as s or pr e s a
significan riesgo. "
La probabilidad del riesgo se det er mi na real i zando est i maci ones individuales r
l uego desarrol l ando un sol o valor de consenso. Aunque dicho enf oque es valioso, se:
han desarrol l ado t cni cas m s el abor adas con l as cual es det er mi nar la pr obabi l i ds:
del riesgo [AFC88], Los cont r ol ador es de ri esgo se pueden eval uar sobre una escala
de probabilidad cualitativa que tiene los si gui ent es valores: imposible, improbable
probabl e y frecuent e. Ent onces se asocia la probabilidad mat emt i ca con cada valer
cualitativo (por ej empl o, una probabilidad de 0.7 a 0. 95 implica un riesgo enorme
ment e probable).
Stephen Grey
Riesgo y
preocupaclo-
Muy alto
nes de la
gestin.
Impacto
Muy baj o
Relevancia
para la gestin
TM
PDF Editor
Cmo se
W valoran las
{secuencias de
riesgo?
25.4.2 Evaluacin del impacto del riesgo
Tres fact ores afect an las consecuenci as que son probabl es si un ri esgo ocurre: su na-
t ural eza, mbi t o y tiempo. La nat ur al eza indica los pr obl emas que son probabl es si
ocurre. Por ejempl o, una i nt erfaz ext erna mal definida haci a el har dwar e del cliente
(un riesgo tcnico) evitar un di seo y pr ueba t empr anos y tal vez gener e pr obl emas
de integracin de si st ema ms tarde. El mbi t o combi na la severidad (cun serio
es?) con su distribucin global (cunt o del proyect o se afect ar, o cunt os clientes
resul t arn daados?). Finalmente, el t i empo de un riesgo consi dera cundo y dur an-
te qu per i odo se sent i r el i mpact o. En la mayor a de los casos un gest or de proyec-
t o tal vez quiera que ocurran l as "mal as noticias" tan pront o como sea posible, per o
en al gunos casos, mi ent ras mayor sea la demor a, mejor.
Regresando una vez ms al enf oque de anl i si s de riesgo que pr opuso la Fuerza
Area de Est ados Unidos [AFC88], se r ecomi endan los si gui ent es pas os para det er-
mi nar las consecuenci as gl obal es de un riesgo:
1. Det ermi nar el valor pr omedi o de la probabilidad de que ocurra para cada
component e de riesgo.
2. Empl eando la figura 25.1, det er mi nar el i mpact o para cada component e, con
bas e en l os criterios most rados.
3. Compl et ar la tabla de riesgos y anal i zar los resul t ados como se descri be en l as
secci ones precedent es.
La ex posi ci n al ri esg o global, ER, se det er mi na medi ant e la siguiente relacin
[HAL98]:
ER = P x C
donde P es la probabilidad de que ocurra un riesgo, y C, el cost o al proyect o en ca-
s o de que ocurra el riesgo.
Por ejempl o, suponga que el equi po de soft ware define un riesgo de proyect o en
la forma siguiente:
Ident i f i caci n del riesgo. De hecho, sl o 70 por ci ent o de l os component es de
sof t war e cal endar i zados para reutilizacin se integra en la aplicacin. La funci ona-
lidad r est ant e t endr que desarrol l arse de modo personal i zado.
Probabi l i dad de riesgo. 80 por ci ent o (quiz).
I mpact o del riesgo. Se planificaron 60 component es de sof t war e reutilizables.
Si sl o s e puede empl ear el 70 por ciento, 18 component es tendran que desarrollar-
s e desde cer o (adems de ot ro sof t war e per sonal i zado que s e ha cal endar i zado pa-
ra desarrollo). Puest o que el component e pr omedi o es 100 LDC y l os dat os l ocal es
indican que el cost o de ingeniera del soft ware para cada uno es de 14.00 dl ares, el
cost o (impacto) global del desarrol l o de los component es sera 18 x 100 x 14 =
25 200 dlares.
Exposi ci n al riesgo. ER = 0.8C 25 200 dl ares - 20 200 dlares.
TM
PDF Editor
^ O N S E J O ^
C omprese la E R de
f odos los ri esg os con
lo esti maci n de costo
para el proyecto. Si la
E R es mayor qu e SO
por ci en to del costo
del proyecto, lo v i abi -
li dad del proyecto
debe leev alu arse.
La e xpos i c i n ai r i e s go s e p u e d e c a l c ul a r p a r a c a d a r i e s go e n la t a bl a d e r i e s gos
u n a v e z q u e s e e s t i me el c o s t o del r i es go. La e xpos i c i n al r i e s go t ot al pa r a t o d o s l os
r i e s gos ( s obr e la l nea d e c or t e e n la t abl a) p u e d e o f r e c e r u n me d i o c o n q u e a j us t a r
la e s t i ma c i n del c o s t o final d e u n pr oye c t o. Ta mb i n s e e mp l e a p a r a pr e de c i r el a u-
me n t o p r o b a b l e e n l os r e c u r s o s d e p e r s o n a l q u e s e r e q ui e r a n e n va r i os p u n t o s du
r a n t e la c a l e n d a r i z a c i n del pr oye c t o.
La pr oye c c i n del r i e s go y l a s t c n i c a s d e a n l i s i s de s c r i t a s e n l a s s e c c i o n e s 25. 4. 1
y 25. 4. 2 s e a pl i c a n d e ma n e r a i t er at i va c o n f o r me a v a n z a el p r o y e c t o d e s o f t wa r e . El
e q u i p o del p r o y e c t o d e b e r e vi s a r d e n u e v o la t a bl a d e r i e s gos e n i nt e r v a l os r e gul a
r es , r e e v a l u a r c a d a r i e s go p a r a d e t e r mi n a r c u n d o n u e v a s c i r c u n s t a n c i a s c a mb i a r n
s u pr oba bi l i da d e i mp a c t o . Co mo c o n s e c u e n c i a , t al v e z s e a n e c e s a r i o a g r e g a r nue -
v o s r i e s gos a la t a bl a , e l i mi na r a l g u n o s riesgos q u e a h o r a s o n i r r e l e v a nt e s y c a mb i a r
l a s p o s i c i o n e s r e l a t i va s d e ot r os .
Anlisis de riesgos
El escenari o: Oficina de Doug Mi-
> del proyecto de software Hog arSeg u ro.
: Doug Miller (gerente del equipo de inge-
del software Hog arSeg u ro) y Vinod Raman, Jamie
Lazar y otros miembros del equipo de ingeniera del soft-
ware del producto.
La convers aci n:
Doug: Me gustara pasar un poco de tiempo en uno llu-
via de ideas acerca de los riesgos que enfrenta el proyec-
to Hog arSeg u ro.
J a mi e ; Cmo en qu puede salir mal?
Doug: S. Aqu hay algunas categoras de dnde pue-
den salir mal las cosas. [Muestra a todos las categoras
anotadas en la introduccin de la seccin 25.3.]
Vi nod: Mmmmm... quieres que slo las mencionemos
o...?
Doug: No. Esto es lo que creo que debemos hacer. To-
dos hagan una lista de riesgos... ahora. . . .
(Pasan diez minutos; todos escriben.)
Doug: Muy bien, alto.
Jami e: (Pero no he terminado!
Doug: Est bien. Volveremos a ver las listas. Ahora, en ca-
da entrada de su lista, asignen un porcentaje de probabili-
dad de que el riesgo ocurrir. Luego, asignan un impacto al
proyecto en una escala de 1 (menor) a 5 (catastrfico).
Vi nod: As que si creo que el riesgo es como lanzar una
moneda, especifico un 50 por ciento de probabilidad, y
si creo que tendr un impacto de proyecto moderado, es-
pecifico un 3, cierto?
Doug: Exactamente.
(Pasan cinco minutos; todos escriben.)
Doug: Muy bien, alto. Ahora haremos una lista del gru-
po en el pizarrn. Yo escribir, dir una entrada de su
lista en formato de todos contra todos.
(Pasan quince minutos; se crea la lista.)
Jami e ( s eal a al pi zarrn y re): Vinod, ese res
go (apunta hacia una entrada en el pizarrn) es ridculo.
Existe una enorme probabilidad de que todos seamos
golpeados por un rayo. Debemos quitarlo.
Doug: No, dejmoslo por ahora. Consideremos todos
los riesgos, sin importar cun locos sean. Ms tarde ven-
tilaremos la lista.
Jami e: Pero ya tenemos casi 40 riesgos, cmo po
dremos manejar todos?
Doug: No podemos. Por eso definiremos una lnea de
corte despus de ordenar estas linduras. Yo har eso ms
tarde y nos reuniremos de nuevo maana. Por ahora re-
gresen a trabajar... y en su tiempo libre, piensen acerca
de cualquier riesgo que hayamos olvidado.
TM
PDF Editor
759
Durant e las pri meras et apas de la planificacin del proyect o se puede est abl ecer un
riesgo de maner a muy general . Confor me pasa el t i empo y s e apr ende m s acer ca
del proyect o y el riesgo, es posible refinar el riesgo en un conj unt o de riesgos m s
detallados, cada uno un poco ms sencillo de retinar, supervisar y gestionar.
Una forma de hacer est o es represent ar el riesgo en el format o con di ci n -tran si ci n -
con secu en ci a (CTC) [GLU94J. Es decir, el riesgo se est abl ece en la forma siguiente:
Dado que <condicin> entonces existe una preocupacin de que (posiblemente) cconse-
cuencia>
Mediante el empl eo del for mat o CTC en lugar del riesgo de reutilizacin anot ado en
la Seccin 25.4.2, se puede escribir:
Dado que todos los componentes de software reutilizables deben ajustarse con estnda-
res de diseo especficos, y como algunos no lo hacen, entonces existe una preocupacin
de que (posiblemente) slo 70 por ciento de los mdulos reutilizables planeados puedan
en realidad integrarse al sistema que se construir, lo que resulta en la necesidad de inge-
niera personalizada para el restante 30 por ciento de componentes.
Esta condicin general se puede refinar en la forma siguiente:
Subcondicin 1. Ciertos componentes reutilizables fueron desarrollados por terceras
personas sin conocimiento de los estndares de diseo internos.
Subcondicin 2. El estndar de diseo para el componente de interfases no se ha con-
cretado y tal vez no se ajuste con ciertos componentes reutilizables existentes.
Subcondicin 3. Ciertos componentes reutilizables se han implementado en un lengua-
je que no soporta el entorno destino.
Las consecuenci as asoci adas con est as subcondi ci ones refi nadas siguen si endo las
mi smas (es decir, 30 por ciento de los component es de sof t war e tienen que s ome-
terse a ingeniera personal i zada), per o el refi nami ent o ayuda a aislar los riesgos sub-
yacent es y puede conduci r a un anlisis y r espuest as ms sencillos.
Todas l as actividades del anl i si s de riesgo pr esent adas hast a el moment o tienen
una sola meta: ayudar al equi po del proyect o a desarrol l ar una est rat egi a para luchar
con el riesgo. Una est rat egi a eficaz debe consi derar t res temas-,
Evitar del riesgo.
Supervisar el riesgo.
Gestionar el riesgo y los pl anes de contingencia.
Si un equi po de sof t war e adopt a ur enfoque rroact i vo hacia el riesgo, evitarlo
si empr e es la mej or estrategia. sta se ogra es-arrollando un plan para reducir el
TM
PDF Editor
riesgo. Por ejempl o, supngase que una el evada movilidad en el personal se anat a
como un riesgo del proyecto, r, . Con bas e en la historia y la intuicin administrativa
la probabilidad, /,, de una el evada movilidad se est i ma en 0.70 (70 por ciento, mai
bien alta) y el impacto, x,, se proyecta como critico. Esto es: una t asa el evada de mc-
vilidad t endr un i mpact o crtico en el costo del proyecto y la cal endari zaci n.
"Si tomo demasi ados precauciones, es por que no dej o nada al ozar. "
Napolen
7 Q se
* puede hacer
para reducir un
riesgo?
Este riesgo se reduce si el gest or del proyecto desarrolla una est rat egi a para re-
ducir la movilidad. Entre los posibl e pas os que s e t oman se encuent ran:
Reuni rse con el personal act ual para det er mi nar las caus as de la movilidad
(por ejempl o, limitadas condi ci ones de t rabaj o, baj os sal arios, mer cado labo-
ral competitivo).
Reducir aquel l as caus as que se control an ant es de que comi ence el proyectc
Una vez iniciado el proyecto, suponer que la movilidad ocurrir y ent onces
desarrollar t cni cas que aseguren la cont i nui dad cuando la gent e se aleje.
Organi zar equi pos de proyect o de modo que la i nformaci n acer ca de cada
actividad de desarrollo se di sperse con ampl itud.
Definir est ndar es de document aci n y est abl ecer mecani smos que asegure -
que los document os se desarrol l en en una forma opor t una.
Llevar a cabo revisiones por par es de t odo el t rabaj o (de modo que ms de
una per sona est "en ritmo").
Asignar un mi embr o de personal de respal do por cada tecnol oga crtica
Conforme avanza el proyect o se inician las actividades de supervisin del ri esg: l l
gest or del proyect o supervisa l os fact ores que pueden proporci onar un indicio ct a
el riesgo se est vol viendo ms o menos probabl e. En el cas o de la el evada t as ;
movilidad del personal , se pueden supervi sar los si gui ent es factores:
Actitud general de los mi embr os del equi po con base en l as pr esi ones del r e -
yer t o.
El gr ado en el cual el equi po est cuaj ado.
Las rel aci ones i nt erpersonal es ent re los mi embr os del equipo.
Potencial es pr obl emas con las compensaci ones y los beneficios.
La disponibilidad de empl eo dent r o y fuera de la compa a.
Adems de supervi sar est os factores, un gest or de proyect o debe supervisa-
efectividad de los pas os de reducci n del riesgo. Por ejempl o, un pas o de r educc. as
del riesgo anot ado l neas arriba pide la definicin de est ndar es de document a; :TI
TM
PDF Editor
f cONSEJ O^^
Si a E R paro u n
-> esg o especf i co es
-en or qu e el costo de
la redu cci n del
ri esg o, n o se i n ten te
'edu ci r el ri esg o si n o
con ti n u ar su perv i sn -
dolo.
y mecani smos para garant i zar que los document os se el aboran en forma oport una.
ste es un mecani smo para asegur ar la continuidad en caso de que un individuo cru-
cial abandone el equipo. El gestor del proyect o debe supervi sar l os document os cui-
dados ament e para asegur ar se de que cada uno puede per manecer por si sol o y que
cada uno cont i ene i nformaci n que sera necesari a si una nueva per sona se viera
obl igada a unirse al equi po de sof t war e en al gn mome nt o a la mitad del proyecto.
La gestin del riesgo y los pl anes de cont i ngenci a suponen que l os esf uer zos de
reducci n han f r acasado y que el riesgo se ha vuelto una realidad. Cont i nuando con
el ejempl o, el proyect o ya est bien avanzado y vari as per sonas anunci an que r enun-
ciarn. Si se ha segui do la est rat egi a de reduccin, el respal do est disponible, la in-
formaci n se ha document ado y el conoci mi ent o se ha di spersado ent re el equipo.
Adems, el gest or del proyect o puede r eenfocar t empor al ment e los r ecur sos (y rea-
justar la cal endari zaci n del proyecto) hacia aquel l as funci ones compl et ament e es-
t ruct uradas, as permi t e que l os nuevos el ement os que deben agr egar se al equi po
"t omen el ritmo". A los individuos que deciden mar char se se l es pide det ener t odo el
t rabaj o y pasar sus l timas s e ma na s "aprendi endo el modo de transferencia". Esto
puede incluir la adquisicin de conoci mi ent o en videos, el desarrol l o de "documen-
tos coment ados" o r euni ones con ot ros mi embr os del equi po que per manecer n en
el proyecto.
Es i mport ant e seal ar que l os pas os de reduccin, supervisin y gestin del ries-
go (RSGR) gener an cost os adi ci onal es en el proyecto. Por ejempl o, utilizar el t i empo
para "respaldar" cual qui er tecnol oga crtica cuest a dinero. Por lo t ant o, part e de la
gest i n del riesgo consi st e en eval uar cundo los benefi ci os que gener an los pasos
RSGR se r ezagan frente a los cost os asoci ados con su i mpl ement aci n. En esenci a,
el planificador del proyect o realiza un clsico anlisis cost o-benefi ci o. Si l os pas os
con que se evita el riesgo de el evada movilidad de personal aument ar an t ant o el cos-
t o del proyect o como su duracin en un est i mado de 15 por ciento, pero el factor de
cost o pr edomi nant e es el "respaldo", el gest or puede decidir no i mpl ement ar est e pa-
so. Por otra part e, si los pasos con que se evita el ri esgo s e proyect an para aumen-
t ar los cost os en 5 por ci ent o y la duraci n en sl o 3 por ciento, el gest or probabl e-
ment e pondr t odo en su lugar.
En un proyect o gr ande es posible definir 30 o 40 riesgos. Si para cada uno se iden-
tifican ent re t res y siete pas os de gestin del riesgo, sta puede convertirse por s
mi sma en un proyecto! Por est a r azn se adapt a la regla 80-20 de Paret o al riesgo
de soft war e. La experi encia indica que 80 por ci ent o del riesgo del proyect o global
(es decir, 80 por ci ent o del potencial para falla del proyecto) puede expl icarse sl o
con 20 por ci ent o de los riesgos identificados. El t rabaj o real i zado dur ant e los pri me-
ros pas os del anlisis de riesgo ayudar al planificador a det er mi nar cul es de l os
riesgos se encuent r an en ese 20 por ci ent o ipor ejempl o, riesgos que conduzcan a la
mayor exposicin al riesgo). Por esta razn al gunos de los riesgos identificados,
eval uados y proyect ados pueden no incluirse en el pl an RSGR, ya que no s e ubican
en el crtico 20 por ci ent o (los riesgos con a iayor prioridad de proyecto).
TM
PDF Editor
Un vol umi noso archivo
que cont i ene l odos los
ent rados del Foro ACM
acerca de Riesgos al
Pblico s e pue de
e ncont r a r e n
c a t l e s s . ml . a c . u k /
Ri s ks .
El riesgo n o e s t l i mi t a do al p r o y e c t o d e s o f t wa r e . Los riesgos p u e d e n oc ur r i r de s -
p u s de q u e el s o f t wa r e s e h a d e s a r r o l l a d o e x i t o s a me n t e y e n t r e g a d o al cl i e nt e . Es-
t os riesgos e s t n t p i c a me n t e a s o c i a d o s c on l as c o n s e c u e n c i a s d e la fal l a d e s o f t wa -
r e e n el c a mp o .
El an li si s de seg u ri dad y peli g ros de sof tw are [LEV95] s o n a c t i v i da de s d e a s e g u r a -
mi e n t o d e la ca l i da d del s o f t wa r e ( cap t ul o 26) q u e s e e n f o c a n en la i de nt i f i ca ci n y
e v a l u a c i n d e l os pe l i gr os p o t e n c i a l e s q u e p u d i e r a n a f e c t a r al s o f t wa r e ne ga t i v a -
me n t e y p r o v o c a r u n a f al l a e n t o d o el s i s t e ma . Si l os pe l i gr os s e p u e d e n i dent i f i car
t e mp r a n o e n el p r o c e s o d e i nge ni e r a del s o f t wa r e , l a s c a r a c t e r s t i c a s d e d i s e o d e
s o f t wa r e s e p u e d e n e s pe c i f i c a r d e mo d o q u e e l i mi ne n o c o n t r o l e n l os pe l i gr os po-
t e nci a l e s .
Hoj a d e infor-
ma c i n del
r i esgo
[WIL97],
Hoja de informacin del riesgo
ID de riesgo: P02-4-32 Fecha: 9 / 5 / 0 4 Prob: 80% Impacto: alto
Descripcin:
Slo 70 por ciento de los componentes de software calendarizados paro
reutilizacin de hecho se integrarn en la aplicacin. La funcionalidad restante
tendr que desarrollarse de manera personalizada.
Refinamiento/contexto:
Subcondicin 1: Ciertos componentes de reutilizacin fueron desarrollados por un
tercer participante sin conocimiento de los estndares de diseo internos.
Subcondicin 2: El estndar de diseo para los componentes de interfaces no ha
sido solidificado y tal vez no concuerden con ciertos componentes reutilizables existentes.
Subcondicin 3: Ciertos componentes reutilizables se han implementado en un
lenguaje que no soporta el entorno destino.
Reducci n/ super vi si n:
1. Contactar con el tercer participante para determinar la concordancia con los
estndares de diseo.
2. Presionar para completar los estndares de interfaz; considerar la estructura del
componente cuando se decida acerca del protocolo de la interfaz.
3. Verificar para determinar el nmero de componentes en la categora 3 de
subcondicin; verificar para determinar si se puede adquirir el soporte para el
lenguaje.
Gestin/pl an de contingencia/disparador:
La ER se calcula en 20 200 dlares. Asignar esta cantidad dentro del costo de
contingencia del proyecto.
Desarrollar una calendarizacin revisada suponiendo que se tendrn que construir
18 componentes adicionales; asignar el personal en concordancia.
Disparador: Los pasos de reduccin son improductivos al 1 / 7 / 0 4 .
Estado actual:
1 2 / 5/ 0 4 : Inician los pasos de reduccin.
Elabor: D. Gagne Asignado a: B. Laster
TM
PDF Editor
En el plan del proyect o de sof t war e se puede incluir una est rat egi a de gest i n de ries-
go o los pas os de gestin del riesgo organi zarse por separ ado en un Plan de redu c-
ci n , su perv i si n y g esti n del ri esg o. El pl an RSGR document a t odo el t r abaj o realiza-
do como part e del anlisis del riesgo y el gestor del proyect o lo empl ea como part e
del pl an global del proyecto.
Al gunos equi pos de soft ware no el aboran un document o RSGR formal. En su lu-
gar, cada riesgo se document a individual mente medi ant e una hoj a de i n f ormaci n del
ri esg o (HIR) [WIL97]. En la mayora de los cas os la HIR se mant i ene empl eando un
si st ema de base de dat os, de modo que la creacin y l as ent r adas de informacin,
or denami ent o de prioridades, bsquedas y ot ros anlisis se logran fcil mente. En la
figura 25.4 se ilustra el for mat o de la HIR.
Una vez document ado el plan RSGR y que el proyect o ha comenzado, se inician
los pas os de reduccin y supervisin del riesgo. Como ya se ha coment ado, la reduc-
cin del riesgo es una actividad encami nada a evitar el probl ema. La supervisin del
riesgo es una actividad de segui mi ent o del proyecto con tres objetivos principales: 1)
val orar si los riesgos predi chos de hecho ocurren; 2) asegur ar que los pasos para evi-
t ar el riesgo definidos para st e s e est n apl i cando con propiedad; y 3) recopilar in-
formaci n que pueda usarse en fut uros anlisis de riesgo. En muchos casos, a los
pr obl emas que ocurren dur ant e un proyect o es posible darl es segui mi ent o hacia m s
de un riesgo. Otra labor de la supervisin del riesgo es intentar ubicar el origen (qu
riesgos provocaron qu pr obl emas a t ravs del proyecto).
Gesti n del ri esg o
Objeti vo: El objetivo de las herramientas de
gestin del riego es ayudar al equipo del pro-
yecto a definir los riesgos, valorar su impacto y probabili-
dad, y seguir los riesgos a travs de todo el proyecto de
software.
Mecni ca: En general, las herramientas de gestin del
riesgo auxilian en la identificacin de riesgos genricos al
proporcionar una lista de riesgos usuales de proyecto y de
negocios, ofrecer listas de verificacin u otras tcnicas "de
entrevista" que auxilien en la identificacin de riesgos es-
V
pecficos del proyecto, asignar probabilidad e impacto a
\
cada riesgo, apoyar las estrategias de reduccin del riesgo
y generar muchos reportes relacionados con el riesgo.
Herramientas representati vas4
Ri skman , desarrollada en Arizona State University (www.
eas.asu.edu/~sdm/merrill/riskman.html), es un sistema
experto en evaluacin de riesgo que identifica riesgos
relacionados con el proyecto.
Ri sk Radar, desarrollada por SPMN (www.spmn.com), au-
xilia o los gestores de proyectos a identificar y gestio-
nor riesgos.
y
4 Las herramientas anotadas aqu son una muestra 3e esta categora. En la mayora de los casos los
nombres de las mismas son marcas regstralas rxx sis respectivos desarrolladores.
TM
PDF Editor
R/s/Tra/c, desarrollada por RST (www.risktrac.com), apoya
la identificacin, el anlisis, el reporte y la gestin de
riesgos a travs de un proyecto de software.
R sk+, desarrollada por C/ S Solutions (www.CS-solutions.
com), se integra con Microsoft Project para cuantificar
costos e incertidumbres de calendarizacin.
X. PRIME R, desarrollada por GrafP Technologies (www.
grafp.com), es una herramienta genrica basada en
Web que predice qu puede salir mal en un proyecto e
identifica el origen de las causas de potenciales fallas y
contramedidas efectivas.
Siempre que en un proyect o de sof t war e est mucho en juego, el sent i do comn dic-
ta el anlisis de riesgos. Sin embar go, muchos gest or es de proyect o de soft ware lo
hacen informal y superfi ci al ment e, si es que lo hacen. El t i empo empl eado en iden-
tificar, anal i zar y gest i onar el riesgo paga por s mi smo di vi dendos en muchas for-
mas: menos t r ast or nos dur ant e el proyecto, una mayor habilidad para segui r y con-
trolar un proyecto, y la confi anza que llega cuando se planifican los pr obl emas an-
t es de que ocurran.
El anl i si s de riesgos puede absor ber una cant i dad significativa de esf uer zo de
planificacin del proyecto. La identificacin, proyeccin, eval uaci n, gestin y super-
visin t oman tiempo. Pero el esf uer zo bien vale la pena. Para citar a Sun Tzu, el ge-
neral chi no que vivi hace 2 500 aos: "Si ust ed conoce al enemi go y se conoce a si
mi smo, no necesita t emer el resul t ado de cien batallas". El enemi go del gest or del
proyect o de sof t war e es el riesgo.
R E F E R E N C I A
[AFC88] Sof tw are Ri sk Abatemen t, AFCS/AFLC Pamphlet 800-45, U.S. Air Forc, 30 de septiem-
bre de 1988.
[BOE89I Boehm, B, W Sof tw are Ri sk Man ag emen t, IEEE Computer Society Press, 1989.
[CHA891 Charette, R. N., Sof tw are E n g i n eeri n g Ri sk An alysi s an d Man ag emen t, McGraw-Hill/Inter-
text, 1989.
[CHA92] Charette, R. N., "Building Bridges over Intelligent Rivers", en Ameri can Prog rammer, vol.
5, nm. 7, septiembre de 1992, pp. 2-9.
[DRU75] Drucker, P Man ag emen t, W. H. Heinemann, 1975.
[G1L88J Gilb, T., Pri n ci pi es of Sof tw are E n g i n eeri n g Man ag emen t, Addison-Wesley, 1988.
1GLU94] Gluch, D. P "A construct for Describing Software Development Risks", CMU/SEI-94-
TR-14, Software Engineering Institute, 1994.
[HAL98J Hall, E. M., Man ag i n g Ri sk: Methods f or Sof tw are Systems Dev elopmen t, Addison-Wesley,
1998.
IHIG95] Higuera, R. P "Team Risk Management", en C rossTalk, U.S. Dept. of Defense, enero de
1995, pp. 2-4.
[KAR96] Karoiak, D. W., Sof tw are E n g i n eeri n g Ri sk Man ag emen t, IEEE Computer Society Press,
1996.
[KEI98] Keil, M. et al. , "A Framework for Identifying Software Project Risks", en C AC M, vol. 41,
nm. 1, noviembre de 1998, pp. 76-83.
[LEV95] Leveson, N. G., Sof tw are System Saf ety an d C ompu ters, Addison-Wesley, 1995.
[SEI93] "Taxonomy-Based Risk Identification", Software Engineering Institute, CMU/SEI-93-TR-
6, 1993.
TM
PDF Editor
765
[TH092] Thomsett, R ' The Indiana Jones School of Risk Management", en Ameri can Prog ram-
mer, vol. 5, nm. 7, septiembre de 1992, pp. 10-18.
[WIL97J Williams, R. C.,). A. Walker y A. J. Dorofee, "Putting Risk Management into Practice", en
IE E E Sof tw are, mayo de 1997, pp. 75-81.
25. 1. Ofrecer cinco ejemplos de otros campos que ilustren los problemas asociados con una
estrategia de riesgo reactiva.
25. 2. Describir la diferencia entre "riesgos conocidos" y "riesgos predecibles".
25. 3. Agregar tres preguntas o tpicos adicionales a cada una de las listas de verificacin de
riesgo que se presentan en el sitio Web SEPA.
25. 4. A usted se le ha pedido construir software para apoyar un sistema de edicin de video de
bajo costo. El sistema acepta como entrada video digital, almacena el video en disco y luego
permite que el usuario haga una amplia variedad de ediciones al video digitalizado. El resulta-
do puede entonces grabarse en DVD u otro medio audiovisual. Investigue un poco acerca de
sistemas de este tipo y luego elabore una lista de riesgos tecnolgicos que enfrentara al comen-
zar un proyecto con estas caractersticas.
25. 5. Usted es el gestor de proyecto de una gran compaa de software. Se le solicita dirigir un
equipo que est desarrollando software de procesamiento de textos de "nueva generacin".
Cree una tabla de riesgos para el proyecto.
25. 6. Describir la diferencia entre componentes de riesgo y controladores de riesgo.
25. 7. Desarrollar una estrategia de reduccin de riesgo y especificar actividades de reduccin
de riesgo para tres de los riesgos anot ados en la figura 25.2.
25. 8. Desarrollar una estrategia de supervisin de riesgo y especificar actividades de supervi-
sin de riesgo para tres de los riesgos anotados en la figura 25,2. Asegrese la identificacin de
los factores que se supervisarn para determinar si el riesgo se est volviendo ms o menos pro-
bable.
25. 9. Desarrollar una estrategia de gestin del riesgo y especificar actividades de gestin del
riesgo para tres de los riesgos anotados en la figura 25.2.
25. 10. Intntese refinar tres de los riesgos anotados en la figura 25.2 y luego crense hojas de
informacin de riesgo para cada uno.
25. 11. Represntense tres de los riesgos anotados en la figura 25.2 empleando un formato CTC.
25. 12. Vulvase a calcular la exposicin al riesgo examinada en la seccin 25.4.2 cuando el
costo/LDC es de 16 dlares, y la probabilidad de 60 por ciento.
25. 13. Puede pensar en una situacin en la que un riesgo de alta probabilidad y alto impacto
no seria considerado como parte de su plan RSGR?
25. 14. Descrbanse cinco reas de aplicacin de software en las que el anlisis de la seguridad
y los peligros del software seran una preocupacin principal.
O T R A S L E CT URAS Y F UENTES L I I N F O R MA C I N
La bibliografa de gestin del riesgo de softw are se ha expandido significativamente durante la
dcada pasada. DeMarco y Lister (Dan ci n g \v . i h Bears Dorset House, 2003) han escrito un libro
entretenido y lcido que gua a los gestores y profesionales de software a travs de la gestin
del riesgo. Moynihan (C opi n g w i th IT/IS Ri s Springer-Verlag, 2002) presenta con-
sejos pragmticos de gestores de proyecto que lidiar continuamente con l. Royer (Proj ect Ri sk
TM
PDF Editor
Man ag emen t, Management Concepts, 2002) y Smith y Merritt (Proacti v e Ri sk Man ag emen t, Prc-
ductivity Press, 2002) sugieren un proceso proactivo para la gestin del riesgo. Karolak (Sof tw a-
re E n g i n eeri n g Ri sk Man ag emen t, Wiley, 2002) ha escrito una guia que introduce un modelo ot '
anlisis de riesgo fcil de usar y que contiene valiosas listas de verificacin y cuestionarios que
se apoyan en un paquete de software.
Schuyler (Ri sk an d Deci si n An alysi s i n Proj ects, PM1, 2001) considera el anlisis de riesgo,
desde una perspectiva estadstica. Hall (Man ag i n g Ri sk: Methods f or Sof tw are Systems Dev c :
men t, Addison-Wesley, 1998) presenta uno de los tratamientos ms exhaustivos de la maten
Myerson (Ri sk Man ag emen t Processi n g f or Sof tw are E n g i n eeri n g Models, Artech House, 1997
considera mtricas, seguridad, modelos de proceso y otros tpicos. Grey (Practi cal Ri skAsses
men t f or Proj ect Man ag emen t, Wiley, 1995) escribi un til manual de la evaluacin del riesg:
Su tratamiento abreviado ofrece una buena introduccin a la materia.
Capers Jones (Assessmen t an d C on trol of Sof tw are Ri sks, Prentice-Hall, 1994) presenta una e >
posicin detallada de los riesgos de software que incluye datos recopilados a partir de cientos
de proyectos de software. Jones define 60 factores de riesgo que pueden afectar el resultado c t
los proyectos de software. Boehm [BOE89] sugiere excelentes formatos de cuestionario y listas,
de verificacin que pueden resultar invaluables en la identificacin de riesgos. Charette [CHA-
presenta un tratamiento detallado de las mecnicas del anlisis de riesgo, y utiliza teora de pro-
babilidad y tcnicas estadsticas para analizar riesgos. En un volumen adicional, Charette lAr
pli cati on Strateg i es f or Ri sk An alysi s, McGraw-Hill, 1990) analiza el riesgo en el contexto de =
ingeniera tanto de sistemas como de software, y sugiere estrategias pragmticas para la ges
tin del riesgo. Gilb (Pri n ci pi es of Sof tw are E n g i n eeri n g Man ag emen t, Addison-Wesley, 1988) prt
senta un conjunto de "principios" (en ocasiones graciosos y a veces profundos) que pueden se--
vir como una gua valiosa para la gestin del riesgo.
Ewusi-Mensah (Sof tw are Dev elopmen t Fai lu res: An atomy of Aban don ed Proj ects, MIT Pres;
2003) y Yourdon (Death March, Prentice-Hall, 1997) analizan lo que ocurre cuando los riesgos
abruman a un equipo de proyecto de software. Bernstein (Ag ai n st the C ods, Wiley, 1998) prese-
ta una entretenida historia del riesgo que se remonta a tiempos antiguos.
El Software Engineering Institute ha publicado muchos informes detallados y guas acerca
del anlisis y la gestin del riesgo. El folleto AFSCP 800-45 [AFC88] del Air Forc Systems Co r -
mand describe las tcnicas de identificacin y reduccin de riesgos. Cualquier nmero del ACW
Sof tw are E n g i n eeri n g Notes tiene una seccin titulada "Riesgos para el pblico" (editor, P. G. Ne_
mann). Si usted quiere las ms recientes y mejores historias de horror de software, ste es el L-
gar al que tiene que ir.
En internet hay disponible una amplia variedad de fuentes de informacin acerca de gesti: n
del riesgo de software. Una lista actualizada de referencias en la World Wide Web se puede er
contrar en el sitio Web SEPA:
ht t p: / / www. mhhe . c om/ pr e s s s ma n.
TM
PDF Editor
C A P T U L O
GESTI N
DE LA CALIDAD 26
C O N C E P T O S
CLAVE
apTrfkaciii
te defectos . . . 77S
a Ua d 769
aatrol
t cofidod 770
sito
te calidad. . . . . 775
ost os
h tallas 771
SabiRdad 786
SO 9001:
2000 790
ws t r e o 781
HH de SQA . . .791
sones
;TF) 774
seguridad de
software 788
seis sigma 785
SOA estadstica 783
E
l enf oque de ingeniera del sof t war e descrito en est e libro se dirige hacia
una sola met a: producir sof t war e de alta calidad. Aunque a muchos lecto-
r es les parecer un ret o la pregunt a: qu es calidad del soft war e?
Philip Crosby [CR079], en su libro fundament al acerca de calidad, ofrece una
respuest a irnica a esta pregunt a:
El problema de la gestin de la calidad no es lo que la gente ignora acerca de ella. El
problema es lo que creen saber...
A este respecto, la calidad tiene mucho en comn con el sexo Todo el mundo lo
quiere. (En ciertas condiciones, desde luego.) Todos sienten que lo entienden. (Aun
cuando no quieran explicarlo.) Todos piensan que su ejecucin slo es cuestin de
seguir las inclinaciones naturales. (Despus de todo, la gente se las arregla de algu-
na forma.) Y, desde luego, la mayora de las personas piensa que los problemas en
estas reas los provocan otras personas. (Si slo se tomaran el tiempo para hacer las
cosas bien.)
Al gunos desarrol l adores de sof t war e cont i nan cr eyendo que la calidad de
st e es al go en lo que se debe comenzar a preocupar sl o des pus de que se ha-
ya gener ado el cdigo. Nada podra est ar ms al ej ado de la verdad! La g esti n
de la cali dad (con frecuencia l l amada g aran ta de Ja cali dad del sof tw are) es una
actividad prot ect ora o de sombrilla (captulo 2) que se aplica a lo l argo del pro-
ceso de soft ware.
La gestin de la calidad abar ca 1) un pr oceso de garanta de la calidad del
sof t war e (SQA, por su s si g las en i n g ls) , 2) t ar eas espec fi cas de asegur ami ent o y
control de la calidad (que incluyen revi si ones t cni cas formal es y una estrategia
de pr uebas de vari os niveles); 3) prct i cas efectivas de ingeniera del sof t war e
(mt odos y herrami ent as); 4) control de t odos l os pr oduct os de t rabaj o del soft-
Q u e s ? No es suficiente habl ar
por habl ar di ci endo q u e la cal i dad
del s of t war e es i mpor t ant e. Se t i ene
que 1 defi ni r expl ci t ament e q u
qui er e deci r c ua ndo di ce "cal i dad
del sof t war e", 2) cr ear un conj unt o d e act i vi da-
de s q ue a yuda r n a a s e gur a r q ue t odo pr oduc-
t o d e t r a ba j o d e i ngeni er a del sof t war e pr esen -
t ar al t a cal i dad, 3) r eal i zar act i vi dades d e
control y as egur ami ent o de la cal i dad en c oda
pr oyect o d e sof t war e, 4 us ar mt ri cas p a r a
desar r ol l ar est r at egi as q ue mej or en el pr oces o
d e s of t war e y, c omo consecuenci a, la cal i dad
del pr oduct o final. ' ' r ,
Qui n l a hac e ? Todos los involucrados en
el or cces o de i ngeni er a del s of t war e son res-
pons abl e s d e la cal i dad.
Por qu es i mport ant e? Es posible
hacer l o bi en o hacer l o d e nuevo ot r a vez. Si un
e qui pe c e s o b a r e s ubr aya la cal i dad en t odas
767
TM
PDF Editor
las actividades de ingeniera dei software, eilo
reduce la cantidad de reelaboracin que se
debe realizar. Esto resulta en menores costos y,
ms importante, mej orar el tiempo de llegada
al mercado.
Cul e s s o n l os p a s o s ? Antes de se que
inicien las actividades de aseguramiento de la
calidad del software es importante definir "cali-
dad def software" en diversos grados de abs-
traccin. Una vez que entienda qu es calidad,
un equipo de software debe identificar un con-
junto de actividades SQA que filtrarn los erro-
res de los productos de t rabaj o antes de que se
aprueben.
Cul e s el producto obtenido? Se crea
un "Plan de aseguramiento de la calidad del
software" par a definir la estrategia SQA del
equi po del software. Durante el anlisis, diseo
y generacin de cdigo el principal producto
de t rabaj o SQA es un breve informe de la revi-
sin tcnica formal. Durante las pruebas se
producen los planes de prueba y los procedi-
mientos. Tambin se pueden generar otros pro-
ductos de t rabaj o asociados con la mejora del
proceso.
Cmo puedo estar seguro de que lo
h e h e c h o c o r r e c t a me nt e ? Encuentre los
errores antes de que se conviertan en defectos!
Es decir, t rabaj e par a mejorar su eficiencia en
la eliminacin de defectos (captulo 22), con lo
que se reduce la cantidad de reelaboracin
que su equipo de software tiene que realizar.
wa r e y l os ca mbi os que ge ne r a n (cap t ul o 27); 5) un pr ocedi mi ent o par a gar ant i zar
la concor danci a con l os e s t nda r e s de desar r ol l o del s of t war e ( cuando s e a apl i ca-
ble), y 6) me c a ni s mos de medi ci n e i nf or me.
Est e cap t ul o s e cent r a en l os t e ma s de gest i n y l as act i vi dades espec f i cas del
pr oce s o que per mi t en a una or gani zaci n de s of t wa r e gar ant i zar que ha c e l as cos as
cor r ect as en el mo me n t o j ust o y e n la f or ma cor r ect a.
2 6 . 1 C O N C E P T O S DE C A L I D A D 1
El con trol de la v ari aci n e s el c or a z n del cont r ol de cal i dad. Un f abr i cant e qui er e
mi ni mi zar la var i aci n ent r e l os pr oduct os q u e se pr oducen, a un c ua ndo ha ga al go
r el at i vament e si mpl e c o mo dupl i car DVD. Se gur a me nt e , e s t o no pue de s er un pr o-
bl ema: la dupl i caci n de l os DVD e s una oper aci n si mpl e de f abr i caci n, y e s posi-
bl e gar ant i zar que s i e mpr e s e cr een dupl i cados e xa ct os del s of t wa r e .
Se puede? Es neces ar i o a s e gur a r s e de que l as pi s t as s e col ocan en l os DVD den-
t r o de una t ol er anci a especi f i cada de mo d o que la mayor a a br uma dor a de l os con-
t r ol ador es de DVD pue da l eer el medi o. Las m q ui na s de dupl i caci n de di s cos pue-
den, y lo hacen, acept ar y r e cha z a r la t ol er anci a. As que i ncl uso un pr oce s o "sim-
ple" c o mo la dupl i caci n de DVD pue de e ncont r a r pr obl e ma s de bi dos a la vari aci n
ent r e mues t r as .
Per o c mo s e apl i ca e s t o al t r abaj o de s of t war e? Cmo pue de una or gani zaci n
de des ar r ol l o de s of t war e neces i t ar cont r ol ar la var i aci n? De un pr oyect o a ot r o se
qui er e mi ni mi zar la di f er enci a ent r e l os r ecur s os pr edi chos neces ar i os par a compl e-
WOA
A .
CLAVE
El cont r ol d e la
var i aci n e s la cl ave
pora un pr oduct o de
al t o cal i dad. En el
c ont e xt o del s of t wa r e
s e l ucha por cont r ol ar
la vari aci n en el
pr oces o genr i co q ue
s e oplico y el nf a s i s
de cal i dad que p e r me a
el t r abaj o de i ngeni er a
del s of t wa r e .
1 Esta seccin, escrita por Michael Stovsky, ha sido adaptada de "Fundamentis of ISO 9000", un libro
de trabajo desarrollado para E sscn ti al Sof tw are E n g i n eeri n g , un video curriculum desarrollado por R
S. Pressman & Associates, Inc. Reimpreso con permiso.
TM
PDF Editor
CAPTULO 26 GESTIN DE LA CALI DAD
769
t ar un proyect o y l os r ecur sos real es utilizados, que incluyen personal , equi po y tiem-
po. En general , se quisiera est ar seguro de que el programa de pr uebas abar ca un
por cent aj e conoci do del soft war e, de una liberacin a otra. No slo se qui ere mini-
mi zar el nmer o de defectos que se liberan, sino que se quiere asegurar que la varian-
za en el nmer o de bu g s t ambi n se minimiza de una liberacin a otra. (Los clientes
pr obabl ement e se mol est ar n si la t ercera liberacin de un pr oduct o tiene diez ve-
ces ms defect os que la liberacin previa.) Nos gustara mi ni mi zar las di ferenci as en
rapi dez y precisin de l as r espuest as de la lnea de soport e para los pr obl emas de los
clientes. La lista puede cont i nuar i ndefi ni dament e.
26.1.1 Calidad
El Ameri can Heri tag e Di cti on ary defi ne cali dad como "una caracterstica o at ri but o de
algo". Como un atributo de un el ement o, la calidad se refiere a caractersticas mensu-
rables, es decir: cosas que se pueden compar ar para conocer est ndares, como longi-
tud, color, propi edades elctricas y maleabilidad. Sin embargo, el soft ware, principal-
ment e una entidad intelectual, es ms difcil de caracterizar que los obj et os fsicos.
No obst ant e, existen l as medi ci ones de las caract er st i cas de un programa. Dichas
pr opi edades incluyen compl ejidad ciclomtica, cohesi n, nmer o de punt os de fun-
cin, lneas de cdi go y muchas ot r as exami nadas en el cap t ul o 15. Cuando se exa-
mina un el ement o con base en s us caract er st i cas mensur abl es se pueden encont r ar
dos tipos de calidad: calidad de di seo y calidad de concordanci a.
La cali dad de di seo se refiere a las caract er st i cas que l os di seador es especi fi can
para un el ement o. La cali dad de con cordan ci a es el grado en el que las especificacio-
nes de di seo se aplican dur ant e la fabricacin.
" l a gent e olvido cun r pi do hiciste un t rabaj o, pero si empre recuerdan cun bien lo hiciste."
Howard Newton
En el desarrol l o de soft ware, la calidad del di seo incluye requisitos, especifica-
ci ones y el di seo del si st ema. La calidad de concordanci a es un t ema enf ocado prin-
ci pal ment e en la i mpl ement aci n. Si st a sigue el di seo y el si st ema resul t ant e
sat i sface sus requisitos y met as de desempeo, la calidad de concordanci a es alta.
Pero la calidad del di seo y la calidad de concordanci a son l os ni cos t emas que
deben considerar los ingenieros de soft ware? Robert Glass [GLA98] argument a que es
conveni ent e una relacin ms "intuitiva
satisfaccin del usuari o = pr oduct o manej abl e + buena calidad
+ ent r ega dent r o de pr esupuest o y t i empo
En el fondo, Gl ass afi rma que la calidad es i mport ant e, pero si el usuari o no est sa-
tisfecho, nada m s importa en realidad DeMarco [DEM99] refuerza est a visin cuan-
do afirma: "La calidad de un pr oduct o es j na funci n de cunt o cambi a el mundo
para mejorar". Esta visin de la calidad afirma que si un product o de sof t war e pro-
TM
PDF Editor
? | .
W i
calidad de
sof t war e?
Utiles vnculos o
recursos de SQA se
pueden enconhor en
www.qudifytree.
tom/llnks/inde*.
htm.
Cules
son los
componentes del
costo de calidad?
por ci ona benef i ci o sust anci al a s us us uar i os finales, s t os es t n di s pues t os a tolera -
pr obl e ma s ocas i onal es en confi abi l i dad y de s e mpe o.
26.1.2 Control de cal idad
El cont r ol de la var i aci n pue de equi par ar s e con el cont r ol de cal i dad. Pero, c m:
se l ogra el cont r ol de cal i dad? st e i nvol ucr a la ser i e de i ns pecci ones , r evi si ones y
pr uebas e mpl e a da s a lo l argo del pr oces o de s of t war e par a gar ant i zar que cada pr :
duct o de t r abaj o sat i sf aga los r equi si t os que s e le ha n as i gnado. El cont r ol de cal i da;
incluye un bucl e de r et r oal i ment aci n con el pr oces o que cr e el pr oduct o de t r aba; :
La combi naci n de medi ci n y r et r oal i ment aci n per mi t e af i nar el pr oces o c ua ndo los
pr oduct os de t r abaj o cr eados f r acas an en cuant o a sat i sf acer s us especi fi caci ones.
Un conce pt o cl ave del cont r ol de cal i dad e s que t odos l os pr oduct os de t r abaj o tie-
ne n es peci f i caci ones def i ni das me ns ur a bl e s con l as cual es se pue de c ompa r a r la sa-
lida de ca da pr oces o. El bucl e de r et r oal i ment aci n e s es enci al par a mi ni mi zar los
def ect os pr oduci dos .
26.1.3 Garanta de la cal idad
La gar ant a de la cal i dad consi st e en un conj unt o de f unci ones de audi t or a e i nfor-
maci n que eval an la efect i vi dad y q u t an compl et as s on l as act i vi dades de c ont r a
de cal i dad. La me t a del a s e gur a mi e nt o de la cal i dad e s br i ndar l e al gest or l os dat os
neces ar i os par a que es t i nf or ma do acer ca de la cal i dad del pr oduct o, y por consi -
gui ent e que c ompr e nda y conf i e en que la cal i dad del pr oduct o est s at i s f aci endo s us
met as . Des de l uego, si l os dat os que of r ece el a s e gur a mi e nt o de la cal i dad i dent i fi -
c a n pr obl emas , e s r es pons abi l i dad del ges t or abor dar l os y apl i car l os r ecur s os nece-
sar i os par a r esol ver l os conf l i ct os de cal i dad.
26.1.4 Costo de la cal idad
El cos t o de la cal i dad i ncl uye t odos l os cos t os que gener a la bs que da de cal idad o
que d e ma n d a el desar r ol l o de l as act i vi dades r el aci onadas con la cal i dad. Los est u-
di os de cost o de la cal i dad s e l l evan a c a bo par a of r ecer una l inea ba s e par a el ces-
t o act ual de la cal i dad, i dent i fi car opor t uni da de s que r e duz ca n el cos t o de cal i dac \
pr opor ci onar una ba s e nor mal i zada de compa r a ci n. La ba s e de la nor ma l i z a dos
casi s i e mpr e e s monet ar i a. Una vez que s e ha n nor ma l i z a do l os cos t os de la cal i da;
s obr e una ba s e monet ar i a, se t i enen l os da t os neces ar i os par a eval uar dnde se e r -
c ue nt r a n l as opor t uni da de s par a mej or ar l os pr ocesos. Ms t odav a, s e pue de e \ a -
l uar el ef ect o de l os c a mbi os en t r mi nos monet ar i os .
Los cos t os de cal i dad s e di vi den en cos t os a s oci a dos con pr evenci n, eval uaci n
y fal l as. Los costos de prev en ci n i ncl uyen pl ani f i caci n de la cal i dad, r evi s i ones t e: -
ni cas f or mal es, equi po de pr ue ba s y e nt r e na mi e nt o. Los costos de ev alu aci n inclu-
yen act i vi dades par a c ompr e nde r me j or la condi ci n del pr oduct o la "pr i mer a ve.: a
t r avs de" cada pr oces o. Los e j e mpl os de cos t os de eval uaci n i ncl uyen i nspecci : -
en el pr oc e s o y e nt r e pr oces os , cal i br aci n y ma nt e ni mi e nt o de e qui po y pr uebas .
TM
PDF Editor
relativo
corregir
Talla.
o
i n cu rri r en
-. costos
tran qu i lo de
i mersi n
Req. Diseo Cdi go Des. Pruebas Oper aci n
pruebas de sistema de campo
Los costos de f allas son aquel l os que desaparecer an si no apareci eran defect os
ant es de enviar un pr oduct o a los clientes. Estos cost os se subdividen en cost os de
fallas i nt ernas y ext ernas. Se incurre en los costos de f allas i n tern as cuando se detec-
ta un defect o en el pr oduct o ant es del envo. Los cost os de fallas i nt ernas incluyen
reel aboraci n, reparaci n y anlisis en modo de falla. Los costos de f allas ex tern as se
asoci an con defect os det ect ados despus de que el product o ha sido envi ado al
cliente. Los ej empl os de cost os de fallas ext er nas son la resolucin de las quej as, de-
volucin y r eempl azo del product o, soport e de ayuda en lnea y t r abaj o de garant a.
Como se esperaba, los cost os relativos para encont r ar y reparar un defect o au-
ment an sust anci al ment e conf or me s e pasa de la prevenci n a det ecci n y de los de
falla i nt erna a los de falla ext erna.
La figura 26.1, basada en dat os recopil ados por Boehm [BOE81] y otros, ilustra es-
te f enmeno.
' Tomo menos t i empo hacer una cosa bien que explicar por qu la hiciste mal . '
H. W. tongfellow
. 2 GAR ANT A DE LA CALI DAD DEL SOFTWARE ( S Q . A )
Incluso los desarrol l adores de sof t war e m s exhaust os est arn de acuer do en que el
sof t war e de alta calidad es una met a i mport ant e. Pero, cmo s e define calidad? Un
bromi st a dijo una vez: "Todo programa hace al go bien, sl o que puede ser la cosa
que no quer emos que haga".
En la bibliografa se han pr opuest o muchas definiciones de la calidad del soft wa-
re. En cuant o a los propsi t os del pr esent e texto, la cali dad del sof tw are se defi ne de
la siguiente maner a:
TM
PDF Editor
Cmo se Concordancia con los requisitos funcionales y de desempeo explcitamente establecidos,
define la estndares de desarrollo explcitamente documentados y caractersticas implcitas que se
calidad del esperan de cualquier software desarrollado profesionalmente.
sof t war e?
No hay duda de que est a definicin puede modificarse o ext enderse. De hecho, la de-
finicin de calidad del sof t war e podra debat i rse i nt ermi nabl ement e. En cuant o a lo?
propsi t os de est e libro, est a definicin sirve para resal t ar t res punt os importantes:
1. Los requisitos de soft ware son la base de l as medi das de la calidad. La falta de
concordanci a con los requisitos es una falta de calidad.
2. Los est ndar es especi fi cados definen un conj unt o de criterios de desarrol l o
que guan la forma en que el sof t war e se el abora. Si no se siguen los criterios,
casi segur ament e resul t ar una falta de calidad.
3. Con frecuenci a no se menci ona un conj unt o de requisitos implcito (por ejem-
plo, el deseo de uso sencillo y facilidad de mant eni mi ent o). Si el sof t war e con-
cuerda con sus requisitos explcitos pero fracasa al sat i sfacer los requisitos
implcitos, su calidad est en duda.
26.2.1 Algunos antecedentes
El control y la garant a de la calidad son actividades esenci al es en cual quier negocie
que el abor e product os de consumo. Antes del siglo xx, el control de calidad era res-
ponsabilidad exclusiva del empr esar i o que fabricaba un product o. La pri mera fun-
cin formal de garant a y control de calidad la introdujeron los Laboratorios Bell er.
1916 y se ext endi r pi dament e a t ravs del mundo industrial. Durant e el deceni o de
1940 se sugirieron enf oques m s for mal es del control de calidad, los cual es se apo-
yaban en la medicin y la mej or a cont i nua de los pr ocesos [DEM86] como los ele-
ment os cl ave de la gestin de la calidad.
"Cometiste demos odos mal os errores. "
Yogi Be r r o
En la actualidad, toda compa a tiene mecani smos que gar ant i zan la calidad er
sus product os. De hecho, las afi rmaci ones explcitas de la preocupaci n de una com-
pa a por la calidad se han convert i do en una tctica de mercadot ecni a dur ant e las
dcadas pasadas.
La historia de la garant a de la calidad en el desarrol l o de sof t war e avanza para-
lela a la de la calidad en la fabricacin de hardware. Durant e los pri meros das de la
comput aci n (dcadas de 1950 y 1960), la calidad era responsabi l i dad exclusiva de:
programador. Los est ndar es de garant a de la calidad para el soft ware se introdu-
j eron en los cont rat os militares de desarrollo de sof t war e dur ant e el deceni o de 1970
y se han ext endi do r pi dament e en el desarrollo del sof t war e en el mundo de los ne-
goci os [IEE94], Si se ext i ende la definicin pr esent ada ant eri orment e, la garant a de
la calidad del soft ware es un "patrn de acci ones si st emt i co y planificado" [SCH98]
TM
PDF Editor
Cul es el
papel de un
yvpo de SQA?
CAPITULO 26 GESTIN DE LA CALI DAD 773
que s e r equi er e par a gar ant i zar al t a cal i dad en el s of t wa r e . Nume r os os y di ver s os
par t i ci pant es t i enen r es pons abi l i dad en la gar ant a de la cal i dad del s of t war e: i nge-
ni er os de s of t war e, ges t or es de pr oyect o, cl i ent es, ve nde dor e s y l os i ndi vi duos que
par t i ci pan en un gr upo de SQA.
El gr upo de SQA f unci ona c o mo el r e pr e s e nt a nt e en c a s a del cl i ent e. Es decir, l as
pe r s ona s que r eal i zan el SQA de be n obs er var el s of t wa r e de s de el punt o de vista del
cl i ent e. El s of t war e sat i sf ace a de c ua da me nt e l os f act or es de cal i dad s e a l a dos en
el cap t ul o 15? El desar r ol l o de s of t wa r e s e ha l l evado a c a b o de a c ue r do con l os es -
t nda r e s pr ees t abl eci dos ? Las di sci pl i nas t cni cas ha n r eal i zado a d e c u a d a me n t e
s us t a r e a s c o mo par t e de la act i vi dad de SQA? El gr upo de SQA i nt ent a r es ponder
s t a s y ot r as pr e gunt a s par a gar ant i zar que la cal i dad del s of t wa r e s e cons er va.
26.2.2 Actividades de SQA
La gar ant a de la cal i dad de s of t wa r e s e c ompone de una var i edad de t a r e a s as oci a-
d a s con dos i nt egr ant es di f er ent es: l os i ngeni er os de s of t war e que r eal i zan el t r aba-
j o t cni co y un gr upo de SQA que t i ene la r es pons abi l i dad de pl ani fi car , super vi sar ,
gua r da r r egi st r os, anal i zar y r epor t ar la gar ant a de cal i dad.
Los i ngeni er os de s of t wa r e a bor da n la cal i dad (y r eal i zan act i vi dades de a s e gur a -
mi e nt o y cont r ol de cal i dad) al apl i car sl i dos m t odos y me di da s t cni cas, llevar a
c a bo r evi si ones t cni cas f or mal es y desar r ol l ar pr ue ba s de s of t wa r e bi en pl ani f i ca-
das. En es t e cap t ul o s l o s e e xa mi na n l as r evi si ones. Los t pi cos de t ecnol og a s e
t r at an en l as par t es 1, 2, 3 y 5 de es t e libro.
La mi s i n del gr upo de SQA e s auxi l i ar al equi po de s of t war e a cons egui r un pr o-
duct o final de al t a cal i dad. El Sof t war e Engi neer i ng i nst i t ut e (SE1) r e comi e nda un
conj unt o de act i vi dades de SQA que a bor da n la pl ani f i caci n, super vi si n, cons er va-
ci n de r egi st r os, anl i si s y el abor aci n de i nf or mes d e a s e gur a mi e nt o de la cal i dad.
Di chas act i vi dades l as r eal i za (o facilita) un gr upo de SQA i nde pe ndi e nt e que s e e n -
ca r ga de l as s i gui ent es act i vi dades:
Preparar un pl an d e SQA par a un pr o y e c t o . El pl an s e desar r ol l a dur a nt e la
pl ani f i caci n del pr oyect o y lo r evi san t odos l os par t i ci pant es. Las act i vi dades de
gar ant a de la cal i dad del e qui po de i ngeni er a del s of t wa r e y del gr upo d e SQA l as
ri ge el pl an. st e i dent i fi ca l as e va l ua ci one s que s e r eal i zar n, l as audi t or as y revi -
s i ones par a l l evar a cabo, los e s t nda r e s apl i cabl es al pr oyect o, l os pr ocedi mi ent os
par a el i nf or me y s egui mi ent o de er r or es, l os doc ume nt os que debe pr oduci r el gr u-
po de SQA y la cant i dad de r et r oal i ment aci n pr opor ci ona da al e qui po de pr oyect o
de s of t war e.
Part i ci par e n e l de s ar r ol l o d e l a de s c r i pc i n de l p r o c e s o de s o f t wa r e del
pr oy e c t o. El e qui po de s of t war e s el ecci ona un pr oc e s o par a el t r abaj o que ha br
de r eal i zar se. El gr upo de SQA revi sa la descr i pci n del pr oce s o par a que c onc ue r de
con l as pol t i cas or gani zaci onal es l os e s t nda r e s i nt e r nos de s of t war e, l os e s t nda -
r e s i mpue s t os de ma ne r a ext er na por e e mpl o 1S09001) y ot r as par t es del pl an de
pr oyect o del s of t war e.
TM
PDF Editor
Revi sar l as act i vi dades de i ngeni er a del s of t ware para veri fi car que s e ajus-
t e al pr oc e s o de s of t ware def i ni do. El grupo de SQA identifica, document a y si-
gue l as desvi aci ones del pr oceso y verifica que se hayan hecho l as correcci ones.
Audi ta product os de trabajo de s of t ware s e l e c c i ona dos para veri fi car que
s e aj ust en c o n l os def i ni dos c o mo part e del pr oc e s o del s of t ware . El grupo
de SQA revisa los pr oduct os de t rabaj o sel ecci onados, identifica, document a y sigue
l as desviaciones; verifica que se hayan hecho las correcciones; y peri di cament e in-
forma de los resul t ados de su t r abaj o al gest or del proyecto.
Garanti za que l as de s vi aci one s e n el trabajo del s of t ware y en l os produc-
t os de trabajo e s t n doc ume nt adas y s e mane j e n de acue rdo c on el proce-
di mi ent o es t abl eci do. Las desvi aci ones se pueden encont rar en el plan del pro-
yecto, en la descripcin del proceso, en los est ndar es aplicables o en los product os
de t rabaj o tcnicos.
Regi stra cual qui er fal ta de aj ust e y l o i nf orma al ge s t or ej ecut i vo. A los ele-
ment os que no se aj ust an se les da segui mi ent o hast a resolverlos.
Adems de est as actividades, el grupo de SQA coordi na el control y la gestin de!
cambi o (captulo 27) y ayuda a recopilar y anal i zar mt ri cas de soft ware.
^CONSEJ O^
L as rev i si on es son
como f i ltros en el f lu j o
e hoka o Jel pi oceso
de sof tw are. Mu y
poco y el f lu j o est
" su ci o" . Demasi ado y
el f lu j o se redu ce a u n
chorto. Use mtri cas
pai a determi n ai qu
rev i si on es f u n ci on an y
resltelos.
Las revisiones del soft ware son un "filtro" para el pr oceso de soft ware. Esto es, las
revi si ones se aplican en varios punt os dur ant e la ingeniera del sof t war e y sirven pa-
ra descubrir errores y defect os que l uego pueden eliminarse. Las revi si ones del soft-
war e "purifican" las actividades de ingeniera del sof t war e que se han denomi nado
anlisis, di seo y codificacin. Freddman y Weinberg [FRE90] abor dan del modo si-
gui ent e la necesi dad de las revisiones:
El trabajo tcnico necesita revisarse por la misma razn que los lpices necesitan gomas.
E rrar es hu man o. La segunda razn por la que se necesitan las revisiones tcnicas es que,
aunque la gente sea buena al captar algunos de sus propios errores, las grandes clases de
errores escapan de su creador con ms facilidad de lo que se le escapan a alguien ms.
Como part e de la ingeniera del sof t war e se pueden llevar a cabo muchos tipos de
revisiones. Cada uno tiene su lugar. Una reunin informal en t orno a una mqui na
expendedor a de caf es una forma de revisin, si se exami nan los pr obl emas tcni-
cos. Una present aci n formal del di seo de sof t war e a un auditorio de clientes, ges-
t ores y personal tcnico t ambi n es una forma de revisin. Sin embar go, est e libro
se enfoca sobre la rev i si n tcn i ca f ormal, a veces l l amada comprobaci n man u al del
c di g o (w alkthrou g h) o i n specci n . Una revisin tcnica formal (RTF) es el filtro ms
efectivo desde un punt o de vista de asegur ami ent o de la calidad. Dirigida por los in-
geni eros de sof t war e (u ot ras personas) para i ngeni eros de soft ware, la RTF es un
medi o efectivo para descubrir errores y mej orar la calidad del soft ware.
TM
PDF Editor
CAPITULO 26 GESTIN DE LA CALIDAD 775
&
I NF ORMACI N
Bu g s, errores y def ectos
La meta del SQA es eliminar los problemas de
calidad en el software. A estos problemas se les
conoce con varios nombres: "bugs", "fallas", "errores" o
'defectos", por mencionar unos cuantos. Cada uno de s-
t*s son trminos sinnimos o existen sutiles diferencias en-
r e ellos?
En este libro se ha hecho una clara distincin entre un
er or (un problema de calidad descubierto an tes de que el
software sea liberado entre los usuarios finales) y un def ec-
to (un problema de calidad detectado slo despu s de que
t software ha sido liberado entre los usuarios finales).2 Se
Ka hecho esta distincin porque los errores y defectos tie-
nen impactos econmicos, de negocios, psicolgicos y hu-
Tionos muy diferentes. Como ingenieros de software se
quiere descubrir y corregir tantos errores como sea posible
rntes de que el cliente o usuario final los encuentre. Se
quieren evitar los defectos porque (justificadamente) hacen
er mal a la gente de software.
Sin embargo, es importante mencionar que la distin-
cin temporal hecha en este libro entre errores y defectos
n o es la tendencia predominante. El consenso general en-
tre la comunidad de ingeniera del software es que defec-
tos y errores, fallas y bugs son sinnimos. Es decir, el
momento en que el problema se descubri no tiene impor-
tancia en cuanto al trmino con que se describe el proble-
ma. Parte del argumento en favor de esta visin es que a
veces es difcil distinguir con claridad entre preliberacin y
posliberacin (por ejemplo, considrese un proceso incre-
mental utilizado en el desarrollo gil [captulo 4]).
Sin importar cmo se elija interpretar estos trminos,
reconzcase que el momento en que se descubre un pro-
blema s importa y que los ingenieros de software deben
intentar duro, muy duro, detectar los problemas antes de
que los clientes y usuarios finales los encuentren. Si se tiene
un inters posterior en este tema, una revisin razonable-
mente amplia de la terminologa que rodea a los "bugs" se
puede encontrar en www.softwaredevelopment.ca/bugs.
shtml. y
Model o d e
ampl i l i caci n
e def ect o.
Errores
provenientes
de pasos previos
Paso de desarrollo
Defectos Deteccin
Er r or e s p a s a d o s p o r a l t o
P o r c e n t a j e d e
e f i c i e nc i a p a r o
d e t e c c i n
d e e r r o r e s
Errores a mpl i f i c a dos 1 : x
d e t e c c i n
d e e r r o r e s
Nue v os e r r or e s g e n e r a d o s
d e t e c c i n
d e e r r o r e s
Errores que
-pasan al paso
siguiente
26.3.1 Impacto de los defectos de software en el costo
El obj e t i v o pr i nci pal de l as r e vi s i one s t c n i c a s f o r ma l e s e s de s c ubr i r l os e r r o r e s d u -
r a n t e el p r o c e s o , d e mo d o q u e n o s e c onv i e r t a n e n d e f e c t o s d e s p u s d e l i ber ar el
s o f t wa r e . El be ne f i c i o obv i o d e l a s r e v i s i one s t c ni c a s f o r ma l e s e s el d e s c u b r i mi e n -
t o t e mp r a n o d e l os e r r o r e s de mo d o q u e y a n o s e p r o p a g u e n al p a s o s i gui e nt e e n el
p r o c e s o del s o f t wa r e .
2 Si se considera la mejora en el proceso de software, un problema de calidad que se propaga desde
una actividad del marco de trabajo del proceso (por ejemplo, modelado) hacia otra (por ejemplo,
construccin) tambin se puede llamar "defecto* porque el problema se debi haber descubierto an-
tes de que un producto de trabajo (por eiemr. o ur. Tiodelo de diseo) se hubiese "liberado" hacia la
actividad siguiente.
TM
PDF Editor
^CONSEJcffi -
E l obj eti v o pri n ci pal de
u n a Rlf es en con trar
los errores an tes de
qu e posen a otra
acti v i dad de i n g en i era
del sof tw are o sean
li berados ol u sv ari o
f i n al.
Varios est udi os industriales (realizados por TRW, NEC y Mitre Corp., ent re otros
indican que las actividades de di seo introducen ent re 50 y 65 por ciento de los erro-
res (y, a final de cuent as, de los defectos) dur ant e el pr oceso de soft ware. Sin embar-
go, las t cni cas de revisin formal han most r ado hast a 75 por ciento de efect i vi da:
[10N86] al descubrir fallos en el diseo. Al det ect ar y eliminar un gran por cent aj e de
dichos errores, el pr oceso de revisin reduce sust anci al ment e el cost o de las activi-
dades subsecuent es en el pr oceso de soft ware.
Para ilustrar el i mpact o en el cost o de la deteccin t empr ana de errores, consid-
rese una serie de cost os relativos que se basan en dat os de cost o real recopilados
para gr andes proyect os de soft ware [IBM81].3 Supngase que la correccin de u-
error descubi ert o dur ant e el di seo cost ar 1.0 unidad monet ari a. En relacin cor
est e costo, el mi smo error descubi ert o justo ant es de que comi ence el periodo de
pr uebas cost ar 6.5 uni dades; dur ant e las pruebas, 15 uni dades; y despus de la li-
beraci n, ent re 60 y 100 uni dades.
26.3.2 Amplilicacin y eliminacin del defecto
Se puede usar un model o de ampl ificacin de defect os [IBM81] para ilustrar la gene-
racin y det ecci n de errores dur ant e el di seo preliminar, el di seo de detalles y los
pas os de codificacin de un pr oceso de ingeniera del soft ware. En la figura 26.2 se
ilustra esquemt i cament e el model o. Un recuadro r epr esent a un pas o de desarroi . :
del soft ware. Durant e el paso, l os errores se pueden generar de maner a inadvertida.
La revisin puede fallar en descubrir errores gener ados de maner a reci ent e y errores
de pas os ant eri ores, lo que resulta en cierto nmer o de errores que se pasan por al-
to. En al gunos casos, los errores que se pasan por alto desde pas os ant eri ores se am-
Ampllicacin
de defecto sin
revisiones.
Di s eo pr el i mi nar
0
0% 0 0%
10
0%
Di s eo de t a l l a do
10 6
X
94
Pr ueba d e i nt egr aci n
5 0 % 0 5 0 %
0
5 0 %
47
1
6
0 %
4 x 1 . 5
0 %
2 5
0 %
' r u e b a d e val i daci n
5 0 %
0
5 0 %
0
5 0 %
Pr ue bo c d i g o / u n i d a d
10
2 0 %
2 5
A in
Pr ue bo d e si st ema
0
5 0 %
0
94
12
Errores l at ent es
3 Aunque estos datos tienen ms de 20 aos de antigedad, an son aplicables en un contexto mo-
derno.
TM
PDF Editor
CAPTULO 26 GESTIN DE LA calidad 777
Amplificacin
de defecto con
revisiones.
Di s eo pr el mi na r
0
Di s eo de t a l l a do
0 7 0 %
3 2
2
10
3 2
1 . 1 . 5 5 0 %
2 5
2 4 Pr ue ba d e i nt egr aci n
Pr ueba c d i g o / u n i d a d
15 5
o
5 0 % 0 5 0 %
0
5 0 %
Pr ue ba d e val i daci n
1 2
~L
u
~L
5
1 0 . 3 6 0 %
2 5
A in
Pr ueba d e si st ema
0
5 0 %
0
24
Errores l at ent es
plifican (factor de amplificacin x) con el t rabaj o actual . Las subdi vi si ones de los re-
cuadr os r epr esent an cada una de est as caract er st i cas y el por cent aj e de eficiencia
de la det ecci n de errores, una funcin de la mi nuci osi dad de la revisin.
i5, dicen los mdicos, son fciles de curar en sus inicios aunque difciles de r econocer . . . pero en
el transcurso del tiempo, cuando no han sido reconocidas a primera vista y t r at adas, se vuelven fciles de reconocer
pero difciles de curar."
La figura 26. 3 ilustra un ej empl o hipottico de la amplificacin del defect o para un
pr oceso de sof t war e en el que no se llevan a cabo revisiones. En la figura se supone
que cada pas o de prueba descubr e y corrige, sin introducir nuevos errores, 50 por
ci ent o de los errores que llegan (una suposicin optimista). Diez defect os de di seo
prel i mi nar se amplificaron a 94 er r or es ant es de comenzar l as pruebas. Doce defec-
t os l at ent es se liberaron al campo. La figura 26.4 consi dera l as mi s mas condi ci ones
except o que la revisin del di seo y del cdi go se llevaron a cabo como part e de ca-
da paso de desarrollo. En est e caso, diez er r or es iniciales de di seo prel iminar se
ampl ificaron a 24 errores ant es de comenzar el peri odo de pruebas. Slo existen t res
defect os latentes. Al consi derar los cost os relativos asoci ados con el descubri mi en-
to y la correccin de er r or es se puede est abl ecer el cost o global (con revisin y sin
ella par a el ej empl o hipottico). El nmer o de errores descubi ert os dur ant e cada uno
de los pasos anot ados en l as figuras 26. 3 y 26.4 se multiplica por el cost o para elimi-
nar un error (1.5 uni dades de cost o para di seo, 6.5 uni dades de cost o ant es de las
pruebas, 15 uni dades de cost o dur ant e l as pruebas, y 67 uni dades de cost o despus
de la liberacin). Empl eando est os dat os, el cost o total para desarrol l o y mant eni -
mi ent o es de 783 uni dades cuando se real izan revisiones. Si no se real izan revisio-
nes el cost o total es de 2 177 uni dades cas; t res veces ms cost oso.
TM
PDF Editor
En las revisiones un ingeniero de soft ware debe utilizar t i empo y esfuerzo, y la or-
ganizacin desarrolladora, dinero. Sin embargo, los resultados del ej empl o preceden-
t e no dejan duda acerca de pagar ahor a o hacerlo ms tarde. Las revisiones tcnicas
formal es (para el di seo y otras actividades tcnicas) ofrecen un beneficio demost ra-
ble en el costo. Se deben llevar a cabo.
26. 4
Cu a n d o s e
* l l e va n a c a bo
RTF, c u l e s s on
l os o b j e t i v o s ?
El
G M M (libro fiuto
de Inspeccin formal)
de NASA SATC se
puede descargar de
salc.gsfc.nasa.
gov/ fl / fi page.
Una revisin tcnica formal (RTF) es una actividad de control de calidad del soft wa-
re que llevan a cabo los i ngeni eros de soft ware (y otros). Los objetivos de una RTF
son 1) descubrir errores en la funcin, lgica o i mpl ement aci n en cual quier repre-
sent aci n del soft ware; 2) verificar que el soft ware en revisin sat i sface sus requisi-
tos; 3) garant i zar que el sof t war e se ha r epr esent ado de acuer do con los est ndar es
predefinidos; 4) lograr soft ware desarrol l ado en una maner a uni forme; y 5) hacer
proyect os ms manej abl es. Adems, la RTF sirve como un campo de ent r enami en-
to, pues permite que los i ngeni eros menos exper i ment ados observen di ferent es en-
f oques respect o del anlisis, el di seo y la construccin del soft ware. La RTF tambin
funge como promot ora del soport e y la cont i nui dad, pues vari as per sonas se fami-
liarizan con l as part es del soft ware que de otra forma nunca veran.
"No hay urgencia ms grande que la que t i ene un hombr e por corregir el t r abaj o de ot ro. "
Mar k Twain
La RTF es en realidad una cl ase de revisin que incluye recorridos, inspecciones,
revi si ones cclicas y ot ro pequeo grupo de eval uaci ones t cni cas de soft ware. Cada
RTF s e realiza en una junta y tendr xito sl o si se planifica, cont rol a y at i ende apro-
pi adament e. En l as si gui ent es secci ones se pr esent an directrices simil ares a las de
un recorrido (por ejempl o, [FRE90], [GIL93J) que se present a como una revisin tc-
nica formal represent at i va.
26.4.1 La junta de revisin
Sin i mport ar el format o de RTF que se elija, cual quier j unt a de revisin debe atener-
se a las si gui ent es restricciones:
En la revisin se deben involucrar (usualmente) entre t res y cinco personas.
Se debe preparar con anticipacin, pero sin que requiera m s de dos hor as de
t rabaj o de cada per sona.
La duracin de la j unt a de revisin debe ser menor a dos hor as.
Dadas est as restricciones, debe ser obvio que una RTF se enfoca en una part e espe-
cfica (y pequea) del soft ware total. Por ejemplo, ms que i nt ent ar revisar un dise-
o compl et o, se llevan a cabo recorri dos para cada component e o grupo pequeo de
component es. Al est rechar el enfoque, la RTF tiene una mayor probabilidad de des-
cubrir errores.
TM
PDF Editor
CAP TULO 26 GESTIN DE LA CALIDAD 779
%
CI?A VE
Uno RTF se enfoca en
ano porcin
-estivamente pequea
i un producto de
tobajo.
( CONSEJ O^
: 1 a l g u n o s s it u a c io n e s
e b u e n a id e a h a c e r
pe a l g u ie n d is t in t o a l
y o d u c t o r r e c o r r a e l
u v d u c t o q u e e x pe r i-
m t n r e v is i n . E s t o
in d u c e o u n a in t e r -
r e t o c i n l it e r a l d e l
r o d u c t o d e t r a b a o y
: u n m e j o r r e c o n o c i-
- & it o d e l o s e r r o r e s .
El enfoque de la RTF se dirige a un product o de t rabaj o (por ejempl o, una porcin
de una especificacin de requisitos, un di seo detal l ado de component e, una lista de
cdigo fuent e de un component e). El individuo que ha desarrollado el product o de tra-
baj o el pr o d u c t o r le informa al jefe del proyecto que el product o est compl et o y
que se requi ere una revisin. El jefe del proyect o se pone en cont act o con un j e fe d e
r e v is i n , quien eval a la disponibilidad del product o, genera copi as del material del
product o y l as distribuye a dos o t res r e v is o r e s para que realicen sus observaci ones
ant es de la junta. Se espera que cada revisor empl ee ent r e una y dos horas en revi-
sar el product o, t omar not as y familiarizarse con el trabajo. Al mi smo tiempo, el je-
fe de revisin t ambi n revisa el product o y est abl ece una agenda para la junta de re-
visin, la que usual ment e se pr ogr ama para el da siguiente.
A la junta de revisin asisten el jefe de revisin, t odos los revisores y el productor.
Uno de los revisores as ume el papel de r e g is t r a d o r , es decir, el individuo que registra
(por escrito) los t emas i mport ant es que surj an durant e la revisin. La RTF comi enza
con una present aci n de la agenda y una breve introduccin a cargo del productor.
Ent onces el productor procede a recorrer el product o de t rabaj o y explica el material,
mi ent ras que los revisores exponen los probl emas que descubrieron ant es de la jun-
ta. Cuando se descubren probl emas o errores vlidos el registrador anot a cada uno.
Al final, t odos los asi st ent es a la RTF deben decidir si 1) acept an el product o sin
modi fi caci ones posteriores, 2) r echazan el product o debi do a errores severos (una
vez corregi dos se tiene que real izar otra revisin) o 3) acept an el product o provisio-
nal ment e (se encont raron errores menor es que es necesari o corregir, per o no se r e-
querir revisin adicional). Cuando se t ome la decisin, t odos los asi st ent es a la RTF
l l enan un document o de finalizacin en el que indican su participacin en la revisin
y su conformi dad con los hal l azgos del equi po revisor.
26.4.2 Informe de la revisin y conservacin de registros
Durante la RTF, un revisor (el registrador) registra act i vament e t odos los pr obl emas
que hayan surgido. stos se r esumen al final de la j unt a de revisin y se genera una
l is t a d e pr o b l e m a s d e r e v is i n . Adems, se llena un in fo r m e r e s u m e n d e l a r e v is i n t c -
n ic a fo r m a l . Un i nforme r esumen de la revisin responde tres pregunt as:
1. Qu se revis?
2. Quin lo revis?
3. Cules fueron l os hal l azgos y concl usi ones?
El i nforme r esumen de la revisin es un format o de una sola pgi na (con posibles
anexos). Se vuel ve part e del registro histrico del proyect o y es posible distribuirlo
ent re el jefe del proyect o y ot r as part es i nt eresadas.
La lista de probl emas de la revisin cumpl e dos propsitos: 1) identificar r eas
probl ema en el product o y 2) funci onar como lista de verificacin de el ement os de
acci n que guan al productor conf or me se hacen las correcci ones. Normal ment e al
i nforme r esumen se anexa una lista de pr obl emas
TM
PDF Editor
Es i mpor t ant e es t abl ecer un pr ocedi mi ent o de s egui mi ent o par a gar ant i zar que
l os e l e me nt os en la lista de pr obl e mas s e h a n cor r egi do a de c ua da me nt e . A menos
que e s t o se haga, e s posi bl e que l os pr obl e mas s ur gi dos "cai gan ent r e l as gr i et as'
Un e nf oque cons i s t e e n as i gnar la r es pons abi l i dad del s egui mi ent o al j ef e de revi-
si n.
"A menudo una reunin es un suceso en el que se toman los minutos y se pierden las horas."
Annimo
( C ONS E J O^
N o s e a l e l o s e r r o r e s
d e m a n e r a h ir ie n t e .
U n a fo r m o d e s e r
g e n t il e s pr e g u n t a r
a l g o q u e pe r m it a a l
pr o d u c t o r d e s c u b r ir e l
e r r o r .
26.4.3 Directrices de la revisin
Las di rect ri ces par a r eal i zar l as r evi s i ones t cni cas f or mal es e s neces ar i o est abl ecer -
l as con ant i ci paci n, di st ri bui rl as ent r e t odos l os revi sores, suscr i bi r l as y l uego se-
gui rl as. Una revi si n des cont r ol ada us ual me nt e e s peor que car ecer de una. Las si-
gui ent es r e pr e s e nt an un conj unt o m ni mo de di r ect r i ces par a l as r evi si ones t cni cas
f or mal es:
1 . Re v is a r e l pr o d u c t o , n o a l pr o d u c t o r . Una RTF i nvol ucr a pe r s ona s y egos . Reali-
zada con pr opi edad, la RTF de be dej ar a t odos l os par t i ci pant es con un cl i do
s ent i mi ent o de l ogro. Si se l l eva a c a bo de ma n e r a i nadecuada, la RTF puede
t oma r un aur a i nqui si t ori al . Los er r or es s e de be n s eal ar con gent i l eza; el t o-
n o de la j unt a de be s er r el aj ado y const r uct i vo; la finalidad n o de be s er aver -
gonzar o menos pr eci ar .
2. E s t a b l e c e r u n a a g e n d a y r e s pe t a r l a . Un mal cl ave de l as j unt as de cual qui er t i po
e s la di vagaci n. Una RTF t i ene que ma nt e ne r el r umbo y segui r el pr ogr ama.
El j ef e de revi si n t i ene la r es pons abi l i dad de ma nt e ne r el pr ogr a ma de la j un-
ta y no vaci l ar en l l amar la at enci n de la ge nt e c ua n do s e e mpi e ce a di vagar
3 . Lim it a r e l d e b a t e y l a im pu g n a c i n . Cuando un revi sor pl ant ee un pr obl ema, tal
vez no haya un acue r do uni ver sal s obr e s u i mpact o. En l ugar de per der t i em-
po debat i endo la cuest i n, el pr obl e ma s e de be r egi st r ar par a t r at ar l o i nfor-
ma l me n t e de s pus .
4 . E n u n c ia r r e a s d e pr o b l e m a s , pe r o n o s e in t e n t e r e s o l v e r t o d o s l o s q u e s e h a y a n
s e a l a d o . Una revi si n no e s una sesi n par a r esol ver pr obl e mas . Est o s e debe
pos pone r has t a de s pu s de la j unt a de revi si n.
5. To m a r n o t a s . En ocas i one s e s bue na i dea que el r egi st r ador t ome not a s en una
pi zar r a, de mo d o que l as pal abr as y l as pr i or i dades pue da n eval uar l as ot r os
r evi sor es c onf or me s e regi st ra la i nf or maci n.
6. Lim it a r e l n m e r o d e pa r t ic ipa n t e s e in s is t ir e n l a pr e pa r a c i n a n t ic ipa d a . Dos ca-
be z a s pi ens an me j or que una, pe r o 14 n o ne c e s a r i a me nt e s on me j or e s que
cuat r o. Ma nt nga s e el nme r o de pe r s o n a s i nvol ucr adas e n el m ni mo nece-
sari o. Sin e mbar go, t odos l os mi e mbr os del e qui po r evi sor de be n pr epar ar s e
por ant i ci pado. El j ef e de revi si n de be sol i ci t ar c ome nt a r i os escr i t os (lo que
of r ece un i ndi ci o de que el revi sor ha anal i zado el mat eri al ).
TM
PDF Editor
CAP TULO 2 6 GESTIN DE LA CALIDAD 781
7. De s a r r o l l a r u n a l is t a d e v e r ific a c i n pa r a c a d a pr o d u c t o q u e t e n g a pr o b a b il id a d
d e s e r r e v is a d o . Una lista de veri fi caci n ayuda al j ef e de revi si n a es t r uct ur ar
la j unt a de RTF, y a c a da r evi sor a e nf ocar s e en l os pr obl e mas i mpor t ant es .
8. As ig n a r r e c u r s o s y pr o g r a m a r l a s RTF. Las r evi si ones s e r n ef ect i vas si s e pr o-
gr a ma n c o mo una t ar ea del pr oces o de s of t war e. Adems , s e de be pr ogr amar
t i e mpo par a r eal i zar l as i nevi t abl es modi f i caci ones que ocur r i r n c o mo resul -
t a do de un a RTF. '
9 . Re a l iza r u n e n t r e n a m ie n t o s ig n ific a t iv o d e t o d o s l o s r e v is o r e s . Los par t i ci pant es
en la revi si n s e r n ef i ci ent es si r eci ben al gn e nt r e na mi e nt o f or mal . El e n-
t r e na mi e nt o debe s ubr ayar t a nt o l os pr obl e mas r el aci onados con el pr oce s o
c o mo el l ado psi col gi co y h u ma n o de l as revi si ones.
1 0. An a l iza r l a s r e v is io n e s pr e v ia s . La j unt a e s benef i ci os a par a des cubr i r pr obl e-
ma s en el pr oces o de revi si n mi s mo. El pr i mer pr oduct o que se haya r evi sa-
do de be es t abl ecer l as di rect ri ces de revi si n.
"Una de las compensaciones ms hermosas de la vida es que ningn hombre puede intentar sinceramente ayudar a
otro sin oyudarse a s mismo."
Ralph Wal do Emerson
Puest o que mu c h a s var i abl es (por ej empl o, n me r o de par t i ci pant es, t i po de pr o-
duct os de t r abaj o, t i e mpo y dur aci n, e nf oque espec f i co de revi si n) i nci den en una
revi si n pr ovechos a, una or gani zaci n de s of t wa r e debe e xpe r i me nt ar par a det er mi -
nar qu e nf oque f unci ona mej or en un cont ext o local. Port er y s us col egas | POR95]
of r ecen una excel ent e gu a par a e s t e t i po de exper i ment aci n.
26.4.4 Revisiones basadas en muestras
En un cont ext o ideal , c a da pr oduct o de t r abaj o de i ngeni er a del s of t wa r e deber a ex-
per i ment ar una revi si n t cni ca f or mal . En el mu n d o real de l os pr oyect os de sof t -
war e, l os r e cur s os s on l i mi t ados y el t i empo e s cort o. Co mo cons ecuenci a, us ual -
me nt e l as r evi si ones se sosl ayan, a un que s e r e c onoz c a s u val or c o mo me c a n i s mo
de cont rol de cal i dad. Thel in y s us col egas [THEOl] a bor da n es t e t e ma c ua ndo afi r-
ma n:
Las inspecciones [RTF] slo son vistas como eficientes si se encuentran muchas fallas du-
rante su bsqueda. Si en los artefactos [productos de trabajo] se encuentran muchas fa-
llas, las inspecciones son necesarias. Si por otra parte, slo se encuentran pocas fallas, la
inspeccin ha sido una prdida de tiempo para muchas personas involucradas en la ta-
rea.4 Ms an, los proyectos de software q - j e esian atrasados con frecuencia disminuyen
el tiempo de las actividades de inspeccicr. '.o que conduce a una falta de calidad. Una so-
4 Desde luego, se puede argumentar que. a! llevar a ; = re. ; t res. se alienta a los productores a en-
focarse en la calidad, incluso si no se encuendar e t s
TM
PDF Editor
^ O N S E J O ^
La s r e v is io n e s l o m a n
t ie m po , pe t o e s
t ie m po b ie n
e m pl e a d o . S in
e m b a r g o , s i e l t ie m po
e s c o r t o y n o s e t ie n e
o t r a o pc i n , n o s e
d is pe n s e n l a s r e v i-
s io n e s . ( n s u l u g a r
u ' c e n s e r e v is io n e s
b a s a d a s e n m u e s t m s .
lucin sera asignar jerarquas a los recursos para las actividades de inspeccin y, en con-
secuencia, concentrar los recursos disponibles en los artefactos ms proclives a las fallas
Thel i n y s us col egas s ugi er en un pr oc e s o de revi si n ba s a do e n q u e mue s t r a s de tc-
dos l os pr oduct os de t r abaj o de i ngeni er a del s of t war e, s t a s s e i ns pecci onan pa-
de t e r mi nar qu pr oduct os de t r abaj o s on m s pr ocl i ves al error. Ent onces l os recur
s os de l as RTF compl e t as s e e nf oc a n sl o e n aquel l os pr oduct os de t r abaj o con pr :
habi l i dad ( bas ndos e en l os da t os r ecopi l ados dur a nt e el mues t r eo) de s er procl i ves
al error.
Para s er ef i caz, el pr oce s o de revi si n ba s a do en mue s t r a s de be i nt ent ar cuant i f -
car aquel l os pr oduct os de t r abaj o que s e a n obj et i vos pr i nci pal es par a l as RTF corr -
pl et as. Par a l ograrl o s e s ugi er en l os s i gui ent es pa s o s [THE01]:
1. I nspecci onar un a f r acci n a de cada pr oduct o de t r abaj o de s of t wa r e i . Regis-
t r e el n me r o de f al l as f e n c o n t r a da s dent r o de a .
2. Desar r ol l ar una es t i maci n br ut a del n me r o de fal l as dent r o del pr oduct o de
t r abaj o i al mul t i pl i car f por 1 /a .
3. Or denar l os pr oduct os de t r abaj o e n f or ma de s c e nde nt e de a c ue r do con la es-
t i maci n br ut a del nme r o de fal l as e n cada uno.
4 . Enf ocar l os r ecur s os de revi si n di sponi bl es e n aquel l os pr oduct os de t r abaj o
con el mayor n me r o e s t i ma do de fallas.
La f r acci n con la que s e ha he c ho un mue s t r e o del pr oduct o de t r abaj o debe 1) ser
r epr es ent at i va del pr oduct o de t r abaj o c o mo un t odo, y 2) s er lo s uf i ci ent ement e
gr ande de tal ma n e r a q u e s ea si gni fi cat i va par a l os r evi sor es que real i cen el mus
t reo. Conf or me a, a ume n t a , la pr obabi l i dad de que la mues t r a s ea un a r epr esent a
ci n vl i da del pr oduct o de t r abaj o t ambi n cr ece. Sin e mbar go, t ambi n a ume n t a r
los r ecur s os r equer i dos par a l evant ar la mues t r a. Un equi po de i ngeni er a del soft-
wa r e de be es t abl ecer el me j or val or par a a s egn l os t i pos de pr oduct os d e t r abaj :
pr oduci dos . 5
HOGARSEGURO
Pr o b l e m a s e n e l S QA
. f I escenari o: Oficina de Doug M-
11er cuando comienza el proyecto de software Ho g a r S e g u r o .
Los a c t o r e s : Doug Miller (gerente del equi po de inge-
niera del software Ho g a r S e g u r o ) y otros miembros del
equi po de ingenier a del software.
La conversaci n:
Do u g : Ya s que no hemos empl eado tiempo pa r a de-
sarrollar un pl an de SQA pa r a este proyecto, per o ya
est amos en l y t enemos que consi derar la cal i dad. . .
cierto?
5 Thelin y sus colegas han realizado una simulacin detallada que puede ayudar a tomar esta deter-
minacin. Vase [THE01J para detalles.
TM
PDF Editor
CAPI TULO 26 GESTIN DE LA CALIDAD 783
J a mi e : Cl aro. Yo hemos deci di do que, conforme desa-
rrollemos el model o de requisitos [captulos 7 y 8], Ed se
no compromet i do desarrol l ar un procedimiento V&V
por a c a da requisito.
Do u g : Eso es muy bueno, per o no vamos a esper ar has-
ta hacer las pr uebas pa r a eval uar l a cal i dad, o si?
Vi n o d ; No! Desde l uego que no. Hemos pr ogr amado
revisiones en el pl an del proyecto par a este incremento
de software. Comenzar emos el control de cal i dad con las
revisiones. ' .
J a mi e : Estoy un poco pr eocupada de que no t engamos
- empo suficiente pa r a realizar t odas las revisiones. De
hecho, s que no podr emos
Do u g : Mmmmm. Qu propones?
J a mi e : Sugiero que seleccionemos aquellos elementos
de los model os de anlisis y di seo cruciales pa r a Ho g a r -
S e g u r o y que los revisemos
Vi n o d : Pero qu ocurre si per demos al go en una part e
el model o que no revisemos?
Sha ki r a : Le al go acer ca de una tcnica d e muestren
[seccin 26. 4. 4] que puede ayudamos o sel eccionar los
candi dat os pa r a revisin. (Shakira explica el enfoque. )
J a mi e : Tal vez. . . per o no estoy segur a d e que incluso
t engamos tiempo pa r a t omar muestras de c a da el ement o
de los modelos.
Vi n o d : Qu quieres que hagamos , Doug?
Do u g : Robemos al go de Programaci n Extrema [captu-
lo 4). Desarrollaremos los elementos d e c a da model o en
par es dos personas y real i zaremos una revisin In-
formal de cada, uno conforme avancemos Luego selec-
ci onaremos los elementos "cruciales" pa r a una revisin
en equi po ms formal , per o conservaremos dichas revi-
siones en un mnimo. De es a forma, t odo ser obser vado
por ms de un conj unt o de oj os, per o an asi conserva-
remos nuestras fechas de ent rega.
J a mi e : Eso significa que t endremos que revisar la calen-
dari zaci n.
Do u g : As debe ser. La cal i dad triunfa sobre la cal enda-
rizacin en este proyecto.
2 6 , 5 E N F O Q U E S F ORMALES AC E R C A P EL S & A
Dur ant e l as dos dcadas pas adas , un pequeo, per o rui doso, s egment o de la comu-
ni dad de i ngeni er a del s of t war e ha ar gument ado que se requi ere un enf oque m s
formal de la garant a de la cal i dad del soft ware. Se puede ar gument ar que un pro-
gr ama de comput ador a es un obj et o mat emt i co [SOMOl]. En cada l enguaj e de pro-
gr amaci n s e defi nen una sintaxis y una semnt i ca rigurosas, y existe un enf oque ri-
gur oso r espect o de la especi fi caci n de requi si t os de sof t war e (captulo 28). Si el mo-
del o de requi si t os (especificacin) y el l enguaj e de pr ogr amaci n se r epr esent an en
una f or ma rigurosa, debe ser posi bl e aplicar pr uebas mat emt i cas de exact i t ud para
demost r ar que un pr ogr ama concuer da exact ament e con s us especi fi caci ones.
Los i nt ent os encami nados a pr obar la exact i t ud de los pr ogr amas (captulos 28 y
29) no son nuevos. Dijkstra [D1J76] y Linger, Mills y Witt [L1N79], ent r e ot ros, acon-
sej ar on pr uebas de exactitud de pr ogr ama y los vi ncul aron con la apl i caci n de con-
cept os de pr ogr amaci n est r uct ur ada (capitulo II).
2 6 . 6 G A R A N T A P E LA C AL I D A? ESTAD STI CA DEL SOFTWARE
La garant a de la calidad est ad st i ca refl eja una t endenci a, creci ent e en la industria,
por adopt ar un enf oque m s cuant i t at i vo acer ca de la cal idad. Para el sof t war e, la
garant a de la cal i dad est ad st i ca impl ica i os pas os si gui ent es:
TM
PDF Editor
Qu posos
se requi eren
par a real izar SQA
est ad st i co?
1. La i nf or maci n acer ca de l os def ect os de s of t wa r e s e r ecopi l a y cl asi fi ca.
2 . Se i nt ent a de t e r mi nar la c a us a s ubyace nt e de cada def ect o (por ej empl o, fal t a
de concor danci a con l as especi f i caci ones, er r or es de di s eo, vi ol aci n de es-
t ndar es , def i ci ent e comuni caci n con el cl i ent e).
3. Medi ant e el pri nci pi o de Par et o (80 por ci ent o de l os def ect os s e e nc ue nt r a en
20 por ci ent o de t oda s l as c a us a s posi bl es) s e ai sl a un 20 por ci ent o (los "vita-
les").
4 . Una vez que l as c a us a s vi t al es h a n s i do i dent i f i cadas, s e cor r i gen l os pr obl e-
ma s que h a n pr ovoc a do l os def ect os .
Este c onc e pt o r el at i vament e si mpl e r epr es ent a un pa s o i mpor t ant e haci a la cr eaci n
de un pr oc e s o de s of t wa r e adapt abl e en el que l os cambi os s e hagan par a mej or ar
aquel l os e l e me nt os del pr oc e s o que i nt r oducen er r or es .
"20 por tiento del cdigo tiene 80 por ciento de los errores. Encuntrelos, corrijnlos!"
Lowell Arthur
26.6.1 Un ejemplo genrico
Para i l ust rar la apl i caci n de l os m t o do s est ad st i cos en el t r abaj o de i ngeni er a del
s of t war e, s upnga s e que un a or gani zaci n d e i ngeni er a del s of t wa r e r ecopi l a i nfor-
maci n acer ca de def ect os dur a nt e un a o. Al gunos de l os de f e ct os s e de s cubr e n
c ua n do el s of t war e est e n desar r ol l o; ot r os, de s pu s de que s e ha l i ber ado e nt r e s us
us uar i os finales. Aunque se des cubr en ci ent os de di f er ent es def ect os, t odos t i enen
un a (o ms ) de l as c a us a s si gui ent es:
Especi f i caci ones i ncompl et as o e r r n e a s (E1E).
Mal a i nt er pr et aci n de la comuni caci n del cl i ent e (MCC).
Desvi aci n i nt enci onal de l as es peci f i caci ones (DIE).
Vi ol aci n de l os e s t nda r e s de pr ogr amaci n (VEP).
Er r or es e n la r epr es ent aci n de l os da t os (ERD).
I nt er f az de c o mp o n e n t e i ncons i s t ent e (ICI).
Error en la l gi ca del di s eo (ELD).
Pr ueba i ncompl et a o er r nea (PIE).
Docume nt aci n i mpr eci sa o i ncompl et a (DII).
Error en la t r aducci n del di s eo al l enguaj e de pr ogr amaci n (TLP).
I nt er f az hombr e - c omput a dor a a mbi gua o i ncons i s t ent e (IHC).
Mi s cel neo (MIS).
Para apl i car el a s e gur a mi e nt o de la cal i dad est ad st i ca del s of t wa r e s e cons t r uye la
t abl a de la figura 26. 5. La t abl a indica que EIE, MCC y ERD s on l as c a u s a s vi t al es que
TM
PDF Editor
CAP TULO 2 6 GESTIN DE LA CALIDAD
785
Toral Se r i os Mo d e r a d o s Me n o r e s
Error N m % N m % N m % N m %
EIE 2 0 5 22% 3 4 27% 6 8 18% 103 24%
MCC 156 17% 12 9% 6 8 18% 7 6 17%
0IE 4 8 5% 1 1% 2 4 6% 2 3 5%
VEP 2 5 3% 0 0% 15 4% 10 2%
ERD 130 14% 2 6 20% 6 8 18% 3 6 8%
ICI 5 8 6% 9 7% 18 5% 3 1 7%
ELD 4 5 5% 14 11% 12 3% 19 4%
PIE 9 5 10% 12 9% 3 5 9% 4 8 11%
CH1 3 6 4% 2 2% 2 0 5% 14 3%
TIP 6 0 6% 15 12% 19 5% 2 6 6%
IHC 2 8 3% 3 2% 17 4% 8 2%
M! S_ ^ 5 6 _ > %
_ 2
_ Q %
_ L
_ 4 % _ 9 %
Tolo les 9 4 2 100% 128 100% 3 7 9 100% 4 3 5 100%
expl i can el 53 por ci ent o de t odos l os er r or es. Sin e mbar go, s e debe obs er var que
EIE, ERD, TLP y ELD s e s el ecci onar an c o mo l as c a us a s vi t al es si sl o s e cons i der a-
r an l os er r or es ser i os. Una vez de t e r mi na da s l as c a us a s vi t al es, la or gani zaci n de
i ngeni er a del s of t wa r e puede c o me n z a r la acci n correct i va. Por ej empl o, par a co-
rregi r MCC, el desar r ol l ador de s of t wa r e pue de i mpl e me nt ar t cni cas que faciliten la
r ecopi l aci n de r equi si t os (cap t ul o 7) par a me j or ar la cal i dad de la comuni caci n y
l as es peci f i caci ones del cl i ent e. Para me j or ar ERD, el des ar r ol l ador pue de adqui ri r
he r r a mi e nt a s par a el mode l a do de dat os y ej ecut ar r evi s i ones de di s eo de da t os
m s r i gur osas.
Es i mpor t ant e anot ar que la acci n correct i va s e enf oca pr i nci pal ment e en l as vi-
t al es. Conf or me s t as s e cor r i gen, n ue va s candi dat as oc upa n la par t e s uper i or de la
cl asi fi caci n.
Las t cni cas de gar ant a est ad st i ca de la cal i dad par a s of t wa r e h a n de mos t r a do
que of r ecen una mej or a sust anci al en la cal i dad [ART97], En al gunos cas os , las or-
gani zaci one s de s of t wa r e han a l c a nz a do 50 por ci ent o de r educci n anual e n l os de-
f ect os de s pu s de apl i car e s t a s t cni cas.
La apl i caci n del SQA es t ad s t i co y el pri nci pi o de Par et o s e pue de n r es umi r en
una sol a or aci n: E m pl e e s u t ie m po e n fo c n d o s e e n l a s c o s a s q u e r e a l m e n t e im po r t a n ,
pe r o pr im e r o a s e g r e s e d e e n t e n d e r q u e s l o q u e r e a l m e n t e im po r t a
Un det al l ado anl i si s del SQA es t ad s t i co est m s all del mbi t o de es t e libro.
Los l ect or es i nt er es ados de be n cons ul t ar [GOH02], [SCH98] o [KAN95],
26.6.2 Seis sigma par a ingeniera del software
S e is s ig m a e s la est r at egi a m s a mpl i a me nt e e - o l e a d a en la act ual i dad par a el a s e -
gur a mi e nt o de la cal i dad est ad st i co en !a i ndust r i a. Or i gi nal ment e popul ar i zada por
TM
PDF Editor
Mot orol a en el de ce ni o de 1980, la est r at egi a s ei s s i gma "es un a met odol og a rigu-
rosa y di sci pl i nada que utiliza anl i si s de da t os y est ad st i co par a medi r y mej or ar e
d e s e mp e o oper at i vo de una c ompa a al i dent i f i car y el i mi nar l os ' def ect os ' en la
f abr i caci n y l os pr oc e s os r el aci onados con el servi ci o" [ISI03). El t r mi no "sei s sig-
ma" s e der i va de s ei s des vi aci ones e s t nda r 3. 4 i ns t anci as (defect os) por mi l l n de
ocur r enci as, lo que i mpl i ca un e s t nda r de cal i dad e xt r e ma da me n t e el evado. La
met odol og a s ei s s i gma def i ne t r es pa s o s cent r al es:
Cul es son De fin ir los r equi si t os del cl i ent e, ent r egabl es y me t a s del pr oyect o por me di o
los posos de m t odos bi en def i ni dos d e comuni caci n con el cl i ent e.
central es de lo
met odol og a sei s * M e " , r e ' pr oce s o exi s t ent e y s u sal i da par a det er mi nar el d e s e mp e o de cal i -
si gma? dad act ual (recopi l aci n de mt r i cas de def ect o) .
An a l iza r l as mt r i cas de de f e ct o y de t e r mi nar l as c a us a s p o c o vital es.
Si un pr oc e s o de s of t wa r e exi s t ent e es t en mar cha, pe r o s e r equi er e mej or a, sei s
s i gma sugi er e dos pa s o s adi ci onal es:
Me j o r a r el pr oc e s o e l i mi nando l as c a us a s or i gi nal es de l os def ect os.
Co n t r o l a r el pr oc e s o par a gar ant i zar que el t r abaj o f ut ur o no vuel va a i nt rodu-
cir l as c a us a s de def ect os.
Est os pa s os cent r al es y adi ci onal es a veces s e c onoc e n c o mo el m t odo DMAMC
(definir, medi r, anal i zar , mej or ar y cont r ol ar ) .
Si un a or gani zaci n es t des ar r ol l ando un pr oce s o de s of t wa r e (en l ugar de me
j or ar un pr oce s o exi st ent e) , l os pa s o s cent r al es s e a u me n t a n de la si gui ent e ma ne
ra:
Dis e a r el pr oce s o par a 1) evi t ar l as c a us a s or i gi nal es d e l os def ect os y 2) s a-
t i sf acer l os r equi si t os del cl i ent e.
Ve r ific a r que el mode l o de pr oces o, de hecho, evi t ar l os def ect os y s at i s f ar
l os r equi si t os del cl i ent e.
A es t a var i aci n a veces s e le l l ama m t o do DMADV (definir, medi r, anal i zar , dise
ar y verificar).
Una exposi ci n det al l ada de s ei s s i gma s e e nc ue nt r a en l as f uent es bi bl i ogrfi cas
dedi cadas a la mat er i a. El l ect or i nt er es ado de be cons ul t ar [ISI03], [SNE03] y
[PAN00].
2 6 . 7 f l f t B I H P A P P E L S OF T WAR E
La fiabilidad del s of t war e, a di f er enci a d e ot r os f act or es d e cal i dad, s e pue de medi r
dirigir y es t i mar e mpl e a ndo da t os hi st r i cos y de desar r ol l o. La fia b il id a d d e l s o ft wa -
r e s e def i ne en t r mi nos es t ad s t i cos c o mo "la pr obabi l i dad de la oper aci n l i bre de
fal l as de un pr ogr ama de comput ador a e n un e nt or no espec f i co dur a nt e un t i empo
espec f i co" [MUS87]. Con fines i l ust rat i vos, s e es t i ma que el pr ogr a ma X t i ene una
TM
PDF Editor
fiabilidad de 0, 96 dur a nt e un pe r i odo de oc ho hor a s de pr oces ami ent o. En ot r as pa-
l abr as, si el pr ogr a ma X f ue s e e j e cut ado 100 veces y r equi r i ese un total de ocho ho-
r as de t i e mpo de pr oc e s a mi e nt o (t i empo de ej ecuci n) , e s pr obabl e que oper ar a co-
r r e ct ame nt e (sin falla) 96 veces .
"El precio inevitable de ID fiabilidad es la simplicidad."
C.A.R. Honre
c f o v E
sde
casi siempre
i seguirse o
s en diseo o
tVE
s notar
F y los
s reiocionodos
sen
i x CPU, no en
i * reloj de
Si empr e que s e est udi a la fiabilidad del s of t war e, s ur ge un a pr egunt a cent r al : qu
si gni fi ca el t r mi no fa l l a ? En el cont ext o de cual qui er anl i si s de cal i dad y fi abi l i dad
del s of t war e, la falla e s la falta de concor danci a con l os r equi si t os del s of t war e. Sin
e mbar go, i ncl uso dent r o de es t a defi ni ci n, exi st en gr adi ent es . Las fal l as sl o pue-
den s er mol e s t as y cat ast r f i cas. Una falla pue de cor r egi r se en s egundos , mi e nt r as
que ot r a tal ve z r equi er a s e ma n a s o i ncl uso me s e s . Para compl i car el t e ma a n ms ,
la cor r ecci n de un a falla puede, de hecho, r es ul t ar en la i nt r oducci n de ot r os er r o-
r es que a final de c ue nt a s r es ul t an en ot r as fal l as.
26.7.1 Medidas de Habilidad y disponibilidad
Los pr i mer os t r abaj os en la fiabil idad del s of t war e i nt ent ar on ext r apol ar l as ma t e m -
t i cas de la t eor a de fiabilidad del ha r dwa r e (por ej empl o, [ALV64]) a la predi cci n de
la fi abi l i dad del s of t war e. La mayor a de l os mode l os de fi abi l i dad r el aci onada con el
ha r dwa r e t r at an acer ca de l as fal l as debi das al u s o m s que a l as que s e de be n a de-
f ect os de di seo. En el har dwar e , l as fal l as que s e deben al us o fsico (por ej empl o,
l os ef ect os de la t emper at ur a, la cor r osi n, l os c hoque s el ct ri cos) s on m s pr oba-
bl es que una falla r el aci onada con el di seo. Des di chadament e, lo opue s t o e s ci ert o
par a el s of t war e. De hecho, t odas l as fal l as de s of t wa r e s e or i gi nan en pr obl e mas de
di s eo o i mpl ement aci n, el u s o (cap t ul o 1) no ent r a en el cuadr o.
Ha habi do de ba t e s acer ca de la rel aci n ent r e conce pt os cl ave e n la fi abi l i dad del
ha r dwa r e y s u apl i cabi l i dad al s of t wa r e (por ej empl o, [LIT89], [ R0090] ) . Aunque t o-
dav a s e t i ene que es t abl ecer un v ncul o i rrefut abl e, val e la pe na cons i der ar u n o s
c ua nt os conce pt os s i mpl es que s e apl i can a e l e me nt os de a mb o s s i s t emas .
Si s e cons i der a un s i s t ema ba s a do en c omput a dor a , una si mpl e medi da de fiabi-
l idad e s el t ie m po m e d io e n t r e fa l l a s (TMEF), donde
TMEF = TMDF + TMDR
Las si gl as TMDF y TMDR si gni fi can t ie m po m e d io d e fa l l a y t ie m po m e d io d e r e pa r a -
c i n , r es pect i vament e. 6
Muchos i nves t i gador es a r gume nt a n que el TMEF e s con mu c h o m s fcil de me -
dir que l os def ect os/ KLDC o l os def ect os / PF. Est abl eci do de ma n e r a si mpl e, el us ua -
rio final est pr e oc upa do por l as fal l as, n o por el cont eo total de er r or es. Debi do a
6 Aunque se pueda requerir la depuracin iy correcosnes relacionadas) como consecuencia de una fa-
lla, en muchos casos el software trabajara adecuadamente despus de un reinicio sin otro cambio.
TM
PDF Editor
f c W W J O ^
Al g u n o s a s pe c t o s d e
l a d is po n ib il id a d ( n o
e s t u d ia d o s a q u ) n o
t ie n e n n a d a q u e v e r
c o n l a s fo l l a s . Po r
e j e m pl o , l o s r e c o r t e s
e n l a c a l e n d a iiza c i n
( pa r a fu n c io n e s d e
s o po r t e ) pr o v o c a n q u e
e l s o ft wa r e n o e s t
d is po n ib l e .
que cada defect o cont eni do dent ro de un pr ogr ama no tiene la mi sma tasa de falla,
la cuent a de defect os t ot al es ofrece poca i nformaci n de la Habilidad del sistema.
Adems de una medi da de fiabilidad, se debe desarrollar una medi da de disponi-
bilidad. La d is po n ib il id a d d e l s o ft wa r e es la probabilidad de que un programa opere
de acuerdo con los requisitos en un punt o dado del tiempo, y se define como
Disponibilidad = [TMDF/(TMDF + TMDR)] x 100%
La medi da de fiabilidad TMEF es i gual ment e sensible a TMDF y TMDR. La medi da de
disponibilidad es un poco ms sensible a TMDR, y es una medi da indirecta de la fa-
cilidad de mant eni mi ent o del soft ware.
26.7.2 Seguridad del software
La s e g u r id a d d e ! s o ft wa r e [LEV86] es una actividad de asegur ami ent o de la calidad de
soft ware que se enf oca en la identificacin y eval uaci n de los peligros pot enci al es
que pueden afect ar negat i vament e al soft ware y provocar una falla de t odo el siste-
ma. Si los peligros se pueden identificar t empr ano en el proceso de soft ware, l as ca-
ractersticas de di seo de soft ware se pueden especificar de modo que eliminarn c
control arn los peligros pot enci al es.
"No puedo imaginar alguna condicin que provoque que este barco se hunda. La industria naviera moderna ha ido
ms alt."
E. I. Smith, capitn del Tit o n k
Como parte de la seguridad del soft ware s e llevan a cabo procesos de modeladc
y anlisis. Inicialmente, los peligros se identifican y clasifican por importancia y ries-
go. Por ejemplo, al gunos de los peligros asoci ados con un control basado en com-
put adora para la conducci n de un aut omvi l pueden ser-,
Provoca acel eracin descont rol ada que no se puede det ener.
No responde a la presin del pedal de f r eno (al apagarlo).
No responde cuando el interruptor se activa.
Pierde o gana rapi dez l ent ament e.
Una vez identificados est os peligros en el nivel del sistema, medi ant e t cni cas de
anlisis se asi gnan severi dad y probabilidad de ocurrencia. 7 Para ser eficaz, el soft-
ware debe anal i zarse en el cont ext o de t odo el si st ema. Por ejempl o, un sutil error
de ent r ada de usuario (las per sonas son component es del sistema) tal vez lo magni -
fique una falla del soft ware para producir dat os de control que posi ci onan de mane-
ra i nadecuada un dispositivo mecni co. Si se rene un conj unt o de condi ci ones am-
7 Este enfoque es similar a los mtodos de anlisis de riesgo descritos en el captulo 25. La diferencia
principal es el nfasis en los contlictos tecnolgicos, ms que en los tpicos relacionados con el pro-
yecto.
TM
PDF Editor
Jno coleccin d i o s o
de ensayos acei t a de
i t Su r k Wd e soft ware
* puede encontrar en
www.safeware-
g. com/ .
bi ent al es e xt e r nas (y s l o si el l as s e r enen) , la posi ci n i nade cuada del di sposi t i vo
me cni co pr ovocar un a falla des as t r os a. Las t cni cas de anl i si s, c o mo el anl i si s
del rbol de fal l as [VES81), la l gi ca de t i empo real [JAN86] o l os mode l os de red de
Petri [LEV87], s e e mpl e a n par a pr edeci r la cade na de e ve nt os que pue de n pr ovocar
pel i gros y la pr obabi l i dad de que cada uno de l os e ve nt os ocurri r par a cr ear la ca-
dena.
Una vez i dent i f i cados y anal i zados l os pel i gros, se especi f i can l os r equi si t os rel a-
ci onados con la segur i dad del s of t war e. Est o es, la especi f i caci n pue de cont e ne r
un a lista de e ve nt os i ndes eabl es y l as r e s pue s t as de s e abl e s del s i s t ema ant e di chos
event os . Ent onces se i ndi ca el papel del s of t wa r e en la gest i n de l os e ve nt os i nde-
s eabl es .
Aunque la conf i abi l i dad del s of t war e y su s egur i dad es t n e s t r e c ha me nt e rel aci o-
na da s , e s i mpor t ant e e nt e nde r l as sut i l es di f er enci as ent r e el l as. La confi abi l i dad del
s of t wa r e utiliza anl i si s est ad st i co par a de t e r mi nar la pr obabi l i dad de que ocur r i r
un a falla del s of t war e . Sin e mbar go, el h e c h o de que ocur r a un a falla no neces ar i a-
me n t e r esul t a en un pel i gr o o per cance. La s egur i dad del s of t wa r e e xa mi na l as for-
ma s e n l as cual es l as fal l as r es ul t an en condi ci ones que pue de n conduci r a un per -
cance. Est o es, l as fal l as no s on cons i de r adas en el vac o, s i no que s e eval an en el
cont ext o de t odo un s i s t ema ba s a do en c omput a dor a y en s u ent or no. Aquel l os l ec-
t or es con mayor i nt er s de be n r emi t i r se al libro de Leveson [LEV95] par a pr of undi -
zar en el t ema.
DE CAL I DAD I S O 9 0 0 Q 8
K
CVVE
k 9000 describe lo
E se debe bocer pora
r Tmejable, pero no
cmo se debe
Es posi bl e defi ni r un s is t e m a d e g a r a n t a d e l a c a l id a d c o mo la est r uct ur a or gani zaci o-
nal , r es pons abi l i dades , pr ocedi mi ent os , pr oces os y r ecur s os par a i mpl ement ar la
gest i n d e la cal i dad [ANS87]. Los s i s t e mas de gar ant a de cal i dad f uer on cr e ados
par a ayudar a l as or gani zaci ones a gar ant i zar que s us pr oduct os y servi ci os s at i s f a-
cen l as expect at i vas de l os cl i ent es al cumpl i r s us especi f i caci ones. El e s t ndar ISO
9000 des cr i be un s i s t ema de gar ant a de la cal i dad en t r mi nos genr i cos que s e apl i -
can a cual qui er negoci o sin i mpor t ar l os pr oduct os o ser vi ci os of r eci dos.
El regi st ro e n u n o de l os mode l os de s i s t ema de gar ant a de la cal i dad cont eni dos
e n ISO 9000 r equi er e que los s i s t e mas y ope r a c i one s de cal i dad de una c ompa a l os
s o me t a n a escr ut i ni o audi t or es de una t er cer a ent i dad r es pect o de s u concor danci a
con el e s t nda r y de su f unc i ona mi e nt o ef i caz. Ant es del regi st ro exi t oso, l os audi -
t or es le ext i enden a la c ompa a un cer t i f i cado de la or gani zaci n de regi st ro que r e-
pr e s e nt an. Ent revi st as de audi t or a s e mi a nua l e s gar ant i zan la concor danci a cont i -
nua con el es t ndar .
8 Esta seccin, escrita por Michael Stovsky se ha adaptado de "Fundamentis of ISO 9000", un libro
de trabajo desarrollado por E s s e n t ia l S o r . - , ore un video curriculum elaborado por R. S.
Pressman & Associates, Inc. Reimpreso ccr. petir-iso
TM
PDF Editor
Extensos vnculos hocki
f ecwsos ISO
9 0 0 0 / 9 0 0 1 se
pueden encai t roi en
www.tantara.ab.
ca/info.htm.
El e s t nda r de gar ant a de la cal i dad q u e s e apl i ca a la i ngeni er a del s of t war e es
el ISO 9001: 2000. El e s t nda r cont i e ne 20 r equi si t os q u e de be n es t ar pr e s e nt e s par=
un s i s t ema ef i ci ent e de gar ant a de la cal i dad. Pues t o que el e s t ndar ISO 9001:200C
e s apl i cabl e a t oda s l as di sci pl i nas de i ngeni er a, s e ha des ar r ol l ado un conj unt o es-
peci al de di r ect r i ces ISO (ISO 9000-3) que a yuda n a i nt er pr et ar el e s t nda r par a em-
pl ear l o en el pr oce s o d e s of t war e.
Los r equi si t os que del i nea ISO 9001: 2000 a bor da n t pi cos c o mo r esponsabi l i dac
de la gest i n, s i s t ema de cal i dad, revi si n de cont r at o, cont r ol de di s eo, cont rol de
do c ume n t o s y dat os , i dent i fi caci n y s egui mi ent o de pr oduct o, cont rol de pr oces o
i nspecci n y pr uebas , acci one s cor r ect i vas y pr event i vas, cont r ol de r egi st r os de ca-
l idad, audi t or as de cal i dad i nt er na, e nt r e na mi e nt o, servi ci o y t cni cas est ad st i cas
Una or gani zaci n de s of t war e obt endr el r egi st r o ISO 9001: 2000 si es t abl ece polti-
cas y pr ocedi mi ent os par a abor dar cada u n o de l os r equi si t os a n o t a do s l neas arriba
(y ot ros) y, a de m s , s er c a pa z d e de mos t r a r q u e s e s i guen di chas pol t i cas y pr oced
mi ent os . Para ma yor i nf or maci n acer ca de ISO 9001, el l ect or i nt er es ado de be con-
sul t ar [HOYQ2], [GAA01] O [CIA01].
I NFORMACI N
a e s t n d a r IS O 9001 : 2000
Las siguientes lneas generales definen los ele-
mentos bsicos del est ndar ISO 9001: 2000.
Informacin ms ampl ia acerca del est ndar se puede ob-
tener de International Organi zat i on for Standardization
( www. i s o . c K) y e n o t r a s f u e n t e s d e I n t e r n e t ( p o r e j e mp l o ,
www. p r a x i o m. c o m) .
Establecer los elementos de un sistema de gestin de cali-
dad.
Desarrollar, implementar y mej orar el sistema.
Definir una poltica que enfatice la importancia del siste-
ma.
Documentar el sistema de cal i dad.
Describir el proceso.
Producir un manual operativo.
Desarrollar mtodos par a controlar (actualizar) los docu-
mentos.
Establecer mtodos par a la conservacin de registros.
Soporte del control y la garant a de cal i dad.
Promover la importancia de la calidad entre todos los
participantes.
, Enfocarse en la satisfaccin del cliente.
Definir un plan de calidad que abor de objetivos, respon-
sabilidades y aut ori dad.
Definir mecanismos de comunicacin entre los partici-
pantes.
Establecer mecanismos de revisin par a el sistema de ges-
tin de cal i dad.
Identificar mtodos de revisin y mecanismos de retroali-
mentacin.
Definir procedimientos de seguimiento.
Identificar recursos de cal idad que incluyan personal,
entrenamiento, elementos de infraestructura.
Establecer mecanismos de control.
Para pl aneacin.
Para requisitos del cliente.
Para actividades tcnicas (por ejemplo, anlisis, diseo,
pruebas).
Para supervisin y gestin del proyecto.
Definir mtodos par a correccin.
Valorar los dat os y mtricas de cal i dad.
Definir enfoques par a procesos continuos y mejora de la
cal i dad. ,
TM
PDF Editor
2 6 . 9 E L P L AN DE S Q A
El pl a n d e S QA pr opor ci ona un ma p a par a instituir la gar ant a de la cal i dad del sof t -
war e. Desar r ol l ado por el gr upo de SQA (o el equi po de s of t wa r e si no exi st e un gr u-
po SQA), el pl an f unci ona c o mo pl ant i l l a par a l as act i vi dades de SQA que s e i nst i t u-
yan par a cada pr oyect o de s of t war e.
En el IEEE [IEE94] s e ha publ i cado un e s t ndar par a pl anes de SQA. El e s t ndar
r e comi e nda un a es t r uct ur a que i dent i fi ca: I) el pr ops i t o y mbi t o del pl an; 2) una
descr i pci n de t odos l os pr oduct os de t r abaj o de i ngeni er a del s of t wa r e (por ej em-
pl o, model os , doc ume nt os , cdi go f uent e) q u e cae n de nt r o del al cance del SQA; 3)
t odos l os e s t nda r e s y pr ct i cas apl i cabl es que s e a pr ove c ha n dur a nt e el pr oce s o d e
s of t war e; 4) acci one s y t a r e a s de SQA (i ncl uso r evi s i ones y audi t or as) y s u ubi caci n
a t r avs del pr oce s o de s of t war e; 5) l as he r r a mi e nt a s y m t o do s que s opor t an l as ac-
ci ones y t ar eas de SQA; 6) pr ocedi mi ent os de gest i n de conf i gur aci n de s of t war e
(cap t ul o 27) par a ges t i onar el cambi o; 7) m t o do s par a ens ambl ar , s al vaguar dar y
ma n t e n e r t odos l os r egi st r os r el aci onados con el SQA; y 8) pape l e s y r esponsabi l i da-
de s en la or gani zaci n r el at i vas a la cal i dad de pr oduct o.
f
Ge s t i n d e l a c a l id a d d e l s o ft wa r e
Obj e t i v o : El objetivo de las herrami ent as de
SQA es auxiliar al equi po de proyecto par a va-
lorar y mej or ar la cal i dad del product o de t r abaj o de soft-
ware.
Me c ni c a : La mecni ca de las herrami ent as var a. En
general, la finalidad es val orar la cal i dad d e un product o
de t r abaj o especfico. Not a; con frecuenci a, dent ro de la
cat egor a de herrami ent as de SQA, se incluye una ampl i a
variedad de herrami ent as de pr ueba d e soft ware (captulos
13 y 14).
ARM, desarrol l ado por la NASA (sat c. gsfc. nasa. gov/ t ool -
s/index. html ), ofrece medi das con las cual es se eval a
la cal i dad de un document o de requisitos de software.
QPR Pr o c e s s Gu id e a n d S c o r e c a r d , desarrol l ada por QPR
Soft ware (www.qpronline.com), ofrece soporte pa r a
seis si gma y otros enf oques de gestin de cal i dad.
Qu a l it y To o l s Co o kb o o k, desarrol l ado por Sytsma and
Manl ey (www.sytsma . com/ t qmt ool s/ t qmt ool me-
nu.html), proporci ona descripciones tiles de herra-
mientas clsicas de gestin de cal i dad tales como los
di agr amas de control, di agr amas de dispersin, di a-
gr amas de afi ni dad y di agr amas de matriz.
Qu a l it y To o l s a n d Te m pl l e s , desarrol l adas por iSixSigma
(ht t p: / / www. i si xsi gma. com/ t t / ), descri be una ampl i a
var i edad de herrami ent as y mt odos tiles par a gestin
de cal i dad.
TQM To o l s , desarrol l ado por Bain & Company (www. bain.
com), bri nda descripciones tiles de una var i edad de
herrami ent as de gestin us adas por TQM y relaciona-
das con los mtodos d e gestin d e cal i dad.
V
9 Las herramientas expuestas slo representa- _na rruestra de esta categora. En la mayora de los
casos los nombres de las mismas sor. marcas registradas por sus respectivos desarroliadores.
TM
PDF Editor
792 P AR T E C U A T R O GESTIN DE PROYECTOS DE SOFTWARE
Pl.
La gest i n de la cal i dad del s of t wa r e e s una act i vi dad pr ot ect or a o de s om
que i ncor por a t a nt o cont r ol c o mo a s e gur a mi e nt o de la cal i dad que s e apl ica a
cada p a s o en el pr oc e s o del s of t war e. La SQA abar ca pr ocedi mi ent os par a la aplica-
ci n ef i caz de m t odos y he r r ami e nt as , r evi s i ones t cni cas f or mal es, es t r at egi as
t cni cas de pr uebas , pr ocedi mi ent os par a cont r ol del cambi o, pr ocedi mi ent os para
gar ant i zar la concor danci a con l os e s t nda r e s y me c a n i s mo s de medi ci n y r epone
La SQA la compl i ca la nat ur al e za compl ej a de la cal i dad del s of t war e, un at r i bt
t o de l os pr ogr a ma s de comput ador a que s e def i ne c o mo "concor danci a con les
r equi si t os es peci f i cados expl ci t a e i mpl ci t ament e". Per o c ua n do s e cons i der a ce
ma n e r a m s gener al , la cal i dad de s of t wa r e abar ca mu c h o s pr oduct os di f er ent es,
f act or es de pr oces o y mt r i cas r el aci onadas .
Las r evi si ones de s of t war e s on un a de l as act i vi dades de cont rol de cal i dad m s
i mpor t ant es . Las r evi s i ones si rven c o mo filtros a t r avs d e t oda s l as act i vi dades ce
i ngeni er a del s of t war e, q u e el i mi nan l os er r or es mi e nt r as son r el at i vament e po c :
cos t os os de encont r ar y corregi r. La revi si n t cni ca f or mal e s un a j unt a que ha de-
mos t r a do ser e xt r e ma da me nt e ef i caz par a descubr i r er r or es.
La act i vi dad a de c ua da par a gar ant i zar la cal i dad del s of t war e r equi er e recopi l ar
eval uar y di st ri bui r l os dat os acer ca de l os pr oce s os de i ngeni er a del s of t war e. La
SQA est ad st i ca ayuda a me j or ar la cal i dad del pr oduct o y el pr oce s o de s of t wa r e e r
s mi s mo. Los mode l os de fi abi l i dad del s of t wa r e ext i enden me di das , l o q u e per mi t e
recopi l ar dat os de def ect o par a ext r apol ar l os en l as t a s a s de falla pr oye ct adas y las
pr edi cci ones de fi abi l i dad.
En r e s ume n, r e cur de ns e l as pal abr as de Dunn y Ul l man [DUN82]: "El as egur a-
mi e nt o de la cal i dad del s of t war e e s el ma p e o (correl aci n) de l os pr ecept os ger en-
ci al es y l as di sci pl i nas de di s eo de la gar ant a de cal i dad en el es paci o ger enci al y
t ecnol gi co apl i cabl e de la i ngeni er a del s of t war e". La habi l i dad par a gar ant i zar la
cal i dad e s la medi da de un a di sci pl i na de i ngeni er a madur a. Cua ndo el ma p e o se lo-
gr a de ma n e r a exi t osa, el r es ul t ado e s la i ngeni er a de s of t wa r e madur a.
[ALV64] Alvin, W. H., von (ed.), Re l ia b il it y E n g in e e r in g , Prentice-Hall, 1964.
[ANS87] ANSI/ASQC A3-1987, Qu a l it y S y s t e m s Te r m in o l o g y , 1987.
[ART92] Arthur, L. J., Improving Soft ware Quality: an Insider' s Guide to TQM, Wiley, 1992.
|ART97] Arthur, L. J., "Quantum Improvements in Software System Quality, en CACM, vol. 40,
nm. 6, junio de 1997, pp. 47-52.
[BOE81] Boehm, B S o ft wa r e E n g in e e r in g E c o n o m ic s , Prentice-Hall, 1981.
[C1A01] Cianfrani, C. A. e l a l . , IS O 9001 : 2000 E x pl a in e d , 2a. ed., American Society for Quality,
2 0 0 1 .
[CR0791 Crosby, P Qu a l it y Is Fr e e , McGraw-Hill, 1979.
|DEM86] Deming, W. E., Ou l o f t h e Cr is is , MIT Press, 1986.
[DEM99] DeMarco, T., "Management Can make Quality (im)possible", Cutter IT Summit, Boston,
abril de 1999.
TM
PDF Editor
CAP TULO 2 6 GESTIN DE LA CALIDAD 793
[DIJ76] Dijkstra, E., A Dis c ipl in e o f Pr o g r o m m in g , Prentice-Hall, 1976.
[DUN82] Dunn, R., y R. Ullman, Qu a l it y As s u r a n c e fo r Co m pu t e r S o ft wa r e , McGraw-Hill, 1982.
[FRE901 Freedman, D. P. y G, M. Weinberg, Ha n d b o o k o /Wa l kt h r o u g h s , In s pe c t io n s a n d Te c h n ic a l
Re v ie ws , 3a. ed., Dorset House, 1990.
[GAAO1 ] Gaal, A., IS O 9001 : 2000fo r S m a l l Bu s in e s s , Saint Lucie Press, 2001.
(G1L93] Gilb, T., y D. Graham, S o ft wa r e In s pe c t io n s , Addison-Wesley, 1993.
[GLA98] Glass, R , "Defining Quality Intuitively", en IE E E S o ft wa r e , mayo de 1998,pp. 103-104,107.
[GOH02] Goh, T., V. Kuralmani y M. Xie, S t a t is t ic a l Mo d e l s a n d Co n t r o l Ch a r t s fo r Hig h Qu a l it y Pr o
c e s s e s , Kluwer Academic Publishers, 2002.
[HOY02] Hoyle, D IS O 9000 Qu a l it y S y s t e m s De v e l o pm e n t Ha n d b o o k: A S y s t e m s E n g in e e r in g Ap-
pr o a c h , 4a. ed., Butterworth-Heinemann, 2002.
[IBM81] "Implementing Software Inspections", not as de curso, IBM Systems Sciences Institute,
IBM Corporation, 1981.
[1EE94] S o ft wa r e E n g in e e r in g S t a n d a r d s , 1994, IEEE Computer Society, 1994.
[ISI03] iSixSigma, LLC, "New to Six Sigma: A Guide for Both Novice and Experienced Quality
Practitioners", 2003, disponible en http://www. isixsigma. com/l ibrary/content/six-sigma-
newbie.asp.
[)AN86] Jahanian, F. y A. K. Mok, "Safety Analysis of Timing Properties of Real-Time Systems",
en IE E E TTa n s . S o ft wa r e E n g in e e r in g , vol. SE-12, nm. 9, septiembre de 1986, pp. 890-904.
[JON86] Jones, T. C., Pr o g r a m m in g Pr o d u c t iv it y , McGraw-Hill, 1986.
[KAN95] Kan, S. H., Me t r ic s a n d Mo d e l s in S o ft wa r e Qu a l it y E n g in e e r in g , Addison-Wesley, 1995.
[LEV86] Leveson, N. G "Software Safety: Why, What, and How", en ACM Co m pu t in g S u r v e y s , vol.
18, nm. 2, junio de 1986, pp. 125-163.
[LEV87] Leveson, N. G. y ) . L. Stolzy, "Safety Analysis Using Petri Neis", en IE E E TTa n s . S o ft wa r e
Engineering, vo\. SE-13, nm. 3, marzo de \987, pp. 386-397.
(LEV95) Leveson, N. G., S a fe wa r e : S y s t e m S a fe t y a n d Co m pu t is , Addison-Wesley, 1995.
[LIN79I Linger, R., H. Mills y B. Witt, S t r u c t u r e d Pr o g r a m m in g , Addison-Wesley, 1979.
ILIT89] Littlewood, B "Forecasting Software Reliability", en S o ft wa r e Re l ia b il it y : Mo d e l in g a n d
Id e n t ific a t io n (S. Bittanti, ed.), Springer-Verlag, 1989, pp 141-209.
[MUS871 Musa, J. D., A. lannino y K. Okumoto, E n g in e e r in g a n d Ma n a g in g S o ft wa r e wit h Rc l ia h i
l it y Me a s u r e s , McGraw-Hill, 1987.
[PAN00] Nande, P. et a l , Th e S ix S ig m a Wa y , McGraw-Hill, 2000.
[POR95] Porter, A., H. Siy, C. A. Toman y L. G. Votta, "An Experiment to Assess the Cost-Bene-
fits of Code Inspections in Large Scale Software Development", en Pr o c . Th ir d ACM S IG- S OFT
S y m po s iu m o n t h e Fo u n d a t io n s o f S o ft wa r e E n g in e e r in g , Washington, D.C., octubre de 1995,
ACM Press, pp. 92-103.
[R0090] Rook, S o ft wa r e Re l ia b il it y Ha n d b o o k, Elsevier, 1990.
[SCH98] Schulmeyer, G. C. y J. I. McManus (eds.), Ha n d b o o k o f S o ft wa r e Qu a l it y As s u r a n c e , 3a.
ed., Prentice-Hall, 1998.
[SOMOl] Somerville, I., S o ft wa r e E n g in e e r in g , 6a. ed., Addison-Wesley, 2001.
[SNE03] Snee, R. y R. Hoerl, Le a d in g S ix S ig m a , Prentice-Hall, 2003.
[THE01] Thelin, T., H. Petersson y C. Wohlin, "Sample Driven Inspections", en Pr o c e e d in g s Wo r ks
h o p o n In s pe c t io n in S o ft wa r e E n g in e e r in g ( WIS E ' 01 ) , Pars, Francia, julio de 2001, pp. 81-91,
se puede descargar de ht t p: / / www. cas. mcmast er. ca/ wi se/ wi seOI/ t hel i nPet ersson-Woh-
lin.pdf.
[VES811 Veseley, W. E. e t a l . , Fa u l t Tr e e Ha n d b o o k, U.S. Nuclear Regulatory Commission, NUREG-
0492, enero de 1981.
26. 1. En las primeras pginas de este capitulo se anot que "el control de la variacin es el co-
razn del control de calidad". Dado que cualquier programa que se crea es diferente de todos
los otros programas, cules son las variaciones que se buscan y cmo se les controla?
26. 2. Es posible valorar la calidad del sortv. are si el cliente cambia con frecuencia lo que se
supone debe hacer?
TM
PDF Editor
26. 3. La calidad y la fiabilidad son conceptos relacionados pero fundamentalmente di ferent e
en varias formas. Comntense.
26. 4. Puede un programa ser correcto y an as no ser fiable? Expliqese.
26. 5. Puede un programa ser correcto y an as no mostrar buena calidad? Expliqese.
26. 6. Por qu con frecuencia existe tensin entre un grupo de ingeniera de software y un gr_-
po independiente de aseguramiento de la calidad del software? Esto es saludable?
26. 7. A usted le han dado la responsabilidad de mejorar la calidad del software por medio ce
su organizacin. Qu es lo primero que debe hacer? Qu sera lo siguiente?
26. 8. Adems de contar errores y defectos, existen otras caractersticas contables del softwa-
re que impliquen calidad? Cules son y cmo se pueden medir directamente?
26. 9. Una revisin tcnica formal slo es eficaz si todos se han preparado por anticipado. Ce-
rno reconoce en la revisin a un participante que no est preparado? Qu hace si usted es e
jefe de revisin?
26. 10. Algunas personas argumentan que una RTF debe valorar el estilo de programacin, as
como la correccin. sta es una buena idea? Por qu?
26. 11. Revise la tabla presentada en la figura 26.5 y seleccione cuatro causas vitales de ene-
res serios y moderados. Sugiera acciones correctivas empleando la informacin presentada en
otros captulos.
26. 12. Investigue la bibliografa acerca de la fiabilidad del software y escriba un ensayo que
describa un modelo de fiabilidad de software. Asegrese de proporcionar un ejemplo.
26. 13. El concepto de TMEF para software est abierto a crticas. Puede pensar en algunas ra-
zones de por qu sucede as?
26. 14. Considere dos sistemas crticos de seguridad que se controlan mediante computadoras
Haga una lista con al menos tres peligros para cada uno que puedan estar ligados directamen-
te con las fallas de software.
26. 15. Adquiera una copia de ISO 9001:2000 e ISO 9000-3. Prepare una presentacin que exa-
mine tres requisitos ISO 9001 y cmo se aplican en un contexto de software.
O T P A S l - E CT t l P AS Y PUEWTBS DE l N P O B M A C l 6
Los libros de Moriguchi (S o ft wa r e E x c e l l e n c e : A To t a l Qu a l it y Ma n a g e m e n t Cu id e , Productivity
Press, 1997) y Horch (Pr a c t ic a i Gu id e t o S o ft wa r e Qu a l it y Ma n a g e m e n t , Artech Publishing, 1996)
son excelentes presentaciones, en el mbito gerencial, de los beneficios de los programas for-
males de aseguramiento de la calidad del software de computadora. Los libros de Deming
[DEM861, Juran ( Ju r a n o n Qu a l it y b y De s ig n , Free Press, 1992) y Crosby ([CR079] y Qu a l it y Is S t il i
Fr e e , McGraw-Hill, 1995) no se enfocan en el software, pero son una lectura obligada para los
gestores ejecutivos con responsabilidad en el desarrollo de software. Gluckman y Roome ( E v e r y -
d a y He r o e s o f t h e Qu a l it y Mo v e m e n t , Dorset House, 1993) humanizan los temas de calidad al con-
tar la historia de los actores en el proceso de calidad. Kan (Me t r ic s a n d Mo d e l s in S o ft wa r e Qu a -
l it y E n g in e e r in g , Addison-Wesley, 1995) presenta una visin cuantitativa de la calidad del soft-
ware.
Cianfani y sus colegas (IS O 9001 : 2000 E x pl a in e d , segunda edicin, American Society for Qua-
lity, 2001) y Gaal (/SO 9001 . 2000fo r S m a l l Bu s in e s s : Im pl e m e n t in g Pr o c e s s - Appr o a c h Qu a l it y Ma -
n a g e m e n t , St. Lucie Press, 2001) estudian el estndar de calidad ISO 9001:2000. Tingley ( Co m -
pa r in g IS O 9000, Ma l c o l m Ba l d r ig e , a n d t h e S E I CMM fo r S o ft wa r e , Prentice-Hall, 1996) ofrecen
una gua til para las organizaciones que luchan por mejorar sus procesos de gestin de cali-
dad.
Los libros de George ( Le a n S ix S ig m a , McGraw-Hill, 2002), Pande y sus colegas (Th e S ix S ig -
m a Wa y Fie l d b o o k, McGraw-Hill, 2001) y Pyzdek (Th e S ix S ig m a Ha n d b o o k, McGraw-Hill, 2000)
TM
PDF Editor
CAP TULO 2 6 GESTIN DE LA CALIDAD
795
describen seis sigma, una tcnica estadstica de gestin de calidad que conduce a productos que
tienen muy bajas tasas de defectos.
Radice {Hig h Qu a l it y , Lo w Co s t S o ft wa r e In s pe c t io n s , Paradoxicon Publishers, 2002), Wiegers
(Peer Re v ie ws in S o ft wa r e : A Pr a c t ic a l Cu id e , Addison-Wesley, 2001), Gilb y Graham (S o ft wa r e In s -
pe c t io n , Addison-Wesley, 1993) y Freedman y Weinberg (Ha n d b o o k o /Wa l kt h r o u g h s , In s pe c t io n s
a n d Te c h n ic a l Re v ie ws , Dorset House, 1990) ofrecen directrices valiosas para llevar a cabo revi-
siones tcnicas formales efectivas.
Musa (S o ft wa r e Re l ia b il it y E n g in e e r in g : Mo r e Re l ia b l e S o ft wa r e , Fa s t e r De v e l o pm e n l a n d Te s t in g ,
McGraw-Hill, 1998) ha escrito una gua prctica para tcnicas de fiabilidad de software aplica-
do. Kapur e l a l . ( Co n t r ib u t io n s t o Ha r d wa r e a n d S o ft wa r e Re l ia b il it y Mo d e l in g , World Scientific Pu-
blishing Co., 1999), Gritzalis (Re l ia b il it y ; Qu a l it y a n d S a fe l y o f S o ft wa r e - l n t e n s iv e S y s t e m s , Kluwer
Academic Publishers, 1997) y Lyu (Ha n d b o o k o f S o ft wa r e Re l ia b il it y E n g in e e r in g , McGraw-Hill,
1996) han editado antologas de importantes ensayos acerca de la fiabilidad del software.
Hermann (S o ft wa r e S a fe t y a n d Re l ia b il it y , Wiley-IEEE Press, 2000), Storey ( S a fe t y - Cr it ic a l Co m -
pu t e r S y s t e m s , Addison-Wesley, 1996) y Leveson [LEV95] continan siendo los estudios ms de-
tallados de la seguridad del software publicados a la fecha. Adems, van der Meulen (De ft n it io n s
fo r Ha r d wa r e a n d S o ft wa r e S a fe t y E n g in e e r s , Springer-Verlag, 2000) ofrece un compendio com-
pleto de importantes conceptos y trminos de fiabilidad y seguridad. Gartner (Te s t in g S a fe t y - Re -
l a t e d S o ft wa r e , Springer-Verlag, 1999) ofrece una gua especializada para probar sistemas cru-
ciales de seguridad. Friedman y Voas (S o ft wa r e As s e s s m e n t : Re l ia b il it y S a fe t y a n d Te s t a b il it y , Wi-
ley, 1995) ofrecen modelos tiles para valorar la fiabilidad y la seguridad.
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de la ges-
tin de calidad de software. Una lista actualizada de referencias en la World Wide Web se pue-
de encontrar en el sitio Web SEPA:
TM
PDF Editor
CAPI TULO
A
GES TI N
DEL CAMBI O
C O N C E P T O S
CLAVE
8 1 3
7 9 7
control
de l o versi n . . 822
control
del cambi o . . . . 8 1 0
depsi t o 8 0 3
tCS 8 0 1
e s t n d a r e s . . . . 824
GCWebApp . . . 8 1 4
gest i n
del cont eni do . . 8 1 7
identificacin . . 8 0 7
de es t ado 8 1 4
(mea bas e . . . . 8 0 0
obj et os de
configuracin . . 8 0 7
pr ot oso de CCS . 8 0 6
SVC 8 0 9
E
l cambi o e s i nevi t abl e c u a n d o s e cons t r uye s of t war e de c omput a dor a . Y _
cambi o a u me n t a el gr ado de conf us i n ent r e l os i ngeni er os de s of t wa r e que
t r abaj an en un pr oyect o. La conf us i n s ur ge c ua ndo l os c a mbi os n o s e ana
l izan a nt e s de r eal i zar l os, no s e r egi st r an a nt e s de i mpl ement ar l os , n o se repor-
t an a qui e ne s de be n s aber l o o n o s e cont r ol an en un a f or ma que mej or ar a
cal i dad y reduci r el error. Babi ch [BB86J abor da es t o c ua n do af i r ma:
El arte de coordinar el desarrollo de software para minimizar... la confusin se llama
gestin de la configuracin. La gestin de la configuracin es el arte de identificar, or-
ganizar y controlar modificaciones al software que se construye por medio de un
equipo de programacin. La meta es maximizar la productividad al minimizar las
equivocaciones.
La gest i n del cambi o, m s us ua l me nt e l l amada g e s t i n d e l a c o n fig u r a c i n d e
s o ft wa r e (GCS o GC), e s un a act i vi dad pr ot ect or a (sombri l l a) que s e apl i ca a lo
l ar go del pr oce s o d e s of t war e. Pues t o q u e el c a mbi o pue de ocurri r en cual qui er
mome nt o, l as act i vi dades d e GCS s e des ar r ol l an par a 1) i dent i fi car el cambi o, 2
cont r ol ar el cambi o, 3) gar ant i zar q u e el c a mbi o s e i r npl ement ar de ma ne r a
a de c ua da , y 4) r epor t ar l os c a mbi os a ot r os que pudi er an es t ar i nt er es ados .
Es i mpor t ant e di st i ngui r con cl ari dad ent r e s opor t e de s of t wa r e y gest i n de
la conf i gur aci n del s of t war e. El s opor t e e s un conj unt o de act i vi dades de i nge-
nier a del s of t war e que ocur r en de s pu s de que s t e s e h a e nt r e ga do al cl i ent e y
f ue pue s t o en oper aci n. La gest i n de la conf i gur aci n del s of t wa r e e s un con-
j unt o de act i vi dades d e s e gui mi e nt o y cont r ol q u e s e i ni ci an c ua n do c omi e nz a
un pr oyect o de i ngeni er a del s of t wa r e y t er mi nan s l o c ua n do s t e s e ret i ra de
oper aci n.
Qu e s ? Cuando se construye
software de comput adora los cam-
bios ocurren. Y puesto que ocurren,
es necesario gestionarlos con efica-
cia. La gestin del cambio, tambin
llamada gestin de la configuracin del softwa-
re (GCS), es un conjunto de actividades disea-
das para gestionar el cambi o al identificar los
productos de t rabaj o que probablemente cam-
bien, establecer relaciones entre ellos, definir
mecanismos par a gestionar diferentes versiones
de estos productos de t rabaj o, controlar los
cambios impuestos y auditor e informar los cam-
bios realizados. '7;
Qui n l o ha c e ? Todos los involucrados en el
proceso de software estn involucrados con la
gestin del cambi o en alguna medi da, pero en
ocasiones se crean posiciones de soporte espe-
cializado para gestionar el proceso de GCS.
Por q u e s i mpo r t a nt e ? Si no se controla el
cambio, l toma el control. Y eso nunca es
bueno. Es muy fcil que una corriente de cam-
TM
PDF Editor
CAP TULO 27 GESTIN DEL CAMBIO
797
bios incontrolados convierta en catico un pro-
yecto de software bien mplementado. Por esta
razn, ia gestin del cambio es una part e esen-
cial de la buena gestin del proyecto y de una
slida prctica de ingeniera de software.
Cul es s o n l os p a s o s ? Puesto que muchos
productos de t rabaj o se producen cuando se
construye el software, cada uno debe identificar-
se en forma individual. Una vez hecho esto se
establecen los mecanismos de control de versin
y cambio. El proceso se audita par a garant i zar
que ia calidad se conserva conforme e cambio
se realiza y que quienes tienen necesidad de
conocerlo reciben informacin acerca de los
cambios mediante los informes respectivos.
Cul e s el pr oduc t o o b t e n i d o ? Un plan de
gestin de la configuracin del software define
la estrategia del proyecto para la gestin del
cambio. Adems, cuando se pi de una GCS far-
mal, el proces de control' del cambi o produc
solicitudes de cambi o de software, informes y
peticiones de cambio de ingeniera.
C mo p u e d o e s t a r s e g u r o d e q u e l o he
h e c h o c o r r e c t a me nt e ? Guando cualquier
producto de t rabaj o puede explicarse, seguirse y
controlarse; cuando los cambios puede seguirse
y anal izarse; cuando todos los que necesitan
saber acerca de un cambio han sido informa-
dos, el t rabaj o se ha hecho bien.
Una me t a pr i mor di al de la i ngeni er a del s of t wa r e e s me j or ar la faci l i dad con la
que l os c a mbi os s e pue de n a c omoda r y r educi r el e s f ue r zo c ua n do l os cambi os se
de be n real i zar. En e s t e cap t ul o s e est udi an l as acci ones espec f i cas que per mi t en
ges t i onar el cambi o.
2 7 . 1 G E S T I N P E LA C O N F I G U R A C I N BEL S OF T WAR E
La sal i da del pr oce s o de s of t wa r e e s i nf or maci n que s e pue de dividir en t r es ampl i as
cat egor as: 1) pr o gr a ma s de c omput a dor a (t ant o al ni vel de f ue nt e c o mo de f or mas
ej ecut abl es) ; 2) pr oduct os de t r abaj o que des cr i ben l os pr ogr a ma s de c omput a dor a
(dirigidos t ant o a pr of es i onal es t cni cos c o mo a usuar i os) , y 3) dat os ( i nt er nos o
e xt e r nos al pr ogr ama) . Los e l e me nt os que c o mpr e n de n la i nf or maci n pr oduci da
c o mo par t e del pr oce s o de s of t wa r e s e de n o mi n a n col ect i vament e c o n fig u r a c i n d e l
s o ft wa r e .
Si c a da e l e me nt o de conf i gur aci n s i mpl e me nt e conduj e r a a ot r os e l e me nt os
habr a poca conf us i n. Por desgr aci a, ot r a var i abl e ent r a e n el pr oces o: el c a m b io .
st e pue de ocurri r en cual qui er mome nt o, por cual qui er r azn. De hecho, la pr i me-
ra ley de la i ngeni er a de s i s t e ma s [BER801 af i r ma: "No i mpor t a dnde s e e nc ue nt r e
en el ciclo de vida del s i s t ema, el s i s t ema cambi ar y el de s e o de cambi ar l o per si st i -
r a lo l argo de t odo el ci cl o de vi da".
"No hoy nada permanente, excepto el cambi o. "
Her di t o, 5 0 0 a . C
Cul e s el or i gen de e s t os c a mb i o s ' La r es pues t a e s t an var i ada c o mo l os c a m-
bi os mi s mos . Sin e mbar go, exi st en cuat r o f ue nt e s f unda me nt a l e s de cambi o:
TM
PDF Editor
A Cul es el
W origen de los
cambios que se
requi eren par a el
s o f t wa r e ?
Cules son
l as met as y
l as act i vi dades
real i zadas por
cada uno de los
part i ci pant es
involucrados en la
gestin del cam-
bi o?
Nuevas condi ci ones en el negoci o o me r c a do di ct an l os cambi os e n l os r e qu-
si t os del pr oduct o o l as r egl as del negoci o.
Nuevas ne c e s i da de s del cl i ent e d e ma n d a n la modi f i caci n de l os da t os que
pr oduce n l os s i s t e ma s de i nf or maci n, de la f unci onal i dad que ent r egan los
pr oduct os o l os ser vi ci os que ent r ega un s i s t ema ba s a do e n comput ador a.
La r eor gani zaci n o el cr eci mi ent o o r educci n del negoci o pr ovocan cambi os
en l as pr i or i dades del pr oyect o o e n la es t r uct ur a del e qui po de i ngeni er a de!
s of t war e.
Rest r i cci ones pr e s upus t al e s o de cal endar i zaci n i nducen un a redefi ni ci n
del s i s t ema o pr oduct o.
La gest i n de la conf i gur aci n del s of t wa r e e s un c onj unt o de act i vi dades que s e h a -
des ar r ol l ado par a ges t i onar el c a mbi o a lo l argo del ci cl o de vida del s of t war e ce
comput ador a. La GCS s e cons i der a c o mo una act i vi dad de a s e gur a mi e nt o de la ca.
dad del s of t wa r e q u e s e apl i ca a lo l ar go del pr oc e s o r espect i vo. En l as s ecci one;
s i gui ent es s e e xa mi na n l as pr i nci pal es t a r e a s de la GCS y c onc e pt os i mpor t ant e s que
a yuda n a ges t i onar el cambi o.
27.1.1 Un escenario de GCS1
Un t pi co e s ce nar i o oper at i vo d e GCS i nvol ucr a un gest or de pr oyect o a car go de un
gr upo de s of t war e; un ges t or de conf i gur aci n a c a r go de l os pr ocedi mi ent os y poli-
t i cas de GC; l os i ngeni er os de s of t war e r e s pons abl e s del des ar r ol l o y mant e ni mi e r
t o del pr oduct o de s of t war e, y el cl i ent e q u e e mpl e a el pr oduct o. En el e s c e n a n :
s upn ga s e que el pr oduct o e s pe que o e i nvol ucr a cer ca de 15 000 l neas de cdigc
que des ar r ol l ar un e qui po de sei s pe r s onas . (Nt ese que s on pos i bl es ot r os es cena-
ri os d e equi pos me n o r e s o mayor es , per o, e n es enci a, exi st en conf l i ct os genr i cos
que cada uno de es t os pr oyect os e nf r e nt a en r el aci n con la GC.)
En el mbi t o oper at i vo el es cenar i o i nvol ucr a di ver s os pape l e s y t ar eas . La met
del gest or del pr oyect o e s gar ant i zar que el pr oduct o s e e nt r e gue dent r o de ci enc
per i odo. En cons ecuenci a, el ges t or super vi sa el pr ogr es o del desar r ol l o y r econoce
y r eacci ona ant e l os pr obl emas . Est o s e h a c e al ge ne r ar y anal i zar l os i nf or mes acer-
ca del e s t a do del s i s t ema de s of t wa r e y al r eal i zar r evi si ones en el s i s t ema.
Las me t a s del ges t or de conf i gur aci n s on gar ant i zar que s e s i guen los procedi -
mi e nt os y pol t i cas par a cr ear , cambi ar y pone r a pr ue ba el cdi go, as c o mo posibi-
litar el a c c e s o a la i nf or maci n acer ca del pr oyect o. La i mpl ement aci n de t cni cas
par a ma n t e n e r el cont r ol s obr e l os c a mbi os de cdi go r equi er e que es t e ges t or intro-
duzca me c a n i s mo s par a sol i ci t ar of i ci al ment e cambi os , eval uar l os ( medi ant e una
j unt a de cont r ol de cambi os , que e s la r es pons abl e de a pr oba r l os c a mbi os al si st e-
I Esta seccin procede de [DAROII. El permiso especial para reproducir "Spectrum of Functionality ir.
CM Systems" de Susan Dart [DAROI], 2001 por Carnegie Mellon University, lo otorg el Software
Engineering Institute.
TM
PDF Editor
CAPTULO 27 GESTIN DEL CAMBIO 799
kVE
un
poro
rque los
s amultneos al
: imponente
ma de s of t war e) y aut or i zar l os. El gest or cr ea y di st r i buye l as l i st as de t a r e a s par a l os
i ngeni er os y b s i c a me nt e cr ea el cont ext o del pr oyect o. Adems , el ges t or recopi l a
es t ad s t i cas ace r ca de c o mp o n e n t e s en el s i s t ema de s of t war e, por ej empl o: la i nfor-
maci n q u e de t e r mi na cul es c o mp o n e n t e s s on pr obl emt i cos e n el s i s t ema.
La me t a de l os i ngeni er os de s of t war e e s t r abaj ar con ef i ci enci a. Est o si gni fi ca que
n o i nt er f i er en d e ma n e r a i nneces ar i a u n o s con ot r os en la cr eaci n y pr ueba del
cdi go ni en la pr oducci n de l os do c ume n t o s de s opor t e. No obs t ant e , al mi s mo
t i empo, i nt ent an comuni car s e y coor di nar s e de ma n e r a ef i ci ent e. Espec f i cament e,
l os i ngeni er os ut i l i zan he r r a mi e nt a s que ayudan a cons t r ui r un pr oduct o de s of t wa-
re cons i s t ent e. Ellos s e c omuni c a n y coor di nan al not i f i car se mu t u a me n t e l as t ar eas
que se r equi er en y l as t ar eas cumpl i das. Los cambi os s e pr opa ga n por me di o del t ra-
baj o d e cada u n o me di ant e ar chi vos f us i onados . Existen me c a n i s mo s par a as egur ar
que, r es pect o de l os c o mpo n e n t e s que e xpe r i me nt an c a mbi os s i mul t neos , exi st e
al guna f or ma de r esol ver l os conf l i ct os y f us i onar l os cambi os . La hi st ori a d e la evo-
l uci n de t odos l os c o mp o n e n t e s del s i s t ema s e ma nt i e ne j unt o con un regi st ro de
l as r a z o n e s de l os c a mbi os y ot r o de lo que c a mbi e n real i dad. Los i ngeni er os t i e-
n e n s u pr opi o e s paci o de t r abaj o par a cr ear , cambi ar , pr obar e i nt egr ar cdi go. En
ci er t o punt o, el cdi go s e convi er t e en una l nea ba s e a part i r de la que cont i na el
des ar r ol l o post er i or y des de la que s e r eal i zan l as var i ant es par a ot r as m qui n a s que
t ambi n s e a n el obj et i vo.
El cl i ent e empl ea el product o. Dado que el pr oduct o l o cont r ol a la GC, el cl iente si gue
pr ocedi mi ent os f or mal es par a solicitar cambi os e i ndi car los b u g s en el product o.
I deal ment e, un s i s t ema de GC ut i l i zado en es t e e s ce nar i o apoyar a t odas e s t a s
f unci one s y t ar eas ; e s t o es, l as f unci one s de t e r mi nan la f unci onal i dad r equer i da de
un s i s t ema de GC. El gest or del pr oyect o ve una GC c o mo un me c a ni s mo de audi t or a;
el ges t or de conf i gur aci n, c o mo un me c a ni s mo de cr eaci n de cont r ol , s egui mi en-
t o y pol t i cas; el i ngeni er o de s of t war e, c o mo un me c a ni s mo d e cont r ol del cambi o,
la cons t r ucci n y el acces o; y el usuar i o, c o mo un me c a n i s mo de gar ant a de la cal i -
dad.
27.1.2 Elementos de un sistema de gestin de la configuracin
En s u det al l ado art cul o acer ca de la gest i n de la conf i gur aci n del s of t war e, Sus an
Dart [DAR01] i dent i fi ca cuat r o i mpor t ant es e l e me nt os que de be n es t ar pr e s e nt e s
c ua n do s e desar r ol l a un s i s t ema de ges t i n de la conf i gur aci n:
E l e m e n t o s d e c o m po n e n t e s : conj unt o de he r r a mi e nt a s acopl adas dent r o de un
s i s t ema de gest i n de ar chi vos por ej empl o, un a ba s e de dat os) que per mi t en
el a c c e s o y la gest i n de cada e l e me nt o de conf i gur aci n del s of t war e .
E l e m e n t o s d e pr o c e s o : ser i e de pr oce ci mi ent os y t a r e a s que def i nen un
e nf oque ef i caz con el cual ges t i onar el cambi o (y act i vi dades r el aci onadas)
par a t odos l os par t i ci pant es e r .a gest i n i ngeni er a y ut i l i zaci n del s of t wa r e
de c omput a dor a .
TM
PDF Editor
( C O N S U O .
La m a y o r a d e l o s
c a m b io s d e s o ft wa r e
e s t n j u s t ific a d o s , a s i
q u e n o h a y r a z n
pa r a q u e j a r s e a c e r c o
d e e l l o s . Ms b ie n , e s
n e c e s a r io a s e g u r a r s e
d e q u e s e t ie n e n l o s
m e c a n is m o s a pr o -
pia d o s po r a m a n e -
j a r l o s .
O
CLAVE
Un producto de trobojo
de ingeniera del
soft ware se convierte
en lineo bose slo
Despus de que se ha
?s ado y aprobado.
E l e m e n t o s d e c o n s t r u c c i n : c onj unt o de he r r a mi e nt a s que a ut oma t i z a n la
cons t r ucci n del s of t wa r e al as e gur ar que s e ha e n s a mbl a do un conj unt o
a de c ua do de c o mpo n e n t e s val i dados (es deci r: la ver s i n cor r ect a) .
E l e m e n t o s h u m a n o s : la i mpl ement aci n de un a GCS ef i caz r equi er e que el
equi po de s of t war e utilice un conj unt o de he r r a mi e nt a s y car act er s t i cas de
pr oce s os (que a ba r c a n ot r os e l e me nt os de GC).
Est os e l e me nt os (que s e es t udi ar n con m s det al l e en s ecci ones veni der as) no s or
mu t u a me n t e excl uyent es. Por ej empl o, l os e l e me nt os de c o mp o n e n t e s t r abaj an en
conj unt o con l os de cons t r ucci n c onf or me a va nz a el pr oces o de s of t war e. Los el e-
me n t o s de pr oce s o gu an muc ha s act i vi dades h u ma n a s que s e r el aci onan con GCS
y, por t ant o, t ambi n pue de n cons i der ar s e e l e me nt os h uma n o s .
27.1.3 Lneas base
El c a mbi o e s un he c ho de vida en el des ar r ol l o del s of t war e. Los cl i ent es qui er en
modi f i car l os requi si t os. Los des ar r ol l ador es qui er en modi f i car el e nf oque t cni co.
Los ge s t or e s qui er en modi f i car la est r at egi a del pr oyect o. Por qu t oda s e s t a s modi -
ficaciones? La r es pues t a, en r eal i dad, e s ba s t a nt e si mpl e. Conf or me pas a el t i empo,
t odos l os par t i ci pant es s a be n m s (acerca de lo que neces i t an, qu e nf oque ser a el
mej or , c mo hacer l o y a un as obt e ne r di nero). Est e conoci mi e nt o adi ci onal e s la
f uer za i mpul s or a det r s de la mayor a de l os c a mbi os y c onduc e a un a expr es i n dif-
cil de ace pt ar par a mu c h o s pr of es i onal es de la i ngeni er a del s of t war e: l a m a y o r a
d e l o s c a m b io s e s t n j u s t ific a d o s !
Una l n e a b a s e e s un conce pt o de gest i n de la conf i gur aci n del s of t wa r e que
ayuda a cont r ol ar el c a mbi o sin i mpedi r s e r i a me nt e el cambi o j ust i fi cabl e. El IEEE
(IEEE Std. No. 610. 12-1990) def i ne un a l nea ba s e como:
Una especificacin o producto que se ha revisado formalmente y se est de acuerdo con
los resultados, y que a partir de ah sirve como la base para el desarrollo ulterior y que
puede cambiarse slo por medio de procedimientos formales de control del cambio.
Ant es de que un e l e me nt o de conf i gur aci n del s of t wa r e s e convi er t a en l nea
base, e s posi bl e r eal i zar el cambi o r pi da e i nf or mal ment e. Si n e mbar go, una vez
es t abl eci da un a l nea bas e, me t af r i came nt e s e pa s a a t r avs de u n a puer t a gi r at o-
ria de una sol a di recci n. Los c a mbi os s e pue de n r eal i zar , pe r o se de be apl i car un
pr ocedi mi ent o espec f i co f or mal par a eval uar y veri fi car cada uno.
En el cont ext o de la i ngeni er a del s of t war e, u n a l nea ba s e e s un hi t o en el de s a -
rrol l o del s of t war e. Se mar ca un a l nea ba s e par a la ent r ega de uno o m s e l e me n-
t os de conf i gur aci n del s of t wa r e (ECS) que s e h a n a pr oba do c o mo cons e cue nci a de
un a revi si n t cni ca f or mal (cap t ul o 26). Por ej empl o, l os e l e me nt os de un mode l o
de di s eo s e han do c ume n t a do y r evi sado. Se han e nc ont r a do er r or es y s e han cor r e-
gi do. Una vez que t odas l as par t es del mode l o s e h a n r evi sado, cor r egi do y l uego
apr obado, el mode l o de di s eo s e convi er t e en l nea bas e. Los cambi os pos t er i or es
a la ar qui t ect ur a del pr ogr a ma ( doc ume nt a dos en el mode l o de di seo) s l o s e pue-
TM
PDF Editor
CAP TULO 2 7 GESTIN DEL CAMBIO 801
^ O W S i i O ^
> s pr e c is o a s e g u r a r s e
Je q u e l a b a s e d e
:j os d e l pr o y e c t o s e
- r n t ie n e e n u n o
Mo c i n c e n t r a l
y it r o l a d o .
den e f e c t ua r d e s p u s de q u e c a da u n o s e h a e va l ua do y a pr oba do. Aunque l as l-
n e a s ba s e s e pue de n defi ni r e n cual qui er gr ado de det al l e, e n la figura 27. 1 s e mue s -
t r an l as l neas ba s e de s of t wa r e m s c omune s .
En la figura 27. 1 t ambi n s e mues t r a la pr ogr es i n de e ve nt os que c onduc e n a
un a l nea bas e. Las t a r e a s de i ngeni er a del s of t war e pr oducen u n o o m s ECS.
Des pus de q u e s t os s e revi san y a pr ue ba n se col ocan en una b a s e d e d a t o s d e l pr o -
y e c t o ( t ambi n l l amada l ib r e r a d e l pr o y e c t o o d e p s it o d e s o ft wa r e , que s e e xa mi n a n
e n la secci n 27. 2). Cuando un mi e mbr o de un equi po de s of t wa r e qui er e modi f i car
un ECS q u e s e ha conver t i do en l nea bas e, s e copi a de la ba s e de da t os del pr oyec-
t o en el e s paci o de t r abaj o pr i vado del i ngeni er o. Sin e mbar go, es t e ECS ext r a do
s l o s e pue de modi f i car si s e s i guen l os cont r ol es de la GCS ( t r at ados m s ade l ant e
en e s t e cap t ul o). Las flechas en la figura 27. 1 i l ust ran la t r ayect or i a de modi f i caci n
par a un ECS conver t i do en l nea bas e.
27.1.4 Elementos de configuracin del software
Un e l e me n t o de conf i gur aci n del s of t wa r e (ECS) e s i nf or maci n que se cr ea c o mo
par t e del pr oce s o de i ngeni er a del s of t war e. En el ext r emo, s e pue de cons i der ar que
un ECS e s un a sol a s ecci n de una gr an especi f i caci n o un c a s o de pr ueba de un
gr an c onj unt o de pr uebas . De ma n e r a m s real i st a, un ECS e s un doc ume nt o, un
conj unt o c ompl e t o de c a s o s de pr ueba o un c o mp o n e n t e de un pr ogr a ma d a d o (por
ej empl o, una f unci n C++ o un a ppl e t de Java).
Ade m s de l os ECS pr ove ni e nt e s de l os pr oduct os de t r abaj o de s of t war e, mu c h a s
or gani zaci one s de i ngeni er a del s of t war e t ambi n col ocan l as he r r a mi e nt a s r es pec-
t i vas ba j o cont r ol de conf i gur aci n. Est o es: ver s i ones es pec f i cas de edi t or es, c o m-
ECS convert i dos
en l nea ba s e y
base de dat os del
proyecto.
Modi f i cado
LINEAS BASE:
Especificacin del sistemo
Requisitos d e soft ware
Especificacin del di seo
Cdi go fuente
Pl anes/ pr ocedi mi ent os/
dat os de pr ueba
Sistema oper at i vo
TM
PDF Editor
piladores, navegador es y ot ras her r ami ent as aut omat i zadas se "congelan" cc
part e de la confi guraci n del soft ware. Puest o que di chas her r ami ent as se utili2
para producir document aci n, cdi go f uent e y dat os, deben est ar disponibl es al :
lizar cambi os en la confi guraci n del soft ware. Aunque los probl emas son raros, i
posible que una nueva versin de una herrami ent a (por ejempl o, un compila
produzca resul t ados di ferent es a los de la versin original. Por est a razn, las her
mi ent as, al igual que el sof t war e que ayudan a producir, pueden convertirse en lii
base como parte de un proceso global de gestin de configuracin.
En realidad, los ECS est n or gani zados para formar obj et os de confi guraci n
ceptibles de cat al ogar en la base de dat os del proyect o con un solo nombre. Un i
to d e c o n fig u r a c i n tiene un nombre, at ri but os y est "conect ado" con otros obje
por medi o de rel aciones. Si se observa la figura 27.2, los obj et os de configurac
Es pe c i f i c ac i onDi s e o, Mode l oDat os , Compone nt e N, Codi goFuent e
Especi f i caci onPrueba est n definidos por separ ado. Sin embargo, cada uno de 1
obj et os se rel aci ona con los otros como lo muest r an las flechas. Una flecha
indica una relacin de composi ci n. Esto es: Mode l oDat os y Component eN
parte del obj et o Es peci f i caci onDi s eo. Una flecha recta con doble punt a ind
una interrelacin. Si se real izase un cambi o al obj et o Codi goFuent e, las inter
ci ones permiten que un ingeniero de sof t war e det ermi ne qu ot ros obj et os (y EC5j]
pueden afect arse. 2
Objetos de
configuracin.
Estas relaciones se definen dentro de la base de datos. La estructura de la base de datos (almacr.
se estudia con mayor detalle en la seccin 27.2.
TM
PDF Editor
CAP TULO 2 7 GESTIN DEL CAMBIO
803
2 7 . 2 E L DE P S I T O DE E C S
En l os pr i me r os d as de la i ngeni er a del s of t wa r e l os e l e me nt os de conf i gur aci n s e
c ons e r va ba n c o mo do c ume n t o s de papel (o t ar j et as per f or adas! ) , que s e col ocaban
en car t apaci os o car pe t as de ani l l os y s e a l ma c e na ba n en ar chi ver os met l i cos. Est e
e nf oque er a pr obl emt i co por mu c h a s r azones : 1) con f r ecuenci a er a difcil e nc on-
t r ar un e l e me nt o de conf i gur aci n c ua n do s e le neces i t aba; 2) us ua l me nt e er a un
r et o de t e r mi nar cul e l e me nt o hab a si do cambi ado, c u n d o y por qui n; 3) la c ons -
t rucci n de un a n ue va ver si n de un pr ogr a ma exi st ent e c ons um a mu c h o t i e mpo y
er a procl i ve al error; 4) la descr i pci n de r el aci ones det al l adas o compl e j as ent r e el e-
me nt os de conf i gur aci n er a vi r t ual ment e i mposi bl e.
En la act ual i dad, l os ECS se cons er van en una ba s e de dat os o deps i t o del pr o-
yect o. El di cci onari o Webst er def i ne la pal abr a d e p s it o c o mo "cual qui er cos a o per s o-
n a que s e cons i der a c o mo cent r o de acumul aci n o al macenami ent o". En l os inicios
de la i ngeni er a del s of t war e, el deps i t o de he c ho er a una per s ona: el pr ogr amador ,
qui en t en a que r ecor dar la ubi caci n de t oda la i nf or maci n r el evant e par a un pr o-
yect o de s of t war e; a de m s , t eni a q u e r ecuper ar la i nf or maci n q u e nunc a s e hab a
r es pal dado por escr i t o y r econst r ui r la i nf or maci n per di da. Tr i st ement e, e mpl e a r a
un a pe r s ona c o mo "cent r o de acumul aci n y a l ma c e na mi e nt o" ( aunque concue r de
con la def i ni ci n del di cci onari o) no f unci ona muy bi en. Hoy el deps i t o e s un a
"cosa": una ba s e de da t os que act a c o mo el cent r o t a nt o de la acumul aci n c o mo
del a l ma c e n a mi e n t o de la i nf or maci n de i ngeni er a del s of t war e. El papel de la per -
s ona (el i ngeni er o de s of t war e) e s i nt er act uar con el deps i t o me di a nt e l as her r a-
mi e nt a s que t i ene i nt egr adas .
27.2.1 El papel del depsito
El deps i t o de ECS e s el conj unt o de me c a n i s mo s y es t r uct ur as de da t os que per mi -
t e que un e qui po d e s of t wa r e ma n e j e el c a mbi o en un a f or ma ef i caz. El deps i t o pr o-
por ci ona l as f unci ones obvi as de un s i s t ema d e gest i n de ba s e de da t os per o, ade-
ms , el deps i t o r eal i za o i mpul sa l as s i gui ent es f unci one s [FOR89]:
I Qu La in t e g r id a d d e l o s d a t o s i ncl uye f unci ones par a val i dar l as e n t r a da s al
deps i t o, gar ant i zar la cons i s t enci a ent r e obj et os r el aci onados y aut omt i ca-
me nt e r eal i zar modi f i caci ones "en cas cada" c ua n do un cambi o e n un obj et o
d e ma n d a al gn c a mbi o a l os obj et os r el aci onados con l.
El c o m pa r t ir in fo r m a c i n of r ece un me c a n i s mo par a di st ri bui r la i nf or maci n
ent r e ml t i pl es des ar r ol l ador es y her r ami ent as , ma ne j a r y cont r ol ar l os
a c c e s os a l os da t os por par t e de ml t i pl es us uar i os y cer r ar y abr i r l os obj et os
de mo d o que l os cambi os n o s e a n t r as l adados i nadve r t i dame nt e haci a ot r os .
La in t e g r a c i n d e h e r r a m ie n t a s est abl ece un model o de dat os al que se puede t ener
acces o medi ant e muchas her r ami ent as de ingenier a del soft ware, cont rol ar el
acce s o a l os dat os y real i zar f u n d o n e s ade cuadas de gest i n de la confi guraci n.
W funciones
npl ement o un
psi t o de ECS?
TM
PDF Editor
La in t e g r a c i n d e l o s d a t o s br i nda f unci one s de ba s e de da t os que per mi t en
que var i as t ar eas de GCS s e r eal i cen en uno o m s ECS.
El fo r t a l e c im ie n t o d e l a m e t o d o l o g a def i ne un mode l o de ent i dad- r el aci n
gua r da do e n el deps i t o que i mpl i ca un mode l o de pr oc e s o espec f i co par a la
i ngeni er a del s of t war e; c o mo m ni mo, l as r el aci ones y obj et os def i nen un
conj unt o de pa s os que s e de be n l l evar a c a bo par a cons t r ui r l os cont eni dos
del depsi t o.
E s t a n d a r iza c i n d e l o s d o c u m e n t o s e s la def i ni ci n de l os obj et os e n la ba s e de
da t os que c onduc e di r ect ament e a un e nf oque e s t ndar par a la cr eaci n de
do c ume n t o s de i ngeni er a del s of t war e.
El deps i t o s e def i ne en f unci n de un me t amode l o. Par a l ograr es t as f unci ones d
m e t a m o d e l o de t e r mi na c mo s e guar da la i nf or maci n en el depsi t o, c mo se t i ene
acce s o a l os da t os medi ant e l as he r r ami e nt as y c mo l os vi sual i zan l os i ngeni er os c t
s of t war e, cun bien s e pue de ma n t e n e r la s egur i dad e i nt egri dad de l os dat os , y cuan
f ci l ment e se pue de ampl i ar el mode l o exi st ent e par a ade cuar l as nue va s necesi da
des. Para mayor i nf or maci n, el l ect or i nt er es ado de be cons ul t ar [SHA95] y [GR195;
27.2.2 Caractersticas y contenido generales
Las car act er s t i cas y el cont eni do del deps i t o s e c ompr e nde n me j or si s e l es obs e-
va des de dos per spect i vas: qu se guar dar e n el deps i t o y qu ser vi ci os especfi-
cos of r e ce st e. En la figura 27. 3 s e pr es ent a un anl i si s det al l ado de l os t i pos ce
r epr es ent aci ones , doc ume nt os y pr oduct os de t r abaj o que se guar dan en el deposi t e
Cont eni do
del depsito.
Casos de uso
Modelo de anlisis
Diagramas basados en escenario
Diagramas orientados a flujo
Diagramas basados en clase ^ - v (
Diagramas comportamentales / V
Model o de diseo / Co r r i d o de>
Diagramas arqu, e nanc as ^ c o m l r u c c 6
Diagramas de intertaz \ A
Diagramas al nivel de component es V- ;& J
Mtricas tcnicas / N
Reglas del negoci o
Funciones del negoci o
Eslrucrura de la or aamzaci n
Arquitectura deintormocin
Cdi go fuente
Cdi go de objeto
Instrucciones de construccin del sistema
Cont eni do
de negoci o
Cont eni do
de model o
Cont eni do
VyV
Cont eni do
d e gestin
del proyecto
Plan del proyecto
Plan GCS/ SQA
Especificaciones del sistema
Especificaciones de requisitos
Documento de diseo
Plon y procedimiento de prueba
Documentos de soporte
Manual del usuario
Estimaciones del proyecto
Calendarizacin del proyecto
Requisitos de GCS
Solicitudes de cambio
Informes de combios
Requisitos de SQA
Informes de proyecto/informes de auditora
Mtricas del proyecto
Documentos
Casos de prueba
Guiones de prueba
Resultados de prueba
Mtricas de calidod
TM
PDF Editor
805
R f c r e n c i a We b
e s e
i obtener en
vww. s of t wor e .
bp. c o m/ pr o dl Kt s /
SCMGR o en ot n.
/
rtpotttoryJitml.
\
CLAVE
El depsito debe ser
copaz de montener los
ES relacionados con
cuchos versiones
iferentes del
software. Ms
mportonte, debe
ofrecer los mecanismos
poro ensamblar dichos
ECS en una
configuracin
especifica de versin.
Un depsi t o robust o proporci ona dos cl ases di ferent es de servicios: 1) los mi smos
tipos de servicios que se pueden esperar de cual quier si st ema sofisticado de gestin
de bas e de dat os, y 2) servicios especficos del ent or no de la ingeniera del soft ware.
Un depsi t o que at i enda a un equi po de ingeniera de soft ware debe 1) integrar-
se con o di rect ament e apoyar l as funci ones de gestin de proceso; 2) apoyar reglas
espec ficas que rigen la funcin de GCS y los dat os conser vados dent r o del depsito;
3) ofrecer una interfaz a ot ras her r ami ent as de ingeniera del soft ware; y 4) acomo-
dar el al macenami ent o de dat os sofisticados (por ejempl o, texto, grficos, video,
audio).
27.2.3 Caractersticas de la GCS
El apoyo a la GCS requi ere que el al macn o depsi t o t enga un conj unt o de herra-
mi ent as que ofrezca soport e para las si gui ent es caractersticas:
Versi ones. Conforme un proyect o progrese se crearn muchas versi ones (seccin
27.3.2) de product os de t rabaj o individuales. El depsi t o debe ser capaz de guardar
t odas est as versi ones para permitir la gestin eficaz de las liberaciones de product o
y permitir que los desarrol l adores regresen a versi ones ant eri ores durant e las prue-
bas y la depuraci n.
El depsi t o debe ser capaz de control ar una ampl ia variedad de tipos de objetos,
incluso texto, grficos, mapas de bits, document os compl ej os y obj et o ni cos como
defi ni ci ones de pant al l as e informes, archi vos de objeto, dat os de prueba y resul t a-
dos. Un depsi t o madur o sigue las versi ones de los obj et os con grados arbitrarios de
granul aridad; por ejemplo, se puede seguir una sol a definicin de dat os o un con-
j unt o de mdul os.
Ges t i n del s e gui mi e nt o de l a de pe nde nc i a y del cambi o. El depsi t o gestio-
na una ampl ia variedad de rel aci ones ent re los obj et os de confi guraci n que guarda.
Se incluyen rel aci ones ent re ent i dades y procesos empresari al es, ent re las part es de
un di seo de aplicacin, ent re component es de di seo y la arquitectura de i nforma-
cin del proyecto, ent re el ement os de di seo y otros product os de t rabaj o, etctera.
Al gunas de est as rel aci ones son mer ament e asoci aci ones, y al gunas son dependen-
ci as o rel aci ones obligatorias.
La habilidad con que se da segui mi ent o a t odas est as rel aci ones es crucial para la
integridad de la i nformaci n guardada en el depsi t o y la generaci n de product os de
t rabaj o bas ados en ella, y es una de las aport aci ones m s i mport ant es del concept o
de depsi t o a la mej ora del proceso de desarrollo de soft ware. Por ejempl o, si se
modifica un di agrama de clase UML, el depsi t o puede det ect ar si l as cl ases relacio-
nadas, las definiciones de interfaz y los component es de cdigo t ambi n requieren
modificacin y pueden colocar en la at enci n del desarrol l ador los ECS afect ados.
Segui mi ent o de requi si t os. Esta funcin especial ofrece la habilidad de seguir
t odos los component es y ent regabl es de di seo y const rucci n que resul ten de una
det ermi naci n especfica de requisitos (seguimiento haci a adel ant e o segui mi ent o
TM
PDF Editor
pr opi ament e dicho). Adems, proporci ona la habilidad de identificar qu requisitos
generaron algn product o de t rabaj o dado (seguimiento hacia at r s o rastreo).
Ges t i n de l a conf i guraci n. Una gestin de la confi guraci n facilita la conser-
vacin del rast ro de una serie de confi guraci ones que represent an hitos especficos
del proyect o o l iberaciones de producci n.
Rutas de audi tor a. Una ruta de auditora est abl ece i nformaci n adicional acerca
de cundo, por qu y por quin se hicieron los cambi os. La i nformaci n acerca de la
fuent e de l os cambi os se puede i ngresar como atributos de obj et os espec ficos en el
depsito.
qu preguntas se
debe disear un
p r o c e s o d e GCS?
El proceso de gestin de la configuracin del sof t war e defi ne una serie de t ar eas que
tienen cuat ro objetivos principales: 1) identificar t odos los el ement os que colectiva-
ment e defi nen la confi guraci n del soft ware; 2) gest i onar los cambi os a uno o ms
de di chos el ement os; 3) facilitar la const rucci n de di ferent es versi ones de una apli-
cacin; y 4) garant i zar que la calidad del sof t war e se conserva conf or me la configu-
racin evol uciona a lo l argo del tiempo.
Un proceso que logra est os objetivos no necesi t a ser burocrtico y mol esto, pero
s debe caract eri zarse en una forma que permi t a que un equi po de sof t war e desa-
rrolle respuest as a un conj unt o de pregunt as compl ejas:
Cmo identifica un equi po de sof t war e los el ement os di scret os de una confi-
guraci n de soft ware?
Cmo gest i ona una organi zaci n las numer osas versi ones exi st ent es de un
pr ogr ama (y su document aci n) en una forma que permi t a que el cambi o se
acomode efi ci ent ement e?
Cmo control a una organi zaci n los cambi os ant es y despus de que el
sof t war e se libere al cliente?
Quin tiene la responsabilidad de aprobar y clasificar los cambi os?
Cmo se garant i za que l os cambi os se hayan real i zado adecuadament e?
Con qu mecani smo se val oran otros cambi os que se real izan?
Estas pregunt as conducen a la definicin de las cinco t ar eas de la GCS i l ust radas en
la figura 27.4: identificacin, control de la versin, control del cambio, auditora de la
configuracin e informe.
En la mi sma figura las t areas de la GCS se apreci an como capas concnt ri cas. Los
ECS fluyen haci a af uer a a t ravs de di chas capas a lo largo de su vida til, y a final
de cuent as se convierten en part e de la configuracin del sof t war e de una o m s ver-
si ones de una aplicacin o si st ema. Conforme un ECS se mueve a t ravs de una
capa, l as acci ones que implica cada capa de pr oceso de la GCS pueden o no aplicar-
se. Por ejempl o, cuando se crea un nuevo ECS debe ser identificado. Sin embargo, si
TM
PDF Editor
CAP TULO 27 GESTIN DEL CAMBIO 8 0 7
Capas del
proceso de
SCS.
n o se sol i ci t an cambi os par a el ECS, la capa de cont rol de cambi o n o s e apl i ca. El
ECS s e as i gna a un a ver si n espec f i ca del s of t wa r e (ent ran en j uego me c a n i s mo s de
cont r ol de la versi n). Se cons er va un r egi st r o del ECS (su nombr e , f echa de cr ea-
ci n, des i gnaci n de ver si n, etc.) par a pr ops i t os de audi t or a de la conf i gur aci n e
i nf or mes a qui e ne s neces i t en saber l o. En l as s ecci ones s i gui ent es s e e xa mi na n con
m s det al l e c a da un a d e e s t a s c a pa s del pr oce s o de GCS.
27.3.1 Identificacin de objetos en la configuracin del software
El cont r ol y la gest i n de e l e me nt os de conf i gur aci n del s of t wa r e r equi er e nombr a r
cada u n o por s e pa r a do y l uego o r ga n i z a do me di a nt e un e nf oque or i e nt ado a obj e-
t os. Es posi bl e i dent i fi car d o s t i pos de obj et os [CH089]: bs i cos y agr egados . 3 Un
o b j e t o b s ic o e s un a uni dad de i nf or maci n cr e ada por un i ngeni er o de s of t wa r e
dur a nt e el anl i si s, el di seo, el cdi go o l as pr uebas . Por ej empl o, un obj et o bs i co
pue de ser una secci n de un a especi fi caci n de requi si t os, par t e de un model o de di se-
o, cdi go f uent e par a un compone nt e , o un conj unt o de cas os de pr ueba que se uti-
l izan par a ej erci t ar el cdi go. Un o b j e t o a g r e g a d o e s una col ecci n de obj et os bsi cos
y ot r os obj et os agr egados . En la figura 27. 2 Es pe c i f i c ac i onDi s e o e s un obj et o agr e-
gado. Concept ual ment e, e s posi bl e verl o c o mo un a lista nombr ada (identificada) de
punt er os que especi fi can obj et os bsi cos c o mo son Mo de l o Da t o s y Compone nt e N.
Versin
software
torio d e conf i gur ad
Control d e la versin
Control d e j c a mb i
Identificacin /
3 El concepto de objeto agregado [GUS89] se ha propuesto como un mecanismo para representar una
versin completa de una configuracin de software
TM
PDF Editor
%
CLAVE
Los interrelociones
establecidos para los
objetos de
configuracin permiten
que un ingeniero de
software evale el
impacto del cambio.
( CONSEJ O^
In c l u s o s i l o t o s e d e
d o l o s d e l pr o y e c t o
o fr e c e l a h a b il id a d
po r a e s t a b l e c e r d ic h a s
ie l a c io n e s , s t o s
c o n s u m e n t ie m po e n
s u e s t a b l e c im ie n t o y
d ific u l t a n m a n t e n e r l o
o c t u o l izo n . Au n q u e
s o n m u y t il e s pa t a e l
a n l is is d e im pa c t o ,
n o s o n e s e n c ia l e s
po r a l a g e s t i n g l o b a l
d e l c a m b io .
\
CLAVE
Uno facilidad "de
hechura" permite a un
ingeniero de software
obtener todos los
objetos de
configuracin
relevantes y construir
v a versin especfica
l software.
Cada obj et o tiene un conj unt o de caract er st i cas distintivas que lo identifican
maner a exclusiva: un nombre, una descripcin, una lista de recursos, y una "ir
zacin". El nombr e del obj et o es una cadena de caract eres que identifican al
sin ambi gedades. La descripcin del obj et o es una lista de el ement os de dat os
identifican el tipo de ECS (por ejempl o, el ement o model o, programa, datos)
represent a el objeto, un identificador de proyect o e i nformaci n de cambi o y/ o
sin.
La identificacin del obj et o de configuracin t ambi n puede considerar las re:
nes entre los obj et os nombrados. Por ejemplo, con la utilizacin de notacin simpl
Di agramadeCl ase <p a r t e d e > ModeloAnalisis;
ModeloAnalisis <pa r l e d e > Especi fi caci onRequi si t os;
se crea una jerarqua de ECS.
En muchos casos, los obj et os est n i nt errel aci onados a t ravs de r amas de jerar-
qua de obj et os. Dichas rel aci ones est ruct ural es cr uzadas se represent an en la forma
siguiente:
Model oDat os <i nt er t el aci onado> Model oFl uj oDat os
Model oDat os < nt er r el aci onado> CasoPruebaCl aseM
En el primer caso la interrelacin es ent re un obj et o compuest o, mi ent ras que la
segunda relacin es ent re un obj et o agregado ( Model oDat os) y un obj et o bsicc
(CasoPruebaCl aseM).
El esquema de identificacin para los obj et os de confi guraci n debe reconoce:
que los obj et os evol uci onan a lo largo del proceso de soft ware. Antes de que ur
obj et o se convierta en lnea bas e puede cambi ar muchas veces, e incluso despus de
establ ecida una lnea base los cambi os qui z sean muy frecuent es.
27.3.2 Control de la versin
El control de la versin combi na procedi mi ent os y her r ami ent as para gest i onar dife-
rent es versi ones de obj et os de configuracin que se crean dur ant e el proceso del
soft ware. Un si st ema de control de la versin i mpl ement a o est di rect ament e inte-
grado con cuat ro gr andes capaci dades: 1) una bas e de dat os del proyect o (depsito)
que guarda t odos los obj et os de confi guraci n relevantes; 2) una capacidad de g e s
t i n d e l a v e r s i n que al macena t odas las versi ones de un obj et o de confi guraci n (o
permi t e que se const ruya cualquier versin empl eando diferencias de versi ones
anteriores); 3) una fa c il id a d d e h e c h u r a que permi t a al ingeniero de sof t war e recopi-
lar t odos los obj et os de configuracin rel evant es y construir una versin especfica
del soft ware. Adems, l os si st emas de control de la versin y de control del cambi o
con frecuenci a i mpl ement an una capaci dad de s e g u im ie n t o d e c o n fl ic t o s (tambin lla-
mada s e g u im ie n t o d e b u g s ) que permi t en al equi po registrar y hacer el segui mi ent o
del est ado de t odos los conflictos dest acados que se asoci an con cada obj et o de con-
figuracin.
TM
PDF Editor
809
"Cual qui er cambi o, incluso u n o por a mej or ar , est a c o mpa a do con i nconveni ent es e i ncomodi dades . "
Amo l d Be n n e t
Vari os s i s t e mas de cont r ol de la ver si n es t abl ecen un c o n j u n t o d e c a m b io una
col ecci n de t odos l os cambi os (con ci ert a conf i gur aci n de l nea base) que
r equi er e la cr eaci n de un a versi n espec f i ca del s of t war e. Dart [DAR91] advi er t e
que un c onj unt o de c a mbi os "capt ur a t odos l os cambi os de t odos l os ar chi vos en la
conf i gur aci n j unt o con la r azn par a l os c a mbi os y det al l es de qui n l os hi zo y
cundo".
Es posi bl e i dent i fi car var i os c onj unt os de cambi o n o mbr a do s par a un a apl i caci n
o s i s t ema. Est o per mi t e que un i ngeni er o de s of t wa r e cons t r uya un a ver si n del sof t -
wa r e al especi f i car l os c onj unt os de c a mbi o (por nombr e) que s e de be n apl i car a la
conf i gur aci n de l nea bas e. Est o s e l ogra apl i cando un e nf oque de m o d e l a d o d e s is -
t e m a . El mode l o de s i s t ema cont i ene 1) un a pl a n t il l a que i ncl uye un a j er ar qu a de
c o mpo n e n t e s y un "or den de cons t r ucci n" par a l os c o mp o n e n t e s que des cr i be
c mo se de be const r ui r el s i s t ema, 2) r egl as de cons t r ucci n y 3) r egl as de veri fi ca-
ci n. 4
Dur ant e l as pa s a da s dos d c a da s s e h a n pr opue s t o var i os e nf oque s aut omat i za-
d o s pa r a el cont rol de la ver si n. La pri nci pal di f er enci a e n l os e nf oque s e s la sof i s-
t i caci n de l os at r i but os q u e s e ut i l i zan en la cons t r ucci n de ver s i ones espec f i cas
y var i ant es de un s i s t ema y l os me c a ni s mos del pr oce s o de cons t r ucci n.
E l S is t e m a de Ve r s io n e s Co n c u r r e n t e s ( S VC)
El empl eo d e herrami ent as con que l ograr el
control de la versin es esencial par a una
gestin del cambi o efi caz. El s is t e m a d e v e r s io n e s
c o n c u r r e n t e s (SVC; CVS, Concurrent Versions System) es
una herrami ent a ampl i ament e empl eada en el control de
versiones. Ori gi nal ment e di seada par a cdi go fuente,
pero til par a cual quier archivo ba s a do en texto, el
sistema SVC 1) est abl ece un depsi t o simple, 2) conserva
t odas las versiones d e un archivo en un archi vo con un
solo nombr e al al macenar slo las di ferenci as entre
versiones progresivas del archi vo original, y 3) prot ege un
archivo contra cambi os simultneos al establ ecer diferentes
directorios par a cada desarrol l ador, con lo que se aisl an
uno de otro. El SVC mezcla los cambi os cuando cada
desarrol l ador completa su t r abaj o.
Es importante notar que el SVC no es un sistema "de
construccin"; est o es, no construye una versin especfica
del software. Esto se l ogra i nt egrando al SVC ot ras
herrami ent as (por ej empl o, Ma ke fil e ). El SVC no
implemento un proceso d e control d e cambi o (por ej empl o,
solicitudes d e cambi o, informes de cambi o, seguimiento d e
bugs).
Pese a sus limitaciones, el SVC "es un sistema
domi nant e en el control d e versiones, t ransparent e respecto
a la red y de fuent e abi er t a [que] es til pa r a todos, desde
desarrol l adores individuales hasta gr andes equi pos
segment ados" [CVS02], Su arquitectura cl iente/servidor
permite que los usuarios accedan a los archivos medi ant e
conexi ones de Internet y su filosofa de fuente abi er t a
facilita su disponibilidad en la mayor a de las pl at aformas
popul ares.
El SVC est di sponi bl e sin costo pa r a entornos
Wi ndows, Macintosh y Unix. Vistese www. cvshome. org
por a mayores detalles.
4 Tambin es posible consultar el modelo de sistema para valorar cmo un cambio en un componente
impactar a otros componentes.
TM
PDF Editor
810 PASTE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
27.3.3 Control del cambio
La real i dad del cont rol del cambi o e n un cont e xt o mo de r n o de i ngeni er a del soft-
wa r e la r e s umi bel l ament e J ames Bach [BAC98]:
El control del cambio es vital. Pero las fuerzas que lo hacen necesario tambin lo tornan
irritante. Nos preocupamos por los cambios porque una pequea perturbacin en el c-
digo puede crear una gran falla en el producto. Pero tambin puede resolver una gran fa-
lla o permitir maravillosas nuevas capacidades. Nos preocupamos por los cambios porque
un solo desarrollador solitario podra hundir el proyecto; aunque en las mentes de dichos
solitarios se originan ideas brillantes, y un proceso de control del cambio gravoso podra
desalentarlos efectivamente de realizar trabajo creativo.
Bach r e conoce que s e e nf r e nt a un a c t o de equi l i bri o. De ma s i a do cont rol del cambi o,
y s e cr e an pr obl emas ; poco, y se cr e an ot r os pr obl e mas .
"0 orte del progreso es presevor el or den ent r e el cambi o, y pr e s e r var el cambi o ent r e el orden,"
AHred North Whi t eheod
CLAVE
Se debe destocor que
arias sofci l udes de
c a mbo pueden
combi nar pora
resultar en uno soto
0(1 y que te 0(1
ifl uol menl e resulten en
cambios o mltiples
configuracin.
^ CONS E J O^
Lo c o n fu s i n c o n d u c e
o e m e s , o l g u n o s d e
e l l o s b o s t o n t e s e r io s .
B c o n t r o l d e l o c c e s o y
d e l o s in a o n izo c i n
n t o n c o n fu s i n ,
[ m fl ie n s e fe r r o -
Bitas d e c o n t r o l d e
kn K in y d e l
En un gr an pr oyect o de i ngeni er a de s of t wa r e el c a mbi o i ncont r ol ado conduce
r pi dame nt e al caos . Res pect o a t al es pr oyect os el cont rol del c a mbi o c ombi na pr o-
ce di mi e nt os h u ma n o s y he r r a mi e nt a s aut omat i zadas . En la figura 27. 5 s e ilustra
e s que m t i c a me nt e el pr oce s o de cont r ol del cambi o. Se emi t e un a s o l ic it u d d e c a m -
b io y s e est i ma par a eval uar l os mr i t os t cni cos, l os pot enci al es ef ect os col at er al es,
el i mpact o gl obal sobr e ot r os obj et os de conf i gur aci n y f unci one s del s i s t ema, y el
COStO pr oyect ado del cambi o. Los r es ul t ados de la eval uaci n s e pr e s e nt a n c o mo un
in fo r m e d e c a m b io , que l o utiliza un a a u t o r id a d d e l c o n t r o l d e l c a m b io (ACC): un a per -
s ona o gr upo que t o ma n la deci si n final acer ca del e s t a do y la pri ori dad del c a m-
bio. Se gener a una o r d e n d e c a m b io e n l a in g e n ie r a (OCI) par a cada cambi o apr obado.
La OCI des cr i be el c a mbi o que s e de be real i zar, l as r est r i cci ones i nsosl ayabl es y l os
cri t eri os de revi si n y audi t or a.
El obj et o que se cambi ar s e col oca e n un di r ect or i o que cont r ol e excl us i vamen-
t e el i ngeni er o de s of t wa r e que r eal i za el cambi o. Un s i s t ema de cont rol de la ver -
si n (vase el r ecuadr o acer ca de SVC) act ual i za el ar chi vo original una vez r eal i zado
el cambi o. Co mo al t er nat i va, el obj et o que s e cambi ar puede "salir" de la ba s e de
da t os del pr oyect o (depsi t o), r eal i zar el cambi o y apl i car l as act i vi dades apr opi adas
de SQA. Luego el obj et o "ent r a" a la ba s e de dat os y s e apl i can me c a n i s mo s a de -
c ua do s de cont r ol de ver si n (secci n 27. 3. 2) par a cr ear la si gui ent e ver si n del s of t -
war e.
Est os me c a n i s mo s de cont r ol de la ver si n, i nt egr ados en el pr oc e s o de cont r ol
de cambi os , i mpl e me nt an d o s i mpor t ant e s e l e me n t o s de gest i n del cambi o: cont r ol
del a c c e s o y de la si ncr oni zaci n. El c o n t r o l d e l a c c e s o ri ge qu i ngeni er os de s of t -
wa r e e s t n aut or i zados par a i ngr esar y modi f i car un obj et o de conf i gur aci n part i -
cul ar. El c o n t r o l d e l a s in c r o n iza c i n ayuda a gar ant i zar que l os cambi os par al el os,
e f e ct uados por dos pe r s ona s di f er ent es, n o s e s obr es cr i ben u n o s obr e otro[HAR89].
TM
PDF Editor
CAP TULO 2 7 GESTIN DEL CAMBIO
811
Al gunos l ect or es qui z comi e nce n a s ent i r s e i nc modos con el gr ado de bur o-
cr aci a que i mpl i ca la descr i pci n del pr oce s o de cont r ol del cambi o mos t r a da en la
figura 27. 5. Est e s ent i mi ent o e s c omn. Si n l as s al vaguar das a de c ua da s el cont r ol
del cambi o pue de r et r as ar el pr ogr e s o y cr ear bur ocr aci a y papel eo i nnecesar i os. La
mayor a de l os des ar r ol l ador es de s of t war e con me c a n i s mo s d e cont rol del cambi o
( de s af or t unadame nt e mu c h o s n o l os t i enen) ha cr e ado var i as c a pa s de cont rol par a
ayudar s e a evi t ar l os pr obl e ma s me nc i ona dos aqu .
Ant es de que un ECS se convi er t a e n l nea ba s e sl o s e neces i t a apl i car c o n t r o l d e
c a m b io in fo r m a l . El des ar r ol l ador del obj et o de conf i gur aci n (ECS) e n cues t i n t i ene
3 proceso de
control del
cambio.
Se r e c onoc e la ne c e s i da d del c a mb i o
I
Solicitud de c a mbi o por por t e del usuar i o
I
Eval uaci n del des ar r ol l ador
i
Se g e n e r a i nforme d e c a mbi o
La aut or i dad d e cont rol del c a mb i o de c i de
Solicitud s e pone en fila p a r a la acci n, s e g e n e r a OCI
I
As i gnaci n d e i ndi vi duos p a r a obj et os d e conf i gur aci n

" Sa l i da " d e obj et os d e conf i gur aci n (el ement os)
I
Se h a c e el c a mb i o
i
Revisin (audi t or a] del c a mb i o
I
"Ent r ada" de los el ement os d e conf i gur aci n que ha n c a mb i a d o
I
Est abl eci mi ent o d e una l nea b a s e p a r a p r u e b a s
Real i zaci n d e act i vi dade s d e ga r a nt a d e c a l i da d y d e p r u e b a s
I
"Pr omoci n" d e los c a mbi o s p a r a incluirlos e n la si gui ent e l i ber aci n (revisin)
Reconst rucci n d e la versi n a p r o p i a d a del s of t war e
I
Revisin (audi t or a) del c a mbi o p a r a l odos los el ement os d e conf i gur aci n
\
Inclusin d e los c a mbi o s e n l a nue va ver si n
J
Di st ri buci n d e la n ue va <
Se ni e ga la solicitud d e c a mb i o

Se i nforma el usuar i o
TM
PDF Editor
812 P AR T E C U A T R O GESTIN DE PROYECTOS DE SOFTWARE
^ O N S E J O ^
pt e s e po r u n po c o
m s d e c o n t r o l d e
c a m b io d e l q u e s e
c r e a q u e n e c e s it a r .
E s pr o b a b l e q u e
d e m a s ia d o s e r l o
c a n t id a d c o r r e c t a .
la posi bi l i dad de r eal i zar cual es qui er a c a mbi os j ust i f i cados por el pr oyect o y los
r equi si t os t cni cos (en t a nt o l os c a mbi os n o af ect en r equi si t os de s i s t ema mas
ampl i os que s e e nc ue nt r a n f uer a del mbi t o de t r abaj o del desar r ol l ador ) . Una vez
que el obj et o haya e xpe r i me nt a do una revi si n t cni ca f or mal y haya si do apr obado
s e pue de cr ear un a l nea bas e. 5 Una ve z que un ECS s e convi er t e en l nea ba s e se
i mpl e me nt a un c o n t r o l d e c a m b io a n iv e l d e l pr o y e c t o . Ahor a, par a r eal i zar un cam
bio, el desar r ol l ador de be obt ener la apr obaci n del gest or del pr oyect o (si el camb: :
e s "local") o de la ACC si el c a mbi o af ect a ot r os ECS. En a l gunos cas os , la gener a-
ci n f or mal de l as sol i ci t udes de cambi o, l os i nf or mes de c a mbi o y l as OC1 s e distri-
buyen. Sin embar go, s e lleva a c a bo la eval uaci n de cada cambi o, y t odos l os cambi os
s e s i guen y r evi san.
Cua ndo el pr oduct o d e s of t wa r e s e l i bera ent r e l os cl i ent es s e i nst i t uye el c o n t r o
d e c a m b io fo r m a l . En la figura 27. 5 se h a e s bo z a do el pr ocedi mi ent o de cont r ol de
cambi o f or mal .
"El combi o e s i nevi t abl e, except o por o los m qui na s e xpe nde dor a s . "
Calcomana en on parachoques
La aut or i dad de cont rol del c a mbi o j uega un papel act i vo en la s e gunda y t er cer a
c a pa s del cont rol . Dependi endo del t a ma o y car ct er de un pr oyect o d e s of t war e
la ACC pue de es t ar c ompue s t a de un a pe r s ona (el ges t or del proyect o) o var i as per-
s o n a s (por ej empl o, r e pr e s e nt ant e s de s of t war e, har dwar e, i ngeni er a de ba s e s de
dat os, sopor t e, mer cadot ecni a) . El papel de la ACC e s t ener una visin gl obal , es t o
es: eval uar el i mpact o del c a mbi o m s all del ECS en cuest i n. Cmo af ect ar el
cambi o al ha r dwa r e ? Cmo af ect ar al de s e mpe o? Cmo modi f i car la per cep-
ci n del cl i ent e acer ca del pr oduct o? Cmo af ect ar la cal i dad y fiabilidad del pr o-
duct o? Es t as y mu c h a s ot r as pr e gunt a s l as abor da la ACC.
HOGARSEGURO
Problemas en la GCS
El e s c e nar i o: Oficina de Doug
Milier cuando comi enza el proyect o del software
Ho g a r S e g u r o .
Los actores: I
ingeniera del soft ware de Ho g a r S e g u r o ) y Vinod Raman,
Jami e Lazar y ot ros mi embros del equi po de ingenier a
del software del pr odudo.
La conversaci n:
Do u g : Yo s que es muy pronto, per o t enemos que
habl ar acer ca de la gestin del cambi o.
Vi nod (re): Apenas. Mercadotecnia llam esta
ma a na con unos cuant os "segundos pensami ent os"
Na da importante, per o es slo el comi enzo.
5 Se puede crear una linea base tambin por otras razones. Por ejemplo, cuando se crean "construc-
ciones diarias" todos los componentes que entran en un tiempo dado se convierten en la linea base
para el trabajo del da siguiente.
TM
PDF Editor
813
Hemos sido bast ant e informales acer ca d e la
del cambi o en proyectos anteriores.
.o s, pero ste es mayor y ms visible, y segn
(asiente con l a cabeza) : Fuimos asesinados
; incontrolados en el proyecto de control de la
en el hogar . . . recuerda las demor as que. . .
frunce el ceo): Una pesadilla que prefiero no
Asi que qu hacemos.
Como lo veo, tres cosas. Primero, t enemos que
:r, o pedir prest ado, un proceso de control de
2Te refieres a cmo la gent e solicita los cambi os?
Si, pero t ambi n cmo eval uamos el cambi o,
cundo hacerl o si eso es lo que decidimos) y
cmo conservamos los registros d e lo que af ect a el
cambi o.
Do u g : Segundo, tenemos que obt ener una herrami ent a 1
de GCS real ment e buena pa r a control del cambi o y de la
versin.
J a mi e : Podemos construir una base de dat os p a r a todos
nuestros product os de t r abaj o.
Vi no d: Se llaman ECS en este contexto, y la mayor a de
las buenas herrami ent as of r ecen cierto soport e pa r a eso.
Do u g : Ese es un buen comi enzo, ahor a tenemos que. . .
J a mi e : Oye, Doug: dijiste que er an tres cosas. , .
Do u g ( s onr e ) : Tercera: todos tenemos que
compromet ernos a seguir el proceso de gestin del
cambi o y usar las herrami ent as, sin importar cul es sean,
de acuer do?
Ci l es
S M las
que se
durant e
de
?
27.3.4 Auditora de la configuracin
La i dent i fi caci n, el cont rol de la ver si n y el cont rol del c a mbi o ayudan al des ar r o-
Il ador del s of t wa r e a ma nt e ne r el or de n en l o que de ot r o mo d o ser i a un a si t uaci n
cat i ca e i nest abl e. Sin e mbar go, i ncl uso el me c a n i s mo de cont rol m s exi t oso sl o
si gue un cambi o has t a que no s e ge ne r a una OCI. Cmo se pue de gar ant i zar que el
c a mbi o s e ha i mpl e me nt a do con pr opi edad? La r es pues t a e s dobl e: 1) r evi s i ones t c-
ni cas f or mal es y 2) audi t or a de la conf i gur aci n del s of t war e.
La revi si n t cni ca f or mal ( pr es ent ada con det al l e en el cap t ul o 26) s e enf oca en
la cor r ecci n t cni ca del obj et o de conf i gur aci n que s e h a modi f i cado. Los r evi so-
r es eval an el ECS par a de t e r mi nar s u cons i s t enci a con ot r os ECS, omi s i one s o
pot enci al es ef ect os col at er al es. Se de be r eal i zar un a revi si n t cni ca f or mal en casi
la mayor a de l os cambi os trivial es.
Una a u d it o r a d e c o n fig u r a c i n d e l s o ft wa r e c ompl e me nt a la revi si n t cni ca for-
mal al abor dar l as s i gui ent es pr egunt as :
1. Se h a r eal i zado el cambi o es peci f i cado en la OCI? Se han i ncor por ado modi -
ficaciones adi ci onal es?
2 . Se ha r eal i zado una revi si n t cni ca f or mal par a eval uar la cor r ecci n t c-
ni ca?
3 . Se ha s egui do el pr oce s o de s of t war e ? Se han apl i cado a d e c u a d a me n t e los
e s t nda r e s de i ngeni er a del s of t war e?
4 . El c a mbi o s e ha r es al t ado en el ECS? Se h a n es peci f i cado la f echa y el aut or
del cambi o? Los at r i but os del obj et o de conf i gur aci n r ef l ej an el cambi o?
TM
PDF Editor
( C ONS E J O^
l a b r e s e u n o l is t a d e
"n e c e s it a c o n o c e r "
pa r a c a d a o b j e t o d e
c o n fig u r a c i n y
c o n s r v e s e a c t u a l i-
za d a . Cu a n d o s e
r e a l ic e u n c a m b io , e s
n e c e s a r io a s e g u r a r s e
d e q u e t o d o s l o s d e l a
l is t a s e a n n o t ific a d o s .
5 . Se h a n s e gui do l os pr ocedi mi ent os d e GCS par a de s t acar el cambi o, regi s-
t r ar l o e i nf or mar de l?
6 . Todos l os ECS r el aci onados s e h a n act ual i zado de ma n e r a a de c ua da ?
En a l gunos cas os , l as pr e gunt as de la audi t or a s e pl ant e an c o mo par t e d e un a rev* -
si n t cni ca f or mal . Sin e mbar go, c ua n do la GCS e s un a act i vi dad f or mal , la audi : : -
ra de GCS la lleva a c a bo por s e pa r a do el gr upo de a s e gur a mi e nt o de la cal i da;
Tal es audi t or as f or mal es de conf i gur aci n t a mbi n a s e gur a n que l os ECS correct as
(por ver si n) s e h a n i ncor por ado e n un a cons t r ucci n espec f i ca y que t oda la doc_
me nt aci n est act ual i zada y e s cons i s t ent e con la ver si n q u e s e h a const r ui do.
27.3.5 Informe de estado
El in fo r m e d e e s t a d o d e l a c o n fig u r a c i n (a veces l l amado c o n t a b il id a d d e e s t a d o ) es
una t ar ea de GCS que r e s ponde l as s i gui ent es pr egunt as : 1) qu ocur r i ? 2) qui c-
io hi zo? 3) cundo ocur r i ? 4) qu ot r a cos a s er af ect ada?
En la figura 27. 5 s e mues t r a el f l uj o de i nf or maci n par a el i nf or me de e s t a do ce
la conf i gur aci n (IEC). Cada ve z que s e le as i gna un a i dent i fi caci n nue va o act ual : -
zada a un ECS s e ef ect a una e nt r ada d e IEC. Cada ve z que la ACC a pr ue ba un cam -
bi o (es deci r, s e expi de un a OCI) s e ge ne r a un a ent r ada en el IEC. Cada ve z que se
r eal i za un a audi t or a de la conf i gur aci n l os r es ul t ados s e r epor t an c o mo par t e de a
t ar ea de IEC. El r es ul t ado del IEC e s posi bl e col ocar l o en un a ba s e de da t o s en l nea
o en un si t i o Web, de mo d o que l os des ar r ol l ador es y l os e nc a r ga dos del mant eni -
mi e nt o del s of t wa r e pue de n t ener a c c e s o a la i nf or maci n del c a mbi o medi ar . : ;
cat egor as cl ave. Adems , s e ge ne r a un IEC con r egul ar i dad y s u finalidad e s man-
t ener a l os ges t or es y pr of es i onal es al er t as ant e de l os c a mbi os i mpor t ant es .
S o po r t e d e l a GCS
Objetivo: Las herramientas de GCS
proporci onan soporte a una o ms d e las
actividades del proceso est udi adas en la seccin 27. 3.
Me c n i c a : La mayor a de tas moder nas herrami ent as de
GCS funciona en conjunto con un depsi t o (un sistema de
bas e de datos) y ofrecen mecani smos pa r a identificar,
control de la versin y el cambi o, audi t or a e informe.
CCC/Ha r v e s t , distribuida por Comput er Associates
(www.cai.com), es un sistema de GCS multiplataforma.
Cl e a r Co s e , desarrol l ada por Rational (www.rational.com),
ofrece una familia de funciones d e GCS.
Co n c u r r e n t Ve r s io n s S y s l e m (SVC), una herrami ent a de
fuente abi er t a (www.cvshome.org), es uno de los
sistemas de control de versin ms ampl i ament e
empl eados en la industria (vase un r ecuadr o anterior).
PVCS , distribuida por Merant (www. merant. com), ofrece
un conjunto completo de herrami ent as de GCS que son
apl i cabl es t ant o en soft ware convencional como en
WebApps.
y
6 Las herramientas mencionadas slo representan una muestra de esta categora. En la mayora de
los casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores
TM
PDF Editor
CAP TULO 27 GESTIN DEL CAMHO
8 1 5
/
f S o u r c e Fo r g e , distribuida por VA Soft ware
(sourceforge.net), ofrece gestin de versin,
capaci dades de construccin, seguimiento de
pr obl emas / bugs y muchas ot ras caractersticas de
gestin.
5 . r r o u n d S CM, desar r ol l ada por Seapi ne Soft ware
(www.seapine.com), proporci ona capaci dades
completas de gestin del cambi o.
V
Vesto, distribuida por Compac (www.vestasys.org), es un
sistema de GCS de domi ni o pblico que puede da r
soporte tanto a proyectos pequeos (< 10 KLDC) como
a gr andes ( 10, 000 KLDC).
Una extensa lista de herrami ent as comerciales y entornos
pa r a GCS, se puede encont rar en
www. cmt oday. com/ yp/ commerci al . html.
\
? Qu
impacto
Sene un cambio
i escont rol ado
sobre una
WebApp?
En la par t e 3 de es t e libro s e es t udi la nat ur al e za especi al de l as apl i caci ones Web
y el pr oce s o de i ngeni er a Web neces ar i o par a const rui rl o. Ent re l as mu c h a s car ac-
t er st i cas que di f er enci an a l as WebApps del s of t wa r e convenci onal s e e nc ue nt r a la
nat ur al e za ubi cua del cambi o.
La i ngeni er a Web ut i l i za un mode l o de pr oces o i ncr ement al i t erat i vo (cap t ul o 16)
que apl i ca mu c h o s pr i nci pi os der i vados del desar r ol l o de s of t wa r e gi l (cap t ul o 4).
Al ut i l i zar es t e enf oque, un equi po de i ngeni er a con f r ecuenci a desar r ol l a un i ncre-
me n t o de WebApp en un pe r i odo muy cor t o me di a nt e un e nf oque ba s a do en el cl i en-
t e. Los i ncr e me nt os s ubs e c ue nt e s agr egan cont eni do y f unci onal i dad adi ci onal es, y
tal vez cada uno i mpl e me nt e c a mbi os que c onduz c a n a cont eni do a ume nt a do,
me j or faci l i dad de uso, est t i ca mej or ada, me j or navegaci n, d e s e mp e o a ume n t a -
do y mayor s egur i dad. En cons ecuenci a, en el mu n d o gil de la i ngeni er a Web el
cambi o se ve de ma n e r a un poc o di f er ent e.
Los i ngeni er os Web de be n adopt ar el cambi o, e i ncl uso un t pi co e qui po gil evi t a
t o da s l as c os a s que pa r e c e n pe s a dos pr oces os , bur ocr t i cos y f or mal es . Por lo gene-
ral, s e cons i der a ( aunque i ncor r ect ament e) que la gest i n de la conf i gur aci n del
s of t war e pos e e e s t a s car act er st i cas. Esta a pa r e nt e cont r adi cci n s e r es uel ve al n o
r e chazar l os pri nci pi os, pr ct i cas y he r r a mi e nt a s de la GCS, si no m s bi en mol de n-
dol as par a sat i sf acer l as ne c e s i da de s es peci al es de l os pr oyect os de i ngeni er a Web.
27.4.1 Problemas en la gestin de la configuracin par a WebApps
Conf or me l as WebApps s e vuel ven cada vez m s i mpor t ant e s par a la s obr evi venci a
y el cr eci mi ent o de l os negoci os, cr ece la neces i dad de la gest i n de la conf i gur aci n.
Por qu? Por que sin cont r ol es ef i caces l os cambi os i na de c ua dos a un a WebApp
( r ecur dese que la i nmedi at ez y la evol uci n cont i nua son l os at r i but os do mi n a n t e s
de mu c h a s WebApps) conduci r an a la di f usi n no aut or i zada de i nf or maci n de un
nue vo pr oduct o; f unci onal i dad e r r ne a o pobr e me nt e pr oba da que f r ust r a a l os visi-
t ant es a un si t i o Web; hoyos e n la s egur i dad que po n e n en pel i gro l os s i s t e mas i nt er-
nos de la compa a; y ot r as c ons e c ue nc i a s e c o n mi c a me n t e de s agr adabl e s o i ncl u-
s o des as t r os as .
TM
PDF Editor
Las est rat egi as general es para la gestin de confi guraci n del sof t war e (GCS) des-
critas en est e captulo son aplicables, per o las tcticas y her r ami ent as se deber
adaptar para que concuerden con la nat ural eza nica de las WebApps. Se deben con-
siderar cuat ro t emas cuando se desarrol l en t ct i cas para la gestin de la configura-
cin de la WebApp: cont eni do, personal , escalabilidad y polticas.
Cont eni do. Una WebApp tpica cont i ene una ampl ia vari edad de contenido: texto
grficos, applets, guiones, archi vos de audi o/ vi deo, format os, el ement os de pgina
activos, tablas, dat os clasificados por niveles y muchos otros. El ret o es organizar
est e ocano de cont eni do en un conj unt o racional de obj et os de confi guraci n (sec-
cin 27.1.4) y luego est abl ecer mecani smos de control de confi guraci n adecuados
para di chos objetos.
Personal . Puest o que un porcent aj e significativo del desarrol l o de la WebApp con-
tina real i zndose en una forma a d h o c , cualquier persona involucrada en la
WebApp puede (y con frecuenci a lo hace) crear cont eni do. Muchos creadores de
cont eni do no tienen conoci mi ent os de ingeniera del sof t war e e i gnoran por com-
pleto la importancia de la gestin de la configuracin. Por lo t ant o, la aplicacin
crece y cambi a en una forma descont rol ada.
Escal abi l i dad. Las t cni cas y los cont rol es apl i cados a una WebApp pequea no
se escal an bien hacia arriba. No es inusual que una WebApp si mpl e crezca signifi-
cat i vament e conforme se i mpl ement an i nt erconexi ones con los si st emas de infor-
maci n existentes, bas es de dat os, depsi t os de dat os y portal es. Conforme crecen
el t amao y la compl ejidad, los cambi os pequeos pueden t ener efect os de largo
al cance e imprevistos que pueden ser probl emticos. En consecuenci a, el rigor de
los mecani smos de control de la configuracin debe ser di rect ament e proporci ona-
les a la escal a de la aplicacin.
Pol ti cas. Quin "posee" una WebApp? Esta pregunt a se pl ant ea en compa as
grandes y pequeas, y su respuest a tiene un i mpact o significativo en las actividades
de gestin y control asoci adas con la IWeb. En ciertas instancias, los desarrol l adores
Web se ubican fuera de la organi zaci n TI, lo que crea pot enci al es dificultades de
comuni caci n. Dart [DAR99] sugiere las si gui ent es pr egunt as para ayudar a ent en-
der l as polticas asoci adas con la IWeb:
M: cm s e Quin as ume la responsabi l i dad de la precisin de la i nformaci n en el sitio
determina Web?
Qui n t i e n e l o
responsabilidad * Qu i n asegur a que se han segui do los procesos de control de calidad ant es
de la GC de la de que la i nformaci n se publ i que en el sitio?
WÂpp? Quin es el responsabl e de real izar los cambi os?
Quin as ume el cost o del cambio?
Las r espuest as a est as pr egunt as ayudan a det ermi nar a l as per sonas que, dent ro
de una organi zaci n, deben adopt ar un proceso de gestin de la confi guraci n para
l as WebApps.
TM
PDF Editor
817
27.4.2 Objetos de configuracin WebApp
Las WebApps a ba r c a n una ampl i a g a ma de obj et os de conf i gur aci n: obj et os de c on-
t eni do (por ej empl o, texto, gr f i cos, i mgenes , vi deo, audi o), c o mp o n e n t e s f unci o-
nal es (por ej empl o, gui ones, appl et s) y obj et os de i nt erfaz (por ej empl o, COM o CORBA).
Los obj et os WebApp se pue de n i dent i fi car ( as i gnndol es nombr e s de archi vo) en
cual qui er f or ma que s ea apr opi ada par a la or gani zaci n. Sin e mbar go, s e r ecomi en-
dan l as s i gui ent es c onve nc i one s par a gar ant i zar que s e cons er va la compat i bi l i dad
ent r e pl at af or mas cr uzadas : l os nombr e s de ar chi vo de be n es t ar l i mi t ados a 32 car ac-
t er es de l ongi t ud, s e deben evi t ar l os n o mbr e s con mays cul as me z c l a da s o t oda s
mays cul as , as c o mo el u s o de s ubr ayados . Adems , l as r ef er enci as URL (vnculos)
dent r o de un obj et o de conf i gur aci n s i empr e de be n us ar t r ayect or i as r el at i vas (por
ej empl o, . . . / pr oduct os / s e ns or e s de al ar ma. ht ml ) .
Todo el cont e ni do de la WebApp t i ene f or mat o y est r uct ur a. Los f or mat os i nt er-
n o s de ar chi vo l os di ct a el e nt or no de c mput o e n el que s e a l ma c e na el cont eni do.
Sin e mba r go, el fo r m a t o d e r e pr e s e n t a c i n ( us ual ment e l l amado fo r m a t o d e d e s pl ie -
g u e ) s e def i ne con el et i l o est t i co y l as r egl as de di s eo es t abl eci das par a la
WebApp. La e s t r u c t u r a d e l c o n t e n id o def i ne un a ar qui t ect ur a de cont eni do; e s t o es:
def i ne la f or ma en la que los obj et os de cont eni do s e e ns a mbl a n par a pr es ent ar
i nf or maci n si gni fi cat i va a un us uar i o final. Boi ko IBOI02] def i ne la es t r uct ur a c o mo
" ma pa s que ust ed t i ende s obr e un c onj unt o de t r ozos [obj et os] de cont eni do par a
or gani zar l os y hacer l os acces i bl es a l as pe r s ona s que l os necesi t an".
27.4.3 Gestin del contenido
La g e s t i n d e l c o n t e n id o s e r el aci ona con la gest i n de la conf i gur aci n e n el s e nt i do
en q u e un s i s t ema de gest i n del cont eni do (SGC) es t abl ece un pr oce s o ( apoyado por
her r ami ent as ) q u e adqui er e cont e ni do exi s t ent e (de un ampl i o or de na mi e nt o de
obj et os de conf i gur aci n de la WebApp), l os es t r uct ur a en un a f or ma que per mi t e
pr es ent ar l os a un us uar i o final y l uego l os of r e ce al e nt or no del l ado del cl i ent e par a
s u despl i egue.
"La gest i n del cont eni do es un ant dot o pa r a el f r enes i nf or mat i vo de la act ual i dad. "
Bob Boiko
El us o m s c o mn del s i s t ema de gest i n del cont eni do ocur r e c ua n do s e cons -
t ruye una WebApp di nmi ca. Est e t i po de WebApp cr ea pgi nas Web "al vuel o". Es
deci r, us ua l me nt e el us uar i o cons ul t a la WebApp sol i ci t ando i nf or maci n espec f i ca.
La WebApp cons ul t a una ba s e de dat os , f or mat e a la i nf or maci n en concor danci a y
la pr es ent a al usuar i o. Por ej empl o, un a c o mpa a musi cal of r ece una librera de CD
e n vent a. Cua ndo un us uar i o solicita un CD o s u equi val ent e en ms i ca el ect r ni ca,
s e cons ul t a un a ba s e de da t os y un a var i edad de i nf or maci n acer ca del ar t i st a, el
CD (por ej empl o, su por t ada o grfi ca), el cont eni do musi cal y mue s t r a s de audi o s e
de s c a r ga n y conf i gur an en una pl ant i l l a d e cont e ni do es t ndar . La pgi na Web resul -
TM
PDF Editor
\
CLAVE
El s ubs i s t e ma de
col ecci n abar ca t odas
l as acci ones que s e
r equi er en pora cr ear ,
adquirir o convert i r el
cont eni do en uno
f or mo que s e pue da
pr es ent ar en el l ado
del cl i ent e.
t ant e se cons t r uye e n el l ado del ser vi dor y pas a al na ve ga dor del l ado del clier.tr
par a que la e xa mi ne el us uar i o final. En la figura 27. 6 s e mue s t r a un a r e pr e s e nt a do -
genr i ca de est o.
En el s ent i do m s gener al , un SGC "conf i gur a" el cont eni do par a el us uar i o f r
al i nvocar t r es s ubs i s t e ma s i nt egr ados: de col ecci n, de gest i n y de publ i caci n
[B0102).
El s u b s i s t e ma de c o l e c c i n. El cont eni do pr oce de de l os da t os y la i nformaci n
que debe cr ear o adqui r i r un desar r ol l ador de cont eni do. El s u b s is t e m a d e c o l e c c i n
abar ca t odas l as acci one s que s e r equi er en pa r a cr ear y / o adqui r i r cont eni do, as.
c o mo l as f unci ones t cni cas ne ce s ar i as par a 1) convert i r el cont eni do en una for-
ma t o que se pue da r epr es ent ar e n un l enguaj e de ma r c a s (por ej empl o, HTML, XML
y 2) or gani zar el cont eni do e n pa que t e s que s e p u e d a n des pl egar con ef i caci a en e
l ado del cl i ent e.
El s ubs i s t e ma d e g e s t i n. Una ve z que el cont e ni do exi st e de be guar dar s e en un
depsi t o, cat al ogar s e par a adqui si ci n y us o s ubs e cue nt e s , y et i quet ar s e par a definir
1) su e s t a do act ual (por ej empl o, el obj et o de cont eni do est compl et o o en desar r o-
llo), 2) la versi n apr opi ada del obj et o de cont eni do, y 3) l os obj et os de cont eni do
r el aci onados . Por lo t ant o, el s u b s is t e m a d e g e s t i n i mpl e me nt a un deps i t o que
abar ca l os s i gui ent es el ement os :
Ba s e d e d a t o s d e c o n t e n id o : la es t r uct ur a de i nf or maci n que s e ha est abl eci do
par a a l ma c e na r t odos l os obj et os de cont eni do.
Sistema de
gestin del
cont eni do
(SGC).
Base de dal os
Plantillas
Si st ema d e
gest i n del
cont eni do
Cdi go
HTML + gui ones
Na v e g a d o r l ado del cl iente
Lado de! servi dor
TM
PDF Editor
CAPTULO 27 GESTIN DEL CAMBI O
819
\
CI?AVE
a s i s t e d e
i i m p l e m e n t o u n
) p o r a t o d o e l
o . Lo g e s t i n
i c c o n f i g u r a c i n s e
w a c o b o d e n t r o d e
i s 9JBstem o .
CL AVE
u x s t e m o d e
i o b t i e n e
) d el d e p s i t o
s n t r e g o o l o s
r . * j o d o r e s e n e l l o d o
m i e n t e .
Capacidades de la base de datos f u n c i o n e s qu e p e r m i t e n a l SGC b u s c a r o b j e t o s
d e c o n t e n i d o e s p e c f i c o s (o c a t e g o r a s d e o b j e t o s ) , a l m a c e n a r y r e c u p e r a r l o s
o b j e t o s , y g e s t i o n a r l a e s t r u c t u r a d e a r c hi vo s qu e s e ha e s t a b l e c i d o p a r a e l
c o n t e n i d o .
Funciones de gestin de la configuracin: l o s e l e m e n t o s f u n c i o n a l e s y f l u j o d e
t r a b a j o a s o c i a d o qu e s o p o r t a n l a i d e n t i f i c a c i n d e l o b j e t o d e c o n t e n i d o ,
c o n t r o l d e l a ve r s i n , g e s t i n d e l c a m b i o , a u d i t o r i a d e l c a m b i o y c r e a c i n d e
i n f o r m e s .
Ad e m s d e e s t o s e l e m e n t o s , e l s u b s i s t e m a d e g e s t i n i m p l e m e n t a u n a f u n c i n d e
a d m i n i s t r a c i n qu e a b a r c a l o s m e t a d a t o s y r e g l a s qu e c o n t r o l a n l a e s t r u c t u r a g l o b a l
d e l c o n t e n i d o y l a f o r m a e n l a qu e r e c i b e s o p o r t e .
El s ubs i s t e ma de publ i caci n. El c o n t e n i d o s e d e b e e x t r a e r d e l d e p s i t o , c o n -
ve r t i r s e e n u n a f o r m a qu e e s t d i s p u e s t a p a r a l a p u b l i c a c i n y f o r m a t e a r s e d e m o d o
qu e s e a p o s i b l e t r a n s m i t i r l o a l o s n a ve g a d o r e s d e l l a d o d e l c l i e n t e . El subsistema de
publicacin l o g r a e s t a s t a r e a s m e d i a n t e u n a s e r i e d e p l a n t i l l a s . Ca d a plantilla e s u n a
f u n c i n qu e c o n s t r u ye u n a p u b l i c a c i n e m p l e a n d o u n o d e t r e s c o m p o n e n t e s d i f e -
r e n t e s [B 0102]:
Elementos estticos: l o s t e x t o s , g r f i c o s , m e d i o s a u d i o vi s u a l e s y g u i o n e s qu e
ya n o r e qu i e r e n p r o c e s a m i e n t o u l t e r i o r s e t r a n s m i t e n d i r e c t a m e n t e a l l a d o d e l
c l i e n t e .
Servicios de publicacin: f u n c i n qu e s o l i c i t a s e r vi c i o s e s p e c f i c o s d e r e c u p e r a -
c i n y f o r m a t e o qu e p e r s o n a l i za n e l c o n t e n i d o (m e d i a n t e r e g l a s p r e d e f i n i d a s ) ,
e f e c t a n c o n ve r s i n d e d a t o s y c o n s t r u ye n vn c u l o s d e n a ve g a c i n a p r o -
p i a d o s .
Servicios extemos: p r o p o r c i o n a n a c c e s o a i n f r a e s t r u c t u r a d e i n f o r m a c i n
c o r p o r a t i va e x t e r n a c o m o d a t o s d e l a e m p r e s a o a p l i c a c i o n e s d e "c u a r t o
t r a s e r o ".
Un s i s t e m a d e g e s t i n d e c o n t e n i d o qu e a b a r qu e c a d a u n o d e e s t o s s u b s i s t e m a s e s
a p l i c a b l e a g r a n d e s p r o ye c t o s d e i n g e n i e r a We b . Si n e m b a r g o , l a f il o so f a b s i c a y l a
f u n c i o n a l i d a d a s o c i a d o s c o n u n SGC s o n a p l i c a b l e s a t o d a s l a s We b Ap p s d i n m i c a s .
Gestin del contenido

Obj e t i v o : Au x i l i a r a l o s i n g e n i e r o s d e
s o f t w a r e y d e s a r r o l l a d o r e s d e c o n t e n i d o a
g e s t i o n a r e l c o n t e n i d o qu e s e i n c o r p o r a e n l a s We b Ap p s .
Me c ni c a: L as he r r a m i e n t a s e n e s t a c a t e g o r a p e r m i t e n
zu e l o s i n g e n i e r o s We b y p r o ve e d o r e s d e c o n t e n i d o
a c t u a l i c e n e l c o n t e n i d o d e u n a We b Ap p e n u n a f o r m a
V"
c o n t r o l a d a . L a m a yo r a e s t a b l e c e u n s i m p l e s i s t e m a d e
g e s t i n d e a r c hi vo s qu e a s i g n a a c t u a l i za c i n p g i n a p o r
p g i n a y p e r m i s o s d e e d i c i n p a r a va r i o s t i p o s d e
c o n t e n i d o We b Ap p . Al g u n o s m a n t i e n e n u n s i s t e m a d e
ve r s i o n e s d e m o d o qu e s e p u e d e n l o g r a r ve r s i o n e s p r e vi a s
d e c o n t e n i d o p a r a p r o p s i t o s hi s t r i c o s .
y
TM
PDF Editor
820 PAETE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
Conten Management Tools Suite, d e s a r r o l l a d a p o r
i n t e r a c l i ve t o o l s . c o m (w w w . i n t e r a c t i ve t o o l s . c o m /) , e s u n
c o n j u n t o d e he r r a m i e n t a s d e g e s t i n d e c o n t e n i d o qu e
s e e n f o c a e n l a g e s t i n d e l c o n t e n i d o p a r a d o m i n i o s d e
a p l i c a c i n e s p e c f i c o s (p o r e j e m p l o , a r t c u l o s n u e vo s ,
a vi s o s c l a s i f i c a d o s , b i e n e s r a c e s ) .
eklron-CMS300, d e s a r r o l l a d a p o r e kt r o n
(w w w . e kt r o n . c o m ) , e s u n c o n j u n t o d e he r r a m i e n t a s qu e
o f r e c e c a p a c i d a d e s d e g e s t i n d e c o n t e n i d o , a s ! c o m o
he r r a m i e n t a s d e d e s a r r o l l o We b .
OmniUpdate, d e s a r r o l l a d a p o r We b s i t e ASP, In c .
(w w w . o m n i u p d a t e . c o m ) , e s u n a he r r a m i e n t a qu e
p e r m i t e a l o s p r o ve e d o r e s d e c o n t e n i d o a u t o r i za d o s
d e s a r r o l l a r a c t u a l i za c i o n e s c o n t r o l a d a s d e c o n t e n i d o
We b Ap p e s p e c i f i c a d o .
N
Tower IDM, d e s a r r o l l a d a p o r To w e r Te c hn o l o g i e s
(w w w . t o w e r t e c h. c o m ) , e s u n s i s t e m a d e p r o c e s a m i e n t o
d e d o c u m e n t o s y d e p s i t o d e c o n t e n i d o p a r a g e s t i o n a r
t o d a s l a s f o r m a s d e i n f o r m a c i n c o m e r c i a l n o
e s t r u c t u r a d a : i m g e n e s , f o r m a t o s , i n f o r m e s g e n e r a d o s
p o r c o m p u t a d o r a , c u e n t a s y f a c t u r a s , d o c u m e n t o s
o f i c i a l e s , c o r r e o e l e c t r n i c o y c o n t e n i d o We b .
En l o s s i g u i e n t e s s i t i o s We b s e p u e d e e n c o n t r a r
i n f o r m a c i n a d i c i o n a l a c e r c a d e l a GCS y l a s
he r r a m i e n t a s d e g e s t i n d e l c o n t e n i d o p a r a i n g e n i e r a
We b :
Web Developer's Virtual Encyclopedia (w w w . w d l v. c o m ) ,
WebDeveloper (w w w . w e b d e ve l o p e r . c o m ) , Developer Shed
(w w w . d e vs he d . c o m ) , webknowhow.net
(w w w . w e b kn o w ho w . n e t ) o WebReference
(w w w . w e b r e f e r e n c e . c o m ) .
27.4.4 Gestin del cambio
El f l u j o d e t r a b a j o a s o c i a d o c o n el c o n t r o l d e l c a m b i o p a r a s o f t w a r e c o n ve n c i o n a l
(s e c c i n 27. 3. 3) g e n e r a l m e n t e e s d e m a s i a d o l a b o r i o s o p a r a l a i n g e n i e r a We b . Es
i m p r o b a b l e qu e s e l o g r e l a s e c u e n c i a p e t i c i n d e c a m b i o s , i n f o r m e d e c a m b i o v
o r d e n d e c a m b i o d e i n g e n i e r a e n u n a f o r m a g i l y a c e p t a b l e p a r a l a m a yo r a d e l o s
p r o ye c t o s d e d e s a r r o l l o We b Ap p , En t o n c e s , c m o s e g e s t i o n a u n a c o r r i e n t e c o n t i -
n u a d e c a m b i o s s o l i c i t a d a p a r a el c o n t e n i d o y l a f u n c i o n a l i d a d d e l a We b Ap p ?
L a i m p l e m e n t a c i n d e u n a g e s t i n d e c a m b i o e f i c a z d e n t r o d e l a f il o so f a "c o d i f i -
c a y ve " qu e c o n t i n e d o m i n a n d o el d e s a r r o l l o d e l a s We b Ap p s r e qu i e r e m o d i f i c a r el
p r o c e s o d e c o n t r o l d e c a m b i o s c o n ve n c i o n a l . Ca d a c a m b i o s e d e b e c l a s i f i c a r e n u n a
d e c u a t r o c l a s e s :
Clase I: u n c a m b i o d e c o n t e n i d o o f u n c i n qu e c o r r i j a u n e r r o r o m e j o r e e l c o n t e -
n i d o o f u n c i o n a l i d a d l o c a l e s .
Clase 2: u n c a m b i o d e c o n t e n i d o o f u n c i n qu e t e n g a i m p a c t o s o b r e o t r o s o b j e t o s
d e c o n t e n i d o o c o m p o n e n t e s f u n c i o n a l e s .
Clase 3: u n c a m b i o d e c o n t e n i d o o f u n c i n qu e t e n g a a m p l i o i m p a c t o a t r a vs d e
u n a We b Ap p (p o r e j e m p l o , g r a n a m p l i a c i n d e l a f u n c i o n a l i d a d , m e j o r a s i g n i f i c a t i va
o r e d u c c i n d e l c o n t e n i d o , g r a n d e s c a m b i o s r e qu e r i d o s e n l a n a ve g a c i n ) .
Clase 4: u n g r a n c a m b i o d e d i s e o (p o r e j e m p l o , u n c a m b i o e n el d i s e o d e l a
i n t e r f a z o e n f o qu e d e n a ve g a c i n ) qu e i n m e d i a t a m e n t e a p r e c i a r n u n a o m s c a t e -
g o r a s d e u s u a r i o s .
7 L a s he r r a m i e n t a s e x p u e s t a s s l o r e p r e s e n t a n u n a m u e s t r a d e e s t a c a t e g o r a . En l a m a yo r a d e l o s
c a s o s l o s n o m b r e s d e l a s m i s m a s s o n m a r c a s r e g i s t r a d a s p o r s u s r e s p e c t i vo s d e s a r r o l l a d o r e s .
TM
PDF Editor
CAP TUL O 27 GESTIN DEL CAMBI O 821
3e s t n d e
c a m b i o s
p a r a
We b Ap p s .
Un a ve z c l a s i f i c a d o s l o s c a m b i o s s o l i c i t a d o s s e p u e d e n p r o c e s a r d e a c u e r d o c o n
e l a l g o r i t m o m o s t r a d o e n l a f ig u r a 27. 7.
En l a m i s m a f ig u r a, l o s c a m b i o s d e l a s c l a s e s I y 2 s e t r a t a n d e m a n e r a i n f o r m a l
y s e m a n e j a n e n u n a f o r m a g i l . En u n c a m b i o d e c l a s e 1 e l i n g e n i e r o We b e va l a e l
i m p a c t o d e l c a m b i o , p e r o n o s e r e qu i e r e r e vi s i n o d o c u m e n t a c i n e x t e r n a .
Co n f o r m e s e r e a l i za e l c a m b i o , l o s p r o c e d i m i e n t o s e s t n d a r d e e n t r a d a y s a l i d a s e
r e f u e r za n m e d i a n t e l a s he r r a m i e n t a s d e c o n f i g u r a c i n d e d e p s i t o . En c u a n t o a l o s
c a m b i o s d e l a c l a s e 2, e s o b l i g a c i n d e l i n g e n i e r o We b r e vi s a r e l i m p a c t o d e l c a m -
b i o s o b r e o b j e t o s r e l a c i o n a d o s (o p e d i r a l o s d e s a r r o l l a d o r e s r e s p o n s a b l e s d e s t o s
qu e l o ha g a n ) . Si el c a m b i o e s f a c t i b l e s i n qu e s e r e qu i e r a n c a m b i o s s i g n i f i c a t i vo s e n
o t r o s o b j e t o s , l a m o d i f i c a c i n o c u r r e s i n r e vi s i n o d o c u m e n t a c i n a d i c i o n a l . Si s e
r e qu i e r e n c a m b i o s s u s t a n t i vo s , s o n n e c e s a r i a s e va l u a c i n y p l a n i f i c a c i n u l t e r i o r e s .
Cambi o cl ase 2
De s a r r o l l a r b r e ve
d e s c r i p c i n e s c r i t a
e va l u a n d o
Tr a n s m i t i r a l o d o s
l o s p a r t i c i p a n t e s
Tr a n s m i t i r a t o d o s
l o s m i e m b r o s d e l
Cambi os
requeridos en
objetos
rel aci onados
Se r e qu i e r e Y
ms
eval uacin I De ocuerdo
l en real izacin
5e requiere
ms
eval uocin
(
"Sa l i d a " d e o b j e t o (s ) ^
d ser c a m b i a d o ! * ) J
/ Ef e c t u a r c a m b i o s d i s e o A
\ c o n s t r u c c i n , p r u e b a J
Cambi o cl ase 1
Cambi o cl ase 3
Cambi o cl ase 4
TM
PDF Editor
L o s c a m b i o s d e l a s c l a s e s 3 y 4 t a m b i n s e t r a t a n e n u n a f o r m a g i l , p e r o s e
r e qu i e r e n a l g u n a d o c u m e n t a c i n d e s c r i p t i va y m s p r o c e d i m i e n t o s d e r e vi s i o n e s
f o r m a l e s . L o s c a m b i o s d e l a c l a s e 3 r e qu i e r e n e l d e s a r r o l l o d e u n a descripcin de.
cambio qu e o f r e zc a u n a b r e ve e va l u a c i n d e l i m p a c t o d e l c a m b i o . L a d e s c r i p c i n s e
d i s t r i b u ye e n t r e t o d o s l o s m i e m b r o s d e l e qu i p o d e i n g e n i e r a We b , qu i e n e s l o r e vi -
s a n p a r a e va l u a r m e j o r s u i m p a c t o . Ta m b i n r e s p e c t o a l o s c a m b i o s d e l a c l a s e 4 s e
d e s a r r o l l a u n a d e s c r i p c i n d e l c a m b i o , p e r o e n e s t e c a s o l a r e vi s i n l a l l e va n a c a b o
t o d o s l o s p a r t i c i p a n t e s .
Gestin del cambio
M Obj e t i vo: Au x i l i a r a l o s i n g e n i e r o s We b y
d e s a r r o l l a d o r e s d e c o n t e n i d o a g e s t i o n a r l o s
c a m b i o s c o n f o r m e s e r e a l i za n s t o s e n o b j e t o s d e
c o n f i g u r a c i n We b Ap p .
Me c ni c a : L a s he r r a m i e n t a s e n e s t a c a t e g o r a
o r i g i n a l m e n t e f u e r o n d e s a r r o l l a d a s p a r a s o f t w a r e
c o n ve n c i o n a l , p e r o e s p o s i b l e a d a p t a r l a s a l a i n g e n i e r a
We b y r e a l i za r c a m b i o s c o n t r o l a d o s e n l a s We b Ap p s .
Herrami entas represent at i vas8
ChangeMan WCM, d e s a r r o l l a d a p o r Se r e n a
(w w w . s e r e n a . c o m ) , e s u n a d e u n c o n j u n t o d e
he r r a m i e n t a s
d e g e s t i n d e l c a m b i o qu e o f r e c e c a p a c i d a d e s d e GCS.
ClearCase, d e s a r r o l l a d a p o r Ra t i o n a l (w w w . r a t i o n a l . c o m ) ,
e s u n c o n j u n t o d e he r r a m i e n t a s qu e o f r e c e n
c a p a c i d a d e s c o m p l e t a s d e g e s t i n d e c o n f i g u r a c i n
p a r a We b Ap p s .
PVCS, d e s a r r o l l a d a p o r Me r a n t (w w w . m e r a n t . c o m ) , e s u n
c o n j u n t o d e he r r a m i e n t a s qu e o f r e c e n c a p a c i d a d e s
c o m p l e t a s d e g e s t i n d e c o n f i g u r a c i n p a r a We b Ap p s .
Source Inlegrty, d e s a r r o l l a d a p o r m ks (w w w . m ks . c o m ) , e s
u n a he r r a m i e n t a GCS qu e s e p u e d e i n t e g r a r c o n
e n t o r n o s d e d e s a r r o l l o s e l e c c i o n a d o s .
J
27.4.5 Control de la versin
Co n f o r m e u n a We b Ap p e vo l u c i o n a p o r m e d i o d e u n a s e r i e d e i n c r e m e n t o s , e s p o s i -
b l e qu e e x i s t a n a l m i s m o t i e m p o va r i a s ve r s i o n e s d i f e r e n t e s . Un a ve r s i n (l a We b Ap p
o p e r a t i va a c t u a l ) e s t d i s p o n i b l e p a r a l o s u s u a r i o s f i n a l e s p o r In t e r n e t ; o t r a ve r s i n
(el s i g u i e n t e i n c r e m e n t o d e l a We b Ap p ) qu i z e s t e n l a s e t a p a s f in al es d e p r u e b a
p r e vi a s a l l a n za m i e n t o ; u n a t e r c e r a ve r s i n e s t e n d e s a r r o l l o y r e p r e s e n t a u n a g r a n
a c t u a l i za c i n e n c o n t e n i d o , e s t t i c a d e i n t e r f a z y f u n c i o n a l i d a d . L o s o b j e t o s d e c o n -
f ig u r ac i n d e b e n e s t a r c l a r a m e n t e d e f i n i d o s , d e m o d o qu e c a d a u n o p u e d a e s t a r
a s o c i a d o c o n l a ve r s i n a d e c u a d a . Ad e m s , d e b e n e s t a r e s t a b l e c i d o s l o s m e c a n i s -
m o s d e c o n t r o l . Dr e i l i n g e r [DRE99] a b o r d a l a i m p o r t a n c i a d e l c o n t r o l d e l a ve r s i n (y
d e l c a m b i o ) c u a n d o e s c r i b e :
En u n s i t i o descontrolado, d o n d e m l t i p l e s a u t o r e s t i e n e n a c c e s o p a r a e d i t a r y c o n t r i b u i r ,
s u r g e el p o t e n c i a l p a r a e l c o n f l i c t o y l o s p r o b l e m a s , m s a n si l o s a u t o r e s t r a b a j a n d e s d e
8 L a s he r r a m i e n t a s e x p u e s t a s s l o r e p r e s e n t a n u n a m u e s t r a d e e s t a c a t e g o r a . En l a m a yo r a d e l o s
c a s o s l o s n o m b r e s d e l a s m i s m a s s o n m a r c a s r e g i s t r a d a s p o r s u s r e s p e c t i vo s d e s a r r o l l a d o r e s .
TM
PDF Editor
CAP T UL O 2 7 GESTIN DEL CAMB IO
823
d i f e r e n t e s o f i c i n a s e n d i s t i n t o s m o m e n t o s d e l d a y l a n o c he . Us t e d p u e d e p a s a r e l d a m e -
j o r a n d o e l a r c hi vo index.html p a r a u n c l i e n t e . De s p u s qu e ha r e a l i za d o l o s c a m b i o s , o t r o
d e s a r r o l l a d o r , qu i e n t r a b a j a e n s u c a s a d e s p u s d e s u j o r n a d a l a b o r a l , o e n o t r a o f i c i n a ,
p u e d e p a s a r l a n o c he c a r g a n d o s u p r o p i a n o ve d o s a ve r s i n r e vi s a d a d e l a r c hi vo
index.html, y s o b r e s c r i b i r p o r c o m p l e t o e l t r a b a j o qu e u s t e d ha r e a l i za d o , s i n f o r m a a l g u n a
d e r e t r o c e d e r !
Es t a s i t u a c i n d e b e s o n a r f a m i l i a r a t o d o s l o s i n g e n i e r o s d e s o f t w a r e , a s c o m o a
t o d o s l o s i n g e n i e r o s We b . Pa r a e vi t a r l o , s e d e b e e s t a b l e c e r u n p r o c e s o d e c o n t r o l d e
l a ve r s i n .
1. Se debe establecer un depsito central para el proyecto WebApp. El d e p s i t o c o n -
t e n d r l a s ve r s i o n e s a c t u a l e s d e t o d o s l o s o b j e t o s d e c o n f i g u r a c i n d e l a We b -
Ap p (c o n t e n i d o , c o m p o n e n t e s f u n c i o n a l e s y o t r o s ) .
2. Cada ingeniero Web crea su propia carpeta de trabajo. L a c a r p e t a c o n t i e n e
a qu e l l o s o b j e t o s c r e a d o s o c a m b i a d o s e n a l g n m o m e n t o d a d o .
3. Los relojes en las estaciones de trabajo de todos los desarroladores deben estar
sincronizados. Es t o t i e n e c o m o f in e vi t a r l o s c o n f l i c t o s d e s o b r e s c r i t u r a
c u a n d o d o s d e s a r r o l a d o r e s r e a l i za n a c t u a l i za c i o n e s qu e e s t n m u y c e r c a n a s
e n e l t i e m p o u n a d e o t r a .
4. Conforme se desarrollan nuevos objetos de configuracin o se cambian los obje-
tos existentes se importan al depsito central. L a he r r a m i e n t a d e c o n t r o l d e l a
ve r s i n (va s e e l e s t u d i o p r e c e d e n t e d e l SVC e n e s t e c a p t u l o ) g e s t i o n a r t o -
d a s l a s f u n c i o n e s d e e n t r a d a y s a l i d a d e l a s c a r p e t a s d e t r a b a j o d e c a d a i n g e -
n i e r o We b .
5. Conforme los objetos se importan al o exportan del depsito se elabora un men-
saje automtico de registro cronometrado. Es t o o f r e c e i n f o r m a c i n t i l p a r a a u -
d i t o r a y s e p u e d e c o n ve r t i r e n p a r t e d e u n e f e c t i vo e s qu e m a d e e l a b o r a c i n
d e i n f o r m e s .
L a he r r a m i e n t a d e c o n t r o l d e l a ve r s i n m a n t i e n e d i f e r e n t e s ve r s i o n e s d e l a We b Ap p
y p u e d e r e ve r t i r s e a u n a ve r s i n m s a n t i g u a si s e r e qu i e r e .
27.4.6 Auditora y elaboracin de informes
En b s qu e d a d e a g i l i d a d , l a s f u n c i o n e s d e a u d i t o r a y e l a b o r a c i n d e i n f o r m e s n o s e
r e s a l t a n e n e l t r a b a j o d e i n g e n i e r a We b . Si n e m b a r g o , n o s e e l i m i n a n p o r c o m p l e t o .
To d o s l o s o b j e t o s qu e e n t r a n o s a l e n d e l d e p s i t o s e a n o t a n e n u n r e g i s t r o qu e p u e d e
r e vi s a r s e e n c u a l qu i e r p u n t o e n e l t i e m p o . Es f a c t i b l e c r e a r u n i n f o r m e d e r e g i s t r o
c o m p l e t o d e m o d o qu e t o d o s l o s m i e m b r o s d e l e qu i p o d e i n g e n i e r a We b t e n g a n u n a
c r o n o l o g a d e l o s c a m b i o s s o b r e u n p e r i o d o d e f i n i d o . Ad e m s , s e e n va u n a n o t i f i -
c a c i n a u t o m t i c a d e c o r r e o e l e c t r n i c o (d i r i g i d a a l o s d e s a r r o l a d o r e s y p a r t i c i p a n -
t e s i n t e r e s a d o s ) c a d a ve z qu e u n o b j e t o e n t r e o s a l g a d e l d e p s i t o .
TM
PDF Editor
Estndares de GCS
y L a s i g u i e n t e l i st a d e e s t n d a r e s GCS
(p r o c e d e n t e e n p a r t e d e w w w , 12207. c o m ) e s
r a zo n a b l e m e n t e e x t e n s a :
Estndares IEEE s t andards . i eee. org/ cat al og/
olis
I NFORMACI N
IEEE 828
IEEE 1042
Estndares ISO
ISO 10007- 19 9 5
ISO/IEC 12207
ISO/IEC TR 15271
ISO/IEC TR 15846
Es t n d a r e s EIA
EIA 649
EIA CMB4-1A
EIA CMB 4-2
EIA CMB 4-3
EIA CMB 4-4
Pl a n e s d e g e s t i n d e c o n f i g u r a c i n
d e l s o f t w a r e
Ge s t i n d e c o n f i g u r a c i n d e l
s o f t w a r e
www. i s o . c h/ i s o / e n/
ISOOonl i ne. frontpage
Ge s t i n d e c a l i d a d , l i n e a m i e n t o s
p a r a GC
Te c n o l o g a d e i n f o r m a c i n ;
p r o c e s o s d e c i c l o d e vi d a d e
s o f t w a r e
Gu a p a r a ISO/IEC 12207
In g e n i e r a d e l s o f t w a r e ; p r o c e s o s
d e c i c l o d e vi d a d e s o f t w a r e ;
g e s t i n d e c o n f i g u r a c i n p a r a
s o f t w a r e
w w w . e i a . o r g /
Es t n d a r d e c o n s e n s o n a c i o n a l
p a r a g e s t i n d e c o n f i g u r a c i n
De f i n i c i o n e s d e g e s t i n d e l a
c o n f i g u r a c i n p a r a p r o g r a m a s d e
c o m p u t a d o r a s d i g i t a l e s
Id e n t i f i c a c i n d e c o n f i g u r a c i n
p a r a p r o g r a m a s d e c o m p u t a d o r a s
d i g i t a l e s
L i b r e r a s d e s o f t w a r e d e
c o m p u t a d o r a
Co n t r o l d e c a m b i o d e
c o n f i g u r a c i n p a r a p r o g r a m a s d e
c o m p u t a d o r a s d i g i t a l e s
EIA CMB 6-1C
EIA CMB 6-3
EIA CMB 6-4
EIA CMB 6-5
EIA CMB 7-1
Estndares
militares
es t adouni dens es
Do D MIL STD-9 73
MIL -HDBK-61
Otros es t ndares
DO-178B
ESA PSS-05-09
AECL CE-1001-STD
r e v. 1
DOE SCM l i st a d e
ve r i f i c a c i n
B S-6488
Me j o r e s p r c t i c a s -RU
CMII
Re f e r e n c i a s d e g e s t i n d e
c o n f i g u r a c i n y d a t o s
Id e n t i f i c a c i n d e c o n f i g u r a c i n
Co n t r o l d e c o n f i g u r a c i n
L i b r o d e t e x t o p a r a c o n t a b i l i d a d d e
e s t a d o d e c o n f i g u r a c i n
In t e r c a m b i o e l e c t r n i c o d e d a t o s d e
g e s t i n d e c o n f i g u r a c i n
www-l i brary. i tsi . di sa. mi l
Ge s t i n d e c o n f i g u r a c i n
Gu a p a r a g e s t i n d e c o n f i g u r a c i n
Di r e c t r i c e s p a r a el d e s a r r o l l o d e
s o f t w a r e d e a vi a c i n
Gu a p a r a g e s t i n d e c o n f i g u r a c i n
d e s o f t w a r e
Es t n d a r p a r a i n g e n i e r a d e l
s o f t w a r e d e s o f t w a r e d e s e g u r i d a d
c r t i c o
c i o . d o e . g o v/ ITRe f o r m / s qs e /
d o w n l o a d /c m c kl s t . d o c
Br itish St d . , g e s t i n d e
c o n f i g u r a c i n d e s i s t e m a s
b a s a d o s e n c o m p u t a d o r a
Of i c i n a d e c o m e r c i o
g u b e r n a m e n t a l : w w w . o g c . g o v. u k
In s t i t u t o d e m e j o r e s p r c t i c a s e n
GC: w w w . i c m hq. c o m
Un a Gua de recursos de gestin de configuracin o f r e c e
i n f o r m a c i n c o m p l e m e n t a r i a p a r a a qu e l l o s i n t e r e s a d o s e n
p r o c e s o s y p r c t i c a s d e GC. Es t d i s p o n i b l e e n
w w w . qu a l i t y. o r g /c o n f i g /c m -g u i d e . ht m l .
y
L a g e s t i n d e c o n f i g u r a c i n d e l s o f t w a r e e s u n a a c t i vi d a d p r o t e c t o r a qu e s e a p l i c a a
l o l a r g o d e l p r o c e s o d e s o f t w a r e . L a GCS i d e n t i f i c a , c o n t r o l a , a u d i t a e i n f o r m a m o d i -
f ic ac io n es qu e i n va r i a b l e m e n t e o c u r r e n m i e n t r a s s e d e s a r r o l l a s o f t w a r e y d e s p u s d e
TM
PDF Editor
CAP TULO 2 7 GESTIN DEL CAMB O
825
qu e s e l e l i b e r a a u n c l i e n t e . To d a l a i n f o r m a c i n p r o d u c i d a c o m o p a r t e d e l a i n g e -
n i e r a d e l s o f t w a r e s e vu e l ve p a r t e d e u n a c o n f i g u r a c i n d e s o f t w a r e . L a c o n f i g u r a -
c i n e s t o r g a n i za d a d e f o r m a qu e p e r m i t e l a g e s t i n o r d e n a d a d e l c a m b i o .
L a c o n f i g u r a c i n d e l s o f t w a r e e s t c o m p u e s t a d e u n c o n j u n t o d e o b j e t o s i n t e r r e -
l a c i o n a d o s , t a m b i n l l a m a d o s e l e m e n t o s d e c o n f i g u r a c i n d e l s o f t w a r e , qu e s e p r o -
d u c e n d e b i d o a a l g u n a a c t i vi d a d d e i n g e n i e r a d e l s o f t w a r e . Ad e m s d e d o c u m e n t o s ,
p r o g r a m a s y d a t o s , e l e n t o r n o d e d e s a r r o l l o qu e s e u t i l i za p a r a c r e a r s o f t w a r e t a m -
b i n s e p u e d e c o l o c a r b a j o c o n t r o l d e c o n f i g u r a c i n . To d o s l o s ECS s e g u a r d a n e n u n
d e p s i t o qu e i m p l e m e n t a m e c a n i s m o s y e s t r u c t u r a s d e d a t o s p a r a g a r a n t i za r l a i n t e -
g r i d a d d e l o s d a t o s , o f r e c e s o p o r t e d e i n t e g r a c i n p a r a o t r a s he r r a m i e n t a s d e s o f t -
w a r e , a p o ya l a d i s t r i b u c i n d e i n f o r m a c i n e n t r e l o s m i e m b r o s d e l e qu i p o d e s o f t w a r e
e i m p l e m e n t a f u n c i o n e s e n a p o yo d e l c o n t r o l d e l a ve r s i n y d e l c a m b i o .
Un a ve z d e s a r r o l l a d o y r e vi s a d o u n o b j e t o d e c o n f i g u r a c i n s e c o n vi e r t e e n l n e a
b a s e . L o s c a m b i o s a u n o b j e t o c o n ve r t i d o e n l n e a b a s e g e n e r a n l a c r e a c i n d e u n a
n u e va ve r s i n d e d i c ho o b j e t o . L a e vo l u c i n d e u n p r o g r a m a p u e d e s e g u i r s e a l e x a -
m i n a r l a hi s t o r i a d e r e vi s i n d e t o d o s l o s o b j e t o s d e c o n f i g u r a c i n . L o s o b j e t o s b s i c o s
y c o m p u e s t o s f o r m a n u n a p i s c i n a d e o b j e t o s a p a r t i r d e l a qu e s e c r e a n l a s ve r s i o -
n e s . El c o n t r o l d e l a ve r s i n e s e l c o n j u n t o d e p r o c e d i m i e n t o s y he r r a m i e n t a s p a r a
g e s t i o n a r e l e m p l e o d e d i c ho s o b j e t o s .
El c o n t r o l d e c a m b i o s e s u n a a c t i vi d a d d e p r o c e d i m i e n t o qu e a s e g u r a l a c a l i d a d y
l a c o n s i s t e n c i a c o n f o r m e l o s c a m b i o s s e r e a l i za n e n u n o b j e t o d e c o n f i g u r a c i n . El
p r o c e s o d e c o n t r o l d e c a m b i o s c o m i e n za c o n u n a p e t i c i n d e c a m b i o , c o n d u c e a u n a
d e c i s i n p a r a a c e p t a r o r e c ha za r l a y c u l m i n a c o n u n a a c t u a l i za c i n c o n t r o l a d a d e l
ECS qu e s e c a m b i a r .
L a a u d i t o r a d e l a c o n f i g u r a c i n e s u n a a c t i vi d a d d e SQA qu e a yu d a a g a r a n t i za r
qu e l a c a l i d a d s e c o n s e r va c o n f o r m e s e r e a l i za n l o s c a m b i o s . L o s i n f o r m e s d e e s t a -
d o o f r e c e n i n f o r m a c i n a c e r c a d e c a d a c a m b i o a qu i e n e s t e n g a n n e c e s i d a d d e c o n o -
c e r l a .
L a g e s t i n d e l a c o n f i g u r a c i n p a r a i n g e n i e r a We b e s s i m i l a r e n m u c ho s a s p e c -
t o s a l a GCS p a r a e l s o f t w a r e c o n ve n c i o n a l . Si n e m b a r g o , c a d a u n a d e l a s t a r e a s
p r i n c i p a l e s d e GCS s e d e b e n d e s t a c a r p a r a ha c e r l a s t a n s i m p l e s c o m o s e a p o s i b l e , y
s e d e b e n i m p l e m e n t a r p r o vi s i o n e s e s p e c i a l e s p a r a l a g e s t i n d e l c o n t e n i d o .
1BAB86] B a b i c h, W. A. , Software Conjiguration Management, Ad d i s o n -We s l e y, 19 86.
[BAC98J B a c h, J "The Hi g hs a n d L o w s o f Cha n g e Co n t r o l ", e n Computer, vo l . 31, n m . 8, a g o s -
t o d e 19 88, p p . 113-115.
(BER80) B e r s o f f , E. H. , V. D. He n d e r s o n y S. G. Si e g e l , Software Conjiguration Management,
Pr e n t i c e -Ha l l , 19 80.
[BOI2] B o i ko , B. , Content Management Bible, Hu n g r y Mi n d s Pu b l i s hi n g , 2002.
[CH0891 Cho i , S. C y W. Sc a c c hi , "As s u r i n g t he Co r r e c t n e s s o f a Co n f i g u r e d So f t w a r e De s c r i p t i o n ",
Procs. 2nd Intl. Workshop on Software Conguraaon Management, ACM, Pr i n c e t o n , NJ, o c t u b r e d e
1989, p p . 66-75.
TM
PDF Editor
3 2 6 PARTE C U A T R O GESTIN DE PROYECTOS DE SOFTWARE
[CVS02] Co n c u r r e n ! Ve r s i o n s Sys t e m We b s i t e , w w w . c vs ho m e . o r g , 2002.
(DAR9 1] Da r t , S. , "Co n c e p t s i n Co n f i g u r a t i o n Ma n a g e m e n t Sys t e m s ", Proc. Third Inlernalioni
Workshop on Software Configuration Management, ACM SIGSOFT, 19 9 1, s e p u e d e d e s c a r g ; -
d e : ht t p : / / w w w . s e i . c m u . e d u / l e g a c y/ s c m / a b s t r a c t s / a b s c m _c o n c e p t s . ht m l .
(DAR99) Da r t , S "Cha n g e Ma n a g e m e n t : Co n t a i n i n g t he We b Cr i s i s ", Proc. Software Configuranc -
Management Symposium, To u l o u s e , Fr a n c i a , 19 9 9 , d i s p o n i b l e e n ht t p : / / w w w . p e r f o r c e . c o i r
p e r f o r c e / c o n f 9 9 / d a r t . ht m l .
[DAR01] Da r t , S. , Spectrum of Functionality in Configuration Management Systems, So f t w a r e Er -
g i n e e r i n g In s t i t u t e , 2001, d i s p o n i b l e e n ht t p : / / w w w . s e i . c m u . e d u / l e g a c y/ s c m / t e c h_r e p
TR11_9 0/TOC_TRI l _9 0. ht m l .
[DRE99] Dr e i l i n g e r , S. . "CVS Ve r s i n Co n t r o l f o r We b Si t e Pr o j e c t s ", 19 9 9 , d i s p o n i b l e e n
ht t p : / / w w w . d u r a k. o r g / c vs w e b s i t e s / ho w t o - c vs / ho w t o - c vs . ht m l .
[FOR89] Fo r t e , G. , "Ra l l y Ro u n d t he Re p o s i t o r y", e n CASE Outlook, d i c i e m b r e d e 19 89 , p p . 5-27
[GRI95) Gr i f f e n , J "Re p o s i t o r i e s : Da t a Di c t i o n a r y De s c e n d a n t Ca n Ex t e n d L e g a c y Co d e l n ve s t m e n t "
e n Application Development Trends, a b r i l d e 1995, p p . 65-71.
[GUS89 ] Gu s t a vs s o n , A "Ma i n t a i n i n g t he Evo l u t i o n o f So f t w a r e Ob j e c t s i n a n In t e g r a t e c
En vi r o n m e n t ", Proc. 2nd Intl. Workshop on Software Configuration Management, ACM
Pr i n c e t o n , NJ, o c t u b r e d e 19 89 , p p . 114-117.
[HAR89] Ha r t e r , R. , "Co n f i g u r a t i o n Ma n a g e m e n t ", e n HPProfessional, vo l . 3, n m . 6, j u n i o d e 1989.
|1EE94] Software Engineering Standards, e d i c i n 19 9 4, IEEE Co m p u t e r So c i e t y, 19 9 4.
UAC02) J a c o b s o n , I. , "A r e s o u n d i n g 'Ye s ' t o Ag i l e Pr o c e s s e s -B u t Al s o Mo r e ", e n Cutter IT Journal.
vo l . 15, n m . 1, e n e r o d e 2002, p p . 18-24.
[REI89] Re i c he n b e r g e r , C. , "Or t ho g o n a l Ve r s i n Ma n a g e m e n t ", Proc. 2nd Intl. Workshop on
Software Configuration Management, ACM, Pr i n c e t o n , NJ, o c t u b r e d e 19 89 , p p . 137-140.
[SHA95] Sha r o n , D. , y R. Bel l , "To o l s Tha t B i n d : Cr e a t i n g In t e g r a t e d En vi r o n m e n t s ", IEEE
Software, m a r zo d e 19 9 5, p p . 76-85.
[TAY85] Ta yl o r , B. , "A Da t a b a s e Ap p r o a c h t o Co n f i g u r a t i o n Ma n a g e m e n t f o r L a r g e Pr o j e c t s ".
Proc. Conf Software Maintenance-1985, IEEE, n o vi e m b r e d e 19 85, p p . 15-23.
27. 1. Po r qu e s c i e r t a l a p r i m e r a l e y d e l a i n g e n i e r a d e s i s t e m a s ? Of r e c e r e j e m p l o s e s p e c f i c o s
d e c a d a u n a d e l a s c u a t r o r a zo n e s f u n d a m e n t a l e s p a r a e l c a m b i o .
27.2. c u l e s s o n l o s c u a t r o e l e m e n t o s qu e e x i s t e n c u a n d o s e i m p l e m e n t a u n s i s t e m a e f i c a z
d e GCS? Co m e n t a r c a d a u n o b r e ve m e n t e .
27. 3. Co n p a l a b r a s p r o p i a s , c o m n t e n s e l a s r a zo n e s p a r a l a s l i n e a s b a s e .
2 7 . 4 . Su p o n g a qu e u s t e d e s e l g e s t o r d e u n p e qu e o p r o ye c t o . Qu l n e a s b a s e d e f i n i r a p a r a
el p r o ye c t o y c m o l a s c o n t r o l a r a ?
27. 5. Em p l e a r UML a g r e g a d o s o c o m p u e s t o s (c a p t u l o 8) p a r a d e s c r i b i r l a s i n t e r r e l a c i o n e s e n t r e
l o s ECS (o b j e t o s d e c o n f i g u r a c i n ) e n l a l i s t a d e l a s e c c i n 27. 1. 4.
2 7 . 6 . Di s e a r u n s i s t e m a d e b a s e d e d a t o s (d e p s i t o ) d e p r o ye c t o qu e l e p e r m i t i r a a u n
i n g e n i e r o d e s o f t w a r e a l m a c e n a r , r e a l i za r r e f e r e n c i a s c r u za d a s , r a s t r e a r , a c t u a l i za r y c a m b i a r
t o d o s l o s e l e m e n t o s i m p o r t a n t e s d e c o n f i g u r a c i n d e s o f t w a r e . C m o m a n e j a r a l a b a s e d e
d a t o s l a s d i f e r e n t e s ve r s i o n e s d e l m i s m o p r o g r a m a ? El c d i g o f u e n t e s e m a n e j a r a d e m a n e r a
d i f e r e n t e a l a d o c u m e n t a c i n ? C m o s e e vi t a r a qu e d o s d e s a r r o l l a d o r e s r e a l i za s e n d i f e r e n t e s
c a m b i o s a l m i s m o ECS e n f o r m a s i m u l t n e a ?
2 7 . 7 . In ve s t i g a r u n a he r r a m i e n t a e x i s t e n t e d e GCS y d e s c r i b i r c m o i m p l e m e n t a e l c o n t r o l d e
l a s ve r s i o n e s y l o s o b j e t o s d e c o n f i g u r a c i n e n g e n e r a l .
2 7 . 8 . L a s r e l a c i o n e s <p a r t e d e > e <i n t e r r e l a c i o n a d o > r e p r e s e n t a n r e l a c i o n e s s i m p l e s e n t r e
o b j e t o s d e c o n f i g u r a c i n . De s c r i b i r c i n c o r e l a c i o n e s a d i c i o n a l e s qu e p u e d a n s e r t i l e s e n e l
c o n t e x t o d e u n d e p s i t o d e GCS.
TM
PDF Editor
CAP TULO 2 7 GESTIN DEL CAMBKD
827
2 7 . 9 . In ve s t i g a r u n a he r r a m i e n t a e x i s t e n t e d e GCS y d e s c r i b i r c m o i m p l e m e n t a l o s
m e c a n i s m o s d e c o n t r o l d e ve r s i o n e s De m a n e r a a l t e r n a t i va , l e e r d o s o t r e s d e l o s a r t c u l o s
a c e r c a d e GCS y d e s c r i b i r l a s d i f e r e n t e s e s t r u c t u r a s d e d a t o s y m e c a n i s m o s d e r e f e r e n c i a qu e
s e e m p l e a n p a r a e l c o n t r o l d e l a s ve r s i o n e s
2 7 . 1 0 . Co n l a f ig u r a 27. 5 c o m o g u i a , d e s a r r o l l a r u n a n l i s i s t o d a v a m s d e t a l l a d o p a r a e l
c o n t r o l d e l c a m b i o . De s c r i b i r e l p a p e l d e l a ACC y s u g e r i r f o r m a t o s p a r a l a p e t i c i n d e l c a m b i o ,
e l i n f o r m e d e l c a m b i o y l a OCI.
2 7 . 1 1 . De s a r r o l l a r u n a l i s t a d e ve r i f i c a c i n p a r a e m p l e a r l a d u r a n t e l a s a u d i t o r a s d e l a
c o n f i g u r a c i n .
27. 12. Cu l e s l a d i f e r e n c i a e n t r e u n a a u d i t o r a GCS y u n a r e vi s i n t c n i c a f o r m a l ? Su s f u n c i o n e s
s e p u e d e n j u n t a r e n u n a r e vi s i n ? Cu l e s s o n l o s p r o s y l o s c o n t r a s ?
2 7 . 1 3 . De s c r i b i r b r e ve m e n t e l a s d i f e r e n c i a s e n t r e GCS p a r a e l s o f t w a r e c o n ve n c i o n a l y l a GCS
p a r a We b Ap p s .
27. 14. Qu e s l a g e s t i n d e l c o n t e n i d o ? Em p l e s e l a We b p a r a i n ve s t i g a r l a s c a r a c t e r s t i c a s d e u n a
he r r a m i e n t a d e g e s t i n d e l c o n t e n i d o y o f r zc a s e u n b r e ve r e s u m e n .
L yo n [Practical CM, Ra ve n Pu b l i s hi n g , 2003, d i s p o n i b l e e n w w w . c o n f i g u r a t i o n . o r g ) ha e s c r i t o
u n a g u a d e t a l l a d a p a r a p r o f e s i o n a l e s d e GC qu e i n c l u ye d i r e c t r i c e s p r a g m t i c a s p a r a i m p l e -
m e n t a r c a d a a s p e c t o d e u n s i s t e m a d e g e s t i n d e l a c o n f i g u r a c i n (a c t u a l i za d o a n u a l m e n t e ) .
Ha s s {Conjiguration Management: Principies and Practice, Ad d i s o n -We s l e y, 2002) y L e n [A Guide
to Sojtware Conjiguration Management, Ar t e c h Ho u s e , 2000) o f r e c e n e x m e n e s t i l e s d e l t e m a .
Whi t e y Cl e m m (Sojtware Conjiguration Management Strategies and Rationai CiearCase, Ad d i s o n -
We s l e y, 2000) p r e s e n t a n l a GCS d e n t r o d e l c o n t e x t o d e u n a d e l a s m s p o p u l a r e s he r r a m i e n t a s
d e GCS.
Mi kke l s e n y Phe r i g o (Practical Sojtware Conjiguration Management: The Latenight Developer's
Handbook, Al l yn & B a c o n , 1997) y Co m p t o n y Ca l l a ha n (Conjiguration Management for
Sojtware, Va n No s t r a n d -Re i n ho l d , 1994) o f r e c e n g u i a s p r a g m t i c a s a c e r c a d e i m p o r t a n t e s
p r c t i c a s d e GCS. B e n -Me n a c he m (Sojtware Configuration Management Guidebook, Mc Gr a w -
Hil l , 1994) y Aye r y Pa t r i n n o s t r o (Sojtware Conjiguration Management, Mc Gr a w -Hi l l , 1992)
p r e s e n t a n b u e n o s p a n o r a m a s p a r a qu i e n e s n e c e s i t a n m a yo r i n t r o d u c c i n a l a m a t e r i a . B e r l a c k
(Sojtware Conjiguration Management, Wi l ey, 1992) p r e s e n t a u n e x a m e n t i l d e c o n c e p t o s d e
GCS, d o n d e r e s a l t a l a i m p o r t a n c i a d e l d e p s i t o y l a s he r r a m i e n t a s e n l a g e s t i n d e l c a m b i o .
B a b i c h (BAB86) p r o p o r c i o n a u n t r a t a m i e n t o a b r e vi a d o , a u n qu e e f i c a z, d e t e m a s p r a g m t i c o s
e n l a g e s t i n d e c o n f i g u r a c i n d e l s o f t w a r e . Ar n o l d y B o hn e r (Sojtware Change impact Analysis,
IEEE Co m p u t e r So c i e t y Pr e s s , 1996) ha n e d i t a d o u n a a n t o l o g a qu e e s t u d i a c m o a n a l i za r e l
i m p a c t o d e l c a m b i o a l i n t e r i o r d e s i s t e m a s c o m p l e j o s b a s a d o s e n s o f t w a r e .
B e r c zu k y Ap p l e t o n (Sojtware Conjiguration Management Patterns, Ad d i s o n -We s l e y, 2002)
p r e s e n t a n u n a d i ve r s i d a d d e p a t r o n e s t i l e s qu e a u x i l i a n e n l a c o m p r e n s i n d e l a GCS y l a
i m p l e m e n t a c i n d e s i s t e m a s d e GCS e f i c a c e s . B r o w n et al. (Anti-Pattems and Patterns in
Sojtware Conjiguration Management, Wi l e y, 1999) e s t u d i a n l a s c o s a s qu e n o s e ha c e n (a n t i p a -
t r o n e s ) c u a n d o s e i m p l e m e n t a u n p r o c e s o d e GCS y l u e g o c o n s i d e r a n s u s r e m e d i o s .
B u c kl e y (Implementing Conjiguration Management, IEEE Co m p u t e r So c i e t y Pr e s s , 19 9 3)
c o n s i d e r a e n f o qu e s d e g e s t i n d e l a c o n f i g u r a c i n p a r a t o d o s l o s e l e m e n t o s d e l s i s t e m a
ha r d w a r e , s o f t w a r e y f ir m w ar e c o n e s t u d i o s d e t a l l a d o s d e l a s p r i n c i p a l e s a c t i vi d a d e s d e
GC. Ra w l i n g s (SCM for Network Development Environments, Mc Gr a w -Hi l l , 1994) c o n s i d e r a e l
i m p a c t o d e l a GCS p a r a d e s a r r o l l o d e s o f t w a r e e n u n e n t o r n o d e r e d . B a ys (Sojtware Release
Methodology, Pr e n t i c e -Ha l l , 1999) p r e s e n t a u n a c o l e c c i n d e m e j o r e s p r c t i c a s p a r a t o d a s l a s
a c t i vi d a d e s qu e o c u r r e n d e s p u s d e qu e s e r e a l za n c a m b i o s e n u n a a p l i c a c i n .
Co n f o r m e l a s We b Ap p s s e vu e l ve n m s d m m i c a s . l a g e s t i n d e l c o n t e n i d o s e vu e l ve u n
t p i c o e s e n c i a l p a r a l o s i n g e n i e r o s We b L o s l i b r o s d e Ad d e y y s u s c o l e g a s (Conten Manage-
TM
PDF Editor
828 PARTE C U A T R O GESTIN DE PROYECTOS DE SOFTWARE
ment Systems, Gl a s s ha u s , 2003) , B o i ko [B0102], Ha c ko s (Conten Managementfor Dynamic l'.f c i-
Delivery, Wi l e y, 2002) , Na ka n o (Web Content Management, Ad d i s o n -We s l e y, 2001) p r e s e n t a r ,
va l i o s o s t r a t a m i e n t o s d e l a m a t e r i a .
En In t e r n e t ha y d i s p o n i b l e u n a a m p l i a va r i e d a d d e f u e n t e s d e i n f o r m a c i n a c e r c a d e l a
g e s t i n d e c o n f i g u r a c i n d e l s o f t w a r e . Un a l i s t a a c t u a l i za d a d e r e f e r e n c i a s e n l a Wo r l d Wi c ;
We b s e p u e d e e n c o n t r a r e n e l s i t i o We b SEPA:
h t t p : / / w w w . m h h e . c o m / p r e s s m a n .
TM
PDF Editor
A
Cinco
TEMAS AVANZADOS EN
INGENIER A DEL SOFTWARE
E
n e s t a p a r t e d e Ingeniera del software. Un enfoque prctico
s e c o n s i d e r a n va r i o s t e m a s a va n za d o s qu e a m p l i a r n l a
c o m p r e n s i n d e l l e c t o r a c e r c a d e l a i n g e n i e r a d e l s o f t w a r e .
En l o s s i g u i e n t e s c a p t u l o s s e a b o r d a r n l a s s i g u i e n t e s p r e g u n t a s :
Qu n o t a c i n y p r e l i m i n a r e s m a t e m t i c o s ("m t o d o s f o r -
m a l e s ") s e r e qu i e r e n p a r a e s p e c i f i c a r f o r m a l m e n t e e l s o f t -
w a r e ?
Qu a c t i vi d a d e s t c n i c a s c l a ve s e l l e va n a c a b o d u r a n t e e l
p r o c e s o d e i n g e n i e r a d e l s o f t w a r e d e s a l a l i m p i a ?
C m o s e e m p l e a l a i n g e n i e r a d e l s o f t w a r e b a s a d a e n c o m -
p o n e n t e s p a r a c r e a r s i s t e m a s a p a r t i r d e c o m p o n e n t e s r e u t i -
l i za b l e s ?
Qu a c t i vi d a d e s t c n i c a s s e r e qu i e r e n p a r a l a r e i n g e n i e r a
d e l s o f t w a r e ?
Cu l e s s o n l a s t e n d e n c i a s f u t u r a s d e l a i n g e n i e r a d e l s o f t -
w a r e ?
Un a ve z qu e s e r e s p o n d a n e s t a s p r e g u n t a s , s e e n t e n d e r n l o s
t e m a s qu e t i e n e n l a p o s i b i l i d a d d e t e n e r u n p r o f u n d o i m p a c t o
s o b r e l a i n g e n i e r a d e l s o f t w a r e d u r a n t e l a d c a d a s i g u i e n t e .
829
TM
PDF Editor
C A P I T U L O
28
m m m m m
C O N C E P T O S
CLAVE
especificociii
constructiva . . . 8 3 7
especificacin
formal . 8 4 2
es quemas 8 4 9
e s t adas 8 3 4
i nvari ante
de dol os 8 3 5
lenguaje Z . . . . 8 4 9
OCl 8 4 S
operaci ones . . . 8 3 4
operadores de
conjuntos 8 3 8
operadores
lgicos 8 4 0
p r e y
p o sto n d ic io n es . 835
MTODOS
FORMAL ES
L
o s m t o d o s d e l a i n g e n i e r a d e l s o f t w a r e s e p u e d e n c l a s i f i c a r s o b r e u n e s -
p e c t r o d e "f o r m a l i d a d " l i g e r a m e n t e vi n c u l a d o c o n el g r a d o d e r i g o r m a t e -
m t i c o a p l i c a d o d u r a n t e el a n l i s i s y el d i s e o . Po r e s t a r a z n , l o s m t o d o s
d e a n l i s i s y d i s e o e s t u d i a d o s p r e vi a m e n t e e n e s t e l i b r o s e u b i c a n e n el e x t r e -
m o i n f o r m a l d e l e s p e c t r o . En l a c r e a c i n d e m o d e l o s d e a n l i s i s y d i s e o s e u ti-
l i za n c o m b i n a c i o n e s d e d i a g r a m a s , t e x t o , t a b l a s y n o t a c i n s i m p l e , p e r o s e ha
a p l i c a d o p o c o r i g o r m a t e m t i c o .
Co n s i d r e s e a ho r a el o t r o e x t r e m o d e l e s p e c t r o d e f o r m a l i d a d . Aqu , u n a e s -
p e c i f i c a c i n y d i s e o s e d e s c r i b e n e m p l e a n d o s i n t a x i s y s e m n t i c a s f o r m a l e s
qu e e s p e c i f i c a n l a f u n c i n y el c o m p o r t a m i e n t o d e l s i s t e m a . L a e s p e c i f i c a c i n e s
m a t e m t i c a e n f o r m a (p o r e j e m p l o , el c l c u l o d e p r e d i c a d o s s e u t i l i za c o m o b a -
s e p a r a u n l e n g u a j e f o r m a l d e e s p e c i f i c a c i n ) .
En s u e s t u d i o i n t r o d u c t o r i o d e l o s m t o d o s f o r m a l e s , An t ho n y Hal l [HAL 90]
a f i r m a ;
L o s m t o d o s f o r m a l e s s o n c o n t r o ve r t i d o s . Su s p a r t i d a r i o s a f i r m a n qu e p u e d e n r e vo -
l u c i o n a r e l d e s a r r o l l o [d el s o f t w a r e ) . Su s d e t r a c t o r e s p i e n s a n qu e s o n i n c r e b l e m e n -
t e d i f c i l e s . Mi e n t r a s t a n t o , p a r a l a m a yo r a d e l a g e n t e , l o s m t o d o s f o r m a l e s s o n t a n
p o c o f a m i l i a r e s qu e e s d if c il j u zg a r l a s a f i r m a c i o n e s e n c o m p e t e n c i a .
En e s t e c a p t u l o s e e x p l o r a n l o s m t o d o s f o r m a l e s y s e e x a m i n a n s u s p o t e n
c a l e s i m p a c t o s s o b r e l a i n g e n i e r a d el s o f t w a r e e n l o s a o s p o r ve n i r .
Qu e s ? L os m to d o s f o r m al es
p er m iten qu e u n i n g en i er o d e so f tw a-
r e c r ee u n a esp ec if ic ac i n m s c o m -
p l eta, c o n sisten te y p r ec i sa qu e l as
qu e se p r o d u c en e m p l e a n d o m to d o s
c o n ven c io n al es. Se u til izan ta n o tac i n d e teo r a
d e c o n j u n to s y l g ic a p a r a c r e a r u n c l ar o p l an -
t eam i en t o d e hec ho s (r equ isito s) . Esta esp ec if ic a-
c i n m atem tic a l u eg o se a n a l i za p a r a m ej o r ar
o in c l u so p r o b a r ) su c o r r ec c i n y c o n sisten c ia.
Pu esto qu e l a esp ec if ic ac i n se c r e a m ed i an t e
n o tac i n m atem tic a, es in her en tem en te m en o s
am b ig u o qu e los m o d o s in f o r m ales d e r ep r esen tac i n .
Qu i n l o ha c e ? Un in g en ier o d e so f t w ar e esp e-
c ial m en te e n t r e n a d o c r ea u n a esp ec if ic ac i n f o r -
m al .
Po r q u e s i m p o r t a n t e ? En l o s sistem as d e
seg u r i d ad o d e m isi n c r tic as, l as f al l as tien en
u n p r ec io el evad o . Cu a n d o el so f t w ar e d e c o m -
p u t a d o r a f al l a e s p o sib l e qu e se p i e r d a n vi d as o
s u r j an g r a ve s c o n sec u en c ias ec o n m ic as. En
tal es situ ac io n es e s esen c ial qu e l o s e r r o r e s sean
d esc u b ier to s an t es d e qu e el so f tw ar e sea p u es-
t o en o p e r a c i n . L os m to d o s f o r m al es r ed u c en
su stan c ial m en te l o s e r r o r e s d e esp ec if ic ac i n y,
c o m o c o n sec u en c i a, sir ven c o m o b a s e p a r a qu e
el so f t w ar e en g a t an p o c o s e r r o r e s u n a vez qu e
el c l ien te c o m ien c e a u sar l o .
Cu l e s s o n l o s p a s o s ? La n o tac i n y heu r sti-
c a d e c o n j u n to s y l a esp ec if ic ac i n c o n str u c tiva
o p er ad o r es d e c o n j u n to s, o p e r a d o r e s l g ic o s
y sec u en c ias f o r m an l a b a s e d e l o s m to d o s
f o r m al es. sto s d ef in en l o s d at o s in var ian tes,
estad o s y o p e r a c i o n e s p a r a l a f u n c i n d e u n sis-
tem a al tr ad u c ir l o s r equ isito s f o r m al es d el p r o -
b l em a en u n a r ep r esen t ac i n m s f o r m al .
TM
PDF Editor
CAP TULO 2 8 MTODOS FORMAL ES 831
Cu l e s e l p r o d u c t o o b t e n i d o ? Cu a n d o s e
a p l i c a n l o s m t o d o s f o r m a l e s se p r o d u c e u n a
e s p e c i f i c a c i n r e p r e s e n t a d a e n u n l e n g u a j e f o r -
m a l c o m o OCL o Z.
C m o p u e d o e s t a r s e g u r o d e q u e l o he
he c ho c o r r e c t a m e n t e ? Pu est o qu e l o s m to -
d o s f o r m a l e s u t i l i zan m a t e m t i c a s d i s c r e t a s
c o m o m e c a n i s m o d e e s p e c i f i c a c i n , se a p l i c a n
p r u e b a s l g i c a s a c a d a f u n c i n d e l s i s t e m a p a r a
d e m o s t r a r qu e l a e s p e c i f i c a c i n e s c o r r e c t a . Sin
e m b a r g o , in c l u so si n o se a p l i c a n l as p r u e b a s
l g i c a s , l a e s t r u c t u r a y d i s c i p l i n a d e u n a e s p e c i -
f i c a c i n f o r m a l c o n d u c i r n a u n a c a l i d a d d e
s o f t w a r e m e j o r a d a .
2 8 . 1 C o n c e p t o s B SI COS
L a Encyclopedia of Sojtware Engineering (MAR94] d e f i n e a s l o s m t o d o s f o r m a l e s :
Un m t o d o e s f o r m a l si t i e n e s l i d a s b a s e s m a t e m t i c a s , u s u a l m e n t e p r o p o r c i o n a d a s p o r
u n l e n g u a j e f o r m a l d e e s p e c i f i c a c i n . Esta b a s e o f r e c e l o s m e d i o s d e d ef i n i r c o n p r ec i s i n
n o c i o n e s c o m o c o n s i s t e n c i a y c o m p l e t u d , y, c o n m s r e l e va n c i a , e s p e c i f i c a c i n , i m p l e-
m e n t a c i n y c o r r e c c i n .
L a s p r o p i e d a d e s d e s e a d a s d e u n a e s p e c i f i c a c i n f o r m a l (c o n s i s t e n c i a , i n t e g r i d a d
y f a l t a d e a m b i g e d a d ) s o n l o s o b j e t i vo s d e t o d o s l o s m t o d o s d e e s p e c i f i c a c i n . Si n
e m b a r g o , e m p l e a r m t o d o s f o r m a l e s r e s u l t a e n u n a p r o b a b i l i d a d m u c ho m a yo r d e
l o g r a r d i c ho s i d e a l e s . L a s i n t a x i s d e u n l e n g u a j e f o r m a l d e e s p e c i f i c a c i n (s e c c i n
28. 4) p e r m i t e qu e l o s r e qu i s i t o s y e l d i s e o s e i n t e r p r e t e n s l o e n u n a f o r m a , l o qu e
e l i m i n a l a a m b i g e d a d qu e c o n f r e c u e n c i a o c u r r e c u a n d o u n l e n g u a j e n a t u r a l (p o r
e j e m p l o , i n g l s ) o u n a n o t a c i n g r f i c a d e b e i n t e r p r e t a r l o s u n l e c t o r . L a s f a c i l i d a d e s
d e s c r i p t i va s d e l a t e o r a d e c o n j u n t o s y l a n o t a c i n l g i c a (s e c c i n 28. 2) p e r m i t e n u n
p l a n t e a m i e n t o c l a r o d e l o s he c ho s (r e qu i s i t o s ) . Pa r a s e r c o n s i s t e n t e , l o s he c ho s p l a n -
t e a d o s e n u n l u g a r e n u n a e s p e c i f i c a c i n n o d e b e n c o n t r a d e c i r s e e n o t r o s i t i o . L a
c o n s i s t e n c i a s e g a r a n t i za p r o b a n d o m a t e m t i c a m e n t e qu e l o s he c ho s i n i c i a l e s p u e -
d e n c o r r e l a c i o n a r s e d e m a n e r a f o r m a l (e m p l e a n d o r e g l a s d e i n f e r e n c i a ) e n p l a n t e a -
m i e n t o s p o s t e r i o r e s d e n t r o d e l a e s p e c i f i c a c i n .
"L o s m t o d o s f o r m a l e s t i e n e n u n e n o r m e p o t e n c i a l p o r a m e j o r a r l a c l a r i d a d y l a p r e c i s i n d e f as e s p e c i f i c a c i o n e s d e
r e qu i s i t o s y p a r o e n c o n t r a r l o s e r r o r e s i m p o r t a n t e s y s u t i l e s . "
St e ve Ea s t e r b r o o k el al.
L a c o m p l e t u d e s d i f c i l d e l o g r a r , a u n c u a n d o s e a p l i qu e n l o s m t o d o s f o r m a l e s .
Al g u n o s a s p e c t o s d e u n s i s t e m a t a l ve z qu e d e n i n d e f i n i d o s m i e n t r a s s e c r e a l a e s p e -
c i f i c a c i n ; o t r a s c a r a c t e r s t i c a s qu i z s e o m i t a n a p r o p s i t o p a r a p e r m i t i r qu e l o s d i -
s e a d o r e s t e n g a n c i e r t a l i b e r t a d d e e l e c c i n e n e l e n f o qu e d e i m p l e m e n t a c i n ; y,
f in al m en te, e s i m p o s i b l e c o n s i d e r a r c a d a e s c e n a r i o o p e r a t i vo e n u n g r a n s i s t e m a
c o m p l e j o . L a s c o s a s t a l ve z s e o m i t a n p o r e r r o r
Au n qu e e l f o r m a l i s m o qu e o f r e c e n l a s m a t e m t i c a s e s a t r a c t i vo p a r a a l g u n o s i n -
g e n i e r o s d e s o f t w a r e , o t r o s (a l g u n o s d i n a n l a m a yo r a ) m i r a n d e s p e c t i va m e n t e l a vi -
TM
PDF Editor
832 PAUTE C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
^ CONSEJ O^
Aunque un buen
Indice de documento
no puede eliminar los
contradicciones, s
puede ayudar o descu-
bridos. Consid rese lo
creacin de un ndice
poro los especifica-
ciones y otros docu-
mentos.
s i n m a t e m t i c a d e l d e s a r r o l l o d e l s o f t w a r e . Co m p r e n d e r p o r qu u n e n f o qu e f o r n - ai
t i e n e s u m r i t o r e qu i e r e , p r i m e r o , c o n s i d e r a r l a s d e f i c i e n c i a s a s o c i a d a s c o n l o s e -
f o qu e s m e n o s f o r m a l e s .
28.1.1 Deficiencias de los enfoques menos formales1
L o s m t o d o s e s t u d i a d o s p a r a e l a n l i s i s y el d i s e o e n l a s p a r t e s 2 y 3 d e e s e l i b r :
e m p l e a n a m p l i a m e n t e e l l e n g u a j e n a t u r a l y u n a e x t e n s a g a m a d e n o t a c i o n e s g r ar "
c a s . Au n qu e l a a p l i c a c i n c u i d a d o s a d e l o s m t o d o s d e a n l i s i s y d i s e o , e n c o n j u r -
t o c o n r e vi s i o n e s e x ha u s t i va s , p u e d e c o n d u c i r y d e he c ho c o n d u c e a s o f t w a r e d e a l : i
c a l i d a d , e l d e s c u i d o e n l a a p l i c a c i n d e e s t o s m t o d o s c r e a u n a d i ve r s i d a d d e p r c
b l e m a s . Un a e s p e c i f i c a c i n d e s i s t e m a p u e d e c o n t e n e r c o n t r a d i c c i o n e s , a m b i g e c a
d e s , va g u e d a d e s , p l a n t e a m i e n t o s i n c o m p l e t o s y g r a d o s m i x t o s d e a b s t r a c c i n .
L a s contradicciones s o n c o n j u n t o s d e p l a n t e a m i e n t o s qu e d i ve r g e n u n o s c o r
o t r o s . Po r e j e m p l o , p a r t e d e u n a e s p e c i f i c a c i n d e s i s t e m a p u e d e a f i r m a r qu e el s i s -
t e m a d e b e s u p e r vi s a r t o d a s l a s t e m p e r a t u r a s e n u n r e a c t o r qu m i c o , m i e n t r a s qu e
o t r a p a r t e , qu e t a l ve z e s c r i b i o t r a p e r s o n a , p u e d e a f i r m a r qu e s l o d e b e n s u p e r vi -
s a r s e l a s t e m p e r a t u r a s qu e o c u r r a n d e n t r o d e c i e r t o i n t e r va l o .
L a s ambigedades s o n p l a n t e a m i e n t o s qu e s e i n t e r p r e t a n e n va r i a s f o r m a s . Po r
e j e m p l o , e l s i g u i e n t e p l a n t e a m i e n t o e s a m b i g u o :
L a i d e n t i d a d d el o p e r a d o r c o n s i s t e d e s u n o m b r e y l a c o n t r a s e a ; s t a c o n s i s t e d e s e i s d -
g ito s. Se d e b e m o s t r a r e n l a UDV d e s e g u r i d a d y d e p o s i t a r s e en el a r c hi vo d e r e g i s t r o c u a n -
d o u n o p e r a d o r s e r eg i st r e en el s i s t e m a .
En e s t e f r a g m e n t o , se debe mostrar s e r e f i e r e a l a c o n t r a s e a o a l a i d e n t i d a d d e !
o p e r a d o r ?
L a s vaguedades c o n f r e c u e n c i a o c u r r e n p o r qu e l a e s p e c i f i c a c i n d e u n s i s t e m a e s
u n d o c u m e n t o m u y vo l u m i n o s o . L o g r a r u n e l e va d o g r a d o d e p r e c i s i n c o n s i s t e n t e -
m e n t e e s u n a t a r e a c a s i i m p o s i b l e .
"Co m e t e r e r r o r e s e s hu m a n o . Re p e t i r l o s , t a m b i n . '
Ma l c o l m F o r b e s
L a incompletud e s u n o d e l o s p r o b l e m a s qu e o c u r r e n c o n m a yo r f r e c u e n c i a c o n
l a s e s p e c i f i c a c i o n e s d e l s i s t e m a . Po r e j e m p l o , c o n s i d r e s e e l r e qu i s i t o f u n c i o n a l :
El s i s t e m a d e b e c o n s e r va r el n ivel ho r a r i o d el d e p s i t o a p ar t i r d e l o s s e n s o r e s p r o f u n d o s
s i t u a d o s e n el d e p s i t o . Dic ho s va l o r e s d e b e n a l m a c e n a r s e r e s p e c t o d e l o s s e i s m e s e s a n -
t e r i o r e s .
Es t o d e s c r i b e l a p a r t e p r i n c i p a l d e l a l m a c e n a m i e n t o d e d a t o s d e u n s i s t e m a . Si u n o
d e l o s c o m a n d o s p a r a e l s i s t e m a f u e s e :
1 Esta sec c i n y o t r as en la p r im er a p ar te d e este c ap tu l o se han ad ap t ad o d el tr ab aj o d e Dar r el In c e
p ar a la ed ic i n eu r o p ea d e l a qu in ta ed ic i n d e Ingeniera del software. Un enfoque prctico.
TM
PDF Editor
C A P I T U L O 2 8 MTODOS FORMAL ES 833
^ O N S E J ^
i o s revisiones t cnicos
(rnales eficaces
yueden eliminar
muchos de estos
problemas. Sin
embargo, algunos no
sern descubiertos.
Debe estarse alerta de
las deficiencias
uronte el diseo, lo
:odificacin y la
puesta a prueba.
L a f u n c i n d el c o m a n d o P R OME D I O e s d e s p l e g a r e n u n a PC el n ivel d e a g u a p r o m e d i o p a -
r a u n s e n s o r p a r t i c u l a r e n t r e d o s t i e m p o s .
y s i s u p o n e qu e n o s e p r e s e n t a n m s d e t a l l e s p a r a e s t e c o m a n d o , l o s d e t a l l e s d e l c o -
m a n d o e s t a r a n s e r i a m e n t e i n c o m p l e t o s . Po r e j e m p l o , l a d e s c r i p c i n d e l c o m a n d o
n o i n c l u ye l o qu e d e b e r a o c u r r i r si u n u s u a r i o d e u n s i s t e m a e s p e c i f i c a u n t i e m p o
qu e f u e s e m a yo r a s e i s m e s e s a n t e s d e l a ho r a a c t u a l .
L o s grados mixtos de abstraccin o c u r r e n c u a n d o p l a n t e a m i e n t o s m u y a b s t r a c t o s
s e m e zc l a n a l a za r c o n p l a n t e a m i e n t o s qu e t i e n e n u n g r a d o m u c ho m e n o r d e d e t a -
l l e . Au n qu e a m b o s t i p o s d e p l a n t e a m i e n t o s s o n i m p o r t a n t e s e n l a e s p e c i f i c a c i n d e
u n s i s t e m a , qu i e n e s l a r e a l i za n c o n f r e c u e n c i a m a n e j a n l a m e zc l a e n t a l f o r m a qu e
r e s u l t a m u y d i f c i l ve r l a a r qu i t e c t u r a f u n c i o n a l g l o b a l d e u n s i s t e m a .
28.1.2 Matemticas en el desarrollo de software
L a s m a t e m t i c a s t i e n e n m u c ha s p r o p i e d a d e s t i l e s p a r a l o s d e s a r r o l a d o r e s d e g r a n d e s
s i s t e m a s . Un a e s qu e s e p u e d e d e s c r i b i r s u c i n t a y e x a c t a m e n t e u n a s i t u a c i n f s i c a ,
u n o b j e t o o e l r e s u l t a d o d e u n a a c c i n . Es p o s i b l e d e s a r r o l l a r u n a e s p e c i f i c a c i n d e
u n s i s t e m a b a s a d o e n c o m p u t a d o r a e m p l e a n d o m a t e m t i c a s e s p e c i a l i za d a s , e n f o r -
m a m u y s i m i l a r a l a qu e u n i n g e n i e r o e l c t r i c o a p l i c a l a s m a t e m t i c a s p a r a d e s c r i b i r
u n c i r c u i t o . 2
L a s m a t e m t i c a s s u s t e n t a n l a a b s t r a c c i n y p o r e n d e s o n u n e x c e l e n t e m e d i o p a
r a e l m o d e l a d o . Pu e s t o qu e s e t r a t a d e u n m e d i o e x a c t o , e x i s t e p o c a p o s i b i l i d a d d e
a m b i g e d a d . L a s e s p e c i f i c a c i o n e s p u e d e n va l i d a r s e m a t e m t i c a m e n t e p a r a c o n t r a -
d i c c i o n e s e i n c o m p l e t u d e s , y s e p u e d e n e l i m i n a r l a s va g u e d a d e s . Ad e m s , l a s m a t e -
m t i c a s s e e m p l e a n p a r a r e p r e s e n t a r , e n u n a f o r m a o r g a n i za d a , g r a d o s d e a b s t r a c c i n
e n l a e s p e c i f i c a c i n d e u n s i s t e m a .
Fi n a l m e n t e , l a s m a t e m t i c a s o f r e c e n u n a l t o g r a d o d e va l i d a c i n a l e m p l e a r l a s
c o m o u n m e d i o d e d e s a r r o l l o d e s o f t w a r e . Es p o s i b l e a p l i c a r u n a p r u e b a m a t e m t i -
c a p a r a d e m o s t r a r qu e u n d i s e o e n c a j a e n u n a e s p e c i f i c a c i n y qu e e l c d i g o d e l
p r o g r a m a e s u n r e f l e j o c o r r e c t o d e u n d i s e o .
28.1.3 Conceptos de mtodos formales
L a m e t a d e e s t a s e c c i n e s p r e s e n t a r l o s p r i n c i p a l e s c o n c e p t o s i n vo l u c r a d o s e n l a e s -
p e c i f i c a c i n m a t e m t i c a d e l o s s i s t e m a s d e s o f t w a r e , s i n a t i b o r r a r a l l e c t o r c o n d e m a -
s i a d o s d e t a l l e s m a t e m t i c o s . Es t o s e l o g r a e m p l e a d o u n o s c u a n t o s e j e m p l o s s i m p l e s .
Ej empl o 1: una tabl a de s mbol os . Un p r o g r a m a s e e m p l e a p a r a m a n t e n e r u n a
t a b l a d e s m b o l o s , l a c u a l s e u t i l i za f r e c u e n t e m e n t e e n d i f e r e n t e s t i p o s d e a p l i c a c i o -
2 En este m o m en to es ad ec u ad a u n a ad ver ten c ia. L as esp ec if ic ac io n es d el sistem a m atem tic o qu e
se p r esen tan en e s t e c ap itu l o n o so n tan su c in tas c o m o u n a esp ec if ic ac i n m atem tic a p ar a u n c ir -
c u ito sim p l e. L o s sistem as d e so f tw ar e s o r - Mo n am en te c o m p l ej o s y ser ia ir r eal esp er ar qu e se p o -
d r an esp ec if ic ar en u n a l in ea d e m at er - a!
TM
PDF Editor
8 3 4 PARTE CI NCO TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
<s>;
%
cfovE
Un i n va r i a n t e d e d a t o s
e s u n c o n j u n t o d e
c o n d i c i o n e s ve r d a d e r a s
e j e c u c i n d el s i s t e m o
qu e c o n t i e n e u n a
c o l ec c i n d e d a t o s .
^ O N S I J O ^ .
Otra forma de
observo/ la nocin de
estado es decir que
los datos determinan
el estado. Esto es, se
pueden examinarlos
datos para ver en qu
estado est el
sistema.
n e s . Co n s i s t e d e u n a c o l e c c i n d e e l e m e n t o s s i n d u p l i c a c i n a l g u n a . En l a f i g u r a 28. 1
s e m u e s t r a u n e j e m p l o d e u n a t a b l a d e s m b o l o s c o m n . En e l l a s e r e p r e s e n t a l a t a -
b l a qu e u t i l i za u n s i s t e m a o p e r a t i vo p a r a r e t e n e r l o s n o m b r e s d e l o s u s u a r i o s d e l s i s -
t e m a . Ot r o s e j e m p l o s d e t a b l a s i n c l u ye n l a c o l e c c i n d e n o m b r e s d e l p e r s o n a l d e u r
s i s t e m a d e n m i n a o l a c o l e c c i n d e l o s n o m b r e s d e c o m p u t a d o r a s e n u n s i s t e m a d e
c o m u n i c a c i o n e s e n r e d .
Su p n g a s e qu e l a t a b l a p r e s e n t a d a e n e s t e e j e m p l o c o n s i s t e d e n o m s d e Maxlds
m i e m b r o s d e p e r s o n a l . Es t e p l a n t e a m i e n t o , qu e c o l o c a u n a r e s t r i c c i n e n l a t a b l a , e s
u n c o m p o n e n t e d e u n a c o n d i c i n c o n o c i d a c o m o invariante de datos, u n a i m p o r t a n -
t e i d e a qu e s e r e t o m a r a l o l a r g o d e e s t e c a p t u l o .
Un i n va r i a n t e d e d a t o s e s u n a c o n d i c i n ve r d a d e r a a l o l a r g o d e l a e j e c u c i n d e .
s i s t e m a qu e c o n t i e n e u n a c o l e c c i n d e d a t o s . L a i n va r i a n t e d e d a t o s qu e s e m a n t i e -
n e p a r a l a t a b l a d e s m b o l o s a p e n a s e s t u d i a d a t i e n e d o s c o m p o n e n t e s : 1) qu e l a t a -
b l a c o n t e n d r n o m s d e Maxlds n o m b r e s y 2) qu e n o ha b r n o m b r e s d u p l i c a d o s e r
l a t a b l a . En e l c a s o d e l p r o g r a m a d e t a b l a d e s m b o l o s , e s t o s i g n i f i c a qu e n o i m p o r -
t a c u n d o s e e x a m i n e l a t a b l a d u r a n t e l a e j e c u c i n d e l s i s t e m a , s i e m p r e c o n t e n d r
n o m s d e Maxlds i d e n t i f i c a d o r e s d e p e r s o n a l y n o i n c l u i r d u p l i c a d o s .
Ot r o c o n c e p t o i m p o r t a n t e e s el d e estado. Mu c ho s l e n g u a j e s f o r m a l e s , c o m o OCL
(s e c c i n 28. 5) , u t i l i za n l a n o c i n d e e s t a d o c o m o s e l e e s t u d i e n l o s c a p t u l o s 7 y 8
e s d e c i r : u n s i s t e m a p u e d e e s t a r e n u n o d e va r i o s e s t a d o s , y c a d a u n o d e e l l o s r e p r e -
s e n t a u n m o d o d e c o m p o r t a m i e n t o o b s e r va b l e e x t e r n a m e n t e . Si n e m b a r g o , u n a d e -
f in ic i n d i f e r e n t e p a r a e l t r m i n o estado s e u t i l i za e n e l l e n g u a j e Z (s e c c i n 28. 6) . Er .
z (y e n l e n g u a j e s r e l a c i o n a d o s ) , e l e s t a d o d e u n s i s t e m a s e r e p r e s e n t a m e d i a n t e l o s
d a t o s a l m a c e n a d o s d e l s i s t e m a (p o r t a n t o , Z s u g i e r e u n n m e r o m u c ho m a yo r d e e s -
t a d o s , qu e r e p r e s e n t a n c a d a p o s i b l e c o n f i g u r a c i n d e l o s d a t o s ) . Al e m p l e a r l a l t i -
m a d e f i n i c i n e n e l e j e m p l o d e l p r o g r a m a d e t a b l a d e s m b o l o s , e l e s t a d o e s l a t a b l a
d e s m b o l o s .
El c o n c e p t o f in al e s e l d e operacin. s t a e s u n a a c c i n qu e o c u r r e d e n t r o d e u n
s i s t e m a y l e e o e s c r i b e d a t o s . Si e l p r o g r a m a d e t a b l a d e s m b o l o s e s t p r e o c u p a d o
Ta b l a d e
s m b o l o s .
Max l d s = 10
1. Wil so n
2, Sim p so n
3. Ab el
4. Fer n an d ez
5.
6.
7.
8.
9 .
1 0 .
TM
PDF Editor
CAPTULO 28 MTODOS FORMAL ES
835
^ O N S E J ^
_3 t cnicas de lluvia
ideas pueden
\ ncmar bien cuando
e ebe desarrollar un
'wriante de datos
; aa una funcin rozo-
:tkmente compleja,
lado miembro del
equipo de software
~ ene que escribir los
mites, restricciones y
imitaciones para lo
ijncin y luego combi-
-ryfos y editarlas.
p o r a a d i r y r e m o ve r n o m b r e s d e p e r s o n a l d e l a t a b l a d e s m b o l o s , e n t o n c e s e s t a r
a s o c i a d o c o n d o s o p e r a c i o n e s : u n a p a r a aadir u n n o m b r e e s p e c f i c o a l a t a b l a d e
s m b o l o s , y u n a p a r a eliminar u n n o m b r e e x i s t e n t e d e l a t a b l a . 4 Si e l p r o g r a m a o f r e -
c e l a c a p a c i d a d d e ve r i f i c a r s i u n n o m b r e e s p e c f i c o e s t e n l a t a b l a , e n t o n c e s ha b r a
u n a o p e r a c i n qu e r e g r e s a r a a l g u n a i n d i c a c i n a c e r c a d e l a p r e s e n c i a d e l n o m b r e
e n l a t a b l a .
Tr e s t i p o s d e c o n d i c i o n e s s e a s o c i a n c o n l a s o p e r a c i o n e s : i n va r i a n t e s , p r e c o n d i -
c i o n e s y p o s c o n d i c i o n e s . Un invariante d e f i n e l o qu e e s t g a r a n t i za d o qu e n o c a m -
b i a r . Po r e j e m p l o , l a t a b l a d e s m b o l o s t i e n e u n i n va r i a n t e qu e e s t a b l e c e qu e e l n -
m e r o d e e l e m e n t o s s i e m p r e s e r m e n o r o i g u a l a Maxlds. Un a precondicin d e f i n e l a s
c i r c u n s t a n c i a s e n l a s cuales es vlida u n a o p e r a c i n p a r t i c u l a r . Po r e j e m p l o , la p r e -
c o n d i c i n p a r a u n a o p e r a c i n qu e a a d e u n n o m b r e a l a t a b l a d e s m b o l o s d e i d e n -
t i f i c a d o r e s d e p e r s o n a l s l o e s vl i d a s i e l n o m b r e n o e s t e n l a t a b l a y t a m b i n si e n
s t a e x i s t e n m e n o s d e Maxlds i d e n t i f i c a d o r e s d e p e r s o n a l . L a poscondicin d e u n a
o p e r a c i n d e f i n e l o qu e e s t g a r a n t i za d o qu e s e r c i e r t o ha s t a c o m p l e t a r u n a o p e -
r a c i n . Es t o l o d e f i n e s u e f e c t o s o b r e l o s d a t o s . En el e j e m p l o d e u n a o p e r a c i n qu e
a a d e u n i d e n t i f i c a d o r a l a t a b l a d e s m b o l o s d e i d e n t i f i c a d o r e s d e p e r s o n a l , l a p o s -
c o n d i c i n e s p e c i f i c a r a m a t e m t i c a m e n t e qu e l a t a b l a ha a u m e n t a d o c o n el n u e vo
i d e n t i f i c a d o r .
Ejempl o 2: un ges t or de bl oques. Un a d e l a s p a r t e s m s i m p o r t a n t e s d e l s i s t e -
m a o p e r a t i vo d e u n a c o m p u t a d o r a e s e l s u b s i s t e m a qu e m a n t i e n e l o s a r c hi vo s qu e
ha ya n c r e a d o l o s u s u a r i o s . Pa r t e d e l s u b s i s t e m a d e a r c hi va d o e s e l gestor de bloques.
L o s a r c hi vo s e n e l a r c hi ve r o e s t n c o m p u e s t o s d e b l o qu e s d e a l m a c e n a m i e n t o qu e
s e m a n t i e n e n e n u n d i s p o s i t i vo d e a l m a c e n a m i e n t o d e a r c hi vo s . Du r a n t e l a o p e r a -
Gest o r d e
b l o qu e s .
Bl o qu es n o u s a d o s
1 3 4 6 9
Bl o qu es u s a d o s
2 5 7 8 10
11 12
Cu a n d o se b o r r a n
l o s ar c hivo s, lo s b l o qu es
Fil a p a r a e n t r a r en l o s b l o qu es n o u s a d o s s e ' ' ê , a n a ' ' ' '
rn i
Ar c hivo #1 Ar c hivo #2 Ar c hivo #3
La c o l a d e b l o qu es c o n tien e b l o qu es p r o ven ien tes d e l o s ar c hivo s b o r r a d o s
3 Se d eb e seal ar qu e aad ir u n n o m b r e -o p u ed e o c u r r ir en el est ad o l l en o , y qu e b o r r ar u n n o m b r e
e s im p o sib l e en el est ad o vac io
TM
PDF Editor
836 PARTE C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
c i n d e l a c o m p u t a d o r a , l o s a r c hi vo s s e c r e a r n y b o r r a r n , l o qu e r e qu i e r e l a a d qu i -
s i c i n y l i b e r a c i n d e b l o qu e s d e a l m a c e n a m i e n t o . El s u b s i s t e m a d e a r c hi va d o l i d i a r
c o n e s t o m a n t e n i e n d o u n d e p s i t o d e b l o qu e s n o u t i l i za d o s (l i b r e s ) y d a r s e g u i -
m i e n t o a l o s b l o qu e s qu e a c t u a l m e n t e e s t n e n u s o . Cu a n d o s e b o r r a u n a r c hi vo , l o s
b l o qu e s l i b e r a d o s n o r m a l m e n t e s e a g r e g a n a u n a f il a d e b l o qu e s qu e e s p e r a n s e r
a g r e g a d o s a l d e p s i t o d e b l o qu e s n o u t i l i za d o s . Es t o s e m u e s t r a e n l a f ig u r a 28. 2. En
e s t a f ig u r a s e m u e s t r a n va r i o s c o m p o n e n t e s : e l d e p s i t o d e b l o qu e s n o u t i l i za d o s ,
l o s b l o qu e s qu e a c t u a l m e n t e c o n s t i t u ye n l o s a r c hi vo s qu e a d m i n i s t r a e l s i s t e m a o p e -
r a t i vo y a qu e l l o s b l o qu e s qu e e s p e r a n a g r e g a r s e a l d e p s i t o . L o s b l o qu e s e n e s p e r a
s e m a n t i e n e n e n u n a f il a, y c a d a e l e m e n t o d e s t a c o n t i e n e u n c o n j u n t o d e b l o qu e s
p r o ve n i e n t e s d e u n a r c hi vo b o r r a d o .
En e s t e s u b s i s t e m a e l e s t a d o e s l a c o l e c c i n d e b l o qu e s l i b r e s , l a c o l e c c i n d e b l o -
qu e s u t i l i za d o s y l a f il a d e b l o qu e s d e vu e l t o s . El i n va r i a n t e d e d a t o s , e x p r e s a d o e n
l e n g u a j e n a t u r a l , e s :
Ni n g n b l o qu e s e r m a r c a d o a l a ve z c o m o n o u t i l i za d o y u t i l i za d o .
To d o s l o s c o n j u n t o s d e b l o qu e s m a n t e n i d o s e n l a f il a s e r n s u b c o n j u n t o s d e
l a c o l e c c i n d e b l o qu e s a c t u a l m e n t e u s a d o s .
Ni n g n n m e r o d e b l o qu e p e r t e n e c e r a d o s o m s e l e m e n t o s d e l a f il a.
L a c o l e c c i n d e b l o qu e s u t i l i za d o s y n o u t i l i za d o s s e r l a c o l e c c i n t o t a l d e
b l o qu e s qu e c o n f i g u r a n l o s a r c hi vo s .
L a c o l e c c i n d e b l o qu e s n o u t i l i za d o s n o t e n d r n m e r o s d e b l o qu e d u p l i c a -
d o s .
L a c o l e c c i n d e b l o qu e s u t i l i za d o s n o t e n d r n m e r o s d e b l o qu e d u p l i c a d o s .
Al g u n a s d e l a s o p e r a c i o n e s a s o c i a d a s c o n el i n va r i a n t e d e d a t o s s o n : aadirf) u n a
c o l e c c i n d e b l o qu e s a l f in al d e l a f il a, eliminar() u n a c o l e c c i n d e b l o qu e s u t i l i za -
d o s d e l f r e n t e d e l a f il a y c o l o c a r l o s e n l a c o l e c c i n d e b l o qu e s n o u t i l i za d o s , y verifi-
car() s i l a f il a d e b l o qu e s e s t va c a .
L a p r e c o n d i c i n d e l a p r i m e r a o p e r a c i n e s qu e l o s b l o qu e s qu e s e a a d i r n d e -
b e n e s t a r e n l a c o n d i c i n d e b l o qu e s u t i l i za d o s . L a p o s c o n d i c i n e s qu e l a c o l e c c i n
d e b l o qu e s a ho r a s e e n c u e n t r a a l f in al d e l a f il a. L a p r e c o n d i c i n d e l a s e g u n d a o p e -
r a c i n e s qu e l a f il a d e b e t e n e r a l m e n o s u n e l e m e n t o e n e l l a . L a o p e r a c i n f in al
ve r i f i c a r s i l a f il a d e b l o qu e s d e vu e l t o s e s t va c a n o t i e n e p r e c o n d i c i n . Es t o s i g -
n i f i c a qu e l a o p e r a c i n s i e m p r e e s t d e f i n i d a , s i n i m p o r t a r d e qu va l o r s e a e l e s t a -
d o . L a p o s c o n d i c i n e n t r e g a e l va l o r cierto s i l a f il a e s t va c a yf al s o d e c u a l qu i e r o t r o
m o d o .
En l o s e j e m p l o s t r a t a d o s e n e s t a s e c c i n s e i n t r o d u c e n l o s c o n c e p t o s c l a ve d e l a e s -
p e c i f i c a c i n f o r m a l . Es t o s e hi zo s i n r e s a l t a r l a s m a t e m t i c a s qu e s e r e qu i e r e n p a r a f o r -
m a l i za r l a e s p e c i f i c a c i n . En l a s e c c i n 28. 2 s e c o n s i d e r a n t a l e s m a t e m t i c a s .
TM
PDF Editor
C A P T U L O 2 8 MTODOS FORMAL ES
837
L a a p l i c a c i n e f i c a z d e l o s m t o d o s f o r m a l e s r e qu i e r e qu e u n i n g e n i e r o d e s o f t w a r e
t e n g a u n c o n o c i m i e n t o o p e r a t i vo d e l a n o t a c i n m a t e m t i c a a s o c i a d a c o n l o s c o n -
j u n t o s y l a s s e c u e n c i a s , y d e l a n o t a c i n l g i c a u t i l i za d a e n e l c l c u l o d e p r e d i c a d o s .
L a f in al id ad d e l a s e c c i n e s p r o p o r c i o n a r u n a b r e ve i n t r o d u c c i n a l t e m a . Pa r a u n a
e x p o s i c i n m s d e t a l l a d a , s e r e c o m i e n d a a l l e c t o r c o n s u l t a r l i b r o s d e d i c a d o s a e s t o s
t e m a s (p o r e j e m p l o , [WIL 87], [GRI93] y [ROS95]) .
28.2.1 Conjuntos y especificacin constructiva
Un conjunto e s u n a c o l e c c i n d e o b j e t o s o e l e m e n t o s , y s e u t i l i za c o m o p i e d r a a n g u -
l a r d e l o s m t o d o s f o r m a l e s . L o s e l e m e n t o s qu e c o n t i e n e u n c o n j u n t o s o n n i c o s (e s
d e c i r : n o s e p e r m i t e n d u p l i c a c i o n e s ) . L o s c o n j u n t o s c o n u n n m e r o p e qu e o d e e l e -
m e n t o s s e e s c r i b e n d e n t r o d e l l a ve s , c o n l o s e l e m e n t o s s e p a r a d o s p o r c o m a s . Po r
e j e m p l o , e l c o n j u n t o
| C++, Sm a l l t a l k, Ad a , COBOL , J a va )
c o n t i e n e l o s n o m b r e s d e c i n c o l e n g u a j e s d e p r o g r a m a c i n .
El o r d e n e n e l qu e a p a r e c e n l o s e l e m e n t o s d e n t r o d e u n c o n j u n t o e s i r r e l e va n t e .
Al n m e r o d e e l e m e n t o s e n u n c o n j u n t o s e l e c o n o c e c o m o c a r d i n a l i d a d . El o p e r a -
d o r # p r o p o r c i o n a l a c a r d i n a l i d a d d e u n c o n j u n t o . Po r e j e m p l o , l a e x p r e s i n
#{A, B, C, D) = 4
i m p l i c a qu e s e ha a p l i c a d o e l o p e r a d o r c a r d i n a l i d a d a l c o n j u n t o m o s t r a d o , c o n u n r e -
s u l t a d o qu e i n d i c a e l n m e r o d e e l e m e n t o s e n e l c o n j u n t o .
Ex i s t e n d o s f o r m a s d e d e f i n i r u n c o n j u n t o . Un c o n j u n t o s e d e f i n e e n u m e r a n d o s u s
e l e m e n t o s (a s s e ha n d e f i n i d o l o s c o n j u n t o s m e n c i o n a d o s ) . El s e g u n d o e n f o qu e
c o n s i s t e e n c r e a r u n a especificacin constructiva de conjuntos. L a f o r m a g e n e r a l d e l o s
m i e m b r o s d e u n c o n j u n t o s e e s p e c i f i c a e m p l e a n d o u n a e x p r e s i n b o o l e a n a . L a e s -
p e c i f i c a c i n c o n s t r u c t i va d e c o n j u n t o s e s p r e f e r i b l e a l a e n u m e r a c i n p o r qu e e l l o
p e r m i t e u n a d e f i n i c i n s u c i n t a d e c o n j u n t o s g r a n d e s . Ta m b i n d e f i n e e x p l c i t a m e n -
t e l a r e g l a qu e s e a p l i c a l c o n s t r u i r e l c o n j u n t o . Co n s i d r e s e e l s i g u i e n t e e j e m p l o d e
e s p e c i f i c a c i n c o n s t r u c t i va :
| n : N I n < 3 n
Es t a e s p e c i f i c a c i n t i e n e t r e s c o m p o n e n t e s : u n a f ir m a, n : N; u n p r e d i c a d o , n < 3; y
u n t r m i n o , n. L a firma e s p e c i f i c a e l i n t e r va l o d e va l o r e s qu e s e c o n s i d e r a r n c u a n -
d o s e f o r m e e l c o n j u n t o ; e l predicado (u n a e x p r e s i n B o o l e a n a ) d e f i n e c m o s e r e s -
t r i n g i r e l c o n j u n t o ; y, f in al m en te, el t rmino b r i n d a l a f o r m a g e n e r a l d e l e l e m e n t o
d e l c o n j u n t o . En e l e j e m p l o a n t e r i o r , ' , r e p r e s e n t a l o s n m e r o s n a t u r a l e s ; p o r l o t a n -
t o , s e c o n s i d e r a r n l o s n m e r o s n a t u r a l e s El p r e d i c a d o i n d i c a qu e s l o s e i n c l u i r n
Qu e s
es peci f i caci n
const ruct i va de
conj unt os ?
TM
PDF Editor
^ O N S U O ^
Es indispensable el
conocimiento de los
operaciones de
conjuntos cuando se
desarrollen especifica-
ciones formales. Debe
pasarse alg n tiempo
familiarizndose con
cado una, sise tiene
la intencin de aplicar
m todos formales.
l o s n m e r o s n a t u r a l e s m e n o r e s qu e 3; y e l t r m i n o e s p e c i f i c a qu e c a d a e l e m e n t o c e
c o n j u n t o s e r d e l a f o r m a n. En c o n s e c u e n c i a , e s t a e s p e c i f i c a c i n d e f i n e e l c o n j u n t :
10, 1 , 2 )
Cu a n d o l a f o r m a d e l o s e l e m e n t o s d e u n c o n j u n t o e s o b vi a , e l t r m i n o s e p u e d e o m
t i r . Po r e j e m p l o , e l c o n j u n t o p r e c e d e n t e s e p o d r a e s p e c i f i c a r c o m o
{/i : N I n < 3)
To d o s l o s c o n j u n t o s qu e s e ha n d e s c r i t o t i e n e n e l e m e n t o s qu e s o n e l e m e n t o s i n d i -
vi d u a l e s . Ta m b i n s e p u e d e n f o r m a r c o n j u n t o s a p a r t i r d e e l e m e n t o s qu e s e a n p a -
r e s , t e m a s , e t c t e r a . Po r e j e m p l o , l a e s p e c i f i c a c i n d e c o n j u n t o
{x,y : N Ix +y = 10 ( x, y2 ) )
d e s c r i b e e l c o n j u n t o d e p a r e s d e n m e r o s n a t u r a l e s qu e t i e n e n l a f o r m a (x.y2) y d o n -
d e l a s u m a d e x ey e s 10. s t e e s e l c o n j u n t o
{(1,81) , (2, 64) , (3, 49 ) , - )
Ob vi a m e n t e , l a e s p e c i f i c a c i n c o n s t r u c t i va d e c o n j u n t o s r e qu e r i d a p a r a r e p r e s e n -
t a r a l g n c o m p o n e n t e d e s o f t w a r e d e c o m p u t a d o r a s e r c o n s i d e r a b l e m e n t e m s
c o m p l e j a qu e l a s a n o t a d a s a qu . Si n e m b a r g o , l a f o r m a y e s t r u c t u r a b s i c a s p e r m a -
n e c e n i g u a l e s .
28.2.2 Operadores de conjuntos
En l a r e p r e s e n t a c i n d e o p e r a c i o n e s d e c o n j u n t o s y l g i c a s s e u t i l i za s i m b o l o g l a e s -
p e c i a l i za d a . El i n g e n i e r o d e s o f t w a r e qu e p r e t e n d a a p l i c a r l o s m t o d o s f o r m a l e s d e -
b e c o m p r e n d e r e s t o s s m b o l o s .
El o p e r a d o r e i n d i c a l a p e r t e n e n c i a d e u n c o n j u n t o . Po r e j e m p l o , l a e x p r e s i n
x E X
t i e n e e l va l o r verdadero s i x e s m i e m b r o d e l c o n j u n t o X y e l va l o r falso e n c a s o c o n -
t r a r i o . Po r e j e m p l o , e l p r e d i c a d o
12 e |6, 1, 12, 22)
t i e n e e l va l o r verdadero d a d o qu e 12 e s m i e m b r o d e l c o n j u n t o .
El o p u e s t o d e l o p e r a d o r e e s e l o p e r a d o r e . L a e x p r e s i n
x e X
t i e n e el va l o r verdadero s i x n o e s m i e m b r o d e l c o n j u n t o X y falso e n c a s o c o n t r a r i o .
Po r e j e m p l o , e l p r e d i c a d o
13 z {13, 1, 124, 22)
t i e n e e l va l o r falso.
L o s o p e r a d o r e s e y e t i e n e n c o n j u n t o s c o m o s u s o p e r a n d o s . El p r e d i c a d o
ACB
TM
PDF Editor
CAP TULO 2 8 MTODOS FORMAL ES 839
t i e n e e l va l o r verdadero s i l o s m i e m b r o s d e l c o n j u n t o s e s t n e n e l c o n j u n t o 6 y t i e -
n e e l va l o r falso e n c a s o c o n t r a r i o . Po r l o t a n t o , e l p r e d i c a d o
(1, 2) c {4, 3, 1, 2}
t i e n e e l va l o r verdadero. Si n e m b a r g o , e l p r e d i c a d o
{HD1, L P4, RC5) C |HD1, RC2, HD3, L P1, L P4, L P6)
t i e n e u n va l o r d e falso p o r qu e e l e l e m e n t o RC5 n o e s t e n e l c o n j u n t o a l a d e r e c ha
d e l o p e r a d o r .
El o p e r a d o r c e s s i m i l a r a c . Si n e m b a r g o , s i s u s o p e r a n d o s s o n i g u a l e s , t i e n e el
va l o r verdadero. Po r l o t a n t o , e l va l o r d e l p r e d i c a d o
HD1, L P4, RC5} C | HDl , RC2, HD3, L P1, L P4, L P6|
e s falso, y e l p r e d i c a d o
(HD1, L P4, RC5} C (HD1, L P4, RC51
e s verdadero.

" t a s e s t r u c t u r a s m a t e m t i c a s e s t n e n t r e l o s d e s c u b r i m i e n t o s m s he r m o s o s r e a l i za d o s p o r l a m e n t e hu m a n a . "
Do u g l a s Ha f s t a d t e r
Un c o n j u n t o e s p e c i a l e s e l c o n j u n t o va c o 0 . s t e c o r r e s p o n d e a c e r o e n l a s m a -
t e m t i c a s n o r m a l e s . El c o n j u n t o va c o t i e n e l a p r o p i e d a d d e s e r u n s u b c o n j u n t o d e
c u a l qu i e r o t r o c o n j u n t o . Do s t i l e s i d e n t i d a d e s qu e i n vo l u c r a n a l c o n j u n t o va c o s o n
01>A=A y 0DA = 0
p a r a c u a l qu i e r c o n j u n t o A, d o n d e u s e c o n o c e c o m o el o p e r a d o r u n i n , a ve c e s c o -
n o c i d o c o m o taza; n e s e l operador interseccin, a ve c e s c o n o c i d o c o m o gorra.
El o p e r a d o r u n i n a d m i t e d o s c o n j u n t o s y f o r m a u n o qu e c o n t i e n e l o s e l e m e n t o s
d e l o s d o s c o n j u n t o s y e l i m i n a l o s d u p l i c a d o s . Po r l o t a n t o , e l r e s u l t a d o d e l a e x p r e -
s i n
{Ar c hi vo l , Ar c hi vo 2, Im p u e s t o , Co m p i l a d o r ) u (Im p u e s t o Nu e vo , D2, D3, Ar c hi -
V02)
e s e l c o n j u n t o
(Ar c hi vo l , Ar c hi vo 2, Im p u e s t o , Co m p i l a d o r , Im p u e s t o Nu e vo , D2, D3)
El o p e r a d o r d e i n t e r s e c c i n a d m i t e d o s c o n j u n t o s y f o r m a u n o qu e c o n s i s t e d e l o s
e l e m e n t o s c o m u n e s e n c a d a c o n j u n t o . Po r l o t a n t o , l a e x p r e s i n
(12, 4, 9 9 , 1} n {1, 13, 12, 77)
g e n e r a e l c o n j u n t o (12, 1) .
El operador diferencia de conjuntos, \ , c o m o s u n o m b r e s u g i e r e , f o r m a u n
c o n j u n t o a l e l i m i n a r l o s e l e m e n t o s d e s u s e g u n d o o p e r a n d o d e l o s e l e m e n t o s d e s u
p r i m e r o p e r a n d o . Po r l o t a n t o , e l va l o r d e l a e x p r e s i n
TM
PDF Editor
940 PARTE C I N C O TEMAS AVANZADOS EN INGENIER A DEL SOFTWARE
(Nu e vo , Vi e j o , Ar c hi vo l m p u e s t o , Pa r a m Si s j \ (Vi ej o , Pa r a m Si s )
g e n e r a e l c o n j u n t o (Nu e vo , Ar c hi vo l m p u e s t o ) .
El va l o r d e l a e x p r e s i n
(a, b , c , d ) n ( x, y)
s e r e l c o n j u n t o va c o 0. El o p e r a d o r s i e m p r e p r o p o r c i o n a u n c o n j u n t o ; s i n e m b a r -
g o , e n e s t e c a s o n o e x i s t e n e l e m e n t o s c o m u n e s e n t r e s u s o p e r a n d o s , a s qu e e l c o n -
j u n t o r e s u l t a n t e n o t e n d r e l e m e n t o s .
El o p e r a d o r f in al e s el producto cruzado, x , a ve c e s c o n o c i d o c o m o producto car-
tesiano. s t e t i e n e d o s o p e r a n d o s . El r e s u l t a d o e s u n c o n j u n t o d e p a r e s d o n d e c a d a
p a r c o n s i s t e d e u n e l e m e n t o t o m a d o d e l p r i m e r o p e r a n d o c o m b i n a d o c o n u n e l e -
m e n t o d e l s e g u n d o . Un e j e m p l o d e u n a e x p r e s i n qu e i n vo l u c r a a l p r o d u c t o c r u za -
d o e s
(1, 2) x {4, 5, 6)
El r e s u l t a d o d e e s t a e x p r e s i n e s
((1,4) , (1,5) , (1,6) , (2, 4) , (2,5) , (2,6) )
N t e s e qu e c a d a e l e m e n t o d e l p r i m e r o p e r a n d o e s t c o m b i n a d o c o n c a d a u n o d e l o s
e l e m e n t o s d e l s e g u n d o .
Un c o n c e p t o i m p o r t a n t e e n l o s m t o d o s f o r m a l e s e s e l d e conjunto potencia. Un
c o n j u n t o p o t e n c i a d e u n c o n j u n t o e s l a c o l e c c i n d e t o d o s l o s p o s i b l e s s u b c o n j u n t o s
d e d i c ho c o n j u n t o . El s m b o l o qu e s e u t i l i za p a r a e s t e o p e r a d o r d e c o n j u n t o e n e s t e
c a p t u l o e s P. Se t r a t a d e u n o p e r a d o r u n i t a r i o qu e , c u a n d o s e a p l i c a a u n c o n j u n t o ,
d e vu e l ve e l c o n j u n t o d e s u b c o n j u n t o s d e s u o p e r a n d o . Po r e j e m p l o ,
P ( 1, 2, 3) = { 0, (1) , (2) , (3) , ( 1 , 2 ) , (1, 3) , ( 2, 3) , (1, 2, 3) )
ya qu e t o d o s l o s c o n j u n t o s s o n s u b c o n j u n t o s d e (1, 2, 3) .
28.2.3 Operadores lgicos
Ot r o c o m p o n e n t e i m p o r t a n t e d e u n m t o d o f o r m a l e s l a lgica: e l l g e b r a d e e x p r e -
s i o n e s ve r d a d e r a s y f a l s a s . El s i g n i f i c a d o d e l o s o p e r a d o r e s l g i c o s c o m u n e s l o c o m -
p r e n d e b i e n c u a l qu i e r i n g e n i e r o d e s o f t w a r e . Si n e m b a r g o , l o s o p e r a d o r e s l g i c o s
a s o c i a d o s c o n l o s l e n g u a j e s d e p r o g r a m a c i n c o m u n e s s e e s c r i b e n e m p l e a n d o s m -
b o l o s d i s p o n i b l e s f c i l m e n t e e n e l t e c l a d o . L o s o p e r a d o r e s m a t e m t i c o s e qu i va l e n -
t e s s o n
A y
V o
-i n o
=> i m p l i c a
L a cuantificacin universal e s u n a f o r m a d e e l a b o r a r u n p l a n t e a m i e n t o a c e r c a d e
l o s e l e m e n t o s d e u n c o n j u n t o qu e r e s u l t a ve r d a d e r o p a r a c u a l qu i e r m i e m b r o d e l
TM
PDF Editor
CAP TULO 2 8 MTODOS FORMAL ES
841
c o n j u n t o . L a c u a n t i f i c a c i n u n i ve r s a l u t i l i za el s m b o l o v. Un e j e m p l o d e s u u t i l i za -
c i n e s
V , N i >j =* i 2 > j 2
e n d o n d e s e e s t a b l e c e qu e p a r a c a d a p a r d e va l o r e s e n e l c o n j u n t o d e n m e r o s n a -
t u r a l e s , si / e s m a yo r qu e j, e n t o n c e s i2 e s m a yo r qu e j2.
28.2.4 Sucesiones
Un a s u c e s i n e s u n a e s t r u c t u r a m a t e m t i c a qu e m o d e l a e l he c ho d e qu e s u s e l e m e n -
t o s e s t n o r d e n a d o s . Un a s u c e s i n s e s u n c o n j u n t o d e p a r e s c u yo s e l e m e n t o s va -
r a n d e 1 a l e l e m e n t o d e m a yo r n m e r o . Po r e j e m p l o ,
{(1, J o n e s ) , (2, Wi l s o n ) , (3, Sha p i r o ) , (4, Es t a ve z) ]
e s u n a s u c e s i n . L o s e l e m e n t o s qu e f o r m a n l o s p r i m e r o s e l e m e n t o s d e l o s p a r e s s e
c o n o c e n c o l e c t i va m e n t e c o m o dominio d e l a s u c e s i n , y l a c o l e c c i n d e s e g u n d o s
e l e m e n t o s s e c o n o c e c o m o e l intervalo d e l a s u c e s i n . En e s t e l i b r o , l a s s u c e s i o n e s
e s t n i n d i c a d a s m e d i a n t e c o r c he t e s a n g u l a d o s . Po r e j e m p l o , l a s u c e s i n p r e c e d e n t e
n o r m a l m e n t e s e e s c r i b i r a c o m o (J o n e s , Wi l s o n , Sha p i r o , Es t a ve z) .
A d i f e r e n c i a d e l o s c o n j u n t o s , l a d u p l i c a c i n s e p e r m i t e e n u n a s u c e s i n , c u yo o r -
d e n e s i m p o r t a n t e . Po r l o t a n t o ,
(J o n e s , Wi l s o n , Sha p i r o ) * (J o n e s , Sha p i r o , Wi l s o n )
L a s u c e s i n va c a s e r e p r e s e n t a c o m o () .
En l a s e s p e c i f i c a c i o n e s f o r m a l e s s e u t i l i za n va r i o s o p e r a d o r e s d e s u c e s i n . L a
c o n c a t e n a c i n , , e s u n o p e r a d o r b i n a r i o qu e f o r m a u n a s u c e s i n c o n s t r u i d a a l
a g r e g a r s u s e g u n d o o p e r a n d o a l f in al d e s u p r i m e r o p e r a n d o . Po r e j e m p l o ,
( 2, 3, 34, 1) ( 12, 33, 34, 200)
g e n e r a l a s u c e s i n (2, 3, 34, 1,12, 33, 34, 200) .
Ot r o s o p e r a d o r e s qu e s e a p l i c a n a l a s s u c e s i o n e s s o n cabeza, cola, frente y ltimo.
El o p e r a d o r cabeza e x t r a e el p r i m e r e l e m e n t o d e u n a s u c e s i n ; cola p r o p o r c i o n a l o s
l t i m o s n - 1 e l e m e n t o s e n u n a s u c e s i n d e l o n g i t u d n ; ltimo e x t r a e e l e l e m e n t o f i-
n a l e n u n a s u c e s i n ; y frente p r o p o r c i o n a l o s p r i m e r o s n - 1 e l e m e n t o s e n u n a s u c e -
s i n d e l o n g i t u d n. Po r e j e m p l o ,
cabeza (2, 3, 34, 1, 9 9 , 101) = 2
cola (2, 3, 34, 1, 9 9 , 101) = (3, 34, 1, 9 9 , 101)
ltimo (2, 3, 34, 1, 9 9 , 101) = 101
frente (2, 3, 34, 1, 9 9 , 101) = (2, 3, 34, 1, 9 9 )
Da d o qu e u n a s u c e s i n e s u n c o n j u n t o d e p a r e s , s e p u e d e n a p l i c a r t o d o s l o s o p e r a -
d o r e s d e c o n j u n t o d e s c r i t o s e n l a s e c c i n 28. 2. 2. Cu a n d o s e e m p l e a u n a s u c e s i n e n
u n e s t a d o , s e d e b e d e s i g n a r m e d i a n t e l a p a l a b r a seq. Po r e j e m p l o ,
ArchivoLista : seq ARCHIVOS
NumUsuarios : N
TM
PDF Editor
342 PARTE CINCO TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
d e s c r i b e n u n e s t a d o c o n d o s c o m p o n e n t e s : u n a s u c e s i n d e a r c hi vo s y u n n m e r o
n a t u r a l .
28. 3 APL ICACIN PE L A NOTACIN MATEMTICA PARA L A ACION FORMAL
^ C m o s e
p u e d e n
r e p r e s e n t a r l o s
e s t a d o s e
i n va r i a n t e s d e
i i f t l Ar a m h I a a h i i a
a a i u > e m p i e u n u o
l o s o p e r a d o r e s
l g i c o s y d e
c o n j u n t o s qu e
ya s e ha n
i n t r o d u c i d o ?
In f o t m o c i n e x t e m o
a c e r c o d e i o s m t o d o s
f o r m a l e s s e p u e d e e n -
c o n t r a r e n . w w w ,
a f m . s b u . a c . u k.
El e m p l e o d e l a n o t a c i n m a t e m t i c a e n l a e s p e c i f i c a c i n f o r m a l d e u n c o m p o n e n t e
d e s o f t w a r e s e i l u s t r a r r e p a s a n d o e l g e s t o r d e b l o qu e s p r e s e n t a d o e n l a s e c c i n
28. 1. 3. Un i m p o r t a n t e c o m p o n e n t e d e u n s i s t e m a o p e r a t i vo d e c o m p u t a d o r a m a n t i e -
n e l o s a r c hi vo s qu e ha n c r e a d o l o s u s u a r i o s . El g e s t o r d e b l o qu e s m a n t i e n e u n d e -
p s i t o d e b l o qu e s n o u t i l i za d o s y t a m b i n s e g u i r l o s b l o qu e s a c t u a l m e n t e e n u s o
Cu a n d o s e l i b e r a n b l o qu e s d e u n a r c hi vo b o r r a d o n o r m a l m e n t e s e a a d e n a u n a f i-
l a d e b l o qu e s qu e e s p e r a n s e r a a d i d o s a l d e p s i t o d e b l o qu e s n o u t i l i za d o s . En l a
f ig u r a 28. 2 s e ha b o s qu e j a d o e s t o e s qu e m t i c a m e n t e . 4
Un c o n j u n t o l l a m a d o BLOQUES c o n s i s t i r d e t o d o s l o s n m e r o s d e b l o qu e . Todos-
Bloques e s u n c o n j u n t o d e b l o qu e s qu e s e u b i c a e n t r e 1 y MxBloques. El e s t a d o l o
m o d e l a r n d o s c o n j u n t o s y u n a s u c e s i n . L o s d o s c o n j u n t o s s o n usados y Ubres. Am -
b o s c o n t i e n e n b l o qu e s : e l c o n j u n t o usados c o n t i e n e l o s b l o qu e s qu e a c t u a l m e n t e s e
e s t n u t i l i za n d o e n l o s a r c hi vo s , y e l c o n j u n t o libres c o n t i e n e l o s b l o qu e s d i s p o n i b l e s
p a r a l o s a r c hi vo s n u e vo s . L a s u c e s i n c o n t e n d r c o n j u n t o s d e b l o qu e s qu e e s t n l is-
t o s p a r a s e r l i b e r a d o s d e l o s a r c hi vo s qu e s e ha n b o r r a d o . El e s t a d o s e p u e d e d e s c r i -
b i r c o m o
usados, libres-, P BLOQUES
FilaBloques: seq P BLOQUES
Es t o e s m u y p a r e c i d o a l a d e c l a r a c i n d e va r i a b l e s d e p r o g r a m a . Es t a b l e c e qu e usa
dos y libres s e r n c o n j u n t o s d e b l o qu e s y qu e FilaBloques s e r u n a s u c e s i n , c a d a
e l e m e n t o d e l a c u a l s e r u n c o n j u n t o d e b l o qu e s . El i n va r i a n t e d e d a t o s s e p u e d e e s -
c r i b i r c o m o
usados n libres = 0 A
usados u libres = TodosBloques A
V i: d o m FilaBloques FilaBloques i c usados A
V i, j: d o m FilaBloques i * j => FilaBloques i n FilaBloques j = 0
L o s c o m p o n e n t e s m a t e m t i c o s d e l i n va r i a n t e d e d a t o s s e c o r r e s p o n d e n c o n c u a t r o
d e l o s c o m p o n e n t e s d e l e n g u a j e n a t u r a l m a r c a d o s qu e s e d e s c r i b i e r o n a n t e r i o r m e n t e .
L a p r i m e r a l n e a d e l i n va r i a n t e d e d a t o s e s t a b l e c e qu e n o e x i s t i r n b l o qu e s c o m u n e s
e n l a s c o l e c c i o n e s d e b l o qu e s u s a d o s y l i b r e s . L a s e g u n d a l n e a a f i r m a qu e l a c o l e c -
4 Si n o s e r ec u er d a b ien el e j e m p l o d el g e s t o r d e b l o qu es , p o r f a vo r va s e d e n u e vo l a sec c i n 28. 1. 3
p a r a r e vi s a r el i n va r i a n t e d e d a t o s , l as o p e r a c i o n e s , p r e c o n d i c i o n e s y p o s c o n d i c i o n e s a s o c i a d a s c o n
el g e s t o r d e b l o qu e s .
TM
PDF Editor
C A P T U L O 2 8 MTODOS F ORMAI S
843
c i n d e b l o qu e s u s a d o s y l i b r e s s i e m p r e s e r i g u a l a t o d a l a c o l e c c i n d e b l o qu e s e n
e l s i s t e m a . L a t e r c e r a l i n e a i n d i c a qu e e l i -s i m o e l e m e n t o e n l a f il a d e b l o qu e s s i e m -
p r e s e r u n s u b c o n j u n t o d e l o s b l o qu e s u s a d o s . L a l n e a f in al a f i r m a qu e , p a r a c u a -
l e s qu i e r d o s e l e m e n t o s d e l a f il a d e b l o qu e s qu e n o s o n e l m i s m o , n o ha b r b l o qu e s
c o m u n e s e n e s t o s d o s e l e m e n t o s . L o s d o s c o m p o n e n t e s f in al es d e l e n g u a j e n a t u r a l d e l
i n va r i a n t e d e d a t o s s e i m p l e m e n t a n e n vi r t u d d e l he c ho d e qu e usados y libres s o n
c o n j u n t o s y p o r l o t a n t o n o c o n t e n d r n d u p l i c a d o s .
L a p r i m e r a o p e r a c i n qu e s e d e f i n i r e s l a qu e e l i m i n a u n e l e m e n t o d e l a c a b e za
d e l a f il a d e b l o qu e s . L a p r e c o n d i c i n e s qu e d e b e e x i s t i r a l m e n o s u n e l e m e n t o e n
l a f il a:
# Fi l a B l o qu e s > 0,
L a p o s c o n d i c i n e s qu e l a c a b e za d e l a f il a d e b e e l i m i n a r s e y c o l o c a r s e e n l a c o l e c -
c i n d e b l o qu e s l i b r e s , y l a Fil a s e d e b e a j u s t a r p a r a m o s t r a r l a e l i m i n a c i n :
usados' = usados \ cabeza FilaBloques A
libres' = libres u cabeza FilaBloques A
FilaBloques' = cola FilaBloques
Un a c o n ve n c i n qu e s e u t i l i za e n m u c ho s m t o d o s f o r m a l e s e s qu e a l va l o r d e u n a
va r i a b l e d e s p u s d e u n a o p e r a c i n s e l e p o n e p r i m a . Po r l o t a n t o , el p r i m e r c o m p o -
n e n t e d e l a e x p r e s i n p r e c e d e n t e a f i r m a qu e l o s n u e vo s b l o qu e s u s a d o s {usados')
s e r n i g u a l e s a l o s a n t i g u o s b l o qu e s u s a d o s m e n o s l o s b l o qu e s qu e s e ha n e l i m i n a -
d o . El s e g u n d o c o m p o n e n t e a f i r m a qu e l o s n u e vo s b l o qu e s l i b r e s (libres') s e r n l o s
a n t i g u o s b l o qu e s l i b r e s m s l a c a b e za d e l a f il a d e b l o qu e s . El t e r c e r c o m p o n e n t e e s -
t a b l e c e qu e l a n u e va f il a d e b l o qu e s s e r i g u a l a l a c o l a d e l a n t i g u o va l o r d e l a f il a d e
b l o qu e s ; e s t o e s : t o d o s l o s e l e m e n t o s e n l a f il a, m e n o s el p r i m e r o .
Un a s e g u n d a o p e r a c i n a g r e g a u n a c o l e c c i n d e b l o qu e s , Abloques, a l a f il a d e
b l o qu e s . L a p r e c o n d i c i n e s qu e Abloques s e a a c t u a l m e n t e u n c o n j u n t o d e b l o qu e s
u s a d o s :
Abloques c usados
L a p o s c o n d i c i n e s qu e e l c o n j u n t o d e b l o qu e s s e a a a d i d o a l f in al d e l a f il a, y e l
c o n j u n t o d e b l o qu e s u s a d o s y l i b r e s p e r m a n e zc a i n va r i a b l e :
FilaBloques' = FilaBloques -Ab l o qu e s A
usados' = usados A
libres' = libres
No e x i s t e d u d a d e qu e l a e s p e c i f i c a c i n m a t e m t i c a d e l a f il a d e b l o qu e s e s c o n s i d e -
r a b l e m e n t e m s r i g u r o s a qu e u n a n a r r a c i n e n l e n g u a j e n a t u r a l o u n m o d e l o g r f i -
c o . El r i g o r a d i c i o n a l r e qu i e r e e s f u e r zo , p e r o l o s b e n e f i c i o s o b t e n i d o s a p a r t i r d e l a
c o n s i s t e n c i a y l a c o m p l e t u d m e j o r a d a s s e p u e d e n j u s t i f i c a r p a r a m u c ho s t i p o s d e
a p l i c a c i o n e s .
^ Cmo s e
V r e pr e s e nt an
s p r e y
M acondi ci ones?
TM
PDF Editor
Un l e n g u a j e f o r m a l d e e s p e c i f i c a c i n u s u a l m e n t e e s t c o m p u e s t o d e t r e s c o m p o n e n -
t e s p r i n c i p a l e s : 1) u n a sintaxis qu e d e f i n e l a n o t a c i n e s p e c f i c a c o n l a qu e s e r e p r e s e n -
t a l a e s p e c i f i c a c i n , 2) semntica p a r a a yu d a r a d e f i n i r u n "u n i ve r s o d e o b j e t o s " [WIN90]
qu e s e e m p l e a r p a r a d e s c r i b i r e l s i s t e m a , y 3) u n conjunto de relaciones qu e d e f i n e n l as
r e g l a s qu e i n d i c a n c u l e s o b j e t o s s a t i s f a c e n a d e c u a d a m e n t e l a e s p e c i f i c a c i n .
Co n f r e c u e n c i a , e l d o m i n i o s i n t c t i c o d e u n l e n g u a j e f o r m a l d e e s p e c i f i c a c i n s e
b a s a e n u n a s i n t a x i s qu e s e d e r i va d e l a n o t a c i n e s t n d a r d e l a t e o r a d e c o n j u n t o s
y e l c l c u l o d e p r e d i c a d o s . Po r e j e m p l o , va r i a b l e s t a l e s c o m o x,y y z d e s c r i b e n u n
c o n j u n t o d e o b j e t o s qu e s e r e l a c i o n a n c o n u n p r o b l e m a (e n o c a s i o n e s l l a m a d o da-
minio del discurso) y s e u t i l i za n e n c o n j u n t o c o n l o s o p e r a d o r e s d e s c r i t o s e n l a s e c -
c i n 28. 2. Au n qu e l a s i n t a x i s u s u a l m e n t e e s s i m b l i c a , t a m b i n s e p u e d e n u t i l i za r
i c o n o s (p o r e j e m p l o , s m b o l o s g r f i c o s c o m o c a j a s , f l e c ha s y c r c u l o s ) s i n o s o n a m -
b i g u o s .
El dominio semntico d e u n l e n g u a j e d e e s p e c i f i c a c i n i n d i c a c m o e l l e n g u a j e r e -
p r e s e n t a l o s r e qu i s i t o s d e l s i s t e m a . Po r e j e m p l o , u n l e n g u a j e d e p r o g r a m a c i n t i e n e
u n c o n j u n t o d e s e m n t i c a s f o r m a l e s qu e p e r m i t e al d e s a r r o l l a d o r d e s o f t w a r e e s p e -
c i f i c a r a l g o r i t m o s qu e t r a n s f o r m a n e n t r a d a e n s a l i d a . Se p u e d e u t i l i za r u n a g r a m t i -
c a f o r m a l (c o m o BNF) p a r a d e s c r i b i r l a s i n t a x i s d e l l e n g u a j e d e p r o g r a m a c i n . Sin
e m b a r g o , u n l e n g u a j e d e p r o g r a m a c i n n o ha c e u n b u e n l e n g u a j e d e e s p e c i f i c a c i n
p o r qu e s l o r e p r e s e n t a f u n c i o n e s d e c m p u t o . Un l e n g u a j e d e e s p e c i f i c a c i n d e b e
t e n e r u n d o m i n i o s e m n t i c o m s a m p l i o , e s d e c i r , d e b e s e r c a p a z d e e x p r e s a r i d e a s
c o m o "p a r a t o d a x e n u n c o n j u n t o i n f i n i t o A, e x i s t e u n a _y e n u n c o n j u n t o i n f i n i t o B
tal qu e l a p r o p i e d a d P s e m a n t i e n e p a r a x y / ' [WIN90], Ot r o s l e n g u a j e s d e e s p e c i f i -
c a c i n a p l i c a n s e m n t i c a s qu e p e r m i t e n l a e s p e c i f i c a c i n d e l c o m p o r t a m i e n t o d e l
s i s t e m a . Po r e j e m p l o , e s p o s i b l e d e s a r r o l l a r u n a s i n t a x i s y u n a s e m n t i c a p a r a e s p e -
c i f i c a r e s t a d o s y t r a n s i c i o n e s d e e s t a d o , y e ve n t o s , j u n t o c o n s u s e f e c t o s s o b r e l a
t r a n s i c i n d e e s t a d o , l a s i n c r o n i za c i n y l a t e m p o r a l i d a d .
Es p o s i b l e u s a r d i f e r e n t e s a b s t r a c c i o n e s s e m n t i c a s p a r a d e s c r i b i r e l m i s m o s i s -
t e m a e n d i f e r e n t e s f o r m a s . En e l c a p t u l o 8 e s t o s e hi zo e n u n a m a n e r a m e n o s f o r -
m a l . Se r e p r e s e n t a r o n c l a s e s , d a t o s , f u n c i o n e s y c o m p o r t a m i e n t o . Se p u e d e u s a r d i -
f e r e n t e n o t a c i n d e m o d e l a d o p a r a r e p r e s e n t a r el m i s m o s i s t e m a . L a s e m n t i c a d e
c a d a r e p r e s e n t a c i n o f r e c e vi s i o n e s c o m p l e m e n t a r i a s d e l s i s t e m a . Pa r a i l u s t r a r e s t e
e n f o qu e c u a n d o s e u s a n m t o d o s f o r m a l e s , s u p o n g a qu e s e u s a u n l e n g u a j e f o r m a l
d e e s p e c i f i c a c i n p a r a d e s c r i b i r a l c o n j u n t o d e e ve n t o s qu e p r o vo c a n qu e o c u r r a u n
e s t a d o p a r t i c u l a r e n u n s i s t e m a . Ot r a r e l a c i n f o r m a l b o s qu e j a t o d a s l a s f u n c i o n e s
qu e o c u r r e n d e n t r o d e u n e s t a d o d a d o . L a i n t e r s e c c i n d e e s t a s d o s r e l a c i o n e s p r o -
p o r c i o n a u n a i n d i c a c i n d e l o s e ve n t o s qu e c a u s a r n qu e o c u r r a n f u n c i o n e s e s p e c i -
f ic as.
En l a a c t u a l i d a d s e e m p l e a n va r i o s l e n g u a j e s f o r m a l e s d e e s p e c i f i c a c i n . OCL
[OMG03], Z ([1S002], [SPJ88], [SP192J) , L ARCH [GUT93] y VDM [JON91] s o n l e n g u a j e s
TM
PDF Editor
CAPTULO 2 8 MTODOS FORMAL ES
845
f o r m a l e s d e e s p e c i f i c a c i n r e p r e s e n t a t i vo s qu e m u e s t r a n l a s c a r a c t e r s t i c a s a n o t a -
d a s c o n a n t e r i o r i d a d . En e s t e c a p i t u l o s e p r e s e n t a u n b r e ve p a n o r a m a d e OCL y Z.
P P H J P I M
H
5
xereoc
de encontrar
w w w -3. i b m . t Mi i /
s o f t w a r e /
a w d t o o l t /
f aar y/
i t a n d o r d s /
o d . hl m f .
El lenguaje restringido a objetos (OCL , por sus siglas en ingl s) e s u n a n o t a c i n f o r m a l d e -
s a r r o l l a d a d e m o d o qu e l o s u s u a r i o s d e UML p u e d a n c o n f e r i r l e m a yo r p r e c i s i n a s u s
e s p e c i f i c a c i o n e s . El l e n g u a j e d i s p o n e d e t o d o e l p o d e r d e l a l g i c a y l a m a t e m t i c a s
d i s c r e t a s . Si n e m b a r g o , l o s d i s e a d o r e s d e OCL d e c i d i e r o n qu e e n e s t e l e n g u a j e s l o
d e b e r a n u s a r s e c a r a c t e r e s ASCII (e n l u g a r d e n o t a c i n m a t e m t i c a c o n ve n c i o n a l ) . Es -
t o p e r m i t e qu e e l l e n g u a j e s e a m s a s e qu i b l e a l a s p e r s o n a s m e n o s i n c l i n a d a s a l a s
m a t e m t i c a s y qu e l a c o m p u t a d o r a l o s p r o c e s e c o n m a yo r f a c i l i d a d . Pe r o e s t o t a m -
b i n f a vo r e c e qu e OCL s e a u n p o c o f a r r a g o s o e n a l g u n o s l u g a r e s .
28.5.1 Un breve panorama de la sintaxis y la semntica del OCL
L a u t i l i za c i n d e l OCL r e qu i e r e qu e u n i n g e n i e r o d e s o f t w a r e c o m i e n c e c o n u n o o
m s d i a g r a m a s UML : l a s c l a s e s , e s t a d o s o d i a g r a m a s d e a c t i vi d a d m s c o m u n e s . Po r
l o t a n t o , s e a g r e g a n e x p r e s i o n e s OCL qu e e s t a b l e c e n he c ho s a c e r c a d e l o s e l e m e n t o s
d e l o s d i a g r a m a s . Es t a s e x p r e s i o n e s s e l l a m a n restricciones; c u a l qu i e r i m p l e m e n t a -
c i n d e r i va d a d e l m o d e l o d e b e g a r a n t i za r qu e c a d a u n a d e l a s r e s t r i c c i o n e s s i e m p r e
p e r m a n e zc a ve r d a d e r a .
Al i g u a l qu e e l l e n g u a j e d e p r o g r a m a c i n o r i e n t a d o a o b j e t o s , u n a e x p r e s i n OCL
i n vo l u c r a o p e r a d o r e s qu e o p e r a n s o b r e l o s o b j e t o s . Si n e m b a r g o , e l r e s u l t a d o d e u n a
e x p r e s i n c o m p l e t a s i e m p r e d e b e s e r b o o l e a n a , e s d e c i r : ve r d a d e r o o f a l s o . L o s o b -
j e t o s p u e d e n s e r i n s t a n c i a s d e l a c l a s e OCL Col ecci n, d e l a c u a l Conj unt o y Su-
ces i n s o n d o s s u b c l a s e s .
El o b j e t o sel f (p r o p i o ) e s e l e l e m e n t o d e l d i a g r a m a UML e n c u yo c o n t e x t o s e e va -
l u a r l a e x p r e s i n OCL . Se p u e d e n o b t e n e r o t r o s o b j e t o s a l navegar u s a n d o e l s m -
b o l o . (p u n t o ) d e l o b j e t o sel f. Po r e j e m p l o :
Si sel f e s c l a s e C, c o n a t r i b u t o a, e n t o n c e s self.a e va l a a l o b j e t o a l m a c e n a d o
e n a.
Si C t i e n e u n a a s o c i a c i n m u l t vo c a l l a m a d a asoc c o n o t r a c l a s e D, e n t o n c e s
seif.aeoc e va l a u n Conj unt o c u yo s e l e m e n t o s s o n d e l t i p o D.
. Fi n a l m e n t e (y u n p o c o m s s u t i l ) , si D t i e n e u n a t r i b u t o b, e n t o n c e s l a e x p r e -
s i n self.asoc.b e va l a e l c o n j u n t o d e t o d a s l a s b qu e p e r t e n e c e n a t o d a s l a s D.
5 Est a s e c c i n e s u n a a p o r t a c i n d e l p r o f e s o r Ti m o hv L et hb r i d g e, d e l a Un i ve r s i d a d d e Ot t a w a , y s e
p r e s e n t a a qu m e d a t e a u t o r i za c i n
TM
PDF Editor
El OCL p r o p o r c i o n a o p e r a c i o n e s c o n s t r u i d a s qu e i m p l e m e n t a n l a s m a t e m t i c a s
d e s c r i t a s e n l a s e c c i n 28. 2, y m s . En l a t a b l a 28. 1 s e p r e s e n t a u n a p e qu e a m u e s -
t r a d e e s t a s o p e r a c i o n e s .
TAB L A 2 8 . 1 RESUMEN DE NOT AC I N CL AVE OCL
No t a c i n OCL Si gni f i c ado
x . y Ob t i e n e l a p r o p i e d a d y d e l o b j e t o x . Un o p r o p i e d a d p u e d e se?
u n a t r i b u t o , el c o n j u n t o d e o b j e t o s a l f i n a l d e u n a a s o c i a c i n ,
el r e s u l t a d o d e e vo l u a r u n a o p e r a c i n u o t r a s c o s a s qu e d e p e -
d a n d e l t i p o d e d i a g r a m a UML . Si x e s u n Co n j u n t o , e n t o n c e ;
y s e a p l i c a a to d o e l e m e n t o d e x ; l o s r e s u l t a d o s s e j u n t an e n i -
n u e vo Co n j u n t o .
c - > 1 Ap l i c a l a o p e r a c i n OCL i n c o r p o r a d a f a l a Co l e c c i n c m is-
m a (en o p o s i c i n a c a d o u n o d e l o s o b j e t o s e n c ) . L o s e j e m p l o :
d e o p e r a c i o n e s i n c o r p o r a d a s s e p r e s e n t a n l n e a s a b a j o .
y, o r , =, O
y l g i c a , o l g i c a , i g u a l , n o i g u a l .
p i m p l i e s q Ve r d a d e r o si q e s ve r d a d e r a o p e s f a l s a .
Mue s t r a d e o p e r a c i o n e s s o b r e c ol e c c i o ne s ( i ncl uye c onj unt os y s e c ue nc i a s )
c - >s i ze ( ] Nm e r o d e e l e m e n t o s e n l o Co l e c c i n c .
c - >e s Em p t y| ) Ve r d a d e r o si c n o t i e n e e l e m e n t o s , f a l s o d e c u a l qu i e r o t r o m o -
d o .
e l > i n c 1 u d esAI l (c 2) Ve r d a d e r o si t o d o e l e m e n t o d e c 2 s e e n c u e n t r a e n c 1.
e l ->e x c l u d e s AII(c 2| Ve r d a d e i o si n i n g n e l e m e n t o d e c 2 s e e n c u e n t r a e n e l .
e l ->f o r AII(e l e m 1 b o o l e x p r ) Ve r d a d e r o si b o o l e x p r e x p r e s i n b o o l e a n a ) e s ve r d a d e r a c u a n -
d o s e a p l i c a a l o d o e l e m e n t o d e c . Co n f o r m e s e e va l a u n e l e -
m e n t o , s e l i g a a l a va r i a b l e e l e m |e l e m e n t o |. qu e s e p u e d e u s a r
e n b o o l e x p r . Esto i m p l e m e n t a c u a n t i f i c a c i n u n i ve r s a l , e s t u d i a -
d a p r e vi a m e n t e .
c ->f o r AII(e l e m l , e e m 2 1 b o o l e x p r l Lo m i s m o qu e a n t e s , e x c e p t o qu e b o o l e x p r s e e va l a p a r a l o -
d o p o s i b l e p a r d e e l e m e n t o s l o m a d o s d e c , i n c l u s o c a s o s d o n -
d e el p a r c o n s i s t e d e l m i s m o e l e m e n t o .
c - > i s u n i qu e |e l e m 1 e x p r | Ve r d a d e r o si e x p r (e x p r e s i n ] e va l a u n va l o r d i f e r e n t e c u a n d o
s e a p l i c a a l o d o e l e m e n t a d e c .
Mue s t r a d e o p e r a c i o n e s e s pe c f i c a s a c onj unt os
s i ->i n t e r s e c l i o n (s 2) El c o n j u n t o d e a qu e l l o s e l e m e n t o s qu e s e e n c u e n t r a n
e n s i y t a m b i n e n s 2.
s i - >u n i o n ( s 2| El c o n j u n t o d e a qu e l l o s e l e m e n t o s qu e s e e n c u e n t r a n
e n s i o e n s 2.
s i ->e x c l u d i n g (x ) El c o n j u n t o s i c o n el o b j e t o x o m i t i d o .
Mue s t r a d e o pe r a c i n e s pe c i f i c a a s e c ue nc i a s
s e q>f i r s t () El o b j e t o qu e e s el p r i m e r e l e m e n t o e n l a s u c e s i n s e q.
TM
PDF Editor
CAPTULO 28 MTODOS FORMAL ES
847
28.5.2 Ejemplo de uso del OCL
En e s t a s e c c i n s e u t i l i za e l OCL p a r a a yu d a r a f o r m a l i za r l a e s p e c i f i c a c i n d e l e j e m -
p l o d e l g e s t o r d e b l o qu e s , i n t r o d u c i d o e n l a s e c c i n 28. 1. 3. El p r i m e r p a s o c o n s i s t e
e n d e s a r r o l l a r u n m o d e l o UML . En e s t e e j e m p l o s e c o m i e n za c o n e l d i a g r a m a d e c l a -
s e d e l a f ig u r a 28. 3. Es t e d i a g r a m a e s p e c i f i c a m u c ha s r e l a c i o n e s e n t r e l o s o b j e t o s i n -
vo l u c r a d o s ; s i n e m b a r g o , s e d e b e n a g r e g a r e x p r e s i o n e s OCL qu e g a r a n t i c e n qu e
qu i e n e s i m p l e m e n t e n e l s i s t e m a c o n o zc a n c o n m a yo r p r e c i s i n qu d e b e n a s e g u r a r
qu e p e r m a n e zc a ve r d a d e r o c o n f o r m e s e d e s a r r o l l e e l s i s t e m a .
L a s e x p r e s i o n e s OCL qu e s e a g r e g a r n c o r r e s p o n d e n a l a s s e i s p a r t e s d e l i n va -
r i a n t e t r a t a d a s e n l a s e c c i n 28. 1,3. Re s p e c t o d e c a d a u n a s e r e p e t i r e l i n va r i a n t e
e n e s p a o l y l u e g o s e b r i n d a r l a c o r r e s p o n d i e n t e e x p r e s i n OCL . Se c o n s i d e r a u n a
b u e n a p r c t i c a o f r e c e r e l t e x t o e n e s p a o l j u n t o c o n l a l g i c a f o r m a l ; ha c e r l o a yu d a
a l l e c t o r a c o m p r e n d e r l a l g i c a , y t a m b i n a p o ya a l o s r e vi s o r e s a d e s c u b r i r e r r o r e s ,
p o r e j e m p l o : s i t u a c i o n e s d o n d e e l e s p a o l y l a l g i c a n o c o r r e s p o n d a n .
1. Ni n g n b l o qu e s e m a r c a r al m i s m o t i e m p o c o m o n o u s a d o y u s a d o .
c o n t e x t Ge s t o r B Io qu e s i n v:
( s e l f . u s a d o s - >i n t e r s e c t i o n ( s e l f . l i b r e s ) ) - > i s Em p t y()
N t e s e qu e c a d a e x p r e s i n c o m i e n za c o n l a p a l a b r a c l a ve c o n tex t (c o n t e x t o ) . Es t o i n -
d i c a e l e l e m e n t o d e l d i a g r a m a UML qu e l a e x p r e s i n r e s t r i n g e . En f o r m a a l t e r n a , el
i n g e n i e r o d e s o f t w a r e p o d r a c o l o c a r l a r e s t r i c c i n d i r e c t a m e n t e e n e l d i a g r a m a
UML , r o d e a d a p o r l l a ve s {). L a p a l a b r a c l a ve sel f s e r e f i e r e a l a i n s t a n c i a d e Gesto r BIo -
qu e s ; e n l o q u e s i g u e , c o m o e s p e r m i s i b l e e n OCL , s e o m i t i r s e l f .
2. To d o s l o s c o n j u n t o s d e b l o qu e s qu e s e m a n t i e n e n e n l a c o l a s e r n s u b c o n j u n -
t o s d e l a c o l e c c i n d e b l o qu e s u s a d o s a c t u a l m e n t e .
c o l a B l o qu e s - >f o r AI I ( a Co n j u n t o B l o qu e s I u s a d o s - >i n c l u d e s AI I ( a Co n j u n t o B l o qu e s ) )
Di a g r a m a d e
c l a s e p a r a u n
g e s t o r d e
b l o q u e s .
TM
PDF Editor
3. Ni n g n n m e r o d e b l o qu e p e r t e n e c e r a d o s o m s e l e m e n t o s d e l a f il a.
c o l a B l o qu e s - >f o r AI I ( c o n j u n t o B l o qu e s l , c o n j u n t o B l o qu e s 2 |
c o n j u n t o B l o qu e s t O c o n j u n t o B l o qu e s 2 m p l i e s
c o n j u n t o B l o q u e s l . e l e m e n t o s , n m e r o > e x c l u d e s AI I ( c o n j u n t o B l o q u e s 2 .
e l e m e n t o s . n m e r o ) )
L a e x p r e s i n a n t e s d e im p lies (i m p l i c a ) e s n e c e s a r i a p a r a a s e g u r a r qu e s e i g n o -
r a n l o s p a r e s d o n d e a m b o s e l e m e n t o s s o n e l m i s m o b l o qu e .
4. L a c o l e c c i n d e b l o qu e s u t i l i za d o s y b l o qu e s s i n u s a r s e r l a c o l e c c i n t o t a l d e
b l o qu e s qu e c o n s t i t u ye n l o s a r c hi vo s ,
a l IB Io o ks = u s a d o s - >u n o n ( l b r e s )
5. L a c o l e c c i n d e b l o qu e s s i n u s a r n o t e n d r n m e r o s d e b l o qu e s d u p l i c a d o s ,
l i b r e s - > s Un i qu e ( a B l o qu e | a B l o qu e . n m e r o )
6. L a c o l e c c i n d e b l o qu e s u t i l i za d o s n o t e n d r n m e r o s d e b l o qu e s d u p l i c a d o s ,
u s a d o s - >i s Un i qu e ( a B l o qu e | a B l o qu e . n m e r o )
El OCL t a m b i n s e u t i l i za p a r a e s p e c i f i c a r p r e c o n d i c i o n e s y p o s c o n d i c i o n e s d e
o p e r a c i o n e s . Po r e j e m p l o , c o n s i d r e n s e l a s o p e r a c i o n e s qu e e l i m i n a n y a g r e g a n
c o n j u n t o s d e b l o qu e s d e l a c o l a . L a n o t a c i n x @p r e i n d i c a qu e e l o b j e t o x e x i s t e an-
tes d e l a o p e r a c i n ; e s t o e s , o p u e s t o a l a n o t a c i n m a t e m t i c a e x p u e s t a c o n a n t e r i o -
r i d a d , d o n d e l a x despu s d e l a o p e r a c i n e s l a qu e e s t d e s i g n a d a e s p e c i a l m e n t e
(c o m o x ' ) .
c o n t e x t Ge s t o r B Io qu e s : :e l i m i n a r B l o qu e s ()
p r e : c o l a B l o qu e s - >s i ze ( ) > 0
p o s t : u s a d o s = u s a d o @p r e - c o l a B l o qu e s @p r e - >f i r s t ( ) a n d
l i b r e s = l i b r e @p r e >u n i o n ( c o l a B l o qu e s @p r e - >f i r s t ( ) a n d
c o l a B l o qu e s = c o l a B l o qu e s @p r e - >e x c l u d n g ( c o l a B l o qu e s @p r e - >f i r s t )
c o n t e x t Ge s t o r B l o qu e s : : a g r e g a r B l o qu e s ( a Co n j u n t o B l o qu e s . -Co n j u n t o B l o qu e s )
p r e : u s a d o s >i n c l u d e s AII( a Co n j u n t o B l o qu e s . e l e m e n t o s )
p o s t : ( c o l a B l o qu e s . e l e m e n t o s = c o l a B l o qu e s . e l e m e n t o s @p r e
- >a p p e n d ( a Co n j u n t o B l o qu e s ) )
a n d u s a d o s = u s a d o @p r e
a n d l i b r e s = l i b r e @p r e
El OCL e s u n l e n g u a j e d e m o d e l a d o , p e r o t i e n e t o d o s l o s a t r i b u t o s d e u n l e n g u a j e f o r -
m a l . Ta m b i n p e r m i t e l a e x p r e s i n d e va r i a s r e s t r i c c i o n e s , p r e c o n d i c i o n e s y p o s c o n -
TM
PDF Editor
CAPITULO 28 MTODOS FORMAL E 849
d i c i o n e s , g u a r d i a s y o t r a s c a r a c t e r s t i c a s qu e r e l a c i o n a n a l o s o b j e t o s r e p r e s e n t a d o s
e n va r i o s m o d e l o s UML .
l o to d
- p u e d e e n c o n t r a i e n
w w -u ser s. f s.
fOfk. iKJik/
- ws o n / o b s / z .
Z e s u n l e n g u a j e d e e s p e c i f i c a c i n qu e ha e vo l u c i o n a d o d u r a n t e l a s d o s d c a d a s p a -
s a d a s y ho y s e u t i l i za a m p l i a m e n t e e n t r e l a c o m u n i d a d d e l o s m t o d o s f o r m a l e s . El
l e n g u a j e Z a p l i c a c o n j u n t o s t i p i f i c a d o s , r e l a c i o n e s y f u n c i o n e s d e n t r o d e l c o n t e x t o d e
p r e d i c a d o s l g i c o s d e p r i m e r o r d e n p a r a c o n s t r u i r esquemas, u n m e d i o p a r a e s t r u c -
t u r a r u n a e s p e c i f i c a c i n f o r m a l .
28.6.1 Breve panorama de la sintaxis y semntica Z
L a s e s p e c i f i c a c i o n e s Z e s t n o r g a n i za d a s c o m o u n c o n j u n t o d e e s qu e m a s ; e s d e c i r ,
u n a e s t r u c t u r a p a r e c i d a a u n r e c u a d r o qu e i n t r o d u c e va r i a b l e s y e s p e c i f i c a l a r e l a -
c i n e n t r e s t a s . Un esquema e s , e n e s e n c i a , l a e s p e c i f i c a c i n f o r m a l a n l o g a d e l
c o m p o n e n t e d e l e n g u a j e d e p r o g r a m a c i n . En l a m i s m a f o r m a qu e l o s c o m p o n e n t e s
s e e m p l e a n p a r a e s t r u c t u r a r u n s i s t e m a , l o s e s qu e m a s s e u t i l i za n a l e s t r u c t u r a r u n a
e s p e c i f i c a c i n f o r m a l .
Un e s qu e m a d e s c r i b e l o s d a t o s a l m a c e n a d o s a l o s qu e u n s i s t e m a a c c e d e y a l t e r a .
En e l c o n t e x t o d e Z e s t o s e d e n o m i n a e l "e s t a d o ". L a u t i l i za c i n d e l t r m i n o estado
e n Z e s l i g e r a m e n t e d i f e r e n t e d e l a qu e s e e m p l e a e n el r e s t o d e e s t e l ib r o . 1" Ad e m s ,
e l e s qu e m a i d e n t i f i c a l a s o p e r a c i o n e s qu e s e a p l i c a n p a r a c a m b i a r e s t a d o y l a s r e l a -
c i o n e s qu e o c u r r e n d e n t r o d e l s i s t e m a . L a e s t r u c t u r a g e n r i c a d e u n e s qu e m a a s u -
m e l a f o r m a :
n o m b r e Es qu e m a -
d e c l a r a c i o n e s
i n va r i a n t e
d o n d e l a s d e c l a r a c i o n e s i d e n t i f i c a n l a s va r i a b l e s qu e c o m p r e n d e n el e s t a d o d e l s i s -
t e m a , y e l i n va r i a n t e i m p o n e r e s t r i c c i o n e s e n l a f o r m a e n l a qu e e l e s t a d o p u e d e e vo -
l u c i o n a r . En l a t a b l a 28. 2 s e p r e s e n t a u n r e s u m e n d e l a n o t a c i n d e l l e n g u a j e Z.
28.6.2 Un ejemplo que utiliza Z
En e s t a s e c c i n s e u t i l i za e l l e n g u a j e d e e s p e c i f i c a c i n Z p a r a m o d e l a r e l e j e m p l o d e l
g e s t o r d e b l o qu e s i n t r o d u c i d o p r e vi a m e n t e e n e s t e c a p t u l o . El s i g u i e n t e e j e m p l o d e
u n e s qu e m a d e s c r i b e el e s t a d o d e l g e s t o r d e b l o qu e s y e l i n va r i a n t e d e d a t o s :
6 Re c u r d e s e qu e e n o t r o s c a p t u l o s estado se e m p l e a p a r a i d e n t i f i c a r u n m o d o d e c o m p o r t a m i e n t o
o b s e r va b l e e x t e r n a m e n t e p a r a u n s i s t e m a
TM
PDF Editor
Ge s t o r B Io qu e s
usados, libres: P BLOQUES
FilaBloques: s e q P BLOQUES
usados n libres = 0 A
usados u libres = TodosBloques A
V;': dom ColaBIoques FilaBloques i c usados A
V/, j: d o m ColaBIoques + j => ColaBIoques i n ColaBIoques j = 0
TAB L A 2 8 . 2 RES UMEN DE NOT AC I N Z
L a n o t a c i n Z s e b a s a e n t e o r a d e c o n j u n t o s t i p i f i c a d a y e n l g i c a d e p r i m e r o r d e n . Z p r o p o r c i o n a u r
c o n s t r u c t o , l l a m a d o e s qu e m a , p a r a d e s c r i b i r e l e s p a c i o y l a s o p e r a c i o n e s d e e s t a d o d e u n a e s p e c i f i c a -
c i n . Un e s qu e m a a g r u p a d e c l a r a c i o n e s d e va r i a b l e c o n u n a l ista d e p r e d i c a d o s qu e r e s t r i n g e n el p o s -
b l e va l o r d e u n a va r i a b l e . En Z el e s qu e m a X s e d e f i n e p o r l a f o r m a
X
p r e d i c a d o s
l a s f u n c i o n e s g l o b a l e s y l a s c o n s t a n t e s s e d e f i n e n p o r l a f o r m a
p r e d i c a d o s
Lo d e c l a r a c i n b r i n d a el t i p o d e l a f u n c i n o c o n s t a n t e , m i e n t r a s qu e el p r e d i c a d o p r o p o r c i o n a su v a b '
En e s t a t a b l a s l o s e p r e s e n t a u n c o n j u n t o a b r e vi a d o d e s m b o l o s Z.
Conj unt os:
S : P X S e s d e c l a r a d o c o m o c o n j u n t o d e Xs.
x e S x e s m i e m b r o d e S.
x $ S x n o e s m i e m b r o d e S.
S CT S e s u n s u b c o n j u n t o d e T: l o d o m i e m b r o d e S t a m b i n e s t e n T.
S u r L a u n i n d e S y T: c o n t i e n e a t o d o m i e m b r o d e S o T o a m b o s .
S n T L a i n t e r s e c c i n d e S y T: c o n t i e n e a t o d o m i e m b r o qu e e s t t o n t o e n S c o m o e n T.
S \ T L a d i f e r e n c i a d e S y T: c o n t i e n e a t o d o m i e m b r o d e S, e x c e p t o a a qu e l l o s qu e t a m b i n
e s t n e n T.
0 Co n j u n t o va c o : n o c o n t i e n e m i e m b r o s .
(x ) Co n j u n t o u n i t a r i o : s l o c o n t i e n e a x .
M El c o n j u n t o d e l o s n m e r o s n a t u r a l e s 0, 1, 2, . . .
S : F X S e s d e c l a r a d o c o m o c o n j u n t o f i n i t o d e X.
m a x (S) El m x i m o d e l c o n j u n t o n o va c o d e n m e r o s S.
Funciones:
f:X >- f e s d e c l a r a d o c o m o u n a i n ye c c i n p a r c i a l d e X a Y.
dom f El d o m i n i o d e f : el c o n j u n t o d e va l o r e s x p a r o l o s c u a l e s e s t d e f i n i d a f (x |.
ron f El r a n g o d e f : el c o n j u n t o d e va l o r e s qu e t o m a f (x | c o n f o r m e x va r a s o b r e el d o m i n i o d e f .
( * i - ) y ) Un a f u n c i n qu e c o n c u e r d a c o n f , e x c e p t o qu e x s e c o r r e l a c i o n a c o n y.
dom f Un a f u n c i n c o m o f , e x c e p t o qu e x e s e l i m i n a d o d e su d o m i n i o .
TM
PDF Editor
CAPTULO 28 MTODOS FORMAL E 851
Lgi ca:
P A Q P y Q: e s ve r d a d e r o si t a n t o P c o m o Q s o n ve r d a d e r o s .
P => Q P i m p l i c a Q: e s ve r d a d e r o si o Q e s ve r d a d e r a o P e s f a l s a .
0 S' = 0 S Ni n g n c o m p o n e n t e d e ! e s qu e m a S c a m b i a e n u n o o p e r a c i n .
Co m o s e ha s e a l a d o , e l e s qu e m a c o n s i s t e d e d o s p a r t e s . L a p a r t e s o b r e l a l n e a c e n -
t r a l r e p r e s e n t a l a s va r i a b l e s d e l e s t a d o , m i e n t r a s qu e l a p a r t e d e b a j o d e l a l n e a c e n -
t r a l d e s c r i b e e l i n va r i a n t e d e d a t o s . Si e m p r e qu e e l e s qu e m a e s p e c i f i c a l a s o p e r a c i o -
n e s qu e c a m b i a n e l e s t a d o l o p r e c e d e e l s m b o l o A. El s i g u i e n t e e j e m p l o d e e s qu e m a
d e s c r i b e l a o p e r a c i n qu e e l i m i n a u n e l e m e n t o d e l a c o l a d e b l o qu e s :
El i m i n a r B l o qu e s
A GestorBloques
#Ge s t o r B l o qu e s > 0,
usados' = usados \ cabeza CoIaBloques A
libres' = libres u cabeza CoIaBloques A
CoIaBloques' = cola CoIaBloques
L a i n c l u s i n d e A GestorBloques r e s u l t a e n t o d a s l a s va r i a b l e s qu e c o n f i g u r a n el e s t a -
d o qu e e s t a r d i s p o n i b l e p a r a e l e s qu e m a EliminarBloques y a s e g u r a qu e el i n va r i a n t e
d e d a t o s s e m a n t e n d r a n t e s y d e s p u s d e qu e l a o p e r a c i n s e ha ya e j e c u t a d o .
L a s e g u n d a o p e r a c i n , qu e a a d e u n a c o l e c c i n d e b l o qu e s a l f in al d e l a c o l a , e s -
t r e p r e s e n t a d a c o m o
Aa d i r B l o qu e s -
A Ge s t o r B l o qu e s
Ab l o qu e s ? : BL OQUES
Abloques? c usados
FilaBloques' = FilaBloques (Ab l o qu e s ?) A
usados' = usados A
libres' = libres A
Po r c o n ve n c i n e n Z, u n a va r i a b l e d e e n t r a d a qu e s e l e e p e r o n o f o r m a p a r t e d e l e s -
t a d o t e r m i n a c o n u n s i g n o d e i n t e r r o g a c i n . Po r e n d e , Ab l o qu e s ?, qu e a c t a c o m o
p a r m e t r o d e e n t r a d a , t e r m i n a c o n u n s i g n o d e i n t e r r o g a c i n .
TM
PDF Editor
Mtodos formales
Obj e t i vo: El o b j e t i vo d e l a s he r r a m i e n t a s d e
l o s m t o d o s f o r m a l e s e s a u x i l i a r a l e qu i p o d e
s o f t w a r e e n l a e s p e c i f i c a c i n y ve r i f i c a c i n d e l a c o r r e c -
c i n .
Me c ni c a : L a m e c n i c a d e l a s he r r a m i e n t a s va r a . En
g e n e r a l , a yu d a n e n l a e s p e c i f i c a c i n y e n l a p r u e b a a u t o -
m t i c a d e l a c o r r e c c i n , u s u a l m e n t e a l d e f i n i r u n l e n g u a j e
e s p e c i a l i za d o p a r a l a p r u e b a d e t e o r e m a s . Mu c ha s he r r a -
m i e n t a s n o s e c o m e r c i a l i za n y s e ha n d e s a r r o l l a d o c o n
p r o p s i t o s d e i n ve s t i g a c i n .
ACL2, d e s a r r o l l a d a e n l a Un i ve r s i d a d d e Te x a s (w w w . c s . u -
^ t e x a s . e d u / u s e r s / m o o r e / a d 2/ ) , e s "t a n t o u n l e n g u a j e
d e p r o g r a m a c i n c o n el qu e p u e d e m o d e l a r s i s t e m a s d e
c m p u t o , c o m o u n a he r r a m i e n t a p a r a a yu d a r l o a p r o -
b a r l a s p r o p i e d a d e s d e d i c ho s m o d e l o s ".
EVES, d e s a r r o l l a d a p o r ORA Ca n a d (w w w . o r a . o n , c a / e -
ve s . ht m l ) , i m p l e m e n t o el l e n g u a j e Ve r d i p a r a e s p e c i f i -
c a c i n f o r m a l y u n g e n e r a d o r d e p r u e b a s
a u t o m a t i za d o .
Un a l i st a e x t e n s a c o n m s d e 9 0 he r r a m i e n t a s d e m t o d o s
f o r m a l e s s e p u e d e e n c o n t r a r e n
ht t p : / / w w w . a f m . s b u . a c . u k/ .
L a d e c i s i n d e u s a r m t o d o s f o r m a l e s e n el m u n d o r e a l n o e s u n a qu e s e t o m e a l a
l i g e r a . B o w a n y Hi n c hl e y [BOW95] ha n a c u a d o "l o s d i e z m a n d a m i e n t o s d e l o s m -
t o d o s f o r m a l e s " c o m o u n a g u a p a r a a qu e l l o s qu e e s t n a p u n t o d e a p l i c a r e s t e i m -
p o r t a n t e e n f o qu e d e l a i n g e n i e r a d e s o f t w a r e . 8
1. Elegirs la notacin apropiada. Pa r a e l e g i r c o n e f i c a c i a d e u n a a m p l i a va r i e d a d
d e l e n g u a j e s f o r m a l e s d e e s p e c i f i c a c i n , u n i n g e n i e r o d e s o f t w a r e d e b e c o n s i -
d e r a r e l vo c a b u l a r i o d e l l e n g u a j e , e l t i p o d e a p l i c a c i n qu e s e e s p e c i f i c a r y l a
a m p l i t u d d e u s o d e l l e n g u a j e .
2. Formalizars pero no en exceso. Po r l o g en er al n o es n ec esar io ap l ic ar l o s m -
t o d o s f o r m a l e s e n t o d o s l o s a s p e c t o s d e u n g r a n s i s t e m a . Aqu e l l o s c o m p o -
n e n t e s c r u c i a l e s p a r a l a s e g u r i d a d s o n l a s p r i m e r a s e l e c c i o n e s , s e g u i d o s p o r
l o s c o m p o n e n t e s c u ya f a l l a n o p u e d e t o l e r a r s e (p o r r a zo n e s d e n e g o c i o s ) .
3. Estimars los costos. L o s m t o d o s f o r m a l e s t i e n e n e l e va d o s c o s t o s d e a r r a n -
qu e . El e n t r e n a m i e n t o d e l e qu i p o , l a a d qu i s i c i n d e he r r a m i e n t a s d e a p o yo y
l a u t i l i za c i n d e c o n s u l t o r e s r e d u n d a e n a l t o s c o s t o s a l i n i c i o . Es p r e c i s o c o n -
s i d e r a r d i c ho s c o s t o s c u a n d o s e e x a m i n a e l r e n d i m i e n t o s o b r e l a i n ve r s i n
a s o c i a d a c o n l o s m t o d o s f o r m a l e s .
7
8
L as he r r a m i e n t a s m e n c i o n a d a s s l o r e p r e s e n t a n u n a m u e s t r a d e e s t a c a t e g o r a . En l a m ayo r a d e
l o s c a s o s , l o s n o m b r e s d e l as m i s m a s s o n m a r c a s r e g i s t r a d a s p o r s u s r e s p e c t i vo s d e s a r r o l l a d o r e s .
Este t r a t a m i e n t o e s u n a ver si n m s a b r e vi a d a d e IBOW95],
TM
PDF Editor
CAP TUL O 2 8 MTODOS FORMAL ES 8 5 3
4. Tendrs un experto en m todos formales a tu disposicin. El e n t r e n a m i e n t o e x -
p e r t o y l a c o n s u l t a r a d e s e g u i m i e n t o s o n e s e n c i a l e s p a r a el x i t o c u a n d o s e
e m p l e a n l o s m t o d o s f o r m a l e s p o r p r i m e r a o c a s i n .
5. No abandonars los m todos tradicionales de desarrollo. Es p o s i b l e , y e n m u -
c ho s c a s o s d e s e a b l e , i n t e g r a r l o s m t o d o s f o r m a l e s c o n m t o d o s c o n ve n c i o -
n a l e s u o r i e n t a d o s a o b j e t o s (p a r t e 2 d e e s t e l i b r o ) . Ca d a u n o t i e n e f o r t a l e za s y
d e b i l i d a d e s . Un a c o m b i n a c i n , s i s e a p l i c a c o n p r o p i e d a d , p u e d e p r o d u c i r e x -
c e l e n t e s r e s u l t a d o s . 9
6. Documentars suficientemente. L o s m t o d o s f o r m a l e s p r o p o r c i o n a n u n m t o -
d o c o n c i s o , s i n a m b i g e d a d e s y c o n s i s t e n t e p a r a d o c u m e n t a r l o s r e qu i s i t o s
d e l s i s t e m a . Si n e m b a r g o , e s r e c o m e n d a b l e qu e u n c o m e n t a r i o e n l e n g u a j e
n a t u r a l a c o m p a e l a e s p e c i f i c a c i n f o r m a l y s i r va c o m o m e c a n i s m o p a r a r e -
f o r za r l a c o m p r e n s i n d e l l e c t o r a c e r c a d e l s i s t e m a .
7. No comprometers los estndares de calidad. "No ha y n a d a m g i c o e n l o s m -
t o d o s f o r m a l e s " [BOW95], y p o r e s t a r a z n d e b e c o n t i n u a r l a a p l i c a c i n d e
o t r a s a c t i vi d a d e s d e SQA (c a p t u l o 26) c o n f o r m e l o s s i s t e m a s s e d e s a r r o l l e n .
8. No sers dogmtico. Un i n g e n i e r o d e s o f t w a r e d e b e r e c o n o c e r qu e l o s m t o -
d o s f o r m a l e s n o r e g a r a n t i za n l a c o r r e c c i n . Es p o s i b l e (a l g u i e n d i r a , p r o b a -
b l e ) qu e e l s i s t e m a f in al , a u n c u a n d o s e d e s a r r o l l e e m p l e a n d o m t o d o s
f o r m a l e s , p u e d e t e n e r p e qu e a s o m i s i o n e s , b u g s m e n o r e s y o t r o s a t r i b u t o s
qu e n o s a t i s f a g a n l a s e x p e c t a t i va s .
9. Probars, probars y probars de nuevo. L a i m p o r t a n c i a d e l a s p r u e b a s d e l s o f t -
w a r e s e ha e s t u d i a d o e n l o s c a p t u l o s 13 y 14. L o s m t o d o s f o r m a l e s n o a b -
s u e l ve n a l i n g e n i e r o d e s o f t w a r e d e l a n e c e s i d a d d e l l e va r a c a b o p r u e b a s
e x t e n s i va s b i e n p l a n e a d a s .
10. Reutilizars. A l a r g o p l a zo , l a n i c a f o r m a r a c i o n a l d e r e d u c i r l o s c o s t o s d e
s o f t w a r e y a u m e n t a r l a c a l i d a d d e s t e e s m e d i a n t e l a r e u t i l i za c i n (c a p t u l o
30) . L o s m t o d o s f o r m a l e s n o c a m b i a n e s t a r e a l i d a d . De he c ho , e s p o s i b l e qu e
l o s m t o d o s f o r m a l e s s e a n u n e n f o qu e a p r o p i a d o c u a n d o s e ha n d e c r e a r
c o m p o n e n t e s p a r a l i b r e r a s d e r e u t i l i za c i n .
Au n qu e l a s t c n i c a s f o r m a l e s d e e s p e c i f i c a c i n b a s a d a s m a t e m t i c a m e n t e n o s e
e m p l e a n c o n a m p l i t u d e n l a i n d u s t r i a , s o f r e c e n ve n t a j a s s u s t a n c i a l e s s o b r e l a s t c -
n i c a s m e n o s f o r m a l e s . L i s ko v y B e r s i n s [L IS86] r e s u m e n e s t o a s :
9 L a i n g e n i e r a d e s o f t w a r e d e s a l a l im p ia (c ap i t u l o 29) e s u n e j e m p l o d e u n e n f o qu e i n t e g r a d o qu e
u t i l i za m t o d o s f o r m a l e s y m t o d o s d e d e s a r r o l l o m s c o n ve n c i o n a l e s .
TM
PDF Editor
PARTE C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
L a s e s p e c i f i c a c i o n e s f o r m a l e s s e p u e d e n e s t u d i a r m a t e m t i c a m e n t e , p e r o n o l a s i n f o r m a -
l e s . Po r e j e m p l o , u n p r o g r a m a c o r r e c t o s e p r u e b a p a r a s a t i s f a c e r s u s e s p e c i f i c a c i o n e s , o
s e p u e d e p r o b a r qu e d o s c o n j u n t o s a l t e r n a t i vo s d e e s p e c i f i c a c i o n e s s o n e qu i va l e n t e s . . .
Ci e r t a s f o r m a s d e i n c o m p l e t u d o i n c o n s i s t e n c i a s e p u e d e n d e t e c t a r a u t o m t i c a m e n t e .
Ad e m s , l a e s p e c i f i c a c i n f o r m a l e l i m i n a l a a m b i g e d a d y a l i e n t a e l m a yo r r i g o r e n
l a s p r i m e r a s e t a p a s d e l p r o c e s o d e i n g e n i e r a d e l s o f t w a r e .
No o b s t a n t e , l o s p r o b l e m a s p e r s i s t e n . L a e s p e c i f i c a c i n f o r m a l s e e n f o c a p r i n c i -
p a l m e n t e e n l a f u n c i n y l o s d a t o s . L a t e m p o r a l i d a d , e l c o n t r o l y l o s a s p e c t o s d e
c o m p o r t a m i e n t o d e u n p r o b l e m a s o n m s d i f c i l e s d e r e p r e s e n t a r . Ad e m s , c i e r t o s
e l e m e n t o s d e u n p r o b l e m a (p o r e j e m p l o , i n t e r f a c e s hu m a n o / m qu i n a ) s e e s p e c i f i -
c a n m e j o r e m p l e a n d o t c n i c a s g r f i c a s o p r o t o t i p o s . Fi n a l m e n t e , l a e s p e c i f i c a c i n
qu e e m p l e a m t o d o s f o r m a l e s e s m s d i f c i l d e a p r e n d e r qu e l o s m t o d o s qu e i n c o r -
p o r a n n o t a c i n UML y r e p r e s e n t a n u n s i g n i f i c a t i vo "c ho qu e c u l t u r a l " p a r a a l g u n o s
p r o f e s i o n a l e s d e l s o f t w a r e .
L o s m t o d o s f o r m a l e s o f r e c e n u n c i m i e n t o p a r a l o s e n t o r n o s d e e s p e c i f i c a c i n qu e
c o n d u c e n a m o d e l o s d e a n l i s i s m s c o m p l e t o s , c o n s i s t e n t e s y s i n a m b i g e d a d e s
qu e a qu e l l o s p r o d u c i d o s c o n m t o d o s c o n ve n c i o n a l e s u o r i e n t a d o s a o b j e t o s . L a s f a -
c i l i d a d e s d e s c r i p t i va s d e l a t e o r a d e c o n j u n t o s y l a n o t a c i n l g i c a p e r m i t e n qu e u n
i n g e n i e r o d e s o f t w a r e c r e e u n p l a n t e a m i e n t o c l a r o d e he c ho s (r e qu i s i t o s ) .
L o s c o n c e p t o s s u b ya c e n t e s qu e r ig en l o s m t o d o s f o r m a l e s s o n 1) e l i n va r i a n t e d e
d a t o s , u n a c o n d i c i n ve r d a d e r a a t r a vs d e l a e j e c u c i n d e l s i s t e m a qu e c o n t i e n e
u n a c o l e c c i n d e d a t o s ; 2) e l e s t a d o , u n a r e p r e s e n t a c i n d e l m o d o d e c o m p o r t a -
m i e n t o o b s e r va b l e e x t e r n a m e n t e d e u n s i s t e m a , o (e n Z y l e n g u a j e s r e l a c i o n a d o s ) l o s
d a t o s a l m a c e n a d o s a l o s qu e u n s i s t e m a t i e n e a c c e s o y a l t e r a ; y 3) l a o p e r a c i n , u n a
a c c i n qu e t i e n e l u g a r e n u n s i s t e m a y l e e o e s c r i b e d a t o s a u n e s t a d o . Un a o p e r a -
c i n e s t a s o c i a d a c o n d o s c o n d i c i o n e s : u n a p r e c o n d i c i n y u n a p o s c o n d i c i n .
L a s m a t e m t i c a s d i s c r e t a s l a n o t a c i n y he u r s t i c a s a s o c i a d o s c o n c o n j u n t o s y
l a e s p e c i f i c a c i n c o n s t r u c t i va , o p e r a d o r e s d e c o n j u n t o s , o p e r a d o r e s l g i c o s y s u c e -
s i o n e s f o r m a n l a b a s e d e l o s m t o d o s f o r m a l e s . L a s m a t e m t i c a s d i s c r e t a s s e i m -
p l e m e n t a n e n e l c o n t e x t o d e l o s l e n g u a j e s f o r m a l e s d e e s p e c i f i c a c i n , t a l e s c o m o
OCL y Z. Es t o s l e n g u a j e s t i e n e n d o m i n i o s t a n t o s i n t c t i c o c o m o s e m n t i c o . El d o m i -
n i o s i n t c t i c o u t i l i za u n a s i m b o l o g a a l i n e a d a d e m a n e r a c e r c a n a c o n l a n o t a c i n d e
c o n j u n t o s y e l c l c u l o d e p r e d i c a d o s . El d o m i n i o s e m n t i c o p e r m i t e qu e e l l e n g u a j e
e x p r e s e l o s r e qu i s i t o s e n u n a f o r m a c o n c i s a .
L a d e c i s i n d e u s a r m t o d o s f o r m a l e s d e b e c o n s i d e r a r l o s c o s t o s d e a r r a n qu e , a s
c o m o l o s c a m b i o s c u l t u r a l e s a s o c i a d o s c o n u n a t e c n o l o g a r a d i c a l m e n t e d i f e r e n t e .
En l a m a yo r a d e l a s i n s t a n c i a s , l o s m t o d o s f o r m a l e s t i e n e n m a yo r e s r e n d i m i e n t o s
r e s p e c t o d e l o s s i s t e m a s c r u c i a l e s p a r a l a s e g u r i d a d y l o s n e g o c i o s .
TM
PDF Editor
CAP TULO 2 8 MTODOS FORMAL ES
855
[B OW9 5] B o w a n , J. P. , y M. G. Hi n c hl e y, ' Te n Co m m a n d m e n t s o f Fo r m a l Me t ho d s ", e n Compu-
ter, vo l . 28, n m . 4, a b r i l d e 19 9 5.
[GRI95J Gr i e s , D. , y F. B. Sc hn e i d e r , A Logical Approach to Discrete Math, Sp r i n g e r -Ve r l a g , 19 9 3.
[GUT93] Gu t t a g , J. V. , y j . J. Ho r n i n g , Larch. Languages and Tools for Formal Specification, Sp r i n -
g e r -Ve r l a g , 19 9 3.
[HAL 90] Hal l , A. , "Se ve n Myt hs o f Fo r m a l Me t ho d s ", e n IEEE Software, s e p t i e m b r e d e 19 9 0, p p .
1 1 - 2 0 .
[HOR85J Ho a r e , C. A. R. , Communicating Sequential Processes, Pr e n t i c e -Ha l l In t e r n a t i o n a l , 19 85.
[IS002] Zformal Specification Notation-Syntax, Type System and Semantics, 1SO/1EC 13568:2002,
In t l . St a n d a r d s Or g a n i za t i o n , 2002.
L FON91] J o n e s , C. B. , Systematic Software Development Using VDM, 2a . e d . , Pr e n t i c e -Ha l l , 19 9 1.
[US86] L i s ko v, B. H. , y V. B e r zi n s , "An Ap p r a i s a l o f Pr o g r a m Sp e c i f i c a t i o n s ", e n Software Specifi-
cation Techniques, N. Ge ha n i y A. T. Mc Ki t t r i c k (e d s . ) , Ad d i s o n -We s l e y, 19 86, p . 3.
[MAR94] Ma r c i n i a k, J. J. (e d . ) Encyclopedia of Software Engineering, Wi l e y, 19 9 4.
IOMG03] "Ob j e c t Co n s t r a i n t L a n g u a g e Sp e c i f i c a t i o n ", e n Unified Modeling Language, v2. 0, Ob -
j e c t Ma n a g e m e n t Gr o u p , s e p t i e m b r e d e 2003, s e p u e d e d e s c a r g a r d e w w w . o m g . o r g .
IROS9 5] Ro s e n , K. H Discrete Mathematics and Its Applications, 3a . e d . , Mc Gr a w -Hi l l , 19 9 5.
(SPI88) Sp i ve y, J. M. , Understanding Z: A Specification Language and Its Formal Semantics, Ca m -
b r i d g e Un i ve r s i t y Pr e s s , 19 88.
[SPI92) Sp i ve y, J. M. , The Z Notation: A Reference Manual, Pr e n t i c e -Ha l l , 19 9 2.
WIL 87) Wi l t a l a , S. A. , Discrete Mathematics: A Unified Approach, Mc Gr a w -Hi l l , 19 87.
[WIN90] Wi n g , J. M. , "A Sp e c i f i e r ' s In t r o d u c t i o n t o Fo r m a l Me t ho d s ", Computer, vo l . 23, n m . 9 ,
s e p t i e m b r e d e 19 9 0, p p . 8-24.
[YOU941 Yo u r d o n , E. , "Fo r m a l Me t ho d s ", Guerrilla Programmer, Cu t t e r In f o r m a t i o n Co r p . , o c t u -
b r e d e 19 9 4.
28. 1. Re vi s a r l o s t i p o s d e d e f i c i e n c i a s a s o c i a d a s c o n l o s e n f o qu e s m e n o s f o r m a l e s p a r a l a i n -
g e n i e r a d e l s o f t w a r e d e l a s e c c i n 28. 1. 1. Of r e c e r t r e s e j e m p l o s d e c a d a u n o a p a r t i r d e l a e x -
p e r i e n c i a p r o p i a .
28. 2. L o s b e n e f i c i o s d e l a s m a t e m t i c a s c o m o m e c a n i s m o d e e s p e c i f i c a c i n s e ha n t r a t a d o e x -
t e n s a m e n t e e n e s t e c a p t u l o . Ex i s t e a l g n a s p e c t o n e g a t i vo ?
28. 3. Us t e d ha s i d o a s i g n a d o a u n e qu i p o qu e e s t d e s a r r o l l a n d o s o f t w a r e p a r a u n f a x m d e m .
Su t a r e a e s d e s a r r o l l a r l a p a r t e d e "d i r e c t o r i o " d e l a a p l i c a c i n . L a f u n c i n d i r e c t o r i o p e r m i t e qu e
a l m a c e n e n ha s t a MaxNombres p e r s o n a s j u n t o c o n l o s a s o c i a d o s d e n o m b r e s d e c o m p a a , n -
m e r o s d e f a x y o t r a i n f o r m a c i n r e l a c i o n a d a . Em p l e a n d o l e n g u a j e n a t u r a l d e f i n a
a) El i n va r i a n t e d e d a t o s
b) El e s t a d o .
c) L a s o p e r a c i o n e s p r o b a b l e s .
28 . 4 . Us t e d ha s i d o a s i g n a d o a u n e qu i p o qu e e s t d e s a r r o l l a n d o s o f t w a r e , l l a m a d o Duplicador
de memoria, qu e o f r e c e m a yo r m e m o r i a a p a r e n t e p a r a u n a PC qu e l a m e m o r i a f sic a. Es t o s e l o -
g r a a l i d e n t i f i c a r , r e c o p i l a r y r e a s i g n a r b l o qu e s d e m e m o r i a qu e s e ha n a s i g n a d o a u n a a p l i c a -
c i n e x i s t e n t e p e r o qu e n o s e u t i l i za n . L o s b l o qu e s n o u t i l i za d o s s e r e a s i g n a n a l a s a p l i c a c i o n e s
qu e r e qu i e r e n m e m o r i a a d i c i o n a l . Co n l a s s u p o s i c i o n e s a p r o p i a d a s y e l u s o d e l e n g u a j e n a t u r a l ,
d e f i n a
a) El i n va r i a n t e d e d a t o s .
b) El e s t a d o .
c) L a s o p e r a c i o n e s p r o b a b l e s
2 8 . 5 . De s a r r o l l e u n a e s p e c i f i c a c i n c o n s i r u c n va p a r a u n c o n j u n t o qu e c o n t i e n e d u p l a s d e n -
m e r o s n a t u r a l e s d e l a f o r m a {x,y, z~ \ t a l e s qu e l a s u m a d e x y y e s i g u a l a z.
TM
PDF Editor
8 5 6 PARTE C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
2 8 . 6 . El i n s t a l a d o r p a r a u n a a p l i c a c i n b a s a d a e n PC d e t e r m i n a p r i m e r o s i e s t n p r e s e n t e s u -
c o n j u n t o a c e p t a b l e d e ha r d w a r e y r e c u r s o s d e l s i s t e m a . Ve r i f i c a l a c o n f i g u r a c i n d e l ha r d w a : ;
p a r a d e t e r m i n a r s i e s t n p r e s e n t e s va r i o s d i s p o s i t i vo s (d e m u c ho s p o s i b l e s d i s p o s i t i vo s ) y d e -
t e r m i n a s i ya e s t n i n s t a l a d a s ve r s i o n e s e s p e c f i c a s d e s o f t w a r e y c o n t r o l a d o r e s d e l s i s t e m a
Qu o p e r a d o r d e c o n j u n t o s e p o d r a u s a r p a r a l o g r a r e s t o ? Of r e c e r u n e j e m p l o e n e s t e c o n -
t e x t o .
28. 7. In t e n t a r d e s a r r o l l a r u n a e x p r e s i n u t i l i za n d o o p e r a d o r e s l g i c o s y d e c o n j u n t o p a r a e l s i -
g u i e n t e e n u n c i a d o : "Pa r a t o d a x ey, s i x e s e l p a d r e eyyy e s e l p a d r e d e z, e n t o n c e s x e s el
a b u e l o d e z. To d o s t i e n e n u n p a d r e . " Su g e r e n c i a : e m p l e a r l a s f u n c i o n e s P(x,y) y G(x , /. ) p a r a r e -
p r e s e n t a r l a s f u n c i o n e s p a d r e y a b u e l o , r e s p e c t i va m e n t e .
28 . 8 . De s a r r o l l a r u n a e s p e c i f i c a c i n c o n s t r u c t i va d e c o n j u n t o d e l c o n j u n t o d e p a r e s d o n d e e l
p r i m e r e l e m e n t o d e c a d a p a r e s l a s u m a d e d o s n m e r o s n a t u r a l e s d i s t i n t o s d e c e r o , y e l s e g u n -
d o e l e m e n t o e s l a d i f e r e n c i a e n t r e l o s m i s m o s n m e r o s . Am b o s n m e r o s d e b e n e s t a r e n t r e 100
y 200, i n c l u s i ve .
2 8 . 9 . De s a r r o l l a r u n a d e s c r i p c i n m a t e m t i c a p a r a e l e s t a d o y e l i n va r i a n t e d e d a t o s d e l p r o -
b l e m a 28. 3. Re f i n a r e s t a d e s c r i p c i n e n e l l e n g u a j e d e e s p e c i f i c a c i n OCL o Z.
28 . 10. De s a r r o l l a r u n a d e s c r i p c i n m a t e m t i c a p a r a e l e s t a d o y e l i n va r i a n t e d e d a t o s d e l p r o -
b l e m a 28. 4. Re f i n a r e s t a d e s c r i p c i n e n e l l e n g u a j e d e e s p e c i f i c a c i n OCL o Z.
28 . 11. Me d i a n t e l a n o t a c i n OCL o Z p r e s e n t a d a s e n l a s t a b l a s 28. 1 o 28. 2, s e l e c c i o n a r a l g u n a
p a r t e d e l s i s t e m a d e s e g u r i d a d HogarSeguro d e s c r i t o p r e vi a m e n t e e n e s t e l i b r o e i n t e n t a r d e s -
c r i b i r l a c o n OCL o Z.
28 . 12. Em p l e a n d o u n a o m s d e l a s f u e n t e s d e i n f o r m a c i n qu e a p a r e c e n e n l a s r e f e r e n c i a s d e
e s t e c a p t u l o o e n "Ot r a s l e c t u r a s y f u e n t e s d e i n f o r m a c i n ", d e s a r r o l l a r u n a p r e s e n t a c i n d e
m e d i a ho r a a c e r c a d e l a s i n t a x i s y l a s e m n t i c a b s i c a s d e u n l e n g u a j e f o r m a l d e e s p e c i f i c a c i n
d i s t i n t o s a OCL o Z.
V* .
Ad e m s d e l o s l i b r o s e m p l e a d o s c o m o r e f e r e n c i a s e n e s t e c a p t u l o , d u r a n t e l a d c a d a p a s a d a
s e p u b l i c a r o n n u m e r o s o s l i b r o s a c e r c a d e t e m a s d e m t o d o s f o r m a l e s . A c o n t i n u a c i n s e p r e -
s e n t a u n a l i s t a d e a l g u n o s d e l o s m s t i l e s :
B o w a n , J. , Formal Specijication and Documentation using Z: A Case Study Approach, In t e r n a -
tio n al Tho m so n Co m p u ter Pr ess, 1996.
Ca s e y, C A Programming Approach lo Formal Methods, Mc Gr a w -Hi l l , 2000.
Cl a r k, T et al. (e d s . ) , Object Modeling with OCL, Sp r i n g e r -Ve r l a g , 2002.
Co o p e r , D y R. B a r d e n , Z in Practice, Pr e n t i c e -Ha l l , 19 9 5.
Cr a i g e n , D. , S. Ge r ha r t y T. Ra l s t o n , Industrial Application of Formal Methods to Model, Design
andAnalyze Computer Systems, No ye s Da t a Co r p . , 19 9 5.
Ha r r y, A. , Formal Methods Fact File: VDMyZ, Wi l e y, 19 9 7.
Hi n c hl e y, M. , y J . B o w a n , Applications of Formal Methods, Pr e n t i c e -Ha l l , 19 9 5.
Hi n c hl e y, M. , y J. B o w a n , Industrial Strenght Formal Methods, Ac a d e m i c Pr e s s , 19 9 7.
Hu s s m a n n , H. , Formal Foundations for Software Engineering Methods, Sp r i n g e r -Ve r l a g , 19 9 7.
J a c ky, J. , The Way of Z: Practical Programming with Formal Methods, Ca m b r i d g e Un i ve r s i t y
Pr e s s , 19 9 7.
Mo n i n , F. , y M. Hi n c hl e y, Understanding Formal Methods, Sp r i n g e r -Ve r l a g , 2003.
Ra n n , D J. Tu r n e r y J. Whi t w o r t h, Z: A Beginner's Guide, Cha p m a n a n d Ha l l , 19 9 4.
Ra t c l i f f , B. , lntroducing Specijication Using Z: A Practical Case Study Approach, Mc Gr a w -Hi l l ,
19 9 4.
TM
PDF Editor
CAP TULO 2 8 MTODOS FORMAL E; 857
She p p a r d , D. , An Introduction to Formal Specification with Z and VDM, Mc Gr a w -Hi l l , 19 9 5.
Wa r n e r , ) . , y A. Kl e p p e , Object Constraint Language, Ad d i s o n -We s l e y, 19 9 8.
De a n (Essence of Discrete Mathematics, Pr e n t i c e -Ha l l , 19 9 6) , Gr i e s y Sc hn e i d e r [GRI93] y L i p s -
c hu l t z y L i p s o n (2000 Solved Problems in Discrete Mathematics, Mc Gr a w -Hi l l , 1991) p r e s e n t a n i n -
f o r m a c i n t i l p a r a qu i e n e s d e b e n a p r e n d e r m s a c e r c a d e l a s b a s e s d e l o s m t o d o s f o r m a l e s .
En In t e r n e t ha y d i s p o n i b l e u n a a m p l i a va r i e d a d d e f u e n t e s d e i n f o r m a c i n a c e r c a d e l o s m -
t o d o s f o r m a l e s . Un a l i s t a a c t u a l i za d a d e r e f e r e n c i a s e n l a Wo r l d Wi d e We b s e p u e d e e n c o n t r a r
e n e l s i t i o We b SEPA:
h t t p : / / w w w . m h h e . c o m / p r e s s m a n .
TM
PDF Editor
C A P T U L O
29
I NGENI ER A DEL SOFTWARE
DE SAL A L IMPIA
C O N C E P T O S
CLAVE
certificacin . . . 8 7 4
especificacin de
tajo de estado . 8 6 6
especificacin
de coja trans-
parente . . . . . . 8 6 6
especificacin de
caja negra . . . . 865
especificacin
de estructura
de cajas 8 6 3
especificacin
funcional . . . . . 8 6 3
estrategi a de
sala limpia . . . . 8 6 0
prueba estadstica
de uso 8 7 3
r e f i n a m i e n t o
de diseo 8 6 7
. . . . 8 6 9
ve r i f i c a c i n . . . . 8 6 7
verificacin
de correccin . . 8 6 8
E
! u s o i n t e g r a d o d e l m o d e l a d o c o n ve n c i o n a l d e i n g e n i e r a d e l s o f t w a r e (y
p o s i b l e m e n t e l o s m t o d o s f o r m a l e s ) , l a ve r i f i c a c i n d e p r o g r a m a s (p r u e -
b a s d e c o r r e c c i n ) y e l SQA e s t a d s t i c o s e ha n c o m b i n a d o e n u n a t c n i c a
qu e p u e d e c o n d u c i r a s o f t w a r e d e c a l i d a d e x t r e m a d a m e n t e a l t a . L a ingeniera de!
software de sala limpia e s u n e n f o qu e qu e r e s a l t a l a n e c e s i d a d d e c o n s t r u i r l a c o -
r r e c c i n e n el s o f t w a r e c o n f o r m e s e d e s a r r o l l a . En l u g a r d e l c l s i c o c i c l o d e a n -
l i s i s , d i s e o , c d i g o , p r u e b a y d e p u r a c i n , el e n f o qu e d e s a l a l i m p i a s u g i e r e u n
p u n t o d e vi s t a d i f e r e n t e [L 1N94]:
L a f il o so f a d e t r s d e l a i n g e n i e r a d e l s o f t w a r e d e s a l a l i m p i a c o n s i s t e e n e vi t a r l a d e -
p e n d e n c i a d e c o s t o s o s p r o c e s o s d e e l i m i n a c i n d e d e f e c t o s al e s c r i b i r l o s i n c r e m e n -
t o s d e c d i g o c o r r e c t o s l a p r i m e r a ve z y ve r i f i c a r s u c o r r e c c i n a n t e s d e p o n e r l o a
p r u e b a . Su m o d e l o d e p r o c e s o i n c o r p o r a l a c e r t i f i c a c i n e s t a d s t i c a d e c a l i d a d d e l o s
i n c r e m e n t o s d e c d i g o c o n f o r m e s e a c u m u l a n e n el s i s t e m a .
En m u c ho s a s p e c t o s , el e n f o qu e d e s a l a l i m p i a e l e va l a i n g e n i e r a d e s o f t w a -
r e a o t r o n i ve l . Al i g u a l qu e l o s m t o d o s f o r m a l e s p r e s e n t a d o s e n el c a p t u l o 28,
el p r o c e s o d e s a l a l i m p i a d e s t a c a el r i g o r e n l a e s p e c i f i c a c i n y el d i s e o , y l a
ve r i f i c a c i n f o r m a l d e c a d a e l e m e n t o d e d i s e o m e d i a n t e p r u e b a s d e c o r r e c c i n
c o n b a s e s m a t e m t i c a s . Al e x t e n d e r el e n f o qu e a d o p t a d o e n l o s m t o d o s f o r -
m a l e s , el e n f o qu e d e s a l a l i m p i a t a m b i n r e s a l t a l a s t c n i c a s p a r a el c o n t r o l
e s t a d s t i c o d e l a c a l i d a d , i n c l u s o p r u e b a s qu e s e b a s a n e n el u s o a n t i c i p a d o d el
s o f t w a r e p o r p a r t e d e l o s c l i e n t e s .
Cu a n d o e l s o f t w a r e f a l l a e n el m u n d o r e a l , a b u n d a n l o s p e l i g r o s i n m e d i a t o s
y a l a r g o p l a zo . L o s p e l i g r o s s e r e l a c i o n a n c o n l a s e g u r i d a d hu m a n a , l a s p r d i -
d a s e c o n m i c a s o l a o p e r a c i n e f e c t i va d el n e g o c i o y l a i n f r a e s t r u c t u r a s o c i a l .
L a i n g e n i e r a d e l s o f t w a r e d e s a l a l i m p i a e s u n m o d e l o d e p r o c e s o qu e e l i m i n a
l o s d e f e c t o s a n t e s d e qu e p u e d a n g e n e r a r p e l i g r o s s e r i o s .
Qu e s ? Cu n t a s ve c e s s e ha
e s c u c ha d o l a e x p r e s i n : "Ha zl o b i e n
l a p r i m e r a ve z"? Esa e s l a f i l o s o f a
p r i m o r d i a l d e l a i n g e n i e r a d e l s o f t -
w a r e d e s a l a l i m p i a : u n p r o c e s o qu e
d e s t a c a l a ve r i f i c a c i n m a t e m t i c a d e l a c o r r e c -
c i n a n t e s d e qu e c o m i e n c e n l a c o n s t r u c c i n d e l
p r o g r a m a y l a c e r t i f i c a c i n d e l a c o n f i a b i l i d a d
d e l s o f t w a r e c o m o p a r t e d e l a a c t i vi d a d d e p r u e -
b a s . El r a s g o f u n d a m e n t a l e s t a s a s d e f al l a
e x t r e m a d a m e n t e b a j a s qu e s e r a n d i f c i l e s
i m p o s i b l e s d e l o g r a r e m p l e a n d o m t o d o s m e r
f o r m a l e s . ;
Qui n lo hace? Un in g en ier o d e so f tw ar e
e s n e r i n l m f -i l t e f tn tr en o d o
O
m e n o s
Por qu e s i mportante? L o s er r o r es im p l ic an
l a r e e l a b o r a c i n . sta l l e va t i e m p o y a u m e n t a
l o s c o s t o s . No s e r a a g r a d a b l e si s e p u d i e s e
r e d u c i r s u s t a n c i a l m e n t e e l n m e r o d e e r r o r e s
(b u g s ) i n t r o d u c i d o s c o n f o r m e el s o f t w a r e s e d i s e -
TM
PDF Editor
CAPTULO 29 INGENIERA DEL SOFTWARE IX SALA LIMPIA
859
a y construye? Esa es la premisa de la ingenie-
ra del software de sala limpia.
Cules son los pasos? tos modelos de anli-
sis y diseo se crean empl eando una represen-
tacin de estructura de cajas. Una "caja" encap-
sula el sistema {o a cierto aspecto del sistema) en
un gr ado especfico de abstraccin. La verifica-
cin de la correccin se aplica una vez que est
completo el diseo de la estructura de caj as.
Una vez verificada la correccin de cada estruc-
tura de caj a comienzan las pruebas estadsticas
de utilizacin. El software se prueba ai definir un
conjunto de escenarios de utilizacin, al deter-
minar la probabil idad de utilizacin par a cada
escenario y luego definir pruebas aleatorias que
concuerden con las probabilidades. Los registros
de error resultantes se anal izan par a permitir el
clculo matemtico de la fiabilidad proyectada
dei componente de software.
Cul es el producto obtenido? Se desarro
lian especificaciones de caj a negra, caj a de
estado y caj a transparente. Los resultados de las
pruebas de correccin formales y de las pruebas
estadsticas de utilizacin se registran.
hecho correctamente? La prueba formal de
correccin se aplica a la especificacin de
estructura de caj as. Las pruebas estadsticas de
utilizacin ejercitan los escenarios de utilizacin
par a garant i zar que los errores en la funcionali-
dad de usuario se descubren y corrigen. Los
datos de prueba se utilizan para proporcionar
un indicio de la fiabilidad del software.
2 9 . 1 EL ENFOSUF. DE SALA LI MPI A
La filosofa de la "sal a l i mpi a" en l as t ecnol og as de f abr i caci n de ha r dwa r e e n r ea-
l idad e s ba s t a nt e simple-, es ef i caz en c ua nt o a cos t o y t i empo par a es t abl ecer un
e nf oque de fabri caci n que evi t e la i nt r oducci n de def ect os de pr oducci n. Ms que
f abr i car un pr oduct o y l uego t r abaj ar par a el i mi nar l os def ect os, el enf oque de sal a
l i mpi a d e ma n d a la di sci pl i na r equer i da par a el i mi nar l os er r or es en la especi f i caci n
y el di s eo y l uego f abr i car l o en una f or ma "l impia".
Mills, Dyer y Linger [MIL87] pr opusi er on, dur a nt e el deceni o de 1 980, ori gi nal -
me nt e la filosofa de sal a l i mpi a par a la i ngeni er a del s of t war e. Aunque l as pr i me-
r a s exper i enci as con es t e e nf oque di sci pl i nado r es pect o al t r a ba j o de s of t war e f ue-
r on si gni f i cat i vament e pr ome t e dor a s [HAU94], n o obt uvo gr a n di f usi n. Hender s on
[HEN95] sugi er e t r es posi bl es r a z ones :
1. Una cr eenci a de que la met odol og a de sal a l impia e s d e ma s i a d o t er i ca, de-
ma s i a do ma t e m t i c a y de ma s i a do radi cal par a apl i carl a en el desar r ol l o de
s of t war e real .
2. No a boga por una pr ue ba uni t ar i a de par t e de l os desar r ol l ador es, s i no que la
sust i t uye con la veri fi caci n de la cor r ecci n y el cont rol est ad st i co de la cal i -
dad, concept os que r epr es ent an una gr an desvi aci n de la f or ma en la que se
desar r ol l a a ct ua l ment e la mayor a del s of t war e.
3. La ma d ur e z de la i ndust ri a de des ar r ol l o del s of t war e. La ut i l i zaci n de l os
pr oces os de sal a l impia r equi er e la rigurosa apl i caci n de pr oces os def i ni dos
en t oda s l as f as es del ci cl o de vi da Da do que gr an par t e de la i ndust ri a cont i -
TM
PDF Editor
na ope r a ndo en gr ados r el at i vament e ba j os de ma d ur e z del pr oces o, l os in-
geni er os de s of t wa r e no han e s t a do l i st os par a apl i car l as t cni cas de sal a
l i mpi a.
A pes ar de l os el ement os de ver dad en ca da una de e s t a s pr eocupaci ones , l os bene
fi ci os pot enci al es de la i ngeni er a del s of t wa r e de sal a l impia s upe r a n con mu c h o la
i nversi n r equer i da par a s uper ar la r esi st enci a cul t ural ubi cada e n el cent r o de est a?
pr eocupaci ones .
"La nico f or ma de q ue en un pr ogr a ma ocur r an los er r or es es que un aut or los col oque ah . No s e conocen ot r os
me c a ni s mos . . . Ln prctica correct a busca evi t ar la insercin de er r or es y, cua ndo se f al l a al r espect o, el i mi narl os ant es
de pr obar l o o cual qui er a ot r a f or ma de ej ecut ar el pr ogr a ma . "
H ar an M ills
29.1 .1 La estrategia de sal a limpia
El e nf oque de sal a l impia utiliza una ver si n especi al i zada del model o de pr oces e
i ncr ement al (cap t ul o 3). Medi ant e pe q ue os equi pos de s of t wa r e i ndependi ent es se
desar r ol l a una "lnea de i nc r e me nt os de s of t wa r e" [LIN94|. Conf or me ca da i ncre-
me n t o s e cert i fi ca s e i nt egr a en el t odo. Por ende, la f unci onal i dad del s i s t ema crece
con el t i empo.
En la figura 29. 1 s e i l ust ra la s uces i n de l as t a r e a s de sal a l i mpi a par a ca da incre-
ment o. Los r equi si t os gl obal es del si st ema o pr oduct o s e desar r ol l an e mpl e a ndo l os
Modelo del
proceso de
sal a limpia.
Incremento 1
I
IS = i ngeni er a d e si st emas
RR = recopi l aci n de requisitos
EEC = especi fi caci n d e estructura de ca j a s
DF = di seo formal
VC = verificacin de correcci n
GC = gener aci n d e cdi go
IC = i nspecci n de cdi go
PEU = pr ueba estad stica de uso
C = certificacin
PP = pl aneaci n de pr uebas
TM
PDF Editor
CAPTULO 29 INGENIERA DEL SOFTWA3E DE SALA LIMPIA
861
Cules son
f as principa-
les t areas l l ev a-
te a cabo como
M rte de la i nge-
e r a del s o f t w a -
re de sal a limpia?
f . nfomwcii y
xursosp
rgenieifo d
- soto l impio s e pueri l
contrai e n www.
-ansoft.tom.
m t odos de i ngeni er a del s of t wa r e es t udi a dos en el cap t ul o 6. La l nea de i ncre-
me nt os de sal a l impia se inicia una vez que la f unci onal i dad s e ha a s i gna do al el e-
me n t o de s of t wa r e del si st ema. Se pr oducen l as si gui ent es t ar eas:
Pl ani f i caci n de l i nc r e me nt o . Se desar r ol l a un pl an de pr oyect o que adopt a la
est r at egi a i ncr ement al . Se cr ea n la f unci onal i dad de ca da i ncr ement o, su t a ma o
pr oyect ado y un pl an de desar r ol l o de sal a l i mpi a. Se de be t ener especi al cui da do
par a as egur ar q u e l os i nc r e me nt os cer t i f i cados se i nt egr ar n en f or ma opor t una.
Re c o pi l ac i n d e r e qui s i t os . Medi ant e t cni cas si mi l ar es a l as i nt r oduci das en
el cap t ul o 7 s e el abor a una descr i pci n m s det al l ada de l os r equi si t os del cl i ent e
(para ca da i ncr ement o) .
Es pe c i f i c ac i n d e l a e s t r uc t ur a d e c aj as . Se ut i l i za un m t odo de especi f i ca-
ci n que e mpl e a estructuras de caja [HEV93] par a descri bi r la especi f i caci n f unci o-
nal . Para aj us t ar s e a l os pr i nci pi os de anl i si s oper at i vo t r at ados en l os cap t ul os 5 y
7, l as es t r uct ur as de c a j a s "ai sl an y s e pa r a n la def i ni ci n cr eat i va de c ompor t a mi e n-
to, da t os y pr ocedi mi ent os en c a da gr ado de r ef i nami ent o".
Di s e o f or mal . Empl e a ndo el e nf oque de est r uct ur a de caj as el di s eo de sal a
l impia es una ext ens i n nat ur al y uni f or me de la especi f i caci n. Aunque e s posi bl e
es t abl ecer una di st i nci n cl ar a ent r e l as dos act i vi dades, la es peci f i caci ones (l l ama-
da s cajas negras) s on i t er at i vament e r ef i nadas ( dent r o de un i ncr ement o) par a vol-
ver se a n l oga s a l os di s eos ar qui t ect ni co y al nivel de c ompone nt e ( l l amados cajas
de estado y cajas transparentes, r espect i vament e) .
Veri f i caci n d e l a c o r r e c c i n. El equi po de sal a l impia l l eva a c a b o una seri e
de r i gur osas act i vi dades de veri fi caci n de la cor r ecci n en el di s eo y l uego en el
cdi go. La veri fi caci n ( secci ones 29. 3 y 29.4) c omi e nz a con la est r uct ur a de caj a de
nivel super i or (especi fi caci n) y se mue ve haci a el det al l e de di s eo y el cdi go. El
pr i mer nivel de veri fi caci n de cor r ecci n ocur r e al apl i car un c onj unt o de "pr egun-
t as de cor r ecci n" [LIN88J. Si s t a s no de mue s t r a n que la especi f i caci n e s cor r ect a
s e e mpl e a n m t odos m s f or mal es ( mat emt i cos) en la veri fi caci n.
Ge ne r a c i n d e c di g o , i n s pe c c i n y v e r i f i c ac i n. Las es peci f i caci ones de
est r uct ur a de caj a, r e pr e s e nt a da s en un l enguaj e especi al i zado, s e t r aducen al l en-
guaj e d e pr ogr a ma ci n apr opi ado. Ent onces s e ut i l i zan c ompr oba c i one s ma nua l e s
e s t nda r o t cni cas de i nspecci n (cap t ul o 26) que ga r a nt i z a n la conf or mi dad
s emnt i ca del cdi go y l as es t r uct ur as de caj as, as c o mo la cor r ecci n si nt ct i ca del
cdi go. Luego s e l l eva a c a bo la veri fi caci n de la cor r ecci n par a el cdi go f uent e.
"La ingenier a del sof tw are de sal a l i mpi o l ogr a el cont rol est ad st i co de l a cal i dad s obr e el desar r ol l o del sof tw are al
separar estrictamente el proceso de diseo del proceso de pr ueba en una l nea de desar r ol l o i ncr ement al de sof tw are."
H ar an M ills
Pl ani f i c ac i n d e pr ue ba s e s t ad s t i c as . Se anal i za el us o pr oyect ado del sof t -
wa r e y s e pl ani fi ca y di sea un c onj unt o de c a s os de pr ueba que ej er ci t an una "dis-
TM
PDF Editor
862
PARTE CINCO TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
^ O N S U O ^ -
La sala limpia destoco
las pruebas que
ejercitan lo forma en
que el softwore es
realmente utilizado.
Los cosos de uso
ofrecen uno introduc-
cin al proceso de
planeacin de
pruebas.
t ri buci n de pr obabi l i dad" de ut i l i zaci n (secci n 29. 4). Como s e mue s t r a en la figu-
r a 29. 1 , es t a act i vi dad de sal a l i mpi a s e l l eva a c a b o en par al el o con la especi fi ca-
ci n, la veri fi caci n y la gener aci n d e cdi go.
Pr ue ba e s t ad s t i c a d e l a ut i l i zaci n. Como s e r ecor dar , la pr ue ba exhaust i -
va del s of t wa r e de c omput a dor a e s i mposi bl e (cap t ul o 1 4), por lo que s i empr e e<
neces ar i o di s ear un n me r o finito de c a s os de pr ueba. Las t cni cas est ad st i cas de
ut i l i zaci n [POO88] ej ecut an una ser i e de pr ue ba s der i vadas de una mue s t r a est a-
dstica (la di st ri buci n de pr obabi l i dad a not a da pr evi ament e) de t oda s l as posi bl es
ej ecuci ones de pr ogr a ma por par t e de t odos l os us uar i os a part i r de una pobl a d or
obj et i vo (secci n 29. 4).
Cert i f i caci n. Una vez c ompl e t a da s la veri fi caci n, la i nspecci n y l as pr uebas
de ut i l i zaci n (y de que t odos l os er r or es ha ya n si do cor r egi dos) , el i nc r e me nt o se
cert i fi ca l i st o par a la i nt egr aci n.
Al igual que ot r os model os de pr oces o de s of t war e t r at ados en ot r as par t es de est e
libro, el pr oces o de sal a limpia s e apoya s us t anci al ment e en la necesi dad de produci r
anl i si s de al t a cal i dad y model os de di seo. Como s e ver m s adel ant e e n est e cap -
tul o, la not aci n de est r uct ur a de c a j a s e s s i mpl e me nt e ot r a f or ma en la que un i nge
ni er o de s of t wa r e pue de r epr es ent ar l os r equi si t os y el di seo. La di st i nci n real dei
enf oque de sal a l i mpi a e s que la veri fi caci n f or mal s e apl i ca a l os mode l os de i nge-
ni er a.
\
CLAVE
Los ms importantes
coracteristicas
distintivos de lo solo
limpio son lo prueba
de la correccin y las
s estadsticas de
29.1 .2 Qu hace diferente a la sal a limpia?
Dycr [DYE92] al ude a l as di f er enci as del enf oque de sal a l i mpi a c ua nd o def i ne el pr o-
ceso:
La sala limpia represent a el pri mer i nt ent o prctico de somet er el proceso de desarrol l o de
soft ware al control estadstico de la calidad con una estrategia bien definida para la me-
jora cont i nua de los procesos. Con el fin de al canzar est a met a se defini un ciclo de vida
ni co de sala limpia, el cual se enfoca en la ingeniera del soft ware basada en mat emt i -
cas para corregir di seos de sof t war e y en la prueba de sof t war e basada en est ad st i cas
para la certificacin de la fiabilidad del soft ware.
La i ngeni er a del s of t war e de sal a l impia di fi ere de l os m t odos convenci onal es y
or i ent a dos a obj et os de la i ngeni er a del s of t wa r e por que:
1. Empl ea en f or ma expl ci t a el cont rol est ad st i co de la cal i dad.
2. Verifica l as es peci f i caci ones del di s eo ut i l i zando una pr ue ba de cor r ecci n ba-
s a da ma t e m t i c a me nt e .
3. I mpl ement a t cni cas de pr ueba con una al t a pr obabi l i dad de descubr i r er r or es
de al t o i mpact o.
Obvi ament e, el e nf oque de sal a l i mpi a apl i ca la mayor a, si no t odos, l os pr i nci pi os
y concept os bs i cos de la i ngeni er a del s of t war e pr e s e nt a dos a lo l argo de es t e libro.
TM
PDF Editor
Los bue nos anl i si s y pr ocedi mi ent os de di s eo s on es enci al es si se qui er e obt ener
al t a cal i dad. Per o la i ngeni er a de sal a l i mpi a di fi ere de l as pr ct i cas del s of t wa r e
convenci onal por que le r est a i mpor t anci a ( al gunos di r an, el i mi na) al papel de la
pr ueba uni t ar i a y la depur aci n y r educe dr s t i ca ment e (o el i mi na) la cant i dad de
pr ueba s que r eal i za el desar r ol l ador del sof t war e. 1
En el desar r ol l o de s of t war e convenci onal l os er r or es se acept an c omo un he c ho
inel udibl e. Pues t o que l os er r or es est n c onde na dos a ser i nevi t abl es, ca da compo-
ne nt e de pr ogr a ma debe pr obar s e en f or ma individual (para descubr i r l os errores) y
l uego depur ar s e (para el i mi nar l os errores). Cua ndo finalmente s e libera el sof t war e,
dur ant e su ut i l i zaci n se descubr en t odav a m s def ect os y comi enz a ot r o ciclo de
pr ueba y depur aci n. La r eel abor aci n as oci ada con di chas act i vi dades es cos t os a y
c ons ume muc ho t i empo. Peor an, puede resul t ar degener at i va: la cor r ecci n de erro-
res tal vez conduz ca (i nadvert i dament e!) a la i nt roducci n de m s er r or es t odav a.
"Un aspect o curioso de lo vida es que si t e r ehusas en absol ut o a acept ar lo mej or con f r ecuenci a lo obt i enes . "
W . S omerset M augham
En la i ngeni er a del s of t wa r e de sal a l impia la pr ue ba uni t ar i a y la depur aci n s e
sust i t uyen ver i f i cando la cor r ecci n y l as pr ue ba s ba s a d a s en est ad st i cas. Di chas
act i vi dades, c ombi na d a s con la cons er vaci n de r egi st r os neces ar i a par a la mej or a
cont i nua, ha cen q u e el enf oque de sal a l impia s ea ni co.
2 9 . 2 ES P ECI F I CACI N FUNCI ONAL
Sin i mpor t ar el m t odo de anl i si s el egi do, se apl i can l os pr i nci pi os de anl i si s ope -
r at i vo pr e s e nt a dos en el cap t ul o 7. Los dat os, l as f unci ones y el c ompor t a mi e nt o s e
model an. Los mode l os que s e obt i enen d e be n par t i ci onar se (refi narse) par a pr opor -
ci onar cada vez mayor det al l e. El obj et i vo gl obal es mover s e de s de una especi f i ca-
ci n (o model o) que ca pt ur e la esenci a de un pr obl ema hast a una especi f i caci n que
of r ezca s us t anci al es det al l es de i mpl ement aci n.
La i ngeni er a del s of t wa r e de sal a l impia cumpl e con l os pr i nci pi os de anl i si s
oper at i vo e mpl e a nd o un m t od o l l a ma do especificacin de estructura de cajas. Una
"caj a" enca ps ul a al s i s t ema (o al gn a s pe c t o de st e) en al gn gr a do de det al l e. Por
medi o de un pr oces o de el abor aci n o r ef i nami ent o en ni vel es, l as c a j a s s e r ef i nan
en una j er ar qu a d ond e ca da una t i ene t r ans par enci a referenci al . Est o es: "el cont e-
ni do de i nf or maci n de ca da especi f i caci n de caj a es suf i ci ent e par a defi ni r su refi-
nami ent o, sin de pe nde r de la i mpl ement aci n de al guna ot ra caj a" [LIN94], Est o le
per mi t e al anal i st a part i r un s i s t ema j er r qui cament e, move r s e de s de la r epr es ent a-
ci n esenci al e n la par t e super i or haci a un det al l e espec f i co de la i mpl ement aci n
en el f ondo. Se ut i l i zan t r es t i pos de caj as:
1 La prueba la realiza un equipo de prueba independiente.
TM
PDF Editor
Cmo s e
logra el ref i-
nami ento como
parte de una
especif icacin de
estructura de
cajas?
\
CLAVE
El refinomiento de l a
e s t r u c t u r o d e c o j o s y l a
verificacin de la
correccin ocurren
simultneamente.
Caja ne gr a. La caj a negr a especi f i ca el c ompor t a mi e nt o de un s i s t ema o de una
par t e de st e. El s i s t ema (o par t e de l) r e s ponde a es t mul os espec f i cos (event os) al
apl i car un conj unt o de r egl as de t r ansi ci n que cor r el aci onan el est mul o con una
r es pues t a.
Caj a d e e s t a do . La caj a de es t ado enca ps ul a l os dat os de e s t a do y ser vi ci os (ope-
raci ones) en una f or ma a nl oga a l os obj et os. En est a vi si n de especi f i caci n se
r epr es ent an l as e nt r a da s a la caj a de es t ado (est mul os) y l as s al i das ( r espuest as) . La
caj a de e s t a do t ambi n r epr es ent a la "hi st ori a de est mul o" de la ca j a negr a, es t o es
l os da t os e nc a ps ul a dos en la caj a de e s t a do que d e be n cons er var s e ent r e l as t ransi -
ci ones i mpl i cadas.
Caj a t r ans par e nt e . Las f unci ones de t r ansi ci n que i mpl i ca la caj a de e s t a do s e
def i nen en la caj a t r ans par ent e. Enunci ado de ma ne r a si mpl e, una caj a t r ans par en-
t e cont i ene el di s eo de pr ocedi mi ent o par a la caj a de est ado.
La figura 29. 2 i l ust ra el enf oque de r ef i nami ent o e mpl e a nd o la especi f i caci n de
est r uct ur a de caj as . Una caj a negr a (CN,) def i ne r es pues t a s par a un conj unt o com-
pl et o de est mul os. CN, s e pue de r ef i nar en un conj unt o de c a j a s negr as , CN, ., hast a
CN, ca da una de l as cual es abor da una cl ase de compor t a mi ent o. El r ef i nami ent o
cont i na ha s t a que s e i dent i fi ca una cl ase cohesi va de c ompor t a mi e nt o (por ej em-
pl o, CN,.,.,). Ent onces s e def i ne una caj a de es t ado (CE, , , ) par a la caj a negr a ( CN, , , )
En est e cas o, CE,.,., cont i ene t odos l os da t os y ser vi ci os que s e r equi er en pa r a i mpl e-
ment a r el compor t a mi ent o que def i ne CN,.,.,. Fi nal ment e, CE,.,., s e r ef i na e n caj as
t r a ns pa r ent es ( C T , y s e especi f i can l os det al l es de di s eo del pr ocedi mi ent o.
Conf or me ocur r e ca da u n o de es t os pa s os de r ef i nami ent o, t ambi n ocur r e la
veri fi caci n de la cor r ecci n. Las es peci f i caci ones de caj a de e s t a do se veri fi can par a
R e f i n a mi e n t o
de est ruct ura
de caj as .
TM
PDF Editor
CAPTULO 29 INGENIERA DEL SOFTWARE DE SALA LIMPIA
865
Especificacin
de c a j a negr a.
f: S* R f: S* R
gar ant i zar que ca da u n o concuer da con el c ompor t a mi e nt o def i ni do por la especi fi -
caci n pa dr e de caj a negr a. De i gual modo, l as es peci f i caci ones de caj a t r ans par en-
t e s e veri fi can cont r a la caj a de e s t a do padr e.
Se debe not ar que l os m t od os de especi f i caci n ba s a d os en l enguaj es c o mo OCL
o Z (cap t ul o 28) e s posi bl e us ar l os e n conj unci n con el e nf oque de especi f i caci n
de est r uct ur a de caj as . El ni co r equi si t o es que ca da gr ado de especi f i caci n s ea
veri fi cabl e f or ma l ment e.
29.2.1 Especificacin de caj a negra
Una especificacin de caja negra descr i be una abst r acci n, es t mul os y r es pues t a
medi a nt e la not aci n mos t r ada en la figura 29. 3 [MIL88J. La f u n c i n / s e apl i ca a una
sucesi n, S*, de e nt r a da s (est mul os), S, y l as t r ans f or ma en una sal i da ( r espuest a) ,
R. Respect o a c ompone nt e s de s of t wa r e s i mp l e s / p u e d e ser una f unci n ma t emt i -
ca, per o, en g e n e r a l , / s e descr i be us a nd o l enguaj e nat ur al (o un l enguaj e f or mal de
especi f i caci n) .
Muchos de l os concept os i nt r oduci dos par a l os s i s t ema s or i ent a dos a obj et os
t ambi n s on apl i cabl es r es pect o de la ca j a negr a. Las abs t r acci ones de da t os y l as
ope r a c i one s q u e mani pul an di chas abs t r acci ones l as enca ps ul a la caj a negr a. Al
i gual que una j er ar qu a de cl ase, la especi f i caci n d e ca j a negr a pue d e exhi bi r el us o
d e j er ar qu as e n l as cual es l as c a j a s de ni vel i nferi or he r e da n l as pr opi eda des de
c a j a s s uper i or es en la est r uct ur a de rbol .
Especificacin
d e c a j a d e
est ado.
TM
PDF Editor
29.2.2 Especificacin de caj a de estado
La caja de estado es "una gener al i zaci n si mpl e de una m qui na de es t ado" [MIL88],
Si se r ecuer da la descr i pci n del mode l a do de c ompor t a mi e nt o y l os di a gr a ma s de
es t ado del cap t ul o 8, un es t ado es al gn modo obs er vabl e d e c ompor t a mi e nt o del
si st ema. Conf or me ocur r en l os pr oces a mi ent os , un s i s t ema r e s ponde a l os event os
(est mul os) me di a nt e la r eal i zaci n de t r ans i ci ones de s de el e s t a do act ual hast a ci er-
t o es t ado nuevo. Conf or me s e real i za la t r ansi ci n es posi bl e que ocur r a una acci n.
La caj a de es t ado ut i l i za una abs t r acci n de da t os par a det er mi na r la t r ansi ci n
haci a el si gui ent e e s t a do y la acci n (respuest a) que ocur r i r c o mo cons ecuenci a de
la t r ansi ci n.
Segn s e mues t r a en la figura 29. 4, la caj a de e s t a do i ncor por a una caj a negr a. El
est mul o, S, que i ngr esa a la caj a negr a l l ega de s de al guna f uent e ext er na y un con-
j unt o de e s t a dos i nt er nos del si st ema, T. Mills [MIL88] pr opor ci ona una descr i pci n
ma t e m t i c a de la f unci n, / de la ca j a negr a cont eni da dent r o de la caj a de es t ado:
g:S* xT" ->RxT
donde o es una s ubf unci n l i gada a un e s t a do espec fi co, f. Cua ndo s e cons i der an en
conj unt o, l os par es de s ubf unci ones de e s t a do (, g) def i nen la f unci n / de caj a
negr a.
29.2.3 Especificacin de caj a transparente
La especi f i caci n de caj a t r a ns pa r ent e es t c e r c a na me nt e r el aci onada con el di s eo
de pr ocedi mi ent os y la pr ogr a ma ci n es t r uct ur ada (cap t ul o 1 1 ). En esenci a, la s ub-
f unci n g dent r o de la caj a de e s t a do se sust i t uye con l as es t r uct ur as de pr ogr a ma -
ci n es t r uct ur ada que i mpl ement a g.
c o mo ej empl o, cons i dr es e la caj a t r ans par ent e que s e mue s t r a en la figura 29. 5.
La caj a negr a, g, de la figura 29. 4 s e sust i t uye con una s uces i n de es t r uct ur as que
i ncor por a una condi ci onal . Est as est r uct ur as, a su vez, s e r ef i nan en c a j a s t r a ns pa -
r ent es de ni vel i nferi or c onf or me pr ocede el r ef i nami ent o e n ni vel es.
Especificacin
d e c a j a
t r anspar ent e.
Est ado
r~
T *i
R
TM
PDF Editor
CAPTULO 29 INGENIERA DEL SOFTWARE DE SALA UMPI A
867
Es i mpor t ant e obs er var que pue de demos t r a r s e la cor r ecci n de la especi f i caci n
de pr ocedi mi ent o descr i t a en la j er ar qu a de caj a t r ans par ent e. Este t ema s e consi -
der a en la secci n si gui ent e.
A Q u condi-
ci ones son
aplicables para
probar que son
adecuadas l as
estructuras
estructuradas?
El e nf oque de di s eo ut i l i zado en la i ngeni er a del s of t wa r e de sal a l i mpi a utiliza con
ampl i t ud la filosofa de pr ogr a ma ci n es t r uct ur ada. Pero, en es t e cas o, la pr ogr a ma -
ci n es t r uct ur ada s e apl i ca mu c h o m s r i gur os ament e.
Las f unci ones d e pr oc e s a mi e nt o bsi co ( descr i t as dur a nt e l as pr i mer a s e t a pa s del
r ef i nami ent o de la especi f i caci n) s e r ef i nan ut i l i zando una "expans i n pr ogr esi va
de f unci ones ma t e m t i c a s en es t r uct ur as de conect i vos l gi cos [por ej empl o, if-then
else] y s ubf unci ones , d ond e la expa ns i n [se] r eal i za ha s t a que t odas l as s ubf unci o-
ne s i dent i f i cadas pue da n es t abl ecer s e di r ect a ment e en el l enguaj e de pr ogr a ma ci n
us a do par a la i mpl ement aci n" [DYE92]
El e nf oque de pr ogr a ma ci n es t r uct ur ada se e mpl e a con efi caci a par a r ef i nar la
f unci n, per o qu hay a cer ca del di s eo? Aqu s e i nvol ucr an var i os c onc e pt os f un-
d a me nt a l e s de di s eo (cap t ul os 5 y 9). Los da t os d e pr ogr a ma s e enca ps ul a n c o mo
un c onj unt o de a bs t r a cci ones que at i enden l as s ubf unci ones . Los concept os de en-
ca ps ul a do de dat os, ocul t a mi ent o de i nf or maci n y cl asi fi caci n de da t os se apr ove-
cha n par a cr ear el di s eo de dat os.
29.3.1 Refinamiento y verificacin del diseo
Cada especi f i caci n de caj a t r a ns pa r ent e r epr es ent a el di s eo de un pr ocedi mi ent o
( subf unci n) neces ar i o par a l ograr una t r ansi ci n de caj a de es t ado. Con la caj a
t r a ns pa r ent e l as es t r uct ur as de pr ogr a ma ci n es t r uct ur ada y el r ef i nami ent o pr ogr e-
si vo s e ut i l i zan c o mo s e i l ust ra en la figura 29. 6. Una f unci n de p r o g r a ma , / s e refi -
na en una s uces i n de s ubf unc i one s g y h. st as, a su vez, s e r ef i nan e n es t r uct ur as
condi ci onal es {if-then-else y do-while). El r ef i nami ent o adi ci onal i l ust ra la cont i nua-
ci n del r ef i nami ent o l gi co.
En cada ni vel de r ef i nami ent o el equi po de sal a l i mpi a2 r eal i za una veri fi caci n
f or mal de cor r ecci n. Est o s e l ogra a n e x a n d o un conj unt o de condi ci ones de cor r ec-
ci n genr i cas a l as es t r uct ur as de pr ogr amaci n es t r uct ur ada. Si una f u n c i n / s e
e xpa nde en una s uces i n g y h, la condi ci n de cor r ecci n par a cual qui er ent r a da a
f e s
g segui da de h h a c e / ?
Cua ndo una f unci n p se r ef i na e n un condi ci onal de la f or ma if < c > t hen q, el se r
(si < c > e nt onc e s q, de ot r o mo d o r), la condi ci n de cor r ecci n par a cual qui er ent r a-
da a p es
2 Puesto que el equipo completo est involucrado en e! proceso de verificacin, es menos probable
que se cometa un error al realizar la verificacin
TM
PDF Editor
Refinamiento
progresivo.
^ CONS E J ^
Si el lector se limita
slo a los estructuras
estructurados
conforme desarrollo
un diseo de procedi-
miento, lo prueba de
correccin es directa.
Sise violan las estruc-
turas las pruebas de
correccin son i
o imposibles.
S i e mp r e q u e l a c o n d i c i n < c > e s v e r d a d e r a , q h a c e p; y s i e mp r e q u e < c > e s
f a l s a , r h a c e p?
Cua ndo la f unci n m s e r ef i na c o mo un bucl e l as condi ci ones de cor r ecci n par a
cual qui er ent r ada a m s on
La t er mi naci n est gar ant i zada?
Si empr e que <c> es ver dader a, n segui da de m ha c e m; y s i empr e que < c >
es fal sa, sosl ayar el bucl e t odav a ha c e m?
Cada vez que una ca j a t r ans par ent e s e r ef i na al si gui ent e ni vel de det al l e s e apl i can
di chas condi ci ones d e cor r ecci n.
Es i mpor t ant e s ea l a r que la ut i l i zaci n de es t r uct ur as de pr ogr a ma ci n es t r uc-
t ur ada r est r i nge el n me r o de pr ueba s de cor r ecci n que s e deben real i zar. Una sol a
condi ci n s e verifica par a l as s uces i ones ; dos condi ci ones se pr ue ba n par a if-then-
else; y t r es condi ci ones s e veri fi can par a l os bucl es.
La veri fi caci n de cor r ecci n de un di s eo de pr ocedi mi ent o s e ilustra empl ea n-
do un ej empl o si mpl e que i nt r oduj er on Linger, Mills y Witt [LIN79]. El obj et i vo es
di s ear y veri fi car un pe q ue o pr ogr a ma que e nc ue nt r a la par t e ent er a, y, de una
TM
PDF Editor
\
CLAVE
Probar que un diseo
es correcto requiere,
primero, identificar
todos los condiciones y
luego probor que cada
una toma el volor
booleano adecuado. A
estas condiciones se
les llama subpruebas.
ra z cuadr ada de un ent er o dado, x. El di seo de pr ocedi mi ent o se r epr esent a en la
figura 29. 7 empl eando el di agr ama de flujo.
Verificar la correcci n de est e di seo requi ere definir l as condi ci ones de ent r ada
y sal ida c omo se indica en la figura 29.8. La condi ci n de ent r ada advi ert e que x debe
ser mayor que o igual a 0. La condi ci n de salida requi ere que x per ma nez ca i nal t e-
rada y que y sat i sfaga la expresi n i ndi cada en la figura. Probar la correcci n del
di seo requi ere compr obar que, en t odos l os casos, son ver dader as las condi ci ones
inicio, bucle, cuenta, s y salida que se muest r an en la figura 29.8. En ocasi ones, a
st as s e les l l ama subpruebas.
1 . La condi ci n inicio dema nda que | x > 0 e y = 01. Con base en l os requi si t os del
probl ema se s upone que la condi ci n de ent r ada e s correct a. 3 En consecuenci a,
se sat i sface la pri mera par t e de la condi ci n inicio, x a 0. Segn el di agr ama de
flujo, el enunci ado que pr ecede i nmedi at ament e a la condi ci n inicio est abl ece
y = 0. Por lo t ant o, la segunda part e de la condi ci n inicio t ambi n se sat i sface.
En consecuenci a, inicio es ver dader a.
2. La condi ci n bucl e se puede encont r ar en una de dos f or mas posi bl es: 1) direc-
t ament e a partir de inicio (en est e caso, la condi ci n bucl e se sat i sface di rect a-
ment e) o por medi o del flujo de cont rol que pasa a t ravs de la condi ci n
cuent a. Dado que la condi ci n cuent a e s idntica a la condi ci n bucle, bucl e e s
ver dader a sin i mport ar la t rayect ori a de flujo que conduce a ella.
3 En este contexto, un valor negativo para .a r a u cuadrada no tiene significado.
TM
PDF Editor
Pr ueba de
que el di seo
es conect o.
Diseo con
subpr uebas.
se
r
L
sal i da: x no cambi a y y2 < x <, (y + 1 ) 2
cuenta: [y2 < x]
3 . La condi ci n cuent a s e encuent r a sl o de s pu s de que el val or de y a u me n t a en
1. Adems , la t r ayect or i a del fl uj o de cont rol que c onduc e a cuent a s e puede in-
vocar sl o si la condi ci n s t ambi n es ver dader a. Por l o t ant o, si (y + l )2 s x ,
se si gue que y 2 s x . L a condi ci n cuent a s e sat i sf ace.
4 . La condi ci n s se pr ueba en la l gica condi ci onal mos t r a da . Por lo t ant o, la
condi ci n s debe s er ver dader a c ua nd o el fl uj o de cont r ol s e mue ve a lo l argo
de la t r ayect or i a mos t r a da .
5 . La condi ci n sal i da d e ma nd a pr i mer o que x n o haya cambi ado. Un e xa me n del
di s eo i ndi ca que x no a pa r ece en ni ngn si t i o a la i zqui er da de un oper ador de
asi gnaci n. No exi st e l l amado de f unci n que us e x. Por lo t ant o, n o cambi a.
Dado que la pr ue ba condi ci onal (y + l ) 2 < x debe fal l ar par a al canzar la condi -
ci n sal i da, s e si gue que (y + l)2 :< x. Adems , la condi ci n bucl e t odav a debe
ser ver dader a (es deci r, y2 =s x). En consecuenci a, se pueden combi nar (y + l )2 > x
y y2 x par a sat i sf acer la condi ci n sal i da.
Ade m s s e debe gar ant i zar que el bucl e t er mi na. Un e xa me n de la condi ci n bucle
i ndi ca que, pue s t o que y a u me n t a y x > 0, el bucl e a la l arga debe t er mi nar .
Los ci nco pa s os a p e n a s a not a d os pr ue ba n la cor r ecci n del di s eo del al gor i t mo
i ndi cado en la fi gura 29. 7. Ahora s e t i ene cer t eza de que el di seo, de hecho, cal cu-
l ar la par t e ent er a de una ra z cuadr ada.
Es posi bl e e mpl e a r un e nf oque ma t e m t i c o m s r i gur oso en el di s eo de la veri -
fi caci n. Sin embar go, una exposi ci n de est e t ema r ebas a el mbi t o de es t e libro.
Los l ect or es i nt er es ados pue de n cons ul t ar [LIN79J.
TM
PDF Editor
CAPITULO 29 INGENIERA DEL SOFTWARE DE SALA LIMPIA
871
4 j | Q u s e
w gana al rea-
l z ar pruebas de
correccin?
29.3.2 Ventajas de la verificacin del diseo4
La ver i f i caci n r i gur osa de la cor r ecci n de ca da r ef i nami ent o del di s eo de la caj a
t r ans par ent e t i ene var i as vent aj as . Linger [LIN94] l as descr i be de la si gui ent e f or ma:
Reducen la veri fi caci n a un pr oces o finito. La ma n e r a secuenci al y a ni da da
e n que s e or ga ni z a n l as es t r uct ur as de cont rol e n una caj a t r a ns pa r ent e def i ne
con nat ur al i dad una j er ar qu a que r evel a l as condi ci ones de cor r ecci n q u e s e
deben veri fi car. Un "axi oma de r eempl a z o" [LIN79] per mi t e sust i t ui r l as
f unci ones pr oyect adas con sus r ef i nami ent os de est r uct ur a de cont rol en la
j er ar qu a de l as s ubpr uebas . Por ej empl o, la s ubpr ue ba de la f unci n pr oyec-
t ada fl de la fi gura 29. 9 r equi er e pr obar que la compos i ci n de l as oper a-
ci ones gl y g2 con la f unci n pr oyect ada f2 t i ene el mi s mo ef ect o s obr e l os
da t os que f l . Nt ese que f2 sust i t uye t odos l os det al l es de su r ef i nami ent o en
la pr ueba. Est a sust i t uci n l ocal i za el a r gume nt o de pr ueba con la est r uct ur a
de cont rol que s e est a est udi ando. De hecho, dej a que el i ngeni er o de
s of t wa r e l l eve a c a bo l as pr ue ba s en cual qui er or den.
Es i mposi bl e s obr ees t i mar el ef ect o posi t i vo q u e la r educci n de la veri fi caci n
a un pr oces o finito t i ene s obr e la cal i dad. Aun c ua nd o t odos l os pr ogr amas ,
except o l os m s t r i vi al es, muest r en un n me r o es enci a l ment e i nfi ni t o de
t r ayect or i as de ej ecuci n, pue de n veri fi carse en un n me r o finito de pasos.
Diseo con
subpr uebas.
[fl]
DO
gl
g2
[f2]
WHILE
P'
DO [f3]
83
[ ]
IF
p2
THEN [f5]
g5
EL8E [f6]
ge
67
END
g8
END
END
Subpruebas:
fl = [DO gl : g2: [f2] END] ?
f 2 = [WHILE pl DO [f3] END] ?
f 3 = [DO g3: [M]: g8 END] ?
f 4 = [IF p2; THEN [f5] EL8E [f6] END] 7
f S = [DO g4: g5 END] 7
f 6 = [DO g6: g7 END] 7
4 Esta seccin y las figuras 29.7 a 29.9 har. sido adaptadas de [LIN94] y se usaron con permiso.
TM
PDF Editor
CLAVE
A pesar del nmero
ext r emadament e
grande de trayectorias
de ejecucin en un
programa, el nmero
de pasos para probar
que el programa e s
correcto e s bast ant e
pequeo.
Permiten al equipo de sala limpia verificar cada lnea de diseo y cdigo. Los
equi pos pue de n r eal i zar la veri fi caci n por medi o del anl i si s y la di scusi n
en gr upo s obr e la ba s e del t e or e ma de cor r ecci n, y s on c a pa c e s de pr oduci r
pr ue ba s escr i t as d ond e s e r equi er e una conf i a nz a adi ci onal e n un s i s t ema
cruci al par a la vida o la mi si n.
Resultan en un nivel de defecto cercano a cero. Dur ant e una revi si n de equi po
s e verifica por t ur nos la condi ci n de cor r ecci n de ca da est r uct ur a de
cont r ol . Cada mi e mbr o del equi po de be es t ar de a c ue r do en q u e ca da
condi ci n e s cor r ect a, de mo d o q u e un er r or s l o e s posi bl e si c a da mi e mbr o
del equi po verifica de ma ne r a i ncor r ect a una condi ci n. El r equi si t o del
a c ue r do un ni me ba s a do e n la veri fi caci n individual gener a un s of t wa r e con
poc os o ni ngn def ect o a nt e s de su pr i mer a ej ecuci n.
Es escaable. Cual qui er s i s t ema de s of t war e, sin i mpor t ar c u n gr a nde s ea ,
t i ene pr ocedi mi ent os de caj a t r ans par ent e de ni vel super i or c ompue s t os de
es t r uct ur as de sucesi n, al t er naci n e i t er aci n. Cada una de el l as us ua l ment e
i nvoca un gr an s ubs i s t ema con mi l es de l neas de cdi go, y ca da u n o de
di chos s ubs i s t e ma s t i ene s us pr opi os pr ocedi mi ent os y f unci ones pr oyect adas
de nivel super i or . De mo d o q u e l as condi ci ones de cor r ecci n par a t al es
es t r uct ur as de nivel super i or s e veri fi can en la mi s ma f or ma que l as es t r uc-
t ur as de nivel i nferi or. La veri fi caci n e n ni vel es s uper i or es pue de t omar , y
val e la pena , m s t i empo, per o n o r equi er e m s t eor a.
Produce mejor cdigo que la prueba unitaria. La pr ueba uni t ar i a veri fi ca l os
ef ect os d e ej ecut ar sl o l as t r ayect or i as de pr ueba s el ecci onadas ent r e
mu c h a s t r ayect or i as posi bl es. Al bas ar la veri fi caci n e n la t eor a de
f unci ones , el e nf oque d e sal a l impia pue de veri fi car cual qui er ef ect o posi bl e
s obr e t odos l os da t os por que, mi ent r as un pr ogr a ma pue de t ener mu c h a s
t r ayect or i as de ej ecuci n, s l o t i ene una f unci n. La veri fi caci n t ambi n es
m s ef i ci ent e que la pr ue ba uni t ar i a. La mayor a de l as condi ci ones de veri fi -
caci n s e pue de c ompr oba r e n u n o s c ua nt os mi nut os, pe r o l as pr ueba s
uni t ar i as r equi er en un t i empo sust anci al en s u pr epar aci n, ej ecuci n y
compr oba ci n.
Es i mpor t ant e adver t i r que la veri fi caci n del di s eo debe, a final de cuent as , apl i -
car s e al pr opi o cdi go f uent e. En es t e cont ext o, con f r ecuenci a s e le l l ama verifica-
cin de a correccin.
La est r at egi a y l as t ct i cas de l as pr ue ba s de sal a l i mpi a s on f unda me nt a l me nt e di fe-
r ent es de l os e nf oque s de pr ue ba convenci onal es . Los m t odos convenci onal es
ge ne r a n un c onj unt o de c a s os de pr ue ba par a descubr i r er r or es d e di s eo y codi fi -
caci n. La met a de l as pr ue ba s d e sal a l impia e s val i dar l os r equi si t os de s of t wa r e
TM
PDF Editor
CAPTULO 29 INGENIERA DEL SOFTWARE DE SALA UMPI A 873
^ C ONS I J O^
incluso si no se es
xrtidorio del enfoque
de salo limpio, vlelo
xna considerar las
yuebas estadsticas
de utilizacin como
xrte integral de su
estrategia de pruebas.
d e mos t r a nd o que una mue s t r a est ad st i ca de c a s os de us o (cap t ul o 7) s e ha ej ecu-
t ado exi t os ament e.
""T
"lo cal idad no es un act o; e s un hbi t o. "
29.4.1 Pruebas estadsticas de uso
El us uar i o de un pr ogr a ma de c omput a dor a r ar a vez necesi t a e nt e nde r l os det al l es
t cni cos del di s eo. El c ompor t a mi e nt o del pr ogr a ma q u e ve el us uar i o lo a l i ment a n
e nt r a da s y e ve nt os que con f r ecuenci a l mi s mo pr oduce. Pero, en l os s i s t ema s c om-
pl ej os, el posi bl e es pect r o de e nt r a da s y e ve nt os (es decir, l os c a s os de uso) tal vez
s e a e xt r e ma d a me nt e ampl i o. Qu s ubc onj unt o de c a s os de us o veri fi car a de c ua -
d a me n t e el c ompor t a mi e nt o del pr ogr a ma ? Esta e s la pr i mer a pr egunt a q u e a bor da
la pr ueba est ad st i ca de uso.
La pr ueba est ad st i ca de us o "equi val e a pr oba r el s of t wa r e en la f or ma q u e l os
us uar i os i nt ent ar an usar l o" [LIN94], Est o s e l ogra si l os equi pos de pr ueba de sal a
l i mpi a ( t ambi n l l a ma dos equipos de certificacin) det er mi na n una di st ri buci n de
pr obabi l i dad de us o par a el s of t war e. La especi f i caci n (caj a negra) de ca da i ncre-
me n t o del s of t wa r e s e anal i za par a defi ni r un c onj unt o de es t mul os ( ent r adas o
event os) q u e pr ovoca n el c a mbi o de c ompor t a mi e nt o del s of t war e. Con ba s e en
ent r evi s t as con us uar i os pot enci al es, la cr eaci n de es cena r i os de us o y una c om-
pr ens i n gener al del domi ni o de la apl i caci n, s e as i gna una pr obabi l i dad de us o a
ca da est mul o.
Los c a s os de pr ueba se ge ne r a n par a ca da c onj unt o d e est mul os5 de a c ue r do con
la di st ri buci n de pr obabi l i dad de uso. Con f i nes i l ust rat i vos, cons i dr es e el s i s t ema
HogarSeguro es t udi ado pr e vi a me nt e en es t e libro. La i ngeni er a del s of t wa r e de sal a
l impia s e apl i ca en el desar r ol l o de un i ncr ement o de s of t wa r e que ges t i ona la i nt e-
r acci n del us ua r i o con el t ecl ado numr i co del si st ema de segur i dad. Respect o de
es t e i nc r e me nt o s e han i dent i f i cado ci nco est mul os. El anl i si s i ndi ca el por cent a j e
de di st ri buci n de pr obabi l i dad de ca da est mul o. Con el fin si mpl i fi car la sel ecci n
de l os c a s os de pr ueba di chas pr obabi l i dades es t n s e cor r el aci onan con los i nt er-
val os nume r a d os ent r e 1 y 99 [LIN94] y s e i l ust ran en la t abl a si gui ent e:
Est mulo del programa Probabilidad Interv alo
Habilitar/deshabilitar (HD)
Fijar zona |FZ]
Consulla (C)
Prueba (P)
Alarma(A)
50%
15%
15%
15%
5%
1 -49
5 0 6 3
64- 78
79- 94
95- 99
5 Es posible utilizar herrami ent as aut omat i zadas para lograr esto. Vase [DYE92]para mayor infor-
maci n.
TM
PDF Editor
Crear una sucesi n de casos de prueba de uso que concuerde con la distribucin
de probabilidad de uso requi ere gener ar nmer os al eat ori os ent re 1 y 99. Cada
nmer o al eatorio corresponde a un interval o en la distribucin de probabilidad pre-
cedent e. Por lo t ant o, la secuenci a de casos de prueba de us o se define aleatoria-
ment e, pero corresponde a la probabilidad correspondiente de presencia de estmulos
Por ejempl o, supngase que se gener an l as si gui ent es secuenci as de nmer os al ea-
torios:
1 3-94-22-24-45-56
81 -1 9-31 -69-45-9
38-21 -52-84-86-4
Al sel ecci onar los est mul os apropi ados con base en el interval o de distribucin que
se muest ra en la t abl a se derivan los casos de uso siguientes:
HD-P-HD-HD-HD-FZ
P-HD-HD-C-HD-HD
HD-HD-FZ-P-P-HD
El equi po de prueba ej ecut a est os casos de us o y verifica el compor t ami ent o del soft-
war e frente a la especificacin del si st ema. El t i empo para l as pr uebas se registra de
modo que sea posible det ermi nar los t i empos de intervalo. Al usar t i empos de inter-
valo, el equi po de certificacin tiene la posibilidad de calcular el t i empo medi o ent re
fallas (TMEF). Si se lleva a cabo una larga secuenci a de pr uebas sin fallas, el TMEF
es baj o y es probabl e que la fiabilidad del sof t war e sea alta.
29.4.2 Certificacin
Las t cni cas de verificacin y prueba ya descri t as en est e cap t ul o llevan a compo-
nent es de soft ware (e i ncr ement os completos) que pueden certificarse. En el con-
texto del enfoque de ingeniera del sof t war e de sal a limpia la certificacin implica
que la fiabilidad (medida en TMEF) se especifica para cada component e.
El i mpact o potencial de los component es de sof t war e certificables va mucho ms
all de un solo proyect o de sala limpia. Los component es de sof t war e reutilizables
se pueden al macenar j unt o con s us escenar i os de uso, est mul os de pr ogr ama y dis-
tribuciones de probabilidad. Cada component e tendra una fiabilidad certificada en
el escenari o de uso y el rgi men de pr uebas descritos. Esta i nformaci n es invalua-
bl e para ot r os que i nt ent en empl ear l os component es.
El enf oque de la certificacin involucra cinco pasos [WOH94):
1 . Creacin de escenar i os de uso.
2. Especificacin de perfiles de uso.
3 . Generaci n de casos de prueba a partir del perfil.
4. Ejecucin de pr uebas y registro y anl i si s de dat os de fallas.
5. Clculo y certificacin de la fiabilidad.
Cmo se
certif ico un
conponente de
sof t w are?
TM
PDF Editor
CAPTULO 29 INGENIERA DEL SOFTWARE CE SALA LIMPIA 875
Los pa s os del l al 4 s e han t r at ado en una secci n ant er i or . Esta secci n s e c onc e n-
t r ar en la cert i fi caci n de la fiabilidad.
La cert i fi caci n par a la i ngeni er a del s of t wa r e de sal a l impia r equi er e la cr eaci n
de t r es model os [ P0093] :
M o d e l o d e mu e s t r e o . La pr ueba del s of t wa r e ej ecut a m c a s os de pr ueba al ea-
t or i os y s e cert i fi ca si n o ocur r en f al l as o un n me r o espec f i co de st as. El val or de
m s e deri va ma t e m t i c a me nt e par a as egur ar que se l ogra la fiabilidad r equer i da.
M o d e l o d e c o mp o n e n t e s . Se cer t i f i car un s i s t ema c ompue s t o de n c ompo-
nent es . El mode l o de c o mp o n e n t e s per mi t e que el anal i st a det er mi ne la pr obabi l i dad
de que el c ompone nt e i fal l ar a nt e s de compl et ar s e.
M o d e l o d e c e r t i f i c ac i n. La fiabilidad gl obal del s i s t ema s e pr oyect a y cert i fi ca.
En el mo me n t o de compl et ar l as pr ue ba s est ad st i cas de us o el equi po de certifi-
caci n t i ene la i nf or maci n neces ar i a par a ent r egar el s of t wa r e que t i ene un TMEF
cert i fi cado, el cual s e cal cul a e mpl e a nd o ca da u n o de di chos model os .
Una descr i pci n det al l ada del cl cul o de l os mode l os de mues t r eo, c ompone nt e s y
cert i fi caci n es t m s all del mbi t o de es t e libro. El l ect or i nt er es ado hal l ar det a-
lles adi ci onal es en [MUS87], [CUR86] y [POQ93].
La i ngeni er a del s of t wa r e de sal a l impia e s un enf oque f or mal par a el desar r ol l o de
s of t wa r e que pue d e llevar a s of t wa r e con cal i dad not a bl e me nt e al t a. Utiliza la e s pe -
ci fi caci n de est r uct ur a de caj as (o m t odos f or mal es) par a el mode l a do de anl i si s
y di s e o y r esal t a la veri fi caci n de la cor r ecci n, e n l ugar de l as pr uebas , c o mo el
pri nci pal me c a ni s mo par a det ect ar y el i mi nar l os er r or es. Se apl i can pr ue ba s es t a-
d st i cas de ut i l i zaci n par a desar r ol l ar la i nf or maci n neces ar i a de t asa de fal l as con
que cert i fi car la fiabilidad del s of t wa r e ent r egado.
El e nf oque de s al a l impia c omi e nz a c on l os model os de anl i si s y di s eo que uti-
l izan una r epr es ent aci n en est r uct ur a de caj as . Una "caj a" enca ps ul a el s i s t ema (o
al gn a s pe c t o de l) en un gr ado espec f i co de abst r acci n. Las caj as negr as s e apr o-
ve c ha n par a r epr es ent a r el c ompor t a mi e nt o de un s i s t ema obs er vabl e de ma ne r a
ext er na. Las caj as de e s t a do enca ps ul a n dat os y ope r a c i one s de es t ado. Una ca j a
t r a ns pa r ent e s e e mpl e a en el mode l a do del di s eo de pr ocedi mi ent o que i mpl i can
l os da t os y oper a ci ones de una caj a de es t ado.
La veri fi caci n de la cor r ecci n s e apl i ca c ua nd o s e compl et a el di s e o de la
est r uct ur a de caj as . El di s eo de pr ocedi mi ent o par a un c o mp o n e n t e de s of t wa r e s e
di vi de en una ser i e de s ubf unci ones . La pr ue ba de la cor r ecci n de l as s ubf unci ones
r equi er e defi ni r condi ci ones de sal i da par a ca da s ubf unci n y s e apl i ca un c onj unt o
de s ubpr ueba s . Si ca da condi ci n de sal i da s e sat i sf ace el di s eo de be s er cor r ect o.
TM
PDF Editor
Una ve z c o mp l e t a d a la ver i f i ca ci n d e la c or r e c c i n c o mi e n z a la p r u e b a es t a d s -
t i ca d e us o. A di f e r e nc i a d l a s p r u e b a s c o n v e n c i o n a l e s , la i nge ni e r a del s o f t wa r e de
s al a l i mpi a n o s u b r a y a la i mpor t a nc i a d e l as p r u e b a s uni t a r i a s o d e i nt e gr a c i n. En
ve z d e el l o el s o f t wa r e s e p r u e b a d e f i n i e n d o u n c o n j u n t o d e e s c e n a r i o s d e us o.
d e t e r mi n a n d o la pr oba bi l i da d d e u s o pa r a c a d a e s c e n a r i o y d e f i n i e n d o e n t o n c e s l as
p r u e b a s a l e a t o r i a s q u e c o n c u e r d e n c o n l as pr oba bi l i d a d e s . Los r e gi s t r os d e e r r or
r e s u l t a n t e s s e c o mb i n a n c o n l os mo d e l o s d e mu e s t r e o , c o mp o n e n t e s y cer t i f i caci n
pa r a pe r mi t i r el c l c ul o ma t e m t i c o d e la f i abi l i dad p r o y e c t a d a r e s p e c t o al c o mp o -
n e n t e d e s o f t wa r e .
La filosofa d e s a l a l i mpi a e s u n e n f o q u e r i gur os o pa r a la i nge ni e r a del s o f t wa r e .
Es u n mo d e l o d e p r o c e s o d e s o f t wa r e q u e d e s t a c a la ver i f i ca ci n ma t e m t i c a d e la
c or r e c c i n y la cer t i f i caci n d e l a f i abi l i dad del s o f t wa r e . La l nea f u n d a me n t a l e s l as
t a s a s d e fal l a e x t r e ma d a me n t e b a j a s q u e s e r a n di f ci l es o i mpos i bl e s d e l ogr ar
e mp l e a n d o m t o d o s me n o s f o r ma l e s .
[CUR86] Currit, P. A., M. Dyer y H. D. Mills, "Certifying the Reliability of Software", en IEEE Trans
Software Engineering, vol. SE-1 2, nm. 1, enero de 1 994.
[DYE92] Dyer, M The Cleanroom Approach to Quality Software Development, Wiley, 1 992.
[HAU94] Hausler, P. A., R. Li nger yC. Trammel, "Adopting Cl eanroom Soft ware Engineering with
a Phased Approach", en IBM Systems Journal, vol. 33, nm 1, enero de 1 994, pp. 89-1 09.
[HEN95] Henderson, J "Why isn't Cl eanroom the Universal Soft ware Devel opment Methodo-
logy", en Crosstalk, vol. 8, nm. 5, mayo de 1 995, pp. 1 1 -1 4.
IHEV93] Hevner, A. R., y H. D. Mills, "Box Structure Met hods for System Devel opment with Ob-
jects", en IBM Systems Journal, vol. 31 , nm. 2, febrero de 1 993, pp. 232-251 .
[LIN79] Linger, R. M., H. D. Mills y B. I. Witt, Structured Programming: Theoiy and Practice, Addi-
son-wesl ey, 1 979.
ILIN881 Linger, R. M., y H. D. Mills, "A Case Study in Cl eanroom Soft ware Engineering: The IBM
COBOL Structuring Facility", Proc. COMPSAC '88, Chicago, oct ubre de 1 988.
[L1N94] Linger, R., "Cleanroom Process Model", en IEEE Software, vol. 11, nm. 2, mar zo de 1994.
pp. 50-58.
[MIL87I Mills, H. D M. Dyer y R. Linger, "Cleanroom Soft ware Engineering", en IEEE Software,
vol. 4, nm. 5, sept i embre de 1 987, pp. 1 9-24.
[MIL88] Mills, H. D., "Stepwise Refi nement and Veriflcation in Box Structured Systems", en Com
puter, vol. 21 , nm. 6, junio de 1 988, pp. 23-35.
IMUS87] Musa, ). D , A l anni no y K. Okumot o, Engineering and Managing Software with Reliabi-
lity Measures, McGraw-Hill, 1 987.
[ P0088| Poore, J. H., y H. D. Mills, "Bringing Soft ware Under Statistical Quality Control", en Qua
tity Progress, novi embre de 1 988, pp. 52-55.
[P00931 Poore, J. H., H. D. Mills y D. Mutchler, "Planning and Certifying Soft ware System Relia-
bi l i t y, en IEEE Software, vol. 10, nm. 1, ener o de 1 993, pp. 88-99.
[WOH94] Wohiin, C., y P. Runeson, "Certification of Soft ware Component s", en IEEE Trans. Soft
ware Engineering, vol. SE-20, nm. 6, junio de 1 994, pp. 494-499.
2 9 . 1 . Si se tuviese que elegir un aspect o de la ingeniera del sof t war e de sala limpia que la
hiciese radi cal ment e di ferent e de los enf oques convenci onal es de ingeniera de soft ware, cul
sera?
TM
PDF Editor
29. 2. Cmo t rabaj an en conj unt o un model o de proceso incremental y la certificacin para
producir soft ware de alta calidad?
29. 3. Empl eando la especificacin de est ruct ura de caj as desarrl l ense model os de anl isis "de
pri mer paso" y de di seo para el si st ema HogarSeguro.
29. 4. Desarrllese una especificacin de est ruct ura de caj as par a una porcin del si st ema
PHTRS pr esent ado en el probl ema 8.1 0.
29. 5. Un algoritmo de or denami ent o en burbuj a se define del modo siguiente:
p r o c e d u r e bubbl e s or t ;
va r i, t, i nt eger ;
begi n
r e p e a t unt i l t = a [ 1 ]
t : = a [ I ] :
f o r j: = 2 t o n d o
if a [ j - l j > a | j ] t he n begi n
t : = a [ j - l ] ;
a O- l ] : = a[ j ] ;
DI: = ' i
e nd
e n d r e p
e nd
Divdase el di seo en subf unci ones y def nase un conj unt o de condi ci ones que permitiran pro-
bar que est e algoritmo es correcto.
29. 6. Documnt ese una prueba de verificacin de correcci n para el or denami ent o en burbu-
ja t rat ado en el probl ema 29.5.
29. 7. Sel eccinese un component e de programa que se haya di seado en otro cont ext o (o uno
que haya asi gnado el instructor) y desarrl l ese respect o de l una prueba compl et a de correc-
cin.
29. 8. Sel ecci nese un programa que se use regul arment e (por ej empl o, un gest or de correo
electrnico, un procesador de pal abra, un programa de hoj as de clculo) y crese un conj unt o
de escenari os de uso para el programa. Def nase la probabilidad de uso para cada escenari o y
luego desarrl l ese una tabla de est mul os de programa y de distribucin de probabilidad simi-
lar al que se muest r a en la seccin 29.4.1 .
29. 9. Para la tabla de est mul os de programa y distribucin de probabilidad desarrol l ada en el
probl ema 29.8, utilcese un gener ador de nmer os al eatorios con el fin de desarrol l ar un con-
junto de casos de prueba par a empl earl o en pr uebas est ad st i cas de uso.
29. 10. Con pal abras propias, descr base el i nt ent o de certificacin en el cont ext o de ingeniera
del sof t war e de sala limpia.
Prowell e al. (Clcanroom Software Engineerng: Technology and Process, Addison-Wesley, 1 999)
ofrecen un t rat ami ent o det al l ado de los aspect os i mport ant es del enf oque de sala limpia. Poore
y Trammell (Cleanroom Software Engineerng: A Reader, Blackwell Publishing, 1 996) han edi t ado
exposi ci ones tiles de t emas de sala limpia. Becker y Whittaker (Cleanroom Software Engineerng
Practices, Idea Group Publishing, 1 996) present an un excel ent e panor ama par a qui enes no est n
famil iarizados con las prct i cas de sala limpia
The Cleanroom Pamphlet (Software Technology Support Center, Hill AFBase, abril de 1 995) con-
tiene reimpresiones de varios artculos importantes Linger 1UN941 produj o una de las mej ores
introducciones a la materia. El Data and Analysis Center for Soft ware (DACS) (www.dacs.dtic.mil)
ofrece muchos artculos tiles, libros guia y : t r ai fuent es de i nformaci n acerca de la i ngeni e-
ra del soft ware de sala limpia.
TM
PDF Editor
Linger y Trammell ("Cleanroom Soft ware Engineering Reference Model", SEI Technical
Report CMU/SE1 -96-TR-022, 1 996) han definido un conj unt o de 14 pr ocesos de sala limpia y 20
product os de t rabaj o que f or man la base para la SEI CMM de la ingeniera de soft ware de sala
limpia (CMU/SEI-96-TR-023).
Michael Deck de Cl eanroom Soft ware Engineering (www. cl eansoft. com) ha preparado una
bibliografa acerca de t emas de sala limpia. Muchos est n disponibl es en format o descargabl e.
La verificacin del di seo medi ant e la prueba de las correcci ones se encuent ra en el centro
del enfoque de sala limpia. Los libros de Stavely {Toward Zero-Defect Software, Addison-Wesley.
1 998), Baber (Error-Free Software, Wiley, 1 991 ) y Schulmeyer {Zero Defect Software, McGraw-Hill,
1 990) abor dan la prueba de correccin en forma muy detallada.
En Internet hay disponible una ampl i a vari edad de fuent es de i nformaci n acerca de la inge-
niera del soft ware de sala limpia. Una lista act ual i zada de referenci as en la World Wide Web se
puede encont rar en el sitio Web SEPA:
TM
PDF Editor
C A P T U L O
I NGENI ER A DEL SOFTWARE
BASADA EN COMPONENTES 30
CONCEPTOS
CLA VE
adoptacin . . . . 8 8 8
calif icacin 8 8 7
c l a s i f i c a c i n 8 9 2
DBC 8 8 6
entorna
de reotliindn . 8 9 4
ingenier a
del dominio . . . 8 8 3
ISBC 8 7 9
middlew are . . . 8 9 0
econom a 8 05
proceso 8 8 2
puntos
de estroctura . . 8 9 7
tipos de
componentes . . 8 8 1
E
n el cont ext o de la i ngeni er a del s of t war e la reut i l i zaci n e s una i dea t an-
t o ant i gua c o mo nue va . Los pr ogr a ma dor e s ha n r eut i l i zado i deas, abs t r ac-
ci ones y pr oces os de s de l os pr i mer os d as de la comput aci n, pe r o el
e nf oque ori gi nal pa r a la reut i l i zaci n er a espec f i co. En la act ual i dad, l os c om-
pl ej os s i s t ema s de al t a cal i dad ba s a d os e n c omput a d or a s s e d e be n const r ui r e n
un t i empo muy cor t o y d e ma n d a un e nf oq ue m s or ga ni z a do de la reut i l i zaci n.
La ingeniera del software basada en componentes (ISBC) es un pr oces o que
c onc e de par t i cul ar i mpor t anci a al di s eo y la cons t r ucci n de s i s t ema s ba s a d os
e n c omput a dor a s que ut i l i zan " component es " de s of t wa r e reut i l i zabl es. Cle-
me nt s [CLE95] descr i be as la ISBC:
[la ISBC] est cambiando la forma en que se desarrollan los grandes sistemas de soft-
ware. [La fSBCj encama la filosofa de "comprar, no construir" de la cual son partida
ros Fred Brooks y otros. En la misma forma como las primeras subrutinas liberaron
al programador de pensar acerca de los detalles, [la ISBC] cambi el inters de pro-
gramar software por el de componer sistemas de software. La implementacin ha da-
do paso a la integracin como centro del enfoque. En sus cimientos est la suposicin
de que existe suficiente base comn entre muchos grandes sistemas de software pa-
ra justificar el desarrollo de componentes reutilizables para explotarla y satisfacerla.
Per o s ur gen var i as pr egunt as . Es posi bl e const r ui r s i s t ema s compl ej os me -
di ant e el e ns a mbl a d o de c ompone nt e s de s of t wa r e reut i l i zabl es pr oveni ent es de
un cat l ogo? Est o se pue de l ograr e n una f or ma ef i caz t a nt o e n c os t o c o mo e n
t i empo? Es posi bl e est abl ecer i ncent i vos a de c ua dos que al i ent en a l os i ngeni e-
r os de s of t war e a reut i l i zar en vez de r ei nvent ar ? Los ges t or es t i enen bue na
di sposi ci n par a i ncurri r e n el gas t o adi ci onal a s oci a do con la cr eaci n d e com
pone nt e s d e s of t wa r e reut i l i zabl es? La bi bl i ot eca de c o mp o n e n t e s es neces ar i a
par a l ograr que la reut i l i zaci n s e cr ee e n una f or ma que s ea accesi bl e a qui e-
ne s la neces i t an? Los c o mp o n e n t e s q u e exi st en pue d e n encont r ar l os qui enes
l os necesi t en?
Q u e s ? Usted compra un sistema
de entretenimiento y lo lleva a casa.
Cada component e ha sido disea-
do par a encajar en una arquitectura
especfica de audi o y video: las cone-
xiones son est andari zadas y el protocolo de co-
municacin se ha preestablecido. El ensambl ado
es sencillo porque usted no tiene que construir el
sistema a partir de cientos de partes discretas
La ingeniera de software basada en componen
tes (ISBC) lucha por lograr la misma coso. Un
conjunto de componentes de software estandari-
zados preconstruidos se hacen disponibles par a
encaj ar en un estilo arquitectnico especfico pa-
ra cierto dominio de aplicacin. Entonces la
aplicacin es ensambl ada usando dichos com
879
TM
PDF Editor
ponentes, en lugar de las partes discretas de un
lenguaje de programacin convencional.
Q ui n lo hace? Los ingenieros de software
aplican el proceso de ISBC.
Por q u e s i mport ant e? Toma slo unos
cuantos minutos ensamblar el sistema de entrete-
nimiento del hogar porque los componentes es-
tn diseados para ser integrados con facilidad.
Aunque el software es considerablemente ms
complejo, se sigue que los sistemas basados en
componentes son ms fciles de ensamblar y
por lo tanto menos costosos de construir que ios
sistemas que se construyen a partir de partes
discretas. Adems, la ISBC alienta el uso de pa-
trones arquitectnicos predecibles y de infraestruc-
tura de software estndar, y por lo tanto conduce
a un resultado de mayor calidad.
Cules son los pasos? La ISBC abarca dos
actividades de ingeniera paralelas: la ingenie-
ra de dominios y el desarrollo basado en com-
ponentes. La ingeniera de dominios explora un
dominio de aplicacin con la intencin especfi-
ca de encontrar componentes funcionales, de
comportamiento y de datos que sean candidatos
para la reutilizacin. Dichos componentes son
colocados en libreras de reutilizacin. El desa-
rrollo basado en componentes obtiene requisitos
de los clientes; selecciona un estilo arquitectni-
co apropiado para satisfacer los objetivos del
sistema a construir; y luego 1) selecciona com-
ponentes potenciales para reutilizacin, 2! cali-
fica los componentes para asegurarse de que
encajan adecuadamente en la arquitectura para
el sistema, 3) adapt a los componentes si se de-
ben hacer modificaciones para integrarlos ade-
cuadamente, y 4) integra los componentes para
formar subsistemas y la aplicacin como un to-
do. Adems, algunos componentes personaliza-
dos son sometidos a ingeniera para enfrentar
aquellos aspectos del sistema que no pueden ser
implementados con el uso de los componentes
existentes.
Cul es el producto de trabajo? Un software
operativo, ensamblado con el uso de componen-
tes de software existentes y desarrollados recien-
temente, es el resultado de la ISBC.
hecho correctamente? Use las mismas
prcticas de SQA que se aplican en todo proce-
so de ingeniera del software: las revisiones tc-
nicas formales valoran los modelos de anlisis y
de diseo, las revisiones especializadas conside-
ran los conflictos asociados con los componentes
adquiridos, las pruebas se aplican para descu-
brir errores en el software desarrollado reciente-
mente y en los componentes reutilizables que se
han integrado en la arquitectura.
Incluso en la act ual i dad, los i ngeni er os de sof t war e l uchan con st as y ot r as pr e-
gunt as acer ca de la reutil izacin de component es de sof t war e. En est e cap t ul o se
abor dan al gunas de l as r espuest as.
3 0 . 1 I NGE NI E R A DE SI STEMAS BAS ADA EN C OMP ONE NT E S
En la superficie, la ISBC par ece bast ant e similar a la ingenier a del sof t war e ori ent a-
da a obj et os convenci onal . El pr oces o comi enza cuando un equi po de sof t war e
est abl ece requi si t os par a el si st ema que se const rui r medi ant e t cni cas convenci o-
nal es de investigacin de requi si t os (captulo 7). Se est abl ece un di seo arqui t ect -
ni co (captulo 10), per o en l ugar de dirigirse i nmedi at ament e haci a t ar eas de di seo
m s det al l adas, el equi po exami na los requi si t os par a det er mi nar qu subconj unt o
est di r ect ament e di spuest o par a la composicin, y no par a la const rucci n. Es decir,
el equi po pl ant ea l as si gui ent es pr egunt as para cada requi si t o del si st ema:
Informorinliloceiai
se puede encontrar en
www. cbd-hq. tom.
TM
PDF Editor
CAPTULO 30 INGENIERA DA SOFTWARE EASADA EN COMPONENTES 881
Hay c ompone nt e s comer ci al es de l nea (CDL) di sponi bl es par a i mpl ement ar
l os requi si t os?
Hay di sponi bl es c ompone nt e s reut i l i zabl es des ar r ol l ados i nt e r na me nt e par a
i mpl ement ar l os r equi si t os?
Las i nt er f ases par a l os c ompone nt e s di sponi bl es s on compat i bl es de nt r o de
la ar qui t ect ur a del si st ema que s e const r ui r ?
El equi po tal vez i nt ent e modi f i car o el i mi nar aquel l os r equi si t os del si st ema que
no s ea posi bl e i mpl ement ar con CDL o de desar r ol l o propi o1 . Si el r equi si t o no pue-
de ca mbi a r s e o el i mi nar se s e apl i can l os m t odos de i ngeni er a del s of t wa r e en la
cons t r ucci n de aquel l os nuevos c ompone nt e s que deben desar r ol l ar se par a sat i sf a-
cer los requi si t os. Per o par a l os r equi si t os que se a bor da n con l os c o mp o n e n t e s di s-
poni bl es c omi e nz a un c onj unt o di f er ent e de act i vi dades de i ngeni er a del s of t war e:
cual i fi caci n, adapt aci n, compos i ci n y act ual i zaci n. Cada una de e s t a s act i vi da-
d e s de ISBC s e exami na con mayor det al l e en la secci n 30.4.
En la pr i mer a par t e de est a secci n s e ha ut i l i zado r epet i da ment e el t r mi no com-
ponente, a u n q u e fal t a una descr i pci n defi ni t i va del t r mi no. Br own y Wal l nau
[BR096] sugi er en l as si gui ent es posi bi l i dades:
Componente: par t e i mpor t ant e, casi i ndependi ent e y r eempl a z a bl e de un si st e-
ma que sat i sf ace una f unci n cl ara en el cont ext o de una ar qui t ect ur a bi en
def i ni da.
Componente del software en ejecucin: pa que t e di nmi co de uni n de u n o o
m s pr ogr a ma s ges t i onados c o mo uni dad y a l os cual es s e t i ene a c c e s o por
medi o de i nt er f as es d oc ume nt a d a s que se pue de n descubr i r en la ej ecuci n.
Componente de software: uni dad de compos i ci n que s l o t i ene de pe nde nc i a s
d e cont ext o expl ci t as y es peci f i cadas en f or ma cont r act ual .
Componente de negocio la i mpl ement aci n d e s of t wa r e de un concept o o pr o-
c e s o de negoci o "aut nomo".
Ade m s de e s t a s descr i pci ones, l os c ompone nt e s de s of t war e t ambi n s e pue de n ca-
r act er i zar con ba s e en s us apl i caci ones en el pr oces o de ISBC. Ade m s de l os com-
pone nt e s CDL, el pr oces o de ISBC pr oduce:
Componentes cualificados: eva l ua dos por i ngeni er os de s of t wa r e par a gar ant i -
zar que no s l o la f unci onal i dad, s i no el d e s e mpe o, la fiabilidad, la faci l i dad
de us o y ot r os f act or es de cal i dad (cap t ul o 26) concuer da n con l os r equi si t os
del s i s t ema o pr oduct o que se const r ui r .
1 La implicacin es que la organizacin ajusta los requisitos de su negocio o producto de modo que
la implementacin basada en componentes se consiga sin que sea necesaria la ingeniera de perso-
nalizacin. Este enfoque reduce los costos y mejora el tiempo en que el producto llega al mercado,
pero no siempre es posible
TM
PDF Editor
Componentes adaptados: a da pt a dos par a modi f i car (accin t ambi n l l amada en-
mascarar o envolver) [BR096] car act er st i cas que no s e r equi er en o i ndeseabl es
Componentes actualizados: sust i t uyen el s of t wa r e exi st ent e c onf or me es t n
di sponi bl es l as nue va s ver s i ones de l os c ompone nt e s .
3 Q . 2 EL PROCESO P E I S B C
El proceso de ISBC s e car act er i za de tal f or ma que n o s l o i dent i fi ca l os c ompone n-
t es ca ndi da t os s i no que t ambi n cual i fi ca la i nt er f az d e ca da c ompone nt e , a da pt a los
c o mp o n e n t e s par a el i mi nar l as equi vocaci ones ar qui t ect ni cas, e ns a mbl a l os c om-
pone nt e s en un est i l o ar qui t ect ni co s el ecci onado y act ual i za l os c ompone nt e s con-
f or me l os r equi si t os del s i s t ema c a mbi a n [BR096], El model o de pr oces o par a la
i ngeni er a del s of t wa r e ba s a da en c o mp o n e n t e s des t a ca l as pi s t as par al el as en l as
cual es la i ngeni er a del domi ni o (secci n 30.3) s e l l eva a c a b o c onc ur r e nt e me nt e con
el desar r ol l o ba s a d o en c ompone nt e s .
La figura 30. 1 ilustra un model o de pr oces o t pi co que expl ci t ament e acopl a la
ISBC [CHR95], La ingeniera del dominio cr ea un mode l o del domi ni o de apl i caci n
que s e ut i l i za c o mo ba s e par a anal i zar l os r equi si t os del us ua r i o e n el flujo de i nge-
ni er a del s of t war e. Una ar qui t ect ur a genr i ca de s of t wa r e pr opor ci ona la ent r ada
pa r a el di s e o de la apl i caci n. Fi nal ment e, d e s pu s de que l os c o mp o n e n t e s reut i -
l i zabl es s e han c ompr a do, s el ecci onado d e bi bl i ot ecas exi s t ent es o cons t r ui do (co-
Medelo de
proceso que
apoya l a ISBC.
Ingeniera del dominio
Anlisis del
Desarrollo
arquitectnico
de software
dominio
Desarrollo
arquitectnico
de software
Desarrollo
de componentes
reutilizables
Depsito de
artefactos/
componentes
reutilizables
TM
PDF Editor
CAPITULO 30 INGENIERA DEL SOFTWARE BASADA EN COMPONENTES 883
mo par t e de la i ngeni er a del domi ni o) , es t n di sponi bl es par a l os i ngeni er os de sof t -
wa r e dur a nt e el desar r ol l o ba s a d o en c ompone nt e s .
Los pa s os de anlisis y diseo arquitectnico def i ni dos c o mo par t e del desarrollo
basado en componentes (figura 30.1 ) s e pue de n i mpl ement ar en el cont ext o de un pa-
radigma de diseo abstracto (ADP, por s us si gl as en ingls) [DOG03], Un ADP i mpl i ca
que el mode l o gl obal del s of t wa r e r epr es ent a do c o mo dat os, f unci ones y compor -
t a mi ent o (control) s e pue d e de s c ompone r j er r qui cament e. Conf or me la de s c om-
posi ci n comi enz a , el s i s t ema s e r epr esent a c o mo una col ecci n de ma r c os de t ra-
ba j o ar qui t ect ni co, ca da uno c ompue s t o de uno o m s pa t r ones de di s eo (cap t u-
lo 1 0). Un r ef i nami ent o ma yor i dent i fi ca l os c ompone nt e s neces ar i os par a cr ear ca-
da pat r n de di seo. En un cont ext o ideal , t odos l os c ompone nt e s se adqui r i r an a
part i r de un depsi t o ( apl i cando act i vi dades de calificacin, adaptacin y composicin
de componentes). Cua ndo s e r equi er en c o mp o n e n t e s es peci al i zados s e apl i ca la in
geniera de componentes.
3 Q . 3 I NGENI ER A DEL P P MI N I Q
La finalidad de la ingeniera del dominio es i dent i fi car, const r ui r , cat al ogar y di semi -
nar un c onj unt o de c ompone nt e s de s of t wa r e que s ea n apl i cabl es par a el s of t war e
exi st ent e y f ut ur o en un domi ni o de apl i caci n part i cul ar. La met a gl obal es est abl e-
cer me c a ni s mos que l es per mi t an a l os i ngeni er os de s of t war e compar t i r di chos
c o mp o n e n t e s par a reut i l i zarl os dur a nt e el t r abaj o en s i s t ema s nue vos y exi st en-
t es. La i ngeni er a del domi ni o i ncl uye t r es gr a nde s act i vi dades: anl i si s, const r ucci n
y di semi naci n.
^ CONSEJ O^ .
fIpioceso de anlisis
estudiado en esta sec-
cin se enfoca en los
componentes reutiliza-
bles. Sin embargo, el
anlisis de sistemas
CDL completos (por
ejemplo, aplicaciones
de comercio electrni-
co, aplicaciones de au-
tomatizacin de
fuerza de ventas)
tambin puede ser
una parte del anlisis
del dominio.
"Lo i ngeni er a del domi ni o t r a t a de encont r ar los aspect os comunes ent r e los si st emas pa r a i dent i fi car los component es
que s eo posi bl e apl i car en muchos si st emas, y pa r a i dent i fi car f ami l i as de pr ogr a ma s que s e posicionen por a sacar la
mayor vent a j a d e di chos component es . "
Paul ( l ement s
Se pue de a r gume nt a r que "la reut i l i zaci n des a pa r ecer , no por el i mi naci n, si no
por i nt egr aci n" en la est r uct ur a de la pr ct i ca de la i ngeni er a del s of t war e [TRA95],
Como la reut i l i zaci n cada vez t i ene ma yor a uge a l gunos cr een que la i ngeni er a del
domi ni o adqui r i r t ant a i mpor t anci a c omo la i ngeni er a del s of t wa r e dur a nt e la d-
ca da si gui ent e.
30.3.1 El proceso de anlisis del dominio
El e nf oque gl obal par a el anl i si s del domi ni o us ua l me nt e s e car act er i za en el con-
t ext o de la i ngeni er a del s of t wa r e or i ent ada a obj et os. Los pa s os en el pr oces o s e
def i nen como:
1 . Definir el domi ni o que s e i nvest i gar.
2 . Cat egor i zar l os e l e me nt os ext r a dos del domi ni o.
TM
PDF Editor
3. Recopi l ar una mues t r a r epr esent at i va de l as apl i caci ones en el domi ni o.
4 . Anal i zar ca da apl i caci n e n la mue s t r a y defi ni r l as cl as es de anl i si s.
5 . Desar r ol l ar un model o de anl i si s par a l as cl ases.
Es i mpor t ant e advert i r q u e el anl i si s del domi ni o es apl i cabl e a cual qui er par adi g-
ma de i ngeni er a del s of t war e, y que s e pue de apl i car al desar r ol l o convenci onal y al
or i ent a do a obj et os.
Aunque l os pa s os ci t ados of r ecen un model o til par a el anl i si s del domi ni o, no
br i ndan una gu a par a deci di r cul es c o mp o n e n t e s de s of t wa r e s on ca ndi da t os a la
reut i l i zaci n. Hut chi nson y Hi ndl ey [HUT88] sugi er en el si gui ent e c onj unt o de pr e-
gunt a s pr ct i cas c o mo una gu a par a i dent i fi car l os c o mp o n e n t e s de s of t wa r e reut i -
l i zabl es:
En l as i mpl ement a ci ones f ut ur as s e r equi er e la f unci onal i dad del c ompone n-
t e?
Cun c om n es la f unci n del c ompone nt e de nt r o del domi ni o?
Exi st e dupl i ci dad d e la f unci n del c ompone nt e de nt r o del domi ni o?
El c ompone nt e de pe nde del ha r dwa r e? Si es as , el ha r d wa r e pe r ma ne c e i n-
var i abl e ent r e l as i mpl e me nt a c i one s o l as es peci f i caci ones del ha r dwa r e pue-
den t r asl adar se haci a ot r o c ompone nt e ?
El di s e o es t lo s uf i ci ent ement e opt i mi zado par a la si gui ent e i mpl ement a-
ci n?
s e pue de n es t abl ecer pa r me t r os r es pect o de un c o mp o n e n t e n o reut i l i zabl e
de mo d o que s e vuel va reut i l i zabl e?
El c ompone nt e es reut i l i zabl e e n mu c h a s i mpl ement a ci ones s l o con c a m-
bi os me nor e s ?
Es fact i bl e la reut i l i zaci n por me di o de la modi f i caci n?
Un c o mp o n e n t e n o reut i l i zabl e s e pue de de s c ompone r par a pr oduci r compo-
ne nt e s reut i l i zabl es?
Cun vl ida e s la des compos i ci n de un c ompone nt e pa r a la reut i l i zaci n?
Para i nf or maci n adi ci onal a cer ca del anl i si s del domi ni o v a s e [ATK01 ], [HEI01 ] y
[PRI93].
30.3.2 Funciones de caracterizacin
A veces es difcil det er mi na r si un c o mp o n e n t e pot enci al ment e reut i l i zabl e e s de he-
cho apl i cabl e en una si t uaci n part i cul ar. Est a det er mi na ci n r equi er e defi ni r un
conj unt o de caract er st i cas del domi ni o que compar t a t odo el s of t war e dent r o d e un do-
mi ni o. Una car act er st i ca del domi ni o def i ne al gn at r i but o genr i co de t odos l os
pr oduct os que exi st en de nt r o de l. Por ej empl o, l as car act er st i cas genr i cas po-
dr an incluir la i mpor t anci a de la segur i dad y fiabilidad, el l enguaj e de pr ogr amaci n,
la concur r enci a en el pr oc e s a mi e nt o y mu c h a s ot r as.
1 Q
component es
i denti f i cados
durante el anl i si s
del dominio sern
candi datos para la
reutilizacin?
TM
PDF Editor
Informacin til acetco
del anlisis del dominio
s e puede encontrar en
www. sel . mi u.
ed u/ s i r /
descri pti ons/
deda.html. ' I | |
Q u es un
punto de e s -
tructura y cul es
son sus caracte-
r sti cas?
Un c onj unt o de car act er st i cas de domi ni o de un c ompone nt e reut i l i zabl e s e pue -
de r epr es ent a r c o mo [Dp], donde ca da el ement o, Dpj , en el conj unt o r epr es ent a una
car act er st i ca especi f i ca del domi ni o. El val or a s i gna do a Dpi r epr es ent a una escal a
ordi nal que i ndi ca la r el evanci a de la car act er st i ca par a el c ompone nt e p. Una es ca-
la tpica [BAS94] podr a s er
1 : No es r el evant e si la reut i l i zaci n e s apr opi ada.
2 : Rel evant e sl o e n ci r cuns t anci as i nusual es.
3 : Rel evant e: el c ompone nt e s e modi f i ca par a usar l o, a pes ar de l as di f er enci as.
4: Cl a r a ment e r el evant e, y si el nue vo s of t wa r e no t i ene est a car act er st i ca, la
reut i l i zaci n s er i nef i ci ent e per o tal vez s ea posi bl e.
5 : Cl a r a ment e r el evant e, y si el nue vo s of t war e no t i ene est a car act er st i ca, la
reut i l i zaci n s er i nef i ci ent e y la reut i l i zaci n sin di cha car act er st i ca no se re-
comi enda .
Cua ndo dent r o del domi ni o de apl i caci n s e const r ui r nue vo s of t war e, w, s e der i va
par a l un conj unt o de car act er st i cas del domi ni o. Ent onces s e c ompa r a n Dp, y Dm
par a det er mi na r si el c ompone nt e exi st ent e p s e reut i l i za con efi caci a en la apl i ca-
ci n w.
Aunque el s of t war e que s e const r ui r c l a r a me nt e exi st e dent r o de un domi ni o de
apl i caci n, l os c ompone nt e s r eut i l i zabl es en l s e d e be n anal i zar par a det er mi nar su
apl i cabi l i dad. En a l gunos c a s os (con suert e, un n me r o l imitado), "r ei nvent ar la r ue-
da" tal vez s ea la mej or el ecci n en c ua nt o a cost o.
30.3.3 Modelado estructural y puntos de estructura
Cua ndo s e apl i ca el anl i si s del domi ni o el anal i st a bus ca l os pa t r one s repet i t i vos en
l as apl i caci ones que r esi den de nt r o de un domi ni o. El mode l a do est r uct ur al es un en-
f oque de i ngeni er a del domi ni o ba s a da e n pa t r one s que f unci ona baj o la pr emi s a de
que cual qui er domi ni o de apl i caci n t i ene pa t r one s r epet i t i vos (de f unci n, dat os y
compor t ami ent o) que t i enen un pot enci al de reut i l i zaci n.
Cada domi ni o de apl i caci n se car act er i za medi a nt e un model o est r uct ur al (por
ej empl o, l os s i s t ema s avi ni cos de l as a e r ona ve s di fi eren e n o r me me n t e en especi fi -
caci ones, pe r o t odo el s of t war e mod e r no en est e domi ni o t i ene el mi s mo mode l o es-
t ruct ural ). Por l o t ant o, el mode l o est r uct ur al es un est i l o ar qui t ect ni co (cap t ul o 10)
que pue d e y de be r eut i l i zar se me di a nt e l as apl i caci ones de nt r o del domi ni o.
McMahon [MCM95] descr i be un punto de estructura c o mo "una est r uct ur a di st i n-
ta dent r o de un model o est r uct ur al ". Los punt os de est r uct ur a t i enen t r es car act er s-
t i cas di st i nt as:
1 . Un punt o de est r uct ur a es una abst r acci n que debe t ener un n me r o l i mi t ado
de i nst anci as. Adems , la abs t r acci n d e be r ecur r i r a t r avs de l as apl i caci o-
ne s en el domi ni o. De ot r o mo d o n o s e j ust i fi ca el cos t o de veri fi car, docu-
me nt a r y di s emi nar el punt o de est r uct ur a.
TM
PDF Editor
886
fe?
\
CLAVE
Un punt o de est r uct ur o
e s onl ogo a un pat r n
d e di seo que s e pue-
de encont r ar repet i da-
me n t e en apl i caci ones
con un domi ni o espec -
fi co.
2. Las r egl as que rigen el us o del punt o de est r uct ur a deben c ompr e nde r s e con
faci l i dad. Adems , la i nt er f az par a el punt o de es t r uct ur a de be s er r el at i va-
me nt e si mpl e.
3 . El punt o de est r uct ur a debe i mpl ement ar la ocul t aci n de i nf or maci n ai ai s-
lar t oda la compl ej i dad dent r o del mi s mo punt o de est r uct ur a. Est o r educe la
compl ej i dad per ci bi da del s i s t ema gl obal es conj unt o.
Como un ej empl o de punt os de est r uct ur a c omo pa t r one s ar qui t ect ni cos de un sis-
t ema, consi dr ese el domi ni o de s of t war e de si st emas de al ar ma. Este domi ni o puede
abar car s i s t ema s t an s i mpl es c o mo HogarSeguro (descri t os en cap t ul os ant er i or es)
o t an compl ej os c o mo el s i s t ema de a l a r ma par a un pr oces o i ndust ri al . Si n emba r -
go, e n cada c a s o s e encuent r a un conj unt o de pa t r one s est r uct ur al es pr edeci bl es:
una interfaz que le per mi t e al us ua r i o i nt er act uar con el si st ema; un mecanismo de
establecimiento de lmites que le per mi t e al us uar i o est abl ecer l mi t es a l os pa r me -
t r os que se medi r n; un mecanismo de gestin de sensores que s e comuni ca con t odos
l os s e ns or e s de super vi si n; un mecanismo de respuesta que r eacci ona a la ent r a da
pr opor ci ona da por el s i s t ema de gest i n de s ens or es , y un mecanismo de control que
le per mi t e al us uar i o cont r ol ar la f or ma en la que s e r eal i za la super vi si n. Cada u n o
de es t os punt os de est r uct ur a s e i nt egr a en una ar qui t ect ur a de domi ni o.
Es posi bl e defi ni r punt os de es t r uct ur a genr i cos que t r as ci endan di f er ent es do-
mi ni os de apl i caci n [STA94]:
t Aplicacin frontal (cliente): la GUI que i ncl uye t odos los me ns , pa nel es y e n-
t r adas y or dena l as f unci ones de edi ci n.
Bases de datos: el deps i t o par a t odos l os obj et os r el evant es r es pect o del do-
mi ni o de la apl i caci n.
Motor de clculo: l os model os numr i cos y n o num r i c os que ma ni pul a n da-
t os.
Funcin de generacin de informes: la f unci n que pr oduce sal i das de cual qui er
tipo.
Editor de aplicaciones: el me c a ni s mo par a per s onal i zar la apl i caci n r es pect o a
l as ne c e s i da de s de us ua r i os espec f i cos.
Los punt os de est r uct ur a se han s uger i do c o mo una al t er nat i va a l as l neas de cdi -
go y punt os de f unci n par a la es t i maci n del cos t o del s of t war e [MCM95], En la s ec-
ci n 30. 6. 2 se pr es ent a una br eve descr i pci n del empl eo de l os punt os de es t r uct u-
ra e n la cot i zaci n.
El desarrollo basado en componentes (DBC) es una act i vi dad de ISBC que ocur r e en
par al el o con la i ngeni er a del domi ni o. Al apl i car l os m t odos de di s eo de anl i si s
y ar qui t ect ni co ya t r a t a dos en est e libro, el equi po de s of t wa r e r ef i na un est i l o ar -
TM
PDF Editor
Q u f acto-
res se consi-
deran durante la
calif icacin de
component es?
qui t ect ni co apr opi ado par a el mode l o de anl i si s c r e a do par a la apl i caci n que s e
const r ui r . 2
Una vez que la ar qui t ect ur a s e ha est abl eci do, deben agr egr sel e c ompone nt e s
que I) es t n di sponi bl es en bi bl i ot ecas de reut i l i zaci n 2) s ea n di s e a dos par a sat i s-
f acer l as neces i da des per s ona l es del cl i ent e. Por t ant o, el fl uj o de t ar eas par a el de -
sarrol l o ba s a do en c ompone nt e s t i ene dos t rayect ori as par al el as (figura 30.1 ). Cua ndo
l os c o mp o n e n t e s reut i l i zabl es es t n di sponi bl es par a su pot enci al i nt egr aci n en la
ar qui t ect ur a t i enen que cual i f i car se y adapt ar s e. Cua ndo s e r equi er en nuevos c o m-
pone nt e s es pr eci so di sear l os. Ent onces l os c ompone nt e s r es ul t ant es s e " compo-
nen" (i nt egran) en la pl ant i l l a ar qui t ect ni ca y s e pr ue ba n en f or ma mi nuci osa.
30.4.1 Calificacin, adapt aci n y composicin de componentes
Co mo ya s e ha visto, la i ngeni er a del domi ni o pr opor ci ona la bi bl i ot eca de compo-
ne nt e s reut i l i zabl es i ndi s pens abl es par a la i ngeni er a del s of t war e ba s a da e n c om-
ponent es. Al gunos de es t os component es s e desarrol l an especi al ment e par a el domi ni o,
ot r os pue de n ext r aer se de apl i caci ones exi st ent es e i ncl uso ot r os pueden adqui r i r se
de t er cer as par t es.
Des gr aci adament e, la exi st enci a de c o mp o n e n t e s reut i l i zabl es no gar ant i za que
pue d a n i nt egr ar se con faci l i dad o ef i caci a en la ar qui t ect ur a el egi da par a una nueva
apl i caci n. Por es t a r a z n s e apl i ca una s uces i n de act i vi dades de desar r ol l o bas a-
da en c ompone nt e s c ua nd o s e pr opone el us o de un c ompone nt e .
Cal i f i caci n d e c o mp o n e n t e s . Esta act i vi dad gar ant i za que el c o mp o n e n t e can-
di dat o r eal i zar la f unci n r equer i da, "encaj ar " a d e c ua d a me nt e en el est i l o ar qui -
t ect ni co que especi f i ca el s i s t ema y mos t r ar l as car act er st i cas de cal i dad (por
ej empl o, de s e mpe o, fiabilidad, faci l i dad de uso) que r equi er e la apl i caci n.
La descr i pci n de la i nt er f az sumi ni st r a i nf or maci n til acer ca de la oper aci n y
la ut i l i zaci n de un c ompone nt e de s of t war e, per o n o pr opor ci ona t oda la i nf or ma-
ci n que s e r equi er e pa r a det er mi na r si un c o mp o n e n t e pr opues t o puede, en la pr c-
tica, r eut i l i zar se con ef i caci a en una apl i caci n nueva . Ent re l os mu c h o s f act or es
cons i der a dos dur a nt e la cual i fi caci n de c o mp o n e n t e s es t n [BR096]: i nt er f az de
pr ogr a ma ci n de la apl i caci n (IPA); he r r a mi e nt a s de desar r ol l o e i nt egr aci n que
r equi er e el c ompone nt e ; r equi si t os de t i empo de ej ecuci n, que i ncl uyen us o de re-
cur s os (por ej empl o, memor i a o a l ma cena mi ent o) , t i empos o vel oci dad y pr ot ocol o
de red; requi si t os de servicio, que i ncl uyen i nt er f ases de si st ema oper at i vo y apoyo de
ot r os component es ; car act er st i cas de segur i dad, que i ncl uyen cont r ol es de a c c e s o y
pr ot ocol os de aut ent i caci n; s upos i ci ones de di s eo ani dado, que i ncl uyen el e m-
pl eo de al gor i t mos num r i c os o n o num r i c os espec f i cos; y ma ne j o de excepci ones .
2 Se debe sealar que en el estilo arquitectnico con frecuencia influye el modelo estructural genri-
co creado durante la ingenieria del Con ir o rvease la ricura 30.1 )
TM
PDF Editor
^ OWS EJ C ^ .
Adems de valorar si
es justificado el costo
de adaptacin para lo
reutilizacin, el equipo
de software tambin
evalo si lograr la fun-
cionalidad requerida y
el desempeo se pue-
den hacei eficientes
tBcpecto del tasto.
Cada uno de es t os f act or es es r el at i vament e senci l l o de eval uar c ua ndo s e prop :
nen c o mp o n e n t e s reut i l i zabl es que s e han des ar r ol l ado es peci a l ment e par a la apli-
caci n. Sin emba r go, es muc ho m s difcil de t e nni na r la oper at i vi dad i nt er na de lc>
CDL o de c ompone nt e s de pr oveni ent es de t er cer os por que la ni ca i nf or maci n d:s
poni bl e tal vez s ea la mi s ma especi f i caci n de la i nt er f az.
A da pt a c i n de c o mp o n e n t e s . En un cont ext o ideal , la i ngeni er a del domi ni o
crear a una bi bl i ot eca de c ompone nt e s que podr an i nt egr ar se f ci l ment e en una ar-
qui t ect ur a de apl i caci n. La i mpl i caci n de la "i nt egr aci n fcil" es que 1) s e ha n im-
pl e me nt a do mt odos cons i s t ent es de gest i n de r ecur sos par a t odos l os component es
en la bi bl i ot eca, 2) exi st en act i vi dades c o mu n e s c omo la gest i n de da t os par a t odos
l os c ompone nt e s , y 3) se han i mpl e me nt a do i nt er f ases dent r o de la ar qui t ect ur a \
con el e nt or no ext er no en una f or ma cons i s t ent e.
En r eal i dad, i ncl uso de s pu s de que un c o mp o n e n t e s e ha cual i f i cado par a em-
pl ear l o dent r o de una ar qui t ect ur a de apl i caci n, es posi bl e que ha ya conf l i ct os en
una o m s de l as r e a s i ndi cadas. Est os confl i ct os us ual ment e s e evi t an ut i l i zando una
t cni ca de a da pt a ci n l l amada encubrimiento de componente [BR096]. Cua ndo ur
equi po de s of t war e t i ene pl eno a c c e s o al di s eo i nt er no y el cdi go de un c ompo
nent e (con f r ecuenci a n o es el cas o cua ndo s e ut i l i zan c ompone nt e s CDL) s e apl ica el
encubrimiento de caja blanca. Al i gual que su cont r apar t e en la pr ue ba de s of t war e
(cap t ul o 1 4), el encubr i mi ent o de caj a bl anca exami na los det al l es de pr oces ami en-
t o i nt er no del c ompone nt e y ha c e modi f i caci ones e n el cdi go par a el i mi nar cual -
qui er confl i ct o. El encubrimiento de caja gris s e apl i ca c ua ndo la bi bl i ot eca de com-
pone nt e s pr opor ci ona un l enguaj e de ext ensi n de c ompone nt e o IPA que per mi t e
el i mi nar o e nma s c a r a r l os confl i ct os. El encubrimiento de caja negra r equi er e la in-
t r oducci n de pr e y pos pr oc e s a mi e nt o en la i nt er f az del c ompone nt e par a el i mi nar
o e nma s c a r a r los confl i ct os. El equi po de s of t war e debe det er mi nar si el e s f ue r z o re-
quer i do par a encubr i r a d e c ua d a me nt e un c o mp o n e n t e es t j ust i fi cado o si, en l ugar
de ello, de be di s ear s e un c ompone nt e per s onal i zado ( desi gnado par a el i mi nar los
conf l i ct os encont r ados ) .
Co mp o s i c i n d e c o mp o n e n t e s . La t ar ea de compos i ci n de c ompone nt e en-
s a mbl a c ompone nt e s cual i f i cados, a da pt a dos y di s ea dos con el fin de agr egr s el os
a la ar qui t ect ur a est abl eci da par a una apl i caci n. Est o se l ogra es t abl eci endo una in-
f r aest r uct ur a que una l os c ompone nt e s en un si st ema oper at i vo. La i nf r aest r uct ur a
( us ual ment e una bi bl i ot eca de c ompone nt e s especi al i zados) pr opor ci ona un mode-
lo par a coor di nar l os c ompone nt e s y l os ser vi ci os espec f i cos que per mi t en que l os
c ompone nt e s se coor di nen mu t u a me n t e y r eal i cen t a r e a s c omune s .
Ent re l os muc hos me c a ni s mos que exi st en par a cr ear una i nf r aest r uct ur a efi caz
hay un conj unt o de cuat r o "i ngr edi ent es ar qui t ect ni cos" [ADL95] que de be est ar
pr es ent e par a l ograr la composi ci n de c ompone nt e s :
M o d e l o d e i nt e r c a mbi o d e da t o s . Respect o de l os c ompone nt e s reut i l i zabl es
s e deben defi ni r me c a ni s mos que per mi t an que l os us uar i os y apl i caci ones i nt erac-
TM
PDF Editor
* ) Q u ingre-
clientes se
necesi tan para lo-
grar l a composi -
cin de componen-
t e s ?
Re f e r e n c i a W e b
Lo rfomK6n ms re-
BA se puede obtener
en www. omg. or g.
Re f e r e nc i a W e b
Lo informacin mi s re-
ciente acerco de COM
www. mkr osof t .
( om/ COM.
t en y t r ansf i er an dat os (por ej empl o, ar r ast r ar y sol tar, cort ar y pegar). Los mecani s -
mos de i nt er cambi o de dat os no sl o per mi t en la t r ansf er enci a de da t os huma no- s of t -
wa r e y component e- component e, s i no t ambi n la t r ansf er enci a ent r e r ecur sos del sis-
t ema (por ej empl o, ar r ast r ar un ar chi vo a un i cono de i mpr esor a par a imprimirlo).
A ut o ma t i z a c i n. Se d e be n i mpl ement a r var i as her r ami ent as , ma c r os y gui ones
par a facilitar la i nt er acci n ent r e c o mp o n e n t e s reut i l i zabl es.
A l ma c e n a mi e n t o e s t r uc t ur ado. Los da t os he t e r og ne os (por ej empl o, da t os
gr f i cos, voz, vi deo, t ext o y da t os numr i cos) que cont i ene un " document o c om-
puest o" deben est ar or gani zados y of r ecer a cces o c omo una sol a est r uct ur a de dat os
y no c o mo una col ecci n de ar chi vos s epa r a dos . "Los da t os es t r uct ur a dos cons er va n
un ndi ce descr i pt i vo de es t r uct ur as a ni da da s por l as cual es l as apl i caci ones pue de n
na vega r l i br ement e par a ubi car, cr ear o edi t ar cont eni dos d e da t os i ndi vi dual es s e-
gn or de ne el us ua r i o final" [ADL95].
M o d e l o d e o bj e t o s u b y a c e n t e . El model o de obj et o a s egur a q u e l os c ompo-
ne nt e s des ar r ol l ados en di f er ent es l enguaj es de pr ogr a ma ci n y que resi den en di f e-
r ent es pl at af or mas pue de n s er i nt er oper abl es. Es decir, l os obj et os deben ser ca pa ces
de c omuni c a r s e a t r avs de una red. Est o s e l ogra si el model o de obj et o def i ne un
es t nda r par a la i nt er oper abi l i dad de l os c ompone nt e s .
Pues t o que el i mpa ct o pot enci al de la reut i l i zaci n y la ISBC s obr e la i ndust ri a del
s of t wa r e es e nor me , var i as gr a nde s c ompa a s y cons or ci os i ndust r i al es han pr o-
pue s t o e s t nda r e s par a el s of t wa r e de c ompone nt e s :
OM G/ CORB A . El Gr upo de Gest i n de Obj et os (OMG, por s u s si gl as e n ingls)
ha publ i cado una arquitectura comn de distribucin de objetos (CORBA: por s us si gl as
e n i ngl s). Un distribuidor de objetos (ORB, por sus si gl as en ingls) pr opor ci ona una
di versi dad de ser vi ci os que per mi t en que l os c ompone nt e s reut i l i zabl es (objetos) s e
c omuni que n con ot r os c ompone nt e s , sin i mpor t ar su ubi caci n dent r o de un si st e-
ma.
COM de M i c r os of t . Mi crosoft ha des ar r ol l ado un modelo de objetos para compo-
nentes (COM, por s us si gl as en ingls) que of r ece u n a especi f i caci n par a ut i l i zar
c ompone nt e s pr oduci dos por var i as e mpr e s a s dent r o d e una sol a apl i caci n que co-
rra baj o el s i s t ema oper at i vo Wi ndows . El COM i ncl uye d o s el ement os : i nt er f aces
COM ( i mpl ement adas c o mo obj et os COM) y un conj unt o de me c a ni s mos q u e regi s-
t ra y pa s a me n s a j e s ent r e i nt er f aces COM.
Co mp o n e n t e s S un Jav aB e ans . El s i s t ema de c o mp o n e n t e s J avaBeans es una
i nf r aest r uct ur a de ISBC port t i l e i ndependi ent e de la pl at af or ma que utiliza y de s a -
rrolla e mpl e a ndo el l enguaj e de pr ogr a ma ci n Java. El si st ema de c o mp o n e n t e s Ja-
va Bea ns i ncl uye un conj unt o de her r ami ent as , l l a ma do Kit de Desarrollo Bean (BDK,
Bean Development Kit), que per mi t e a l os desar r ol l ador es 1) anal i zar c mo f unci onan
l os Beans exi s t ent es ( component es ; 2) per s onal i zar s u c ompor t a mi e nt o y apar i en-
cia, 3) es t abl ecer me c a ni s mos par a coor di naci n y comuni caci n, 4) desar r ol l ar
TM
PDF Editor
I' II !I'! HL l n 11
Lo i nfamaci n ms re-
cente oceico de Jovo-
beons se puede obte-
ner en
javn.sun.tom/
producs/
j avabeons/docs/
Beans per s onal i zados par a us ar l os en una apl i caci n espec f i ca, y 5) pr oba r y eva-
l uar el c ompor t a mi e nt o Bean.
Cul de es t os e s t nda r e s domi na r la i ndust r i a? En est e mo me n t o no exi st e una
r es pues t a senci l l a. Aunque mu c h o s des ar r ol l ador es ha n a dopt a do u n o de l os es t n-
dar es, tal vez l as gr a nde s or ga ni z a ci ones de s of t wa r e qui er an opt ar por u n o d e l os
t r es es t nda r es , s egn l as cat egor as de apl i caci n y l as pl a t a f or ma s que el i j an.
I NFORMACI N
Arquitectura comn de distribucin de objetos
1 Los si st emas di ent e- ser vi dor se i mpl ement an
e mpl e na do component es (objetos) d e sof t war e
q ue de be n ser c a pa c e s d e i nt eract uar unos con ot ros den-
t ro d e una sol a mqui na (cliente o servidor) o a t ravs d e
la r ed. Un distribuidor de objetos (ORB) es middleware
(soft ware per sonal i zado) q ue per mi t e que un obj et o resi-
dent e en un cliente env e un mens a j e a un mt odo q ue est
e nc a ps ul a do en un obj et o resi dent e en un servidor. En
esenci a, el ORB i nt ercept a el me ns a j e y ma ne j a l as activi-
da de s d e comuni caci n y coor di naci n necesar i as pa r a
encont r ar el obj et o al cual fue di r i gi do el mens aj e, invoca
su mt odo, pa s a los dat os a pr opi a dos al obj et o y t ransfi ere
los da t os resul tantes d e vuel ta al obj et o que ge ne r pri me-
r o el mens aj e.
CORBA, COM y JavaBeans i mpl ement an una filosofa
d e distribuidor de objetos. En est e r ecuadr o CORBA se
us ar pa r a ilustrar el mi ddl ewar e ORB,
En la fi gura 3 0 . 2 se ilustra la est ruct ura bsi ca d e una
ar qui t ect ur a CORBA. Cua nd o CORBA se i mpl ement o en un
si st ema cliente-servidor, los obj et os servi dores a mbos se
defi nen ut i l i zando un lenguaje de descripcin de nterfase
(IDL, interface description languoge), un l enguaj e d e decl a-
r aci ones que per mi t e que un i ngeni er o d e sof t war e def i na
obj et os, at ri but os, mt odos y los mens aj es q ue se r equi er en
pa r a invocarl os. Par a que un obj et o resi dent e en el cliente
a c omode una peticin p a r a un mt odo r esi dent e en el ser-
vi dor se cr ean stubs ( adapt ador es ) del IDL en el cliente y el
servidor. Los stubs pr opor ci onan la compuer t a a t ravs d e
la q ue se a c omoda n las pet i ci ones d e obj et os a lo l ar go del
si st ema cl iente-servidor.
Puesto que l as pet i ci ones d e obj et os a t ravs d e la red
ocur r en en t i empo d e ej ecuci n, se d e be est abl ecer un me-
cani s mo pa r a a l ma cena r la descri pci n de obj et o d e modo
que la i nformaci n pert i nent e acer ca del obj et o y su ubi ca-
ci n estn di sponi bl es c ua ndo se necesi t e. El depsi t o d e
i nt erfaz l ogr a esto.
Cua nd o una apl i caci n en el cliente d e be i nvocar un
mt odo ubi cado dent r o d e un obj et o en cual qui er par t e del
si st ema, CORBA utiliza i nvocaci n di nmi ca p a r a 1) obt e-
ner i nformaci n pert i nent e a c e r c a del mt odo d e s e a d o a
part i r del depsi t o d e i nt erfaz, 2) cr ear una est ruct ura d e
da t os con pa r met r os que pa s a r n al obj et o, 3) cr ea r una
peticin pa r a el obj et o, y 4) i nvocar la pet i ci n. Ent onces
la peticin p a s a al ncl eo del ORB una pa r t e del si st ema
oper at i vo d e la red espec f i ca d e la i mpl ement aci n q ue
gest i ona las pet i ci ones y se cumpl e la pet i ci n.
La peticin pa s a a t ravs del ncl eo y la pr oces a el ser-
vidor. En el sitio d e st e un a d a p t a d o r d e obj et o a l ma c e na
i nf or maci n d e la cl ase y el obj et o en un depsi t o d e inter-
f az resi dent e en el servidor, a c e pt a y gest i ona las peticio-
nes q ue l l egan del cliente y r eal i za una di ver si dad d e ot r as
f unci ones d e gest i n d e obj et os. En el servi dor stubs del IDL
simil ares a los def i ni dos en la mqui na cliente se utilizan
c omo la i nt erfaz pa r a la i mpl ement aci n del obj et o real re-
si dent e en el sitio del servidor.
30.4.2 Ingeniera de componentes
Como ya s e i ndi c en est e cap t ul o, el pr oces o de ISBC al i ent a el u s o de c ompone n-
t es de s of t war e exi st ent es. Sin embar go, hay ocas i ones en que l os c ompone nt e s deben
di s ear s e. Es decir, s e deben desar r ol l ar nue vos c o mp o n e n t e s de s of t wa r e e i nt e-
gr ar se con l os CDL ya exi s t ent es y con l os c o mp o n e n t e s de desar r ol l o pr opi o. Pues-
t o que l os nue vos c o mp o n e n t e s s e i nt egr an a la bi bl i ot eca pr opi a de c o mp o n e n t e s
reut i l i zabl es, deben di s ea r s e par a su reut i l i zaci n.
TM
PDF Editor
Arqui t ect ura
CORBA bsi ca.
No hay na da mgi co e n la cr eaci n de c o mp o n e n t e s de s of t wa r e reut i l i zabl es. Los
concept os de di s eo t al es c o mo abst r acci n, ocul t aci n, i ndependenci a f unci onal ,
r ef i nami ent o y pr ogr amaci n es t r uct ur ada, j unt o con m t odos or i ent ados a obj et o,
pr ue ba s de SQA y m t odos de veri fi caci n de cor r ecci n, t odos cont r i buyen a la
cr eaci n de c ompone nt e s de s of t wa r e reut i l i zabl es. 3 En est a secci n n o s e vol ver n
a t r at ar e s t os t ema s . Ms bi en, s e cons i der ar n l os t e ma s espec f i cos de la reut i l i za-
ci n que c ompl e me nt a n l as pr ct i cas sl i das de i ngeni er a del s of t wa r e.
30.4.3 Anlisis y diseo par a la reutilizacin
El mode l o de anl i si s s e anal i za par a det er mi nar aquel l os e l e me nt os del model o que
a punt a n haci a l os c o mp o n e n t e s reut i l i zabl es exi st ent es. El pr obl ema es ext r aer i n-
f or maci n a part i r del mode l o de r equi si t os en una f or ma que c onduz c a a la "con-
cor danci a de especi f i caci ones".
Si la concor danci a de es peci f i caci ones pr oduce c ompone nt e s que se a j us t a n con
l as ne c e s i da de s de la apl i caci n act ual , el di s eador pue de ext r aer di chos c ompo-
ne nt e s de una bi bl i ot eca (depsi t o) de reut i l i zaci n y apl i car l os en el di s eo de nue -
vos si st emas. Si no encuent r a c ompone nt e s de di seo, el i ngeni er o de s of t war e de be
apl i car m t odos de di s eo convenci onal u OO par a cr ear l os. En est e punt o cuan-
d o el di s eador c omi e nz a a cr ear un nue vo c ompone nt e s e de be cons i der ar el di-
seo para la reutilizacin (DPR).
Como ya s e indic, el DPR r equi er e q u e el i ngeni er o de s of t wa r e apl i que sl i dos
c onc e pt os y pr i nci pi os de di s eo d e s of t wa r e (cap t ul o 9). Per o t ambi n s e deben
3 Para aprender ms acerca de estos concept os vanse las partes 2 y 5 de este libro.
TM
PDF Editor
cons i der ar la car act er st i cas del domi ni o de la apl i caci n. Bi nder [BIN93] sugi er e va-
ri os t e ma s cl ave" que f or man una ba s e par a el di s eo des t i na do a la reut i l i zaci n.
Da t o s e s t ndar . Se d e be i nvest i gar el domi ni o de la apl i caci n e i dent i fi car las
es t r uct ur as de dat os gl obal es (por ej empl o, es t r uct ur as de ar chi vos o una ba s e de da-
t os compl et a) . Ent onces s e pue de n car act er i zar t odos l os c o mp o n e n t e s de di s eo
par a a pr ovecha r di chas es t r uct ur as de da t os es t ndar .
Pr o t o c o l o s d e i nt erf az e s t ndar . Se deben est abl ecer t r es ni vel es de pr ot oco-
lo d e i nt er f az: la na t ur a l ez a de l as i nt er f aces i nt r amodul ar es , el di s eo de i nt er f aces
t cni cas (no huma na s ) ext er na s y la i nt er f az hombr e - m qui na .
Pl ant i l l as d e pr o g r a ma . El mode l o d e est r uct ur a (secci n 30.3.3) si rve c o mo
una pl ant i l l a par a el di s eo ar qui t ect ni co de un pr ogr a ma nuevo.
Una vez es t abl eci das l as i nt er f ases, l os da t os e s t nda r y l as pl ant i l l as de pr ogr a-
ma , el di s eador t i ene un ma r c o de t r a ba j o en el que pue de cr ear el di seo. Los nue -
vos c o mp o n e n t e s que se aj us t en a es t e ma r c o de t r abaj o t i enen una mayor pr obabi -
lidad de que s e les reutil ice pos t er i or ment e.
Cons i dr es e una bi bl i ot eca uni versi t ari a. Ci ent os de mi l es de libros, publ i caci ones
per i di cas y ot r as f uent es de i nf or maci n est n di sponi bl es par a ut i l i zarl os. Per o el
i ngr eso a di chas f ue nt e s r equi er e desar r ol l ar un s i s t ema de cl asi fi caci n. Par a nave-
gar por est e gr an vol umen de i nf or maci n, l os bi bl i ot ecari os han def i ni do un si st ema
de cl asi fi caci n que i ncl uye el cdi go de cl asi fi caci n de la Bi bl i ot eca del Congr es o
(en l os Es t ados Uni dos de Amri ca), pa l a br a s cl ave, nombr e s de aut or y ot r as ent r a-
da s de ndi ce. Todo es t o per mi t e que el us uar i o e nc ue nt r e r pi da y f ci l ment e la
f uent e r equer i da.
Ahor a, cons i dr es e un gr an deps i t o de c ompone nt e s . Ci ent os de mi l es de c om-
ponent es de s of t war e reut i l i zabl e s e hal l an e n l. Pero, cmo encuent r a un i ngeni e-
ro de s of t war e el c ompone nt e que necesi t a? Para r es ponder est a pr egunt a sur ge otra:
cmo s e descr i ben l os c ompone nt e s de s of t war e en t r mi nos cl asi fi cabl es y sin a m-
bi gedades? st as s on pr egunt as difciles y t odav a no s e ha desar r ol l ado una r espues-
ta defi ni t i va. En est a secci n s e expl or an l as t endenci as act ual es que permi t i rn a los
f ut ur os i ngeni er os de s of t war e na vega r ent r e l as bi bl i ot ecas de reut i l i zaci n.
30.5.1 Descripcin de los componentes reutilizables
Un c ompone nt e de s of t wa r e r eut i l i zabl es s e descr i be en mu c h a s f or mas , pe r o una
descr i pci n ideal i ncl uye lo q u e Tracz [TRA90] ha l l amado el modelo 3C: concept o,
cont eni do y cont ext o.
892
^ O N S E J O ^
El DPR puede sei bas-
tante difcil cuando los
componentes deben
estoi en interfaz o in-
tegrados con sistemas
heredados o con siste-
mas mltiples cuyo ar-
quitectura y protocolos
de interfaz sean in-
consistentes.
4 En general, se deben realizar preparativos para el DPR como parte de la ingeniera del dominio (sec-
cin 30.3).
TM
PDF Editor
CAPTULO 30 INGENIERA D A SOFTWARE BASADA EN COMPONENTES 893
El concepto de un c ompone nt e de s of t wa r e es " una descr i pci n de lo que ha c e el
c ompone nt e " [WHI95]. La i nt er f az con el c ompone nt e es t c ompl e t a me nt e descr i t a
y la s emnt i ca r epr esent ada dent r o del cont ext o de l as pr econdi ci ones y l as pos con-
diciones, i dent i fi cada. El concept o de be comuni car la i nt enci n del component e.
El contenido de un c ompone nt e descr i be c mo s e cons t r uye el concept o. En e s e n-
cia, el cont eni do es i nf or maci n ocul t a par a l os us uar i os habi t ual es y que s l o nece-
si t an conocer l a qui enes qui er an modi f i car o pr obar el c ompone nt e .
El contexto si t a un c ompone nt e de s of t wa r e r eut i l i zabl e en su domi ni o de apl i ca-
bi l i dad. Es decir, al especi f i car l as car act er st i cas concept ual es , oper at i vas y de
i mpl ement aci n el cont ext o per mi t e que un i ngeni er o de s of t war e e nc ue nt r e el c om-
pone nt e apr opi ado par a sat i sf acer l os r equi si t os de la apl i caci n.
Par a que s e a n t i l es en la pr ct i ca, concept o, cont eni do y cont ext o s e d e be n t ra-
duci r en un e s q ue ma de especi f i caci n concr et o. Se han escr i t o d oc e na s de e ns a yos
y ar t cul os acer ca de l os e s q u e ma s de cl asi fi caci n par a c ompone nt e s de s of t wa r e
reut i l i zabl es (por ej empl o, [LUC01 ] y [WHI95] cont i enen bi bl i ograf as ext ensas) . Los
m t odos pr opues t os se pue de n cl asi fi car en t r es gr a nde s r eas: m t odos de bi bl i ot e-
c onom a y de ci enci as de la comuni caci n, m t odos de i nt el i genci a artificial y si st e-
ma s de hi per t ext o. La gr an mayor a del t r abaj o r eal i zado ha s t a la f echa sugi er e el
e mpl e o de m t odos de bi bl i ot econom a par a la cl asi fi caci n de c ompone nt e s .
La figura 30. 3 pr es ent a una t a xonom a de l os m t od os de i ndexaci n en la bi bl i o-
t econom a . Los vocabularios controlados de indexacin l i mi t an l os t r mi nos o si nt axi s
con que s e cl asi fi ca un obj et o ( component e) . Los vocabularios de indexacin no con-
trolados no ponen r est r i cci ones en la nat ur al eza de la descr i pci n. La mayor a de los
e s q u e ma s de cl asi fi caci n par a l os c o mp o n e n t e s de s of t wa r e s e i ncl uye en t r es ca-
t egor as.
Cl as i f i c ac i n e n ume r a da . Los c o mp o n e n t e s s e descr i ben medi a nt e una es t r uc-
t ura j er r qui ca en la cual s e def i nen l as cl ases y l os ni vel es var i abl es de s ubcl as es de
l os c ompone nt e s de s of t wa r e. La es t r uct ur a j er r qui ca de un e s q u e ma de cl asi fi ca-
ci n e n u me r a d a facilita compr ender l o y util izarl o. Sin e mba r go, a nt e s de const r ui r
una j er ar qu a s e debe l l evar a c a bo la i ngeni er a del domi ni o de mo d o que haya su-
ficiente conoci mi ent o de l as e nt r a da s a de c ua da s en la j er ar qu a.
Cl as i f i c ac i n po r f a c e t a s . Se anal i za una r ea del domi ni o y s e i dent i fi ca un
c onj unt o de car act er st i cas descr i pt i vas bsi cas. Est as car act er st i cas, l l a ma da s face-
tas, e nt onc e s s e cl asi fi can s egn su i mpor t anci a y s e conect an con un c ompone nt e .
Una f acet a descr i be la f unci n que el c ompone nt e real i za, l os da t os que s e ma ni pu-
l an, el cont ext o en el que s e apl i can o cual qui er a ot ra car act er st i ca. El c onj unt o de
f acet as que descr i be un c ompone nt e s e de nomi na descriptor de facetas. En gener al ,
la descr i pci n por f acet as s e l imita a no m s de si et e u ocho f acet as.
Cl as i f i c ac i n de v a l o r e s y at ri but os . Un c onj unt o de at r i but os s e def i ne par a
t odos l os c ompone nt e s en ci ert a r ea del domi ni o. Ensegui da s e as i gnan val or es a
di chos at r i but os en una f or ma mu y si mi l ar a la cl asi fi caci n por f acet as. De hecho,
TM
PDF Editor
Indexaci n
d e vocabul ari os
Taxonom a d e
los mt odos de
i ndexaci n
[ F R A 9 4 ] .
Cont r ol ado Descont rol ado
Por cl ases Pal abr a cl ave Trminos ext ra dos Trminos no
del t ext o ext ra dos del texto
Enumer ada Descriptores
Por f a cet a s Encabezados
d e mat eri a
Con sintaxis
Sin sintaxis
Di cci onari o
la cl asi fi caci n de val or es y at r i but os es si mi l ar a la cl asi fi caci n por f acet as, con l as
si gui ent es excepci ones : 1) no s e l imita el n me r o de at r i but os que s e pue de n utili-
zar, 2) n o s e as i gnan pr i or i dades a l os at r i but os, y 3) no s e utiliza la f unci n di cci o-
nari o.
Con ba s e en un es t udi o emp r i co de ca da una de e s t a s t cni cas de cl asi fi caci n,
Fr akes y Pole [FRA94] i ndi can que n o exi st e una t cni ca cl ar ament e " me j o r y que
"ni ngn m t odo se d e s e mp e m s que mo d e r a d a me n t e e n la efi caci a de bs que-
da. . . " Par ecer a que t odav a falta real i za m s t r abaj o en el desar r ol l o de e s q u e ma s
de cl asi fi caci n ef i caces par a bi bl i ot ecas de reut i l i zaci n.
30.5.2 El entorno de reutilizacin
La reut i l i zaci n de c o mp o n e n t e s d e s of t wa r e de be apoyar l a un e nt or no que i ncl uya
l os s i gui ent es el ement os :
Una ba s e de d a t os de c o mp o n e n t e s c a pa z d e a l ma c e na r c o mp o n e n t e s de
s of t war e, as c o mo la i nf or maci n de cl asi fi caci n neces ar i a par a r ecuper ar -
Un s i s t ema de gest i n de bi bl i ot ecas que of r ezca a c c e s o a la ba s e de dat os.
Un s i s t ema de r ecuper aci n de c ompone nt e s de s of t war e (por ej empl o, un
di st ri bui dor de obj et os) que per mi t a que una apl i caci n cl i ent e r ecuper e c om-
pone nt e s y ser vi ci os del ser vi dor d e la bi bl i ot eca.
Her r ami ent as d e ISBC que a poye n la i nt egr aci n de l os c o mp o n e n t e s reutili-
z a d os en un nue vo di s eo o i mpl ement aci n.
los.
Cada una de e s t a s f unci ones i nt er act a con o es t i ncor por ada e n l os conf i nes de
una bi bl i ot eca de reut i l i zaci n.
TM
PDF Editor
CAPITULO 30 INGENIERA DEL SOFTWARE BASADA EN COMPONENTES 895
l i MI-l i l i Hl l i dl
t raren
h t t p : / / www.
cbd-hq.com/.
M
La bi bl i ot eca de reut i l i zaci n es un e l e me nt o de un depsi t o de s of t war e ma yor
(cap t ul o 27) y pr opor ci ona medi os par a el a l ma c e na mi e nt o de c o mp o n e n t e s de sof t -
wa r e y una ampl i a ga ma de pr oduct os de t r abaj o reut i l i zabl es (por ej empl o, es peci -
f i caci ones, di seos, pa t r ones , ma r c os de t r abaj o, f r a gme nt os de cdi go, c a s os de
pr ueba, gui as de usuari o). La bi bl i ot eca cont i ene una ba s e de da t os y l as he r r a mi e n-
t a s neces a r i a s par a consul t ar l a y r ecuper ar c ompone nt e s de el l a. Un e s q ue ma de
cl asi fi caci n de c ompone nt e s (secci n 30. 5. 1 ) si rve c o mo ba s e par a cons ul t ar la bi -
bl i ot eca.
Las cons ul t as us ua l me nt e s e car act er i zan medi a nt e el e l e me nt o cont ext o del mo-
del o 3C ya descr i t o en est a secci n. Si una consul t a inicial r esul t a en una ext ens a lis-
ta de c ompone nt e s candi dat os , la cons ul t a se r ef i na par a reduci rl a. Ent onces s e ex-
t r ae la i nf or maci n de c onc e pt o y cont eni do ( despus de hal l ar l os c ompone nt e s
candi dat os) par a auxi l i ar al desar r ol l ador e n la sel ecci n del c ompone nt e apr opi ado.
Una descr i pci n det al l ada de la est r uct ur a de l as bi bl i ot ecas de reut i l i zaci n y de
l as he r r a mi e nt a s q u e l as ges t i ona n es mej or dej r sel a a l as f ue nt e s es peci al i zadas en
la mat er i a. El l ect or i nt er es ado obt endr ma yor i nf or maci n cons ul t a ndo [F1S00] y
ILIN95],
Desarrollo basado en componentes
Obj e t i v o: Auxiliar en el model ado, diseo, re-
visin e integracin de los componentes de soft-
war e como part e de un sistema mayor.
M e c ni c a: La mecnico de las herramientas var a. En
general , las herramientas de DBC auxilian en una o ms
de las siguientes capaci dades: especificacin y model ado
de la arquitectura del software; navegacin y seleccin de
los componentes de software disponibles; integracin de
componentes.
H erramientas representati v as5
ComponentSource (www.componentsource.com) propor-
ciona un ampl ia serie de componentes (y herramientas)
de software CDL apoyado en muchos est ndares de
componentes diferentes.
Component Manager, desarrol l ada por Flashline (www-
.flashline.com), "es una aplicacin que posibilita, pro-
mueve y mide la reutilizacin de componentes de
software".
Select Component Factory, desarrol l ada por Select Busi-
ness Solutions (www.selectbs.com/products), "es un
conjunto integrado de productos par a el diseo de soft-
war e, revisin de diseo, gestin de servicios y compo-
nentes, gestin de requisitos y generacin de cdigo".
Software Through Pctures-ACD, distribuida por Aonix
(www.aonix.com), permite el model ado integral em-
pl eando UML par a la arquitectura que rige el model o
OMG; un enfoque par a la ISBC abi ert a e independien-
te de la empresa.
3 Q . 6 E C O N O M A PE LA I S B C
La i ngeni er a del s of t wa r e ba s a da en c o mp o n e n t e s t i ene un at r act i vo i nt ui t i vo. En
t eor a, de be pr opor ci onar a una or gani zaci n de s of t wa r e vent a j a s en c ua nt o a cali-
5 Las herramientas expuestas slo representar una muestra de esta categora. En la mayora de los
casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores.
TM
PDF Editor
Uno diversidad de or f t
culos que ofrecen direc-
trices poro el DBCy los
sistemas bosodos en
CDL se puede encontrar
en www. s e i . c mu .
edu.
dad y opor t uni dad, lo que de be t r aduci r s e e n ahor r os. Pero, exi st en dat os r eal es que
a poye n est a i nt ui ci n?
La r espuest a a est a pr egunt a pr i mer o requi ere ent ender lo que en real i dad s e puede
r eut i l i zar en un cont ext o de i ngeni er a del s of t wa r e y l uego cul es s on en real i dad
l os cos t os a s oci a dos con la reut i l i zaci n. Como cons ecuenci a , s er posi bl e desar r o-
llar un anl i si s cost o- benef i ci o par a la reut i l i zaci n de c ompone nt e s .
30.6.1 Impacto sobre la calidad, la productividad y el costo
Exi st en nume r os a s evi denci as, a part i r de est udi os de c a s o i ndust r i al es (por ej empl o,
[ALL02], [HEN95], [MCM95]), que i ndi can la posi bi l i dad de der i var s us t anci al es bene-
ficios de negoci os a part i r de la reut i l i zaci n vi gor osa del s of t war e. Mej or an la cali-
dad del pr oduct o, la pr oduct i vi dad de desar r ol l o y el cost o gl obal .
Cal i dad. En un e nt or no ideal , un c ompone nt e de s of t war e que s e desar r ol l e par a
reut i l i zaci n s e veri fi car a c o mo cor r ect o ( vase el cap t ul o 29) y no cont endr a de -
fect os. En r eal i dad, la veri fi caci n f or mal no se l l eva a c a bo de ma n e r a r ut i nar i a y
exi st e la posi bi l i dad de que ocur r an def ect os, y de he c ho ocur r en. Si n emba r go, con
ca da reut i l i zaci n los def ect os s e e nc ue nt r a n y el i mi nan, y, c o mo r esul t ado, mej or a
la cal i dad del c ompone nt e . Con el t i empo el c ompone nt e q ue d a vi r t ual ment e libre
de def ect os.
En un es t udi o r eal i zado en Hewl et t - Packar d, Lim [LIM94] r epor t que la t as a de
def ect os par a el cdi go reut i l i zado es de 0. 9 def ect os por KLDC, mi ent r a s que la t a-
sa par a s of t wa r e des ar r ol l ado r eci ent ement e es de 4.1 def ect os por KLDC. En una
apl i caci n c ompue s t a de 68 por ci ent o de cdi go r eut i l i zado la t a s a de def ect o f ue
de 2. 0 def ect os por KLDC, es deci r: un 51 por ci ent o de mej or a r es pect o de la t asa
e s pe r a da si la apl i caci n hubi es e s i do desar r ol l ada sin reut i l i zaci n. Henry y Faller
[HEN95] r epor t a un 35 por ci ent o de mej or a e n la cal i dad. Aunque l os r epor t es a ne c -
dt i cos abar can un es pect r o r a z ona bl e me nt e ampl i o de por c e nt a j e s de mej or a e n la
cal i dad, es j ust o af i r mar que la reut i l i zaci n of r ece un benef i ci o i mpor t ant e en cuan-
t o a la cal i dad y fiabilidad par a el s of t wa r e ent r egado.
Product i v i dad. Cua ndo l os c o mp o n e n t e s r eut i l i zabl es s e apl i can a lo l argo del
pr oces o de s of t war e, s e dedi ca me n o s t i empo a la cr eaci n de pl anes, model os , do-
cument os , cdi go y dat os que s e r equi er en par a cr ear un s i s t ema fiable. Por lo t a n-
to, s e ent r ega al cl i ent e el mi s mo ni vel de f unci onal i dad con me n o s es f uer zo, lo que
mej or a la pr oduct i vi dad. Aunque l os r epor t es de mej or a por cent ual en la product i vi -
dad s on not a bl e me nt e di f ci l es de i nt er pr et ar , 6 par ece que la reut i l i zaci n del 30 al
50 por ci ent o puede r esul t ar en me j or a s en la pr oduct i vi dad en el r ango del 25- 40 por
ci ent o.
6 Muchas circunstancias at enuant es (por ejemplo, dominio de aplicacin, complejidad del problema,
estructura y t amao del equipo, duracin del proyecto, tecnologa aplicada) tienen un profundo im-
pacto sobre la productividad del equipo del proyecto.
TM
PDF Editor
CAPTULO 30 INGENIERA D A SOFTWARE BASADA EN COMPONENTES
897
^CONSEJ O^-
El costo de desarrollar
un componente reutilh
zable con frecuencia
es mayor que el de
desarrolloi un compo-
nente especfico para
una aplicacin. Aseg-
rese de que en el futu-
ro habr uno
necesidad lespecto del
componente reutiliza-
ble. Aqu es donde se
realiza lo retribucin.
Co s t o . Los a hor r os en el cos t o ne t o por la reut i l i zaci n s e es t i man al pr oyect ar el
cos t o del pr oyect o si st e f ues e des ar r ol l ado de s de cer o, C0, y l uego s e r est a la s uma
de l os cos t os a s oci a dos con la reut i l i zaci n, Cr, y el cos t o real del s of t wa r e en el mo-
me n t o de la ent r ega, Q.
El f act or C0 s e pue de det er mi nar al apl i car una o m s de las t cni cas de es t i ma-
ci n es t udi adas en el cap t ul o 23. Los cost os asoci ados con la reutil izacin, C incl uyen
[CHR95]: anl i si s y mode l a do del domi ni o, desar r ol l o de ar qui t ect ur a del domi ni o,
a u me n t o en la doc ume nt a c i n par a faci l i t ar la reut i l i zaci n, s opor t e y mej or a de los
c ompone nt e s de r eut i l i zaci n, r egal as y l i cenci as par a c ompone nt e s adqui r i dos ex
t er nament e, cr eaci n o adqui si ci n y oper aci n de un depsi t o de reut i l i zaci n, y en-
t r e na mi e nt o del per sonal en di s eo y const r ucci n par a reut i l i zaci n. Aunque l os
cost os a s oci a dos con el anl i si s del domi ni o (secci n 30.3) y la oper aci n de un de-
psi t o de reut i l i zaci n pue de n s er sust anci al es, mu c h o s de l os ot r os cost os i ndi ca-
dos aqu abor dan l os confl i ct os que f or man par t e de una buena prct i ca de i ngeni er a
de s of t war e, ya s ea que la r eut i l i zaci n s ea o no una pri ori dad.
30.6.2 Anlisis de costo empl eando puntos de estructura
En la secci n 30. 3. 3 s e def i ni un punt o de est r uct ur a c o mo un pat r n ar qui t ect ni -
co r ecur r ent e en la t ot al i dad de un domi ni o de apl i caci n part i cul ar. Un di s eador de
s of t wa r e (o i ngeni er o de si st emas) pue de desar r ol l ar una ar qui t ect ur a par a una nue-
va apl i caci n, si st ema o pr oduct o al defi ni r una ar qui t ect ur a del domi ni o y l uego do-
t arl a con punt os de est r uct ur a. st os s on o c ompone nt e s r eut i l i zabl es i ndi vi dual es o
pa que t e s de c ompone nt e s reut i l i zabl es.
Aunque l os punt os de est r uct ur a s e a n reut i l i zabl es, s us c os t os de cual i fi caci n,
adapt aci n, i nt egr aci n y ma nt e ni mi e nt o n o s on i nsi gni f i cant es. Ant es de pr oceder
a la reut i l i zaci n el ges t or del pr oyect o de be c ompr e nde r l os cos t os a s oci a dos con la
ut i l i zaci n de l os punt os de est r uct ur a.
Dado que t odos l os punt os de est r uct ur a (y l os c o mp o n e n t e s reut i l i zabl es en ge-
neral ) t i enen una hi st ori a, es posi bl e recopi l ar dat os de cos t os de ca da uno. En un
cont ext o i deal l os cos t os de cal i fi caci n, adapt aci n, i nt egr aci n y ma nt e ni mi e nt o
a s oci a dos con ca da c ompone nt e en una bi bl i ot eca de r eut i l i zaci n se ma nt i enen pa-
ra ca da c a s o de ut i l i zaci n. Ent onces se pue de n anal i zar di chos da t os par a des ar r o-
llar l os cos t os pr oyect a dos r es pect o del si gui ent e c a s o de reut i l i zaci n.
Como ej empl o, cons i dr es e una nueva apl i caci n, X, que r equi er e 60 por ci ent o
de cdi go nue vo y la reut i l i zaci n de t r es punt os de est r uct ur a: PE,, PE2 y PE.,. Cada
u n o de es t os c ompone nt e s reut i l i zabl es s e ha ut i l i zado en mu c h a s ot r as apl i caci o-
nes, y es t n di sponi bl es l os c os t os pr omedi o par a cual i fi caci n, adapt aci n, i nt egr a-
ci n y ma nt eni mi ent o.
La est i maci n del esf uer zo necesari o para ent regar X requi ere det ermi nar lo siguiente:
es f uer z o gl obal = Enu
d ond e
TM
PDF Editor
nuevo = e s f ue r z o r equer i do par a di s ear y const r ui r nue vos c o mp o n e n t e s de
s of t wa r e ( det er mi nados e mpl e a nd o l as t cni cas descr i t as en el cap -
t ul o 23)
Ecaiir = e s f ue r z o r equer i do par a cal i fi car PE, , PE2 y PE3
adapi = e s f ue r z o r equer i do par a a da pt a r PE, , PE2 y PE3
int = e s f ue r z o r equer i do par a i nt egr ar PE,, PE2 y PE3
El e s f ue r z o r equer i do par a cual i fi car, a da pt a r e i nt egr ar PE,, PE2 y PE3 s e det er mi na
al t oma r el pr omedi o de l os da t os hi st r i cos r ecopi l ados par a la cual i fi caci n, adap-
t aci n e i nt egr aci n de l os c o mp o n e n t e s reut i l i zabl es e n ot r as apl i caci ones.
La i ngeni er a del s of t wa r e ba s a da en c o mp o n e n t e s of r ece benef i ci os i nher ent es en
la cal i dad del s of t war e, la pr oduct i vi dad del desar r ol l ador y el c os t o gl obal del si st e-
ma. Sin emba r go, f al t a s uper a r mu c h o s obs t cul os a nt e s de que el model o d e pr o-
ces o de ISBC s e utilice a mpl i a me nt e e n la i ndust ri a.
Ade m s de los c ompone nt e s del sof t war e, un i ngeni er o de s of t war e puede adqui ri r
una ampl i a ga ma de ar t ef act os reut i l i zabl es. Ent re s t os s e e nc ue nt r a n r epr es ent a-
ci ones t cni cas del s of t wa r e (por ej empl o, especi f i caci ones, mode l os ar qui t ect ni -
cos, di seos) , doc ume nt os , pat r ones , ma r c os de t r abaj o, da t os de pr ueba e i ncl uso
t ar eas r el aci onadas con el pr oces o (por ej empl o, i ns pecci ones t cni cas) .
El pr oces o de ISBC i ncl uye dos s ubpr oc e s os concur r ent es : la i ngeni er a del domi -
ni o y el desar r ol l o ba s a do en c ompone nt e s . La finalidad de la i ngeni er a del domi ni o
es i dent i fi car, const rui r, cat al ogar y di s emi nar un c onj unt o de c ompone nt e s de sof t -
wa r e en un domi ni o de apl i caci n espec f i co. Ent onces el desar r ol l o ba s a d o en c om-
ponent es califica, adapt a e integra di chos c ompone nt e s par a empl ear l os en un nuevo
si st ema. Adems , el desar r ol l o ba s a do en c o mp o n e n t e s di s ea los c ompone nt e s
nue vos que s e ba s a n en l os r equi si t os per s ona l i z a dos de un s i s t ema nuevo.
Las t cni cas de anl i si s y di s eo par a c ompone nt e s r eut i l i zabl es s e ba s a n en l os
mi s mos pr i nci pi os y concept os que f or man par t e de una bue na pr ct i ca de i ngeni e-
ra del s of t war e. Los c o mp o n e n t e s reut i l i zabl es deben di s ea r s e en un e nt or no que
es t abl ezca es t r uct ur as de da t os es t ndar , pr ot ocol os de i nt er f az y ar qui t ect ur as de
pr ogr a ma par a ca da domi ni o de la apl i caci n.
La ingenier a del s of t war e bas ada en component es utiliza un model o de i nt ercam-
bio de dat os, her r ami ent as, a l ma cena mi ent o est r uct ur ado y un model o de obj et o sub-
yacent e par a const rui r l as apl i caci ones. El model o de obj et o gener al ment e concuer da
con uno o m s es t ndar es de c ompone nt e s (por ej empl o, OMG/CORBA) que def i nen
la f or ma en que una apl i caci n puede acceder a los obj et os reutil izabl es. Los e s q ue ma s
de cl asificacin per mi t en que un desar r ol l ador encuent r e y r ecuper e c ompone nt e s reu-
t i l i zabl es y s e aj us t e a un model o que i dent i fi ca concept o, cont eni do y cont ext o. La
cl asi fi caci n e nume r a d a , la cl asi fi caci n por f a cet a s y la cl asi fi caci n de val or es y
at r i but os s on r epr esent at i vas de muc hos e s que ma s de cl asificacin de component es .
TM
PDF Editor
C A P T U L O 3 0 INGENIERA DEL SOFTWARE BASADA EN COMPONENTES
899
La econom a de la reutil izacin del sof t war e se abor da medi ant e una sola pr egun-
ta: es efectivo en cost o el construir menos y reutilizar ms ? En general , la respuest a
e s s, per o un pl ani fi cador de proyect os de sof t war e debe consi der ar los cost os im-
por t ant es asoci ados con la calificacin, adapt aci n e i nt egraci n de los componen-
t es reutilizables.
[ADL95] Adler, R. M., "Emerging Standards for Component Software", en Computer, vol 28, nm.
3, marzo de 1995, pp. 68-77.
[ALL021 Alien, P., "CBD Survey: The State of the Practice", en The Cutter Edge, marzo de 2002,
disponible en http://www.cutter.com/research/2002/edge020305.html.'
[ATK0I) Atkinson, C., et al., Component-Based Product Line Engineerng wilh UML, Addison-Wes-
ley, 2001,
[BAS94] Basili, V. R., L. C. Briand y W. M. Thomas, "Domain Analysis for the Reuse of Software
Development Experiences", Proc. Of the I9th Annual Software Engineerng Workshop, NA-
SA/GSFC, Greenbelt, MD, diciembre de 1994.
[B1N93] Binder, R., "Design for Reuse is for Real", en American Programmer, vol. 6, nm. 8, agos-
to de 1993, pp. 30-37.
[BR0961 Brown, A. W., y K. C. Wallnau, "Engineerng of Component-Based Systems", en Com-
ponent-Based Software Engineerng, IEEE Computer Society Press, 1996, pp. 7-15.
(CHR951 Christensen, S. R "Software Reuse Initiatives at Lockheed", en CrossTalk, vol. 8, nm.
5, mayo de 1995, pp. 26-31.
[CLE95J Clements, P. C., "From Subroutines to Subsystems: Component-Based Software Deve-
lopment", en American Programmer, vol. 8, nm. 11, noviembre de 1995.
|DOG03] Dogru, A., y M. Tanik, "A Process Model for Component-Oriented Software Enginee-
rng", en IEEE Software, vol. 20, nm. 2, marzo-abril 2003, pp. 34-41.
[FIS00] Fischer, B "Specification-Based Browsing of Software Component Libraries", en ). Auto-
mated Software Engineerng, vol. 7, nm. 2, 2000, pp. 179-200, disponible en http://ase.arc-
.nasa.gov/people/fischer/papers/ase-00.html.
[FRA94) Frakes, W. B., yT. P. Pole, "An Empirical Study of Representation Methods for Reusable
Software Components", en IEEE Trans. Software Engineerng, vol. SE-20, nm. 8, agosto de
1994, pp. 617-630.
[HEI01] Heineman, G., y W. Councill (eds ), Component-Based Software Engineerng, Addison-
Wesley, 2001.
[HEN95J Henry, E y B. Faller, "Large Scale Industrial Reuse to Reduce Cost and Cycle Time", en
IEEE Software, septiembre de 1995, pp. 47-53.
[HUT881 Hutchinson, J. W., y P. G. Hindley, "A Preliminary Study of Large Scale Software Reuse",
en Software Engineerng Journal, vol. 3, nm. 5, 1988, pp. 208-212.
[LIA93] Liao, H., y Wang, F., "Software Reuse Based on a Large Object-Oriented Library", en ACM
Software Engineerng Notes, vol. 18, nm. 1, enero de 1993, pp. 74-80.
[L1M941 Lim, W. C., "Effects of Reuse on Quality, Productvity, and Economics", en IEEE Softwa-
re, septiembre de 1994, pp. 23-30.
|LIN95] Linthicum, D. S "Component Development (a Special Feature)", Application Develop-
ment TYends, junio de 1995, pp. 57-78.
(LUC01] deLucena, Jr., V., "Facet-Based Classification Scheme for Industrial Software Compo-
nents", 2001, se puede descargar de http://research.microsoft.com/users/cszypers/e-
vents/WCOP2001 /Lucena.pdf
[MCM95] McMahon, P. E., "Pattem-Based Architecture: Bridging Software Reuse and Cost Ma-
nagement", en Crosstalk, vol. 8. nrr 3, marzo de 1995, pp. 10-16.
[ORF96] Orfali, R., D. HarkeyyJ. Edwards. The Essenal Distributed Objects Survival Guide, Wiley,
1996.
[PR193] Prieto-Daz, R., "Issues and Exper.ences n Software Reuse", en American Programmer,
vol. 6, nm. 8, agosto de 1994, pp 67-68
TM
PDF Editor
900 P ARTE C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
|POL94] Pollak, W. y M. Rissman, "Structural Models and Patterned Architectures", en Computer
vol. 27, nm. 8, agosto de 1994, pp.67-68.
[STA94] Staringer, W., "Constructing Applications from Reusable Components", en IEEE Softwa-
re, septiembre de 1994, pp. 61-68.
1TRA90] Tracz, W., "Where Does Reuse Start?", Proc. Realities ofReuse Workshop, Syracuse Un
versity CASE Center, enero de 1990.
[TRA951 Tracz, W., "Third International Conference on Software Reuse-Summary", en ACM Soft-
ware Engineering Notes, vol. 20, nm. 2, abril de 1995, pp. 21-22.
[WH195] Whittle, B., "Models and Languages for Component Description and Reuse", en ACM
Software Engineering Notes, vol. 20, nm. 2, abril de 1995, pp. 76-89.
[YOU98] Yourdon, E. <ed.), "Distributed Objects", en Cutter IT Journal, vol. 11, nm. 12, diciem-
bre de 1998.
30.1. Uno de los obstculos clave para la reutilizacin consiste en hacer que los desarrollado-
res de software consideren la reutilizacin de componentes existentes en lugar de reinventar
unos nuevos (despus de todo, construir cosas es divertido!). Sugerir de tres a cuatro formas
diferentes en que una organizacin de software puede ofrecer incentivos para que los ingenie-
ros de software empleen la reutilizacin. Qu tecnologas deben existir para apoyar el esfuer-
zo de la re utilizacin?
30.2. Aunque los componentes de software son los "artefactos" reutilizables ms obvios, se
pueden reutilizar muchos otros productos de trabajo producidos como parte de la ingeniera del
software. Considerar los planes de proyecto y las estimaciones de costo. Cmo se pueden reu-
tilizar y cul es el beneficio de hacerlo?
30.3. investigese un poco acerca de la ingeniera del dominio y detllese el modelo de proce-
so esbozado en la figura 30.1. Identifiqense las tareas que se requieren para el anlisis del do-
minio y el desarrollo arquitectnico del software.
30.4. En qu son semejantes las funciones de caracterizacin para dominios de aplicacin y
los esquemas de clasificacin de componentes? En qu se diferencian?
30. 5. Desarrollar un conjunto de caractersticas de dominio para sistemas de informacin que
sean relevantes respecto al procesamiento de datos de estudiantes de una universidad.
30.6. Desarrollar un conjunto de caractersticas de dominio que sean relevantes para un soft-
ware de procesamiento de textos y publicacin.
30.7. Desarrollar un modelo estructural simple para un dominio de aplicacin que asigne indi-
vidualmente el instructor o uno con el cual se est familiarizado.
30.8. Qu es un punto de estructura?
30.9. Adquirir informacin acerca del ms reciente estndar CORBA, COM o JavaBeans y ela-
borar un ensayo de tres a cinco pginas que aborde sus principales atributos. Obtener informacin
acerca de una herramienta de distribucin de solicitudes de objetos e ilustrar cmo la herra-
mienta se ajusta al estndar.
3 0 . 1 0 . Desarrollar una clasificacin enumerada para un dominio de aplicacin que asigne el
instructor o uno con el que se est familiarizado.
3 0 . 1 1 . Desarrollar un esquema de clasificacin por facetas para un dominio de aplicacin que
asigne el instructor o uno con el que se est familiarizado.
3 0 . 1 2 . Investigese en la bibliografa para obtener datos recientes de calidad y productividad
que apoyen el uso de la 1SBC. Presntense los datos a la clase.
TM
PDF Editor
C A P T U L O 3 0 INGENIERA DEL SOFTWARE BASADA EN COMPONENTES 901
En aos recientes se han publicado muchos libros acerca del desarrollo basado en componen-
tes y la reutilizacin de stos. Heineman y Councill [HEI01 ], Brown (Large Scale Component-Based
Development, Prentice-Hall, 2000), Alien (Realizing e-Business with Components, Addison-Wesley,
2000), Herzum y Sims (Business Component Factory, Wiley, 1999) y Alien, Frost y Yourdon (Com-
ponent-Based Development for Enterprise Systems: Applying the Select Perspective, Cambridge Uni-
versity Press, 1998) cubren todos los aspectos importantes del proceso de ISBC. Apperly y sus
colegas (Service- and Component-Based Development, Addison-Wesley, 2003), Atkinson [ATK01]
y Cheesman y Daniels ( JML Components, Addison-Wesley, 2000) examinan la ISBC poniendo es-
pecial cuidado en UML.
Leach (Software Reuse: Methods, Models, and Costs, McGraw-Hill, 1997) proporciona un an-
lisis detallado de los conflictos de costo asociados con la ISBC y la reutilizacin. Poulin (Measu-
ring Software Reuse: Principies, Practices, and Economic Models, Addison-Wesley, 1996) sugieren
algunos mtodos cuantitativos para valorar los beneficios de la reutilizacin de software.
En aos recientes se han publicado docenas de libros que describen los estndares basados
en componentes de la industria. En ellos se abordan las funciones internas de los estndares
mismos, pero tambin consideran muchos tpicos importantes de la ISBC. A continuacin se
presenta una muestra de los tres estndares estudiados en este capitulo:
CORBA
Bolton, F., Pur CORBA, Sams Publishing, 2001.
Doss, G. M., CORBA Networking With Java, Wordware Publishing, 1999.
Hoque, R CORBA for Real Programmers, Academic Press/Morgan Kaufmann, 1999.
Si e ge l , CORBA Fundamentis and Programming, Wiley, 1999.
Slama, D., J. Garbis y P. Russell, Enterprise CORBA, Prentice-Hall, 1999.
COM
Box, D., K. Brown, T. Ewald y C. Sells, Effective COM: 50 Ways to Improve YourCOM- and MTS-
Based Applications, Addison-Wesley, 1999.
Gordon, A., The COM and COM+ Programming Primer, Prentice-Hall, 2000.
Kirtland, M., Designing Component-Based Applications, Microsoft Press, 1999.
Tapadiya, P., COA+ Programming, Prentice-Hall, 2000.
Muchas organizaciones aplican una combinacin de estndares de componentes. Los libros de
Geraghty y sus colegas [COM-CORBA Interoperability, Prentice-Hall, 1999), Pritchard (COM and
CORBA Side by Side: Architectures, Strategies, and Implementations, Addison-Wesley, 1999), y Ro-
sen y sus colegas (Integrating CORBA y COM Applications, Wiley, 1999) consideran los conflictos
asociados con el uso tanto de CORBA como de COM como la base para el desarrollo basado en
componentes.
JavaBeans
Asbury, S., y S. R. Weiner, Developing Java Enterprise Applications, Wiley, 1999.
Anderson, G., y P. Anderson, Enterprise Javabeans Component Architecture, Prentice-Hall,
2002.
Monson-Haefel, R., Enterprise Javabeans, tercera edicin, O'Reilly & Associates, 2001.
Romn, E., etal., Mastering Enterprise Javabeans, 2a. ed., Wiley, 2001.
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de la ingenie-
ra del software basada en componentes. Una lista actualizada de referencias en la World Wide
Web se puede encontrar en el sitio Web SEPA
ht t p: / / www. mhhe. com/ pressmai i .
TM
PDF Editor
C A P I T U L O
31
^
CONCEPTOS
CLAVE
anlisis de
inventarios... .909
arquitecturas
c/s 920
arquitecturas
00 921
economa 923
ingeniera
directa 918
ingeniera
inversa 912
mantenimiento .906
modelo de
proceso RPN...903
proceso de
reingeniera . . .908
reestructuracin 916
reestructuro
de datos .917
REINGENIERA
E
n un r el evant e ar t cul o publ i cado e n la H arvard Business Review, Mi chael
Ha mme r [HAM90] s e nt l as ba s e s par a una r evol uci n e n el pe ns a mi e nt o
admi ni st r at i vo acer ca de l os pr oces os de negoci os y la comput aci n:
Es el momento de dejar de pavimentar los senderos para vacas. En lugar de incrus-
tar procesos anticuados en silicio y software, debemos eliminarlos y comenzar de
nuevo. Debemos someter a "reingeniera" nuestros negocios: usar el poder de las
modernas tecnologas de la informacin para redisear radicalmente nuestros pro -
cesos de negocios con la finalidad de alcanzar mejoras radicales en su desempeo.
Cualquier compaa opera de acuerdo con una gran cantidad de reglas desarticu-
ladas... La reingeniera lucha por separarse de las viejas reglas acerca de cmo or-
ganizar y dirigir nuestros negocios.
Al igual que t odas l as revol uci ones, el l l amado a l as a r ma s de Hammer gener
c a mbi os posi t i vos y negat i vos. Dur ant e el deceni o de 1990, a l guna s c ompa a s
apl i car on un es f uer zo l eg t i mo en la r eal i zaci n de r ei ngeni er a, y l os r es ul t ados
l as conduj er on a mej or a r su compet i t i vi dad. Ot r as se a poya r on excl us i vament e
e n el r edi mens i ona mi ent o y la s ubcont r at aci n (en l ugar de la re ngeni er a) par a
me j or a r s us l neas ba s e; por lo t ant o, con f r ecuenci a r esul t ar on or gani zaci ones
con poc o pot enci al par a un cr eci mi ent o f ut ur o [DEM95].
Dur ant e es t a pr i mer a dca da del si gl o xxi, la pr omoc i n exa ger a da de la rei n-
geni er a ha deca do, pe r o el pr oc e s o en s cont i na en c ompa a s gr a nd e s y
pequea s . Los ne xos ent r e la r ei ngeni er a de negoci os e i ngeni er a del s of t wa r e
se e nc ue nt r a n e n una revi si n de si st ema.
M Qu e s ? Considere cualquier produc-
V to tecnolgico que le haya servido bien.
Usted lo utiliza regularmente, pero se
est volviendo obsoleto. Se rompe con
mucha frecuencia, su reparacin toma ms tiempo
del que usted quisiera, y ya no representa ms la
nueva tecnologa. Qu hacer? Si el producto es
hardware, probablemente usted lo tirar a la basu-
ra y comprar un modelo ms nuevo. Pero si es soft-
ware personalizado, dicha opcin tal vez no est
disponible. Necesitar reconstruirlo. Crear un pro-
: . no con una mejor funcionalidad, mejor desem-
peo y fiabilidad, as como una mejor facilidad de
mantenimiento. A eso se le llama reingeniera.
Qui n l a hace? En el mbito de las organizacio-
nes, la reingeniera la llevan a ca bo especialistas
en negocios (con frecuencia compa as consulto-
ras). En el mbito del software la reingeniera la
realizan los ingenieros de software.
Por qu es i mportante? Se vive en un mundo en
cambi o constante, t as demandas acerca de las fun-
ciones de negocios y la tecnologa de la informa-
cin que ios soportan estn cambi ando a un ritmo
que impone una enorme presin competitiva en las
TM
PDF Editor
CAP TULO 3 1 REINGENIERA 903
organizaciones comerciales. Tanto el negocio como
el software que soporta (o es) el negocio debe redi-
searse par a mantener el ritmo.
Cul es son l os pas os ? La reingeniera de proce-
sos de negocio (RPN) define las metas del negocio,
identifica y evala los procesos vigentes del nego-
cio, y crea procesos de negocios renovados que
cumplen mejor las metas actuales El proceso de
reingeniera de software incluye anlisis de inventa-
rios, reestructuracin de documentos, ingeniera
inversa, reestructuracin de programas y datos, e
ingeniera avanzada. La finalidad de estas activida-
des es crear versiones de programas existentes que
muestren mayor calidad y mejor facilidad de man-
tenimiento.
Cul e s el producto obt eni do? Se produce una
diversidad de productos de trabajo de reingeniera
(por ejemplo, modelos de anlisis, modelos de dise-
o, procedimientos de prueba). El resultado final es
Un pr oceso de rengeniera de negoci os o el soft-
ware de reingeniera que b soporta.
hecho correctamente? Utilice las mismas prcti-
cas de SQA que se aplican o cualquier procesa de
ingeniera del software: las revisiones tcnicas for-
males evalan los modelos de anlisis y de diseo;
las revisiones especializadas consideran la aplica-
bifidad y ia compatibilidad en el negocio; y las prue-
bas se aplican par a descubrir errores en contenido,
funcionalidad e interoperabilidad.
\
CLAVE
Lo RPN con f r ecuenci a
ge ne r a uno nueva
f unci onal i dad de
s of t wa r e , mi e nt r a s q ue
la rei ngeni er a del
s of t wa r e t r abaj a pa r a
r eempl azor la
f unci onal i dad del
s of t wa r e exi s t ent e con
un mej or s of t wa r e y d e
ma y o r faci l i dod de
ma nt e ni mi e nt o.
Us ua l ment e el s of t wa r e e s la r eal i zaci n de l as r egl as del negoci o que Ha mme r
descr i be. Conf or me c a mbi e n di chas regl as, el s of t wa r e t ambi n de be hacer l o. En la
act ual i dad, l as gr a ndes c ompa a s t i enen de c e na s de mi l es de pr ogr a ma s de compu-
t ador a que apoyan a l as vi ej as regl as del negoci o. A medi da que los admi ni st r ador es
t r abaj en en la modi fi caci n de l as r egl as y l ogren mayor es efect i vi dad y compet i t i vi -
dad, el s of t wa r e de be ma nt e ne r el ri t mo. En a l gunos cas os , es t o i mpl i ca la cr eaci n
de ma yor e s y nue vos s i s t e ma s ba s a d os en comput a dor a . 1 Pero, en mu c h o s ot r os,
si gni fi ca la modi f i caci n o r econst r ucci n d e l as apl i caci ones exi st ent es.
En est e cap t ul o s e e xa mi na la r ei ngeni er a e n f or ma des cendent e, c o me n z a n d o
con un br eve pa nor a ma de la r ei ngeni er a de pr oces os d e negoci o y de s pu s s e abor -
d a n con ma yor det al l e l as act i vi dades t cni cas que s e l l evan a c a bo al r eal i zar la
r ei ngeni er a del s of t war e.
3 1 . 1 R E N G E N I E R A P E P R OC E S OS P E N E S Q C I P
La r ei ngeni er a de pr oces os de negoci o (RPN) r ebas a el mbi t o de l as t ecnol og as de
la i nf or maci n y de la i ngeni er a del s of t war e. Ent re l as mu c h a s def i ni ci ones (la
mayor a un t a nt o abst r act a) s uger i das par a la RPN des t aca una publ i cada e n la revi s-
ta Fortune [STE93]: "La bs que da e i mpl ement aci n de un c a mbi o radi cal e n el pr o-
c e s o de negoci os par a l ograr r es ul t ados de vanguar di a". Pero, c mo se l l eva a c a bo
la bs que da y c mo s e l ogra la i mpl ement aci n? Ms i mpor t ant e a n, c mo s e
pue de gar ant i zar que el "cambi o r adi cal " s uger i do conduci r a "r esul t ados de van-
guar di a" e n l ugar de c a os or gani zaci onal ?
I La explosin de aplicaciones y sistemas basados en Web estudiados en la parte 3 de este libro es un
indicio de esta tendencia.
TM
PDF Editor
9 0 4 PARTE CI NCO TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
" Enf r ent ar el ma a n o con la i deo de e mpl e a r los mt odos de ayer e s vi sual i zar l a vi do t o mo una par l i si s. "
J a m e s Bel l
^ O N S E J O ^
Como ingenieio de
softwote, su trabajo lo
desempe o en lo base
de esto jerarq ua. Sin
embargo, aseg rese
de q ue alguien ha
pensado seriamente
en los niveles supe-
riores. Si esto no ha
ocurrido, su trobo jo
esi en nesgo.
Araplja infcmottn
acerco de la RPff s e
puede encontrar en
www. b r i n l . c o m/
BPR.htm.
31.1.1 Procesos de negoci os
Un pr oces o de negoci o es "un conj unt o de t ar eas l gi cament e r el aci onadas q u e s e
ej ecut an par a l ograr un r esul t ado de negoci os espec fi co" [DAV90]. Dent r o del pr o-
ces o de negoci o, la gent e, el equi po, l os r ecur s os mat er i al es y l os pr ocedi mi ent os del
negoci o s e combi na n par a pr oduci r un r es ul t ado espec f i co. Los ej empl os de pr oce-
s os de negoci os i ncl uyen el di s eo de un nue vo pr oduct o, la c ompr a de ser vi ci os y
sumi ni st r os, la cont r at aci n de un nue vo e mpl e a do y el p a g o a pr oveedor es . Cada
u n o d e ma n d a un conj unt o de t ar eas y t a mbi n empl ea di ver sos r ecur s os dent r o del
negoci o.
Cada pr oces o de negoci o t i ene un cl i ent e defi ni do: una pe r s ona o gr upo que reci -
be el r es ul t ado (por ej empl o, una i dea, un i nf or me, un di seo, un pr oduct o) . Adems ,
l os pr oces os de negoci os t r a s pa s a n l as f r ont er as de la or gani zaci n. Est o r equi er e
que di f er ent es gr upos de or ga ni za ci ones par t i ci pen en l as " t ar eas l gi cament e rel a-
ci onadas " que def i nen el pr oceso.
En el cap t ul o 6 s e i ndi c que t odo s i s t ema es en real i dad una j er ar qu a de sub-
s i s t emas . Un negoci o n o es la excepci n. Cada s i s t ema de negoci o ( t ambi n l l ama-
do una f unci n negoci o) es t c ompue s t o de u n o o m s pr oces os de negoci o, y a ca da
pr oces o de negoci o lo def i ne un c onj unt o de s ubpr oces os .
La RPN s e pue de apl i car en cual qui er ni vel de la j er ar qu a, per o c onf or me s e
ampl a su mbi t o (es decir, conf or me uno s e mueve haci a arriba en la jerarqua) los ries-
gos a s oci a dos con el l o cr ecen s us t anci al ment e. Por es t a r azn, la mayor a de l os
e s f ue r z os de la RPN s e enf oca e n pr oces os i ndi vi dual es o s ubpr oces os .
"Tan pr ont o se nos pr es ent o a l go viejo en una cosa nueva , nos t r anqui l i zamos . "
F. W. Ni e t z s c h e
31.1.2 Un model o de RPN
Como la mayor a de l as act i vi dades de i ngeni er a, la r ei ngeni er a de pr oc e s os de
negoci o es i t erat i va. Las me t a s del negoci o y l os pr oces os con que se l ogr an s e
deben a da pt a r a un e nt or no de negoci os ca mbi a nt e. Por est a r a zn no exi st e pri nci -
pi o ni fin par a la RPN: s e t r at a de un pr oces o evol ut i vo. En la figura 31.1 s e mue s t r a
un model o de r ei ngeni er a de pr oc e s os de negoci o. El model o def i ne s ei s act i vi da-
des.
De f i ni c i n de l ne g o c i o . Las me t a s del negoci o s e i dent i f i can denl e el cont ext o
de cuat r o cont r ol ador es cl ave: r educci n de cost o, r educci n de t i empos, mej or a de
la cal i dad y desar r ol l o y f or t al eci mi ent o del per s onal . Es posi bl e defi ni r l as me t a s al
nivel del negoci o o r es pect o de un c ompone nt e espec f i co del negoci o.
I de nt i f i c ac i n del p r o c e s o . Se i dent i fi can l os pr oces os cr uci al es par a l ograr l as
me t a s pr eci s adas en la def i ni ci n del negoci o. Luego podr a cl asi f i car se de a c ue r do
TM
PDF Editor
CAPI TULO 3 1 REINGENIERA 905
con su importancia, necesi dad de cambi o o en cualquier otra forma que sea ade-
cuada para la actividad de reingeniera.
Eval uaci n del pr oc e s o. El proceso exi st ent e se anal i za y mi de exhaust i va-
ment e. Se identifican las t areas del proceso; se anot an los cost os y el t i empo que con-
sumen las t areas del proceso; y se aislan los probl emas de calidad y desempeo.
Es peci f i caci n y di s eo del pr oc e s o. Con base en la ret roal i ment aci n obte-
nida durant e l as pri meras tres actividades de la RPN, se preparan casos de uso (cap-
tulo 7) para cada pr oceso que ser redi seado. En del cont ext o de la RPN los casos
de uso identifican un escenari o que ent rega cierto resul tado a un cliente. Con el cas de
uso como la especificacin del pr oceso se di sea un nuevo conj unt o de t areas para
el proceso.
El aboraci n de prot ot i pos. Un proceso de negoci o redi seado debe conver-
tirse en prototipo ant es de que sea i nt egrado por compl et o en el negoci o. Esta acti-
vidad "prueba" el proceso de modo que puedan llevarse a cabo refi nami ent os.
Ref i nami ent o y parti cul ari zaci n. Con base en la retroal imentacin del pro-
totipo, el proceso de negoci o se refina y luego se particulariza dent ro de un si st ema
de negoci o.
En ocasi ones, est as actividades de RPN se utilizan j unt o con las her r ami ent as de
anlisis de flujo de trabajo. La finalidad de est as herrami ent as es el aborar un mode-
lo de flujo de t rabaj o prctico, esfuerzo encami nado a anal i zar mej or los procesos
existentes. Adems, para i mpl ement ar las pri meras cuat ro actividades descri t as en
el model o de proceso se pueden aplicar las t cni cas de model ado usual ment e aso-
ci adas con las actividades de ingeniera de procesos de negocio (captulo 6).
Modelo de RPN. Definicin del
TM
PDF Editor
Reingeniera de procesos de negoci o (RPN)
Objeti vo: El objetivo de las herramientas de e-Work, desarrollado por Mefastorm
la RPN es apoyar el anlisis y la evaluacin de
los procesos de negocio existentes y la especificacin y el
diseo de unos nuevos.
Mecni ca: La mecnica de las herramientas vara. En
general, las herramientas de la RPN permiten que un
analista de negocios modele los procesos de negocio
existentes en un esfuerzo destinado a evaluar las
ineficiencias del flujo de trabajo o problemas funcionales.
Una vez que se identifican los problemas existentes las
herramientas permiten que los analistas elaboren
prototipos o simulen procesos de negocio revisados.
Extend, desarrollada por ImagineThat, Inc.
(vAvw.imaginethatinc.com), es una herramienta de
simulacin para el modelado de procesos existentes y
la exploracin de unos nuevos. Extend proporciona
una extensa capacidad "si... entonces" que permite
que un analista de negocios explore diferentes escenarios
, de proceso,
(www.metastorm.com), apoya la gestin de procesos
de negocios en procesos manuales y automatizados.
IceTools, desarrolladas por Blue Ice (www.blueice.com), es
una coleccin de plantillas de RPN para Microsoft
Office y Microsoft Project.
SpeeDev, desarrollada por NimbleStar Group
(www.nimblestar.com), es una de muchas herramientas
que permiten que una organizacin modele flujos de
trabajo de procesos (en este caso, flujo de trabajo de
TI).
Workflow tools, desarrolladas por MetaSoftware
(www.metasoftware.com), incorpora un conjunto de
herramientas para modelado, simulacin y
calendarizacin del flujo de trabajo.
Una lista til de vnculos a herramientas de RPN se puede
encontrar en http://www.donald-
firesmith.com/Components/Producers/Tools/BusinessProce
ssReengineeringTools.html.
El e s c e n a r i o e s l a n c o m n : u n a a pl i c a c i n h a c ubi e r t o l a s n e c e s i d a d e s d e n e g o c i o s
de u n a c o mp a a d u r a n t e 10 o 15 a o s . Du r a n t e e s e l a ps o s e h a cor r egi do, a d a p t a -
d o y me j o r a d o mu c h a s ve c e s . El p e r s o n a l e n f r e n t e s t e t r a b a j o c o n l as me j o r e s
i nt e nc i one s , p e r o l a s b u e n a s pr c t i c a s d e i nge ni e r a del s o f t wa r e s i e mp r e f u e r o n
s o s l a y a d a s ( debi do a la pr e s i n de o t r o s a s u n t o s i mpor t a nt e s ) . Ahor a l a a pl i c a c i n
e s i ne s t a bl e . Toda v a f u n c i o n a pe r o, c a d a ve z q u e s e i nt e nt a u n c a mb i o , o c u r r e n
e f e c t o s c ol a t e r a l e s , i n e s p e r a d o s y s er i os . Y la a pl i c a c i n t oda v a t i e ne q u e evol uci o-
na r . Qu h a c e r ?
El s o f t wa r e al c ua l n o s e l e p u e d e d a r ma n t e n i mi e n t o n o e s u n p r o b l e ma n u e v o .
De h e c h o , la i mpor t a nc i a c a d a ve z ma y o r q u e s e le c o n c e d e a la r e i nge ni e r a del s of t -
wa r e la h a n i mp u l s a d o l os p r o b l e ma s e n el ma n t e n i mi e n t o del s o f t wa r e q u e h a n i do
c r e c i e nd o d u r a n t e m s d e 40 a o s .
2 Las herramientas expuestas el autor no las respalda; slo representan una muestra de las herra-
mientas incluidas en esta categora. En la mayora de los casos, los nombres de las herramientas
son marcas registradas por sus respectivos desarrolladores.
TM
PDF Editor
CAP TULO 31 REINGENIERIA 907
31.2.1 Mantenimiento del software
Dur ant e l as t r es d c a da s pa s a d a s el ma nt e ni mi e nt o del s of t wa r e s e car act er i z
[CAN72] c o mo un "i ceberg". Se e s pe r a ba que lo i nme di a t a me nt e visibl e f ues e t odo
lo que hab a, pe r o s e sab a que ba j o la super f i ci e s e e nc ont r a ba una e nor me ma s a
de pr obl e ma s y c os t os pot enci al es. A pr i nci pi os del deceni o de 1970, el ma nt eni -
mi ent o del i ceber g er a s uf i ci ent ement e gr a nde c o mo par a hundi r un por t aavi ones .
En la act ual i dad, f ci l ment e podr a hundi r a t oda la ma r i na !
El ma nt e ni mi e nt o del s of t wa r e exi st ent e expl i ca casi el 60 por ci ent o del es f uer -
zo que e mpl e a una or gani zaci n de desar r ol l o, y el por cent aj e cont i na el evndos e
c onf or me s e pr oduce m s s of t wa r e (HAN93], Los l ect or es con e s c a s os conoci mi en-
t os s obr e el t ema podr an pr egunt ar s e por qu se r equi er e t a nt o ma nt e ni mi e nt o y
por qu s e dedi ca t a nt o es f uer zo. Os bor ne y Chi kofsky [C>SB90] of r ecen una r es-
pues t a parci al :
Gran parte del software del que dependemos en la actualidad tiene en promedio de 10 a
15 aos de antigedad. Aun cuando dichos programas se crearon empleando las mejores
tcnicas de diseo y codificacin conocidas en la poca [y la mayora no lo eran| , se crea-
ron cuando el tamao de los programas y el espacio de almacenamiento eran las princi-
pales preocupaciones. Entonces emigraron hacia nuevas plataformas, se ajustaron para
adecuarlos a los cambios en las mquinas y a la tecnologa de los sistemas operativos y
aumentaron para satisfacer las necesidades de nuevos usuarios; todo se hizo sin consi-
derar lo suficiente la arquitectura global. El resultado es estructuras mal diseadas, codi-
ficacin deficiente, lgica inadecuada y escasa documentacin de los sistemas de
software por los que ahora se nos llama para mantenerlos en operacin...
Ot r a r azn r espect o del pr obl ema del ma nt e ni mi e nt o del s of t war e es la movi l i dad
del per sonal . Es pr obabl e que el equi po (o per sona) de s of t wa r e que r eal i z el t ra-
baj o ori gi nal ya n o est . Peor an, l a s ge ne r a c i one s s ubs e c ue nt e s de per sonal han
modi f i cado el s i s t ema y lo h a n da a do. En la act ual i dad, tai vez no haya na di e que
t enga al gn conoci mi ent o di r ect o del s i s t ema her edado.
Como s e i ndi c en el cap t ul o 27, la nat ur al eza ubi cua del c a mbi o s ubyace en
t odo el t r abaj o de s of t wa r e. El ca mbi o es i nevi t abl e c ua ndo s e cons t r uyen s i s t ema s
ba s a d os e n comput a dor a ; e n cons ecuenci a, s e deben desar r ol l ar me c a ni s mos par a
eval uar , cont r ol ar y ef ect uar modi f i caci ones.
"ID facil idad de ma nt eni mi ent o de los pr ogr a mos y la comprensi bi l i dad d e los pr ogr a ma s son concept os par al el os:
mi ent r a s m s difcil sea compr ender un pr ogr ama, m s difcil s er su ma nt eni mi ent o. "
G erai d Berns
Des pus d e l eer l os pr r a f os a nt er i or es un l ect or podr a pr ot es t ar : "Pero yo n o
p a s o el 60 por ci ent o de mi t i empo c omponi e nd o er r or es e n l os pr ogr a ma s que de-
sarrol l o". Desde l uego, el ma nt e ni mi e nt o del s of t wa r e e s muc ho m s q u e " compo-
ner er r or es". Es posi bl e defi ni r el ma nt e ni mi e nt o des cr i bi endo cuat r o act i vi dades
[SWA76] que s e r eal i zan de s pu s de que u r pr ogr a ma es l i berado par a su ut i l i zaci n.
TM
PDF Editor
\
CLAVE
El mont e ni mi e nt o del
s of t wa r e incluye cuat r o
act i vi dades: correcci n
de error, adopt aci n,
mej or a y rei ngeni en' o.
Uno excelente fuent e
de informacin ocerco
s o t a r e S puede
encontrar en
w w w .
r eengi neer i ng. net .
El ma nt e ni mi e nt o del s of t war e s e def i ne i dent i f i cando cuat r o act i vi dades di f er ent es:
ma nt e ni mi e nt o correct i vo, ma nt e ni mi e nt o adapt at i vo, mej or a o ma nt e ni mi e nt o de
per f ecci onami ent o y ma nt e ni mi e nt o pr event i vo o r ei ngeni er a. Sl o cer ca del 20 por
ci ent o del t r abaj o de ma nt e ni mi e nt o se empl ea e n " componer errores". El r es t ant e
80 por ci ent o s e dedi ca a a da pt a r l os s i s t ema s exi s t ent es a l os ca mbi os en s u ent or -
n o ext er no, r eal i zar l as mej or a s que sol i ci t an l os us uar i os y r edi s ear una apl i caci n
par a usar l a en lo f ut ur o. Al consi der ar que el ma nt e ni mi e nt o i ncl uye t oda s es t as act i -
vi dades e s r el at i vament e senci l l o obs er var por qu a bs or be t ant o es f uer zo.
31.2.2 Un model o de procesos de reingeniera del software
La r ei ngeni er a r equi er e t i empo, cues t a cant i dades si gni fi cat i vas de di ner o y absor -
be r ecur s os que de ot r o modo s e ocupar an en pr obl ema s i nmedi at os . Por t odas
es t as r a z one s la r ei ngeni er a no s e l ogra en unos c ua nt os me s e s , ni si qui er a e n unos
c ua nt os aos . La r ei ngeni er a de l os s i s t ema s de i nf or maci n es una act i vi dad que
a bs or ber r ecur s os de la t ecnol og a de la i nf or maci n dur a nt e mu c h o s aos . Por
t ant o, t oda or gani zaci n neces i t a una est r at egi a pr agmt i ca r es pect o de la r ei nge-
ni er a del s of t war e.
El mode l o de pr oces o de r ei ngeni er a i ncl uye una est r at egi a oper at i va. El model o
s e t r at ar m s a del a nt e en est a secci n, per o pr i mer o s e pr es ent ar n a l gunos pri n-
ci pi os bsi cos.
La r ei ngeni er a es una act i vi dad de r econs t r ucci n, y la r ei ngeni er a de l os si st e-
ma s de i nf or maci n s e c ompr e nd e mej or si se cons i der a una act i vi dad anl oga: la
r econst r ucci n de una cas a. Cons i dr es e la si gui ent e si t uaci n.
El l ect or compr a una c a s a en ot r o es t ado. En r eal i dad nunc a ha vi st o la pr opi e-
dad, per o la adqui r i e n un pr eci o s or pr e nde nt e me nt e baj o, con la adver t enci a de
que tal vez t enga que r econst r ui r se por compl et o. Cmo s e pr oceder a?
Ant es de que s e pueda iniciar la r econst r ucci n ser a r a zona bl e i ns pecci onar
la cas a. Det er mi nar si es neces ar i o r econst r ui r l a r equi er e que el l ect or (o un
i ns pect or pr of esi onal ) el abor e una lista de cri t eri os de mo d o que la i nspecci n
resul t e si st emt i ca.
Ant es de tirar y reconst rui r t oda la casa s e debe t ener la cer t eza que la est r uc-
t ura es dbil. Si la casa es est r uct ur al ment e sl i da tal vez sea posi bl e "r emode-
larla" sin reconst rui rl a (a un cost o muc ho m s baj o y e n mu c h o me n o s t i empo).
Ant es de i ni ci ar la r econst r ucci n s e de be t ener la cer t eza de que s e ent i ende
c mo se cons t r uy la original . Eche un vi st azo det r s de l as par edes . Ent i enda
el al ambr ado, la pl omer a y l os c ompone nt e s est r uct ur al es. Incl uso si s e t i ran
t odos a la bas ur a, la compr ens i n que s e adqui er a ser til c ua ndo comi ence
la const r ucci n.
Si s e c omi e nz a a r econst r ui r sl o se ut i l i zar n l os mat er i al es m s mod e r nos y
de l arga dur aci n. Est o pue de cos t ar un poc o m s ahor a, per o ayudar a
evi t ar un ma nt e ni mi e nt o c os t os o y t a r da do m s adel ant e.
TM
PDF Editor
CAPI TULO 31 REINGENIERIA
909
Si s e deci de r econst r ui r es pr eci so di sci pl i nar se en c ua nt o a ello. Ut i l cense
pr ct i cas que r edunda r n en al t a cal i dad, hoy y ma a na .
Aunque es t os pri nci pi os s e e nf oc a n en la r econst r ucci n de una cas a, t ambi n s e
apl i can i gual ment e bi en a la r ei ngeni er a de s i s t ema s y apl i caci ones ba s a d a s e n
comput a dor a s .
La i mpl ement aci n de e s t os pri nci pi os r equi er e apl i car un model o de pr oces o de
r ei ngeni er a del s of t wa r e q u e def i ne sei s act i vi dades, c o mo s e mue s t r a en la figura
31. 2. En a l gunos c a s os di chas act i vi dades ocur r en e n una s ecuenci a l ineal , pe r o st e
no s i empr e e s el caso. Por ej empl o, tal vez la i ngeni er a i nver sa ( compr ender el f un-
c i ona mi e nt o i nt er no de un pr ogr ama) t enga que ocur r i r a nt e s de que c omi e nc e la
r eest r uct ur aci n de doc ume nt os .
El pa r a di gma de r ei ngeni er a que s e mue s t r a e n la figura es un mode l o cclico.
Est o si gni fi ca que ca da una de l as act i vi dades pr e s e nt a da s c omo par t e del par adi g-
ma pue de n vol ver a vi si t arse. En al gn ci cl o par t i cul ar el pr oces o qui z t er mi ne de s -
pu s de cual qui er a de di chas act i vi dades.
Anl i s i s de i nve nt ar i os . Las or gani zaci ones de s of t wa r e deber an t ener un i nven-
t ari o de t odas s u s apl i caci ones. El i nvent ar i o tal vez n o s ea m s que un model o en
una hoj a de cl cul o que c ont e nga i nf or maci n que pr opor ci one una descr i pci n
det al l ada (por ej empl o, t a ma o, edad, i mpor t anci a par a el negoci o) de l as apl i caci o-
ne s act i vas. Al or de na r est a i nf or maci n de a c ue r do con la i mpor t anci a par a el
negoci o, ant i gedad, faci l i dad act ual de ma nt e ni mi e nt o y ot r os cri t eri os l ocal ment e
i mpor t ant es a pa r e c e n l os candi dat os par a r ei ngeni er a. Ent onces s e pue de n asi g-
na r los r ecur sos a l as apl i caci ones ca ndi da t a s par a el t r abaj o de r ei ngeni er a.
Modelo de
proceso de l a
reingeniera del
software.
Reestructuracin
de documentos
TM
PDF Editor
9 1 0
^ ONS EJ O^ ^
Si el tiempo y los
temos escasean,
puede considerar la
aplicaci n del principio
de Poreto al software
q ue ser sometido a
ingeniera. Apliq ue el
proceso de reinge-
niera al 2 0 por ciento
del software q ue
explica el 8 0 por
ciento de los
problemas.
^ÔNSEJO^^
Cree solamente tanta
documentaci n como
necesite para
entender el software,
ni una pgina m s.
Es i mport ant e seal ar que el inventario deber visitarse con regularidad. El est ado
de las apl i caci ones (por ejempl o, importancia respect o del negocio) puede cambi ar
en funcin del t i empo y, como resul tado, cambi arn las prioridades para la reinge-
niera.
Reest ruct uraci n de doc ume nt os . La document aci n dbil es la marca de mu-
chos si st emas heredados. Pero qu se hace acerca de ello? Cules son las opcio-
nes?
1 . Crear documentaci n consume muchsimo tiempo. Si el si st ema funci ona vivir
con lo que se t enga. En al gunos casos st e es el enf oque correcto. No es posi-
ble recrear document aci n para ci ent os de pr ogr amas de comput ador a. Si un
programa es rel at i vament e est t i co est l l egando al final de su vida til, por lo
que es i mprobabl e que experi ment e un cambi o significativo, djelo ser!
2. La documentaci n debe actualizarse, pero se tienen recursos limitados. Se utili-
zar un enfoque de "document ar cuando se toque". Tal vez sea i nnecesari o
volver a document ar por compl et o la aplicacin. En cambi o, se document an
compl et ament e aquel l as porci ones del si st ema que en la actual idad experi-
ment an cambi os. Con el t i empo evol uci onar una coleccin de document a-
cin til y rel evant e.
3. El sistema es crucial para el negocio y debe volver a documentarse por completo.
Incluso en est e caso un enfoque inteligente es recortar la document aci n a un
m ni mo esencial .
Cada una de est as opci ones es viable. Una organi zaci n de sof t war e debe elegir la
m s a p r o p i a d a p a r a c a d a c a s o .
Ingeni er a i nversa. El t rmi no ingeniera inversa tiene sus or genes en el mundo
del hardware. Una compa a desensambl a un product o de har dwar e de un compe-
tidor con la finalidad de compr ender sus "secretos" de di seo y fabricacin. Tales
secret os podran compr ender se fci l ment e si se obt uvi esen las especi fi caci ones de
di seo y fabricacin del compet i dor. Pero di chos document os est n pat ent ados y no
est n disponibles para la compa a que realiza la ingeniera inversa. En esenci a, la
ingeniera inversa exitosa obt i ene una o ms especi fi caci ones de di seo y fabrica-
cin para un product o cuando se exami nan espec menes real es del producto.
La ingeniera inversa para el sof t war e es bast ant e similar. Sin embargo, en ambos
casos el programa obj et o de la ingeniera inversa no es el de un compet i dor, si no el
t rabaj o de la propia compa a (con frecuenci a el aborado muchos aos atrs). Los
"secretos" que se compr endan sern oscuros, pues nunca se desarrol l una especi-
ficacin. Por lo t ant o, la ingeniera inversa del sof t war e es el proceso de anal i zar un
programa con la finalidad de crear una represent aci n del pr ogr ama en un mayor
grado de abst racci n que el cdigo fuent e. La ingeniera inversa es un proceso de
recuperaci n de diseo. Las her r ami ent as de la ingeniera inversa obt i enen infor-
TM
PDF Editor
CAPTULO 31 REINGENIER1A 911
pot a lo
obtener en
www. t omp. l ancs.
a c . u k / p r o j e t t s /
Renai s s nnceWeb/ .
macin del di seo de datos, arqui t ect ni co y de procedi mi ent os a partir de un pr o-
grama existente.
Reest ruct uraci n de cdi go. El tipo m s comn de reingeniera (en realidad, en
est e caso el empl eo del t rmi no reingeniera es cuestionabl e) es la reest ruct uraci n
de cdigo.-' Al gunos si st emas her edados tienen una arqui t ect ura de pr ogr ama rela-
t i vament e slida, per o los mdul os individuales se codificaron en una forma que difi-
culta comprenderl os, probarl os y mant enerl os. En tal es casos se puede reest ruct urar
el cdi go dent r o de los mdul os sospechosos.
Llevar a cabo est a actividad requiere anal i zar el cdi go fuent e empl eando una
herrami ent a de reestructuracin. Se indican l as viol aciones de las est ruct uras de
programaci n est ruct urada y ent onces el cdi go se reest ruct ura (esto se puede hacer
aut omt i cament e). El cdigo reest ruct urado resul t ant e se revisa y prueba para
garant i zar que no se han introducido anormal i dades. La document aci n del cdi go
interno se act ual i za.
Reest ruct uraci n de dat os . Un pr ogr ama con una arqui t ect ura de dat os dbil
ser difcil de adapt ar y mej orar. De hecho, en muchas apl icaciones la arqui t ect ura
de dat os est ms rel acionada con la viabilidad a largo pl azo de un pr ogr ama que el
cdi go fuent e.
A diferencia de la reest ruct uraci n de cdigo, que ocurre en un grado relativa-
ment e baj o de abst racci n, la reest ruct uraci n de dat os es una actividad de reinge-
niera a gran escal a. En la mayora de los casos, la reest ruct uraci n de dat os
comi enza con una actividad de ingeniera inversa. La arquitectura de dat os actual se
anal i za con minuciosidad y se defi nen los model os de dat os necesari os (captulo 9).
Se identifican los obj et os de dat os y los atributos, y despus se revisa la calidad de
las est ruct uras de dat os existentes.
Cuando la est ruct ura de dat os es dbil (por ejempl o, act ual ment e se i mpl ement an
archi vos pl anos, cuando un enfoque relacional simplificara enor mement e el proce-
samiento), los dat os se somet en a reingeniera.
Puest o que la arqui t ect ura de dat os tiene una fuert e influencia sobre la arquitec-
tura del pr ogr ama y los al goritmos que lo puebl an, los cambi os a los dat os invaria-
bl ement e resul t arn en cambi os arqui t ect ni cos o al nivel de cdigo.
Ingeni er a di rect a. En un mundo ideal, las apl i caci ones se reconstruiran empl e-
ando un "mot or de reingeniera" aut omat i zado. El pr ogr ama ant i guo sera i nsert ado
en el motor, anal i zado, reest ruct urado y l uego r egener ado en una forma que exhi-
biese los mej or es aspect os de la calidad del soft ware. A corto pl azo es improbabl e
que tal "mot or" aparezca, per o l as empr es as han introducido her r ami ent as que
mej oran un limitado subconj unt o de di chas capaci dades que aborden domi ni os de
aplicacin especficos (por ejempl o, las apl i caci ones que se i mpl ement an medi ant e
3 La reestructuracin de cdigo tiene algunos de ios elementos de "refactorizacin", un concepto de
rediseo introducido en el capitulo 4 y tratado en otras partes de este libro.
TM
PDF Editor
912 PARTE CI NCO TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
un si st ema de base de dat os especfico). Ms i mport ant e, di chas her r ami ent as de
reingeniera se est n vol vi endo cada vez m s sofi st i cadas.
La i ngeni er a directa, t ambi n l l amada renovaci n o r ecl amaci n [CHI90], no sl o
recupera la i nformaci n de di seo a partir del sof t war e exi st ent e, t ambi n utiliza
est a i nf or maci n par a al t erar o reconst i t ui r el si st ema exi st ent e con la finalidad de
mej or ar su cal i dad global. En la mayor a de los cas os el sof t war e s omet i do a rei nge-
niera vuelve a i mpl ement ar la funci n del si st ema exi st ent e y t ambi n aade nuevas
f unci ones o mej or a el des empeo global.
La ingeniera inversa invoca una i magen de "r anur a mgi ca". En la r anur a se i nsert a
una lista f uent e sin document ar y di seado casual ment e, y del ot ro ext r emo sal e una
descri pci n (y t oda la document aci n) compl et a del di seo par a el pr ogr ama de
comput ador a. Desdi chadament e, la r anur a mgi ca no existe. La i ngeni er a i nversa
puede obt ener i nformaci n de di seo a partir del cdi go fuent e, per o el gr ado de abs-
t racci n, la compl et ud de la document aci n, el gr ado en el que las her r ami ent as y
un anal i st a huma no t r abaj an en conj unt o, y la di recci onal i dad del pr oceso son enor -
mement e vari abl es.
El grado de abstracci n de un pr oceso de ingeniera i nversa y l as her r ami ent as uti-
l i zadas para efect uarl o se refieren a la sofisticacin de la i nf or maci n del di seo que
e s posi bl e obt ener del cdi go fuent e. Ideal ment e, el gr ado de abst racci n debe ser
tan al t o como sea posibl e. Esto es, el pr oceso de ingeniera i nversa debe ser capaz
de deri var r epr esent aci ones de di seo de pr ocedi mi ent o (un gr ado de abst racci n
bajo), i nformaci n de est ruct ura de pr ogr ama y dat os (un gr ado de abst racci n un
poco m s el evado), model os de obj et o, model os de flujo de dat os o cont rol (un grado
de abst racci n rel at i vament e alto) y cl ases UML, di agr amas de es t ado y despl i egue
(un gr ado al t o de abst racci n). Conf or me el gr ado de abst racci n aument a, el i nge-
ni er o de sof t war e obt i ene i nformaci n que le permi t i r compr ender con m s facili-
dad el pr ogr ama.
La completud de un pr oces o de i ngeni er a inversa se refi ere al gr ado de det al l e que
se of r ece en un gr ado de abst racci n. En la mayor a de l os casos, la i nt egri dad dis-
mi nuye conf or me el gr ado de abst racci n aument a. Por ej empl o, dada una lista del
cdi go fuent e, es r el at i vament e sencil l o desarrol l ar una r epr esent aci n compl et a
del di seo del pr ocedi mi ent o. Tambi n s e pueden derivar r epr esent aci ones senci l l as
de di seo, per o e s mucho m s difcil desarrol l ar un conj unt o compl et o de di agr amas
o model os UML.
La compl et ud mej or a en proporci n directa con la cant i dad de anl i si s que efec-
ta qui en real i za la i ngeni er a inversa. La interactividad se refiere al gr ado en el que
el ser h uma no est "i nt egrado" con las her r ami ent as aut omat i zadas par a crear un
pr oceso de ingeniera inversa efectivo. En la mayor a de l os casos, conf or me a ume n-
ta el gr ado de abst racci n la i nt eract i vi dad debe aument ar o la compl et ud sufri r.
TM
PDF Editor
CAP TULO 31 REINGENIERA 913
Proceso de
i ngeni er a
i nversa.
Cdigo Fuente sucio
Cdigo uente limpio
1
Especificacin final
I
CLAVE
Se d e b e n a b o r d o r t r e s
t e ma s d e lo i ngeni er a
i nve r s a : g r a d o d e
a bs t r a c c i n, i nt e gr i d a d
y di r ecci ona l i da d.
Si la direccionalidad del proceso de ingeniera inversa es unidireccional, t oj a la
informacin extrada del cdigo fuente se ofrece al ingeniero de software que erton-
ces puede usarla durante cualquier actividad de mantenimiento. Si la direccionalidad
es bidireccional, la informacin alimenta a una herramienta de reingeniera que
intenta reestructurar o regenerar el programa antiguo.
En la figura 31.3 se representa el proceso de ingeniera inversa. Antes de que
comiencen las actividades de ingeniera inversa, el cdigo fuente no estructurado
("sucio") se reestructura (seccin 31.4.1) de modo que slo contenga las estructuras
de programacin estructurada.4 Esto facilita la lectura del cdigo fuente y ofrece la
base para las subsecuentes actividades de ingeniera inversa.
El ncleo de la ingeniera inversa es una actividad llamada extracci n de abstrac-
ciones. El ingeniero debe evaluar el programa antiguo y, a partir del cdigo fuente
(con frecuencia sin documentar), desarrollar una especificacin significativa del pro-
cesamiento que realiza, la interfaz del usuario que se aplica y las estructuras de
datos del programa o las bases de datos que se utilizan.
31.3.1 Ingeni er a i nversa para comprender los dat os
La ingeniera inversa de datos ocurre en diferentes grados de abstraccin y con fre-
cuencia es la primera tarea de reingeniera. Al nivel del programa, las estructuras de
datos internos del programa usualmente deben someterse a reingenieria inversa
4 El cdigo se reestructura empleando un mcxor de reestructuracin, una herramienta que reestruc-
tura cdigo fuente.
TM
PDF Editor
Recursos tiles paro la
de pr ogr amo" se
pueden enctmtrof e n
wwwscl.iit.nrc.
ca/projetls/dr/
dr.htmi
^ CONSEJ O^
Los compromisos
aparentemente insig-
nificantes en los
estructuras de datos
pueden conducir a
problemas potencial-
mente catastr ficos en
a os futuros.
Considere como
ejemplo el problema
m.
como parte de un esfuerzo global de reingeniera. En el nivel del sistema las estruc-
turas globales de datos (por ejemplo, archivos, bases de datos) con frecuencia se
someten a reingeniera para ajusfarlos con los nuevos paradigmas de gestin de
bases de datos (por ejemplo, el movimiento desde los archivos planos hacia los sis-
temas de bases de datos relacinales u orientados a objetos). La ingeniera inversa
de las actuales estructuras globales de datos establece el escenario para la intro
duccin de una nueva base de datos que abarque todo el sistema.
Estructuras de datos internos. Las tcnicas de ingeniera inversa para datos
internos del programa se enfoca en la definicin de clases de objetos. Esto se logra
al examinar el cdigo del programa con el propsito de agrupar las variables de pro-
grama relacionadas. En muchos casos, la organizacin de los datos dentro del cdi-
go identifica tipos abstractos de datos. Por ejemplo, estructuras de registro, archivos,
listas y cyrnrjgstructuras de datos con frecuencia ofrecen una indicacin inicial de las
clases. *^7^
Estructura de bases de datos. Sin importar su organizacin lgica y estructura
fsica, una base de datos permite la definicin de objetos de datos y apoya algn
mtodo para establecer relaciones entre los objetos. En consecuencia, la reingenie-
ra de un esquema de base de datos en otro requiere comprender los objetos exis-
tentes y sus relaciones.
Los siguientes pasos [PRE94] se pueden utilizar para definir el modelo de datos
existente como un precursor para la reingeniera de un nuevo modelo de base de
datos: 1) construccin de un modelo inicial de objeto, 2) determinacin de los can-
didatos clave, 3) refinar las clases tentativas, 4) definicin de generalizaciones y 5)
descubrimiento de asociaciones (empleo de tcnicas anlogas al enfoque CRC). Una
vez que se conoce la informacin definida en los pasos precedentes, se aplica una
serie de transformaciones [PRE94] para correlacionar la estructura antigua de la
base de datos con una nueva estructura de base de datos.
31. 3. 2 Ingeniera i nversa para comprender el procesami ent o
La ingeniera inversa para comprender el procesamiento comienza con un intento
por comprender y luego extraer abstracciones de procedimientos representadas por
el cdigo fuente. Para comprender las abstracciones de procedimientos el cdigo se
analiza en grados variables de abstraccin: sistema, programa, componentes, patrn
y planteamiento.
La funcionalidad global de todo el sistema de aplicacin se debe comprender
antes de que ocurra un trabajo de ingeniera inversa ms detallado. Esto establece
un contexto para un mayor anlisis y ofrece poca visin de los conflictos de inter-
operabilidad entre las aplicaciones dentro del sistema. Cada uno de los programas
que conforman el sistema de la aplicacin representa una abstraccin funcional en
un mayor grado de detalle. Se crea un diagrama de bloques que representa la inte-
raccin entre dichas abstracciones funcionales. Cada componente realiza alguna
TM
PDF Editor
CAP TULO 3 1 REINGENIERA
915
s ubf unci n y r epr es ent a una abst r acci n de pr ocedi mi ent o defi ni da. Par a ca da c om-
pone nt e s e desar r ol l a una nar r at i va de pr oces ami ent o. En a l guna s s i t uaci ones ya
exi st en es peci f i caci ones del s i s t ema, el pr ogr a ma y l os c ompone nt e s . Cua ndo st e
es el caso, l as especi f i caci ones s e revi san par a veri fi car si concuer da n con el cdi go
exi st ent e. 5
"Existe u n o pasi n por la compr ensi n, as como exi st e uno por la msi ca. Dicho pasi n es m s comn e n los ni os,
per o ms t a r de se pi er de en l a ma yor a de l as per s onos . "
fllbert Ei nstei n
Las c os a s s e compl i can m s c ua nd o s e cons i der a el cdi go dent r o de un c ompo-
nent e. El i ngeni er o bus ca l as s ecci ones de cdi go q u e r epr es ent en pa t r ones de pr o-
cedi mi ent o genr i cos. Casi en ca da c ompone nt e una secci n del cdi go pr epar a l os
da t os pa r a el pr oces a mi ent o ( dent r o del mdul o) , una secci n di f er ent e de cdi go
real i za el pr oc e s a mi e nt o y ot r a secci n del cdi go pr epar a l os r es ul t ados del pr oce-
s a mi e nt o pa r a expor t ar l os des de el c ompone nt e . Dent r o de ca da una de es t as s ec-
ci ones s e pue d e n encont r a r pe que os pat r ones ; por ej empl o, la val i daci n de l os
da t os y la veri fi caci n de e nl a c e s con f r ecuenci a ocur r e dent r o de la secci n de cdi -
go que pr epar a l os da t os par a el pr oces ami ent o.
En s i s t ema s gr a nde s la i ngeni er a i nversa, por lo gener al , se l ogra ut i l i zando un
e nf oque s e mi a ut oma t i z a do. Las he r r a mi e nt a s a ut oma t i z a da s s e ut i l i zan par a ayudar
al i ngeni er o de s of t wa r e a c ompr e nde r la s emnt i ca del cdi go exi st ent e. Ent onces
la sal i da de est e pr oces o pas a a la r eest r uct ur aci n y a l as he r r a mi e nt a s de i ngeni e-
ra a va nz a da par a compl et ar el pr oces o de r ei ngeni er a.
31.3.3 Ingeniera inversa de interfaces de usuario
Las IGU sof i st i cadas a hor a s on i ndi s pens abl es en pr oduct os ba s a dos en c omput a do-
ra y en s i s t ema s de t odo t i po. En cons ecuenci a, desar r ol l ar de nuevo l as i nt er f aces
de us uar i o s e h a vuel t o u n o de los t i pos m s c o mu n e s de act i vi dad de r ei ngeni er a.
Per o a nt e s de que una i nt er f az de us uar i o se pueda r econst r ui r deber r eal i zar se una
act i vi dad de i ngeni er a i nversa.
Ent ender por compl et o una i nt er f az de us uar i o exi st ent e r equi er e especi f i car la
est r uct ur a y el c ompor t a mi e nt o de la i nt erfaz. Merl o y s u s col egas (MER931 sugi er en
t r es pr egunt a s bs i cas que s e d e be n r es ponder c onf or me c omi e nz a la i ngeni er a
i nver sa de la IGU:
Cul es s on l as a cci ones bs i cas (por ej empl o, pr es i ones de t ecl a o cl i cs de
r at n) que debe pr oces ar la i nt er f az?
5 Con frecuencia, las especificaciones escritas en las primeras etapas en la historia de vida de un pro-
grama nunca se actualizan. Conforme los cambios se realizan, el cdigo ya no concuerda ms con
las especificaciones.
TM
PDF Editor
916 P ART E C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
Cmo
e nt e nde r l os
f unci ones de una
i nt erf az de us ua-
rio e x i s t e n t e ?
Cul es la descr i pci n c ompa c t a de l as r es pues t as de c ompor t a mi e nt o del
s i s t ema a e s t a s acci ones ?
Qu s e ent i ende por " r eempl azo" o, m s exa ct a ment e, qu concept o de equi -
val enci a de i nt er f aces es r el evant e en est e cas o?
La not aci n de mode l a do de c ompor t a mi e nt o (cap t ul o 8) pue de of r ecer un medi o
par a desar r ol l ar r es pues t a s a l as pr i mer as dos pr egunt as . Gr an par t e de la i nf or ma-
cin necesar i a par a cr ear un model o de c ompor t a mi e nt o s e pue de obt ener obser -
vando la mani f est aci n ext er na de la i nt erfaz exi st ent e. Per o la i nf or maci n adi ci onal
necesar i a par a cr ear el model o de c ompor t a mi e nt o s e debe ext r aer del cdi go.
Es i mpor t ant e s eal ar que una GUI de r e e mpl a z o tal vez no refl ej e e xa c t a me nt e
la i nt erfaz ant i gua (de hecho, qui z sea r adi cal ment e di ferent e). Con f r ecuenci a val e la
pe na desar r ol l ar nueva s met f or a s de i nt er acci n. Por ej empl o, una GUI ant i gua
sol i ci t a que un usuar i o pr opor ci one un fact or de escal a (que var a des de 1 hast a 10)
par a encoger o ampl i ar una i magen gr f i ca. Una GUI s omet i da a r ei ngeni er a pue de
ut i l i zar una bar r a de des l i zami ent o y un r at n par a r eal i zar la mi s ma f unci n.
Ingeniera inversa
Objeti vo: Ayudar a los Ingenieros de software
a comprender la estructura de diseo interna de
los programas complejos.
Mecni ca: En la mayora de los casos, las herramientas
de ingeniera inversa aceptan cdigo fuente como entrada
y producen una diversidad de representaciones de diseo
estructural, procedi mi ent o, dat os y comport ami ent o.
Irnagix 4D, des ar r ol l ada por Imagi x (wvAV.imagix.com),
" a y ud a a los d e s a b o l l a d o r e s d e s of t war e a c ompr e nde r
software C y C++ complejo o heredado" al someter a inge-
niera inversa y documentar el cdigo fuente.
Undersland, desarrollada por Scientific Toolworks, Inc.
(www.scitools.com), analiza gramaticalmente Ada,
Fortran, C, C++ y Java "para realizar ingeniera inver-
sa, documentar automticamente, calcular mtricas de
cdigo y auxiliarlo a comprender, navegar y mantener
el cdigo fuente".
Una extensa lista de herramientas de ingeniera inversa se
puede encontrar em http://scgwiki.iam.unibe.ch:8080/
SCG/ 370.
La r ees t r uct ur aci n de s of t wa r e modi f i ca el cdi go f uent e o l os da t os con la finali-
dad de a decua r l os par a f ut ur os cambi os . En gener al , la r eest r uct ur aci n n o modi fi -
ca la arqui t ect ura global del pr ogr ama. Ti ende a enf ocar se sobr e l os det al l es de di seo
de l os mdul os i ndi vi dual es y en l as es t r uct ur as de da t os l ocal es def i ni dos dent r o de
l os mdul os . Si el t r abaj o de r eest r uct ur aci n s e ext i ende m s all de l as f r ont er as
6 Las herramientas expuestas el autor no las respalda; slo representan una muestra de las herra-
mientas incluidas en esta categora. En la mayora de los casos, los nombres de las herramientas
son marcas registradas por sus respectivos desarrolladores.
TM
PDF Editor
CAP TULO 3 1 RHNGENIERA
917
^ O N S i J O ^
Aunq ue la reestiuctu-
loci n del c digo
puede aliviar inmedia-
tamente los
problemas asociados
con lo depuiaci n o
los cambios
peq ue os, eslonoes
reingeniera. El
beneficio real se logra
s lo cuando se rees-
tructuran los datos y
lo arq uitectura.
del mdul o y abar ca la arqui t ect ura del sof t war e, la reest ruct uraci n se convi ert e en
i ngeni er a a va nza da (seccin 31.5).
La reest ruct uraci n ocurre cuando la arqui t ect ura bsi ca de una apl i caci n e s
slida, aun cuando el interior t cni co necesi t e t rabaj arse. Se inicia cuando gr andes
par t es del sof t war e son f unci onal es y sl o un subconj unt o de los component es y
dat os necesi t an una modi fi caci n ext ensa. 7
31.4.1 Reestructuracin del cdi go
La reest ruct uraci n del cdi go se real i za para gener ar un di seo que pr oduzca la
mi sma funci n que el pr ogr ama original, per o con mayor calidad. En general , las t c-
ni cas de reest ruct uraci n de cdi go (por ej empl o, t cni cas de simpl ificacin lgica
de Warni er [WAR74]) model an la lgica del pr ogr ama ut i l i zando l gebra bool eana y
l uego apl i can una seri e de regl as de t r ansf or maci n que pr oducen lgica reest ruct u-
rada. El obj et i vo es t omar el "t azn de espaguet i " de cdi go y deri var un di seo de
pr ocedi mi ent o que concuer de con la filosofa de la pr ogr amaci n est r uct ur ada (capi-
t ul o 11).
Tambi n s e han pr opuest o ot r as t cni cas de reest ruct uraci n par a utilizarlas con
las her r ami ent as de rei ngeni er a. Un di agr ama de i nt ercambi o de r ecur sos correl a-
ci ona cada mdul o de pr ogr ama y los r ecur sos (tipos de dat os, pr ocedi mi ent os y
variables) que s e i nt er cambi an ent r e el l os y ot r os mdul os. Medi ant e la creaci n de
r epr esent aci ones del flujo de r ecur sos se puede reest ruct urar la arqui t ect ura del pro-
gr ama para l ograr m ni mos acopl ami ent os ent r e mdul os.
31. 4. 2 Reestructuracin de los datos
Ant es de comenza r la reest ruct uraci n de dat os se debe llevar a cabo una actividad
de i ngeni er a inversa denomi nada anlisis del c digo fuente. Pri mero se eval an
t odos l os enunci ados del l enguaj e de pr ogr amaci n que cont engan defi ni ci ones de
dat os, descri pci ones de archi vos, I/ O y descri pci ones de i nt erfaz. La finalidad e s
ext raer el ement os y obj et os de dat os para obt ener i nf or maci n acer ca del flujo de
dat os y compr ender las est r uct ur as de dat os exi st ent es que se han i mpl ement ado.
Esta actividad a veces se denomi na anlisis de datos [RIC89].
Una vez compl et ado el anl i si s de dat os comi enza el redise o de datos. En su
f or ma m s simpl e, un paso de estandarizaci n de registro de dat os clarifica las defi-
ni ci ones de dat os par a l ograr consi st enci a ent r e los nombr es de el ement os de dat os
o f or mat os de registro fsicos dent r o de una est ruct ura de dat os exi st ent e o f or mat o
de archivo. Ot ra f or ma de redi seo, denomi nada racionalizaci n del nombre de los
dat os asegur a que t odas l as convenci ones de nombr ami ent o de los dat os concuer -
dan con el est ndar local y que los ps eudni mos se el i mi nan como flujo de dat os a
t ravs del si st ema.
7 A veces es difcil distinguir entre reestructuracin extensa y volver a desarrollar. Ambos son rein-
geniera.
TM
PDF Editor
9 1 8 P A R T E C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
Cuando la reestructuracin rebasa la estandarizacin y la nacionalizacin se rea-
lizan modificaciones fsicas a las estructuras de datos existentes para lograr que el
diseo de los datos sea ms efectivo. Esto puede significar una traduccin de un for-
mato de archivo a otro o, en algunos casos, la traduccin desde un tipo de base de
datos a otro.
Reestructuracin de software
Objeti vo: El objetivo de las herramientas de
reestructuracin es transformar el antiguo soft-
ware de computadora carente de estructura en lenguajes
de programacin y estructuras de diseo modernos.
Mecni ca: En general, el cdigo fuente se ingresa y trans-
forma en un mejor programa estructurado. En algunos
casos, la transformacin ocurre dentro del mismo lenguaje
de programacin. En otros casos, un lenguaje de programa-
cin antiguo se transforma en un lenguaje ms moderno.
DMS Software Reengineering Toolkit, desarrollada por
Semantic Design (www.semdesigns.com), proporciona
V
*\
una diversidad de capacidades de reestructuracin
para COBOL, C/C++, Java, FORTRAN 90 y VHDL.
FORESYS, desarrollada por Simulog (www.simulog.fr),
analiza y transforma programas escritos en FORTRAN.
Function Encopsulaliort Tool, desarrollada en la Wayne
State University
(www.cs.wayne.edu/~vip/RefactoringTools/), refactori-
za en C++ los antiguos programas en C.
plusFORT, desarrollada por Polyhedron (www.polyhedron.
com), es un conjunto de herramientas de FORTRAN
que tiene capacidades para reestructurar en FORTRAN
moderno o C estndar los programas en FORTRAN
deficientemente diseados.
3 1 . 5 I N G E N I E R A DI RECTA
^ Qu opci o-
* nes e x i s t e n
cuando s e enf ren-
t a un programa
def i ci ent ement e
di seado e i mpl e-
me nt ado?
Un programa con flujo de control el equivalente grfico de un tazn de espagueti, con
"mdulos" que tienen 2 000 enunciados de longitud, con pocas lneas significativas
de comentarios en los 290 000 enunciados fuente y ninguna otra documentacin, se
debe modificar para que se ajuste a los cambiantes requerimientos de los usuarios.
Se tienen las siguientes opciones:
1. Se puede trabajar modificacin tras modificacin, luchando con el diseo im-
plcito y el cdigo fuente para implementar los cambios necesarios.
2. Se puede intentar comprender el extenso funcionamiento interno del pro-
grama con el propsito de realizar modificaciones de manera ms eficiente.
3. Se puede redisear, recodificar y probar aquellas porciones del software que
requieran modificacin mediante la aplicacin de un enfoque de ingeniera
del software en todos los segmentos revisados.
8 Las herramientas expuestas slo representan una muestra de esta categora. En la mayora de los
casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores.
TM
PDF Editor
^ ONS E J O^ -
Lo reingeniera es muy
porecida o lo limpieza
denlol. Puede pensai
en miles de tazones
pata demorada, y la
aplozat muchas
veces. Peto eventual-
mente sus t cticos
dilatorias regresarn
para provocarte dolor.
4. Se puede redisear, recodificar y probar ei pr ogr ama compl et ament e empl eando
her r ami ent as de rei ngeni er a como auxi l i ares par a compr ender el di seo ac-
tual.
No exi st e una opci n individual "correcta". Las ci r cunst anci as pueden dictar la pri-
mer a opci n, i ncl uso si las ot r as son m s deseabl es.
En l ugar de esper ar hast a que se reciba la solicitud de mant eni mi ent o, la organi -
zaci n de desarrol l o o soport e utiliza los r esul t ados del anl isis de i nvent ari os para
sel ecci onar un pr ogr ama que 1) se empl ear dur ant e un nmer o det er mi nado de
aos, 2) act ual ment e se utilice con xito, y 3) es probabl e que exper i ment ar gran-
des modi fi caci ones o mej or as en el fut uro cercano. Ent onces se apl i can las opci ones
2, 3 o 4.
Este enf oque de mantenimiento preventivo lo i nt roduj o Miller [MIL81 ] con el nom-
bre de retrofit* estructurado. Este concept o se defi ne como "la apl i caci n de las met o-
dol og as de hoy a los s i s t emas del ayer par a apoyar los requi si t os del maana".
A pri mera vista, la sugerenci a de que se desarrol l e de nuevo un gran pr ogr ama
cuando ya exi st e una versi n operat i va puede par ecer bast ant e ext r avagant e. Ant es
de emitir un juicio, consi dr ense los punt os si gui ent es:
1. El cost o de ma nt ener una lnea de cdi go f uent e tal vez oscile ent re 20 y 40
veces el cost o de su desarrol l o inicial.
2 . El r edi seo de la arqui t ect ura de sof t war e (est ruct ura de pr ogr ama o dat os)
empl eando concept os moder nos de di seo puede facilitar enor mement e el
mant eni mi ent o futuro.
3. Puest o que ya exi st e un prot ot i po del sof t war e, el desarrol l o de la productivi-
dad debe ser mucho mayor que el pr omedi o.
4. El usuar i o ahor a tiene experi enci a con el sof t war e. En consecuenci a, los nue-
vos requi si t os y la direccin del cambi o pueden af i r mar se con mayor facilidad.
5. Las her r ami ent as aut omat i zadas para rei ngeni er a facilitarn al gunas par t es
del t rabaj o.
6. Ant es de t ermi nar el mant eni mi ent o prevent i vo existir una confi guraci n
compl et a del sof t war e (document os, pr ogr amas y dat os).
Cuando una or gani zaci n de desarrol l o de sof t war e vende sof t war e como pro-
duct o, el mant eni mi ent o prevent i vo se consi dera como "nuevas l i beraci ones" de un
pr ogr ama. Un gran desarrol l ador de sof t war e local (por ej empl o, un gr upo de desa-
rrollo de sof t war e par a si st emas de negoci os dest i nados a una gran compa a con
sumi dora de product os) puede t ener 500-2 000 pr ogr amas de producci n dent r o de
* El trmino retrofit (literalmente retroajustei recibe muchas denominaciones en espaol, entre las
que destacan: remodelado, modemizac: in. retrocambio, reajuste, modificacin retroactiva. Para no
generar confusin con otros conceptos y denomi naci ones similares, pero no relacionados, utilizar
el trmino original, que por lo dems es reconocido dentro del medio. (N.T.)
TM
PDF Editor
^ CONSEJ ^
En algunos casos, lo
migiaci n hacia lo
arq uitectura cliente-
servidor no debe
enfocarse como rein-
geniero, sino como
un nuevo esfuerzo de
desorrollo. la reinge-
niera ingresa ol
cuadro s lo cuando lo
funcionalidad especi-
fica del sistema
antiguo se integrar
en la nueva arq uitec-
su domi ni o de responsabi l i dad. Di chos pr ogr amas pueden cl asi fi carse segn su
i mport anci a y l uego revi sarl os c omo candi dat os par a mant eni mi ent o prevent i vo.
El pr oceso de ingeniera avanzada apl ica los principios, concept os y mt odos de
la i ngeni er a del sof t war e par a r ecr ear una apl icacin exi st ent e. En la mayor a de los
casos, la ingeniera di rect a no si mpl ement e crea el equi val ent e moder no de un pro-
gr ama ant i guo. Ms bien, los nuevos requi si t os de usuar i o y t ecnol og a se i nt egran
en el t r abaj o de rei ngeni er a. El pr ogr ama que se desarrol l a de nuevo ampl a las
capaci dades de la apl i caci n ant eri or.
31.5.1 Ingeniera directa para arquitecturas cl i ente/ servi dor
Durant e las dcadas pas adas mucha s apl i caci ones par a comput ador a cent ral s e han
somet i do a rei ngeni er a para adapt ar l as a ar qui t ect ur as cl i ent e/ ser vi dor (incluso
WebApps). En esenci a, los r ecur sos de cmput o cent r al i zados (que incluyen sof t wa-
re) se distribuyen ent r e mucha s pl at af or mas cliente. Aunque se pueden di sear
vari os ent or nos di st ri bui dos di ferent es, la apl i caci n tpica de comput ador a cent ral
que se s omet e a rei ngeni er a en una arqui t ect ura cl i ent e/ ser vi dor t i ene las si gui en-
t es caract er st i cas:
La funci onal i dad de la apl i caci n migra haci a cada comput ador a cl iente.
En los si t i os cl iente se i mpl ement an nuevas i nt erfases IGU.
Las f unci ones de base de dat os se asi gnan al servidor.
La funci onal i dad especi al i zada (por ej empl o, anl i si s i nt enso de cmput o)
puede per manecer en el sitio servidor.
Tant o en los sitios cl iente como servi dor se deben est abl ecer nuevos requi -
si t os de comuni caci ones, seguri dad, ar chi vado y control .
Es i mport ant e seal ar que la migracin desde la comput ador a central hacia el cmpu-
to cl i ent e/ servi dor requi ere reingeniera t ant o de negoci o como de soft ware. Adems,
se debe est abl ecer una "infraestructura de red de empr esa" [JAY94J.
La reingeniera par a apl i caci ones cl i ent e/ ser vi dor comi enza con un ampl i o an-
lisis del ent or no de negoci os que incluye la comput ador a central exi st ent e. Se pue-
den identificar t res capas de abst racci n. La capa de base de dat os pone los ci mi ent os
de una arqui t ect ura cl i ent e/ ser vi dor y gest i ona las t r ansacci ones y consul t as desde
apl i caci ones cl iente. Aunque di chas t r ansacci ones y consul t as s e deben cont rol ar
dent r o del cont ext o de un conj unt o de regl as de negoci os (definidas medi ant e un
pr oceso de negoci o exi st ent e o s omet i do a reingeniera). Las apl i caci ones cliente
of r ecen la funci onal i dad deseada par a la comuni dad de usuari os.
Las f unci ones del si st ema de gest i n de bases de dat os exi st ent e y la arqui t ect u-
ra de dat os de la base de dat os exi st ent e deben s omet er s e a ingeniera i nversa como
pr ecur sor es del r edi seo de la capa de ba s e de dat os. En al gunos casos se crea un
nuevo model o de dat os (captulo 8). En cada ca s o la ba s e de dat os cl i ent e/ ser vi dor
se s omet e a reingeniera para gar ant i zar que las t r ansacci ones se ej ecut an en f or ma
TM
PDF Editor
CAP TULO 31 REINGENIERA
921
consi st ent e, que t odas l as act ual i zaci ones l as real i zan sl o usuar i os aut ori zados,
que l as regl as cent ral es del negoci o se r ef uer zan (por ej empl o, ant es de que se borre
el regi st ro de una empr esa el servi dor se asegur a de que no haya cuent as por pagar,
cont r at os o comuni caci ones r el aci onados con dicha empr esa) , que l as consul t as se
pueden aj ust ar ef i ci ent ement e y que se ha est abl eci do una capaci dad compl et a de
archi vado.
La capa de reglas de negocios r epr esent a el sof t war e que resi de t ant o en el clien-
te como en el servidor. Este sof t war e realiza t ar eas de control y coordi naci n par a
gar ant i zar que l as t r ansacci ones y consul t as ent r e la apl icacin cl iente y la base de
dat os se aj ust an al pr oceso de negoci os est abl eci do.
La capa de aplicaciones cliente i mpl ement a f unci ones de negoci os que requi eren
gr upos espec fi cos de usuar i os finales. En mucha s i nst anci as, una apl i caci n de
comput ador a central se s egment a en vari as apl i caci ones de escritorio m s pequea s
y somet i das a rei ngeni er a. La comuni caci n ent r e l as apl i caci ones de escritori o
( cuando e s necesari o) se cont rol a medi ant e la capa de regl as de negoci os.
Un est udi o compl et o del di seo y la reingeniera del sof t war e cl i ent e/ ser vi dor es
mat er i a de libros especi al i zados. El l ector i nt er esado debe consul t ar [VAN02],
[COUOO] y [ORF99].
31. 5. 2 Ingeni er a di recta para arqui tecturas ori entadas a objetos
La i ngeni er a del sof t war e ori ent ado a obj et os se ha convert i do en la al t ernat i va en
cuant o al par adi gma de desarrol l o par a muchas or gani zaci ones de sof t war e. Pero,
qu hay acer ca de las apl i caci ones exi st ent es que se desarrol l aron empl eando
mt odos convenci onal es? En al gunos cas os la r espuest a es dej ar t al es apl i caci ones
"como est n". En ot ros, l as apl i caci ones vi ej as deben s omet er s e a rei ngeni er a de
modo que se i nt egren con facilidad en gr andes si st emas or i ent ados a obj et os.
La rei ngeni er a del sof t war e convenci onal en una i mpl ement aci n or i ent ada a
obj et os utiliza mucha s de l as mi s mas t cni cas est udi adas en la par t e 2 de est e libro.
Primero, el sof t war e exi st ent e se somet e a ingeniera i nversa de modo que s ea posi-
ble crear model os de dat os, f unci onal es y de compor t ami ent o apropi ados. Si el si s-
t ema de rei ngeni er a ampl a la funci onal i dad o el compor t ami ent o de la apl icacin
original, se crean casos de us o (captulos 7 y 8). Luego los model os de dat os cr eados
dur ant e la ingeniera i nversa se utilizan j unt o con el model ado CRC (captulo 8) par a
est abl ecer la base con que se definirn las clases. Ensegui da se defi nen las j erarqu as
de cl ases, los model os de rel aci n de obj et os, los model os de compor t ami ent o de
obj et os y los subsi st emas y ent onces comi enza el di seo or i ent ado a obj et os.
Conf or me la i ngeni er a directa or i ent ada a obj et os progresa desde el anl i si s
hast a el di seo se puede i nvocar un model o de pr oces o ISBC (captulo 30). Si la apli-
caci n ant i gua s e encuent r a en un domi ni o que ya ocupan muc ha s apl i caci ones
or i ent adas a obj et os, es pr obabl e que haya una buena biblioteca de component es y
que se pueda utilizar dur ant e la i ngeni er a directa.
TM
PDF Editor
922 P A R T E C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
^ O N S E J O ^
Q u pasos se deben
seguir poro someter o
reingeniero uno
interfaz de usuario?
Un mo n u o l d e m s d e
3 0 0 pgi nas acerco de
los patrones ile
(desarrollado como
porte del proyecto
FAMOOS ESPR1D se
puede descargar desde
www. i om. uni he.
di / - s t g/
Ar c h i v e / f a mo o s /
p a t t e r n s / i n d e x 3 .
En aquel l as cl ases que d a ba n const r ui r se des de el pri nci pi o tal vez s ea posi bl e
reut i l i zar al gor i t mos y es t r uct ur as de da t os de la apl i caci n convenci onal exi st ent e
Sin emba r go, qui z s e a pr eci so di s ear l os de nue vo pa r a aj us t ar l os a la ar qui t ect u-
ra or i ent ada a obj et os.
31. 5. 3 Ingeniera directa de i nterfaces de usuario
Conf or me l as apl i caci ones mi gr an de la c omput a dor a cent ral haci a el escri t ori o, los
usuar i os ya no de s e a n t ol er ar l as i nt er f aces de us ua r i o mi s t er i os as ba s a d a s en car ac-
t er es. De hecho, una por ci n si gni fi cat i va del t r abaj o e mpl e a do en la t ransi ci n de la
c omput a dor a cent ral a la comput aci n cl i ent e- ser vi dor se puede dedi car a la rei n-
geni er a de l as i nt er f aces de us uar i o de la apl i caci n cl i ent e.
Merl o y s us col egas [MER95] s ugi er en el si gui ent e mode l o par a la r ei ngeni er a de
i nt er f aces de usuar i o:
1 . Comprender la interfaz original y los datos q ue se trasladan entre ella y el resto de
la aplicaci n. La finalidad es ent ender c mo ot r os el ement os de un pr ogr a ma
i nt er act an con el cdi go exi st ent e que i mpl ement a la i nt er f az. Si se des ar r o-
llar una nueva GUI, l os dat os que fl uyan ent r e st a y el pr ogr a ma r es t ant e
d e be n s er cons i s t ent es con l os da t os que a ct ua l ment e fl uyen ent r e la i nt er f az
ba s a da en car act er es y el pr ogr ama.
2 . Remodelar el comportamiento implcito en la interfaz existente en una serie de
abstracciones q ue tengan sentido en el contexto de una GUI. Aunque el modo de
i nt er acci n pue de s er r adi cal ment e di ferent e, el c ompor t a mi e nt o de negoci os
que mue s t r a n los us uar i os de l as i nt er f ases vi ej a y nueva ( cuando s e le consi -
der a en t r mi nos de un es cenar i o de util izacin) de be pe r ma ne c e r igual. Una
i nt erfaz r edi s eada deber per mi t i r que un us ua r i o mues t r e el compor t a-
mi ent o de negoci os apr opi ado. Por ej empl o, c ua nd o s e cons ul t a una ba s e de
da t os la vieja i nt er f az pue de r equer i r una l arga seri e de c o ma n d o s ba s a d os en
t ext o par a especi f i car la consul t a. La GUI s omet i da a r ei ngeni er a pue de dirigir
la cons ul t a a una p e q u e a s ecuenci a de el ecci ones con el r at n, per o el pr o-
psi t o y el cont eni do de la cons ul t a pe r ma ne c e n i nt act os.
3 . Introducir mejoras q ue hagan ms eficiente el modo de interacci n. Las fal l as er -
gonmicas de la interfaz existente se estudian y corrigen en el diseo de la
nueva GUI.
4 . Construir e integrarla nueva GUI. La exi st enci a de bi bl i ot ecas de cl ases y her r a-
mi ent as aut omat i zadas puede reducir si gni fi cat i vament e el t r abaj o requeri do
para const rui r la GUI. Sin embar go, la i nt egraci n con el sof t war e de la apl i ca-
cin exi st ent e puede requeri r m s t i empo. Debe t ener se cui dado de gar ant i zar
que la GUI no pr opagar ef ect os col at eral es adver sos en el rest o de la apl i caci n.
"Puede pa ga r poco di ner o a hor a , o puede pa gor mucho di nero m s a de l a nt e . "
Anunci o de tal l er mecni co que s ugi e r e un aj us t e
TM
PDF Editor
En un mu n d o per f ect o, cual qui er pr ogr a ma al que no s e le pudi er a dar ma nt eni -
mi ent o ser i a r et i r ado i nmedi a t a ment e, y ser a sust i t ui do por apl i caci ones de ma yor
cal i dad con r ei ngeni er a desar r ol l ada e mpl e a nd o mo d e r n a s pr ct i cas de i ngeni er a
del s of t war e. Sin emba r go, se vi ve e n un mu n d o de r ecur s os l i mi t ados. La r ei nge-
ni er a d e ma nd a r ecur s os que pue de n ut i l i zarse par a ot r os pr ops i t os del negoci o. En
cons ecuenci a, a nt e s de que una or gani zaci n i nt ent e s ome t e r a r ei ngeni er a una
apl i caci n exi st ent e, de be r eal i zar un anl i si s cost o- benef i ci o.
Sneed [SNE95] ha pr opues t o un model o de anl i si s cost o- benef i ci o par a la rei n-
geni er a. Se def i nen nue ve par met r os :
P, cos t o de ma nt e ni mi e nt o anual act ual par a una apl i caci n
P2 = cos t o de oper aci n a nua l act ual par a una apl i caci n
P3 = val or de negoci os a nua l act ual de una apl i caci n
P = cos t o de ma nt e ni mi e nt o anual pr edi cho d e s pu s de la r ei ngeni er a
P5 = cos t o de oper aci n a nua l pr edi cho de s pu s de la r ei ngeni er a
P = val or de negoci os anual pr edi cho de s pu s de la r ei ngeni er a
P7 = cos t o e s t i ma do de la r ei ngeni er a
Pg = f echa es t i mada de la r ei ngeni er a
P9 = f act or de ri esgo de la r ei ngeni er a (P9 = 1.0 es el val or nomi nal )
L = vi da e s pe r a da del s i s t ema
El cos t o a s oci a do con el ma nt e ni mi e nt o cont i nuo de una apl i caci n candi dat a (es
deci r, si la r ei ngeni er a n o s e real i za) s e pue de defi ni r c o mo
CMAN, = [P3 - (P, + P2)L X L (31- 1)
Los cos t os a s oci a dos con la r ei ngeni er a s e def i nen e mpl e a nd o la si gui ent e r el aci n:
Creing = P ~ (^4 + Ps> X ( " P g ) - ( P 7 X P 9 ) ] ( 31 - 2 )
Con la ut i l i zaci n de l os c os t os pr e s e nt a dos en l as ecua ci ones (31-1) y (31-2) el
benef i ci o gl obal de la r ei ngeni er a s e pue de cal cul ar c o mo
c os t o benef i ci o = CRENG - CMAM (31-3)
El anl i si s cos t o- benef i ci o pr e s e nt a do en l as e c ua c i one s s e pue de r eal i zar par a t odas
l as apl i caci ones de al t a pr i or i dad i dent i f i cadas dur a nt e el anl i si s de i nvent ar i o (sec-
ci n 31. 2. 2). Aquel l as apl i caci ones que mue s t r e n el ma yor cost o- benef i ci o podr n
des t i nar s e a la r ei ngeni er a, mi ent r a s el t r a ba j o con ot r a s s e pue d e pos pone r ha s t a
q u e haya r ecur s os di sponi bl es.
La r ei ngeni er a s e pr es ent a en d o s di f er ent es gr ados de abst r acci n. En el mbi t o del
negoci o, la r ei ngeni er a s e cent r a en el pr oces o de negoci os con el pr ops i t o de ef ec-
TM
PDF Editor
t uar los cambi os par a mej or ar la compet i t i vi dad en al guna r ea del negoci o. En el
mbi t o del sof t war e, la reingeniera exami na los si st emas y apl i caci ones de infor-
maci n con la finalidad de reest ruct urarl os o reconst rui rl os de modo que muest r en
mayor cal idad.
La rei ngeni er a de pr ocesos de negoci o (RPN) defi ne met as del negoci o, identifica
y eval a los pr oces os de negoci os exi st ent es (en el cont ext o de met a s definidas),
especi fi ca y di sea pr ocesos revi sados, y el abor a prot ot i pos, los refi na y part i cul ari -
za dent r o de un negoci o. La RPN t i ene un objetivo que va m s all del sof t war e. Su
resul t ado con frecuenci a es la definicin de las f or mas en las cual es l as t ecnol og as
de la i nformaci n pueden apoyar mej or a los negoci os.
La reingeniera de sof t war e compr ende una serie de act i vi dades que incluyen
anl i si s de inventario, reest ruct uraci n de document os, ingeniera i nversa, reest ruc-
t uraci n de pr ogr amas y dal os, e i ngeni er a directa. La finalidad de est as act i vi dades
es crear versi ones de pr ogr amas exi st ent es que s ean de mayor cal i dad y t engan
mayor facilidad de mant eni mi ent o ( pr ogr amas que ser n vi abl es ya muy avanzado
el siglo xxi).
El anl i si s de i nvent ari os permi t e que una organi zaci n eval e cada apl i caci n
si st emt i cament e, con la finalidad de det er mi nar cul es son candi dat as a la rei nge-
niera. La reest ruct uraci n de document os crea un mar co de t rabaj o de document aci n
que necesari o par a bri ndar apoyo a l argo pl azo a una apl i caci n. La ingeniera
isa es el pr oceso de anal i zar un pr ogr ama con el propsi t o de obt ener i nforma -
cion de di seo de dat os, arqui t ect ni co y de procedi mi ent o. Fi nal ment e, la i ngeni e-
ra directa reconst ruye un pr ogr ama empl eando moder nas prct i cas de i ngeni er a
del sof t war e y la i nf or maci n apr endi da dur ant e la ingeniera inversa.
El cost o-benefi ci o de la rei ngeni er a se det er mi na cuant i t at i vament e. El cost o del
statu q uo, est o es, el cost o asoci ado con el soport e y el mant eni mi ent o act ual es de
una apl icacin exi st ent e, se compar a con los cost os pr oyect ados de la rei ngeni er a y
la reducci n resul t ant e en los cost os de mant eni mi ent o. En casi t odos l os casos en
los que un pr ogr ama t enga una vida larga y en la act ual i dad muest r e escasa facili-
dad de mant eni mi ent o, la rei ngeni er a r epr esent a una est rat egi a de negoci os efecti-
va en cuant o al cost o.
[CAN72] Canni ng, R., "The Ma i nt e na nc e ' I ceber g' ", en EDPAnalyzer, vol . 10, n m. 10, oc t ubr e
de 1972.
[CAS88] "Case Tool s for Rever se Engi neer i ng", en CASE Outlook, CASE Consul t i ng Gr oup, vol 2,
n m. 2, 1988, pp. 1- 15.
ICHI90] Chi kof sky, E. ). y ). H. Cr os s , II, " Rever s e Engi ne e r i ng a n d Des i gn Recover y: A
Ta x o n o my , en IEEE Software, e ne r o de 1990, pp. 13-17.
[COUOO] Coul ouri s, G., J. Dol l i mor e y T. Ki ndberg, Distrbuted Systems: Concept s a nd Desi gn, 3a.
ed. , Addi son-Wesl ey, 2000.
|DAV90) Da venpor t , T. H. y J. E. Young, "The New I ndust r i al Engi neeri ng-, I nf or ma t i on
Technol ogy a nd Bus i nes s Pr oces s Redesi gn", en Sloan management Review, ve r a no de 1990,
pp. 11-27.
TM
PDF Editor
CAP TULO 31 REINGENIERA
925
[DEM95] DeMarco, T., "Lean and Mean", en IEEE Software, novi embr e de 1995, pp. 101-102.
[HAM90) Hammer , M., "Reengi neer Work: Don' t Aut omat e, Obl i t rat e", en H arvard Business
Review, julio-agosto de 1990, pp. 104-112.
[HAN93] Manna, M., "Mai nt enance Burden Begging for a Remedy", en Datamation, abril de
1993, pp. 53-63.
[JAY94| Jaychandr a, Y., Re-engineering the Networked Enterprise, McGraw-Hill, 1994.
|MER93| Merlo, E. et al., "Reverse Engi neer ng of user Interfaces", Proc. Working Conference on
Reverse Engineerng, IEEE, Baltimore, mayo de 1993, pp. 171-178.
[MER95] Merlo, E. et al., "Reengi neeri ng User Interfaces", en IEEE Software, ener o de 1995, pp.
64-73.
1M1L81] Miller,)., en Techniq ues ofProgram and System Maintenance, (G. Parikh, ed.) wi nt hr op
Publishers, 1981.
[ORF99] Orfali, R., D. Harkey y J. Edwards, Client/Server Suvival Guide, 3a. ed., Wiley, 1999.
[OSB90] Osborne, W. M. y E. J. Chikofsky, "Fitting Pi eces t o t he Mai nt enance Puzzl e", en IEEE
Software, ener o de 1990, pp. 10-11.
[PRE94J Premerl ani , W. J. y M. R. Blaha, "An Approach for Reverse Engi neer ng of Rel at i onal
Databases", en CACM, vol. 37, nm. 5, mayo de 1994, pp. 42-49.
[RIC89I Ricketts, J. A., ). C. DelMonaco y M. W. Weeks, "Data Reengineering for Application
Systems", Proc. Conf. Software Maintenance-1989, IEEE, 1989, pp. 174-179.
[SNE951 Sneed, H., "Planning the Reengineering of Legacy Systems", en IEEE Software, ener o de
1995, pp. 24-25.
[STE93] St ewart , T. A., "Reengineering: The Hot New Managing Tool", en Fortune, 23 de agost o
de 1993, pp. 41-48.
[SWA76] Swanson, E. B., "The Di mensi ons of Mai nt enance", Proc. Second Intl. Conf. Software
Engineerng, IEEE, oct ubre de 1976, pp. 492-497.
[VAN02) Van St een, M. y A. Tanenbaum, Distributed Syst ems: Principies and Paradigms.
Prentice-hall, 2002.
[WAR74] Wamier, J. D Ijygical Construction ofPrograms, Van Nostrand-Reinhold, 1974.
31. 1. Considerar cualquier empl eo realizado en los ltimos cinco aos. Describir el proceso de
negocio en el que se particip. Emplear el model o de RPN descrito en la seccin 31.1.3 para
recomendar cambios al proceso con la finalidad de hacerlo ms eficiente.
3 1 . 2 . Invest i gar un poco acer ca de la efi caci a de la rei ngeni er a de pr oces os del negoci o.
Present ar ar gument os en favor y en contra de est e enfoque.
3 1 . 3 . El i nst ruct or sel ecci onar uno de los pr ogr amas que t odos en la cl ase han desarrol l ado
dur ant e est e curso. Int ercambi e su pr ogr ama en f or ma al eat ori a con al gui en m s en la cl ase.
No expl i que u of r ezca un "paseo" por el pr ogr ama. Ahora, i mpl ement e una mej or a (que haya
especificado el instructor) en el programa que ha recibido.
a) Realice t odas las t ar eas de i ngeni er a del sof t war e, i ncl uso una breve pr ueba manual
(mas no con el aut or del programa).
b) Conser ve un cui dadoso segui mi ent o de t odos los er r or es encont r ados dur ant e las
pruebas.
c) Describa sus experi enci as en clase.
31. 4. Explorar la lista de verificacin del anlisis de inventario pr esent ado en el sitio Web SEP e
intentar el desarrollo de un sistema cuantitativo de calificacin de soft ware que pudiese aplicarse
a pr ogr amas exi st ent es con la finalidad de elegir pr ogr amas candi dat os par a reingeniera. El
sistema debe rebasar el anlisis present ado en la seccin 31.6.
3 1 . 5 . Sugeri r opci ones a la document aci n por escri t o o el ect rni ca convenci onal que
pudi esen servir como base par a la r eest r uct ur aci n de document os. (Sugerenci a: pi nsese en
l as nuevas t ecnol og as descri pt i vas que se pudi er an usar par a comuni car el pr opsi t o del
soft ware. )
TM
PDF Editor
31.6. Al gunas per s onas creen que la t ecnol og a de inteligencia artificial aument ar el gr ado
de abst racci n del pr oceso de ingeniera inversa. Realizar al go de investigacin acerca de est a
materia (es decir, el uso de IA en la ingeniera inversa) y escribir un breve ensayo que cont enga
una opinin acerca de est e punt o.
31.7. Por qu la compl et ud es difcil de lograr conf or me aument a el gr ado de abst racci n?
31.8. Por qu debe aument ar la interactividad si la compl et ud aument a?
31.9. Con base en la i nformaci n obt eni da va Internet, pr esent e a su cl ase las caract er st i cas
de t res herrami ent as de ingeniera inversa.
31.10. Existe una sutil diferencia ent re reest ruct uraci n e ingeniera directa. Cul es?
31.11. Investigue la bibliografa o f uent es de Internet par a encont r ar uno o m s escri t os que
borden est udi os de caso de reingeniera de comput ador a central a cliente-servidor. Present e un
resumen.
31. 12. Cmo determinara de P, a P7 en el modelo costo-beneficio presentado en la seccin 31.6?
Al igual que muchos t emas apasi onant es en la comuni dad de negocios, las exageraci ones que
rodeaban la reingeniera de procesos de negoci o han dado paso a una visin ms pragmt i ca
de la mat eri a. Hammer y Champy (Reengineering the Corporation, HarperBusiness, edicin revi-
sada, 2001) precipit el i nt ers t empr ano con el xito de vent as de su libro. Ms tarde, Hammer
(Beyond Reengineering. H ow the Processed-Centered Organization Is Changing Our Work and Our
Lives, HarperColIins, 1997) refino su visin al enfocarse sobre los t emas "cent rados en el pro-
ceso".
Los libros de Smith y Fingar (Business Process Management (BPM): The Third Wave, Meghan-
Kiffer Press, 2003), Jacka y Keller (Business Process Mapping: Improving Customer Satisfaction,
wiley, 2001), Sharp y McDermott (Workflow Modeling, Artech House, 2001), Andersen (Business
Process improvement Toolbox, Ameri can Society for Quality, 1999) y Harrington et al. (Business
Process Improvement Workbook, McGraw-Hill, 1997) present an est udi os de caso y directrices
det al l adas para la RPN
Feldmann (The Practical Guide to Business Process Reeingineering Using IDEFO, Dorset House,
1998) analiza una notacin de model ado que auxilia en la RPN. Berztiss (Software MeLhods for
Business Reengineering, Springer, 1996) y Spurr el ai (Software Assistancefor Business Reengineering,
Wiley, 1994) exami nan herrami ent as y t cni cas que facilitan la RPN.
Secord y sus col egas (Modernizing Legacy Systems, Addison-Wesley, 2003), Ulrich (Legacy
systems. rransformation Stratcgics, Prentice-Hall, 2002), Valenti (Successf ul Software Reenginee-
ring, IRM Press, 2002) y Rada (Reengineering Software: H ow to Reuse Programming to Build new,
State-of-the-Art Software, Fitzroy Dearborn Publishers, 1999) se enf ocan en las est rat egi as y prc-
ticas para la reingeniera en un cont ext o tcnico. Miller (Reengineering Legacy Software Systems,
Digital Press, 1998) "ofrece un mar co de t rabaj o par a mant ener las apl i caci ones de los si st emas
si ncroni zadas con las est rat egi as del negoci o y los cambi os tecnolgicos". Umar (Application
(Re)Engineering: Building Web-Based Applications and Dealing with Legacies, Prentice-Hall, 1997)
ofrece l i ncami ent os valiosos para las organi zaci ones que quieren t ransformar los si st emas
her edados en un ent or no basado en Web. Cook (Building Enterprise Information Architectures:
Reengineering Information Systems, Prentice-Hall, 1996) analiza el puent e entre la RPN y la tecno-
loga de la informacin. Aiken (Data Reverse Engineering, McGraw-Hill, 1996) estudia cmo recu-
perar, reorganizar y reutilizar datos de la organizacin. Arnold (Software Reengineering, IEEE
Computer Society Press, 1993) ha reunido una excelente antologa de los primeros ensayos que tra-
taban acerca de las tecnologas de la reingeniera del soft ware.
Una ampl i a variedad de f uent es de i nformaci n acerca de reingeniera de sof t war e est dis-
ponibl e en Internet. Una lista act ual i zada de referenci as en la World Wide Web s e puede encon-
trar en el sitio Web SEPA:
TM
PDF Editor
C A P I T U L O
EL CAMI NO
POR RECORRER
32
CONCEPTOS
CLAVE
mbito del
cambio 929
conocimiento . .934
datos 933
tica 936
i mpor t anci a
del software - . 928
informacin . . . 9 3 3
personas 930
proceso 931
tendencias
tecnolgicas . . .936
E
n l os 31 cap t ul os pr e c e de nt e s s e expl or un pr oces o par a la i ngeni er a del
s of t wa r e. Se pr e s e nt a r on t a nt o pr ocedi mi ent os d e gest i n c o mo m t od os
t cni cos, pr i nci pi os bs i cos y t cni cas especi al i zadas, act i vi dades or i ent a-
da s a l as pe r s ona s y t ar eas a d e c ua d a s par a aut omat i zar l as, not aci n de papel y
l pi z y he r r a mi e nt a s de s of t wa r e. Se a r gume nt que la medi ci n, la di sci pl i na y
una vi gi l anci a est r i ct a s obr e la cal i dad ge ne r a r n un s of t wa r e que sat i sf aga l as
ne c e s i da de s de l os cl i ent es, que sea: fi abl e, que t enga faci l i dad de ma nt e ni mi e nt o,
que s ea mej or . Sin emba r go, nunc a s e ha pr omet i do que la i ngeni er a del soft -
wa r e s e a una pa na c e a .
Conf or me s e cont i ne el vi aj e e n el nuevo siglo, l as t ecnol og as d e s of t war e
y s i s t ema s s egui r n s i endo un des af o par a l os pr of es i onal es del s of t wa r e y l as
c ompa a s que cons t r uyan s i s t ema s ba s a d os en comput a dor a s . Aunque escr i bi
es t as pa l a br a s con una vi si n del si gl o xx, Max Hopper [HOP90] descr i bi c on
pr eci si n el es t ado act ual del as unt o:
Puesto que los cambios en la tecnologa de la informacin se estn volviendo tan r-
pidos e implacables, y las consecuencias de caer ante ellos son irreversibles, las com-
paas dominarn la tecnologa o morirn... Piense en ello como en un molino de
tecnologa. Las compaas tendrn que correr cada vez ms rpido para permanecer
en su lugar.
Qu e s ? El futuro nunca es fcil de
predecir, no obstante eruditos, confe-
rencistas televisivos y expertos indus-
triales rio se resisten. El camino por
recorrer, est pl agado de restos de
excitantes nuevas tecnologas que en realidad
nunca lo fueron (a pesar de las exageraciones
publicitarias), y con frecuencia lo conforman las
tecnologas ms modestas que de alguna forma
modificaron la direccin y amplitud del camino
principal. En consecuencia, no se intentar pre-
decir el futuro sino que se estudiarn algunos de
los conflictos que ser necesario considerar pora
comprender cmo el software y la ingeniera del
software cambi arn en los aos por venir.
Qui n l o h a c e ? Todo l mundo!
Por q u e s i mpo r t a nt e ? Por qu los anti-
guos reyes contrataban adivinos? Por qu las
grandes corporaciones multinacionales conirc-
tan firmas consultoras y grupos de analistas
par a el aborar predicciones? Por qu un por-
centaje sustancial del pblico lee horscopos?
Porque quieren saber qu vendr para estar
preparados.
Cul e s s o n l os p a s o s ? No existe una frmu-
la para predecir el camino que se recorrer. Se
intenta hacerlo mediante la recopilacin de
datos y su organizacin par a proporcionar
informacin til y el examen de asociaciones
sutiles para obtener conocimiento y, a partir de
ste, sugerir probables hechos que predigan
cmo sern las cosas en cierto tiempo futuro.
Cul es el producto obteni do? Una visin
del futuro cercano que podra o no ser correcta.
he c ho c o r r e c t a me nt e ? Predecir el camino
que se recorrer es un arte, no una ciencia. De
hecho, es bastante raro cuando una prediccin
927
TM
PDF Editor
seria acer ca del futuro es absol ut ament e correc-
ta o i nequ vocament e er r nea (con la excepci n,
por fort una, de las predi cci ones del fin del
mundo). Se buscan t endenci as y se intenta extra-
pol arl as haci a adel ant e en el t i empo. Las correc-
ciones de la ext rapol aci n slo se pueden valo-
r ar conf or me pa s a el tiempo.
Los cambios en la tecnologa de ingeniera de software son de hecho "rpidos e
implacables", mientras que, al mismo tiempo, el progreso, por lo general, es bastan-
te lento. Pero cuando se toma la decisin de adoptar un nuevo mtodo (o una nueva
herramienta), de llevar a cabo el entrenamiento necesario para comprender su apli-
cacin y de introducir la tecnologa en la cultura de desarrollo del software, algo ms
nuevo (e incluso mejor) ha llegado, y el proceso comienza de nuevo.
En este captulo se examinan tendencias hacia el futuro. La finalidad no es explo-
rar todas las reas de investigacin que resulten prometedoras. Tampoco es mirar en
una "bola de cristal" y pronosticar el futuro. Ms bien, se explora el mbito del cam-
bio y la forma en la que ste afectar el proceso de ingeniera del software en los
aos por venir.
3 2 . 1 L A I MP O R T A N C I A DEL S OF T WA R E . S E G U N D A PARTE
La importancia del software de computadora se puede establecer en muchas formas.
En el captulo I el software se caracteriz como un diferenciador. La funcin que pro-
porciona el software diferencia productos, sistemas y servicios, y ofrece una ventaja
competitiva en el mercado. Pero el software es ms que un diferenciador. Los progra-
mas, documentos y datos que constituyen el software ayudan a generar el producto
ms importante que cualquier individuo, negocio o gobierno pueda adquirir: informa
ci n. Pressman y Herrn [PRE91] describen al software en la forma siguiente:
El soft ware de comput adora es una de slo unas cuant as tecnol ogas cl ave que t endrn
un i mpact o significativo en casi cualquier aspect o de la soci edad moderna. . . Es un meca-
ni smo para aut omat i zar negocios, industrias y gobi ernos, y un medi o para transferir nueva
tecnologa, un mt odo de capt ura de experi enci as valiosas par a que las utilicen otros, un
medi o para diferenciar los product os de una compa a de los de sus compet i dores, y una
vent ana al conoci mi ent o colectivo de una corporaci n. El soft ware es un pivote par a casi
cualquier aspect o de los negocios. Pero, en muchas formas, el sof t war e t ambi n es una
tecnol oga oculta. Se encuent ra soft ware (usual ment e sin darse cuent a de ello) cuando se
viaja al trabajo, se realiza al guna compr a al menudeo, se det i ene en el banco, se hace una
l l amada telefnica, se visita al mdi co o se realiza al guna de las ci ent os de actividades co-
tidianas que reflejan la vida moderna.
La omnipresencia del software conduce a una conclusin simple: siempre que
una tecnologa tenga un amplio impacto (un impacto que pueda salvar vidas o
ponerlas en peligro, construir negocios o destruirlos, informar a los lderes de
gobiernos o mal informarlos) debe manejrsele con cuidado.
TM
PDF Editor
CAP TULO 3 2 EL CAMINO POR RECORRER 929
"Las pr edi cci ones s on mu y di f ci l es d e hacer , e s pe c i a l me nt e c u a n d o s e r e l a c i ona n con el f u t u r o . "
Mark Twoin
3 2 . 2 EL MBI TO PEL CAMBI O
Los cambios en la informtica durante los pasados 50 aos han sido dirigidos por
avances en las ciencias bsicas: fsica, qumica, ciencia de materiales e ingeniera.
Esta tendencia continuar durante el primer cuarto del siglo xxi. El impacto de las
nuevas tecnologas es profundo: en las comunicaciones, la energa, el cuidado de la
salud, la transportacin, el entretenimiento, la economa, la industria manufacture-
ra y la guerra, por mencionar slo unas cuantas.
Tecnologas a observar. Las tecnologas para mirar.
I NFORMACI N
Los editores de PC Magazine [PCM03]
preparan un nmero anual de "Tecnologas del
futuro" que "[busca] a travs de todos los espacios de chat
(hay varios de ellos) identificar las 20 tecnologas ms
prometedoras del maana". Las tecnologas registradas
abarcan toda una amplia gama, desde el cuidado de la
salud hasta la guerra. Sin embargo, es interesante
observar que el software y la ingeniera del software tienen
un significativo papel que jugar en todas, ya sea como
impulsores de la tecnologa o como una parte integral de
ellas. Las siguientes representan una muestra de las
tecnologas registradas:
Nanot ubos de carbono. Con una fina estructura
parecida al grafito, los nanotubos de carbono pueden
funcionar como alambres, para transmitir seales
desde un punto a otro, y como transistores, usando
cambios de seal para almacenar informacin. El uso
de estos dispositivos parece prometedor en el
desarrollo de dispositivos electrnicos ms pequeos,
ms rpidos, de menor energa y menos costosos (por
ejemplo, microprocesadores, memorias, pantallas).
Bi os ens ores . Los sensores microelectrnicos, externos o
implantables, ya se utilizan ampliamente en la
deteccin, desde agentes qumicos en el aire que se
respira hasta niveles de sangre en pacientes cardiacos.
Conforme estos'sensores se vuelvan ms sofisticados,
podrn implantarse en pacientes mdicos para
supervisar una variedad de condiciones relacionadas
, con la salud, o incorporarlos a los uniformes de los
soldados para supervisar la presencia de armas
biolgicas o qumicas.
Pant al l as OLED. Un OLED (diodo emisor de luz
orgnico) "utiliza una molcula diseadora con base
de carbono que emite luz cuando una corriente
elctrica pasa a travs de ella. Junte muchas de estas
molculas y obtendr una pantalla muy delgada de
asombrosa calidad; no requiere fuente de luz trasera
que provoca prdidas de energa" [PCM03], El
resultado: pantallas ultradelgadas que se pueden
enrollar o doblar, extender sobre una superficie curva o
adaptarse de alguna otra forma a un entorno
especfico.
Retcula de cmput o. Esta tecnologa (disponible en la
actualidad) crea una red que aprovecha los miles de
millones de ciclos de CPU no utilizados de cada
mquina en la red y permite que se completen tareas
de cmputo excesivamente complejas sin contar con
una supercomputadora. Vase un ejemplo prctico que
abarca 4. 5 millones de computadoras en
http://setiathome.berlceley.edu/.
Mqui nas cogni t i vas. El "santo grial" en el campo de
la robtica es desarrollar mquinas que estn
conscientes de su entorno, que puedan "recabar pistas,
responder a situaciones siempre cambiantes e
interactuar con personas de modo natural" [PCM03].
Las mquinas cognitivas todava estn en las primeras
etapas de desarrollo, pero el potencial (si se logra
alguna vez) es enorme.
TM
PDF Editor
A l argo pl azo, l os a va nc e s r evol uci onar i os e n la i nf or mt i ca bi en pue de n dirigir-
l os l as ci enci as soci al es: psi col og a h u ma n a , soci ol og a, filosofa, ant r opol og a y
ot r as. El per i odo de gest aci n de l as t ecnol og as i nf or mt i cas que s e pue da n der i var
de e s t a s di sci pl i nas es muy difcil de pr edeci r , pe r o l as pr i mer as i nf l uenci as ya han
c o me n z a d o (por ej empl o, l as c omuni d a d e s una es t r uct ur a ant r opol gi ca de
usuar i os, que s on r ami f i caci ones de l as r edes de par es a pares).
La i nf l uenci a de l as ci enci as soci al es qui z ayude a mol dear la di r ecci n de la
i nvest i gaci n en i nf or mt i ca e n l as ci enci as bsi cas. Por ej empl o, el di s eo de l as
f ut ur as c omput a d or a s tal vez lo gu e m s el conoci mi ent o de la psi col og a cer ebr al
que el de la mi cr oel ect r ni ca convenci onal .
A cor t o pl azo, l os c a mbi os que i nci di rn e n la i ngeni er a del s of t wa r e dur a nt e la
si gui ent e dca da reci bi rn la i nfl uenci a de cuat r o f ue nt e s s i mul t neas : 1) l as pe r s o-
n a s que r eal i cen el t r abaj o, 2) el pr oc e s o que apl i quen, 3) la nat ur al eza de la i nfor-
maci n y 4) la t ecnol og a i nf or mt i ca s ubyacent e. En l as s ecci ones q u e si guen s e
e xa mi na n con m s det al l e ca da u n o de es t os c ompone nt e s : per s ona s , pr oces o,
i nf or maci n y t ecnol og a.
3 2 . 3 LAS PERSONAS Y I.A FORMA EN LA QUE CONSTRUYEN SI STEMAS
El s of t war e que r equi er en l os s i s t ema s de al t a t ecnol og a s e vuel ve m s compl ej o
ca da a o, y el t a ma o de l os pr ogr a ma s r es ul t ant es a u me n t a pr opor ci onal ment e. El
r pi do cr eci mi ent o en el t a ma o del pr ogr a ma "pr omedi o" pr esent ar a poc os pr o-
bl e ma s si n o f ues e por un he c ho si mpl e: c onf or me a u me n t a el t a ma o del pr ogr a-
ma , t ambi n de be a u me n t a r el n me r o de pe r s ona s q u e deben t r abaj ar e n l.
La exper i enci a i ndi ca que c onf or me a u me n t a el n me r o de pe r s ona s de un equi -
p o de pr oyect o d e s of t war e, tal vez la pr oduct i vi dad gl obal del gr upo di smi nuya. Una
f or ma par a r esol ver es t e pr obl ema cons i s t e en cr ear equi pos de i ngeni er a del sof t -
war e, y en cons ecuenci a dividir al per s onal en gr upos de t r abaj o i ndi vi dual es. Si n
emba r go, c onf or me cr ece el n me r o d e equi pos de t r a ba j o de i ngeni er a del s of t wa -
re, la comuni ca ci n ent r e el l os se vuel ve t an difcil y t ar dada c o mo la comuni ca ci n
ent r e l os i ndi vi duos. Peor a n, la comuni ca ci n (ent re i ndi vi duos o equi pos) t i ende
a s er i nef i ci ent e; es decir, s e pas a de ma s i a do t i empo t r ansf i r i endo muy poc o cont e-
ni do de i nf or maci n, y con muc ha f r ecuenci a la i nf or maci n i mpor t ant e "cae ent r e
l as gri et as".
"El choque del f ut ur o es lo a got a dor a t ensi n y desor i ent aci n que i nduci mos en los i ndi vi duos al suj et ar l os o
dema s i a dos cambi os en un per i odo dema s i a do cor t o. "
Atvin Tof f l er
Si la comuni da d de la i ngeni er a del s of t wa r e t i ene que t r at ar con efi caci a el dile-
ma de la comuni caci n, el c a mi no que r ecor r er n l os i ngeni er os de s of t wa r e de be
incluir ca mbi os r adi cal es en la f or ma en que l os i ndi vi duos y l os equi pos s e comuni -
can ent r e s. El cor r eo el ect r ni co, l os si t i os Web y l as conf er enci as de vi deo cent r a-
930
Para predicciones
acerco del futuro de ta
tecnologa y otros
materias, vase
www. f ut ur e f a c i ng.
com.
TM
PDF Editor
l i zadas a hor a s on me c a ni s mos c o mu n e s par a conect ar a un gr an n me r o de per s o-
na s a una r ed de i nf or maci n. La i mpor t anci a de es t as he r r a mi e nt a s en el cont ext o
del t r abaj o de i ngeni er a del s of t wa r e n o s e de be sobr eval uar . Con un cor r eo el ec-
t r ni co ef i ci ent e o un si st ema de mens a j er a i ns t ant nea, el pr obl ema que e nc ue n-
t re un i ngeni er o de s of t war e en la ci udad de Nueva York pue de r esol ver se con la
a yuda de un col ega en Tokio. En r eal i dad, l as s es i ones de conver s aci n [chat] s obr e
un t ema par t i cul ar y l os gr upos de not i ci as es peci al i zados se vuel ven deps i t os de
conoci mi ent o que per mi t en que el s aber col ect i vo de un gr an gr upo de t cni cos s ea
apl i cado par a sol uci onar un pr obl ema t cni co o un conf l i ct o de gest i n.
El vi deo per s onal i za la comuni caci n. En el mej or de l os cas os , per mi t e que l os
col egas en di f er ent es ubi caci ones (o en di f er ent es cont i nent es) se "r enan" con ci er
ta r egul ar i dad. Adems , el vi deo t ambi n of r ece ot r o benef i ci o: se pue de us ar c o mo
depsi t o de conoci mi ent o acer ca del s of t wa r e y par a ent r ena r a l os reci n l l egados
a un pr oyect o.
"Lo respuesta artstico a de c ua da ant e la t ecnol og a digital es adopt ar l a como una nueva vent ano a t odo lo
e t e r na me nt e h uma no, y usar l a con pasi n, sabi dur a, t emer i dad y al egr a. "
Ral ph Lambregl i a
^ CONSEJO^
Msym s' no
programadores" estn
construyendo sus
propias (peq ue os)
aplicaciones. Esta
tendencia actual es
probable q ue se
acelere en lo futuro.
Estosciviles'
deberan aplicar la
tecnologa estudiado
en este libro? Proba-
blemente no. Pero
deberan adoptar uno
filosofa de ingeniera
del software gil,
incluso si no adoptan
la prctica.
La evol uci n de l os a ge nt e s i nt el i gent es t ambi n ca mbi a r l os pa t r one s l abor al es
de un i ngeni er o de s of t war e al ext ender s us t anci al ment e l as ca pa ci da des de l as
he r r a mi e nt a s de s of t war e. Los a ge nt e s i nt el i gent es mej or a r n la habi l i dad del i nge-
ni er o al c ompr oba r var i as veces l os pr oduct os de t r abaj o de i ngeni er a e mpl e a nd o
conoci mi ent o espec f i co del domi ni o, r eal i zando t ar eas admi ni st r at i vas, l l evando a
c a bo una i nvest i gaci n dirigida y coor di na ndo la comuni caci n ent r e l as per s ona s .
Fi nal ment e, la adqui si ci n de conoci mi ent o es t c a mbi a ndo en f or ma radi cal . En
I nt er net , un i ngeni er o de s of t wa r e puede suscr i bi r se a gr upos de not i ci as que se
e nf oq ue n en r e a s de t ecnol og a que le i nt er esen di r ect ament e. Una pr egunt a envi a-
da a un gr upo de not i ci as precipita l as r espuest as de ot r as par t es i nt er esadas al r ededor
del mundo. La World Wide Web of r ece a un i ngeni er o de s of t wa r e la m s gr a nde
bi bl i ot eca del mu n d o de t r abaj os e i nf or mes de i nvest i gaci n, ma nua l es , c ome nt a -
r i os y r ef er enci as acer ca de la i ngeni er a del s of t war e.
Si la hi st ori a es un i ndi ci o, es a cer t a do deci r que l as pe r s ona s no ca mbi a r n. Sin
emba r go, l as f or ma s en l as que s e comuni ca n, el ent or no en el que t r abaj an, la
maner a en la que adqui er en conoci mi ent o, l os mt odos y her r ami ent as que usan, la dis-
cipl ina que apl i can y, por l o t ant o, la cul t ura gener al del desar r ol l o del s of t war e c a m-
bi ar n en f or ma s si gni fi cat i vas e i ncl uso pr of undas .
3 2 . 4 E L
" N U E Y Q "
P R O C E S O DE I N G E N I E R I A D E L S O F T WA R E
Es r a zona bl e car act er i zar l as pr i mer a s d o s d c a da s de la pr ct i ca de la i ngeni er a del
s of t wa r e c o mo la er a del " pe ns a mi e nt o l i neal ' Foment a da por el model o cl si co del
ci cl o vital, la i ngeni er a del s of t wa r e s e e nf oc c o mo una act i vi dad l ineal en la que
TM
PDF Editor
se podr an apl i car una seri e de pa s os s ecuenci al es con la finalidad de r esol ver pr o-
bl e ma s compl ej os. Si n emba r go, l os e nf oque s l i neal es a cer ca del desar r ol l o de sof t -
wa r e cor r en cont r a la f or ma e n la que la mayor a de l os s i s t ema s r ea l ment e s e cons -
t ruye. En r eal i dad, l os s i s t ema s compl ej os evol uci onan i t er at i vament e, i ncl uso en
f or ma i ncr ement a! . Por es t a r azn, un gr an s e gme nt o de la c omuni da d de i ngeni e-
ra del s of t wa r e s e des pl aza haci a model os i ncr emnt al es gi l es par a el desar r ol l o
del s of t wa r e.
Los model os de pr oces o i ncr ement al gil r econocen que la i ncer t i dumbr e domi na
la mayor a de los pr oyect os, que l os pl azos de ent r ega con f r ecuenci a s on i mposi bl es
de cumpl i r y cort os, y que la i t eraci n pr opor ci ona la habi l i dad de dar una sol uci n
parcial , i ncl uso c ua ndo un pr oduct o compl et o no es real i zabl e dent r o del t i empo asi g-
nado. Los model os evol ut i vos subr ayan la necesi dad de pr oduct os de t r abaj o i ncre-
mnt al es, anl i si s de riesgo, pl aneaci n y l uego revisin del pl an, y r et r oal i ment aci n
con el cl i ent e. En muc hos cas os el equi po de s of t war e apl i ca un "mani f i est o gil"
(cap t ul o 4) que s ubr aya "los i ndi vi duos e i nt er acci ones s obr e l os pr oces os y her r a-
mi ent as ; el s of t war e oper at i vo s obr e la doc ume nt a c i n det al l ada; la col abor aci n del
cl i ent e s obr e la negoci aci n de cont r at os; y la r es pues t a al ca mbi o s obr e el segui -
mi ent o de un pl an" [BEC01].
"La mej or pr epar aci n par a el buen t r abaj o ma a n a es hacer un bue n t r a ba j o hoy. "
Elbert Hubbard
Las t ecnol og as de obj et os, j unt o con la i ngeni er a del s of t wa r e ba s a da e n com-
pone nt e s (cap t ul o 30), s on una cons ecuenci a nat ur al de la t endenci a haci a l os
model os de pr oces os i ncr ement a l es y evol ut i vos. Ambos t endr n un pr of undo
i mpa ct o s obr e la pr oduct i vi dad del desar r ol l o de s of t wa r e y la cal i dad del pr oduct o.
La reut i l i zaci n de c ompone nt e s of r ece benef i ci os i nmedi at os y convi ncent es.
Cua ndo la reut i l i zaci n s e u n e con l as he r r a mi e nt a s CASE pa r a l os pr ot ot i pos de una
apl i caci n, los i nc r e me nt os del pr ogr a ma s e pue de n const r ui r mu c h o m s r pi da-
me nt e que medi a nt e l os e nf oque s convenci onal es . La el abor aci n de pr ot ot i pos
i nvol ucr a al cl i ent e con el pr oces o. En cons ecuenci a, es pr obabl e que l os cl i ent es y
us uar i os s e i nvol ucr en mu c h o m s en el desar r ol l o del s of t war e. Esto, a su vez,
pue de conduci r a una ma yor sat i sf acci n del us uar i o final y en gener al a mej or a r la
cal i dad del s of t war e.
El r pi do cr eci mi ent o en l as t ecnol og as de r ed y mul t i medi a (por ej empl o, el
a u me n t o exponenci al en l as WebApps dur a nt e l as pa s a d a s dcadas) est c a mbi a n-
do t a nt o al pr oces o de i ngeni er a del s of t wa r e c o mo a s us par t i ci pant es. De nuevo,
se est a nt e un pa r a di gma i ncr ement al gil que des t a ca la i nmedi at ez, la segur i dad
y la est t i ca, as c o mo pr eocupaci n por la i ngeni er a de s of t war e m s convenci o-
nal . Los mod e r nos equi pos de s of t wa r e (por ej empl o, un equi po de i ngeni er a Web)
con f r ecuenci a me z c l a n t cni cos con especi al i st as de cont eni do (por ej empl o, art i s-
t as, msi cos, vi deogr f os) par a const r ui r una f uent e de i nf or maci n des t i nada a una
TM
PDF Editor
c omuni da d de us uar i os gr a nde e i mpr edeci bl e. El s of t wa r e que s e ha des ar r ol l ado
con ba s e e n e s t a s t ecnol og as ha ge ne r a do r adi cal es c a mbi os e c onmi c os y cul t ur a-
les. Aunque l os c onc e pt os y pr i nci pi os bs i cos t r a t a dos en est e libro s on apl i cabl es,
el pr oces o de i ngeni er a del s of t wa r e se debe adapt ar .
A lo l ar go de la hi st or i a de la i nf or mt i ca h a ocur r i do una t r ansi ci n sutil en la t er -
mi nol og a con que se descr i be el t r abaj o de desar r ol l o del s of t war e r eal i zado par a la
c omuni d a d de negoci os . Hace cuar ent a a os , el t r mi no procesamiento de datos er a
la f r ase oper at i va par a descri bi r la ut i l i zaci n de l as c omput a d or a s en un cont ext o
de negoci os. En la act ual i dad, el pr oc e s a mi e nt o de da t os ha da do pa s o a ot r a f r ase
tecnologa de la informaci n que si gni fi ca lo mi s mo per o pr es ent a un sutil c a m-
bi o en el enf oque. La i mpor t anci a r adi ca n o s l o en pr oces ar gr a ndes cant i dades de
dat os, s i no e n obt ener i nf or maci n si gni fi cat i va de di chos dat os. Obvi ament e, s t a
f ue s i empr e la finalidad, pe r o el ca mbi o en la t er mi nol og a refl ej a un c a mbi o muc ho
m s i mpor t ant e en la filosofa de la gest i n.
Cua ndo en la act ual i dad s e a bor da n l as apl i caci ones de s of t wa r e l as pal abr as
datos e informaci n a pa r e c e n r epet i dament e. La pal abr a conocimiento s e e nc ue nt r a
en a l guna s apl i caci ones de i nt el i genci a artificial, per o su ut i l i zaci n e s r el at i vamen-
t e es ca s a . Vi r t ual ment e nadi e s e r ef i er e a la sabidura en el cont ext o de l as apl i ca-
ci ones de s of t war e.
Los da t os s on i nf or maci n en br ut o: col ecci ones de hechos que deben pr oces ar -
se par a que s ea n si gni fi cat i vos. La i nf or maci n s e der i va al as oci ar l os he c hos en un
Espectro de
"informacin".
Datos:
sin asociatividad
Informacin:
asociatividad dentro
de un contexto
asociatividad dentro de creacin de principios
mltiples contextos generalizados con
base en el conocimiento
procedente de fuentes
diferentes
TM
PDF Editor
cont ext o dado. El conoci mi ent o as oci a la i nf or maci n obt eni da en un cont ext o con
ot r a i nf or maci n obt eni da en un cont ext o di f er ent e. Fi nal ment e, la sabi dur a s e pr e-
s ent a c ua nd o l os pr i nci pi os gener a l i za dos s e der i van de conoci mi ent os di spar es.
Cada una de e s t a s cuat r o vi si ones de la "i nf or maci n" s e r epr es ent a e s que m t i c a -
me nt e en la figura 32. 1.
A la f echa, la gr an mayor a del s of t wa r e s e ha cons t r ui do pa r a pr oces ar da t os o
i nf or maci n. Los i ngeni er os de s of t wa r e a hor a es t n i gual ment e pr e oc upa dos con
l os s i s t ema s que pr oces an el conoci mi ent o. 1 1 conoci mi ent o e s bi di mensi onal . La
i nf or maci n r ecopi l ada acer ca de una di ver si dad d e t e ma s r el aci onados e i nconexos
s e r el aci ona par a f or mar un cuer po de hechos que s e l l amar conocimiento. La cl ave
es la habi l i dad per s onal par a asoci ar la i nf or maci n pr oveni ent e de di ver sas f uent es ,
que tal vez n o t engan al guna conexi n evi dent e, y combi nar l a en una f or ma q u e
of r ezca al gn benef i ci o di st i nt o.
" La s a b i d u r a e s e l p o d e r q u e p e r mi t e ut i l i zar el c o n o c i mi e n t o p o r a el b e n e f i c i o d e nos ot r os mi s mo s y d e o t r o s . "
Thomas J. Wa f s o n
Para i l ust rar la pr ogr esi n de s de da t os ha s t a conoci mi ent o, cons i dr ens e l os
da t os cens a l es que i ndi can que l os na ci mi ent os en 1996 e n Es t ados Uni dos f uer on
4. 9 mi l l ones. Est e n me r o r epr es ent a un val or d e dat os. Al r el aci onar es t a pi eza de
dat os con l as t a s a s de naci mi ent o par a l os 40 a o s pr ecedent es , s e pue d e der i var
una til pi eza de informacin-, l os c a da vez m s vi ej os baby boomers de la dca da de
1950 y de pr i nci pi os de la de 1960 hac an un l t i mo e s f ue r z o par a t ener hi j os a nt e s
del fi nal de su vida r epr oduct i va. Adems , l os gen- Xer s ( mi embr os de la gener aci n
X) c o me n z a b a n su vida r epr oduct i va. Los dat os cens a l es e nt onc e s pue de n vi ncul ar-
s e con ot r as pi ezas de i nf or maci n a pa r e nt e me nt e no r el aci onada. Por ej empl o, el
n me r o act ual de pr of es or es de escuel a el ement al q u e s e r et i r ar n dur a nt e la
si gui ent e dcada, el n me r o de es t udi ant es uni ver si t ar i os que s e gr a dua r n en edu-
caci n pr i mar i a y secundar i a, la pr esi n s obr e l os pol t i cos par a ma nt e ne r ba j os l os
i mpues t os y, por l o t ant o, l i mi t ar l os a u me n t o s sal ar i al es a l os pr of esor es.
Todos e s t os e l e me nt os d e i nf or maci n s e pue de n c ombi na r par a f or mul ar una
r epr es ent aci n del conoci mi ent o: exi st i r una pr esi n si gni fi cat i va s obr e el si st ema
educat i vo en Es t ados Uni dos e n la pr i mer a dca da del si gl o xxi, y es t a pr esi n c on-
t i nuar dur a nt e una dcada. Con la ut i l i zaci n de es t e conoci mi ent o pue d e surgi r
una opor t uni dad de negoci o. Qui z haya si gni fi cat i vas opor t uni da des pa r a des a r r o-
llar nue vos mo d o s de a pr endi za j e que s ea n m s ef i caces y me n o s cos t os os que l os
e nf oq ue s act ual es.
1 El rpido crecimiento de las tecnologas de extraccin y al macenami ent o de dat os refleja esta ten-
dencia creciente.
TM
PDF Editor
CAP TULO 3 2 EL CAMINO POR RECORRER
935
El cami no que recorrer el sof t war e conduce a si st emas que pr ocesan el conoci -
mi ent o. Se han est ado pr oces ando dat os empl eando comput ador as dur ant e 50 a os
y ext r ayendo i nformaci n dur ant e m s de t res dcadas. Uno de los desafi os m s sig-
nificativos que enfrent a la comuni dad de ingeniera del soft ware es construir si st emas
que den el pr xi mo paso a lo l argo del espect ro: si st emas que ext rai gan conoci -
mi ent o a partir de los dat os e i nformaci n en una forma prct i ca y benefi ci osa.
La gent e que const ruye y utiliza sof t war e, el pr oceso de i ngeni er a del sof t war e que
s e aplica y la i nformaci n que s e pr oduce resul t an af ect ados por los avances en el
har dwar e y la t ecnol og a del sof t war e. Hi st ri cament e, el har dwar e ha servi do como
el i mpul sor t ecnol gi co en la comput aci n. Una nueva t ecnol og a de har dwar e pro-
porci ona pot enci al . Ent onces los const r uct or es de sof t war e r eacci onan a las dema n-
da s de los consumi dor es con la finalidad de apr ovechar el pot enci al .
Es pr obabl e que las t endenci as f ut ur as de la t ecnol og a de har dwar e avancen por
dos t rayect ori as paral el as. A lo l argo de una t rayect ori a las t ecnol og as de har dwar e
cont i nuar n evol uci onando con rapi dez. Ant e la mayor capaci dad que of r ecen las
ar qui t ect ur as de har dwar e t radi ci onal es, l as dema nda s a los i ngeni er os de sof t war e
cont i nuar n creci endo.
Pero los cambi os ver dader os en la t ecnol og a de har dwar e podr an produci rse en
ot ra di recci n. El desarrol l o de ar qui t ect ur as de har dwar e no t radi ci onal es (por
ej empl o, nanot ubos de car bono, mi cr opr ocesador es EUL, mqui nas cogni t i vas, ret-
cul as de cmput o) podr an pr ovocar cambi os radi cal es en el tipo de sof t war e que se
const rui r y cambi os f undament al es en el enf oque haci a la i ngeni er a del sof t war e.
Dado que est os enf oques no t radi ci onal es se est n madur ando, e s difcil det er mi nar
cul t endr un i mpact o significativo e i ncl uso es m s difcil predeci r cmo cambi ar
el mundo del sof t war e par a adapt ar s e a ellos.
Las t endenci as fut uras de la ingeniera del sof t war e las i mpul san las t ecnol og as
de sof t war e. La reutil izacin y la i ngeni er a del sof t war e bas ada en component es
of r ecen la mej or oport uni dad en cuant o a mej or as en la magni t ud de la calidad de
los si st emas y en el t i empo en que llegan al mer cado. De hecho, conf or me pasa el
t i empo, el negoci o del sof t war e puede comenza r a par ecer se mucho al negoci o de
har dwar e de la act ual i dad. Qui z haya empr es as que const r uyan di sposi t i vos dis-
cret os ( component es de sof t war e reutilizables), ot r as empr es as que const r uyan
component es de si st emas (por ej empl o, un conj unt o de her r ami ent as para la inte-
raccin hombr e- mqui na) e i nt egradores de si st emas que of r ezcan sol uci ones (pro-
duct os y si st emas const r ui dos de f or ma personal i zada) par a el usuar i o final.
La ingeniera del sof t war e cambi ar , de eso se puede est ar seguro. Pero, sin
i mport ar cun radi cal es s ean los cambi os, se puede est ar segur o de que la calidad
nunca per der su i mport anci a, y de que el anl i si s y el di seo efect i vos y las pr ue-
ba s compet ent es si empr e t endr n un l ugar en el desarrol l o de los si st emas bas ados
en comput ador as.
TM
PDF Editor
936
PARTE CI NCO TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
I NFORMACI N
Tendencias tecnolgicas
P. Cripwell Associates (www.jpcripwell.com),
una firma de consultorio especializada en
gestin del conocimiento e ingeniera de la informacin,
analiza cinco impulsores tecnolgicos que influirn en las
direcciones de la tecnologa en los aos por venir.
Combi naci n de t ecnol og as . Cuando dos
importantes tecnologas se funden, el impacto del resultado
con frecuencia es mayor que la suma del impacto de cada
una por separado. Por ejemplo, la tecnologa de los
satlites GPS (sistemas de posicionamiento global) junto
con la capacidad de cmputo a bordo y las tecnologas de
pantallas LCD han permitido construir sofisticados sistemas
de localizacin en los automviles. Las tecnologas con
frecuencia evolucionan a rutas separadas, pero el impacto
en los negocios o social significativo slo ocurre cuando
alguien los combina para resolver un problema.
Fusi n de dat os . Mientras ms datos se adquieran,
ms datos se necesitarn. Ms importante an, mientras
ms datos se adquieran, ms difcil es extraer informacin
til. De hecho, con frecuencia se necesita adquirir todava
ms datos para comprender qu datos son importantes;
qu datos son relevantes para una necesidad o fuente
particular, y qu datos se deben emplear para la toma de
decisiones. Este es el problema de la fusin de datos. J. P.
Cripwell utiliza como ejemplo un sistema avanzado de
supervisin de trfico automovilstico. Sensores digitales de
rapidez (en el camino) y cmaras digitales detectan un
acci dent e. La sever i dad del a c c i de nt e se d e b e de t e r mi na r
(a travs de las cmaras?). Con base en la severidad, el
sistema de supervisin debe contactar a la polica, los
bomberos o ambulancias; el trfico se debe redirigir; los
medios de comunicacin (radio) deben difundir
advertencias; y debe informrseles a los automviles
individuales (si estn equipados con sensores digitales o
comunicacin inalmbrica). Para lograrlo se debe tomar
una variedad de decisiones, con base en los datos
adquiridos a partir del sistema de supervisin (fusin de
datos).
Tecnol og a de empuj e. En aos pasados surgi un
problema y se desarroll tecnologa para resolverlo. Puesto
que el problema era evidente para muchas personas, el
mercado para la nueva tecnologa estaba bien definido.
En la actualidad, algunas tecnologas evolucionan como
soluciones que buscan problemas. Un mercado debe
empujarse para reconocer que necesita la nueva
tecnologa (por ejemplo, telfonos mviles, PDA).
Conforme las personas reconocen la necesidad, la
tecnologa se acelera, mejora y con frecuencia se
transforma conforme evoluciona la combinacin de
tecnologas.
Red y cas ual i dad. En este contexto, red implica
conexiones entre personas o entre personas e informacin.
Conforme crece la red, la probabilidad de sinergia entre
dos nodos de red (por ejemplo, personas, fuentes de
informacin) tambin crece. Una conexin fortuita (casual)
puede conducir a una inspiracin y a nueva tecnologa o
aplicacin.
So b r e c a r g a d e i nf or ma c i n. Un amplio ocano de
informacin est a disposicin de cualquiera con una
conexin de Internet. El problema, desde luego, es
encontrar la informacin correcta, determinar su validez y
luego traducirla en una aplicacin prctica en un mbito
de negocios o personal.
je! cdigo de tico
1CM/1EEE se puede
ncontroien
SMri.itsg.edu/
Codes/defoult.
3 2 . 7 L A R E S P O N S A B I L I D A D DE LA I N G E N I E R A DEL S OF T WA R E
La i ngeni er a del sof t war e ha evol uci onado en una profesi n r espet ada en el mbi -
t o mundi al . Como profesi onal es, los i ngeni eros de sof t war e deben regi rse por un
cdi go de t i ca que gu e el t r abaj o que real i zan y los pr oduct os que pr oducen. Una
fuerza de trabajo conj unt o ACM/IEEE-CS ha producido un C digo de tica y prctica
profesional para los ingenieros de software (versin 5.1). El cdigo [ACM98] afirma:
Los i ngeni eros de soft ware se deben compr omet er a s mi smos a convertir el anlisis, la
especificacin, el diseo, el desarrollo, la prueba y el mant eni mi ent o del soft ware en una
profesin beneficiosa y respet ada. En concordanci a con su compr omi so con la sal ud, la
TM
PDF Editor
seguri dad y el bi enest ar del pblico, l os i ngeni eros de sof t war e deben adher i r se a los si-
gui ent es Ocho Principios:
1. PBLICO. Los i ngeni eros de sof t war e deben act uar consi st ent ement e con el i nt ers del
pbl ico.
2. CLIENTES Y EMPLEADORES. Los i ngeni eros de sof t war e deben act uar en una forma que
benefi ci e l os i nt er eses de s us cl i ent es y empl eador es y sea consi st ent e con el i nt ers p-
blico.
3. PRODUCTO. Los i ngeni eros de sof t war e deben gar ant i zar que sus pr oduct os y modifi-
caci ones r el aci onadas sat i sfacen los mayor es es t ndar es profesi onal es posibles.
4. JUICIO. Los i ngeni eros de sof t war e deben mant ener la integridad y la i ndependenci a en
su juicio profesi onal .
5. GESTIN. Los gest or es y l deres de la ingeniera del sof t war e deben suscribir y pr omo-
ver un enf oque tico de la gest i n del desarrol l o y el mant eni mi ent o del sof t war e.
6. PROFESIN. Los i ngeni eros de s of t war e deben pr omover la i nt egri dad y la buena repu-
t aci n de la profesi n en una forma consi st ent e con el i nt ers pblico.
7. COLEGAS. Los i ngeni eros de sof t war e deben ser j ust os con s us col egas y apoyarl os.
8. COMPROMISO PERSONAL. Los i ngeni eros de sof t war e deben part i ci par en un apr endi -
zaj e per manent e en rel aci n con la prct i ca de su pr of esi n y pr omover un enf oque tico
par a s u prct i ca.
Aunque cada uno de est os ocho pri nci pi os es i gual ment e i mport ant e, apar ece un
t ema ms rel evant e: un i ngeni ero de sof t war e debe t rabaj ar en pro del i nt ers pbli-
co. En el mbi t o per sonal , un i ngeni ero de sof t war e debe at ener se a l as si gui ent es
reglas:
Nunca robar dat os par a benefi ci o personal .
Nunca distribuir o vender i nformaci n pat ent ada que haya obt eni do como
par t e de su t r abaj o en un proyect o de sof t war e.
Nunca dest rui r o modi fi car mal i ci osament e los pr ogr amas, archi vos o dat os
de ot ra per sona.
Nunca violar la pri vaci dad de un individuo, grupo u or gani zaci n.
Nunca atacar un si st ema por deport e o benefi ci o.
Nunca crear o difundir un virus o gus ano de comput ador a.
Nunca usar la t ecnol og a de comput aci n par a facilitar la di scri mi naci n o el
host i gami ent o.
Dur ant e la dcada pasada, ci ert os mi embr os de la industria del sof t war e han
cabi l deado por una legislacin prot ect ora que [SEE03]:
1. Permita a l as compa as liberar el sof t war e sin revelar los def ect os conoci dos.
2. Exent ar a los desar r ol l ador es de responsabi l i dad penal por cual esqui er a da-
os que resul t en debi do a di chos def ect os conoci dos.
TM
PDF Editor
3. Restringir a ot r os la revel acin de def ect os sin per mi so del desarrol l ador ori-
ginal.
4. Permitir la i ncorporaci n de sof t war e de "aut oayuda" dent r o de un pr oduct o
que pueda desact i var (va comandos remot os) la oper aci n del product o.
5. Exent ar a los des abol l ador es de sof t war e con "aut oayuda" de los da os en
caso de que el sof t war e lo desact i ve una t ercera per sona.
Al igual que con cualquier legislacin, el debat e con frecuenci a se centra en conflic-
t os polticos, no tecnolgicos. Sin embargo, mucha gent e (incluso est e autor) consi de-
ra que la legislacin prot ect ora, si se pr opone de maner a i nadecuada, ent ra en con-
flicto con el cdi go de t i ca de la i ngeni er a del sof t war e al exent ar i ndi r ect ament e
a los i ngeni eros de sof t war e de su responsabi l i dad para produci r sof t war e de alta
cal idad.
Ya han pasado 25 a os desde que se escribi la pri mera edicin de est e libro. Todava
me r ecuer do s ent ado en mi escritorio como un j oven profesor, escri bi endo el manus -
crito de un libro acer ca de una mat eri a de la que poca gent e se pr eocupaba e inclu-
so t odav a me nos r eal ment e compr end a. Recuerdo las car t as de r echazo de los edi-
t ores, qui enes ar gument aban (gentil, per o firmemente) que nunca habr a un mer ca-
do para un libro acer ca de "ingeniera del soft ware". Af or t unadament e, McGraw-Hill
decidi darl e una oport uni dad, 2 y el rest o, como dicen, es historia.
Dur ant e los pas ados 25 aos, est e libro ha cambi ado sust anci al ment e: en al can-
ce, en t amao, en estilo y en cont eni do. Al igual que la i ngeni er a del sof t war e, ha
creci do y (espero) madur ado con los aos.
Un enf oque de ingeniera par a el desarrol l o del sof t war e de comput ador a es ahor a
sabi dur a convenci onal . Aunque el debat e cont i na acer ca del "paradi gma correcto",
la i mport anci a de la agilidad, el gr ado de aut omat i zaci n y los mt odos m s efect i -
vos, los principios subyacent es de la ingeniera del sof t war e ahor a son acept ados a
lo l argo de la industria. Por qu, ent onces, se ha visto su ampl i a acept aci n sl o
r eci ent ement e?
La respuest a, creo, se encuent r a en la dificultad de la t ransi ci n t ecnol gi ca y el
cambi o cultural que la acompaa. Aun cuando la mayor a de las per s onas apreci an
la necesi dad de una disciplina de ingeniera para el sof t war e, se l ucha cont r a la i ner-
cia de la prctica pasada y se enf r ent an nuevos domi ni os de apl icacin (y los desa-
rrol l adores que t r abaj an en ellos), que parecen listos a repetir los errores del pasado.
2 En realidad, el crdito corresponde a Peter Freeman y Eric Munson, qui enes convencieron a McGraw-
Hill de que vala la pena intentarlo.
TM
PDF Editor
C AP T UL O 3 2 EL CAMINO POR RECORRER 939
Par a f aci l i t ar la t r a ns i c i n s e n e c e s i t a n mu c h a s c os a s : un p r o c e s o d e s o f t wa r e
gi l , a d a p t a b l e y s e ns i bl e ; m t o d o s m s e f e ct i vos ; h e r r a mi e n t a s m s p o d e r o s a s ;
me j o r a c e p t a c i n d e l os p r o f e s i o n a l e s y a p o y o de l os ge s t or e s ; y n o p e q u e a s d os i s
d e e d u c a c i n y "publ i ci dad". La i nge ni e r a del s o f t wa r e n o h a t e n i d o el be ne f i c i o de
la publ i ci dad ma s i v a , pe r o, c o n f o r me p a s a el t i e mpo, el c o n c e p t o s e v e n d e a s
mi s mo . De a l g u n a ma n e r a , e s t e l i br o e s un " a n u n c i o publ i ci t ar i o" p a r a la t e c nol og a .
El l e ct or t al v e z n o e s t d e a c u e r d o c on t od os l os e n f o q u e s d e s c r i t os e n e s t e l i bro.
Al g u n a s de l as t c n i c a s y o p i n i o n e s s o n c ont r ove r t i d a s ; o t r a s d e b e r n a j u s t a r s e pa r a
t r a b a j a r bi e n e n d i f e r e n t e s e n t o r n o s d e d e s a r r ol l o d e s o f t wa r e , s i n e mb a r g o , mi s i n-
c e r a e s p e r a n z a e s q u e Ingeniera del software. Un enfoque prctico h a y a d e l i n e a d o l os
p r o b l e ma s q u e s e e n f r e n t a n , d e mo s t r a d o la f u e r z a d e l os c o n c e p t o s d e la i nge ni e r a
del s o f t wa r e y of r e c i d o u n ma r c o de t r a b a j o de l os m t o d o s y h e r r a mi e n t a s .
Co n f o r me s e a v a n z a e n el si gl o xxi, el s o f t wa r e s e h a c onve r t i d o e n el p r o d u c t o
m s i mp o r t a n t e y e n u n a i ndus t r i a pr i mor di a l e n el e s c e n a r i o mu n d i a l . Su i mp a c t o e
i mp o r t a n c i a h a n t r a n s i t a d o u n l ar go c a mi n o . E i ncl us o, u n a n u e v a g e n e r a c i n d e
d e s a r r o l l a d o r e s d e s o f t wa r e d e b e e n f r e n t a r mu c h o s d e l os mi s mo s d e s a f o s q u e
e n f r e n t a r o n l a s p r i me r a s g e n e r a c i o n e s . Es pe r o q u e l as p e r s o n a s q u e e n f r e n t e n el
r e t o i n g e n i e r o s d e s o f t wa r e t e n d r n la s a bi dur a d e de s a r r ol l a r s i s t e ma s q u e
me j o r e n la c ond i c i n h u ma n a .
[ACM98] ACM/IEEE-CS joint Task Forc, Software Engineering Code of Ethics and Professional
Practice, 1998, disponible en ht t p: / / www. acm. or g/ ser vi ng/ se/ code. ht m.
[BECOl] Beck, K. el al., "Manifest for Agile Soft ware Development", ht t p: / / www. agi l emani f es-
t o. org/ .
[BOL91] Bollinger, T. y C. McGowen, "A Critical Look at soft ware Capability Evaluations", en
IEEE Software, julio de 1991, pp. 25-41.
[GIL961 Giib, T "What is Level Six?", IEEE Software, enero de 1996, pp. 97-98, 103.
[HOP90] Hopper, M. D., "Rattling SABRE, New Ways to Compet e on Information", en Harvard Bu-
siness Review, mayo-j uni o de 1990.
[PAU931 Paulk, M. el al., Capability Maturity Modelfor Software, Soft ware Engineering Institute,
Camegi e Mellon University, 1993.
(PCM03] "Technologies to Watch", en PC Maga/.ine, julio de 2003, disponible en ht t p: / / www. pc-
mag. com/ art i cl e2/ 0, 4149, 1130591 .OO.asp.
[PRE911 Pressman, R. S. y S. R. Herrn, Software Shock, Dorset House, 1991.
[SEE03) The Soft ware Engineering Ethics Research Institute, "UC1TA Updates", 2003, disponible
en ht t p: / / seer i . et su. edu/ def aul t . ht m.
3 2 . 1 . Obt ener una copia de las principales revistas de negoci os y noticias de esta s emana (por
ej empl o, Newsweek, Time, Business Week). Elaborar una lista de cada el ement o del artculo o
noticia que se pueda utilizar para ilustrar la i mport anci a del soft ware.
32. 2. Uno de los domi ni os ms rei dos de la aplicacin del soft ware son los si st emas y apli-
caci ones basados en Web. Estudiar cmo la gent e, la comuni caci n y el proceso tienen que evo-
lucionar para adapt ar se al desarrollo de las WebApps de "siguiente generacin".
TM
PDF Editor
940 P ARTE C I N C O TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
32. 3. Escribir una breve descripcin del ent or no de desarrollo de un i ngeni ero de soft ware
ideal hacia el 2010. Describir los el ement os del ent or no (hardware, soft ware y tecnologas de
comunicacin) y su i mpact o sobre la calidad y el t i empo en que llega al mercado.
32. 4. Revisar el est udi o de los model os de proceso i ncrement al es giles en el captulo 4.
Realizar una investigacin y recopilar artculos reci ent es acerca de la materia. Resumir las for-
t al ezas y debilidades de los par adi gmas gi l es con base en las experi enci as subr ayadas en los
artculos.
32. 5. Intntese desarrollar un ej empl o que comi ence con la recopilacin de dat os en brut o y
llvese a cabo la adquisicin de informacin, luego de conoci mi ent o y, por ltimo, de sabidura.
32. 6. Proporcionar ej empl os especficos que ilustren uno de los ochos principios ticos de la
ingeniera del soft ware menci onados en la seccin 32.7.
Los libros que estudian las t endenci as fut uras del soft ware y la comput aci n abarcan una
ampl i a vari edad de t emas tcnicos, cientficos, econmi cos, polticos y sociales. Sterling
(Tomorrow Now, Random House, 2002) recuerda que el progreso real rara vez e s or denado y efi-
ciente. Teich (Technology and the Future, Wadwort h, 2002) present a reflexivos ensayos acerca
del i mpact o social de la tecnologa y cmo la cultura cambi ant e da forma a la tecnologa.
Naisbitt, Philips y Naisbtt (High Tech/High Touch, Nicholas Brealey, 2001) seal an que muchas
per sonas se han "intoxicado" con la alta tecnologa y que la "gran irona de la era de la alta tec-
nologa es que la humani dad se ha esclavizado a los dispositivos que se supone brindaran liber-
tad". Zey (The Future Factor, McGraw-Hill, 2000) analiza cinco fuerzas que darn forma al destino
humano durant e est e siglo. Cant n (Techno/utures, Hay House, 1999) estudia cmo la t ecnol o-
ga t ransformar los negoci os en el siglo xxi. Robertson (The New Renaissance: Computis and
the Next Level of Civilization, Oxford University Press, 1998) argument a que la revolucin en la
comput aci n puede ser el avance individual m s significativo en la historia de la civilizacin.
Broderick (Spike, Forge, 2001) anal i za el i mpact o de las tecnologas emergent es. Dert rouzos
y Gates (HTwf Will be: tlow the New World of Information Will Change Our Uves, Harper-Business,
1998) ofrecen un estudio det al l ado de al gunas de las direcciones que pueden t omar las t ecno-
logas de la i nformaci n en las pri meras dcadas de est e siglo. Barnatt (Valueware: Technology,
Humanity and Organization, Praeger Publishing, 1999) present a un intrigante est udi o de una
"econom a de ideas" y cmo el valor econmi co se crear conf or me evolucionen los ci berne-
gocios. El de Negropont e (Being Digital, Alfred A. Knopf, 1995) fue un xito de vent as a medi a-
dos del deceni o de 1990 y cont i na ofreci endo una i nt eresant e visin de la comput aci n y de su
i mpact o global.
Kroker y Kroker (Digital Delirium, New World Perspectives, 1997) han editado una cont rover-
tida coleccin de ensayos, poemas y humor que exami nan el i mpact o de las t ecnol og as digita-
les sobre las per sonas y la soci edad. Brin (The TTansparent Society: Will Technology Forc Us to
Choose Between Privacyand Freedom?, Perseus Books, 1999) vuelven a revisar el cont i nuo deba-
te asoci ado con la inevitable prdida de privacidad personal que acompaa al creci mi ent o de
l as t ecnol og as de la i nformaci n. Shenk (Data Smog: Surviving the Information Olut,
HarperCollins, 1998) estudia los pr obl emas asoci ados con una "sociedad i nfest ada de i nforma-
cin" que se sofoca por el vol umen de i nformaci n que produce el soft ware.
Brockman [The Next Fifly Years, Vintage Books, 2002) y Miller y sus col egas (21st Centuty
Technologies: Promises and Perls of a Dynamic Future, Brookings Institution Press, 1999) han edi -
t ado una coleccin de artculos y ensayos acerca del i mpact o de la tecnologa sobre las est ruc-
t uras sociales, empresari al es y econmi cas. Para aquel l os i nt eresados en los t emas tcnicos,
Luryi, Xu y Zaslavsky (Future Trcnds in Microelectronics, Wiley, 1999) han editado una coleccin
de articulos acerca de las probabl es direcciones para el hardware de comput adora, con nfasi s
en las nanot ecnol og as. Hayzelden y Bigham (Software Agents for Future Communication
Systems, Springer-Verlag, 1999) han edi t ado una coleccin que anal i za las t endenci as en el
desarrollo de agent es de soft ware inteligentes.
TM
PDF Editor
C AP T UL O 3 2 EL CAMINO POR RECORRER 941
Conforme el soft ware se vuelve cada vez ms parte de la fabricacin de vi rt ual ment e t odas
las facet as de la vida moderna, la "cibertica" ha evol uci onado como un t ema i mport ant e de
estudio. Los libros de Spinello (Cyberethics: Morality and Law in Cybcrspace, Jones & Bartlett
Publishers, 2002), Halbert e Ingulli (Cyberethics, Sout h-West ern College Publishers, 2001) y Baird
y sus col egas (cyberethics: Social and Moral Issues in the ComputerAge, Promet heus Books, 2000)
consi deran el t ema en detalle. El gobierno est adouni dense ha publ i cado un vol umi noso repor-
te en CD-ROM (2 Ist Centuiy Guide to Cybercrime, Progressive Management , 2003) que consi de-
ra t odos los aspect os del cri men comput aci onal , conflictos de propiedad intelectual y el Centro
de Proteccin a la Infraest ruct ura Nacional (N1PC, por sus siglas en ingls).
Kurzweil (The Age of Spiritual Machines, When Computers Exceed Human Intelligcnce,
Viking/Penguin Books, 1999) ar gument a que, dent ro de 20 aos, la tecnologa de har dwar e ten-
dr la capaci dad de model ar por compl et o el cerebro humano. Borgmann (Holding on lo Reahty.
The Nature of Information al theTUrn of the Millenium, University of Chicago Press, 1999) ha escri
t o una i nt eresant e historia de la i nformaci n, y rast rea su papel en la t ransformaci n de la cul-
tura. Devlin (InfoSense: TUrning Information Into Knowledge, W. H. Freeman & Co., 1999) i nt ent a
darle sent i do al const ant e flujo de i nformaci n que bombar dea a la poblacin di ari ament e.
Gleick (Faster: The Acceleration offust About Eveiything, Pant heon Books, 2000) est udi a la tasa
si empre en aceleracin del cambi o tecnolgico y su i mpact o sobre t odos los aspect os de la vida
moderna. Jonscher (The Evolution ofwired Life: From the Alphabcl to the Soul-Catcher Chp-HOW
Infoi-mation Technologies Change Our World, Wiley, 2000) ar gument a que el pensami ent o y la
interaccin humanas t rasci enden la importancia de la tecnologa.
En Internet hay disponible una amplia variedad de fuent es de i nformaci n acerca de las
direcciones fut uras en las t ecnol og as rel aci onadas con el sof t war e y la ingeniera de soft ware
Una lista act ual i zada de referenci as en la World Wide Web se puede encont rar en el sitio Web
SEPA:
TM
PDF Editor
I NDI CE ANAL TI CO
ABC MPI, 37
Abst racci n, 252
Accesibilidad, 375
Acci ones, 25
Acopl ami ent o, 260, 482
niveles de, 329
medi ci n, 487, 489
Actividades, 24
Act i vi dades de sombrilla, 2 4, 2 8
Act i vi dades del mar co de t rabaj o,
2 4, 2 6
genri cas, 26
Actores, 173, 206
Agilidad, 79. Vase tambin
Proceso gil
definicin de, 79
fact ores humanos , 82
pri nci pi os de la, 80
Al macenami ent o de dat os, 278
Ambi ent e de t r abaj o, 368
mbi t o, 112
mbi t o del sof t war e, 651, 693
lmites, 693
Anlisis, 192. Vase tambin
Anlisis de los requi si t os
or i ent ado a obj et os, 201
pat r ones, 183 (Vase tambin
Pat rones)
reglas por experi enci a, 194
Anlisis de inventario, 909
Anlisis de peligros, 762
Anlisis de requisitos, 192. Vase
tambin Anlisis
obj et i vos del, 193
ingeniera Web, 545
Anlisis de t areas, 361
Anlisis del rbol de deci si n,
717
Anlisis del domi ni o, 194
Anlisis del flujo de t rabaj o, 364
Anlisis del usuari o, mt odos
para el, 361
Anlisis del valor de front era,
437, 624
Anlisis del valor ga na do (AVG),
742
Anlisis gr amt i co, 212
Anlisis Rel aci n-Navegaci n
(ARN), 589
Aplicaciones ba s a da s en Web.
Vase WebApps
rbol de dat os, 552
rbol de requi si t os de la cal i dad,
WebApps, 568
Arquet i pos, 289
Arqui t ect ura, 253
anl i si s de sensi bi l i dad, 294
apl i caci ones bas adas en Web,
587
de dat os, 140
descri pci n de la, 276
i mport anci a de la, 277
MVC, 589
Arqui t ect ura de aplicacin, 8-9
Arqui t ect ura de dat os, 140
Arqui t ect ura del agent e par a soli-
citud de obj et o, 890
Arqui t ect ura del cont eni do, 586
est ruct uras, 586
Asegur ami ent o de la calidad, 770
act i vi dades, 773
est ad st i co, 783
historia, 772
pl an, 791
Asegur ami ent o de la cal i dad del
sof t war e (SQA). Vase
Asegurami ent o de la calidad
Asoci aci ones, 232
Atributos, 222
At ri but os de los dat os, 198
Auditoria de confi guraci n, 813
apl i caci ones bas adas en
Web, 823
Auditoras, 806. Vase tambin
Auditora de configuracin
Aut ent i fi caci n, 631
Autoridad del cont rol del cambi o
(ACC), 810
Aut ori zaci n, 62
Base de dat os del proyect o, 800.
Vase tambin Depsi t o
Caj a de t i empo, 740
Cal endari zaci n, 724, 727, 736
concept os, 725
principios, 728
segui mi ent o, 739
var i anza, 743
Calidad
cont ext o de la ISBC, 896
cost o de la, 770
definicin de, 463, 769
det er mi nant es, 665
directrices par a la IWeb, 513
fact ores, 464
f act or es del ISO 9126, 465
medi ci n, 676
medi das de la, 677
Calidad de la concor danci a, 769
Calidad del di seo, 769
Calidad del sof t war e. Vase
Calidad
Calificacin de component es , 887
Cambi o, 6, 7, 114
mbi t o del, 929
i mpact o sobr e el sof t war e, 6
ori gen del, 797
Caos, 48
Capital del sof t war e, 22
Caract er st i ca, definicin de, 95
Cardinalidad, 199. 232
Casos de pr ueba
caract er st i cas de los, 420
deri vaci n, 427
Cat egor as de usuari o, definicin
de las, 521
Cent ro de t ransacci n, 306
Certificacin, 874
Clase
agr egada compuest a, 230
multiplicidad, 232
Cl ase- responsabi l i dad- col abora-
dor, 225. Vase tambin
Model ado CRC
Clases de anl i si s
apl i caci ones bas adas e n Web,
554
at ri but os, 221
caract er st i cas de las, 221
identificacin de las, 219
oper aci ones, 223
t i pos de, 219, 226-227
Cl ases de cont rol ador, 227
Cl ases de di seo, 259
caract er st i cas de las, 260
t i pos de, 259
Cl ases de ent i dad, 226
Cl ases de front era, 226
Clientes, 111
COCOMO II, 710
Codificacin, 631
Codificacin, principios, 123
Cdi go f uent e
a nivel de pr ogr ama, 493
medi ci n, 493
vol umen, 493
Cohesi n, 260, 483
medi ci n para la, 489
niveles de, 326
Col aboraci n, 83, 110
definicin de CRC, 228
Compl ej i dad, 482, 490
medi ci n, 491
Compl ej i dad ci cl omt i ca, 426
Component es
adapt aci n de, 888
bas ados en cl ases, 321
clasificacin de, 893
composi ci n de, 888
convenci onal es, 317, 340
943
TM
PDF Editor
944 NDICE ANALTICO
definicin de, 315, 889
descri pci n de, 892
ej empl o de di seo de, 321
i ngeni er a de, 890
nuevos, 696
reutilizables, 695
visin OO, 316
Compr obaci n de correcci n,
867, 868
Compr obaci ones subor di nadas,
869
Comput aci n ubi cua, 10
Comuni caci n, 26, 110
conj unt o de t areas, 112
del cliente, 523
ingeniera Web, 510, 523
pri nci pi os de la, 110
Concurrenci a, 286
Condi ci n post eri or, 834
Condicin previ a, 833
Confi guraci n del soft ware, 797
Conj unt o de base, 424, 425
Conj unt o de cambi os, 809
Conj unt o de t ar eas
comuni caci n, 112
comuni caci n con el cliente,
524
const rucci n, 124
definicin del, 27
despl i egue, 128
d i s e o , 122
model aci n del anlisis, 118
pl aneaci n, l i
pl aneaci n del proyect o, 693
pr uebas, 125-126
pr uebas de apl i caci ones bas a-
das en la Web, 611
r ef i nami ent o del, 737
s e l e c c i n . 7 3 2
Conoci mi ent o, 934
Consecuenci as i mprevi st as, 1
Consej o Airlie, 658
Co n s t r u c c i n , 2 6, 3 9 9
conj unt o de t ar eas, 124
i ngeni er a Web, 510
prct i ca, 122
Const rucci n basada en compo-
nent es, 8
Const r ucci ones est r uct ur adas,
340
Control de cal i dad, 770
Control de la vari aci n, 768
Control de la versi n, 805, 808
apl i caci ones bas adas en la
Web, 822
Control del cambi o, 810
flujo de t rabaj o, 811
t i pos de, 811
Cont rol ador vista del model o
(MVC), 589
Cont rol adores, 394
Correcci n, 677
compr obaci n de la, 868
condi ci ones, 869
verificacin de la, 867, 868
Cort afuegos, 631
Costo, var i anza, 744
Cost os de falla, 771
Cost os de prevenci n, 770
Cost os de val oraci n, 770
Cristal, 95
Curva de la baer a, 5
Curva Put nam-Ral ei gh-Norden,
730
Cur vas de falla, 7
Decisin de hacer la compr a, 717
Defect os, 775
Dependenci as, 232
Depsito, 801
caract er st i cas del, 804
cont eni do, 804
Depuraci n, 408
consi der aci ones psi col gi cas,
410
est rat egi as, 411
pr oceso de, 409
t ct i cas, 412
Desarrol l o bas ado en componen-
t es (DBC), 63, 886
Desarrol l o conduci do por la
caract er st i ca (DCC), 95
Desarrol l o del s of t war e adapt at i -
vo (DSA), 89
Desarrol l o or i ent ado a aspect os,
65
Descomposi ci n del pr obl ema,
652
Descomposi ci n funci onal , 362
Desgast e, 5, 6
Despliegue, 26
principios, 126
i nge ni e r a We b, 5 1 0
Despl i egue de la funci n de cali-
dad (QFD), 171
Deterioro, 6
Di agrama de cas o de uso, 150
Di agr ama de cl ase, 148, 223
Di agrama de cont ext o, 212
Di agrama de cont ext o de la arqui-
tectura (DCA), 288
Di agr ama de cont ext o del siste-
ma, 145
Di agr ama de despl i egue, 148
Di agr ama de est ado, 181, 216,
237, 555
utilizacin de pr uebas, 450
Di agr ama de flujo, 340, 341
Di agr ama de flujo de dat os
(DFD), 212, 299
Di agr ama de flujo del si st ema
(DFS), 146
Di agr amas de actividad, 148,
180, 208, 340
Di agr amas de rel aci n de ent i -
dad, 200
Di agr amas de secuenci a, 238
apl i caci ones bas adas en la
Web, 554, 555
Diseo, 245, 275, 314, 350
a nivel de component e, 314,
593
apl i caci ones bas adas e n la
Web, 566
arqui t ect ni co, 275, 585
at ri but os de calidad, 251
compr obaci n de la correc-
cin del, 868
conj unt o de t areas, 122, 252
directriz de calidad, 249
est t i co, 582
hi permedi a, 595
ingeniera del s of t war e de sal a
limpia, 867
i nt erfaces con el usuari o, 350
i nt erfaces par a apl i caci ones
bas adas en Web, 573
medi ci n, 479
proceso, 250
verificacin, 867
Di seo al nivel de component es ,
314
593
directrices, 326
pasos, 331
pri nci pi os bsi cos, 322
Di seo arqui t ect ni co, 275, 287
apl i caci ones ba s a da s en la
Web, 585
compl ej i dad del, 296
di agrama del flujo de dat os,
297
eval uaci n del, 294
r ef i nami ent o del, 290, 310
Di seo de dat os, 26
a nivel arqui t ect ni co, 278
a nivel de component e, 279
Di seo de i nt erfaz, 350
anl i si s del, 358
apl i caci ones bas adas e n la
Web, 573
flujo de t rabaj o, 368, 580
pat r ones par a el, 371, 372
pri nci pi os del, 351, 574
pr oceso del, 358
Di seo de la i nt erfaz con el
usuari o, 350
anl i si s de t ar eas, 361
anlisis del flujo de trabajo, 364
aspect os del, 372
eval uaci n del, 377
medi ci n, 492
pri nci pi os del, 352
TM
PDF Editor
NDICE ANALTICO
945
proceso, 358
pasos, 368
regl as de oro, 351
Di seo de navegaci n, 590
Di seo del cont eni do, 584
Di seo esttico, 572, 582
582
aspect os de configuracin, 582
Di seo grfico. Vase Di seo
est t i co
Disponibilidad, apl i caci ones
Distribucin, 286
Distribucin del esf uer zo, 732
Domi ni o semnt i co, 844
ECS, 803
Ecuaci n del soft ware, 712, 731
Eficacia en la remoci n de def ec-
tos (EED), 678
Eficiencia, 466
El aboraci n, 159, 652
El aboraci n de obj et os, 364
El aboraci n de t areas, 363
obj et os, 364
t ar eas, 363
El ement os de confi guraci n del
sof t war e (ECS), 800
El ement os de di seo
arqui t ect ni co, 264
component es , 266
dat os, 263
despl i egue, 267
i nt erfaz, 264
El ement os del si st ema, 134
Encubri mi ent o de component es ,
888
Ensayo, 774. Vase tambin
Revisiones
Ent rega i ncr ement al , 81
Envoltura, 888
Equi po de medi ci n, MDOO, 485
Equi pos
giles, 82, 649
coordi naci n, 650
cuaj ados, 83, 90, 647
organi zaci n propi a, 83
pr ogr amador e n jefe, 647
t i pos de, 646
Equi pos giles, 649
Equi pos de sof t war e. Vase
Equi pos
Errores, 775
correcci n de, 414
cost o relativo, 771
Escalabilidad, WebApps, 569
Escenari os del usuari o, 172
Especi fi caci n, 160
Especificacin const ruct i va, 837
Especificacin de caj a de est ado,
866
Especificacin de caj a negra, 865
Especi fi caci n de caj a t r anspa-
rent e, 866
Especificacin de la est ruct ura de
caj a, 864
Especificacin del cont rol (EC),
215
Especificacin del pr oceso (EP),
217
Especificacin formal, 842
Espect ro de la i nformaci n, 933
Estado, 833
Est ereot i po, 232
Estilos arqui t ect ni cos, 280
cent r ada en dat os, 281 -282
est rat i fi cada, 284
flujo de dat os, 281
l l amada y ret orno, 283
or i ent ada a obj et os, 284
t axonom a de los, 281
Est i maci n, 690, 696
715
basada en PF, 702
basada en LDC, 700
basada en el probl ema, 699
basada en el proceso, 704
descomposi ci n, 698
desarrol l o gil, 714
est i maci n, 713
model os, 710
model os emp ri cos, 709
observaci ones, 691
proyect os OO, 713
t cni cas aut omat i zadas, 709
uso- casos, 705
Est i maci n del proyect o. Vase
Est i maci n
Est i maci ones
reconciliacin, 708
Est ruct ura de anl i si s de t r abaj o
(EAT), 737
Estructura de superficie, 445
Est ruct ura pr of unda, 445
tica, 936
cdi go de, 936
consi der aci ones personal es,
937
Eval uaci n del riesgo, 752, 757
Event os, 215, 235
Evolucin del soft ware, 12
leyes de la, 13
Evolucin. Vase Evolucin del
sof t war e
Exposicin al riesgo, 757
cl cul o de la, 757
Extraccin de dat os, 278
Facilidad de mant eni mi ent o, 466,
677
Factibilidad, 693
Fact ores de cal i dad de McCall,
463
Fact ores humanos , 82
Factorizacin, pri mer nivel, 302
Fiabilidad, 465, 786
medi das de, 787
Filtros, 283
Flujo de t r ansf or maci n, 297
For mas de navegaci n (FdN), 591
For mat o de condi ci n- t r ansmi -
si n- consecuenci a (CTC),
759
Formul aci n, 510, 517
de pr egunt as, 519
recopi l aci n de requisitos, 520
Fuent e abi ert a, 10
Funci onal i dad, 465
Funci ones de ayuda, 373
Funci ones de caract eri zaci n,
884
Fundament os, 741
punt os de fijacin, 59
GCS, 797, 815
el ement os de la, 799
escenari o, 798
est ndar es, 824
est r at os del proceso, 807
funci ones, 805
gest i n del cambi o, 820
gest i n del cont eni do, 817
identificacin, 807
ingeniera Web,
medi ci n, 598
medi ci n del valor de nego-
cios, 538
model o de anl i si s, 580
obj et os de confi guraci n, 817
j erarqu a del usuari o, 546
proceso, 806
pr uebas de des empeo, 631
pr uebas de navegaci n, 625
pr uebas de seguri dad, 680
tipos de, 506
Gestin de la calidad, 767. Vase
tambin Asegur ami ent o de
la cal i dad
Gestin de la confi guraci n del
sof t war e. Vase GCS
Gest i n de la conf i gur aci n,
829. Vase tambin SCM
Gestin de requisitos, 161
Gestin del cambi o, 796. Vase
tambin GCS
815
Gestin del cont eni do, 817
Gestin del proyect o, 640
aspect os de la, 643
prct i cas crticas, 658
Gestin del proyect o de sof t war e.
Vase Gest i n de proyect o
Gestin del riesgo, 747
TM
PDF Editor
946 NDICE ANALTICO
Grfica de flujo, 423, 425
Grfica de la est ruct ura, 320
Grfica de lnea de tiempo, 737
Graficacin de la t ransacci n,
306
Graficacin de la t r ansf or maci n,
299
Graficacin del flujo de dat os,
298
Grfico de est ado, 336
Granul ari dad, 114
Grupo i ndependi ent e de pr ueba
(GIP), 386
GUI, 451
facilidad de uso, 620
j erarqu a de clase, 444
medi ci ones para, 494
mt odos OO, 441
model aci n del flujo de dat os,
436
model ado del flujo de t r ansac-
ci n, 436
model aci n del est ado finito,
435
model os de compor t ami ent o,
451
navegaci n, 610
opci ones, 400
particin, 447
part i ci ones de equi val enci a,
436
pat r ones, 455
principios, 124
pr oceso par a apl i caci ones
ruta bsi ca, 423
servicios de ayuda, 454
si st emas en t i empo real, 455
t c n i c a s , 4 1 8
Herrami ent as, 24
al macenami ent o de dat os,
2 7 9
anl i si s est ruct urado, 218
cal endari zaci n, 737
casos de uso, 78
DBC, 8 9 5
depuraci n, 413
desarrol l o de la i nt erfaz con el
usuari o, 376
desarrol l o gil, 98-99
di seo de casos de pr ueba,
439
est i maci n, 716
gest i n de la cal i dad, 791
gest i n del cambi o, 822
gest i n del cont eni do, 819
gest i n del proceso, 66
gest i n del proyect o, 659
gest i n del proyect o de i nge-
niera Web, 536
gest i n del riesgo, 763
i ngeni er a de los requisitos,
163
i ngeni er a i nversa, 916
i nt ermedi as, 321
LDA, 297
medi ci n de apl i caci ones
medi ci n del product o, 495
medi ci n del pr oc e s o y el pr o-
yecto, 676
mt odos formal es, 852
mi ner a de dat os, 279
model ado de dat os, 200
model ado del anl i si s en
UML, 239
model ado del proceso, 43
model ado del si st ema, 151
PDL, 344
pl aneaci n de pr uebas, 408
pr uebas de apl i caci ones bas a-
das en Web, 633
reest ruct uraci n, 918
RPN, 905, 906
si mul aci n del si st ema, 139,
140
sopor t e de la GCS, 814
UML/OCL, 339
Herrami ent as del soft ware, vase
Herrami ent as
Historias del usuari o, 85
HogarSeguro
rbol de dat os, 552
cart a ndice CRC, 226
cl ases de anlisis, 220, 554
cl ases de di seo, 261
confi guraci n de pant al l a, 371
DCA, 289
di agr ama de ACTIVIDAD, 209,
558
di agr ama de carriles, 210
di agr ama de cl ase, 181, 225
di agr ama de despl i egue, 268
di agr ama de est ado, 216, 237,
555
di agrama de flujo de dat os,
212, 213, 300
di agr ama de secuenci a, 238,
554
di agr ama uso- caso, 178, 208
di seo de component e, 344
EP, 217
es quema concept ual , 597
est ruct ura arqui t ect ni ca, 292,
306, 310
est ruct ura de la funci n de
seguri dad, 292
model o CRC, 231
narrat i va de pr ocesami ent o,
2 1 2
obj et os del cont eni do, 584
rel aci ones de cl ase, 290
USN, 592
uso- casos, 175, 205, 369, 549
HogarSeguro (cuadros al mar -
gen), 17, 57, 62, 111, 143,
170, 172, 177, 182, 185,
203, 207, 216, 224, 231,
258, 261, 265, 295, 305,
323, 328, 330, 354, 362,
388, 406, 412, 421, 426,
448, 477, 486, 521, 533,
549, 577, 622, 651, 668,
679, 702, 719, 742, 758,
782, 812
Hoj as de i nformaci n del riesgo,
757, 762
Idiomas, 270
IMCM, 29
adopci n de la, 32
model o cont i nuo, 30
met as, 32
model o por et apas, 32
ni vel es. de capaci dad, 30
prct i cas, 31
Impurezas, 775
Increment o. Vase I ncr ement os
del sof t war e
I ncr ement os de soft ware, 51, 81
I ndependenci a funci onal , 256
Indi cadores, 466
ndice de calidad de la est ruct ura
del di seo (1CED), 480
Informaci n, r epr esent aci n de
la, 933
Informe de cambi os, 810
Infraest ruct ura, tecnologa, 141
Ingeniera de requisitos, 155
t ar eas de la, 157
Ingeniera de sof t war e de sala
limpia, 64, 850
certificacin, 874
di ferenci aci n de caract er st i -
cas, 862
di seo, 867
especi fi caci n funci onal , 863
est rat egi a, 860
pr uebas, 872
Ingeniera del di seo, 245
Ingeniera del domi ni o, 883
Ingeniera del pr oces o de nego-
cios (1PN), 903
j erarqu a, 141
Ingeniera del product o, 142
Ingeniera del si st ema
j erarqu a, 136
visin mundi al , 136
Ingeniera del sof t war e
definicin de la, 23
de sal a limpia, 858
est rat os, 24
tica, 936
f ut ur o de la, 927
TM
PDF Editor
NDICE ANALTICO 947
prct i ca, 104. Vase tambin
Prctica
principios, 107
Ingeniera del sof t war e asi st i da
por comput ador a. Vase
Her r ami ent as
Ingeniera del sof t war e basada
en component es, 879, 880.
Vase tambin ISBC
Ingeniera di rect a, 911, 918
cl i ent e/ servi dor, 920
si st emas OO, 921
Ingeniera i nversa, 910, 912
dat os, 913-914
pr ocesami ent o, 914- 915
Ingeniera Web (IWeb), 502
act i vi dades del mar co de tra-
baj o, 509
caract er st i cas del equi po, 527
cas os de uso, 547
const rucci n del equi po, 528
desarrol l o en casa, 533
directrices de calidad, 513
di seo a nivel de componen-
te, 593
di seo arqui t ect ni co, 585
di seo de i nt erfaz, 573
di seo de navegaci n, 590
di seo del cont eni do, 584
est i maci n, 715
formul aci n, 517 (Vase tam-
bin Formul aci n)
GCS, 815
her r ami ent as, 508
las peor es prct i cas, 539
las mej or es prcticas, 512
mt odos, 507
medi ci n, 536
medi ci n del di seo, 598
model ado del anlisis, 544
pl aneaci n, 525
pr egunt as bsi cas, 511
proceso, 507, 508, 511
pr uebas, 604, 607, 612
subcont rat aci n, 530
Ingeniera Web, pi rmi de de dise-
o, 572
Inicio, 157
Inmedi at ez, 505
Inspecci ones, 774. Vase tambin
Revi si ones
Integridad, 678
Int ereses gener al es, 65
Interfaz con el usuari o, 349.
Vase tambin Int erfaz
anlisis, 359
car ga de memor i a, 353
consi st enci a, 354
cont eni do del despl i egue, 367
cont rol del usuari o, 351
i ngeni er a i nversa, 915
me cani s mos de cont rol , 579
model o de anl i si s, 356
pat r ones, 372
prot ot i po, 557, 580
pr uebas, 616
Int ermedi o (middleware), 322
Int ernaci onal i zaci n, 375
Invari ant e de dat os, 834
ISAC. Vase Her r ami ent as
ISBC, 879
anl i si s del cost o, 897
econom a de la, 895
proceso, 882
ISO 9000, 790
ISO 9001: 2000, 38, 790
es quema del, 790
Itinerario del proyect o. Vase
Cal endari zaci n
Jerarqu a del cont eni do, 552
j er ar qu as de usuari o, 546
Lenguaj e de di seo de pr ogr ama.
Vase LDP
Lenguaj e de especi fi caci n Z,
849
ej empl o, 849
not aci n, 850
Lenguaj e de restriccin de obj e-
t os (LRO), 338, 845
condi ci ones pr evi as/ post er i o-
res, 337
ej empl o de, 847
i nvari ant e, 338
not aci n, 846
visin general , 845
Lenguaj es de descri pci n arqui -
t ect ni ca (LDA), 296
Lenguaj es de especi fi caci n for-
mal, 844
Ley de Demt er, 261
Ley de Fiit, 576
Lder del equi po, 644
Lnea de base, 800
definicin de, 800
medi ci n, 681
Lista de pr obl emas, 169
Lista de verificacin
cal i dad del di seo de
WebApps, 570
validacin de requisitos, 161,
186
Lista de verificacin de el emen-
t os de riesgo, 750
Lista de verificacin par a la vali-
daci n de requisitos, 161
Manej o del error. 374
Manifiesto, desarrol l o de sof t wa-
re gil, 77
Manifiesto gil, 77
Mant eni mi ent o, 7, 12, 907
medi ci n del, 496
Mant eni mi ent o del sof t war e, 7,
12, 907. Vase tambin
Mant eni mi ent o
Marcos de t rabaj o, 270
Mat ri ces grfi cas, 430
MDHOO, 595
di seo abst r act o de i nt erfaz,
597
di seo concept ual , 595
di seo de navegaci n, 596
MDSD, 91
rei npeni er a, 908
Medicin (mtricas), 467
acopl ami ent o, 487
anl i si s de, 474
a nivel de component es , 488
536, 598, 674
ar gument os par a la, 680
at ri but os de la, 471
basada e n la funci n, 474
calidad, 677
calidad de la especi fi caci n,
477
cdi go fuent e, 492
cohesi n, 489
compl ej i dad, 491
defi ni ci n, 467
di seo, 479
di seo arqui t ect ni co, 479
est abl eci mi ent o, 684
et i quet a, 666
i nt erfaz con el usuari o, 492
linea de base, 681
mant eni mi ent o, 496
or i ent ada a la cl ase, 486
or i ent ada al t amao, 669
or i ent ada a obj et os, 481, 495,
673
or i ent ada a la oper aci n, 491
or gani zaci ones pequeas , 682
privada, 666
proceso, 663, 682
product i vi dad, 699
proyect o, 462, 472, 667
pr uebas, 494
pblica, 666
retos, 468
t i pos de, 471
Medicin de Halstead, 493
Medicin de la product i vi dad,
699
Medicin de lnea de cdi go
(LDC), 669
Medicin del sof t war e. Vase
Medicin
Medi ci ones CK, 482
Medi das, 467
directas, 668
indirectas, 668
TM
PDF Editor
948 I NDI CE ANAL I T I CO
MEIEP, 37
Mej orami ent o del proceso del
sof t war e (MPS), 664
estadstico, 667
Mel, 92
principios, 93
reuni ones, 94
Metfora, 577
Mtodo de anlisis del cambi o de
arqui t ect ura (MACA), 294
Mtodos, 24
Mtodos formal es, 64, 830
concept os, 830, 833
definicin de, 830
directrices de los, 852
prel i mi nares mat emt i cas,
837
Miniespecificaciones, 169
Mitigacin del riesgo, 760
Mitos, 14-15
de la gestin, 13-14
del cliente, 15
del desarrollador, 16
Modalidad, 200
Modelado, 26
ingeniera Web, 510
Modelado gil, 97
principios del, 97-98, 121
Modelado CRC, 225, 226
en PE, 86
Modelado de dat os, 197
Modelado de Hatley-Pirbhai, 144
Modelado del anlisis, 1S9, 191
bas ado en clases, 181, 21?
basado en escenari os, 179,
202
conj unt o de tareas, 118
cont eni do, 551
del comport ami ent o, 181, 234
enfoques, 196
ingeniera Web, 544
interaccin, 554
ori ent ado al flujo, 182, 211
principios, 117
Modelado del di seo, principios,
119
Modelado del flujo de control,
215
Modelado del si st ema, 137, 144
fact ores restrictivos, 138-139
UML, 147
Modelado estructural, 885
Modelo clsico del ciclo de vida,
50
Modelo CRC
col aboraci ones, 228
construccin, 225
responsabi l i dades, 227
revisin de directrices, 233
Modelo de amplificacin del
defecto, 776
Modelo de anlisis
apl i caci ones basadas en Web,
550
el ement os del, 179, 197
relacin con el di seo, 247
Modelo de comport ami ent o, 235
Modelo de desarrol l o concurren-
te, 60
Modelo de espiral, 58
pr obl emas con el, 59
Modelo de interaccin, 554
Modelo de la cascada, 50
probl emas con el, 51
Modelo del cont eni do, 551
Modelo del di seo, 247
di mensi ones del, 263
relacin con el anlisis, 247
Modelo DRA, 53
retrocesos, 54
Modelo funcional, 557
Modelos de proceso
gil, 81
cascada, 50
Cristal, 95
DAR, 53
DAS, 89
DCC, 95
det er mi nados por el riesgo, 58
desarrol l o concurrent e, 60
diferencias, 28-29
especializado, 63
espiral, 58
est ados de bl oqueo, 51
evolutivo, 54
incremental, 52
ISBC, 882
RPN, 904
Programaci n Extrema, 84
prescriptivo, 49
prototipos, 55
sala limpia, 859
Modelos evolutivos, 54-55
Modelos i ncrement al es, 52
Modelos iterativos, 55
Modelos prescriptivos, 49. Vase
tambin Modelos de proceso
fallas de los, 78
Modo de bombero, 747
Modularidad, 254
Monitoreo del riesgo, 760
MS, 107
Multiplicidad, 232
Navegacin, 559, 572
anlisis de la, 559, 561
preguntas, 560
semnt i ca, 591, 626
sintaxis, 590, 592, 625
Negociacin, 112, 160, 184
Nodos de navegaci n, 591
Notacin del di seo
basada en texto, 242
comparaci n de la, 345
grfica, 340
tabular, 342
Nueva econom a, 10
Objeto de los datos, 197
Obj et os de configuracin, 802
apl i caci ones basadas en Web,
817
Obj et os de cont eni do, 551, 584
Obtencin, 158, 652
Obt enci n de requisitos, 166
Ocul t ami ent o de i nformaci n,
256
OMG/CORBA, 889
Operaci ones, 223, 833
identificacin, 223
Operadores de conj unt o, 838
Operadores lgicos, 840
Orden del cambi o, 810
Organizacin propia, 83-84
Ori ent ado a obj et os
concept os, 201
estimacin, 713
segui mi ent o del proyecto, 741
Paquet es, 234
Paquet es de anlisis, 234
Paradi gma OPM, 469
Particin, 652
de equivalencia, 435, 623
Patrones, 108, 119, 124
anlisis de, 183
arquitectnicos, 280, 281, 284
di seo, 254
di seo de hi permedi a, 594
depsi t os de hi permedi a, 595
interfaz con el usuario, 371
plantilla de pat r ones para el
anlisis, 183
plantilla para los, 37
proceso, 36
pruebas, 455
Pat rones arquitectnicos, 280
refi nami ent o de los, 287
tipos de, 586
Pat rones de di seo, 254. Vase
tambin Pat rones
descripcin de los, 269
plantillas, 269
uso de, 270
Pat rones del proceso, 34
ej empl o de, 36
PE. Vase Programaci n Extrema
(PE)
Persistencia, 286
Personal, 641, 930
aspect os de gestin, 641
relacin con el esfuerzo, 729
usuarios, 643
PERT/CPM, 736
Peso del vnculo, 429, 433
Plan de SQA, 791
TM
PDF Editor
NDICE ANALTICO
949
Pl aneaci n, 26, 655
Pl aneaci n de pr uebas, 381, 608
Pl aneaci n del ciclo adapt at i vo
(PCA), 90
Pl aneaci n del proyecto, 692
Plan RSGR, 761, 763
Plantilla model o del si st ema, 145
Portabilidad, 465
Prctica (ingeniera del soft ware),
103-132
Pregunt as, libres de cont ext o, 55
Primitivismo, 260, 482
Principio abi er t o- cer r ado (PAC),
322
Principio de cer r adur a comn
(PCC), 325
Principio de equivalencia de la
reutilizacin (PER), 325
Principio de inversin de la
dependenci a (PS1), 324
Principio de Paret o, 125
Principio de reutilizacin comn
(PRC), 325
Principio de segr egaci n de inter-
fase (PS1), 324
Principio de sust i t uci n de Liskov
(PSL), 324
Principio W5HH, 115, 657
Principios, 113, 655
anlisis, 117
codificacin, 123
comuni caci n, 110
despl i egue, 126
di seo, 119-120
i ngeni er a del sof t war e, 107
IWeb, 511, 525
model ado gil, 121
pl aneaci n, 113
pr uebas, 124
Proceso, 24
aspect os de la gest i n del pr o-
yect o, 653
aspect os de gest i n, 642
descomposi ci n, 654
di recci ones fut uras, 931
eval uaci n, 37
mar co de t rabaj o, 24
medi ci n, 663
rel aci n con el product o, 43
Proceso gil, 81
poltica del, 81
Pr oceso del s of t war e en equi po
(PSE)
act i vi dades del mar co de t ra-
baj o, 41
obj et i vos, 40
escri t os, 41
Proceso del sof t war e per sonal
(PSP), 39
Proceso uni fi cado (PU), 67
fases, 68
historia del, 67
pr oduct os del t rabaj o, 71
Pr ocesos de negoci os, 904
Product o, 651
aspect os de gest i n, 642
del t rabaj o, 173
relacin con el pr oceso, 43
Product o esenci al , 52
Pr ogr amaci n est r uct ur ada, 340
Pr ogr amaci n ext r ema (PE), 84
act i vi dades del mar co de tra-
baj o, 85
codi fi caci n, 87
di seo, 86
pl aneaci n, 85
pr uebas, 88
Pr ogr amaci n par, 87
Prototipos, 55
pr obl emas con los, 57
Proyect os
di ferenci as, 526
est i maci n, 690
medi ci n OO, 673
medi ci n para, 667
pr obl emas, 656
segui mi ent o, 739
t i pos de, 733
Proyect os de sof t war e. Vase
Proyect os
Prudenci a, 934
Prueba bet a, 405
Prueba de caj a negra, 422, 433
Prueba de ruta bsi ca, 423
ej empl o de, 428
Prueba de uni dad, 88
Pr uebas
al eat ori as, 48
a nivel de component e, 610,
623
604
arqui t ect uras convenci onal es,
386
arqui t ect uras OO, 388
bas adas en el uso, 403
bas adas en escenar i os, 444
bas adas en faltas, 443
bas adas en grfi cas, 434
bas adas en la cl ase, 447
bas adas en ligas, 403
bas e de dat os, 613
caract er st i cas genri cas, 383
conj unt o de t ar eas, 125
cont eni do, 610, 612
cl i ent e/ servi dor, 452
criterio de compl et i t ud, 389
de cl ase mltiple, 449
de uso est ad st i co, 873
document aci n, 454
especi al i zadas, 452
est rat egi as, 383, 390
est r at egi as OO, 402
est ruct ura de cont rol , 430
est ruct ura pr of unda, 446
est ruct ura de superfi ci es, 446
exhaust i vas, 422
i ngeni er a del sof t war e de sal a
limpia, 872
i nt erfaces, 610, 616, 617, 619
lmites, 437
tabla ort agonal , 438
Pruebas a la confi guraci n
611, 628
del l ado del cliente, 629
del l a d o del s e r vi d or , 6 2 8
Pr uebas a la uni dad, 388, 392
ambi ent e par a las, 394
consi der aci ones de las, 392
pr ocedi mi ent os para las, 393
Pruebas a las bases de dat os, 613
Pr uebas al flujo de dat os, 431
Pr uebas al si st ema, 388, 406
Pr uebas alfa, 405
Pr uebas de acept aci n, 88
Pr uebas de agr upami ent o, 404
Pr uebas de bucle, 431
Pr uebas de caj a bl anca, 423
Pr uebas de carga, 633
Pr uebas de compat i bi l i dad, 622
Pr uebas de condi ci n, 431
Pruebas de des empeo, 408, 631
Pr uebas de humo, 399
Pr uebas de i nt egraci n, 388, 394
Pr uebas del cont eni do, 612
Pr uebas de t abl a ort ogonal , 438
ascendent es, 398
document aci n, 400
descendent e, 396
est udi o, 395
humo, 395
Pr uebas de navegaci n, 625
Pr uebas de recuperaci n, 407
Pr uebas de regresi n, 398
Pr uebas de ruta, 624
Pr uebas de sof t war e. Vase
Pr uebas
Pr uebas de t ensi n, 408, 633
Pr uebas de validacin, 388, 404
criterios, 404
principios, 123
Pruebas est ad st i cas de uso, 873
PSE, 40
PSP, 39
Punt os de fijacin, 59
Punt os de funci n, 474, 670
cmput o de, 476
l enguaj es de pr ogr amaci n,
672
reconci l i aci n, 671
Punt os de la est ruct ura, 885
anl i si s del cost o, 897
caract er st i cas de los, 885-886
Punt os de obj et o, 711
TM
PDF Editor
9 5 0 NDICE ANALTICO
Punt os de prioridad, 165
Punt os vitales, 784-785
Recopilacin de requisitos
colaborativa, 167 [Vase tam-
bin Obtencin)
directrices, 167
equipo, 168
Recopilacin de requisitos,
WebApps, 520
Recursos ambi ent al es, 696
Recursos del proyecto, 694
Recursos humanos, 695
Red de actividad, 735
Red de t areas, 735
Reestructuracin
de cdigo, 917
de datos, 917
Reestructuracin de cdigo, 911
Reestructuracin de datos, 911
Reestructuracin de document os,
910
Refabricacin, 87, 258
Refinamiento, 257
Refinamiento paso a paso, 257
Regla 40-20-40, 732
Reingeniera, 906
econom a de la, 923
model o del proceso, 908
Reingeniera del proceso de
negoci os (RPN), 903
model o del proceso, 904
Relaciones del cont eni do, 554
Reportes de est ado, 814
Requisitos de los aspect os, 65
Requisitos, validacin de los, 186
Re s g u a r d o s , 3 9 4
Responsabilidades, definicin de
CRC, 227
Retraso, 93
Reutilizabilidad, 64
Reutilizacin, 8, 109, 269, 325,
894
anlisis y di seo, 891
medi o ambi ent e, 894
Revisin de la confi guraci n, 405
Revisiones, Vase tambin
Revisiones t cni cas forma-
les (RTF)
basadas en muest ra, 781
conservaci n del registro, 779
directrices, 780
junta de reuni n, 778
report e general, 779
reportes, 779
Revisiones basadas en muest ra,
781
Revisiones del soft ware, 774.
Vase tambin Revisiones
Revisiones t cni cas formal es
RTF), 250, 577, 774. Vase
teimbin Revisiones
Riesgo, 114
component es, 753
est rat egi as, 747
format o CTC, 759
definicin de, 748
cont rol adores, 753
identificacin, 750
impacto, 754, 757
planeacin, 759
proyeccin, 754
refi nami ent o del, 759
tipos de, 748
Rotulacin, me ns y comandos,
374
Ruta crtica, 736
Rutas de accin, 306
Rutas i ndependi ent es, 424
Salvaguarda del soft ware, 762,
788
Segui mi ent o de conflictos, 808
Segui mi ent o de la dependenci a,
805
Segui mi ent o de requisitos, 805
Segui mi ent o del proyecto, IWeb,
535
Seguridad, 407, 506
apl i caci ones basadas en la
Web, 569
pr uebas de, 407, 630
Servicios ot orgados, 807
Sigma seis, 785
Similaridad, 482
Simulacin del si st ema, 139
Sistema
definicin de, 134
el ement o macro, 135
Sistema de versi ones concurren-
t es (SVC), 809
Si st emas basados en componen-
tes, 880
Sitios Web, bien di seados, 583
Soft ware
apl i caci ones heredadas, 11
caract er st i cas del, 5
definicin de, 4
mi t os acerca del, 14
papel evolutivo del, 2
pr egunt as fundament al es, 4-5
referenci as histricas, 4
Soft ware de ingeniera y cientfi-
co, 9
Soft ware de Inteligencia
Artificial, 9-10
Soft ware de lnea de product o, 9
Soft ware de sistema, 8
Soft ware heredado, 11
calidad del, 12
Software, cat egor as de aplica-
cin, 8- 9
Soft ware empot rado, 9
Solicitud de cambio, 810
Solucin de probl emas, 106
Solucin pico, 86
Soporte, 126
SPICE, 37
Sprint, 94
Subcont rat aci n, 718
ingeniera Web, 530
Sucesi ones, 841
Suficiencia, 482
Susceptibilidad a las pruebas,
caract er st i cas de la, 420
Tabla de decisin, 342
Tabla de recursos, 739
Tabla de riesgo, 754
Tablas de rastreabilidad, 162
Tamao, 482
Tamao, proyect os de soft ware,
698
Tecnologa del proceso, 42
Tecnologas, futuro, 929, 935
Tiempo de respuest a, 373
Ti empo en el mercado, aplicacio-
nes basadas en Web, 569
Tiempo medi o de reparaci n
(TMDR), 787
Tiempo medi o ent re fallas
(TMDF), 787
Toxicidad del equi po, 648
Transaccin, 298
Tubos, 282
UML
di agrama de actividad, 148,
180 209, 335
di agrama de carriles, 209, 366
di agrama de caso de uso, 150,
178, 547
di agrama de col aboraci n,
332
di agrama de clase, 150, 180
di agrama de despliegue, 148,
268
di agrama de est ado, 181, 216,
247
di agrama de model aci n del
si st ema, 148
di agr amas de secuenci a, 238
el aboraci n del component e,
318
est ereot i po, 233
grfica de est ado, 336
OCL, 337, 845
paquet es, 234
represent aci ones de interfaz,
265, 333
Unidad semnt i ca de navegaci n
(USN), 592, 626
Uso, casos de, 360
anlisis de tareas, 361
apl i caci ones basadas en la
Web, 524, 547, 554
TM
PDF Editor
NDICE ANALTICO
desarrol l o del, 173
escri t ura, 202
identificacin de event os, 235
medi ci n, 674
pr egunt as acer ca del, 174-
175
Usuario, 26, 643
identificacin del, 173
punt os de vista mltiples, 173
Usuari os finales, 111
Validacin, 161, 384
Velocidad del proyect o, 86
Verificacin, 384
V ncul os de navegaci n, 591
Volatilidad, 483
WebApps, 9, 504
at ri but os de las, 504
TM
PDF Editor
NDI CE DE SI GLAS MS COMUNE S
EN I NGENI ER A DEL SOFTWARE
Siglas espaol / i ngl s
Trmino equivalente en espaol
ABC MPI (apreciacin basada en el CMM para el mej o-
r ami ent o del pr oceso interno) 37
ACC (autoridad del control del cambi o) 810
ADP (paradi gma de di seo abstracto) 883
AECO (acopl ami ent o ent r e cl ases de objetos) 485
AG2D (anlisis geomt r i co bidimensional) 701
AG3D (anlisis geomt r i co tridimensional) 701
AIE (archivos de i nt erfaz ext ernos) 475
ALI (archivos lgicos internos) 474
AOO (anlisis or i ent ado a objetos) 201
APD (acceso pbl i co a dat os) 495
APH (rbol de profundi dad de la herencia) 484
ARN (anlisis rel aci n-navegaci n) 560
AVG (anlisis del valor ganado) 742
AVL (anlisis de val ores limite) 437
CAD (diseo asi st i do por comput adora) 700
CCYD ( component es comerci al es ya desarrol l ados)
695
CDL ( component es comerci al es de lnea) 881
CE (consul t as ext ernas) 474
CN (cont ador numri co) 6?6
CO (complejidad de la operaci n) 491
COCOMO (model o const ruct i vo de costos) 710
COM (modelo de obj et os par a component es) 889
CORBA (arquitectura comn de distribucin de objetos)
889
CPTC (costo pr esupuest ado para el t rabaj o
cal endari zado) 743
CPTR (costo pr esupuest ado del t r abaj o realizado) 743
CRC (cl ase-responsabi l i dad-col aborador) 225
CRTR (costo real del t r abaj o real i zado) 743
CTC (condi ci n-t ransi ci n-consecuenci a) 759
DAS (desarrollo adapt at i vo de soft ware) 89
DBC (desarrollo bas ado en component es) 63
DBMS (gestor de bases de dat os) 614
DCA (diseo de cont ext o arquitectnico) 288
DCBD (descubri mi ent o de conoci mi ent o en base
de dat os) 278
DCC (desarrollo conduci do por caractersticas) 95
DCS (di agrama de cont ext o del si st ema) 145
DFD (di agrama de flujo de dat os) 211, 298
DFS (diagrama de flujo del si st ema) 146
DIE desviacin intencional de las especificaciones) 784
DU document aci n i mpreci sa o incompleta) 784
952
Trmino equivalente en ingls
CMM (based apprai sal for internal procces i mprovement
CBA 1PI)
CCA (change control authority)
ADP (abstract desi gn paradi gm)
CBO (coupling bet ween obj ect classes)
2DGA (t wo-di mensi onal geomet ri c analysis)
3 DGA (t hree-di mensi onal geomet r i c analysis)
El Fs (external i nt erface files)
ILFs (internal logical files)
OODA (object-oriented domai n analysis)
PAD (public acces s t o dat a member s)
DI T (depth of t he i nheri t ance tree)
RNA (relationship-navigation-analysis)
EVA (earned val u analysis)
BVA ( boundar y val u anal ysi s)
CAD (comput er aided design)
COTS (comercial off-the-shelf)
COTS (comercial off-the-shelt)
EQs (external inquiries)
NC (numerical control)
OC (operation complexity)
COCOMO (costructive cost model)
COM (component obj ect model)
CORBA ( common obj ect request broker architecture)
BCWS (budgeted cost of wor k schedul ed)
BCWP (budgeted cost of work performed)
FTR (formal technical reviews)
ACWP (actual cost of work performer)
CTC (condi t i on-t ransi t i on-consequence)
ASD (adapt at i ve sof t war e devel opment )
CBD (component based devel opment )
DBMS (dat abase manager system)
ACD (architecture cont ext di agram)
KDD (knowl edge di scovery in dat abases)
FDD (feature driven devel opment )
SCD (system cont ext di agram)
DFD (data flow di agram)
SFD (system flow di agram)
I DS (intentional deviation from specifications)
IID (i naccurat e or i ncompl et e documenl at i on)
TM
PDF Editor
NDICE DE SIGLAS MS COMUNES EN INGENIERA DEL SOFTWARE
9 5 3
DMADV (definir, medir, analizar, di sear y verificar) 786
DPR (di seo para la reutilizacin) 891
DRA (desarrollo rpi do de aplicaciones) 53
DSOA (desarrollo de sof t war e ori ent ado a aspect os) 65
DU (cadena definicin-uso) 431
EAT (estructura de anl i si s del trabajo) 737
EC (especificacin de control) 215
ECS (el ement os de confi guraci n del soft ware) 800
EDI (ent ornos de desarrol l o integrado) 413
EE (ent radas ext emas) 474
EED (eficacia en la eliminacin de defect os) 677
EIE (especificaciones i ncompl et as o errneas) 784
EIS (ent orno de ingeniera del soft ware) 696
ELD (error de la lgica del di seo) 784
EP (especificacin de proceso) 217
EPI (equipos de pr oduct o integrado) 40
ER (exposicin al riesgo) 757
ERD (errores de la represent aci n de l os dat os) 784
FA (factor de acopl ami ent o) 487
FCM (falta de cohesi n en mt odos) 485
FCP (funcin de control perifrica) 701
FDN (formas de navegaci n) 591
FIN (dependenci a hacia dent ro) 495
FIUC (facilidades de i nt erfaz del usuari o y control) 701
FPGC (facilidades de present aci n grfica de comput a-
dora) 701
GBD (gestin de bas e s de dat os) 701
GCS (gestin de la configuracin del soft ware) 796
GI P (grupo i ndependi ent e de prueba) 386
GUI s (interfaces grfi cas de usuario) 452
I CED (ndice de calidad de la est ruct ura de di seo) 480
ICI (interfaz de component e i nconsi st ent e) 784
ICOA (ingeniera de component es ori ent ada a aspect os)
65
IDCO (ndice de de s e mpe o del costo) 744
IHC (interfaz hombr e- comput ador a ambi gua o i nconsi s-
tente) 784
IMCM (integracin del model o de capaci dad de madu-
rez) 29
IMS (ndice de madur ez del soft ware) 496
IPA (interfaz de pr ogr amaci n de la aplicacin) 887
IPN (ingeniera de pr ocesos de negoci os) 140
IR (ingeniera de requisitos) 157
ISBC (ingeniera del software basada en componentes) 879
ISO (organizacin i nt ernaci onal de est andari zaci n) 38
IU (interfaz con el usuari o) 264
KLDC (miles de l neas de cdigo) 669
LDA (lenguaje de descri pci n arquitectnica) 296
LDP (lenguaje de di seo de programas) 217
MA (model ado gil) 97
MACA (mt odo de anlisis de compensaci n para la
arquitectura) 294
MAD (mdul os de anl i si s de di seo) 701
MCC (mala i nt erpret aci n de la comuni caci n del clien-
te) 784
MDHOO (mt odo de di seo hi permedi a or i ent ado a
objetos) 595
DMADV (define, measure, anal yze, design, and verity)
DFR (design for reuse)
RAD (rapid application devel opment )
AOSD (aspect - ori ent ed sof t war e devel opment )
DU (definition-use chain)
WBS (work br eakdown structure)
CSPEC (control specification)
s e i s (software confi gurat i on tems)
I DEs (integrated devel opment envi ronment )
EIs (external inputs)
DRE ideffect removal efficiency)
I ES (incomplete or er r oneous specification)
SEE (soft ware engi neer i ng envi ronment )
EDL (error in desi gn logic)
PSPEC (process specification)
IPT (integrated product t eams)
RE (risk exposure)
ERD (error in dat a represent at i on)
CF (coupling factor)
LCOM (lack of cohesi on in met hods)
FCF (peripheral control function)
WoN (ways of navigating)
FIN (fan-in)
UICF (user i nt erface and control facilities)
CGDF (comput er graphi cs display facilities)
DBM (dat abase management )
SCM (soft ware confi gurat i on management )
ITG (i ndependent test group)
GUI s (graphical user interfaces)
DSQI (design st ruct ure quality ndex)
ICI (inconsistent component interface)
AOCE (aspect -ori ent ed component engi neeri ng)
CPI (cost per f or mance index)
HCI ( human- comput er interaction)
CMMI (capability mat uri t y model integration)
SMI (software mat uri t y index)
API (application pr ogr ammi ng interface)
BPE (business pr ocesses engi neeri ng)
RE (requi rement s engi neeri ng)
CBSE (component based sof t war e engi neeri ng)
ISO (international organi zat i on for st andardi zat i on)
UI (user interface)
KLOC (t housands lines of code)
ADLs (architectural description l anguages)
PDL (program desi gn l anguage)
AM (agile modeling)
ATAM (architecture t rade-off anal i si s met hod)
DAM (design anal ysi s modul es)
MCC (mi si nt erpret at i on of cust omer communi cat i on)
OOHDM (obj ect -ori ent ed hi permedi a desi gn met hod)
TM
PDF Editor
9 5 4 NDICE DE SIGLAS MS COMUNES EN INGENIERA DEL SOFTWARE
MDSD (mt odo de desarrol l o de si st emas dinmicos) 91
ME (met as especficas) 31
MEI EMP ( mt odo de eval uaci n de la 1MCM es t ndar
par a el mej or ami ent o del proceso) 37
MEPS (mejora est ad st i ca del pr oces o de soft ware) 667
MFH (mt odo del fact or de herenci a) 487
MG (met as genri cas) 32
MIS (miscelneo) 784
MMCGP (model o de madur ez de la capaci dad de gest i n
de personal ) 641
MPC ( mt odos ponder ados por clase) 484
MRC (mt odo de ruta critica) 736
MVC (model o-vi st a-cont rol ador) 589
NCR (nmero de cl ases raz) 495
NCSC (nuevos compone nt e s de sof t war e comerci al es)
63
NDD (nmero de descendi ent es) 485
NOA (nmero de oper aci ones aadi das) 488
NPO (nuevos punt os objeto) 711
NPOp r o m ( nmer o pr omedi o de par met r os de la oper a-
cin) 492
OCI (orden de cambi o de ia ingeniera) 810
OCL (l enguaj e de restriccin de obj et o) 332
OMG (grupo de gest i n de objetos) 889
OPM ( obj et i vo/ pr egunt a/ mt r i ca) 470
ORB (distribuidor de objetos) 889
PAC (principio abi ert o-cerrado) 322
PCC (principio del cierre comn) 325
PCR (principio comn de la reutilizacin) 325
PDL (lenguaje de di seo de pr ogr amas) 343
P E {prcticas especi fi cas) 31
PER (principio de equi val enci a ent r e reutilizacin y ver-
sin) 325
PERT (tcnica de evaluacin y revisin de programa)
736
PF (punt o de funcin) 474
PG (prcticas genricas) 32
PI D (principio de inversin de la dependenci a) 324
PI E (prueba i ncompl et a o errnea) 784
PNR (curva Put nam-Norden-Rayl ei gh) 730
POA (programaci n or i ent ada a aspect os) 65
PSE (proceso de sof t war e en equi po) 40
PSI (principio de segr egaci n de la interfaz) 324
PSL (principio de sust i t uci n de Liskov) 324
PS P (proceso de sof t war e personal ) 39
PU (proceso unificado) 67
PYP (porcent aj e pbl i co y protegido) 495
QFD (despliegue de la funci n de calidad) 171
RPC (respuesta par a una clase) 485
RSGR (reduccin, supervi si n y gest i n del riesgo) 761
RTF (revisin t cni ca formal) 774
SCCT (sistema de clasificacin de cinta t ransport adora)
145
SE (salidas ext ernas) 474
SEI (instituto de i ngeni er a del soft ware) 29
SQA (garant a de la cal i dad del soft ware) 767
SQL l enguaj e de consul t as est ruct urado) 614
DSDM (dynamic syst ems devel opment met hod)
SG (specific goals)
SCAMPI (st andard CMMI as s es s ment met hod for pr ocess
i mprovement )
SSPI (statistical sof t war e pr ocess i mprovement )
MIF (method i nheri t ance factor)
GG (generic goals)
MI S (mi scel l aneous)
PM- CMM (people ma na ge me nt capability mat uri t y
model )
WMC (weighted met hods per class)
CPM (critical pat h met hod)
MVC (model -vi ew-cont rol l er)
OR (number of root cl asses)
NCSC (commerci al off-t he-sel f (COTS) sof t war e compo-
nent)
NOC (number of children)
NOA (number of oper at i ons added by a subcl ass)
NOO (number of oper at i ons overri dden by subcl ass)
NPa v g (average numbe r of par amet er s per operat i on)
ECO (engi neeri ng change order)
OCL (object const rai nt l anguage)
OMG (object ma na ge me nt group)
GQM ( goal / quest i on/ met r i c)
ORB (object request broker)
OCP (open cl osed principie)
CCP (common cl osure principie)
CRP (common r euse principie)
SP (specific practices)
REP (release r euse equi val ency principie)
PERT (program eval uat i on and revi ew t echni que)
FP (function points)
GP (generic practices)
DI P (dependency inversin principie)
IET (i ncompl et e or er r oneous testing)
PNR (Put nam-Norden-Rayl ei gh curve)
AOP (aspect -ori ent ed pr ogr ammi ng)
TSP (team sof t war e process)
I SP (interface segr egat i on principie)
LSP (Liskov subst i t ut i on principie)
PSP (personal sof t war e process)
UP (unified process)
PAP (percent public prot ect ed)
QFD (quality funct i on depl oyment )
RFC (response for a class)
RMMM (risk mitigation, moni t ori ng and management )
CLSS (conveyor line sort i ng syst em)
EOs (eos (external out put s)
SEI (soft ware engi neer i ng institute)
SQA (soft ware quality assur ance)
SQL (structured query l anguage)
TM
PDF Editor
NDICE DE SIGLAS MS COMUNES EN INGENIERA DEL SOFTWARE 9 5 5
SVC (sistema de ver si ones concur r ent es) 809
TC ( t amao de la cl ase) 488
TI (tecnologa de la i nformaci n) 278
TLP (error de la t raducci n del di s eo al l enguaj e de pro-
gramaci n) 784
TMC (tiempo medi o de cambi o) 677
TMDF y TMDR (t i empo medi o de falla y t i empo medi o
de reparaci n) 787
TMEF (t i empo medi o ent re fallas) 787, 874
TMR (t i empo medi o de reparaci n) 407
TOp r o m ( t amao pr omedi o de operaci n) 491
UML (l enguaj e de model ado uni fi cado) 68
USN (unidad semnt i ca de navegaci n) 591
VAD (visin abst r act a de dat os) 597
VC (vari anza del costo) 744
VEP (violacin de los es t ndar es de pr ogr amaci n) 784
VyV (verificacin y validacin) 384
CVS (concurrent ver si ons syst em)
CS (class size)
IT (i nformat i on t echnol ogi es)
PLT (error pr ogr ammi ng l anguage t ransl at i on)
MTTC ( mean- t i me- t o- change)
MTTC & MTTF ( mean- t i me- t o- char ge) and ( mean-
t i me-t o-fai l ure)
MTBF ( mean t i me bet ween failures)
MTTR (mean t i me to repair)
OSa v (average operat i on size)
UML (unified model i ng l anguage)
NSU (navigation semant i c unit)
ADV (abstract dat a view)
CV (cost vari ance)
VPS (violation of pr ogr ammi ng st andar ds)
V&V (verification and validation)
Siglas i ngl s/ espaol
Trmino en ingls
3DGA (t hree- di mensi onal geomet r i c analysis)
2DGA (t wo- di mensi onal geomet r i c anaiysis)
ACD (archi t ect ure cont ext di agram)
ACWP (actual cost of wor k performer)
ADLs (architectural description l anguages)
ADP (abstract desi ng paradi gm)
ADV (abstract dat a view)
AM (agile model i ng)
AOCE (aspect-oriented component engineering)
AOP (aspect -ori ent ed programmi ng)
AOSD (aspect -ori ent ed sof t war e devel opment )
API (application pr ogr ammi ng i nt erface)
ASD (adapt at i ve sof t war e devel opment )
ATAM (architecture t rade-off anal i si s met hod)
BCWP (budget ed cost of wor k performed)
BCWS (budget ed cost of wor k schedul ed)
BPE (busi ness pr oces s es engi neeri ng)
BVA (boundary val u analysis)
CAD (comput er ai ded desi gn)
CBD ( component based devel opment )
CBO (coupling bet ween obj ect cl asses)
CBSE (component based sof t war e engi neeri ng)
CCA (change cont rol authority)
CCP ( common cl osur e principie)
CF (coupling factor)
CGDF (comput er graphi cs di spl ay facilities)
Trmino equivalente en espaol
AG3D (anlisis geomt r i co t ri di mensi onal ) 701
AG2D (anlisis geomt r i co bi di mensi onal ) 701
DCA (di seo de cont ext o arqui t ect ni co) 288
CRTR (costo real del t r abaj o real i zado) 743
LDA (l enguaj e de descri pci n arqui t ect ni ca) 296
ADP (paradi gma de di s eo abst ract o) 883
VAD (visin abst r act a de dat os) 597
MA ( model ado gil) 97
ICOA (ingeniera de component es orientada
a aspectos) 65
POA (programaci n or i ent ada a aspect os) 65
DSOA (desarrollo de sof t war e or i ent ado a aspect os) 65
IPA (interfaz de pr ogr amaci n de la aplicacin) 887
DAS (desarrollo adapt at i vo de soft ware) 89
MACA (mt odo de anl i si s de compensaci n par a la
arqui t ect ura) 294
CPTR (costo pr esupuest ado del t r abaj o real i zado) 743
CPTC (costo pr esupuest ado par a el t r abaj o cal endar i za-
do) 743
IPN (ingeniera de pr ocesos de negoci os) 140
AVL (anlisis de val or es lmite) 437
CAD (di seo asi st i do por comput ador a) 700
DBC (desarrollo bas ado en component es ) 63, 886
AECO ( acopl ami ent o ent re cl ases de obj et os) 485
I SBC (ingeniera del sof t war e bas ada
en component es) 879
ACC (autoridad del cont rol del cambi o) 810
PCC (principio del cierre comn) 325
FA (factor de acopl ami ent o) 487
FPGC (facilidades de pr esent aci n grfi ca
de comput ador a) 701
TM
PDF Editor
9 56 NDICE DE SIGLAS MS COMUNES EN INGENIERA DEL SOFTWARE
COTS (comercial off-the-shelf)
CLSS (conveyor line sorting system)
CMM (based apprai sal for internal procces i mprovement
CBA 1PI)
CMMI (capability mat uri t y model integration)
COCOMO (constructive cost model)
COM (component obj ect model)
CORBA (common obj ect request broker architecture)
CPI (cost per f or mance index)
CPM (critical pat h met hod)
CRP (common r euse principie)
CS (class size)
CSPEC (control specification)
CTC (condition - transition - consequence)
CV (cost variance)
CVS (concurrent versi ons system)
DAM (design anal ysi s modul es)
DBM (dat abase management )
DBMS (dat abase manager system)
DFD (data flow di agram)
DFR (design for reuse)
DI P (dependeney inversin principie)
DI T (depth of the i nheri t ance tree)
DMADV (define, measure, anal yze, design, and verify)
DRE (deffect removal efficiency)
DSDM (dynamic systems development method)
DSQI (design st ruct ure quality index)
DU (definition-use chain)
ECO (engineering ctiange order)
EDL (error in desi gn logic)
EI s (external inputs)
EIFs (external i nt erface files)
EOs (external out put s)
EQs (external inquiries)
ERD (error in dat a represent at i on)
EVA (earned val u analysis)
FDD (feature driven devel opment )
FIN (fan-in)
FP (function points)
GG (generic goals)
GQM (goal / quest i on/ met ri c)
GP (generic practices)
GUI s (graphical user interfaces)
HCI ( human- comput er interaction)
ICI (inconsistent component interface)
I DEs (integrated devel opment envi ronment s)
I DS lintentional deviation from specifications)
IES uncompl et e or er r oneous specification)
IET ncomplete or er r oneous testing)
CDL (component es comerci al es de linea) 695
SCCT (sistema de clasificacin de ci nt a
t ransport adora) 145
ABC MPI (apreciacin basada en el cmm para el
mej or ami ent o del pr oceso interno) 37
IMCM (integracin del model o de capaci dad de
madurez) 29
COCOMO (model o const ruct i vo de costos) 710
COM (modelo de obj et os par a component es) 889
CORBA (arquitectura comn de distribucin de
objetos) 889
IDCO (ndice de de s e mpe o del costo) 744
MRC (mt odo de rut a crtica) 736
PCR (principio comn de la reutilizacin) 325
TC (t amao de la clase) 488
EC (especificacin de control) 215
CTC (condi ci n-t ransi ci n-consecuenci a) 759
VC (varianza del costo) 744
SVC (sistema de versi ones concurrent es) 809
MAD (mdulos de anlisis de diseo) 701
GBD (gestin de bases de dat os) 701
DBMS (gestor de bases de datos) 614
DFD (di agrama de flujo de dat os) 211, 298
DPR (diseo par a la reutilizacin) 891
PI D (principio de inversin de la dependenci a) 324
APH (rbol de profundi dad de la herenci a) 484
DMADV (definir, medi r, anal i zar, di sear
y verificar) 786
EED (eficacia en la eliminacin de defectos) 677
MDSD (mt odo de desarrol l o de si st emas
dinmicos) 91
ICED (Indice de calidad de la est ruct ura de diseo) 480
DU (cadena definicin-uso) 431
OCI (orden de cambi o de la ingeniera) 810
ELD (error de la lgica del diseo) 784
EE (ent radas externas) 474
AIE (archivos de interfaz ext emos) 475
SE (salidas ext ernas) 474
CE (consul t as ext emas) 474
ERD (errores de la represent aci n de l os datos) 784
AVG (anlisis del valor ganado) 742
DCC (desarrollo conduci do por caractersticas) 95
FIN (dependenci a hacia dent ro) 495
PF (punto de funci n) 474, 670
CRC (cl ase-responsabi l i dad-col aborador) 225
RTF (revisin t cni ca formal) 774
MG (met as genricas) 32
OPM (obj et i vo/ pregunt a/ mt ri ca) 470
PG (prcticas genricas) 32
GUI s (interfaces grfi cas de usuario) 452
IHC (interfaz hombr e- comput ador a ambi gua o
i nconsi st ent e) 784
ICI (interfaz de component e i nconsi st ent e) 784
EDI (ent ornos de desarrol l o integrado) 413
DIE (desviacin i nt enci onal de l as especificaciones) 784
EIE (especificaciones i ncompl et as o errneas) 784
PIE (prueba i ncompl et a o errnea) 784
TM
PDF Editor
NDICE DE SIGLAS MS COMUNES EN INGENIEBA DEL SOFTWASE
957
IID (i naccurat e or i mcompl et e document at i on)
ILFs (internal logical files)
I PT (integrated product t eams)
I SO (i nt emat i onal organi zat i on for st andardi zat i on)
I SP (interface segregat i on principie)
IT (i nformat i on t echnol ogi es)
ITG (i ndependen! t est group)
KDD (knowl edge di scovery in dat abases)
KLOC ( t housands lines of code)
LCOM (lack of cohesi on in met hods)
LSP (Liskov subsl i t ut i on principie)
MCC (mi si nt erpret at i on of cust omer communi cat i on)
MI F (method i nheri t ance factor)
MI S (mi scel l aneous)
MTBF (mean t i me bet ween failures)
MTTC & MTTF ( mean- t i me- t o- char ge) and ( mean- t i me-
to-failure)
MTTC ( mean- t i me- t o- change)
MTTR (mean t i me t o repair)
MVC (model -vi ew-cont rol l er)
NC (numeri cal control)
NCSC (commerci al of - t he- sel f (COTS) sof t war e
component )
NOA ( number of oper at i ons added by a subcl ass)
NOC ( number of children)
NOO (number of oper at i ons overri dden by subcl ass)
OR ( number of root classes)
NPavg (average number of par amet er s per operat i on)
NSU (navigation semant i c unit)
OC (operation complexity)
OCL (object const rai nt l anguage)
OCP (open cl osed principie)
OMG (object management group)
OODA (obj ect -ori ent ed domai n analysis)
OOHDM (obj ect -ori ent ed hi permedi a desi gn met hod)
ORB (object r equest broker)
OSou( ( (average operat i on size)
PAD (public acces s t o dat a member s)
PAP (percent public and prot ect ed)
PCF (peripheral cont rol funct i on)
PERT (program eval uat i on and revi ew t echni que)
PLT (error pr ogr ammi ng l anguage translation)
PM- CMM (people ma na ge me nt capability mat uri t y model )
PNR (Put nam-Norden-Rayl ei gh curve)
PSP (personal sof t war e process)
PSPEC (process specification)
QFD (quality funct i on depl oyment )
RAD (rapid appl i cat i on devel opment )
RE (requi rement s engi neeri ng)
RE (risk exposure)
DII ( document aci n i mpreci sa o i ncompl et a) 784
ALI (archi vos l gi cos i nt ernos) 474
EPI (equi pos de pr oduct o i nt egrado) 40
I SO (organi zaci n i nt ernaci onal
de est andar i zaci n) 38
PSI (principio de segr egaci n de la interfaz) 324
TI (tecnologa de la i nformaci n) 278
GI P (grupo i ndependi ent e de prueba) 386
DCBD (descubri mi ent o de conoci mi ent o en base de
datos) 278
KLDC (miles de l neas de cdigo) 669
FCM (falta de cohesi n en mt odos) 485
PSL (principio de sust i t uci n de Liskov) 324
MCC (mala i nt erpret aci n de la comuni caci n
del cliente) 784
MFH (mt odo del factor de herenci a) 487
MI S (miscelneo) 784
TMEF (t i empo medi o ent re fallas) 787
TMDF y TMDR (tiempo medi o de falla y t i empo medi o
de reparaci n) 787
TMC (tiempo medi o de cambi o) 677
TMR (t i empo medi o de reparaci n) 407
MVC (model o-vi st a-cont rol ador) 589
CN (cont ador numri co) 696
NCSC (nuevos compone nt e s de sof t war e
comerci al es) 63
NOA ( nmer o de oper aci ones aadi das) 488
NDD ( nmer o de descendi ent es) 485
NPO ( nuevos punt os objeto) 711
NCR ( nmer o de cl ases raz) 495
NPOp r o m (nmero pr omedi o de par met r os de la
operaci n) 492
USN (unidad semnt i ca de navegaci n) 591
CO (compl ej i dad de la operaci n) 491
OCL (l enguaj e de rest ri cci n de objeto) 332
PAC (principio abi ert o-cerrado) 322
OMG (grupo de gest i n de obj et os) 889
AOO (anlisis or i ent ado a objetos) 201
MDHOO (mt odo de di seo hi per medi a or i ent ado a
obj et os) 595
ORB (distribuidor de obj et os) 889
TOp t o n l ( t amao pr omedi o de operaci n) 491
APD (acceso pbl i co a datos) 495
PYP (porcent aj e pbl i co y prot egi do) 495
FCP (funcin de cont rol perifrica) 701
LDP (l enguaj e de di seo de pr ogr amas) 217
PERT (tcnica de eval uaci n y revisin de programa) 736
TLP (error de la t raducci n del di seo al l enguaj e
de programaci n) 784
MMCGP (model o de madur ez de la capaci dad de gest i n
de personal ) 641
PNR (curva Put nam-Norden-Rayl ei gh) 730
PSP (proceso de sof t war e personal ) 39
EP (especificacin de proceso) 217
QFD (despliegue de la funci n de calidad) 171
DRA (desarrollo rpi do de apl i caci ones) 53
IR (ingeniera de requisitos) 157
ER (exposicin al riesgo) 757
TM
PDF Editor
9 5 8 NDICE DE SIGLAS MS COMUNES EN INGENIERA DEL SOFTWARE
REP (rel ease r e us e equi val ency pri nci pi e)
RFC ( r es pons e for a class)
RMMM (risk mi t i gat i on, moni t or i ng, a nd ma na ge me nt )
RNA ( r el at i onshi p- navegat i on- anal i sys)
SCAMPI ( st andar d CMM1 a s s e s s me n t me t hod for
pr oce s s i mpr ove me nt )
SCD (syst em cont ext di agr am)
SCI s ( s of t war e conf i gur at i on i t ems)
SCM ( sof t war e conf i gur at i on ma na ge me nt )
SG (speci fi c goal s)
SEE ( sof t war e engi neer i ng envi r onment )
SEI ( sof t war e engi neer i ng i nst i t ut e)
S FD (syst em flow di agr am)
SMI ( sof t war e mat ur i t y index)
S QA ( sof t war e qual i t y as s ur ance)
S QL ( st r uct ur ed quer y l anguage)
S P (speci fi c pr act i ces)
SSPI (statistical s of t wa r e pr oc e s s i mpr ovement )
TS P ( t eam s of t wa r e pr oces s )
U1 ( user i nt er f ace)
UI CE (user i nt er f ace a nd cont r ol facilities)
UML (unified mode l i ng l anguage)
UP (uni fi ed pr oces s )
V&V ( ver i f i car on a nd val i dat i on)
VP S (vi ol at i on of pr ogr a mmi ng st andar ds)
WBS (work b r e a k d o wn st r uct ur e)
WMC (wei ght ed me t h o d s pe r cl ass)
WoN ( ways of navegat i ng)
PER (principio de equi val enci a ent r e r eut i l i zaci n
y versi n) 325
RP C ( r espuest a par a una cl ase) 485
RSGR ( r educci n, super vi si n y gest i n del riesgo) 761
ARN (anl i si s r el aci n- navegaci n) 560
MEI EMP ( mt odo d e eval uaci n d e l a IMCM e s t nda r
par a el me j or a mi e nt o del pr oceso) 37
DCS ( di agr ama de cont e xt o del s i s t ema) 145
ECS ( el ement os de conf i gur aci n del s of t war e) 800
GCS (gest i n de la conf i gur aci n del s of t war e ) 796
ME ( met as espec f i cas) 31
EI S ( ent or no de i ngeni er a del s of t war e) 696
SEI (i nst i t ut o d e i ngeni er a del s of t war e) 29
DF S ( di agr ama d e fl uj o del si st ema) 146
I MS (ndice de ma d u r e z del s of t war e) 496
SQA ( gar ant a de la cal i dad del s of t war e) 767
SQL ( l enguaj e de cons ul t as est r uct ur ado) 614
PE (prct i cas espec f i cas) 31
MEPS ( mej or a est ad st i ca del pr oc e s o d e s of t war e) 667
PSE ( pr oceso de s of t wa r e e n equi po) 40
IU (i nt erfaz c on el usuar i o) 264
FI UC (faci l i dades de i nt er f az del us uar i o y cont r ol ) 701
UML ( l enguaj e de mod e l a d o uni f i cado) 68
PU ( pr oceso uni f i cado) 67
VyV (veri fi caci n y val i daci n) 384
VEP (violacin de l os e s t nda r e s d e pr ogr amaci n) 784
EAT ( est r uct ur a de anl i si s del t r abaj o) 737
MPC ( mt odos pond e r a d os por cl ase) 484
Fd N ( f or mas d e navegaci n) 591
TM
PDF Editor
Roger S. Pressmari es una aut ori dad reconoci da a nivel internacional en el
mejoramiento del proceso del soft ware y en las tecnologas de ingeniera del
soft ware.
Los 32 captulos de la sexta edicin se han or gani zado en cinco partes:
Parte 1. El proceso del software, presenta diferentes perspectivas del proceso
del software y consi dera todos los modelos de proceso importantes; adems,
abor da el debat e entre las filosofas del proceso prescriptivo y del proceso gil.
Parte 2. Prctica de la ingeniera del software, presenta mtodos de anlisis,
di seo y prueba con especial inters en las tcnicas ori ent adas a objetos y el
model ado UML.
Parte 3. Aplicacin de la ingeniera Web, presenta un enfoque completo de
ingeniera par a el anlisis, diseo y prueba de apl i caci ones Web.
Parte 4. Gestin de proyectos de software, presenta temas relevantes par a
quienes pl anean, gestionan y controlan un proyecto de software.
Parte 5. Temas avanzados en ingeniera del software, presenta captulos que
abor dan mtodos formales, ingeniera del software de sala limpia, ingeniera
de software bas ada en componentes, reingeniera y t endenci as futuras.
Adems de muchos captulos nuevos y significativamente revisados, la sexta
edicin incluye apr oxi madament e 1 20 recuadros que:
Permiten al lector seguir a un equi po de proyecto (ficticio) conforme planifica
y disea un sistema bas ado en comput adora.
Proporciona estudios complementarios de temas selectos.
Subraya los "conjuntos de t areas" que describen el flujo de t rabaj o par a
actividades selectas de ingeniera del software.
Sugiere herramientas aut omat i zadas de inters par a los temas de los captulos.
Visite nuestra pgina WEB
www.mcgraw-hiH-educacion.com
McGraw-Hill
Interamericana
TM
PDF Editor

Ingenieria Del Software - Roger S. Pressman 6ta Edicion2 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ingenieria Del Software - Roger S. Pressman 6ta Edicion2 PDF

Caricato da

Copyright:

Formati disponibili

Roger S.

Desarrollo de casos de uso

Desarrollo de interfases de usuario

Gesti n de proyectos IWeb

Gestin del contenido

Potrebbero piacerti anche