Ingenieria Del Software - Roger Pressman 6th

/
Un enfoque prctico
CAPTULO 1
PARTE UNO
PARTE DOS
PARTE TRES
El proceso del software 21

CAPTULO 2
El proceso: una visin general
CAPTULO 3
Modelos prescriptivos de proceso
CAPTULO 4
Desarrollo gil
22
48
77
Prctica de la ingeniera del software
103
CAPTULO 5
La prctica: una visin genrica
CAPTULO 6
Ingeniera de sistemas
104
133
CAPTULO 7
Ingeniera de requisitos
155
CAPTULO 8
Modelado del anlisis
191
CAPTULO 9
Ingeniera del diseo
245
CAPTULOlO
Diseo arquitectnico
275
CAPTULO 11
Diseo al nivel de componentes
315
CAPTULO 12
Diseo de la interfaz de usuario
350
CAPTULO 13
Estrategias de prueba del software
CAPTULO 14
Tcnicas de prueba del software
CAPTULO 15
Mtricas del producto poro el software
382
418
462
Aplicacin de la ingeniera Web 501

CAPTULO 16
~ CUATRO
Software e ingeniera del software
Ingeniera Web
502
CAPTULO 17
Formulacin y planeacin poro ingeniera Web
CAPTULO 18
Modelado de anlisis poro aplicaciones Web
544
517
CAPTULO 19
Modelado de diseo para aplicaciones Web
566
CAPTULO 20
Cmo probar aplicaciones Web
604
Gestin de proyectos de software 639

CAPTULO 21
Conceptos de gestin de proyectos
CAPTULO 22
Mtricas de proceso y proyecto
640
663
CAPTULO 23
Estimacin poro proyectos de software
CAPTULO 24
Calendarizacin de proyectos de software
690
CAPTULO 25
Gestin del riesgo
CAPTULO 26
Gestin de la calidad
CAPTULO 27
Gestin del cambio
724
74 7
767
796
vil
vill
CONTENIDO BREVE
PARTE CINCO
Temas avanzados en ingeniera del software 829

CAPTULO 28
Mtodos formales
CAPTULO 29
Ingeniera del software de sala limpia
CAPTULO 30
Ingeniera del software basada en componentes
CAPTULO 31
Reingeniera
CAPTULO 32
El camino por recorrer
830
902
927
858
879
Prefacio xxviii
Recorrido xxxi
CAPTULO 1
SOFTWARE E INGENIERA DEL SOFTWARE
1. 1
El papel evolutivo del software
1. 2
Software
1. 3
La naturaleza cambiante del software
1.4
Software heredado
Calidad del software heredado
l .4 .2
Evolucin del software
1.5
Mitos del software
1.6
Cmo inicia todo
1.7
Resumen
12
12
14
17
18
18
Problemas y puntos a considerar
19
Otras lecturas y fuentes de informacin
PARTE UNO:
11
1.4 . 1
Referencias
EL PROCESO DEL SOFTWARE

CAPTULO 2
20
21
EL PROCESO: UNA VISIN GENERAL
22
2. 1
Ingeniera del software: una tecnologa estratificada
2.2
Marco de trabajo para el proceso
2.3
Integracin del modelo de capacidad de madurez (IMCM)
2 .4
Patrones del proceso
23
24
29
34
2 .5
Evaluacin del proceso
2 .6
Modelos de proceso personales y en equipo
36
38
2 .6 . 1
Proceso de software personal (PSP)
2.6 .2
Procesos de software en equipo (PSE)
2.7
Tecnologa del proceso
2 .8
Producto y proceso
2 .9
Resumen
Referencias
39
40
42
43
44
45
46
CAPTULO 3
47
MODELOS PRESCRIPTIVOS DE PROCESO 48
3 .1
Modelos prescriptivos
3.2
El modelo en cascada
49
3 .3
Modelos de proceso incrementales
51
3.3.1
El modelo incremental
52
3.3.2
El modelo DRA
50
53
1x
CONTENIDO
3.4
3.4. l
3.5
3.6
Construccin de prototipos 55
58
3.4.2
El modelo en espiral
3.4.3
El modelo de desarrollo concurrente
3 .4 .4
Un comentario fino! sobre los procesos evolutivos
60
61
Modelos especializados de proceso 63

3.5. 1
Desarrollo bosodo en componentes
3.5.2
El modelo de mtodos formoles
63
3.5.3
Desarrollo del sohwore orientado o aspectos 65
64
El proceso unificado 67
3.6. l
Uno breve historio
3.6.2
Foses del proceso unificado 68
3.6 .3
3 .7
54
Modelos de proceso evolutivos
Resumen
Referencias
67
Productos de trobojo del proceso unificado 71

72
73
Problemas y puntos a considerar 7 4

CAPTULO 4
DESARROU.0 GIL 71
4.1
Qu es la agilidad? 79
4. 2
Qu es un proceso gil?
4 .3
81
4.2. 1
Los polticas del desarrollo gil
4.2.2
Factores humanos
Programacin extremo WE)
Desarrollo odoptolivo de sohwore (DAS)
4.3 .3
Mtodo de desarrollo de sistemas dinmicos (MDSDI 91
4.3 .4
Mel 92
4.3.5
Cristal 95
89
4.3.6
Desarrollo conducido par caractersticos (DCC]
4.3.7
Modelado gil (MA) 97
Resumen
95
99
100
Problemas y puntos o considerar
1O1
Otros lecturas y fuentes de informacin
l 02
PARTE DOS: PRCTICA DE LA INGENIERA DEL SOFTWARE

CPTULO 5
5 .2
84
4.3.2
Relerencios
5 .1
81
82
Modelos giles de proceso 84

4.3. 1
4.4
75
10 3
LA PRACTICA: UNA VISIN GENRICA 104
Lo prctica de lo ingeniera del sohware

5.1 . 1
La esencia de lo prctico
5. 1.2
Principios esenciales
Prcticos de comunicacin
109
5 .3
Prcticos de lo ploneocin
l 13
5 .4
Prctico del modelado
116
107
105
106
CONTENIDO
5 .5
xi
5.4.l
Principios del modelado del on6l1sis
5.4 2
Pnncip1os de modelodo del diseo
Prctica de la construccin
122
5.5. l
5.5 2
pruebos
123
Principios y conceptos de codificacin

Principios de los
56
Despliegue
5.7
Resumen
Referencias
117
l 19
124
126
128
l 29
l 30
CAPTUL06
131
INGENIERA DE SISTEMAS
133
l 34
6. l
Sistemas basados en compuladoro
6. 2
Lo jerarqua de lo ingeniera de sistemas

6.2. l
Modelado del sistema
137
6.2.2
Simulacin del sistema
139
136
6.3
Ingeniera de procesos de negoc,os. uno visin general
6.4
Ingeniera de producto: una visin general
6.5
Modelado del sistema
6.6
144
6.5. 1
Modelado HatleyPirbhoi
6.5 2
Moclelodo del s1slema con UMI.
Resumen
151
Referencias
144
Otros lectvros y fuentes
CAPTULO 7
152
de mformocin 153
INGENIERA DE REQUISITOS
7 .1
Un puente hacia el diseo y la construccin
7.2
Toreos de
7.4
147
152
7. 3
140
142
155
156
lo ingeniera de requisitos 157
7.2.1
Inicio
7.2.2
Obtencin
158
7 2.3
Elaboracin
7 2.4
Negociacin
158
159
160
7.2.5
Especificacin
7.2.6
Validacin
7.2.7
Gestin de requisitos
Inicio del proceso
160
161
161
de lo ingeniera de requisitos 163
7.3.1
Identificacin de los interesados
7.3.2
Reconocimiento de mltiples puntos de visto
7 3 3
Troboo con respecto o
7 3.4
Formulacin de las primeros pregunlas
Obtencin de requisitos
164
lo colaboracin 164
165
166
7.4. l
Recopilacin conjunto de requisitos
7 4 2
Despliegue de la funcin de calidod
7.4 3
Escenarios del usuario
172
167
171
164
xii
CONTENIDO
7.5
7.6
7.4.4
Productos de trabajo de lo obtencin
Desarrollo de casos de uso 173
Construccin del modelo de anlisis
Elementos del modelo de anlisis
7.6.2
Patrones de anlisis
Negociacin de requisitos
7.8
Validacin de requisitos
7.9
Resumen
Referencias
184
186
187
CAPTULOS
188
l 89
MODELADO DEL ANLISIS 191
Anlisis de requisitos
192
8. 1. 1
Filosofa y objetivos generales
8.1.2
Reglas prcticos de anlisis
8. l .3
Anlisis del dominio
194
Enfoques de modelado del anlisis
196
8.3
Conceptos del modelado de datos
197
8.3. l
Objetos de datos
l 97
8.3.2
Atributos
8.3.3
Relaciones
198
8.3.4
Cardinalidad y modalidad
199
8.4
Anlisis orientado a objetos
8.5
Modelado bosodo en escenarios
8.7
l 93
194
8.2
8.6
179
183
186
8. 1
179
7.6. 1
7.7
173
199
201
202
8.5 .1
Escrituro de cosos de uso
8.5.2
8.5.3
Desarrollo de un diagramo de actividad

Diagramas de carril 209
202
208
Modelado orientado al flujo 211

8.6. l
Creacin de un modelo de flujo de datos
8.6. 2
8.6.3
Creacin de un modelo de control del flujo 21 4

Especificacin de control 215
8.6.4
Especificacin de proceso
Modelado basado en clases
21 l
217
219
8 7. l
Identificacin de clases de anlisis 2 l 9
8.7.2
Espetificocin de atributos 222
8.7.3
Definicin de operaciones
8.7.4
8.7.5
Modelado de Close-ResponsobilidocKolaborador (CRC)

Asociaciones y dependencias 232
8.7.6
Paquetes de anlisis 233
8.8
Creacin de un modelo
8.9
8.8.2
Resumen
8.8. 1
223
de comportamiento 234
Identificacin de eventos con el coso de uso

Representaciones de estado
239
236
235
225
CONTENIDO
Referencias
xm
24 1
241
CAPTULO 9
243
INGENIERA DEL DISEO 245
9. 1
Diseo dentro del contexto de la ingeniera del software
9.2
Proceso y calidad del diseo 249
9.3
Conceptos del diseo 252
9.4
9.5
9 .6
9 .3. l
Abstraccin
252
9 .3.2
Arquitectura
253
9.3.3
Patrones 254
9.3.4
Modularidad
9.3.5
Ocultacin de informacin
9.3.6
Independencia funcional
9.3.7
Refinamiento
247
254
256
256
257
9.3.8
Refabricocin
9.3.9
Clases de diseo 259
258
El modelo de diseo 262

9.4. 1
Elementos del diseo de datos
263
9.4.2
Elementos del diseo arquitectnico 264
9.4.3
Elementos de diseo de interfaz 264
9.4.4
Elementos de diseo al nivel de componentes
9.4.5
Elementos de diseo al nivel del despliegue 267
Diseo de software basado en patrones
269
9.5 . 1
9.5.2
Utilizacin de potrones en el diseo
9 .5.3
Marcos de trabajo 270
Resumen
266
Descripcin de un patrn de diseo 269

270
271
Referencias 272
273
CAPTULO 10
273
DISEO ARQUITECTNICO 275
l 0.1
Arquitectura del software 276

277
10.2
10.1.2
Por qu es importante la arquitectura?
Diseo de datos 278
10.2.1
Diseo de datos al nivel arquitectnico
278
10.2.2
Diseo de datos al nivel de componentes 279
10. l .1
10.3
10.4
Qu es lo arquitectura?
Estilos y patrones arquitectnicos
276
280
1O. 3. l
10.3.2
Uno breve taxonoma de estilos arquitectnicos
10.3.3
Organizacin y refinamiento
Patrones arquitectnicos
Diseo arquitectnico
10.4. l
284
287
287
Representacin del sistema en el contexto
288
281
xi.V
CONTENJDO
10.5
10.6
10.4.2
Definicin de arquetipos
10.4.3
Refinamiento de la arquitectura en componentes
10.4.4
Descripcin de la creacin de instancias del sistema
Un mtodo de anlisis de compensacin poro lo arquitectura
10.5.2
Complejidad arquitectnica
10.5.3
Lenguajes de descripcin arquitectnica
296
10.6.2
Flujo de transaccin
10.6.3
Correlacin de transformaciones
10.6.4
Correlacin de transacciones
10 .6.5
Refinamiento del diseo arquitectnico
Resumen
298
299
306 ,
31 1
312
3 13
DISEO AL NIVEL DE COMPONENTa 315

316
Qu es un componente?
11. 1. 1
Concepto orlentado a objetos
11.1 .2
El concepto convencional
317
11.1 .3
Un concepto relacionado con el proceso
318
321
322
Diseo de componentes basados en clases
de diseo 322
11.2. 1
Principios bsicos
11.2.2
lneas generales de diseo al nivel de componentes
11.2.3
Cohesin
11.2.4
Acoplamiento
327
329
11.3
Conduccin del diseo al nivel de componentes
11.4
Lenguaje de restriccin de objetos
11.5
Diseo de componentes convencionales
331
337
340
11.5. 1
Notacin grfica del diseo
340
11.5.2
Notacin tabular del diseo
342
11.5.3
Lenguaje de diseo de programas
11.5.4
Comporocin entre notaciones de diseo
Resumen
343
345
346
347
Problemas y punlos a considerar
347
CAPTULO 12
12.1
31 O
3 12
CAPTULO 11
Referencias
297
297
Flujo de transformacin
11.6
296
Correlacin del Aujo de datos en uno arquitectura del software
O tros lecturas y fuentes de informacin
11.2
292
10.5.1
Referencias
11. 1
290
294 r
Evaluacin de diseos ar~uitectnicos alternos
10.6. 1
10.7
289
348
DISEO DE LA INTERFAZ DE USUARIO 350
las reglas de oro
35 1
12.1 . 1
Dar el control al usuario
12. 1.2
Reducir la carga en la memoria del usuario
12.1.3
lograr que la interfaz sea consistente
35 1
354
353
325
294
CONTENIDO
12.2
12.3
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
Anlisis de la interfaz
359
12.3.l
Atilisis del usuario
12.3.2
Anlisis y modelado de tareas
12.3.3
Anlisis del contenido de la pantalla
12.3.4
12.4
XV
36 1
.Anlisis del entorno de trabajo
367
367
la. interfaz 368
Posos del diseo de

12.4. l
360
Aplicacin de los pasos del diseo de la interfaz 369
12.4.2
Patrones de diseo de la interfaz de usuario 371
12.4.3
Ternos de diseo 372
12.5
Evaluacin del diseo
12.6
Resumen
Referencias
377
378
379
380
Otros lecturasy fuentes de informacin 380
CAPrrutO 13
13. 1
ESTRATiGIAS DE PRUEBA DEL SOFTWARE 382
Un enfoque estratgico para lo prueba del software

Verificacin y validocin 3 84
13.1. 2
Organizacin paro los pruebas del sftware
Estrategia de prueba para arquitecturas convencionales del software
13.1.4
Estrategia de prueba 1 del software paro arquitecturas orientados o objetos

Criterios paro completar lo prueba 389
13.2
Aspectos estratgics
13.3
Estrategias de pruebo poro el software ~onvencionol
13.6
13.3 .l
Pruebo.deunidad
Pruebo de integracin , 394
391
392
Estrategias de prueba paro _software or-ientodo o objetos 402

Pruebo de unidad en el contexto orientado a objetos
402
13.4.2
Pruebo de integracin en el contexto orientado a objetos
Pruebas de validacin 404
13.5. l
Criterios de. lo prueba de volidotin 404
13.5.2
Revisin de lo configuracin
13.5.3
Pruebas alfo y beta
Pruebo qel sistema

13.6rl
' 13,6.2
13.7
390
13. 3.2
13.4. 1
13.5
385
13. 1.3
13. l .5
13.4
383
l 3. l . 1
405
405
406
Prueba de recuperacin
407
Prueba de segridad 407
13.6.3
Pruebo de. resistencia
l 3.6.4
Pruebo de desempeo 408
408
El arle de lo deputocin 409
13 .7. l
t i proceso de depuracin
13.7.2
Consideraciones psicolgicos
4lO
411
403
386
388
xv1
CONTENIDO
13.7.3
13.7.4
13.8
Resumen
Estrategias de depuracin 412

Correccin del error
4 14
415
Referencias 416
Problemas y puntos o considerar 416
Otros lecturas y fuentes de informoci.n 4 17
CAPTULO 14
14.1
14.2
14.3
14.4
418
4 19
422
Fundamentos de los pruebas del software

Pruebas de cojo negro y cojo blanco
Pruebas de cojo blanco
Pruebo de lo ruto bsico
14.4.1
14.4.2
14.4.3
14.4.4
14.5
TCNICAS DE PRUEBA DEL SOFTWARE
423
423
Notacin de grfico de flujo
423
425
427
Rutas independientes del programo

Derivacin de cosos de pruebo
Motrices de grficos 430
430
43 l
Pruebo del flujo de dots 431 ~
Pruebo de bucles 432
14.6 Pruebo de cojo negro 41 3
Mtodos grficos de pruebo 434
14.6.1
14.6.2
Particin equivalente 436
Anlisis
de valores lmite 437
14.6.3
Pruebo de tablo ortogonal 438
14.6.4
14.7 Mtodos de pruebas orientados o objetos 441
14.7. l
Implicaciones del concepto orientado o objetos en el diseo de cosos de pruebo 442
14.7.2
Aplicobilidod de mtodos convencionales de diseo de cosos de pruebo 442
14.7.3
Pruebo bosodo en fallos 443
Cosos de pruebo y jerarqua de clase 444
14.7.4
Pruebo bosodo en escenarios 444
14.7.5
14.7.6
Estructuras de superficie y de fondo en pruebas 446
14.8 Mtodos de pruebo oplicobles ol nivel de clase 447
14.8.1
Pruebo aleatorio poro doses orientados o objetos 447
14.8.2
Pruebo de particin ol nivel de clase 448
14.9 Diseo de coso de pruebo de interclose 449
14.9. l
Pruebo de doses mltiples 449
Pruebas derivados de modelos de comportamiento 451
14.9.2
14. l O Pruebo de_entornos especiolzodos: arquitecturas y aplicaciones 452
14. 1O. l Pruebas de interfaces grficosde-usuorio 452
14. 10.2 Pruebo de orquitecturos cliente/servidor 452
14. 1O. 3 Pruebo de lo documentacin y los funciones de ayudo 454
14.10.4 Pruebo de sistemas de tiempo reol 455
14. 11 Patrones de pruebo 456
Pruebas de lo estructuro de control
14.5.1
14.5.2
14.5.3
Pruebo de condicin
CONTENIDO
14. 12 Resumen 457

459
Referencias
459
Otras lecturas y fuentes de informacin 460
CAPfTuLo 15
15. l
Calidad general
15. l . l
15. l . 2
15. l . 3
15.2
15.3
15.4
463
Factores de calidad de McCall
465
Lo transicin a un concepto cuantitativo 466

tv\edidas, mtricas e indicadores
467
467
15.2.2
El reto de los mtricos del prducto
15.2.3
15.2.4
Principios de medicin
Medicin del sohwore orientado a objetivos 470
15.2.5
!os atributos de los mtricos efectivos del sohware 471
468
1'5.2.6
Panorama de las mtricos del producto 472
469
Mtricos poro el modelo de anlisis
474
15. 3. l
Mtricas basados en la funcin
15.3.2
Mtricas poro la colidod de la especificacin
474
477
Mtricos poro el model de diseo 479

15.4. i
Mtricos del ,diseo arquitectnico '479
15.4.2
tv\itricas poro el diseo orientG:Jdo o objetos 481
15.4.3
15.4.4
Mtricas orientadas a closes: la coleccin de mtricas de CK
15.4.5
Mtricas orientados a objetos,propuestos por Lorenzy Kidd
15.4.6
Mtricas de diseo ol nivel de componentes 487
15.4.7
Mtricas orientadas a lo operacin 491
15.4.8
Mtricos de diseo de la interfaz de usuario 492
Mtricos poro el cdigo fuente
15.6
Mtricos poro pruebas 494
493
15.6. l
Mtricas de Halsteod aplicados o las pruebas 494
15.6".r
Mtricas poro pruebas orientados o objetos 495
15.7
Mtricas poro el mantenimiento 496
15.8
Resumen
Referencias
497
497

Otros lecturas y fuentes de informacin 500
PARTE TRES: APIJCACIN DE LA JNGENJERiA WD 501
CAfflULO 16
483
Mtricas orientados o objetos: la coleccin de mtricas poro el diseo orientado

o. objetos 4 '8 6
15.5
"
464
Factores de calidad del estndar ISO 9126
Un marco conceptual poro los mtricos del producto
15 .2. l
J'\I
MffRICAS DEL PRODUCTO PARA EL sonw.ARE 462
INcaNJERi.A WEB
502
16. l
Atributos de los sistemas y aplicaciones basados en Web
16.2
Estratos de la Ingeniera de WebApp
507
504
487
CONTENIDO
16.2.l
16.2.2
16. 2.3
16.3
Proceso 507
Mtodos 507
Herromientos y tecnologa 508
El proceso de ingeniera Web 508
, l Q.3. . .1 , _Definicin del morco de trabajo . 509

16.3.2
Refinamiento del morco de traba jo 512
16.4 Mejores prcticos en ingeniera Web 512
16.5 Resumen 514
Referencias 515
Problemas y puntos a considerar 515
CAPTULO 17
17. l
Formulacin de sistemas basados en Web 5 18
17. l. l
17.1 .2
17. 1.3
17.2
17.3
El puente hacia el. modelado de onlisis 525 ,
Los actores 526
t.
Construccin del equipo 528
Conflictos de gestin de proyecto poro ingeniera Web 528

Ploneocin de WebApp: subcontrotociti
530
Planeocin. de WebApp: ingeniera Web en coso 533
Medicin para ingeniera Web y WebApps 536
17.5. l
17.5.2
17.6
17.7
Recopilacin de requisitos poro WebApps 520
El equipo de ingeniera Web 526
17.4. l
17.4.2
17.5
Preguntas de formulacin ., 519
Planeocin de proyectos de ingeniera Web 526
17 3,.1
17.3.2
17.4
.FORMULACIN Y PL.\NEACIN PARA DfGENIERA WD ~17
Mediciones poro esfuerzo de ingeniera .Web 537

Medicin del valor de negocios 538
los peores prcticas para proyectos WebApp 539

Resumen 540
Referencias 54 l
CAPTULO 18
18. l
18. l. l
18. 1.2
18.1.3
18.2
18.3
Lo jerarqua de usuario 546

Desarrollo de cosos de uso 547
Afinacin del modelo de caso de uso 549
El modelado de anlisis poro WebApps 550

El modelo de contenido 551
18.3. l
18.3.2
18.3.3
18.4
18.5
MODELADO DE ANLISJS PARA APUCACIONES WD 544
Requisitos poro el onlisis de los WebApps 545 '
Definicin de objetos de contenido 551

Relaciones y jerarqua de contenido . 552
Clases de anlisis paro WebAppst' 553
El modelo de interaccin 554

El modelo funcional 557
18.6
El modelo de configuracin
18.7
Anlisis reloci6n-novegaci6n 559
18.8
559
18.7.1
Anlisis de relaciones: preguntas clave 560
18.7.2
Anlisis de navegacin 561
Resumen 563
Referendos 563
CAfflULO 19
19. l
MODELADO DE DISEO PARA APLICACIONES WEB 566
Temas de diseo para ingeniera Web 567

19. 1. l
Diseo y calidad de una W ebApp 567
19.1.2
Metas de diseno 571
19.2
Pir6mkle del diseno IWeb 572
19.3
Diseno de la interfaz de la WebApp 573
19.4
19.5
19.6
19.7
19.3.1
Principios y directrices del diseo de la interfaz 574
19.3.2
f.Aecanismos de control de la interfaz 579
19.3.3
Flujo de trabajo en el diseno de lo interfaz 580
Diseo esttico 582

19.4. l
Cuestiones de la plantilla
19.4.2
Cuestiones de diseno grfico 583
582
Diseno del contenido 584

19.5. 1
Objetos de contenido 584
19.5.2
Cuestiones del diseo de contenido 585
Diseno arquitectnico 585

19.6.1
Arquitectura de contenido 586
19.6.2
Arquitectura de WebApp 588
Diseo de navegacin
590
19.7.1
Semntico de novegacin 591
19.7.2
Sintaxis de navegacin 592
19.8
Diseo al nivel de componentes 593
19.9
Patrones de diseno hipermedia 594
19 . 10 f.Alodo de diseno hipermedia orientado a objetos (MDHOOI

Diseno conceptual para el MDHOO 595
19. l 0.2
Diseo de navegacin mediante el MDHOO 596
19.10.3
Diseno abstraclo de lo interfaz e implementacin 597
19.1 1 Mtricas de diseo poro WebApps 598

19.12 Resumen
599
Referencias 600
Otras lectura y fuentes de informacin 603
CMO PROBAR APLICACIONES WEB 604

20. l
595
19. l 0.1
Prueba
de concepios para WebApps 605
20. 1. 1
Dimensiones de calidad
605
CONTENIDO
20.1 .2
20. 1.3
20. 1.4
20.2
20.3
Pruebo del contenido 6 12
Pruebo de mecanismos de lo interfaz 6 17

Pruebo de lo semntica de la interfaz 619
Pruebo de la facilidad de uso 620
Pruebas de compatibilidad 622
Pruebas de navegacin
625
Pruebo de lo sintaxis de navegacin 625

Pruebo de la semntico de navegacin 626
Prueba de lo configuracin 628
20.7.1
20.7.2
20.8
20.9
.Estrategia de pruebas de lo interfaz 616
Pruebo al nivel de componentes 623
20.6.1
20.6.2
20.7
Objetivos de lo pruebo de contenido 6 12

Pruebo de los bases de datos 6 l 3
Pruebo de lo interfaz del usuario 616
20.4. 1
20.4.2
20.4.3
20.4.4
20.4.5
20.5
20.6
Ploneocin de los pruebas 608
El proceso de pruebo: un panorama 609
20.3. 1
20.3.2
20.4
Errores dentro de un ambiente WebApp 606

Estrategias de pruebas 607
Conflictos en el lodo del servidor 628

Conffictos en el lodo del cliente 629
Pruebas de seguridad 630

Pruebas del desempeo 631
20.9.1
20.9.2
Pruebas de carga 633
20.9. 3
Pruebas de tensin 63 3
Objetivos de los pruebas del desempeo 632
20.10 Resumen 635

Referencias 636
Problemas y puntos ~ considerar 637
PARTE CUATRO: GESTIN DE PROYECTOS DE SOFTWARE 639

CAPmJLO 21
CONCEPTOS DE GESTIN DE PROYECTOS 640
21.1
El espectro de la ge~tin 641
21 . l.1
El personal 641
El producto 642
21.1.2
El proceso 642
21. l.3
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
q;.
21.2.4
Equipos giles 649
21.2 .5
ConHictos de. coordinacin y comunicacin 650
21.3 El producto 651
CONTENIDO
21.3.1
21.3.2
21 .4
El proceso
Combinacin del producto y el proceso
656
El principio W 5 HH
Prcticos crticos
Resumen
657
658
659
660
660
CA.ffl'ULO 22
664
Mtricos del proceso y mejoro del pr~eso de software

Mtricos del proyecto
668
669
Mtricqs orientadas al ta~ao

Mtricos orientadas o la funcin
670
Reconciliacin de las mtricas LDC y PF

Mtricos orientados o objetos
673
Mtricos orientados o cosos de uso
674
Mtricos de proyectos de in~eniera Web
Medicin de lo calidad
671
674
676
677
678
22.4 Integracin de las mtricas dentro del proceso de software 680
., '22, 4:.laa ;.,rArgumerttos pdro tos mliicas del soWxi're 680
Establecimiento de una lnea base 68 l
22.4.2
22.4.3
Recopilacin, clculo y evaluacin de mtricas 682
22.5 Mtricas para organizaciones pequeos 682
22.6 Estableciminto de un programo de mtrias de software 684
22.7 Resumen 686
Referencias 687 ,
CAPmJLO 23
23.1
23.2
23.3
23.4
Eficacia en lo eliminacin de defectos
El proceso de planificacin del proceso

mbito del software
23.4.1
23.4.2
ESTIMACIN PARA PROYECTOS DE SOFTWARE 690
Observaciones acerca de lo estimacin
Recursos
664
667
Mtricas paro calidad del software
22.3. l
22.3 .2
1,,
MTRICAS DE PROCESO t PROYECTO 663
Medicin del software
22.2.1
22.2.2
22.2.3
22.2.4
22.2.5
22.2.6
22.3
661
Mtricos en los domini9s del proceso y el proyecto
22.1. 1
22.1.2
22.2
653
654
Descomposicin del proceso
El proyecto
Referencias
22. 1
652
Descomposicin del- problema
21.4.1
21.4.2
21.5
21 .6
21.7
21.8
651
mbito del software
691
692
y factibilidad 693
694
Recursos humanos
695
Recursos de software reuti lizables
695
CONTENIDO
23.4.3
23.5
23.6
Tcnicos de descomposicin 698
23 .6.1
23.6.2
23.6.3
23.6.4
23.6.5
23.6.6
23.6.7
23.6.8
23.6.9
23.7
Reursos del entorno 696
Estimacin de proyectos. de software 696

Tamao del software 698
Un ejemplo de estimacin basado enLDC . 700
Un ejemplo de estimacin basado en PF 702
Estimacin basado en el proceso 704
Un ejemplo de estimacin basada en el proceso 705
Estimacin con cosos de uso 705
Un ejemplo de estimacin basada en cosos de uso
23.8
23.9
707
Reconciliacin de estimaciones. 708
Modelos empricos de estirnacip 709
23.7.1
23.7.2
23.7.3
699
Estimacin basado en el problema
:1
lo estructuro de los modelos de estimacin 710

El modelo COCOMO 11 71 O
Lo ecuacin del software 712
Estimacin poro proyectos orientados o objetos 7 13

Tcnicos de estimacin especializados 714
23.9.1
23. 9 .2
Estimacin para desarrollo gil
714
Estimacin para proyectos de in gen ierfo Web 715
23. 1O Lo decisin desarrollar-comprar 217

2 3. 1O. 1 Creacin de un rbol de decisin 717
23.10.2 Subconlratacin 718
23.11 Resumen 720
Referencias 721
CAPfnn.024
24.1
24.2
Colendorizocin de proyecto 727
24.2. 1
24.2.2
24.2.3
24.3
Distribucin del esfuerzo 732

Ejemplo de conjunto de toreos 733
Refinamiento de los toreos principales 734
Definicin de una red de toreos 735

Colendorizacin
24.5.1
24.5.2
24.5 .3
24.6
24.7
Principios bsicos 728

Relacin entre.el personal y el esfuerzo 729
Definicin de un conjunto de toreos paro el proyecto de software 732
24.3.1
24.3.2
24.4
24.5
CALENDARIZACIN DE PROYECTOS DE SOFrWARE 724
Conceptos bsicos 725
736
Cronogramas 738
Seguimiento de lo colendarizocin 739
Seguimiento del progreso en un proyecto 00 74 1
Anlisis del valor ganado 742

Resumen 744
CONTENIDO
Referencias 7 44
Problemas y puntos o considerar 7 44
Otros lecturas y fuentes de informacin 7 46
CAPTUI.025
GESTIN DEL RIESGO 747
25 . 1
Estrategias de riesgo reactivos y prooctivos
25.2
Riesgos del soflwore 749
25 .3
Identificacin de riesgos
25.4
748
750
25.3. 1
Evaluacin del riesgo global del -proyecto 752
25.3.2
Componentes y controladores del riesgo
Proyeccin del riesgo

25.4. 1
Desarrollo de uno toblcrde riesgos
25.4.2
Evaluacin del impocto del riesgo 757
25.5
Refinamiento del riesgo
25.6
Reduccin, supervisin y gestin del riesgo
25 .7
El pion RSGR
25.8
Resumen
Referencias
753
754
755
759
759
7 63
764
7 64
Problemas y pontos o considerar 765

Otros lecturas y fuentes de i'nformocin
CAPiTuI.o26
26. l
26.2
26.3
26.4
GESTIN DE LA CALIDAD 767
Conceptos de calidad
26.1.1
7 65
768
Calidad 769
26.1 .2
Control de calidad 770
26.1 .3
Garanta de la calidad
26.1.4
Costo de lo calidad
26.2.1
Algunos antecedentes 772
26.2.2
Actividades de SQA 773
770
770
'
Garanta de lo calidad del software (SQA)
771
Revisiones del software 774

26.3.1
Impacto de los defectos de software en el costo 775
26.3 .2
Amplificacin y eliminacin del defecto 776
Revisiones tcnicas formales
778
26.4. 1
lo junta de revisin 778
26.4.2
Informe de lo revisin y conservacin de registros
26.4.3
Directrices de lo revisin ~ 780~
26.4.4
Revisiones basados en muestras 781
26.5
Enfoque formoles acerco del SQA 783 ,
26.6
Garanta de lo calidad estadstico del software
26.7
783
26.6. l
Un ejemplo genrico 784
26.6.2
Seis sigma poro ingeniera del software 785
Fiabilidad del software 786

26.7.1
fv\edidas de fiabilidad y disponibilidad
787
779
26.7.2
Seguridad del software 788
26.8 los estndares de calidad ISO 9000 789

26.9 El plan de SQA 791
26. 1O Resumen 792
Referencias 792
Otros lecturas y fuentes de inf0<mocin 794
CAPiroI.o27
27.1
27. l . l
27. 1.2
27. l.3
27.1.4
27.2
27.4
Resumen
Referencias
Elementos de configuracin del software 801
803
El papel de depsilo 803

Caractersticos y contenidos generales 804
Coroclellsticos de lo GCS 805
806
Identificacin de objetos en lo configuracin del software 807

Control de lo ve,$in
808
Control del cambio 81 O

Auditora de lo configuracin
8l3
lnfO<me de es!odo 814

Problemas en lo gestin de lo configuracin poro WebApps 815
Objetos de configuracin WebApp 817
Gestin del contenido 817
Gestin del combio 820
Control de la versin 822
,,
Auditora y eloborocin de informes 823
824
825

827
PARTE CINCO: TEMAS AVANZADOS EN INGEN1EIA DEL sonwARE 829
CAPfflJLO 28
28. l
MTODOS FORMALES 830
Conceptos bsicos 831
28.1.1
28.1.2
28.) .3
28.2
799
neos base 800
Gestin de lo configuracin poro ingeniera Web 815
27.4. l
27.4.2
27.4.3
27.4.4
27.4.5
27.4 .6
27.5
Elementos de un sistema de gestin de lo configuracin
El proceso de GCS
27.3. l
27.3.2
27.3.3
27.3.4
27.3.5
del software 797
Un escenario de GCS 798
El depsito de ECS
27.2.1
27.2.2
27.2.3
27.3
GESTIN DEL CAMBIO 796
Gestin de lo configuracin
Deficiencias de los enfoques menos formoles 832

Motern6ticos en el desarrollo de software
Concepios de mtodos fO<moles 833
Preliminares motem6ticos
28.2. l
833
837
Coojunlos y especificacin constructivo
837
CONTENJI>O
28.2.2
28 .2.3
28 .2.4
Operaciones_ de conjuntos 838

Ope<odores lgicos 840
Sucesiones 84 1
28.3
28.4
28.5
Apl icocin de lo notacin motem6tico poro lo especificocin formol
29.1
El enfoque de solo limpio
lenguojes formoles de espeeilicoci6n
842
844
845
28.5 .1
Un breve ponoromo de lo sintoxis y lo semntico del OCl 845
28.5.2
Ejemplo de uso del OCL 847
28.6 8 lenguoje de especificocin Z 849
28.6.1
Breve ponoromo de lo sintoxis y sem6ntico Z 849
28.6.2
Un ejemplo que utilizo Z 849
28.7 los diez mondomientos de los mtodos formoles 852
28.8 Mtodos formoles: el comino por recorrer 853
28.9 Resumen 854
r
Referendos 855
Problemos y puntos o consideror 855
Otros leciuros y fuentes de informacin 856
lenguoje restringido o objetos (OCL)
INGENIEIA DEL SOn'WARE DE SALA LIMPIA 858
29. 1. 1
29.1 .2
29.2
29.5
Especificacin de caja de estado 866

Especificacin de coja transporente
Resumen
Referencias
866
867
Refinomienlo y verificacin del diseo 867

Ventojos de lo verificacin del diseo 871
Pruebas de sola limpio
29.4. 1
29.4.2
863
Especificacin de cojo negro 865
Diseo de solo limpio
29.3.1
29.3.2
29.4
Qu hoce diferente o lo sala limpia? 862
Especificacin funcional
29.2.1
29.2.2
29.2.3
29.3
859
lo estrotegio de solo limpio 860
872
Pruebas es!odsticas de uso
873
Certificacin 874
875
876

Otros leciuros y fuentes de informacin
cAPiTuLo 30
30.1
30.2
30.3
30.4
877
INGENIEIA DEL S0n'WARE BASADA EN COMPONENTES 879
Ingeniera de sistemos basada en componentes 880

El proceso de ISBC 882
883
30.3. 1 - El proceso de anlisis del dominio 883
30.3.2
Funciones de caracterizacin 884
30.3.3
Modelodo estrudvrol y puntos de estrudvro 885
Desarrollo basado en componentes 886
Ingeniera del dominio
CONTENIDO
30.4. l
30.4.2
30.4.3
30.5
Calificacin, adaptacin-y composicin de componentes 887

Anlisis y diseo para la reutilizacin
891
Clasificacin y recuperacin de componentes 892
30.5. l
30.5.2
30.6
890
Ingeniera de componentes
Descripcin de los componentes reutilizables

El entorno de reutilizacin
892
894
Economa de la ISBC 895
30.6. l
30.6.2
896
Anlisis de costo empleando puntos de estructura 897
30.7 Resumen 898
Referencias 899
Impacto sobre la calidad, la productividad y el costo
REINGENIIIA 902
CAPiTuJ.o31
31 . l
31.2
Reingeniera de procesos de negocio 903
31 . 1. l
31.1.2
Un modelo de RPN
Reingeniera
del software 906
31.2. l
31.2.2
31 .3
31 .6
31 .7
" - ,..,..
Mantenimiento del software 907
Ingeniera inversa para comprender los datos 91 3

Ingeniera inverso para comprender el procesamiento 914
Ingeniera inverso de interfaces de usuario 915
Reestructuracin 916
31 .4 . l
31.4.2
31 .5
904
Un modelo de procesos de reingeniera del software 908

Ingeniera inverso 912
31 .3. l
31 .3.2
31 .3.3
3 1.4
Procesos de negocios 904
Reestructuracin del cdigo 917

Reestructuracin de los datos 917
Ingeniera directa 918
31 .5. l
31 .5.2
Ingeniera directa para arquitecturas diente/servidor 920
31 .5.3
Ingeniera directa de interfaces de usuario 922
Ingeniera directa para arquitecturas orientadas a objetos 921
La economa de la reingeniera 923

Resumen
Referencias
923
924

Otros lecturas y !tientes de.informacif'!
CAPrrtJLO 32
32. l
32.2
32.3
32.4
32 .5
32 .6
926
EL CAMINO POR RECORRER 927
La. importancia del software. Segunda parte 928

El mbito del cambio
929
Las personas y la forma en lo que construyen sistemas 930

El nuevo proceso de ingeniera del software 931
Nuevos modos de representar la informacin 933
La tecnologa como impulsor 935
CONTENIDO
XXV11
32.7
La responsabilidad de la ingeniera del software
32.8
Un comentario final
Referencias
938
939
939
fndce analti.co 943

Sjgfas ms comunes en ngeniera del software 953
936
CLAVE
..teristkas
.. sattw., ... ~
s
Clllllptas ' ,,. ,,,
iupl<adn ... ..&.
.a.idn
ie softwat \ .; .5
4tterioro ..':. " ~ if;
ffOMII .~., . ~;
.12
liistorio . ,~~.,..,
aitos . ....J.-.. 14
,i
CAPiTm.o 1
SOF'IWARE E JNGENJERlA DE!. SOFTWARE
Y si se toma en cuenta la ley de las consecuencias imprevistas, hay muchos efectos

que todava es imposible predecir en el trabajo diario.
Por ltimo, nadie podra haber predicho que millones de programas de computadora tendran que corregirse, adaptarse y mejorarse conforme pasara el tiempo y
que la labor de desarrollar estas actividades de "mantenimiento" absorberla ms
gente y recursos que todo el trabajo aplicado para la creacin del software nuevo'.
,.,.,
~?in,
;:~~;t:l,'
A medida que la importancia del software ha crecido, la comunidad del software
ha intentado de manera continua desarrollar tecnologas que hagan ms fcil, ms
rpida y menos cara la construccin y el mantenimiento de programas de computadora de alta calidad. Algunas de estas tecnologfas se limitan al dominio de una
aplicacin especifica (por ejemplo, al diseo y la implementacin de sitios Web);
otras se enfocan al dominio de una tecnologa (como la programacin orientada a
objetos y la programacin orientada a aspectos); y existen otras con base general
(por ejemplo, sistemas operativos como LINUX). Sin embargo, an no se desarroll?
una tecnologia de software que lo haga todo, y la probabilidad de que sta surja en
el futuro es pequea. Aun as, las personas dejan sus trabajos, su seguridad y hasta
sus vidas en manos del software de computadoras. Ms vale que ste sea bueno.
Este texto presenta un marco para quienes construyen software de computadora:
las personas que deben hacer buen software. El marco, que incluye un proceso, un
conjunto de mtodos y una serie de herramientas se llama ingeniera del software.
;
~~
~~,..,
<n~n
;
'~i(;.;ij
> '
fS
~~VE
Bdt.m es 1on1o oo
prodooo ClllOO el veltulo JXIIO $U eotTego.
~ ili;:--~,H!I!'
,'
'
~,~:-a}<
111.....-es
,...... 1 1 .... ms fd, Slfll "'
propGnOllllsilaaff
En la actualidad, el software tiene un papel dual. Es, a la vez, un producto y un

vehculo mediante el cual se entrega un producto. como producto, ofrece la potencia de cmputo presentada como hardware de una computadora o, de manera ms '
amplia, por una red de computadoras accesible mediante hardware local. Sin importar el lugar en que resida el software, ya sea en un celular o dentro de una computadora central, ste es un transformador de informacin; realiza la produccin, el
manejo, la adquisicin, la modificacin, el despliegue o la transmisin de la informacin que puede ser tan simple como un solo bit o tan compleja como una presentacin multimedia, En su papel de vehculo para la entrega de un producto, el software acta <:;orno la base para el control de la computadora (sistemas operativos), la comunicacin de informacin (redes), y la creacin y el control de otros programas
(utilerias de software y ambientes).
CAPiTuLo 1
SOFTWARE E INGEN!EruA DEL SOF1'WARE
El software enttega el producto ms importante de nuestro tiempo: infonnacin.

Transforma los datos personales (por ejemplo, las transacciones financieras de un
individuo) de.forma que los datos sean ms tiles en un contexto local; maneja informacin de negocios para mejorar la competitividad; proporciona una va para las
redes de informacin akededor del mundo (Internet) y proporciona los medios para
adquirir informacin en todas sus formas.
El papel c;lel software de computadora ha experimentado un cambio significativo
en un periodo un poco mayor a 50 aos. Las mejoras sustanciales en el desempeo
del hardware, los cambios profundos en las arquitecturas de cmputo, los enormes
incrementos en las capacidades de memoria y almacenamiento, y la amplia variedad de opciones de salida y de entrada han propiciado el surgimiento de sistemas
ms elaborados y complejos basados en computadoras.
ILos libros populares publicados durante las dcadas de 1970 y 1980 ofrecen una
amplia visin histrica de la cambiante.percepcin de las computadoras y del software y su impacto en la cultura. Osborne [OSB79] descrlbi una "nueva Revolucin Industrial". Tfller [TOE'80] llam al surgimiento de la microelectrnica parte de "la ter cera ola del cambio" en la historia de la humanida<;l. y Naisbitt [NAII 82] predijo la
transformacin de una sociedad industriaLen una"sociedad de la informacin". Fei-
~ fene tiempo, r&-
m n oms de es
a hdsicos.
flvis, a18ndn en
'5 ,-fcciones errf>.
aas 111f1 BSlos exper,
115 lron e.n lo
"""'1te oeventos y
llodogas. Consrve-
'1 oomildod:nadie
ia6e en realidad el fu., de los sistemas
se construyen.
genbaum y McCorduck [FEI83J sugirieron que la informacin y el conocimiento (controlados por computadoras) seran el punto de enfoque para el poder en el siglo xx1, y
Stoll [ST089J argument que la "comunidad electrnica" creada por redes y software
era la clave del intercambio de conocimiento alrededor del mundo. Todos estos escritores tenan razn.
Al comienzo de la dcada de 1990, Toffler [TOF90] describi un "cambio de poder" en el que todas las viejas estructuras' (gubernamentales, educativas, industriales, econmicas y militares) se desintegraran a medida que las computadoras y el
software condujeran a una "democratizacin del conocimiento". Yourdon [YOU92J
se preocupaba de qul las compaas lstadounitlenses pudieran perder su margen
competitivo en negocis relacionados con el software y predijo "la declinacin y cada del programador estadounidense". Hammer y Champy [HAM93] argumentaban que
las tecnologias de informacin rep,esentaran un papel primordial en la "reingeniera de la corporacin". A mediados de la dcada de 1990 la penetracin de las computadoras y del software provoc el surgimiento de una serie de libros de "neoluditas"
(como Resisting the Virtual Lije, editado por James Brook y Iain Boa!, y The Future Does
Not Compute, de Stephen Talbot). Estos autores satanizaban a la computadora al enfatizar inquietudes legitimas, pero ignorando los grandes beneficios que ya se haban
obtenido [LEV95J.
CAPTULO l
SOF'IWARE E INGEN!EruA DEL SOF'IWARE
A finales de la dcada de 1990, Yourdon [YOU96) evalu de nuevo a los candidatos a profesionales del software y sugiri el "surgimiento y resurreccin" del programador estadounidense. A medida que Internet cobraba mayor importancia, el giro
que habla dado Yourdon parecla ser el correcto. Al finalizar el siglo xx, el enfoque
cambi nuevamente, esta vez con el impacto del Y2K, "bomha de tiempo" (por ejemplo [YOU98a). [KAR99)). Aunque las fatales predicciones de aquellos que vislumbraban una catstrofe respecto al Y2K fueron falsas, sus populares escritos acarrearon
la permanencia del software en la vida de los seres humanos.
Ya iniciado el nuevo siglo, Johnson (JOHO I Jexplic el poder del "surgimiento" como un fenmeno que explica lo que sucede cuando interconexiones presentes en
entidades relativamente simples resultan en un sistema que "se autoorganiza para
formar un comportamiento ms adaptable e inteligente". Yourdon [YOUR02J retom
los trgicos sucesos ocurridos el 11 de septiembre de 2001 en Nueva York para explicar el impacto continuo del terrorismo global en la comunidad informtica. Wolfram [WOL02) present un tratado sobre "un nuevo tipo de ciencia" en donde expone
una teorfa unificadora basada sobre todo en elaboradas simulaciones de software. Daconta y sus colegas [DAC03J explicaron la evolucin de la "red semntica", y cmo esto cambiar el modo en que la gente interacta a travs de las redes globales.
, ,, M'
w~
~\.:::,,~1%~?,
"',,
~
'
~ -.., , ,C:1111
En la actualidad una enorme industria del software se ha convertido en un factor

dominante en la economa del mundo industrializado. El programador solitario de la
era inicial ha sido sustituido por equipos de especialistas en software, en los que cada uno se enfoca en una parte de la tecnologa requerida para desarrollar una aplicacin compleja. Hasta ahora, las preguntas formuladas al programador solitario
son las mismas que se hacen cuando se construyen los sistemas basados en computadoras modernas: 1
Por qu tarda tanto la obtencin del software terminado?
Por qu son tan altos los costos de desarrollo del software?
Por qu es imposible encontrar todos los errores en el software antes de en-
tregarlo a los clientes?
un excelente libro de ensayos sobre el negocio del software, Tom DeMarco (DEM95J expone la
idea contraria. Explica: "En vez de cuestionarse por qu cuesta tanto el software, uno debe preguntarse 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 softwareH.
En
CAPrrUI.0 1 SOFTWARE E INGENIER!A DEL SOFTWARE
Por qu se gastan tanto tiempo y esfuerzo en el mantenimiento de los programas existentes?

Por qu es dificil medir el progreso al desarrollar y darle mantenimiento .al
software?
stas y muchas otras preguntas demuestran la preocupacin de la industria por el
software y por la manera en que ste se desarrolla; una preocupacin que ha conducido a la adopcin de la prctica de la ingeniera del software.
En 1970, menos del uno por ciento de las personas podran haber definido lo que significaba "software de computadora". En la actualidad, la mayoria de los profesionales
y muchos miembros del pblico creen que entienden el software. Pero, en realidad
lo hacen?
Una definicin de software en un libro de texto puede tener la siguiente forma: e/
software se forma con 1) las instrucciones (programas de computadora) que al ejecutarse proporcionan las caractersticas, fenciones y el grado de desempeo deseados; 2) las
estructuras de datos que permiten que los programas manipulen informacin de maneta adecuada; y 3) los documentos que describen la operacin y el uso de los programas.
No existe duda de que se pueden encontrar definiciones ms completas. Pero se requiere ms que una definicin fonnal.
Para entender el software (y la ingeniera del software), es importante examinar
las caractersticas que lo hacen fferente de otras cosas que construye el ser humano. El software es un eleme~to lgico, en lugar de fisico, de un sistema. Por lo tanto, el software tiene caracteristicas mtiy diferentes a las del hardware:
1
Bsoftwore se ,
desorrollo, no
se manufactura.
esoftwore no se
*gosto, pero
!I detenora.
l. El software se desarrolla o construye; no se manufactura en el sentido clsico.

A pesar de que existen similitudes entre el desarrollo del software y la manufactu'ra del hardware, las dos actividades son diferentes en lo fundamental. En
\
ambas, la alta calidad se alcanza por medio del t>uen diseo, pero la fase de
manufactura del hardware puede incluir problemas de calidad inexistentes (o
que son fciles de corregir) en el software. Ambas actividades dependen de
las personas, pero la relacin entre la gnte utilizada y el trabajo realizado es
diferente' por completo (vase el capitulo 24). Ambas actividades requeren la
construccin de un "producto", pero los enfoques son diferentes. Los costos
del software se concentran en la ingeniera. Esto significa que los proyectos
de software no se pueden manejar como si fueran proyectos de manufactura.
2. El software no se "desgasta".
En la figura 1.1 se muestra, para el hardware, la tasa de fallas como una funcin del tiempo.' La relacin, llamada a menudo "curva de la baera", indica
CAPfTuI.o 1 SOFTWARE E INGENlERfA DEL SOFl'WARE
tiiM+IH
Curva de
fallal para
elhardwme.
Si S6 deseo reducir el
deleriofO d,/ sdwm,
es necesario reoHzor
un me;o, dise-0 (ropf
tvlos 9-12).
fS
~'&vi
los mtodos de lo
ingenietfo del softwore
pretenden recwr lo
magnitud de los picos
y lo pendiente de lo
anu real ~sa

muestro en lo
figuro 1.2.
que el hardware tiene un nmero considerablemente alto de fallas al inicio de

su vida (a menudo stas se atribuyen a defectos de diseo o manufactura).
Despus, los defectos se corrigen y la tasa de fallas baja hasta un nivel estable
(se desea que ste sea muy bajo) por algn periodo. Sin embargo, conforme
pasa el tiempo, la tasa de fallas se eleva de nuevo conforme los componentes
del hardware sufren los efectos acumulativos del polvo, la vibracin, el abuso,
las temperaturas extremas y muchos otros males ambientales. Expresado en
forma ms simple, el hardware comienza a desgastarse.
El software es inmune a los males ambientales que desgastan el hardware.
Por lo tanto, la curva de la tasa de fallas para el software deberla tener la forma de la "curva idealizada" que se muestra en la figura 1.2. Los defectos sin
descubrir causan tasas de falla altas en las primeras etapas de vida de un programa. Sin embargo, los errores se corrigen (en el mejor de los casos sin
agregar otros errores) y la curva se aplana corno se muestra en la figura 1.2.
La curva idealizada es una simplificacin burda del modelo de fallas real para
el software (para ms informacin vase el capitulo 26). Sin embargo, la implicacin es clara: el software no se desgasta, pero s se deteriora.
Esta contradiccin aparente se puede explicar de mejor manera si se considera la "curva real" de la figura 1.2. Durante su vida,2 el software experimenta
cambios. Conforme stos ocurren se presenta la posibilidad de introducir
errores, lo que ocasiona que la curva de fallas tenga un pico, como se muestra en la figura 1.2. Antes de que la curva pueda regresar a su estado original
con una tasa de fallas estable, se requiere otro cambio, lo que ocasiona que la
2 De hecho, desde el momento en que comienza el desarrollo, y mucho antes de que se entregue
primera versin, el cliente puede solicitar cambios.
CAPi'l'uJ.o l
SOPTWARE E JNGElilJERiA DEL SOFTWARE
4;:..;1+
CUrvasde
lallapara
el software.
'
c&v1
lo rooyor porte del

softwore on se cons
lruye olo medido del
<lte.
curva tenga otro pico. o'e est manera, el nivel de fallas mnimo se comienza
a elevar; el software se deteriora debido a los cambios.
Otro aspecto del desgaste ilustra la diferencia entre el hardware y el software. Cuando un componente del hardware se desgasta se sustituye con un
repuesto. Pero en el s?ftware no existen repuestos. Cualquier falla del software implica un error en el diseo o el proceso mediante el cual se pas del diseo al cdigo mquina ejecutable. Por lo tanto, e!J.mantenimiento del software
implica de manera considerable una complejidad mayor que el del hardware.
3. A pesar de que la industria tiene una tendencia hacia la construccin por compo-
nentes, la mayora del so.ftwate an se construye a Jet medida.
Considrese la forma en que se disea y construye un hardware de control

para un producto de cmputo. El ingeniero de diseo dibuja un esquema simple del sistema de circuitos digital. realiza algunos anlisis fundamentales para asegurarse de que el diseo realizar las funciones apropiadas y despus
busca en los catlogos de componentes digitales cada circuito integrado de
acuerdo con un nmero de parte, una funcin definida y validada, una interfaz
bien definida y un conjunto estandarizado de directrices de integracin. una
vez seleccionado cada componente, pu~de solicitrsele para despus ensamblarlo.
cuando una disciplina de ingeniera evoluciona se crea una coleccin de
diseos estndar de componentes. Los tomillos y los circuitos integrados son
slo dos ej(lmplos de los miles de componentes estndar que utilizan los ingenieros mecnicos y elctricos al disear sistema!? nuevos. Los componentes
reutilizables se han creado para que el ingeniero se pueda concentrar en los
CAPrruLO 1 SOF1WARE E INGENIERlA DEL SOFI'WARE
elementos que en realidad son innovadores en el diseo; es decir, e.n las partes que representan algo nuevo. En el mundo del hardware, la reutilizacin de
componentes es una parte natural del proceso de ingeniera. En el mbito del
software, dicha actividad apenas se ha comenzado a extender.
'1''
,'.:;'t!f'#
..........
',~1
Un componente de software se debe disear e implementar de forma que

pueda utilizarse en muchos programas diferentes. Los componentes reutilizables modernos encapsulan tanto los datos como el proceso que se aplica a stos, lo que permite al ingeniero de software crear aplicaciones nuevas a partir
de partes reutilizables.3 Por ejemplo, las interfaces actuales con el usuario se
construyen con componentes reutilizables que permiten la creacin de ventanas grficas, mens desplegables y una amplia variedad de mecanismos de
interaccin. Las estructuras de datos y los detalles de procesamiento requeridos para construir la interfaz estn contenidos en una librera de componentes reutilizables para la construccin de la interfaz.
En la actualidad existen siete grandes categoras del software de computadora que

presentan retos continuos para los ingenieros de software.
software de sistemas. El software de sistemas es una coleccin de programas
escritos para servir a otros programas. Algunos programas de sistemas (como los
compiladores, editores y utileras para la administracin de archivos) procesan estructuras de informacin complejas pero determinadas.4 otras aplicaciones de sistemas (por ejemplo, componentes del sistema operativo, controladores, software de
red, procesadores para telecomunicaciones) procesan datos indeterminados. En cada caso, el rea de software de sistemas se caracteriza por una interaccin muy intensa con el hardware de la computadora; utilizacin por mltiples usuarios; operacin concurrente que requiere la gestin de itinerarios, de comparticin de recursos,
y de procesos sofisticados; estructuras de datos complejas y mltiples interfaces externas.
software de aplicadn. El software de aplicacin consiste en programas inde-
pendientes que resuelven una necesidad de negocios especifica. Las aplicaciones en
3 La ngenleria del software basado en componentes se presenta en el captulo 30.

4 El software es detenninado 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.
CAPfTuI.o 1 SOFTWARE E INGENIERA DEL SOFTWARE
esta rea procesan datos empresariales o tcnicos de forma que facilitan las operaciones de negocios o la toma de decisiones tcnicas o de gestin. Adems del procesamiento de datos convencional, el software de aplicacin se utiliza para controlar
l~s funciones de negocios en tiempo real (por ejemplo, el procesamiento de transacciones en los puntos de venta y el control de proces?s de m~nufactura en tiempo
real.)
Software dentfftco y de i.tgenieria. El software cientifico y de ingeniera, que se

caracterizaba por algoritmos "de~pradores de nv.meros". abarca desde la astronoma
hasta la vulcanologa, 9esde el anlisis de la tensin automotriz hasta la dinmica
orbital de los transqor~ad(?res espaciales, y desde la biolqga molecular hasta la manufactura automatizada. Sin e,nbargo, las aplicaciones modernas dentro del rea
cientfica y de ingenieria se alejan en la actualidad de los algoritmos numricos convencionales. El diseo asistido por computadora, la simulacin de sistemas y otras
aplicaciones interactivas han comenzado a tomar caractersticas de software en
tiempo real e incluso de software de sistemas.
Software emportado. El software emportado reside dentro de la memoria de slo
lectura del sistema y con l se implementan y controlan caractersticas y funciones
para el usuario final y el sistema mismo, El software incrustado puede desempear
funciones limitadas y curiosas (como el control del teclado de un horno de microondas) o proporcionar capacidades de control y funcionamiento significativas (por
ejemplo, las funciones digitales de un automvil, como el control de combustible, el
despliegue de datos en el tablero, los sistemas de frenado, etctera).
Software de linea de productos. El software qe linea de productos, diseado para proporcionar una capacidad especifica y la utilizacin de muchos clientes diferentes, 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, aplicaciones de procesadores de palabras, hojas de clculo, grficas por computadora,
multimedia, entretenimiento, manejo de bases de datos, administracin de personal
y finanzas en los negocios).
Aplicadones basadas en Web. Las 'WebApps" engloban un espectro amplio de
aplicaciones. En su fonna 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 aplicaciones B2B adquieren mayor importancia, las WebApps evolucionan hacia ambientes
computacionales sofisticados que no slo proporcionan caractersticas, funciones de
cmputo y contenidos independientes al usuario final, sino que estn integradas con
bases de datos corporativas y aplicaciones de negocios.
Software de inteligencia artiftdal. Este software utiliza algoritmos no numricos en la resolucin de problemas complejos que es imposible abordar por medio de
un anlisis directo. Las aplicaciones dentro de esta rea incluyen la robtica, los sis-
10
CAPTULO 1 SOFTWARE E INGENIEruA DEL SOFTWARE
temas expertos, el reconocimiento de patrones (imagen y voz), las redes neuronales

artificiales, la comprobacin de teoremas y los juegos en computadora.
Existen millones de ingenieros de software que trabajan duro en una o ms de estas categoras. En algunos casos se construyen sistemas nuevos, pero en otros las aplicaciones existentes se corrigen, adaptan y mejoran. Es comn ver a un joven ingeniero de
software que trabaja en programas ms viejos que l mismo. Las generaciones pasadas
de creadores de software han dejado un legado en cada una de las categoras que se
han definido prrafos atrs. Se espera que el legado de la generacin actual facilite
la tarea de los ingenieros de software del futuro. No obstante, en el horizonte han
aparecido retos nuevos:
Computacin ubicua. El crecimiento rpido de las redes inalmbricas podra

conducir pronto a la verdadera computacin distribuida. El reto para los ingenieros
de software ser desarrollar software de sistema y de aplicacin que permita que dispositivos pequeos, computadoras personales y sistemas de empresa se comuniquen a travs de grandes redes.
Alimentacin de la red. La World Wide Web se convierte con rapidez en un dispositivo computacional. as como en un proveedor de contenido. El reto para los ingenieros de software es crear aplicaciones simples (por ejemplo, planeacin de las
finanzas personales) y complejas que beneficien a mercados de usuarios finales especficos alrededor del mundo.
"lo1itmpre es posible predecir, pero siempre es posible prepararse.
Fuente abierta. Existe una tendencia creciente que impulsa la distribucin del cdigo fuente para aplicaciones de sistemas (como sistemas operativos, bases de datos
y ambientes de desarrollo) de forma que los clientes hagan modificaciones locales.
El reto para los ingenieros de software es construir un cdigo fuente que sea descriptivo en s mismo, pero, an ms importante, desarrollar tcnicas que permitan tanto a los clientes como a los diseadores conocer los cambios realizados y la forma
en que se manifiestan dentro del software.
La ''nueva economa". La locura del punto-com que se afianz en los mercados
financieros hacia finales de la dcada de 1990 y la subsiguiente ruptura en los primeros aos del siglo xx, ha llevado a mucha gente de negocios a creer que la nueva
economa est muerta. La nueva economa est viva y saludable, pero evolucionar
con lentitud; la caracterizar la comunicacin y la distribucin masiva. Andy Lippman [LIP02J puntualiza esta situacin cuando escribe:
CAPrruLO 1 SOFTWARE E INGENIERA DEL SOFTWARE
11
Estamos entrando en una era caracterizada por las comunicaciones entre las mquinas distribuidas y la gente dispersa, en Jugar de la que define una conexin entre dos individuos o
entre un individuo y una mquina. El antiguo enfoque de la telefonia se refiere a "conexiones con"; la siguiente ola se refiere a "conexiones entre". Por mencionar algunos ejemplos,
se tiene Napster, la mensajeria instantnea, los sistemas de mensaje cortos y las BlackBerries.
El reto para los ingenieros de software es construir aplicaciones que faciliten la comunicacin y la distribucin de productos en masa mediante productos apenas en formacin.
Cada uno de estos "nuevos retos" obedecer sin duda la ley de las consecuencias
imprevistas y tendrn efectos (para la gente de negocios, los ingenieros de software
y los usuarios finales) que no pueden predecirse en la actualidad. Sin embargo, los
ingenieros de software se pueden preparar al iniciar un proceso que tenga la suficiente agilidad y adaptabilidad como para acoplarse a los cambios drsticos en la
tecnologa y las reglas de negocios que con seguridad se presentarn en la dcada
siguiente.
Qu es el
software
lleredado?
Existen cientos de miles de programas de computadora y todos pertenecen a uno de

los siete grandes dominios de aplicacin -software de sistemas, software de aplicacin, software cientifico y de ingeniera, software empotrado, software de producto,
WebApps y aplicaciones IA- que se expusieron en la seccin 1.3. Algunos de estos
programas son de vanguardia -slo divulgados entre ciertas personas. industrias y
gobiernos-, pero otros son ms viejos, y en algunos casos mucho ms viejos.
Estos programas viejos -con frecuencia referidos como software heredado- han
sido el foco de atencin y preocupacin continua desde la dcada de 1960. DayaniFard y sus colegas [DAY99] describen el software heredado de la siguiente forma:
Los sistemas de software heredado ... fueron desarrollados hace dcadas y han sido modificados en forma continua para cumplir los requerimientos de los cambios en los negocios
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 sus colegas [LIU98J extendieron esta descripcin al escribir que "muchos sistemas heredados persisten como el soporte de las funciones centrales de negocios y
son indispensables para las empresas" . Por lo tanto, al software heredado lo caracterizan. su longevidad y el ser crtico para los negocios.
12
CAPTULO 1 SOFIWARE E INGENIERA DEL SOFTWARE
1.4.1
Qu sede
be hacer si
se tiene un
sohware hereda
'do con poca cah
dad?
Cules son
los tipos de
cambios que se
realizan sobre
el software
heredado?
Calidad del software heredado
Por desgracia, existe una caracterstica adicional que tal vez est presente en el software heredado: poca calidad. 5 Algunas veces, los sistemas heredados tienen diseos
imposibles de extender, cdigo complicado, documentacin escasa o inexistente, casos de prueba y resultados que nunca fueron archivados, un historial de cambio manejado con pobreza, etctera; la lista podrla seguir hasta tener una longitud considerable. No obstante, estos sistemas son el soporte de "las funciones centrales de
negocios y son indispensables para las empresas" [LIU98]. Qu se puede hacer?
La nica respuesta razonable podra ser no hacer nada, al menos hasta que el sistema heredado experimente algn cambio significativo. Pero si satisface las necesidades de sus usuarios y funciona de manera confiable, el sistema no est roto y no
requiere arreglos. Sin embargo, conforme pasa el tiempo, los sistemas heredados
evolucionan por una o ms de las razones siguientes:
El software debe adaptarse para satisfacer las necesidades de los nuevos ambientes o las nuevas tecnologas de cmputo.
El software debe mejorarse para implementar los nuevos requerimientos de
los negocios.
El software debe extenderse para hacerlo operable con sistemas y bases de
datos ms modernos.
El software debe redisearse para hacerlo viable dentro de un ambiente de red.
Cualquier ingeniero de
software debe reconer
cer que el cambio es

natural. No debe intenror combatirlo.
Cuando suceden estas formas de evolucin en un software heredado, ste debe someterse a una reingeniera (captulo 31) de modo que conserve su viabilidad en el
futuro. La meta de la ingeniera de software moderna es "imaginar metodologas que
se basen en la nocin de la evolucin"; esto es, la nocin de que "los sistemas de
software cambian de manera continua, los nuevos sistemas de software se construyen a partir de los viejos, y ... todos deben interactuar y cooperar con los dems"
(DAY99).
1.4.2 Evolucin del software

El software de computadora evoluciona a travs del tiempo, sin importar su dominio
de aplicacin, tamao o complejidad. El cambio (que con frecuencia es llamado
mantenimiento del software) conduce este proceso, y se presenta cuando se corrigen
errores, cuando el software se adapta a un nuevo ambiente, cuando el cliente solicita caractersticas o funciones nuevas, y cuando la aplicacin experimenta una reingeniera 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 software, 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.
CAPTULO 1 SOFTWARE E INGENIERIA DEL SOFIWARE
13
Debido a que los programas a gran escala como Windows y Solaris se expanden bien en
el intervalo de 30 a 50 millones de lneas de cdigo, los administradores de proyecto exitosos han aprendido a dedicar tanto tiempo a combinar los enredos de nuestro cdigo heredado como a agregar cdigo nuevo. Para decirlo de manera ms simple, en una dcada
en la que el desempeo promedio del microchip de PC se increment cien veces, la incapacidad de escalar el software incluso a tasas lineales ha pasado de un pequeo secreto
a una enorme alteracin en toda la industria.
En los ltimos 30 aos, Manny Lehman {LEH97a] y sus colegas han analizado en
forma detallada la industria del software y los sistemas en un esfuerzo dirigido a desarrollar una teora unificada para la evolucin del software. Los detalles de dicho trabajo superan el enfoque del presente texto,6 pero las leyes subyacentes derivadas de
su estudio son dignas de destacarse [LEH97b):
La ley del cambio continuo (1974). Los sistemas de tipo electrnico 7 deben
adaptarse en forma continua, de lo contrario se volvern menos satisfactorios a travs del tiempo.
La ley de la complejidad creciente (1974). Cuando un sistema de tipo electrnico est en evolucin, su complejidad se incrementa a menos que se realice el
trabajo necesario para mantenerla o reducirla.
La ley de la autorregulacin (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.
Pw q los
sistemas
. . . . .s
al..,.
_ .. peso
ill-,o?
La ley de la consetvacin de la estabilidad organizacional (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 ley de la consetvacin de la familiaridad (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 mantener el dominio sobre su contenido y comportamiento. El crecimiento excesivo disminuye ese dominio. Por tanto, el crecimiento promedio permanece sin cambio durante la evolucin del sistema.
La ley del crecimiento continuo (1980). El contenido funcional de los siste-
mas de tipo electrnico debe incrementarse en forma continua para mantener la satisfaccin del usuario a lo largo del periodo de vida del sistema.
La ley de la calidad decreciente (1996). La calidad de los sistemas de tipo
electrnico parecer declinar a menos que stos se mantengan y adapten en forma
rigurosa de acuerdo con los cambios en su ambiente operacional.
6 Para una clara explicacin de la evolucin del software, el lector interesado puede revisar (LEH97a).
7 Los sistemas de tipo electrnico 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.
14
CAPTULO l
SOF'IWARE E INGENIERA DEL SOF'IWARE
La ley del sistema de retroalimentacin ( 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 obtengan mejoras significativas sobre cualquier base razonable.
Lq6 leyes que Lehman y sus colegas han definido son una parte inherente de la
realidad de un ingeniero de software. En lo sucesivo, en este texto se discutirn modelos para el proceso del software, mtodos de ingeniera de software y tcnicas de
gestin que pretenden mantener la calidad del software mientras ste se encuentra
en evolucin.
Los mitos del software -creencias acerca del software y de los procesos empleados
para construirlo- se pueden rastrear hasta los primeros das de la computacin. Los
mitos tienen ciertos atributos que los convierten en insidiosos. Por ejemplo, los mitos parecen una relacin de hechos razonables (algunas veces contienen elementos
verdaderos). se observan de manera intuitiva, y con frecuencia los promulgan practicantes experimentados, quienes "conocen el terreno".
.....
l'f ausencio de normas signm<otivos, uno industrio nuevo como el software seelt depencf.er de les iilsluntfnt"
.., ,,
En la actualidad, la mayora de los profesionales reconocidos en la ingenierla del

software identifican los mitos en su real dimensin: actitudes equivocadas que han
causado problemas serios a los administradores y al personal tcnico por igual. Sin
embargo, las antiguas actitudes y viejos hbitos son dificiles de modificar, por lo que
an subsisten creencias falsas sobre el software.
$/f:ifrif1
la red de ID!inisltudores de proyectos de
sohwore jlJede aym
o termino! con s1os y
otros milos. !lidio red

se J)llede encontrar en
-w.....-.
Los administradores con responsabilidades sobre el

software, al igual que sus pares en la mayora de las disciplinas, a menudo estn bajo presin por mantener los presupuestos, evitar que los itinerarios se extiendan y
mejorar la calidad. De la misma forma que una persona a punto de ahogarse se aferra a un tronco, con frecuencia el administrador del software se aferra a un mito si
siente que esta creencia reducir la presin (aun en forma temporal).
Mitos de la a dministracin.
Mito:
Ya se tiene un libro lleno de estndares y procedimientos para la construccin de software. Esto proporcionar a mi gente todo el conocimiento necesario?
Realidad: Tal vez sea verdad que el libro de estndares existe, pero se usa? Los
encargados de la construccin del software saben de su existencia?
El libro refleja la prctica moderna de la ingeniera del software? Est completo? Es adaptable? Est dirigido al mejoramiento del tiem-
CAPTULO 1
SOFIWARE E INGENIERA DEL SOFIWARE
15
po de entrega sin dejar de enfocarse en la calidad? En muchos casos

la respuesta a todas estas preguntas es no.
Mito:
Si se est atrasado en el itinerario es posible contratar ms programadores para as terminar a tiempo (algunas veces llamado el concepto de la
horda mongola).
Realidad: El desarrollo de software no es un proceso mecnico como la manufactura. En palabras de Brooks [BR075J: "Agregar gente a un proyecto de software atrasado lo atrasa ms". De inicio, este enunciado podra parecer contraro a la intuicin. Sin embargo, cuando se agregan
nuevos integrantes a un equipo la gente que ya estaba trabajando debe invertir tiempo en la enseanza a los recin llegados, lo cual reduce el tiempo dedicado al esfuerzo para el desarrollo productivo. Se
puede agregar gente, pero slo de una manera planeada y bien coordinada.
Mito:
Si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa compaa Jo construya.
Realidad: Si una organizacin no entiende cmo administrar y controlar internamente los proyectos de software, de manera invariable entrar en
conflicto al subcontratar este tipo de proyectos.
Mitos del cliente. El cliente que solicita un software de computadora puede ser la
fs lmSOrio trobojor
uo entender
s, debe hacer onRS comenzar. En
m:sn?s no es posf
desaro//ar todos
l:s de1r1/les, pero en
m se sepa, mees el riesgo que se
c:m.
persona del escritorio de al lado, un grupo tcnico en el piso de abajo, el departamento de ventas o de mercadotecnia, o una compaa externa que ha solicitado el
software bajo contrato. En muchos casos, el cliente cree en mitos acerca del software porque los profesionales y administradores del software hacen muy poco para corregir la desinformacin. Los mitos conducen a expectativas falsas (del cliente) y en
definitiva a insatisfaccin con el desarrollador.
Mito:
Un enunciado general de los objetivos es suficiente para comenzar a escrbir programas; los detalles se pueden afinar despus.
Realidad: A pesar de que no siempre es factible que el enunciado de los requerimientos sea comprensible y estable, un enunciado ambiguo de los
objetivos es la receta perfecta para el desastre. Los requerimientos
precisos (los cuales se derivan usualmente en forma iterativa) se desarrollan slo mediante la comunicacin continua y efectiva entre el
cliente y el desarrollador.
M i to:
Los requermientos del proyecto cambian de manera continua, pero el

cambio puede ajustarse con facilidad porque el software es flexible.
Realidad: Es verdad que los requerimientos del software cambian, pero el impacto del cambio vara de acuerdo con el momento en que ste se introduce. Cuando los cambios en los requerimientos se solicitan en
16
CAPTULO 1 SOFTWARE E INGENIERA DEL SOFTWARE
etapas tempranas (antes de iniciar con el diseo o el cdigo), el impacto en el costo es relativamente pequeo. 8 Sin embargo, conforme
pasa el tiempo, el impacto en el costo crece con rapidez -se han distribuido los recursos, se ha establecido un marco general para el diseo- y el cambio puede provocar una convulsin que requiera recursos adicionales y una modificacin significativa en el diseo.
Mitos del desarrollador. Los mitos que an subsisten entre los desarrolladores
del software han permanecido a travs de 50 aos de cultura de programacin. Durante los primeros aos del software, la programacin era vista como una forma de
arte; por ello, las viejas formas y actitudes son dificiles de eliminar.
Mito:
Siempre que se piense que no hoy tiempo

paro la ingenierfa del
software, se debe
considerar si hobr
tiempo pora hacerlo
tado de nuevo.
Una vez que el programa ha sido escrito y puesto a funcionar, el trabajo

est terminado.
Realidad: Alguien dijo alguna vez que entre ms rpido se comience a escribir
cdigo, ms tiempo pasar para que el programa est terminado. Los
datos de la industria indican que entre 60 y 80 por ciento de todo el
esfuerzo aplicado en el software se realizar despus de que el sistema haya sido entregado al cliente por primera vez.
Mito:
Mientras el programa no se est ejecutando, no existe forma de evaluar

su calidad.
Realidad: Uno de los mecanismos ms efectivos para el aseguramiento de la calidad del software se puede aplicar desde el inicio de un proyecto: la
revisin tcnica formal. Las revisiones al software (descritas en el capitulo 26) son un "filtro de calidad" que han probado ser ms efectivas
que las pruebas para encontrar ciertas clases de errores en el software.
Mito:
El nico producto del trabajo que puede entregarse para tener un proyecto exHoso es el programa en funcionamiento.
Realidad: un programa en funcionamiento es slo una parte de la configuracin

del software que incluye muchos elementos. La documentacin proporciona un fundamento para la ingeniera exitosa y, an ms importante, representa una guia para el mantenimiento del software.
Mito:
La ingeniera del software obligar a emprender la creacin de una documentacin voluminosa e innecesariay de manera invariable tornar ms
lento el proceso.
Realidad: La ingeniera del software no se refiere a la elaboracin de documentos. Est relacionada con la creacin de calidad. Una mejor calidad
8 Muchos ingenieros de software han adoptado un enfoque "gil" que adapta los cambios en forma
incremental, con lo que se controla su impacto y costo. Los mtodos giles se exponen en el captulo 4.
CAPTULO 1 SOF'IWARE E INGENIERA DEL SOFTWARE
17
conduce a la reduccin de los trabajos redundantes. Y una menor cantidad de trabajos redundantes resulta en menores tiempos de entrega.
Muchos profesionales de los sistemas reconocen la falacia de los mitos del software. Por el contrario, las actitudes y los mtodos habituales conducen a adoptar
malas prcticas administrativas y tcnicas, a pesar de que la realidad exige un mejor enfoque. El reconocimiento de las realidades del software es el primer paso hacia la formulacin de soluciones prcticas para la ingeniera del software.
Cualquier proyecto de software se inicia por alguna necesidad de negocios: la necesidad de corregir un defecto en una aplicacin existente; el imperativo de adaptar un
sistema heredado a un ambiente de negocios cambiante; el requerimiento de extender las funciones 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 software la necesidad de negocios se expresa de manera informal durante una simple conversacin.
En el recuadro que est abajo se presenta una conversacin tpica.
Con excepcin de una referencia pasajera, el software no se mencion durante la
conversacin. Aun as, el software har la diferencia en el futuro de la lnea de productos HogarSeguro. El mercado aceptar el producto slo si el software incrustado
en l satisface de manera apropiada las necesidades del cliente (que an no ha sido
definido). En los captulos subsecuentes se dar seguimento a la ingeniera del software en HogarSeguro.
a.: &geniol,mmoclel
de conedor a SlfflSOl'8t d.todca 1o'
.si CI cuoJquier -COSQ, UlCJIII' ef prtcob 80'1.1
El proyecto HogarSeguro 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.
18
CAPTULO l
SOFIWARE E INGENIERA DEL SOFIWARE
saliciti del 41$p0Sllvo sin IISOI' q;i

que nos M o uno nueva generacin de pro
_ . GCC8IO a la
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 importantes en el mbito mundial. En los pasados 50 aos, el software ha evolucionado desde 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 problemas al desarrollar software de alta calidad a tiempo y dentro del presupuesto. El
software -programas, datos y documentos- se dirige a un amplio espectro de tecnologas y reas de aplicacin. En la actualidad el software evoluciona de acuerdo con
un conjunto de leyes que han permanecido inalteradas a lo largo de 30 aos. La intencin de la ingeniera del software es proporcionar un marco general para construir software con una calidad mucho mayor.
(BR0751 Brooks, F., The Mythica/ Man-Month, Addison-Wesley, 1995.

(DAC03] Daconta, M., L. Obrst y K. Smith, The Semantic Web, Wiley, 2003.
[DAY991 Dayani-Fard, H. et al., "Legacy Software Systems: Jssues, Progress, and Challenges".
IBM Technical Report: TR-74. 165-k, abril de 1999, disponible en http://www.cas.ibrn.com/
toronto/publicalions/TR-74.165/k/Jegacy.html.
JDEM95]DeMarco, T., Why Does Software Cost So Much?, Dorset House, 1995.
[FEI83JFeigenbaum, E. A. y P. McCorduck, Thc Fifth Generation, Addison-Wesley, 1983.
[HAM93] Hammer, M. y J. Charnpy. Reeingineering the Corporation, HarperCollins Publishers,
1993.
CAPTULO 1 SOFTWARE E INGENJE:ru.A DEL SOF1WARE
19
UOHO I J Johnson, S., Emergence: The Connected Lives ofAnts, Brains, Cities and Software, Scribner, 2001.
[KAR99J Karlson, E. y J. Kolber, A Basic Introduclion to Y2K: How the year 2000 Computer Crisis
Ajfects YOU, Next Era Publications, !ne, 1999.
[LEH97a] Lehman, M y L. Belady, Program Evolution: Processes ojSoftware Change, Academic
Press, 1997.
(LEH97b] Lehman, M. et al., "Metrics and Laws of Software Evolution-The Nineties View". en
Proceedings of the 4th International Software Metrics Symposium (METRJCS '97), IEEE, 1997.
puede descargarse de http://www.ece.utexas.edu/-perry/work/papers/feastl .pdf.
[LEV95J Levy, s., "The Luddites Are Back", en Newsweek, 12 de julio de 1995, p. 55.
[LIP02) Lippman, A., "Round 2.0'', en Context Magazine, agosto de 2002, http://www.contextmag.com/.
[LIU98J Liu, K. et al., ''Report on the First SEBPC Workshop on Legacy Systems", Durham University, febrero de I 998, disponible en http:/ /www.dur.ac.uk/CSM/SABA/legacy-wksp I /
report.html.
[OSB79J Osborne, A., Running Wild-The Next Induscrial Revolution, Osborne/McGraw-Hill,
1979.
[NAI82J Naisbitt, J., Megatrends, Wamer Books, I 982.
[ST089J Stoll, c., The Cuckoo's Egg, Doubleday, I 989.
(TOF80)Tofler, A., The Third Wave, Morrow Publishers, 1980.
[TOF90J Toffier, A. Powershijl, Bantam Publishers, 1990.
[WIL02J Williams, S., "A Unified Theory ofSoftware Evolution", en salon.com, 2002. http://www.
salon.com/tech/feature/2002/04/08/lehman/index.html.
[WOL02] Wolfram, S., A New Kind ofScience, Wolfram Media, !ne., 2002.
tYOU92] Yourdon, E., The Decline and Fa// of the American Programmer, Yourdon Press, 1992.
[YOU96J Yourdon, E., The Rise and Resurrection of the American Programmer, Yourdon Press,
1996.
[YOU98aJ Yourdon, E. y J. Yourdon, Time Bomb 2000, Prentice-Hall, 1998.
[YOU98bJ Yourdon, E., Death March Projects, Prentice-Hall, I 999.
[YOU02) Yourdon, E., Byte Wars, Prentice-Hall, 2002.
2IAILINA$ X IV1UQ$ A S:QJIIJHUB

1.1. Encontrar al menos cinco ejemplos adicionales de la manera en que la ley de las consecuencias imprevistas se aplica al software de computadora.
1.2. Encontrar algunos ejemplos (positivos y negativos) que indiquen el impacto del software
en la sociedad actual. Revisar una de las referencias anteriores a I 990 en la seccin 1.1, e indicar las predicciones del autor que resultaron correctas, as como las que fueron errneas.
1.3. Desarrollar sus propias respuestas a las preguntas formuladas en la seccin 1. I. Debtanse con los compaeros de clase.
1.4. La definicin de software que se presenta en la seccin 1.2 se aplica a los sitios Web? Si la
respuesta es afirmativa, indicar la sutil diferencia entre un sitio Web y el software convencional.
1.5. Muchas aplicaciones modernas cambian frecuentemente (antes de presentarlas al usuario final y despus de que se empieza a utilizar la primera versin). Sugiranse algunas formas
de construir software para detener el deterioro debido al cambio.
1.6. Considrense las siete categoras presentadas en la seccin 1.3. Es posible aplicar el
mismo enfoque de la ingeniera del software a cada una de ellas? Explicar la respuesta.
1. 7. Seleccionar alguno de los nuevos retos mencionados en la seccin 1.3 (o algn desafio
an ms nuevo que pudiera haber surgido desde la impresin de este texto) y escribir un documento de una cuartilla que describa la tecnologa y los retos que representa para los ingenieros
de software.
20
CAPTULO l
SOFTWARE E INGENIEruA Da SOFTWARE
1.8. Describir con palabras propias la ley de la conservacin de la estabilidad organzac,onal

(seccin 1.4.2).
1.9. Describir con palabras propias la ley de la conservacin de la familiaridad (seccin I .4.2.).
1.10. Describir con palabras propias la ley de la calidad decreciente (seccin 1.4.2.).
1.11. A medida que la presencia del soflware se vuelve ms generalizada, los riesgos al pblico (debido a las fallas en los programas) representan una preocupacin significativa y creciente. Desarrollar un escenario catastrfico realista en el que la falla de un programa de computadora podria producir un gran dao (Ya sea econmico o humano).
1.12. Examinar con atencin al grupo de noticias de Internet comp.risk y preparar un resumen de los riesgos al pblico que se han discutido recientemente. Fuente alternativa: Software
Engineering Note publicada por la ACM.
Existen miles de libros que tratan sobre el soflware de computadora. La inmensa mayoria discute los lenguajes de programacin o las aplicaciones del software, pero muy pocos tratan del
soflware en si mismo. Pressman y Herron (SOftware Shock, Dorset House, 1991) presentan uno
de los primeros debates (dirigidos al pblico en general} del software y de la forma en que los
profesionales lo construyen. El libro ms vendido de Negroponte (Being Digital, Alfred A. Knopf,
Inc., 1995) ofrece una visin de la computacin y su impacto global en el siglo xx1. DeMarco
[DEM95J ha escrito una coleccin de ensayos divertidos y profundos acerca del software y del
proceso a travs del cual ste se desarrolla. Los libros de Norrnan (The Inv1SJble Computer, MlT
Press, I 998) y Bergman (lnformation Appliances and Beyond, Academic Press/Morgan Kaufmann, 2000) sugieren que el impacto extendido de las PC disminuir conforme los instrumentos de informacin y la computacin omnipresente conecten a todos en el mundo industrializado
y casi cualquier "aparato" que se posea est conectado a una nueva infraestructura 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) argumentaba que la "plaga moderna"
de las impurezas del software se puede eliminar y sugiere formas de lograrlo. Compaine (Digital Divide: Facing a Crisis or Creating a Mylh, MIT Press, 2001) escribe que la "brecha" entre aquellos que lienen acceso a los recursos de informacin (como la Web) y los que no lo tienen se est reduciendo conforme avanza la primera dcada del presente siglo.
En Internet existe una amplia variedad de fuentes de informacin sobre tpicos relacionados
con el software y su administracin. Asimismo, en nuestro sitio web se puede encontrar una lista actualizada de recursos en la red que son relevantes para el estudio del software:
http:/ /www.mhhe.com/pressman.
I O La seccin Otras lecturas y fuentes de informacin que se presenta al final de cada capitulo ofrece un
breve panorama de tas fuentes impresas que pueden ayudarle a aumentar su comprensin de los
temas principales presentados en este capitulo. Hemos creado un sitio de intemet muy extenso para
apoyar Ingeniera del software: un enfoque prctico en http://www.mhhe.com/pressman. Entre tos
muchos tpcos incluidos se encuentran referencias captulo por capitulo sobre ingenie ria del software existentes en ta red que complementan del material presentado en cada captulo. con estas
referencias se proporciona un enlace con Amazon.com para localizar tos libros que se mencionan
en cada seccin.
EL
PROCESO
DEL SOFlWARE
n esta parte de Ingenierla del sojlware, un enfi>queprcUco 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?
Qu es el desarrollo gil del software y cmo difiere de los
modelos de proceso ms tradcionales?
Cuando se respondan estas preguntas se estar mejor preparado para entender el contexto en el cual se apliea la prctica de la
ingenierla del software.
21
- - - - - - - - - - - ~ ~ - - - - = - ~-
CAPITULO
EL
PROCESO:
,
UNA VISION GENERAL
CONCEPTOS
CLAVE
adivldadts
somlirila ..... 28
Debido a que el software, como cualquier capital, es conocmiento materializado, y

dado que el conocimiento en un inicio es disperso, tcito, latente y en gran medida
incompleto, el ctesarrollo del software es un proceso de aprendizaje sociaL El proceso
es un dilogo en el cual el conocimiento que el software debe convertir se conjunta y
se materializa en este ltimo. El proceso proporciona interaccin entre los usuarios
y las herramientas en evolucin, y entre los diseadores y sus herramientas
{tecnologa}. E$ un proceso iterativo en el que la herramienta en evolucin sirve como
un medio para la comunicacin, en el cual cada nueva etapa del dilogo logra obtener ms conocimiento til de las pe;sonas implicadas.
*!unto
de ta1tas ..... 27
valuacin
del proceso . 36
IMO\ .. . 29
ISO 9001: 2000 .38

mor<0 dt fraboo
del proceso . .24
pah'oaes
del proceso .... .34
De hecho, la construccin del software de computadora es un proceso iterativo de aprendizaje, y el resultado, algo que .Baetjer llamara: "el capital del software", es una materializacin del conocimiento recolectado, depurado y organizado conforme el proceso estuvo en ejecucin.
PSE ..........40
PSP ..........39
tecnologa
del proceso .. . 42
n un fascinante libro que ofrece la visin de un economista sobre el soft~

ware y la ingeniera del software, Howard Baetjer, Jr. {BAE98J comenta so~
bte el proceso del software:
Qu e$? Cuando se 1robo10 pc:ll'tl

construir un prodoctQ o sistema es irb
portante seguir una serie de posos pAl"
~IOft IN po,os? En detalle, el proceso que

_ . clepencfe del software que se est cons~ . Un proceso puede ser apropiado parQ
decibles: uno espe<;ie de mopo d. co,aea, u, ~ paro un sistema de oeronutico,
tretercis que ayude o crear un resullarr.fo.
mientras que un proceso distinto pc>r CQmpleto serio
de olta cofidad y o ~empo. El mopo d e ~
et. indioado paro la creacin de un sitio Web.
que debe $9uirse se liorna proceso de aoftwar..
,c...i
" el ptoducto obtenido? Desde el
Quin lo hcrce? Los ingenieros de softwtn
punto de vtsto del ingeniero de software, los
y sos jefes odapron el proceso a sus ~ f
productoJ obtenidos son los programas, docudespus lo siguen. Adems, la gente que ha W:>
me,,tos
y datos que se producen como conse
licitado el sottwQre tiene uno funcin ~ <fe.
cuencia de las actividades y toreos definidos
sempear en el proceso de definirlo, ~
fJOr tif procso
Ct6.IM
...... ..._ seguro de q11e fo IMt
importante? Porqve ofrece ..,..
MCh
COITeckmtMtit? Existen muchos meca
bilidad, control y organizacin o uno OdMdad
~ de Mluocin del proceso de soltwo~ que
que puede volverse catico si no se comrolc, Sm
~ . o los organizaciones determinar lo "mo
embargo, un enfoque de ingeniera del~
~ det proceso de software. No obstante, lo
moderno debe $81" "gil". Debe ~ ~
:ocifidod,
el tiempo ~uerido, to viabilidad o lorgo
aquellas octividodes, controles y ~
~
del
producto que se coo$truye son los mejo
nes apropiados paro el equipo del~ y i
res lnditodores de lo eficodo del proceso que se
producto que ha de pro(;irse.
y probarlo.
Por qu es
22
CAPTULO 2 EL PROCESO: UNA VISIN GENERAL
23
Pero, qu es con exactitud un proceso de software desde un punto de vista tcnico? Dentro del contexto de este libro, un proceso de software se define como un
marco de trabajo para las tareas que se requieren en la construccin de software de
alta calidad. El proceso es un sinnimo de ingeniera del software? La respuesta es
s y no. un proceso de software define el enfoque que se adopta mientras el software est en desarrollo. Pero la ingeniera del software tambin abarca las tecnologas
que requiere el proceso (mtodos tcnicos y herramientas automatizadas) .
An ms importante es que la ingeniera del software la realizan personas
creativas y con conocimiento que deben trabajar en un proceso de software maduro que sea apropiado para el producto que construyen y para las demandas de sus
mercados.
A pesar de que cientos de autores han definido en forma individual la ingeniera del
software, la definicin que propuso Fritz Bauer [NAU69] en una conferencia fundamental sobre la materia an se puede utilizar como base para el debate:
[La ingeniera del software es] el establecimiento y uso de principios slidos de la ingeniera para obtener econmicamente un software confiable y que funcione de modo eficiente en mquinas reales.
Casi cualquier lector se sentir tentado a sumar otras ideas a esta definicin. Dice poco sobre los aspectos tcnicos de la calidad del software; no se refiere de manera directa a la necesidad de satisfacer al cliente o al tiempo de entrega de un producto; omite mencionar la importancia de la medicin y la mtrica; no establece la importancia
de un proceso efectivo. No obstante, la definicin de Bauer ofrece una idea bsica.
Cules son "los principios slidos de la ingeniera" que pueden aplicarse en el desarrollo del software de computadora? De qu manera se construye "econmicamente"
un software "confiable"? Qu se requiere para crear programas de computadora que
funcionen "de manera eficiente" no slo en una, sino en vanas "mquinas reales" diferentes? Estas interrogantes continan siendo un reto para los ingenieros de software.
"M6s f1111 disciplina oun cuerpo de conocimiento, lo ingeniera es un verbo, uno palabro de iltd6n, una IIClllllffl
de abordar U11 problema.*
El IEEE [IEE93J ha elaborado una definicin ms comprensible al establecer:

Cmo se
tngenieria del software: 1) La aplicacin de un enfoque sistemtico, disciplinado y cuanti-
define la
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).
.,.,..,-a
t sohware?
Y aun as, lo que es "sistemtico, disciplinado" y "cuantificable" para un equipo de software, puede ser gravoso para otro. Se requiere de disciplina, pero tambin de adaptabilidad y agilidad.
PARTE UNO
24
EL PROCESO DEL S011WARE
Uhffli
Estratos de la
ingeniera de
software.
-'~"'
c&v1
Lo ingenieo del
softwore abarca un
proceso, mtodos y
herromientos.
' oss lalhs 111D
dii(Qdllqueinformoci6n
e1 INUQISQ, lclS
mtodos y los
m,
'
"'*
~i>,ed
enooMrarse en
........
.........
La ingeniera del software es una tecnologa estratificada. como se muestra en la

figura 2.1, cualquier enfoque de la ingeniera (incluido el de la ingeniera del software) debe estar sustentado en un compromiso con la calidad. La Gestin de la Calidad
Total, Sigma Seis y enfoques similares fomentan una cultura de mejora continua del
proceso, y es esta cultura la que al final conduce al desarrollo de enfoques muy efectivos para la ingeniera del software. La base que soporta la ingeniera del software
es un enfoque en la calidad.
La base de la ingeniera del software es el estrato del proceso. El proceso de la ingeniera del software es el elemento que mantiene juntos los estratos de la tecnologa y que permite el desarrollo racional y a tiempo del software de computadora. El
proceso define un marco de trabajo [PAU931 que debe establecerse para la entrega
efectiva de la tecnologa de la ingeniera del software. El proceso del software forma
la base para el control de la gestin de los proyectos de software y establece el contexto en el cual se aplican los mtodos tcnicos, se generan los productos del trabajo (modelos, documentos, datos, reportes, formatos, etctera), se establecen los fundamentos, se asegura la calidad, y el cambio se maneja de manera apropiada.
Los mtodos de la ingeniera del software proporcionan los "cmo" tcnicos para
construir software. Los mtodos abarcan un amplio espectro de tareas que incluyen la
comunicacin, el anlisis de requisitos, el modelado del diseo, la construccin del
programa, la realizacin de pruebas y el soporte. Los mtodos de la ingeniera del software se basan en un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluye actividades de modelado y otras tcnicas descriptivas.
Las herramientas de la ingeniera del software proporcionan el soporte automatizado o semiautomatizado para el proceso y los mtodos. Cuando las herramientas
se integran de forma que la informacin que cree una de ellas pueda usarla otra, se
dice que se ha establecido un sistema para el soporte del desarrollo del software, que
con frecuencia se denomina ingeniera del software asistida por computadora.
Un marco de trabajo establece la base para un proceso de software completo al identificar un nmero pequeo de actividades del marco de trabajo aplicables a todos los
proyectos de software, sin importar su tamao o complejidad. Adems, el marco de
trabaJo del proceso abarca un conjunto de actMdades sombrilla aplicables a lo largo
dcl proceso del software.
CAPTULO 2
+11+1+11,
25
EL PROCESO UNA VISIN GENERAL
Proceso del software
Un marco de
trabajo del
Marco de trabajo del proceso
proceso
de software.
Actividades sombrilla
Actividad del marco de trabajo # 1
accin de lo ingeniera de software # 1 . 1
1,
Conjunto
de toreos
1o<eo1 del ttoboo

producto$ del trabajo
puntos de OS'9uromiento
de lo calidad
fundomenlos del p,")'edo
accin de lo ingeniera de software #1.k

Conjunto
de toreos
I0'90s del trabajo

productos c!.1 trobajo
puntos de osego,omienlo
de lo colidod
fundomen~ del p<oyeclo
1,
Actividad del marco de trabajo #n

accin de lo ingeniera del software #n.1
lorecn del trobaio
Conjunto
de toreos
p,oductos del lrobojo

puntos de o,egurom...ilO
de lo colidod
Fundom.nto, del pl'Oyec!O

accin de lo ingeniera de software #n.m
Conjunto
de toreos
toreo, del 1roboo

p,odudOs del 1robojo
punlOI de osegur,;imoenlO
de lo colidod
fundamentos del proyecto
li
Como se muestra en la figura 2.2, cada actividad dentro del marco contiene un
conjunto de acciones de ingeniera del software; es decir, una serie de tareas relacionadas que produce un producto del trabajo en la ingeniera del software (por ejemplo,
el diseo es una accin de la ingeniera del software). Cada accin la forman tareas
de trabajo individuales que completan alguna parte del trabajo implicado por la accin.
f1111111
Mnt-
lS16 hociendo qu, cundo y cmo logror cierto meto.

lv Jacobsea, Gr.ty leodi J .lalll
..-
..
PARTE UNO
26
.EL PROCESO DEL SOFTWARE
El siguiente marco de trabajo genrico del proceso (utilizado como base para la
descripcin de los modelos de proceso en los captulos subsecuentes) se puede aplicar en la inmensa mayora de los proyectos de software:
Cules
son las cinco

actividades del
marco de trabajo
'del proceso
general?
Comunicacin. Esta actividad del marco de trabajo implica una intensa colaboracin y comunicacin con los clientes; 1 adems, abarca la investigacin de requisitos y otras actividades relacionadas.
Planeacin. Esta actividad establece un plan para el trabajo de la ingeniera del
software. Describe las tareas tcnicas que deben realizarse, los riesgos probables,
los recursos que sern requeridos, los productos del trabajo que han de producirse y
un programa de trabajo.
Modelado. Esta actividad abarca la creacin de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseo que lograr satisfacerlos.
Construccin. Esta actividad combina la generacin del cdigo (ya sea manual
o automatizado) y la realizacin de pruebas necesarias para descubrir errores en el
cdigo.
Despliegue. El software (como una entidad completa o un incremento completado de manera parcial) se entrega al cliente, quien evala el producto recibido y
proporciona informacin basada en su evaluacin.
Estas cinco actividades genricas del marco de trabajo son tiles durante el desarrollo de programas pequeos, la creacin de grandes aplicaciones en la red, y en la ingeniera de sistemas basados en computadoras grandes y complejas. Los detalles del
proceso del software sern muy diferentes en cada caso, pero las actividades dentro
del marco permanecern iguales.
"EinsHin argumentaba que deba existir uno explicacin simplificado de la naturaleza porque Dios no es ropri<hoso pj
arbitrario. Tal fe no cooforta ol ingeniero del software. Mucho de lo cornplefidod que debe 1110niobror es de mrdw
otbitrario.
FrtdBroeu
Si se usa un ejemplo derivado del marco de trabajo genrico del proceso, la actividad de elaboracin del modelo la componen dos acciones de la ingeniera del software: anlisis y diseo. El anlisis2 abarca un conjunto de tareas de trabajo (por ejemplo, la investigacin, elaboracin, negociacin, especificacin y validacin de requisitos) que conducen a la creacin del modelo de anlisis (o a la especificacin 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 (stake) 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.
CAPTULO 2 EL PROCESO: UNA VJSIN GENERAL
~,
~
C~VE
27
quisitos). El diseo abarca tareas de trabajo (diseo de datos, diseo arquitectnico, diseo de interfaz y diseo al nivel de componentes) que crean un modelo de diseo (una especificacin de diseo).3
1A1iJ1os 11oyectos
~diferentes
CllpllOs de toreos.
B~ de software
illlie el coojooto de
tt!CS coo base en
~yenlos
c:misticos del
Como tambin se aprecia en la figura 2.2, cada accin de la ingeniera del software la representa un gran nmero de diferentes conjuntos de tareas: una serie de tareas de trabajo, productos relacionados, puntos para el aseguramiento de la calidad
y fundamentos de proyecto dentro de la ingeniera del software. El conjunto de tareas que mejor se ajuste a las necesidades del proyecto y a las caractersticas del equipo es el que se escoge al final. Esto implica que una accin de la ingeniera del software (como el diseo) se puede adaptar a las necesidades especficas del proyecto
p:r).
de software y a las caractersticas del equipo de proyecto.
Conjunto de tareas
Un conjunto de tareas define el trabajo real
....-::;
que debe realizarse poro cumplir los objetivos de
J'(J accin de ingeniera del software. Por ejemplo, la
recopilacin de requisitos es una accin importante de la
ngeniera del software que ocurre durante lo actividad de
comunicacin. Lo meta de la reunin de requisitos es
eriender qu desean los distintos dientes del software que
,e va a construir.
Para un proyecto pequeo, al parecer simple, el
CXlOjunto de toreas para lo recopilacin de requisitos
ouede ser como se enumera a continuacin:
,
Hacer uno lista de los dientes para el proyecto.
2 Invitar a todos los dientes a una reunin informal.

3. Pedir a codo cliente que hago una lista de
caractersticas y funciones requeridas.
4
Establecer un debate sobre los requisitos y elaborar

una lista final.
5. Priorizar los requisitos.

6 . Advertir los reas de incertidumbre.
:n, un proyecto de software mayor y m6s complejo, se
i:equeriro un conjunto diferente de tareas. ste puede

inc:Lir la siguiente lista:
1 Hacer una lista de los clientes para el proyecto.
2 Entrevistar a codo uno de los clientes, por seporodo,

para determinar de manera general sus deseos y
necesidades.
3. Elaborar una lista preliminar de las funciones y

caractersticas basadas en la informacin que
ofrezcan los clientes.
4. Hacer un programa de reuniones paro recopilar los
requisitos.
5. Conducir las reuniones.

6. 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 listo revisada de los requisitos de los
clientes.
9. Utilizar tcnicos de despliegue de funciones de
calidad poro jerarquizar los requisitos.
10. Empaquetar los requisitos poro que puedan
entregarse de manero incremental.
11 . Observar las restricciones que sern puestas en el
sistema.
12. Debatir mtodos poro validar el sistema.

Ambos conjuntos de tareas consiguen la recopilacin
de requisitos, pero son muy diferentes en cuanto a
profundidad y formalidad. El equipo de software elige el
conjunto de tareas que permitir6 alcanzar la mela de cada
actividad del proceso y accin de ingeniera del software
que mantenga lo calidad y agilidad.
3 Cabe aclarar que "la elaboracin del modelo" debe interpretarse de un modo diferente cuando se realiza el mantenimiento de un software existente. En algunos casos ocurre el modelado del diseo y el
anlisis, pero en otras situaciones de mantenimiento se le utiliza para ayudar a entender el software
heredado, al igual que para representar adiciones o modificaciones en ste.
28
PARTE UNO
El marco de trabajo descrito en la visin general de la ingenieria de software lo

completa una serie de actividades sombrilla. Las actividades tlpicas en esta categora
incluyen:
Seguimiento y control del proyecto de software: permite que el equipo de

software evale el progreso comparndolo con el plan del proyecto y as tomar las
Las actividades
sombrilla ocurren olo
largo del proceso de
software y se eofocon
de modo prindpol en
lo gestin, el mstreo y
el control del proyecto.
,,
,r.,
c&v1
lo odoptocin del
proceso de soflware es
esencial l)OIO el xito
del proyecto.
acciones necesarias para mantener el programa.
Gestin del riesgo: evala los riesgos que pudieran afectar los resultados del
proyecto o la calidad del producto.
Aseguramiento de la calidad del software: define y conduce las actividades
requeridas para asegurar la calidad del software.
Revisiones tcnicas formales: evala los productos del trabajo de la ingeniera del software en un esfuerzo encaminado a descubrir y eliminar los errores antes
de que stos se propaguen hacia la siguiente accin o actividad.
Medicin: define y recolecta mediciones del proceso, el proyecto y el producto

para ayudar al equipo a entregar software que satisfaga las necesidades del cliente;
se puede usar en conjunto con todas las otras actividades del marco de trabajo o actividades sombrilla.
Gestin de la configuracin del software: maneja los efectos del cambio a
travs del proceso del software.
Gestin de la reutilizacin: define los criterios para la reutilizacin de productos del trabajo (se incluyen componentes del software) y establece mecanismos para la creacin de componentes reutilizables.
Preparacin y produccin del producto de trabajo: abarca las actividades
requeridas para crear productos del trabajo como modelos, documentos, registros,
formatos y listas.
Las actividades sombrilla se aplican durante el proceso del software y se tratan con
detalle en captulos posteriores de este texto.
Todos los modelos de proceso se caracterizan dentro del marco del proceso mostrado en la figura 2.2. La aplicacin inteligente de cualquier modelo de proceso del
software debe reconocer que la adaptacin (al problema, proyecto, equipo y a la cultura organizacional) es esencial para el xito de esta actividad. Pero los modelos de
proceso difieren de manera fundamental en:
El flujo global de actividades y tareas, y las interdependencias entre las actividades y las tareas.
Dt qu
manera
ditteren los
modelos del
pro<eso entre s?
El grado en el cual las tareas de trabajo estn definidas dentro de cada actividad del marco de trabajo.
El grado en el cual se identifican y se solicitan los productos de trabajo.
La forma en la que se aplican las actividades de aseguramiento de la calidad.
La manera en la que se aplican las actividades de seguimiento y control.
CAPTULO 2
29
EL PROCESO UNA VISIN GENDW.
El grado general de detalle y el rigor con el que se describe el proceso.

El grado en el que los clientes estn comprometidos con el proyecto.
El grado de autonoma otorgado al equipo de proyecto de software.
El grado en el cual estn definidos la organizacin y las responsabilidades
en el equipo.
..........
,.., "8 una receta es slo un temo con el que un conero inteligente puede jugar cado vez de una ll1Cllllfa dislintl.
Los modelos de proceso que enfatizan la definicin, la identificacin y la aplicacin

detallada de las actividades del proceso han sido aplicados dentro de la comunidad
de la ingeniera del software en los ltimos 30 aos. La aplicacin de estos modelos
prescriptivos intenta mejorar la calidad del sistema, hacer que los proyectos sean ms
manejables, que las fechas de entrega y los costos sean ms predecibles, y guiar a
los equipos de ingenieros de software mientras realizan el trabajo que requiere construir un sistema. Por desgracia, ha habido ocasiones en que estos objetivos no se han
alcanzado Si los modelos prescriptivos se aplican en forma dogmtica y sin ningu-
O.
caracteriza
..,?
proceso
na adaptacin, stos pueden incrementar el grado de burocracia asociada con la

construccin de sistemas basados en computadoras, y de manera inadvertida crear
dificultades para los desarrolladores y los clientes.
En aos recientes se han propuesto modelos de proceso que subrayan la agilidad
del proyecto y siguen un conjunto de principios, 4 los cuales conducen a un enfoque
ms informal para el proceso del software (dicho enfoque no es menos efectivo, segn argumentan quienes lo propusieron). Estos modelos giles del proceso resaltan la
manejabilidad y adaptabilidad. son apropiados para muchos tipos de proyectos y son
tiles de manera particular cuando se desarrollan aplicaciones en la red.
Cul de los enfoques para el proceso del software es el mejor? Esta pregunta ha
ocasionado un debate emocional entre los ingenieros de software y se abordar en
el captulo 4. Por ahora, es importante darse cuenta de que estos dos enfoques de
proceso tienen una meta comn : crear software de alta calidad que satisfaga las necesidades del cliente, pero tienen perspectivas diferentes.
2,3
El Instituto de Ingenierla del software (SEi, por sus siglas en ingls) ha desarrollado
un modelo completo de un amplio proceso basado en un conjunto de capacidades
de software y de sistemas que deben estar presentes conforme las organizaciones
alcanzan diferentes grados de capacidad y madurez del proceso. El SEi sostiene que
para lograr estas capacidades una organizacin debe crear un modelo de proceso (figura 2.2) que se ajuste a las directrices establecidas por la integracin del modelo de
capacidad de madurez (JMCM) [CMM02J.
4
Los modelos giles y los principios que los guan se explican en el capitulo 4.
30
PARTE UNO
ifrhii+
Perfil de c apacidad del rea
del proceso de
laIMCM
pp
Ploneoci6n del p ~
Gesti6n ele requiik,.
Medkin y on6'iJis
Ges6n de lo c:onfiguroci6n
A,eguromiento de lo colidod
del producto y el pr0<8$o
GR
MA
GC
ACPP
[PHI02].
--
'--
o
PP
GR
MA
GC
rea del proceso
ACPP
airo
La IMCM representa un modelo completo de proceso en dos formas di ferentes: 1)

como un model o continuo y 2)como un modelo discreto. El modelo continuo IMCM
describe un proceso en dos dimensiones, como se ilustra en la figura 2.3. Cada rea
Una ialcmu:i6n
cO(lfleta ocer~ de lo
del proceso (por ejemplo, la planeacin del proyecto o la gestin de los requisitos)
se evala de manera formal contra las m etas y prcticas especficas y se clasifica de
acuerdo con los siguientes niveles de capacidad:
tMCM puede
* -811
ldtp://www.stl.
ca.N.11/-'I
Nivel O: Incompleto. El rea del proceso (por ejemplo, la gestin de requisitos)

an no se realiza o todava no alcanza todas las metas y objetivos definidos para el
nivel I de capacidad.
Nivel 1: Realizado. Todas las metas especficas del rea del proceso (como las
defini la IMCM) han sido satisfechas. Las tareas de trabajo requeridas para producir el producto especfico han sido realizadas.
Nivel 2 : Administrado. Todos los criterios del nivel l han sido satisfechos. Adems, todo el trabajo asociado con el rea de proceso se ajusta a una poltica organizacional definida; toda la gente que ejecuta el trabajo tiene acceso a recursos adecuados para realizar su labor; los clientes estn implicados de manera activa en el
rea de proceso, cuando esto se requiere; todas las tareas de trabajo y productos estn "monitoreados, controlados y revisados; y son evaluados en apego a la descripcin del proceso" [CMM02).
Nivel 3: Definido. Todos los criterios del nivel 2 se han cumplido. Adems, el
proceso est "adaptado al conjunto de procesos estndar de la organizacin, de
acuerdo con las polticas de adaptacin de esta misma, y contribuye a la informacin
de los productos del trabajo, mediciones y otras mejoras del proceso para los activos del proceso organizacional" [CMM02J.
Nivel 4: Administrado en forma cuantitativa. Todos los criterios del nivel 3

han sido cumplidos. Adems, el rea del proceso se controla y mejora mediante mediciones y evaluacin cuantitativa. "Los objetivos cuantitativos para la calidad y el
CAPTULO 2
31
desempeo del proceso estn establecidos y se utilizan como un criterio para administrar el proceso" [CMM02).
Nivel 5: Mejorado. Todos los criterios del nivel 4 han sido satisfechos. Adems,
el rea del proceso "se adapta y mejora mediante el uso de medios cuantitativos (es
tadsticos) para conocer las necesidades cambiantes del cliente y mejorar de manera continua la eficacia del rea del proceso que se est considerando" [CMM02J .
!.
....... 11 aisis del software es autoinfli9icla, como cuondo 00 dice: Prefieroque Mi mal a qwt
- . . ~ repararlo despus.
lsti-.
La IMCM define cada rea del proceso en funcin de "metas especficas" y de las
"prcticas especficas" requeridas para alcanzar dichas metas. Las metas especficas
establecen las caracteristicas que deben existir para que las actividades implicadas
por un rea de proceso sean efectivas. Las prcticas especficas convierten una meta
en un conjunto de actividades relacionadas con el proceso.
Por ejemplo, la planeadn del proyecto es una de las ocho reas del proceso
definidas por la IMCM para la categora de "gestin del proyecto". 5 Las metas especficas (ME) y las prcticas especificas asociadas (PE) que se han definido para la planeacin del proyecto son [CMM02):
ME 1 Establecer es timaciones
PE 1.1- 1 Estimar el alcance del proyecto.
PE 1.2- 1 Establecer estimaciones para los atributos del producto y las tareas
del trabajo.
PE 1.3- 1 Definir el ciclo de vida del proyecto.
PE 1.4- 1 Determinar estimaciones de esfuerzo y costo.
ME 2 Desarrollar un plan de proyecto

PE 2.1-1 Establecer el presupuesto y el programa.
PE 2.2- 1 Identificar los riesgos del proyecto.
PE 2.3- 1 Planear la gestin de los datos.
PE 2 4- 1 Planear los recursos del proyecto.
PE 2.5-1 Planear los conocimientos y habilidades que se requieren.
PE 2 .6-1 Planear la participacin del cliente.
PE 2.7- 1 Establecer el plan de proyecto
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.
32
PARTE UNO
EL PROCESO DEL SOFIWARE
ME 3 Comprometerse con la planeacin

PE 3.1 - 1 Revisar los planes que afectan el proyecto.
PE 3.2-1 Conciliar el trabajo y los niveles de recursos.
PE 3.3-1 Comprometerse con la planeacin
Adems de las metas y prcticas especficas, la IMCM tambin define una serie de
cinco metas genricas y prcticas relacionadas con cada rea del proceso. cada una
de las metas genricas corresponde a uno de los cinco niveles de capacidad. Por lo
tanto, para lograr un nivel de capacidad particular se debe alcanzar la meta genrica para ese nivel y las prcticas genricas que corresponden a esa meta. Para ilustrar lo anterior, a continuacin se enumeran las metas genricas (MG) y las prcticas genricas (PG) para el rea del proceso de planeacin del proyecto [CMM02J:
MG 1 Alcanzar las metas especificas

PG 1.1 Realizar prcticas base.
MG 2 Institucionalizar un proceso de gestin
B#/H,iliIM1
Uoo itlfonnad6lt
cqmpleto; as CilfflO
~ Y8rsi6n 4spontie
11& lo IMCM peade
.,.,.
PG 2.1 Establecer una poltica organizacional.

PG 2.2 Planear el proceso.
PG 2.3 Proporcionar recursos.
PG 2.4 Asignar responsabilidades.
olltenelse en
PG 2.5 Capacitar gente.
www....-.
PG 2.6 Manejar configuraciones .

PG 2.7 Identificar y hacer participar a clientes.
PG 2.8 Monitorear y controlar el proceso.
PG 2.9 Evaluar la adherencia de un modo objetivo.
PG 2.1 O Revisar el estatus con un alto grado de gestin.
MG 3 Institucionalizar un proceso definido

PG 3.1 Establecer un proceso definido.
PG 3.2 Recolectar informacin de la mejora.
MG 4 Institucionalizar un proceso manejado en forma cuantitativa

PG 4.1 Establecer objetivos cuantitativos para el proceso.
PG 4.2 Estabilizar el desempeo del subproceso.
MG 5 Institucionalizar un proceso de mejoramiento.

PG 5.1 Asegurar la mejora continua del proceso.
PG 5.2 Corregir las causas de los problemas desde la raz
El modelo discreto de la IMCM define las mismas reas, metas y prcticas del proceso que el modelo continuo. La principal diferencia es que el modelo discreto establece cinco niveles de madurez, en vez de cinco niveles de capacidad. Para lograr un
nivel de madurez se deben conseguir metas y prcticas especficas relacionadas con
un conjunto de reas del proceso. La relacin entre los niveles de madurez y las
reas del proceso se muestran en la figura 2.4.
CAPiTuJ.0 2
~ La IMCM: se debe o no hacer?
La IMCM es un modelo total del proceso. Define (en alrededor de 700 pginas) las carader'.$JCXJS del proceso que deben existir si una organizacin
dl9eo establecer un proceso de software completo. La preg.nle que se ha debatido durante una dcada es la IMCM
es -=esiva? Como la mayor parte de las cosas en la vida (y
<m el. software) la respuesta no es un simple s o no.
Siempre debe adoptarse el espritu de la IMCM. Frente
riesgo de la simplificacin excesiva, se argumenta que el
~
lo del software debe tomarse con seriedad: debe
paneorse; debe controlarse de manera uniforme; debe
i:a:51r'earse con precisin; debe conducirse de manera pro
lm.onol. Debe centrarse en los necesidades de los clientes
oe proyecto, las habilidades de los ingenieros de software
'o calidad del producto terminado. Nadie debe poner en
i,do estas ideos.
Los requisitos detallados de la IMCM deben tomarse en
:::..ai1c con seriedad si una organizacin construye siste-
+mv11+
33
mas grandes y complejos que impliquen docenos o cientos

de personas por varios meses o aos. Es posible que la
IMCM seo correcta en ciertas situaciones, si la cultura organizacional es ffexible frente a modelos de procesos estndares y se realizo una gestin para lograr que sea un xito.
No obstante, en otras situaciones ~s posible que la
IMCM seo demasiado poro que una organizacin la asimile de manera exitosa. Esto significa que la IMCM es
mala o demasiado burocrtica o que est posada de mo
da? No. Tan slo significa que lo correcto para la culturo
de una compaa puede no serlo paro otra .
La IMCM es un logro significativo paro la ingeniera del
software. Proporciona una exposicin integral de las actividades y acciones que deben estor presentes cuando una
organizacin construye un software de computadora. Aun
si una organizacin de software elige no adoptar sus detalles, todo equipo de software debe retomar su espritu y
aprender de su exposicin del proceso y la prctica de la
ingeniera del software.
..-.asdel
Nival
Enfoque
poceso
mqueridas
De optimimcin
Mejoro
continua del
proceso
Innovacin organizacional y despliegue

Anlisis causal y resolucln
Gestionado de
modo cuantitativo
Gestin
cuantitativa
Ejecucin del proceso organizacional

Gestin cuantitativa del proyecto
para alcanzar
dvel de
mturez.
Definido
Gestionado
Ejecutado
Estandarizacin
del proceso
Gestin
bsica del
proyecto
.l
,-. del ,,__
Desarrollo de requisitos
Solucin tcnica
Integracin del producto
Verificacin
Validocin
Enfoque del proceso organizacional
Definicin del proceso organizacional
Capacitacin organizacional
Gestin integrada del proyecto
Gestin integrada del proveedor
Gestin del riesgo
Anlisis y resolucin de la decisin
Ambiente organimcional para la integracin
Equipo integrado
Planeacin del proyecto
Monitorea y control de l proyecto
Gestin de acuerdos del proveedor
Medicin y anlisis
Aseguramiento de la calidad del
producto y del proce so
Gestin de la configuracin
34
PARTE UNO
EL PROCESO DEL SOF'IWARE
del proceso?
El proceso de software puede definirse como una coleccin de patrones que definen
un conjunto de actividades, acciones, tareas de trabajo o comportamientos relacionados [AMB98] que requiere el desarrollo de un software de computadora. Dicho en
'
trminos generales, un patrn de proceso ofrece una plantilla: un mtodo consistente para describir una caracterstica importante del proceso de software. Mediante la
Qlles
patrn
combinacin de patrones, un equipo de software puede construir un proceso que satisfaga lo mejor posible las necesidades de un proyecto.
.......
le,.._ es muy '5liita ala repeticin de portes. Adems, las par11s . . . . . . . .
a.1 ,air
Los patrones pueden definirse en cualquier grado de abstraccin.6 En algunos casos se puede utilizar un patrn para describir un proceso completo (por ejemplo, un
prototipo). En otras situaciones se utilizan los patrones para describir una actividad
del marco de trabajo importante (como la planeacin) o una tarea dentro de una actividad del marco de trabajo (por ejemplo, la estimacin de un proyecto).
~,
~
C~YE
Uno ~ontillo del patrn
ofrece un medio
consistente poro
descbir un patrn.
Ambler [AMB98] propuso la siguiente plantilla para describir un patrn de proceso:
Nombre del patrn. Al patrn se le asigna un nombre significativo que describa su

funcin dentro del software (como comunicacin con el cliente).
Propsito. Se describe con brevedad el objetivo del patrn. Por ejemplo, el objetivo de la comunicacin con el cliente es "establecer una relacin de colaboracin
con el cliente en un esfuerzo encaminado a definir el alcance del proyecto, los requisitos del negocio y otras condiciones del proyecto". El propsito puede expandirse
con textos explicatorios adicionales y diagramas apropiados, si se requieren.
npo. Se especifica el tipo de patrn.
Ambler fAMB98J sugiere tres tipos:
Los patrones de tarea definen una accin de la ingeniera del software o

una tarea de trabajo que es parte del proceso y relevante para una prctica exitosa de la ingeniera del software (por ejemplo, la recopilacin de
requisitos es un patrn de tarea).
Los patrones de escenario definen una actividad del marco de trabajo para
el proceso. Debido a que una actividad del marco de trabajo rene mltiples tareas de trabajo, un patrn de escenario incorpora mltiples patrones de tarea relevantes para el escenario (actividad del marco de trabajo).
Un ejemplo del patrn de escenario es la comunicacin. Este patrn incorporara el patrn de tarea reunin de requisitos y otros.
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, JO, 12 y 14. Los patrones y "antipatrones" para
las actividades de gestin de proyectos se explican en la parte 4 de este libro.
CAPTULO 2
35
Los patrones de fase definen la secuencia de actividades del marco de trabajo que ocurre junto con el proceso, aun cuando el flujo general de actividades es iterativo por naturaleza. Un ejemplo de un patrn de fase puede
ser un modelo en espiral o de construccin de prototipos. 7
Contexto inicial. Se describen las condiciones en las cuales se aplica el patrn.

Antes de iniciar ste se debe cuestionar 1) qu actividades organizacionales o relativas al equipo han ocurrido, 2) cul es el estado de entrada para el proceso, y 3)
qu informacin de ingeniera del software o informacin del proyecto ya existe.
Por ejemplo, el patrn de planeacin (un patrn discreto) requiere que l) los
clientes y los ingenieros de software hayan establecido una colaboracin en cuanto
a comunicacin; 2) se haya completado con xito un gran nmero de patrones de
tarea (especificados) para el patrn de comunicacin con el cliente; y 3) seconozcan los alcances del proyecto, los requisitos bsicos del negocio y las restricciones del proyecto.
Problema. Se describe el problema que debe resolver el patrn. Por ejemplo, el problema que debe resolver la comunicacin con el cliente puede describirse de la
siguiente manera: La comunicadn entre el desarrolladory el cliente muchas veces es
inadecuada porque no se est.ablece un formato efectivo para obtener infonnadn, no se
crea. un mecanismo til para registrarla, y no se realiza una revisin significativa.
Solucin. Se describe la implementacin del patrn. En esta seccin se discute cmo el estado inicial del proceso (existente antes de que se haya implementado el
patrn) se modifica como consecuencia del inicio del patrn. Tumbin se describe
cmo la informacin de la ingeniera del software o la informacin del proyecto,
disponible antes de iniciado el patrn, se transforma como consecuencia de la ejecucin exitosa del patrn.
Contexto resultante. Se describen las condiciones que habr una vez que el patrn haya sido implementado con xito. Para completar el patrn deben realizarse
las siguientes preguntas: l) qu actividades organizacionales o relacionadas con
el equipo debieron haber ocurrido?, 2) cul es el estado de salida para el proceso?, y 3) qu informacin de la ingeniera del software o informacin del proyecto
ha sido desarrollada?
Patrones relacionados. Se proporciona una lista de todos los patrones de proceso directamente relacionados con ste, en forma jerrquica o de alguna otra forma.
Por ejemplo, el patrn estacionario de comunicacin abarca los patrones de tarea
reunin del equipo para el proyecto, definicin de una linea de colaboracin, aislamiento de alcances, reunin de requisitos, descripcin de restricciones y una creacin de un modelo mini-spec.
Estos patrones de fase se exponen en el captulo 3.
36
PARTE UNO EL PROCESO DEL SOF'IWARE
Usos conocidos/ Ejemplos. Se indican los ejemplos especficos en los cuales el

patrn es aplicable. Por ejemplo, la comunicacin es obligatoria al principio de
cada proyecto de software; se recomienda por medio del proceso de software, y es
obligatoria una vez que la actividad de despliegue est realizada.
Mhiiilrn1
S pueden entootrot
fuentes extensos sobr~
los patrones del

proceso en
www.11mbysoft.
COlll/ p(OteS$
PatternsPagt.hlllll.
Los patrones de proceso proporcionan un mecanismo efectivo para describir

cualquier proceso de software. Los patrones permiten una organizacin de ingeniera del software para desarrollar un descripcin del proceso jerrquico que comience en un alto grado de abstraccin (un patrn de fase). La descripcin se refina hasta
un conjunto de patrones estacionarios que describen actividades del marco de trabajo, y ms tarde se refina de un modo jerrquico en patrones de tareas ms detallados para cada patrn estacionario. Despus de que se han desarrollado los patrones
de proceso, pueden reutilizarse para la definicin de variantes de proceso; es decir,
un equipo de software puede definir un model o de proceso personalizado usando
patrones como bloques de construccin para el modelo de proceso .
.~ Ejemplo de un patrn del proceso
~ El siguiente patrn de proceso abreviado des-
cribe un enfoque aplicable cuando los clientes

tienen una idea general de lo q ue de be hacerse, pero no
estn seguros de los requisitos especficos del software.
Nombre del patrn. Prototipo.

Propsito. El objetivo del patrn es construir un modelo
(un prototipo) que los dientes evalen de modo iterativo
en un esfuerzo encaminado a identificar los requisitos
del software.
Tipo. Patrn de fase.
Contexto inicial. Deben cumplirse las siguientes condiciones antes de iniciar este patrn: 1) los dientes han
sido identificados; 2) se ha establecido un modo de comunicacin entre los clientes y el equipo de trabajo; 3)
los clientes han identificado el problema que ha de resolverse; 4) se ha desarrollado un entendimiento inicial
del alcance del proyecto, los requisitos bsicos del negocio y las restricciones del proyecto.
Problema. Los requisitos son vagos o no existen. No
obstante, se reconoce con claridad la existencia de un
problema, y ste debe ir acompaado de una solucin
de software. Los clientes no estn seguros de lo que desean; es decir, na pueden describir ningn detalle de
los requisitos del software.
Solucin. Aqu se presenta una descripcin del proceso
de prototipo. Para ms detalles, vase el captulo 3.
Contexto resultonte. Los clientes aprueban un prototi
pode software que identifica requisitos bsicos (par
ejemplo, modelos de interaccin, rasgos computaciona
les, funciones de procesamiento). Despus 1) el prototi
po puede evolucionar recorriendo una serie de
incrementos poro convertirse en el software de produc
cin, o 2) el prototipo se descarta y el software de produccin se construye con otros patrones de proceso.
Patrones relacionados. Los siguientes patrones estn
relacionados con este patrn: comunicacin con
el cliente; diseo iterativo; desarrollo iterativo; evaluacin del cliente; extraccin de

requisitos.
Usos conocidos/ ejemplos. El prototipo se recomien
da cuando los requisitos son inseguros.
2.5 EyALyAcrN QEL eaocgso

La existencia de un proceso de software no es garanta de que ste ser entregado
a tiempo, de que satisfar las necesidades del cliente, o de que mostrar las caractersticas tcnicas que conducirn a caractersticas de calidad a largo plazo (captulo 26). Los patrones de proceso deben ir acompaados de una prctica slida de la
CAPTULO 2
37
ifr!idi
Es examinada par
Identifico
modificaciones a
Evaluacin del
proceso de software
Mejoramiento del
proceso de software------ - - -- - - - - - !
Determinacin
de la capacidad
Motivo
b b e't'Dluocin se
;J'ftlllOO comprender
es1Cdo actual del

p-:eso de software y
2 l!len!o mejorarlo.
De qu
tmicas
fwaalesse
~
para
fflllllcn, el proceso
.ttware?
ingeniera del software (parte 2 de este libro). Adems, el proceso mismo debe evaluarse para asegurarse de que cumpla una serie de criterios bsicos del proceso que
han demostrado ser esenciales para una ingeniera de software exitosa. 8 La relacin
entre el proceso de software y los mtodos aplicados para la evaluacin y el mejoramiento se muestra en la figura 2.5. Se han propuesto varios enfoques para la eva-
luacin del proceso de software en las dcadas pasadas:

El mtodo de evaluacin de la IMCM estndar para el m ejoramiento del
proceso (MEIEMP)ofrece un modelo de cinco pasos para la evaluacin del proceso que incluye la iniciacin, el diagnstico, el establecimiento. la accin y el aprendizaje. El mtodo MEJEMP utiliza el SEl IMCM (seccin 2.3) como base para la evaluacin [SEIOOJ.
La apreciacin basada en el CMM para el mejoram i ento del proceso interno (ABC MPI) ofrece una tcnica de diagnstico para evaluar la madurez relativa de una organizacin de software mediante la ABC MPI (un precursor de la IMCM,
el cual se explic en la seccin 2.3) como base para la evaluacin [DUNOlJ .
El estndar SPICE (ISO/ IEC 15504 ) define un conjunto de requisitos para la
evaluacin del proceso de software; lo que pretende es ayudar a las organizaciones
en el desarrollo de una evaluacin objetiva de la eficacia de cualquier proceso de
software definido [SPl99J.
El ISO 900 1:2000 para software es un estndar genrico que se aplica a cualquier organizacin que desee mejorar la calidad general de los productos, sistemas
8
La JMCM del SEi tCMM02] describe, en detalle y con amplitud, las caractersticas de un proceso de
software y los criterios para un proceso exitoso.
38
PARTE UNO
o servicios que provee. Por lo tanto, el estndar se aplica de modo directo a compaas y organizaciones de software.
Debido a que el ISO 900 l :2000 se usa de manera amplia en el mbito internacional,
se examinar con brevedad en los prrafos que siguen.
"tas o,ganlzodones de softwore han mostrodo deficiencias significativos en su habiliclotf para aJtlilalizef los ...-.
ckls tllRadas en froyedos completos.
'!.
La Organizacin Internacional de Estandarizacin (ISO, por sus siglas en ingls)

ha establecido el estndar ISO 900 l :2000 (ISOOO] para definir los requisitos de un
sistema de gestin de calidad (captulo 26) que sirva para elaborar productos de ms
alta calidad y as mejorar la satisfaccin del cliente. 9
La estrategia fundamental que sugiere el ISO 900 I :2000 se describe de la siguiente manera:
El ISO 9001 :2000 subraya la importancia que tiene para una organizacin identificar, implementar, gestionar y mejorar de manera continua la efectividad de los procesos necesarios para el sistema de administracin de la calidad, y gestionar las interacciones de estos
1-filf:ifrh':;1
Un excelenlt resumen
de.! ISO 9001:2000
~encoomiisei
http://prult&
<Ofl/$
9001.i..
procesos para conseguir los objetivos de la organizacin...
El ISO 900 l :2000 ha adoptado un ciclo de "planear-hacer-revisar-actuar" que se aplica a los elementos de gestin de calidad de un proyecto de software. Dentro de un
contexto de software, "planear" establece los objetivos, las actividades y tareas del
proceso necesarios para conseguir un software de alta calidad y una satisfaccin
del cliente; "hacer" implementa el proceso de software (incluidas las actividades del
marco de trabajo y las actividades sombrilla); "revisar" monitorea y mide el proceso
para asegurarse de que todos los requisitos establecidos para la gestin de calidad
hayan sido cumplidos; "actuar" inicia las actividades de mejoramiento del proceso de
software, el cual tiene una continuidad de trabajo para mejorar el proceso.
Para un tratamiento ms detallado del ISO 9001 :2000 los lectores interesados en
el tema deben consultar los estndares ISO o [CIAO 1l, [KETO l] o [MONO l J.
El mejor proceso de software es el que est cerca de la gente que realizar el trabajo.
Si un modelo de proceso de software ha sido desarrollado en un mbito corporativo
u organizacional, puede ser efectivo slo si es en gran medida adaptable para satisfacer las necesidades del equipo del proyecto, que es el que en realidad lleva a cabo
el trabajo de ingeniera del software. En un escenario ideal, cada ingeniero de software creara un proceso que llene lo mejor posible sus propias necesidades, y al mis9 El aseguramiento de la calidad del software (ACSJ, un elemento importante de la gestin de calidad,
ha sido definido como una actividad sombrilla que se aplica a travs de todo el marco de trabajo del
proceso. Se expone en detalle en el captulo 26.
CAPITULO 2
39
mo tiempo satisfaga las amplias necesidades del equipo y la organizacin. De modo

alternativo, el equipo mismo crearla su propio proceso, y al mismo tiempo cubrirla
las necesidades ms reducidas de los individuos y las necesidades amplias de la organizacin. Watts Humphrey ([HUM97J y [HUMOOJ) argumenta que es posible crear
un "proceso de software personal" o un "proceso de software en equipo". Ambos requieren de un arduo trabajo, capacitacin y coordinacin, pero ambos se pueden
conseguir. 10
,,.,... . . lilne xito slo se ho formado el hbito de hacer las cosos que la gente sin ixlo
. . . . . . . . !
.,
2.6.1
Proceso de software personal (PSP)
Cada desarrollador utiliza algn proceso para construir un software de computadora. El proceso puede ser fortuito o ad hoc, puede cambiar a diario, puede no ser eficiente, efectivo o hasta exitoso, pero existe un proceso. Watts Humphrey [HUM97]
sugiere que para cambiar un proceso personal inefectivo, un individuo debe pasar
por cuatro fases, en las cuales se requiere capacitacin e instrumentacin cuidadosa. El proceso de software personal (PSP) resalta la medida personal del producto de
trabajo que se produce y la calidad resultante del producto de trabajo. Adems, el
PSP responsabiliza al profesional encargado de la planeacin del proyecto (por ejemplo, la estimacin y la planificacin) y Je confiere el poder de controlar la calidad de
todos los productos de trabajo del software que se desarrollan.
El modelo PSP define cinco actividades del marco de trabajo: planeacin, diseo
de alto nivel, revisin del diseo de alto nivel, desarrollo y anlisis de resultados.
C. ecttvl-
Planeacln. Esta actividad selecciona requisitos y, con base en stos, desarrolla
alza
el tamao y la estimacin de los recursos. Adems, se estiman los defectos (el nmero de defectos proyectado en el trabajo) . Todas las mediciones se registran en hojas de trabajo o en plantillas. Al final, se identifican las tareas de desarrollo y se crea
un programa del proyecto.
-.s del
.-..a1rabao
PSI'?
Diseo de alto nivel. Se elaboran las especificaciones externas para que cada
componente sea construido y se crea un diseo del componente. Se construyen prototipos cuando existe incertidumbre. Todos los elementos se registran y rastrean .
Revisin del disefio de alto nivel. Los mtodos formales de verificacin (captulo 26) se aplican a errores descubiertos en el diseo. Las mediciones se mantienen
para todas las tareas importantes y los resultados de trabajo.
Desarrollo. El diseo al nivel de componente se refina y revisa. Se genera, revisa, compila y prueba el cdigo. Las mediciones se mantienen para todas las tareas
importantes y los resultados de trabajo.
lo Vale la pena mencionar que los proponentes del desarrollo gil del software (captulo 4) tambin ar-
gumentan que el proceso debe pennanecer cerca del equipo. Ellos proponen un mtodo alternativo
para lograrlo.
40
PARTE UNO
Anlisis de resultados. Mediante las mediciones y medidas recolectadas (una

cantidad sustancial de datos debe analizarse de manera estadstica) se determina la
efectividad del proceso. Las mediciones y medidas deben ofrecer una gua para modificar el proceso y as mejorar su efectividad.
,re.,
~~
c&vE
El PSP destoco lo
necesidad de registrar
y onolizor los hpos de
errores que se
cometen poro
desouollor estrategias
encominodos o
eliminarlos.
El PSP destaca la necesidad que tiene cada ingeniero de software de identificar los
errores desde el principio y la importancia de entender los tipos de errores que suele cometer. Esto se lleva a cabo mediante una actividad de evaluacin rigurosa aplicada en todos los productos de trabajo que genera el ingeniero de software.
El PSP representa un enfoque disciplinado, basado en mediciones, de la ingeniera de software que puede conducir a un choque de culturas a muchos profesionales. Sin embargo, cuando el PSP se presenta de un modo adecuado a los ingenieros
de software [HUM96L la mejora resultante en la productividad de la ingeniera del
software y la calidad de ste son significativas [FER97]. No obstante, la industria no
ha adoptado con amplitud el PSP. Las razones, tristemente, tienen ms relacin con
la naturaleza humana y la inercia organizacional que con las fuerzas y debilidades
del enfoque del PSP. Este ltimo es un reto intelectual y demanda un grado de compromiso (por parte de los profesionales y sus jefes) que no siempre es posible obtener. La capacitacin es relativamente larga y sus costos son altos. En lo cultural, el
grado requerido de medicin es dificil para mucha gente involucrada con el software.
Una interrogante es s1 el PSP puede usarse como un proceso de software efectivo
a un nivel personal. La respuesta es, sin duda, s. Pero aun si el PSP no es adoptado
en su totalidad, vale la pena estudiar muchos de los conceptos de mejora del proceso que ste presenta.
e1 mn,m,
j,\(J, ROllll}O 1 ~ 6
lo conmuccioo de
equipos de alto
desempeo empleando
el PSE y el PSP puede
obtenerse en
w-.stl.<11111.
2.6.2 Proceso de software en equipo (PSE)

Debido a que muchos proyectos de software en el mbito industrial los dirige un equipo de profesionales, Watts Humphrey extendi las lecciones aprendidas para la introduccin del PSP y propuso un proceso de software en eqwpo (PSE). La meta del PSE es
construir un equipo de proyecto "autodirigido" que se organice para producir un software de alta calidad. Humphrey [HUM98] define los siguientes objetivos del PSE:
fts,/.
Construir equipos autodirigidos que planeen y tengan un seguimiento de su
trabajo. establezcan metas y posean sus procesos y planes. Estos grupos
pueden ser equipos de software puros o equipos de producto integrado
(EPI) de 3 a 20 ingenieros.
Mostrar a los jefes cmo preparar y motivar a sus equipos y cmo ayudarlos a sostener un alto desempeo.
Acelerar el mejoramiento del proceso de software al realizar, con el comportamiento normal y esperado, el nivel 5 del MCM.
Ofrecer una gua de mejoramiento a organizaciones de alta madurez.
CAPTULO 2
41
Facilitar la enseanza universitaria de habilidades de equipo industrial de

calidad.
Un equipo autodirigido entiende en forma consistente sus metas y objetivos generales. Define funciones y responsabilidades para cada uno de sus miembros; re
gistra datos cuantitativos del proyecto (como productividad y calidad); identifica un
proceso de equipo apropiado para el proyecto y una estrategia para implementar el proceso; define estndares locales aplicables al trabajo de ingeniera de software del
equipo, evala en cada momento riesgos y reacciones; y registra, gestiona y reporta
el estatus del proyecto.
"&lcontrar buenos ugodores es fcil. Hacer que jueguenenequipoes otro historio." '
CaeyS......
'
c{Av1
El PSE define las siguientes actividades del marco de trabajo: lanzamiento, diseo
de alto nivel, implementacin, integracin y prueba, y anlisis de resultados. Al igual
que sus contrapartes en el PSP (ntese que la terminologa es diferente), estas actividades permiten al equipo planear, disear y construir un software de una manera disciplinada al mismo tiempo que miden de modo cuantitativo el proceso y el producto.
Los anlisis de resultados muestran el escenario para el mejoramiento del proceso
El PSE utiliza una amplia variedad de escritos, formas y estndares que sirven para
guiar a los miembros del equipo en su trabajo. Los escritos definen actividades espe
cficas del proceso (por ejemplo, lanzamiento, diseo. implementacin, integracin
y prueba, y anlisis de resultados del proyecto) y otras funciones ms detalladas del
trabajo (como planeacin del desarrollo, desarrollo de requisitos, gestin de la configuracin de software y prueba de unidad) que son parte del proceso del equipo.
Con fines ilustrativos, es til tomar en cuenta la actividad inicial del proceso: el lan-
zamiento del proyecto

cada proyecto es "lanzado" con una secuencia de tareas (definida como un escrito) que permite al equipo establecer una base slida para iniciar el proyecto. Se recomienda el siguiente escrito de lanzamiento (slo de manera general) [HUMOOJ
Revisar los objetivos del proyecto con la gestin y acordar y documentar
las metas del equipo.
Establecer las funciones del equipo.
Definir el proceso de desarrollo del equipo.
Elaborar un plan de calidad y plantear los objetivos de calidad.
Preparar un plan para las necesidades de soporte necesarias.
Producir una estrategia de desarrollo general.
Elaborar un plan de desarrollo para el proyecto en su totalidad.
Hacer planes detallados para cada ingeniero en la siguiente fase.
Adaptar los planes individuales a un plan de equipo.
42
PARTE UNO
Hacer un balance de la cantidad de trabajo del equipo para obtener un programa mnimo en trminos generales.
Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para
cada riesgo clave.
Es importante sealar que la actividad de lanzamiento puede aplicarse antes de ca-
da actividad del marco de trabajo del PSE, el cual se explic prrafos atrs. Esto se
ajusta a la naturaleza iterativa de muchos proyectos y permite que el equipo se adapte a las necesidades cambiantes del cliente y a las lecciones aprendidas de actividades previas.
El PSE reconoce que los mejores equipos de software son autodirigidos. Los
miembros del equipo plantean los objetivos del proyecto, adaptan el proceso para
cubrir sus necesidades, controlan el programa y la medicin y el anlisis de las medidas recolectadas; adems, trabajan de manera continua para mejorar el enfoque
del equipo respecto de la ingeniera del software.
Al igual que el PSP. el PSE es un enfoque riguroso para la ingeniera del software
que ofrece beneficios distintos y cuantificables en productividad y calidad. El equipo
debe comprometerse con el proceso y debe recibir capacitacin para asegurarse de
que el enfoque se aplique de manera apropiada.
Los modelos genricos de proceso tratados en las secciones precedentes deben

adaptarse para que los utilice un equipo de proyecto de software. Para lograrlo se
han desarrollado herramientas de tecnologa del proceso destinadas a ayudar a las organizaciones de software a analizar sus procesos actuales, organizar sus tareas,
controlar y monitorear su progreso, y administrar su calidad tcnica [NEG99].
Las herramientas de tecnologa del proceso permiten que una organizacin de
software construya un modelo automatizado del marco de trabajo comn del proceso, de los conjuntos de tareas y las actividades sombrilla explicadas en la seccin
2.2. El modelo, que a menudo se representa como una red, entonces puede analizarse para determinar el flujo de trabajo tpico y examinar las estructuras de proceso alternativas que podrian conducir a la reduccin del tiempo o costo del desarrollo.
Una vez creado un proceso aceptable es posible utilizar otras herramientas de
tecnologa del proceso para localizar, monitorear e incluso controlar todas las tareas
de ingeniera del software definidas como una parte del modelo del proceso. cada
miembro del equipo de software puede emplear dichas herramientas en la elaboracin de una lista de verificacin de las tareas de trabajo que se deben desarrollar, los
productos del trabajo que es imperativo producir, y las actividades para el aseguramiento de la calidad que deben realizarse. La herramienta de tecnologa del proceso tambin se puede aprovechar para coordinar el uso de otras herramientas de la
ingeniera del software asistida por computadora que sean apropiadas para una tarea de trabajo particular.
CAPTULO 2 a PROCESO: UNA VISIN GENERAL
43
HenamJentas de modelado del
proceso
'
Obetivo: Si una organizacin trabajo en el

mejoromien1o de un proceso de un negocio (o de un software el primer objetivo es entendeoo. Los herramientas de
:idelodo del proceso (tambin llamados lecnologa del
p,oc:mo o herromienlos de gestin del proceso) se utilizan
pero representar los elementos clave de un proceso para
~ sle puedo entenderse con mayor claridad. Tales herra
~ tambin ofrecen vnculos con descripciones del pro~ que ayudan o quienes se interesen en el proceso a
ll'llllnder las acciones y los lareos de trabajo necesarias pa
CD desarrollooo. los herramienlos de modelocin del p ~
s:, prap<>fConan vnculos can otros hen-omientos que
el:-, sopor1e o octividades definidos del proceso.
IIKnica: Los herromien1os de esto cotegoro permiten
equipa definir los elementos de un modelo del proceso
nico (acciones, toreos, productos de trabajo), ofrecen una

gua detalloda del contenido o lo descripcin de codo ele
mento del proceso, y despus gestionan el proceso mien
Iras se conduce. En algunos casos los herramientas de
tecnologa del proceso incorporan tareas de gestin del
proyecto eslndor, como estimacin, itinerario, rastreo y
control.
HerTamientas representativas:11
/grabe Process Tools, distribuidas par Corel Corporotion
(www.igrafx.com/products/process), es uno serie de
herramientas que permiten al equipa organizar, medir
y modelar el proceso de software.
Objexis Team Porto/, desarrollado par Objexis Corparotion

(www.abjexis.com), proporciona lo definicl6n y el con
trol completos del Rujo de trabajo del proceso.
Si el proceso es dbil, sin duda el producto final sufrir las consecuencias. Asimismo, una confianza excesiva en el proceso es peligrosa. En un breve ensayo Margaret Davis [DAV95) comenta sobre la dualidad del producto y el proceso:
Alrededor de cada diez aos, a veces cada cinco, la comunidad del sollware redefine "el
problema" cambiando su enfoque de los aspectos del producto a los asuntos del proceso
Entonces se han obtenido lenguajes de programacin estructurados (producto) seguidos
por mtodos de anlisis estructurado (proceso) y encapsulacin de datos (producto), as[
como el nfasis actual en el Modelo de Madurez de Capacidad para el Desarrollo de SOllware del Instituto de lngenierla del Software (proceso) (seguidos por los mtodos orienta
dos a objetos y el desarrollo gil de sollwareJ.
Mientras la tendencia natural de un pndulo es llegar al reposo en el punto medio en
tre dos extremos, el objetivo de la comunidad del sollware cambia en forma constante
porque cada vez que una oscilacin termina se aplica una nueva fuerza. Estas oscilacio
nes son nocivas en si mismas porque confunden al profesional promedio del software con
los cambios radicales en el significado de hacer el trabajo o dejar que ste se desarrolle
solo. Las oscilaciones tampoco resuelven "el problema", puesto que estn destinadas a fallar mientras el producto y el proceso sean tratados como si formaran una dicotoma en
lugar de una dualidad.
11 Las herramientas mencionadas aqu representan una muestra de esta categora. En la mayorla de
los casos los nombres son marcas registradas de sus respectivos desarrolladores.
44
PARTE UNO
Existen precedentes en la comunidad cientfica hacia las nociones de dualidad, cuando las contradicciones en las observaciones no se pueden explicar por completo con una
u otra teora competidora. La naturaleza dual de la luz. la cual parece ser en forma simultnea una particula y una onda, ha sido aceptada desde la dcada de 1920, cuando LOuis
de Broglie la propuso. Creo que las observaciones posibles sobre los artefactos del software y su desarrollo demuestran una dualidad fundamental entre el producto y el proceso. No se puede llegar a entender el artefacto completo, su contexto, uso, signiflcado y
valor si slo se ve como un proceso o nicamente como un producto .
Todas las actividades humanas pueden verse como un proceso, pero cada ser humano tiene un sentido de autovaloracin de aquellas actividades que generan una representacin que puede emplear o apreciar ms de una persona, emplear una y otra vez, o
aprovechar en algn otro contexto. Es decir, el ser humano encuentra placer en reutilizar
sus productos y en que otros los reutilicen.
Por lo tanto, mientras la rpida asimilacin de reutilizar metas en el desarrollo de software aumenta de manera potencial la satisfaccin que experimentan los profesionales de
su trabajo, tambin aumenta la urgencia de aceptacin de la dualidad del producto y el
proceso. Considerar un artefacto reutilizable como slo un producto o slo como un proceso oscurece el contexto y las maneras de utilizarlo, u oscurece el hecho de que cada uso
resulta en un producto que, a su tiempo, se aprovechar como entrada a alguna otra actividad de desarrollo de software. Poner un punto de vista sobre el otro reduce en forma
sustancial las oportunidades de reutilizar y. por lo tanto, pierde la oportunidad de incrementar la satisfaccin del trabajo.
'*
el sisllnlD ideal, si se pudiera obtenet, serio un cdigo Ion flexible y dinimo COIIIO ~ prMS par ...
dpllle mile sihNKin concebible uno regla exacto. Pero lo vida es demasiado (omplejo para . _ 1511 illa
inda ton tDclo el poder humano.
"Sil
La gente obtiene tanta (o ms) satisfaccin del proceso creativo que del producto final. Un pintor disfruta los trazos del pincel tanto como el resultado del cuadro.
Un escritor disfruta la bsqueda de una metfora apropiada tanto como el libro terminado. Un profesional del software creativo debe sentir tanta satisfaccin del proceso como del producto terminado.
El trabajo que realiza la gente de software cambiar en los aos que siguen. La
dualidad del producto y el proceso es un elemento importante para mantener a la
gente creativa comprometida mientras finaliza la transicin desde la programacin
hasta la ingenieria del software.
La ingeniera del software es una disciplina que integra al proceso, los mtodos y las
herramientas para el desarrollo del software de computadora. Se ha propuesto un
gran nmero de modelos de proceso para la ingeniera del software, pero todos definen un conjunto de actividades del marco de trabajo, una coleccin de tareas con-
CAPTULO 2
45
ducidas para realizar cada actividad, productos de trabajo generados como consecuencia de las tareas y un conjunto de actividades sombrilla que acompaan el proceso entero. Los patrones de proceso pueden aprovecharse para definir las caractersticas del mismo.
La integracin del modelo de capacidad de madurez (IMCM) es un modelo total
del proceso, que describe las metas, prcticas y capacidades especficas con que de
be contar un proceso de software maduro. El SPICE y otros estndares definen los
requisitos para guiar una evaluacin del proceso de software, y el estndar ISO
9001 :2000 examina la gestin de la calidad dentro de un proceso.
Se han propuesto los modelos personal y en equipo para el proceso de software.
Ambos destacan la medicin, la planeacin y la autodireccin como ingredientes
clave para un proceso de software exitoso.
Los principios, conceptos y mtodos que permiten realizar el proceso llamado ingeniera del software sern considerados en el resto de este libro.
[AMB98) Ambler, S., Process Patterns: Building Large-Sca/e Systems Using Object Technology,
Cambridge University Press/SIGS Books, 1998.
[BAE98) Baetjer, Jr., H., Software as Capital, IEEE Computer Society Press, 1998, p. 85.
[CIAOll Cianfrani, c. et al., ISO 9001:2000 Explained, American Society of Quality, 2001.
[CMM02J capability, Maturio,, Model Tntegration (CMMI), Versin 1.1, Software Engineering Institute,
marzo de 2002, disponible en http://www.sei.cmu.edu/cmmi/.
[DAV95] Davis, M., "Process and Product: Dichotomy or Duality", en software Engmeering Notes,
ACM Press, vol. 20, nm. 2, abril de 1995, pp. 17-18.
(DUNOl)Dunaway. D. y S. Masters, CMM-Based Appraisa/for Interna/ Process Improvement(CBA /PI
Version J.2 Method Description, Software Englneering 1nstitute, 2001, puede descargarse de
http:/ /www.sei.cmu.edu/publications/documents/0l.reports/01 tr033.html
[ELE98J El Emam, K., J. Drouin y w. Melo (eds.), SPICE: The Theory and Pract1ce o/Software
Process Improvement and Capability Determinalion, IEEE Computer Society Press. 1998.
[FER97] Ferguson, P. et al , "Results of applying the personal software process", en IEEE
Computer, vol 30, nm 5, mayo de 1997, pp. 24-31.
(HUM96J Humphrey, W., "Using a Defined and Measuted Personal Software Process", en IEEE
SOflware, vol. 13, nm. 3, mayo-junio de 1996. pp. 77-88.
(HUM97J Humphrey, W., Jntroduction to the Personal Software Process, Addison-Wesley, 1997.
(HUM98J Humphrey, w, NThe Three Dimensions of Process Improvement, Part 111: The Team
Process", en Crosstalk, abril de I 998. Disponible en http://www.stsc.hill.af.mil/crosstalk/
1998/apr/dimensions.asp.
(HUMOOJ Humphrey, w., lntroduclion to the Team software Process, Addison-Wesley, 2000.
(IEE93) IEE Standards Co/lection: software Engineering, IEE Standard 6 I 0.12-1990, IEEE, 1993.
[ISOOOJ ISO 9001 2000 Document Sel, lntemational Organization for Standards, 2000, http:/ /
www.iso.ch/iso/en/iso9000-l 4000/ iso9000/ 9000isoindex.html.
[ISOOIJ "Guidance on the Process Approach to Quality Management systems", Document
JSO/TC l 76/SC2/N544R, lnternational Organization for Standards, mayo de 2001
[KETOIJ Ketola, J. y K. Roberts, ISO 9001:2000 in a Nutshe/1, 2a. ed., Paton Press, 2001.
[MONO!) Monnich, H.,Jr. y H. Monnich, lSO 9001 :2000 for Small-and Medium-Sized Businesses,
American Society of Quality, 2001.
(NAU69J Naur, P y B. Randall (eds.), SOjtware Engineering A Report on a Conference Sponsored
by the NATO Sdence Comltlee, NATO, 1969.
[NEG99J Negele, H., "Modeling of Integrated Product Development proceses", Proc. 9th Annual
Symposium of!NCOSE, Reino Unido, 1999.
46
PARTE UNO
[PAU93] Paulk, M. et al.. Capability Maturity ModelJor Software, Software Engineering lnstitute,
Camegie Mellon University, Pittsburgh, PA, 1993.
[PHI02) Phillips, M., "CMMI V 1.1 Tutora!", abril de 2002, disponible en http:/ /www.sei.cmu.
edu/cmmi/.
[SEIOOJ SCAMPI, VI.O Standard CMMI Assessment Methodfor Process Improvement: Method
Description, Software Engineering Institute, Technical Report CMU/SEI-2000-TR-009,
disponible en http/ /www.sei.cmu.edu/publications/documents/OO.reports/00tr009.html
ISPI99] "SPICE: Software Process Assessment, Part 1: Concepts and Introduction". Versin 1.0,
ISO/IEC JTCI, 1999.
2. 1. En la introduccin a este captulo, Baetjer puntualiza: "El proceso ofrece una interaccin
entre usuarios y diseadores, entre usuarios y herramientas en evolucin, entre diseadores y
herramientas en evolucin [tecnologa]". Hganse cinco preguntas respecto a a) lo que los diseadores deben preguntar a los usuarios; b) los usuarios deben preguntar a los diseadores;
e) lo que los usuarios deben preguntarse a s mismos sobre el producto de software que se
construir: y d) lo que los diseadores deben preguntarse a s mismos sobre el producto de
software que se construir y el proceso que se utilizar para hacerlo.
2.2. En la figura 2.1 se colocan los tres estratos de ingeniera del software arriba de un estrato titulado "un enfoque en la calidad". Esto implica un programa de calidad de una organizacin amplia 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 actividades genricas del proceso de ingeniera del soft-
ware no se apliquen? Si es as, descrbase.

2.4. Las actividades sombrilla ocurren a lo largo de todo el proceso del software. Se aplican
de modo uniforme a travs del proceso o algunas estn concentradas en una o ms actividades del marco de trabajo?
2.5. Descnbase un marco de trabajo del proceso con palabras propias. Cuando se dice que las
actividades del marco de trabajo son aplicables a todos los proyectos, esto significa que las mismas tareas de trabajo se aplican a todos los proyectos, sin importar el tamao y complejidad?
Explquese la respuesta.
2.6. Intente establecer un conjunto de tareas para la actividad de comunicacin.
2.1. Investigar un poco ms acerca de la IMCM y discutir las ventajas y desventajas de los modelos de la IMCM continuo y discreto.
2.8. Desplegar la documentacin de la JMCM del sitio de la red del SEi y seleccionar un rea del
proceso que no sea la planeacin del proyecto. Hacer una lista de las metas especficas (ME) y de
las prcticas especficas (PE) asociadas que se definan mediante el rea que se haya elegido.
2 .9. Considerar la actividad de comunicacin dentro del marco de trabajo. Desarrollar un patrn completo del proceso (podra ser un patrn discreto) aprovechando los principios descritos en la seccin 2.4.
2. 10. Cul es el propsito de la evaluacin del proceso? Por qu el SPJCE ha sido desarrollado como un estndar para la evaluacin del proceso?
2 . 11 . Investigar ms sobre el PSP y preparar una breve presentacin que indique los benefi-
cios cuantitativos del proceso.

2. 12. La utilizacin de "escritos" (un mecanismo requerido en el PSE) no goza de gran aceptacin entre la comunidad del software. Hacer una lista de las ventajas y desventajas mientras se
toman en cuenta los escritos y sugerir al menos dos situaciones en que seran tiles y otras dos
situaciones en donde no tendran tantos beneficios.
CAPTULO 2
47
El estado actual de la ingeniera del software y el proceso de software lo determinan bien

publicaciones mensuales como IEEE SOjlware, Computer, y IEEE rt-ansactions on Software Engi
neering. Publicaciones peridicas como Application Development rt-ends y Cutter IT Joumal a
menudo contienen artculos sobre temas de ingeniera del software. La disciplina se "resume"
cada ao en la Proceedmg of the Intemational Conference on software Engineenng, patrocinado
por el IEEE y ACM, y se discute a profundidad en publicaciones como ACM n-ansactions on
Software Engineering and Melhodo/ogy, ACM Software Engineering Notes y Annals of Sojlware
Engineering. Miles de pginas de la red estn dedicadas a la ingeniera del software y al
proceso de software.
En los aos recientes se han publicado muchos libros referentes al proceso de sollware y a
la ingenierla del software. Algunos presentan un panorama del proceso en su totalidad,
mientras otras centran su atencin en unos cuantos temas importantes y excluyen otros. Entre
las propuestas ms populares se encuentran:
Abran, A. y J. Moore, SWEBOK Gwde to the software Engineerng Body of Knowledgc, IEEE,
2002
Ahern, O, etal., CMMI Distilled, Addison-Wesley, 2001.
Chrisis, B et al. CMMI. GwdelinesJor Process Jntegraton and Product lmprovement, AddisonWesley, 2003.
Chrstensen, M. y R. Thayer, A Project Manager'S Guide to Sojlware Engineering Best Pracliccs.
IEEE-CS Press (Wiley), 2002.
Glass, R., Fact and Fal/acies oJSOftware Engineerng, Addison -Wesley, 2002
Hunter, R. y R. Thayer (eds.). SOftware Process Improvement, IEEE-CS Press (Wiley), 200 I.
Persse, J., lmplemeneing the Capability Maturity Mode/, Wiley, 2001.
Plleeger, S., Software Engmeering Theoryand Practice, 2a. ed, Prentice-Hall, 2001.
Potter, N y M. Sakry, Making Process lmprovcmcnt Work, Addlson-Wesley, 2002.
Sommerville, l., Software Engineering, 6a. ed., Addison-wesley, 2000
En lo que respecta a lecturas ms ligeras. un libro de Robert Glass (Software Con{Jict.
Yourdon Press, 1991) presenta ensayos sorprendentes y controversiales sobre el software y el
proceso de ingenierla del sollware. Yourdon (Deach March ProJects, Prentice-Hall, 1997) expone
lo que sale mal cuando fallan grandes proyectos de software y cmo evitar esos errores.
Garmus (Measuring lhc Software Process, Prcntice-flall, 1995) y Florac y Carlton (Mea.~uring
the Software Process, Addison-Wesley, 1999) explican cmo evaluar de modo estadstico la
eficacia de cualquier proceso de software.
Se ha publicado una gran variedad de procedimientos y estndares de la ingeniera del
software desde la dcada pasada. El IEEE SOjlwarc Engineering Standards contiene muchos
estndares diferentes que cubren casi cada uno de los aspectos importantes de la tecnologa.
El conjunto de documentos ISO 9001:2000 proporciona una gua a las organizaciones de
software que deseen mejorar sus actividades de gestin de calidad. Otros estndares de ingeniera del software se pueden obtener del Departamento de Defensa, la FAA y otras agencias
gubernamentales y no lucrativas de Estados Unidos de America. Fairclough (Software Engneering Guides, Prentice-Hall, 1996) ofrece una referencia detallada de estndares de ingeniera del
software producida por la Agencia Espacial Europea (ESA, por sus siglas en ingls).
En Internet est disponible una gran variedad de fuentes de informacin sobre ingenieria
del software y el proceso de sollware Una lista actualizada de referencias de la World Wide
Web relevantes para el proceso de software puede encontrarse en el sitio:
http:// www.mhhe.com/ pressman.
MODELOS PRESCRIPTIVOS
DE PROCESO
CONCEPTOS
CLAVE
c's1rucd6n de
protottoJ ... ..ss
dtwrollo
tOIKlll'rente 60
mtfodos
fonnales. .. .64
modelo DIC . 63
lllOihl DRA , ,U
11!Nlelo DSOA 6S
modelo
cos<llda .......SO
modelo en
espiral ........58
llllklelo
ilcrt!lltlltal .. .52
modelo
prescriptivo 49
proceso
nolutlvo .... .54

proceso
os modelos prescriptivos de proceso se propusieron originalmente para or~

denar el caos del desarrollo de $Oftware. La historia ha indicado que estos
modelos convencionales han trado consigo cierta cantidad de estructuras
tiles para el trabajo en la ingenieria del software, y han proporcionado un camno a seguir razonablemente efectivo para los equipos de software. Sin embargo, el trabajo de la ingeniera del software y el producto resultante an
permanecen 1al brde del caos" [NOGOOJ.
En un documento intrigante sobre la extraa relacin entre el orden y el caos
en el mundo del software, Nogueira y sus colegas establecen:
l!l borde del caos se define como "un estado natural entre el ore.en y el caos, una
relacin estrecha entre la estructura y la sorpresa" [K.AU95J. El borde del caos se p1.1ede
visuallz;r como un estado inestable, estructurado en forma parcial,,. es inestable
porque es atraldo de manera constante hacia el caos o hacia el orden absoluto.
se tiende a pensar que el orden es el estado ideal de la naturaleza, fSto po<lrta ser
un error. La investigacin... apoya la teora de que la operacin lejos del equilibrio
genera creatividad, procesos O(ganizados por s mismos y retroalimentacin creciente [R0096J. El orden absoluto significa la ausencia de variablidad. lo cual sera
una ventaja 1m ambientes impredecibles. El cambio ocurre cuando existe alguna es
tructura para que pueda organizarse, dicha estructura no debe ser tan rigida como
para que evite el cambio. Por otro lado, <l.emasiado caos puede imposibilitar la coor~
dinaci6n y la coherencia. ta falta de estructura no siempre significa desorden.
Ullifkodo .. .. .67
ware.
de IQHwQre y
svs gerentes adaptan vn inocleto prescriptivo de
proceso a svs necesidades y ~ lo siguen,
Adems, la gente que he solicitado el .t'twore
tiene un popel por desempear conforme se ej8""
cuto el modelo de software.
Pe>r qu es importante? Porque propo(C1ona
estabilidad, control y 019ootc.1d6n uno activi
Quin lo hace? Los in~el'O$
CAPTULO 3 MODELOS PRESCRIPTIVOS DE PROCESO
49
Las implicaciones filosficas de este argumento son significativas respecto de la

ingeniera del software. S los modelos prescriptvos .del proceso' buscan estructura
y orden, stos resultan inapropiados para un mundo del software que se basa en el
cambio? Adems, s se rechazan los modelos convencionales del proceso (y el orden
que stos implican) y se reemplazan con algo menos estructurado, se imposibilita
alcanzar la coordinacin y la coherencia en el trabajo del software?
No existen respuestas fciles, pero existen opciones disponibles para los ingenieros de software. En este captulo se examinar el enfoque del proceso prescriptivo,
en el cual el orden y la consistencia del proyecto son los aspectos dominantes. En el
captulo 4 se examinar el enfoque del proceso gil en .el cual la organizacin propia, la colaboracin, la comunicacin y la adaptabilidad dominan la filosofia del proceso.
Cualquier organizacin de ingeniera del software debe describir un conjunto nico

de actividades dentro del marco de trabajo (captulo 2) para el (los) proceso(s) de
software que adopte. Tambin debe llenar cada actividad del marco de trabajo con
un conjunto de acciones de ingeniera del software, y definir cada accin en cuanto
a un conjunto de tareas que identifique el trabajo (y los productos del trabajo) que
deben completarse para alcanzar las metas de desarrollo. Despus, la organizacin
debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza especfica
de cada proyecto, a las personas que lo realizarn, y el ambiente en el que se ejecutar el trabajo. Sin importar el modelo del proceso seleccionado, los ingenieros de
software han elegido de manera tradicional un marco de trabajo genrico para el
proceso, el cual incluye las siguientes actividades dentro del marco: comunicacin,
planeacin, modelado, construccin y desarrollo.
"Existen 11111chas formas de ir hacia delante, pero slounode permanecer."

Fraakll D. Roosewlt
Los modelos prescriptivos de proceso a menudo se denominan modelos "convencionales" de proceso.
PARTE UNO
50
Aunque un proceso
seo prescrip#vo, no se
debe asumir que ste
es estfJ#co. los
modelos prescriptivos
se deben adoptar o
las personas, ol
problema y al
proyecto.
EL PROCESO DEL SOPIWARE
En las secciones siguientes se examinarn varios de los modelos prescriptivos del

proceso de software. Se les llama "prescriptivos" porque prescriben un conjunto de
elementos del proceso: actividades del marco de trabajo, acciones de ingeniera del
software, tareas, productos del trabajo, aseguramiento de la calidad, y mecanismos
de control del cambio para cada proyecto. Cada modelo de proceso prescribe tambin unjlujo de trabajo; esto es, la forma en la cual los elementos del proceso se interrelacionan entre s.
Todos los modelos de proceso del software se ajustan a las actividades genricas
del marco de trabajo descritas en el captulo 2, pero cada uno aplica una importancia diferente a estas actividades y define un flujo de trabajo que invoca cada actividad del marco de trabajo (as como acciones y tareas de la ingeniera del software)
de una manera diferente.
Existen ocasiones en que los requisitos de un problema se entienden de una manera

razonable: cuando el trabajo fluye desde la comunicacin a travs del despliegue de
una manera casi lineal. Esta situacin se encuentra a veces cuando es necesario hacer
adaptaciones o mejoras bien definidas a un sistema existente (por ejemplo, una adaptacin a un software contable debido a los cambios en las regulaciones del gobierno).
Esto puede ocurrir tambin en un nmero limitado de proyectos de nuevos desarrollos,
pero slo cuando los requerimientos estn bien definidos y son estables en forma razonable.
El modelo en cascada, algunas veces llamado el delo de vida clsico, sugiere un enfoque sistemtico, secuencial2 hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y que contina con la planeacin, el modelado,
la construccin y el despliegue para culminar en el soporte del software terminado.
El modelo en cascada es el paradigma ms antiguo para la ingeniera del software. Sin embargo, en las dcadas pasadas, las crticas a este modelo de proceso han
El modelo en cascada.
ComunicCJCin
l -
nido del proyecto

recopilacin de requisitos
Plonea(in
estimacin
itinerario
seg1Jmiento
Modelado
on6lisls
diseo
Construccin
cdigo
pruebo
Despliegu.
eotrego
soporte
retroolime:nrocin
A pesar de que el modelo en cascada original, que propuso Winston Royce [ROY70]. prev "ciclos
de retroalimentacin", la inmensa mayora de las organizaciones que aplica este modelo de proceso
lo trata como si fuera estrictamente lineal.
CAPTULO 3 MODELOS PRESCRIPT!VOS DE PROCESO
51
ocasionado que aun sus ms fervientes practicantes hayan cuestionado su eficacia

[HAN95]. Entre los problemas que algunas veces se encuentran al aplicar el modelo
en cascada estn:
1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el
modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera
indirecta. Como resultado, los cambios confunden mientras el equipo de
proyecto acta.
2. Con frecuencia es dificil para el cliente establecer todos los requisitos de manera
explicita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos.
3. El cliente debe tener paciencia. Una versin que funcione de los programas
estar disponible cuando el proyecto est muy avanzado. Un error grave ser
desastroso si no se detecta antes de la revisin del programa.
En un anlisis interesante de proyectos reales, Bradac [BRA94J concluy que la
naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar
tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica
en el trabajo productivo. El estado de bloqueo tiende a ser ms comn al principio y
al final del proceso secuencial.
En la actualidad, el trabajo del software est acelerado y sujeto a una cadena infinita de cambios (de caractersticas, funciones y contenido de la informacin). Con
frecuencia, el modelo en cascada no es aprop_iado para dicho trabajo. Sin embargo.
puede servir como un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el trabajo se realiza, hasta su conclusin, de una manera lineal.
En muchas situaciones los requisitos iniciales del software estn bien definidos en
forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Adems, quiz haya una necesidad imperiosa de proporcionar de manera rpida un conjunto limitado de funcionalidad para el usuario y despus refinarla y expandirla en las entregas posteriores del software. En estos casos
se elige un modelo de proceso diseado para producir el software en forma incremental.
eon CNll1IJ$lada frecuencJo, el trobojo en el software sigue la primero ley def ciclismo: no impontl PCl(ilJ ~ WIJ'IS.
as ll10lltelia arriba ymnlra el Viento.
"
,,
52
PARTE UNO
3.3.1 El modelo incremental
El modelo incremental
entrego uno serie de
lanzamientos,
llamados incrementos,
que proporcionan en
formo progresivo ms
funcionalidad poro los
clientes a medido que
se entrego codo uno
de los incrementos.
Si el diente demando
lo entrego en una
fecho imposible de
cumplir, sugirase
entregar uno oms
incrementos poro eso
fecho yel resto del
software (incrementos
adiciono/es) despus.
El modelo ncremental combina elementos del modelo en cascada aplicado en forma

iterativa. Como se muestra en la figura 3.2, el modelo incremental aplica secuencias
lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada
secuencia lineal produce "incrementos" del software [MCD93]. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer
incremento, podra realizar funciones bsicas de administracin de archivos, edicin
y produccin de documentos; en el segundo incremento, ediciones ms sofisticadas, y
tendra funciones ms complejas de produccin de documentos; en el tercer incremento, funciones de correccin ortogrfica y gramatical; y en el cuarto, capacidades
avanzadas de configuracin de pgina. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construccin de
prototipos que se expone en la seccin 3.4. l.
A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos bsicos, pero muchas caractersticas suplementarias (algunas conocidas, otras no) no se incorporan. El producto
esencial queda en manos del cliente (o se somete a una evaluacin detallada). Como
resultado de la evaluacin se desarrolla un plan para el incremento siguiente. El plan
afronta la modificacin del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de caractersticas y funcionalidad adicionales. Este proceso se repite despus de la entrega de cada incremento mientras no
se haya elaborado el producto completo.
El modelo de proceso incremental, al igual que la construccin de prototipos y
otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones
iiMJFD
O Comunicoci6n
O Ploneoci6n
O Modelodo {onlisis, diseno]
ll1 Construccin jc6digo, pruebo)
El modelo
incremental.
:
a
-~
incremento #n
Despliegue !entrego, retroolimentoci6n}
e
incremento #2
entrego de
n-simo incremento
B
>.
incremento # 1
entrego del
segundo incremento
j
Tiempo del calendario de pro~
CAPTULO 3
MODELOS PRESCR!PTIVOS DE PROCESO
53
"incompletas" del producto final, pero proporcionan al usuario la funcionalidad que

necesita y una plataforma para evaluarlo.3
El desarrollo incremental es til sobre todo cuando el personal necesario para una
implementacin completa no est disponible. Los primeros incrementos se pueden
implementar con menos gente. Si el producto esencial es bien recibido se agrega (si
se requiere) ms personal para implementar el incremento siguiente. Adems, los
incrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, un
sistema grande podra requerir la disponibilidad de un hardware nuevo que est en
desarrollo y cuya fecha de entrega es incierta. Serla posible planear los primeros
incrementos de forma que se evite el uso de este hardware, lo que permitira la
entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados.
3.3.2
El modelo DRA
El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo ORA es una adaptacin a
"alta velocidad" del modelo en cascada en el que se logra el desarrollo rpido
mediante un enfoque de construccin basado en componentes. Si se entienden bien
los requisitos y se limita el mbito del proyecto.4 el proceso DRA permite que un
equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a 90 das) [MAR91].
Como otros modelos de proceso, el enfoque DRA cumple con las actividades
genricas del marco de trabajo que ya se han presentado. La comunicacin trabaja
para entender el problema de negocios y las caractersticas de informacin que debe
incluir el software. La planeadn es esencial porque varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye tres
grandes fases -modelado de negocios, modelado de datos y modelado del proceso- y establece representaciones del diseo que sirven como base para la actividad
de construccin del modelo DRA. La construccin resalta el empleo de componentes
de software existente y la aplicacin de la generacin automtica de cdigo. Por ltimo, el despliegue establece una base para las iteraciones subsecuentes, si stas son
necesarias [KER94J.
El modelo de proceso DRA se ilustra en la figura 3.3. Es obvio que las restricciones
de tiempo impuestas sobre un proyecto DRA exigen un "mbito de escalas" [KER94J .
Si una aplicacin de negocios se puede modular de forma que cada gran funcin
pueda completarse en menos de tres meses (mediante la aplicacin del enfoque ya
Es importante observar que para todos los modelos de proceso giles que se tratan en et captulo 4
Estas condiciones no se pueden garantizar por ningn medio. De hecho, muchos proyectos de soft-
tambin se utiliza una filosofia incremental.

ware tienen los requisitos muy pobremente definidos al principio. En tales casos los enfoques de
construccin de prototipos o evolutivos (seccin 3.4) son meores opciones de proceso. Vase
{REl95J.
54
PARTE UNO
iihiff
Equipo #n
El modelo
DRA.
M
modelado del negocio
modelado d. loa dato&
modelado del prooeso
!"]
c..........
~.raci()n de
COMpOMnlas
Equipo #2
Comunicacin
91nefaCin
Ma,I
de ccligo
modelado del MgOCOO

modelado de los dab
modelodo dttl proceso
....._....
OUlclmlico
pruebo,
'
-mv
C1n11r satl.
NU!ilil111Ci6n de
Equipo#!
Modelado
modelado del negocio
modelado cle los datos
modelada clel proceso
~CIIIIOMiCO
c:...... vcd6n
revnlizoel6n de
componente
D,.1,.,n11gtaci6n
enirego
relroo~menloclII
get*OCln ~
ele c6digo
pruaba,
60-90diaa
Cules
so11 los
desventaos del
modelo DRA?
descrito), sta es una candidata para el DRA. cada gran funcin se puede abordar
mediante un equipo de ORA por separado, para despus integrarlas y formar un todo.
Como todos los modelos de proceso, el enfoque ORA tiene inconvenientes
[BUT94 J: 1) para proyectos grandes, pero escalables, el ORA necesita suficientes
recursos humanos para crear el nmero correcto de equipos ORA; 2) si los desarrolladores y clientes no se comprometen con las actividades rpidas necesarias para
completar el sistema en un marco de tiempo muy breve, los proyectos de ORA fallarn; 3) si un sistema no se puede modular en forma apropiada, la construccin de
los componentes necesarios para el ORA ser problemtica; 4) si el alto rendimiento es un aspecto importante, y se alcanzar al convertir interfases en componentes
del sistema, el enfoque ORA podra no funcionar; y 5) el ORA seria inapropiado cuando los riesgos tcnicos son altos (por ejemplo, cuando una aplicacin nueva aplica
muchas nuevas tecnologas)
3, 4 NAPIL9$ PI 219Sll9 IYQLPtJYAI

El software, como todos los sistemas complejos, evoluciona con el tiempo (GIL88].
Los requisitos de los negocios y productos a menudo cambian conforme se realiza
el desarrollo; por lo tanto, la ruta lineal que conduce a un producto final no ser real;
las estrictas fechas tope del mercado imposibilitan la conclusin de un producto
CAPTULO 3
MODELOS PRESCRIPTIVOS DE PROCESO
55
completo, por lo que se debe presentar una versin limitada para liberar la presin
competitiva y de negocios; se tiene claro un conjunto de requisitos del producto o
sistema esencial, pero todava se deben definir los detalles de las extensiones del
producto o sistemas. En stas y otras situaciones similares, los ingenieros de software necesitan un modelo de proceso que haya sido diseado de manera explcita
para incluir un producto que evolucione con el tiempo.
Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que
los ingenieros de software desarrollen versiones cada vez ms completas del software.
3.4. 1
. .1. .11l.11f0-
ddente
necesidad
411'11
E:modelode
c:am:zruc:c1n
ol polotipos.
Construccin de prototipos
A menudo un cliente define un conjunto de objetivos generales para el software,

pero no identifica los requisitos detallados de entrada, procesamiento o salida. En
otros casos, el responsable del desarrollo del software est inseguro de la eficacia de
un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera
tomar la interaccin humano-mquina. En stas, y en muchas otras situaciones, un
paradigma de construccin de prototipos puede ofrecer el mejor enfoque.
A pesar de que la construccin de prototipos se puede utilizar como un modelo
de proceso independiente, se emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto de cualquiera de los modelos de proceso
expuestos en este capitulo. Sin importar la forma en que ste se aplique, el paradigma de construccin de prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos
estn satisfechos.
El paradigma de construccin de prototipos (figura 3.4) se inicia con la comunicacin. El ingeniero de software y el cliente encuentran y definen los objetivos glo-
56
PARTE UNO
EL PROCESO DEL SOF1WARE
bales para el software, identifican los requisitos conocidos y las reas del esquema
en donde es necesaria ms definicin. Entonces se plantea con rapidez una iteracin
de construccin de prototipos y se presenta el modelado (en la forma de un diseo
rpido) . El diseo rpido se centra en una representacin de aquellos aspectos del
software que sern visibles para el cliente o el usuario final (por ejemplo, la configuracin de la interfaz con el usuario y el formato de los despliegues de salida). El
diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo
evala el cliente/usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para
satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer.
De manera ideal, el prototipo debera servir como un mecanismo para identificar
los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador
intenta emplear los fragmentos del programa ya existentes o aplica herramientas
(como generadores de informes, administradores de ventanas, etctera) que permiten producir programas de trabajo con rapidez.
Pero qu debe hacerse con el prototipo una vez cumplido el propsito descrito?
Brooks [BR075] ofrece una respuesta:
En la mayora de los proyectos, el primer sistema construido apenas se utliza. Tal vez sea
demasado lento, muy grande o torpe en su uso, o rena las tres caracteristicas a la vez.
No existe otra opcin que comenzar de nuevo, aunque sea doloroso, es lo mejor, y construr
una revsn redseada en la que se resuelvan estos problemas .. . cuando se aplca un
concepto nuevo de sistema o una tecnologa nueva, se tene que construir un sistema inservible y que sea necesario desechar, porque incluso la mejor planeacin no es omnisciente
como para que el sistema est perfecto desde la primera vez. Por lo tanto, la pregunta de
la administracin no es si debe construirse un sistema piloto y desecharlo. Esto tendr que
hacerse. La nica pregunta es si se planea la construccin de un desechable o se promete
entregrselo a los clentes.
El prototipo puede servir como "primer sistema", el que Brooks recomienda desechar. Pero sta tal vez sea una visin idealizada. Es verdad que a los clientes y los
desarrolladores les gusta el paradigma de construccin de prototipos. A los usuarios
les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos tambin se toma problemtica por las
siguientes razones:
l. El cliente ve lo que parece una versin en funcionamiento del software, sin
Resstase olo presin

por convertir un
prototipo burdo en un
{Jloducto. Como
resultodo, casi
siempre lo calidad se
reduce.
saber que el prototipo est unido "con chicle y cable para embalaje", que por
la prisa de hacerlo funcionar no se ha considerado la calidad del software
global o la facilidad de mantenimiento a largo plazo. Cuando se informa que
el producto debe construirse otra vez para mantener los altos niveles de calidad, el cliente no lo entiende y pide la aplicacin de "unos pequeos ajustes"
para que se pueda elaborar un producto final a partir del prototipo. Es muy frecuente que la gestin del desarrollo de software sea muy lenta.
CAPTULO 3
57
2. A menudo, el desarrollador establece compromisos de implementacin para
lograr que el prototipo funcione con rapidez. Tal vez se utilice un sistema
operativo o lenguaje de programacin inadecuado slo porque est disponible
y es conocido; se puede implementar un algoritmo ineficiente slo para
mostrar capacidad. Despus de un tiempo, el desarrollador quiz se familiarice con estas selecciones y olvide las razones por las que son inapropiadas.
La seleccin menos ideal ahora se convierte en una parte integral del sistema.
A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser
un paradigma efectivo para la ingeniera del software. La clave es definir las reglas
del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de
acuerdo en que el prototipo se construya y sirva como un mecanismo para la definicin de requisitos, en que se descarte, al menos en parte, y en que despus se desarrolle el software real con un enfoque hacia la calidad.
58
PARTE UNO
3.4.2 El modelo en espiral

El modelo en espiral, que Boehm [B0E88J propuso originalmente, es un modelo de
proceso de sonware evolutivo que conjuga la naturaleza iterativa de la construccin
de prototipos con los aspectos controlados y sistemticos del modelo en cascada.
Proporciona el material para el desarrollo rpido de versiones incrementales del
sonware. Boehm [BOEOI] describe este modelo de la siguiente manera:
E.I modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el
riesgo que se emplea para conducir sistemas intensivos de ingenierfa del software concurrente y con mltiples usuarios. Tiene dos caractersticas distintivas principales. Una de
ellas es un enfoque clclico para el crecimiento incremental del grado de definicin e implementacin de un sistema, mientras disminuye su grado de riesgo. La otra es un con-
~,
'1
c&v1
El modelo en espiral se
puede odoptor y
oplicorlo orrovs del
cido de vido completo
de uno oplicocin,
desde el desarrollo del

coocepto hosto el
mantenimiento.
junto de puntos de fijacin para asegurar el compromiso del usuario con soluciones de
sistema que sean factibles y mutuamente satisfactorias.
Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de

entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento del modelo o un prototipo. Durante las ltimas iteraciones se producen versiones cada vez ms completas del sistema desarrollado.
un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de ingenieria del software Para propsitos ilustrativos se
aprovechan las actividades genricas del marco de trabajo expuestas pginas atrs.5
Cada una de las actividades del marco de trabajo representa un segmento de la ruta
en espiral que se presenta en la figura 3.5. cuando comienza este proceso evolutivo
el equipo de software realiza actividades implicadas en un circuito alrededor de la
liM+iiJ
Planeacin
eshmoci6n
itinerario
on61isis de riesgos
Un modelo
en espiral
tpico.
Comunicacin
Modelado
on6lisis
diseo
Construccin
cdigo
pruebo
5 El modelo en espiral expuesto en esta seccin es una variacin del modelo que propuso Boehm. Para
ms infonnacin sobre el modelo en espiral original, vase BOE88J En BOE98J se puede encon
trar una exposicin ms reciente del modelo en espiral de Boehm
CAPTULO 3
MODELOS PRESCRIPTIVOS DE POOCESO
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 trabajo 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 especificacin del producto; los pasos subsecuentes 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 ajustes 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 modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Por lo tanto, el primer circuito alrededor de la espiral podra
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 contina 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 iteraciones alrededor de la espiral. Despus, un circuito alrededor de la espiral se podra
emplear para representar un "proyecto de mejoramiento del producto". En esencia,
la espiral. cuando se caracteriza de esta forma, permanece operativa hasta que el
software se retira. En ocasiones el proceso est inactivo, pero siempre que se inicie
un cambio el proceso comienza en el punto de entrada aprobado (por ejemplo,
mejoramiento del producto).
El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas a gran escala. Como el software evoluciona conforme avanza el proceso, el
desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos
en cada etapa evolutiva. El modelo en espiral emplea la construccin de prototipos
como un mecanismo encaminado 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 iterativo 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 antes de que se vuelvan
roblemticos.
6 las flechas que apuntan hacia dentro a lo largo del eje que separa la regin de despliegue de la de
avnuncacin indican una posibilidad de iteracin /oca/ a lo largo de la misma ruta de la espira/.
60
PARTE UNO
As como otros paradigmas, el modelo en espiral no es una panacea. Es dificil

convencer a los clientes (en particular en situaciones bajo contrato) de que el enfoque evolutivo es controlable, ya que se requiere una habilidad considerable para
evaluar el riesgo y se confia en dicha habilidad para obtener el xito. Si un riesgo
importante no se descubre y administra, sin duda surgirn problemas.
3.4.3
~ONSIJOS.
Amenudo, el modelo
concurrente es ms
opropiodo pura
proyectos de inge-
nieoo de sistemas
(captulo 6), donde
estn implicados diferentes equipos de
ingeniera.
El modelo de desarrollo concurrente
El modelo de desarrollo concurrente, llamado algunas veces ingeniera concurrente, se

representa en forma esquemtica como una serie de actividades del marco de trabajo, acciones y tareas de la ingeniera del software y sus estados asociados. Por
ejemplo, la actividad de modelado, definida para el modelo en espiral, se lleva a cabo
al invocar las acciones siguientes: construccin de prototipos o modelado y especificacin del anlisis y diseo. 7
En la figura 3.6 se proporciona un esquema de una tarea de ingeniera de software
relacionada con la actividad de modelado para el modelo de proceso concurrente.
La actividad - modelado- puede estar en alguno de los estados destacados mencionados antes en cualquier momento dado. De forma similar, otras actividades o
tareas (por ejemplo, la comunicacin y la construccin) se representan de una manera anloga. Todas las actividades existen de forma concurrente, pero se encuentran
en diferentes estados. Por ejemplo, al principio del proyecto la actividad de comunicacin (no se muestra en la figura) ha completado su primera iteracin y existe en el
estado de en espera de cambios. La actividad de modelado que existi en el estado ninguno mientras se realizaba la comunicacin inicial, ahora realiza una transicin al estado en desarrollo. Sin embargo, si el cliente indica cambios en los requisitos, la actividad de modelado se mueve del estado en desarrollo al estado de en
espera de cambios.
El modelo de proceso concurrente define una serie de eventos que dispararn
transiciones de estado a estado para cada una de las actividades, acciones o tareas
de la ingeniera del software. Por ejemplo, durante los primeros estados del diseo
(una accin de la ingenieria del software que ocurre en el curso de la actividad de
modelacin) no se detecta una inconsistencia en el modelo del anlisis. Esto genera el evento correccin del anlisis del modelo, el cual disparar la creacin del anlisis desde el estado realizado hasta el estado de en espera de cambios.
El modelo de proceso concurrente se aplica a todos los tipos de desarrollo de software y proporciona una visin exacta del estado actual de un proyecto. En lugar de
confinar las actividades, acciones y tareas de la ingeniera del software a una
secuencia de eventos, define una red de actividades. Cada actividad, accin o tarea
en la red existe de manera simultnea con otras actividades, acciones o tareas. Los
7 Se debe notar que el anlisis y el diseo son acciones complejas que requieren un debate sustancial. La parte 2 de este libro considera estos tpicos en forma detallada.
8
Un est.ado es alguna forma de comportamiento observable desde el exterior.
CAPTULO 3
eieme,to
*imodelo
-11::==z:-Jante
.pcocaso.
61
Ninguno
Actividad de modelado
eventos generados en un punto de la red del proceso disparan transiciones entre los
estados.
3.4.4
Un comentario final sobre los procesos evolutivos
Ya se ha detectado que al software de computadoras moderno lo caracteriza el cambio continuo, los tiempos de entrega muy reducidos, y una necesidad intensa de
satisfacer al cliente/usuario. En muchos casos, el tiempo de llegada al mercado es
el requisito de gestin ms importante. Si se pierde una ventana del mercado, el
mismo proyecto de software puede perder su significado.9
,'8o hasta aqui, yslo el maana gua mi comino.N

Los modelos evolutivos de proceso se concibieron para abocarse a estos aspectos y, adems, como modelos de proceso de clase general. Estos modelos tambin
tienen debilidades, las cuales resumen Nogueira y sus colegas [NOGOOJ:
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 llegar al mercado (al aprender errores de los antecesores).
62
PARTE UNO
EL PROC50 DEL SOFTWARE
A pesar de los incuestionables beneficios de los procesos evolutivos de software, se tienen

algunas dificultades con este tipo de procesos. La primera dificultad es que la construccin de prototipos [y otros procesos evolutivos ms elaborados] implican un problema
para la planeacin del proyecto debido al nmero incierto de ciclos requeridos para construir
el producto. La mayora de las tcnicas de gestin y estimacin de proyectos se basa en
configuraciones lineales de las actividades, por Jo que stas no se ajustan por completo.
La segunda dificultad es que los procesos evolutivos de software no establecen la ve-
locidad mxima de la evolucin. Si las evoluciones suceden demasiado rpido, sin un periodo de relajacin, existe la certidumbre de que el proceso caer en el caos. Por otro lado,
si la velocidad es demasiado lenta, se podra afectar la productividad.
Una tercera dificultad es que los procesos de software se deben enfocar en la flexibili dad y extensibilidad en vez de en la alta calidad. Esta afirmacin suena atemorizan te. Sin
embargo, se debe priorizar la velocidad del desarrollo sobre los cero defectos. Si el desarrollo
se extiende para alcanzar una alta calidad, se producira un retraso en la entrega del producto, la cual se hara cuando el nicho de oportunidad ya haya desaparecido. Este cambio
de paradigma Jo impone la competencia en el borde del caos.
En efecto, un proceso de software que se enfoca en la flexibilidad y la velocidad del

desarrollo por encima de la alta calidad suena atemorizante. Aun as, esta idea la ha
propuesto cierto nmero de respetados expertos en la ingeniera del software (por
ejemplo, [YOU95], [BAC97]).
El propsito de los modelos evolutivos es desarrollar software de alta calidad 1 de
una manera iterativa o incremental. Sin embargo, es posible aplicar un proceso evolutivo para destacar la flexibilidad, extensibilidad y velocidad del desarrollo. El reto
para los equipos de software y sus dirigentes es establecer un balance apropiado
entre estos parmetros crticos del proyecto y el producto, y el producto y la satisfaccin del cliente (el rbitro final de la calidad del software).
incremento.
1O En este contexto, la calidad del software se define con mucha amplitud para abarcar no slo la satisfaccin del cliente, sino tambin una variedad de criterios tcnicos tratados en el captulo 26.
CAPTULO 3
63
Doug: lee, . . N 1111

Como dio Ecf, ..,._
mejor n'ICMI' el plan o,,.....
conforme solicilan
los...._
Los modelos especializados de proceso adoptan muchas de las caractersticas de

uno o ms de los modelos convencionales presentados en las secciones anteriores.
Sin embargo, los modelos especializados tienden a aplicarse cuando se ha elegido
un enfoque de ingenieria del software definido de una manera muy estrecha. 11
3.5. l
Desarrollo basado en componentes
Los nuevos componentes de software comerciales (NCSC), desarrollados por vendedores que los ofrecen como productos, se pueden emplear cuando el software est
en proceso de construccin. Estos componentes proporcionan funcionalidad dirigida con interfaces bien definidas que permiten que el componente se integre en el
software.
El modelo de desarrollo basado en componentes (DBC) (captulo 30) incorpora muchas
de las caracteristicas del modelo en espiral. Es evolutivo por naturaleza [NIE92J y exige
un enfoque iterativo para la creacin del software. Sin embargo, el modelo configura
aplicaciones a partir de componentes de software empaquetados en fonna previa.
Las actividades de modelado y construccin comienzan con la identificacin de
los componentes candidatos. Estos componentes se pueden disear como mdulos
de software convencionales o como clases o paquetes de clases orientados a objetos. 12 Sin importar la tecnologia que se aplique en la creacin de los componentes,
el modelo de desarrollo basado en componentes incorpora los siguientes pasos
(implementados mediante un enfoque evolutivo):
Los productos basados en componentes disponibles se investigan y evalan

para el dominio de aplicacin en cuestin.
Se consideran los aspectos de integracin de componentes.
Se disea una arquitectura de software (captulo 1O) para adaptar los componentes.
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 desarroJlo 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
2se e11G1psu/a una serie de datos y los procedimientos que procesan dichos datos. Un paquete de clases es una coleccin de clases relacionadas que trabajan juntas para alcanzar algn resultado final.
64
PARTE UNO a
PROCESO DEL SOFTWARE
Los componentes (capitulo 11) se integran en la arquitectura.
Se realizan pruebas detalladas (captulo 11) para asegurar una funcionalidad

apropiada.
El modelo de desarrollo basado en componentes conduce a la reutilizacin del

software, la cual proporciona beneficios a los ingenieros de software. Con base en
estudios de reutilizacin, QSM Associates, Inc. informa que el ensamblaje de componentes conduce a una reduccin de 70 por ciento del ciclo de desarrollo; 84 por
ciento del costo del proyecto y un ndice de productividad de 26.2, comparado con
una norma de la industria de 16.9 [YOU94]. A pesar de que estos resultados estn en
funcin de la robustez de la biblioteca de componentes, no hay duda de que el
modelo de desarrollo basado en componentes proporciona ventajas significativas
para los ingenieros de software.
3.5.2
El modelo de mtodos formales
El modelo de mtodos formales (captulo 28) comprende un conjunto de actividades

que conducen a la especificacin matemtica del software de computadora. Los
mtodos formales permiten que un ingeniero de software especifique, desarrolle y
verifique un sistema basado en computadora al aplicar una notacin matemtica
rigurosa. Algunas organizaciones de desarrollo del software aplican en la actualidad
una variacin de este enfoque, llamado ingeniera del software de sala limpia {MIL87,
DYE92] . Este modelo se explica en el captulo 29.
"Es ms fdl escribir unprogramo incorrectoque entender uno correcto."

Cuando se utilizan mtodos formales durante el desarrollo, stos proporcionan
un mecanismo para eliminar muchos de los problemas difciles de superar con otros
paradigmas de la ingeniera del software. La ambigedad, el estado incompleto y la
inconsistencia se descubren y corrigen con mayor facilidad -no mediante una revisin ad hoc, sino a travs de la aplicacin de un anlisis matemtico-. Cuando los
mtodos formales se utilizan durante el diseo sirven como base para la verificacin
de programas y, por consiguiente, permiten que el ingeniero de software descubra y
corrija errores que de otra manera podran no haberse detectado.
A pesar de que an no existe un enfoque establecido, los modelos de mtodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha mencionado una gran preocupacin acerca de su aplicabilidad en su entorno de gestin:
Si los mtodos formales

pueden demostrar
la correccin del
software, por qu
no se 1tiliza en
forma extensa?
En la actualidad, el desarrollo de modelos formales es muy caro y consume

mucho tiempo.
Se requiere una capacitacin detallada, debido a que pocos responsables del

desarrollo de software cuentan con los antecedentes necesarios para aplicar
mtodos formales.
CAPTULO 3
MODELOS PIWlCruP'IlVOS DE PROCESO
65
Es dificil la utilizacin de estos modelos como un mecanismo de comunicacin con clientes que no tienen muchos conocimientos tcnicos.
No obstante, tal vez el enfoque a travs de mtodos fonnales 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 desarrolladores que padecen severas penurias econmicas cuando aparecen errores en el
software.
3.5.3
Desarrollo del software orientado a aspectos
Sin importar el proceso de software que se elija, los constructores de software complejo implementan de manera invariable un conjunto especfico de caractersticas.
funciones y contenido de infonnacin. Estas caractersticas especificas del software
se modelan como componentes (por ejemplo, clases orientadas a objetos) y despus se
construyen dentro del contexto de una arquitectura de sistema. Conforme los sistemas basados en computadora se vuelven ms elaborados <:y complejos), ciertos
intereses" -propiedades requeridas para el cliente o reas de inters tcnicoabarcan toda la arquitectura. Algunos intereses son propiedades de alto nivel de un
sistema (por ejemplo, seguridad, falta de tolerancia). Otros intereses afectan las funciones (como la aplicacin de reglas de negocios), mientras que otros son sistmicos (como la sincronizacin de tareas o la gestin de memoria).
Cuando los intereses se relacionan con mltiples funciones, caractersticas e
informacin del sistema, con frecuencia se denominan intereses generales. Los requerimientos de aspectos definen estos intereses generales que ejercen un impacto a travs de la arquitectura del software. El desarrollo de software orientado a aspectos
(DSOA), referido con frecuencia como programadn orientada a aspectos (POA). es
un paradigma de la ingeniera del software relativamente nuevo que proporciona un
proceso y enfoque metodolgico para definir, especificar. disear y construir aspee
tos -"mecanismos ms all de subrutinas y legados para localizar la expresin de

un inters general" [ELROl].
Grundy [GRU02] explica con mayor profundidad los aspectos en el contexto de lo
que l llama ingeniera de componentes orientada a aspectos [ICOAJ:
La !COA utiliza un concepto de capas horizontales a travs de componentes de software
descompuestos en fonna vertical, llamados "aspectos", para caracterizar propiedades

generales de los componentes, los cuales pueden ser funcionales y no funcionales. Por lo
general, los aspectos sistmicos incluyen interfases con el usuario, trabajo en colaboracin, distribucin, persistencia, gestin de la memoria, procesamiento de transiciones,
seguridad, integridad y otros. Los componentes pueden proporcionar o requerir uno o ms
"detalles de aspecto" relacionados con un aspecto particular, como un mecanismo de
visin, acceso extensible y tipo de interfase (aspectos de la interfase con el usuario);
generacin, transportacin y recepcin de eventos (aspectos de distribucin); almacenamiento/recuperacin e indizacin de datos (aspectos de persistencia); autentificacin,
codificacin y derechos de acceso (aspectos de seguridad); atomicidad de la transaccin,
PARTE UNO EL PROCESO DEL SOFIWARE

control de concurrencia y control del transporte (aspectos de transaccin), y asi sucesivamente. Cada detalle de aspecto tiene una serie de propiedades en relacin con caractersticas personales y no funcionales del detalle.
Hasta ahora no se ha concretado un proceso orientado a aspectos diferente. Sin

embargo, es probable que tal proceso adopte caractersticas de los modelos de proceso en espiral y concurrente (secciones 3.4.2 y 3.4.3). La naturaleza evolutiva del
modelo en espiral es apropiada cuando se identifican y construyen los aspectos. La
naturaleza paralela del desarrollo concurrente es esencial porque los aspectos se
desarrollan de manera independiente de los componentes del software localizados
y, aun as, los aspectos tienen un impacto directo sobre estos componentes. Por lo
tanto, resulta esencial implementar una comunicacin asincrnica entre las actividades del proceso de software aplicadas al desarrollo y la construccin de aspectos
y componentes.
Si se desea conocer una exposicin detallada del desarrollo del software orientado a aspectos, se recomienda remitirse a libros dedicados a esta materia. El lector
interesado puede consultar [GRA03], [KJS02] o [ELROl].
Gestin del proceso

Objetivo: Ayudar en la definicin, ejecucin
y gestin de los modelos prescriptivos del
Mecnica: Los herramientas de gestin del proceso
permiten c:ue una or9anizacin o equipo de softwore

defino 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 softwore hacen el trabajo tcnico y una
plantilla para los gerentes, que deben rastrear y controlar
el proceso de softwore.
Herramientas representativas13
La GDPA, una serie de herramientas para la definicin del

proceso de investigacin, desarrollado en lo
Universidad de Bremen en Alemania

(www.informatik.uni-bremen.de/ uniform/gdpa/
home.htm),proporciona un amplio espectro de
funciones para el modelado y lo gestin del proceso.
SpeeDev, desarrollado por Spee Dev Corporotion

(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:J /205.252.62.38/English/
DProcessNotation.htm es pasible 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 ..
CAPTULO 3
MODELOS PRl:SCRIPTNOS DE PROCEro
67
En su libro fundamental 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 autores establecen:
En la actualidad la tendencia en el software se encamina a sistemas mayores y comple-
jos . Eso se debe en parte al hecho de que las computadoras se volvan ms poderosas cada
ao, lo que alentaba que los usuarios esperaran ms de ellas. Esta tendencia tambin la
impuls el uso expandido de Internet para el intercambio de todo tipo de informacin.
Nuestro apetito por un software cada vez ms complejo crece en la medida en la que
aprendemos cmo puede mejorarse un producto desde que sale uno hasta que llega el
otro. Necesitamos un software que se adapte mejor a nuestras necesidades, pero que, a
su vez, haga el software ms complejo. En resumen, queremos ms.
De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los

mejores rasgos y caractersticas de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principios del desarrollo
gil de software (captulo 4). El proceso unificado reconoce la importancia de la
comunicacin con el cliente y los mtodos encaminados a describir el punto de vista
del cliente con respecto a un sistema (por ejemplo, el caso de uso 14). El PU enfatiza
el importante papel de la arquitectura de software, y "ayuda al arquitecto a enfocarse en las metas correctas, como el entendimiento, el ajuste a los cambios futuros y
la reutilizacin" [JAC99]. Sugiere un flujo de proceso iterativo e incremental y que
proporciona el sentido evolutivo esencial en el desarrollo del software moderno.
En esta seccin se presenta una visin general de los elementos clave del proceso unificado. En la parte 2 de este texto se analizan los mtodos que pueblan el proceso y las tcnicas y notaciones complementarias del UML, 15 las cuales se requieren
al aplicar el proceso unificado en el trabajo real de la ingeniera del software.
3.6. l
Una breve historia
Durante la dcada de 1980 y al principio de la dcada siguiente, los mtodos y lenguajes de programacin orientados a objetos (00) 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 (Untfied 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) [STIOI) o [FOW99).
68
PARTE UNO
puso una amplia variedad de anlisis y diseo orientados a objetos (AOO y DOO) y
se introdujo un modelo de proceso orientado a objetos de propsito general (similar
a los modelos evolutivos presentados en este captulo). Al igual que la mayora de
los paradigmas "nuevos" para la ingeniera del software, los seguidores de cada uno
de los mtodos de AOO y DOO argumentaban acerca de cul de ellos era el mejor,
pero ningn mtodo o lenguaje domin la escena de la ingeniera del software.
Al principio de la dcada de 1990, James Rumbaugh [RUM91J, Grady Booch
[B0094] e Ivar Jacobson [JAC92] comenzaron a trabajar en un "mtodo unificado"
que combinara las mejores caractersticas de cada uno de sus mtodos individuales
y adoptara caractersticas adicionales que propusieran otros expertos (por ejemplo,
[WIR901) en el campo OO. El resultado fue el lenguaje de modelado unificado (UML,
por sus siglas en ingls) -que contiene una notacin robusta para el modelado y el
desarrollo de sistemas 00-. Para 1997, el UML se convirti en un estndar de la
industria para el desarrollo de software orientado a objetos. Al mismo tiempo,
Rational Corporation y otras firmas desarrollaron herramientas automticas para
apoyar los mtodos del UML.
El UML proporciona la tecnologa necesaria para apoyar la prctica de la ingeniera del software orientada a objetos, pero no provee el marco de trabajo 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 trabajo para la ingeniera del software orientada a objetos, mediante la utilizacin del
UML. En la actualidad, el proceso unificado y el UML se emplean de forma amplia en
proyectos 00 de todos los tipos. El modelo iterativo e incremental que propone el
PU puede y debe adaptarse para satisfacer necesidades 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 reactivo ante el cambio.
. . .....,
Ettwww.
.........
,,....,.-,
ellCIWIIRK
tlanentos
utk
sobre el PU.
3.6.2
Fases del proceso uni1icado17
Se han analizado cinco actividades genricas del marco de trabajo y se ha explicado que stas se pueden aplicar para describir cualquier modelo de proceso del software. 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 inicio del PU abarca la comunicacin con el cliente y las actividades de
planeacin. Al colaborar con los clientes y usuarios finales se identifican los requisitos 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 respaldara la Rational Corporation, un contribuyente importante en el desarrollo y refinamiento del
proceso y un constructor de ambientes completos (herramientas y tecnologa).
CAPTULO 3
69
MODELOS PREScnIPTIVOS DE PROCESO
siStema, y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a travs de
U" conjunto preliminar de casos de uso que describen cules caractersticas y func.ones 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, otro 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 subsistemas ms importantes y de las funciones y caractersticas que los forman. Despus,
la arquitectura se refinar y expandir en un conjunto de modelos que representarn visiones diferentes del sistema. La planeacin identifica recursos, evala los riesgos importantes, define un itinerario y establece una base para las fases que se aplicarn 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 modelo de anlisis, el
modelo de diseo, el modelo de implementacin y el modelo de despliegue. En algunos casos, la elaboracin crea una "lnea de base arquitectnica ejecutable" [ARL02J
que representa un sistema ejecutable en su "primer corte". 18 La lnea de base arquitectnica demuestra la viabilidad de la arquitectura, pero no proporciona todas las
Elaboroci6n
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.
70
~--..........
se~ ll(* uno

brilhnre l'Jlillidn y
colaellllllios
PU.
PARTE UNO
caractersticas y funciones necesarias 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 modificaciones al plan se deben hacer en este momento.
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 componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr
esto requiere que los modelos de anlisis y diseo iniciados durante la fase de elaboracin se completen para reflejar la versin final del incremento del software.
Todas las caractersticas y funciones necesarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en cdigo fuente. Conforme los componentes estn en proceso de implementacin, se disean y ejecutan pruebas de
unidad para cada uno de ellos. Adems, se realzan las actividades de integracin
(ensamblaje de componentes y pruebas de integracin). Los casos de uso se utilizan
para derivar un conjunto de pruebas de aceptacin que se ejecutan antes del inicio
de la siguiente fase del PU.
La fase de transicin del PU abarca las ltimas etapas de la actividad genrica de
construccin y la primera parte de la actividad genrica de despliegue. El software
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, manuales del usuario, guas de resolucin de problemas, procedimientos de instalacin) para el lanzamiento. Al final de la fase de transicin, el incremento de software se convierte en
un lanzamiento de software utilizable.
La fase de produccin del PU coincide con la actividad de desplegue del proceso
genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura), y se reciben y evalan los informes de defectos y los requerimientos de cambios.
Es probable que mientras se realizan las fases de construccin, transicin y produccin ya se hayan iniciado los trabajos 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 trabajo de ingeniera del
software. En el contexto del PU, unjlujo de trabajo es anlogo a un conjunto de tareas
(definido en el captulo 2). Esto es, un flujo de trabajo identifica las tareas necesarias
para completar una accin importante de ingeniera del software y los productos de
19 En la prueba beta, una accin de prueba controlada (captulo 13). el software lo utilizan usuarios finales 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.
CAPTULO 3
MODELOS PRESCRIPl'lVOS DE PROC50
71
trabajo que se producen como consecuencia de la realizacin exitosa de tareas. 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, subtareas 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 propsito 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 riesgos del proyecto y del negocio que pudieran representar un obstculo para el xito.
Desde el punto de vista del ingeniero de software, el producto de trabajo ms importante 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" humanos y no humanos del software) interactan con el sistema y obtienen valor a partir
de ste. En esencia, el modelo de casos de uso es una coleccin de escenarios de uso
con plantillas estandarizadas que implican caractersticas y funciones del software
mediante la descripcin de una serie de condiciones previas, un flujo de eventos o
un escenario, y un conjunto de condiciones exteriores para la interaccin representada. En un inicio, los casos de uso describen requisitos al nivel del dominio de negocios (por ejemplo, el grado de abstraccin es alto). Sin embargo, el modelo 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 conjunto de productos de trabajo que elabora
requisitos (incluso requisitos no funcionales2), asi como una descripcin arquitectnica 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 anlisis que describan en forma adecuada el comportamiento del sistema. El modelo de
anlisis del PU es un producto de trabajo que se desarrolla como consecuencia de
esta actividad. Los paquetes 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, subsistemas y las interfases entre los subsistemas.
Los modelos de anlisis y diseo expanden y refinan una representacin evolutiva
de la arquitectura del software. Adems, en la fase de elaboracin se revisan los riesgos 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 componentes de software que se construirn para ejecutar el sis-
20 Requisitos que no se pueden deducir del modelo de caso de uso.
---~-.
-~-.
72
ifrUfi:
Principales
productos de
trabajo
producidos
para cada
fase del PU.
PARTE UNO
Fase de inicio
Documento de lo visin
Modelo inicial de coso
de uso
Glosario inicial
del proyecto
Coso inicial de negocio
Evaluacin inicial
del riesgo
Pion de proyecto,
foses e iteraciones
Modelo del negocio
si e$ necesario
Uno o m6s protottpos
. . . . . 1llll!arN6n
Mc,delo(le C:O~ de UQ
R11qul11h Wj>lemenlori011
Fase de construccin
Modelo del diseo

Componentes del
software
Incremento integrado
del software
Plan y procedimiento
de pruebas
,jeQ/!Qbi.
Cosos de pruebo
Mod.io de dis~
Documentacin
prellminor
del soporte
u~ r..-isodo de rie'90I
manuales del usuario
Pion de pr9>lo que
manuales de instalacin
descripcin del
pion de ilel:o<:in
llvi94 de lrbao adopldQs incremento actual
~
produclos tcnicos
ind'f6n los >
fundonol,,
Modelo de anll,
De~ipci6n de Jo
ar~del~e
Prolotipo orquilec:16nieo
MI
,.. ......killn
l~ l o de Qflwc:-
'integrado
Rpttei de la, pr'Uba1
beta
R~IIMmOc:in ~rol
d.f U$UOIO
del lr<>bajo
Molivol preliminor
del usuorio
tema, y un modelo de despliegue convierte los componentes en el ambiente fsico de

computacin. Por ltimo, un modelo de prueba describe las pruebas empleadas para
asegurar que los casos de uso se reflejen de manera apropiada en el software que se
ha construido.
La fase de transicin entrega el incremento del software y evala los productos
de trabajo elaborados durante la etapa en que los usuarios finales trabajan con el
software. En esta etapa se produce la retroalimentacin proveniente de las pruebas
beta y los requerimientos cualitativos de cambio.
Los modelos prescriptivos del proceso de software se han aplicado durante muchos
aos en un esfuerzo encaminado a ordenar y estructurar el desarrollo del software.
Cada uno de estos modelos convencionales sugiere un flujo de proceso que de alguna forma es diferente, pero todos realizan el mismo conjunto de actividades genricas del marco de trabajo: comunicacin, planeacin, modelado, construccin y despliegue.
El modelo en cascada sugiere una progresin lineal de actividades del marco de
trabajo que a menudo resulta inconsistente con la realidad moderna en el mundo del
software (por ejemplo, con el cambio continuo, los sistemas en evolucin, las fechas
de entrega restringidas). Sin embargo, este modelo se puede aplicar en situaciones
en las cuales los requisitos estn bien definidos y son estables.
CAPTULO 3
73
Los modelos incrementales del proceso de software producen software como una
serie de entregas de incrementos. El modelo DRA est diseado para proyectos grandes que se deben entregar en marcos de tiempo muy reducidos.
Los modelos de proceso evolutivos reconocen la naturaleza evolutiva de la mayora de los proyectos de ingeniera del software y estn diseados para ajustarse al
cambio. Los modelos evolutivos, como el de construccin de prototipos y el modelo
en espiral, generan productos de trabajo incrementales (o versiones del software en
funcionamiento) con rapidez. Estos modelos se pueden adaptar para aplicarlos a travs de todas las actividades de la ingeniera del software: desde el desarrollo de conceptos hasta el mantenimiento del sistema a largo plazo.
El modelo basado en componentes destaca la reutilizacin y ensambladura de
componentes. Los modelos de mtodos formales conducen a la utilizacin de un
enfoque basado en las matemticas para el desarrollo y la verificacin del software.
El modelo orientado a aspectos incluye los intereses generales que cubren la arquitectura total del sistema.
El proceso unificado es un proceso de software "guiado por los casos de uso, de
arquitectura cntrica, iterativo e incremental" diseado como un marco para los
mtodos y herramientas del UML. El proceso unificado es un modelo incremental en
el que se definen cinco fases: 1) una fase de inido 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 creacin de modelos de anlisis y diseo, con nfasis en las definiciones de clase y representaciones arquitectnicas; 3) una fase de construcdn que refina y despus traduce
el modelo de diseo en componentes de software 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 monitoreo continuo y el soporte.
[AMB021 Ambler, s. y L. Constantine, The Uni.fied Process Inception Phase, CMP Books, 2002.
[ARL02] Arlow, J. e T. Neustandt, UML and the Unijied Process, Addison-Wesley, 2002.
[BAC97J Bach, J.. "Good Enough Quality: Beyond the Buzzword", en IEEE Computer, vol.30,
nm. 8, agosto de 1997, pp. 96-98.
[B0E88J Boehm, B., "A Spiral Model for Software Development Enhancement", en Computer,
vol. 21, nm. 5, mayo de 1988, pp. 61-72.
[B0E98] Boehm, B., "Using the WINWIN Spiral Model: A Case Study", en Computer, vol.3,
nm.7, julio de 1998, pp. 33-34.
[BOEOI) Bohem, B., "The Spiral Model as a Too! for Evolutionary Software Acquisition", en
CrossTalk, mayo de 2001, disponible en http://www.stsc.hill.af.mil/crosstalk/2001/05/
boehm.html.
[B0094] Booch, G., Object-Oriented Analysis and Design, 2a. ed., Benjamin Cummings, 1994.
[BRA94] Bradac, M., D. Peny y L. Votta, "Prototyping a Process Monitoring Experiment", en IEEE 71rlns.
Sojlware Engmeering, vol. 20, nm. 10, octubre de 1994, pp. 774-784.
[BR075J Brooks, F., The Mylhical Man -Monlh, Addison-Wesley, 1975.
74
PARTE UNO
[BUT94) Butler, J., "Rapid Application Development in Action", en Managing System Development,
Applied COmputer Research, vol. 14, nm.5, mayo de 1994, pp. 6-8.
[DYE 92] Dyer, M., The Cleanroom Approach to Quality Software Development. Wiley, 1992.
[ELROI] Elrad, T., R. Filman y A. Bader (eds.), "Aspect-Oriented Programming", en Comm. ACM,
vol. 44, nm. 10, octubre de 2001, edicin especial.
[FOW99) Fowler, M. y K. Scott, UMLDistilled, 2a. ed., Addison-Wesley, 1999.
[G!L88J Gilb, T., Principies of Software Engineering Management, Addison-Wesley, 1998.
[GRA03) Gradecki, J. y N. Lesiecki, Mastering Aspectf; Aspect-Oriented Programming in Java,
Wiley,2003.
[GRU02J Grundy, J., "Aspect-Oriented Component Engineering", 2002, http://www.cs. auckland.
ac.nz/-john-g/aspects.html.
[HAN95) Hanna, M., "Farewell to Waterfalls", en Software Magazine, mayo de 1995, pp. 38-46.
[HES96] Hesse, W., "Theory and Practice of the Software Process-A Field Study and its
Implications for Project Management". Software Process Technology, 5th European Workshop,
EWSPT 96, Springer LNCS I I 49, 1996, pp. 241-256.
LHESOI) Hesse, w., "Dinosaur Meets Archaeoptery)c? Seven Theses on Rational's Unified
Process (RUP)", en Proc. 8th Intl. Workshop on Eva/uation of Modelng Methods in System
Anafysis and Design, Ch. VII Interlaken, 2001.
[JAC92J Jacobson, l., Object-Oriented software Engineering, Addison-wesley, 1992.
[JAC99) Jacobson, J., 6ooch, G. y J. Rumbaugh, The Unijied Software Development Process,
Addison-Wesley, 1999.
[KAU95] Kauffman, S., At Home in the Universe, Oxford, 1995.
[KER941 Kerr. J. y R. Hunter, Inside RAD, McGraw-Hill, 1991.
[MAR91] Martn, J., Rapid Application Development, Prentice-Hall, 1991.
[McDE93J McDermid J. y P. Rook, "Software Development Process Models", en Software
Engineer's Rejerence Book, CRC Press, 1993, pp. 15/26- 15/28.
[MIL87] Mills, H.D., M. Dyer y R. Linger, "Cleanroom Software Engineering", en IEEE Software,
septiembre de 1987, pp. 19-25.
[NIE92J Nierstrasz, O., S. Gibbs y D. Tsichritzis, "Component-Oriented Software Development",
en CACM, vol. 35, nm. 9, septiembre de 1992, pp. 160- 165.
[NOGOO] Nogueira, J., C. Jones y LUqi, "Surfing the Edge of Chaos: Applications to Software
Engineering", Command and Control Research Technology Symposium, Naval Post Graduate
School, Monterey CA, junio de 2000, disponible en
http//www.dodccrp.org/2000CCRTS/cd/html/pdf_papers/Track_4/075.pdf.
[REE02] Reed, P., Developing Applcations with Java and UML, Addison-Wesley, 2002.
[REI95] Reilly, J. P., "Does RAD Live Up th the Hype", en IEEE Software, septiembre de 1995, pp.
24-26.
[R0096] Roos, J., 'The Poised Organization: Navigating Effectively on Knowledge Landscapes",
1996, disponible en http:/ /www.imd.ch/fac/roos/paper_po.html.
(ROY70] Royce, W.W., "Managing the Development of Large Software Systems: Concepts and
Techniques" en, Proc. WESCON, agosto de 1970.
[RUM91J Rumbaugh, J. et al., Object-Orienled Modelng and Design, Prentice-Hall, 1991.
[STIOIJ Stiller, E. y C. LeBlanc, Project-Based Software Engineering: An Object-Oriented Approach,
[WIR90] Wirfs-Brock, R., B. Wilkerson y L. Weiner, Designing Object-Oriented software, PrenticeHall, 1990.
[YOU94J Yourdon, E., "Software Reuse", en Application Developmenl Strategies, vol. 6, nm. 12,
diciembre de 1994, pp. 1-16.
[YOU95] Yourdon, E., "When Goood Enough Is Best", en IEEE Software, vol. 12, nm. 3, mayo
de 1995, pp. 79-81.
3. 1. Leer [NOGOOJ y escribir un documento de dos o tres pginas que trate sobre el impacto
del "caos" en la ingeniera del software.
CAPTULO 3
75
3.2. Dar tres ejemplos de proyectos de software que pudieran adaptarse al modelo en cascada.
Ser especfico.
3.3. Proporcionar tres ejemplos de proyectos de software que pudieran adaptarse al modelo
de construccin de prototipos. Ser especifico.

3 . 4. ,Cules adaptaciones se requieren en el proceso si el prototipo evolucionar hacia un
s:stema o producto que puede entregarse?
3.5. Para lograr un desarrollo rpido el modelo ORA asume la existencia de una cosa. Cul es
y por qu dicha suposicin no siempre es verdadera?

mcremental Ser especfico.
3.7.Qu se puede decir acerca del software que est en desarrollo o en mantenimiento
mientras se avanza hacia fuera del flujo de proceso en espiral?
3.8. ,Es posible combinar modelos de proceso? Si la respuesta es afirmativa. mencinese un

CJCmplo
3.9. El modelo concurrente del proceso define un conjunto de "estados". Describir con
palabras propias lo que representan estos estados, y despus indicar cmo entran en juego
dentro del modelo concurrente del proceso.
3.1 o. Cules son las ventajas y desventajas de desarrollar software para el cual la calidad es
to suficientemente buena"? Esto es, qu pasa cuando se resalta la velocidad del desarrollo
sobre la calidad del proyecto?
basado en componentes. Ser especifico.
3.12. Es posible probar que un componente de software o incluso un programa completo est
correcto. Entonces, por qu no todos lo hacen?
3.13. Exponer con argumentos propios el significado de "intereses generales# La iterativa
sobre el ADP se expande con rapidez. Investigar y escribir un documento breve sobre la
situacin actual.
3.14. El proceso unificado y el UML son la misma cosa? Explicar la respuesta.
3 . 15. Cul es la diferencia entre una fase del PU y un flujo de trabajo del PU~
La mayor parte de los textos sobre ingeniera del software consideran los modelos prescriptivos de proceso con algn detalle. Los libros de Sommerville (Software Engineering, sexta
edicin, Addison-Wesley, 2000), Pfleeger (Software Engineering: Theory and Pra.ctice, PrenticeHall, 2001), y Schach (Object Oriented and C/assical software Engineering, McGraw-Hill, 2001)
consideran los paradigmas convencionales y analizan sus fortalezas y debilidades A pesar de
que no se dedica en forma especfica al proceso. Brooks (The Mythical Man -Month, segunda
edicin, Addison-wesley, 1995) presenta la experiencia ganada en proyectos antiguos que
tienen una gran relacin con el proceso. Firesmith y Henderson-Sellers (The OPEN Process
Framework: An Jntroduction, Addison-wesley, 2001), presenta una plantilla general para crear
procesos de software flexible, pero, an asl, indisciplinados# y analiza los atributos y objetivos
del proceso.
Sharpe y McDermott (Worijlow Mode/ing: Tools far Process !mprovement ond Applicotion
Development, Artech House, 2001) presentan herramientas para el modelado de procesos de
sotlware y negocios. Jacobson Griss y Jonsson (Sojlware Reuse, Addison-Wesley, 1997) y
McClure (SOjlware Reuse Techmques, Prentice-Ha/1, J997) presentan mucha informacin til
7()
PARTE UNO
E'L PROCESO DEL SOFTWARE
sobre el desarrollo basado en componentes. Heineman y Council (Component-Based Software

Engineering, Addison-Wesley, 2001) describen el proceso requerido para implementar sistemas
basados en componentes. Kenett y Baker (Software Process Quality: Management and Control,
Marcel Dekker, 1999) consideran la forma en que la gestin de calidad y el diseo de proceso
estn conectados en forma intima entre s.
Ambriola (Software Process Technology, Springer-Verlag, 2001), Derniame y sus colegas
(Software Process: Principies, Meiodology, and Technology, Springer-Verlag, 1999) presentan
conferencias editadas que incluyen muchos aspectos tericos y de investigacin y que son
relevantes para el proceso de software.
Jacobson, Booch y Rumbaugh han escrito el libro fundamental sobre el proceso unificado
UAC99). Sin embargo, los libros de Arlow y Neustadt [ARL02J y una serie de tres volmenes de
Ambler y Constantine [AMB02) ofrecen una excelente informacin complementaria. Krutchen
{The Rational Un!fied Process, segunda edicin, Addison-Wesley, 2000) ha escrito una valiosa
introduccin al PU. La gestin de un proyecto dentro del contexto del PU est escrita en detalle
por Royce (Software Project Management: A Unijied Framework, Addison-Wesley, 1998). La
descripcin definitiva del PU la ha desarrollado la Rational Corporation y est disponible en
lnea en www.rational.com.
En Internet existe una amplia variedad de fuentes de informacin sobre la ingeniera y el
proceso del software. En el sitio web de SEPA se puede encontrar una lista actualizada de referencias en la red mundial que son relevantes para el proceso de software:
http:// www.mhhe. com/ pressman.
n 200 I, Kent eeck y otros I6 notables desarrolladores, escritores y consultores [BECOlJ (conocidos como la ''Alianza Agil") firmaron el ''Manifiesto
para el dcsarrllo gil de software", el cual estableca:
Hemos descubierto mejores formas de desarrollar software al construirlo por nuestra

cuenta y ayudar a otros a hacerlo. Por medio de este ttabajo hemos llegado a valorar:
A los individuos y sus interacdones sobre tos procesos y las herramientas.
Al software en juhCionamienw sobre la documentacin extensa.
A la colaboracin del cliente sobre la negociacin del contrato.
A la respuesta al cambio sobre el seguimiento de un plan,

Esto es, aunque los tnninos a la derecha tjenen valor, nosotros valoramos ms
los aspectos de la izquierda
un manifiesto se asocia por lo general con un movimiento poltico emergente: aquel que ataca a la vieja vanguardia y sugiere un cambio revolucionario (en
De alguna forma, esto es con exactitud de

lo que se trata et desarrollo gil.
A pesar de que las ideas sobyacentes que conducen al desarrollo agu han es~
tacto presentes por muchos aos, no ha sido sino hasta la dcada pasada que estas ideas han cristalizado en un "movimiento". En esencia, los mtodos giles1
se desarrollaron en un intento por superar las deblldade:s advertidas y reales en
la ingeniera del software convencional. El desarrollo gil proporciona beneficios
importantes, pero es imposible aplicarlo en todos los proyectos, prO<;\uctos, personas y situaciones.
el mejor de los casos para mejorar}.
Qu es? La ingeniero de ~
comunicocion activo y continua enlte los deso

Ombinc uno Rfosoffo y un
~ y .los dientes.
conjunto de directrices d e ~ - ,.__ fo hac? los ingehiros de sohwore y
Lo filo$0o busco la sot$fQu5n d}
otros portipanle$ del proyect9 (8e~otes, ~liencliente y la enfre9c1 temprana de se,&;.
twy uwarios finales) trabaan junfs en vn ecvl-
re
git
de proyecto ~
mk>dos i ~
mnimo de productos de trabajo de lo iQ91t
re incremental equipos
os y con alto motivacin;
ena del software; y uno Jimplicldod g,,nerol

del desarrollo, Los directrices de des:irrffo resllan la entresa sobre el anlisis y el diset'lo (aun
que estas octvidades no se d.scortanl, y la
po dgtl: un equipo con orgonizadn propio y

~ cxmtrolo su propio destino. Un eqoipo gil
merita la comunicacin y lo colaboracin entre
todos los que trabajan en l,
.,._. qvi es importanN? El ombien~ moder
ele los negocios ocasiono qoe los sistemas

basados en computadoras y los productos de
no
A los mtodos giles algunas veces se les llama mtodos ligeros o livianos.
77
78
PARTE UNO
No es la anttesis de la prctica slida de la ingeniera del software y es posible

aplicarla como una filosofia predominante para cualquier trabajo de software.
En la economa moderna. a menudo resulta dificil o imposible predecir cmo evolucionarn con el tiempo los sistemas basados en computadoras (por ejemplo, las
aplicaciones Web). Las condiciones del mercado cambian con rapidez, las necesidades de los usuarios finales evolucionan, y las nuevas amenazas competitivas emergen sin previo aviso. En muchas situaciones ya es imposible definir por completo los
requisitos antes de que comience el proyecto. Los ingenieros de software deben ser
tan giles como para responder a un ambiente de negocios fluido.
Lo anterior significa que el reconocimiento de estas realidades modernas ocasiona que se descarten los valiosos principios, conceptos, mtodos y herramientas de
la ingeniera del software? No, en lo absoluto Como todas las disciplinas de ingeniera, la ingeniera del software contina en evolucin. Se puede adaptar con facilidad para enfrentar los retos que implica una exigencia de agilidad.
En un libro que invita a la reflexin y trata sobre el desarrollo gil de software,

Alistair Cockbum (COC02aJ argumenta que los modelos prescriptivos de proceso
presentados en el capitulo 3 tienen una falla importante: olvidan las fragilidades de las
personas que construyen el software de computadora. Los ingenieros de software no
son robots. Ellos muestran una gran variedad en los estilos de trabajo y diferencias
significativas en su grado de habilidad, creatividad, orden. consistencia y espontaneidad. Algunos se comunican muy bien en forma escrita, otros no. Cockbum argumenta que los modelos de proceso pueden "enfrentar las debilidades comunes de la
gente con disciplina o tolerancia [alguna de las dos]" [COC02a). y que los modelos
CAPTULO 4
DESARROLLO GIL
79
de proceso ms prescriptivos eligen la disciplina. l establece: "Como la consistencia en la accin es una debilidad humana, las metodologas que exigen un alto grado de disciplina son frgiles" [COC02a].
Los modelos de proceso funcionarn si proporcionan un mecanismo realista que
fomente la disciplina necesaria, o deben estar caracterizados de manera que muestren "tolerancia" por la gente que realiza el trabajo de la ingeniera del software. De
manera invariable, la gente de software adopta y sostiene ms fcilmente las prcticas tolerantes, pero (como Cockburn lo admite) tal vez sea menos productiva. Como la mayoria de las cosas en la vida, se deben considerar los intercambios.
Qu es la agilidad en el contexto del trabajo de la ingeniera del software? Ivar Jacobson OAC02) proporciona una definicin til:
Agilidad se ha convertido actualmente en la palabra de moda en cuanto se describe un
moderno proceso de software. Cualquiera es gil. Un equipo gil es un equipo rpido
que responde de manera apropiada a los cambios. Stos son. en gran parte, la materia
del desarrollo de software. Cambios en el software que se va a construir, cambios entre los miembros del equipo, cambios debidos a las nuevas tecnologas, cambios de todo tipo que pueden incidir en el producto que se construye o en el proyecto que crea el
producto. En cualquier actividad de software se debe incluir un soporte para los cambios, esto es algo que adoptamos porque es el alma y el corazn del software. un equipo gil reconoce que el software lo desarrollan individuos que trabajan en equipo y que
las aptitudes de esta gente, y su capacidad para colaborar, son esenciales para et xito del proyecto.
De acuerdo con la visin de Jacobson, la insistencia en el cambio es el conductor

primordial hacia la agilidad. Los ingenieros de software deben tener pies veloces si
quieren ajustarse a los cambios rpidos que describe Jacobson.
"La a,lklad es di,imico, con contenido espefico, ajustable al cambio de manera dinll\ko y orienteda ol
aiilien,to.
,,
Pero la agilidad es ms que una respuesta efectiva al cambio. Tambin incluye la
filosofa del manifiesto enunciado al principio de este captulo. Estimula las estructuras y actitudes de los equipos para que la comunicacin (entre los miembros del
equipo, entre los tcnicos y la gente de negocios, entre los ingenieros de software y
sus gerentes) sea ms fcil. Resalta la entrega rpida del software operativo y le resta importancia a los productos de trabajo intermedio (lo cual no siempre es bueno);
adopta al cliente como una parte del equipo de desarrollo y trabaja para eliminar la
actitud del tipo "nosotros y ustedes" que an perjudica a muchos proyectos de software; reconoce que la planeacin tiene sus lmites en un mundo incierto y que el
plan de proyecto debe ser flexible.
80
PARTE UNO
La Alianza Agil [AGI03] define 12 principios para quienes quieren alcanzar la agi-
lidad:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana
y continua de software 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 ambiente y
el soporte que necesitan, y confiar en ellos para obtener el trabajo realizado.

6. El mtodo ms eficiente y efectivo de transmitir informacin hacia y dentro de
un equipo de desarrollo es la conversacin cara a cara.
7. El software en funcionamiento es la medida primaria de progreso.

8. Los procesos giles promueven el desarrollo sustentable. Los patrocinadores,
desarrolladores y usuarios deben ser capaces de mantener un paso constante

de manera indefinida.
9. La atencin continua a la excelencia tcnica y al buen diseo mejora la agilidad.
10. La simplicidad -el arte de maximizar la cantidad de trabajo no realizado- es
esencial.
11. Las mejores arquitecturas, los mejores requisitos y los mejores diseos emer-
gen de equipos autoorganizados.

12. A intervalos regulares el equipo refleja la forma en que se puede volver ms
efectivo; entonces su comportamiento se ajusta y adecua en concordancia.

La agilidad se puede aplicar en cualquier proceso de software. Sin embargo, para lograrlo es esencial que el proceso sea diseado en una forma que permita al
equipo del proyecto adaptar y coordinar las tareas, conducir la planeacin en una
forma que entienda la fluidez de un enfoque de desarrollo gil, eliminar todo pero no los productos de trabajo esenciales y mantenerlos controlados, y enfatizar
una estrategia de entrega incremental que proporcione software en funcionamiento al cliente tan rpido como sea factible para el tipo de producto y el ambiente operativo.
CAPiTtJLO 4
DESARROLLO GIL
81
Cualquier proceso gil de software se caracteriza de una manera que refiere tres su
posiciones clave fFOW02J acerca de la mayoria de los proyectos de software:
1. Resulta dificil predecir cules requisitos del software persistirn y cules cambiarn. De igual forma, es dificil presagiar cmo cambiarn las prioridades del
cliente mientras se ejecuta un proyecto.
2. Para muchos tipos de software, el diseo y la construccin estn intercalados.
Esto es, ambas actividades se deben realizar de manera conjunta, de modo
que los modelos de diseo sean probados conforme se crean. Resulta difcil
predecir cunto diseo se necesita antes de que la construccin se utilice para
probar el diseo.
3. El anlisis, el diseo y la construccin no son predecibles (desde el punto de
vista de la planeacin). lo que sera deseable.
Dados los puntos anteriores, surge una pregunta importante: cmo se crea un
proceso susceptible de manipular en forma impredecible? La respuesta, como ya se
ha puntualizado antes, reside en la adaptabilidad del proceso (a un proyecto y a condiciones tcnicas que cambian con rapidez). Por lo tanto, un proceso gil debe ser
adaptable.
Pero una adaptacin continua sin un progreso logra muy poco. Por lo tanto, un
proceso gil de software debe adaptarse en forma incremental. Para llevar a cabo
una adaptacin incremental, un equipo gil requiere de la retroalimentacin con el
cliente (para que sea factible realizar las adaptaciones apropiadas). Un catalizador
efectivo para la retroalimentacin del cliente es un prototipo operacional o una porcin de un sistema operacional. Por lo tanto, debe insttuirse una estrategia incremen
tal de desarrollo. Los incrementos de software (prototipos ejecutables o una porcin de
un sistema operacional) deben entregarse en cortos periodos para que la adaptacin
mantenga un buen ritmo con el cambio (imprevisibilidad). Este enfoque iterativo le
permite al cliente evaluar el incremento del software de manera regular, proporcionar la retroalimentacin necesaria al equipo de software, e influir sobre las adaptaciones del proceso que se realizan para adecuar la retroalimentacin.
. . . . . . . pcn la rllroalimentaci6n r6pida, ni en el proceso de desarrulle I
ti,...~ 1
4 .2.1 Las poiticas del desarrollo gil

Existe un debate considerable (a veces estridente) sobre los beneficios y la aplicabilidad del desarrollo gil del software como alternativa a procesos de ingeniera del
software ms convencionales. Jim Highsmith [HIG02a) (a manera de broma) analiza
los extremos cuando caracteriza el sentimiento del campo proagilidad ("agilitado-
82
No es necesorio elegir
en/Te agilidad einge
nie,a del software. En
lugar de ello, se
puede definir un
enfoque de ingenie,o
de software que seo
gil.
PARTE UNO
res"). "Los metodlogos tradicionales son un conjunto de tipos que se arrastran en

el lodo y que prefieren producir documentacin que no fluye, en vez de un sistema
de trabajo que cubra las necesidades del negocio." Como contraparte, establece la
posicin del campo de la ingeniera del software (de nuevo, en forma de broma):
"Los metodlogos 'ligeros' y, eh, 'giles' son un conjunto de intrusos informticos
que van a estar ah para dar una maldita sorpresa cuando intenten elevar sus juguetes al nivel de software de la empresa".
Al igual que todos los argumentos sobre la tecnologa del software, este debate
sobre la metodologa corre el riesgo de degenerar en una guerra religiosa. Si estalla
la guerra, desaparece el pensamiento racional, y las creencias, en vez de los hechos,
guan la toma de decisiones.
Nadie est en contra de la agilidad. La pregunta real es: cul es la mejor manera de lograrla? Igual de importante es la pregunta: cmo se construye un software
que satisfaga hoy las necesidades de los clientes y muestre las caractersticas de calidad que le permitan extenderse y escalar para cubrir a largo plazo las necesidades
del cliente?
No existen respuestas absolutas para ninguna de estas preguntas. Aun dentro de
la escuela gil se han propuesto varios modelos de proceso (seccin 4.3). cada uno
con un enfoque sutilmente diferente para el problema de la agilidad. Dentro de cada
modelo hay un conjunto de "ideas" (que los agilitadores suelen llamar "tareas de trabajo") que representan una separacin significativa de la ingenieria del software
convencional. Y aun as, muchos conceptos de agilidad son tan slo adaptaciones de
buenos conceptos de la ingeniera del software. Como punto final, hay mucho que
ganar si se considera Jo mejor de ambas escuelas, y nada que ganar si se denigra alguno de los dos enfoques.
El lector interesado puede consultar [HIGO 1), [H!G02a) y (DEM02) para un animado resumen de los aspectos tcnicos y polticos importantes.
4.2.2
Factores humanos
Los defensores del desarrollo gil del software resaltan la importancia de los "factores de las personas" en un desarrollo gil exitoso. Como establecen Cockburn y
Highsmth [COCO l J: "El desarrollo gil se centra en los talentos y las habilidades de
los individuos, puesto que el proceso se ajusta a personas y equipos especficos". El
punto clave en esta afirmacin es que el proceso se ajusta a las necesidades de las personas y del equipo, y no al revs.2
"Aqudo openas suficiente poro un equipo es excesivo o insuficiente poro otro.
AUstair
e.e.._
La mayora de las organizaciones de software exitosas reconocen esta realidad sin importar el modelo de proceso que elijan.
CAPiTuLo 4
DESARROU.O GIL
83
Si los miembros del equipo de software van a manejar las caractersticas del proceso que se aplica para construirlo, debe existir un gran nmero de rasgos clave entre la gente de un equipo gil y el equipo mismo:
Competencia. En el contexto de un desarrollo gil (al igual que en la ingeniera

del software convencional), la "competencia" abarca un talento innato, habilidades
especficas relacionadas con el software, y un conocimiento general del proceso
que el equipo haya elegido aplicar. La habilidad y el conocimiento del proceso pueden y deben ensearse a toda la gente que funge como miembro de un equipo
gil.
Enfoque comn. Aunque los miembros del equipo gil desempeen tareas diferentes y aporten distintas habilidades al proyecto, todos deben enfocarse en una
meta: entregar al cliente un incremento de trabajo de software dentro del tiempo
establecido. Alcanzar esta meta requiere que el equipo tambin se centre en adaptaciones continuas (pequeas y grandes) mediante las cuales el proceso satisfar
las necesidades del equipo.
Colaboracin. La ingeniera del software (sin considerar el proceso) incluye

evaluar, analizar y usar informacin que se comunica al equipo de software; crear
informacin que ayudar al cliente y a otros a entender el trabajo del equipo; y
construir informacin (software de computadora y bases de datos relevantes) que
ofrezca un valor comercial para el cliente. Estas tareas se cumplirn si los miembros del equipo colaboran, entre ellos, con el cliente y con sus gerentes.
Habilidad para la toma de decisiones . Todo buen equipo de software (incluidos los equipos giles) debe permitirse la libertad de controlar su propio destino. Esto implica que al equipo se le d autonomia, es decir, autoridad para tomar
decisiones en cuanto a cuestiones tcnicas y del proyecto.
capacidad de resoluci n de problemas confusos. Los gestores de software

deben reconocer que el equipo gil enfrentar ambigedades y sufrir golpes de
manera continua debido al cambio. En algunos casos, el equipo debe aceptar que
el problema que est resolviendo hoy tal vez no sea el problema que debe resolverse maana. Sin embargo, las lecciones aprendidas en cualquier actividad para
la resolucin de problemas (incluidas aquellas que sirven para solucionar el problema errneo) pueden beneficiar al equipo en fases posteriores del proyecto.
Confianza y respeto mutuo. El equipo gil se debe convertir en lo que De
Marco y Lister [OEM98J llaman un equipo "cuajado" (vase el capitulo 21). un equipo cuajado muestra la confianza y el respeto necesarios para que "se unan con
tanta fuerza, que el todo sea mayor que la suma de las partes" [DEM98J .
Organizacin propia. En el contexto del desarrollo gil, la organizacin propia
implica tres factores: 1) el equipo gil se organiza a si mismo para el trabajo que
debe hacerse; 2) el equipo organiza el proceso que mejor se ajusta a su ambiente
local; 3) el equipo organiza el programa de trabajo con el que se alcance de mejor
84
PARTE UNO
EL POOCESO DEL SOF'IWARE
manera la entrega del incremento del software. La organizacin propia tiene varios
beneficios tcnicos, pero lo ms importante es que mejora la colaboracin y eleva
la moral del equipo. En esencia, el equipo sirve como su propia gestora. Ken Schwaber [SCH02] puntualiza estos aspectos cuando escribe: "El equipo selecciona la
cantidad de trabajo que cree que es capaz de hacer dentro de la iteracin, y el
equipo se compromete con el trabajo. Nada desalienta ms a un equipo que alguien ms se comprometa por l. Nada motiva ms a un equipo que aceptar la responsabilidad de cumplir los compromisos que l mismo hizo".
La historia de la ingeniera del software est llena de decenas de descripciones y metodologas, mtodos de modelado y notaciones, herramientas y tecnologas obsoletas. Cada elemento surgi con notoriedad y despus Jo eclips algo nuevo y (supuestamente) mejor. con la introduccin de un amplio espectro de modelos giles de
proceso -cada uno en busca de su aceptacin dentro de la comunidad del desarrollo de software- el movimiento gil est en la misma ruta histrica.3
, .... ,efisMn VI Iris ICI$ metodologas como un adolescente WI tros la ropa;
s..,._~,
En las siguientes secciones se presenta una visin general de cierto nmero de diferentes modelos giles de proceso. Existen muchas similitudes (en filosofa y prctica) entre estos enfoques. La intencin es subrayar aquellas caractersticas de cada
mtodo que lo hacen nico. Es importante sealar que todos los modelos giles se
ajustan (en mayor o menor grado) al Manifiesto para el desarrollo de software y a los
principios enunciados en la seccin 4.1.
4.3.1
Programacin extrema (PE)
A pesar de que los primeros trabajos sobre las ideas y los mtodos asociados con la
programacin extrema (PE) se realizaron a finales de la dcada de 1980, el trabajo
fuehlllo
.. .f"""..
.....
~
excMIMl6n*
las ,im '1 tt.
fundamental sobre la materia, escrito por Kent Beck [BEC99], se public en 1999. Los
libros subsiguientes de Jeffries et al. OEFOl] sobre los detalles tcnicos de la PE, y el
trabajo adicional de Beck y Fowler [BECO lb] sobre la planeacin de la PE expusieron
los detalles del mtodo.
La PE utiliza un enfoque orientado a objetos (parte 2 de este libro) como su paradigma de desarrollo preferido. La PE abarca un conjunto de reglas y prcticas que
ocurren en el contexto de cuatro actividades del marco de trabajo: planeacin, dise3
Esto no es algo malo. Antes de que uno o ms modelos o mtodos sean aceptados como un estndar 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 "perdedores" desaparecen o se unen a los modelos "ganadores".
CAPTULO 4
85
DESARROLLO GIL
diseo simple
cortos CRC
soluciones pico
prototipos
historias del usuario
valores
criterios de los pruebas de iteracin
pion de iteracin
Lonzomiento
incremento de software
velocidad calculada
del proyecto
pruebo de unidad
integracin continua
pruebas de aceptacin
o, codificacin y pruebas. En la figura 4.1 se ilustra el proceso de la PE y se observan algunas de las ideas y tareas clave asociadas con cada actividad del marco de trabajo. En los siguientes prrafos se resumen las actividades clave de la PE.
Planeadn. La actividad de planeacin comienza creando una serie de historias

(tambin llamadas historias del usuario) que describen las caractersticas y la funcionalidad requeridas para el software que se construir. cada historia (similar a los casos de uso descritos en los captulos 7 y BJ la escribe el cliente y se coloca en una
carta ndice. El cliente le asigna un valor (es decir, una prioridad) a la historia basndose en los valores generales del negocio respecto de la caracterstica o la funcin. 4
Los miembros del equipo de la PE evalan entonces cada historia y le asignan un
costo, el cual se mide en semanas de desarrollo. Si la historia requiere ms de tres
semanas de desarrollo, se le pide al cliente que la divida en historias menores, y se
realiza de nuevo la asignacin del valor y el costo. Es importante destacar que las
historias nuevas pueden escribirse en cualquier momento.
Los clientes y el equipo de PE trabajan juntos para decidir cmo agrupar las historias hacia el prximo lanzamiento (el siguiente incremento de software) para que
el equipo de la PE las desarrolle. Una vez establecido el compromiso bsico (el
acuerdo de las historias que se incluirn, la fecha de entrega y otras cuestiones del
proyecto) para un lanzamiento, el equipo de la PE ordena las historias que se desarrollarn de una de las siguientes tres maneras: l) todas las historias sern imple4
El valor de una historia puede depender tambin de la presencia de otra historia.
86
PARTE UNO
.11 :i
Enelsille
........
Cz../'1(#/dff
I

Vlilctso"piaode
~ - pa111ta l'l
EL PnOCESO DEL SOFTWARE
mentadas de un modo inmediato (dentro de pocas semanas); 2) las historias con valor ms alto se movern en el programa y se implementarn al principio; o 3) las
historias ms riesgosas se movern dentro del programa y se implementarn al
principio.
Despus de que se ha entregado el primer lanzamiento del proyecto (tambin llamado incremento de software), el equipo de la PE calcula la velocidad del proyecto.
Dicho de un modo ms simple, la velocidad del proyecto es el nmero de historias de
los clientes implementado durante el primer lanzamiento. Entonces, la velocidad del
proyecto puede utilizarse para l) ayudar a estimar fechas de entrega y el programa
para lanzamientos subsecuentes, y 2) determinar si se ha hecho un compromiso excesivo en algunas de las historias de todo el proyecto de desarrollo. Si se presenta
un compromiso excesivo, el contenido de los lanzamientos se modifica o se cambian
las fechas de las entregas finales.
Conforme avanza el trabajo de desarrollo, el cliente puede agregar historias, cambiar el valor de la historia existente, dividir historias o eliminarlas. Entonces el equipo de la PE considera de nuevo los lanzamientos restantes y modifica sus planes de
acuerdo con ello.
Diseo. El diseo de la PE sigue de manera rigurosa el principio MS (mantenerlo

simple). Siempre se prefiere un diseo simple respecto de una presentacin ms
compleja. Adems, el diseo ofrece una gua de implementacin para una historia
como est escrita, ni ms ni menos. Se desaprueba el diseo de funcionalidad extra=
(porque el desarrollador supone que se requerir ms tarde).
La PE apoya eJ uso de tarjetas CRC (captulo 8) como un mecanismo efectivo para pensar en el software en un contexto orientado a objetos. Las tarjetas CRC (cola borador-responsabilidad-clase) identifican y organizan las clases orientadas al objeto6 que son relevantes para el incremento del software actual. El equipo PE conduce el ejercicio del diseo por medio de un proceso similar al descrito en el captulo
8 (seccin 8.7.4.). Las tarjetas CRC son el nico producto de trabajo realizado como
parte del proceso de la PE.
Si se encuentra un problema dificil de diseo como parte del diseo de la historia, la PE recomienda la creacin inmediata de un prototipo operacional de esa porcin del diseo. El prototipo del diseo, llamado la solucin pico, se implementa y
evala. El propsito es reducir el riesgo cuando comience la verdadera implementa5 Estas directrices de diseo se deberan seguir en todos los mtodos de ingenierla del software,
aunque a veces las notaciones y terminologias sofisticadas que se utilizan en el diseo pueden emplearse de una manera ms simple.
6
En el captulo 8, y a lo largo de la parte 2 del libro, se estudian las clases orientadas a objetos.
CAPTULO 4
DESARROLLO GIL
87
cin y validar las estimaciones originales en la historia que contiene el problema del
diseo.
La PE apoya la refabricacin, una tcnica de construccin que tambin lo es de diseo. Fowler [FOWOOJ describe la refabricacin de la siguiente manera:
Refabricacin es el proceso de cambiar un sistema de software de tal manera que no altere el comportamiento externo del cdigo y que mejore la estructura interna. Es una manera disciplinada de limpiar el cdigo [y modificar/simplificar el diseo interno]. lo que
minimiza las oportunidades de introducir errores. En esencia, al refabricar, se mejora el
diseo del cdigo despus de que se ha escrito.
Debido a que el diseo de la PE virtualmente no utiliza la notacin y produce, si acaso, muy pocos productos de trabajo, distintos a las tarjetas de CRC y soluciones pico, el diseo se considera como un artefacto que puede y debe modificarse de manera continua a medida que prosigue la construccin. El propsito de refabricar es
controlar estas modificaciones al sugerir pequeos cambios del diseo que "pueden
mejorar de manera radical el diseo" [FOWOOJ. Sin embargo, debe notarse que el esfuerzo requerido para refabricar puede aumentar en forma drstica a medida que
crece el tamao de la aplicacin.
Una nocin central en la PE es que el diseo ocurre tanto antes como despus
del comienzo de la codificacin. Refabricar significa que el diseo ocurre de manera continua a medida que se construye el sistema. De hecho. la actividad de cons
truccin misma le proporcionar al equipo de PE una gula sobre cmo mejorar el
diseo.
Codificadn. La PE recomienda que despus de disear las historias y realizar el

trabajo de diseo preeliminar el equipo no debe moverse hacia la codificacin, sino
que debe desarrollar una serie de pruebas de unidad que ejerciten cada una de las
historias que vayan a incluirse en el lanzamiento actual (incremento de software) .7
Una vez creada la prueba de unidad, el desarrollador es ms capaz de centrarse en
lo que debe implementarse para pasar la prueba de unidad. No se agrega nada extrao (MS). Una vez que el cdigo est completo, la unidad puede probarse de inmediato, y asi proporcionar una retroalimentacin instantnea a los desarrolladores.
Un concepto clave durante la actividad de codificacin (y uno de los aspectos de
la PE de los que ms se ha hablado) es la programacin en pareja. La PE recomienda
que dos personas trabajen juntas en una estacin de trabajo de computadora para
crear el cdigo de una historia. Esto proporciona un mecanismo para la resolucin
de problemas en tiempo real (dos cabezas piensan mejor que una) y el aseguramiento de la calidad en las mismas condiciones. Tambin alienta que los desarrolladores
se mantengan centrados en el problema que se tiene a la mano. En la prctica, cada persona tiene un papel sutilmente diferente. Por ejemplo, una persona puede pen-
7 Este enfoque es anlogo a conocer las preguntas del examen antes de comenzar a estudiar Esto facilita mucho ms el estudio al enfocar la atencin slo sobre las preguntas que sern formuladas.
88
PARTE UNO
sar en los detalles de codificacin de una porcin particular del diseo, mientras que la
otra se asegura de que se sigan los estndares 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 programadores completan su trabajo el cdigo que desarrollaron se
integra con el trabajo de otros. En algunos casos esto lo lleva a cabo diariamente el
equipo de integracin. En otros casos, la pareja de programadores es la responsable
de la integracin. Esta estrategia de "integracin continua" ayuda a evitar problemas de
compatibilidad e interfaz y proporciona un ambiente de "prueba de humo" (capitulo
13) que ayuda a descubrir los errores desde el principio.
PrUebas. Ya se ha hecho notar que la creacin de una prueba de unidad8 antes de
&1
~~
c&vE
Los pruebos de
oceptncin de lo PE se
devon de los historias
del usuoo.
comenzar la codificacin es un elemento clave para el enfoque de la PE. Las pruebas de unidad que se crean deben implementarse con un marco de trabajo que permita automatizarlas (por lo tanto, pueden ejecutarse de manera fcil y repetida). Esto apoya una estrategia de regresin de prueba (captulo 13) cuando el cdigo se modifica (al cual a menudo se le confiere la filosofia de la PE de refabricar).
Cuando las unidades individuales de prueba se organizan en un "conjunto universal de pruebas" [WEL99J, las pruebas de integracin y validacin del sistema pueden
realizarse a diario. Esto proporciona al equipo de PE una indicacin continua del
progreso y tambin puede encender luces de emergencia previas si las cosas salen
mal. Wells [WEL99] establece: "Arreglar problemas pequeos cada pocas horas toma menos tiempo que arreglar problemas enormes justo antes de la fecha limite".
Las pruebas de aceptacin de la PE, tambin llamadas pruebas del cliente, las especifica el cliente y se enfocan en las caractersticas generales y la funcionalidad del
sistema, elementos visibles y revisables por el cliente. Las pruebas de aceptacin se
derivan de las historias del usuario que se han implementado como parte de un lanzamiento de software.
aicnta el desmroUo de sojtwil.re 1f11.
~dePou;Milw.
Las pruebas de unidad, que se tratan con detalle en el captulo 13, se enfocan sobre un componente
individual del software, al ejercitar la interfaz de los componentes. las estructuras de datos y la funcionalidad en un esfuerzo por descubrir los errores locales en el componente.
CAPTULO 4
DESARROLLO _GIL
89
4.3.2 Desarrollo adaptativo de software (DAS)

El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith [HIGOOJ como
una tcnica para construir software y sistemas complejos. Los apoyos filosficos del
DAS se enfocan en la colaboracin humana y la organizacin propia del equipo.
Highsmith [HIG98J expone lo anterior cuando escribe:
La organizacin propia es una propiedad de los sistemas adaptativos complejos, similar a
un "aj" colectivo; es en el momento de energa creativa cuando surge la solucin a algn
problema persistente. La organizacin propia emerge cuando los individuos. los agentes
independientes (clulas en un cuerpo, especies en un ecosistema, desarrolladores en un
equipo de software) cooperan [colaboran] para crear salidas emergentes. Una salida
emergente es una propiedad ms all de la capacidad de cualquier agente individual. Por
ejemplo, las neuronas individuales del cerebro no poseen conciencia, pero en forma co
lectiva generan la propiedad de la conciencia. Tendemos a ver este fenmeno del surgimiento colectivo como un accidente, o al menos como independiente y sin reglas. El
estudio de la organizacin propia demuestra que dicha visin es errnea.
90
PARTE UNO a
PROCESO DEL SOF\'WARE
iihliD
Desarrollo
adaptativo de
software.
Recopilacin de requisitos
ploneocin del ciclo odoptotivo
enunciado de la misin
restricciones del proyecto
requisitos bsicos
JAD
especificaciones mnimas
pion de lanzamiento en el tiempo
Lanzamiento
incremento de software
a;uste para ce/os subsecuentes
componentes implementados/probados
grupos de enfoque para retroalimentacin

revisiones tcnicas formales
post morlem
---
EuhilO
wnial ,......
i)1fesp111ulbl$.
Cules son
las carade
rstkas de los
ciclos adaptativos
'del DAS?
la coloboroci6n
efectivo con el diente

ocurrir slo si se
eliminan todos los
octitudes del tipo *yo
yustedesH.
Highsmith argumenta que un enfoque de desarrollo gil y adaptativo basado en la

colaboracin es "tanto como una fuente de orden en las complejas interacciones entre disciplina e ingeniera". l define un "ciclo de vida" del DAS (figura 4.2), el cual
incorpora tres fases: especulacin, colaboracin y aprendizaje.
Especulacin. En esta fase se inicia el proyecto y se conduce el ciclo adaptativo de

planeacin. Este ltimo utiliza informacin de inicio del proyecto -el enunciado de
la misin del cliente, restricciones de proyecto (por ejemplo, fechas de entrega o descripciones del cliente) y los requisitos bsicos- para definir el conjunto de ciclos de
lanzamiento (incrementos del software) que se requerirn para el proyecto.9
Colaboracin. La gente motivada trabaja junta de una forma que multiplica su talento y sus salidas creativas ms all de sus nmeros absolutos. Este enfoque de colaboracin es un tema recurrente en todos los mtodos giles, pero la cooperacin
no es fcil. No es slo comunicacin, aunque la comunicacin es parte de ella. No
es slo un asunto de trabajo en equipo, aunque un equipo "cuajado" (captulo 21) es
esencial para la presencia de la colaboracin real. No es un rechazo al individualismo, ya que la creatividad individual representa un papel importante en el pensamiento de colaboracin. Esto es, por encima de todo, una cuestin de confianza. Las
personas que trabajan juntas deben confiar entre si para l) criticar sin animosidad;
9 Obsrvese que el plan del ciclo adaptativo puede adaptarse, y con probabilidad lo har, al proyecto
cambiante y a las condiciones del negocio.
CAPTULO 4
91
DESARROLLO GIL
1) ayudar sin resentimientos; 3) trabajar tan duro o ms duro de lo que ya lo hacen;

4) tener el conjunto de aptitudes para contribuir al trabajo en curso; y 5) comunicar
los problemas o preocupaciones en una forma que conduzca a la accin efectiva .
8$
. .flSla escudlor. He aprendido mucho al eS<uchar a las personas. La mayora ~ lo 9et11e n~

nst1terw1J ,
Aprendizaje. Como miembros de un equipo de DAS se comienzan a desarrollar los
componentes integrantes de un ciclo adaptativo, la importancia radica en el aprendizaje y en el progreso a travs de un ciclo completo. De hecho, Highsmith [HIGGOO]
argumenta que los desarrolladores de software a menudo sobreestiman su comprensin (de la tecnologa, el proceso y el proyecto). y que el aprendizaje les podra
ayudar a mejorar su grado de entendim iento real. Los equipos del DAS aprenden de
tres maneras:
1. Grupos enfocados. El cliente o los usuarios finales proporcionan retroalimentacin sobre los incrementos de software que se entregan. Esto indica en
forma directa la satisfaccin o la insatisfaccin de las necesidades del negocio.
2. Revisiones tcnicas formales. Los miembros del equipo del DAS revisan
los componentes del software desarrollado mientras mejoran su calidad y su
aprendizaje.
3 . Post mortem. El equipo de DAS se vuelve introspectivo al vigilar su propio
desempeo y proceso (con el prposito de aprender acerca de su enfoque y

despus mejorarlo).
Es importante destacar que la filosofla del DAS es meritoria sin importar el modelo
de proceso empleado. El acento general en la dinmica de la organizacin propia en

los equipos, la colaboracin interpersonal y el aprendizaje individual y por equipo
conducen grupos de proyectos de software con una mayor posibilidad de xito.
4.3.3
Mtodo de desarrollo de sistemas dinmicos (MDSD)
El mtodo de desarrollo de sistemas dinmicos (STA97J es un enfoque de desarrollo de

software gil que "proporciona un marco de trabajo para construir y mantener sistemas con restricciones de tiempo muy estrechas mediante el empleo de la construccin de prototipos incrementales en un ambiente de proyecto controlado" [CCS02J.
Similar a algunos aspectos del proceso DRA descrito en el captulo 3, el MDSD sugiere una filosofa tomada de una modificacin del principio de Pareto. En este caso, 80 por ciento de la aplicacin se puede entregar en 20% del tiempo que tomara
entregar 100 por ciento de la aplicacin (sistema completo).
Al igual que la PE y el OSA, el MDSD sugiere un proceso iterativo de software. Sin
embargo, el enfoque del MDSD en cada iteracin sigue la regla del 80 por ciento. Esto es, slo se necesita el trabajo suficiente para cada incremento y para facilitar el
92
PARTE UNO EL PROCESO DEL SOfl'WARE
movimiento hacia el nuevo incremento. Los detalles restantes se pueden completar

posteriormente cuando se conozcan ms los requisitos de negocios o cuando los
cambios hayan sido solicitados o ajustados.
En la red mundial hay una organizacin (DSDM Consortium, www.dsdm.org) que
de manera colectiva asume el papel de "conservador" del mtodo. Esta organizacin
ha definido un modelo gil de proceso, llamado el ciclo de vida del MDSD. Este mtodo define tres ciclos iterativos diferentes, a los cuales preceden dos actividades del
ciclo de vida adicionales:
Estudio deJactiMidad: establece los requisitos bsicos de negocio y las restricciones asociadas con la aplicacin del mtodo y para evaluar si la aplicacin es una
candidata viable para el proceso del MDSD.
Estudio de negocios: establece los requisitos funcionales y de informacin que permitirn que la aplicacin proporcione un valor al negocio; tambin define la arquitectura bsica de la aplicacin.
Iteracin de modelo funcional: produce una serie de prototipos incrementales que
demuestran la funcionalidad para el cliente (nota: todos los prototipos del MDSD estn diseados para evolucionar hacia la aplicacin entregable). El propsito durante este ciclo iterativo es recopilar requisitos adicionales mediante la retroalimentacin de lo que obtiene el usuario, mientras ste trabaja con el prototipo.
Iteracin de construccin y diseo: revisa la construccin de prototipos durante la
iteracin del modelo funcional para asegurar que cada uno de ellos ha sido desarrollado de una manera que Je permitir proporcionar un valor operativo de negocios
para los usuarios finales. En algunos casos, la iteracin del modelo funcional y el diseo y la iteracin de construccin suceden en forma concurrente.
Implementacin: coloca el incremento de software ms reciente (un prototipo
"operacionalizado") en el ambiente operativo. Se debe destacar que 1) el incremento puede no estar 100 por ciento completo o 2) se pueden requerir cambios cuando
el incremento se coloca en el sitio. En cualquier caso, el trabajo de desarrollo del
MDSD contina al regresar a la actividad de iteracin del modelo de funcin.
El MDSD se puede combinar con la PE para obtener un enfoque conjunto que define un modelo slido de proceso (el ciclo de vida del MDSD) con los aspectos prcticos (PE) necesarios para construir incrementos de software. Adems, los conceptos del DAS de colaboracin y equipos autoorganizados se pueden adaptar a un modelo de proceso combinado.
4.3.4 Mel
Mel (trmino derivado de una jugada de rugby1) es un modelo gil de proceso que
desarrollaron Jefff Sutherland y su equipo a principios de la dcada de 1990. En aos

1O Un grupo de jugadores se alinea alrededor del baln y los compaeros de equipo trabajan juntos (algunas veces de manera violenta) para desplazar el baln hacia el lado contrario del campo de juego.
CAPTULO 4
93
DESARROLLO GIL
recientes, Schwaber y Beedle [SCHOI] han presentado el desarrollo posterior de los

mtodos de mel. Los principios de la mel [ADM96J son consistentes con el manifiesto gil.
Los equipos de trabajo pequeos estn organizados para "maximizar la comunicacin, minimizar los gastos generales y maximizar el hecho de compartir conocimiento tcito e informal".
El proceso debe adaptarse a los cambios tcnicos y de negocios "para asegurar que se produzca el mejor producto posible".
El proceso produce incrementos frecuentes de software "los cuales se pueden
inspeccionar, ajustar, probar, documentar y construir".
El trabajo de desarrollo y la gente que lo realiza estn divididos en "particiones o paquetes de bajo acoplamiento".
conforme se construye el producto se realizan pruebas y documentacin
constantes.
Los procesos de mel proporcionan la "capacidad de declarar un producto como 'realizado' siempre que esto se requiera (porque la competencia acaba de
hacer un lanzamiento. porque la compaa necesita el dinero, porque el usuario/cliente necesita las funciones. porque ya se est en el momento en que se
prometi... " [ADM96].
Con los principios de la mel se guian las actividades dentro de un proceso que incorpora las siguientes actividades del marco de trabajo: requisitos, anlisis, diseo,
evolucin y entrega. En cada actividad del marco de trabajo las tareas de trabajo suceden dentro del patrn de proceso (tratado en el prrafo siguiente) llamado sprint.
El trabajo realizado dentro de un sprint (el nmero requerido de sprints variar de
acuerdo con el tamao y la complejidad del producto) se adapta al problema y con
frecuencia lo modifica en tiempo real el equipo de mel. En la figura 4..3 se Ilustra el
flujo general del proceso de mel.
'1a. . .,_,_ <Omtruir un so/twor, m$ suore.
.............
La mel subraya el uso de un conjunto de "patrones de proceso de software"
[NOY02] que ha probado su efectividad en proyectos con tiempos de entrega muy re
<lucidos, requisitos cambiantes y condiciones crticas en los negocios. cada uno de

estos patrones de proceso define un conjunto de actividades de desarrollo:
Retrasos: son una lista que considera la prioridad de los requisitos o caractersti
cas de proyecto que proporcionan un valor comercial para el cliente. En cualquier
momento se pueden agregar elementos a los retrasos (as se introducen los cambios). El gerente de producto evala los retrasos y actualiza las prioridades de acuerdo con lo requerido.
94
PARTE UNO EL PROCESO DEL SOFTWARE
iii'I/Cf
Flujo de proceso de la mel.
Retraso de sprint:
Caractersticas
~ - - :',~.- i_i~p_~-ind_i<s, o
Elementos
de retraso
Mel: reunin diaria de 15 minutos

los miembros del equipo responden
o las preguntas bsicas
1) Qu hiciste desde lo ltima reunin?
2) Tienes algn obstculo?
3) Qu hars antes de la prxima reunin?
__,c2J
;::.::i;_s_ ......_ _ _
0~.~1se demuestra
al final del sprint
Retraso del producto:

Caractersticas del producto deseadas por el cliente
que han recibido prioridad
Sprint: consiste en unidades de trabajo que se requieren para satisfacer un requi-
Lo mel incorporo un
conjunto de patrones
de proceso que resalto
los prioridades del
proyecto, lo divisin
del trabajo, los
unidades de trobojo, lo
comunicacin ylo
retroalimentacin
frecuente del cliente.
sito definido en los retrasos en un periodo predefinido (el lapso usual es de 30 das).
En esta etapa, los elementos de los retrasos a los que se dirigen las unidades de trabajo del sprint estn congelados (es decir, durante el sprint no se introducen cambios). Por lo tanto, el sprint permite a los miembros del equipo trabajar en un ambiente enfocado al corto plazo, pero estable.
Reuniones de mel: son reuniones cortas (por lo general de 15 minutos) y las realiza a diario el equipo de mel. Existen tres preguntas que plantean y responden todos los miembros del equipo.
Qu hiciste desde la ltima reunin?
Cules obstculos encontraste?
Qu esperas lograr para la siguiente reunin del equipo?
Un lder de equipo, llamado "maestro de la mel", preside la reunin y evala las
respuestas de cada persona. Cada reunin de mel ayuda al equipo a descubrir problemas potenciales tan pronto como sea posible. Estas reuniones diarias tambin
conducen a la "socializacin del conocimiento" [BEE99] y, por ende, a promover una
estructura de equipo con organizacin propia.
CAPTULO 4
DESARROLLO GIL
95
Demostracin: se entrega el incremento de software al cliente de forma que ste

demuestre y evale la funcionalidad implementada. Es importante sealar que la demostracin quiz no contenga toda la funcionalidad planeada, sino aquellas funciones susceptibles de entregarse dentro del periodo establecido.
Beedle y sus colegas [BEE99J presentan un anlisis completo de estos patrones y
establecen: "La MEL supone la existencia del caos ... ". El patrn de proceso de la
mel permite que un equipo de desarrollo de software trabaje de manera exitosa en
un mundo donde la eliminacin de la incertidumbre es imposible.
4.3.5
Cristal
Alistair Cockburn [COC02a] y Jim Highsmith [HIG02b] crearon la familia cristal de los
mtodos giles 11 con el fin de lograr un enfoque de desarrollo de software que coloca un premio en la "manejabilidad" durante lo que Cockburn caracteriza como "un
juego cooperativo de inventiva y comunicacin con recursos limitados, con una meta primaria consistente en la entrega de software til y en funcionamiento y una meta
secundaria de prepararse para el juego siguiente" [COC02bJ.
Para alcanzar la manejabilidad, Cockburn y Highsmith definieron un conjunto de
metodologas, cada una de ellas con elementos esenciales comunes a todas, y funciones, patrones de proceso. productos de trabajo y prcticas nicas en cada una cte
ellas. En realidad, la familia cristal es un conjunto de procesos giles, los cuales han
probado su efectividad en diferentes tipos de proyectos. El objetivo es permitir que
los equipos giles seleccionen el miembro de la familia cristal ms apropiado para
su proyecto y ambiente.
4.3.6
Desarrollo conducido por caractersticas (DCC)
El desarrollo conducido por caracteristicas (DCC) lo concibieron originalmente Peter

Coad y sus colegas [COA99J como un modelo de proceso prctico para la ingeniera
del software orientada a objetos. Stephen Palmer y John Felsing [PAL02] han extendido y mejorado el trabajo de Coad, al describir un proceso adaptativo y gil que puede
aplicarse en proyectos de software de tamao moderado y grande.
En el contexto del DCC una caracterstica "es una funcin valuada por el cliente
que puede implementarse en dos semanas o menos" [COA99). La importancia que

se Je concede a la definicin de caractersticas proporciona los siguientes beneficios.
Como las caractersticas son bloques pequeos de funcionalidad entregable,
los usuarios las describen con mayor facilidad, pueden entender cmo stas
se relacionan con otras con mayor rapidez, y pueden revisarlas de mejor manera en bsqueda de ambigedades, errores u omisiones.
Las caractersticas se pueden organizar en un agrupamiento jerrquico relacionado con el negocio.
11 El nombre "cristal" se deriva
pio color, fonna y dureza.
de las caracterlsticas de los cristales geolgicos, cada uno con su pro-
Como una caracterstica es el incremento de software entregable, el equipo

desarrolla caractersticas operativas cada dos semanas.
Debido a que \as caractersticas son pequeas, sus diseos y representaciones
de cdigo son ms fciles de inspeccionar de manera efectiva.
La planeacin del proyecto, la elaboracin de su programa y su rastreo los
gua la jerarqua de la caracterstica, en lugar de hacerlo un conjunto de tareas de ingeniera del software adaptado en forma arbitraria.
Coad y sus colegas [COA99] sugieren la siguiente plantilla para definir una caracterstica:
<accin> el <resultado> <porlparaldela> un <objeto>

donde un <objeto> es "una persona, sitio o cosa (incluyendo papeles, momentos en
el tiempo o intervalos de tiempo, o descripciones del tipo de catlogo de entrada)".
Los ejemplos de las caractersticas para una aplicacin de comercio electrnico podran ser:
Agregar el producto a un carrito de supermercado.

Desplegar las espec!ficadones tcnicas de un producto.
Almacenar la informadn de navegacin para un cliente.
Un conjunto de caractersticas agrupa caractersticas relacionadas en categoras relacionadas con el negocio y se define como [COA99]:
<acdn><-ar, -er, -ir> un <Objeto>

Por ejemplo: hacer la venta del producto es un conjunto de caractersticas que podra
abarcar las caractersticas relacionadas con anterioridad y otras.
El enfoque del DCC define cinco actividades de "colaboracin" dentro del marco
de trabajo (en el DCC stas se llaman "procesos") como se muestra en la figura 4.4.
UMICI
Desarrollo
conducido por
caractesUcas
[COA99]
(usado con
autorizacin).
1
1
~$arrollar
un
modelo
general
(ms forma que

contenido)
Elaborar
uno lista de
coractedsticas
Pion
-+
por
Diso
_,
caracterstico
por
coractersli
C'Onstru<:cio
-.
por
caracterstico
,-
Uno listo de
caractersticos
agrupados
en conjuntos
y reas
de contenido
Un pion de desarrollo
Propietarios de clase
Propietarios
del conjunto
de caractersticos
Un paquete
de diseo
(secuencias)
Funcin
cliente-valor
completada
,...
CAPTULO 4
DESARROLLO GIL
97
El DCC concede una mayor importancia a las directrices y tcnicas de la gestin

del proyecto que muchos otros mtodos giles. cuando los proyectos crecen en tamao y complejidad, con frecuencia la gestin ad hoc del proyecto es inadecuada.
Resulta esencial para los desarrolladores, sus gerentes y el cliente entender el estatus 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 incrementos de software (caractertsticas) estn programados de manera apropiada. Para
lograrlo el DCC define seis puntos de fijacin durante el diseo y la implementacin
de una caracterstica: "ensayo del diseo, diseo, inspeccin del diseo, cdigo, inspeccin del cdigo, promocin de la construccin" [COA99J.
4.3.7
Modelado gil (MA)
En muchas situaciones los ingenieros de software deben construir sistemas grandes y

crtticos para los negocios. El mbito y la complejidad de dichos sistemas se deben modelar de forma que 1) todas las circunscripciones entiendan mejor lo que se debe lograr; 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 mtodos y notacin para el modelado de ingenieria del software en el anlisis y diseo (tanto arquitectnico como al nivel de componentes). Estos mtodos tienen un mrito significativo, pero se ha comprobado que su aplicacin enfrenta dificultades y es desafiante
poderlos sostener (sobre muchos proyectos). Parte del problema es el "peso" de estos mtodos de modelado. Con esto se hace referencia al volumen de notacin requerida, el grado de formalismo sugerido, el tamao de los modelos para proyectos
grandes, y la dificultad para el mantenimiento del modelo conforme ocurren los
cambios. Aun as!, el modelado del anlisis y el diseo tiene un beneficio sustancial
para los proyectos grandes: por ninguna otra razn que hacer que estos proyectos
sean manejables en el sentido intelectual. Existe un enfoque gil para el modelado
de la ingeniera del software que pudiera proporcionar una alternativa?
En el "Sitio oficial del modelado gil", Scott Ambler [AMB02J describe el modelado gil (MA) de la siguiente manera:
El modelado gil (MA) es una tecnologia basada en la prctica para el modelado efectivo
de los sistemas basados en software. Dicho de una forma ms simple, el modelado gil es
una coleccin de valores, principios y prcticas para el modelado de software que puede
aplicarse en un proyecto de desarrollo de software de una manera efectiva y ligera. Los
modelos giles son ms efectivos que los tradicionales porque son slo lo sulicientemen
te buenos, no tienen que ser perfectos [AMB021:
Adems de los valores consistentes con el manifiesto gil, Ambler sugiere valor y humildad. 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
quienes manejan la tecnologa no tienen todas las respuestas, y que los expertos en
negocios y otros participantes de la empresa son dignos de respeto y consideracin.
98
PARTE 'UNO
A pesar de que el MA sugiere un arreglo amplio de principios de modelado

"esenciales" y "suplementarios", los responsables de que el MA sea nico son los siguientes [AMB02]:
Modelar con un propsito. Un desarrollador que use el MA debe tener una meta
especfica en mente (por ejemplo, comunicar informacin al cliente o ayudarle a entender mejor algn aspecto del software) antes de crear el modelo. Una vez identificada la meta para el modelo, el tipo de notacin que se usar y el grado de detalle
requerido sern ms obvios.
Usar mltiples modelos. Existen muchos modelos y notaciones diferentes con los
cuales describir el software. Slo un pequeo subconjunto es esencial para la mayora de los proyectos. El MA sugiere que para proporcionar la visin necesaria cada modelo debe presentar un aspecto diferente del sistema, y slo aquellos mode-
los que proporcionen un valor para la audiencia a la que estn dirigidos deben
usarse.
Viajar ligero. La realizacin de trabajo de la ingeniera del software requiere con-
~oNsuoS.
HVioior ligero es un
enfoque apropiado
para Jodo el trabao
de ingeniera del
software. Construir
sl() oque/los modelos
que proporcionan
valor ceni ms, ni
menos
H
servar slo los modelos que proporcionarn valor a largo plazo y descartar el resto. Cada producto de trabajo que se conserve debe recibir mantenimiento conforme se presentan cambios. Esto representa un trabajo que reduce la velocidad del
equipo. Ambler [AMB02] observa que "cada vez que se decide conservar un modelo se intercambia la agilidad por la conveniencia de tener la informacin disponible
para el equipo de una forma abstracta (por ende, existe una posibilidad de mejorar
la comunicacin dentro del equipo, as como con los propietarios del proyecto)".
El contenido es ms importante que la representacin. El modelado debe comunicar informacin a la audiencia a la que est dirigido. un modelo sintcticamente
perfecto que comunique slo un poco del contenido til no tiene tanto valor como
un modelo con una notacin defectuosa que, sin embargo, comunique un contenido valioso para su audiencia.
Conocer los modelos y las herramientas con que se crean. Es necesario entender
las fortalezas y debilidades de cada modelo y las herramientas con los que se cre.
Adaptar en forma local. El enfoque del modelado se debe adaptar a las necesidades del equipo gil.
~ Desarrollo gil
~ Objetivo: El objetivo de las herramientas del
desarrollo gil es ayudar en uno o ms

aspectos del desarrollo gil con nfasis en la facilitacin
de la generacin rpida de software operativo. Estos
herramientas tambin se pueden utilizar cuando se aplican

los modelos prescriplivos de proceso (captulo 3).
Mecnica: La mecnica de las herramientas vara. En general,

los conjuntos de herramientas tcnicas incluyen apoyo
automatizado poro la planeocin del proyecto, el desarrollo
CAPTULO 4
99
DESARROLLO GIL
::::a:a ce uso'/ \a recopi\acin de requisi\os, e\ di!.eo
a generacin de cdigo y lo reolizocin de pruebas.

tiiilo:imWtie
. n,lalai representativos:12
Ccmo el desarrollo gil es un tpico octuol, lo

~ de los vendedores de herromientos de
s;::.,,ore pretenden vender herromientos que apoyen el
~ gil. Los herromientos que se presentan o
c::r.t:r,uocin tienen coroctersticos que los hocen tiles
ce t:.'IOneO porticulor poro los proyectos giles.
Exn!rne, desorrollodo por Microtool
microtool.com), proporciono soporte para la
ges\in de un proce!.O gi\ en varios o&,i1dodes

tcnicas dentro del proceso.
ldeogramic UML, desorrollodo por ldeogramic

(www.ideogramic.com) es un conjunto de herramientas
poro el UML creado en formo especfico poro usarlo
dentro de un proceso gil.
Together Too/ Set distribuido por Borland

(www.borland.com o www.togethersoft.com),
proporciono un poquete de herramientas que apoya
muchas actividades tcnicos dentro de la PE y otros
procesos 6giles.
Una filosofia 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 trabajo que realizan; comunicacin y colaboracin entre los miembros del equipo
y entre los profesionales y sus clientes; un reconocimiento de que el cambio representa una oportunidad; y un especial cuidado en la entrega rpida del software que
satisfaga al cliente. Los modelos de proceso gil se disearon para cumplir con cada uno de estos aspectos.
La programacin extrema (PE) es el proceso gil que ms se utiliza. organizada
como cuatro actividades del marco de trabajo -planeacin, diseo, codificacin y
pruebas-, la PE sugiere algunas tcnicas innovadoras y poderosas que permiten a
un equipo gil crear frecuentes lanzamientos de software al entregar caractersticas
y funcionalidad que describe y despus prioriza el cliente.
El desarrollo de software adaptativo (OSA) destaca la colaboracin humana y la
organizacin propia del equipo. Organizado con tres actividades del marco de trabajo --especulacin, colaboracin y aprendizaje-, el OSA utiliza un proceso iterativo que incorpora la planeacin del ciclo adaptativo, mtodos de recopilacin de requisitos relativamente rigurosos y un ciclo iterativo de desarrollo que incorpora grupos enfocados en el cliente y revisiones tcnicas formales como mecanismos de retroalimentacin en tiempo real. El mtodo de desarrollo de sistemas dinmicos
(MDSD) define tres diferentes ciclos iterativos -iteracin funcional del modelo, iteracin 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 herramientas mencionadas aqu son slo una muestra de esta categora. En casi todos los
casos los nombres son marcas registradas de sus respectivos desarrolladores.
100
PARTE UNO
EL PROCESO DEL SOF'IWARE
ga por el uso de programas y sugiere que slo se requiere el trabajo suficiente para cada incremento de software y as facilitar el movimiento hacia el incremento prximo.
La mel subraya el uso de un conjunto de patrones de proceso de software que
han probado su efectividad en proyectos con lmites de tiempo muy ajustados, requisitos cambiantes y que son crticos para el negocio. Cada patrn de proceso define
un conjunto de tareas de desarrollo y permite al equipo de mel construir un proceso que se adapte a las necesidades del proyecto.
Cristal es una familia de modelos giles de proceso que pueden adaptarse a las
caractersticas especficas de un proyecto. Como otros enfoques giles, cristal adopta una estrategia iterativa, pero se ajusta al rigor del proceso para incluir proyectos
de tamaos y complejidades diferentes.
El desarrollo conducido por caractersticas (DCC) es algo ms "formal" que otros
mtodos giles, pero aun as mantiene la agilidad al enfocar al equipo de proyecto
en el desarrollo de caractersticas, funciones que evala el cliente y que se pueden
implementar en dos semanas o menos. El DCC concede una mayor importancia al
proyecto y a su gestin que otros enfoques giles. El modelado gil (MA) sugiere que
el modelado es esencial para todos los sistemas, pero que la complejidad, tipo y tamao del modelo debe ajustarse al software que ser construido. Mediante la proposicin de una serie de principios de modelado esenciales y complementarios, el
MA proporciona una gua til para los profesionales durante las tareas de anlisis y
diseo.
IADM96J Advanced Development Methods, lnc., "Origins of Scrum", 1996, http://www.controlchaos.com/.

{AGI03J The Agile Alliance Home Page, http:/ /www.agilealliance.org/home.
[AMB02J Ambler, S., "What is Agile Modeling (AM)?", 2002, http:/ /www.agilemodeling.com/
index.htm.
[BEC99J Beck, K .. Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.
[BECOlaJ Beck, K. etal., "Manifesto for Agile Software Development", http://www.agilemanifesto.org/.
[BECO lb) Beck, K. y M. Fowler. Planning Extreme Programming, Addison-Wesley, 2001.
[BEE99J Beedle, M. et al.. "SCRUM: An extension pattem language for hyperproductive software
development", incluido en: Pattem Languages of Program Design 4, Addison Wesley, Longman, Reading, MA, 1999. Obtenido de http://jeffsutherland.com/scrum/scrum-plop.pdf.
[BUSOO] Buschmann, F. et al.. Pattern-Oriented Software Architecture, 2 volmenes, Wiley, 1996,
2000.
[COA99] Coad, P., E. Lefebvre y J. DeLuca, Java Modeling in Color with UML, Prentice-Hall, 1999.
[COCOlJ Cockbum, A . y J. Highsmith, "Agile Software Development: The People Factor", IEEE
Computer, vol 34, nm. 11, noviembre de 2001, pp. 131-133.
[COC02a] Cockburn, A., Agile Software Development, Addison-Wesley, 2002.
[COC02b] Cockburn, A., "What is Agile and What Does lt Imply?", presentado en el Agile DeveJopment summit en Westminster College en Salt Lake City, marzo de 2002, http:/ /crystalmethodologies.org/.
[CCS02] CS3 Consulting Services, 2002, http:/www.cs3inc.com/DSDM.htm.
[DEM98) DeMarco, T. y T. Lister, Peopleware, 2a. ed., Dorset House, 1998.
[DEM021 DeMarco, T. y B. Boehm, "The Agile Methods Fray", en IEEE Computer, vol. 35, nm. 6,
junio de 2002, pp. 90-92.
CAPTULO 4
DlSARROILO GIL
101
[FOWOO) Fowler, M. et al, Refactoring lmproving the Design of E.xisting Code, Addison-Wesley,
2000.
[FOWOIJ Fowler M. y J. Highsmith, "The Agile Manifesto", Software Development Magazine, agosto
de 2001, http:/ /www.sdmagazine.com/documents/s=844/sdm0J 08a.htm.
[FOW02J Fowler, M., "The New Methodology", junio de 2002, hllp:/ /www.martinfowler.com/
articles/newMethodology.html#N8B.
[HIG98J Highsmith, J., "Life-The Artificial and the Real", Software Development, 1998, en
http:/ /www.adaptivesd.com/articles/order.hLml.
[HIGOOJ Highsmith, J., Adaptive Software Development: An Evolutionary Approach to Managlng
Complex systems, Dorset House Publishing, 1998.
[HIGOIJ Highsmith, J. (ed ), "The Greal Methodolog1es Debate: Parl I", Cutter 1TJoumal, vol. 14.
nm. 12, diciembre de 2001.
[HlG02aJ Highsmith, J. (ed.), "The Greal Methodologies Debate: Part 2", Cutter IT Journal, vol. 15.
nm. 1, enero de 2002.
[HIG02b] Highsmith, J., Agile Software Development Ecosystems, Addison-Wesley, 2002.
UAC02] Jacobson, 1, "A Resounding 'Yes' to Agile Processes-Bul Also More", Cutter IT Joumal,
vol. 15, nm. 1, enero de 2002, pp. 18-24.
UEFO I J Jeffries, R, et al., Extreme Programming lnstalled, Addison-Wesley, 2001.
[NOY02) Noyes, B., "Rugby, Anyone?", Managing Development (una publicacin en lnea de
Fawcette Technical Publications), junio de 2002, http://www.fawcette.com/resources/managingdev/methodologies/scrum/
[PAL02J Palmer, s. y J Felsing, A Practica/ Guide to Feature Driven Development, Prentice Hall,
2002.
[SCHO 1J Schwaber, K. y M Beedle, Agi/c Software Development wllh SCRUM. Prentlce-Hall. 200 l.
[SCH02) Schwaber, K, "Agile Processes and Self Organization", Agile Alliance, 2002,
http:/ /www.aanpo.org/articles/index
[STA97J Stapleton, J., DSDM-Dynam1c system Development Method The Method in Praclice. Addison Wesley, 1997.
[WEL99J Wells, D., "XP-Unit Tests", 1999, http://www.extremeprogramming.org/rules/
unittests.html.
4.1. Lase de nuevo el "Manifiesto para el desarrollo gil de sof\ware" al principio de este capitulo. El lector puede pensar en una situacin en la que uno o ms de los cuatro HvaloresH
pueda meter a un equipo de software en problemas?
4.2. Descrlbase agilidad (para proyectos de sof\ware) con palabras propias.
4.3. Por qu un proceso iterativo facilita ms manejar el cambio? Todos los procesos giles
tratados en este capitulo son iterativos? Es posible concluir un proyecto en slo una iteracin
y an as! seguir siendo gil? Explquense las respuestas.
4.4. Podr!a cada uno de los procesos giles describirse recurriendo a las actividades genricas del
marco de trabajo mencionadas en el capitulo 2? constryase una tabla que coloque las actividades
genricas dentro de las actividades definidas para cada proceso gil
4.5. Trtese de idear un "principio de agilidad" adicional que pudiera ayudar a una equipo de
ingeniera del software a volverse an ms manejable.
4.6 . Seleccinese un principio de agilidad de los enunciados de la seccin 4.1 y trtese de determinar si cada uno de los modelos de proceso presentados en este captulo muestran el principio.
4. 7. Por qu cambian tanto los requisitos? Despus de todo, ,la gente no sabe lo que quiere?
4 .8. Considrense los siete rasgos enunciados en la seccin 4.2.2. Ordnense los rasgos con
base en su percepcin desde lo que es ms importante hasta lo que tiene menor importancia.
4.9. La mayora de los procesos giles recomiendan la comunicacin cara a cara. Aun en la
actualidad, los miembros de un equipo de sof\ware y sus clientes pueden estar geogrficamen-
1111 im11m~~
102
PARTE UNO
t'L PROCESO DEL SOFTWARE
te separados entre si. Esto implica la necesidad de evitar la separacin geogrfica? Es posible
pensar en formas de contrarrestar este problema?
4 . 1O. Escrbase una historia del usuario para PE que describa los "sitios favoritos" o la caracterstica de "favoritos" disponible en la mayora de los exploradores Web.
4.11. '-Qu es una solucin pico en PE?
4.12. Oescribanse los conceptos de PE refabricacin y programacin en pareja con palabras
propias.
4.13. Utilcese la plantilla del patrn de proceso presentada en el capitulo 2 y desarrllese un
patrn de proceso para cualquiera de los patrones de mel presentados en la seccin 4.3.4
4.14. '-Por qu se dice que cristal es unaJam,Jia de mtodos giles?
4.15. Utilcese la plantilla de caracterstica para el DCC descrito en la seccin 4.3.6 y definase
un conjunto de caractersticas de un explorador Web. Ahora desarrllese un conjunto de caractersticas para el conjunto mencionado antes.
4 . 16. Vistese el sitio oficial del modelado gil y hgase una lista completa de todos los principios de MA esenciales y complementarios.
AtRII LIGtVRll J rv1n PI IMfQINA:mM

La tllosofia total y los principios subyacentes del desarrollo gil de software se consideran a
profundidad en los lbros de Ambler (Agile Mode/ing, Wilcy, 2002), Beck [BEC99J. Cockburn
[COC02] y Highsmth (HIG02b].
LOs libros de Beck [BEC99J. Jeffries y sus colegas (Extreme Programming Jnstalled, AddisonWesley, 2000), Succi y Marchesi (Extreme Programming Examined, Addison Wesley, 2001), New
kirk y Martin (E.xtreme Programming in PractJce, Addison Wesley, 2001) y Aver y sus colegas
(Extreme Programming Applied: Play to Win, Addison-Wesley, 2001) ofrecen una exposicin de
los pros y contras de la PE junto con una gula de la mejor forma de aplicarla. McBreen (Questwnmg Extreme Programming, Addison Wesley, 2003) asume una posicin crtica con respecto a
la PE, al definir cundo y dnde sta es apropiada. Por otro lado, McBreen (Pair Programming
llummated, Addison-Wesley, 2003) presenta una consideracin profunda de la programacin en
pareja.
Fowler y sus colegas (Refactoring: Jmproving the Design of Exisling Code, Addison wesley
1999) se enfoca en un nivel muy detallado en el importante concepto de la refabricacin dentro
de la PE. McBreen (Soflware Crajlsmanship. The New lmperative, Addison-Wesley, 2001) analiza
el arte del software y aboga a favor de las alternativas giles y la ingeniera de sollware tradi
cional.
El OSA lo aborda a profundidad Highsmith [HIGOOJ. Stapetlon realiz un tratamiento valioso
del MDSD (DSDM The Method in Praclice, Addison-Wesley. 1997). Palmer y Felsmg (PAL02J
presentan un tratamiento detallado del DCC. Carmichael y Haywood (Better Software Faster
Prentice-Hall. 2002) presentan otro til tratamiento del DCC que incluye un recuento paso a paso por la mecnica del proceso. Schwaber y sus colegas (Agile Software Devclopment witJ,
SCRUM, Prentice-Hall, 2001) presentan un detallado tratamiento de la mel.
Martin <Age Software Development, Prent1ce-Hall, 2003) analiza los principios. patrones
prcticas giles poniendo especial cuidado en la PE. Poppendieck y Poppendieck (Lean Developmcnt; An Agile Toolkitfor Software Developmcnt Managers, Addison-Wesley, 2003) proporciona las directrices para manejar y controlar los proyectos giles. Highsmith <Agile Software
Development Ecosystems. Addison-Wesley, 2002) presenta una valiosa visin de principios, pro
cesos y prcticas giles. .
En Internet se dispone de una amplia variedad de fuentes de informacin sobre el desarrollo gil de software. En el sitio web de SEPA se puede encontrar una lista actualizada de referencias en la red mundial, las cuales son relevantes para el proceso gil:
;.:;~:
d!~:.~:;::
~~~=t,t~:::~:.::1r
:
,
:
;
.
.
E
;,.ge- (
prctica de Ja ingentera del softw~re. Eh los captulos siguiente~ se . , ,

abordarn las siguientes preguntas;
'
~Qu conceptos y f)tindposg1,UanJa~rctica 1e ta _illf:fOietf,~.del $0ft."'
wa,re?
.~. '\:
,, ,,
.,@-,o.;
}d'
De qu manera la lngenierfa de sistemas conduce a Uhiirtg'eruera del
so,~ware,efectiva?
"
'
'
\\
..
!t
\~
4Qu es la ingenier~ de requisitos, y ql~ sn:~P$ conceptos rela- ,,,,.

cionados que condycen a un buen imHss d~ requisitS?
Cmo se crea el modeJ6 de atfJis!s y cules son sus ~lementbs?
Qu es fr1genlera de diseo y c1,1.l~s
son los conceptos reiadonados .
que conducen a un buen diseo?
. ~.
Qu conceptos, tndelos y mtodos se util!Z;ln para

quitectntcos, de interfaz y al nivel c~mBonentes?
de
creardiseos ar..,
'
1;
Qu estrategias son aplicables a la realizacin de ptUeb~$ de software?

Qu mtodos se utilizan para,disearcasos de prueba efe~tivos?
Qu mediciones y mtricas se usan para establecer la calidad del ar.li..i'

sis y los modelos de diseo. cdjg;'fuente y casos de prueba'
una vez que estas preguntas hayan sido respondidas1 habr tma mejor
preparacin para la prctica Qe la Ingeniera del software:
LA
PRCTICA:
UNA VISION GENERICA
#
CONCEPTOS
CLAVE
prlndples "-:
., anilisis .. .117
elcltspliegMl26
el clselio .. .119
.........
gl ......121
,. ____
la c04lfkadiN 123
din .......l09
la lllpnierio
411 saftwwe 107
1, plone4icl6a 113
,.,,...., .124
prtglllfas
wsHH .... ...115
rtMilclil4e
,,.W-s ... .106
n un libro que explora las vidas y los pensamientos de los ingenieros de

software, Ellen Ullman {ULL97] representa un fragmento de vida al relatar
los pensamientos de un practicante bajo presin:
No tengo idea de qu hora es. No hay ventanas en esta oficina, tampoco reloj, slo el
LEO parpadeante en roo de un horno de microondas, el cual parpadea 12:00, 12:00,
12:00, 12:00. Joel y yo hemos estado programando por dfas Tenemos un "bicho", el
necio demonio de un error Por eso la pulsacin roja sm tiempo se siente bien, como
una lectura de nuestros cerebros. los cuales se han sincronizado de alguna manera
a la misma velocidad del parpadeo .
En qu estamos trabajando?.. Los detalles se me escapan ahora. Podrfamos estar
ayudando a gente pobre y enferma o ajustando una serie de rutinas de bajo nivel para
ven ficar bits en un protocolo de una base de datos distnbuida, no me importa. Me debera importar, en otra parte de m1 ser-ms tarde, quiz cuando salgamos de estecuarto lleno de computadoras- me importar mucho por qu, para quin y con qu
propSJto estoy escnb1endo software Pero ahora no. He pasado a travs de una
membrana donde el mundo real y ~us usos ya no importan. Soy un ingeniero de software ..
Sin duda, una imagen oscura de la prctica de la ingeniera del software, pero
con la que, despus de reflexionar, muchos de los lectores de este libro sern
capaces de identificarse
104
CAPTULO 5
LA PRCTICA: UNA VISIN GENRICA
105
Las personas que crean software de computadora practican el arte, la maestra o

la disciplina 1 llamada ingeniera del software. Pero, qu es la "prctica" de la ingeniera del software? En un sentido genrico, la prctica es una coleccin de conceptos, principios, mtodos y herramientas a las que un ingeniero de software recurre a
diario. La prctica permite a los gerentes coordinar proyectos de software e ingenieros de la especialidad para construir programas de computadora. La prctica multiplica un modelo de proceso de software con los cmos tcnicos y de gestin necesarios para realizar el trabajo. La prctica transforma un enfoque fortuito en algo
ms organizado, ms efectivo y con ms probabilidades de alcanzar el xito.
En el captulo 2 se introdujo un modelo de proceso de software genrico compuesto de una serie de actividades que establecen un marco de trabajo para la prctica
de la ingeniera del software. Las actividades genricas del marco de trabajo -comunicacin, planeacin, modelado, construccin y despliegue- y las actividades sombrilla establecen la arquitectura de una esqueleto para el trabajo de ingeniera del
software. Todos los modelos de proceso de software presentados en los captulos 3
y 4 pueden organizarse en este esqueleto arquitectnico. Pero qu cabida tiene ah
la prctica de la ingeniera del software? En las secciones siguientes se considerarn
los conceptos y principios genricos que se aplican a las actividades del marco de
trabajo. 2
Algunos escritores utilizan uno de estos trminos y excluyen los otros. En realidad, la ingenierla 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 captulos posteriores del libro.
1111mm11m111111m11,11
1ll llillllllllllll l lWI
106
PARTE DOS PRCTICA DE LA INGENIERA DEL SOF1WARE
5.1.1
tcoNsuoS.
Se pod1a argumentar
que el enfoque de
Po/yo consiste en
simple senffdo comn.
Es verdad. Pero es
sorprendente la
frecuencia con la que
el senffdo comn no
es comn en el
mundo del software.
La esencia de la prctica
En un libro clsico, How to So/ve lt, escrito antes de que existieran las computadoras
modernas, George Polya [POL45] puntualiz la esencia de la resolucin de problemas 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 aseguramiento de la calidad).
En el contexto de la ingeniera del software estos pasos de sentido comn conducen

a una serie de preguntas esenciales [adaptadas de POL45}:
Entender el problema.
A quin le interesa la solucin del problema? Es decir, quines son los clientes?
Cules aspectos se desconocen? Qu datos, funciones, caractersticas y
comportamientos se requieren para resolver de manera apropiada el

problema?
El problema puede dividirse en categoras? Es posible representar problemas
menores que puedan entenderse con mayor facilidad?

El problema puede representarse de manera grfica? Se puede crear un
modelo de anlisis?
Planear la solucin.
Se haban visto problemas similares antes? Existen patrones reconocibles en
una solucin potencial? Hay un software existente que implemente los datos,
las funciones, las caractersticas y los comportamientos que se requieren?
Se ha resuelto un problema similar? Si es as, los elementos de la solucin
pueden reutilizarse?
Se pueden definir los subproblemas? Si es as, las soluciones para los subpro-
blemas parecen fciles?

Se puede representar una solucin de modo que conduzca a una implementacin efectiva? Se puede crear un modelo de diseo?
Llevar a cabo el plan.

La solucin marcha conforme al plan? El cdigo fuente se puede seguir
conforme al modelo 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?
CAPTULO 5
LA PRCTICA UNA VISIN GENRICA
107
Examinar el resultado.
Es posible probar cada parte de la solucin del componente? Se ha implemen-
tado una estrategia de prueba razonable?
rasgos y
comportamientos que se requieren;, El software ha sido validado contra todos
La solucin produce resultados acordes con los datos, fundones,
los requisitos de los clientes?

[
"1'11
lit._ de mda prablema exisle un grano de descubrimiento.
5.1.2 Principios esenciales

El diccionario define la palabra principio como "una ley o supuesto importante que
se requiere en un sistema de pensamiento". A travs de este libro se examinan principios en muchos grados diferentes de abstraccin. Algunos se enfocan en la ingeniera del software como un todo, otros consideran una actividad genrica y especfica del marco de trabajo (por ejemplo, comunicacin con el cliente), y otros se centran en acciones de la ingeniera del software (como diseo arquitectnico) o tareas
tcnicas (escribir un escenario de uso). Sin importar qu tan especficos son, los
principios ayudan a establecer un conjunto slido de prctica de ingeniera del software. Por esa razn son importantes.
David Hooker [H0096J ha propuesto siete principios esenciales, los cuales se
enfocan en la prctica de la ingeniera del software como un todo, que se reproducen enseguida. 3
9"
El primer principio: la razn por la que todo existe

Un sistema de software existe por una razn: para ofrecer un valor a sus usuarios.
Todas las decisiones deben tomarse con esto en mente. Antes de especificar un
requisito de un sistema, antes de sealar una pieza de funcionalidad del sistema,
antes de determinar las plataformas del hardware o los procesos de desarrollo, uno
debe hacerse preguntas como: esto agrega un valor real al sistema? Si la respuesta
es negativa no se debe hacer. Todos los dems principios estn apoyados en ste.
El segundo principio: MS (mantenerlo simple)

El diseo de software no es un proceso fortuito. Existen muchos factores que deben
considerarse en cualquier esfuerzo de diseo. Todo el diseo debe ser tan simple como
sea posible, pero no ms simple. Esto facilita un sistema de ms fcil comprensin y

entendimiento. Esto no quiere decir que las caractersticas, hasta las internas, deban
descartarse en nombre de la simplicidad. Adems, los diseos ms elegantes por lo
general son los ms simples. Simple tampoco significa "rpido y malo". De hecho, se
3 Reproducido con permiso del autor [H0096J. Hooker define patrones para estos principios en:
http://c2.com/cgi/wild?5evenPrinciplesofSottwareDevelopment.
llllllllli
11
'lll.11:lliUI
108
PARTE DOS PRCTICA DE LA INGENIERA DEL SOFTWARE
requiere de mucha reflexin y trabajo sobre mltiples iteraciones para simplificar. El

resultado buscado es un software que se mantenga y sea menos propenso al error.
~dlltnajrau1idall losimplicidad, lo cuci est muy por encima de le curiosillirrl 1111 ......
Alualrr ....
El tercer principio: mantener la visin
una visin clara es esendal para el xito de un proyecto de software. Sin la visin clara
el proyecto podra terminar con "dos [o ms] significados" en uno. Sin una integridad conceptual un sistema amenaza con tomarse en una masa confusa de diseos
incompatibles, unida por un tipo inadecuado de tomillos ...
Arriesgar la visin arquitectnica de un sistema de software debilita y al final
rompe hasta un sistema bien diseado. Tener a un arquitecto capaz de mantener la
visin y reforzar lo acordado ayuda al aseguramiento de que un proyecto de soft-
~,
C~VE
Si el software tiene un
valor. tto rombior o
lo lorgo de su vida til.
Por eso razn, el
software debe
construirse de formo
que se le puedo dar

mantenimiento.
ware sea exitoso.
El cuarto principio: Jo que uno produzca, otros Jo consumirn
En muy pocas ocasiones un sistema de software con fuerza industrial se construye

y utiliza de manera aislada. De alguna u otra forma, alguien ms utilizar, mantendr, documentar o depender de su capacidad de entender el sistema. Por lo tanto,
siempre debe especificarse, disearse e implementarse con la idea de que alguien
ms tendr que entender lo que se realice. La audiencia de cualquier producto de
software es potencialmente grande, por lo que se debe especificar tomando en cuenta a los usuarios. Se debe disear teniendo en mente a quienes lo implementen, as
como codificar considerando a aquellos que deben mantener y extender el sistema.
Tal vez alguien tenga que depurar el cdigo escrito y eso lo convertir en un usuario del cdigo. El hecho de facilitar el trabajo a otro agrega valor al sistema.
El quinto principio: estar abierto al futuro
Un sistema con una larga vida tiene ms valor. En los ambientes computacionales
de la actualidad, en los que las especificaciones cambian a cada momento y las plataformas de hardware son obsoletas despus de algunos meses, la vida del software se mide, de modo tpico, en meses en lugar de aos. No obstante, los verdaderos
sistemas de software "con fuerza industrial" deben durar ms tiempo. Estos sistemas
tendrn xito si estn listos para adaptarse a stos y otros cambios. Los sistemas que
logran el xito son aquellos que han sido diseados de esta manera desde el principio. Nunca se debe disear para llegar a una esquina. Uno siempre se debe preguntar:
"qu tal si?", y prepararse para todas las respuestas posibles, al crear sistemas que
resuelvan el problema general, no un problema especfico.4 Es muy probable que
esto conduzca a la reutilizacin de un sistema entero.
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 mayor esfuerzo para el proyecto.
CAPTULO 5
109
El sexto principio: planear para la reutilizadn

La reutilizacin ahorra tiempo y esfuerzo.5 AJ alcanzar un alto grado de reutilizacin
se logra una de las metas ms dificiles en el desarrollo de un sistema de software.
La reutilizacin de cdigo y diseos ha sido proclamada como un beneficio importante 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 documentadas.
La nueva bibliografa se est enfocando en la reutilizacin del diseo en la forma de
patrones de software. Sin embargo, esto es slo una parte 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 planeadn adelantada para la reutilizacin reduce el costo e incrementa el valor de los
componentes reutilizables y los sistemas en que dichos componentes se incorporan.
El sptimo principio: 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 resultados. 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 valiosa. un efecto colateral del pensamiento es aprender a reconocer, cuando alguien no
sabe algo, en qu punto se puede investigar la respuesta. Cuando el pensamiento
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 recompensas potenciales son enormes.
Si todos los ingenieros de software y todos los equipos de desarrollo tan slo
siguieran los siete principios de Hooker, muchas de las dificultades que se han experimentado 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 medio de una actividad de comunicacin (tambin llamada obtencin de requisitos). Un cliente tiene un problema que se puede ajustar a
5 Nota del autor: aunque esto es cierto para quienes reutilizan el software en proyectos futuros, la reutilizacin puede resultar cara para quienes deben disenar y construir componentes reutilizables. Algunos 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.
11111111111
110
PARTE DOS PRCTICA DE LA INGEN'IERA DEL SOfTWARE
una solucin basada en computadora. Un desarrollador responde a la solicitud

ayuda del cliente. La comunicacin ha comenzado. Pero el camino desde la cor.:-:;
nicacin hasta el entendimiento suele estar lleno de baches.
La comunicacin efectiva (entre pares tcnicos, con el cliente u otros participan:es.
del software y con los gerentes de proyecto) est entre las actividades ms desafiaras
que enfrenta un ingeniero de software En este contexto se examinan los principios
conceptos de comunicacin de acuerdo con la manera en que se aplican en la com:
nicacin con el cliente. Sin embargo, muchos de los principios se aplican del m
modo a las formas de comunicacin que ocurren dentro de un proyecto de software.
~ ONIUOS .
Antes de comvnkUI se
debe estor seguro de

entender el punto de
visto de /u otra porte,

Slm lJII f)CKO ~ 51/S
necesidades, y
entonces opinar.
Principio # 1: Escuchar. Se debe centrar la atencin en las palabras de ~

habla. en vez de formular la respuesta a dichas paJabras. Es necesario pedir
explicacin si algo no est claro, pero deben evitarse las interrupciones constant~
Nunca se debe ser conflictivo con palabras o actitudes (por ejemplo, dirigir la mirada a los lados o sacudir la cabeza) cuando una persona habla.
Principio #2 : Prepararse antes de comunicar. Se debe invertir aJgn tiem;,c
en entender el problema antes de reunirse con otros. Si es necesario, se puede realizar una investigacin para entender el negocio y dominar la jerga. Si se tiene la reSponsabilidad de conducir la reunin, es recomendable preparar una agenda del
antes de la junta.
Principio # 3 : Alguien debe facilitar la actividad. Cualquier reunin de com::rnicacin debe tener un lder o mediador 1) para mantener una conversacin cr..mica y en una direccin productiva; 2) para mediar en cualquier conflicto que o.:.
rra; 3)
para asegurar que se sigan los otros principios.
Principio #4 : La comunicadn cara a cara es lo mejor. Pero, por lo genera

funciona mejor cuando est presente otra representacin de la informacin relevarte. Por ejemplo, un participante podra crear un esquema o un documento que sirva
como foco de la discusin
l
Principio #5 : Tomar notas y documentar las decisiones Las cosas suelen
caer en malentendidos. AJgu1en que participe en la comunicacin debe servir como
"grabadora" y escribir todos los puntos y decisiones importantes.
Principio #6: Buscar la colaboradn. La colaboracin y el consenso se presentan cuando el conocimiento colectivo de los miembros del equipo se combina
para describir las funciones o caractersticas del producto o sistema. Cada pequea
colaboracin sirve para construir confianza entre los miembros del equipo y crear
una meta comn para dicho equipo.
Principio # 7 : Conservar el enfoque, examinar un mdulo a la vez. Entre

ms gente est implicada en una comunicacin. ms posibilidades existen de que la
CAPTULO 5
111
discusin salte de un tpico al siguiente. El mediador debe mantener la conversacin

centrada en un mdulo sin dejar un tema hasta que ste haya sido resuelto (sin
embargo, vase el principio #9).
La diferencia entre clientes y usuarios finales

Los ingenieros de software se comunican con
muchos participantes diferentes, pero los dientes
GSUOrios finales tienen el impacto ms significativo
el trobojo tcnico que sigue. En algunos cosos el
y el usuario son uno mismo, pero en muchos
111!::,a:x,s el diente y el usuario final son personas
. . .irw:les, que trabajan poro diferentes administradores en
!llill'"e':!es organizaciones de negocios.
:i::r.n.e es la persono o grupo que: 1) en un inicio
e: software que se va o construir; 2) define los

generales de negocios poro el software; 3)
proporciona los requisitos bsicos del producto; 4)

coordino los recursos econmicos poro el proyecto. En un
negocio de productos o sistemas, con frecuencia el cliente
es el departamento de mercodotecnio. En un ambiente de
TI el diente puede ser un componente o departamento del
negocio.
Un usuario final es lo persono o grupo que: 1) en realidad
usar el software que se construye poro alcanzar algn
propsito de negocios, y 2} definir los detalles operativos
del software de formo que el propsito del negocio puedo
alcanzarse.
Principio #8: Si algo no est claro, se hace un dibujo. La comunicacin verbal slo llega hasta cierto punto. Con frecuencia un esquema o figura puede proporcionar claridad cuando las palabras fallan al realizar su trabajo.
Principio #9: a) Una vez que se llega a un acuerdo sobre algo, se debe continuar; b) si no se puede llegar a un acuerdo, se debe continuar C) si una
caracterstica o fundn no est clara y no se puede clarificar en el momento,
se debe continuar. La comunicacin, como cualquier actividad de ingeniera del
software, requiere de tiempo. En lugar de que se itere sin fin, los particpante5 deben
reconocer que hay muchos tpicos que requieren anlisis (vase el principio #2) y
que "continuar" algunas veces es la mejor forma agilitar la comunicacin.
Principio # l O: La negodadn no es un concurso o un juego. Funciona
mejor cuando ambas partes ganan. En muchas ocasiones los ingenieros de soft
ware y el cliente deben negociar funciones y caracterl:;tica:;, prioriclacle5 y fecha5 ele
entrega. Si el equipo ha colaborado de buena forma. todas las partes tienen una meta
comn. Por lo tanto, la negociacin demandar el compromiso de todus Ju:; purtc~.
----=
11 wenat io: lugar de trabajo
de ingen-'o del soltwore.
Jamie lazar, miembro del equipo de

Vinod Raman, miembro del equipo de
Ed Robbins, miembro del equipo de software.
Ed: Ou han odo ace,-ca de ""9 proyecto ele
HogarSeguro?
Vinod: La reunin de inicio est pt"<>gramadc poro lo
prximo semana.
PARTE DOS PRCTlCA DE LA INGBllmlA DEL SOF1WARE
112
juntos o nueslras prifflenll
lil:wo..
Vinod: Vi que Doug leia un

requisitos. Poc:lrio apolb' que .W
principiol paro la buena
prestodo maana.
Jamie: Buena idea ... . . . . .
Ymod (IOl,...Nlo)r SI, dcw.
Conjunto de tareas genricas para la comwlicacln

1. lden~ficar al cliente primario y otros
Solidos y entrados resultantes.
participante$ ($eCci6n 7.3.1 ).
2. Reunirse con el dienle pnmorio poro

los preguntas libres de contexro (seccin 7.3.4), las
cuales definen:
los necesidades y valores del negocio
los coroctersticos y necesidades del usuoo final
los solidos visibles que se hayan requerido poro
el usuario.
los restricciones del negocio.
3.
Desarrollar un enunciado esaita de uno pgino

sobre el mbita del proyecto, el cvol est sujeta o
revisin.
Revisor el enunciado del mbito con los interesados

en el software y ajustarlo segn lo requericlo.
Colaborar con el cliente y el usuario final poro

definir:
Escenarios de uso visibles poro el diente con el
uso del formato estnclor4 (seccin 7.5).
Caractersticas, funciones y componomientas

,mponantes del software.
Riesgos de negocios definidos por el cliente
(seccin 25.3).
6. DesorroOor uno breve descripcin 8$Clo (por
ejemplo, uno serie de listos) de escenarios,
solidos/entrados, caractersticos/funciones y riesgos.
7. Iterar con el diente poro refinar los 8$Cenorios,
solidos/entrados, corodersticos/funciones y riesgos.
8. As,gnor prioridades definidos por el cliente o codo
escenario del usuario, caracterstico, funcin y
compor1omienta (seccin 7.4.2).
9. Revisor todo lo informacin recopilado durante lo
actividad de comunicacin con el diente y otros
participantes, y ajustarla de lo formo que se
requiero
1O. Prepararse poro lo actividad de ploneocin
(captulos 23 y 24).
6 Los formatos para escenarios de uso se discuten en el capitulo 8
CAPTULO 5
LA PRCTICA UNA VISIN GENRICA
113
La actividad de comunicacin ayuda al equipo de software a definir sus metas y objetivos generales (por supuesto, sujeto al cambio conforme pasa el tiempo). Sin
embargo, entender estas metas y objetivos no es lo mismo que definir un plan para
llegar a ellos. La actividad de planeacin abarca un conjunto de prcticas tcnicas y
de gestin que permiten al equipo de sofiware definir un mapa del camino mientras
se viaja a travs de su meta estratgica y objetivos tcticos.
"'& la Pfeparadn para lo !mio siempre he encontradoque los piones son lltiles, pero que lo plaaeda
1 t,1 ... ...
DwiJIMD.Bse.......
Existen muchos enfoques diferentes para la planeacin. Algunas personas son
"minimalistas", y argumentan que el cambio con frecuencia obvia la necesidad de un
plan detallado. Otros son tradicionalistas, y dicen que el plan proporciona un mapa
efectivo del camino, y mientras ms detallado sea ste, menor probabilidad habr de
que el equipo pierda el rumbo. Adems, otros son "agilistas" y argumentan que tal
vez un "juego de planeacin" rpido sea necesario, pero que el mapa del camino surgir cuando comience el "trabajo real" sobre el software.
Qu hacer? En muchos proyectos la sobreplaneacin consume tiempo y no produce frutos (demasiadas cosas cambian), pero la planeacin insuficiente es una
receta para el caos. Como la mayora de las cosas en la vida, la planeacin se debe
producir con moderacin, lo suficiente para proporcionar una gua til parn el equipo -no ms, no menos.
Sin importar el rigor con el que se conduzca la planeaci6n, los siguientes principios son vlidos en todo momento.
Principio # 1 : Entender los alcances del proyecto. Es imposible utilizar un

mapa de carreteras si no se sabe el sitio a donde se quiere ir. El hecho de entender
los alcances proporciona al equipo de soltware un de5tino.
Principio #2: Involucrar al cliente en la actividad de planeacin. El cliente
define prioridades y establece las restricciones del proyecto. El ajuste de estas realidades a menudo requiere que los ingenieros de software negocien las rdenes de
entrega, los lmites de tiempo y otros asuntos relacionados con el proyecto.
Principio #3: Reconocer que la planeacin es iterativa. El plan de un proyecto nunca se graba en una piedra. En cuanto comience el trabajo es muy probable
que las cosas cambien. En consecuencia, debe ajustarse el plan para adaptarlo a los
cambios. Adems, los moctelo5 iterativos e incrementales del proceso dictan la replaneacin (despus de la entrega de cada incremento de software) basada en la retroalimentacin recibida de los usuarios.
1111mm11 11
114
PARTE DOS PRC!tCA DE LA INGENIERA DEL SOFTWARE
Principio #4: Estimar con base en el conocimiento disponible. La finalidad

de la estimacin es proporcionar un indicio del esfuerzo, costo y duracin de las
tareas. con base en el conocimiento que el equipo tiene del trabajo que se va a realizar. Si la informacin es vaga o poco confiable, las estimaciones tendrn, de igual
forma, poca confiabilidad.
Principio #5: Considerar el riesgo cuando se define el plan. Si el equipo ha

definido riesgos que tienen un alto impacto y una alta probabilidad, es necesario un
plan de contingencia. Adems, el plan de proyecto (que incluye el calendario) se
debe ajustar para incluir la posibilidad de que uno o ms de estos riesgos se torne
un problema real.
Principio #6: Ser realista. Las personas no trabajan el 100 por ciento de cada
da. El ruido siempre entra en cualquier comunicacin humana. Las omisiones y la
ambigedad son hechos de la vida. Los cambios ocurrirn. Hasta los mejores ingenieros de software cometen errores. stas y otras realidades deben considerarse
mientras se establece el plan del proyecto.
'8 xito est ms en funcin del sentido comn consistente que del genio.
Aa . . .
Principio #7: Ajustar la granularidad mientras se define el plan.
La granu-
laridad se refiere al grado de detalle que se introduce conforme se desarrolla el plan.
El trmino gronuloridod
se refiere ol detolle con

el que algunos
elementos de lo
planeacin se
representan odirigen.
Una "granularidad fina" en el plan proporciona detalles significativos de las tareas de

trabajo. los cuales se planean en incrementos relativamente cortos de tiempo (de
forma que el ajuste y el control se den con frecuencia). Un plan de "granularidad
gruesa" proporciona tareas de trabajo ms amplias, las cuales se planean en periodos ms largos. Por Jo general, la granularidad cambia de fina a gruesa conforme el
tiempo lmite del proyecto est ms lejos de la fecha actual. En las siguientes semanas o meses el proyecto se puede planear con detalle significativo. Las actividades
que no se realizarn por muchos meses no requieren una granularidad fina (hay
demasiadas cosas que pueden cambiar).
Principio #8: Definir cmo se intentar asegurar la calidad. El plan debe

identificar la forma en que el equipo de software pretende asegurar la calidad. Si
habr revisiones tcnicas formales/ stas se deben calendarizar. En caso de que se
utilice programacin en pareja (captulo 4) durante la construccin sta debe estar
definida de manera explcita en el plan.
Principio # 9: Describir cmo se pretende incluir el cambio. Incluso a la

mejor planeacin puede superarla el cambio incontrolable. El equipo de software
debe identificar la forma en que se incluirn los cambios conforme se realiza el trabajo de ingeniera del software. Por ejemplo, el cliente puede solicitar un cambio en
7 Las revisiones tcnicas formales se estudian en el captulo 26.
CAPTULO 5 LA PRCTICA UNA VISIN GENtRiCA
115
cualquier momento? Si se presenta una solicitud de cambio el equipo est obligado a implementarlo de inmediato? Cmo se evalan el impacto y el costo del cambio?
Principio # 1O: Adaptar el plan a menudo y hacer los ajustes cuando stos
se requieran. Oa tras da los proyectos de software van por detrs del calendario
establecido. Por ello, es de mucha ayuda adaptar el progreso a diario. Se deben buscar reas problemticas y situaciones en las que el trabajo calendarizado no vaya de
acuerdo con el trabajo que se ejecuta en realidad. Cuando se encuentran desfases,
el plan se ajusta en concordancia con ello.
En la bsqueda de mayor efectividad, todos los integrantes del equipo de software deben participar en la actividad de planeacin. Slo entonces son miembros del
equipo "comprometidos" con el plan.
En un excelente documento sobre procesos y proyectos de software, Bany
Boehm [BOE96J establece: "Se necesita un principio de organizacin que se reduzca
para proporcionar planes [de proyecto] simples para proyectos simples." Boehm
sugiere un enfoque dirigido a los objetivos, fundamentos y calendarios del proyecto,
a las responsabilidades, enfoques tcnicos y de gestin y a los recursos requeridos.
l lo llam principio W5HH (why, what, when, who, where, how, how). debido a una
serie de preguntas que conducen a una definicin de caractersticas clave del proyecto y el plan de proyecto resultante:
Por qu est en desarrollo este sistema? Todas las partes deben evaluar la
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 se har? Se debe identificar la funcionalidad que se construir y, por ende,
las tareas requeridas para realizar el trabajo.
Cundo se terminar? Es necesario establecer un flujo de trabajo y un tiempo
lmite para las tareas clave del proyecto, as como identilcar los runctamentO!S requeridos por el cliente.
Quin es el responsable de una funcin? Se deben definir el papel y la responsabilidad de cada miembro del equipo de soflware.
En dnde se ubican dentro de la organizacin? No todos los papeles y responsabilidades residen dentro del mismo equipo de software. El cliente, los usuarios
y otros participantes tambin tienen responsabilidades.
Cmo se realizar el trabajo en los sentidos tcnico y de gestin? Una
vez que se establece el mbito del producto, es necesario definir una estrategia tcnica y de gestin para el proyecto.
Cunto se necesita de cada recw-so? La respuesta a esta pregunta se obtiene al desarrollar estimaciones (captulo 2.3) con base en las respuestas a las preguntas anteriores.
116
PARTE DOS PRGnCA DE LA INGENIERA DEL SOF'IWARE
Las respuestas a las preguntas W5HH de Boehm son importantes independientemente del tamao o la complejidad de un proyecto de software. Pero, cmo se inicia el proceso de planeacin?
.....
"8samos que los desllrolladom ele software estn perdiendo uno verdad vital: la mayora de las mpiadalllS
sal. lo que hacen. Elas piensan que lo saben, pero no es CIS
on/unto de tareas genricas para la planeacin

~
1. Reevaluar el mbito del proyecto

(secciones 7.4 y 21.3).
8. Crear un plan con granularidad fina para la

iteracin actual (captulos 23 y 24).
2. Evaluar los riesgos (seccin 25.4).
Definir tareas de trabajo para cada funcin y
3. Desarrollar o refinar los escenarios del usuario

(secciones 7.5 y 8.5).
4.
Extraer funciones y caractersticas o partir de los

escenarios (seccin 8.5).
5.
Definir las funciones y caradersticos tcnicos que

forman la infraestructura del software.
caracterstico (seccin 23.6).

Estimar el esfuerzo para cada torea de trabajo
(seccin 23.6).
Asignar responsabilidad para cada tarea de
trabajo (seccin 23.4).
Definir los productos de trabajo que sern
producidos.
6. Agrupar los funciones y corodersticos (escenarios)

de acuerdo con lo prioridad del diente.
Identificar los mtodos paro el aseguramiento de

la calidad que se usarn (captulo 26).
7. Crear un pion de proyecto con uno gronuloriclod

gruesa (captulos 23 y 24).
Definir el nmero proyectodo de incrementos de
software.
Establecer un calendario general del proyecto
(captulo 24).
Establecer los fechas de entrego proyectadas para
coda incremento.
Describir los mtodos para el cambio en la gestin

(captulo 27).
9.
Rastrear el progreso de manera regular (seccin

24.5.2).
Observar las reas problemticos (par ejemplo, el
desfase del calendario}.
Hocer los ajustes que se requieran.
Los modelos se crean para obtener un mejor entendimiento de la entidad real que se
construir. Cuando la entidad es un objeto tsico (por ejemplo, un edificio, un avin,
una mquina), se puede construir un modelo idntico en forma y tamao, pero en
menor escala. Sin embargo, cuando la entidad es software, el modelo debe tomar
una forma diferente. Debe ser capaz de representar la informacin que el software
transforma, la arquitectura y las funciones que permiten que ocurra la transformacin, las caractersticas que desean los usuarios, y el comportamiento del sistema
conforme se realiza la transformacin. Los modelos deben cumplir estos objetivos
en diferentes grados de abstraccin (primero al presentar el software desde el punto
de vista del cliente y despus al representar el software en un nivel ms tcnico).
CAPTULO 5
LA PRCflCA. UNA VISIN GENRICA
117
En el trabajo de la ingeniera del software se crean dos clases de modelos: modelos de anlisis y modelos de diseo. Los modelos de anlisis representan los requisitos del cliente al presentar el software en tres dominios diferentes: el dominio de la
informacin, el dominio funcional y el dominio del comportamiento. Los modelos de
diseo representan caractersticas del software que ayudan a los profesionales a
construirlo de manera efectiva: la arquitectura (captulo 10). la interfaz del usuario
(captulo 12), y el detalle al nivel de componentes (captulo 11).
En las secciones siguientes se presentan los principios y conceptos bsicos que
son relevantes para el modelado del anlisis y el diseo. Los mtodos tcnicos y la
notacin que permiten que los ingenieros de software creen modelos de anlisis y
diseo se presentan en los captulos posteriores.
"B
5.4. l
""* praj,lema del ingeniero en wmquier situacin de diseo es descubri <UI es realmente el p,olilenia.
w..
Principios del modelado del anlisis
En las pasadas tres dcadas se ha desarrollado un gran nmero de mtodos de

modelado del anlisis. Los investigadores han identificado los problemas del anlisis y sus causas y han desarrollado una variedad de notaciones de modelado y los
conceptos heursticos correspondientes para manejarlos. Cada mtodo de anlisis
tiene un punto de vista nico. Sin embargo, todos los mtodos de anlisis estn relacionados por medio de una serie de principios operativos:
Principio # 1: El dominio de informadn de un problema debe representarse y entenderse. El dominio de infonnacin lo forman los datos que fluyen hacia
el sistema (a partir de los usuarios finales, otros sistemas o dispositivos externos),
los datos que fluyen desde el sistema (a travs de la interfaz del usuario, interfases
de red, reportes, grficas y otros medios) y los almacenamientos de datos que se
recopilan y reorganizan los objetos consistentes de informaci6n (es decir, los datos
que se mantienen en forma permanente).
Principio #2: Se deben definir las fundones que ejecuta el software. Las
funciones del software proporcionan un beneficio directo a los usuarios finales y
tambin aporta soporte interno a aquellas caractersticas visibles para el usuario.
Algunas funciones transforman los datos que fluyen hacia el sistema. En otros casos,
las funciones efectan algn grado de control sobre el procesamiento interno del
software o elementos externos del sistema. Las funciones se pueden describir en
muchos grados diferentes de abstraccin, que van desde un enunciado general del
propsito hasta una descripcin detallada de los elementos ctel procesamtenl que
deben utilizarse.
Principio #3: Se debe representar el componamienco del sojtWare (como

una consecuenda de eventos externos). Al comportamiento del software de computadora lo gua su interaccin con el ambiente externo. La entrada que proporcionan
lllilWILIIIIKI '
118
PARTE DOS
PRCTICA Df LA INGENlERA DEL SOFTWARE
los usuarios finales. los datos de control que aporta un sistema externo o los datos
de monitoreo que se recolectan a travs de una red ocasionan que el software se
comporte de una manera especifica.
Principio #4: Los modelos que presentan informadn, fundn y comportamiento deben partirse de forma que descubran el detalle de una manera
estratificada (o jerrquica). El modelado del anlisis es el primer paso en la resolucin de problemas en la ingeniera del software. Esto permite al profesional entender mejor el problema y establecer una base para la solucin (diseo). Los problemas complejos son dificiles de resolver por completo. Por esta razn, se utiliza una
estrategia de "divide y ganars". Un problema grande y complejo se divide en subproblemas hasta que cada subproblema es relativamente fcil de entender. Este concepto se llama particin, y es una estrategia clave en el modelado del anlisis.
Principio #5: La tarea del anlisis debe moverse de la informadn esencial

hacia el detalle de implementadn. El modelado del anlisis comienza con la
descripcin del problema desde la perspectiva del usuario final. La "esencia" del problema se describe sin ninguna consideracin de la forma en la que se implementar la solucin. Por ejemplo, un videojuego requiere que el jugador "instruya" al protagonista en qu direccin seguir cuando ste se mueve dentro de un laberinto peligroso. Esa es la esencia del problema. El detalle de implementacin (descrita en
forma normal como una parte del modelo del diseo) indica cmo se implementar
la esencia. Respecto del videojuego se podra aplicar la entrada de voz. De manera
alternativa, se podra digitar un comando del teclado, o se podra apuntar un joystick
(o un mouse) en una direccin especifica .
Conjunto de tareas genricas para el modelado del anlisis

1. Revisar ~o~ requisitos _del negocio, los
coroctensticos/neces1dodes del
usuario, los salidos visibles poro el

usuario, los restricciones del negocio, y otros
requisitos tcnicos que se hayan determinado
durante los actividades de comunicacin con el
diente y de ploneocin.
2. Expandir y refinar los escenarios del usuario (seccin
8.5).
Definir o todos los actores.
Representar lo formo en que los actores
interactan con el software.
Extraer funciones y caractersticos o partir de los
escenarios del usuario.
Revisor los escenarios del usuario poro verificar
que estn completos y su exactitud (seccin 26.4).
3. Modelar el dominio de lo informacin (seccin 8.3).

Representar todos los objetos importantes de
informocin.
Definir los atributos poro codo objeto de
informacin.
Representar los relaciones entre los objetos de
informacin.
4. Modelar el dominio funcional (seccin 8.6).
Mostrar lo formo en que los funciones modifican

los objetos de datos.
Refinar los funciones poro proporcionar los
detalles de lo elaboracin.
Escribir uno narracin del procesamiento que
describo codo funcin y subfuncin.
Revisar los modelos funcionales (seccin 26.4).
CAPTULO 5
5. Modelar el dominio del comportamiento (seccin
119
Revisar los modelos de comportamiento (seccin
8.8).
26.4).
Identificar los eventos exlemos que ocasionan

cambios en el comportamiento dentro del
sistema.
6. Analizor y modelar la interfase del usua rio (ca pitulo

12).
Dirigir el anlisis de tareas.
Identificar los estados que representon cado forma

de comportamiento observable desde el exterior.
Presentor el modo en el que un evento lleva al
sistema a cambiar de un estado a otro.
Crear prototipos de lo imagen en pantalla,

7.
Revisar todos los modelos en cuanto o que estn

completos, su consistencia y las omisiones.
5.4.2 Principios de modelado del diseo

El modelo de diseo del software es el equivalente al plano de una casa para un
arquitecto. Comienza con la representacin de la totalidad del objeto que ser construido (por ejemplo, una reproduccin tridimensional de la casa) y con lentitud lo
refina para proporcionar una gua para construir cada detalle (por ejemplo, el diseo de la plomera). En forma similar, el modelo del diseo que se crea para el software proporciona una variedad de diferentes vistas del sistema.
.,._" .. ti 1liseiio seo saliio y justo:averiguado fflo, persguelo mvehamn,; no por III niCham datei Ir et
......."'11 has nsueko efecluar.
wa..sw.,....
->----. . ..
No hay pocos mtodos para derivar los diferentes elementos de un diseo de software. Algunos mtodos se guan mediante los datos al permitir a la estructura de
datos dictar la arquitectura del programa y los componentes de procesamiento resultantes. A otros los conduce el patrn al utilizar informacin acerca del dominio del
problema (el modelo de anlisis) para desarrollar estilos ar9uitectnicos y p.ttrom:s
de procesamiento. Incluso otros estn orientados a objetos, al usar los objetos del
dominio del problema como los conductores para la creacin de estructuras de datos
y los mtodos para manipularlos. An as, todos ellos siguen un conjunto de principios de diseo que se pueden aplicar sin importar el mtodo que se utilice:
Principio # I: El diseifo debe ser rastreable hasta el modelo de anlisis. El
modelo de anlisis describe el dominio de la informacin del problema, las funciones visibles para el usuario, el comportamiento del sistema y un conjunto de clases
de anlisis que empaqueta los objetos del negocio con los mtodos que les sirven.
El modelo de diseo traduce esta informacin a una arcuitectura, un conjunto e
subsistemas que implementan las funciones mas importantes y un conjunto de diseos al nivel de componentes que son la realizacin de las clases de anlisis. Excepto
el modelo asociado con la infraestructura de software, los elementos del modelo de
diseo deben ser rastreables hasta el modelo de anlisis.
11
lli. lli'
120
PARTE DOS
ttilH5f1
Principio #2: Siempre se debe considerar la arquitectura del sistema que

se va a construir. La arquitectura del software {captulo 1O) es el esqueleto del sistema 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 estas 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.
.,,....,.
En cs.WWWI.
,,_./se
ell(onl!Dr(OllMlffl(IIOS
~ssc,lweel
procese de d.
Junro con \Jl10

e6ndelo
esttildelm.
PRCl'ICA DE LA INGENmA DEL SOF1WARE
Principio #3: El diseo de datos es tan importante como el diseo de funciones de procesamiento. El diseo de datos es un elemento esencial del diseo
arquitectnico. La manera en que se realizan los objetos de los datos dentro del diseo no puede dejarse a la suerte. Un diseo de datos bien estructurado ayuda a simplificar el flujo del programa, facilita el diseo y la implementacin de los componentes del software, y confiere ms eficiencia al procesamiento en general.
Principio #4: I.o.s interfaces (internas y externas) deben disearse con cuidado. La manera en que fluyen los datos entre los componentes de un sistema tiene
mucho que ver con la eficiencia del procesamiento, la propagacin del error y la simplicidad del diseo. Una interfaz bien diseada facilita la integracin y ayuda a quien
realiza la prueba a validar funciones de componentes.
Principio #5: El diseo de interfaz del usuario debe ajustarse a las necesidades 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 arquitectura, un diseo de interfaz pobre siempre conduce a la percepcin de que el software
est "mal" hecho.
Principio #6: El diseo al nivel de componentes debe ser independiente del
modo funcional . La independencia funcional es una medida del "significado sencillo" de un componente de software. La funcionalidad que entrega un componente
debe ser cohesiva; es decir, debe centrarse en una y slo una funcin o subfuncin.8
Principio #7: Los componentes deben estar apareados entre s en forma
minima y vinculados con el ambiente externo. El apareamiento se consigue de
muchas maneras: va interfaz de componente, por mensajes, a travs de datos globales. A medida que aumenta el nivel de apareamiento, la probabilidad de propagacin del error tambin aumenta y la facilidad de mantenimiento general del software disminuye. Por lo tanto, el apareamiento de componentes debe mantenerse tan
bajo como sea posible.
8 En el captulo 9 se puede encontrar una exposicin adicional acerca de la cohesin.
CAPTULO 5
121
LA PRACTICA- UNA VISIN GENRICA
Principio #8: IAs representadones del diseo (modelos) deben ser fcilmente comprensibles. El propsito del diseo es comunicar informacin a los profesionales que generarn cdigos, a aquellos que probarn el software, y a quienes
tal vez mantengan el software en lo futuro. Si el diseo es dificil de entender, no servir como un medio efectivo de comunicacin.
Principio #9: El diseo debe desarrollarse de manera iterativa. En cada iteradn el diseador debe buscar la mayor simpliddad. Como casi todas las actividades creativas, el diseo ocurre de modo iterativo. Las primeras iteraciones sirven para refinar el diseo y corregir errores. pero las iteraciones posteriores deben
buscar que el diseo sea tan simple como sea posible.
Cuando se aplican estos principios de manera apropiada, el ingeniero de software crea un diseo que muestra los factores internos y externos de calidad. Los factores de calidad externos son aquellas propiedades del software que los usuarios pueden observar fcilmente (como velocidad, confiabilidad, correccin, facilidad de
uso) Los factores de calidad internos son importantes para los ingenieros de software, ya que conducen hacia un diseo de alta calidad desde una perspectiva tcnica.
Lograr factores de calidad internos requiere que el diseador entienda conceptos
bsicos de diseo (captulo 9)
Modelado g11
En su libro sobre modelodo gil, Scoft AmblM
[AMB02) define uno serie de principios9
~m:ll::ile5 cuando el on61isis y el diseo se conducen
del contexto de lo filosolo del desorrol1o gil de
(captulo .4).
# 1: lo meto primario del equipo de software es
consMJir softwore, no crear modek.
# 2: Viojor ligero; es decir, no deben crearse ms

modelos de los necesarios.
# 3: Intentar producir el modelo ms simple que
describir el problema o el software.

# 4: Construir modelos de formo que stos sean
ajustables ol combio.
# 5: Ser copoz de enunciar un propsito explcito
poro coda modelo que se cree.
# 6: Adoptar los modelos desorrollodos al
sislllmo que se tiene en mono
Principio #
7: Trotor de constn,;, modelo tiles, pero
olvidarse de construir modelos per~tos.
Princtp,o # 8: No volverse dogmfico acerco de lo s:ntox:s

del modelo. s; ste comun;co su contenida de monera
exitoso, lo representoci6n es secundario.
Prinapio # 9: Si el instinto indica que un modelo no es el
correcto ounque ste luzco bien en el popel,
proboblemente existe uno rozn poro estar
preocupados.
Principio # l O: Oblener retroolimentocin ron pronto como

sea posible.
Sin imporlor el modelo de proceso que se elija o las
prcticos especficos de lo ingeniera del software que se
apliquen, todos los equipos de software quieren ser giles.
Por lo tanto, estos principios se deben oplicor sin imporlor
el modelo de proceso del software que se haya
seleccionado.
9 Los principios mencionados en e:.ta seccin se han abreVlado y adaptado para los propsitos de este
libro.
II
122
PARTE DOS
1 ~111:111111
PRCTICA DE LA !NGENIEruA DEL SOFIWARE
onjunto de tareas genricas para el diseo

1. Utilizar el modelo de anlisis,
seleccionar un estilo arquitectnico
(patrn) apropiado paro el software
(captulo l O).
2. Dividir el modelo de anlisis en subsistemas de
'
diseo y ubicar stos dentro de lo arquitectvra

(captulo 10).
Tener la certeza de que coda subsistema es
coherente en el sentido funcional.
Disear interfases de subsistema.
Especificar la secuencia de accin con base en los

Crear un modelo de comportamiento de la
interfaz.
Definir los objetos de la interfaz y mecanismos de
control.
Revisor el diseo de la interfaz y a justarlo como
sea necesario (seccin 26.4).
4. Conducir el diseo al nivel de componente.

Especificar todos los algoritmos en un grado
relativamente bajo de abstraccin.
Ubicar los doses o funciones de anlisis paro

codo subsistema.
Refinar la interfaz de codo componente.
Mediante lo utilizacin del modelo del dominio de

la informacin, disear estruduros de datos
Definir les estructuras de datos en el nivel de

componente (seccin 26.4).
opropiodo$.
3. Disear lo interfaz del usuario (captulo 12).

Revi,ar lo, rosultadM del onlisis de tareos.
Revisor el diseo en el nivel de componentes

(seccin 26.4).
5. Desarrollar un modelo de despliegue (seccin 9.4.5).
La actividad de construccin abarca una serie de tareas de codificacin y realizacin

de pruebas que conducen al software operativo que est listo para entregarlo al
cliente o usuario final. En el trabajo de la ingenierla del software moderna la codificacin puede ser: l) la creacin directa de cdigo fuente de un lenguaje de programacin; 2) la generacin automtica de cdigo fuente al utilizar una representacin
intermedia del diseo del componente que ser construido; 3) la generacin auto-
mtica de cdigo mediante un lenguaje de programacin de cuarta generacin (por

ejemplo, Visual C++).
en
,,.._ gran porte de mi vida he sido Uf1 fisgn del software, asomndome furtivamente
t6dip1Danenas. Ocasionaln-1e, 811CU8111rouno joyo recl, un programo bien estructwado escrito can . . . . CIF i 11 IIS.
. . . desarrolado de formo que codo componente es simple y organizoda, y dsdo para f11!1 el .....
,_._...con fddad.
El enfoque inicial de las pruebas est al nivel de componentes, con frecuencia llamadas pruebas de unidad. Los otros niveles de prueba incluyen: 1) pruebas de integracin (realizadas mientras el sistema est en construccin) 2) pruebas de validacin,
las cuales evalan si los requisitos han sido satisfechos para el sistema completo (o
para el incremento de software); y 3) pruebas de aceptacin, que realiza el cliente en
un esfuerzo encaminado a ejercitar las caractersticas y funciones.
CAPTULO 5
123
Existe una serie de principios y conceptos aplicables a la codificacin y las pruebas. stos se presentan en las secciones siguientes.
5.5. l
Principios y conceptos de codificacin
Los principios y conceptos que guan la tarea de codificacin estn alineados de

manera muy cercana al estilo de la programacin, los lenguajes de la programacin
y los mtodos de programacin. Sin embargo, existe un conjunto de principios fundamentales que pueden establecerse:
Principios de preparacin: Antes de escribir una lnea de cdigo se debe estar seguro de:
1. Entender el problema que se intenta resolver.
2. Entender los principios y conceptos bsicos del diseo.
3. Escoger un lenguaje de programacin que satisfaga las necesidades del software que se va a construir y el ambiente en el que ste va a operar.
4 . Seleccionar un ambiente de programacin que proporcione herramientas que

faciliten el trabajo.
5 . Crear un conjunto de pruebas de unidad que sern aplicadas una vez que se
complete el componente que se va a codificar.
Principios de codificacin: Cuando se comience a escribir el cdigo se debe estar

seguro de:
1. Restringir los algoritmos al seguir la prctica de la programacin estructurada
[BOHOO] .
2. Seleccionar las estructuras de datos que satisfarn las necesidades del diseo.
3. Entender la arquitectura del software y crear interfases que sean consistentes

con ella.
4. Mantener la lgica condicional tan simple como sea posible.

5. Crear ciclos anidados en una forma que los haga fciles de probar.
6. Seleccionar nombres de variables significativas y seguir otros estndares locales de codificacin.
7. Escribir cdigo que tenga documentacin propia.

8 . Crear una configuracin lineal (por ejemplo, sangras y lneas en blanco que
ayuden a la comprensin del cdigo).
Principios de validacin: Despus de haber completado los primeros pases de codificacin, se debe estar seguro de:
1. Conducir un ensayo de cdigo cuando sea apropado
2 . Realizar pruebas de unidad y corregir los errores que se hayan descubierto.

3. Refabricar el cdigo.
11'11'11
PARTE DOS PRCilCA DE LA INGENtERiA DEL SOFTWARE
124
Los libros sobre codificacin y los principios que la guan incluyen trabajos recientes sobre el estilo de programacin [KER78J, construccin prctica de software
[MCC93). perlas de programacin [BEN99). el arte de la programacin [KNU99).
aspectos de la programacin pragmtica [HUN99). y muchos otros.
Conjunto de tareas genricas para la construccin

1. Construir lo infraestructura
orquitect6nico (captulo 1O).
Codificar ~s algori~s internos y las funciones de

procesom,enlo reloc,onados.
Revisar el cdigo conforme ste se escribe (seccin
26..4).
Revisar el diseo arquitectnico.

Codificar y probar los componentes que forman lo
mfroestructvro arquitectnico.
Buscar la exactitud.
Asegurarse de que se han mantenido los
estndares de codificacin.
Asegurarse de que el c6cligo se documenta a s
mismo.
Adquirir patrones arquitectnicos reutilizables.

Probar lo infraestructura poro asegurar lo
integridad de lo interfaz.
2. Construir un componente del softwore (c:optulo 11 ).
Revisar el diseo ol nivel de componente.

Crear uno serie de pruebas de unidad para el
componente (secciones 13.3. l y 1.4.7).
Codificar las estructuras de datos y lo interfase del
componente
3. Realizar pruebas de unidad al componente.

Dirigir todos las pruebas de unidad.
Corregir los errores descubiertos.
Aplicar de nuevo los proebos de unidad.
4. Integrar el componente terminado a lo infraestructura
arquilectnica
5.5.2 Principios de las pruebas

En un libro clsico sobre las pruebas realizadas al software, Glen Myers [MYE79]
establece una serie de reglas que bien pueden servir como objetivos de las pruebas:
C,des son
los objetivos
4e las pntbos al
softwae?
Las pruebas consisten en un proceso en el que se ejecuta un programa con la

intencin de encontrar un error que an no se descubre.
Un buen caso de prueba es aquel en el que hay una gran probabilidad de
encontrar un error que aun no se descubre.
Una prueba exitosa es aquella que encuentra un error que an no se
descubra.
Estos objetivos implican un cambio radical desde el punto de vista de algunos desarrolladores de software. stos se oponen a la visin inusual de que la prueba exitosa es aquella en la que no se encuentran errores. El objetivo aqu es disear pruebas
que de manera sistemtica descubran diferentes clases de errores y que lo hagan
con un gasto mnimo de tiempo y esfuerzo.
Davis [DAV95] sugiere un conjunto de principios para las pruebas, 10 el cual se ha
adaptado para aprovecharlo en este libro
1O Aqu se presenta slo un pequeo subconjunto de los principios de oav1s para las pruebas. Para ob-
tener ms informacin vase [DAV95).
CAPTULO 5
LA PRCTICA : UNA VlSIN GENtRICA
125
Principio # 1: Todas las pruebas deben ser rastreables hasta los requisitos
del cliente. 11 El objetivo de las pruebas realizadas al software es descubrir errores.
De aqu se desprende que los defectos ms severos (desde el punto de vista del cliente) son aquellos que hacen fallar el programa al tratar de satisfacer sus requisitos.
Principio #2 : La.s pruebas se deben planear mucho antes de que comience

el proceso de prueba. La planeacin de las pruebas (captulo 13) puede comenzar
tan pronto como el modelo de anlisis est completo. La definicin detallada de los
casos de prueba puede comenzar en cuanto el modelo de diseo haya sido solidificado. Por tanto, todas las pruebas se pueden planear y disear antes de que se haya
generado cualquier cdigo.
Principio # 3: El prind po de Pareto es aplicable para las pruebas de software . Para establecerlo de manera simple, el principio de Pareto implica que 80 por
ciento de los errores descubiertos durante las pruebas con probabilidad sern rastreables hasta 20 por ciento de todos los programas. El problema, por supuesto, es
aislar estos componentes sospechosos y despus probarlos.
Principio #4 : Las pruebas deben comenzar "en Jo pequeo" y progresar

hacia "lo grande". Las primeras pruebas que se planean y ejecutan. por lo general,
se enfocan en los componentes individuales. Conforme progresan las pruebas, el
enfoque cambia en un intento de encontrar errores en grupos integrados de componentes y, por ltimo. en el sistema completo.
Principio # 5 : La.s pruebas exhaustivas no son posibles. El nmero de permutaciones entre las rutas, incluso de un programa con un tamao moderado, es
excepcionalmente grande. Por esta razn es imposible ejecutar cada combinacin
de rutas para las pruebas. Sin embargo, se puede cubrir de manera adecuada la lgica del programa para asegurar que se hayan ejercitado todas las condiciones al nivel
de componentes (capitulo 14).
Conjunto de tareas genricas para las pruebas

1. Disear pruebas de unidad poro
coda componente del software
(seccin 13.3.1)
Aplicar de nueva las pruebas de unidad.

2.
Desorrollor una estrategia de integracin (seccin

13.3.2).
Revisor codo prueba de unidad poro asegurar una

cobertura apropiado.
Establecer el orden y lo estrategia que se usor

poro lo integracin.
Dirigir la prueba de unidad.
Definir las #construcciones# y las pruebas

requeridos poro ejercitarlas.
1I Este principio se refiere a las pruebas funcionales; es decir, a las que se enfocan en los requisitos.
Las pruebas estroclllrales (que se enfocan en los detalles arquitectnicos o lgicos) pueden no referirse en forma directa a los requisitos especficos.
11 1 ,IUII
PARTE DOS
126
PRCl'ICA DE LA INGENiflliA DEL SOFTWARE
Dirigir pruebas de humo o diario.

Dirigir pruebas de regresin codo vez que seo
necesario.
3.
Desarrollar uno estrategia de validacin (seccin

13.5).
Establecer los criterios de validacin.
Definir los pruebas requeridos poro valida r el
software.
4.
Dirigir los pruebas de integracin y validacin.

5 . Dirigir los pruebas con mucho orden.

Realizar los pruebas de recuperacin (seccin
13.6.1).
Realizar los pruebas de seguridad (seccin
13.6.2).
Realizar los pruebas de tensin (seccin 13 .6.3).
Realizar los pruebas de desempeo (seccin
13.6.4).
6. Coordinar con el diente los pruebas de aceptacin
(seccin 13.5.3).
Aplicar de nuevo los pruebas codo vez que seo

necesario.
1 ,6 PllfLRMI
Como se mencion 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 cliente y a los usuarios finales un incremento de software operativo que provee funciones y caractersticas tiles. cada ciclo de soporte proporciona documentacin y asistencia humana para todas las funciones y caractersticas introducidas durante todos
los ciclos de despliegue que se han presentado hasta la fecha. Cada ciclo de retroalimentacin ofrece al equipo de software una gua importante que conduce a modificaciones en las funciones, caractersticas y el enfoque que se toma para el siguiente incremento.
La entrega de un incremento de software representa un fundamento importante
para cualquier proyecto de software. Cuando el equipo se prepara para crear un

incremento, se debe seguir una serie de principios clave:
Principio # 1: Se deben administrar las expectativas que el cliente tiene del

software. Con demasiada frecuencia, el cliente espera ms de lo que el equipo ha
Se be tener lo
serpJd de que el
lllle sobe qu
tsperor antes de que
se entregue el increrJeflto de software.
Oe otro manero, el
cifI1e esperar ms
/ lo que se /e puede
,m,egor.
prometido entregar y de inmediato se presenta 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 punto 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 software debe
ser cuidadoso de no enviar al cliente mensajes 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 software y despus menos de lo prometido para el siguiente).
CAPTULO 5
LA PRCTICA: UNA VlSIN GENtruCA
127
Principio #2: Se debe ensamblar y probar un paquete de entrega completo.

Se debe ensamblar un CD-ROM u otro medio que contenga todo el software ejecutable, archivos con los datos de soporte, documentos 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
todas las configuraciones de cmputo posibles (por ejemplo, hardware, sistemas
operativos, dispositivos perifricos, arreglos de red).
Principio #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 mecanismos para mantener un
registro apropiado con que el equipo de software pueda realizar una evaluacin
categrica de los tipos de soporte solicitados.
Principio #4: Se debe propordonar material instructivo apropiado a los

usuarios .finales. El equipo de software entrega ms que el software en s; en caso
de ser necesario, se debe desarrollar un entrenamiento apropiado, se deben proporcionar directrices para la resolucin de problemas, y se deben publicar descripciones
acerca de "cul es la diferencia con este incremento de software". 12
Principio #5: El software con errores se debe arreglar primero y entregarse despus. Ante la presin del tiempo, algunas organizaciones de software entregan incrementos de baja calidad con una advertencia para el cliente de que los errores "se eliminarn en la prxima versin". Esto es un error. En el negocio del software se dice: "Los clientes olvidarn que se les entreg un producto de alta calidad
unos pocos dias despus, pero nunca olvidarn los problemas que les caus un producto de baja calidad. El software se los recuerda todos los das".
El software entregado proporciona un beneficio para el usuarto nnal, pero tambin provee una retroalimentacin til para el equipo de software. Al utilizar el incremento, los usuarios finales deben ser motivados a comentar sobre las caractersticas y funciones, facilidad de uso, confiabilidad y cualesquiera otras caractertsticas
apropiadas. La retroalimentacin debe recopilarla y registrarla el equipo de software y aprovecharla para 1) hacer modificaciones inmediatas al incremento entregado
(si es necesario); 2) definir los cambios que sern incorporados en el prximo incremento 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 materiales de ayuda que quieren los usuarios.
11
128
PARTE DOS
11. IIRIIII
PRCTICA DE LA INGENJERA DEL SOFTWARE
onjunto de tareas genricas para el despliegue

~
1. Crear medios de entrego.

Ensamblar y probar todos los
archivos ejecutables.
Ensamblar y probar todos los archivos de datos.
Establecer una base de datos poro el reporte de

problemas/errores.
3. Establecer mecanismos de retroalimentacin del
usuano.
Crear y probar toda la documentacin del usuario.
Definir el proceso de retroalimentacin.
Implementar las versiones electrnicas (por

ejemplo, pdD.
Definir la s formas de retroalimentacin (en pa pel o

electrnico)
Implementar archivos de -ayuda# con hipertexto.
Establecer la base de datos de retroalimentacin.
Implementar una gua poro lo resolucin de

problemas.
Definir el proceso de evaluacin de la

retroalimentacin.
Probor los medios de enh'ego con un grupo
pequeo de usuarios represenlativos.

2. E~toblem lo persono o grupo encargado del
&0pork. humano.
4.
Diseminar los medios de entrego o todos los

usuarios.
5. Dirigir los funciones de soporte continuos.

Proporcionar asistencia en lo instalacin y el
lnlCIO.
Crear lo documentacin o las herramientas de

soporte por computadora.
Establecer mecanismos de contacto (por ejemplo,
un sitio web, telfono, correo electrnico).
Establecer mecanismos poro la localizocin de
problemas.
Establecer mecanismos poro el reporte de
problemas.
Proporcionar asistencia continua y de resolucin

de problemas.
6. Recopilar la retroalimentacin del usuario
Registrar lo retroalimentacin.
Evaluar lo retroalimentacin.
Comunicarse con los usuarios sobre lo
retroalimentacin.
S.7 RsuuN
La prctica de la ingeniera del software incluye conceptos, principios, mtodos y
herramientas que aplican los ingenieros de software durante el proceso de software. Cada proyecto de ingeniera del software es diferente, aun as existe un conjunto
de principios y tareas aplicables para cada actividad del marco de trabajo del proceso, sin importar el proyecto o producto.
Si se pretende dirigir una buena prctica de la ingeniera del software, es necesario un conjunto de puntos esenciales tcnicos y de gestin. Los puntos tcnicos
incluyen la necesidad de entender los requisitos y las reas de incertidumbre del prototipo, as como la necesidad de definir de manera explcita la arquitectura del software y el plan de integracin de componentes. Los puntos esenciales de gestin
incluyen la necesidad de definir prioridades y especificar un calendario realista que
las refleje, la necesidad de precisar medidas de control del proyecto apropiadas para
la calidad y el cambio.
CAPTULO 5
LA PRCTICA: UNA VlSIN GENRICA
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 establezca la mejor comunicacin.
Los principios de planeacin se enfocan en las directrices encaminadas a construir 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 modelado incluye tanto el anlisis como el diseo, al describir representaciones del software que se vuelven ms detalladas de manera progresiva. La finalidad
de los modelos es solidificar la comprensin del trabajo que se realizar y proporcionar 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 integracin combina los componentes individuales e involucra una serie de pruebas que
se enfocan en los aspectos del funcionamiento general y de las interfases locales.

Los principios de codificacin definen las acciones genricas que deben ocurrir antes
de que se escriba el cdigo, mientras ste se crea y despus de que se haya completado. 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 objetivo de encontrar un error.
Durante el desarrollo del software evolutivo se presenta el desarrollo para cada
incremento de software que se presenta al cliente. Los principios clave para la entrega consideran administrar las expectativas del cliente y dotar al usuario con informacin 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. Jeffries, Agile Modeling, Wiley, 2002.

[BEN991 Bentley, J., Programming Pear/s, 2a. ed., Addison-Wesley, 1999.
[BOE 96) Boehm, B., "Anchoring the Software Process", en IEEE Software, vol. 13, nm. 4, julio
de 1996, pp. 73-82.
[BOHOOJ Bohl, M. y M. Rin, Tools for Structured Design: An lntroduction to Programming Logic,
5a. ed., Prentice-Hall, 2000.
[DAV95J Davis, A., 201 Principies o/software Development, McGraw-Hill, 1995.
[FOW99] Fowler, M. et al., Refactoring: rmproving the Design of Existing Code, Addison -Wesley,
1999.
(GAR95J Garlan, D. y M. Shaw, "An lntroduction to software Archtecture", en Avances in
Software Engineering and K.nowledge Engineering, vol. I (V. Ambriola y G. Tortora, eds.).
World Scientific Publishing Company, 1995.
[HIGOOJ Highsmth, J., Adaptive software Development: An Evolutionary Approach to Managing
Complex systems, Dorset House Publishing, 2000.
11
130
11
111:111
PARTE DOS PRCTICA DE LA INGENIERA DEL SOFJWARE

fH0096J Hooker, D., "5even Principies of Software Development". septiembre de 1996, disponible
en http://c2.com/cgi/wikiSevenPrinciplesOfSoftwareDevelopment.
IHUN95J Hunt, D. , A. Bailey y B. Taylor, The Art of Facilitation, Perseus Book Group, 1995.
[HUN99J Hunt A., D. Thomas y w. Cunningham, The Pragmatic Programmer, Addison-Wesley,
1999.
[JUS99] Justice, T. et al., The Facilitator's Fieldbook, AMACOM, 1999.
[KAN93J Kanner, C., J. Falk y H. Q. Nguyen, Testing Computer Software, 2a. ed., Van Nostrand
Reinhold, 1993.
[KAN96J Kaner, S. et al., The Facilitator's Guide to Preparatory Decision Making, New Society
Publishing, 1996.
[KAR94J Karten, N., Managing Expectations, Dorset House, 1994.
[KER78] Kernighan, B. y P. Plauger, The Elements of Programming Style, 2a. ed., McGraw-Hill,
1978.
[KNU98J Knuth, D., The Art of Computer Programming, 3 volmenes, Addison-Wesley, 1998.
[MCC93J McConnnell, s.. Code Complete, Microsoft Press, 1993.
[MCC97J McConnell, S.. "Software's Ten Essentials", en IEEE SOftware, vol. 14, nm. 2, marzoabril, 1997, pp. 143-144.
[MYE78J Myers, G., Composite Structured Design, Van Nostrand, 1978.
[MYE79] Myers, G., The Art ofSOjtware Testing, Wiley, 1979.
[PAR72J Parnas, D.L., "On Criteria to Be Used in Decomposing Systems into Modules", en
O\CM, vol. 14, nm. l, abril de 1972, pp. 221-227.
[POL45J Polya, G., How to SO/ve lt, Princeton University Press. 1945.
[ROS75] Ross. D.. J. Goodenough y C. Irvine. "Software Engineering: Process, Principies and
Goals", en IEEE Computer, vol. 8, nm. 5, mayo de 1975.
[SHA95a) Shaw, M. y D. Garlan, "Formulations and Formalisms in Software Architecture", Volume
1000-Lecture Notes in Computer Science, Springer-Verlag, 1995.
[SHA95b] Shaw, M. et. al., "Abstractions for Software Architecture and Tools to Support Them",
en IEEE Trans. SOjtware Engineering, vol. SE-21 , nm. 4, abril de 1995, pp. 314-335.
[STE74J Stevens. W., G. Myers y L. Constantine, "Structured Design", en TBM Systems Journal,
vol. 13, nm. 2, 1974, pp. J 15-139.
[TAY90) Taylor D. A., Object-Oriented Technology: A Manager's Guide, Addison-Wesley, 1990.
IULL97J Ullman, E.. aose to lhe Machine: Technophilia and its Discontents, City Lights Books,
1997.
[WIR71J Wirth, N., "Program Development by Stepwise Refinement", en CACM, vol. 14, nm. 4,
1971, pp. 221-227.
[W0095J Wood, J. y D. Silver, Joint Application Design, Wiley, 1995.
[ZAH90) Zahniser. R. A., "Building Software in Groups", en American Programmer, vol. 3, nms.
7-8, julio-agosto de 1990.
ba!JnlNII X uvaa A srt!lfNMP

5. 1. lntntese resumir en un prrafo breve los ''siete principios para el desarrollo de software"
de David Hooker (seccin 5.1). Trtese de extraer la esencia de su gua en slo unas cuantas
oraciones y sin usar las palabras de Hooker.
5.2 . Existen otros puntos tcnicos "esenciales" que se puedan recomendar a los ingenieros de
software? Enunciar cada uno de ellos y explicar por qu se han incluido.
5 .3. Existen otros puntos "esenciales" de gestin que se puedan recomendar a los ingenieros de
software? Enunciar cada uno de ellos y explicar por qu se ha incluido.
5 .4 . Un principio importante de la comunicacin establece "prepare antes de comunicar".

Cmo podra esta preparacin manifestarse por s misma en los primeros trabajos que se
realizan? Cules productos de trabajo podran resultar como consecuencia de la preparacin
oportuna?
CAPTULO 5
LA PRGnCA: UNA VISIN GENRICA
131
5.5. Hgase una investigacin de la "facilitacin" para la actividad de comunicacin (utilcense las referencias que se proporcionan u otras) y preprese un conjunto de directrices que se
enfoquen slo en la facilitacin.
5.6 . En qu difieren la comunicacin gil y la comunicacin de la ingeniera de software tradicional? En qu son similares?
5 . 7. Por qu es necesario continuar?

5 .8 . Realizar una investigacin de la "negociacin" para la actividad de comunicacin y preparar un conjunto de directrices que se enfoquen slo en la negociacin.
5 .9. Describir lo que significa granularidad en el contexto de un calendario de proyecto.

5 . 10. Por qu son importantes los modelos en el trabajo de la ingeniera de software? Siempre
son necesarios? Son calificadores para su respuesta acerca de la necesidad?
5 . 11 . Cules son los tres "dominios que se consideran durante el modelado del anlisis?
5 . 12. Tratar de agregar un principio adicional a los enunciados para la codificacin de la seccin 5.6.
5 . 13. Qu es una prueba exitosa?
5 . 14. Se est de acuerdo con el siguiente enunciado?: "debido a que entregamos mltiples
incrementos al cliente, no debemos preocupamos por la calidad en los primeros incrementos;
los problemas se pueden resolver en iteraciones posteriores. Explquese la respuesta.
5 . 15. Por qu es importante la retroalimentacin para el equipo de software?
La comunicacin con el cliente es una actividad muy importante en la ingeniera del software;
no obstante, algunos profesionales no dedican tiempo a leer acerca de ella. Los libros de Pardee
(To Satsfy and Delight Your Costumer, Dorset House. 1996) y Karten [KAR94J proporcionan una
gran perspectiva de los mtodos para la interaccin efectiva con el cliente. En muchos libros
sobre la gestin de proyectos se consideran los conceptos y principios de la comunicacin y la
planeacin. Las ofertas tiles relativas a la gestin de proyectos incluyen: Hughs y couerell
(Software Project Management, segunda edicin, McGraw-Hill, 1999), Phillips (The Software
Project Manager's Handbook, IEEE Computer Society Press, 1998), McConnell (Software Project
Survival Guide, Microsoft Press, 1998) y Gilb (PTincip/e:s of sojlware Engineenng Managemem.
Addison-Wesley, 1998).
casi cualquier libro sobre ingeniera del software contiene una exposicin til sobre los conceptos y principios para el anlisis, el diseo y las pruebas. Entre las mejores ofertas estn los
libros de Endres y sus colegas (Handbook o/Software and syscems Engineering, Addison-Wesley,
2003), Sommerville (Software Engineering, sexta edicin, Addison-Wesley, 2000), Pfleeger
(Software Engineering: Theory and Practice, Prentice-Hall, 2001) y Schach (Object-Orienled and
Classica/ Software Engineering, McGraw-Hill, 2001). Davis ha recopilado una amplia coleccin de
principios de software en [DAV95).
Los conceptos y principios del modelado se consideran en muchos libros dedicados al anlisis de requisitos o al diseo de software. Young (Ejfective Requirements Practices, AddisonWesley, 2001) resalta un "equipo conjunto" de clientes y desarrolladores que elaboren los requisitos colectivamente. Weigers (Software Requirements, Microsoft Press, 1999) presenta muchos
requisitos clave de ingeniera y requisitos de las prcticas de gestin. Sommerville y Kotonya
(Requirements Engineering: Process and Techniques, Wiley, 1998) analizan los conceptos y las tcnicas de "obtencin" y otros principios de la ingeniera de requisitos.
El libro de Norman (The Design ofEveryday Things. Currency/Doubleday. 1990) es una lectura obligada para cualquier ingeniero de software que intente hacer el trabajo de disen
Winograd y sus colegas (Bringing Design to Software, Addison-Wesley. 1996) han editado una
excelente coleccin de ensayos que tratan sobre los aspectos prcticos del diseo de software.
Constantine y Lockwood (Software for Use, Addison-Wesley, 1999) presentan los conceptos aso-
11
132
PARTE DOS
l a1IUll~I
PRcnCA DE LA INGENIERA DEL SOFTWARE
ciados con el "diseo centrado en el usuario". Tognazzini (Tog on SOflware Design, AddisonWesley. 1995) presenta una valiosa exposicin filosfica de la naturaleza del diseo y el impacto de las decisiones sobre la calidad y la capacidad del equipo para producir un software que
proporcione un gran valor a su cliente.
Hay cientos de libros que tratan sobre uno o ms elementos de la actividad de construccin.
Kemighan y Plauger [KER78J escribieron un texto clsico sobre el estilo de programacin
McConnell [MCC93J presenta directrices pragmticas para la construccin prctica de software
Bentley [BEN99J sugiere una amplia variedad de perlas de programacin; Knuth (KNU98) ha
escrito una serie clsica de tres volmenes sobre el arte de la programacin, y Hunt [HUN99J
sugiere directrices pragmticas de programacin. La bibliografa sobre pruebas ha florecido en
la dcada pasada. Myers [MYE79) se conserva como un clsico. Los libros de Whitaker (How to
Break SOflware, Addison-Wesley, 2002), Kaner y sus colegas (Lessons Leamed in SOflware Testing
Wiley, 200 I) y Marick (The Craft of SOflware Tesling, Prentice-Hall, 1997) presentan conceptos y
principios importantes sobre las pruebas, as como una gua pragmtica considerable.
En Internet existe una amplia variedad de fuentes de informacin sobre la prctica de la
ingenieria del software. En el sitio web de SEPA se puede encontrar una lista actualizada de
referencias en la red mundial, las cuales son relevantes para la prctica de la ingeniera de software:
CAPTULO
INGENIERA
DE SISTEMAS
CONCEPTOS
......
LAVE
fl'Nll(fo . ..142
....... .140
. . . .os ...135
aililnUML ..147
,...a.s .... .144

-
.....134
aljllledwa
..s.s
fm .......135
....tos ...135
prll'llllI .136
...wo ....144
. . . . . . . .139
ace casi 500 aos, Maquiavelo dijo: "No hay nada ms dificil de llevar a
cabo, ms peligroso de realizar o de xito ms incierto que encabezar la
introduccin de un nuevo orden de cosas". Durante los 50 ltimos aos,
los sistemas basados en computadora han introducido un nuevo orden. Aunque
la tecnologa ha tenido varios avances desde la poca de Maquiavelo. sus palabras an siguen vigentes.
La ingeniera del software ocurre como consecuencia de un proceso llamado
ngeniera de sistemas. En lugar de concentrarse slo en el software, esta disciplina se centra en una variedad de elementos mientras analiza, disea y organiza aquellos elementos de un sistema que pueden ser un producto, un servicio
o una tecnologa para la transformacin o control de informacin.
El proceso de ingeniera de sistemas asume distintas formas, segn el dominio de aplicacin en que se utilice. La ingeneria de procesos de negocios se aplica cuando el contexto del trabajo se enroca en una empresa. cuando se va a
construir un producto (en este contexto un producto incluye todo, desde un telfono inalmbrico hasta un sistema de control de trfico areo), al proceso se le
llama ingeniera de producto.
Tanto la ingeniera de procesos de negocio como la de producto intentan
poner orden en el desarrollo de sistemas basados en computadora. Aunque cada
uno de eJJos se utiliza en un dominio de aplicacin diferente, ambos buscan
poner al software en su contexto. Es decir, tanto la ingeniera de procesos de
Qu es? Antes de que sea posible

construir el software, por rnec:lio de la
ingeniera, sedebeentenderel saste
mo" en que ste reside. Pom lograrlo es necesario determinar e l ~
general del sislemaj se debe iden1ificar el papal
que tienen el hardware, el software, las personas, los bases de datos, los procedimientos y
otros elementos del sistema; y se deben identifi
car, analizar, especificar, modelar, validar y gestionar los requisitos operacionales. Estos adivi
dodes son el fundamento de la ingeniera de sis
temas.
Quin lo hace? Un ingeniero de sistemas tra
bajo para entender los requisitos de un sistema
trabajar con el diente, usuarios futuros y otros
-meresodos.
Por qu .. lmportantef b<.iste un niteu;; ., ,

pn:,w,rbio que dice: 1os rbales no dejan ver el
bosque". En este contexto, el "bosque"' es el sis

lema y los rboles son los elementos tecnolgi
cos (incluido el software) que se requieren poro
realizar el sistema. Si se construyen los elemen
tos tecnolgicos de una manera predpitoda
antes de entender el sistema, sin dudo se come
laln errores que decepcionorn al diente.
Antes de preocuparse por los rboles se debe
entender el bcque.
Culea son loa palOS? Se identifican los objeliYO) y requi5ilo~ operacionales ms detallados
al obtener mformodn del dinf; S dnalizan

los requ1s1tos para evaluar su claridad, si esf6
completo y es consistente;
se cree uno 1ttpec1'f'1
cocin, que por
lo general est incorporado o

133
PARTE DOS
134
PRCTICA DE LA INGENIERlA DEL SOFTWARE
~como
puede realim; cr
CW..
YQS,~.,.
pero
CICIM.d.ea,
negocios como la ingeniera de producto, trabajan para asignar un papel al softwa

re de computadora y, al mismo tiempo, establecer los enlaces que unen al software.
con otros elementos de un sistema basado en computadora
Este captulo se centrar en las necesidades de gestin y en las actividades especficas del proceso que permitan a la organizacin de software asegurarse de hacet
las cosas correctas en el tiempo correcto y del modo correcto.
A, l IPTINAI l&lf PM 1M COWITMOl:I

La palabra sistema tal vez sea el trmino ms usado y del que ms se abusa en e
lxico tcnico. Se habla de sistemas polticos, sistemas educativos, de sistemas de

aviacin y sistemas de fabricacin, de sistemas bancarios y sistemas de locomocin
La palabra dice muy poco. El adjetivo se utiliza para describir el sistema y as! enten
der el contexto en el que se usa la palabra. El diccionario Webster define sistema de
la siguiente manera:
1. Un conjunto o disposicin de cosas relacionadas que forman una unidad o un todo orgnico, 2 Una serie de hechos, principios, reglas, etctera, clasificado y dispuestos de manera ordenada que muestran un plan lgico de la unin de las partes; 3 . Un mtodo o plan
de clasificacin o d1spos1c1n; 4. Una manera establecida de hacer algo; mtodo; procedimiento...
En el diccionario aparecen cinco definiciones ms, pero no se sugiere un sinnimo

preciso. Sistema es una palabra especial. Al retomar la definicin del diccionario
Wcbster, un sistema basado en computadora se define como
Un conjunto o disposicin de elementos que estn organ11ados para cumplir una meta
predefinida al procesar mformac1on.
En realidad , el trmino mgcueria ck sistemc.15 se emplea con frecuencia en este contexto. Sin em
bargo, para los propositos de este libro ffingenerta de sistemas" es genrico y abarca la ingeniera
de procesos del negocio y ,a mgeruena de producto
CAPTULO 6
135
Es posible que la meta sea apoyar una funcin de negocio o desarrollar un produc-
to que pueda venderse para generar beneficios. Para cumplir la meta, un sistema
basado en computadora emplea una variedad de elementos del sistema:
software. Programas de computadora, estructuras de datos y documentacin

que sirven para hacer efectivo el mtodo, procedimiento o control lgico que se
requiere.
Hardware. Dispositivos electrnicos que proporcionan capacidad de clculo, dispositivos de interconexin (por ejemplo, conmutadores de red, dispositivos de telecomunicacin) que penniten el flujo de datos, y dispositivos electromecnicos (como
sensores, motores, bombas) que proporcionan una funcin externa, del mundo real.
Personas. Usuarios y operadores del hardware y software.

Bases de datos. Una extensa y organizada recopilacin de informacin a la cual
se tiene acceso a travs de software y que persiste a travs del tiempo.
Documentacin. Informacin descriptiva (por ejemplo, modelos, especificaciones, manuales, archivos de ayuda en lnea, sitios web) que detalla el uso y operacin
del sistema.
Procedimientos. Los pasos que definen el uso especfico de cada elemento del
sistema o el contexto de procedimiento en que reside el sistema.
Estos elementos se combinan de varias maneras para transformar la informacin.
Por ejemplo, un departamento de mercadotecnia transforma la informacin bruta de
ventas en un perfil del comprador tlpico del producto; un robot transforma un archivo de rdenes que contiene instrucciones especficas en un conjunto de seales de
control que provocan alguna accin fisica especfica. La creacin de un sistema de informacin para asesorar al departamento de mercadotecnia y un software de control para
el robot requiere de la ingeniera de sistemas.
1' ,._. afies
uno mmputadora que oo puedas lonzor por lo ventano.
Una caracterstica complicada de los sistemas basados en computadora es que tal

vez constituyen un macroelemento de un sistema an mayor. El macroelemento es
un sistema basado en computadora que es parte de un sistema mayor basado tambin en computadora. Por ejemplo, un siscema de aucomaazacin ae una ;mmca se
considera una jerarqua de sistemas. En el nivel ms bajo de la jerarqua se encuentra una mquina de control numrico, robots y dispositivos de entrada de informacin. Cada uno de stos es un sistema basado en computadora por derecho propio.
Los elementos de la mquina de control numrico incluyen hardware electrnico y
electromecnico (por ejemplo, procesador y memoria, motores, sensores), software
(para comunicaciones y control de la mquina). personas (el operador de la mquina), una base de datos (el programa de CN almacenado), documentacin y proced-
' ll lkllilllll
136
PARTE DOS PRGnCA DE LA INGENIERA DEL SOFTWARE
mientas. Podra aplicarse una descomposicin similar al robot y al dispositivo de

entrada de informacin. Todos son sistemas basados en computadora.
En el siguiente nivel de la jerarqua se define una clula de fabricacin. sta es u:sistema basado en computadora que puede tener elementos propios (por ejemplo
computadoras, instalaciones mecnicas), y tambin integra los macroelementos qut
se han denominado mquina de control numrico, robot y dispositivo de entrada de
informacin.
En resumen, la clula de fabricacin y sus macroelementos estn compuestos de::
elementos del sistema con las etiquetas genricas: software, hardware, personas
bases de datos, procedimientos y documentacin. En algunos casos los macroelementos pueden compartir un elemento genrico. Por ejemplo, el robot y la mquina
de CN podra operarlas el mismo operador (el elemento personas). En otros casos
los elementos genricos son exclusivos de un sistema.
El papel del ingeniero de sistemas es definir los elementos de un sistema especfico basado en computadora en el contexto de la jerarquia global de sistemas
(macroelementos). En las secciones siguientes se examinan las tareas que constituyen la ingeniera de sistemas de computadoras.
6.2
(ti Iii Iii 5':'1

~
. . . . . de
...... de Sis1emos
(OSS)~
_...._ ies en
uu hmss.,..
&,
~~
C~VE
le 1nm ilgenierlo de
sislams comienzo con
u: f5'11e1Dniento cloro
d:I cmtexlo -lo visin
~ Vdespus, de
r:mero rogresivo, el
~sedelimi1o
bi5*I kl comrensin
de mdelolles tcnicos.
LA rlllAl@VIA PI LA IHUBJIRIA PI IJ$XINAI

Sin importar su dominio de enfoque, la ingeniera de sistemas abarca una serie de
mtodos para navegar de arriba hacia abajo y de abajo hacia arriba en la jerarqua
ilustrada en la figura 6. 1. El proceso de la ingeniera de sistemas por Jo general
comienza con una "visin global". Es decir, se examina el dominio entero del negocio o producto para asegurarse de que se puede establecer el contexto tecnolgico
o de negocios apropiado. La visin global es refinada para enfocarse totalmente en
un dominio especfico de inters. Dentro de un dominio especial se analiza la necesidad de elementos del sistema (por ejemplo, informacin, software, hardware, personas). Al final se inicia el anlisis, diseo y construccin del elemento del sistema
deseado. En la parte alta de la jerarqua se establece un contexto muy amplio, y en el
de la parte baja se conducen actividades tcnicas detalladas, realizadas por la disciplina de ingeniera correspondiente (por ejemplo, ingeniera de hardware o software). 2
Dicho de una manera un poco ms formal, la visin global (VG) la compone un
conjunto de dominios (D;) en donde cada uno de ellos puede ser un sistema o un sistema de sistemas por derecho propio.
VG
= ID 1, D;z, D.3, ..., Dnl
Cada dominio Jo componen elementos (E1) especficos, los cuales tienen un papel
para cumplir el objetivo y las metas del dominio o componente:
Sin embargo, en algunas situaciones los ingenieros del sistema deben considerar primero los elementos 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.
CAPTULO 6
D;
= {E1,
137
Ei, E3, ..., Eml
Por ltimo, cada elemento se implementa al especificar los componentes (Cd tcnicos que logran la funcin necesaria para un elemento:
E1 = {C,, C2, C3, ..., Ck)
En el contexto de software un componente podra ser un programa de computadora, un componente reutilizable de un programa, un mdulo, una clase u objeto o
incluso un enunciado en lenguaje de programacin.
"Siempre diseia las Cll5GS considerndolos en su contexto inmedioto supeor: uno sllo en un <uorto, un cuarto en una
casa, una caso en un verindario, un vendorio en unpion urbano:
Es importante notar que el ingeniero de sistemas estrecha ms el enfoque de trabajo conforme avanza hacia abajo en la jerarqua descrita. Sin embargo, la visin
global muestra una clara definicin de la funcionalidad general que Je permitir al
ingeniero entender el dominio y el sistema o producto en el contexto apropiado.
Dominio de negocio
o de producto
Visin global
6.2.1 Modelado del sistema

El modelado de sistemas es un elemento importante del proceso de ingeniera de sistemas. Sin importar que el enfoque est en la visin global o en la visin detallada,
el ingeniero crea modelos que [MOT92) :
lli llllllll
138
Qu se
logra con el
modelo de la
ingeniera de
sistemas?
PARTE DOS
PRcnCA DE LA INGENIERA DEL S0f1WARE
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 informacin al modelo.
Representan todas las uniones (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 permutaciones y variaciones posibles, Jo

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 producll.
permite la representacin de formas humanas en tres dimensiones. Las entradas a este dominio comprenden la habilidad de adaptar movimiento de un actor 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 suministra una amplia variedad de fotocopiadoras, escneres y equipos similares.
El ingeniero de sistemas modela las necesidades de la organizacin suministradora y trabaja para entender el flujo de informacin que engendra una orden de suministro. Aunque una orden de suministro puede originarse desde
muchas fuentes, el ingeniero toma en cuenta slo dos de ellas: la demanda
interna y la peticin externa. Esto permite una particin simplificada de entradas que se requiere para generar la orden de suministro.
Un ingeniero de
sistemas considero los
siguientes factores al
determinar soluciones
alternativas:
supuestos,
simplfociones,
limitaciones,
restricciones y
preferencias del
cliente.
3. limitaciones que ayudan a delimitar el sistema. Por ejemplo, se modela un sistema 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 modelado para acomodar un mximo de dos motores y sus numerosos
sistemas asociados.
4.
Restricciones que guan la manera de crear el modelo y tomar el enfoque al

implementarlo. Por ejemplo, la infraestructura tecnolgica para el sistema de
representacin tridimensional descrito antes utiliza procesadores duales basados en GS. 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 nivel o en otros niveles; las entradas endgenas unen componentes individuales de un elemento el'
una visin particular.
CAPTULO 6
139
5 . Preferencias que indican la arquitectura preferida para todos los datos, funcio-
nes y tecnologa. La solucin preferida a veces entra en conflicto con otros

factores restrictivos. Sin embargo, la satisfaccin del cliente muchas veces se
toma en cuenta hasta el punto de realizar su enfoque preferido.
El modelo de sistema resultante (desde cualquier visin) puede reclamar una solucin automtica por completo, semiautomtica o un enfoque manual. De hecho, con
frecuencia es posible caracterizar modelos de cada tipo que sirvan como soluciones
alternativas del problema que se tiene entre manos. En esencia, el ingeniero de sistemas tan slo modifica la influencia relativa de diferentes elementos del sistema
(personas, hardware, software) para crear modelos de cada tipo.
1 ~ GBGS simples delieci ser simples. los <osas complejos deben ser posibles."
6.2.2 Simulacin del sistema
Muchos sistemas basados en computadora interactan con el mundo real en forma

reactiva. Es decir, los eventos del mundo real los monitorean el hardware y el software que componen el sistema basado en computadora y, con base en estos eventos, el sistema impone control sobre las mquinas, los procesos e incluso sobre la
gente que genera los eventos. Los sistemas de tiempo real y sistemas empotrados a
menudo pertenecen a la categora de sistemas reactivos.
Muchos sistemas de la categora de los reactivos controlan mquinas o procesos
(como aerolneas comerciales o refineras de petrleo) que deben operar con un
grado muy alto de confiabilidad. Si el sistema falla podran ocurrir prdidas econmicas o humanas significativas. Por esta razn, el modelado del sistema y las herramientas de simulacin se utilizan para ayudar a eliminar sorpresas cuando se construyen sistemas reactivos basados en computadora. EStas herramientas se aplican
durante el proceso de ingeniera de sistemas, cuando se especifica el papel del hardware, el software, las bases de datos y las personas. El modelado y las herramientas de
simulacin permiten al ingeniero de sistemas probar una especificacin del sistema.
Herramientas de simulacin del sistema

Objetivo: Los herramientas de simulacin del
sistema proporcionan al ingeniero de software
lb copocidod de predecir el comportamiento de un
s:.aemo de tiempo real antes de que ste se construyo.
oems, estos herramientas permiten al ingeniero de
5ICll"'ware desarrollar moquetas del sistema en tiempo
r:!Ci lo que permite al diente tener uno visin del
funcionamiento, operacin y respuesta antes de lo

implementacin real.
Mecnica: los herramientas de esta categora permiten

a l ecuipo definir los elementos de un sistema basado
en computadoras, y despus ejecutar varias

simulaciones paro entender mejor los coracters~cos
operacionales y el desempeo general del sistema.
PARTE DOS PRCTICA DE LA INGENIERA Dfl. sortwARE
140
Existen dos omplias categoras de simulacin del
Simics, desarrollada par Yirtutech (www.virtutech.com), es
sistema: l) herramientas de propsitos generales que

pueden modelar de manero virtual cualquier sistema
basado en computadoras, y 2) herramientas de
propsitos especiales, que estn diseadas para
emplearlas en un dominio de aplicacin especfica
(como en sistemas de aerolneas, sistemas de
manufacturo, sistemas electrnicos).
Henamientas representativas4
CSIM, desarrollado par Lockheed Martn Advanced
Technology Lobs (www.atl.extemal.lnco.com), es un
simulador de eventos discretos de propsitos generales
paro sistemas orientados a diagramas de edificios.
uno plataforma de simulacin de sistema que puede

modelar y analizar sistemas basados en hardware y
software.
SLX, desarrollado par Wolverine Software

(www.wolverine.com), proporciona bloques de
construccin de propsito general paro modelar el
desempeo de uno amplio variedad de sistemas.
En http:/ /www.idsio.ch/-ondreo/simtools.htrnl se puede
encontrar uno serie de vnculos o varios fuentes de
simulacin de sistemas.
6, 3 JH@IHJIRl4 PI Ppocsos PI B1G9CJ9$; PBA yg16111 FIMIRAL

La meta de la ingeniera de procesos de negocios (IPN) es definir arquitecturas que permitan que un negocio utilice informacin de manera efectiva. Cuando las necesidades de tecnologa de informacin de una compaia se observan de manera global
Ctles
S011
las
_...tecmas que
se 4efilea y
casi no hay duda de que se requiera la ingeniera de sistemas. No slo se requiere la

especificacin de la arquitectura de cmputo apropiada, sino tambin se debe desarrollar la arquitectura de software que puebla la configuracin nica de fuentes de
cmputo de la organizacin. La ingeniera de procesos de negocios es un enfoque
que crea un plan general para implementar la arquitectura de cmputo [SPE93].
Se deben analizar y disear tres arquitecturas diferentes dentro del contexto de
objetivos y metas de negocios.
Arquitectura de datos
4tsarrolcm como
,-te de la IPN?
Arquitectura de aplicaciones
Infraestructura de la tecnologa
La arquilectura de dalos proporciona un marco de trabajo para las necesidades de
informacin de un negocio o de una funcin de negocios. Los ladrillos de la arquitectura son los objetos de datos que utiliza el negocio. Un objeto de los datos contiene un conjunto de atributos que define algn aspecto, cualidad, caracterstica o
descriptor de los datos que se describen.
Una vez definido un conjunto de datos se identifican sus relaciones. Una relacin
indica la forma en que los objetos estn conectados entre s. Como ejemplo se pue-
Las herramientas mostradas aqu son una muestra de esta categora. En la mayora de los casos los
nombres estn registrados por sus respectivos desarrolladores.
CAPTULO 6
14 1
den considerar los objetos cliente y productoA. Los dos objetos pueden conectarse por la relacin compra; es decir, un cliente compra productoA o productoA es
comprado por un cliente. Los objetos de datos (que pueden existir cientos o hasta
miles para una actividad de negocios importante) fluyen entre funciones de negocio,
estn organizados dentro de una base de datos y se transforman para ofrecer informacin que satisface las necesidades del negocio.
La arquitectura de apjjcacin abarca aquellos elementos de un sistema que transforman objetos dentro de la arquitectura de datos por algn propsito del negocio.
En el contexto de este libro se considera que la arquitectura de aplicacin es el sistema de programas (software) que realiza esta transformacin. Sin embargo, en un
contexto ms amplio, la arquitectura de aplicacin puede incorporar el papel de las
personas (quienes son transformadores y usuarios de informacin) y procedimientos
de negocios que no han sido automatizados.
La
infraestructura tecnolgica proporciona el fundamento para las estructuras de
datos y de aplicacin. La infraestructura comprende el hardware y el software con

que se apoyan las aplicaciones y los datos. Esto incluye computadoras, sistemas de
operacin, redes de computadora, enlaces de telecomunicaciones, tecnologas de almacenamiento y la arquitectura (por ejemplo, cliente, servidor) diseada para implementar estas tecnologas.
En la figura 6.2 se define e ilustra una jerarqua de proceso de negocios para
modelar estas arquitecturas de sistema.
lo empreso.
1---.---.---.-----t
Planeacin
estratgica
de la informacin
(visin global)
Anlisis del
rea de
nesocio
(viJin de
dominio)
Diseo del
sistema del
MO.!JCXO
(vis,on del
elemento)
Ingeniero
de software
1 11111111
14 2
CAPTULO 6 INGENIER!A DE SISmMS
La meta de la ingeniera de producto es traducir el deseo del cliente, de una serie de

capacidades definidas, a un producto del trabajo. Para conseguir esta meta la inge-
Amenudo se utilizo
en esre conrexto el
modg/o concurrgnfg
dbl ptOCbSO (captulo
3). Codo disciplino de

ingeniera troboio en
paralelo. 5e debe
esl/Jr seguro de que

se promueva lo
comunicacin
mientras codo
disciplino desempeo
su troboo.
niera de producto -como la ingeniera de procesos de negocios- debe crear una

arquitectura y una estructura. La arquitectura abarca cuatro componentes de sistema distintos: software, hardware, datos (y bases de datos) y personas. Se establece
una infraestructura de soporte e incluye la tecnologa requerida para unir los componentes y la informacin (como documentos, CD-ROM, video) que se emplea para
dar soporte a los componentes.
Como lo muestra la figura 6.3, la visin global se consigue mediante la ingeniera
de requisitos (captulo 7). Los requisitos generales del producto se obtienen del cliente. Estos requisitos comprenden necesidades de informacin y control, funcionalidad
del producto y comportamiento, desempeo general del producto, diseo, restricciones de la interfaz y otras necesidades especiales. Una vez que se conocen estos
requisitos, el trabajo de la ingenieria de requisitos es asignar funcin y comportamiento a cada uno de los cuatro componentes antes descritos.
una vez hecha la asignacin comienza la ingeniera de componentes del sistema.
La ingeniera de componentes del sistema es en realidad un conjunto de actividades
concurrentes que dirige por separado cada uno de los componentes del sistema
ingeniera de software, ingeniera de hardware, ingeniera humana e ingeniera de
La jerarqua de
Ingeniera de
re~uisitos
(visin global)
El producto
completo
la ing eniea de
productos.
Copocidodes
Ingeniera de
com~nente
(visin de
dominio)
Requisito de proceso
Modelado de
anlisis y diseo
(visin del
elemento)
Componentes
de programa
!:==:lllllla:::::!::::;;;:::~:::::::._
Ingeniero
de software
CAPTULO 6
143
bases de datos. cada una de estas disciplinas de ingeniera toma una visin de dominio especfica, pero es importante sealar que las disciplinas de ingeniera deben
establecer y mantener una comunicacin activa entre ellas. Parte del papel de la
ingeniera de requisitos
esto suceda.
es establecer los mecanismos de
interfaz que permitan que
La visin de elemento para la ingeniera de producto es la disciplina de ingeniera aplicada a un componente asignado. Para la ingeniera de software esto significa
actividades de modelado del anlisis y diseo (cubierto en detalle en captulos posteriores) y actividades de construccin y despliegue que abarcan: generacin de
cdigo, pruebas y tareas de soporte. Los modelos de anlisis de tareas asignan requisitos a las representaciones de datos, funcin
y comportamiento. El diseo convier-
te el modelo de anlisis en diseos de datos, arquitectnicos, de interfaz y en el nivel

de componentes del software.
lngenieria de sistema preliminar

Ed: Ya les mande a los dos una copio por c:cnw,
elec!ronico. Revsenla y luego hablamos.
Vinocl: iOu te parce dMpus de t o ~

(Jomie y Yiood recibieron el sigt1ienle Jex1o de fd.)
Notas preeliminores de la estructuro/funcionattdad de
Hoga,Seguro:
El sistemo utilizar6 una o ms PC. varios paneles de

control manuales y monlobles en fa pared, valO$
sensores y varios cootrolodores- de

dispositivos/aplicado,..s.
Todo$ ~ comunicorr) por prolocolos inolmbrit;(
(por eemplo, 802. l lb) y sern diseados poro la

consfruccin de casos nuevos y lo oplicocin en ((2$0$
exislenles.
Todo el hardware, o excepcin de nuestro nuevo oojo

inolmbrico, eslor fuero
i Y qu opinaron los dems?

Bueno, me miraron como si estvviero loco, pero
(el gerente de ingeniera del softwareJ le gust lo
- . gil- as que est hablando con ellos.
miaba lomando notas con mi PDA durante lo
obtuve una lislo de funciones bsicos.
Qu ben, djame ver.
del anaquel
Funcionalidad bsico del software obtenido de fo

conversacin de inicio.
Funciones de seguridod de lo ca~:
Sensor de movimiento de puerlo/venlod poro
moniforear un occeso no outori:zado (roben}.
Monitoreo de fuego y humo.
Montoreo de nivel de a911a en Xlk.lno IP9' oompklr
inundacin o rompimiento del calenlador el& agoot.
' 1
144
PARTE DOS
illii.llill
PRcnCA DE LA INGENIERA DEL SOF'IWARE
mowimiento en el eiderior.
o:,locacin de ,eguridad por Internet.
Disponer un mensaje lo
Contoc1onend.don11
paro,...,...
peridicos, correo, alcllrv.
FuncOlle$ d. la mquina Alh 1k1 . . . .

Listo de llamados a arav. de un
Hora del mensaje.

Texto del mensoie a arav. de un
reconocimiento de '<0%.
funciones del creo ~ -. .
estridores del correo "*""nic:4
l.ecluro de YQZ pot COff90
telefnico.
Directorio lelefnico ~
Vnculo con el PDA.
Otros funciones:
Por definine.
Todm las funciones ...
Debido a que un sistema puede representarse con diferentes grados de abstraccir

(por ejemplo, la visin global, la visin de dominio, la visin de elemento), los mode
los de sistema tienden a ser jerrquicos o estratificados por naturaleza. En la parte
ms alta de la jerarqua se presenta un modelo del sistema completo (la visin global). Los objetos principales de datos, las funciones de procesamiento y los comportamientos se representan sin incluir el componente del sistema que implementara
los elementos del modelo de visin global. A medida que la jerarqua se refina e
estratifica se modela el detalle al nivel de componentes (en este caso, representaciones de hardware, software, etctera). Al final, los modelos de sistemas evolucionan a modelos de ingeniera (los cuales se refinan despus) que son especficos para
la disciplina de ingeniera apropiada.
6 .5.1 Modelado Hatley-Pirbhai

Todo sistema basado en computadora puede modelarse como transformacin de la
informacin al emplear una plantilla de entrada-proceso-salida. Hatley y Pirbha:
[HAT87) han ampliado esta visin para incluir dos caractersticas adicionales del sistema: procesamiento de la interfaz del usuario y mantenimiento y procesamiento de
CAPTULO 6
145
autocomprobacin. Aunque estas caractersticas adicionales no estn presentes en

todos los sistemas basados en computadora, son comunes y su especificacin hace
que cualquier modelo de sistema sea ms robusto.
Con el uso de la representacin de entrada, procesamiento, salida, procesamientos de la interfaz del usuario y procesamiento de autocomprobacin, un ingeniero de
sistemas puede crear un modelo de componentes de sistema que deje un fundamento para etapas posteriores en cada una de las disciplinas de ingeniera.
En el desarrolJo de un modelo de sistema se utiliza una plantilla modelo del sistema [HAT87]. El ingeniero de sistemas asigna elementos de sistema a cada una de
las cinco regiones de procesamiento dentro de la plantilla: 1) interfaz del usuario, 2)
entrada, 3) funcionamiento y control del sistema, 4} salida, y 5) mantenimiento y
autocomprobacin.
Al igual que casi todas las tcnicas de modelado utilizadas en la ingeniera de sistemas y de software, la plantilla modelo del sistema le permite al analista crear una
jerarqua en detalle. En el nivel ms alto de la jerarqua est el diagrama de contexto
del
sistema
(DCS). El diagrama de contexto "establece los lmites de informacin
entre el sistema que implementa y el ambiente en el que opera el sistema" (HAT87J.

Es decir, el DCS define todos los productores externos de informacin que el sistema utiliza, todos los consumidores externos de informacin que el sistema crea,
todas las entidades que se comunican a travs de la interfaz o realizan mantenimiento y autocomprobacin.
Para ilustrar el uso del DCS se considerar un sistema de clasificacin de cinta
transportadora {SCCT) descrito en la siguiente declaracin (un tanto confusa) de
objetivos:
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.
ae
con base en un nmero de identificacin impreso en un lateral de la caJa y un coa1go

barras, las cajas se mandarn a los contenedores apropiados. Las cajas pasan en un orden aleatorio y estn igualmente espaciada5. La lnea 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 obtener la velocidad de la lnea transportadora, almacena todos los nmeros de parte clasificados, 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 para el
seer se muestra en la figura 6.4. El diagrama 5e divide en cinco :seg-
mentos principales. El segmento de arriba representa el procesamiento de la interfaz

del usuario,
y los segmentos de la izquierda y de la derecha mue:strnn el proce:sa-
miento de entrada y de salida, respectivamente. El segmento central contiene funciones de control
y proceso, y el segmento de abajo se enfoca en el mantenimiento
146
Uhtii
Diagrama de
contexto del
sistema del
PARTE DOS PRCTICA DE LA INGENIERA DEL SOF1WARE
Proceso
de lo interfaz
del usuario
Operador de
lo estacin de
dosificacin
SCCT.
Peticin
Lector de
cdigo de
barros
Cinto
transportadora
Procesamiento
de entrada
+ TConsultas Comond~s
de control Mecanismo de
dosificacin
Sistema de
Cdigo
clasificacin
de borras
1
de cinta
Dolos formoteodos del informe
transporladora
___r-
Indicador de la
Dolos de diagnstico
velocidodde lo cinto
Mantenimiento Operador de
lo estacin de
y
dosificacin
autocomprobacin
Estructuro
principal
Procesamiento
de solido
y la autocomprobacin. Cada caja que se muestra en la figura representa una enti-
dad externa; es decir, un productor o consumidor de informacin del sistema. Por

ejemplo, el lector de cdigo de barras produce informacin que es introducida al sistema SCCT. El smbolo para el sistema completo (o, a niveles ms bajos, subsistemas
principales) es un rectngulo con las esquinas redondeadas. Por lo tanto, el SCCT se
representa en la regin de procesamiento y control al centro del DCS. Las flechas etiquetadas que se muestran en el DCS representan informacin (datos y control) que
va de un ambiente externo hacia el sistema SCCT. La entidad externa lector de cdigo de barras produce entrada de informacin etiquetada como cdigo de barras. En
esencia, el ose coloca cualquier sistema en el contexto del ambiente externo.
El ingeniero de sistemas refina el diagrama de contexto de arquitectura al estudiar con ms detalle el rectngulo sombreado de la figura 6.4. Se identifican los subsistemas principales que permiten funcionar al sistema clasificador de cinta transportadora dentro del contexto definido por el DCS. Los subsistemas principales se
definen en un diagrama de flujo del sistema (DFS) que se obtiene del DCS. El flujo de
informacin a travs de las regiones del DCS se utiliza para guiar al ingeniero de sistemas en el desarrollo del DFS, un esquema ms detallado del SCCT. El diagrama de
flujo del sistema muestra los subsistemas principales y el flujo de las lneas de informacin importantes (datos y control). Adems, la plantilla del sistema divide el proceso del subsistema en cada una de las cinco regiones de proceso previamente estudiadas. En este punto, cada uno de los subsistemas puede contener uno o ms elementos del sistema (por ejemplo, hardware, software, personas) tal y como los ha
asignado el ingeniero de sistemas.
C APTULO 6
14 7
DFS de A
El diagrama de lujo del sistema (DFS) inicial se convierte en el nodo superior de

una jerarqua de DFS cada rectngulo redondeado del DFS original puede expan
dirse en otra plantilla de arquitectura dedicada a ella en forma exclusiva. Este proceso se ilustra de manera esquemtica en la figura 6.5 cada uno de los DFS del sistema puede utilizarse como punto de partida de subsiguientes fases de ingenierla
para el subsistema que se describe.
En los subsiguientes trabajos de ingeniena se pueden especificar (delimitar) los
subsistemas y la informacin que fluyen entre ellos. un reldlo descrtpllvo ele cacta
subsistema y una definicin de todos los datos que fluyen entre los subsislemas son
elementos importantes de la especificacin del sistema.
6.5.2 Modelado del sistema con UML

El UML proporciona una cantidad impresionante de diagramas que pueden utilizar
se para el anlisis y diseo al nivel de software y del s1stema. 5 Para el SCCT se modelan cuatro elementos importantes del sistema. 1) el hardware que pennite el SCCT;
y la clasificacin; 3) el
operador que acata varias peticiones del sistema; y 4) la base de datos que contiene
infonnacin relevante del cdigo de barras y el destino.
2) el software que implementa el acceso a la base de datos
5 En los captulos del 8 al 11 se presenta una exposc1on ms detallada de los diagramas de UML. Para
una exposicin completa del UML el lector interesado debe consultar [SCH021, [lAROlJ o [BEN991 .
11 Aill:IIJ
148
PARTE DOS PRCTICA DE LA INGEN!ERA DEL SOFTWARE
Uhilii
Diagrama de
despliegue
del hardware
deSCCT.
El hardware del SCCT se puede modelar en el nivel del sistema mediante un diagrama de despliegue de UML, como se ilustra en la figura 6.6. Cada caja tridimensional muestra un elemento del hardware que es parte de la arquitectura fisica del sistema. En algunos casos, los elementos del hardware tendrn que disearse y construirse como parte del proyecto. Sin embargo, en muchos casos los elementos del
hardware se pueden adquirir ya construidos. El reto para el equipo de ingeniera es
realizar la interfaz de los elementos del hardware de manera apropiada.
Los elementos del software para el seer se pueden modelar en una variedad de
formas mediante el uso de UML. Los aspectos de procedimiento del software del
SCCT se pueden representar mediante un diagrama de actividad (figura 6.7). Esta
notacin del UML es similar al diagrama de flujo y se utiliza para representar lo que
sucede mientras el sistema realiza sus funciones. Los rectngulos redondeados
implican una funcin especfica del sistema; las flechas representan el flujo a travs
del sistema; el rombo de decisin representa una decisin ramificada (cada flecha
que sale del rombo est etiquetada); las lneas slidas horizontales implican la realizacin de actividades en paralelo.
Otra notacin de UML que se puede usar para modelar software es el diagrama de
clase (junto con muchos diagramas relacionados con las clases que se examinan en
apartados posteriores de este libro). En el nivel de la ingeniera del sistema las clases6 se extraen en un enunciado del problema. Para el SCCT las clases candidatas
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.
CAP'nJLO 6
149
INGENIERA DE SJSttMAS
'
Iniciar lnea
del conductor
Obtener la velocida
del conductor
Cdigo de barras
vlido
Oblener
el eil0to$
del condudor
Conductor detenido
Conductor en movimiento
podran ser de: caja, lnea de conduccin, lector de cdigo de barras, contro-
lador de maniobras, solicitud del operador, reporte, producto y otras Cada

clase encapsula un conjunto de atributos que representa toda la informacin necesaria acerca de la clase. Una descripcin de clase tambin contiene un conjunto de operaciones que se aplican a la clase en el contexto del sistema seer. En la figura 6.8 se
muestra un diagrama de clase de UML la clase caja.
El operador del seer se puede modelar con un diagrama de UML de tipo casos
de uso como se muestra en la figura 6.9 El diagrama de caso de uso ilustra la forma
en la que un actor (en este caso el operador que se representa con una figura adherida) interacta con el sistema. cada valo etiquetado dentro de la caja (la cual
representa la frontera del sistema SCCT) implica un caso de uso -un escenario
escrito que describe una interaccin con el sistema.
150
PARTE DOS PRACTICA DE LA INGENIERA DEL SOFTWARE
iihtil
Diagrama de
clasedeUML
para la clase
caja.
Nombre de lo clase
Cojo
cdigo de barros
velocidad hacia delante
ubicocn del conductor
Atribvtos
ohuro
profundidad
peso
confenido
atributos
lectura del c6cligo

de barros( 1
octuolizoci6n
de velocidod( 1
lectura de ve1ocdod( 1
octuolizocin
de lo ubicacin{)
lectura de ubicacin( )
obtencin de dimensiones( )
pobiencin del peso( l
verificacin de contenido( )
iihti.Ji
Diagrama de
caso de uso
para el
operador
seer.
Operador
del SCCT
Operaciones
(los parntesis
ol final del nombre
indican lo listo de
otribvtos que requiere
lo operacin)
CAPTULO 6
151
Herramientas de modelado de sistemas

Objetivo: Los herramientas de modelado de
sistemas proporcionan al ingeniero de software
ropocidod de modelar todos los elementos de un
~ basado en computadoras al usar uno notacin
es:,eonco para lo herramienta.
Mecnica: Los mecnicos de las herramientas varan.
!=br" k, general, los herramientas de esto categora ayudan
mgeniero de sistemas o modelar 1) lo estructura de
b:bs los elementos funcionales del sistema; 2) el
aiqx,nomiento esttico y dinmico del sistema; 3) lo
~ mquina-humano.
Herramientas representativas 7
O:scnbe, desarrollado por Embarcadero Technologies
r-- embarcodero.com), es una adaptacin de
bemlmientos de modelado basados en UML que puede
~ l a r sistemas de software o sistemas completos.
Rational XDE and Rose, desarrollado por Rotional

Technologies (www.rotionol.com), proporciono uno
odoptocin basado en UML de herramientas de
desarrollo y modelado poro sistemas bosodos en
computodoros, lo cual se utiliza de manero amplio.
Real-Time Studo, desarrollado por Artison Software

(www.artisansw.com) es una conjunto de herramientas
de modelado y desarrollo que dan soporte ol
desarrollo de sistemas en tiempo real.
Te/elogie Tau, desarrollado por Telelogic

(www.telelogic.com), es un conjunto con herramientas
basados en UML que da soporte al modelado de
diseo y anlisis, y tiene vnculos con caractersticos de
construccin de software.
Un sistema de alta tecnologa comprende varios componentes: hardware, software,

personas, bases de datos y procedimientos. La ingeniera de sistemas ayuda a traducir las necesidades del cliente en un modelo de sistema que emplea uno o ms de
estos componentes.
La ingeniera de sistemas comienza a1 adoptar una "visin global". Se analiza el
dominio del negocio o producto para establecer todos los requisitos bsicos. El enfoque se reduce entonces a una "visin de dominio", donde cada uno de.lo5 elemen
tos del sistema se analiza en forma individual. cada elemento se asigna a uno o ms
componentes de ingeniera, los cuales se estudian aplicando la disciplina de ingeniera correspondiente.
La ingeniera del proceso de negocios es un enfoque de la ingeniera de sistemas
mediante el cual se definen arquitecturas que permitan a un negocio utilizar la informacin de manera eficaz. El objetivo de la ingeniera del proceso de negocios es
crear una arquitectura de datos, una arquitectura de aplicacin y una infraestructura de tecnologa comprensibles que satisfagan las necesidades de la estrategia de
negocio y los objetivos y metas de cada rea del negocio.
La ingeniera de productos es un enfoque de la ingeniera de sistemas que
comienza con el anlisis del sistema. El ingeniero de sistemas identifica las necesi-
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.
152
PARTE DOS PRC11CA DE LA INGENlERlA DEL SOFTWARE
dades del cliente, determina la factibilidad econmica y tcnica,
y asigna funcione
y rendimientos al software, el hardware, las personas y las bases de datos; es dec.;

a los componentes clave de la ingerueria.
[BEN99J Bennett, S., S. McRobb y R. Fanner, Object-Oriented Systems Analysis and Design U~
UML, McGraw-Hill, 1999.
[HAR93) Hares, J. S., Jnforrnation Engineeringfor Advanced Practitioner, Wiley, 1993, pp. 12-13
[HAT87) Hatley, D. J. e l. A. Pirbhai, Strategiesfor Real-Time System Specijication, Dorset House
1987.
[LARO 1J Larman, C., Applying UML and PaUems: An lntroduction to Object-Oriented Analysis ana
Design and
Unijied Process, 2a. ed., Prentice-Hall, mayo de 2001.
[MAR901 Martin. J.. Inforrnation Engneering: Book II-Planning and Analysis, Prentice-Hall, l99C
[MOT92) Motamarri, S., "Systems Modeling and Description", en Software Engineering Notes, v<j
17, nm. 2, abril de 1992, pp. 57-63.
[SCH02)Schmuller, J., Teach Yourself UML in 24 Hours, 2a. ed., Sams Publishing, 2002.
[SPE93J Spewak, s., Enterprise Architecture P/anning, QED Publishing, 1993.
[THA97) Thayer, R. H. y M. Dorfman, Software Requirements Engineering, 2a. ed., IEEE ComputeSociety Press, 1997.
me
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 ei
cual se est familiarizado. La jerarqua se debe extender hasta los elementos simples del sistema (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 conjunto de dominios que definan la visin global del sistema o producto. Describir el conjunto de elementos que componen uno o dos de los dominios. Para un elemento, identificar los componentes 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 ingenietia de procesos del negocio requiere definir datos, arquitectura de aplicaciones.
adems de una infraestructura de aplicaciones. Describir cada uno de estos tnninos 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 deberla realizar como ingeniero de siste-
mas.
bJ Proponer al menos dos ubicaciones diferentes para el sistema con base en las respuestas a sus preguntas.
cJ En clase. comparar sus ubicaciones con las de sus compaeros.

6.8. Desarrollar un diagrama de contexto del sistema para el sistema basado en computadoras que se haya elegido (o uno asignado por su profesor).
CAPTULO 6
INGENIERiA DE SJSTEMAS
153
6 .9 Aunque la informacin hasta este punto est muy entrecortada, trtese de desarrollar un
cliagrama de desarrollo, un diagrama de actividad, un diagrama de clase y un diagrama de caso
de uso con UML para el producto HogarSeguro
6 .1 o. Realizar una investigacin bibliogrfica y escribir un documento breve que describa
cmo funcionan las herramientas de modelado y simulacin. Alternativa recopile b1bliografia
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 actividades 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? Explquese la respuesta.
Los libros de HaUey y sus colegas (ProcessJor systems Arch1tecture and Requirements Engineering,
Dorset House, 2001 ). Buede (The Engineering Design of systems: Mode/s and Methods, Wiley,
1999), Weiss y sus colegas (Sjlware Product-Une Engineering, Addison-Wesley, 1999),
Blanchard y Fabrycky (systern Engineering and Ana!)'szs, 3a. ed., Prentice-Hall, 1998), Armstrong
y sage (lntroducaon to systems Engineenng, Wiley, 1997), y Martn (systems Engmeering
Guidebook, CRC Press, 1996) presentan el proceso de la ingenierta del sistema (con un nfasis
distinto en la ingenierta) y proporcionan una gula muy valiosa. Blanchard (~tem Engmeering
Management, segunda edicin, Wiley, 199n y lacy (system Engineering Management, McGrawHill, 1992) exponen aspectos de gestin de la ingenieria del sistema.
Choraras (Enterp~ Archilecture and New Generation systems, St. Lucie Press, 2001) presenta ingeniera de informacin y arquitecturas de sistema para la "siguiente generacin" de soluciones de TI; se incluyen sistemas basados en Internet. Wallnau y sus colegas (Building Systems
Jrom Comercial Componermts, Addison-Wesley, 2001) se enfoca en los aspectos de la ingenierla
de sistemas basada en componentes para productos y sistemas de informacin. Lozinsky
(Enterprise-Wide software SO/ubons: lntegratJon Strategies and Practices, Addison-Wesley, 1998)
abarca el uso de paquetes de software como una solucin que permite a las compalas pasar
de los sistemas heredados a los procesos de negocio modernos. Una exposicin muy valiosa del
riesgo y la ingenier!a del sistema se presenta en el libro de Bradley (Elimination of Risk in
systems, Tharsis Boooks, 2002).
oavis (Business Process McxJeling wtCII Ms. A ProcCJcal Gwae. Spr!nger-verlag. 200 I l. Bustard
y sus colegas (system Models for Business Process Improvement, Artech House, 2000), y Scheer
(Business Process Engmeering Reference Models Jor Industrial cnterpriso, Springcr-vcrlag, l ':l':ltl)
describen los mtodos de modelado del proceso de negocios para sistemas de informacin y de
toda una empresa.
Oavis y Yen [The lnformatJon system Consultant's Handbook: Syslems Analysis and Design, CRC
Press, 1998) presentan una cobertura encicloptdica de los aspectos del anlisis y diseo de sistemas en el dominio de los sistemas de informacin. Una ayuda excelente del IEEE por Thayer
y Oorfman [THA97J discute la interrelacin entre los anlisis al nivel de sistema y al nivel de
software.
Law y sus colegas (Simulalion Modeling and Analysis, 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 interesados en un tratamiento ms elaborado del tpico, los libros de Gerald Wemberg (An
Jntroduclion to General System Thinkmg, Wiley, lnterscience, 1976, y On the Design of Stable
systems, Wiley-lnterscience, 1979) se han convertido en clsicos y ofrecen una excelente exposicin sobre el "pensamiento general de sistemas", lo que de manera implcita conduce a un
enfoque general del anlisis y diseo de sistemas. Otros libros ms recientes de Weinberg
(General Pnndple:s o/ Systems Ikslgn, Dorset House, J998 y Rethinkmg Systems Anatysis and
Deslgn, Dorset House, 1998) continan la tradicin de este primer trabaJo
,IR'IIID
154
PARTE DOS PRCTICA DE LA INGENlERA DEL SOFTWARE

En Internet existe una amplia variedad de fuentes de mformac1n sobre la ingeniera de si
temas y materias relacionadas En el sitio Web de SEPA, http: / / www.mhhe.com/pressmai:
se puede encontrar una lista actualizada de referencias en la red mundial que son relevant..
para la ingeniera del sistema , la ingeniera de la informacin, la ingeniera de proceso del neg
co y la ingeniera del producto.
CAPITULO
INGENIERA
DE REQUISITOS
a comprensin de los requisitos de un problema est entre las tareas ms

dificiles que enfrenta un ingeniero de software. Cuando se piensa por primera vez acerca de ello, la ingeniera de requisitos no parece tan dificil.
Despus de todo, el cliente no sabe lo que se requiere? Los usuarios finales no
deberan entender bien las caractersticas y funciones que les proporcionarn un
beneficio? Es sorprendente, pero en muchas ocasiones la respuesta a estas preguntas es: "no". Y aun si los clientes y usuarios finales son explcitos en sus necesidades, estos requisitos pueden cambiar durante el proyecto. La ingeniera de
requisitos es dificil.
En el prlogo a un libro de Ralph Young (YOUO 1J sobre las prcticas efectivas
en los requisitos, el autor de este libro escribi:
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 manera 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 seno peligro.
Todos los que hemos trabajado en el negocio de los sistemas y el so1hvare por m::,
de unos cuantos aos hemos vivido esta pesadilla. y slo unos pocos de nosotros hemos aprendido a contmuar aun con esta circunstancia. Nosotros tenemos dificultades cuando tratamos de obtener requisitos de nuestros clientes. Tenemos problemas
al comprender la informacin que adquirimos. Con frecuencia, registramos los re-
Qu es? lo ingeniera de requsitos ayudo o los ingenieros de softwo

re o entender mejor el problema en
cuyo solucin trabajarn Incluye el
conjunto de toreas que conducen a
_ _..n>nrl,er cul ser el impacto del software
negocio, qu es lo que el cliente quere
nteroctuarn los usuarios finales con el
lo hace? los ingenieros de software

veces referidos como ingenieros de sis
o analistas en el mundo de lo TI) y otros
lilllres4odos (gerentes, clientes y usuarios finales)
~~lS
_.~llf'ln en la ingeniera de requisitos
Por qu es importante? El diseo y la cons

trucc,n de 1.m elegante programa de computa
doro que resuelva el problema incorrecto no
satisface los necesidades de nodie. Por lo kinto,
es muy importante entender lo que el diente
qu'ere antes de comenzar o disear y constrvir
un sistemo basado en computadora.
Cules son los posos? la ingeniera de requi
sitos empiezo con la fase de inicio, la cual es
uno torea que define el mbto y la nolurolezo
del problema que debe resolverse. Despus con
tino con lo obtencin, que es uno torea que
ayudo al cliente o definir sus necesidades; pos
teriormente sigue con lo elaboracin, que es la
155
11
156
PARTE DOS
ilK:IWllilll.
PRCl!CA DE LA INGENIERA DEL SOFTWARE
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 experimentados. Pero existen soluciones.
Sera deshonesto decir que la ingeniera de requisitos es la "solucin" para los retos
que se han enunciado. Pero proporciona un enfoque slido para abordar dichos
desafos.
Las actividades de diseo y construccin de software de computadora son desafiantes, creativas y hasta divertidas. De hecho, la construccin es tan irresistible que
muchos desarrolladores de software quieren entrar en ella antes de comprender cor
claridad de qu es lo que se necesita. Ellos argumentan que las csas se aclararr
mientras construyen; que los interesados en el software sern capaces de entender
mejor las necesidades slo despus de examinar las primeras iteraciones del software; que las cosas cambian tan rpido que la ingeniera de requisitos es una prdida de tiempo; que la linea de base produce un programa que funciona y todo lo
dems es secundario. Lo que hace seductores a estos argumentos es que contiener
elementos de verdad. 1 Pero cada uno de ellos es imperfecto y puede conducir a ur
proyecto de software fallido.
En particular, esto es cierto para los proyectos chicos (menos de un mes) que implican un esfuerzc
relativamente pequeo. Conforme el software crece en tamao y complejidad, estos argumentos comienzan a derrumbarse.
CAPTULO 7
157
INGENIERA DE REQUISTl'OS
"la,....
ms W de conslrui" un sistema de software es decidir qu constnit NingWIO po11e del trabajo ISlrGpll
- . ti sist1n1D resubante si se hoce mol. Ningu1111 parte es ms W de rectificar despuis.
frtdhlu
La ingeniera de requisitos como todas las dems actividades de la ingeniera del
software, debe adaptarse a las necesidades del proceso. el proyecto, el producto y las
personas que realizan el trabajo. Desde la perspectiva del proceso del software, la
ingeniera de requisitos (IR) es una accin de la ingeniera del software que comienza durante la actividad de comunicacin y contina en la actividad de modelado.
En algunos casos se elige un enfoque abreviado. En otros, cada una de las tareas
definidas para comprender los requisitos se debe llevar a cabo de manera rigurosa.
Sobre todo, el equipo de software debe adaptar su enfoque a la IR, lo que no significa abandono. Es esencial que el equipo de software haga un esfuerzo real por entender los requisitos de un problema antes de intentar resolverlo.
La ingeniera de requisitos tiende un puente hacia el diseo y la construccin.
Pero dnde se origina el puente? Se puede argumentar que comienza al pie de los
participantes del proyecto (es decir, gerentes, clientes, usuarios finales), donde se
definen las necesidades del negocio, se describen los escenarios de los usuarios. se delinean las caractersticas y funciones, y se identifican las restricciones del proyecto.
otros quiz sugieran que comienza con la definicin ms amplia del sistema, en el
que el software es slo un componente (captulo 6) del dominio del sistema que es
an mayor. Pero sin importar el punto de inicio, el trabajo a lo largo del puente se
inicia en la parte alta del proyecto. lo que permite que el equipo de sof\ware exami
ne el contexto del trabajo de software que ser realizado; las necesidades especficas que el diseo y la construccin deben abordar, las prioridades que indican el
orden en el que se debe completar el trabajo; y la infonnaci6n1 las funciones y los
comportamientos que tendrn un impacto profundo en el diseno resultante
La ingeniera de requisitos proporciona el mecanismo apropiado para entender lo
que el cliente quiere, analizar las necesidades, evaluar la factibilidad. negociar una
solucin razonable, especificar la solucin sin ambigedades, validar la especificacin, y administrar los requisitos conforme stos se transforman en un sistema operacional [THA97). El proceso de la ingeniera de requisitos se lleva a cabo a travs de
siete distintas funciones: inicio, obtencin, elaboracin, negociacin, especificacin,
validacin y gestin.
Resulta importante destacar que algunas de estas funciones de la ingeniera de
requisitos ocurren en paralelo y que todas deben adaptarse a las necesidades del
proyecto. Todas estn dirigidas a definir lo que el cliente quiere. y todas sirven para
establecer una base slida respecto del diseo y la construccin de lo que obtendr
el cliente.
11 ilKIWIIII~
PARTE DOS PRCTICA DE LA INGENIERA DEL SOFJWARE
158
7.2.1
Inicio
Cmo se inicia un proyecto de software? Es un evento aislado que se convierte e:el catalizador para un nuevo sistema o producto basado en computadora? O la
necesidad evoluciona con el tiempo? No existen respuestas definitivas para estas
preguntas.
"Par lo genertJI, las semi1as de los desastres ms importantes ensoftware se siembra! en los primeros 1nls -
desd. el comienzo del proyecto.'
En algunos casos, una conversacin informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniera del software. Pero en general, la mayora
de los proyectos comienza cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. Los participantes de la comunidad de
negocios (es decir, los gerentes, gente de mercadotecnia, gerentes de producto) definen un caso de negocios para la idea, tratan de identificar la amplitud y profundidad
del mercado, hacen un anlisis preliminar de factibilidad, e identifican una descripcin
funcional del mbito del proyecto. Toda esta informacin est sujeta a cambios (una
situacin probable), pero es suficiente para suscitar conversaciones con la organizacin de ingeniera del software. 2
Al inicio3 del proyecto los ingenieros de software hacen una serie de preguntas
libres de contexto, las cuales se exponen en la seccin 7.3.4. El objetivo es establecer una comprensin bsica del problema, las personas que quieren una solucin, la
naturaleza de la solucin que se desea, y la efectividad de la comunicacin preliminar entre el cliente y el desarrollador.
7 .2.2 Obtencin
Por qv
es ctdcil
En verdad parece muy simple preguntarle al cliente, a los usuarios y otros interesados cules son los objetivos para el sistema o producto, qu es lo que se debe lograr,
de qu forma el producto satisface las necesidades del negocio y por ltim o cmo se
utilizar el sistema o producto da a da. Pero no es simple, es muy dificil.
Christel y Kang [CRI92] identifican una serie de problemas que ayudan a entender
por qu es dificil la obtencin de requisitos:
Problemas de mbito. El lmite del sistema est mal definido o los
Cllllpl'ender con
clientes/usuarios especifican detalles tcnicos innecesarios que pueden

confundir, en lugar de clarificar, los objetivos generales del sistema.
dlrillod lo que
.-,e el et.ente?
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
ptulo6)
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 captulo.
CAPTULO 7 INGENIERA DE REQUISITOS
159
Problemas de comprensin. Los clientes/usuarios no estn seguros por

completo de qu es lo que se necesita, comprenden poco acerca de las capacidades y limitaciones de su ambiente de cmputo, no comprenden del todo
el dominio del problema, tienen dificultades al comunicar necesidades al
ingeniero de sistemas, omiten informacin que consideran "obvia", especifican requisitos que chocan con las necesidades de otros clientes/usuarios, o
especifican requisitos ambiguos o inestables.
Problemas de volatilidad. Los problemas cambian conforme transcurre el

tiempo.
Para ayudar a superar estos problemas, los ingenieros de requisitos deben realizar
en forma organizada la actividad de recopilacin de requisitos.
7 .2.3 Elaboracin
La informacin conseguida con el cliente durante el inicio y la obtencin se expande y se refina durante la elaboradn. Esta actividad de la ingeniera de requisitos se
enfoca en el desarrollo de un modelo tcnico refinado de las funciones, caractersticas y restricciones del software.
La elaboracin es una accin del modelado del anlisis (captulo 8) y se compone de una serie de tareas de modelado y refinamiento. La elaboracin se conduce
mediante la creacin y el refinamiento de escenarios del usuario que describen la

forma en que el usuario final (y otros actores) interactuarn con el sistema. Cada
escenario del usuario se analiza para obtener clases ele anAlisis: entidades del dominio de negocios visibles para el usuario final. Se definen los atributos de cada clase
de anlisis y se identifican los seNicios4 que requiere cada clase. Se identifican las
relaciones y la colaboracin entre las clases y se produce una variedad de <liagramas
de UML complementarios.
El resultado final de la elaboracin es un modelo de anlisis que define el dominio de la informacin, las funciones y el componamiento del problema.
Modelado del anlisis

Supngase por un momento que es necesario
especificar todos los requisitos poro la
-r:xio. de una cocino gourmet. Se conocen las
5
n
-~iries de la solo, la ubicacin de los puertos y

y el espacio disponible en la pored.
~ especificar por completo lo que se va a construir
hacer una lista de todos los gabinetes y
oplicociones (su fabricante, modelo, nmero y

dimensiones). Despus se podran especificar las
contraportes (laminado, granito, etctera), uniones de
plomera, pisos y los techos. Esta lista podra constituir uno
espec.ificocin til, pero no proporciona un modelo de lo
que se desea. Para completar el modelo se podra crear
una representocin tridimensional que muestre la posicin
4 Tambin se utilizan los trminos operaciones y mtodos.
1111
PARTE DOS
PRCTICA DE LA INGENIER!A DEL SOFTWARE
de los gabinetes y aplicaciones y los relaciones entre ellos.

A pomr del modelo, sera ms fcil evaluar lo eficiencia
del Hujo de lrobajo (un requisito poro todos las cocines), y
lo apariencia esttica del saln (un requisito personal, pero
muy importante.)
Los modelos de anlisis se construyen por una razn
muy parecida a la del desarrollo de un plano de trabajo o
7 .2.4
fn
una negociacin
e!Koz na debe haber

gaoodor ni perdedor.
Ambos portes ganan
porque se soliifico un
'/rato con el que los
dos pueden vivir.
1IUIIJIIJ
una representacin tridimensional poro el caso de la

cocino. Es imporiante evaluar codo componente del
sistema en relacin con los otros. Esto permite determinar
cmo encojan los requisitos en esto visin y evaluar lo
esttico del sistema como ha sido concebido.
Negociacin
Dados los recursos limitados del negocio, no resulta inusual que los clientes y usuarios pidan ms de lo que se puede lograr. Tambin es relativamente comn que diferentes clientes o usuarios propongan requisitos que entran en conflicto entre s a.
argumentar que su versin es "esencial para nuestras necesidades especiales".
El ingeniero de requisitos debe conciliar estos conflictos por medio de un proceso de negociacin. Se pide a los clientes. usuarios y otros interesados que ordener
sus requisitos y despus discutan los conflictos relacionados con la prioridad. Se
identifican y analizan los riesgos asociados con cada requisito (para obtener ms
detalles vase el captulo 25). Se hacen "estimaciones" preliminares del esfuerzc
requerido para su desarrollo y despus se utilizan para evaluar el impacto de cada
requisito en el costo del proyecto y sobre el tiempo de entrega. Mediante un enfoque
iterativo. los requisitos se eliminan, combinan o modifican de forma que cada parte
alcance cierto grado de satisfaccin.
7 .2 .5
Especificacin
,,-~
En el contexto de los sistemas basados en computadora (y en software), el trminc

especificacin tiene significados diferentes para personas distintas. Una especificacin puede ser un documento escrito, un conjunto de modelos grficos, un modelo
matemtico formal, una coleccin de escenarios de uso, un prototipo o cualquier
combinacin de stos.
lo formalidad y el
"plantilla estndar" [SOM97) argumentan que esto conduce a que los requisitos sean
presentados de una manera ms consistente y por ende ms entendible. Sin embargo, algunas veces es necesario ser flexible mientras se desarrolla una especificacin
Respecto de sistemas grandes el mejor enfoque podra ser un documento escrito que
combinara descripciones en el lenguaje natural y modelos grficos. Por otro lado, en
cuanto a productos o sistemas ms pequeos, podra ser que no se necesite ms que
escenarios de uso, cuando dichos sistemas residan en ambientes tcnicos que se
comprendan bien.
C~VE
formato de uno
especificacin varan
con el tomoo y lo
complejidad del
softwore que se va o
construir.
Algunos sugieren que para una especificacin se debe desarrollar y utilizar una
La especificacin es el producto de trabajo final que genera la ingeniera de requisitos. Sirve como base para las actividades de ingeniera de software subsecuentes.
CAPITULO 7
161
Describe la funcin y el desempeo de un sistema basado en computadora y las restricciones que regirn su desarrollo.
7.2.6 Validacin
La calidad de los productos de trabajo procedentes de la ingenieria de requ1s1tos se
evala durante un paso de validadn. La validacin de requisitos examina la especificacin para asegurar que todos los requisitos de software se han establecido de
manera precisa que se han detectado las inconsistencias, omisiones y errores y que
stos han sido corregidos, y que los productos de trabajo cumplen con los estndares establecidos para el proceso, proyecto y producto.
El mecanismo primario para la validacin de requisitos es la revisin tcnica formal (captulo 26) El equipo de revisin que valida los requisitos incluye ingenieros
de software, clientes, usuarios y otros interesados que examinan la especificacin y
buscan errores en el contenido o la interpretacin, reas que tal vez requieran una
clarificacin, informacin faltante, inconsistencias (que es un problema importante
cuando se desarrollan productos o sistemas grandes). conflictos entre los requisitos,
o requisitos irreales (inalcanzables).
Ltsta de verificacin para la validacin de requisjtos

Con frecuencia resulto til exominar codo
requisito frente o uno serie de pregunto$ en
de lislo de verificocin. Enseguida 5e pr=to un
l-=r:,e-'io subconjunto de len preguntas que deben
J.m requisitos estn establecidas de manero cloro?

~
pueden malinterpretorse?
~ ~te del requisito (por ejemplo, una persono, uno
El requisito es rastreable poro cualquier modelo de

sistema que hoyo sido creado?
tEI requi$ilo es rostrcoblc paro los obetiYos gencrolel
del 5btemo o prodUCIO~
8UICiodo final del requisito ha sida examinada por la

onginol o comporndolo con ello?
ala especificacin esl estructurada de una formo que

conduzco o su comprensin, reerencio y h-oduccin
fcil en productos de trabajo m6s t<:nicos~
~ niq.,,silo
Se ha creodo algn ndice paro la especificacin?
~ i n o un reglamento) est6 identificado? El
El requisito se puede probar? Si es as, se pueden

especificar los pruebas (algunas veces llamodos criterios
de volidocin) poro ejercitar el requisito?
est restringida en trminos cuontitotivos2
~ otros requisitos estn relocionadas con stei

j&lrl registrados de manero dora por medio de una
~ de referencias cruzadas u otro mecanismo:!
j3 rwqv,s,lo violo alguno restriccin del dominio del
Los requisitos asociados con el rendimiento, el

desempeo y las caractersticos operacionales se han
esloblecida de manero cloro? Cules requisitos
perecen ser implcilos2
S2rno2
7 .2 .7
En el captulo 6 se estableci que los requisitos para los sistemas basados en computadoras cambian y que el deseo de cambiarlos persiste durante la vida del sistema.
La gestin de requisitos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios l :;to5 en cull-
1 11
162
1111111
PARTE DOS PRcnCA DE LA INGENIERA DEL SOfiWARE
quier momento mientras se desarrolla el proyecto. 5 Muchas de estas actividades se

idnticas a las actividades de la gestin de la configuracin del software (GCS) q-..
se tratan en el captulo 27.
La gestin de requisitos comienza con la identificacin. Cada requerimiento s.
asigna a un solo identificador. Una vez identificados los requisitos se desarrollan !atablas de rastreabilidad. En la figura 7. l se muestra de manera esquemtica ur
tabla de rastreabilidad, cada una de ellas relaciona los requisitos con uno o mas
aspectos del sistema o de su ambiente. Entre las muchas tablas de rastreabilidac!
posibles estn las siguientes:
Cuando un sistema es
grande y comple;o, lo
Tabla de rastreabilidad de las caracteristicas. Muestra la manera en que le

requisitos se relacionan con las caractersticas del sistema/producto observabl~
para el cliente.
Tabla de rastreabilidad de la fuente. Identifica la fuente de cada requisito.
determinaci6n de las
Tobla de rastreabilidad de dependencia. Indica la forma en que los requisito.
conexiom1s entre los

requisitos f)l}erle ~r
uno toreo redituoble.

Se recomienda el uso
de los toblo~de rastreobilidod poro focilitor un
poco el trobo;o.
estn relacionados entre s.
Tabla de rastreabilidad del subsistema. Establece categoras entre los req~sitos de acuerdo con el(los) subsistema(s) que gobiema(n).
Tabla de rastreabilidad de la interfaz. Muestra la forma en que los requisitc.~
se relacionan con las inteases internas y externas del sistema.
En muchos casos, estas tablas de rastreabilidad se mantienen como parte de la
base de datos de los requisitos de forma que pueda buscrseles con rapidez para
entender cmo el cambio en un requisito afectar diferentes aspectos del sistema
que se construir.
ifrHDi
\ ~
..sistema
. -o su ambiente
. ..
pecto- especfico
del
Tabla
genrica de
rastreabWdad.
IA01'
Req
Aii
- .......
1
R01
R02
IV""
IV""
lv"
y"'
...,,,
...,,, lv""
ROS
...,,,
...,,,IV""
v'
Rnn
,...,,, ,...,,,
R03
804
..
...,,,
y"'
La gestin fonnal de requisitos se inicia slo para proyectos grandes, los cuales tienen cientos de requisitos identificables. En los proyectos pequeos esta funcin de la ingeniera de requisitos es bastante menos fonnal.
CAPTULO 7
163
Ingeniea de requisitos
Objetivo: las herramientas de lo ingeniera
de requisitos ayudan en lo recopilacin,
.:modo, gestin y validacin de requisitos.
.-.1a1-nKa : La mecnica de los herramientas vara. Por lo

, kis herramientas de lo ingeniera de requisitos
~ uno variedad de modelos grficos (por
, UML) que muestran los aspectos de informacin,
-.::i::JCl!"'amiento y comportamiento de un sistema. Estos
os forman la base poro todas las otros actividades
e f"O(eSO del software.
1m11mientas representativas6
lic Systems Guide, lnc. ha preporodo una lista
1-=XXlolefliente completa de herramientas poro la
.-::1!!"'-,o de requisitos, sta se puede encontrar en
www.systemsguild.com/Guildsite/Robs/retools.
modelado de requisitos se estudia en el captulo 8.
bn-triientas que se presentan a continuacin se
en lo gestin de requisitos.
desarrollado por Cybemetic lntelligence GMBH
eosy-rm.com), construye un diccionario/glosorio
especfico del proyecto que contiene descripciones y

atributos detollodas de los requisitos.
OnYourMarlc Pro, desarrollado por OmniVisto
(www.omni-vista.com), construye una base de datos de
los requisitos, establece relaciones entre stos, y
permite a los usuarios analizar la relacin entre los
requisitos y los calendarios/costos.
Rotional RequisitePro, desarrollado por Rational Software
(www.rational.com), permite a los usuarios desarrollar
una base de datos de los requisitos, represento las
relociones entre stos y los organiza, prioriza y rastrea.
RTM, desarrollado por lntegrated Chipware
(www.chipware.com), es una herramienta poro la
descripcin y rostreobilidod de requisitos que tambin
soporto ciertos aspectos del control del cambio y
gestin de los pruebas.
Se debe hacer notar que muchos toreas de la gestin de

requisitos se pueden realizar con una simple hoja de
clculo o un sistema pequeo poro el manejo de bases
de datos.
En un escenario ideal, los clientes y los ingenieros de software trabajan juntos en el

mismo equipo. 7 En tales casos, la ingeniera de requisitos se trata slo de guiar conversaciones significativas con colegas que son miembros bien conocidos del equipo.
Sin embargo, en la realidad a menudo es bastante diferente.
Los clientes pueden estar en una ciudad o pas diferente, pueden tener :slo una
idea vaga de lo que se requiere, tal vez tengan opiniones conflictivas acerca del sistema que se construir, quiz su conocimiento tcnico sea limitado y tengan un tiempo
limitado para interactuar con el ingeniero de requisitos. Ninguna de estas situaciones
es deseable, pero son muy comunes, y el equipo de software con frecuencia se ve obligado a trabajar dentro de las restricciones que impone esta situacin.
En las secciones siguientes se examinan los pasos requeridos para iniciar la ingeniera de requisitos; es decir, para comenzar un proyecto de forma que se mantenga
en movimiento hacia una solucin exitosa.
Las herramientas mencionadas aqu son una muestra dentro de esta categora. En la mayoria de los
casos los nombres estn registrados por sus respectivos desarrolladores.
Este enfoque se recomienda para todos los proyectos y es una parte integral de la filosofa para el
desarrollo gil de software.
1,Lillil'
164
PARTE DOS
PRCTICA DE LA INGENIERA DEL SOF1WARE
7.3.1 Identificacin de los interesados

Sommerville y Sawyer [S0M97] definen a los interesados como "todos aquellos Q'
se benefician en una fonna directa o indirecta del sistema que est en desarroll....
Un interesodo es
cualquiera que
participo en formo
directo en el sistema
que se vo odesorrollor
u obtiene beneficios de
ste.
Ya se ha identificado a los sospechosos usuales: gerentes de operaciones de neg:

cios, gerentes de producto, gente de mercadotecnia, clientes internos y extem...
usuarios finales, consultores, ingenieros de producto, ingenieros de software, ing.:
nieros de soporte
y mantenimiento y otros. cada interesado tiene una visin di:.:
rente del sistema, obtiene beneficios diferentes cuando ste se desarrolla de mane:--exitosa, y est abierto a diferentes riesgos si el esfuerzo de desarrollo llegara a falla~
En el inicio el ingeniero de requisitos puede crear una lista de personas que cor
tribuirn durante la obtencin de requisitos (seccin 7.4). La lista inicial crecer cor
fonne se establezca contacto con los interesados, ya que a cada uno de ellos se
preguntar: "COn quin ms piensa que debera hablar?"
7 .3.2 Reconocimiento de mltiples puntos de vista

Debido a que existen muchos clientes diferentes, los requisitos del sistema se expl...
rarn desde diversos puntos de vista. Por ejemplo, el grupo de mercadotecnia esL..;
interesado en funciones y caractersticas que estimulen al mercado potencial, qu~
hagan que el nuevo sistema sea fcil de vender. Los gerentes de negocios estn inte
resados en un grupo de caractersticas que se puedan construir sin rebasar un pre
supuesto y que estn listas para llegar a nichos de mercado definidos. Los usuariC"
finales pueden desear caractersticas con las que estn familiarizados y sean fcile
de aprender y utilizar. Los ingenieros de software quiz estn interesados en funciones que den el soporte de la infraestructura y caractersticas ms accesibles a.
mercado. Los ingenieros de soporte se pueden enfocar en la facilidad de manterumiento del software.
c.i..,. atres ill1eresados en 111G habitocin y pregnteles qu tipo de sistema quieren. fs ,raWile.,. . . .
- -oII5 opilliones difet'entes"
Cada uno de estos componentes (y otros) proporcionarn informacin al procese

de la ingenieria de requisitos. conforme se recopila informacin desde mltiples
puntos de vista, los requisitos que surjan pueden ser inconsistentes o entrar en conflicto con algn otro. El trabajo del ingeniero de requisitos es categorizar toda la
informacin de los interesados (incluidos los requisitos inconsistentes y conflictivos
en una forma que permita a quienes tomen la decisiones elegir un conjunto de requisitos para el sistema que sean consistentes de manera interna.
7.3.3 Trabajo con respecto a la colaboracin

En los captulos previos se ha mencionado que los clientes (y otros interesados
deberan colaborar entre s (evitando peleas insignificantes) y con los profesionales
CAPTULO 7
165
de la ingeniera del software si se desea obtener un sistema exitoso. Pero, cmo se

logra esta colaboracin?
El trabajo del ingeniero de requisitos es identificar reas en comn (es decir, los
requisitos en los que todos los interesados estn de acuerdo) y reas de conflicto o
inconsistencia (esto es, los requisitos solicitados por un interesado que entran en
conflicto con las necesidades de otro). sta es, por supuesto, la ltima categora que
presenta un desafio.
Utilizacin de los 'puntos de prioridad"

requisitos, al mismo tiempo que se entiende
~ i a relativo de todos, es lo utilizacin de
de votacin# basado en puntos de prioridad.
de"esodos reciben lo misma cantidad de puntos
que
pueden *gastarse en cualquier nmero de
Se presento uno listo de requisitos y los
(desde su punto de vista) al asignarle uno o m6s puntos de

prioridad. los puntos asignados no se pueden reutilizar.
Una vez que los puntos de prioridad del interesado se han
ogotodo, dicho persono no puede realizar ninguno otro
accin sobre los requisitos. los puntos totales que asignen
o coda requisito todos los interesados indican la
importancia general de codo requisito.
indican la importancia relativo de cado uno

La colaboracin no significa, necesariamente, que los requisitos se definan por
consenso. En muchos casos, los interesados colaboran al proporcionar su visin de
los requisitos, pero un fuerte "campen de proyecto" (por ejemplo. un gerente de nego-
cios o un tcnico importante) puede tomar la decisin final acerca de cules requisitos se aceptan.
7.3.4 Formulacin de las primeras preguntas

En este captulo se ha destacado que las preguntas formuladas al inicio del proyecto deben ser "libres de contexto" [GAU89J. El primer conjunto de preguntas libres de
contexto se enfoca en el cliente y otros interesados, metas generales y en los beneficios. Por ejemplo, el ingeniero de requisitos podra preguntar:
Quin est detrs de la solicitud de este trabajo?
Quin usar la solucin?
Cul ser el beneficio econmico de una solucin exitosa?
Existe otra fuente para la solucin requerida?
Estas preguntas ayudan a identificar a todos los participantes que tendran inters en el software que ser construido. Adems, estas preguntas identifican el beneficio medible de una implementacin exitosa y las alternativas posibles para personalizar el desarrollo del software.
Es mejor salier algo de las preguntas que todo de los respuestas."
....:.llllllllll
166
PARTE DOS
PRCTICA DE LA INGENJERA DEL SOF1WARE
La siguiente serie de preguntas permite que el equipo de software compre mejor el problema y deja que el cliente exprese sus percepciones acerca de una soi
cin:
Cules son
las pregun
tas que ayudan a
comprender en
forma preliminar
el problema?
Cmo podra caracterizarse un buen resultado generado por una solucin

exitosa?
Cules problemas debera atacar esta solucin?
Podra usted describir o mostrar el ambiente de negocios en el que se
utilizar la solucin?
Los aspectos especiales del desempeo o las restricciones afectarn la forrru:
en que se busque la solucin?
La serie final de preguntas se enfoca en la efectividad de la actividad de comu.cacin en s misma. Gause y Weinberg (GAU89] las llaman las "metapreguntas
proponen la siguiente lista abreviada:
Es usted la persona adecuada para contestar esta pregunta? Sus respuestas
son "oficiales"?
Mis preguntas son relevantes para su problema?
Estoy haciendo demasiadas preguntas?
Alguien ms puede proporcionar informacin adicional?
Debera preguntarle alguna otra cosa?
e que pragunla es un tonto durante cinco minutos; el que no pregunta es un tonto por siempre.*
Estas preguntas (y otras) ayudarn a "romper el hielo" y a iniciar la conversacir"
esencial para la obtencin exitosa. Pero un formato de reunin de pregunta y res
puesta no es un enfoque que haya sido exitoso de manera contundente. De hechc
la sesin de preguntas y respuestas se debe usar slo para el primer encuentro, .
despus se debe reemplazar por un formato de obtencin de requisitos que combine elementos de resolucin de problemas, negociacin y especificacin. En la seccin 7.4 se presenta un enfoque de este tipo.
7,4 AIJEHcrN PI 119Rl$lt91

El formato de pregunta y respuesta descrito en la seccin 7.3.4 es til en la etapa inicial, pero no es un enfoque que haya sido exitoso de manera decisiva para una
obtencin de requisitos ms detallada; de hecho, la sesin de preguntas y respuestas se debe usar slo para el primer encuentro y despus se debe reemplazar por un
formato de obtencin de requisitos que combine elementos de la r~solucin, elaboracin, negociacin y especificacin del problema. En la siguiente seccin se presenta un enfoque de este tipo.
CAPTULO 7
167
INGENIERA DE REQUlSrTOS
7 .4. 1 Recopilacin conjunta de requisitos

Cuando se desea estimular un esfuerzo conjunto y orientado al equipo de recopilacin de requisitos. un equipo de participantes y desarrolladores trabajan juntos para
identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos para la solucin [ZAH90]. 8
Se han propuestos muchos y diferentes enfoques para la recopilacin conjunta de
requisitos. Cada uno utiliza un escenario muy diferente, pero todos aplican alguna
variacin de las siguientes directrices bsicas:
Las reuniones las dirige alguno de los asistentes, ya sea un ingeniero de
C.les
S01 las
ktrices bsicas
pn lnaacabo
software o un cliente (junto con otros participantes interesados).

Se establecen reglas para la preparacin y la participacin.
Se sugiere una agenda que sea tan formal como para cubrir todos los puntos
-naia
importantes, pero tan informal como para estimular el flujo de ideas.
-;.ta de
1 c:in de
Un moderador (puede ser un cliente, un desarrollador o un agente externo)

controla la reunin.
lllfllShS?
Se utiliza un "mecanismo de definicin" (pueden ser hojas de trabajo,

grficos, hojas adheribles, un tablero electrnico, un mensajero electrnico o
un foro virtual)
La meta es identificar el problema, proponer elementos de solucin, negociar
diferentes enfoques y especificar un conjunto de requisitos de solucin preliminares en una atmsfera que conduzca al cumplimiento de la meta.
Para entender mejor el fluJo de los eventos (conforme stos ocurren). se presenta un escenario breve que describe la secuencia de eventos que conducen a la reunin para la recopilacin de requisitos y que ocurren durante la reunin y despus
de sta.
"Dedimmos nuho tien'1)0-lo mayora del esfuerzo del proyecte>- no a lo implemen1aci6n ni a los pruebas, sino a
lnlllr ele de<illir qu es lo que se 'tCI a cons1n!ir!
Briall lowrace
Durante la fase de inicio (seccin 7.3) las preguntas y respuestas bsicas establecen el mbito del problema y la percepcin global de una solucin. Fuera de estas
reuniones iniciales, los participantes escriben una "solicitud de producto" de una o
dos pginas. Se fijan un lugar, una hora y una fecha para la reunin y se selecciona
un moderador. Los miembros del equipo de software y otras organizaciones intere-
A este enfoque se le llama algunas veces tcnica de especificacin facilitada de la aplicacin (FAST
por sus siglas en mgls)
11 lli:IIJ
168
ElffilfifrlM1
desoooilo (OJIUflW
de apliw<iolles OAO,
por SIIS siglos ef1
ingls} es, lllO 1cnklJ

popular p!IJO lo
recophjn de
requisilos. En
www.--
C11111/ wp;.tm
se puede encontror una
bueoo desaipoo de
esto jali(Q,
PARTE DOS PRCTICA DE LA INGENirn!A DEL S0f"IWARE
sadas son invitados a asistir. La solicitud de producto se distribuye a todos los asistentes antes de la fecha de reunin.
Mientras revisa la solicitud de producto en los das previos a la reunin, se pide a
cada asistente hacer una lista de objetos que son parte del ambiente que rodea al sistema, otros objetos que ste producir, y objetos que utiliza para realizar sus funciones. Adems, se le pide a cada asistente que elabore una lista de los servicios
(procesos o funciones} que manipulan o interactan con los objetos. Por ltimo
tambin se preparan listas de las restricciones (por ejemplo, costo, tamao, reglas
del negocio) y de los criterios de rendimiento (por ejemplo, velocidad, exactitud). Se
informa a los asistentes que no se espera que las listas sean exhaustivas, sino que
reflejen la percepcin que cada persona tiene del sistema.
Como un ejemplo, 9 considrese el fragmento de un documento previo a la reunin, escrito por una persona de mercadotecnia involucrada en el proyecto de
HogarSegu.ro. Esta persona escribe la siguiente narracin acerca de la funcin de seguridad en el hogar que ser parte de HogarSeguro.
Nuestra investigacin indica que el mercado para los sistemas de administracin del hogar est creciendo a una tasa de 40 por ciento anual. La primera funcin de HogarSeguro
que saquemos al mercado debera ser la funcin de seguridad en el hogar. La mayora de
la gente est familiarizada con los "sistemas de alanna", por lo que dicha funcin sera fcil de vender.
La funcin de seguridad en el hogar protegerla contra o reconocera una variedad de
"situaciones" indeseables como una entrada ilegal, fuego, inundaciones, niveles de monxido de carbono y otras. Utilizar nuestros sensores inalmbricos para detectar cada situacin, el usuario podr programarla
y llamar
por telfono automticamente a una
oficina de monitoreo cuando detecte alguna situacin.
Si un sistema a
producto servir6 o
muchos usuarios se
debe tener lo
completa seguridad de
que los requisitos se
obtienen de una
muestro representotivo de los usuarios. Si
slo uno de los
usuarios define todos
los requisitos, el
riesgo de rechazo es
o/to.
En realidad, otros podran contribuir a este relato durante la reunin para la recopilacin de requisitos, y mucha ms informacin estara disponible. Pero aun con
informacin adicional, la ambigedad podra estar presente, es probable que existieran omisiones y podran ocurrir errores. Por ahora, la "descripcin funcional
anterior ser suficiente.
El equipo de recopilacin de requisitos lo componen representantes de los departamentos de mercadotecnia, de ingeniera de hardware y software y de manufactura. Se utilizar un moderador externo.
cada persona desarrolla las listas previamente descritas. Los objetos descritos
para HogarSeguro podran incluir el panel de control, los detectores de humo, los
sensores en puertas y ventanas, los detectores de movimiento, una alarma, un evento (cuando algn sensor se active}. una pantalla, una PC, nmeros telefnicos, una
9. El ejemplo de HogarSeguro (con extensiones y variaciones) se utiliza para ilustrar mtodos importantes de la ingeniera del software en muchos de los captulos que siguen. como ejercicio, sera til
realizar una reunin para la recopilacin de requisitos propia y desarrollar una sere de listas para
sta.
CAPTULO 7
169
llamada telefnica y otros. La lista de servicios podra incluir la configuracin del sistema, la colocacin de la alarma, el monitoreo de sensores, la marcacin telefnica,
la programacin del panel de control y la lectura de pantalla (obsrvese que los servicios actan sobre los objetos). De una manera similar, cada asistente elaborar listas de restricciones (por ejemplo, el sistema debe reconocer cuando los sensores no
estn en funcionamiento, debe ser amigable para el usuario, debe tener una interfaz
directa con la lnea telefnica) y criterios de rendimiento (por ejemplo, el evento de
un sensor debe ser reconocido en un segundo o menos; se debe implementar un
esquema para la prioridad de los eventos).
ta liedies no dejan de existir slo porque son ignorados."
Cuando se inicia la reunin para la recopilacin de documentos, el primer tpico

que se trata es la nesesidad y la justificacin para el nuevo producto, todos deben
estar de acuerdo en que la necesidad del producto se justifica. Una vez establecido
el acuerdo, cada participante presenta sus listas para examinarlas. Las listas pueden
fijarse en las paredes del saln usando hojas grandes de papel, pegarse en los muros
mediante hojas adhesivas o escribirse en un pizarrn. De manera alternativa, las listas pueden haber sido colocadas en un boletn electrnico, en un sitio Web interno,
o situadas dentro de un ambiente de foro de discusin (chat room) para revisarlas
antes de la reunin. En forma ideal, cada asunto en la lista debe permitir manipularse por separado para que las listas se puedan combinar, los asuntos puedan
borrarse y se les puedan realizar adiciones. En esta etapa la crtica y el debate estn
estrictamente prohibidos.
Despus de que las listas individuales sobre el rea de un tpico se hayan presentado, el grupo crea una lista combinada. Dicha lista elimina los asuntos redundantes, incorpora ideas nuevas surgidas durante el debate, pero no borra nada.
Despus de haberse creado las listas combinadas para todas las reas de los distintos tpicos, el moderador coordina el debate. La lista combinada se reduce, se
incrementa o replantea para reflejar de manera apropiada el producto/sistema que
se desarrollar. El objetivo es desarrollar una lista consensada en el rea de cada
tpico (objetos, servicios, restricciones y rendimiento). Despus dichas listas se integran para la accin posterior.
Cuando se completan las listas consesadas, el equipo se divide en subequipos
menores; cada uno trabaja para desarrollar miniespecijicaciones para uno o ms
asuntos de cada una de las listas. ' cada miniespecificacin es una explicacin concisa de la palabra o frase contenida en la lista. Por ejemplo, la miniespecificacin
para el objeto Panel de control de HogarSeguro podra ser:
1o 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.
1 :IKil
170
PARTE DOS
PRCTICA DE LA INGENirnA DEL SOFTWARE
El Panel de control 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 subequipo presenta sus miniespecificaciones a todos los asistent~

para comentarlas. Se realizan las adiciones, anulaciones y elaboraciones poster:
res. En algunos casos, el desarrollo de las miniespecificaciones descubrir nue\:
requisitos de objetos. servicios, restricciones y rendimiento que se agregarn a
listas originales. Durante los debates el equipo encontrar algn asunto que ..
pueda resolverse durante la reunin. Se mantendr una lista de asuntos pendieni..;;
para que despus se pueda actuar sobre estas ideas.
Despus de completar las miniespecificaciones, cada asistente hace una lista ..
criterios de validacin para el producto/ sistema y la presenta al equipo. Entonces
crea una lista consensada de criterios de validacin. Por ltimo, uno o ms partic
pantes (o agentes externos) reciben el encargo de escribir las especificaciones cor
pletas mediante el uso de todas los asuntos tratados en la reunin.
Jamie: S, tanto tcnicas oomo . . . . .

Rep.....,tante ele pnl clucd6ffl
significa?
ti
Jamie: Debemos estar seguros . . .

no puedo entrar en el sistama, dewtn'4
cosa o hacer oigo pec,r. Gran parta d. fo
responsabi1iclod recae en nosotros.
Doug: Muy cierro.
nec:esilamo$-
Mercadotecnia: Pero aun m

conectividacl por Internet... slo osegNna. ~
que cualquier inlrvso entre.
Ed: Es ms fcil decirfo que hocedo y ..
..__.. ~dotecnia: Desde nuestro

~. , liw abarco todo k, funcin.
~ ~ mencion que los usuarios queran toda
lo: ~ldidad de HogarSeguro accesible por Internet?
&o~
lo funcin de segundad en el hogar, no?
h Un 1 .....c.tD1:ecnia: S, 415 cormcto...
fan:hmm qu&agn,gar eso funciono~dod y los objetos
apropiodos.
Fodllladan t&o tambin agrega algunos

~
Moderador (lntwrvrnpiendot; No ..........
este awnto o hora . Anclemos que VIIO ~
debe realizarse y continuemos..
(Ooug, que lleva el regislro de lo reuain, bQr;'ll~

anoloc:in correspondiente.)
Moderador: Sien1o que an hay mm coeos por

considerar aqu
(8 grupo utiliza los siguientes 45 minuto& ei, niiNery

expandir los detalles de la funcin ele segurictad an ti
h~ r.)
CAPTULO 7
INGENIERA DE REQUJSITOS
171
7 .4 .2 Despliegue de la funcin de calidad

El despliegue de la funcin de calidad (QFD, por sus siglas en ingls) es una tcnica
que traduce las necesidades del cliente en requisitos tcnicos para el software. El
QFD "se concentra en aumentar la satisfaccin del cliente desde el proceso de la
ingeniera del software [ZUL92]." Para lograr lo anterior, el QFD resalta una comprensin de lo que es valioso para el cliente y despus despliega estos valores durante el proceso de ingeniera. El QFD identifica tres tipos de requisitos fZUL92]:
Requisitos normales. Reflejan los objetivos y metas establecidos para un producto o sistema durante las reuniones con el cliente. Si estos requisitos estn presentes, el cliente estar satisfecho. Algunos ejemplos de requisitos normales podran ser los tipos de grficos en pantalla, las funciones especficas del sistema, y los
niveles de rendimiento solicitados.
Requisitos esperados. Estn implcitos en el producto o sistema y pueden parecer
tan obvios, aunque son fundamentales, que el cliente no los establece de manera explcita. Su ausencia causara una insatisfaccin significativa. Algunos ejemplos de requisitos esperados son la facilidad de la interaccin humano/mquina, correccin y confiabilidad operacional general y facilidad en la instalacin del software.
Requisitos estimulantes. Reflejan las caractersticas que van ms all de las
expectativas del cliente y que prueban ser muy satisfactorias cuando estn presentes. Por ejemplo, un software procesador de palabras se solcita con caractersticas
estndar. El producto entregado contiene varias capacidades de configuracin de
pgina que son bastante satisfactorias e inesperadas.
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 requisitos. En los prrafos siguientes se presenta una visin general de dichos conceptos
(adaptados para el software de computadora).
?_..
las expedali,as Wlan, y entre ms lo hocen ms prometen.
"
wa.w,.,,.,
En las reuniones con el cliente, la.funcin de despliegue se aplica para determinar

el valor de cada funcin que se requiere para el sistema. El despliegue de la informacin identifica los datos de los objetos y eventos que debe consumir y producir el sistema. Los datos estn ligados a las funciones. Por ltimo, el despliegue de tareas examina el comportamiento del sistema o producto dentro del contexto de su entorno.
El anlisis de valor se realiza para determinar la prioridad relativa de los requisitos
determinados durante cada uno de los tres despliegues.
El QFD utiliza entrevistas y observacin del cliente, sondeos y exploracin de los
datos histricos (por ejemplo, los reportes de problemas) como datos crudos para la
actividad de recopilacin de requisitos. Despus, estos datos se traducen en una
n1
11
PARTE DOS
172
,11:111
PRAcnCA DE LA INGENIERtA DEL SOfTWARE
tabla de requisitos -llamada la tabla de la voz del cliente- que se revisa con el cliente.
Una variedad de diagramas, matnces y mtodos de evaluacin se utilizan para obtener
los requisitos esperados y tratar de conseguir los requisitos estimulantes [BOS91].
7 .4.3 Escenarios del usuario

Conforme se recopilan los requisitos se comienza a materializar una visin general
de las funciones y caracteristicas del sistema. Sin embargo, resulta dificil continu...r
con actividades de ingeniera del software ms tcnicas mientras el equipo de software no entienda la manera en que las distintas clases de usuarios finales aplicar!!
estas funciones y caractersticas Para lograrlo, los desarrolladores y usuarios pueden crear un conjunto de escenarios que identifican una cadena de uso para el SIStema que se va a construir. 1..05 escenarios. llamados con frecuencia casos de us.:r
DAC92J, proporcionan una descnpcin de cmo se usar el sistema. Los casos de
uso se examinan con un mayor detalle en la seccin 7.5.

HOGARSEGURO
Desarrollo de un escenario de uso prellmlnar
Podamos hoc.io de un par de fonnm,
ah.a ... SJUIDfo manllner los cosos
1:~-........
, 11111..S..:a Dinos (y apunlo o uno persono de
o6mo visualims el occeso ol sislema.
tacnia:
-~1
Humm , bueoo, es lo
tlllMea fuera de c:ma y tuviera que dejar a
.._ digamos uno penona de t.mpiezo o un
...,. il,w quien no lendrio el cdigo de
CAPTULO 7 INGENIERA DE REQUISITOS
~ una imagen del panel de control del
-.,ridad. jui,to con una lisio de 10$ funciones

rwabar. aclMJr' el sislemo, desoctivor el
~ uno o ms sensores. Supongo que
fillltnitifffle RICIOfliguror las zonas de
yollQI cosasaimo $a, pero no esloy seguro.
173
(Mientras lo persona de mercadc*tc:nia a>ntino
hablando, Ooug loma las n o t a s ~ ~

notas fom10n la base para el primer caso dltvso
informal. De manera aflernotiva, se lepudohablt
pedido a la persona de mercadotecnia que . . . . . . .
escenario, pero esto se hara fuero de l o ~
7 .4.4 Productos de trabajo de la obtencin

Los productos de trabajo producidos como consecuencia de la obtencin de requisitos variar de acuerdo con el tamao del sistema o producto que se vaya a construir.
La mayora de los sistemas incluye los siguientes productos de trabajo:
Un enunciado de necesidad y factibilidad.
un enunciado limitado del mbito del sistema o producto.
una lista de clientes, usuarios y otros interesados que participaron en la
obtencin de requisitos.
Una descripcin del ambiente tcnico del sistema.
Una lista de requisitos (de manera preferente organizados por funcin) y las
restricciones de dominio aplicables a cada uno.
Un conjunto de escenarios de uso que proporcionen un discernimiento de la
utilizacin del sistema o producto en diferentes condiciones de operacin.
Cualesquiera prototipos desarroUados para definir de mejor forma los requisitos.
Cada uno de estos productos de trabajo los revisa toda la gente que ha participado
en la obtencin de requisitos.
En un libro que analiza la manera de escribir casos de uso eficaces, Alistair Cockburn
[COCO I J menciona que "un caso de uso captura un contrato ... (que] describe el comportamiento del sistema en diferentes condiciones mientras ste responde a la peticin de uno de sus usuarios". En esencia, un caso de uso cuenta una historia estilizada de la manera en que un usuario final (el cual desempea uno de varios papeles posibles) interacta con el sistema en un conjunto especfico de circunstancias.
La historia puede ser un texto narrativo, un esquema de tareas o interacciones, una
descripcin basada en una plantilla o una representacin por medio de diagramas.
Sin importar su forma, un caso de uso muestra el software o sistema desde el punto
de vista del usuario final.
El primer paso al escribir un caso de uso consiste en definir el conjunto de "actores" que estarn involucrados en la historia. Los actores son las diferentes personas
11
11
174
.-~,
.........
.......
..........1
wm.., pllde
. . . . . . k,s
-deUSD.
Qu se
necesha
saer para desarrollar un caso de

ase eficaz?
PARTE DOS
111a:1~111 ,
PRCTICA DE LA INGENIERA DEL SOFTWARE
(o dispositivos) que utilizan el sistema o producto dentro del contexto de la funcioy el comportamiento que se describir. Los actores representan los papeles que jut
gan las personas (o dispositivos) conforme el sistema opera. Definido de una mane
ra ms formal, un actor es algn elemento que se comunica con el sistema o pre
dueto y que es externo al sistema en s mismo. Cada actor tiene una o ms metas
cuando utiliza el sistema.
Es importante sealar que un actor y un usuario final no son necesariamente
mismo. Un usuario tipico puede desempear varios papeles al usar un sistema
mientras que un actor representa una clase de entidad externa (con frecuencia, per
no siempre, una persona) que desempea slo un papel en el contexto del caso c1t
uso. Como un ejemplo, considrese al operador de una mquina (un usuario) qlk
interacta con la computadora de control para una clula de manufactura que cor
tiene varios robots y mquinas de control numrico. Despus de la revisin cuidadosa de los requisitos. el software para la computadora de control requiere cuatr
diferentes modos (actores) para su interaccin: modo de programacin, modo de
prueba. modo de monitoreo y modo de resolucin de problemas. Por lo tanto, St
pueden definir cuatro actores: el programador, el que realiza las pruebas, el que
monitorea y el que resuelve los problemas. En algunos casos el operador de la
mquina puede desempear todos estos papeles. En otras situaciones, son personas
diferentes las que pueden desempear el papel de cada actor.
Como la obtencin de requisitos es una actividad evolutiva, no todos los actores
se identifican durante la primera iteracin. Durante sta es posible identificar los
actores primarios [JAC92J, mientras que los actores secundarios se identifican conforme se aprende ms acerca del sistema. Los actores primarios interactan para
lograr la funcin requerida del sistema y obtienen el beneficio que se espera de ste
Ellos trabajan de manera directa y frecuente con el software. Los actores secundarios dan soporte al sistema de manera que los actores primarios puedan hacer su trabajo.
Ya identificados los actores pueden desarrollarse los casos de uso. Jacobson
[JAC92J sugiere varias preguntas 1 que se deberan contestar mediante un caso de
uso.
Quin(es) es(son) el(los) actor(es) primario(s)?
Cules son las metas del actor?
Cules son las condiciones previas que deben existir antes de comenzar la
historia?
Cules son las tareas o funciones principales que realiza el actor?
Cules excepciones podran considerarse mientras se describe la historia?
Cules son las variaciones posibles en la interaccin del actor?
11 Las preguntas de Jacobson se han extendido para proporcionar una visin ms completa del contenido del caso de uso.
CAPTULO 7
175
Cul es la informacin del sistema que el actor adquirir, producir o

cambiar?
El actor tendr que informar al sistema acerca de cambios en el medio
ambiente externo?
Cul es la informacin que el actor desea del sistema?
El actor quiere ser informado acerca de cambios inesperados?
Como se recordar, los requisitos bsicos de HogarSeguro definen tres actores: el
propietario de la casa (un usuario}, un administrador de la configuracin

(probablemente la misma persona que el propietario, pero en una funcin diferente), los sensores (dispositivos agregados al sistema}, y el subsistema de monitoreo (la estacin central que monitorea la funcin de seguridad en el hogar donde
est instalado HogarSeguro). Para los propsitos de este ejemplo slo se considera
al actor propietario. ste interacta con la funcin de seguridad en el hogar en diferentes formas mediante el uso el panel de control de la alarma o una PC:
Ingresa una contrasea para permitir todas las dems interacciones.
Indaga acerca del estatus de una zona de seguridad.
Indaga acerca del estatus de un sensor.
Presiona el botn de pnico en caso de emergencia.
Activa/desactiva el sistema de seguridad.
Si se considera la situacin en la cual el propietario utiliza el panel de control, el caso
de uso bsico para la activacin del sistema se presenta de la siguiente manera: 12
HogarSeguro
,....
rn
solida
en casa
instante
desviacin
no lisio
U/
alarma
verificar
fuego
'\
/
activado
encendido
o o
12 Ntese que este caso de uso difiere de la situacin en la cual se entra en el sistema a travs de Internet. En este caso, la interaccin se lleva a cabo por medio del panel de control. el acceso es diferente que cuando se utiliza una PC.
111111111! 11
176
PARTE DOS
PRCTICA DE LA INGENJF:RA DEL SOF'TWARE
l. 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 fisica puertas y ventanas 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 contrasea se compara con la clave almacenada en el sistema. Si la contrasea es incorrecta, 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 caso de uso bsico presenta una historia de alto nivel que describe la interaccir
entre el actor y el sistema.
En muchas ocasiones, los casos de uso tienen una mayor elaboracin para proporcionar ms detalles acerca de la interaccin. Por ejemplo, Cockbum [COCO!
sugiere la siguiente plantilla para las descripciones detalladas de los casos de uso
caso de uso:
(oo frewendo, los
rnsos de uso se
esaiben de manero
,::formol. Sin
embargo, se recr>miendo el uso de lo
Propietario de la casa.
Meta en el contexto:
Establecer el sistema para monitorear los sensores

cuando el propietario salga de la casa o permanezca dentro ella.
Condiciones previas:
El sistema ha sido programado para una contrasea y reconocer diferentes sensores.
PJ11tillo mostrado
Activador:
oquf poro asegurar

que se consideren
Escenario:
lodos los ospectvs

dove.
Inicio de monitoreo
Actor primario:
El propietario decide "iniciar" el sistema, es decir,

encender las funciones de alarma.
l. 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 operacin.
Excepciones:
1. El panel de control no est listo: el propietario verifica todos los sensores para determinar cules estn abiertos; los cierra.
2. La contrasea es incorrecta (el panel de control emite un sonido): el propietario introduce de nuevo la contrasea correcta.
3. La contrasea no es reconocida: debe contactarse el subsistema de monitoreo y respuesta 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.
CAPTULO 7
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.
Prioridad:
Esencial, debe implementarse.
Disponible desde:
El primer incremento.
Frecuencia de uso:
Muchas veces al da.
canal hacia el actor:
Actores secundarios:
Tcnicos de soporte, sensores.
travs de la inteaz del panel de control.
canales hacia los actores secundarios:
Tcnico de soporte: lnea telefnica.

sensores: inteaces almbricas e inalmbricas.
Asuntos pendientes:
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
momento en que presiona la primera tecla'
4. Existe alguna fonna de desactivar el sistema antes de que ste se active en realidad?
Los casos de uso para las otras interacciones del propietario se desarrollaran de
una manera similar. Es importante sealar que cada caso de uso debe revisarse con
cuidado. Si algn elemento de la interaccin es ambiguo, existe la posibilidad de que
una revisin del caso de uso descubra el problema.
de un tJ.lagrama de alto nivel para un QUO

Jamie: Apenas estoy cx:wnenz.ai,do"nolocin del UML Eritonaa, tia~
el hogar lo ~ la cojo grande
su interior~ 2Y los volos representan lili8
que escribimos en ~
Moderaclol. S. y los figu,m P8QCldCl5.
odol'EI$; es decir, las peraonas o (;OIQI ~
con el sistema segn se describe en ef CCIIO
y utilic el cuadro eliqlllado pcw
m1:n1
111 lili:ILIW
PARTE DOS
178
PRCilCA DE LA INGENTERA DEL SOFTWARE
Y"mod: De ocuen:lo, entooces lienemos narrativos de

casos de uso para coda uno de los volos. Necesitomos
desarrollar narrativas ms detallados con bose en
plantillas, He ledo ocet'CO de ellas.
Ma deradori Proboblemente, pero eso puede esperar
hoslo que hoyomos consideido otros funciones de
Persona de mercaclolecnia: EspllWl, he..,_

viendo esle diogramo, y de repen1e me di cuenlQ qvt
hemos olvidado oigo.
Moderador: De Y e ~ tGN es lo que oMdamaft

(la reunin contina)
HogarSegvro.
:p.
Diagrama de
caso de uso
para la
funcin de
seguridad en
el hogar de
HogarSeguro.
ensores
Desarrollo de casos de uso

Objetivo: Ayudo en el desorrollo de cosos de
uso al proporcionar plantillas que slo
requieren el llenado de espacios en blanco, poro as crear
casos de uso eficaces. La mayora de las funcionalidades
poro los casos de uso estn incluidas en un conjunto de
funciones ms amplio para la ingeniera de requisitos.
Cleor Requrement Workbench, desorrollodo por LiveSpecs

Software (www.livespecs.com), proporciono soporte
automatizado para la creacin y evaluacin de casos
de uso, as como una variedad de otros funciones poro
la ingeniera de requisitos.
La vasta mayora de las herramientas para el modelado

del anlisis, bosodas en UML, proporcionan soporte
grfico y en texto para el desarrollo y modelado de
casos de uso.
Obects by Design, una fuente poro herramientas de UML

(www.objectsbydesign.com/tools/umltools_byCompany
.html) proporciona vnculos completos pora conocer
herramientas de este tipo.
En UseCases.org (www.usecases.org) se puede encontrar
una variedad de plantillas para desarrollar casos de
uso, as como una bose de datos poro soportarlos.
13 Las herramientas mencionadas aqu son una muestra de esta categora. En la mayora de los casos
los nombres estn registrados por sus respectivos desarrolladores.
CAPTULO 7
179
El objetivo del modelo de anlisis es descnbir los dominios requeridos de informacin, funcionamiento y comportamiento para un sistema basado en computadoras.
El modelo cambia en forma dinmica conforme los ingenieros de software aprenden
ms acerca del sistema que se va a construir y los interesados entienden mejor lo
que necesitan. Por esta razn el modelo de anlisis es una representacin de los
requisitos en un momento determinado, por lo que se espera que ste cambie.
Conforme el modelo de anlisis evoluciona, ciertos elementos se volvern relativamente estables. por lo que proporcionarn una base slida para las tareas de diseo
que siguen. Sin embargo, otros elementos del modelo pueden ser ms voltiles, lo que
indicar que el cliente an no entiende por completo los requisitos para el sistema.
El modelo de anlisis y los mtodos utilizados para construirlo se describen con
detalle en el captulo 8. En las secciones siguientes se presenta una breve visin
general.
7.6.l
Elementos del modelo de anlisis
Existen muchas maneras de buscar los requisitos para un sistema basado en computadora. Algunas personas involucradas con el software dicen que lo mejor es seleccionar un modo de representacin (por ejemplo, el caso de uso) y aplicarlo sin tomar
en cuenta todos los modos restantes. Otros profesionales creen que resulta valioso
utilizar varios modos de representacin para mostrar el modelo de anlisis. Las diferentes formas de representacin obligan al equipo de software a considerar los
requisitos desde distintos puntos de vista, un enfoque que tiene mayores probabilidades de descubrir omisiones, inconsistencias y ambigedades.
Los elementos especficos del modelo de anlisis los determina el mtodo de
modelado que se utilice (captulo 8). Sin embargo, existe un conjunto de elementos
genricos comn a la mayora de los modelos de anlisis:
Elementos basados en escenarios. El sistema se describe, desde el punto de

vista del usuario, por medio de un enfoque basado en escenarios. Por ejemplo. los
casos de uso bsicos y sus correspondientes diagramas de caso de uso (figura 7 .3)
5inve es una buena

aa iwolucror alos
czesodos. Uno de
b nejores formas de
kcerfo es pedirle o
~ IHIO que elabore
c:sos de uso que
d&ribon la forma en
.;..e se utilizar el
s:ftwure.
evolucionan para convertirse en casos de uso ms elaborados basados en plantillas.

Los elementos del modelo de anlisis basados en escenarios con frecuencia son los
primeros que se desarrollan durante la elaboracin del modelo. Por tal motivo. sirven como una entrada para la creacin de otros elementos de modelado.
Un enfoque algo diferente dentro del modelado basado en escenarios muestra las
actividades o funciones que han sido definidas como parte de la tarea de obtencin
de requisitos. Estas funciones existen dentro de un contexto de procesamiento. Esto
es, la secuencia de actividades (tambin se pueden utilizar los trminos funciones u
operaciones) que describe el procesamiento dentro de un contexto limitado se define como parte del modelo de anlisis. Como la mayora de los elementos del mode
lo de anlisis (y otros modelos de la ingeniera de software), las actividades (funcio-
lllillllll 1111
180
PARTE DOS
nes) se pueden representar en muchos grados diferentes de abstraccin. Los modelos en esta categora pueden definirse de manera iterativa. Cada iteracin proporciona detalles adicionales del procesamiento. Como un ejemplo, en la figura 7.4 se
presenta un diagrama de actividad en UML para la obtencin de requisitos. 14 Se
muestran tres niveles de elaboracin.
iihili
Diagramas
de actividad
para la
obtencin de
documentos.
:
Obtener requisitos
.:..pj
Diagrama de
clase para el
Sensor.
Sensor
nombre/id
ti
u~acin
rea
caractersticos
identificar( )
activar()
desactivar()
reconfigurar{ )
14 El diagrama de actividad es bastante parecido al diagrama de !lujo: un diagrama grfico para representar las secuencias y lgica del !lujo de control (capi tulo 11 ).
CAPTIJLO 7
181
Elementos basados en clases. cada escenario de uso implica un conjunto de

"objetos" que se manipula mientras un actor interacta con el sistema. Estos objetos
se clasifican en clases: una coleccin de clases con atributos similares y comportamientos en comn. Por ejemplo, se puede usar un diagrama de clase para mostrar
una clase de Sensor para la funcin de seguridad de HogarSeguro (figura 7.5).
Obsrvese que el diagrama lista los atributos de los sensores (por ejemplo, nombre/id,
tipo) y las operaciones [por ejemplo, identificar( ), habilitar( )] que pueden aplicarse
para modificar dichos atributos. Adems de los diagramas de clase, otros elementos
del modelado del anlisis muestran la forma en que las clases colaboran con uno y
otro y las relaciones e interacciones entre las clases. Lo anterior se examina con
mayor detalle en el captulo 8.
Elementos de comportamiento. El comportamiento de un sistema basado en

computadora puede tener un profundo efecto sobre el diseo que se elija, as como
en el enfoque de implementacin que se aplique. Por lo tanto, el modelo de anlisis
debe proporcionar elementos de modelado que muestren el comportamiento.
El diagrama de estado (captulo 8) es un mtodo para representar el comportamiento de un sistema al mostrar sus estados y los eventos que ocasionan que dicho
sistema cambie de estado. Un estado es cualquier forma de comportamiento observable. Adems, el diagrama de estado indica las acciones (por ejemplo, la activacin
del proceso) que se toman como consecuencia de un evento particular.
Para ilustrar un diagrama de estado, considrese el estado de lectura de comandos de una fotocopiadora de oficina. En la figura 7.6 se presenta el diagrama de estado correspondiente en UML. Un rectngulo redondeado representa un estado. El rectngulo se divide en tres reas: 1) el nombre del estado (por ejemplo, Lectura de
comandos), 2) las variables de est.ado que indican la manera en que el estado se
Lectura
de comandos
Nombre del estodo
EstahJs del s,srema = "listo
Mensaje desplegado ..
introducir cmd*
Variables de estado
Ospk:iy status - steody
Estatus despl
do estable
Entrodo/subsistemas listo
Accin: pedir lo entrado del
usuario en el pone!
Accin: leer lo entrada del
usuario
Accin: interpretar la entrada
del usuario
111111111 11
Actividades de estado
182
PARTE DOS
PRAcnCA DE LA INGENIERA DEL S0f1WARE
HOGARSEGURO
~
Modelado preliminar del comportamiento
11 escenario: Uoo solo de
NUftlGNI. Conlino lo l'9Ul'lin poro lo
recopt1ocion de
Persona de mwc:aclatecnia: EstopaNCII_...,

tcnico, no s si yo puedo ayudar en ella partlt.
......
Mocleraclor: Seguro que puedes.cul ...

comportamiento que obseM:n desde el punll>~
~ Vinod Raman, miembro del equipo de
usuario!
a.---= .lamie Lozar, miembro del equipo de

..-....: Ed Robbins, miembro del equipo de software;
Ooug Miler, miembro del equipo de software; tres
~ de mercodot.cruo; un represeotonte de
inglnieiio del producto; y un moderodor.
la-1ul6m
MI d1rn l I a lamos o punto de tenninor de hablar
OCllRa
de lo funcionalidad de 599uridod en el hogar de
~ Pero antes de hacerlo, me gustara discutir
el mnpor1amienlo de lo funcin
. . . . . -cad..._: Yo no entiendo lo que
Per1011a ele
mercado18aN: Eh... ~ 4
estar monitoreondo los semores, 8lllili'6 i.,..to

comandos del propietario de lo CICIIO Dasfil18ifl*t11
eslot\1$.
Moderador: Ves, t puedes hacedo.
Jamie: Tambin revisor la PC poro delwminar ti _ .

alguno entrado desde ah, por ..nplo "' accmo
bosodo en Internet o inormoci6n de cxinfigunaci6n
~decir ali'! componamiento
U C-J: Es cuondo 1e das al produclo un ' tiempo

..... ti .. QOiiipOl"to mal
Madt adan
explicotles.
._ador
'- explica cil equipo de recopilacin
de
No exac1ameni.. Dervne
. . los cx,nc,eplol bsicos del modelado del

CXllllpOfbniri,.)
(El
Ma clerador: Si eitisle, pero W1W o

despus de lo reunin.
manifiesta a s1 mismo en el mundo exterior, y 3) las actividades de estado que ir

can la forma en que se ingresa al estado (entrada/) y las acciones (do:) invoca
mientras se permanece en el mismo.
Elementos orientados al flujo. Cuando la informacin fluye a travs de un s:

tema basado en computadora sta se transforma El sistema acepta la entrada
una variedad de formas, aplica funciones para transformarla y produce una sali~
tambin en formas diferentes La entrada puede ser una seal de control que trar
m1te un transductor, una serie de nmeros que teclea un operador humano, t.
paquete de informacin transmitido a travs de una liga de red, o un volumin~
archivo de datos obtenido de un almacenamiento secundario. La transformaci1.
puede incluir una sola comparacin lgica, un algoritmo numrico complejo o L
enfoque de interferencia de reglas perteneciente a un sistema experto. La sah1..
puede encender una sola luz de LEO o producir un reporte de 200 pginas. En ef~
to. es posible crear un modelo de flujo para cualquier sistema basado en compi
tadora, sin importar su tamao o complejidad. En el captulo 8 se presenta una exp
sicin ms detallada del modelado del flujo.
CAPTULO 7
183
7.6.2 Patrones de anlisis

Cualquiera que lleve a cabo ingeniera de requisitos en ms de unos cuantos proyectos de software comienza a darse cuenta que ciertas cosas suceden de manera
recurrente en todos los proyectos dentro de un dominio de aplicacin especfico. is
stos pueden denominarse patrones de anlisis [FOW97] y representan algo (por
ejemplo, una clase, una funcin o un comportamiento) dentro del dominio de aplicacin que puede reutilizarse al modelar muchas aplicaciones.
Geyer-Shultz y Hahsler [GEYO I J sugieren dos beneficios que pueden asociarse
con el uso de patrones de anlisis:
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, as 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 confiables para problemas comunes
Los patrones de anlisis se integran al modelo respectivo mediante una referen cia al nombre del patrn. stos tambin se encuentran almacenados en un depsito
para que los ingenieros de requisitos puedan utilizar los servicios de bsqueda y as
encontrarlos y reutilizarlos.
La informacin acerca de un patrn de anlisis se presenta en
dar que tiene la siguiente forma[GEYOIJ: 16
una plantilla estn-
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) capaces de afectar la manera en que se utiliza el patrn, as 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 problema, poniendo especial atencin en los aspectos estructurales y de comportamiento.
Consecuencias: se enfoca en lo que sucede cuando se aplica el patrn y en los cambios 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 dominio de aplicacin que se considere.
16 En la bibliografia se ha propuesto una variedad de plantillas de patrn. Los lectores mteresados pue
den consultar [FOW97J. (BUS961 y (GAM.95) entre much~ otras fuentes.
184
PAMB DOS PRAcncA DE LA INGENIERA oa sonwARE

Diseo: examina la manera en que el patrn de anlisis se puede lograr por medio de
patrones de diseno conocidos.
Usos conocidos: 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 I) por lo general se utiliza junto con el
patrn en estudio, 2) es similar en el sentido estructural a dicho patrn, 3) es una variacin del mismo.
En el captulo 8 se presentan ejemplos de patrones de anlisis, as como otros anlisis de este tpico.
Patrones
los patrones se pueden ver en casi cualquier
actividad de la vida diario.
Considrense las pelculas de accin y aventuras -de
manero ms especfico los pelculas policiacos de accin y
ovenluros con matices de comedio--. Se pueden definir
patrones poro el HroeyCompaiero, CapilnJefede/Hroe,
CriminakonCorazn y muchos ms.
Por ejemplo, el Capiln/efede/Hroe de manero invariable
es ms viejo, uso corbata (el hroe no), les grita en Formo
constonle al HroeyCompaero, usuolmenle es quien da el
7,7
perfil cmico, o puede usarse en un papel ms malvolo poro

poner trabas burocrticos o intereses personales en el comino
del HroeyCompoiiero. Se ha esloblecido un patrn
dromtico.
Poro un ejemplo algo ms tcnico considrese un
telfono celular. Los siguientes patrones son obvios: Uamar
BuscarNmero, VerMensojes entre muchos otros. Coda
uno de estos patrones puede describirse uno vez y despus
reutilizarse en el software para cualquier telfono celular.
HEGQSJ6SJ6N PI 119VHJt93
En un contexto ideal de la ingeniera de requisitos, las tareas de inicio, obtencin
elaboracin determinan los requisitos con el suficiente detalle como para emprerder los pasos subsecuentes de la ingeniera del software. Desgraciadamente, es~
sucede muy rara vez. En realidad, el cliente y el desarrollador entran en un proces-.
de negociacin, en el cual se le debe pedir al cliente un balance de la funcionalidad
el rendimiento y otras caractersticas del sistema o producto frente al costo y el tie!l'
po de colocacin en el mercado. El objetivo de esta negociacin es desarrollar u:plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones del mundo real (por ejemplo, tiempo, gente, presupuesto) a Ice
que est sometido el equipo de sottware.
~ awerdo es ti1lle de mwli 111 pa5tel de tal formo que mdo t.n0 pense que se qued (1)11 la rebonGllo mspide.
~,..
Las mejores negociaciones son aquellas que buscan un resultado del tipo "ganarganar".17 Esto es, el cliente gana al obtener el sistema o producto que satisface la
17 Se han escrito docenas de libros sobre las aptitudes para la negociacin (POr ejemplo, [LEWOO), [FAR9T
[D0N96J) sta es una de las competenoas ms importantes que un ingeniero o gerente de software~
ven (o no tan joven) puede aprender. se recomienda leer al menos uno de los libros mencionados.
CAPTULO 7
185
mayora de sus necesidades, y el equipo de software gana al trabajar con presupuestos y lmites de tiempo realistas y alcanzables.
Bohem [B0E98J define un conjunto de actividades de negociacin en el inicio de
cada iteracin del proceso del software. En lugar de la actividad sencilla de comunicacin con el cliente, se definen las siguientes actividades:
1. Identificacin de los interesados clave en el sistema o subsistema.
2. Determinacin de las "condiciones ganadoras" de los interesados.

3. Negociacin de las condiciones ganadoras de los interesados para reconciliarlas en conjunto de condiciones del tipo ganar-ganar para todos los involucrados (incluido el equipo de software).
La conclusin exitosa de estos pasos iniciales asegura un resultado del tipo ganarganar, el cual se convierte en el criterio clave para continuar con las actividades subsecuentes de la ingeniera del software.
El arte de la negoctacin
El oprendizoje del orte de lo negociocin
efectivo es uno octividod que sirve o travs de
-..o lecnico y persono!. Lo considerocin de las
~i::a'lles directrices puede resultar muy volioso:
Esconocer que no es una competencia. Poro ser

e:, 1oso, ambos lodos deben tener el sentimiento de
haber ganado o logrodo oigo. Los dos portes
llerldrn que llegar o un acuerdo.
Dtsear una estra/egia. Decidir que es lo que se

desearo lograr; qu es fo que lo otro porte quiere
alcanzar, y qu es lo que se va a hocer poro que
ambos cosos sucedan.
Escuchar de manera adiva. No se debe pensor en
bmulor uno respuesto mientras lo otro porte est
hablando. Es necesario escuchor. Es posible que se
obtengo un conocimiento que ayudar o negociar de

mejor monero lo posicin propia.
4.
Enfocarse en los intereses de la otra parte. Si se

quieren evitar los conffictos no se debe tomor uno
posicin inAexible.
5. No dejar que se vuelva persono/. Enfocarse en el

problema que debe 5er re5ueho.
6.
Ser creofivo. Cuando exi$len situaciones de
estoncomiento no se debe tener miedo de pensar
fuero de los cOnones.

7.
Eslor listo paro pactar. Uno vez que se ho llegado o
un acuerdo, no es necesario esperar: se debe poctor

dicho convenio y seguir odelonle.
Doug: En realidad s. Enviaste algunos buera

elemenlo$ o la reunin . ~ bmtonte.
Uso (sonriendo): Si claro, elle. me dijeron cp,e .....
y que no fue IMlCI oc:INidad muy IRnpla q u a ~
Doug (riendo): Me a5eglITTri de quilorme lo~ dt

tcnico la prxima va que le visite.. Mira, liso, JO cal)
que podemos tener un probl- en lermiftar todia lu
funcionalidades poro lo funcin de aegvridod ai el ....
186
PARTE DOS PRACTICA Df LA INGENJERA DEL SOFTWARE
J)Ol'Q los fec.has efe los que esl hablando tu gerencia. Es

muy pronk' yo lo s, pero yo he estado haciendo un
pequeo respaldo efe lo planeacin y...

U. Debemos teneno paro esa fecho, Doug. De cul
funcionofidod esfs hablando~
Doug: M.e parece que podemos socor tocio lo funcin
de 5e9uridod en el hogar paro lo fecho lmite, pero
tenckllm$ que retrasar ef acceso por lntemet hasta lo
segvndo eottego.
UN: Doug, el occeso por Internet es lo que da o

HcgarSeguro lo calidad de "novedoso. Vamos a
c;onstn,ir IQdo nuestro compaa de mercadatecna
alrededor de esto. Debemos tenerlo!

Doug; Entiendo tu situacin, de verdad. El problema es
que para darte acceso a lnremet necesitaremos tener un
sitio Web completomenle seguro, yo construi<fo y"'

funcionamiento. Paro eso se necesita tiempo y1ifllillllt
Tombifi tendremos que construir funcionalidaclet
adicionales en la primera entrega... no creo.-Jo
podamos hocer con los recU!'SO$ que
tenemos_...
Usa (frunciendo el ceo): Yo veo, pero diiW:t

encontrar uno formo de hacerlo. Es CNCiaf ~ ' funciones de seguridad en el hogar y poro lo dio.
funciones tomhin.. los otros funcione puedan.,,.....
hasta los siguientes entregas... &star d e ~
eso.
liso y Doug perecen estor en un callej6n mtdidci y
an as deben negociar uno solucin o este problema. Ea
esto situocin, ~ "ganar" lo.doo En elf)OF* ele
un mediador, cul serio uno sugerencio aprq,iadof
Al crear cada elemento del modelo de anlisis, ste se examina para conocer su e
sistencia, sus omisiones y ambigedades. A los requisitos que representa el mOG.
el cltcnle les da jerarqua y se agrupan en paquetes de requisitos que se implen'~
tan como incrementos de software y se le entregan. Una revisin del modelo de a.
lisis se enfoca en las siguientes preguntas:
iJ
Cuando se
revisan los
requisitos, cules
preguntas deben
hacerse?
Cada requisito es consistente con el objetivo general del sistema/product~

Todos los requisitos han sido especificados con el grado apropiado de
abstraccin? Esto es, algunos requisitos proporcionan un grado de detalle
tcnico que sea inapropiado en esta etapa?
El requisito es necesario en realidad o representa una caracterstica
agregada irrelevante para el objetivo del sistema?
Cada requisito est limitado y no es ambiguo?
Cada requisito tiene una atribucin? Esto es, existe una fuente (por lo
general, especfica, individual) determinada para cada requisito?
Algunos requisitos entran en conflicto con otros?
Cada requisito es alcanzable en el ambiente tcnico que recibir al sistefl'~
producto?
Cada requisito se puede probar una vez que ste haya sido implementado~
El modelo de requisitos releja de manera apropiada la informacin, la
funcin y el comportamiento del sistema que ser construido?
El modelo de requisitos se ha sometido a "particin" para que exponga en
forma progresiva informacin ms detallada acerca del sistema?
CAPTULO 7
INGENJERA DE REQUISITOS
187
Se han usado patrones de requisitos para simplificar el modelo de requisitos?

Todos los patrones se han validado de manera apropiada? Todos los
patrones son consistentes con los requisitos del cliente?
stas y otras preguntas deben realizarse y contestarse para asegurar que el modelo
de requisitos es un reflejo exacto de las necesidades del cliente y que proporciona
una base slida para el diseo.
Antes de que el diseo y la construccin de un sistema basado en computadora puedan comenzar, es necesario entender los requisitos. Esto se logra realizando una
serie de tareas de ingeniera de requisitos, la cual se lleva a cabo durante las actividades de comunicacin con el cliente y modelado que han sido definidas para el proceso genrico del software. Los miembros del equipo de software realizan siete funciones distintas dentro de la ingeniera de requisitos: inicio, obtencin, elaboracin,
negociacin, especificacin, validacin y gestin.
Al inicio del proyecto el desarrollador y el cliente (as como otros interesados)
establecen los requisitos bsicos del problema, definen las restricciones predominantes del proyecto y especifican las caractersticas y funciones ms importantes
que deben estar presentes en el sistema para que ste alcance sus objetivos. Esta
informacin es expandida y refinada durante la obtencin, una actividad para la
recopilacin de requisitos que emplea reuniones que encabeza un moderador facili tadas, el QFD y el desarrollo de escenarios de uso.
La elaboracin posterior expande los requisitos hacia un modelo de anlisis; es
decir, una coleccin de elementos del modelo basados en escenarios, en actividades
y en clases. de comportamiento y orientados al flujo. En la creacin de estos ele-
mentos se puede utilizar una variedad de notaciones de modelado. El modelo puede

referirse a patrones de anlisis, caractersticas del dominio del problema que son
recurrentes a travs de diferentes aplicaciones.
Cuando se identifican los requisitos y se crea el modelo de anlisis, el equipo de
software, el cliente y otros interesados en el proyecto negocian la prioridad, disponibilidad y costo relativo de cada requisito. El objetivo de esta negociacin es desa
rrollar un plan de proyecto realista. Adems, cada requisito y el modelo de anlisis
como un todo se validan contrastndolos con las necesidades del cliente para asegurar que se construir el sistema correcto.
REFERENc14s
[B0E98I Boehm, B. y A. Egyed, "SOftware Requirements Negotiation: Sorne Lcssons Learned",
en Proc. InU. Conf. Sofa.vare Engineering, ACM/IEEE, 1998, pp. 503-506.
fBOS91]Bossert, J. L., Quality Function Deployment: A Practitioner's Approach, ASQC Press, 1991.
fBUS96J Buschmann, F. et al., Pattem-Oriented Sojhvare Ardutecture: A system Pattcm, Wiley,
1996.
1 11tt11--- ---""""!!!
188
PARTE DOS
PRcnCA DE LA INGENIER!A DEL SOf"l'WARE
[COCOJJ Cockbum, A., Wriling E.ffective use-cases, Addison-Wesley, 2001.

[CRI921 Christel, M. G. y K. c. Kang, "lssues in Requirements Elicitation", en Software Engineerir.f
tnstitute, CMU/SEl-92-TR-12 7, septiembre de 1992.
(D0N96J Donaldson, M. C. y M. Donaldson, Negotialing Jor Dummies, IDG Books Worldwide
1996.
[FAR97) Farber, D. C., Common sense Negodalion: The Art of Winning Gracefu/Jy, Bay Press, 19r
[FOW97) Fowler, M., Analysis Patterns: Reusable Object Models, Addison-Wesley, 1977.
[GAM95] Gamma, E. et al., Design Pattems: EJements of Reusable Object-Oriented Softwaf?..
[GAU89J Gause, D. C. y G. M. Weinberg, Exploring Requirements: Quality Before Design, Dorsct
House, 1989.
(GEYOl] Geyer-Schultz, A. y M, Hahsler, Software Engineering with Analysis Pattems, Technic;
Report o1/2001, lnstitut fr lnformationsverarbeitung und-wirtschatl, Wirschatlsuniversit..
Wien, noviembre de 2001, obtenido de http://wwwai.wu-wien.ac.at/-hahsler/research/vi:'
lib_working2001 /virlib/.
UAC92J Jacobson, l., Objetc-Oriented Software Engineering, Addison-Wesley, 1992.
[LEWOOJ Lewicki, R., D. Saunders y J Minton, E.ssentials of Negotiation, McGraw-Hill, 2002.
(PAR96J Pardee, W., To Satisjy and Delight Your Costumer, Dorset House, 1996.
[S0M97J Somerville, l. y P. sawyer, Requirements Engineering, Wiley, 1997.
[THA97J Thayer, R. H. y M. Dorfman, Software Requirements Engineering, 2a. ed., IEEE Comput...
Society Press. 1997.
[YOUOIJ Young, R., E.ffective Requirements Practices, Addison-Wesley, 2001.
[ZAH90J zahniser, R. A., "BuiJding SOl1ware in Groups", en American Programmer, vol.3. nms. 8, julio-agosto de 1990.
[ZUL92J Zultner, R., "Quality Function Deployment for Software: Satisfying Costumers", ~
American Programmer, febrero de 1992, pp. 28-41.
7.1. Por qu varios desarrolladores de software no prestan mucha atencin a la ingeniera '""'"
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 fil:'
cin inicio?
7 .3. A usted se le ha dado la responsabilidad de obtener requisitos de un cliente que dice eStie'
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 sistel"'
en el tiempo?
7 .6. Suponga que ha convencido al cliente (usted es un excelente vendedor) de cada deman....
que ha hecho como desarrollador. E.so lo convierte en un negociador experto? Por qu?
7. 7. Desarrollar al menos tres "preguntas de contexto libre" adicionales que pueda hacerle
algn interesado durante la fase de inicio.
7 .8. A travs de este captulo se ha hecho referencia al "cliente". Describa al "cliente" para
desarrolladores de sistemas de informacin, para constructores de productos basados en com~
tadora, para constructores de sistemas. Debe tenerse precaucin: pueden existir ms clientes e
este problema de lo que se imagina.
7.9. Desarrolle un "paquete" que facilite la recopilacin de requisitos. El equipo debe incluir 1.:
conjunto de directrices para realizar una reunin de recopilacin de requisitos y una serie c..
materiales que puedan utilizarse para facilitar la creacin de listas y otros dispositivos que p~
dan ayudar en la definicin de requisitos.
CAPTULO 7 INGENIERiA DE REQUISITOS
189
7 . 1 O. 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 captulo. Realizar una reumn de recopilacin de requisitos mientras se utilizan las directrices presentadas en este captulo.
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 linea.
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. Exphcar 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 . 1s . con 1a plantilla presentada en la seccin 7 6.2, sugerir uno o ms patrones para una aplicacin que aplique el instructor.
7 . 16. Qu significa "ganar-ganar" en el contexto de la negociacin durante la actividad de
ingeniera de requisitos7
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 pnmordial para la creacin exitosa de cualquier sistema complejo basado en
computadora, la ingemeria de requ1s1tos se expone en una gran cantidad de libros. Hull y sus
colegas (Reqwrements Engineering, Springer-Verlag, 2002). Bray (An Jntroduction to Requircments
Engineering, Addison Wesley, 2002). Arlow (Requirements Engineering, Addison-Wesley, 2001),
Gllb (Requirements Engineenng, Addison-We.~ley, 2000), Craham (RC<fuirements Cngimx:m15 urr
Rapid Development, Addison-Wesley, 1999) y Sommerville y Kotonya (Requirement,; Engincering
Proceses and Techniques, Wiley, 1998) son slo algunos libros dedicados a este tema. Dan Bcrry
(http://se uwaterloo.ca/-dberry/b1b html) ha publicado una amplia variedad de escritos acerca
de tpicos relacionados con la ingeniera de requisitos.
Lauesen (Software Requiremencs. St_yles and Techniques. Adchson Wesley, 2002) presenta una
amplia muestra de notaciones y mtodos para el anlisis de requisitos. Wcigers (Software
Requirements, Microsoft Press, 1999) y Leffingwell y sus colegas (Managmg Software Requiremencs:
A Unijied Approach, Addison-Wesley, 2000) presentan una coleccin til de las mejores prcticas de requisitos y sugieren guias pragmticas para casi todos lo~ aspectos del proceso de la
ingenierla de requisitos.
Robertson y Robertson (Mastcnng the Rcqwremencs Process, Add1son Wesley, 1999) presentan un estudio de caso muy detallado que ayuda a explicar todos los aspectos del anhsis de
requisllos y el modelo de anlisis de sofiware. Kovitz (Practica/ Software Reqwrements: A Manual
ofContent and Style, Manning Publications, 1998) explica paso a paso un enfoque para el anlisis de requisitos y una gua de estilo para aquellos que deben desarrollar especificaciones de
requisitos Jackson (Sojlware Requirements Analysis and Spedjication A LexJcon of Practices,
Pnndples and Prejudices, Addison-Wesley, 1995) presenta una visin sugerente del tema de la A
a la z (de manera literal). Plocsch (ASSeltlons, Scenanos and Prototypes, Spnnger-Verlag, 200.3)
explica tcnicas avanzadas para desarrollar requisitos de software.
190
PARTE DOS
Windle y Abreo (Software Reqwrements Using the Unified Process, Prentice-Hall, 2002) exponen 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 revisa:
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. Bitlner y Spence (Use-case Modeling, Addison-Wesley, 2002
examinan el tema de manera amplia, as como Cockbum [COCO I J, Armour y Miller (Advanca.
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 anlisis e ingeniera de requisitos. En el sitio web de SEPA, http:// 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.
MODELADO
DEL ANLISIS
n el mbito tcnico, la ingeniera de software comienza con una serie de

tareas de modelado que conducen a una especificacin de requisitos y a
una representacin completa del diseo del software que se construir. El
modelo de anlisis, que en realidad es una serie de modelos, es la primera repre~
sentacin tcnica de un sistema.
En un libro sobre mtodos de modelado del anlisis, Tom DeMarco [DEM79l
describe el proceso de la siguiente manera:
Al observar los problemas y fallas reconocidas de la fase de anlisis es necesario agregarle los siguientes obetivos:
Los productos del anlisis deben tener una elevada facilidad de manteni-
miento. Esto se aplica en particular al documento final especificacin de re

quisitos de software].
Los problemas de gran tamao deben tratarse con un mtodo efectivo de particin. La especificacin del tipo de las novelas victorianas ya no sirve.
Deben utilizarse grficas cuando sea posible.
Se debe diferenoar entre consideraciones lgicas Iesencales} y fisicas {de implementacin)...

Como mnimo se necesita...
Algo que ayude a hacer una particin de los requisitos y a documentarla antes
de 1a especificacin..
Algunos medios para el seguimiento y evaluacin de las interfases...

Herramienta~ nuevas para aescrlblr la lgica y la tctica.
texto narrativo.
atgo meor que un
Aunque DeMarco escribi acerca de los atributos del modelado del anlisis hace
ms de un cuarto de siglo, sus contribuciones se siguen aplicando en la notacin
y los mtodos modernos de modelado del anlisis.
191
11
192
~
~~
C~VE
El modelo de onlisis y
lo especificacin de
requisitos proporciono
un medio paro evoluar
lo calidad una vez que
el software est
construido.
PARTE DOS
11
il&:1111
PRCTICA DE LA INGEN!ERIA Da SOFIWARE
El anlisis de requisitos genera la especificacin de caractersticas operacionales .:.

software; indica la interfaz del software con otros elementos del sistema, y estab.;;
ce las restricciones que debe tener el software. El anlisis de requisitos permite cr. .
el ingeniero de software (a veces llamado en este contexto analista. o modelador) ~
extienda sobre requerimientos bsicos establecidos durante tareas anteriores a
ingeniera de requisitos y construya modelos que representen escenarios del usu~
rio, actividades funcionales, clases de problemas y sus relaciones, el comportamier
to de las clases y el sistema y, a medida que se transforma, el flujo de datos.
El anlisis de requisitos le proporciona al diseador de software una representa
cin de informacin, funcin y comportamiento que puede trasladar a diseos arqu.
tectnicos, de interfaz y en el nivel de componentes. Por ltimo, el modelo de an
lisis y la especificacin de requisitos ofrecen al desarrollador y al cliente los medio:.
para evaluar la calidad una vez construido el software.
Por medio del modelado del anlisis el ingeniero de software se centra primen.
en el qu, no en el cmo. Qu objetos manipula el sistema, qu funciones debe
desempear el sistema, qu comportamientos muestra el sistema, qu interfaces se
definen y qu restricciones se aplican? 1
En captulos anteriores se estableci que en esta etapa tal vez no fuera posible
realizar una especificacin completa de requisitos. Quiz el desarrollador no este
1 Es necesario mencionar que conforme los clientes se vuelven ms refinados en el sentido tecnolgico existe una tendencia hacia la especificacin tanto del cmo como del qu. Sin embargo, el enfoque primario debe permanecer en el qu.
CAPTULO 8
MODELADO DEL ANLISIS
193
seguro de qu enfoque especfico realizar la funcin y si se desempear de manera apropiada. Estas realidades favorecen un enfoque iterativo para el anlisis y el
modelado de requisitos. El analista debe modelar lo que se conoce y utilizar ese
modelo como base para disear un incremento de software. 2
8.1.1
Filosofa y objetivos generales
El modelo de anlisis debe cumplir tres objetivos primarios: I) describir lo que

requiere el cliente, 2) establecer una base para la creacin de un diseo de software, y 3) definir un conjunto de requisitos que puedan validarse una vez construido el
software. El modelo de anlisis llena el vaco entre una descripcin al nivel de sistema (captulo 6) -que detalla la funcionalidad general del sistema, la cual se logra al
aplicar software. hardware. datos. humanos- y otros elementos del sistema y del
diseo de software (captulo 9) -que detallan la arquitectura de aplicacin del soflware, la interfaz con el usuario y la estructura en el nivel de componentes-. Esta
relacin se ilustra en la figura 8. 1 .
Es importante puntualizar que algunos elementos del modelo de anlisis estn

presentes (en un grado ms alto de abstraccin) en la descripcin del sistema, y que
esas tareas de ingeniera de requisitos en realidad comienzan como parte de la ingeniera de sistemas. Adems, todos los elementos del modelo de anlisis son identificables de manera directa en las partes del modelo del diseo. No siempre es posible una divisin clara de tareas de anlisis y diseo entre estas dos importantes actividades del modelado. De modo invariable, como parte del anlisis se realiza algn
diseo y algn anlisis se efecta durante 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 reqws1tos para el sistema.
1IUIJ
194
1a1111ilia.aill_ __
PARTE DOS PRCTICA DE LA INGENJERIA DEL SOFTWARE
8.1 .2 Reglas prcticas de anlisis

Arlow y Neustadt [ARL02] sugieren varias reglas prcticas que deben seguirse para
crear el modelo de anlisis:
El modelo debe centrarse en los requisitos visibles dentro del problema o dominio
de negocio. El grado de abstraccin debe ser alto deforma relativa. HNo se debe
perder tiempo en detalles" [ARL02] que tratan de explicar cmo funcionar el
sistema.
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 informacin, funcin y comportamiento del sistema.
Debe retrasarse la consideracin de la infraestructura y otros modelos no funcionales hasta el diseo. Por ejemplo, es posible que se requiera una base de
datos, pero las clases necesarias para implementarla, las funciones que se
requieren para acceder a ella y el comportamiento que se exhibir cuando se
utilice debe considerarse slo despus de que se haya completado el anlisis
de dominio del problema.
Se debe minimizar el acoplamiento de todo el sistema. Es importante representar las relaciones entre clases y funciones. Sin embargo, si el nivel de
"interconexin" es extremadamente alto se deben hacer esfuerzos para
reducirlo.
Se debe tener la seguridad de que el modelo de anlisis proporciona valor a todos

los interesados. cada circunscripcin tiene su propio uso del modelo. Por
ejemplo, los interesados relacionados con los negocios deben utilizar el
modelo para validar los requisitos; los diseadores, como base para el diseo
la gente de aseguramiento de la calidad, como ayuda para planear pruebas de
aceptacin.
El modelo debe mantenerse tan simple como sea posible. No se deben agregar
diagramas adicionales cuando stos no ofrezcan informacin nueva. No se
deben utilizar formas de notacin nuevas cuando basta con una simple lista.
8.1.3 Anlisis del dominio
Cbif:iiN:'i
&i -w.ltv,ls.
etm/F.r,,/ii,ft/
Sohww.
illplNrflll/
SL-45.mp
puedeitenconlrols&
mucnos rerurmIJlles
\l(llO el onfis~ del
domino.
Al examinar la ingeniera de requisitos (captulo 7) se estableci que los patrones de

anlisis a menudo ocurren de nuevo en muchas aplicaciones dentro de un dominio
de negocio especfico. Si estos patrones se definen y se clasifican por categora de
una manera que permitan al ingeniero o al analista de software reconocerlos y reutilizarlos, la creacin del modelo de anlisis se acelera. Un factor de mayor importancia es que la probabilidad de aplicar patrones de diseo reutilizables y componentes ejecutables de software aumenta en forma sustancial. Esto ofrece tiempo al
mercado y reduce los costos del desarrollo.
CAPTULO 8 MODELADO DEL ANLISIS
195
Entrada y salida para el anlisis del dominio.
..
1terotura tecnica
Aplicaciones existentes
'-tes del
iento
~dominio
Sondeos a los clientes

Recomendacin experta
Requisitos actuales/futuros
Taxonomas de clase
"I
Modelos funcionales
Lenguajes de dominio
. Anlisis
. del dominio
'-
Estndares de reutilizacin
Modelo
de anlisis
del dominio
Pero, en primer lugar, cmo se reconocen los patrones de anlisis? Quines los
definen, los asignan a una categora y los preparan para aplicarlos en proyectos subsecuentes? Las respuestas a estas preguntas residen en el anlisis del dominio.
Firesmith [FIR93] describe el anlisis del dominio de la siguiente manera:
El anlisis del dominio de software es la identificacin, el anlisis y la especificacin de requisitos comunes de un dominio especifico de aplicacin para, de manera tpica, reutilizarlo 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 capacidades comunes reutilizables dentro de un dominio especifico de aplicacin, en trminos
de objetos, clases, subensamblajes y marcos de trabajo.
El "dominio de aplicacin especfico" puede variar desde aeronutica hasta servicios

bancarios, desde videojuegos en multimedia hasta software aplicado en instrumental mdico. La meta del anlisis o de dominio es directa: encontrar o crear aquellas
clases de anlisis o funciones y caractersticas comunes que se aplican ampliamente para que puedan reutilizarse. 3
En cierta forma, el papel de un analista de dominio es similar al de un maestro

forjador de herramientas en un ambiente de manufactura pesada. El trabajo de este
ltimo es disear y fabricar instrumentos que puedan ser usados por mucha gente
que realiza trabajos similares. El papel del analista de dominio4 es descubrir y definir
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"[LET031.
4 No debe suponerse que si se cuenta con la colaboracin de un analista del dominio, un ingeni ~ro de
sollware 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.
11.w111m
196
PARTE DOS PRCTICA DE LA INGENIERA Dll SOF1WARE
patrones de anlisis reutilizables, clases de anlisis e informacin relacionada que

pueda usar mucha gente en aplicaciones parecidas.
La figura 8.2 [ARA89J ilustra entradas y salidas clave para el proceso de anlisc.
de dominio. Las fuentes de conocimiento del dominio se examinan en un intento pe
identificar objetos que pueden ser reutilizados a travs del dominio.
Una visin del modelado del anlisis, llamado anlisis estructurado, considera que le"
datos y el proceso que transforman los datos son entidades separadas. Los objet~
de datos se modelan en una forma que define sus atributos y relaciones. Los proce
sos que manipulan los objetos de los datos se modelan de tal manera que muestra-cmo transforman los datos, mientras los objetos de datos fluyen por el sistema.
Un segundo enfoque del modelado del anlisis, llamado anlisis orientado a ObJC
tos, se centra en la definicin de clases y en la manera en que stas colaboran entre
ellas para efectuar los requisitos del cliente. El UML y el proceso unificado (capitu;,
3) estn orientados a objetos en forma predominante.
B[uilisls es fruslronte, lleno de relaciones interpersonales comple;os, indefinido y clfidl. En ,acm palalns, a
fasdimte. Una .ez que ests engonc:hodo, el viejo placer de lo coostruccin de sistemas IIIIKO ser~ pn
Slllicwte.
.......
Aunque el modelo de anlisis propuesto en este captulo combina caracterstica.

de ambos enfoques, es comn que los equipos de software elijan uno y excluyar
todas las representaciones del otro. El cuestionamiento no es cul es el mejor, sinr
qu combinacin de representaciones le proporcionar a los interesados el mejer
modelo de requisitos de software y el puente ms efectivo para el diseo de software
El modelado del anlisis conduce a la derivacin de cada uno de los elementos de
modelado mostrados en la figura 8.3. No obstante, el contenido especifico de cacL.
elemento (por ejemplo, los diagramas con que se construyen el elemento y el modelo) puede diferir de proyecto a proyecto. Como ya se ha puntualizado muchas veces
en este libro, el equipo de software debe trabajar para mantenerlo simple. Slo st:
deben utilizar aquellos elementos que agreguen valor al modelo.
ir. qlldeliemos construir modelos?Por qu no construimos el sistema y yo? la respuesta es que podemos
c.stJtir modelos de tol forma que resabemos o enfali<emos ciertos coraderisticos crticas de un sistema, al "*-,o que
nfasis ootros aspedos del sistema.
.-nos
CAPTULO 8
197
E......._ orientados
'""""'
de
de
E'-basodos
C0$0S de U>O, lexlo
Co$0S de u>0, d,agromos
Diogromos de octiYidod
Diogramos de corril
Diogromos
flujo
dolos
Oiogromos de flujo de control
Narrativos de procesomiento
..._.._...
...........
1
Modelo de anlisis
..._._
e
Diagramas de do...
PoqueleS de onlis"
Modelos CRC
Diogromos de colaboracin
O.ogromos de eslodo
O.ogromos de sec-.ncio
El modelado del anlisis a menudo comienza con el modelado de datos. El ingeniero

o analista de software define todos los objetos de datos que se procesan dentro del
sistema y las relaciones entre los objetos de datos, adems de otra informacin pertinente para las relaciones.
8.3.1 Objetos de datos

Un objeto de datos es una representacin de casi cualquier informacin compuesta
que el software debe entender. Informacin compuesta se refiere a algo que tiene
muchas propiedades o atributos diferentes. Por lo tanto, "anchura" (un valor individual) no sera un objeto de datos vlido, pero las dimensiones (la incorporacin de
altura, anchura y profundidad) podran definirse como un objeto.
Un objeto de datos 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 evento (como una alarma). un papel (por
ejemplo, un vendedor), una unidad organizacional (como un departamento de contaduria), un lugar (como un almacn), o una estructura (como un archivo). Por ejemplo,
una persona o un auto pueden verse como un objeto de datos en el sentido de que cualquiera de ellos puede definirse en trminos de un conjunto de atributos. La descripcin
del objeto de datos incorpora el objeto y todos sus atributos.
Un objeto de datos encapsula slo datos: no existe alguna referencia dentro de un
objeto de datos a las operaciones acten sobre los datos.5 Por lo tanto, el objeto de
datos puede representarse como una tabla, tal como se muestra en la figura 8.4. Los
encabezados de la tabla reflejan los atributos del objeto. En este caso. un auto se
define en trminos de matea, modelo, nmero de serie, tipo de cal'fOCera, color y propietario. El contenido de la tabla representa ejemplos especficos del objeto de datos. Por
ejemplo, un Chevy Corvette es una muestra del objeto de datos auto.
5
Esta distincin separa los objetos de datos y las clases u objetos definidos como parte del enfoque
orientado a objetos.
198
PARTE DOS
PRACTICA DE LA INGENIERA DEL SOf"IWARE
iihtiii
Representacln
Nombres
de atributos
tabular d e
ob jetos de
datos.
Une los obetos de datos entre s,

en este coso, propietario
Morco Modelo # de id
lexus LS400 AB123 . .
Instancio Cbtncy
BMW
Ford
.,
n
Sedan
Color
Blanco
Corwlle U56. . .
Ro
ceo
750il
Tourus
Coup
Blanco
Azul
UL
XZ765. . .
O 12AA5 .. Sedn
RSP
BLF
8.3.2 Abibutos
~~
cf&v1
Los otbutos definen o

un objeto de datos,
describen sus
coracterstic05 y, en
oltmis cosos, hocen
referencia ootro
objeto.
t hif:iltlM1
e-.....,es
.l'MliiaJli(l.
.........
.......,,.
impol1onll pllU
aqillll .. inllAlan
.....
Atributos
Atributos
identificador
descriptivos
referenciales
~~~
-..&i ....
puede ...... 111111
Los atributos definen las propiedades de un objeto de datos y toman una de las tR
caractersticas diferentes. Se pueden utilizar para 1) nombrar una ocurrencia c.
objeto de datos, 2) describir la ocurrencia o 3) hacer referencia a otra ocurrencia ~
otra tabla. Adems, se debe definir uno o ms atributos como un identificador; ~
decir, el atributo identificador se convierte en una "clave" cuando se desea encone-_
una ocurrencia del objeto de datos. En algunos casos. los valores para el (los) ide,..
tificador(es) son nicos, aunque esto no es un requisito. En referencia al objeto .:
datos auto, un identificador razonable podra ser el nmero de serie.
El conjunto de atributos apropiado para un objeto de datos se determina median
te la comprensin del contexto del problema. Los atributos para auto sirven b1....
para una aplicacin que utilice el Departamento de vehculos de motor, pero est
atributos seran intiles para una compaa automotriz que necesite un soft.wafl
para el control de fabricacin En este ltimo caso, los atributos para auto tal "
incluiran tambin nmero de Nrie, tipo de oanoceria y color, pero adems tendran
adicionarse muchos ms atributos (como cdigo interior, tipo de tren de manejo, desia,.dor de paquete de ajuste, tipo da transmisin) para hacer de auto un objeto significan
en el contexto de control de fabricacin
INFORMACIN
Objetos de datos y clases 00, son lo mismo?

Cuando se debate acerco de los objetos de
tombi"1 incorporo los operaciones que manipulan los
datos es comn que surjo uno pregunto: un
objeto de dotas es lo mismo que uno dose orientada o
objetos~ Lo respuesto es no.
datos implicados por dichos atributos. Adems, lo

definici6n de doses implico uno inlroestructuro completo
que es porte del enfoque de lo ingenierio de software
Un objeto de datos define un elemento compue.slo de

los datos; esto es, incorporo uno coleccin de elementos de
dolos individuales (atributos) y do un nombre O lo
coleccin de elementos (el nombre del objeto de datos).
Uno clase 00 encapsulo atributos de los datos, pero
orienlodo o objetos Los doses se comunicon entre s o

travs de mensajes; pueden organizarse en jerarquas;
proporcionan corocterslicos heredadas poro ob jetos que
son uno instancia poro uno clase.
CAPTULO 8
199
MODELA.DO DEL ANLISIS
pe=no -l
_,automvil
al Uno conexin bsico entre objetos

de datos
El
a::d? automvil
poro monet _r.__ _..
b) Relaciones entre objetos

de dolos
8.3.3 Relaciones
Los objetos de datos estn conectados entre si de muchas maneras diferentes. Por
ejemplo, dos objetos de datos, persona y auto, pueden representarse con la simple
notacin ilustrada en la figura 8.Sa. Se establece una conexin entre persona y
auto porque los objetos se relacionan entre s. Pero, cules son las relaciones? La
respuesta se determina entendiendo el papel de las personas (propietarios, en este
caso) y de los autos dentro del contexto del software que se construir. Se puede
definir un conjunto de parejas objeto/relacin que definan las relaciones relevantes.
Por ejemplo:
Una persona posee un auto.
una persona est asegurada para condudr un auto.
Las relaciones posee y est asegurada para conducir definen las conexiones relevantes entre persona y auto. En la figura 8.5b se ilustran estas parejas objeto/relacin
de manera grfica. Las flechas de la figura 8.5b ofrecen informacin importante
acerca de la direccionalidad de la relacin y a menudo reducen la ambigedad o las
malas interpretaciones.
8.3.4 Cardinalidad y modalidad
Los elementos del modelado de datos -objetos de datos, atributos y relacionesofrecen la base para entender el dominio de informacin de un problema. Sin
embargo, tambin es necesario comprender informacin adicional relacionada con
estos elementos bsicos.
Hasta este punto se ha definido un conjunto de objetos y se han representado las
parejas objeto/relacin que los limitan. Pero un simple par que establece que
objetox se relaciona con objetoY no proporciona suficiente informacin para los
propsitos de la ingeniera del software. se debe entender cuntas ocurrencias del
objetoX estn relacionadas con cuntas ocurrencias del objetoY. Esto conduce al
concepto del modelado de datos llamado cardinalidad.
El modelo de datos debe ser capaz de representar el nmero de ocurrencias de
los objetos en una relacin dada. Tillmann (TIL93J define la cardinalidad de un par
objeto/relacin de la siguiente manera: "cardinalidad es la especificacin del nme-
PARTE oos
200
Cmo se
maneja ana
situacin en la
que un objeto de
datos est relo
donado con la
0<11rrenda de
muchos otros
objetos de datos?
mcrteA. oc u
INGENIERA. oo. son-w=
ro de ocurrencias de un [objeto) que puede relacionarse con el nmero de ocurrer.

cias de otro [objeto]" Por ejemplo, un objeto puede relacionarse slo con otro ob,eto (una relacin 1 l) . un objeto puede relacionarse con muchos objetos (una relaci
1:N); un nmero de ocurrencias de un objeto puede relacionarse con algn ot"
nmero de ocurrencias de otro objeto (una relacin M:N). 6 La cardinalidad tambiL
define "el nmero mximo de objetos que puede participar en una relacin" [TIL9
Sin embargo, no indica si un obeto particular de datos debe participar o no en
relacin. El modelo de datos agrega modalidad al par objeto/relacin para espec ~
car esta informacin.
Diagramas de entidad-relacin
la parejo objeto-relacin es lo piedra angular
del modelo de datos. fatos parejos pueden
representarse de manero grfico mediante el diagramo ele
entidad relacin (DER). 7 El DER lo propu$0 originalmente
Peter Chen (CHE77] poro el diseo de sistemas de bases
relacionales, y despus otros lo han ampliado. Con el DER
se identifico un conjunto de componentes primarios:
objetos ele datos, atributos, relaciones e indicadores de
varios tipos. El propsito primordial del DER es representar
objetos de datos y sus relaciones.
Yo se ha hecho uno introduccin ele lo notocin
rudimentario poro el DER. las objetos de datos se
representan por medio de un redngulo etiquetodo. las

relaciones se representan mediante uno lneo etiquetado
que conecto objetos En algunos variaciones del DER lo
lneo de conexin contiene un rombo que esl etiq uetodo
con lo relacin. Los conexiones entre objetos de datos y
relaciones se establecen mediante uno va riedad de
smbolos especiales que indican su cardinalidad y
modalidad.
Poro ms informacin sobre el modelado de datos y el
diagramo de entidad-relacin el lector interesado puede
consultar [THAOO]
La modalidad de una relacin es de O si no hay una necesidad explcita para qlk

ocurra la relacin o la relacin es opc1onal. La modalidad es I si una ocurrencia de
la relacin es obligatoria .
de informan sea ti, confiable, adoptable y e<onmico debe estar basado ,riarD .,
......_ de datos, y slo de manera secundario en el antisis del proceso .. . porque la tsi1ldWa 4t clalls llfln
4e fuma inherente o la ve,dod, mientras que el proceso es relativo a la taim.
. , _ " ' 111 sis11ma
Modelado de datos
Objetivo: Los herramientas poro el modelado

de datos proporcionan ol ingeniero de software
lo capacidad de representar obetos de datos, sus
coroctersticos y relaciones. Estos herramientas -que se

utilizon sobre todo poro grandes aplicaciones de bases de
datos y olros proyectos de sistemas de inb-mocio-
J
6 Por eemplo, un to puede tener muchos sobnnos y un sobrino puede tener muchos tos
7 Aunque el DER todava se usa en algunas aplicaciones para el diseno de bases de datos, en la actualidad la notacin en UML es la ms utilizada para el diseo de datos
CAPTULO 8
il::t;:;:,on:ic:
>non un medio outomotizodo poro creor
a::::::rcMOs
de entidod-reloci6n, diccionarios de objetos de
"'1<Xlelos relocionodos.
aicanica : Las herramientas en esta cotegorlo permiten

::no describir objetos de dolos y sus
relaciones. En
cosos utilizan lo notacin del DER; en otros
a:::=anes modelan los relaciones por medio de otros
-~-"'-. Adems permiten lo creacin de un modelo
datos ol generar un esquema de bose de datos
201
SMBO.
nmmentas representativas
desarrollado por Computes Associotes

3 cc.oom), O)'\Jdo en el diseo de objetos de datos,
:.i..-os propios y elementos clave poro bases de datos.
f;Win,
desorrollodo por Emborcodero Software

A"Tlborcodero.com), brindo soporte al modelado
relacin.
Orocle/Designer, desorrollodo por Orode Systems

(www orocle com). modela procesos de negocios,
entidades de dolos y relaciones que se transforman en
diseos a partir de los cuales se generan oplicociones
completas y bases de datos.
MetoScope, desorrollodo por Modrone Systems

(www.modronesystems.com), es uno herromienlo poro
el modelado de dolos de bojo costo que do soporte o
lo representacin grfica de dolos.
Mocle/Sphere, desarrollado por Magno Solutions GMBH

(www.magnosolutions.com), do soporte o uno voriedod
de herramientas de modelado relacional.
VisibleAnalyst, desorrollodo por Visible Systems

(www.visible.com), da soporte a una variedad de
funciones de modelado del anlisis, incluido el
modelado de datos.
Cualquier estudio sobre el anlisis orientado a objetos debera comenzar definiendo

el trmino orientado a objetos. Qu es un punto de vista orientado a objetos? Por
qu un mtodo se considera orientado a objetos? Qu es un objeto? Cuando la 00
obtuvo una amplia variedad de adeptos durante las dcadas de 1980 y 1990, existieron muchas opiniones diferentes (por ejemplo, [BER93), {TAY90], [STR88], [B0086]
acerca de las respuestas correctas a estas preguntas. En la actualidad ha surgido una
visin coherente de la OO.
El objetivo del anlisis orientado a objetos (AOO) es definir todas las clases (adems de las relaciones y el comportamiento asociado con ellas) relevantes para el
problema y que deben resolverse. Esto se logra llevando a cabo algunas tareas
1. Deben comunicarse los requisitos bsicos del usuario entre el cliente y el ingeniero de software.
2 . Deben identificarse las clases (es decir, se definen los alributos y mtodos) .
3. Se define una jerarqua de clases.
4 . Deben representarse las relaciones de objeto a objeto (conexiones entre objetos).
5. Debe modelarse el comportamiento del objeto.
6 . Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo

est completo.
Las herramientas mencionadas aqu son una muestra de esta categona. En la mayora de los casos
los nombres estan registrados por sus respectivos desarrolladores
202
PARTE DOS
PRCTICA DE LA INGENJEruA DEL SOFTWARE
En lugar de examinar un problema mediante un modelo ms convencional

tipo entrada-procesamiento-salida (flujo de informacin) o un modelo derivado e:
forma exclusiva de las estructuras jerrquicas de informacin, el AOO construye
modelo orientado a las clases que se basa en la comprensin de los conceptos O'"'
Conceptos orientados a objetos

Los conceptos orientados o objetos (00) estn
bien establecidos en el mundo de lo ingeniera
del software. A continuacin se presentan los descripciones
abreviados de conceptos 00 que se encuentran con
frecuencia durante el modelado del anlisis. En el captulo
1O se presentan otros objetos 00 que estn alineados de
manero ms cercana al diseo de software.
Atributos: uno coleccin de valores de los datos que
describen una clase.
Clase: encapsulo los datos y las abstracciones de
procedimiento requeridos paro describir el contenido y el
comportamiento de alguno entidad del mundo real. Dicho
de otro manero, uno clase es una descripcin
generalizado (par ejemplo, uno plantillo, un patrn o un
plano de trabajo) que describe uno coleccin de objetos

similores.
Objetos: instancias de uno clase especfica. Los obie:a
heredan los atributos y operaciones de una clase.
Operaciones: tambin llamados mtodos y servicios
proporcionan lo representacin de uno de los
comportamientos de uno clase.
Subclase: uno especializacin de la superdose. IJr,c
subclase puede heredar tanto los atributos como los
operaciones de una superdose.
Superdose: tambin llamado uno e/ose bsica, es
generalizacin de un conjunto de doses que estn
relacionadas con ello.
Aunque el xito de un sistema o producto basado en computadora se w

muchas formas, la satisfaccin del usuario encabeza la lista. Si los ingerue
software entienden la manera en que los usuarios finales (y otros actores ~
interactuar con el sistema, el equipo de software ser ms capaz de caracte'""
forma apropiada los requisitos y construir modelos significativos de anlisis
o. Por lo tanto, el moc;lelado del anlisis con UML comienza con la creacin c.
narios en la forma de casos de uso, diagramas de actividad y diagramas de
8.5.l Escritura de casos de uso

Un caso de uso captura las interacciones que ocurren entre los productore..
sumidores de informacin y del sistema en s mismo. En esta seccin se e
forma en que se desarrollan los casos de uso como una parte de la actr
modelado del anlisis.9
El concepto de un caso de uso (captulo 7) es relativamente fcil de ente
cribe un escenario de uso especfico en un lenguaje directo desde el pUilk
9 Los casos de uso son una parte particularmente importante del modelado del anliso
terfases con el usuario. El anlisis de la interfaz se trata con detalle en el captulo 12
CAPTULO 8
203
de un actor definido. 10 Pero cmo puede saberse 1) sobre qu escribir? 2), cunto
escribir acerca de ello? 3), qu tan detallada debe ser la descripcin?, y 4) cmo organizar la descripcin? Estas son las preguntas que deben contestarse para que los casos
de uso tengan un valor como herramienta para el modelado del anlisis.
11a . . dtuso]sonsimplemente uno ayudo poro definir lo que existe fuero del sistemo (lidores) yle
llillrll' 11$15JemQ (casos de uso).#
que.,_.
Sobre qu escribir? Las primeras dos tareas de la ingeniera de requisitos 11 -inicio y obtencin- proporcionan la informacin necesaria para comenzar a escribir
casos de uso. Las reuniones para la recopilacin de requisitos, despliegue de la funcin de calidad (QFD) y otros mecanismos para la ingeniera de requisitos se utilizan
para identificar a los interesados, definir el mbito del problema, especificar las
metas operativas globales, esquematizar todos los requisitos funcionales conocidos
y describir las cosas (objetos) que manipular el sistema.
El desarrollo de una serie de casos de uso se comienza haciendo una lista de las
funciones o actividades que realiza un actor especfico. stas pueden obtenerse de
una lista de funciones requeridas del sistema por medio de conversaciones con los
clientes o usuarios finales, o mediante una evaluacin de los diagramas de actividad
(seccin 8.5.2) desarrollados como parte del modelado del anlisis.
1O Un actor no es una persona especfica, sino el papel que desempea una persona (o dispositivo) dentro de un contexto especfico. Un actor "llama al sistema para entregar uno de sus servicios"
[COCO!).
11 Estas tareas de la ingeniera de requisitos se examinan con detalle en el captulo 7.
204
PARTE DOS PRCTICA DE LA TNGENIERA DEL SOFIWARE
Ed: El vdeo ser digot y se o_lll)OChor6' en dscoi
Moderador: Sueno p~ooto, pero pof ohoro

pospongamos los os~cros de Jmplet'!ienloci6tl.
2MerE!dith?
Mentditht De oc~, ento~es b9sia:mente' hoy dos

porle$ pol'O lo funcin ~ viijilanda.. lo primero
configuro el $.$1ml;J, lndvyend'o el es'tledmien!Q de on
plano de lo coso -ne<:e$itomos herr<:uniE!litqs que oyvden
al propietario eh~ y lo ~undQ pqrte es kt funcin
de vigilcmco real en $lmjsma. Como el ~stobleeimiento
del p!Qno es portes(ie lo t1dividad de, c_onfl9~roon, me
enfocor en lo fundri Je vigitom;ig,
Maderodor (sonrjendo): ~ qpitostf~ p(llobros
de lo boca.
~ b : Mm.... Quiero ~nr deso o lo func_ir de
vigilancia, )'QW!l o JtV~ de lo PC o de Intern!, Sienlo '
que el acceso por lntrnet serq el de lfSO ms frecuen!e,
De <UO)quier manero, quiero ser capaz de desplegar
vi$lm de ls c4moros en uno PC. y COfl,trolor el
movimiento y los ~er(omienlos ~ yna cmata

especfico Espifico la cmara ~conodo desde el
plano de lo co;a, Qu1iro ~robar y ~ i r lo $Olida
de los cmaros de manero ~lec;tivo. Tombin qyiero ser
capaz de bloquear el oc:~so o una o ms ~ras- con
una contraseo especifica. Y quiero la opcin de ver
pequeos ventanos que mwstren vi$f0$ de todos las
cmaras y despus ~r cop(lz de sel~r la que
quiero destacar.
Jomie: Esos se llaman vstas ~ mini(lfura.
Meredith: Bien, ~ntonces <4uiero visfl;IJ en 111lriioturo ele

todos c c6mtos, Tambin quiero-qUllt lo interfaz con
funcin de vlgilancitl tenga lo mismo aporenc:ia que
todos tos otros interfases ~ Hogar~. Quiero que
seo i{ltutlvo; el d:ecr.._ que no sea necesorio leer un
manual para poder usorla.
M,:idrctdcm Buen trabajo,, ahqo entremos n esta
funct6n con un~ ms de dtlolle...
La funcin de vigilancia en el hogar de HogarSeguro que se examina en el rec
dro identifica las siguientes funciones (una lista abreviada) que realiza el actor ide-:tificado como propietario de la casa:
Tener acceso a la cmara de vigilancia va Internet.
Seleccionar la cmara que desea ver.
Solicitar vistas en miniatura de todas las cmaras.
Desplegar vistas de la cmara en una ventana de una PC.
Controlar la visin panormica y de acercamiento en una cmara especfica
Registrar en forma selectiva la salida de cmara.
Repetir la salida de cmara.
Conforme se realizan las conversaciones posteriores con el interesado (qu.
desempea el papel de un propietario), el equipo de recopilacin de requisitos desarrolla casos de uso para cada una de las funciones mencionadas. En general,
casos de uso se escriben primero en un estilo narrativo informal. Si se requie:
mayor formalidad se rescribe el mismo caso de uso utilizando un formato estruc:.rado similar al propuesto en el captulo 7 y reproducido en esta seccin como t=:
recuadro.
Con fines ilustrativos, considrese la funcin "acceso a cmara de vigilancia-des
pliegue de vistas de cmara (ACV-DVC)". El interesado que desempea el papel de.
propietario podra escribir el siguiente relato:
CAPTULO 8
MODELADO DEL ANUSIS
205
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 usuario 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 cmara especifica 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 seleccionar "todas las cmaras" como mi opcin de visualizacin. Una vez que he seleccionado 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 "seleccionar una cmara" y la ventana de visin original desaparece y se despliega de nuevo el
plano de planta de la casa.
Una variacin del caso de uso relatado presenta la nteraccin como una secuencia
ordenada de las acciones del usuaro. cada accin se representa como un enunciado declarativo. Despus de vsitar la funcin ACV-DVC, se puede escrbir:
Caso de uso: Acceso a cmara de vigilancia-despliegue de vistas 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".
1O. 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 velocidad de un marco por segundo.
Es importante destacar que esta presentacin secuencial no considera algunas interaccones alternativas (la narrativa tiene un flujo ms lbre y representa unas cuantas altematvas). Los casos de uso de este tipo se refieren algunas veces como esce-
narios primarios [SCH98).

,,_._ . . uso pueden usarse en m11<hos procesos [de software]. Nuestro favorito es un pnceso que sea llerolhly
i!llllludd9 por tl riesp."
PARTE DOS
PRCTICA DE LA INGEN!EruA DEL SOF'IWAAE
Por supuesto, para una comprensin completa de la funcin que se pretende

cribir es esencial una descripcin de las interacciones alternativas. Por lo tanto "'
paso en el escenario primario se evala realizando las siguientes preguntas [SC.
Cmo se
examinan
ClfSOS
alteraatlvos dt
1<dn mientras
se desarrolla un
caso de uso?
El acto puede ejecutar otra accin en este punto?

Es posible que el actor encuentre alguna condicin de error en este punt..
es asl, cul podr!a ser?
Es posible que el actor encuentre algn otro comportamiento provocado
algn evento fuera de su control? Si es as, cul podrla ser?
El resultado de las respuestas a estas preguntas es la creacin de un conjum
escenarios secundarios que son parte del caso de uso original, pero que represe
comportamientos alternativos.
Por ejemplo, considrense los pasos 6 y 7 en el escenario primario presen
lneas atrs:
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 respuesta es: "s". Con refe
cia al relato de flujo libre, el actor puede elegir ver las vistas en miniatura de to
las cmaras de manera simultnea. Por ende, un escenario secundario podra ~
"Ver las vistas en miniatura de todas las cmaras".
Es posible que el actor encuentre alguna condicin de error en este punto? Cua,
un sistema basado en computadora est en funcionamiento puede ocurrir cualqu
cantidad de condiciones de error. En este contexto se consideran slo las conct..
nes de error que pueden ocurrir como resultado directo de las acciones descritas
los pasos 6 o 7. De nuevo, la respuesta a la pregunta es: "si". Puede ser que nun
se haya configurado un plano de planta con iconos de las cmaras. Por lo tanto
elegir "seleccionar una cmara" se produce una condicin de error: "no existe
plano de planta configurado para esta casa" . 12 Esta condicin de error se convie~..e
en un escenario secundario.
Es posible que el actor encuentre algn otro comportamiento en este punto-., ..

nuevo, la respuesta a la pregunta es: "s". Cuando se realizan los pasos 6 y 7 el st
tema puede encontrar una condicin de alarma. Esto podr!a resultar en que el sistc
ma desplegara una notificacin especial de alarma (tipo, ubicacin, accin del s.s
tema) y le proporcione al actor una serie de opciones relacionadas con la naturale
za de la alarma. Como este escenario secundario puede ocurrir para casi todas 1~
interacciones, no se convertir en una parte del caso de uso para el ACV-DVC. E.
12 En este caso, otro actor, el administrador del sistem a, 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.
CAPTULO 8
207
vez de eso, se desarrollar un caso de uso por separado -"condicin de alarma

encontrada"-, el cual estar referenciado a otros casos de uso, segn se requiera.
En relacin con las plantillas formales para los casos de uso que se muestran en
el recuadro, los escenarios secundarios se representan como excepciones a la
secuencia bsica descrita respecto al ACV-DVC.
Ca,o de uso: Aa:.eso o lo cmara
efe vigilancia.despliegue ele vistos

ele cdmQro (ACV-DVC).
Propietatjo
ltilMliilidio: Verla salidCI de lo cmaros
~ Q lo largo de lo coso
desde cuolquier ubicacin remoto
o 1rc1Ys de. Internet.
,n,ios: El ~ se d.be configutor por
completo; 1&dttben obtener ID y
contraseas apropiqdo$ poro los
usuarios.
El pn:,pietotio decide echarle un
yitozo o su tQ$0 rnienttOl se
.icuentrQ fur< de eUa.
....l,tlllllfNIIIIIMliC'1--tiAAldrl!l odlducuce:e su IO de U5UOrio.
S ~ introduce dos c:ontra$eo$ (codo uno
at metlOS oc.ho-corodtre$l,
1 l . El sistemo despliega lo solido d. video

ventano de visVQlizocin a un~-~
Excepciones:
controseas".
2. La ViCi6Ji de vigiktncio no est

este sistemo, a, que el tiuemo de.pliega
de error apropiado veose el coso de 1.IIO:
"con69uror lo fol)Cin de vigUancio".
3. El propietario selecxiono "Ver visk:1$ en mmtal\lf'o
poro tod0$ k1s c&motos; vclse et coso de ueo; -V.,.
vistos en miniatura paro toda, lo. cmoras"
4. No est di~ible un plano de ploofa o tte no se
ha configurado, osque el sistem despliega el
mensoje de error opropiodo; ~se el e@ clauso
configurar plono de lo coso".
5. Se encuentra ',lnQ wndicin de otonno; ve<IMt el
caso de uso; "<:onoiei6Ji de olOMIO encontmda" .
Prioridad:
Prioridad moderada, qlllt*

implementor ~ - de las
funciones bsicos.
Disponible en:
Frecuencia de uso:
El tercer n c ~ .
S I8lllm dasp.lliego todos los botones de lo$

ltJua'lci'Of'lelm$ imporlante$.
ltp-Of'i1t::n io .i.cciono "vigilancia" de los botones

de las funciones ms importantes.
S prcp;.ia,io selecciona "ekoger uno cmoran.
!I smemc:t cL.pliega el plc,no de la COSO,
EJ pnpelrio selecciono el cono de una cmoro del
plano de planto.
El ~ r i o wlecciona el botn "vi$1o".
El listelrlo despliega uno ventano de visuali-zoci6n
que est identiQcada con la ID ~ lo cmaro.
Poco fr$Cu..-,le.
Canal hacia el actor: A travs de un browser bosado en

PC y conexioo d Internet ot sitio
web de HogarSe,,guro.
Actores secundarios: Administrador del sistema,
cmaras.
Conales hacia los adores secundarios:
1. Administrador del sistema: sistemo bo,ado en PC,

2. Cmaros: conectividad inalmbrica
208
PARTE DOS PRCTICA DE LA !NGENIER!A DEL SOFTWARE
Aspedal pandientes
3.
Cu6I es el mecanismo qu protege contra el uso no

autorizado de esto capacidad por porte de los
empleados de lo cornpat0?
2 ala seguridad es wficlente? El ingreso no autorizado
en esta caraderistica representara uno invo~n
mpOrtanle de lo privacidad.
idi i:iid','1
(undo se hon
lemlalodo de lnlffllr los

cosos de tl!O? Paro una
exl)()Siun vol1oso de
esle Jpko, ffll5e
oelips.ettf
tstCOS8$101t,
Mlllootips."1f
al.o respuesto del sistema vio lntamet *6 . . . . . .

dado el ancho de bonda r.querido pGIQ lia Wllla
de crnora?
4. Se desarrollar uno oopacidad para picpaaaonar

video a uno kno mayor de cuodros por 1119"'*
cuando estn diSf)Ol'!ibles conexeone1 con . . ,
ancho de banda?
En muchos casos no es necesario crear una representacin grfica de un escerio de uso. Sin embargo, la representacin diagramtica puede facilitar la compre
sin, en particular cuando el escenario es complejo. Como se mencion en el ca1i
tulo 7, el UML proporciona una capacidad para hacer diagramas de casos de uso pi
liminar para el producto HogarSeguro. Cada caso de uso se representa mediante w
valo. En esta seccin slo se ha examinado en detalle el caso de uso para el AC\
ove.
IIS~.
......
8.5.2 Desarrollo de un diagrama de actividad

El diagrama de actividad en UML (que se trat en forma breve en los captulos 6 y
complementa el caso de uso al proporcionar una representacin grfica del flujo de in
raccin dentro de un escenario especifico. De manera similar al diagrama de llu
un diagrama de actividad utiliza rectngulos redondeados para indicar una funci
especifica del sistema, flechas para representar el flujo a travs del sistema, rombde decisin para mostrar una ramificacin por decisin (cada flecha que sale d
rombo se etiqueta). y lneas horizontales slidas para indicar que ocurren activid
des paralelas.
Diagrama
prellminar de
caso de uso
para el
sistema
HogarSeguro.
HogarSeguro
Cmaros
CAPTULO 8
209
Introducir contraseo - - - - - - - ~
e ID del usuario
Contraseas/ID vlidos
Contraseas/ID no vlidos
Tambin se pueden
seleccionar
otras funciones
Restan intentos
de entrado
Seleccionar uno
cmara especfico
Vistos en miniatura
er lo solida de u11a cmaro

en una ventano etiquetada
Opcin para
otro vista
Ver otro cmaro
En la figura 8. 7 se muestra un diagrama de actividad para la funcin de ACVDVC. se debe resaltar que el diagrama de actividad agrega detalles adicionales que
no se mencionan de manera directa (pero s implcita) en el caso de uso. Por ejemplo, un usuario puede intentar ingresar la IDusuario y la contrasea slo un nmero limitado de veces. Esto se representa mediante un rombo de decisin debajo de
opcin para reingreso.
8.5.3 Diagramas de carril

El diagrama de carril de UML es una variacin til del diagrama de actividad, ya que
permite al modelador la representacin del flujo de actividades descritas por el caso
de uso y, al mismo tiempo, indicar qu actor (si hay mltiples actores involucrados
en una funcin especfica) o clase de anlisis tiene la responsabilidad de la accin
descrita mediante un rectngulo de actividad. Las responsabilidades se representan
210
PARTE DOS PRCilCA DE LA INGENIERA DEL SOF1WARE
Diagrama de ccmil para la funcin de Acceso a la cm<Ua de vigilancia-despliegue dlt

vistas de cm<Ua.
Propietario
Introducir contraseo
e ID del suorio
Cmara
Interfaz
--------+----------+--------------.
Controseos/lD vlidos
Seleccionar na
funcn importante
Tambin se
pueden
seleccionar . - - - ~ - - - airas
Seleccionar vigiloncio
funciones
Opcin poro reingreso
Vistos en
Generar salido
de video
Visto de solida de cmara
en uno ventana eti uetodo
Ver otro
cmoro
--,
&~
C~VE
lm~de
enUML
~elllujode
ma:aones y las
decisixles e indico
dmlWGll
deeh
como segmentos paralelos que dividen el diagrama en forma vertical, como los
carriles de una alberca.
Exislen lres clases de anlisis - Propietario, Inteaz y Cmara- con responsabilidades directas o indirectas en el contexto del diagrama de actividad representado
en la figura 8.7. Respecto de la figura 8.8, el diagrama de actividad se reorganiza de
forma que las aclividades asociadas con una clase de anlisis particular pertenezcaJl
al carril correspondiente a dicha clase. Por ejemplo, la clase Interfaz representa la
interfaz con el usuario de acuerdo con la visin del propietario. El diagrama de actividad considera dos opciones que son responsabilidad de la interfaz: opcin para el rem-
CAPTULO 8
MODELADO DEL ANUS!S
211
greso y opcin para otra vista. Estas opciones y las decisiones asociadas con ellas per-
tenecen al carril de Interfaz. Sin embargo, las flechas conducen desde ese carril de
regreso al carril de propietario, donde ocurren las acciones del propietario.
El modelado de datos orientado al flujo es una de las notaciones de anlisis utilizadas con mayor amplitud en la actualidad. 13 Aunque el diagrama de flujo de datos
(DFD) y los diagramas y la informacin relacionados no son una parte formal de
UML, pueden utilizarse para complementar los diagramas en UML y proporcionar un
conocimiento adicional de los requisitos y el flujo del sistema.
El DFD tiene una visin del sistema del tipo entrada-proceso-salida. Esto es, los
objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento, y los objetos de datos resultantes fluyen al exterior del
software. Los objetos de datos se representan mediante flechas rotuladas y las transformaciones se representan por medio de crculos (tambin llamadas burbujas). El
DFD se presenta en una forma jerrquica. Esto es, el primer modelo de flujo de datos
(algunas veces llamado un DFD de nivel O o diagrama de contexto) representa el sistema como un todo. Los diagramas de flujo de datos subsecuentes refinan el diagrama de contexto, ya que proporcionan una cantidad creciente de detalles con cada
nivel subsiguiente.
e propsito de los diogrQIJ)Os de flujo de datos es proporcionar un puente semntico entre los usuo(ros ylos
'
-.,olfadores de sistemas.
8.6.1
Creacin de un modelo de flujo de datos
El diagrama de flujo de datos permite que el ingeniero de software desarrolle modelos del dominio de informacin y del dominio funcional al mismo tiempo. A medida
que el DFD se refina hacia grados mayores de detalle, el analista desempea una
descomposicin funcional implcita del sistema. Al mismo tiempo, el refinamiento
del DFD resulta en un correspondiente refinamiento de datos mientras se mueve
hacia los procesos que incorporan la aplicacin
Unas pocas directrices simples permiten obtener una ayuda invaluable durante la
creacin de un diagrama de flujo de datos: 1) el nivel Odel diagrama de flujo de datos
debe representar al software/sistema como una sola burbuja; 2) la entrada y la salida primaria deben establecerse con cuidado; 3) la refinacin debe comenzar por el
aislamiento de procesos, objetos de datos y almacenamientos de datos candidatos a
ser representados en el siguiente nivel; 4) todas las flechas y burbujas se deben rotular con nombres significativos; 5) se debe mantener la continuidad del flujo de infor-
13 El modelo de flujo de datos es una actividad de modelado esencial en el anlisis estructurado.
212
PARTE DOS PRcnCA DE LA INGENIER!A DEL SOFTWARE
iihiiKi
DFDalnlvel
Panel
de contexto
de control
para la
Oesplegue
delpoi,el
de control
funcin de
seguridad de
HogarSeguro.
Sen10tt1$
~~
'*'
c&v1
lo continuidod del fluo
de informacin debe
montene~ conforme
se refino codo nivel del
DFD. Esto significo que
lo entrado ysolido en
oo nivel deben ser los
mismas 11J8 lo entrodo
y soillo en un nivel
refinado.
lneio
telelni<:o
macin al cambiar de nivel a nivel; 14 y 6) la refinacin de las burbujas debe hacerse

una por una. Existe una tendencia natural a complicar de ms el diagrama de flu
de datos. Esto ocurre cuando el analista intenta mostrar muchos detalles demas.a
do pronto o representar aspectos de procedimiento del software en lugar de elementos del flujo de informacin.
El uso del DFD y de la notacin relacionada se ilustra de nuevo considerando l.:
funcin de seguridad en el hogar de HogarSeguro. En la figura 8.9 se muestra un DFC
al nivel de contexto para la funcin de seguridad. Las entidades externas primari~
(cajas) producen informacin para el uso del sistema y consumen informacin que
ste genera. Las flechas rotuladas representan objetos de datos o jerarquas de objetos de datos. Por ejemplo, comandos y datos del usuario abarcan todos los
comandos de configuracin, todos los comandos de activacin/desactivacin. todas
las interacciones y todos los datos que se ingresan para calificar o expandir ur
comando.
El DFD de nivel o ahora se expande a un modelo de flujo de datos de nivel J. Pero
cmo se logra esto? Un enfoque simple, pero efectivo, es realizar un "anlisis gramatical" [ABB83] sobre la narrativa que describe la burbuja al nivel de contexto. Esto
es, se aslan todos los sustantivos y verbos en la narrativa de procesamiento de
HogarSeguro 15 obtenida durante la primera reunin para la recopilacin de requisitos. Con propsitos ilustrativos. considrese el siguiente texto narrativo de procesamiento con la primera aparicin de todos los sustantivos subrayados y la primera
aparicin de todos los verbos en itlicas. 16
14 Esto es, los objetos de datos que fluyen hacia el sistema o cualquier transformacin en algn nivel
deben ser los mismos objetos de datos (o sus partes constituyentes) que fluyen hacia la transformacin en un nivel ms refinado
15 Una narrativa del procesamiento es similar en estilo al caso de uso, pero algo diferente en propsito. La narrativa del procesamiento proporciona una descripcin general de la funcin que ser desarrollada. 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 ingerencia directa en el proceso de modelacin. Tambin se debe notar que, cuando se considere el modelado basado en clases de la seccin 8.7, se usar un anlisis gramatical similar.
CAPiTtJLO 8 MODELADO DEL ANLISIS
213
La funcin de seguridad de HogarSeguro pennite al propietario configurar el sistema de segwidad 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 ;,_anel
de control.
Durante la jnstalacjn, la PC de HogarSeguro se utiliza para programar y configurar el
.si.st.e.J:na. A cada sensor se le asigna un n.r:nerQ y lilo, se programa una contrasea ma~ 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 solidta una a!arma audjb!e
que el propietario especifica durante las actividades de configuracin del sistema, el software marca el nmero telefnico de un servicio de monitoreo, propordona 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 jnformacjn 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 mensajes de opcin e ioformacjn de) estatus del sistema en el panel de control, la PC o la ventana del buscador. La interaccin del propietario asume la siguiente forma ...
En relacin con el anlisis gramatical comienza a surgir un patrn. Los verbos son
los procesos de HogarSeguro; esto es, al final pueden representarse como burbujas
en un DFD subsecuente. Los sustantivos son entidades externas (cajas), objetos de
datos o de control (flechas), o almacenamientos de datos (lneas dobles). Despus
debe observarse que los sustantivos y verbos se puedan asociar de distintas formas
Informacin
del sensor
Sensore$ - - ---,
Esta tus
del sensor
Alarmo
Tipo de alarma
Tonos del nmero
telefnico
linea
telefnico
214
PARTE DOS
PRCTICA DE LA INGENIEl'lA DEL SOFTWARE
iiPiii
DFD de nivel 2
que refina el
proceso de
mortoreo
de sensores.
tcoNSIJOS.
Se debe tener lo
seguridad de que todo
lo narroffva de procesamiento que se
intento ano/izar est
esaito con el msmo
grodo de abstrocd6n.
entre s. Por ejemplo, a cada sensor se Je asigna un nmero y un tipo; por lo tant
el nmero y el tipo son atributos del objeto de datos sensor. Entonces, al realizar uanlisis gramatical sobre la narrativa de procesamiento para una burbuja en cua
quier nivel del DFD, se puede generar mucha informacin til acerca de cmo pr
ceder con la refinacin para el siguiente nivel. En la figura 8.10 se presenta un DFt
de nivel I para el cual se ha utilizado esta informacin. El proceso al nivel de co
texto mostrado en la figura 8.9 se ha expandido a seis procesos obtenidos de un ex:!
men del anlisis gramatical. De manera similar, el flujo de informacin entre los pr
cesos en el nivel I ha sido obtenido del anlisis. Adems, se mantiene la continu
dad del flujo de informacin entre los niveles O y 1.
Los procesos representados en el DFD de nivel 1 se refinan despus hacia nivel~
ms bajos. Por ejemplo, es posible refinar el proceso monitorear sensores hacia ur
DFD de nivel 2 como se muestra en la figura 8. 11. De nuevo, debe sealarse que St.
mantiene la continuidad del flujo de informacin entre los niveles.
La refinacin de los DFD contina hasta que cada burbuja realiza una sola fun cin; es decir, hasta que el proceso que representa la burbuja desempee una funcoque podra implementarse con facilidad como un componente de programa. En e
capitulo 9 se examina un concepto, llamado cohesin, con el cual se evala ta sill'plicidad de una funcin dada. Por ahora, se busca refinar los DFD hasta que cada
burbuja tenga "un solo significado".
8.6.2 Creacin de un modelo de control del flujo

En muchos tipos de aplicaciones el modelo de datos y et diagrama de flujo de datos
son todo lo que se necesita para obtener una visin significativa de los requisitos de
CAPTULO 8
215
software. Sin embargo, como ya se ha mencionado, existe una clase muy grande de
aplicaciones que estn guiadas por eventos en lugar de datos, que producen informacin de control en lugar de reportes o despliegues, y que procesan informacin
con un especial inters por el tiempo y el rendimiento. Dichas aplicaciones requieren aplicar el modelado de control deljlujo, adems del modelado del flujo de datos.
Ya se ha mencionado que un evento o elemento de control se implementa como
un valor booleano (por ejemplo, verdadero o falso, encendido o apagado, I o O) o
una lista discreta de condiciones (vaco, saturado, lleno) . En la seleccin de los eventos que son candidatos potenciales se sugieren las siguientes directrices:
Hacer una lista de todos los sensores que el software "lee".
Listar todas las condiciones de interrupcin.
Listar todos los "interruptores" que maneja un operador.
Listar todas las condiciones de datos.
De acuerdo con el anlisis de sustantivos y verbos aplicado a la narrativa de
procesamiento, revisar todos los "elementos de control" como posibilidades
de entradas y salidas del control de flujo.
Describir el comportamiento de un sistema mediante la identificacin de sus
estados; determinar el grado en el que se alcanza cada estado, y definir las
transiciones entre los estados.
Enfocarse en posibles omisiones -un error muy comn al especificar el
control-; por ejemplo, se puede preguntar: "existe alguna otra manera de
alcanzar este estado o salir de l?".
8.6.3 Especificacin de control

La especificacin de control (EC) representa el comportamiento del sistema (en el
nivel desde el cual est referido) de dos maneras diferentes. 17 La EC contiene un diagrama de estado que es una especificacin secuencial del comportamiento. Tambin
puede contener una tabla de activacin del programa: una especificacin combinatoria del comportamiento.
En la figura 8.12 se muestra un diagrama de estado preliminar 18 para el modelo
de control del flujo en el nivel l para HogarSeguro. El diagrama indica cmo responde
el sistema a diferentes eventos conforme ste atraviesa los cuatro estados definidos
en este nivel. Al revisar el diagrama de estado, un ingeniero de software puede
determinar el comportamiento del sistema y, an ms importante, puede encontrar
si existen "hoyos" en el comportamiento especificado.
17 Despus, en este mismo captulo, se presenta notacin adicional para el modelado del comportamiento.
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 representaaon de informacin
216
PARTE DOS PRCTICA DE LA INGENJERiA DEL SOF1WARE
,j.f .., f
Diagrama de estado para la funcin de segurtdad de HogarSeguro.
Sstemo
cooeelo
it.lnlc1o
lntemiplor
inicio/ poro,
enc8'1d1do
Ellalussisleffla itl<Jdivo"
Entror/1NCt0 deJpf eg..-M.naote1
"lnielondo $1Sltffl0'
Entror/in,c,or de$f)l"'SueMen,oe2
'Por favor e1pei.
Entro,/Iniciar <IMphegueEstotu, deslello
lento
Hocer correr diognsticcs
fnlrat/JIUC,O,
Retntcio
Entrar/inor E>1atuuimmo ,noctfvo"

En1ror/moc,ar dapliegoeMenso.l us1o
Entror/,nidor desptteg.,..M8'1So,.2
Entr111/1nielor desplieguehlolus e,table
G9lf*ieieelo/Tedodemoneo
opogodo/con4fol
FolloDetectodo/ iniciar
despliegveMensoje2 contoctor
ol Vendedor'
Afxi9odo
de,ocilvorControseo
Entror/1ru<:1or Estotusmltmo montoqo'

Enltor/,n1C1<1r E>1o1uw,le1M
Entror/inlcior despliegveMeMQjil l Armodoi-__::ti:::;em=.:,;ue::;ro"-1 monuor.aYAlarma
Entror/,nleiqr de,pl,egueMensoiil2 "

Enlror/inicior d&Splleguel:llotvs es1oble
Hoce< mon-YCotltrola<Sislllmo
Go1-....1~1o ,,._,...,____
En1!9r/inlclor despli~iltMtnsoe 1
"Al.ARMA"
1 - - - - - - - i Enlror/,nicior desplir,gveMensoe2
senso>isporodo/ duporodor~IIO<
...__...........
_ _ _, ......,.......
__ _
-_-,~_ _ ___, inicioTemporizodor
Entror/,nie,or de.pl,eguel;S1Ql111
Dewllorapido
Hocer. mon,IOreorYControlorS,stema
Hocer: ,onidodeAlom,q
Hacer: notifico1Re,puestaAlcumo
G<ilpedeleck,/fed<>demone o
sen,orOi,porodo/
reinicioTemporizador
Por ejemplo, el diagrama de estado (figura 8.12) indica que las transiciones des.Je
el estado desocupado pueden ocurrir si el sistema se reinicia, activa o apaga. Si el s
tema se activa (es decir, se enciende el sistema de alarma) ocurre una transick
hacia el estado MonitoreoEstarusSistema. los mensajes que se despliegan cambi~
como se muestra, y se solicita el proceso SistemaContro!JIMonitoreo. Con el estaMonitoreo Stratus Sistema ocurren dos transiciones: 1) al desactivar el sistema se pre:
senta una transicin de regreso al estado desocupado; 2) cuando se dispara un ser
sor ocurre una transicin hacia el estado AccinEnAlarma. Durante la revisin s
consideran todas las transiciones y el contenido de todos los estados.
HOGARSEGURO
Modelado deljl.ujo de datos

La convenacin:
(Jomie ho bosquejado los modelo5 que se 111Ulll11 en
los figures 8.9, 8 10, 8.11 y 8.12 y se lolll'IU8IRlo
Vinod).
Jamie: Tom un cuno de ingenierfa del softwrn lft la
universidod, 'f
oprand esta$ QOIGS S ~
ani
CAPTULO 8
217
Ecl: 2De verdad,

Jamie: S, pero primero debemosaealCll'nJM
de anlisis completo, y ste no
lo
Jcnnle (con -..1: Yo

Doug: Bien, .tenemos rm.rdt.
mucho riempo pc;ara hacedo.
La EC describe el comportamiento del sistema, pero no brinda informacin acerca del trabajo interior de los procesos que activa. La notacin de modelado que proporciona esta informacin se estudia en la seccin 8.6.4.
8.6.4 Especificacin de proceso

La especificacin de proceso (EP) se utiliza para describir todos los procesos del
modelo de flujo que aparecen en el nivel final de refinacin. El contenido de la especificacin de proceso puede incluir texto narrativo, una descripcin en lenguaje de
diseo de programas (LDP) 19 del algoritmo del proceso, ecuaciones matemticas,
tablas, diagramas o grficas. Al proporcionar una EP para acompaar cada burbuja
en el modelo de flujo, el ingeniero de software crea una "miniespecificacin" que
puede servir como gua para el diseo del componente del software que implementar el proceso.
Para ilustrar el uso de la EP, considrese la transformacin procesamiento de contrasea representada en el modelo de flujo para HogarSeguro (figura 8. 10). La EP para
esta funcin podra tomar la forma:
EP: procesamiento 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 se19 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.
218
PARTE DOS PRCTICA DE LA INGCNJERiA DEL SOF'JWARE

guridad de HogarSeguro. El procesamiento de contrasena recibe una contrasea de cuatro
dgitos a partir de la funcin de mteracon con el usuano. La contrasea se compara primero con la contrasea maestra almacenada en el sistema. Si la contrasea maestra coincide [Mensaje de ID vlida = verdadero] se pasa a la funcin de mensaje y despliegue del
estatus. Si la contrasea maestra no coincide, se comparan los cuatro dlgitos con una tabla de contrasenas secundarias (stas se pueden asignar a invitados o trabajadores que
necesitan entrar en la casa cuando el propietario no est). Si la contrasea coincide con
alguna entrada dentro de la tabla [mensaje de Id vlida = verdadero]. se pasa a la funcin
de mensaje y despliegue del estatus. Si no existe alguna coincidencia mensaje de Id vlida
= falso], se pasa a la funcin de mensaje y despliegue del estatus.
Si en esta etapa se desean tener detalles algortmicos adicionales, se podra inclu

tambin una representacin en lenguaje de diseo de programas como parte de la
EP. Sin embargo, muchos profesionales del software creen que la versin en LDP se
puede posponer hasta que comience el diseo de componentes.
Anlisis estructurado
Objetivo: Las herramientas del anlisis
estructurado ayudan a un ingeniero de software
a crear modelos de datos, modelos de Rujo 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 a
eliminar errores antes de que stos se propaguen en el
diseo o, aun peor, en la misma implementacin.
Mecnica: Las herramientas de esta cotegora utilizan un
"diccionario de datos como la base de datos central poro
la descripcin de todos los objetos de datos. Una vez que
las entradas del diccionario estn definidos, pueden
crearse diagramas de entidod-relacin y se pueden
desarrollar las jerarquas de objetos. Las coroctersticos de
diagramacin del Rujo de datos permiten crear fcilmente
este modelo grfico y tambin proporciono caractersticos
poro 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
diagramas de estado como notacin operativa.
AxiomSys, desarrollado por STG, lnc. (www.stgcase.com),
proporciona un paquete completo de herramientas
poro el anlisis de la estructura que incluye extensiones
de HorrleyPirbhoi poro el modelado de sistemas en
tiempo real.
MacA&D, WinA&D, desarrollados por Excel Software
(www.excelsoftware.com), proporcionan un conjunto

de herramientas simples y barotos poro el anlisis y el
diseo en mquinas Moc y Windows.
MetoCASE Workbench, desarrollado por Metocose
Consulting (www.metacose.com) es una
metaherramienta utilizada poro definir un mtodo de
anlisis o diseo (incluido en anlisis estructurado): sus
conceptos, regios, notaciones y generadores.
Sysfem Architect, desarrollado por Popkin Software

(www.popkin.com), proporciono un amplio rango de
herramientas de anlisis y diseo, incluye herramientas
poro el modelado de datos y el anlisis estructurado.
20 Las herramientas mencionadas aqu representan una muestra de esta categora. En la mayora de
los casos los nombres estn registrados por sus respectivos desarrolladores.
CAPTULO 8
219
Qu se debe hacer para desarrollar los elementos basados en clases de un modelo

de anlisis: clases y objetos, atributos, operaciones, paquetes, modelos CRC y diagramas de colaboracin? Las secciones siguientes presentan una serie de directrices
informales que ayudarn a identificarlos y representarlos.
8. 7 .1 Identificacin de clases de anlisis

Al observar el interior de una habitacin se ver que existe un conjunto de objetos
fisicos que pueden identificarse, clasificarse y definirse con facilidad (en trminos de
atributos y operaciones). Pero cuando se "observa" el espacio del problema de una
aplicacin de software, quiz las clases (y los objetos) sean ms dificiles de comprender.
e problema realmente difi<il es descubrir cules son los objetos correctos [clases] en primer lugar/
CarlAtglci
Se puede iniciar la identificacin de clases al examinar el enunciado del problema o (de acuerdo con la terminologia aplicada previamente en este captulo) al realizar un "anlisis gramatical" sobre las narrativas desarrolladas para el sistema que
se va a construir o de los casos de uso. Las clases se determinan al subrayar cada
sustantivo e introducindolas en una simple tabla. Los sinnimos deben anotarse. Si
la clase se requiere para implementar una solucin, entonces es parte del espacio de
solucin; por otro lado, si una clase slo se necesita para describir una solucin es
parte del espacio del problema. Qu se debe buscar despus de que todos los sustantivos han sido aislados? Las clases se manifiestan en una de las siguientes formas:
Entidades externas (por ejemplo, otros sistemas, dispositivos, personas) que

producen o consumen informacin que usar un sistema basado en computadora.
Cosas (por ejemplo, reportes, despliegues, letras, seales) que son parte del
dominio de la informacin para el problema.
Sucesos o eventos (por ejemplo, una transferencia de propiedad o la consecucin de una serie de movimientos de robot) que ocurren dentro del contexto
de la operacin del sistema.
Papeles (por ejemplo, gerente, ingeniero, personal de ventas) que desempean

personas que interactan con el sistema.
Unidades organizacionales (por ejemplo, divisin, grupo, equipo) relevantes

para alguna aplicacin.
Sitios (por ejemplo, el piso de manufactura o el puerto de carga) que establecen el contexto del problema y la funcin global del sistema.
PARTE DOS
Estructuras (por ejemplo, sensores, vehculos de cuatro ruedas o computadoras

que definen una clase de objetos o clases de objetos relacionadas.
Esta categorizacin es una de las muchas que se han propuesto en la bibliografa
Por ejemplo, si los desarrolladores del software para un sistema de observaci:
mdica definen un objeto con el nombre de Imageninvertida o lnversindelmagea.
podran estar cometiendo un error sutil. La Imagen obtenida del software po~
por supuesto, ser una clase (es una cosa integrante del dominio de la informacin
La inversin de la imagen es una operacin que se aplica a la clase. Probablemente
la inversin() se definira como una operacin para la clase Imagen, pero no se establecera como una clase diferente para connotar "inversin de imagen". Como establece Cashman [CAS89J: "El objetivo de la orientacin hacia los objetos es encapsLlar, pero aun as mantener separados, los datos y las operaciones sobre los datos
Para ilustrar la forma en que las clases de anlisis pueden definirse durante la;
primeras etapas del modelado, se utiliza de nuevo la funcin de seguridad d<:
HogarSeguro. En la seccin 8.6.1 se realiz un "anlisis gramatical" sobre la narrativa del procesamiento22 para la funcin de seguridad. Al extraer los sustantivos Se
puede proponer una serie de clases potenciales:
Clase potencial
Clasificacin general
propietario
papel o entidad externa
sensor
entidad externa
panel de control
entidad externa
instalacin
ocurrencia
sistema [alias sistema de seguridad)
cosa
nmero, tipo
no objetos, atributos del sensor
contrasea maestra
cosa
nmero telefnico
cosa
evento del sensor
ocurrencia
alarmo audible
entidad externa
servicio de monitoreo
unidad organizacional o entidad externa
La lista podra extenderse hasta que todos los sustantivos en la narrativa del proce-
samiento hayan sido considerados. Obsrvese que cada entrada en la lista ha sido
21 Otra categorizacin importante -la cual define entidad, frontera y clases de controlador- se examina en la seccin 8.7.4.
22 Es importante notar que esta tcnica debe usarse tambin para todos los casos de uso desarrollados como parte de la actividad para la recopilacin de requisitos (obtencin). Esto es, los casos de
uso pueden analizarse gramaticalmente para extraer clases de anlisis potenciales.
CAPTULO 8
221
llamada como un objeto potencial. cada uno de ellos debe considerarse a fondo
antes de tomar una decisin final.
Les luchan, olgunas doses lriunlon, otros son eliminados."

'
Coad y Yourdon [COA91] sugieren seis caractersticas de seleccin que se deben

usar cuando un analista considera cada clase potencial para incluirlas en el modelo
de anlisis:
1. Informacin referida. La clase potencial ser til durante el anlisis slo si la

informacin acerca de ella debe recordarse para que el sistema pueda funcionar.
2.
Servidos requeridos. La clase potencial debe tener un conjunto de operaciones

identificables que puedan cambiar el valor de sus atributos de alguna manera.
3.
Atributos mltiples. Durante el anlisis de requisitos el enfoque debe estar en

la informacin "importante"; una clase con un solo atributo puede, de hecho,
ser til durante el diseo, pero probablemente es mejor representarla como
un atributo de otra clase durante la actividad de anlisis.
4.
Atributos comunes. Es posible definir un conjunto de atributos para la clase

potencial, y estos atributos pueden aplicarse en todas las instancias de la
clase.
5.
Operadones comunes. Es posible definir un conjunto de operaciones para la

y estas operaciones pueden aplicarse en todas las instancias
clase potencial,
de la clase.
6.
Requisitos esenciales. Las entidades externas que aparecen en el espacio del

problema, y que producen o consumen informacin esencial para la operacin de cualquier solucin para el sistema, se definirn casi siempre como
clases en el modelo de requisitos.
Considerarla una clase legtima para incluirla en el modelo de requisitos requiere

que una clase potencial satisfaga todas (o casi todas) estas caractersticas. La decisin de incluir clases potenciales en el modelo de anlisis es algo subjetiva, y una
evaluacin posterior puede ocasionar que se descarte o reinstale una clase. Sin
embargo, el primer paso del modelado basado en clases es la definicin de clases. y
se deben tomar decisiones (incluso subjetivas). Con esto en mente, se aplican las
caractersticas de seleccin a la lista de clases potenciales de HogarSeguro:
Clase potencial
Nmero de caracterstica que aplica
propietario
rechazado , 1 y 2 lallon aunque aplica 6
sensor
aceptado loOas aplican
panel de control
aceptado todas aplican
PARTE DOS
PRCTICA DE LA INGENIERA oa SOFTWARE
instalacin
rechazado:
sistema (alias funcin de seguridad)
aceptada: todos aplican
nmero, tipo
rechazada: falla 3. atributos del sensor
contrasea maestra
rechazada: falla 3
nmero telefnico
rechazado: falla 3
evento del sensor
aceptada: todas aplican
alarma audible
aceptado: aplican 2, 3, 4, 5. 6
servicio de monitoreo
rechazado: 1 y 2 fallan aunque aplico 6
se debe sealar que l) la lista anterior no est completa (se tendran que agregar
ses adicionales para terminar el modelo); 2) algunas de las clases potenciales rec
zadas se convertirn en atributos para las clases aceptadas (por ejemplo, n ~
tipo son atributos de sensor, y contrasea maestra y nmero telefnico se pueden COfl'
tiren atributos de sistema); 3) la existencia de enunciados diferentes del proble
podra ocasionar decisiones distintas de "aceptacin o rechazo" (por ejemplo, si a
propietario tuviera una contrasea diferente o si pudiera identificarse por su voz
clase Propietario satisfara las caractersticas l y 2 y sta habra sido aceptada
8. 7 .2 Especificacin de atributos
Los atributos describen una clase que ha sido seleccionada para incluirla en
modelo de anlisis. En esencia, los atributos son los que definen la clase, lo cual c -
los atributos son el

conjunto de objetos de
datos que definen por
completo lo clase
dentro del contexto del
problema.
rifica qu significa la clase en el contexto del espacio del problema.

En el desarrollo de un conjunto de atributos significativo para una clase de ana..
sis un ingeniero de software puede estudiar de nuevo un caso de uso y seleccion::.;
aquellas "cosas" que "pertenecen" de manera razonable a la clase. Adems, se deb..
contestar la siguiente pregunta para cada clase: Cules elementos de datos (corr
puestos o elementales) definen esta clase en el contexto del problema?
Esto se ilustra considerando la clase sistema definida para HogarSeguro . Se h.:
mencionado que el propietario puede configurar la funcin de seguridad para reflejar la informacin del sensor, informacin de la respuesta de alarma, informacin de
la activacin/desactivacin, informacin de la identificacin, y as sucesivamente
Estos elementos de datos compuestos se pueden representar de la siguiente manera
informacin de identificacin
= ID del sistema + verificacin del nmero telefnico + estatus
del sistema
informacin de la respuesta de alarma
= tiempo de retraso + nmero telefnico

= contrasea maestra + nmero de intentos permi-
informacin de la activacin/desactivacin
sibles
contrasea temporal
Algunos de los datos a la derecha del signo de igual podran refinarse hasta un nivel
elemental. pero para los propsitos de este captulo constituyen una lista razonable
de atributos para la clase sistema (parte sombreada de la figura 8.13) .
223
CAPrruLO 8 MODELADO DEL ANLISIS
Los sensores son parte del sistema global de HogarSeguro, y aun as no estn enlistados como elementos de datos o como atributos en la figura 8.13. Ya se ha definido sensor como una clase, y varios objetos de sensor se asociarn con la clase
sistema. En general, se evita la definicin de un elemento como un atributo si ms
de uno de los elementos se asociar con la clase.
8.7.3 Definicin de operaciones

Las operaciones definen el comportamiento de un objeto. Aunque existen muchos
tipos distintos de operaciones, stas se pueden dividir, por lo general, en tres grandes categoras: I) operaciones que manipulan los datos de alguna manera (por ejemplo, al agregar, borrar, reformatear, seleccionar), 2) operaciones que realizan un
cmputo, 3) operaciones que preguntan acerca del estado de un objeto, y 4) operaciones que monitorean un objeto para la ocurrencia de un evento de control. Estas
funciones se ejecutan al operar sobre atributos o asociaciones (seccin 8.7.5). Por lo
tanto, una operacin debe tener "conocimiento" de la naturaleza de los atributos y
asociaciones de la clase.
Como una primera iteracin en la obtencin de un conjunto de operaciones para
una clase de anlisis, el analista puede estudiar otra vez la narrativa de un procesamiento (o caso de uso) y seleccionar aquellas operaciones que pertenezcan de
manera razonable a la clase. Esto se logra estudiando de nuevo el anlisis gramatical y aislando los verbos. Algunos de estos verbos sern opciones legtimas y podrn
conectarse con facilidad a una clase especfica. Por ejemplo, en la narrativa del procesamiento presentada prrafos atrs en este captulo, se observa que "al sensor se
le asigna un nmero y un tipo" o "se programa una contrasea maestra para habilitar y deshabilitar el sistema". Estas frases indican algunos hechos:
Sistema
ID sistema
verificacinNmeroTelefnico
E$fa1Ussistema
Ttemporetraso
Nmerotelefnico
Conlrasearnaestra
Contrmealempol al
Nmerodeintentos
programar( )
desplegar( )
reiniciar( )
buscar()
modificar( )
llamar()
PARTE DOS
224
PRCTICA DE LA INGENIERIA DEL SOFTWARE
Que una operacin de asignar() es relevante para la clase sensor.

Que una operacin de programar( ) est encapsulada por la clase sistema.
Que habilitar() y deshabilitar() son operaciones que se aplican a la clase
sistema.
En una investigacin posterior tal vez la operacin programar() sea dividida er
serie de suboperaciones ms especficas que se requieren para configurar el sist...
Por ejemplo, programar() implica la especificacin de nmeros telefnicos, la
guracin de caractersticas del sistema (como al crear la tabla de sensores, al t
ducir las caractersticas de la alarma) y la introduccin de contrasea(s). Sin em
go, por ahora programar() se especifica como una sola operacin.
HOGARSEGURO
Modelos de clase
El escenario: Cubculo de Ed, al
comenzar el modelodo del onlisis
de estos paredes. 8Cmo sabe el plano de pl.JnfQ

colo<:or esos obilos~
LN
Jamie, Vinod y Ed, miembros del equipo
de ingeniera del $0twore de HogorSeguro.
Ed: No lo sob&, pero las otros dcues si Miren los

atributos de obojo, di90~, ~ cuales se vson poro construir una pared El t49'**>
pared hene unos coordenodas de ,n,cio y MOi, y fo
operacin de dibujo{ Jhace el reslo
---=
La conwnadr.:
(Ed ha estado troborondo ~ lo e.xtracxin de clases o

de lo plontiUo ele coso ele uso poro el "Acceso a
lo cmaro ele vigilanciadespllitgue de vistas
c6mara" {preseniodo en un rcuodro anterior en
.a. aipitulo] y est mostrando o sus colegas las do$eS
que ha extrado.
lcl: Entonces cuando el prop1etorio quiere escoger una

c::imara l o ella debe elegirla ele un plano de planto He
cWinido uno clase llamado PlanodePlanto. Aqu e$t6
d'IDgl'ama
Ed: SI, los necesito poro poder dar lo io5ormaci6n del

movimiento y el acercamiento.
Vinod: Tengo vna pregvnlo iPor qu lo cmcw tiene
uno ID, pero las otros doses no?
Ed: Vamos a necesilor idntificar cada cmar pcwo

propsitos del despliegue.
(Todos mtran la figura 8.14.)
Jamlei Entonces PlanodePlanto 6$ uno dos.e que se

a las paredes que e$ln compuestos por segmentos
pared puertas y venlonos, y tambin las cmoras;
ao lo que significan esos lneas etiquetados, no?
esas lineas se llaman "asociaciones. las clases
asociadas entre s de acuerdo CQO los asociaciones
1111 he mostrado. (las asociaciones HI estudian en la
8 51
. . . . &mnces el plano de planta real est hecho de

CIOllliene c:arnaros y
Jamie: Y lo mismo paso poro las pue;tas y.......,_._

Parece como si las cmoros tuvieran unos poc:iouie
atribulo$ extra
sensores colocados dentro
Ja,,_: Tiene sentido para m,, pero tengo olgunca

preguntas. (Jomie hace preguntas que resullan en
modificacon9$ menor9$ )
Vinod: Tien~ 1orjetas CRC paro cada una ele ems

dosesa Si es as, debemos seguirlas, slo hay que 4Niar
seguros de que no $8 ha Offllticlo nado.
Ed: No estoy seguro de cmo haaKb

Vinocl: No es difcil, y los resultodos son rrtl/'f buenot.
Les mostrar.
CAPTULO 8
225
PlanodePlanta
tipo
nombre
Oimensionesexternas
determinarTipo()
posiciQnarPlanodePlanta( )
escalar()
cambiar color{ )
Se ubica dentro de
...
Es porte de
Cmara
Pa.-.d
fi
lis'
tJbicadn
~nsionespared
tmpodeVisln
g~eTamo
Con urOCl'I
Acercamiento
determlnarfipo(
lroducirUbic0<:1 ni )
despie9arlD( )
de=arVlsto()
de
rAcereomienlo(}
dewminarTipo()
~lcularDimens1ones{ J
Se usa para
construir
Se usa para
construir
Se usa poro construir
1
5'gmento
de Pared
Ventano
tipo
Coordllnq(jainicio
COfdenodQ,final
SlgvlenteSegmento
Pared
determioarTipo( )
dibujar
...
determinarTipo( }
dibujar
Ventona
tipo
Coordeoadosintco
Coord&nadasfilll
SiguienteVentooo
'
tipo
Coordenada$inld
Coorde.nadofincil
Slgueni.Pl.lrta
determinarTipo(J
dibujar
8. 7 .4 Modelado de Clase-Responsabilidad-Colaborador (CRC)

El modelado de aase-Responsabilidad-Colaborador (CRC) [WIR90J proporciona un
medio simple para identificar y organizar las clases relevantes para los requisitos del
sistema o producto. Ambler [AMB95J describe el modelado CRC de la siguiente
forma:
Un modelo CRC en realidad es una coleccin de tarjetas ndice estndar que representan
clases. Las tarjetas se dividen en tres secciones. A lo largo del borde superior de la tarjeta
se escribe el nombre de la clase. En el cuerpo de la tarjeta se listan las responsabilidades
de la clase a la izquierda y los colaboradores a la derecha.
En realidad, el modelo CRC puede utilizar tarjetas ndice reales o virtuales. El objetivo es desarrollar una representacin organizada de las clases. Las responsabilidades
226
PARTE DOS
PRACf!CA DE LA INGENIERA DEL SOFTWARE
son los atributos y las operaciones relevantes para la clase. Dicho de manera rr
simple, una responsabilidad es "cualquier cosa que la clase sabe o hace" (AMB9E
Los colaboradores son aquellas clases que se requieren para que una clase reciba
informacin necesaria para completar una responsabilidad. En general, una colat>.
racin implica ya sea una solicitud de informacin o la solicitud de alguna accin
Ut,o clt lQS propsitqs de los rorjetQs CRC es follar al inio, follar constantemente yfollar sin que $8 etro. Es l)IUCho
ms brofotitar 111! bilto de klrjetos que reorganizar uno gran cantidad de cdigo ~me.,,
tlfers...
En la figura 8.15 se ilustra una tarjeta ndice CRC simple para la clase Planode-planta. La lista de responsabilidades que se muestra en la tarjeta CRC es prelimin.;.
y est sujeta a adiciones o modificaciones. Las clases Pared y Cmara se anotr
enseguida de la responsabilidad que requerir su colaboracin.
Clases. Las directrices bsicas para identificar clases y objetos ya se han presetado en este mismo captulo. La taxonomia de los tipos de clases que se present e:"
la seccin 8.7.1 se puede extender considerando las siguientes categoras:
e(l(On!IGISQ>IMl[i
excelente expooo6r\
de este lil)O de COSO$.
Clases de entidad, tambin llamadas clases de modelo o negocios. se extraen

de manera directa del enunciado del problema (por ejemplo, Planodeplanta
y Sensor). De manera tpica, estas clases representan clases que se almacenarn en una base de datos y que persisten durante la aplicacin (a menos
que se borren de manera especifica).
Clases defrontera. Se utilizan para crear la interfaz (por ejemplo, pantallas
interactivas o reportes impresos) que el usuario ve y con la cual interacta
cuando se utiliza el software. Las clases de entidad contienen informacin
iihilifj
Una carta
...
...
ndice del
modeloCRC.
,- 1, Clase: PJca...-PIQnt
,_t;:,
Descripcin
1-
,;,
~
...
... ,-..
,,
-"
1-
e< .,
'
ReJMnsabilid.ac:I
G<
Colaborador ,,1,
Define el nombre/tipo del plano de planta

Maneja la posicin del plano de planta
Escala el plano de planta para su despliegue
Escala el plano de planta para su desplieque
..-..
Incorporo paredes, puertos y ventanas

Muestra lo posicin de los cmoros de video
Pared
Cmara
'
F"
''
CAPTULO 8
227
importante para los usuarios, pero no se despliegan a s mismas. Las clases

de frontera estn diseadas con la responsabilidad de manejar la forma en
que los objetos de entidad se presentan a los usuarios. Por ejemplo. una clase
de frontera llamada VentanadeCmara tendra la responsabilidad de
desplegar la salida de una cmara de vigilancia para el sistema HogarSeguro.
Las clases de controlador manejan una "unidad de trabajo" [UML03) desde el
inicio hasta el final. Esto es, las clases de controlador se pueden disear para
manejar 1) la creacin o actualizacin de los objetos de entidad; 2) la inmediatez de objetos de frontera conforme stos obtienen informacin de objetos
de entidad; 3) la comunicacin compleja entre conjuntos de objetos; y 4) la
validacin de datos comunicados entre los objetos o entre el usuario y la aplicacin. En general, las clases de controlador no se consideran sino hasta que
ha comenzado el diseo.
........
dljllls,-len daslfkarse de manero cienttfo en tres grandes cotegorlos: los que no fundonan, los quu1
y los que se pienlen."
Responsabilidades. En las secciones 8.7.2 y 8.7.3 se han presentado las directrices bsicas para identificar responsabilidades (atributos y operaciones). Wirfs-Brock
y sus colegas [WIR90) sugieren cinco directrices para determinar las responsabilidades de las clases:
1. La inteligencia del sistema se debe distribuir entre las clases para

abordar de mejor manera las necesidades del problema. Cada aplicacin abarca un cierto grado de inteligencia; esto es, lo que el sistema sabe y
puede hacer. Esta inteligencia puede distribuirse entre las clases de varias
maneras diferentes. Las clases "poco inteligentes" (aquellas que tienen menos
responsabilidades) pueden modelarse para actuar al servicio de unas cuantas
clases "muy inteligentes" (las que tienen muchas responsabilidades). Aunque
este enfoque hace que el flujo de control en un sistema sea directo, tiene unas
cuantas desventajas: a) concentra toda la inteligencia en unas pocas clases, lo
que dificulta los cambios, y b) tiende a requerir ms clases, y por ende, un mejor esfuerzo de desarrollo.
Si la inteligencia del sistema se distribuye con mayor amplitud entre las
clases de una aplicacin, cada objeto sabe y hace slo unas cuantas cosas (las
cuales, por lo general, son bien enfocadas), y la cohesin del sistema mejora.
Lo anterior aumenta la facilidad de mantenimiento del software y reduce el
impacto de los efectos colaterales debidos al cambio.
Para determinar si la inteligencia del sistema est bien distribuida las responsabilidades anotadas en cada tarjeta ndice del modelo CRC deben evaluarse y as comprobar si alguna clase tiene una lista de responsabilidades
228
PARTE DOS
PRCllCA DE LA INGENIERA DEL SOFIWARE
demasiado larga. Esto indica una concentracin de inteligenda.23 Adems, las

responsabilidades para cada clase deben mostrar el mismo grado de abstracc
2. cada responsabilidad debe establecerse tan general como sea posible. Esta directriz implica que las responsabilidades generales (tanto atrib1
tos como operaciones) deben estar en la parte alta de la jerarqua de la cla
(debido a que son genricas son aplicables en todas las subclases).
3. La informacin y el comportamiento relacionado con ella deben es

dentro de la misma clase. Con esto se logra el principio 00 llamado ene
su/acin. Los datos y los procesos que manipulan los datos deben empaque
tarse como una unidad cohesiva.
4. La informacin relativa a una cosa debe localizarse con una sola

clase, no distribuirse entre muchas de ellas. Una sola clase debe toma:
la responsabilidad de almacenar y manipular un tipo especfico de informacin. En general, esta responsabilidad no se puede compartir entre varias c -ses. Si la informacin se distribuye, el software se vuelve ms dificil de
mantener y ms desafiante de probar.
5. Las responsabilidades pueden compartirse entre clases relacionadas

cuando esto es apropiado. Existen muchos casos en los que una varieda....
de objetos relacionados deben mostrar el mismo comportamiento al mismo
tiempo. Como un ejemplo, considrese un videojuego que debe desplegar le:
siguientes clases: Jugador, CuerpoJugador, BrazosJugador, PiemasJugador, CabezaJugador. Cada una de estas clases tiene sus propios atributos
(por ejemplo, posicin, orientacin, color, velocidad) y todos deben actualizarse y
desplegarse cuando el usuario manipula un joystick. Por lo tanto, las responsabilidades actualizar( ) y desplegar() deben compartirlas cada uno de los ob1e
tos mencionados. El Jugador sabe cuando algo ha cambiado y se requiere
actualizar(). Colabora con los otros objetos para lograr una nueva posicin u
orientacin, pero cada objeto controla su propio despliegue.
Colaboraciones. Las clases cumplen sus responsabilidades en una de dos formas

1) una clase puede utilizar sus propias operaciones para manipular sus propios atJibutos, y con ello cumplir con una responsabilidad particular, o 2) una clase puede
colaborar con otras clases.
Wirfs-Brock y sus colegas [WIR90J definen las colaboraciones de la siguiente

manera:
Las colaboraciones representan las solicitudes que un cliente hace a un servidor con el fin
de cumplir una responsabilidad. Una colaboracin es la materializacin del contrato entre el cliente y el servidor... Se dice que un objeto colabora con otro objeto si, para cumplir con una responsabilidad, necesita enviar algunos mensajes al otro objeto. Una
23 En tales casos puede ser necesario dividir las clases en mltiples clases o subsistemas completos
para d1stribwr la intehgencia de manera ms eficaz.
CAPTULO 8
229
colaboracin sencilla luye en una direccin, lo que representa una solicitud del cliente al
servidor. Desde el punto de vista del cliente, cada una de sus colaboraciones est asociada
con una responsabilidad particular que ha implementado el servidor.
Las colaboraciones identifican las relaciones entre clases. Cuando un conjunto de

clases colabora para lograr algn requisito, ste puede organizarse en un subsistema (un aspecto de diseo).
Las colaboraciones se identifican al determinar si una clase puede cumplir cada
responsabilidad por s misma. Si no es as, entonces se requiere de la interaccin con
otra clase y, por ende, una colaboracin.
Como un ejemplo, considrese la funcin de seguridad de HogarSeguro. Como
parte del procedimiento de activacin, el objeto PaneldeControl debe determinar
si algn sensor est abierto. Se define una responsabilidad llamada determinar-estatus-sensor( ). Si los sensores estn abiertos, PaneldeControl debe establecer un
atributo de estatus como "no listo". La informacin de los sensores se obtiene de
cada objeto sensor. Por lo tanto, la responsabilidad determinar-estatus-control() trabaja en colaboracin con sensor.
Para ayudarse en la identificacin de los colaboradores, el analista puede examinar tres relaciones genricas diferentes entre las clases [WIR90]: 1) la relacin esparte-de, 2) la relacin tiene-conocimiento-de, y 3) la relacin depende de. Cada una
de las tres relaciones genricas se considera con brevedad en los siguientes prrafos.
Todas las clases que son parte de una clase agregada se conectan a sta a tr~vs
de una relacin del tipo es-parte-de. Considrense las clases definidas para el victeojuego ya mencionado, la clase CuerpoJugador es-parte-de Jugador, al igual 9ue
BrazosJugador, PiemasJugador y cabezaJugador. En UML estas relaciones se
1
representan como la agregacin mostrada en la figura 8.16.
Cuando una clase debe obtener informacin de otra clase se establece la reladn
tiene-conocimiento-de. La responsabilidad determinar-estatus-sensor( ) mencionada
antes ejemplifica una relacin del tipo tiene-conocimiento-de.
La relacin depende-de implica que dos clases tienen una dependencia que no se
logra mediante las relaciones tiene-conocimiento-de o es-parte-de. Por ejemplo,
cabezaJugador siempre debe estar conectada a CuerpoJugador (a menos que el
videojuego sea violento en particular). Aun as, cada objeto puede existir sin el conocimiento directo del otro. Un atributo del objeto cabezaJugador llamado posicin
central est determinado desde la posicin central de CuerpoJugador. Esta informacin se obtiene a travs de un tercer objeto, Jugador, quien la adquiere de
CuerpoJugador. Por ende, CabezaJugador depende-de cuerpoJugador.
En todos los casos, el nombre de la clase del colaborador se registra en la tarjeta
ndice del modelo CRC enseguida de la responsabilidad que ha producido la colaboracin. Por lo tanto, la tarjeta ndice contiene una lista de responsabilidades y las
colaboraciones correspondientes que permiten que las responsabilidades puedan
cumplirse (figura 8.15).
230
PARTE DOS
Una clase
agregada
compuesta.
Cuando se ha desarrollado un modelo CRC completo, los representantes del clie:tes y la ingeniera del software pueden revisar el modelo utilizando el siguiente en.
que [AMB95]:
1. Todos los participantes en la revisin (del modelo CRC) reciben un subcon-
junto de las tarjetas ndice del modelo CRC. Las tarjetas que colaboran se deben separar (es decir, ningn revisor debe tener dos que colaboren).
2. Todos los escenarios de caso de uso (y los diagramas de caso de uso corres-
pondientes) deben organizarse en categoras.

3. El lder de la revisin lee el caso de uso en forma deliberada. cuando el lder
llega a una clase nombrada pasa una seal a la persona que tiene la tarjeta
indice de clase correspondiente. Por ejemplo, un caso de uso para HogarSeguro contiene la siguiente narrativa:
El propietario observa el panel de control de HogarSeguro para determinar si el sistema
est listo para la entrada. Si no lo est, el propietario podr cerrar tlsicamente ventanas y puertas para que se presente el indicador de listo. [Un indicador de no-listo implica que un sensor est abierto; es decir, que esa puerta o ventana est abierta.]
Cuando el lder de la revisin llega a "panel de control", en la narrativa del cas...

de uso, la seal se pasa a la persona que posee la carta ndice del Paneldecontrol. La frase "implica que un sensor est abierto" requiere que la tarjeta.
ndice contenga una responsabilidad que validar esta implicacin (lo cual se
logra mediante la responsabilidad determinar-estatus-sensor()). Enseguida de
la responsabilidad escrita en la tarjeta est el colaborador sensor. Entonces, la
seal se pasa a la clase sensor.
4. Cuando se pasa la seal, la persona que posee la tarjeta de clase debe describir las responsabilidades anotadas en ella. El grupo determina si una (o ms)
de las responsabilidades satisface el requisito del caso de uso.
CAPrruLO 8
231
5. Si las responsabilidades y las colaboraciones anotadas en las tarjetas ndice

no satisfacen el caso de uso, se hacen las modificaciones necesarias a la tarjeta. Esto puede incluir la definicin de clases nuevas (y corresponden a las
tarjetas de ndice de CRC) o la especificacin de responsabilidades o colaboraciones nuevas revisadas sobre las tarjetas existentes.
Esta forma de operacin contina hasta que se termina con el caso de uso. Cuando
se han revisado todos los casos de uso se contina con el modelado del anlisis.
dtEd,
Panelopciones: pn:lpOlona lonlilOICMltl,

permilen al usuario selec:cionar Unct
Ponelsituacin: poporaona 'inkli,,_l'iirl
permiten al usuario selecx:ionar ta
inl'
232
Planodeplanta el mrsmo que el obeto de vigilando, pero
seleccionorSituoci6rr
Pctnel$ituacin (clase)
ste despl ego los dispositivos.
entrorPlonodePlonto
PlanoclePlonta (dosel
lconosdeOi~tivo. informacin sobre icono$que

representan luces, opl,cociooes, cmoros, etctera .
PonelesdeD1spoS1tivo s,mvladn de una aplicacin o
panel de control de un d,spa~itivo; permile el control.
Opercadones:
DesplegarControl(} ~onorControl(J,
de$~r5,tuacin{!, selec;cioparSituacin(J,
entrorPkmodePlonto(J, selecionar/conoDispo$ilivo(},
desplego,Pane/Dispos,hvo{J, entrar PonelD,sposihvo{},
Ckue: lnlerfazAdministr:acnHogar
...ponsabilidad
Colaborador
desplegarControl
PaneloperacionH (clase}
seleccionarControf
Ponelopetadones (dosel
desplegorS tuact0n
Pane1Situocin (clase)
--,c&v1
Ed: Entonces cuando se invoca la operacin

enlrarpkmodePlanto(), sta cotobora con el ob eto
PlonodePlonta como el que desarrolla1Tl0$ para la
vigilancia. Espera, aqu tengo su descrlpci6n. (Ven la
figura 8.14)
Vinod: Exactamente. Y s1 quisiramos nMsar lodo
modelo de dose, podramos comenzar con esta carta
ndice, despus ir o lo corta ndice del colaboradoi y
ah, a una de los colaboradores de los cclabonaclor.
a s suc;esivomente.
Ed: Buena formo de encontrar omisiones o emns.
Vinod: S.
,:.,
8.7.5 Asociaciones y dependencias
Uno osocion define

uno relacin entre
doses. lo multiplicidad
define coontus de uno
clase est6n
relacianadas con
cuntus de otro dose.
En muchos casos, dos clases de anlisis se relacionan entre s de alguna manera, parecida a la forma en que se relacionan dos objetos de datos (seccin 8.3..3). En UML estas
relaciones se llaman asodadones. Vase de nuevo la figura 8.14; la clase PlanodePlantz
se define al identificar un conjunto de asociaciones entre PlanodePlanta y otras dos clases, Cmara y Pared. La clase Pared se asocia con tres clases que permiten que se
construya una pared, SegmentodePared, Ventana y Puerta.
En algunos casos, una asociacin se puede definir en forma ms extensa al inclicar multiplicidad (el trmino cardinalidad ya se us antes en este captulo). En ree
rencia a la figura 8.14, un objeto de Pared se construye con uno o ms objetos d
SegmentosdePared. Adems, el objeto Pared puede contener O o ms objetos
de Ventana y Oo ms objetos de Puerta. Estas restricciones de multiplicidad se ilustran en la figura 8.17, donde "uno o ms" se representa mediante 1.. * y "O o ms" por
medio o.. *. En UML el asterisco indica una frontera superior ilimitada en el rango
Qu es un
estereotipo?
En muchos casos existe una relacin cliente servidor entre dos clases de anlisis
En tales casos, una clase de cliente depende de alguna manera de la clase de serv dor y se establece una relacin independencia. Las dependencias se definen mediante un estereotipo. un estereotipo es un "mecanismo de extensibilidad" [ARL02] den-
24 Otras relaciones de multiplicidad - una a una, una a muchas, muchas a muchas, una a un rango especifico con lmites inferior y superior, y otras- se pueden indicar como parte de una asoc1ac1n
CAPTULO 8
233
Pared
Se utilizo poro
construir
....
o.. *
1..* 1
SegmentoPared
1
Se utilizo poro
- construir
Se utilizo ~oro
construir
Ventana
10
Pv.rta
1,
Ventano
Despliegue
'
Cmara
<<acceso>>
(contraseo)
tro del UML que permite a un ingeniero de software definir un elemento de modelado especial cuya semntica define el cliente. En UML los estereotipos se representan
dentro de comillas angulares (por ejemplo, estereotipo).
Como una ilustracin de una dependencia simple dentro del sistema de vigilancia de HogarSeguro, un objeto de Cmara (en este caso, la clase de servidor) proporciona una imagen de video o un objeto de VentanadeDespliegue (en este caso,
la del cliente). La relacin entre estos dos objetos no es una asociacin simple, aun as
existe una asociacin de dependencia. En un caso de uso escrito para la vigilancia
(que no se muestra), el modelador aprende que se debe proporcionar una contrasea
especial para ver ubicaciones especficas de cmara. Una forma de lograr esto es que
Cmara pida una contrasea y despus d penniso a VentanadeDespliegue para

producir la imagen de video. Esto se puede representar como se muestra en la figura
8. 18, donde <<acceso implica que el uso de la salida de la cmara est controlado
mediante una contrasea especial.
8. 7 .6 Paquetes de anlisis
Una parte importante del modelado del anlisis es la categorizacin. Esto es, los
diferentes elementos del modelo de anlisis (por ejemplo, casos de uso, clases de
PARTE DOS
Paquetes.
l"!":-""T.:'""'!"~-r-~
MHioAm ente
...... Nombre del paquete

/ \
+Arbor'
+R-0isoj6
!'
!
'
.\
.
.------,-........
Persona
+Jogodot
+Protogoni~to
+Antcrgonlst<:1
+PopeldScporte
~
~~
c&v1
Un poquete se utiliza
paro ensamblar una
coleccin de clases
relacionados.
anlisis) se clasifican de una manera que los empaquete como una agrupacin mada un paquete de anlisis-, a la cual se le asigna un nombre representativo.
Para ilustrar la utilizacin de paquetes de anlisis considrese el videojuego e,::
se present prrafos atrs. Al desarrollar el modelo de anlisis para el videojuego
obtiene un gran nmero de clases. Algunas se enfocan en el ambiente del juego ::ejemplo, las escenas visuales que el usuario ve mientras se desarrolla el juegClases como rbol, Paisaje, Camino, Pared, Puente, Edificio, EfectoVJ.SUa..
podran estar dentro de esta categora. Otras se enfocan en los personajes dentro d.
juego al describir sus caractersticas fisicas, acciones y restricciones. Se podran de'..
nir clases como Jugador (la cual se describi con anterioridad), Protagonista.
Antagonista y Papelesdesoporte. Adems, otras describen las reglas del jueg
cmo navega el jugador a travs del ambiente. Aqu son candidatas clases cocReglasDeMovimiento y RestriccionesEnAccin. Pueden existir muchas otr::..
categoras. Estas clases pueden representarse como los paquetes de anlisis que Se
muestran en la figura 8. 19.
El signo de ms que precede al nombre de la clase de anlisis en cada paqueindica que las clases tienen visibilidad pblica y que, por lo tanto, son accesible!:
desde otros paquetes. Aunque no se muestran en esta figura, hay otros smbolos qu::
pueden preceder a un elemento dentro de un paquete. Un signo de menos indica que tr
elemento est oculto de todos los otros paquetes, y un smbolo # indica que un elemento es accesible slo a las clases contenidas dentro de un paquete dado.
Los diagramas de clase, las tarjetas ndice CRC y otros modelos orientados a las clases tratados en la seccin 8.7 representan elementos estticos del modelo de anli-
CAPTULO 8
235
sis. Ahora es tiempo de hacer una transicin al comportamiento dinmico del sistema o producto. Para lograrlo el comportamiento del sistema debe presentarse como
una funcin de los elementos especficos y el tiempo.
El modelo de comportamiento indica la forma en que el software responder a los eventos o estmulos externos. En la creacin del modelo el analista debe realizar los siguientes pasos:
l. Evaluar todos los casos de uso para entender por completo la secuencia de
interaccin dentro del sistema.

2 . Identificar los eventos que conducen la secuencia de interaccin y entender la
forma en que estos eventos se relacionan con las clases especficas.

3. Crear una secuencia para cada caso de uso.
4 . Construir un diagrama de estado para el sistema.
5. Revisar el modelo de comportamiento para verificar su exactitud y consisten-
cia.
Cada uno de estos pasos se expone en las secciones siguientes.
8.8.1 Ident11lcacin de eventos con el caso de uso

Como se mencion en la seccin 8.5, el caso de uso representa una secuencia de
actividades que implica a los actores y al sistema. En general. siempre que el sistema y un actor intercambian informacin ocurre un evento. Si se recuerda la explicacin anterior acerca del modelado del comportamiento en la seccin 8.6.3, ser
importante puntualizar que el evento no es la informacin que se ha intercambiado, sino el hecho de que la informacin haya sido intercambiada.
Los puntos del intercambio de informacin se obtienen examinando un caso de
uso. A manera de ilustracin, se reconsiderar el caso de uso para una pequea
parte de la funcin de seguridad de HogarSeguro.
El propietario utiliza el teclado para introducir una contrasea de cuatro digitos. La CQ!l=
trasea se compara con Ja contrasea vlida almacenada en el sistema Si la contrasea
es incorrecta, el panel de control emitir un sonido por una sola vez y se reiniciar para
esperar otra entrada. Si la contrasea es correcta, el panel de control esperar la accin
posterior.
Las partes subrayadas del escenario del caso de uso indican eventos. Se debe identificar a un autor para cada evento; la informacin intercambiada se debe anotar, y
cualquier condicin o restriccin debe registrarse.
Como ejemplo de un evento tipico, considrese la frase subrayada del caso de uso
"el propietario utiliza el teclado para introducir una contrasea de cuatro dgitos". En
el contexto del modelo de anlisis, el objeto, propietario,25 transmite un evento al
25 En este ejemplo se asume que cada usuario (propietario) que interacta con HogarSeguro tiene una
contrasea de identificacin y que, por lo tanto, es un obJeto legtimo.
236
PARTE DOS
PRCTICA DE LA INGENIElliA DEL SOFTWARE
objeto PaneldeControl El evento podria llamarse introducdn de contrase

informacin transferida son los cuatro dgitos que constituyen la contrasea
sta no es una parte esencial del modelo de comportamiento. Es importante se
que algunos eventos tienen un impacto explcito sobre el flujo de control del c...
uso, mientras que otros no tienen impacto directo sobre el flujo de control. Por e
plo, el evento introduccin de contrasea no cambia de manera explicita el flu
control del caso de uso, pero los resultados del evento comparacin de concn
(derivado de la interaccin "la contrasea se compara con la contrasea ,
almacenada en el sistema") tendr un impacto explcito sobre la informaci,.
flujo de control del software de HogarSeguro.
Una vez que se han identificado todos los eventos, stos se ubican con los
tos involucrados. Los objetos pueden ser responsables de generar eventos (por e
plo, Propietario genera el evento de introduccin de contrasea) o de reco
eventos que han ocurrido en cualquier sitio (por ejemplo, PaneldeControl rec
ce el resultado binario del evento comparacin de contrasea).
8.8.2 Representaciones de estado
&'
'~
c&v1
El sistema tiene
estodos que
representan un
comportamiento
espelico obserwble
desde el exterior; una
clase tiene estodos que
rensenton su
comportamiento
cuando el sistema
reolizo sus funciones.
En el contexto del modelado del comportamiento se pueden considerar dos dife

tes caracterizaciones de los estados: 1) el estado de cada clase conforme el sis ...
realiza su funcin, y 2) el estado del sistema como se observa desde el exterior~
forme el sistema realiza su funcin. 26
El estado de una clase implica caractersticas tanto pasivas como activas [CH,
Un estado pasivo es simplemente el estatus actual de todos los atributos de un ob ~
Por ejemplo, el estado pasivo de la clase Jugador (en la aplicacin de videojlk.
estudiada con anterioridad) incluira los atributos de posicin y orientacin del Jugad
as como otras caractersticas relevantes para el juego (por ejemplo, un atributo
indique la existencia de deseos mligicos). El estado activo de un objeto indica el esta
actual del objeto cuando ste est sujeto a una transformacin o a un procesam ec
to continuos. La clase Jugador podra tener los siguientes estados activos: en m 'J\
miento, en descanso, herido, en curacin, atrapado, perdido, etctera. Debe ocurrir
evento (algunas veces llamado un disparador) para obligar a un objeto a hacer
transicin de un estado activo a otro.
En los prrafos siguientes se explican dos diferentes representaciones del cocportamiento. La primera indica la forma en que una clase individual cambia sus eS1..
do con base en eventos externos, y la segunda muestra el comportamiento del SOi..
ware como una funcin del tiempo.
Diagramas de estado para clases de anlisis. Un componente de un model

del comportamiento es un diagrama de estado en UML que representa los estado..
activos para cada clase y los eventos (disparadores) que ocasionan cambios entr_
26 Los diagramas de estado presentados en la seccin 8.6.3 muestran el estado del sistema. La expo
sicin en esta seccin se enfocar al estado de cada clase dentro del modelo de anlisis.
CAPTULO 8
237
Temporizador ,;;; TiempoCerrodo
Temporizador
> TiempoCerrodo
Contraseo = incorrecto
y nmeroDelntentos < lntentosmximos
--
Golpe
de teclo
Lectura "
Contrasea
introducida
Comparacin
Hacer: volidor
Contraseo
Cerrado"'
....-'-
nmeroDelntentos >
lntentosmximos
Contraseo
&
correcto
rSeleccin
'"
Activacin exitoso
estos estados activos. En la figura 8.20 se ilustra un diagrama de estado para la clase
PaneldeControl en la funcin de seguridad de HogarSeguro.

Cada flecha en la figura 8.20 representa una transicin desde un estado activo de
una clase hasta otro. Las etiquetas mostradas para cada flecha representan elevento que dispara la transicin. Aunque el modelo de estado activo proporciona un discernimiento activo de la "historia de vida" de una clase, es posible especificar informacin adicional para proporcionar mayor profundidad en la comprensin del comportamiento de una clase. Adems de especificar el evento que ocasiona la transicin, el analista puede especificar una guardia y una accin [CHA9.3J . Una guardia es
una condicin booleana que debe satisfacerse para que ocurra la transicin. Por
ejemplo, la guardia para la transicin desde el estado de "lectura" al estado de "comparacin" de la figura 8.20 se puede determinar al examinar el caso de uso:
si (introduccin de contrasea
4 dgitos), entonces comparar con contrasea almacenada
En general, la guardia para una transicin por lo regular depende del valor de uno o
ms atributos de un objeto. En otras palabras, la guardia depende del estado pasivo
del objeto.
Una acdn sucede de manera concurrente con la transicin del estado o como
consecuencia de ste, y por lo general implica una o ms operaciones (responsabilidades) del objeto. Por ejemplo, una accin conectada con el evento contrasea introdudda (figura 8.20) es una operacin llamada Validarcontrasea( ) que da acceso a
PARTE DOS
PRCTICA DE LA INGENIERA DEL SOF'IWARE
Diagrama de secuencia (pardal) para la funcin de seguridad de HogarSeguro.
Prop,retoro
srs;emo
ffistemo
isto
Solicitud de bsqueda
nmerDelntentos >
lntentosmximos
Activacin exitoso
1
1
1
1
Resultado
Contraseo ~ correcto
Solicitud de octivocin
Activacin exitoso
un objeto de contrasea y realiza una comparacin dgito por dgito para validar ~
contrasea introducida.
Diagramas de secuencia. El segundo tipo de representacin de comportamiento, llamado un diagrama de secuencia en UML, indica cmo los eventos causan transiciones de objeto a objeto. Una vez que se han identificado los eventos al examinar
un caso de uso, el modelador crea un diagrama de secuencia: una representacin de
cmo los eventos causan un flujo de un evento a otro como una funcin del tiempo
En esencia, el diagrama de secuencia es una versin abreviada del caso de uso
Representa clases clave y eventos que causan que el comportamiento fluya de clase
a clase.
En la figura 8.21 se ilustra un diagrama de secuencia parcial de la funcin de
seguridad de HogarSeguro. cada flecha representa un evento (derivado de un caso
de uso) e indica cmo el evento canaliza el comportamiento entre los objetos de
HogarSeguro. El tiempo se mide de manera vertical (hacia abajo), y los rectngulos
verticales delgados representan el tiempo invertido en procesar una actividad. Los
estados se pueden mostrar a lo largo de una linea de tiempo vertical.
El primer evento, sistema listo, se deriva del ambiente externo y canaliza el comportamiento a un objeto de propietario. El propietario introduce una contrasea. Se
pasa un evento de solicitud de bsqueda al sistema, el cual busca la contrasea en
una base de datos simple y regresa un resultado (encontrado o no encontrado) al
PaneldeControl (ahora en el estado de comparacin). Una contrasea vlida resul-
CAPTULO 8
239
ta en un evento contrasea=correcta para el Sistema, el cual activa los sensores con

un evento de solicitud de activacin. Por ltimo, el control se pasa de regreso al propietario con el evento activacin exitosa.
una vez que se ha desarrollado un diagrama de secuencia completo, todos los
eventos que ocasionan transiciones entre objetos del sistema se pueden cotejar con
un conjunto de eventos de entrada y eventos de salida (de un objeto). Esta informacin es til en la creacin de un diseo eficaz para el sistema que ser construido.
Modelado del anlisis generalJzado en UML

Objetivo: Las herramientas poro el modelado
del onlisis proporcionan lo capocidod de
ArgoUML, uno herramienta de fuente abierta

(orgouml.tigris.org).
modelos basados en escenarios, modelos

clases y modelos de comportamiento mediante
onUML.
Control Center, desarrollado por TagetherSoft

(www.togethersoft.com).
e""
Las herramientas en esta categora soportan

mngo de diagramas en UML requeridos poro
'-" modelo de onlisis (estas herramientas
10p0rion el modelado del diseo). Adems de lo
oe diagramas, los herramientas en esta categora
lo verificacin de lo consistencia y lo correccin
'Os diagramas en UML; 2) proporcionan vnculos
:.:,eoo y lo generacin de cdigo; 3) construyen
de datos que ayudan o lo administracin y
de grandes modelos en UML requeridos poro
cxrnplejos.
..,...,...,ta, representativas 27
....-"le:! herramientas soportan un rango completo

_,..,,..,..,s en UML requeridos poro el modelado del
Enterprise Architect, desarrollado por Sporx Systems

(www.sporxsystems.com.ou).
Object Technology Workbench (OTW), desarrollado por
OTW Software (www.otwsoftwore.com).
Power Designar, desarrollado por Sybase
(www.sybose.com).
Rational Rose, desarrollado por Rotionol Corporotion
(www.rationol.com).
System Archited, desarrollado por Popkin Software
{www.popkin.com).
UML Studio, desarrollado por Progsoft Corporotion
(www.progsoft.com).
Visio, desarrollado por Microsoft (www.microsoft.com).
Visual UML, desarrollado por Visual Object Modelers
(www.visuoluml.com}.
El objetivo del modelado del anlisis es crear una variedad de representaciones que
muestran los requisitos del software para la informacin, la funcin y el comportamiento. Esto se logra aplicando dos diferentes filosofias de modelado (pero potencialmente complementarias): el anlisis estructurado y el anlisis orientado a objetos. El anlisis estructurado considera al software como un transformador de infor-
27 Las herramientas mencionadas aqu son una muestra de esta categora. En la mayora de los casos
los nombres estn registrados por sus respectivos desarrolladores
240
PARTE DOS
PRCTICA DE LA INGENIERiA DEL SOFTWARE
macin. ste ayuda al ingeniero de software a identificar los objetos de datos

relaciones y la manera en la cual estos objetos de datos se transforman mientras
yen a travs de las funciones de procesamiento del software. El anlisis orientac.
objetos examina un dominio de problema definido como un conjunto de casos
uso en un esfuerzo por extraer clases que definen el problema. Cada clase tiene
conjunto de atributos y operaciones. Las clases estn relacionadas entre s en _
variedad de formas diferentes y se moldean mediante la aplicacin de diagramas
UML. El modelo de anlisis lo componen cuatro elementos de modelado: modc.
basados en escenarios, modelos de flujo, modelos basados en clases y modelos
comportamiento.
Los modelos basados en escenarios muestran los requisitos del software desa._
punto de vista del usuario. El caso de uso -una descripcin narrativa o basada.
una plantilla de una interaccin entre un actor y el software- es el elemento
mario del modelado. El caso de uso, derivado durante la obtencin de requis;
defme los casos clave para una funcin o interaccin especfica. El grado de fo
lidad y detalle del caso de uso vara, pero el resultado final proporciona la en
necesaria a las otras actividades de modelado del anlisis. Los escenarios tamtpueden describirse por medio de un diagrama de actividad: una representacin g
fica del tipo de un diagrama de flujo que muestra el flujo del procesamiento de
de un escenario especfico. Los diagramas de carril ilustran la forma en que el
de procesamiento incumbe a varios actores o clases.
Los modelos de flujo se enfocan en el flujo de objetos de datos conforme las ;
ciones de procesamiento los transforman. Los modelos de flujo, que se derivar,
anlisis estructurado, utilizan el diagrama de flujo de datos; sta es una notaci'"
modelado que muestra la manera en que una entrada se transforma en una sa
conforme los objetos de datos se mueven a travs del sistema. Cada funcin del s,
ware que transforma datos se describe mediante una especificacin del preces
narrativa. Adems del flujo de datos, este elemento de modelado tambin mue:.
el flujo de control (una representacin que ilustra la forma en que los eventos a;
tan el comportamiento del sistema).
El modelado basado en clases utiliza informacin derivada de elementos
modelado orientado al flujo y basado en escenarios para extraer clases candida
atributos y operaciones de las narrativas basadas en texto. Se establecen los en _
ros para la definicin de una clase. La tarjeta ndice clase-responsabilidad-colat-rador puede usarse en la definicin de relaciones entre las clases. Adems, se pue
aplicar una variedad de notaciones de modelado en UML para definir jerarqlLZ.
relaciones, asociaciones, agregaciones y dependencias entre las clases. Los PCftes de anlisis se utilizan para categorizar y agrupar clases de manera que sean rmanejables para los sistemas grandes.
Los primeros tres elementos del modelado del anlisis proporcionan una vis
esttica del software. Los modelos de comportamiento muestran un desempe dinmico. El modelo de comportamiento utiliza la entrada de elementos basados
CAPTULO 8
241
escenarios, orientados al flujo y basados en clases para representar los estados de

las clases de anlisis y del sistema como un todo. Esto se logra identificando los
estados, definiendo los eventos que ocasionan que una clase (o sistema) tenga una
transicin de un estado a otro, e identificando las acciones que suceden cuando se
realiza la transicin. En el modelado del comportamiento se utiliza la notacin en
UML de los diagramas de estado y los diagramas de secuencia.
[ABB83) Abbott, R., "Program Design by Informal English Descriptions", en CACM, vol. 26, nm.
11, noviembre de 1983, pp. 892-894.
[AMB95) Ambler, s.. "Using Use-cases", en Software Development, julio de 1995, pp. 53-61.
[ARA89J Arango, G. y R. Prieto-Diaz, "Domain Analysis: Concepts and Research Directions", en
Domain Analysis: Acquisition of Reusable Information far Software Construction, (Arango, G. y
R. Prieto-Diaz, eds.), IEEE Computer Society Press, 1989.
[ARL02] Arlow, J. e l. Neustadt, UML and the Unified Process, Addison-Wesley, 2002.
[BER93) Berard, E. V., Essays on Objetc-Oriented Software Engineering, Addison-Wesley, 1993.
[B0086] Booch, G., "Object-Oriented Development", en TEE 'Trans. Software Engineering, vol. SE12, nm. 2, febrero de 1986, pp. 21 lff.
[BUD96J Budd, T., An Introduction to Objetc-Oriented Programming, 2a. ed., Addison-Wesley,
1996.
[CAS891 cashman, M., "Object-Oriented Domain Analysis", en ACM Software Engineering Notes,
vol. 14, nm. 6, octubre de 1989, p. 67.
[CHA93J de Champeaux, D., D. Lea y P. Faure, Object-Oriented System Development, Addisonwesley, 1993.
[CHE77] Chen, P., The Entity-Relationshp Approach to Logical Database Design, QED Information
Systems, 1977.
[COA91l Coad, P. y E. Yourdon, Object-Oriented Analysis, 2a. ed., Prentice-Hall, 1991.
[COCO!] Cockbum, A . Writing Ejfective Use Cases, Addison-Wesley, 2001.
[DAV931 Davis, A., Software Requirements: Objects, Functions and States, Prentice-Hall, 1993.
[DEM79) DeMarco, T., Structured Analysis and system Specification, Prentice-Hall, 1979
[FIR93) Firesmith, D. G., Object-Oriented Requrements Analysis and Logical Design, Wiley, 1993.
[LET03) Lethbridge, T., comunicacin personal sobre el anlisis del dominio. mayo de 2003.
[OMG03) Object Management Group, OMG Unified Modeling Language Specification, versin
1.5, marzo de 2003, disponible en http://www.rational.com/uml/resources/documentation/.
[SCH02J Schmuller, J., Teach Yourse}fUML in 24 Hours, 2a. ed., SAMS Publishing 2002.
[SCH98J Schneider, G. y J. Winters, Applying use cases, Addison -Wesley, 1998.
[STR88] Stroustrup, B., "What is Object-Oriented Programming?", en IEEE Software. vol. 5, nm.
3, mayo de 1988, pp. 10-20.
[TAY90) Taylor, D. A., Object-Oriented Technology: A Manager's Gude, Addison-Wesley, 1990.
[THAOOJ Thalheim, B., Entity Relationship Modeling, Springer-Verlag, 2000.
[TIL93J Tillmann, G., A Practica} Guide to Logical Data Modeling, McGraw-Hill, 1993.
[UML03J The UML Caf, "Customers Don't Print Themselves", disponible en http:/ /www.
theumlcafe.com/a0079.htm, mayo de 2003.
[WJR90] Wirfs-Brock, R., B. Wilkerson y L. Weiner, Designing Object-Oriented Software, PrenticeHall, 1990.
8.1. Es posible comenzar a codificar inmediatamente despus de haber creado el modelo de

anlisis? Explicar la respuesta y despus justificar los puntos en contra.
PARTE DOS PRAcnCA DE LA INGENIERA DEL SOFTWARE

8.2. Un anlisis prctico es aquel en el cual el modelo "debe enfocarse en los requisitos que
son visibles dentro de los dominios del problema o del negocio". Cules tipos de requisitos ne
son visibles en estos dominios? Dar algunos ejemplos.
8.3. Cul es el propsito del anlisis del dominio? Cmo se relaciona con el concepto de los
patrones de requisitos?
8.4. En unas cuantas lneas, trtese de describir las diferencias primordiales entre el anlisis
estructurado y el anlisis orientado a objetos.
8.5. Es posible desarrollar un modelo de anlisis eficaz sin desarrollar los cuatro elementos
que se muestran en la figura 8.3? Explicar la respuesta.
8.6. Supngase que han pedido construir uno de los siguientes sistemas.
Un registro de cursos basado en red para una universidad.

Un sistema procesador de rdenes basado en Internet para una tienda de computadoras
Un sistema simple de facturacin para un negocio pequeo.
d) El software que reemplace un Rolodex y que se encuentre dentro de un telfono inalmbrico.
e) un libro de cocina automtico que est construido dentro de un horno elctrico o de
microondas.
a)
b)
e)
Seleccinese el sistema que se considere interesante y describanse sus objetos de datos, relaciones y atributos.
8. 7 . Dibujar un modelo al nivel de contexto (DFD de nivel O) para uno de los cinco sistemas que
se listan en el problema 8.6. Escribir una narrativa del procesamiento para el sistema al nivel de
contexto.
8.8. Utilizar el DFD al nivel de contexto desarrollado en el problema 8. 7 para dibujar los diagramas de flujo de los niveles 1 y 2. Para comenzar, utilcese un "anlisis gramatical" en la
narrativa del procesamiento al nivel de contexto. Recurdese especificar todo el fluido de informacin mientras rotula todas las flechas que se encuentran entre las burbujas. sense nombres
significativos para cada transformacin.
8.9. Desarrllense especificaciones de control (EC) y especificaciones de proceso (EP) para el
sistema que seleccion en el problema 8.6. Trtese de que el modelo sea lo ms completo posible.
8.1 o. El departamento de obras pblicas de una ciudad grande ha decidido desarrollar un sis-
tema de rastreo y reparacin de baches basado en la Web (SRRB). Se incluye la siguiente descripcin:
Los ciudadanos pueden entrar al sitio Web y reportar la ubicacin y severidad de los
baches. cuando stos se reportan entran a un "sistema de reparacin del departamento de
obras pblicas", donde se les asigna un nmero de identificacin, junto con la direccin de la
calle, el tamao (en una escala de Oa 10), la ubicacin (en la orilla de la calle, en medio,
etctera), el distrito (determinado por la direccin de la calle), y la urgencia de la reparacin (determinada por el tamao del bache). Los datos de la orden de trabajo estn asociados con cada bache e incluyen la ubicacin y el tamao del bache, nmero de identificacin de la reparacin, cantidad de personal necesario, horas aplicadas a la reparacin,
estado del bache (trabajo en progreso, reparado, reparado en forma temporal, no reparado), cantidad de material de relleno utilizado, y costo de la reparacin (clculo de las horas
aplicadas, nmero de personas, material y equipo utilizados). Por ltimo, se crea un archivo de daos para registrar informacin sobre averas reportadas debido a los baches, el
cual incluye nombre del ciudadano, direccin, nmero telefnico, tipo de dao, precio del
dao en dlares. El SRRB es un sistema basado en la Web; todas las peticiones se hacen
en forma interactiva.
Con base en una notacin de anlisis estructurada, desarrolle un modelo de anlisis para el
SRRB.
CAPTULO 8
243
8 . 11. Describir los trminos orientados a objetos encapsu/adn y herencia.

8. 12. Escribir un caso de uso basado en una plantilla para el sistema de gestin para el hogar
HogarSeguro, descrito de manera informal en un recuadro ubicado enseguida de la seccin
8.7.4.
8. 13. Dibujar un diagrama de caso de uso en UML para el sistema SRRB presentado en el problema 8. 1O. Tendrn que hacerse varios supuestos sobre la manera en que el usuario interacta con este sistema.
8 . 14. Desarrollar un modelo de clase para el sistema SRRB presentado en el problema 8.1 o.
8 .15. Desarrollar un conjunto completo de tarjetas ndice del modelo CRC para el sistema SRRB
presentado en el problema 8.1 o.
8 . 16. Encabezar una revisin de las tarjetas ndice de CRC con sus colegas. Cuntas clases
adicionales, responsabilidades y colaboradores fueron agregados como consecuencia de la revisin?
8 .1 7 . Desclibir la diferencia entre una asociacin y una dependencia para una clase de anlisis.
8 . 18. Qu es un paquete de anlisis y cmo debe utilizarse?
8 . 19. De qu manera difiere un diagrama de estado para clases de anlisis de los diagramas
de estado presentados para el sistema completo?
Se han publicado docenas de libros sobre anlisis estructurado. En la mayora se trata el tema
de una manera adecuada, pero slo en unos cuantos se presenta un trabajo en verdad excelente. DeMarco y Plauger (Structured Ana[ysis and System Spedji.cation, Pearson, 1985) es un clsico que sigue siendo una buena introduccin a la notacin bsica. Los libros de Kendal y
Kendal (Systems Analysis and Design, 5a. ed., Prentice-Hall, 2002) y Hoffer et al. (Modem Systems
Analysis and Design, Addison-Wesley, 3a. ed., 2001) son referencias valiosas. El libro de Yourdon
(Modem Structured Ana[ysis, Yourdon-Press, 1989) sobre el tema se conserva entre las publicaciones ms completas a la fecha.
Allen (Data Modeling for Evezyone, Wrox Press, 2002), Simpson y Witt (Data Modeling
Essentials, 2a. ed., Coriolis Group, 2000), Reingruber y Gregory (Data Modeling Handbook, Wiley,
1995) presentan guias detalladas para crear modelos de datos relacionados con la calidad
industrial. Un interesante libro de Hay (Data Modeling Pattems, Dorset House, 1995) presenta
patrones de modelos de datos tpicos que se encuentran en muchos negocios diferentes. un tratamiento detallado del modelado del comportamiento puede encontrarse en Kowal (Behavior
Models: Specifying User's Expectations, Prentice-Hall, 1992).
Los casos de uso son la base del anlisis orientado a objetos. Los libros de Bittner y Spence
(Use Cose Modeling, Addison-Wesley, 2002), Cockburn [COCO!], Arrnour y Miller (Advanced UseCase Modeling: SO.ftware Systems, Addison-Wesley, 2000) y Rosemberg y Scot (Use-case Driven
Object Modeling with UML: A Practica/ Approach, Addison-Wesley, 1999) proporcionan una gua
valiosa en la creacin y uso de este importante mecanismo de representacin y logro de requerimientos.
Arlow y Neustadt han escrito apreciables anlisis del UML [ARL02J, Schmuller (SCH02J,
Fowler y Scott (UML Distilled, 2a. ed., Addison-Wesley, 1999), Booch y sus colegas (The UML User
Guide, Addison-Wesley, 1998) y Rumbaugh y sus colegas (The Unified Modeling Language
Reference Manual, Addison-Wesley, 1998).
Los mtodos de anlisis y diseo que apoyan el proceso unificado los explica Larman
(Applying UML and Pattems: An Introduction to Obj ect-Oriented Ana[ysis and Design and the Unified
process, 2a. ed., Prentice-Hall, 2001), Dennis y sus colegas (System Ana[ysis and Design: An
Object-Oriented Approach with UML, Wiley, 2001 ), y Rosenberg y Scott (Use-Cose Driven Object
Modeling with UML, Addison-Wesley, 1999), Balcer y Mellor (EXecutable UML: A Foundationfor

Model Driven Architecture, Addison-Wesley, 2002) exponen la semntica general del UML, los
modelos que se pueden crear, y una forma de considerar el UML como un lenguaje ejecutable
Starr (Executable UML: How to Build Class Models, Prentice-Hall, 2001) ofrece una gua til y
sugerencias detalladas para crear clases de diseo y anlisis efectivos.
En Internet se dispone de una gran variedad de fuentes de informacin sobre el modelado
del anlisis. En el sitio SEPA se puede encontrar una lista actualizada de referencias de la red
que son notables para el modelado del anlisis:
ht tp://www.mhhe.com/ press man.
INGENIERA
DEL DISEO
a ingeniera del diseo abarca un conjunto de principios, conceptos yprc
ticas que conducen al desarrollo de un sistema o producto de alta calidad.
Los principios del diseo (explicados en el captulo 5) establecen una filosofia primordial que guan al diseador en el trabajo qe desempea. E:s necesa
rio comprender los conceptos del diseo antes de que se apliquen las mecnicas
de la prctica del diseo, y la prctica del diseo mismo conduce a la creacin de
varias representaciones del software, el cual sirve como guia para la actividad de
construccin que sigue.
La ingeniera del diseo no es una frase comn dentro del contexto de la ingeniera del software. Sin embargo. deberta serlo. El disefio es una actividad primordial de la ingeniera. Aprincipios de la dcada de 1990, Mitch Kapor, el creador de Lotus l-2-3, present un "manifiesto sobre el diseo de software" en DrDobbs Joumal. Ah afirma:
Qu es el diseflo? l!s el lugar en donde una persona se puede parar con un pie en
dos mundos --el mundo de ta tecnofoga y el de la gente y los propsitos humanos-e intenta unidos ...
El crtico de arqutectura romana Vitruvlus aport la nocin de que las construc~
clones bien diseadas eran aquellas que mostraban firmeza, <:Omodidad y placer, LO
mismo debe decirse 4el buen software. Fi.lmi:Za:. el programa no debe tener nlng(m
error que inhiba su funcin, Comodidad: un pt9grama debe cumplir con los propsi~
tos para los que fue creado. Placer: la experiencia de usa.r el programa debe Sr agradable. Aqi. se presentan los principios de un teona de di$CJ\O para software.
245
246
PARTE DOS
La meta de la ingeniera del diseo es producir un modelo de representacir
muestre firmeza, comodidad y placer. Para lograrlo, un diseador debe practica:

diversificacin y despus la convergencia. Belady [BEL81] establece que "la div
ficacin es la adquisicin de un repertorio de alternativas, la materia prima del
o: componentes, soluciones de componentes y conocimiento, todo contenid.:.
catlogos, libros de texto y en la mente". Una vez que se ha integrado este conjde informacin, el diseador debe elegir y tomar elementos del repertorio que e
plan los requisitos definidos por la ingeniera de requisitos (captulo 7) y el moc.
de anlisis (captulo 8). Cuando esto ocurre, se consideran y se rechazan las a.
nativas, y el ingeniero de diseo converge en "una configuracin particular de c..
ponentes y, por lo tanto, en la creacin del producto final" [BEL8l].
La diversificacin y la convergencia demandan intuicin y juicio. Estas cualicia_
estn basadas en la experiencia de construir entidades similares, un conjunto
principios que guan cmo evoluciona el modelo, un conjunto de criterios que p
miten juzgar la calidad, y un proceso de iteracin que conduce a una representaa
del diseo final.
La ingeniera del diseo para el software de computadora est en un cambio c.
tinuo, en la medida en que evolucionan mejores mtodos, mejores anlisis y e:
comprensin ms amplia. Aun en la actualidad, la mayora de las metodologas
diseo de software carecen de profundidad, flexibilidad y naturaleza cuantitat::que por lo general se asocian con disciplinas de diseo de ingeniera ms clsia:
Sin embargo, existen mtodos para el diseo de software, se dispone de criter
para la calidad del diseo, y es posible aplicar notacin de diseo. En este capn..
se explorarn los conceptos y principios fundamentales aplicables a todo el dise
de software, los elementos del modelo del diseo y el impacto de los patrones sobe! proceso de diseo. En los capitulas 10, 11 y 12 se examina una variedad de me
dos de diseo de software mientras se aplican al diseo arquitectnico, de nter'
y en el nivel de componentes.
CAPTULO 9
247
INGENIERA DEL DISEO
El diseo del software se encuentra en el ncleo tcnico de la respectiva ingeniera

y se aplica de manera independiente al modelo de software que se utilice. una vez
que se analizan y especifican los requisitos, el diseo del software es la ltima
accin de la ingeniera correspondiente dentro de la actividad del modelado, la cual
establece una plataforma para la construccin (generacin de cdigo y pruebas).
-S milagro rris comn de la i119enierio de soflwore es lo transicin del anlisis al diseo ydel diseo al cdigo.
RldinO.
Cada uno de los elementos del modelo de anlisis (captulo 8) proporciona la

informacin necesaria para crear los cuatro modelos de diseo que se requieren
para una especificacin completa de diseo. En la figura 9.1 se ilustra el flujo de
informacin durante el diseo del software. Los requisitos del software que muestran los elementos basados en escenarios, basados en clases, orientados al flujo y de
comportamiento alimentan la tarea de diseo. Mediante la notacin de diseo y de los
mtodos de diseo que se exponen en captulos posteriores, la tarea de diseo produce un diseo de datos-clase, un diseo arquitectnico, un diseo de interfaz y un
diseo de componentes.
El diseo de datos-clase transforma los modelos de anlisis y clases (capitulo 8)
en las clases de diseo y las estructuras de datos que se requieren para implemen-
Transformacin del modelo de anlisis en un modelo de diseo.
Diseo en el nivel
de componentes
t..<09romos de clase
Paquetes de onlisis
ModelosCRC
'),c,gromos de coloborocin
Modelo de diseo
248
PARTE DOS
PRCTICA DE LA INGENIER!A DEL SOFTWARE
tar el software. Las clases y relaciones que definen las tarjetas indice CRC y el contenido detallado de datos que muestran los atributos de clase y otras notaciones proporcionan la base para la actividad de diseo de datos. Una parte del diseo de da
ses puede ocurrir en conjunto con el diseo de la arquitectura del software. El dise
o de clase ms detallado se realiza a medida que se disea cada componente del
software.
El diseo arquitectnico define la relacin entre los elementos estructurales ms
importantes del software, los estilos arquitectnicos y patrones de diseo que pueden usarse para satisfacer los requisitos definidos por el sistema, y las restricciones
que afectan la manera en que se pueden implementar los patrones arquitectnicos
[SHA96J. La representacin del diseo arquitectnico -el marco de trabajo de un
sistema basado en computadora- puede derivarse de la especificacin del sistema
del modelo de anlisis y de la interaccin de los subsistemas definidos dentro de
modelo de anlisis.
El diseo de la interfaz describe la forma en que el software se comunica con los
sistemas que interactan con l y con los humanos que los utilizan. Una interfaz
implica un flujo de informacin (por ejemplo, datos o control) y un tipo de compor
tamiento especlfico. Por lo tanto, los escenarios de uso y los modelos de comportamiento proporcionan mucha de la informacin que se requiere en el diseo de la
interfaz.
El diseo al nivel de componentes transforma los elementos estructurales de lz
arquitectura del software en una descripcin procedimental de los componentes de::
ste. La informacin obtenida de los modelos basados en clases, los modelos de fluJ
y los modelos de comportamiento sirven como base para el diseo de componentes
wsten dos formas de construir un diseo de software. Uno formo es hacerlo tan simple que obviamentl ti.,
defldenls, ylo omi es bocerlo ton compticodo que no existen deficiencias obvios. El primer mtodo es mucho
4lfldl.
e.u. .....
Durante el diseo se toman decisiones que al final incidirn en el xito de la cons
truccin del software, asi como en, con el mismo grado de importancia, la facilida ..
con que el software puede mantenerse. Pero, por qu es tan importante el diseo7
La importancia del diseo del software puede describirse con una sola palabra
calidad. El diseo es la etapa en la que se fomentar la calidad en la ingeniera de
software. El diseo proporciona las representaciones del software susceptibles d~
evaluar respecto de la calidad. El diseo es la nica forma en que, de manera exacta, un requisito del cliente se puede convertir en un sistema o producto de software
terminado. El diseo del software sirve como fundamento para todas las actividades
subsecuentes de la ingeniera del software y del soporte de ste. Sin diseo se corre
el riesgo de construir un sistema inestable, el cual fallar cuando se realicen cam
bios pequeos; que ser difcil de probar; cuya calidad no podr evaluarse sino hast:
CAPTULO 9
INGENIERIA DEL DISEO
249
etapas tardas del proceso del software, cuando queda poco tiempo y ya se ha gastado mucho dinero en l.
El diseo del software es un proceso iterativo mediante el cual los requisitos se traducen en un "plano" para construir el software. Al inicio, el plano representa una
visin holstica del software. Es decir, el diseo se representa en un grado alto de
abstraccin, el cual puede rastrearse de manera directa hasta conseguir el objetivo
especfico del sistema y requisitos ms detallados de comportamiento, funcionales y
de datos. A medida en que ocurren las iteraciones del diseo, un refinamiento subsiguiente conduce a representaciones del diseo a grados mucho ms bajos de abstraccin. Estos grados an se pueden rastrear hasta los requisitos, pero la conexin
es ms sutil.
A travs del proceso del diseo, la calidad en evolucin de ste se evala con una
serie de revisiones tcnicas formales o con revisiones de diseo explicadas en el
captulo 26. McGlaughlin [MCG91] sugiere tres caractersticas que sirven como gua
en la evaluacin de un buen diseo:
El diseo debe implementar todos los requisitos explcitos contenidos en el
modelo de anlisis, y debe ajustarse a todos los requisitos implcitos que
desea el cliente.
El diseo debe ser una gua legible y comprensible para quienes generan
cdigo y quienes realizan pruebas y, en consecuencia, dan soporte al
software.
El diseo debe proporcionar una imagen completa del software -dando
direccin a los dominios de datos, funcionales y de comportamiento- desde
una perspectiva de implementacin.
Cada una de estas caractersticas es en realidad una meta del proceso de diseo.
Pero, cmo se alcanza cada una de ellas?
Directrices de calidad. Con el fin de evaluar la calidad de una representacin de
diseo se deben establecer los criterios tcnicos para un buen diseo. En secciones
posteriores de este capitulo se expondrn los conceptos de diseo que tambin sirven como criterios de calidad del software. Por ahora se presentan las siguientes
directrices:
l. Un diseo debe presentar una estructura arquitectnica que a) se haya creado
mediante patrones de diseo reconocibles, bJ la integren componentes que
PARTE DOS
250
PRCTICA DE LA INGEN1ERA DEL SOFTWARE
exhiban buenas caractersticas de diseo (stas se explican ms adelante
Cllles son
las caracte
ristkas de un
bvea diseo?
este captulo), y e) pueda implementarse de manera evolutiva, 1 para que d

esta forma facilite la implementacin y las pruebas.
2 . Un diseo debe ser modular, esto es, el software deber dividirse de man
lgica en elementos o subsistemas.
3. Un diseo debe contener distintas representaciones de los datos, la arquitec

tura, las interfaces y los componentes.
4. Un diseo debe conducir a estructuras de datos que sean apropiadas para

clases que habrn de implementarse y que procedan de patrones de datos
conocibles.
5. Un diseo debe conducir a componentes que presenten caractersticas ti

nales independientes.
6. Un diseo debe conducir a interfases que reduzcan la complejidad de las c

nexiones entre los componentes y el ambiente externo.
7. Un diseo debe obtenerse por medio de un mtodo repetible que se base e

informacin obtenida durante el anlisis de requisitos del software.
8. Un diseo debe representarse por medio de una notacin que comunique

manera eficaz su significado.
Estas directrices de diseo no se logran por casualidad. El proceso de diseo del s
ware fomenta el buen diseo aplicando principios fundamentales de diseo
metodologa sistemtica y una revisin cuidadosa.
,_Q
Evaluact6n de la calidad del diseo: la revtsl6n tcnica tormal
~ El diseo es imporlonle porque permite que un
equipo de software evale la calidad 2 del software antes

de implementan<>; es decir, en un momento en el que los
errores, omisiones o inconsistencias son fciles de corregir
y no resultan caros. Pero tc6mo se evala la calidad
durante el diseo? El software no se puede comprobar
porque no existe un software ejecutable al cual aplicarle
pruebas. Qu debe hacerse?
Durante el diseo, la calidad se evala al realizar una
serie de revisiones tcnicas formales (RTF). Las RTF se
tratan con detalle en el captulo 26, 3 pero resulta valioso
hacer un resumen de la tcnica en este punto. Una RTF es

una reunin que dirigen miembros del equipo de softwo
Por lo general participan dos, tres o cuatro personas,
depende del 6mbito de la informacin de diseo que se
revisar6. Cada persona desempea un papel: el lder de
revisin planeo la reunin, establece la agenda y de~
realiza la reunin; el relator toma notas para que nado K
olvide; el productor es la persona cuyo producto de trabo:
(por ejemplo, el diseo de un componente del software)
revisa. Antes de la reunin, cada persona en el equipa de
revisin recibe uno copio del producto de trabajo del
1 Para sistemas ms pequeos algunas veces et diseo puede desarrollarse en forma lineal.
2
Los factores de calidad tratados en et captulo 15 pueden ayudar al equipo de revisin mientras o
evala la calidad,
En este punto se podrla considerar la revisin de la seccin 26.4. Las RTF son una parte crtica
proceso de diseo y un mecanismo Importante para lograr la calidad del diseo,
CAPTULO 9
251
INGENIERA DEL DISEO
7 se le pide que lo lea en busco de errores,
o ombigedodes. Cuando lo reunin comienzo,

es detector todos los problemas del producto
poro que stos puedan corregirse antes de que
e '"'iplementocin. la RTF tiene uno duracin tpico
de entre 90 minutos y dos horas. Al concluir lo RTF, el

equipo de revisin determino s se requieren acciones
posteriores por porte del productor antes de que el
producto de trabajo del diseo puedo aprobarse como
porte del modelo de diseo final.
Atributos de calidad. Hewlett-Packard [GRA87J desarroll un conjunto de atributos de calidad; entre ellos estn la funcionalidad, la facilidad de uso, la confiabilidad,
el desempeo y la soportabilidad. Estos atributos de calidad representan un objetivo
para todo el diseo de software:
Lo funcionalidad se estima al evaluar el conjunto de caractersticas y capacidades del programa, la generalidad de las funciones que se entregan y la
seguridad del sistema en su totalidad.
Lo facilidad de uso se valora al considerar los factores humanos (captulo 12),
la esttica, consistencia y documentacin generales.
Lo confiabilidad se evala al medir la frecuencia y severidad de las fallas, la
precisin de los resultados de salida, la media del momento de fallas (MMF).
la habilidad para recuperarse de las fallas y la previsibilidad del programa.
El desempeo se mide con la velocidad de procesamiento, tiempo de

respuesta, consumo de recursos, rendimiento y eficacia.
Lo soportabi/idad combina la habilidad de extender el programa (extensibilidad), la adaptabilidad y la serviciabilidad -estos tres atributos representan
un concepto ms comn.facilidad de mantenimiento- adems, resistencia a

pruebas, compatibilidad, configurabilidad (habilidad para organizar y
controlar elementos de la configuracin de software) (captulo 27), la facilidad
con que puede instalarse el sistema, y la facilidad con que se pueden localizar
los problemas.
No todos los atributos de la calidad del software tienen el mismo peso cuando se
desarrolla el diseo del software. Tal vez una aplicacin tenga un especial inters en
la seguridad. Es posible que otra demande desempeo con un enfoque particular en la
velocidad de procesamiento. Una tercera puede centrarse en la confiabilidad. Sin
importar el peso, es importante puntualizar que estos atributos de calidad deben
considerarse al comienzo del diseo, no despus de que el diseo est completo y
haya comenzado la construccin.
252
PARTE DOS
PRcnCA DE LA INGENIERA DEL SOF'IWARE
CONJUNTO DE TAREAS
onJunto de tareas genricas para el dJseo

1. Examinar el modelo del dominio de
la informacin y disear las estructuras de
datos apropiadas para los objetos de datos y
sus atributos
2. Por medio del modelo de onlisis, seleccionar un
'
estilo arquitectnico (patrn) que sea apropiado
para el software.
3. Dividir el modelo de anlisis en subsistemas de
diseo y ubicar estos subsistemas dentro de lo
arquitectura.
Asegurarse de que codo subsistema es cohesivo en
su funcionamiento.
Disear los interfaces del subsistema.
Ubicar clases o funciones de anlisis poro coda
subsistemo.
4. Crear un conjunto de clases de diseo o
componentes.
Traducir cada descripcin de las clases de anlisis en
una clase de diseo.
Verificar codo clase de diseo contra los criterios de
diseo; considerar los aspectos de lo herencia.
Definir mtodos y mensajes asociados con coda
clase de diseo.
5.
6.
7.
8.
Evaluar y seleccionar patrones de diseo para uro

clase de diseo o un subsistema.
Revisar las clases de diseo y modificarlas segn e
requiero.
Disear cualquier interfaz requerida con sistemas e
dispositivos externos.
Disear lo interfaz del usuario.
Revisor los resultados del anlisis de toreos.
Especificar lo secuencio de accin con base en
Crear un modelo de comportamiento de lo intena:_
Definir los objetos de la interfaz y mecanismos de
control.
Revisor el diseo de la interfaz y modificarlo segse requiera.
Conducir el diseo ol nivel de componentes.
Especificar todos los algoritmos o un grado de
abstraccin relativamente bajo.
Refinar la interfaz de coda componente.
Definir estructuras de datos al nivel de componer'&.
Revisor coda componente y corregir todos los errc"E
descubiertos.
Desarrollar un modelo de despliegue.
A travs de la historia de la ingeniera del software ha evolucionado un conjunte

conceptos fundamentales de diseo de software. Aunque el grado de inters en a:.
concepto ha variado con los aos, han pasado la prueba del tiempo. Cada uno a
ce al ingeniero de software un fundamento sobre el cual pueden aplicarse mto...
de diseo ms elaborados.
M. A. Jaclcson OAC75) dijo una vez: "El comienzo de la sabidura para [un i ~
niero de software] es reconocer la diferencia entre hacer que un programe fund
y conseguir que lo haga del modo correcto". Los conceptos fundamentales del d.
o de software ofrecen el marco de trabajo necesario para hacer las cosas "del mcorrecto".
9.3.1 Abstraccin
Cuando se considera una solucin modular a cualquier problema se pueden expo:muchos grados de abstraccin. En un alto grado de abstraccin una solucin se es
blece en trminos generales con el lenguaje del entorno del problema. En los grac.
de menor abstraccin se proporciona una descripcin ms detallada de la solucia
CAPTULO 9
253
INGENIERA DEL DISEO
,. absttGuilres lma ele lo.s formas fundamentales en los que el humano se enfrenta ala Coll)lllet"ldad:
<
Wyhodi'
'"
En la medida en que cambian los diferentes grados de abstraccin se trabaja para
crear abstracciones procedimentales y de datos. Una abstraccin procedimental se
refiere a una secuencia de instrucciones que tiene una funcin especfica y limitada.
El nombre de abstraccin procedimental implica estas funciones, pero se omiten
detalles especficos. Un ejemplo de abstraccin procedimental sera la palabra abrir
para una puerta. Abrir implica una larga secuencia de pasos procedimentales (por
ejemplo, caminar a la puerta, alcanzar la manija, darle vuelta a la manija y empujar
la puerta, hacerse a un lado para abrir paso a la puerta que se abre, etc.). 4
Una abstraccin de datos es una coleccin nombrada de datos que describe un
objeto de datos. En el contexto de abstraccin procedimental, abrir se puede definir
como una abstraccin de datos llamada puerta. como cualquier objeto de datos, la
abstraccin de datos para puerta abarcara una serie de atributos que la describan
(por ejemplo, puerla, tipo, direccin de aperlura, mecanismo de apertura, peso, dimensiones) .
Se puede decir que la abstraccin procedimental abrir empleara la informacin contenida en los atributos de la abstraccin de datos puerta.
9.3.2
Arquitectura
La arquitectura del software alude a "la estructura general del software y las formas
en que la estructura proporciona una integridad conceptual para un sistema"

[SHA95aJ. En su forma ms simple, la arquitectura es la estructura u organizacin de
los componentes del programa (mdulos), la manera en que stos componentes
interactan, y la estructura de datos que utilizan los componentes. En un sentido
ms amplio, sin embargo, los componentes pueden generalizarse para representar
elementos importantes del sistema y sus interacciones.
"Uno dfquilduro de software es el producto del trabajo de desarrollo que ofrece el mayor rendimiento cle lo
inVersin con respecto o lo colichid, el tiempo y el costo.
"
t.n Ban flrl,
Una de las metas del diseo de software es derivar una representacin arquitectnica de un sistema. Esta representacin sirve como el marco de trabajo a partir del
cual se conducen actividades de diseo ms detalladas. Un conjunto de patrones
Sin embargo, debe notarse que un conjunto de operaciones puede reemplazarse con otro, siempre
que la funcin implicada por la abstraccin de procedimiento sea la mi sma. Por lo tanto, los pasos
requeridos para implementar abrir podran cambiar en forma sustancial si la puerta fuera automtica y estuviera unida a un sensor.
PARTE DOS
PRCTICA DE LA INGENIERA DEL SOFl'WARE
arquitectnicos permite que un ingeniero de software reutilice conceptos en el ru

de diseo.
No debe de;orse que
lo orquiteduro sucedo
po, si solo. Si eso
poso, el resto del
tiempo de proyecto se
invertir en tratar de
obligarlo oajustarse ol
diseo. Se recomiendo disear lo
o,quiteclum de
manero explcito.
El diseo arquitectnico puede representarse al usar uno o ms de muchos m~

los diferentes [GAR95J. Los modelos estructurales representan la arquitectura ccr.una coleccin organizada de componentes del programa. Los modelos del marco
trabajo incrementan el grado de abstraccin del diseo al intentar identificar marc
de trabajo repetibles del diseo arquitectnico que se encuentran en tipos de apr
dones similares. Los modelos dinmicos abordan los aspectos conductuales de
arquitectura del programa, al indicar cmo puede cambiar la configuracin de la estn.
tura o el sistema, como funcin de los eventos externos. Los modelos del procese
centran en el diseo del proceso tcnico o de negocios que el sistema debe cor _
ner. Por ltimo, los modelos funcionales pueden utilizarse para representar la je..;=,
qua funcional de un sistema. El diseo arquitectnico se expone en el captulo 10
9.3.3 Patrones
Brad Appleton define un patrn de diseo de la siguiente manera: "Un patrn es
semilla de conocimiento, la cual tiene un nombre y transporta la esencia de una so:
cin probada a un problema recurrente dentro de cierto contexto en medio de r.
reses en competencia" [APP98J. Dicho de otro modo, un patrn de diseo desa:
una estructura de diseo que resuelve un problema de diseo particular dentro
un contexto especfico y en medio de "fuerzas" que pueden tener un impacto e.
manera en que se aplica y utiliza el patrn.
1.t
patrn.
un probl$no que ocurre uno yotra vez en nuestro entorntt, yd~ clesulb&o ~ la
soilKllAi<ho prbleno, de tal forma que puedas usar esta solucin un m~l11 de:ve<~ ms, sfrl IIQfl(O lmrlo
di i lllisml! forma."
'*
La finalidad de cada patrn de diseo es proporcionar una descripcin que le

mita al diseador determinar 1) si el patrn es aplicable al trabajo actual, 2) si
patrn se puede reutilizar (por ende, ahorrar tiempo del diseo), y 3) si el pat:"
puede servir como gua para desarrollar un patrn similar, pero diferente en cu~
a la funcionalidad o estructura. Los patrones de diseo se exponen con mayor de:
lle en la seccin 9.5.
9.3.4 Modularidad
Los patrones de arquitectura y diseo de software materializan la modularidad
decir, el software se divide en componentes con nombres independientes y que es pe
ble abordar en forma individual. Estos componentes llamados mdulos se integ:para satisfacer los requisitos del problema.
Se ha establecido que la "modularidad es el atributo particular del software e
permite que un programa sea manejable de manera intelectual" [MYE78J. El sofi"
re monoltico (es decir, un programa grande compuesto por un mdulo sencillo
CAPTULO 9
255
INGENIERA DEL DISEO
puede entenderlo con facilidad un ingeniero de software. El nmero de rutas de control, la amplitud de las referencias, el nmero de variables y la complejidad general
imposibilitara comprenderlo. Este punto se ilustra con el siguiente argumento,
basado en observaciones de solucin de problemas humanos.
Considrense dos problemas, p 1 y p 2. Si la complejidad observada para p 1 es
mayor que la de p 2 se deduce que el esfuerzo requerido para resolver p I es mayor que
el esfuerzo necesario para resolver p 2 Como un caso general, este resultado es obvio
en el sentido intuitivo; la resolucin de un problema dificil toma ms tiempo.
Tambin se deduce que la complejidad observada de dos problemas, cuando
estn combinados, con frecuencia es mayor que la suma de las complejidades observadas cuando cada una de ellas se toma por separado: esto conduce a una estrategia de "divide y vencers" (es ms fcil resolver un problema complejo cuando ste
se divide en piezas ms manejables). Esto tiene implicaciones importantes con respecto a la modularidad y al software. De hecho, es un argumento para la modularidad.
Es posible concluir que si el software se subdivide en forma indefinida, el esfuerzo requerido para desarrollarlo se reducir en forma sensible. Por desgracia, hay
otras fuerzas que entran en juego, lo que ocasiona que esta conclusin sea (tristemente) invlida. En relacin con la figura 9.2, el esfuerzo (costo) para desarrollar un
solo mdulo de software decrece conforme se incrementa el nmero de mdulos. Si
se tiene el mismo conjunto de requisitos, ms mdulos significan un tamao individual menor. Sin embargo, a medida que crece el nmero de mdulos, el esfuerzo
(costo) asociado con la integracin de los mdulos tambin crece. Estas caractersticas conducen tambin a la curva total del costo o el esfuerzo que se muestra en la
figura. Existe un nmero M de mdulos que resultara en un costo de desarrollo
mnimo, aunque hasta el momento no se tiene la sofisticacin necesaria para predecir M con seguridad.
Las curvas que se muestran en la figura 9.2 proporcionan una gua til cuando se
considera la modularidad. sta debe aplicarse, pero se debe tener cuidado de per-
1 Costo total del soflware
'costo por .integrar
Regin de costo
mnimo
...,..,
...---"----,
. . r--, . .
1
I
,
;
;'
.,.,
- - - - - Costa/mdulo
Nmero de
mdulos
256
manecer en la vecindad de M. Debe evitarse la modularidad excesiva o insuficiente

pero cmo puede conocerse la vecindad de M? Qu tan modular debe hacerse e
software? Las respuestas a estas preguntas requieren comprender otros conceptos
de diseo que se considerarn despus, en este mismo captulo.
Un diseo y el programa resultante se modularizan de manera que el desarrollr
se pueda planear con mayor facilidad; se puedan definir y entregar incrementos de
software; los cambios puedan ajustarse con mayor facilidad; las pruebas y la elim.nacin de errores se pueda conducir con ms eficiencia, y el mantenimiento se
pueda conducir sin efectos laterales de consideracin.
9.3.5 Ocultacin de informacin

El concepto de modularidad conduce a todos los diseadores de software a fonm ..larse una pregunta fundamental: cmo puede descomponerse una solucin de software para obtener el mejor conjunto de mdulos? El principio de ocultacin de info. macin [PAR72] sugiere que los mdulos "se caracterizan por las decisiones de dise-
--,
&'
CLAVE
lo finolidod de lo
ocultacin de
informacin es reseivor
los detalles de los
estructuras de datos y
de los procesamientos
de procedimiento
detrs de uno intertoz
del mdulo. El
conocimiento de los
detalles no debe estor
ol olconce de los
usuorios del mdulo.
o que (cada uno) oculta a los otros". En otras palabras, los mdulos deben especficarse y disearse de manera que la informacin (procedimiento y datos) que est..
dentro del mdulo sea inaccesible para otros mdulos que no necesiten esa infor
macin.
La ocultacin implica que se puede conseguir una modularidad efectiva al defir
un conjunto de mdulos independientes que se comuniquen entre s y que inte
cambien slo la informacin necesaria para lograr la funcin del software. La abs
traccin ayuda a definir las entidades de procedimiento (o informacin) que conforman el software. La ocultacin define y fortalece las restricciones de acceso para lo.a:
detalles de procedimiento dentro de un mdulo y para cualquier estructura de date
local que utilice el mdulo [ROS75] .
El uso de la ocultacin de informacin, corno un criterio de diseo para sistema:c;
modulares, proporciona los mayores beneficios cuando se requieren modificaciones
durante la realizacin de las pruebas y, despus, en el curso de mantenimiento de
software. Como la mayora de los datos y procedimientos est oculta de las otra..
partes del software, existe una probabilidad menor de introducir errores inadvertido_
al realizar las modificaciones y propagarlos a otros lugares dentro del software.
9.3.6 Independencia funcional

El concepto de independencia funcional es la suma directa de la modularidad y de !oc
conceptos de abstraccin y ocultacin de informacin. En referencias obligadas
sobre el diseo de software, Wirth [WIR7 l] y Pamas [PAR72] aluden a las tcnicas de refnamiento que mejoran la independencia de los mdulos. Trabajos posteriores de
Stevens, Myers y Constantine [STE74] consolidaron el concepto.
La independencia funcional se consigue al desarrollar mdulos con una funcioc
"determinante" y una "aversin" a la interaccin excesiva con otros mdulos. Dich...
de otra manera, se desea disear el software de tal manera que cada mdulo aborde
una subfuncin especfica de los requisitos y tenga una sola interfaz cuando se
CAPTULO 9
INGENIERIA DEL DISEO
257
observe desde otras partes de la estructura del programa. Es justo preguntarse por
qu es importante la independencia.
El software con una modularidad efectiva, es decir, con mdulos independientes,
es ms fcil de desarrollar porque la funcin se puede fraccionar y las interfaces se
simplifican (considrense las ramificaciones cuando el desarrollo se realiza en equipo). Los mdulos independientes son ms fciles de mantener (y probar) porque se
limitan los efectos secundarios que originan las modificaciones al diseo o al cdigo, se reduce la propagacin de errores, y es posible emplear mdulos reutilizables.
En resumen, la independencia funcional es una clave para el buen diseo, y el diseo es la clave para lograr la calidad del software.
La independencia se evala aplicando dos criterios cualitativos: cohesin y acoplamiento. La cohesin es una medida de la fuerza funcional relativa de un mdulo.
El acoplamiento es una medida de la interdependencia relativa entre los mdulos.
La cohesin es una extensin natural del concepto de ocultacin de informacin
descrito en la seccin 9.3.5. Un mdulo cohesivo realiza una sola tarea, para lo que
requiere muy poca interaccin con otros componentes en otras partes del programa.
Dicho de manera sencilla, un mdulo cohesivo debe (idealmente) hacer slo una cosa.
El acoplamiento es una medida de la interconexin entre los mdulos de una
estructura de software. El acoplamiento depende de la complejidad de la interfaz
entre los mdulos, el punto donde se realiza una entrada o referencia a un mdulo,
y los datos que pasan a travs de la interfaz. En el diseo de software se intenta conseguir el acoplamiento ms bajo posible. una conectividad sencilla entre los mdulos da como resultado un software ms fcil de entender y menos propenso a experimentar el "efecto ola" [STE74]. el cual se presenta cuando surgen problemas en un
lugar y despus se propagan a travs del sistema.
9.3.7 Refinamiento
El refinamiento paso a paso es una estrategia de diseo descendente que propuso inicialmente Niklaus Wirth [WIR71) . El desarrollo de un programa se realiza al refinar
de manera sucesiva los niveles de detalle procedimentales. Una jerarqua se desarrolla al descomponer el enunciado macroscpico de una funcin (una abstraccin
procedimental) paso a paso hasta alcanzar las oraciones del lenguaje de programacin.
En realidad, el refinamiento es un proceso de elaboracin. Se inicia con el enunciado de una funcin (o una descripcin de datos) que se define con un alto grado
de abstraccin. Esto es, el enunciado describe los datos o la funcin de manera conceptual, pero no proporciona informacin acerca de los trabajos internos de la funcin o de la estructura interna de los datos. El refinamiento hace que el diseador
trabaje sobre el enunciado original y que proporcione ms y ms detalles conforme
se realiza cada refinamiento sucesivo (elaboracin)
La abstraccin y el refinamiento son conceptos complementarios. La abstraccin
le permite a un diseador especificar procedimientos y datos sin considerar detalles
258
de grado menor. El refinamiento ayuda al diseador a revelar los detalles de

menor mientras se realiza el diseo. Ambos conceptos auxilian al diseador e:-creacin de un modelo de diseo completo a medida que evoluciona la activicla.
diseo.
"No fall. Slo enM1tr6 10 000 formas faOidos de hacer los cosos:
m1m,+,m1
9.3.8 Refabricacin
En www.
rtfo(torin..<011
Una actividad importante de diseo que sugieren muchos mtodos giles (ca::
se pueden 8fl<Olr
excelentes reCIMSOS
m lo rafubriar:n.
de un componente sin cambiar su funcin o comportamiento. Fowler [FOW99l ~
lo 4) es la refabricadn, tcnica de reorganizacin que simplifica el diseo (o c<X'..

ne la refabricacin de la siguiente manera: "La refabricacin es el proceso de
biar un sistema de software de tal forma que no se altere el comportamiento
no de su cdigo [diseo) y an as se mejore su estructura interna."
Cuando un software se refabrica el diseo existente se examina en busca
redundancias, elementos de diseo intiles, algoritmos innecesarios o insufici
estructuras de datos inapropiadas o construidas de manera incorrecta, o cu
otra falla de diseo que se pueda corregir para lograr un mejor diseo. Por ee.
una primera iteracin de diseo podra producir un componente que muestra
cohesin (realiza tres funciones que tienen muy pocas relaciones entre si). E!
fiador puede decidir que el componente debe refabricarse en tres componentes
tintos, cada uno de ellos con una elevada cohesin. El resultado ser un soft
ms fcil de integrar, probar y mantener.
HOGARSEGURO
conceptos de disefio
los actores: Vinod, Jomie y Ed, miembros del equipo

de ingeniera del ilOftware de HogarSegvro. Tambin,
Shokiro un nuevo miembro del qvipo.
la convnllci6ft:
cuatro miembros del equipo a<:oban de regresar de
NMlnOtio matutino, titulado ..Aplicacin de concepto$
de diseo", que ofreci un profesor local de
computacional )
,,..... tol*,Meron algo del seminorio2

..
tabla la mayor parte de los cosos, pero
no es una mola idea escucharlas de nuevo.
Jamie: Cuando realizaba mis estudios prof.sionales

se nvnco entend realmente por qu la ocuhaci6n de
informacin era ton 1mportonle como dken
Vinod: Porque ... es una tcnico paro reducir la
propagacin del error en un programo, En n10lidod
lo independencia fvncionol 1ombin se logra lo mi

Shakira: Yo no tengo un ttulo en SC, entonces m
de la$cosos que mencion el instrvctcr son nuevm
m. Yyo puedo generar un buen cdigo y rpido No
veo por qu esle awnto es ton ,mportanle
Jamie: He visto 1v trabajo, Shak, y tsabes ~ T
hace$ mucho$ de estos >sos en forma natural

es que tus diseos y tu cdigo funcionan.
petr
CAPTULO 9
INGENIERA DEL DISEO
259
9.3.9 Clases de diseo

En el captulo 8 se mencion que el modelo de anlisis define un conjunto completo de clases de anlisis. Cada una de estas clases describe algn elemento del dominio del problema, con enfoque en los aspectos del problema visibles para el usuario
o el cliente. El grado de abstraccin de una clase de anlisis es relativamente alto.
Conforme evoluciona el modelo de diseo, el equipo de software debe definir un
conjunto de clases de diseo que l) refine las clases de anlisis al proporcionar detalles del diseo que permitirn la implementacin de las clases, y 2) produzca un conjunto nuevo de clases de diseo que implementen una infraestructura de software
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 [AMBO!] :
Las clases de interfaz con el usuario definen todas las abstracciones necesarias
para la interaccin humano-computadora (IHC). En muchos casos, la IHC
ocurre dentro del contexto de una metfora (por ejemplo, un libro de verificacin, un formato de orden, una mquina de fax) y las clases de diseo para la
interfaz pueden ser representaciones visuales de los elementos 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) necesarios para implementar algn elemento del dominio de
negocios.
Las clases de proceso implementan abstracciones del negocio en un nivel ms
bajo, las cuales se requieren para manejar por completo las clases del
dominio de negocios.
Las clases persistentes representan almacenamientos de datos (por ejemplo,
una base de datos) que persistirn ms all de la ejecucin del software.
260
PARTE DOS
PRACTICA DE LA INGENIERIA DEL SOFTWARE
Las clases de sistema implementan las funciones de gestin y control de

software que permiten que el sistema opere y se comunique dentro des
entorno de computacin y con el mundo exterior.
A medida que evoluciona el modelo de diseo el equipo de software debe
llar un conjunto completo de atributos y operaciones para cada clase de di~
grado de abstraccin se reduce conforme cada clase de anlisis se transfon=:z
una representacin del diseo. Esto es, las clases de anlisis representan ob
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 gU1a
implementacin.
Arlow y Neustadt (ARL02] sugieren revisar cada clase de diseo para asegure::
la misma est "bien formada Ellos definen cuatro caractersticas de una di,s;
diseo bien formada:
Qu es
,na clase de
diseo "bien
formada"?
completa y suficiente. Una clase de diseo debe ser la encapsuJacin c

ta de todos los atributos y mtodos que se pueden esperar, en forma razonab!e
base en una interpretacin reconocible del nombre de la clase), que exista,...
clase. Por ejemplo, la clase escena definida para el software de edicin de , _ _ .,,_
est completa slo si contiene todos los atributos y mtodos que pueden a
de manera razonable con la creacin de una escena de video. La suficiencia
ra que la clase de diseo contenga slo aquellos mtodos que sean suficientes
lograr el objelivo, ni ms ni menos.
Primitivismo. Los mtodos asociados con una clase de diseo deben enfi
en el cumplimiento de un servicio para la clase. Una vez que el servicio ha
implementado con un mtodo, la clase no debe proporcionar otra forma de c
mentar la misma cosa Por eemplo, la clase videoclip del software de edi
video podran tener atributos punto-inicial y punto-final para indicar los puntos de
y fin del cltp (ntese que el video bruto cargado en el sistema puede ser mas
que el clip que se usa) Los mtodos establecerPuntolnicial() y establecerPuntoFinal:
porcionan los nicos medios para configurar los puntos de inicio y fin del clip.
cohesin alta. una clase de diseo cohesiva tiene un conjunto de respo
dades pequeo y enfocado, y aplica atributos y mtodos de manera sencilla
implementar dichas responsabilidades. Por ejemplo, la clase Videoclip del
re para la edicin de video podra contener un conjunto de mtodos para videoclip. Mientras cada mtodo se enfoque slo en atributos asociados con cl
clip se mantendr la cohesin.
Acoplamiento bajo. Dentro del modelo de diseo es necesario que las el

diseo colaboren con alguna otra. Sin embargo, la colaboracin se debe ma
en un mnimo aceptable. Si un modelo de diseo tiene un acoplamiento alto
las clases de diseo colaboran con todas las otras clases de diseo), el sist
dificil de implementar, probar y mantener a travs del tiempo. En general, las
CAPTULO 9
261
INGENIERA DEL DISEO
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 mtodo slo debe enviar mensajes a mtodos de clases vecinas.5
PlanodePlonta
tipo
dimensiones exteriores
ogregorCmoro( l
ogregorPared{ }
ogregorVenlono( )
borrorSegmenlo( )
dibujar()
Cmara
1
tipo
id
C<:tmpodevisin
ngulodebsquedo
Coofigurocinacercomiento
~1
Segm-,nto
Coordenadoinicio
Coordenodofin
obtenerTipo( )
dibujar()
f
1
S99mentodepard
000
Ventona
.,
.....
Rejlnadn de una dase de anlisis en una clase de diseo
"'
Ed: Entonces irecoerJos lo dc;iw PlcmoclePlanta,

Se utiliza como uoo porte de lasJvl'ICiones de vigilancio y
administracin del hogar.
Vinod (afirmando con la cabeza): S, me parece
~ t n lo dose PlanodePlonta {vase el
enel ruodro de la seccin 8.7.4 y la figuro
4] y lo ha refinado para el modelo de diseo.)
recordar que la usamos como porte de nuestros onl1sis

de CRC poro lo odminsftqcn del hogor,
Ed: lo hicimos. De cuolquei- monera, lo estoy refinando
poro el diseo. Quiero mostrar cmo implementaremos
S Una forma menos formal de enunciar la Ley de Demter es: "Cada unidad debe hablar slo con sus
amigos; no con extraos."
262
PARTE DOS
Ecl (afirmando funcionar6.
..
Vinod: Yo tambi-.
--~c&v1
&'
El modelo de diseo
tiene cuatro elementos
importantes: datos,
arquitectura,
componentes e
interfaz.
El modelo de diseo puede verse en dos dimensiones diferentes, como se ilustra ...
la figura 9.4. La dimensin del proceso indica la evolucin del modelo de diseo ca:forme se ejecutan las tareas de diseo como una parte del proceso del software. dimensin de abstracdn representa el grado de detalle a medida que cada eleme:to del modelo de anlisis se transforma en un equivalente del diseo y despus se
refina de una manera iterativa. En la figura, la lnea punteada indica la frontera en..~
los modelos de anlisis y diseo. En algunos casos se distingue con claridad entre :
modelos de anlisis y diseo; en otros, el modelo de anlisis se combina con el diseo y la distincin resulta menos obvia.
Los elementos del modelo del diseo utilizan muchos de los diagramas en u _
aplicados en el modelo de anlisis. La diferencia es que estos diagramas estn renados y elaborados como parte del diseo; se proporciona un mayor detalle para
implementacin especfica y se resaltan la estructura y el estilo arquitectnicos, :~
componentes que residen dentro de la arquitectura y las interfaces entre los com~
nentes y con el mundo exterior.
"llS ~ ocera1 de si el diseo es ne<esmio o evitable estn bastante fuero de lugar. el disefte es ilevitaWe. la
tllernalivo al MIi mseio es el mal diseo yno su inexisten<io.
Sin embargo, es importante mencionar que los elementos del modelo anotados
lo largo del eje horizontal no siempre se desarrollan de una manera secuencial. ::.la mayora de los casos, el diseo arquitectnico preliminar establece la platafonr_
y lo siguen el diseo de interfaz y el diseo al nivel de componentes, los cuales _
menudo se realizan en paralelo. El modelo de despliegue con frecuencia se retras..
hasta que el diseo ha sido desarrollado por completo.
CAPTULO 9
263
INGENIERA DEL DISEO
Dimensiones del modelo de diseo.
Alto
, ...... -~isit
,o
w
"2
..
CII
,, -e
,o
e
j
Oiogromos de clase
Paquets de on61isis
Moi:lelo,CRC
D~~~~~rC:,~~~
Diagramas
de doto.s
de flujo
Diogromo1 de flujo
de control
Narrativos de
procesamiento
DiogromoJ de close
Paquetes e anlisis
Moilelos CRC
Casos de uso - texto

D;feg~~;;ios de coso
Diagramas de act1v1dad
D,agromos de carril
D~~~~g~,~~~~
O,ogromos e estado
1 Realizaciones de clase
de diseo
Subsistemas
Oiairamos de
co oborocin
)..._cte..Aol 1
D1a9romas
de secuencia
t-Diseo de interfose
tcnica
Diseo de nave9oci6n
Diseo de IGU
iy
Diagramas de secuencia
.........i-- .. ................
Dia9romos de colaboroci6n
Diagramas de componente
Clases de diseo
Diagramas de actividad
Diagramo, de secuencio
ases e no
aetivida!'.l
1agromos e secuencia
8!09romas
Elementos
orquitect6nicos
Elementos
de interfoz
.. -......................
Diagramas de secuencio
ea9ro~o'd~ s;omponente
~~~6C~,~~i6~
. . . .
Realizaciones de clase
ele diseo
Rsfinamisntos a:
si stemasd
Requisitos:
Restriccionef
lnteroperobi idod
Objetivos y
configuroci6n
Diagramas de componente
Clases de diseo
Diagramas de actividad
l?elinami,mlos a:
R~ti~~~if;es de clases
Boto
D~~~~g6r~~~~
Dxgramas ~e flujo
e datos
D;fe~~~~~~ de flujo
1
Narrativas de
procesamiento
Diagramas de estado
Elementos al nivel
de componenles
---
Subsistemas
Diagromas de despliegue
Elementos al nivel
del despliegue
Dimensin del proceso
9.4. l
Elementos del diseo de datos
Al igual que otras actividades de la ingeniera del software, el diseo de datos (algunas veces llamado arquitectura de datos) crea un modelo de datos o informacin que
se representa con un alto grado de abstraccin (la visin de los datos del cliente/usuario). Despus, este modelo de datos se refina en representaciones que de manera
progresiva tienen una implementacin especfica y que pueden procesarse mediante el sistema basado en computadora. En muchas aplicaciones de software la arquitectura de los datos tendr una profunda influencia sobre la arquitectura del software que los debe procesar.
La estructura de los datos siempre ha sido una parte importante del diseo del
software. Al nivel de los componentes del sistema, las estructuras del diseo de
datos y los algoritmos con que se manipulan son esenciales para la creacin de aplicaciones de alta calidad. Al nivel de aplicacin, la traduccin de un modelo de datos
(obtenido como una base de la ingeniera de requisitos) a una base de datos es esencial para alcanzar los objetivos de negocio de un sistema. Al nivel de negocios, la
coleccin de informacin almacenada en bases de datos dispersas y reorganizadas

en una "conjuncin de datos" permite la explotacin de datos o el descubrimiento de
un conocimiento que puede tener un impacto sobre el xito del mismo negocio. En
264
PARTE DOS
&'
cada caso, el diseo de datos juega un papel importante. El diseo de datos se explica con mayor detalle en el captulo JO.
"'
c&v1
El modelo
arquitectnico se
derivo del dominio de
aplicacin, del modelo
de onlisis y de los
estilos y patrones
disponibles.
9.4.2
PRcnCA DE LA INGENIERA DEL SOF1WARE
Elementos del diseo arquitectnico
ir.-
El diseo arquitectnico para el software es el equivalente al plano de planta de

casa. Este plano muestra la configuracin general de las habitaciones, su tamaf
forma y las relaciones entre ellas, y las puertas y ventanas que permiten el mo miento hacia y desde los cuartos. El plano de planta proporciona una visin glob;;:
de la casa. Los elementos del diseo arquitectnico dan una visin general del soware.
""""5 uu un llornidor en lo 1ablo de diseo oun martillo en el sitio de construccin:
El modelo arquitectnico [SHA96J se obtiene a partir de tres fuentes: 1) la inf<r

macin acerca del dominio de aplicacin para el software que se va a construir _
los elementos del modelo de anlisis especfico, tales como diagramas de flujo d:
datos o clases de anlisis, sus relaciones y colaboraciones para el problema que :?tiene a la mano, y 3) la disponibilidad de patrones (seccin 9.5) y estilos arquitea nicos (captulo 10).
9.4.3 Elementos de diseo de interfaz

El diseo de inteifaz para software es el equivalente a un conjunto de dibujos de~llados (y especificaciones) para puertas, ventanas y utilidades externas de una casa.
Estos dibujos representan el tamao y forma de las puertas y ventanas, la manera e=:
que operan, la manera en que las conexiones de las utilidades (como agua, energ-:::
elctrica, gas, telfono) llegan a la casa y se distribuyen entre las habitaciones representadas en el plano de planta. Estos dibujos indican dnde est localizado el tr' bre de la puerta, si hay un intercomunicador que anuncie la presencia de un visita!'te y cmo est instalado el sistema de seguridad. En esencia, los dibujos (y espec:caciones) detallados para las puertas, ventanas y utilidades externas indican cr:tluyen las cosas y la informacin desde y hacia la casa y dentro de las habitacionc:...
que son parte del plano de planta. Los elementos del diseo de interfaz para so
ware muestran cmo fluye la informacin hacia o fuera del sistema y cmo ste ~
comunicado entre los componentes definidos como parte de la arquitectura.
"El pblico esl ms fumiliorizodo con el diseo molo que con el bueno. En efecto, est coodi<ionodo opefer el mol lseo poi~~
con lo que vive. lo nuevo es omenozante, lo viejo es segmo.
Existen tres elementos importantes del diseo de interfaz: 1) la interfaz con e!

usuario (IU); 2) interfaces externas a otros sistemas, artefactos, redes u otros pr.:--ductores o consumidores de informacin; y 3) interfaces internas entre varios cor.
CAPTULO 9 INGENIERIA DEL DISEO
26 5
ponentes de diseo. Estos elementos de diseo de interfaz permiten al software

comunicarse de manera externa y permiten la comunicacin y colaboracin interna
entre los componentes que pueblan la arquitectura del software.
El diseo de la IU es una accin primordial de la ingeniera de software, y se considera con detalle en el captulo 12. El diseo de una IU incorpora elementos estticos (por ejemplo, distribucin, color, grficas, mecanismos de interaccin), elementos ergonmicos (por ejemplo, informacin y ubicacin de la distribucin, metforas,
navegacin de la !U), y elementos tcnicos (como patrones de la IU, componentes
reutilizables). En general, la IU es un subsistema nico dentro de la arquitectura de
aplicacin general.
El diseo de las interfases externas requiere informacin definitiva acerca de la
entidad hacia donde se manda o recibe la informacin. En todos los casos, esta
informacin debe recopilarse durante la ingeniera de requisitos (captulo 7) y verificarse una vez que comience el diseo de la interfaz.6 El diseo de interfases externas debe incorporar revisin de errores y (cuando sea necesario) caractersticas
apropiadas de seguridad.
El diseo de las interfaces internas est cercanamente alineado con el diseo al
nivel de los componentes (capitulo I 1). Las realizaciones del diseo de clases de
anlisis representan todas las operaciones y esquemas de mensajes requeridos para
permitir la comunicacin y colaboracin entre las operaciones de varias clases. Cada
TelfonoMvil
PDAln<ilmbrico
1
1
1
~,,
'
',
1
',
PoheldControl
\
\
\
I
I
I
I
\
pontallalCD
indicadoreslfD
.--- - - - - ~ Teclado
cara cterstica sTeclado
bocina
int rfas nalmbrica
leerGolpedeTecla( )
decodificarTeclo()
desplegarEstatus( J
'
<<Interfaz>>
luzLEDs()
Teclado
enviarMensajeControl( J
eerGolpedeTeclo()
decodificarTecla()
6 No resulta poco comn que las caractersticas de la mterfaz cambien con el tiempo. Por lo tanto. un
diseador debe asegurar que la especificacin para la mteaz se mantenga actualizada.
266
PARTE DOS
EaHif:iliM1
--...1t.-
mensaje debe ser diseado para ajustarse a la transferencia de informacin de requi-
ca.te111C1111!rlllse
inxioomuy
sitos y los requerimientos funcionales especficos de la operacin que ha sido solicitada.

En algunos casos, una interfaz se modela de una manera muy parecida a una
dmu disallo
delo 111.
PRcnCA DE LA INGENIERlA DEL SOf'IWARE
clase. El UML define una interfaz de la siguiente manera [OMGOI]: "Una interfaz es
un determinante de las operaciones (pblicas] visibles de manera externa de uru::
clase. componente u otro clasificador (incluidos los subsistemas) sin especificaci"
de estructura interna". Dicho de un modo ms simple, una interfaz es un conjun~..
de operaciones que describe parte del comportamiento de una clase
acceso a esas operaciones.
y proporcion:
Por ejemplo, la funcin de seguridad de HogarSeguro emplea un panel de contro

que permite al propietario de la casa controlar ciertos aspectos de la funcin &
seguridad. En una versin avanzada del sistema, las funciones del panel de contrc
pueden implementarse va PDA inalmbrico o telfono mvil.
La clase PaneldeControl (figura 9.5) proporciona el comportamiento asociadcon un teclado y, por lo tanto, debe implementar operaciones de leerTeclaPresionado
y decodijiauTecla( ). Si estas operaciones se suministrarn a otra clase (en este case
a PDAinalmbrico y TelfonoMvil), resulta intil definir una interfaz como .:.
que se muestra en la figura. La interfaz llamada Teclado se muestra como un este
reotipo de <<interfaz>> o como un crculo pequeo y etiquetado que se conecta _
la clase con una lnea. La interfaz se define sin atributos y con el conjunto de operaciones necesarias para lograr el comportamiento de un teclado.
'<'. ,
;:.. t
_ _... fllll Cllllllln las personas cuoodo trotan de disear algo completmnente aprtlM
C 11 la ...... de los "8 son completamente tontos."
. , .. . . .
La lnea punteada con un tringulo abierto en su extremo (figura 9 .5) indica que
la clase PaneldeCOntrol proporciona operaciones de Teclado como parte de St.

comportamiento. En UML esto se caracteriza como una realizacin. Esto es, parte de
comportamiento de PaneldeCOntrol se implementar al realizar las operaciones de
Teclado. Estas operaciones se proporcionarn a otras clases que entren a la interfaz.
9 .4.4 Elementos de diseo al nivel de componentes

El diseo al nivel de componentes para el software equivale a un conjunto de dibt.jos detallados (y especificaciones) para cada cuarto en una casa. Estos dibujos muestran el alambrado y la instalacin sanitaria dentro de cada cuarto, la ubicacin de los
receptculos elctricos e interruptores, llaves, lavabos, tinas, desages
y armarios
Tambin describen los pisos que se usarn, los moldes que se aplicarn, y cualquie:
otro detalle asociado con el cuarto. El diseo al nivel de componentes para software describe por completo el detalle interno de cada componente del software. Par;:
C APiTtJLO 9
267
INGENIERA DEL DISEO
-----EJ
lograrlo el diseo al nivel de componentes define estructuras de datos para todos los
objetos de datos locales, as como detalle algortmico para todo el procesamiento
que ocurre dentro de un componente y una interfaz que permite el acceso a todas
las operaciones de los componentes (comportamientos).
"los ~ no son los detalles. Ellos hocen el diseo.
,,.
Dentro del contexto de la ingeniera del software orientada a objetos, un componente se representa a manera de diagrama en UML como se muestra en la figura 9.6.
En esta figura se representa un componente llamado ManejoSensor (parte de la
funcin de seguridad de HogarSeguro). El componente est conectado a una clase
llamada sensor, la cual est asignada a ste mediante una flecha punteada. El componente Manejosensor realiza todas las funciones asociadas con los sensores de
HogarSeguro, entre las que se encuentran su monitoreo y configuracin. En el captulo 11 se presenta una explicacin ms a fondo acerca de los diagramas de componente.
Los detalles de diseo de un componente se pueden modelar a muchos grados distintos de abstraccin. En la representacin del procesamiento lgico se puede utilizar
un diagrama de actividad. El flujo detallado de procedimiento para un componente
puede representarse, ya sea mediante un pseudocdigo (una representacin del tipo
de lenguaje de programacin que se describe en el captulo 11), o de algn formato
diagramtico (por ejemplo, un diagrama de actividad o un diagrama de flujo).
9 .4.5 Elementos de diseo al nivel del despliegue

Los elementos de diseo al nivel del despliegue indican cmo se ubicarn la funcionalidad y los subsistemas dentro del entorno computacional fsico que soportar al
software. Por ejemplo, los elementos del producto HogarSeguro estn configurados
para operar dentro de tres entornos de computacin primarios: una PC domstica, el
panel de control de HogarSeguro y un servidor ubicado en CPI Corp. (lo que proporciona acceso al sistema a travs de Internet).
Durante el diseo se desarrolla un diagrama de despliegue en UML y despus se
refina, como se muestra en la figura 9.7. En sta se muestran tres ambientes computacionales (en realidad, debera haber ms. si se incluyen sensores, cmaras y
otros). Se indican los subsistemas (funcionalidad) que se alojan dentro de cada ele-
268
UhiiU
Diagrama de
despliegue
enUMLpara
HogarSeguro.
PARTE DOS
PRCTICA DE LA INGENlERA Dl'l. SOFiWARE
Panel de control
5eAidor de CPI
.-
~'S;.,;Jmll
_____,/
- AccesoPropietorio
,...._
Vigilancia
"'
C~VE
Los diogromos de
despliegue comienzan
en un formato
descriptor, donde el
entorno de despliegue
se describe en
trminos generales.
Despus se utilizo un
fomioto de instoncio y
se describen de
mero ex~icito los
elementos de lo
mento de cmputo. Por ejemplo, la computadora personal aloja subsistemas <f..-.

implementan seguridad, vigilancia, administracin del hogar y caractersticas c.:
comunicacin. Adems, se ha diseado un subsistema de acceso externo para co~trolar todos los intentos de acceso al sistema HogarSeguro desde una fuente exte:
na. cada subsistema sera elaborado para indicar los componentes que implementa
El diagrama mostrado en la figura 9.7 est en forma de descriptor. Esto signiftc.a
que el diagrama de despliegue muestra el entorno computacional, pero no indica de
manera explcita detalles de configuracin. Por ejemplo, no se identifica la "comp..
tadora personal". Podra ser una "Wintel" PC o una Macintosh, una estacin de tra
bajo Sun o una Linux-box. Estos detalles se proporcionan cuando el diagrama de
despliegue se revisa en forma de instanda durante etapas posteriores del diseo cuando comienza la construccin. Se identifica cada instancia del despliegue (um
configuracin de hardware con un nombre especfico).
ClfflJUfOn.
... tlllle yralnn, loma ooa ~ relajacin. Cuando regreses ol trahojo, to juicio ser ms SIIJIII' T alae
. . _ parque eatonces el trabajo parece ms pequea, uno mayor porte del mismo puede
llilila yla falla de armona yproporcin se observo con ms focitidod:"
ser_.
CAPTULO 9
269
INGENIERA DEL DISEO
Los mejores diseadores en cualquier campo de trabajo tienen la misteriosa habilidad de vislumbrar patrones que caracterizan un problema y los patrones correspondientes que pueden combinarse para crear una solucin. A travs del proceso de
diseo, un ingeniero de software debe buscar toda oportunidad para reutilizar patrones de diseo existentes (cuando cumplen las necesidades de un diseo) en vez de
crear nuevos.
9.5.1
Descripcin de un patrn de diseo
Las disciplinas maduras de la ingeniera utilizan miles de patrones de diseo. Por

ejemplo, un ingeniero mecnico utiliza un eje de dos pasos como un patrn de diseo clave. Los atributos (dimetros del eje, dimensiones del orificio de las llaves, etctera) y las operaciones (por ejemplo, la rotacin del giro y la conexin del giro) son
inherentes al patrn. Un ingeniero elctrico utiliza un circuito integrado (un patrn
de diseo en extremo complejo) para resolver un elemento especfico de un problema nuevo. Los patrones de diseo pueden describirse empleando la plantilla [MAI03]
que se muestra en el recuadro "Plantilla del patrn de diseo".
Plantilla del patrn de diseo

Nombre del patrn: describe la esencia del
patrn en un nombre corlo, pero expresivo.
describe el patrn y lo que hoce.
-conocido-como: lista los sinnimos para el

9111:i~jc-')11;
proporciona un ejemplo del problema.
-;dad: anota situaciones especficas de diseo en

:uales es aplicable el patrn.
~,,..,...m: describe las clases que se requieren para
lar 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 implementa el patrn.
Patrones relacionados: patrones de diseo relacionados
mediante referencias cruzadas.
Una descripcin del patrn de diseo puede considerar tambin un conjunto de

fuerzas de diseo. Las fuerzas de diseo describen requisitos no funcionales (por
ejemplo, facilidad de mantenimiento, portabilidad) asociados con el software en el
que se aplicar el patrn. Adems, las fuerzas definen las limitaciones que restringen la manera en que se implementar el diseo. En esencia, las fuerzas de diseo
describen el ambiente y las condiciones que deben existir para que el patrn del
diseo sea aplicable. Las caractersticas del patrn (clases, responsabilidades y colaboraciones) indican los atributos ajustables del diseo para permitir que el patrn se
ajuste a una variedad de problemas [GAM95] . Estos atrtbutos representan caractersticas del diseo que pueden buscarse (por ejemplo, a travs de una base de datos)
270
PARTE DOS
PRcnCA DE LA INGNIERA DEL SOFJWARE
para que sea factible encontrar un patrn apropiado. Por ltimo, la gua asoci:.
con el uso de un patrn de diseo indica las ramificaciones de las decisiones diseo.
......
"
,.es palronls
estn all1ldio bornear, lo que significo que siempre debes termilarlos y adaplDrfo$ aIII ptapio
'
Los nombres de los patrones de diseo deben elegirse con cuidado. Uno de
problemas tcnicos clave en la reutilizacin de software es la falta de habilidad p_...
encontrar patrones reutilizables existentes, a pesar de que existen cientos o miles ..,_
patrones. La bsqueda del patrn "correcto" tiene un apoyo inmenso si se cue:1:!.
con un nombre significativo del patrn.
9.5.2 UWizacin de patrones en el diseo

Los patrones de diseo pueden usarse durante el diseo del software. Una vez ..,
se ha desarrollado el modelo de anlisis (captulo 8). el diseador puede exarr
una representacin detallada del problema que debe resolver y las restricciones
impone el problema. La descripcin del problema se examina en varios grados
abstraccin para determinar si es flexible para uno o ms de los siguientes tipos de pa..;
nes de diseo.
Qu tipos
de patrones
de diseo estn
disponibles para
el ingeniero de
sohware?
Patrones arquitectnicos. Estos patrones definen la estructura general deJ s.

ware, indican las relaciones entre los subsistemas y los componentes del sofu,
y definen las reglas para especificar las relaciones entre los elementos (da:;
paquetes, componentes, subsistemas) de la arquitectura.
Patrones de diseo. Estos patrones se aplican a un elemento especfico

diseo como un agregado de componentes para resolver algn problema de dS(:' relaciones entre los componentes o los mecanismos para efectuar la comunicac:
de componente a componente.
Idiomas. A veces llamados patrones de cdigo, estos patrones especficos de

guaje por lo general implementan un elemento algortmico o un componente
protocolo de interfaz especfico o un mecanismo de comunicacin entre los c ~
nentes.
cada uno de los tipos de patrones difiere en el grado de abstraccin con e.
est representado y con el grado en el que proporciona una gula directa para la a::.
vidad de construccin (en este caso, codificacin) del proceso de software.
9.5.3 Marcos de trabajo

En algunos casos es necesario proporcionar una infraestructura esqueltica esp,-,
fica de implementacin, llamada marco de trabajo, para el trabajo de diseo. Est
el diseador puede seleccionar una "miniarquitectura reutilizable que ofrezca el e
CAPTULO 9
INGENIERA DEL DISEO
271
portamiento y la estructura genrica para una familia de abstracciones de software,

junto con un contexto ... que especifique su colaboracin y uso dentro de un dominio dado" [APP98J.
un marco de trabajo no es un patrn arquitectnico, sino un esqueleto con una
coleccin de "puntos de conexin" (tambin llamados ganchos y ranuras) que le permiten adaptarse a un dominio de un problema especfico. Los puntos de conexin
permiten al diseador integrar clases o funcionalidad especficas del problema dentro del esqueleto. En un contexto orientado al objeto, un marco de trabajo es una
coleccin de clases que cooperan.
En esencia, el diseador de un marco de trabajo argumentar que una miniarquitectura reutilizable se puede aplicar a todo el software que se desarrollar dentro de
un dominio limitado de aplicacin. Para que sean ms efectivos, los marcos de trabajo se aplican sin cambios. Se pueden agregar elementos de diseo adicionales,
pero slo a travs de los puntos de conexin que permiten que el diseador desarrolle el esqueleto del marco de trabajo.
La ingeniera de diseo comienza cuando la primera iteracin de la ingeniera de

requisitos llega a su fin. La finalidad del diseo de software es aplicar un conjunto
de principios, conceptos y prcticas que conducen al desarrollo de un sistema o producto de alta calidad. La meta del diseo es crear un modelo de software que implemente todos los requisitos del cliente de manera correcta y complazca a aquellos
que lo usen. Los ingenieros de diseo deben examinar por medio de muchas alternativas de diseo y converger en la solucin que mejor cumpla las necesidades de
los interesados en el proyecto.
El proceso de diseo avanza de una visin general de software a una visin ms
estrecha que define el detalle requerido para implementar un sistema. El proceso
comienza con un enfoque en la arquitectura. Se definen los subsistemas; se establecen mecanismos de comunicacin entre los subsistemas; se identifican los componentes; y se desarrolla una descripcin detallada de cada componente. Adems, se
disean las interfases internas, externas y del usuario.
Los conceptos de diseo han evolucionado en la primera mitad del siglo de trabajo de la ingeniera del software. Estos conceptos describen atributos del software
de computadora que deben estar presentes sin importar el proceso de ingenieria del
software que se elija, los mtodos de diseo que se apliquen, o los lenguajes de programacin que utilicen.
El modelo de diseo abarca cuatro elementos diferentes. En la medida en que se
desarrolla cada uno de estos elementos evoluciona una visin ms completa del
diseo. El elemento arquitectnico utiliza informacin derivada del dominio de aplicacin, el modelo de anlisis y catlogos disponibles para patrones y estilos que
deriven una representacin estructural completa del software, sus sistemas y com-
272
ponentes. Los elementos de diseo de interfaz modelan interfaces internas y ext ~

nas y la interfaz del usuario. Los elementos al nivel de componentes definen ca...:
uno de los mdulos (componentes) que pueblan la arquitectura. Por ltimo, los e
mentas de diseo al nivel de despliegue asignan la arquitectura, sus component~
las interfases a la configuracin fsica que albergar el software.
El diseo basado en patrones es una tcnica que reutiliza elementos de diS:
que han probado ser exitosos en el pasado. Cada patrn arquitectnico, patrr
diseo o idioma se cataloga, se documenta por completo y se considera cuidados....
mente cuando se evala para incluirlo en una aplicacin especfica. Los marcos
trabajo, una extensin de los patrones, ofrecen un esqueleto arquitectnico pardiseo de subsistemas completos dentro de un dominio de aplicacin especfica
[AMBO I J Ambler, s.. The Object Primer. cambridge Univ. Press, 2a. ed., 2001.
[APP98J Appleton, 8., "Pattems and software: Essential Concepts and Terminology", xm
obtenerse en http://wwwenteract.com/-bradapp/docs/pattems-intro.html.
[ARI...02] Arlow, J. e l. Neusdadt, UML and the Unified Proeess, Addson-Wesley, 2002.
[BEL81] Belady, L, prlogo de Software Design, Methods and Techniques (L J. Peters, autor) 'i
don Press, 1981.
[FOWOOJ Fowler, M . et al., Refactoring: tmproving the Design of Existing Code, Addison-\\
2000.
(GAM951 Gamma, E. et al., Design Pattems, Addison-Wesley, 1995.
[GAR951 Garlan, D. y M . Shaw, #An lntroduction to software Architecture", en Advances
SOjh,vare Engineering and Knowledge Engineenng, vol. I r,,. Ambriola y G. Tortera, eds.) \Scientific Publishing Company, 1995.
[GRA87J Grady, R. 8 . y D. L. casswell, Software Metrics: Establishing a Company-Wide Pros-=
Prentice-Hall. 1987.
UAC75] Jackson, M. A., Prindples ofProgram Design, Acadernic Press, 1975.
[UE03] Lieberherr, K., "Demeter: Aspect-Oriented Programming", mayo de 2003, disponibl..::
http://www.ccs.neu.edu/home/lieber /LoD.html.
[MAI03J Maioriello, J ''What Are Design Pattems and Do I Need Them?", developer.com. 2
disponible en http://www.developer.com/design/article.php/ 1474561.
[MCG91 J McGlaughlin, R . "SOme Notes on Program Design", en Software Engineering Notes
16, nm. 4, octubre de 1991, pp. 53-54.
[MYE78] Myers, G., Composite Strudured Design, Van Nostrand, l 978.
[OMGOIJ Object Management Group, OMG Unijied Modeling Language Specificati.on, versin
septiembre de 2001.
[PAR72J Parnas. D. L., "On Criteria to be used in Decomposing Systems into Modules",
vol. 14, nm. 1, abril de 1972, pp. 221-227.
[ROS751 Ross, D., J Goodenough y C. lrvine, "SOftware Engineering: Process, Principies
Goals", en IEEE Computer, vol. 8, nm. 5, mayo de 1975.
[SCH02] Schmuller. J.. Teach Yourself UML, SAMS Publishing, 2002.
[SHA96] Shaw, M. y D. Garlan, software Architecture, Prentice-HaU, 1996.
[STA02) " Metaphor", en The Stanford HO Leammg Space, 2002, http:/ /hci.stanford.edU,::,.
concepts/metaphor.html.
[STE74J Stevens, w., G. Myers y L Constantine, "Structured Design", en IBM systems Jouma..
13, nm. 2, 1974, pp. 115- 139.
[WIR71J Wirth, N., " Program Oevelopment by Stepwise Refinement", en C4CM, vol. 14, n::l.
1971 , pp. 221 - 227.
CAPTULO 9
INGENIERA DEL DISEO
273
9.1. Se disea un software cuando se "escribe" un programa? Qu es lo que hace que el diseo de software sea diferente a la generacin de cdigo?
9.2 . Si un diseo de software no es un programa {de hecho no lo es), entonces, qu es?

9.3. Cmo se evala la calidad de un diseo de software?
9.4. Examinar el conjunto de tareas presentadas para un diseo. Cundo se evala la calidad
dentro del conjunto de tareas? Cmo se logra esto?
9.5. Dar ejemplos de tres abstracciones de datos y abstracciones procedimentales que puedan
utilizarse para manipularlas.
9.6. Describir con argumentos propios la arquitectura de software.
9 . 7 . sugerir un patrn de diseo relacionado con una categora de cosas cotidianas (por ejemplo, productos electrnicos, automviles, aparatos). Documentar el patrn con ayuda de la
plantilla que se presenta en la seccin 9.5.
9 .8 . Existe algn caso en el que los problemas complejos requieran de menos esfuerzo para
resolverse? Cmo afectara ese caso el argumento para la modularidad'
9 .9. se debe implementar un diseo modular como software monolitico? Cmo se puede
lograr esto? El desempeo es la nica justificacin para la implementacin del software monoltico?
9 . 1o. Explicar la relacin entre el concepto de ocultacin de informacin como un atributo de
modularidad efectiva y el concepto de independencia del mdulo.
9 . 11. Cmo se relacionan los conceptos de acoplamiento y portabilidad del software? Dar
ejemplos que apoyen la explicacin.
9 . 12. Aplicar un "enfoque de refinamiento paso a paso" para desarrollar tres grados diferentes
de abstraccin procedimental para uno o ms de los siguientes programas: a) Desarrollar una
mquina que expida cheques que, al dar una cantidad numrica en dlares, imprima la cantidad en palabras que por lo general se requiere en un cheque; b) resolver de manera iterativa la
raz de una ecuacin trascendental; e) desarrollar una tarea simple que planee algoritmos para
un sistema operativo.
9.13. Realizar una pequea investigacin sobre programacin extrema y escribir un texto
breve acerca de la refabricacin para un proceso de desarrollo de software gil.
9.14. Visitar un depsito de patrones de diseo (en la web) y navegue por unos minutos a travs de los patrones. Elegir uno y presentarlo ante los compaeros de clase.
Donald Norman ha escrito dos libros (The Design of Everyday Things, Doubleday, 1990, y The
Psychology of Everyday Things, HarperCollins, 1988) que se han convertido en clsicos en la
bibliografia sobre diseo y "debe" leerlos cualquiera que disee 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 diseadores que qu'eran ampliar su manera de pensar. Por
ltimo, un texto clsico de Polya (How to So/ve Jt, Princeton University Press, 2a. ed., 1988) proporciona un proceso de resolucin de problemas genrico que puede ayudar a los diseadores
de software al enfrentarse con problemas complejos.
Dentro de la misma tradicin, Winograd et al. C&mgmg Design to Software, Addison-Wesley,
1996) analiza los diseos de software que funcionan, los que no funcionan y por qu. un libro
fascinante editado por Wixon y Ramsey (Field Methods Casebook for Software Design, Wiley,
274
PARTE DOS
1996) sugiere mtodos de investigacin de campo (muy parecidos a los que utilizan los arum
plogos) para entender cmo los usuarios finales hacen el trabajo que hacen, y despus ofrec:
una gua para disear el software que satisfaga sus necesidades. Beyer y Holtzblatt (Contex....;
Design: A Customer-Centered Approach to ~ems Designs, Academic Press, 1997) ofrecen et.. il
visin del diseo de software que integra al cliente-usuario en cada aspecto del proceso .:-...
diseo de software.
McConnell (Code Complete, Microsoft Press, 1993) presenta una excelente exposicin de
aspectos prcticos de disear software para computadora de alta calidad. Robertson (Sur:;
Program Design, 3a. ed., Kboyd y Fraser Publishing, 1999) ofrece una til explicacin introo...:
toria del diseo de software para quienes comienzan su estudio acerca del tema. Fowler ) ~
colegas (Rejactoring: lmproving the Design oJExisting Code, Addison-Wesley, 1999) exponen te:
nicas para el mejoramiento incremental de los diseos de software.
En la dcada pasada se han escrito muchos libros sobre diseos basados en patrones pare
ingenieros de software. Gamma y sus colegas [GAM95] han escrito el libro fundamental so:: :,
el tema. Otros libros de oouglass (Rea/-Tfme Design Pattems, Addison-Wesley, 2002), Metsl::"'
(Design Pattems Applied, Wrox Press, 2002), Marinescu y Roman (EJB Design Pattems, v.r
2001) sitan patrones de diseo en ambientes de aplicacin y lenguajes especficos. Ader.--.zs.
los libros clsicos del arquitecto Christopher Alexander (Notes on the synthesis ofForm, Harva:!
University Press. 1964, y A Pattem La.nguage: Towns, Buildings, Construction, Oxford Univers;::I:
Press. 1977) debe leerlos el diseador de software que pretenda comprender a fondo los ~ ~
nes de diseo.
En Internet se dispone de una amplia variedad de fuentes de informacin sobre ingenie""
de diseo. Una lista actualizada de referencias en la red mundial relevantes para el diseo software y la ingeniera de diseo puede encontrarse en el sitio web de SEPA:
http://www.mhhe.com/pres.sm.an.
DISEO
ARQUIJECTNICO
....289
.276
I diseo se ha descrito como un proceso de varios pasos ert el cual las re~
presentaciones de la estructura de los datos y el programa, las caractenstkas de la informacin y el detalle procedimental se sintetizan a partir de
los requisitos. Esta descripcin la ampla Freeman (FRESO]:
fDJiseo es una actividad relacionada con la toma.de decisiones, a menudo de. naturaleza estructural. Comparte con la prograrnacit'I una preocupacin relacionada con
abstraer la representacin de la informacin y las secuencias del procesamiento, pe~
ro el grado de detalles es muy diferente en los extremos. J;l diseo construye representaciones coherentes y bien planeadas de los programas, que se concentran en las
interrelaciones entre las partes al nivel ms elevado y las operaciones lgicas et'I tos
niveles inferioresT
Como se indic en el captulo 9. el diseo est orientado a le\ infonnacin. Los

mtodos de diseo del software se derivan d la consideracin de cada uno de
los tres dominios del anlisis del modelo. Los dominios de la informacin, la funcin y el comportamiento sirven como gua para el diseo del software.
En este capitulo se presentarn los mtodos requeridos para crear "represen~
taciones coherentes y bien planeadas" de las capas de los datos y la arquitectura del modelo de dseo. El objetivo es proporcionar un enfoque sistemtico del
diseo arquitectnico: los planos preliminares que se utilizan.
tos derivados durante lo ingenierfo del sistemo y
el on6lisis de los requisitos del software.

Por qu es importante? Nadie trotara de
construir una coso sin un plono, verdad? Tam-
poco empezara o trozar piemos bosqoojando lo

d'stnbvc:16n de lo fontanera. Necesitara un fXJ"
norama general (la propio coso) cintes de pteo

cuporse por os detalles. Eso es lo que hQce el di
seo orqu ledn1co proporciona una visto gene
aseguro que se obtengo lo que se deseo.
Cui... son los pasos? El diseo orquited6ni
el diseo de 10$ dato$ y lueg<>
vac1on de uno o ms represento
dura arquitectnica del siste
_lhr., estilos o patrones orqui~
derivar lo estfucturo que se
equisitos del diente. En

275
276
PARTE DOS PRACTICA DE LA INGENIERlA en SOf'lWAR.E
En su notable libro sobre el tema, Shaw y Garlan [SHA96J analizan la arquitecttn

del software de la siguiente manera:
Desde la primera vez que un programa se dividi en mdulos los sistemas de software
han tenido arqwtecturas, y los programadores han sido responsables de las interacciones
entre los mdulos y las propiedades globales del ensamblae Histricamente las arqmtecturas han estado impllcitas (como accidentes de implementacin o sistemas heredados
del pasado) Los buenos desarrolladores de software han adoptado con frecuencia uno o
varios patrones arquitectnicos como estrategia para la organizacin del sistema, pero "'IS
emplean de manera informal y no tienen medios para hacerlos explicitos en el sistema r ._
sultante.
Hoy, la arquitectura del software efectiva y su representacin y diseo explcitos

han vuelto temas dominantes en la ingeniera del software.
,a....._ de un
,i.-
.. se
10.1.1
sisllrna es oo marco conceptual completo.,. desde su forma yeslrudln

i111gran)."
bus""
Qu es la arquitectwa?
Cuando se analiza la arquitectura de un edificio vienen a la mente muchos atrib

diferentes. En el aspecto ms simple se considera la forma general de la estruc:
fisca. Pero, en realidad, la arquitectura es mucho ms. es la manera en que los
versos componentes de un edificio se integran para formar un todo cohesionado
la manera en que el edificio se amolda a su ambiente y se combina con otros ~
cos vecinos. Es el grado en el cual el edificio cumple con el propsito estableou
en que satisface las necesidades de su propietario. Es la percepcin esttica de la
tructura -el impacto Visual del edificio- y la manera en que las texturas, los c
res y los materiales se combinan para crear la fachada externa y el "entorno vi\te" del interior Son pequeos detalles: el diseo de la iluminacin, el tipo de piS<'
colocacin de las cosas que cuelgan de las paredes, la lista es casi interminable
nalmente, se trata de un arte.
277
CAPrruLO 10 DISEO ARQUITECJ'NICO
Pero qu pasa con la arquitectura del software? Bass, Clement y Kazman [BAS03]
definen este trmino elusivo de la siguiente manera:
La arquitectura del software de un programa o sistema de cmputo es la estructura o las
estructuras del sistema, que incluyen los componentes del software, las propiedades visibles externamente de esos componentes y las relaciones entre ellos.
La arquitectura no es el software operativo. En cambio, es una representacin que

permite que un ingeniero del software: l) analice la efectividad del diseo para cumplir con los requisitos establecidos, 2) considere opciones arquitectnicas en una
etapa en que an resulta relativamente fcil hacer cambios al diseo, y 3) reduzca
los riesgos asociados con la construccin del software.
"a.se CIKllllo ontts con su arquitectura y despus arrepintase asu gusto."
.
Esta definicin destaca el papel de los "componentes del software" en cualquier
representacin arquitectnica. En el contexto del diseo arquitectnico, un componente de software es algo tan simple como un mdulo del programa o una clase
orientada a objetos, pero tambin se extiende para incluir bases de datos y middleware que permita configurar una red de clientes y servidores.
En este libro, el diseo de la arquitectura del software considera dos niveles de la
pirmide del diseo (figura 9.1): el diseo de datos y el diseo arquitectnico. En el
contexto del anlisis anterior, el diseo de los datos permite representar el componente de datos de la arquitectura en sistemas convencionales y definiciones de clase (atributos y operaciones de encapsulamiento) de los sistemas orientados a objetos. El diseo arquitectnico se concentra en la representacin de la estructura de
los componentes del software, sus propiedades e interacciones.
l 0.1.2 Por qu es importcmte la arquitectura?
En un libro dedicado a la arquitectura del software, Bass y sus colegas [BAS03J identifican tres razones clave por las cuales la arquitectura del software es importante:
Las representaciones de la arquitectura del software permiten la comunicacin entre todas las partes (participantes) interesadas en el desarrollo de un
sistema de cmputo.
La arquitectura destaca las decisiones iniciales relacionadas con el diseo que
tendrn un impacto profundo en todo el trabajo de la ingenieria del software
que le sigue y, Jo que tambin resulta importante, en el xito final del sistema
como entidad operacional.
La arquitectura "constituye un modelo relativamente pequeo e intelectualmente comprensible de cmo est estructurado el sistema y cmo trabajan
juntos sus componentes" [BAS03J
278
PARTE DOS PRCTtCA DE LA INGENJERA DEL SOFlWARE
El modelo de diseo arquitectnico y los patrones arquitectnicos que contiene

transferibles. Es decir, los estilos y patrones arquitectnicos (seccin 10.3.1) se ap
al diseo de otros sistemas y representan un conjunto de abstracciones que perrr
a los ingenieros de software describir la arquitectura de maneras predecibles.
La accin de diseo de datos traduce los objetos de datos definidos como parte
modelo de anlisis (capitulo 8) en estructuras globales al nivel de componentes
software y, cuando es necesario, una arquitectura de base de datos al nivel de
cacin. En algunas situaciones debe disearse y construirse una base de datos~
cficamente para un nuevo sistema. Sin embargo, en otras, se emplean una o
bases de datos existentes.
10.2.1 Diseo de datos al nivel arquitectnico

Hoy los negocios grandes y pequeos estn inundados de datos. No resulta pocc
mn que incluso un negocio de tamao moderado tenga docenas de bases de d~
que sirven a muchas aplicaciones que abarcan cientos de gigabytes de datos. E.
to consiste en extraer informacin til de este entorno de datos, sobre todo cua
la informacin deseada tiene funcionalidad cruzada (por ejemplo, informacir.
slo se obtiene si los datos especficos de mercadotecnia estn relacionados de
nera cruzada con los datos de ingenierla del producto).
i'dlf: . Fw1
!n el siguentasilio
Weo ~ obtillne
illformod6n (bl(a de
laste~~
okmndedo~:
.............
IWWW.
cea.
Para resolver este desafio la comunidad de empresas de la tecnologa de la infor.:.::

cin (TI) ha desarrollado la tcnica de minera de datos, tambin denominada desa
miento de conocimiento en bases de datos (DCBD). que recorre bases de datos existecon el fin de extraer informacin apropiada en el mbito de los negocios. Sin emba._
la existencia de mltiples bases de datos, sus diferentes estructuras, el grado de de:r
lle que contienen y muchos otros factores hacen que la minera de datos resulte d...
dentro de un entorno existente de base de datos. Una solucin alterna, denominada
macn de datos agrega una capa adicional a la arquitectura de datos.

Un almacn de datos es un entorno de datos independiente que no est direc
mente integrado en las aplicaciones cotidianas. pero que abarca todos los datos
!izados en un negocio [MAT96). En cierto sentido, un almacn de datos es una b.:_::
de datos grande e independiente que tiene acceso a los datos almacenados en
bases de datos que sirven al conjunto de aplicaciones requeridas en un negocio.
Conviene ms dejar el anlisis detallado del diseo de estructuras de datos, bas
de datos y almacenes de datos a los libros dedicados a estos temas (por ejemr
[DATOOO]. [PRE98]. [KIM98]). El lector interesado debe leer la seccin
y fuentes de informacin de este captulo como referencia adicional.
Otras /ecru.
CAPTULO 10
279
DISEO ARQUITECfNICO
Minera y almacenamtento
de datos
Objetivo: Los herromientos de lo minera de
ayudon en lo identificocin de relociones entre
s que describen un objeto de datos especfico o un
-""1o de objetos de dotos. los herromientas poro el
~=enomienlo de dotos oyudon en el diseo de modelos
... ..TI almacn de dotos.
ica: Estos herromientos tienen diversos mecnicos.

ger,erol, los herromientas de minero oceptan conjuntos
de datos como entrodo y permiten que el usuario
a:risulte poro trotor de comprender mejor los
.i-rw......s entre diversos elementos de dotos. los
entas de a lmacenamiento empleodos en el diseo
ionon vnculos con la entidad u otros opciones de
Objects, desorrollodo por Business Objects, SA

e,.,ww.businessobjects.com), es un conjunto de
~ientos de diseo de dotos que opoyo Nlo
integrocin, lo consulta, el informe, el onlisis y el

onlisis de dotosN.
SPSS, desorrollodo por SPSS, lnc. (www.spss.com),
proporciono uno omplio voriedod de funciones
estadsticos que permiten el onlisis de conjuntos grondes
de dotos.
Almacenamiento de datos:
lndustry Warehouse 5tudio, desorrollodo por Sybase
(www.sybose.com), proporciona uno infroestructura de
olmocn de dotos empoquetodo que "sirve como
lrompolnN poro iniciar el diseo de un almocn de dotos.
IFW Business /ntelligence Suite, desarrollado por
Modelwore (www.modelwarepl.com), es un conjunto de
modelos, herramientas de software y diseos de base
de datos que "proporcionan un camino rpido al
a lmacn de datos y a l 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
Worehousing lnformotion Center (www.dwinfocenter.org).
10.2.2 Diseo de datos al nivel de componentes

El diseo de datos al nivel de componentes se concentra en la representacin de estructuras de datos a las que se tiene acceso en forma directa mediante uno o ms
componentes de software. Wasserman [WAS80] ha propuesto un conjunto de principios que se emplea para especificar y disear estas estructuras de datos. En realidad,
el diseo de datos empieza durante la creacin del modelo de anlisis. Si se recuerda
que el anlisis y el diseo de requisitos suelen superponerse, se considerar el siguiente conjunto de principios (adaptado de [WAS80]) para la especificacin de datos:
1. Los principios del anlisis sistemtico aplicados a la funcin y el comportamiento

tambin deben aplicarse a los datos. Tambin es necesario desarrollar y revisar
las representaciones del flujo de datos y el contenido, identificar los objetos
de datos, considerar organizaciones alternas de datos y evaluar el impacto de
los datos 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 datos eficiente debe tener en cuenta las
operaciones que se realizarn en la estructura de datos. Los atributos y operaciones encapsulados dentro de una clase satisfacen este principio.
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.
280
PARTE DOS PRAcnCA DE LA INGENlERfA DEL SOFTWARE
3 . Debe establecerse un mecanismo para la definicin del contenido de cada obje!

de datos y usarlo para definir los datos y las operaciones que se les aplican. Los
diagramas de clase (captulo 8) definen los elementos de datos (atributos)

contenidos dentro de una clase y el procesamiento (operaciones) que se aplca a esos elementos de datos.
4. Las decisiones del diseo al nivel de datos deben posponerse hasta una de las ...
timas etapas del proceso de diseo. Un proceso de refinacin paso a paso es
aplicable al diseo de datos. Es decir, la organizacin general de los datos
puede definirse durante el anlisis de los requisitos, refinarse durante el trabajo de diseo de datos y especificarse de manera detallada durante el disef
al nivel de componentes.
mcx
5. La representacin de una estructura de datos slo debe conocerse para los

los que deben usar directamente los datos que contiene tal estructura. El conce:,-
to de ocultacin de la informacin y el concepto relacionado del acoplamier'

(captulo 9) proporcionan conocimientos importantes sobre la calidad de ur
diseo de software.
6. Debe desarrollarse una biblioteca de estructuras de datos tiles y tambin las

operaciones que pueden aplicrseles. Esto se logra con una biblioteca de clases
7 . Un diseo de software y un lenguaje de programacin deben dar soporte a la es
pedjicacin y la realizacin de los tipos de datos abstractos. La implementaCJ.J
de una sofisticada estructura de datos llega a volverse excesivamente difid
no existen medios para la especificacin directa de la estructura en el lengtje de programacin elegido para la implementacin.
Estos principios forman una base para un enfoque de diseo de datos, al nivel componentes, que se integre a las actividades de anlisis y diseo.
Cuando un constructor estadounidense usa la frase "colonial con una sala al centr-r
(centre hall colonia]) para describir una casa, la mayora de quienes estn famil:.:.
zados con las casas en Estados Unidos evocar una imagen general del aspecto _
la casa y de su plano general. El constructor ha usado un estilo arquitectnico ca.mecanismo descriptivo para diferenciar la casa de otros estilos (por ejemplo, ma:.
en A, rancho elevado, cape Cod). Pero algo ms importante es que el estilo arquite
tnico tambin es una plantilla para la construccin. Resulta necesario proporcioc
mayores detalles de la casa. Se deben especificar sus dimensiones finales, agregcaractersticas personalizadas. determinar los materiales de construccin, perc
estilo ("colonial con sala al centro") es el que gua el trabajo del constructor.
....... la .... de todo ar1isto hay un patrn o tipo de arquitectura."
CAPTULO 10
DISEO ARQ.UITECl'NICO
281
El software que se construye para sistemas de cmputo tambin muestra uno o

muchos estilos arquitectnicos. Cada estilo describe una categora de sistemas que
abarca 1) un conjunto de componentes (por ejemplo, una base de datos, mdulos
computacionales) que realizan una funcin requerida por el sistema; 2) un conjunto
de conectores que permiten la "comunicacin, coordinacin y cooperacin" entre los
componentes; 3) restricciones que definen cmo se integran los componentes 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), comprender las propiedades generales de un sistema.
Un estilo arquitectnico es una transformacin impuesta al diseo de todo un sistema. El objetivo es establecer una estructura para todos los componentes del sistema. En caso de que una arquitectura existente se vaya a someter a reingeniera (captulo 31), la imposicin de un estilo arquitectnico desembocar en cambios fundamentales en la estructura del software, incluida una reasignacin de la funcionalidad
de los componentes [BOSOOJ.
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 elementos 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 regla sobre la arquitectura, pues describe la manera en que el software manejar algn aspecto de su funcionalidad al nivel de la infraestructura (por ejemplo, concurrencia) [BOSOO]; 3) los patrones arquitectnicos tienden a abarcar aspectos especficos del comportamiento dentro del contexto de la arquitectura (por ejemplo, cmo
maneja una aplicacin en tiempo real la sincronizacin o las interrupciones) . Los patrones se usan junto con un estilo arquitectnico para determinar la forma de la estructura general de un sistema. En la siguiente seccin se exRondrn estilos y patrones arquitectnicos de uso comn en el software.
10.3. l
Una breve taxonoma de estilos arquitectnicos
Aunque se han creado millones de sistemas de cmputo en los ltimos 50 aos, la

gran mayora puede clasificarse (consltense [SHA96). [BUS96], [BAS03]) en un nmero relativamente pequeo de estilos arquitectnicos:
Arquitectura centrada en datos. Un almacn de datos (por ejemplo, un archivo o
una base de datos) se encuentra en el centro de esta arquitectura; otros componentes tienen acceso a l y cuentan con la opcin de actualizar, agregar, eliminar o, por
otra parte, modificar los datos de ese almacn. En la figura 10. l se ilustra un estilo
tpico centrado en datos. El software cliente tiene acceso a un almacn central. En
algunos casos ste es pasivo. Es decir, el software cliente accede a los datos independientemente de cualquier cambio hecho a los datos o a las acciones de otro software cliente. Una variacin de este enfoque transfonna el depsito en un "pizarrn"
que enva notificaciones al software cliente cuando cambian los datos de inters para el cliente.
PARTE DOS PRCTICA DE LA INGENIERA DEL SOFIWARE
Arquitectura
centrada en
datos.
Software
Softw<we
d iente
Software
denle
d ienle
Software
cliente
Software-
Software
cliente
cliente
Software
diente
Una arquitectura centrada en datos promueve la capacidad de integracin [BAS

Esto significa que es posible cambiar componentes existentes y agregar nuevos c..
ponentes cliente a la arquitectura sin preocuparse por otros clientes (ya que los ~
ponentes cliente operan en forma independiente). Adems, es posible pasar datos
tre clientes empleando el mecanismo del pizarrn (es decir, el componente piza
sirve para coordinar la transferencia de informacin entre clientes). Los com!)O':tes cliente ejecutan los procesos de manera independiente.
Arquitectura de flujo de datos. Esta arquitectura se aplica cuando los datos
entrada se habrn de transformar en datos de salida mediante una serie de compo;:r

tes para el clculo o la manipulacin. Una estructura de tuberas y filtros (figura 1
tiene un conjunto de componentes, denominados filtros, conectados por tuberas
transmiten datos de un componente al siguiente. Cada filtro funciona sin toma:-
Filtro
Filtro
Filtro
Filtro
Tuberas y filtros
Filtro
Filtto
filtro
CAPTULO 10
283
DJSEO ARQUITEC!NICO
cuenta si los componentes tienen flujo ascendente o descendente; est diseado para esperar la entrada de datos con cierta forma y producir su salida (al siguiente filtro) de una forma especifica. Sin embargo, no es necesario que el filtro conozca el
funcionamiento de los filtros vecinos.
Si el flujo de datos degenera en una sola lnea de transformaciones se denomina

procesamiento por Jotes secuencial. Esta estructura acepta un procesamiento por lotes de datos y luego aplica una serie de componentes secuenciales (filtros) para
transformarlos.
Arquitectura de llamada y retomo. Este estilo arquitectnico permite que un diseador de software (arquitecto del sistema) obtenga una estructura de programa
que resulta relativamente fcil modificar y cambiar de tamao. En esta categora hay
dos subestilos [BAS03]:
Arquitectura de programa principal/subprograma. Esta estructura de programa
clsica separa la funcin en una jerarqua de control donde un programa
"principal" invoca a varios componentes de programa, que a su vez pueden
invocar a otros componentes. En la figura 10.3 se ilustra una arquitectura de
este tipo.
Arquitectura de llamada de procedimiento remoto. Los componentes de una arquitectura de programa principal/subprograma se distribuyen entre varias
computadoras de una red.
ProglQl'IIO principal
Su=ma
co
Subprogromo
de oplicoci(,
OI'
Subprograma
de oplicocin
Subprogromo
controlodor
Subprogromo
Sobprogr<:uno
de oplicocin
de oplicacin.
Subprograma
de aplicacin
284
PARTE DOS
PRCTICA DE LA INGcNtERlA DEL SOFlWARE
Arquitectura orientada a objetos. Los componentes de un sistema encapst.. los datos y las operaciones que deben aplicarse para manipular los datos. La co:-inicacin y coordinacin entre componentes se consigue mediante el paso de meT\Sa' ~
Arquitectura estratificada. En la figura 10.4 se ilustra la estructura bsica de
arquitectura estratificada. Hay varias capas definidas; cada una de ellas realiza :-,e.
raciones que se acercan progresivamente aJ conjunto de instrucciones de la m("::
na. En la capa externa los componentes sirven a las operaciones de interfaz de us..:
rio. En la capa interna los componentes sirven como interfaz con el sistema opc:z
tivo. Las capas intermedias proporcionan servicios de utilera y de software de a;-::
caciones.
Estos estilos arquitectnicos slo son un pequeo subconjunto de los que ~
ne el diseador de software. 2 Una vez que la ingeniera de requisitos define las
racteristicas y restricciones del sistema que habr de construirse, podrn elegirse
estilo arquitectnico o la combinacin de estilos que mejor combinen con las ca:tersticas y restricciones. En muchos casos ser apropiado ms de un estilo y poo:
disearse y evaluarse distintas opciones. Por ejemplo, en muchas aplicaciones
base de datos se combina un estilo por capas (apropiado para casi todos los s
mas) con una arquitectura centrada en datos.
10.3.2 Patrones arquitectnicos

Si el constructor decide construir una casa colonial con saJa al centro slo p-...
aplicar un estilo arquitectnico. Los detalles del estilo (por ejemplo, nmero de _
2 Consltese [BOSOOJ. [HOFOOJ, [BAS03J, (SHA97], (BUS96J y [SHA96J para contar con un analis:s
tallado de los estilos y patrones arquitectnicos.
CAPTULO 10
285
DISEO ARQUITECIN!CO
Eleccin de un estilo arquitectnico
a.lllciendlo el ceo): Hemos estado modelando la

con UML . ya !Jabes, clases, relaciones y ese tipo
As que sopo~ qU(:) lo adecuado ser aplicor lo
orienll:Jc:lQ o obje1os. 3
el espacio.
Jamie: Bueno, eso no es cierto. Hay ierQrquQS de
clase... piensa en la erarqua (09re9ad6n) q hicimos
para el objeto PlanoCasa [figuro 9.3]. Una arquitectu
ro orientada a objetos es uno combinocio de esa
estructvr<:i y las interconexiones (ya sobes, coloboraei
nes) entre las clases. lo mostraremos al describir por
completo b atributo$ y las operaciones, los mensajes
que se intercambian y la estructura de las doses,
Ed: Voy a dedicar una hora a correlociQllQr \ir'ld orqui
lectura de llamada y r~romo, loego regresor aqu y
pensar en lo arquitectura orientada o objetos.
Jamie: Doug no tendr prQblema con 8$0. l dijo q~
debemos considerar orquitectvros alternos. Por cierto~ no
hay ninguna razn poro no combinar amhcs orquitectu
ros.
lo que quiero decir es que n<> logro visualizar
Ed: Bueno, en eso ~stoy.
.-uctvro real, sl el diseo de doses Rotando en
meneas, fachada de la casa, colocacin de puertas y ventanas) variarn considerablemente, pero una vez que se ha tomado la decisin de la arquitectura general de
la casa, el estilo se impondr al diseo.4
Los patrones arquitectnicos difieren un poco.s Por ejemplo, cada casa (y todo estilo arquitectnico para casas) emplea un patrn cocina, el cual define la necesidad
de colocar los articulos bsicos de cocina, un fregadero, alacenas y, posiblemente,
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 propietario). 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 durante la ingeniera del sistema y el producto (capitulo 6), pero el diseo arquitectnico dentro de la
ingeniera del software muy bien tendra que considerar estos aspectos.
Esto indica que tendr una sala central y un pasillo, que las habitaciones estarn colocadas a la izquierda y la derecha de la sala, que la casa tendr dos lo 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 sal a al centro.
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 hacen la sutil distincin sugerida en esta seccin.
286
~,
C~VE
Uno arquitectura del
softwore tiene wrios
patrones
orquilectnicos que
atienden temas como

lo concurrencia, lo
persistencia y lo
distribucin.
PARTE DOS
PRCTICA DE LA INGENIERiA OO. SOF'lWARE
reglas para ubicar cosas relacionadas con el flujo de trabajo en la habitacin. Ad<:
ms, el patrn podra especificar la necesidad de cubiertas y acabados, iluminaci'"
interruptores de pared o una isla central, pisos, etc. Obviamente, hay ms de un a.seo de cocina, pero todo diseo se concebir dentro del contexto de la "soluci&que sugiere el patrn cocina.
Como ya se indic, los patrones arquitectnicos para el software definen un e""'foque especfico para el manejo de alguna caracterstica de comportamiento del ~
tema. Bosch [BOSOOJ define varios patrones arquitectnicos. En los siguientes pr!':fos se presentan ejemplos representativos.
Concurrencia. Muchas aplicaciones deben manejar varias tareas de manera tal cr~
simulen paralelismo (es decir, esto ocurre cada vez que un solo procesador mane _
varias tareas "paralelas" o componentes). Una aplicacin tiene varias maneras .:.z
manejar la concurrencia, y cada una se presenta mediante un patrn arquitectrv
diferente. Por ejemplo, un enfoque consiste en usar un patrn de manejo de pr~
sos del sistema operativo que ofrece caractersticas integradas del sistema opera.::
vo que permiten la ejecucin concurrente de los componentes. El patrn tambin corpora funcionalidad del sistema operativo que maneja la comunicacin entre
procesos, la calendarizacin y otras funciones requeridas para alcanzar la Cf'CO
rrencia. Otro mtodo sera definir un calendarizador de tareas al nivel de aplicad
un patrn calendarizador de tareas contiene un conjunto de objetos activos, y e.a-..
uno de ellos incluye una operacin tic() [BOSOOJ. El calendarizador invoca peri~camente tic() para cada objeto, que luego realiza las funciones que debe realizar:;.:
tes de regresar el control al calendarizador, mismo que invoca de nuevo la ope::
cin tic( J para el siguiente objeto concurrente.
Persistencia. Los datos persisten si sobreviven despus de la ejecucin del pror..r.-
so que los cre. Los datos persistentes se almacenan en una base de datos o ur ;:,:
chivo; en un momento posterior, otros procesos tienen la opcin de leerlos o ~
ficarlos. En los entornos orientados a objetos la idea de un objeto persistente exte:i-de un poco ms el concepto de persistencia. Los valores de todos los atributos
objeto, el estado general de ste y otra informacin complementaria se almace.:para su aplicacin y recuperacin posterior. En general, se emplean dos patrones quitectnicos para lograr la persistencia: 1) un patrn de sistema de administroa
de base de datos que aplica las capacidades de almacenamiento y recuperacin de
sistema de administracin de base de datos a la arquitectura de la aplicacin o
un patrn de persistencia al nivel de la aplicacin que construye caractersticas de p:o
sistencia en la arquitectura de sta (por ejemplo, el software de procesamientc .
palabras que maneja su propia estructura de documento).
Distnl>ucin. El problema de la distribucin dirige la manera en que se comun..::;:
entre s los sistemas, o los componentes de stos, en un entorno distribuido. ~

problema incluye dos elementos: 1) la manera en que las entidades se conectan =l:'
tre s, y 2) la naturaleza de la comunicacin. El patrn arquitectnico ms comr ~
CAPTULO 10 DISEO ARQUITECTNICO
287
tablecido para dirigir el problema de la distribucin es el de corredor. Un corredor acta como "intermediario" entre el componente cliente y un componente servidor. El
cliente enva un mensaje al corredor (que contiene toda la informacin apropiada
para que se realice la comunicacin), el cual completa la conexin. CORBA (captulo 30) es un ejemplo de una arquitectura de corredor.
Antes de elegir cualquiera de los patrones arquitectnicos indicados en los prrafos anteriores, debe evaluarse si es apropiado para la aplicacin y el estilo arquitectnico general, adems de evaluar su facilidad de mantenimiento, confiabilidad, seguridad y desempeo.
10.3.3 Organizacin y refinamiento
Debido a que el proceso de diseo suele dejar a un ingeniero de software con varias
opciones arquitectnicas, es importante establecer un conjunto de criterios de diseo para evaluar un diseo arquitectnico. Las siguientes preguntas [BAS0.3] proporcionan una visin especifica del estilo arquitectnico que se ha derivado.
Control. Cmo se maneja el control dentro de la arquitectura? Existe una jerarqua de control distintiva y, si es as, cul es la funcin de los componentes dentro
de esta jerarquia de control? Cmo transfieren los campos el control dentro del sistema? Cmo se comparte el control entre los componentes? Cul es la topologa
del control (es decir, cul es la forma geomtrica que asume el control)? Est sincronizado el control o los componentes operan asincrnicamente?
Datos. Cmo se comunican los datos entre los componentes? El flujo de datos
es continuo o los objetos de datos se pasan espordicamente al sistema? Cul es el
modo de transferencia de los datos (por ejemplo, los datos se pasan de un componente a otro o estn disponibles globalmente para compartirse entre los componentes del sistema)? Existen componentes de datos (por ejemplo, un pizarrn o almacn) y, de ser as, cul es su papel? Cmo interactan los componentes funcionales
con los de datos? Los componentes de datos son pasivos o activos (es decir, interactan activamente con otros componentes del sistema)? Cmo interactan los
datos y el control dentro del sistema?
Estas preguntas 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 tambin 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-
288
PARTE DOS
PRCTICA DE LA INGENIERL\ DEL SOFTWARE
nas del software, el diseador especifica la estructura del sistema al definir y refi=los componentes del software que implementan la arquitectura. Este proceso prosi:i;
de manera iterativa hasta que se obtiene una estructura arquitectnica completa.
f .,., ........ ,., ...................... poed,_, .............. ~111!4 ..... J

l 0.4.1 Representacin del sistema en el contexto
,,
~
C~VE
El contexto
arquitectnico
represento lo manero
en que el software
interacto con los
entidades externos a
sus timites.
Cmo inter
actan los
sistemas &ntre s?
En el captulo 6 se indica que un ingeniero del sistema debe modelar el contexto

diagrama de contexto del sistema (figura 6.4) cumple con este requisito al represe..
tar el flujo de la informacin dentro y fuera del sistema, la informacin del usuar
el procesamiento relevante de soporte. AJ nivel de diseo arquitectnico, un are::
tecto del software aplica un diseo de contexto arquitectnico (DCA) para mode"
la manera en que el software interactuar con las entidades ubicadas ms all de
lmites. la estructura genrica de los diagramas de contexto arquitectnico se
tran en la figura 10.5.
Si se toma como referencia la figura, los sistemas que interactan con el sis..
de destino (el sistema para el que se est desarrollando un diseo arquitectnicc
representan as:
Sistemas superordinados: los que emplean el sistema de destino como parte
.z
algn esquema de procesamiento de nivel ms elevado.

Sistemas subordinados: los que utiliza el sistema de destino y que proporcio-
nan los datos o el procesamiento necesarios para completar la funciona li~del sistema de destino.
Sistemas superordinodos
.----....
Diagrama de
contexto
arquitectnico
(adaptado de
[BOSOO]).
Sistema de destino
Uses
Pares
Usan
ctores
Sistemas subordinados
CAPTULO 10
289
DISENO ARQUITECTNJOO
Sistemas al nivel de par: los que interactan de igual a igual (es decir, la informacin 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 consumiendo informacin necesaria para el procesamiento de requisitos.
Cada una de estas entidades externas se comunica con el sistema de destino mediante 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 emplea (es empleado por) la funcin de seguridad en versiones posteriores del producto. Los pneles de propietario y control son actores que actan como productores y
consumidores de la informacin utilizada, producida (o de ambos tipos) por el software de seguridad. Por ltimo, el software 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
datos 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 importantsima en el diseo de una arquitectura para el sistema de destino. En general, se
requiere un conjunto relativamente pequeo de arquetipos para disear incluso sistemas relativamente complejos. La arquitectura del sistema de destino la integran
Producto
Sistemo bosodo
HogorSeguro
en Internet
Panel de
control
Propietario
Sistema de destino:
funcin de seguridad
funcin de
Uso
vigllanda
Pares
290
PARTE DOS PRC'l'!CA DE LA INGENIERA DEL SOITWARE
arquetipos, que representan elementos estables de la arquitectura pero que pued!:dar paso a instancias de muchas maneras diferentes, con base en el comportarme
to del sistema.
En muchos casos, los arquetipos se derivan al examinar las clases de anlisis c.
finidas corno parte del modelo de anlisis. Si se contina el anlisis de la funcir ~
seguridad casera de HogarSeguro se definirian los siguientes arquetipos:
Nodo. Representa una coleccin cohesiva de elementos de entrada y salida
en la funcin de seguridad casera. Por ejemplo, un nodo estara integrado P'w
1) varios sensores y 2) varios indicadores de alarma (salida).
Detector. Una abstraccin que abarca todo el equipo de sensores que alimenta informacin en el sistema de destino.
Indicador. Una abstraccin que representa todos los mecanismos (por ejerplo, sirena de alarma, luces parpadeantes, timbre) para indicar que est oc..rriendo una condicin de alarma.
Controlador. Una abstraccin que descnbe el mecanismo que permite el a:mado o desarmado de un nodo. Si los controladores residen en una red tie:-~
la capacidad de comunicarse entre s.
Cada uno de estos arquetipos se describe con la notacin UML, como se muestra et
la figura 10.7.
Recurdese que los arquetipos forman la base de la arquitectura pero son abstrar
ciones que deben refinarse an ms a medida que avanza el diseo arquitectr.
Por ejemplo, Detector podra refinarse en una jerarqua de clase de sensores.
10.4.3 Refinamiento de la arquitectura en componentes
A medida que se refina la arquitectura del software en componentes, la estruct..J:t
del sistema empieza a emerger. Pero cmo se eligen estos componentes? Para =~
iihfiiD
Relaciones
UMLparalos
mquetipos de
la funcin de
ls.,o
....
seguridad de
HogarSeguro
(adaptado de
CBOSOOD.
munico con
1
.... ~ . . Ir
'
CAPTULO l O
291
DISEO ARQUITECTNIOO
ponder, el diseador de la arquitectura empieza con las clases descritas como parte
del modelo de anlisis. 6 Estas clases de anlisis representan entidades dentro del dominio de la aplicacin (negocio) que deben atenderse dentro de la arquitectura del
software. Por tanto, el dominio de la aplicacin es una fuente para la derivacin y el
refinamiento de los componentes. Otra fuente es el dominio de la infraestructura. La
arquitectura debe adecuarse a muchos componentes de infraestructura que habilitan los componentes de la aplicacin, pero que no tienen conexin de negocios con
el dominio de la aplicacin. Por ejemplo, los componentes de administracin de memoria, de comunicacin, de base de datos y de administracin de tareas suelen integrarse en la arquitectura del software.
La interfaz descrita en el diagrama de contexto de la arquitectura (seccin 10.4.1)
indica que uno o ms componentes especializados procesan los datos que fluyen por
la interfaz. En algunos casos (por ejemplo, una interfaz grfica de usuario) debe disearse una arquitectura completa de subsistemas con muchos componentes.
*la estructura de un smema de software proporciona lo ecologa en que noce, maduro y muere ti cdigo. Un h6bitut
llietl .._ pennite el xito en lo evolucin de todos los componentes necesarios de un sistema de S11flwore."
lt.tottts
Continuando con la funcin de seguridad casera de HogarSeguro, se definir el
conjunto de componentes de nivel superior que atienden la siguiente funcionalidad:
Administracin de comunicacin externa: coordina la comunicacin de la fun -
cin de seguridad con entidades externas; por ejemplo, sistemas de Internet,

notificacin externa de alarma.
Procesamiento del panel de control: maneja toda la funcionalidad del panel de
control.
Manejo del detector: coordina el acceso a todos los detectores conectados al
sistema.
Procesamiento de alarma: verifica todas las condiciones de alarma y acta so-
bre ellas.
Cada uno de estos componentes de nivel superior tendra que elaborarse iterativamente y luego posicionarse dentro de la arquitectura general de HogarSeguro. Para
cada uno se definiran clases de diseo (con los atributos y las operaciones apropiadas) . Sin embargo, es importante observar que los detalles de diseo de todos los
atributos y las operaciones slo se especificaran hasta la realizacin del diseo en
el nivel de componentes (captulo 11).
En la figura 10.8 se ilustra la estructura arquitectnica general (representada como
un diagrama de componentes UML) . El componente Manejo de comunicacin externa
6
Si se elige un enfoque convencional (no orientado a objetos\, es posible derivar los componentes del
modelo de flujo de datos. En la seccin 10.6 se analizar este enfoque.
292
PARTE DOS
PRCTICA DE LA INGENIERA DEL sonwARE
Estructura general de la arquitectura d e HogarSeguro con componentes de rvel su:palll'
DireciOf'
HagarSeguro
~-
''
Manejo de
Seleccin
de funcin
''
'
<!omunicocin
externo
,,
,,
Interfaz grfica
de usuario
'
''
''
''
''
'
,,
Vigilancia
,,
Admini
de lo ces::
Interfaz de
Internet
Procesamiento
de pone!
de control
Procesamiento
de alarmo
adquiere las transacciones provenientes de los componentes que procesan la ir.

grfica de usuario de HogarSeguro y la inteifaz de In teme!. El componente director de
garSeguro maneja esta informacin y selecciona la funcin de producto apropiada
este caso, segundad). El componente procesamiento de panel de control interacta
el propietario para annar o desarmar la funcin de seguridad. El componente me
de detector agrupa los sensores para detectar una condicin de alarma, y el compor: ,..
te procesamiento de alanna produce una salida cuando se detecta la alarma.
10.4.4 Descripcin de la creacin de instancias del sistema

El diseo arquitectnico que se ha modelado hasta este punto a todava es de u:"
vel relativamente alto. Se ha representado el contexto del sistema; se han defulos arquetipos que indican las abstracciones importantes dentro del dominio del;-blema; es evidente la estructura general del sistema; y se han identificado los p-::
cipales componentes del software. Sin embargo, an se necesita mayor refinarr to (recurdese que todo el diseo es iterativo).
Esto se logra desarrollando una instando de la arquitectura. Es decir, la arq~
tura se aplica a un problema especifico con el propsito de demostrar que la estr:
tura y los componentes son apropiados.
En la figura 10.9 se ilustra una instancia de la arquitectura HogarSeguro para el s
tema de seguridad. Los componentes que muestra la figura 10.8 se refinan an rpara mostrar detalles adicionales. Por ejemplo, el componente manejo de detector ir' racta con el componente de infraestructura calendarizador que implementa el agru:
miento "concurrente" de cada objeto sensor del sistema de seguridad. Una elaboracsimilar se realiza para cada uno de los componentes representados en la figura Io...
CAPTULO l O
293
DISEO ARQ.UITECTNIOO
Instancia de la funcin de seguridad con elaboracin de componentes.
-''
'
''
''
''
''
'
''
''
''
s _
''
Interfaz de
Internet
',,
',,
PrQCesarniento
depone!
de control
,,
,,
,
,,
,,
,,
,,
Com11nicaci6n
telef6nico
Colendorzodor
funciones de
despl~ue CP
Diseo arquitectnico
Objetivo: Los herramientas de diseo
arquitectnico modelan lo estructuro general del
.iore al representar interfases, dependencias,
'9IIXJOlleS e inlerocciones de los componentes.
-nica: Los herramientas cuentan con mecnicos

-Jos. En casi todos los cosos, lo capacidad del diseo
~ tectnico es porte de lo funcionalidad de los
"BTOmientos automatizados poro modelado de anlisis y
Senso,
Alarmo
(www.synthis.com), es uno herramienta especializado

poro el diseo y lo construccin de arquitectura
especficos de componentes Web.
ObjecfiF, desarrollado por microTOOL GmbH
(www.microtoof.com), es uno herramienta de diseo
UML que llevo o arquitecturas (por ejemplo, Coldfusion,
J2EE, Fusebox) sensibles o lo ingeniera de software
bosodo en componentes (captulo 30).
Rational Rose, desorrollodo por Rotionol

(www.rotionol.com), es uno herramienta de diseo
bosodo en UML que soporto todos los aspectos del
diseo arquitectnico.
7 Las herramientas expuestas slo representan una muestra de esta categora. En casi todos los casos los nombres son marcas registradas por sus respectivos desarrolladores.
294
PARTE DOS
PRCl1CA DE LA INGENIERA DEL SOFTWARE
En el mejor de los casos, el diseo produce varias opciones arquitectnicas que s-evalan para determinar cul es la ms apropiada respecto al problema que hahde resolverse. En las siguientes secciones se analizaran diseos arquitectnicos a.
ternos.
1 ....__el slane. lljame ir esaileras arribo y revisor.

10.5. l
ltC.W.
Un mtodo de anlisis de compensacin para la arquitectura
El Instituto de Ingeniera del Software (SEi, por sus siglas en ingls) ha desarrollac.
un mtodo de anlisis de compensacin para la arquitectura (MACA) [KAZ98] que .:'.
fine un proceso de evaluacin iterativo para las arquitecturas del software. Las s:
guientes actividades de anlisis del diseo se realizan iterativamente:
~Gllnlfo
..........
...,..._........,
sobreWICAse
OOll!ldlert
1. Recopilar escenarios. Se desarrolla un conjunto de casos de uso (captulos 7 _

8) para representar el sistema desde el punto 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 c::que se atiendan todas las preocupaciones 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 diseo arquitectnico se
incluyen confiabilidad, desempeo, seguridad, facilidad de mantenimiento,
flexibilidad, facilidad de prueba, portabilidad, facilidad de reutilizacin e nter
perabilidad.
5. Identificar la sensibilidad de los atributos de calidad respecto de varios atributos

arquitectnicos para un estilo arquitectnico espedjico. Esto se logra haciendo
pequeos cambios en la arquitectura y determinando la sensibilidad al cambio de un atnouto de calidad, como el desempeo. Cualquier atributo al que
afecte significativamente la variacin en la arquitectura se considerar un
punto de sensibilidad.
6. Analizar las arquitecturas a/temas (desarrolladas en el paso 3) empleando el an..

lisis de sensibilidad aplicado en el paso 5. El SEI describe este enfoque de la Siguiente manera [KAZ98J:
Una vez determinados los puntos de sensibilidad arquitectnica se encuentran los puntos
en que se requiere compensacin con slo identificar los elementos arquitectnicos a los
CAPTULO 10
DISEO ARQUITECINICO
295
que son sensibles varios atributos. Por ejemplo, el desempeo de una arquitectura cliente-servidor sera muy sensible al nmero de servidores (el desempeo aumentar, dentro
de cierto rango, al aumentar el nmero de servidores) ... Por tanto, el nmero de servidores es un punto de compensacin para esta arquitectura.
Estos seis pasos representan la primera iteracin MACA. Con base en los resultados
de los pasos 5 y 6 ser posible eliminar algunas opciones arquitectnicas, modificar
una o ms de las arquitecturas restantes y representarlas con ms detalle,
aplicar de nueva cuenta los pasos de MACA.8
y luego
de la arquitectura
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 arquitectmco lo examinen Un articulo sobre MAAS se
descarga de http:/ /www.sei.cmu.edu/publications/ articlest saam -metho-propert-sas.htm.
296
PARTE DOS
PRACTICA DE LA INGEN1ERA 1E. sonwARE
10.5.2 Complejidad arquitectnica

Una tcnica til para evaluar la complejidad general de una arquitectura detent' da consiste en considerar las dependencias entre componentes dentro de la ar
tectura. Estas dependencias las orienta la mformacin, el flujo de control, o arn
dentro del sistema. Zhao [ZHA98] sugiere tres tipos de dependencias:
Dependencias compartidas que representan relaciones de dependencia entre conswm~
res que usan el mismo recurso o los productores que producen para los mismos con.-mmidores. Por ejemplo, supnganse dos componentes
u y v que se
refieren a los mismos
datos globales Entonces eXIste una relacin de dependencia compartida entre u y 1,
Dependenoas deflujo que representan las relaciones de dependencia entre productores J

consumidores de recursos Por ejemplo, para dos componentes u y ~ si u debe comrletarse antes de que el control pase a v prerrequsito) o s1 u se comunica con v medla. ltt
parmetros. entonces existe una relacin de dependencia de flujo entre u y v
Dependendas restnng,das que representan restricciones al flujo relativo de control ertre

un conjunto de actividades Por ejemplo, si dos componentes u y v no pueden ejecutarse
al mismo tiempo (exclusin mutua), entonces existe una relacin de dependencia res ingida entre u y v.
Las dependencias compartidas y de flujo que seala Zhao son similares al conc
de acoplamiento descrito en el captulo 9. Acoplamiento es un concepto importante
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 herramientas estandarizadas y de
tacin que permite representar el diseo de una manera poco ambigua y fac
comprender. Aunque el arquitecto del software puede dibujar con notacin u~
necesitan otras formas de diagramacin, y unas cuantas herramientas relaciol'l d.I::
para aplicar un enfoque ms formal a la especificacin de un diseo arquitect
El lenguaje de descripcin arquJtectnica (LOA) proporciona una semntica )
sintaxis para describir una arquitectura del software. Hofmann y sus colegas [HO
sugieren que un LOA debe proporcionar al diseador la capacidad de separar
ponentes arquitectnicos. de integrar componentes individuales en bloques ar
tectnicos mayores y de representar interfaces (mecanismos de conexin) e
componentes. Una vez que se hayan establecido las tcnicas descriptivas, bast
en el lenguaje para diseo arquitectnico, es ms probable que se establezcar
mtodos de evaluacin efectivos para la arquitectura a medida que el diseo e
ciona.
CAPTULO 10
297
DISEO ARQUITECfNICO
Lenguajes de descripcin arquitectnica

El siguiente resumen de varios LOA importantes
lo prepar Rickard Land [LAN02] y se
.,..,.,..,-;..,.. con el permiso del autor. Debe observarse que
~,..,......,.os cinco LOA se han desarrollado con fines de
gacin y no son productos comerciales.
.poset.stanford.edu/rapide/) [LUC95] construye a
p>1ir de lo nocin de conjuntos parciales ordenados.

(www.cs.cmu.edu/-UniCon) [SHA96] define
arquitecturas de software desde el punto de vista de
c.:ITacciones tiles paro los diseadores.
Wright (www.cs.cmu.edu/-able/wright/) [ALL97)

formaliza los estilos arquitectnicos empleando
predicados, lo que permite comprobar la esttico
para determinar la consistencia y el grado en que se
ha completado uno arquitectura .
Acme (www.cs.cmu.edu/-acme/)(GAROO) es un LOA de
segundo generacin.
UML {www.uml.org/) incluye muchos de los artefactos

necesarios paro descripciones arquitectnicas; no es
tan completo como otros LDA.
www.cs.cmu.edu/-able/aesop/) [GAR94] atiende

e. problema de reutilizacin del estilo.
Los estilos analizados en la seccin 10.3.1 representan arquitecturas radicalmente

diferentes; por tanto, no debe sorprender que no exista una completa correlacin (o
mapeo) que logre la transicin del modelo de anlisis a diversos estilos arquitectnicos. En realidad, no hay correlacin prctica para algunos estilos arquitectnicos.
El diseador debe abocarse a la traduccin de requisitos en diseo para estos estilos mediante las tcnicas analizadas en la seccin 10.4.
Ilustrar un enfoque de la correlacin arquitectnica requiere tener en cuenta una
tcnica de correlacin aplicada a la arquitectura de llamada y retomo (una estructura muy comn en muchos tipos de sistemas). Esta tcnica de correlacin permite que
un diseador derive arquitecturas de llamada y retorno razonablemente complejas a
partir de diagramas de flujo de datos dentro del modelo de anlisis. La tcnica, a veces denominada diseo estructurado, se presenta en libros de Myers [MYE78J y Yourdon y Constantin [YOU79].
El diseo estructurado suele caracterizarse como un mtodo de diseo orientado
a flujo de datos, ya que proporciona una conveniente transicin de un diagrama de
flujo de datos (captulo 8) a una arquitectura del software. El tipo de flujo de informacin es el controlador para el enfoque de correlacin o mapeo.
10.6.1
Flujo de transformacin
La informacin debe entrar y salir del software en una forma lgica para "la realidad
externa". Por ejemplo, los datos escritos en un teclado, los tonos de una linea telefnica y las imgenes de video en una aplicacin multimedia son medios de informacin de la realidad externa. Estos datos externos deben convertirse en una forma
interna para el procesamiento. La informacin ingresa en el sistema por rutas que
298
PARTE DOS
PRCl1CA DE LA INGEN!rnA on SOFTWARE
transforman los datos externos en una forma interna. Estas rutas se identifican e
mo flujo de entrada. En el ncleo del software ocurre una transicin. Los datos~
trantes se pasan por un centro de transfonnadn y empiezan a moverse por rutas e
ahora los llevan "fuera" del software. Al desplazamiento de los datos por estas n.
se Je denomina flujo de salida. El flujo general de datos ocurre de manera secuend
y sigue una o unas cuantas rutas "en linea recta". 9 Cuando un segmento de un a.;grama de flujo de datos muestra estas caractersticas est presente el flujo de tran5'
formacin.
10.6.2 Flujo de transaccin
Al flujo de informacin suele caracterizarlo un solo elemento de datos, llamado t:-:::
sacdn, que dispara otro flujo de datos por una de muchas rutas. Cuando un diag"T
ma de flujo de datos (DFD) asume la forma mostrada en la figura 1O.lo est prese-rc
el flujo de transaccin.
Al flujo de transaccin lo caracterizan los datos que se desplazan por un carr
entrante que convierte la informacin proveniente del exterior en una transaca
sta se evala y, con base en su valor, se inicia el flujo por una de muchas ruta.,
accin. Al elemento que concentra y distribuye el flujo de informacin, del que~
nan muchas rutas de accin, se le denomina centro de transaccin.
Debe observarse que, dentro del DFD de un sistema grande, tienen que estar:--,
sentes los flujos de transformacin y transaccin. Por ejemplo, en una transacc
orientada a flujo, el flujo de informacin por un camino de accin puede tener
ractersticas del flujo de transformacin..
M Hli8(1)
1
FluJo de
transacct6n.
Una correlacin obvia para este tipo de flujo de informacin es la arquitectura de flujo de datos
crita en la seccin 10.3.1. Sin embargo, hay muchos casos en que esta arquitectura tal vez nos
mejor eleccin para un sistema complejo. Entre los ejemplos se incluyen sistemas que expe~
tarn cambios sustanciales con el tiempo o sistemas en los cuales el procesamiento asociad~
el flujo de datos no necesariamente resulta secuencial.
CAPTULO 10
299
DISEO ARQUITECTNJOO
10.6.3 Correlacin de transformaciones

La correlacin de transformaciones es un conjunto de pasos de diseo que permite
que un DFD con caractersticas de flujo de transformacin se correlacione con un estilo arquitectnico especfico. Ilustrar este enfoque requiere considerar de nuevo la
funcin de seguridad HogarSeguro. 10 un elemento del modelo de anlisis es un conjunto 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 arquitectura se llevan a cabo los siguientes pasos de diseo:
Paso 1. Revisar el modelo fundamental del sistema. El modelo fundamental

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
datos que fluyen al interior y hacia fuera de la funcin. En la figura 10.11 se describe un modelo de nivel O; en la 10.12 se muestra un flujo de datos refinado para la
funcin de seguridad.
se refina
., este
se debe
esfuerzo por
;bujas que
Paso 2. Revisar y refinar los diagramas de flujo de datos para el software.

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 datos de nivel 3, como se muestra en la
figura 10.14. En el nivel 3 cada transformacin del DFD muestra una cohesin relativamente alta (captulo 9). Es decir, el proceso implicito en una transformacin realiza una funcin nica y distintiva que puede implementarse como un componente
del software HogarSeguro. Por tanto, el DFD de la figura 10.14 contiene suficiente detalle para un "primer corte" en el diseo arquitectnico del subsistema supeNisar
sensores, y se sigue adelante sin mayor refinamiento.
De~liegue
de pqnel~
Panel de
control
cootrol
Uneo
sensores
telefnico
t O 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.
300
DFD de nivel
1 para la
funcin de
segurtdadde
HogarSeguro.
PARTE DOS PRACTICA DE LA INGENIERA DEL SOFTWARE
Panel
de control
Comandos
..__ __. de~uorio
__.- - - - - - y otos.,.. .... -
....
....
.... _
- - .....
~;;
~,
.....
',,
' ' ~,
_ _______
''
.......
__.
''
f
f
I
I
1
/ ln~rm~~in
- - -nf~cil> __ .... //de esp1egue
Sensores - - Estotus
-----
de sensores
de sensores
Tipo de alarmo
lr;:=1:
de=.
'"'-1
~
Tonos de
nmero telefnico
DFD de nivel 2
que retina la
transformacin
morutorear
sensores.
Paso 3. Determinar si el DFD tiene caracterlsticas de flujo de transf

dn o de transaccin. En general, siempre es posible representar el flujo de
macin dentro de un sistema como una transformacin. Sin embargo, cuando se
cuentra una caracterstica obvia de transaccin (figura 10.10), se recomienda
correlacin de diseo diferente. En este paso el diseador selecciona las c a ~
CAPTULO 10
DISEO ARQUITECTNICO
301
DFD de nivel 3 para monitorear sensores con lmites de flujo.
Informacin de configuracin l
71 \
Datos de configuracin
Cdigo de
condicin de
alarmo, ID de sensores,
informacin de calendario
Tonos de nmero
telefnico
ticas de flujo global (de todo el software) con base en la naturaleza prevaleciente del
DFD. Adems, se aslan las regiones locales del flujo de transformacin o transaccin. Estos subjlujos se aprovechan para refinar la arquitectura del programa derivado de una caracterstica global descrita antes. Por ahora, la atencin se centrar slo en el flujo de datos del subsistema monitorear sensores descrito en la figura 10.14.
Al evaluar el DFD (figura 10.14) se aprecia que los datos entran al software por
una ruta de entrada y salen por tres rutas de salida. No participa un centro de transaccin distintivo (aunque la transformacin establece condiciones de alarma que
podran percibirse como tales). Por tanto, se supondr una caracterstica general de
transformacin para el flujo de la informacin.
Paso 4 . Aislar el centro de transformacin al especificar limites de flujo de

entrada y salida. En la seccin anterior, el flujo de entrada se describi como un
camino que convierte la informacin con forma externa en informacin interna; el
flujo de salida hace la conversin inversa. Los lmites de los flujos de entrada y salida estn abiertos a la interpretacin. Es decir, diferentes diseadores seleccionarn
puntos ligeramente diferentes del flujo como posicin de los lmites. En realidad. las
soluciones alternas de diseo se obtienen al modificar la posicin de los lmites de
flujo. Aunque debe tenerse cuidado al seleccionar los lmites, la variacin en una
burbuja a Jo largo del camino de flujo generalmente tendr poco impacto en la estructura final del programa.
302
PARTE DOS
PRCTICA DE LA INGENlFRA DEL SOFIWARE
Los limites de flujo en este ejemplo se ilustran como curvas sombreadas que m
rren verticalmente por el flujo de la figura 10.14. Las transformaciones (burbu;-_
que constituyen el centro de transformacin caen dentro de los dos lmites som~
dos que corren de arriba abajo en la figura. Podra respaldarse el argumento de :;es posible reajustar un limite (por ejemplo, podra proponerse un lmite de tluic
entrada que separe leer sensores y adquirir infonnadn de respuesta). En este paso de _
seo debe resaltarse la seleccin de lmites razonables, no la larga iteracin sobrt
posicin de los limites.
No se debe odoptor
un enfoque dogmtico
en esto etopo. To/ vez
seo necesario establecer dos oms contro/odores paro
procesamiento o
clculo de entrado,
con bose en Jo comp/eiidad del sistema
que habr de construirse. Si el sentido
comn dicto este e~
foque, sese!
41/Mllilb
Factorizacin
de primer
nivel para
supervsar
sensores.
Paso 5. Realizar una "factorizadn de primer nivel". La arquitectura del r-'

grama que se ha derivado a partir de los resultados de la correlacin lleva a una _
tribucin descendente del control. La factorizadn genera una estructura de pros:c
ma en que los componentes descendentes se encargan de la toma de decisior~
los componentes de bajo nivel realizan ms trabajo de entrada, clculo y salida _
componentes de nivel intermedio se encargan de parte del control y realizan ~
dades moderadas de trabajo.
Al encontrar el flujo de transformacin se correlaciona un DFD con una estn..c::;.
ra especfica (una arquitectura de llamada y retomo) que proporciona control pa._;

procesamiento de la informacin de entrada, de transformacin y de salida. En .:.
gura 10.15 se muestra esta factorizacin de primer nivel para el subsistema s ~
sar sensores. Un controlador principal (llamado supervisar director de sensores)
CAPiTtJI.O 10 DISEO ARQUITECTNICO
303
en la parte superior de la estructura del programa y coordina las siguientes funciones subordinadas 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 todas las operaciones de los datos en forma adecuada
para el trabajo interno (por ejemplo, un mdulo que invoca varios procedimientos de transformacin de datos).
un controlador de procesamiento de informacin saliente, llamado controlador 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 complejos en sistemas 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 primer nivel debe limitarse al mnimo posible para realizar las funciones de control y
aun mantener buenas caractersticas de independencia funcional.
Paso 6. Realice una "factorizacin de segundo nivel". La factorizacin de segundo nivel se logra al correlacionar las transformaciones individuales (burbujas) de
una DFD con los mdulos apropiados dentro de la arquitectura. Si se empieza en el
limite del centro de transformacin y se desplaza hacia fuera por rutas de entrada y
Juego por rutas de salida, las transformaciones se correlacionarn en niveles subordinados de la estructura del software. En la figura 10.16 se muestra el enfoque general de la factorizacin de segundo nivel.
Aunque en la figura 10.16 se ilustra una correlacin uno a uno entre transformaciones de DFD y mdulos de software, suelen ocurrir correlaciones diferentes. Es posible combinar dos o hasta tres burbujas y representarlas como un componente, o
expandir una sola burbuja en dos o ms componentes. Consideraciones prcticas y
medidas de la calidad del diseo 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 nuevamente al desplazarse hacia fuera, desde el
limite del centro de transformacin en el lado del flujo de entrada. El centro de transformacin del software del subsistema monitorear sensores se correlaciona de manera un poco diferente. Cada conversin de datos o transformacin de datos de la parte de la transformacin del DFD se correlaciona con un mdulo que est subordinado al controlador de transformacin. En la figura 1O. 17 se muestra una arquitectura
de primera iteracin completa.
Los componentes correlacionados de la manera anterior y mostrados en la figura 10.17 representan un diseo inicial de la arquitectura del software. Aunque el
nombre de los componentes indica una funcin, debe escribirse una breve explica-
304
PARTE DOS PRCTICA DE LA INGENIERA DELSOf"IWARE
Factorizacin
de segundo
nivel para
supemsar
sensores.
Generar
despliegue
1iifH1,j U
Generar pulsos
poro lneo
Estructura de primera iteiactn para supemsa.r sensores.
nmero
telefnico
Generar
despliegue
Generar
pulsos
poro lneo
305
CAPTULO 10 DISEO ARQUITECTNICO
cin de su procesamiento (adaptado de la especificacin creada durante el modelado del anlisis).
Paso 7. Refinar la arquitectura de primera iteracin empleando diseo heurlstico para mejorar la calidad del software. Siempre es posible refinar una arquitectura de primera iteracin si se aplican conceptos de independencia funcional
(captulo 9). Los componentes se expanden o contraen para producir una factorizacin sensible, una buena cohesin, un acoplamiento mnimo y, lo que es ms importante, una estructura que se implemente sin dificultades, se pruebe sin confusin y
se mantenga sin problemas.
Los refinamientos los determinan los mtodos de anlisis y evaluacin descritos
brevemente en la seccin 10.5, adems de las consideraciones prcticas y el sentido
comn. Por ejemplo, hay ocasiones que el controlador del flujo de datos de entrada
resulta totalmente innecesario, que se requiere algn procesamiento de entrada en
un componente subordinado al controlador de transformacin, que no puede evitarse el acoplamiento elevado debido a los datos globales, o que no logran alcanzarse
las caracteristicas ptimas de la estructura. Los requisitos del software, junto con el
juicio humano, deben servir para tomar la decisin final.
El objetivo de los siete pasos precedentes es desarrollar una representacin arquitectnica del software. Es decir, una vez definida la estructura, es posible evaluar y
refinar la arquitectura del software al tener un panorama general de l. Las modificaciones hechas en este momento requieren poca informacin adicional, pero tendrn un fuerte impacto en la calidad del software.
El lector debe hacer una breve pausa y considerar la diferencia entre el enfoque
del diseo descrito y el proceso de "escribir programas". Si el cdigo es la nica representacin del software, el desarrollador tendr gran dificultad para evaluar o refinar a voluntad, en un nivel global u holstico. En realidad, tendr dificultad para
"ver el bosque entre los rboles".
Rqlnamiento de una arquitectura de primera iteracin

Ed: Mira, aqu est la arquitectura que he tooido,
(Ed muestra a Jamie la figura 10.17, (J\le tlikustuda por
unos momentos.)
Jamie: Est muy bien, pero creo que podemos hacer de
gunas cosas para simplificarla y mejorarla.
acaba de tompletar un diseo de primera iteracin
Ed: Cmo cufes2
..bsistamo moniforear sensores. Se detiene poro pesu opinin a Jomie.)
Jamie: Bueno, por qu usos el componente conlrota

dor de entrodo de sensores2
306
PARTE DOS
PRCfiCA DE LA
INGDllmiA DEL SOFTWARE
Ida Po,quia necesitas un senSOI' po~ la c;orrelacin.

.,.... En 'realidod 1')(). El controlador no hace mucho,
~ eistal'no5 ~ un solo camino de Rujo para
_ _.. de enttada. Pcdemos eliminar el con1rolador sin
.iq:IOlllfflOI o ~coiotwales,
ilrltPuedo'WYir ClOft eso. ~ el c:mbio y...

- - C - , . .Nlo): &pe,ol Tambin podemos redu
litio.~- edablea,,- conclidones de alarma y
~~ lelelnico. En realidad el controlador
aiJ it..SO.moci6n que mwstras no es necesario, y lo pe~ tdl:Xi6n de-la c:ohe;si6n resulta toleroble.
Ecl: Simplificacin, ~!
Jamie: As es. Y mienfrm hac:amos ~ _..
bueno idea reducir los componantes
kirmar-.,..,.,
generar despliegue. El fonnalo cW ~ di& ,-1
de control es simple. Podamos definir w nuevo al6dulo

Domado producir detpliegue.
Ed (l,azanclo un..._...): t0e ffll!dD.-esto ID
que crees que podemos hoari
(Muestra a Jamie lo figura 10.18.>
Jamie: Es un inicio.
ii+HiiIO
Estructura refinada del
programa
para
superv1sar
sensores.
10.6.4 Correlacin de trcmsacciones

En muchas aplicaciones de software. un solo elemento de datos dispara varios
jos de informacin que afectan una funcin relacionada con el elemento de
que dispara. El elemento de datos, llamado transacdn, y sus correspondiente.;
ractersticas de flujo se analizaron en la seccin 10.6.2. En esta seccin se cor
rarn los pasos de diseo empleados para correlacionar el flujo de transaccicr
una arquitectura de software.
La correlacin de transacciones se ilustrar si se considera el subsistema
teraccin con el usuario de la funcin de seguridad de HogarSeguro. En la ; .
10.12 se muestra el flujo de datos de nivel I para este subsistema. Al refinar e.
se deriva un diagrama de flujo de datos de nivel 2, como se muestra en la 10.19. El objeto de datos comandos de usuario fluye dentro del sistema y
un flujo de infonnacin adicional por una de tres rutas de accin. Un solo ele
CAPTULO 10
DISEO ARQUITECfNICO
307
de datos, tipo de comando, hace que el flujo de datos se expanda hacia fuera del
concentrador. Por tanto, la caracterstica general del flujo de datos 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, parmetros y datos del
sistema son entradas del camino de accin "configurar"). Todas las rutas de accin
fluyen en una sola transformacin, desplegar mensajes y estatus.
Los pasos del di seo para la correlacin de transacciones son similares y en algunos casos idnticos a los pasos para correlacin de transformaciones (seccin
10.6.3). Una diferencia importante se encuentra en la correlacin del DFD con la estructura del software.
Paso 1. Revisar el modelo fundamental del sistema.

Paso 2. Revisar y refmar los diagramas de flujo de datos para el software.
Paso 3. Determinar si el DFD tiene caractersticas de flujo de transformacin o de transaccin.
Los pasos l, 2 y 3 son idnticos a los correspondientes en la correlacin de transformaciones. El DFD que se muestra en la figura I O. 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 caractersticas de flujo de transformacin. Por tanto, deben determinarse lmites de flujo
para ambos tipos.
Paso 4 . Identificar el centro de transaccin y las caractersticas de flujo en

cada una de las rutas de accin. La ubicacin del centro de transaccin se desprende directamente del DFD. El centro de transaccin se encuentra en el origen de
varias rutas de accin que fluyen de l de manera radial. En el caso del flujo mostrado en la figura 10.19, la burbuja invocar procesamiento de comandos es el centro de
transaccin.
~E
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" (mostrado dentro de un rea sombreada en la figura 10.19) tiene caractersticas de transformacin. El flujo de entrada, de transformacin y de salida se indican con lmites.
Paso 5. Correlacionar el DFD con una e structura de programa sensible al

procesamiento de la transaccin. El flujo de transaccin se correlaciona con una
arquitectura que contiene una rama entrante y una para despacho. La estructura de
la rama entrante se desarrolla de manera muy parecida a la correlacin de transformaciones. Si se empieza en el centro de transaccin, las burbujas ubicadas a lo largo del camino entrante se correlacionan con mdulos. La estructura de la rama para
despacho contiene un mdulo despachador que controla todos los mdulos de ac-
308
PARTE DOS
PRcnCA DE LA INGENIERA DEL SOf'IWAAE
1Uhf[8O DFD de nivel 2 para el subsistem a
de interaccin con el usuario.
Datos de
configuracin
Parmetros y datos sin trabajar
del sistema
lnformacir
de desplieg..e
cin subordinados. cada camino de flujo de accin del DFD se correlaciona COI"'
estructura que corresponde a sus caractersticas de flujo especficas. Este proc
ilustra esquemticamente en la figura 1020.
Si se toma en cuenta el flujo de datos del subsistema de interaccin con el
rio, la factorizacin de primer nivel para el paso 5 se muestra en la figura 10.21
burbujas leer comandos del usuario y activar/ desactivar sistema se correlaciona;
rectamente con la arquitectura sin necesidad de mdulos de control inmediat..
centro de transaccin, invocar comando de procesamiento, se correlaciona dire
mente con el mdulo despachador del mismo nombre. Se crean controladores la configuracin del sistema y el procesamiento de la contrasea, como se ilustra e
figura 10.21 .
Paso 6. Factorizar y refinar la estructura de transaccin y la de cada

no de accin. cada camino de accin del DFD tiene sus propias caracterstic.:.
flujo de informacin. Ya se ha observado que es posible encontrar los flujos de tran:
macin o transaccin. La "subestructura" relacionada con el camino de aca:
desarrolla empleando los pasos de diseo analizados en esta seccin y en la
rior.
Como ejemplo, considrese el flujo de informacin de procesamiento de la
trasea que se muestra en la figura 10.19 (dentro del rea sombreada) . El flujo rr:-
CAPTULO 10
DISEO ARQUITECINJCO
309
Ruto de
recepcin .__,.
tra caractersticas de transformacin clsicas. Se ingresa una contrasea (flujo entrante) y se transmite a un centro de transformacin donde se compara contra las
contraseas almacenadas. Si no se obtiene una coincidencia, se producen una alarma y un mensaje de precaucin (flujo saliente) . El camino "configurar" se dibuja de
manera similar empleando correlacin de transformaciones. En la figura 10.22 se
muestra la arquitectura del software resultante.
Paso 7 . Refinar la arquitectura de primera iteracin empleando diseo heurstico para mejorar la calidad del software. Este paso para la correlacin de
transacciones es idntico al de transformaciones. En ambos enfoques de diseo, cri-
310
PARTE DOS
PRC11CA DE LA INGENIERA DEL SOF1WARE
Arquitectwa
de primera
iteracin para
el subsistema
de Interaccin
con el usuario.
Ptoducir
IMflSOje de !P
no es v61idr
terios como independencia del mdulo, factibilidad (eficacia de la implementac_ ~

la prueba) y facilidad de mantenimiento deben ponderarse cuidadosamente cua.:
se propongan modificaciones estructurales.
"Hfiio lo lllS simple posmle, pero no ms simple de lonecesario.
10.6.5 Refinamiento del diseo cnquitectnico

Cualquier anlisis del refinamiento del diseo debe prologarse con el siguiente
mentarlo: recuerde que un "diseo ptimo" que no funciona tiene un mrito cues..
nable. El diseador de software debe preocuparse por desarrollar una represe:cin del software que cumpla con todos los requisitos funcionales y de desempe:'
as como la aceptacin del mrito basado en las medidas y la heurstica del diseDebe estimularse el refinamiento de la arquitectura del software durante las meras etapas del diseo. Como se analiz al principio de este captulo, es posible-.
rivar, refinar y evaluar estilos arquitectnicos alternos para determinar cul es
"mejor" enfoque. Este mtodo para afrontar la optimizacin es uno de los vercta_
ros beneficios que se obtienen de desarrollar una representacin de la arquitect_
del software.
Es importante indicar que a menudo la simplicidad estructural refleja eleganc:.:
eficiencia. El objetivo del refinamiento del diseo debe ser el uso del menor n!T'Z
de componentes que permitan una integracin efectiva de los mdulos y de la
CAPTULO l O
DISEO ARQUITECTNIOO
311
tructura de datos menos compleja que sirva adecuadamente 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 componentes del

software, sus propiedades y la conexin entre ellos. Entre los componentes del software se incluyen los mdulos del programa y las diversas representaciones de datos
que ste manipula. Por tanto, el diseo de datos es una parte integral de la derivacin de la arquitectura del software. La arquitectura destaca las decisiones iniciales
del diseo y proporciona un mecanismo para considerar los beneficios de estructuras de sistema alternas.
El diseo de datos traduce los objetos de datos (definidos en el modelo de anlisis) a estructuras de datos que residen dentro del software. Los atributos que describen el objeto, la relacin entre los objetos de datos y su utilizacin dentro del programa influyen en la eleccin de las estructuras de datos. En un grado ms elevado
de abstraccin, el diseo de datos lleva a la definicin de una arquitectura para una
base de datos o un almacn de datos.
El ingeniero del software tiene a su disposicin varios estilos y patrones arquitectnicos. 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 conectores que permiten la comunicacin, coordinacin y cooperacin entre componentes, 3) restricciones que definen la manera en que se integran los componentes
para formar el sistema, y 4) modelos semnticos que permiten a un diseador comprender las propiedades generales de un sistema.
En sentido general, el diseo arquitectnico se realiza aplicando varios pasos. En
primer lugar, el sistema debe estar representado en el contexto; es decir, el diseador debe definir las entidades externas que interactan con el software y la naturaleza de la interaccin. Una vez que se ha especificado el contexto, el diseador debe identificar un conjunto de abstracciones de nivel superior, llamadas arquetipos,
que representan elementos 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 componentes y se representan
dentro del contexto de una arquitectura que los soporta. Por ltimo, se crean instancias especficas de la arquitectura para "probar" el diseo en un contexto real.
Como un simple ejemplo de diseo arquitectnico, el mtodo de correlacin o mapeo presentado en este capitulo emplea las caractersticas del flujo de datos para derivar un estilo arquitectnico de uso comn. Un diagrama de flujo de datos se correlaciona con una estructura del programa empleando uno o dos enfoques de correlacin (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.
312
PARTE DOS
PRCTICA DE LA INGENIERA DEI. SOFTWARE
[AH083] Aho. A. V., J. Hopcroft y J. Ullmann, Data Structures and Algorithms, Addison-Wes;:,s
1983.
[All.97] Allen R., "A Formal Approach to software Architecture", tesis de doctorado, camegie Mc::r
University, Nmero de reporte tcniro: CMU-CS-97-144, 1997.
[BAROOJ Barroca. L. y P. Hall (eds.), Software Arr:hitecture: Advances and Applications, Spri~
Verlag, 2000.
[BAS03) Bass, L., P. Clements y R. Kazman, Software Architecture in Practice, 2a. ed.. Add!s
Wesley, 2003.
[BOSOO] Bosch, J.. Design & Use o/Software Arclutectures, Addison-Wesley, 2000.
[BUS96) Buschmann, F., Pattem-Oriented Software Arclutecture, Wiley, 1996.
[DATOOJ Date, c. J. An Introduction to Database systems, 7a. ed., Addison-Wesley, 2000.
[DIKOO] Dikel, D. D. Kane y J. Wilson, Software Architecture: Organizational Principies and
tems, Prentice-Hall, 2000.
[FRESO] Freeman, P., "The Context of Design", en Software Design Techniques, 3a. ed. (P. Free,:.;::
y A. Wasserman, eds.), IEEE Computer SOciety Press, 1980, pp. 2-4.
[GAR94] Garlan D. R. Allen y J. Ockerbloom, "Exploiting Style in Architectural Design En, _
ments", en Proceedings ofSIGSOFT '94 Symposium on the Foundations o/Software~
ring, 1994.
[GAROOJ Garlan D., R. T. Momoe y D. Wile, H Acme: Architectural Description of componen
sed Systems", en Foundations of Component-Based Systems, G. T. Leavens y M. Sita
(eds.), Cambridge University Press, 2000.
[HOFOO] Hofmeister, C., R. Nord y D. Soni, Applied Software Architecture, Addison-Wesley
[HOFOIJ Hofmann: C. et al., "Approaches to Software Architecture", se descarga de: http
seer.nj.nec.com/84015.html.
[KAZ98J Kazman, R. et al., The Architectural D:adeoffAna lysis Method, Software Engin
Institute, CMU/SEl-98-TR-008, julio de 1998.
[KIM98) Kimball, R., L. Reeves, M. Ross y w. Thomthwaite, The Data Warehouse Lif~ ~
kit: Experl Methods for Designing, Developing, and Dep/oymg Data Warehouses, Wile}
[LAN02) Land R. A Brief Survey of software Architecture, reporte tcnico, Departamento de
niera de Cmputo, Universidad Malardalen, Suecia, febrero de 2002.
[LUC95J Luck.ham D. C. et al., "Specification and Analysis of System Architecture Using le
en IEEE Transactions on Software Engineering, ejemplar "Special lssue on Software Are
ture", 1995.
[MAT96) Mattison, R.. Data Warehousing: Strategies, Techno/ogies, and Techniques, McGrcr.
1996.
IMYE78] Myers, G., Composite Structured Design, Van Nostrand, 1978.
[PRE981 Preiss, B. R., Data Structures and Algorithms: With Object-Oriented Design Patter:::;;
C++, Wiley, 1998.
[SHA96J Shaw. M. y D. Garlan, SoftwareA.rchitecture, Prentice-Hall, 1996.
[SHA97) Shaw, M. y P. Clements, HA Field Guide to Boxology: Preliminary Classificatior
chitectural Styles for software Systems", en Proc. COMPSAC, Washington, DC, agosto de
[WAS80) Wasserrnan, A., "Principies of Systematic Data Design and Implementation, e-;
ware Design Techniques (P. Freeman y A. Wasserrnan, eds.). 3a. ed., IEEE computer
Press, 1980, pp. 287-293.
[YOU791 Yourdon, E. y L Constantine, Structured Design, Prentice-Hall, 1979.
[ZHA98J Zhao, J., "On Assessing the Complexity of Software Architectures", en Proc. Jntl. S...
Architecture Workshop, ACM, Orlando, FL, 1998, pp. 163-167.
10.1. Empleando la arquitectura de una casa o un edificio como metfora, realizar c

dones con la arquitectura del software. En qu son similares las-disciplinas de la arqu.
clsica y la del software? En qu se diferencian?
CAPTULO lo
DISEO ARQUITECl'NJCX)
313
10.2. Escribir un artculo de tres a cinco pginas que presente directrices para seleccionar estructuras 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 seleccionar, 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 negocios convencionales y un almacn de datos.
10.4. Presentar dos o tres ejemplos de aplicaciones para cada uno de los estilos arquitectnicos indicados en la seccin 10.3.1.
10.5. Algunos de los estilos arquitectnico indicados en la seccin J 0.3. 1 son de naturaleza jerrquica, otros no. Elaborar una lista de cada tipo. Cmo se implementaran los estilos arquitectnicos que no son jerrquicos?
10.6. Los trminos estilo arquitectnico, patrn arquitectnico y marco conceptual suelen encontrarse en el anlisis sobre la arquitectura del software. Investigar un poco (utilizar la Web) y describir 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. l.
10.9. Algunos diseadores sostienen que todos los flujos de datos deben considerarse orientados 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 transformacin. Utilizar un flujo de ejemplo para ilustrar puntos importantes.
10.1 O. Si no se ha hecho, completar el problema 8.1 O. Emplear los mtodos de diseo descritos en este captulo para desarrollar una arquitectura del software para el PHTRS.
10.11. Empleando un diagrama de flujo de datos y una descripcin del procesamiento, describir un sistema de cmputo que tenga distintas caractersticas de flujo de transformacin. Definir los lmites del flujo y correlacionar el diagrama de flujo de datos con la arquitectura del
software empleando la tcnica descrita en la seccin l 0.6.3.
10.12. Empleando un diagrama de flujo de datos y una descripcin del procesamiento, describir un sistema de cmputo 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 (Pattems of EnterpriseApplication Architecture, Addison-Wesley, 2003), Clements y sus
colegas (Documentig Software Architecture: View and Beyond, Addison-Wesley, 2002). Schmidt y
sus colegas (Pattern-Oriented SOftware Architectures. dos volmenes, Wiley, 2000), Bosch
[BOSOOJ, Dikel y sus colegas [OJKOO]. Hofmeister y sus colegas [HOFOO] Bass. Clements y
Kazman [BAS03], Shaw y Garlan [SHA96J y Buschmann et al. (BUS96] proporcionan un anlisis
a fondo del tema. Un trabajo previo de Garlan (An Introduction to Software Architecture, Software
Engineering Institute, CMU/SEI-94-TR-02 l, 1994) Tiene una excelente introduccin. Clements y
Northrop (SOftware Product Lines: Practices and Pattems, Addison-Wesley, 2001) trata el diseo
de arquitecturas que dan soporte a lineas de productos de sofware. Clements y sus colegas
(Evaluating Software Architectures, Addison-Wesley 2002) considera los temas asociados con la
evaluacin de alternativas de arquitectura y la seleccin de la mejor arquitectura para un problema de dominio dado.
314
PARTE DOS
PRcnCA DE 1A INGENIERA DEL SOr!WARE
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~
ftom Commerdal COmponents, Addison-Wesley, 2001) presentan mtodos para construir arq-_
tecturas basadas en componentes. Pritchard (COM and CORBA Side-by-Side, Addison-Wes...
1999), Mowbray (CORBA Design Pattems, Wiley, 1997) y Mari< et al. (Objetet Manager,-.
Architecture Guide, Wiley, 1996) provee lineaminttos de diseo detallados para la estructura :;::
soporte CORBA, Shanley (Protedcd Mode Software Architecture, Addison-Wesley 1996) proporc
na asesorta sobre diseo arquitectnico para cualquier sistema operativo basado en tiempo
para PC, sistemas operativos multiproposito o drivers.
La investigacin actual sobre arquitectura de software se documenta anualmente eo
Proceedings of the Intemational Workshop en Software Architecture, patrocinados por la AG
otras organizaciones de computacin, y los Proceedings of the lntemational Conference
Software Engineering. Barroca y Hall [BAROOJ presentan un til estudio de investigacin recie:- _
El modelado de datos es un requisito para un buen diseo en esta materia. Los libros
Teory (Database Modeling and Design, Academic Press, 1998); Schmidt (Data Modeling
Information Professionals, Prentice-Hall, 1998); Bobak (Data Modeling and Design Jor Toe
Architectures, Artech House, 1997); Silverstone, Graziano e lnmon (The Data Model RescBook, Wiley, 1997); Date [DATOOJ, y Reingruber y Gregory (The Data Modeling Handbook: A B.
Praclice Approach to Building Quality Data Models, Wlley, 1994) contiene presentaciones deta..3-das sobre notacin de modelado de datos, heurstic y aspectos del diseo de bases de datO"
diseo de almacenes de datos se ha vuelto ms importante en los ltimos aos. Los libre'
Humphreys, Hawkins y Dy (Data Warehousing: Architecture and Implementation, Prentice-11999); Kimball et al. [KJM98) e lrunon [INM9S] tratan el tpico con mucho detalle.
El estudio general del diseo de software con discucin de aspectos de arquitectura y
o de datos puede encontrarse en la mayoria de los libros dedicados a la ingeniera de sof"
re. Tratamientos ms rigurosos del tema se hallan en Feijs (A Formaliza/ion of Design MeUPrentice-Hall, 1993) Witt et al. (Software Architecture and Design Prindples, Thomson Publisr
1994) y Budgen (Software Design, Addisson-Wesley, 1994).
Presentaciones completas de diseo orientado al flujo de datos pueden encontrarse en M
[MYE78]. Yourdon y Constantine [YOU79], y Page-Jones (The Practical Guide to Structured Sy.,a:r:::
Design, 2a. ed. Prentice Hall, 1998). Estos libros estn dedicados slo al diseo se inc
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 rele,
tes para el diseo arquitectnico puede encontrarse en el sitio Web de SEPA:
=-
http:/ /www.mhhe.cotn/pressman.
DISEO AL NIVEL
DE COMPONENTES
l diseo al nivel de componentes se presenta despus. de que se ha completado la primera iteracin del diseo arquitectnico. En esta etapa ya se
han establecido los datos generales y la estructura del programa. El objetivo es traducir el modelo de diseo en un software operacional. Pero el grado de
abstraccin del modelo de diseo existente es relativamente elevado, y el del programa operacional, bajo. La traduccin llega a ser desafiante, abriendo la puerta
para el ingreso de errores sutiles que resultan diflciles de encontrar y corregir en
etapas posteriores del proceso de software. En una famosa conferencia, Edsgar
Dijkstra, una <le las personas que ms ha contribuido a nuestra <:omprensin del
diseo de software, afirm [DIJ72]:
E
..317
....321
...32S
.. ...340
....322
Al parecer, la diferencia en~re el software y muchos otros productos es que en stos,

-<;Orno regla general, mayor calidad representa preco ms elevado. Quienes desean
software realmente confiable descubrirn que deben encontrar un medio para evitar
la mayor parte de los errores desde el principio y; como resultado, el proceso de pro~
gramactn se votver mucho ms econmico ... los buenos programq,dOte$... no de..
ben desper<licar su tiempo depurando: deben evitar los errores desde el principio.
Aunque estas palabras fueron pronuncladas hace muchos aos, an son v"
licias, cuando el modelo de diseo se traduce en cdigo fuente debe)'\ seguirse
una serie de principios de diseo que no slo realicen la traduccin, sino que
.....324
-dlrl .
340
laii...., ..322
''eViten la introduccin de errores desde el principio".

Es posible representar el diseo al nivel de componentes empleando un lenguaje de programacin. En esencia, el programa se crea con el modelo de dise"
o arquitectnico como gua. Un enfoque alterno consiste en representar el
di-
seo al ruvel de componentes empleando alguna representacin intermedia '(por
ejemplo, grfica, tabular o t,asada en texto) que se traduzca fcilmente en cdigo fuente. Independientemente del mecanismo con que se represente el diseo
al nivel de componentes, las estructuras de datos, las interfaces y los algoritmos
definidos deben adecuarse a diversas lneas generales de diseo bien definidas,
que ayuden a evitar errores a medida que evoluciona el diseo procedimental.
En este captulo se examinaran esas lneas generales y los mtodos disponibles
para seguirlas.
internos y el procesamiento de detalles de <:edo

componente no se representan en vn 9rQdQ de
obstracc1on parecido ol c6di90. El diseo al nJ
vel de componentes define los e$ln.K;tvros de cki
315
316
PARTE DOS
PRCllCA DE LA INGENIFllA DEL SOFTWARE
De manera general, un componente es un bloque de construccin modular para

software de cmputo. De manera ms formal, la especificacin unificada de leng:
je de modelado de OMG [OMGOl] define un componente como "una parte mod
desplegable y reemplazable de un sistema que encapsula implementacin y exp:..
un conjunto de interfaces".
Como se analiz en el capitulo 10, los componentes pueblan la arquitectura
software y, por tanto, ayudan a cumplir con los objetivos y requisitos del sistema
construccin. Debido a que los componentes residen en el interior de la arquitec
ra del software, deben comunicarse y colaborar con otros componentes y con er
dades (como otros sistemas, dispositivos, personas) que existen fuera de los lim.
del software.
I *las Males no mn slo detales.lntegroo el diseo.

El verdadero significado del trmino "componente" variar dependiendo del p
to de vista del ingeniero de software que lo usa. En la siguiente seccin se revisa:
tres conceptos importantes de lo que es un componente y la manera en que se
a medida que se realiza el modelado del diseo.
CAPTULO 11
DISEO AL NIVEL DE COMPONENTES
317
11.1.1 Concepto orientado a objetos

En el contexto de la ingeniera del software orientada a objetos, un componente contiene un conjunto de clases que colaboran entre s. 1 Cada clase de un componente
se ha elaborado completamente para incluir todos los atributos y las operaciones relevantes para su implementacin. como parte de la elaboracin del diseo, tambin
deben definirse todas las interfaces (mensajes) que permiten que las clases se comuniquen y colaboren con otras clases de diseo. Para lograrlo, el diseador empieza
con el modelo de anlisis y elabora clases de anlisis (en el caso de componentes que
se relacionan con el dominio del problema) y clases de infraestructura (en el caso de
componentes que proporcionan servicios de soporte para el dominio del problema).
Este proceso de elaboracin del diseo se ilustra imaginando que el software se
construir para una imprenta sofisticada. El objetivo general del software es recopilar las necesidades del cliente en el mostrador, cotizar un trabajo de impresin y pasarlo a una planta de produccin automatizada. Durante la ingeniera de los requisitos se deriva una clase de anlisis denominada Trabajolmprenta. Los atributos y
las operaciones definidos durante el anlisis se observan en la parte superior izquierda de la figura 11.1. Durante el diseo arquitectnico se define Trabajolm prenta como un componente de la arquitectura de software y se representa empleando la notacin abreviada de UML que se muestra en la parte central derecha de
la figura. Observe que Trabajolmprenta tiene dos interfaces, calcularlrabajo, que
proporciona la capacidad de cotizar el trabajo, e iniciarlrabajo, que pasa el trabajo a
la planta de produccin. stas se representan empleando los smbolos que se muestran a la izquierda del recuadro del componente.
El diseo al nivel de componentes empieza en este punto. Deben elaborarse los
detalles del componente Trabajolmprenta para que proporcionen la informacin
suficiente que gue la implementacin. La clase de anlisis original se elabora para
dar forma a todos los atributos y las operaciones requeridos para implementar la clase como el componente Trabajolmprenta. Tomando como referencia la parte inferior derecha de la figura 11. l, la clase de diseo Trabajolmprenta elaborada contiene informacin de atributos ms detallada, adems de una descripcin expandida
de las operaciones requeridas para implementar el componente. Las interfaces calcularlrabajo e iniciarlrabajo llevan implcitas la comunicacin y colaboracin con
otros componentes (que no se muestran aqu) . Por ejemplo, la operacin calcularCostoPagina{) (parte de la interfaz calcula!Trabajo) colaborara con un componente
TablaPrecios que contiene la informacin de precios de los trabajos. La operacin

verijicarPrioridad() (parte de la interfaz iniciar!rabajo) colaborara con el componente ColaTrabajos para determinar los tipos y las prioridades de los trabajos en espera (o en cola) que se encuentran en produccin.
Esta actividad de elaboracin se aplica a cada componente definido como parte
del diseo arquitectnico. una vez completado, se elabora an ms cada atributo,
1 En algunos casos un componente podra contener una sola clase.
318
PARTE DOS
PRCTICA DE LA INGEN!ElA DE:. SOFTWARE
operacin e interfaz. Deben especificarse las estructuras de datos apropiadas p.:

cada atributo. Adems, tambin se disea el detalle algortmico que se requiere ::ra implementar la lgica de procesamiento asociada con cada operacin. Esta ~
vidad de diseo procedimental se analizar ms adelante, en este mismo cap,;....
Por ltimo, se disean los mecanismos necesarios para implementar la interfaz. E.caso del software orientado a objetos, esto abarca la descripcin de todos los mer..5cjes que se requieren para realizar la comunicacin entre objetos dentro del sistem..
iifhlH
Elabol'ac16n
deun
Trobojolmprerno
componente
de diseo.
colcularCO>lodeTrobool()
lmpnm,ry po,onrobooj 1
<<interfaz>>
coiculotlroboo
,
,
,
<<in.teNaz>>
in.c,or Trabajo
consm,irO,denTrobojo{)
-if1CarPrionclod( }
posorTrobojoAProduccin( 1
numeroOePoginos
..,.....,o0ei.ooo.
tipol'opel
pesol'opel
lomonoPopel
colori'opel
ompliocon
requisoo,Color
coroderiiticosProducdon
opcione.O..trtbucion
opco.,..,Encuodernodo
po,toda.Almocen
refine
pnondod
cos1oTololTrobojo
numetaOT
colcula.Co.ioPogino( 1
olculotCo,IOPopel()
colculorCa.lOProd(}
colculotCO>loTrobojoTotal( }
con,1niit0rclenTrabajo( 1
f8Y!sotf'rior,docl( 1
posorTrobojoAl'rodvcc,on()
11.1.2 El concepto convencional

En el contexto de la ingeniera del software convencional, un componente es ur
mento funcional de un programa que incorpora la lgica del procesamiento, las
tructuras internas de los datos necesarios para implementar dicha lgica, y u.-.:
terfaz que permita la invocacin del componente y el paso de los datos. Un ca.
nente convencional, tambin denominado mdulo, reside dentro de la arquitec
CAPTULO 11
DISEO AL NIVEL DE COMPONEN'lt.'S
319
del software y representa uno de tres papeles importantes: 1) como componente de
control que coordina la invocacin de todos los dems componentes del dominio del
problema, 2) como componente del dominio del problema que implementa una funcin completa o parcial requerida por el cliente, o 3) como componente de infraestructura responsable de funciones que soportan el procesamiento requerido en el dominio del problema.
Como los componentes orientados a objetos, los componentes del software convencional se derivan del modelo de anlisis. Sin embargo, en este caso el elemento
de datos orientado al flujo del modelo de anlisis sirve como base para la derivacin.
Cada transformacin (burbuja) representada en los niveles inferiores del diagrama
de flujo de datos (captulo 8) se correlaciona directamente (seccin 10.6) con una jerarqua de mdulos. Los componentes de control (mdulos) residen cerca de la parte superior de la jerarqua (arquitectura) y los componentes del dominio del problema
tienden a residir haca la parte inferior de la jerarqua. Para lograr una modularidad
efectiva, se aplican conceptos de diseo como la independencia funcional (captulo
9) a medida que se elaboran los componentes.
se descubre que un sistemo complejo que funciono ho evolucionado opartir de-111t sl$18IIIO $lmplt
..... llndollaba.
Este proceso de elaboracin del diseo de componentes convencionales se ilustra considerando de nuevo el software que se habr de construir para un sofisticado
centro de fotocopiado. Un conjunto de diagramas de flujo de datos se derivara durante el modelado del anlisis. Se supondr que stos se correlacionan (seccin
10.6) dentro de la arquitectura que se muestra en la figura l l .2. Cada recuadro representa un componente de software. Tmese en cuenta que los recuadros con pantalla gris tienen una funcin equivalente a las operaciones definidas en la clase 'lrabajolmprenta analizada en la seccin 11 .1.1. Sin embargo, en este caso cada operacin se representa como un mdulo separado que se invoca como se muestra en
la figura. Con otros mdulos se controla el procesamiento y, por tanto, son componentes de control.
Durante el diseo al nivel de componentes, se elabora cada mdulo mostrado en
la figura 11.2. La interfaz del mdulo se define de manera explcita. Es decir, se representa cada objeto de datos o de control que fluye por la interfaz. El algoritmo que
permite que el mdulo realice su funcin est diseado con el enfoque de refinamiento paso a paso analizado en el captulo 9. El comportamiento del mdulo suele representarse con un diagrama de estado.
Para ilustrar este proceso considrese el mdulo CalcularCostoPagina. Su objetivo
es calcular el costo de impresin por pgina a partir de las especificaciones del cliente. Los datos necesarios para realizar esta funcin son: nmero de pgines en el documento, nmero total de documentos que se producirn, impNtsin por una o ambas caras, color
320
PARTE DOS
PRcnCA DE LA INGENIE!l1A OO. SOflWARE
o blanco y negro y tamao. Estos datos se pasan a caJcularCostoPagina mediante la terfaz del mdulo. ste usa los datos y determina un costo por pgina que se bax
en el tamao y la complej idad del trabajo (una funcin de todos los datos pasados ._
mdulo con la interfaz). El costo por pgina es inversamente proporcional al ta::o del trabajo y directamente proporcional a su complejidad.
ifrP.ii
Sistema de
administracin
de trabajo
Grfica de
esbuctura
deun sistema convencional.
'
,
, ,
''
'
Seleccionar
lo funcin
de manejo
de trabajo
leer datos
de trabajo
ae impresin
,,
, ,
Construir
costo
de trabajo
orden
de trabajo
Enviar
trabajo
o produccin
'
Calcular costo
de pgina
Calcular coslo
de papel
Calcular costo
deprod.
Revisar
prioridad
Posar trobap
a
produc:aaa
En la figura 11 .3 se representa el diseo al nivel de componentes empleanc.

notacin UML modificada. El mdulo CalcularCostoPagina tiene acceso a los ~
invocar al mdulo obtenerDatosTrabajo, que permite el paso de todos los datos
vantes al componente, y una interfaz de base de datos, accesarBDCostos, que ...
te que el mdulo tenga acceso a una base de datos con todos los costos de
sin. A medida que prosigue el diseo se elabora el mdulo Ca/cularCostoPagr:.
ra proporcionar el detalle del algoritmo y la interfase (figura 11.3). El detalle df[
goritmo se representa empleando el texto de seudocdigo que se muestra en .a
ra con un diagrama de actividad de UML. Las interfaces se representan como tr-..:
leccin de objetos o elementos de datos de entrada y salida. La elaboracin .i5.
seo contina hasta que se proporcione detalle suficiente para gui ar la constr
del componente.
CAPTULO 11
obtenerDotosTrobojo
321
Componen/e de diseo
ColculorCostoPogino
occesorBDCostos
Mdvlo eloorado
CostoPagina
entro: numeroP09inos
entro: numeroDocumenlo$
entro; lodos 1, 2
entro: color t, 2, 3, 4
entrQ: tomooPagina A, B, C, D
sale; costo de p69ino
entra: 1amooTrabajo
(mtrQ: color 1, 2, 3, 4
entra: tamooPogina - A, B, C, D
sale: CBP
sole: SF
obtenerDatosTtobajo (nvmeroPaginas,
numeroDocumentos, lado$, color,
tomaQl'ogino, cosk>Pogino)
accesorBDCostos{tamaoTrobojo, color,
tomooPogino, CBP, Sf)
calculotCostoPagino( ) - - - - - - - - - - - - -
rrn ..
tamao de trabctfo
numer0Pa9ittas nvmeroDocumentos;
buscar costo bQsi; <ie pgina (CBPJ >
aceesarBDCostos {TT, color);
buscar factor de tamao (Fn >
accesarBDCoslos (TT, color, tamao
factor de romplejidad de trabajo (Fcn ..
1 + l(lado&-Wco$t0Lodo +- FTJ
costoPogind CBP " FCT
11 .1.3 Un concepto relacionado con el proceso

En los conceptos orientado a objetos y convencional del diseo al nivel de componentes presentados en las secciones anteriores, se supone que los componentes se
han diseado desde cero. Es decir, que el diseador debe crear un nuevo componente basado en especificaciones derivadas del modelo de anlisis. Hay, por supuesto,
otro enfoque.
En la dcada pasada, la comunidad de la ingeniera del software ha destacado la
necesidad de construir sistemas que usen los componentes de software existentes.
En esencia, un catlogo de componentes probados al nivel de diseo o de cdigo
queda a disposicin del ingeniero de software a medida que avanza en el trabajo de
diseo. Mientras se desarrolla la arquitectura del software, se eligen del catlogo los
componentes o patrones de diseo y se usan para poblar la arquitectura. Debido a que
estos componentes se han creado con la reutilizacin en mente, se encuentra a disposicin del diseador una descripcin completa de su interfaz, la funcin o las funciones que realiza y la comunicacin y colaboracin que requiere. La ingeniera del
software basada en componentes se analizar de manera muy detallada en el captulo 30.
322
PARTE DOS
PRCl'ICA DE LA INGENIERA DEL SOFTWARE
M1ddleware e lngemea de software basada en componentes

Uno de los elementos clave que llevo al xilo o
el froco$0 de lo ingeniera del software basado
en componentes es lo disponibilidad de middlewore. sta
es uno coleccin de componentes de infroeslrucluro que
permiten que los componentes del dominio del problema
OMG CORBA (http://www.corbo.org/).

Microsoft COM
(http://www.microsoft.com/com/tech/complus.osp
se comuniquen con otros en uno red o dentro de un sisfemo complejo. Quienes desean usar ingeniera del software
basado en componentes o medido que avanza el proceso
de software cuentan con tres estndares competidores:
los anteriores sitios Web presentan uno amplia variedoc

de tutorioles, manuales, herramientas y recursos genenr.=
sobre estos importantes estndares de middlewore. En e
captulo 30 se encontrar ms informacin acerco de lo
ingeniera del software basado en componentes.
Sun JovoBeons (http://jovo.sun.com/products/ejb/).
Como ya se ha observado, el diseo al nivel de componentes se basa en info

desarrollada como parte del modelo de anlisis (captulo 8) y representada
parte del modelo arquitectnico (captulo 10). Cuando se elige un mtodo de
niera de software basado en componentes, el diseo al nivel de stos se coix
en la elaboracin de las clases de anlisis (clases especificas del dominio del p.
ma), y la definicin y la afinacin de las clases de infraestructura. La descripcim
tallada de los atrtbutos, las operaciones y las interfaces empleados por estas
representa el detalle de diseo requerido como precursor de la actividad de .:,truccin.
11 .2.1
Principios bsicos de diseo
Hay cuatro prtncipios bsicos de diseo aplicables al diseo al nivel de compc

tes y se han adoptado ampliamente cuando se aplica ingeniera de software or.e:::
da a objetos. La motivacin elemental para la aplicacin de estos principios es
diseos que sean ms sensibles al cambio y reducir la propagacin de efectos se
danos cuando ocurren cambios. Estos principios pueden usarse para guiar a:
ador a medida que desarrolla un componente de software.
El principio abierto-cerrado (PAC). 'TEl componente de] un mdulo debe

abierto para extensin, pero cerrado para modijicadn" [MAROO]. Esta frase paree-.
contradiccin, pero representa una de las caractersticas ms importantes ~

buen diseo al nivel de componentes. Para expresarlo de manera simple, el di!
dor debe especificar el componente de manera que permita extenderlo (dent:"
dominio funcional que atiende) sin necesidad de modificaciones internas al ,;
componente (al nivel de cdigo o lgica). Para eJlo, el diseador crea abstracc
que sirven como memoria intermedia entre la funcionalidad que tal vez habra e.tenderse y la propia clase de diseo.
CAPTULO 11
323
ihterUZ>>
Sensor
leer{)
habilitar( 1
inhobilitQr( }
- -- -- - ~
O-ro<
probar()
'
~-----------r------------r----------r----------
1
1
1
$el1sorPuertos/
Ventanas
SensorHumo
DetectorMovimento
S,,,,o,<:clo,
1 S,,,,o,C02
Por ejemplo, suponga que la funcin de seguridad HogarSeguro usa la clase Detector que debe revisar el estatus de cada tipo de sensor de seguridad. Es probable
que con el tiempo aumenten el nmero y los tipos de sensores de seguridad. Si la lgica de procesamiento interno est implementada como una secuencia de construcciones si-entonces-si_no (if-then-else), donde cada una atiende un tipo de sensor diferente, la adicin de un nuevo tipo de sensor requerir lgica de procesamiento interno adicional (un si-entonces-si_no adicional). Esto es una violacin del PAC.
Una manera de cumplir con el PAC en el caso de la clase Detector se ilustra en
la figura 11.4. La interfaz sensor presenta una vista consistente de sensores para el
componente Detector. Si se agrega un nuevo tipo de sensor no se requieren cambios en la clase Detector (componente). Se preserva el PAC.
M I ~ Cubiculo de Vinod.
Vinod: Es poro lo gente que deo M rnascokn Mde,.

parlamentos o condominios o oasos muy c:en:iancl$. S.,..
rro empieza a ladrar. El vecino $$ enojo y se quejo. Col\
este sensor, si el perro ladro durante MQ$ de un mint.ltrt,
por decir algo, el sensor detono unc1 alarmo~.llama al telfono celular del dueo.
Shakira: No bromees.
SL. y no vas a creer oon lo que han scdido oho$oerindeme.

f. . .); l.o llamaroti $l'li!Or dtector de ladridos.
Qu signiilt
Vinod: Es en serio. Doug quiere SClbercuntc f.empo

nos tomar agregarlo o la funcin de seguridad.
Shakira (pensando por un momento); No mu

cho... mira [le muestra a Vinod la figuro 11.4J. Hemos
aislado las doses de sensores reales tras la interfaz set, '
sor. Siempre y cuando tengamos especificaciones del
sensor de perros, se agrego en un tris. Lo nico que tn-
324
PARTE DOS
PRCT!CA DE LA lNGEN!ERA DEL SOFIWARE
o.es- un compo, opopiodo .. . o
M. No hay~ necesidad de
Deledo,:.
Vinocl: No elt mol.pe,o

ro mismo I 61 lo .-,uf
5haldwa: sr, la....,..,.

pmite hacerlo sin inucho
a boug, nos tendr ocupados y

_, mnll'O pam,s hasta 1a prximo
Principio de sustitucin de Uskov (PSL) . "Debe tenerse la opcin de sustitt:=

subclases con sus dases prindpales." [MAROOJ Este principio del diseo, que orig=.t
mente propuso Barbara Liskov [US88], sugiere que un componente que use una
se principal debe seguir funcionando apropiadamente si, en cambio, se pasa al
ponente una clase derivada. El PSL exige que cualquier clase derivada de una e
principal se apegue a cualquier contrato implcito entre la clase principal y los
ponentes que la usan. En el contexto de esta explicacin, un "contrato'' es una
didn previa que debe ser verdad despus de que el componente usa una clase :
cipal y una condidn posterior que debe ser cierta despus de que el componente
una clase principal. Cuando un diseador crea clases derivadas, tambin deben
tarse a las condiciones previas y posteriores.
Principio de inversin de la dependencia (PID). "Dependa de las abstraca~

no de las concreciones." [MAROOJ como hemos visto en el anlisis del PAC, las _
tracciones son el lugar donde un diseo se puede extender sin grandes complica..x:,
nes. Cuanto ms dependa un componente de otros componentes concretos (e;,
gar de abstractos, como la interfaz), ms dificil ser extenderlos.
Si se prescinde del diseo yse posa direc

fomente o/ cdigo,
slo recurdese que
ste es fo concred6n'' fino/. As que se
estar violando el PID.
Principio de segregacin de la inteaz (PSI). "Es mejor tener muchas inte:especjicas del cliente que una interfaz de propsito general." [MAROO] Hay mucho-
sos en que varios componentes de cliente usan las operaciones proporcionadas por
clase de servidor. El PSI sugiere que el diseador debe crear una interfaz espec..:.
zada para servir a cada categora importante del cliente. Slo las operaciones imtantes para una categora especial de clientes deben especificarse en la interfaz
ra esos clientes. Si varios clientes necesitan las mismas operaciones, deben esp:
ficarse en cada una de las interfaces especializadas.
Por ejemplo, piense en la clase PlanoCasa que se usa en Hogarseguro para
dones de seguridad y vigilancia. En el caso de las funciones de seguridad, Pla.noe.
sa slo se emplea durante las actividades de configuracin y utiliza las operadw
colocarDispositivO( ), mostrarDispositivo( ), agruparDispositivo() y eliminarDisposiC'
para colocar, mostrar, agrupar y eliminar sensores del plano. La funcin de vigilr
de HogarSeguro usa las cuatro operaciones indicadas para seguridad, pero sl,,,
quiere operaciones espaciales para manejar las cmaras: mostrarPV() y mostrarm
CAPTULO 11
DISEO AL NIVEL DE C OMPONENTES
325
positivo(). Por tanto, el PSI sugiere que los componentes de cliente de las dos funcio-
nes de HogarSeguro tengan interfaces especializadas y definidas para ellas. La interfaz

de seguridad slo abarcara las operaciones colocarDispositivo( ), mostrarDispositivo( ),
agruparDispositivo() y eliminarDispositivo( ). La interfaz de vigilancia incorporara las
cuatro operaciones anteriores, adems de mostrarPV( ) y mostrarIDDispositivo( J.
Aunque los principios de diseo al nivel de componentes proporcionan una gua
til, los propios componentes no existen en el vaco. En muchos casos, los componentes o las clases individuales se organizan en subsistemas o paquetes. Es razonable preguntar, cmo debe presentarse esta actividad de empaquetamiento? Exactamente, cmo deben organizarse los componentes a medida que avanza el diseo?
Martn (MAROOJ sugiere principios adicionales de empaquetamiento que son aplicables al diseo al nivel de componentes.
Principio de equivalencia entre reutilizacin y versin (PER). "La esencia de la

reutilizacin es la misma que de la versin." [MAROOJ Cuando las clases o componen-
tes se disean para reutilizarlos, hay un contrato explcito entre el desarrollador de

la entidad reutilizable y la persona que la usar. El desarrollador se compromete a
establecer un sistema de control de versiones que d soporte y mantenga las versiones anteriores de la entidad mientras los usuarios actualizan lentamente la versin
ms actual. En lugar de atender cada clase individualmente, lo aconsejable sera agrupar las clases reutilizables en paquetes que pueden manejarse y controlarse a medida que evolucionan nuevas versiones.
Principio del cierre comn (PCC). "Las clases que cambian juntas deben permanecer juntas." [MAROOJ Las clases deben empaquetarse de manera que sean un todo coherente. Es decir, cuando las clases se empaquetan corno parte de un diseo, deben
atender la misma rea de funciones o comportamientos. Cuando alguna caracterstica de esa rea debe cambiar, es probable que slo deban modificarse las clases del
paquete. Esto lleva a un control de cambios y a un manejo de las versiones ms efectivos.
Principio comn de la reutilizacin (PCR). "Las clases que no se reutilizan juntas
no deben agruparse juntas." (MAROOJ Cuando una o ms clases cambian en un paquete, tambin cambia el nmero de versin del paquete. Todas las dems clases o
los dems paquetes que dependen de ese paquete deben actualizarse ahora a la versin ms reciente del paquete y probarse para asegurar que la nueva versin funciona sin incidentes. Si no hubo cohesin al agrupar las clases, es posible que cambie
una clase que no tenga relacin con las dems. Esto requerir un proceso innecesario de integracin y prueba. Por ello, slo deben incluirse en un mismo paquete las
clases que se reutilizarn juntas.
'
11.2.2 Lneas generales de diseo al nivel de componentes

Adems de los principios analizados en la seccin 11.2.1, es posible aplicar un conjunto pragmtico de lineas generales de diseo a medida que avanza el diseo al ni-
326
PARTE DOS
Qvse
debe tomar
en cuenta cuando
se nombran los
'compo11911tes?
vel de componentes. Estas lneas generales se aplican a componentes, sus inte"";...

ces y las caracteristicas de dependencia y herencias que impactan el diseo res..:..
tante. Ambler [AMB02) sugiere las siguientes lneas generales:
Componentes. Deben definirse convenciones de asignacin de nombres :;::-..

componentes especificados como parte del modelo arquitectnico, y luego refin.::s:
y elaborarse como parte del diseo al nivel de componentes. Los nombres del --,.
delo arquitectnico deben extraerse del dominio del problema y tener algn si~
cado para los participantes que ven el modelo arquitectnico. Por ejemplo, el !'
bre de clase Planocasa tiene significado para quienes Jo leen, sin importar suS
tecedentes tcnicos. Por otra parte, los componentes de infraestructura o las c
elaboradas al nivel de componentes deben tener un nombre que refleje el sigr do especfico de la implementacin. Si se habr de manejar una lista vinculada
mo parte de la implementacin de Planocasa, la operacin manejarUsta( ) re!"'.
apropiada, aunque una persona sin conocimientos tcnicos podria malinterpre
Tambin vale la pena usar estereotipos para ayudar a identificar la naturaleza
los componentes al nivel de diseo detallado. Por ejemplo, infraestructura P'w
usarse para identificar un componente de infraestructura; basededatos>> podra
se para identificar una base de datos que sirve a una o ms clases del diseo e ;:
do el sistema; tabla>> se usarla para identificar una tabla dentro de una base.:...
tos.
Inteaces. Las interfaces proporcionan informacin importante acerca de .a

municacin y la colaboracin (adems de ayudar a lograr el PAq. Sin emb~
representacin libre de las interfaces tiende a complicar los diagramas del c
nente. Ambler [AMB02) recomienda que l) cuando los diagramas se vuelva?""
complejos se use la representacin de linea y crculo para una interfaz, en lusa,
liMliit
Cohesin de
capa.
Panel de control
2 Es improbable que una persona de marcadotecnia o de la organizacin del cliente (un tipo
tecedentes tcnicos) examine el detalle de la infonnacin de diseo.
CAPiTtJLO 11
327
enfoque ms formal del recuadro UML y la flecha con lnea de guiones; 2) porrazones de consistencia, las interfaces deben fluir desde la izquierda del recuadro del
componente; 3) slo deben mostrarse las interfaces relevantes del componente en
cuestin, aunque estn disponibles otras. Estas recomendaciones pretenden simplificar la naturaleza visual de los diagramas de componentes UML.
Dependencias y herencia. Para mejorar la legibilidad es buena idea modelar las

dependencias de izquierda a derecha y la herencia de abajo (clases derivadas) hacia
arriba (clases principales). Adems, las interdependencias entre los componentes
deben representarse mediante interfaces, en lugar de hacerlo mediante la representacin de una dependencia de componente a componente. Siguiendo la filosofia del
PAC, esto ayudar a mejorar las opciones de mantenimiento del sistema.
11.2.3 Cohesin
En el captulo 9 se describi la cohesin como la "funcin nica" de un componente. En el contexto del diseo al nivel de componentes para sistemas orientados a objetos, la cohesin implica que un componente o una clase slo encapsula atributos y
operaciones relacionadas estrechamente entre s y con la clase del propio componente. Lethbridge y Laganire [LETOI] 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, componentes 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 funcin de seguridad de HogarSeguro haga una llamada telefnica al exterior si se dispara una alarma. Sera posible definir un conjunto de paquetes en capas como se
muestra en la figura 11.5. Los paquetes con pantalla gris contienen componentes de
infraestructura. El acceso se tiene del paquete del panel de control hacia abajo.
De comunicacin. Todas las operaciones con acceso a los mismos datos se definen dentro de una clase. En general, esa clase slo se concentra en los datos en
cuestin, accesndolos y almacenndolos.
Resulta relativamente fcil implementar, probar y mantener las clases y los componentes que muestran cohesin funcional, de capa y de comunicacin. El diseador debe luchar por alcanzar estos grados de cohesin. Sin embargo, hay muchos
casos en que se encuentran los siguientes niveles inferiores de cohesin:
Secuencial. Los componentes o las operaciones estn agrupados de manera que
el primero permita la entrada al siguiente, y as sucesivamente. El objetivo es implementar una secuencia de operaciones.
3
En general, mientras mayor sea el grado de cohesin, ms fcil ser implementar, probar y mantener el componente.
328
PARTE DOS
PRCilCA DE LA INGENlERA DEl. SOFTWARE
Procedimental. Las componentes o las operaciones estn agrupados de ma.:- ~

ra que permiten la invocacin de uno inmediatamente despus de que se invoque
anterior, aunque no se hayan pasado datos entre ellos.
Temporal. Las operaciones que se realizan reflejan un comportamiento o esta..
especfico, como una operacin que se realiza al principio o todas las operaciO""'
realizadas cuando se detecta un error.
Utilitaria. Se han agrupado componentes, clases u operaciones que existen d

tro de la misma categora, pero que no tienen otra relacin. Por ejemplo, una d
llamada Estadistica muestra cohesin utilitaria si contiene todos los atributos .,
operaciones necesarios para calcular seis medidas estadsticas simples.
Estos grados de cohesin son menos deseables y deben evitarse cuando eXs:
otras opciones de diseo. Sin embargo, es importante tomar en cuenta que a ve
los temas pragmticos de diseo e implementacin obligan al diseador a optar pcr
grados inferiores de cohesin.
Ed (un poco exasperado): aY esoquefTado811o

lendr ms de cien lineo, ele cdigo. veo .-....;
implementarlo.
Jamie: 2Y qu pasoria ~ metax:lolealio d.cide cambiar lo manera en que representamos el campo de
'i#a{ Jme muestro grficomente el campo
dloc6maro.
Jme nlUeSll'o grficomente lo om
1o anara.
Ecl: Simplemente memelo en la opeiac:i6n ~

moro{ Jy elaboro el m6dulo.
Jamie: Y qu pena coo k>5 efectos a:ilateialesf
Ed: A qu te refies?
CAPTULO 11
DISEO AL NNEL DE COMFONENllS
;que hoces el cambio pero, sin

con el despliegue del ID.
329
Ed: De modo que ests en conlm.de ilf
qu posara si una persona de
el mdulo dentro de dos oos.

operacin tan bien como t y,
ct..c:uidado.
Ed (pensndolo por un ............

mos ir con di9renle! operaciones de
Jamle: Buena decisi611.
11.2.4 Acoplamiento
En exposiciones precedentes del anlisis y el diseo se observ que la comunicacin

y la colaboracin son elementos esenciales de cualquier sistema orientado a objetos. Sin embargo, hay un lado oscuro en esta importante (y necesaria) caracterstica. A medida que aumenta la cantidad de comunicacin y colaboracin (es decir, a
medida que crece el grado de "conectividad" entre las clases), tambin aumenta la
complejidad del sistema. Y a medida que sta aumenta, la dificulta de implementar,
probar y mantener el software tambin lo hace.
El acoplamiento 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 interdependientes, el acoplamiento aumenta. un objetivo importante en el diseo al nivel de
componentes consiste en mantener el acoplamiento Jo ms bajo posible.
El acoplamiento de clase se manifiesta de varias maneras. Lethbridge y Laganire [LETOIJ definen las siguientes categoras de acoplamiento:
Acoplamiento del contenido. Ocurre cuando un componente "modifica subrepticiamente datos internos de otro" [LETOIJ. Esto viola la ocultacin de la informacin, que es un concepto bsico del diseo.
:'?llci6n se
- diseo de
de datos
yolos df
;,cedmentales
-pl!!or los es
de dotas. Sin
no deben
Acoplamiento comn. Ocurre cuando varios componentes usan una variable

global. Aunque esto es necesario en algunas ocasiones (por ejemplo, para establecer valores predeterminados en toda una aplicacin), el acoplamiento comn puede
llevar a la propagacin incontrolable de errores y a efectos colaterales imprevisibles
cuando se hacen cambios.
Acoplamiento de control. Se presenta cuando la operacin A() invoca la operacin B() y pasa una marca de control a B. La marca de control "dirige" entonces el
flujo lgico dentro de B. El problema con esta forma de acoplamiento es que un cambio no relacionado en B puede causar la necesidad de cambiar el significado de la
marca de control que pasa A. Si esto se orrute, se presentar un error.
Acoplamiento de estampa. Ocurre cuando ClaseB se declara como tipo para
un argumento de una operacin de ClaseA. Debido a que Clases ahora es parte de
la definicin de ClaseA, la modificacin del sistema se vuelve ms compleja.
330
PARTE DOS PRcnCA DE LA INGENIERA DEL SOFTWARE
Acoplamiento de datos. Ocurre cuando las operaciones pasan cadenas larg..

de argumentos de datos. El "ancho de banda" de la comunicacin entre clases
componentes crece y la complejidad de la interfaz aumenta. La prueba y el mar _
nimiento son ms dificiles.
Acoplamiento de llamada a rutina. Ocurre cuando una operacin invoca
otra. Este grado de acoplamiento es comn y, a menudo, muy necesario. Sin etn.:'2::
go, aumenta la conectividad de un sistema.
Acoplamiento de uso de tipo. OCurre cuando el componente A usa un tipc
datos definido en el componente B (por ejemplo, esto ocurre cada vez que "una c..::
declara una variable de instancia o una local como si tuviera otra clase para su ~
[LETOI]). Si cambia la definicin del tipo, tambin deben cambiar todos los corr:c
nentes que usan la definicin.
Acoplamiento de inclusin o importacin. Ocurre cuando el componer~

importa o incluye un paquete o el contenido del componente B.
Acoplamiento externo. OCurre cuando un componente se comunica o co..a:c

ra con componentes de infraestructura (como las funciones del sistema de OJ"D"cin, la capacidad de la base de datos, las funciones de comunicacin). Aunque 5;;'
tipo de acoplamiento es necesario, debe limitarse a un pequeo nmero de cor--;c
nente o clases dentro de un sistema.
El software debe comunicarse interna y externamente. Por tanto, el acoplamier~
fundamental. Sin embargo, el diseador debe trabajar para reducir el acoplar,, ~
cada vez que sea posible y comprender las ramificaciones de un acoplamiento
vado cuando no pueda evitarse.
CAPTULO 11
DISEO AL NIVEL DE COMPONENIES
331
Al principio de este captulo se observ que el diseo al nivel de componentes es de

naturaleza elaborativa. El diseador debe transformar la informacin del anlisis y
los modelos arquitectnicos en una representacin de diseo que proporcione suficiente detalle para guiar la actividad de construccin (codificacin y prueba). Los siguientes pasos representan un conjunto de tareas tpicas para el diseo al nivel de
componentes, cuando se aplica a un sistema orientado a objetos.
Paso 1. Identificar todas las clases de diseo que corresponden al dominio

del problema. usando los modelos de anlisis y arquitectnico, cada clase de anlisis y componente arquitectnico est elaborado como se describi en la seccin
l l.1.1.
Paso 2. Identificar todas las clases de diseo que corresponden al dominio de la infraestructura. Estas clases no se describen en el modelo 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 componentes de esta categora se incluyen componentes de interfaz grfica de usuario, del sistema operativo, de administracin de objetos y datos, y otros.
Paso 3. Elaborar todas las clases de diseo que no se adquieran como

componentes reutilizables. La elaboracin requiere que se describan de manera
detallada todas las interfases, los atributos y las operaciones necesarios para implementar la clase. Al realizar esta tarea debe tomarse en cuenta el diseo de la heurstica (por ejemplo, la cohesin y el acoplamiento de componentes).
Paso 3a. Especificar los detalles del mensaje cuando las clases o los componentes colaboran. El modelo 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 componentes, a veces es til mostrar los detalles de
estas colaboraciones al especificar la estructura de mensajes que se pasan entre 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 componentes del sistema
332
PARTE DOS PRCTICA DE LA INGENIERA OO. SOFlWAII.E
Diagrcuna de
TrobojoProduccin
colaboracin
con envio de
mensajes.
OrdenTrobojo
ColoTrobojo
En la figura 11.6 se ilustra un diagrama simple de colaboracin para el sistem::

impresin analizado antes. Tres objetos, TrabajoProduccton, OrdenTrabqc:.
ColaTrabajo, colaboran para preparar el envo de un trabajo de impresin al;
de produccin. Los mensajes se pasan entre objetos como lo ilustran las flec~
la figura. Durante el modelado del anlisis los mensajes se especifican com
muestra en la figura. Sin embargo, a medida que avanza el diseo, cada mensa
elabora al expandir su sintaxis de la siguiente manera [BEN02].
(condioin guardia] expresi6n de aec:uencia (valor dewelto):
nombre del mensaje (late
de argumentos)
donde una (condicin guardia] est escrita en lenguaje de restriccin de objeto 'C"t.
por sus siglas en ingls)~ y especifica cualquier conjunto de condiciones que de:_
cumplirse antes de enviar el mensaje; expt88in de seouencia es un valor entero (u ...
indicador de orden, como 3.1.2) que indica el orden secuencial en que se envia
mensaje; (valor devuelto) es el nombre de la informacin que devuelve la operacir
vocada por el mensaje; nombre del mensaje identifica la operacin que se invoca y
ta de argumentos) es la lista de los atributos que se pasan a la operacin
Paso 3b. Identificar las interfaces apropiadas para cada componente. Er.
contexto del diseo al nivel de componentes, una interfaz UML es un "grupo de e-raciones externamente visibles (es decir, pblicas). La interfase no contiene est::"
tura interna; no tiene atributos ni asociaciones... " [BEB02]. Definida de manera rformal, una interfaz es el equivalente a una clase abstracta que proporciona una
nexin controlada entre las clases de diseo La elaboracin de una interfaz se
tra en la figura 11.1. En esencia, las operaciones definidas para la clase de diseo
tn ordenadas en una o ms clases abstractas. cada operacin dentro de la d...:::
abstracta (la interfaz) debe tener cohesin es decir, debe mostrar procesarni
que se concentra en una funcin o subfuncin limitada.
Tomando como referencia la figura 11 l, podra argumen tarse que la interfaz
ciarTrabajo no muestra suficiente cohesin. En realidad, realiza tres subfunciones
El OCL se analiza brevemente en la seccin 11 .4 y en el captulo 28.
CAPTULO 11
333
Refaciorizacin de definiciones de interfases y clases para ImprimirTrabajo.
lmprimirTrobojo
OrdenTrabaj
nTrobojo
0---
atrbvlcs apropiads
<<interfot>>
ioitjorTrobojo
COMltuirOrdenTrobojoj )
TrobooPr<>dvccin
ColoTrabajo
olribvtos optQpk,<k,s
revsorProridod( )
'
ferentes: construir una orden de trabajo, revisar la prioridad del trabajo y pasar un
trabajo a produccin. El diseo de la interfaz debe refactorizar. Un enfoque sera reexaminar las clases del diseo y definir una nueva clase OrdenTrabajo que se ocupara de todas las actividades asociadas con la elaboracin de una orden de trabajo. La
operacin construirorden1i:abaj0() se vuelve una parte de esa clase. De igual manera,
se podra definir una clase FilaTrabajo que incorporara la operacin revisarPrioridad( ).
Una clase TrabajoProduccion abarcara toda la informacin asociada con un trabajo
de produccin que se pasar a la planta de produccin. La interfaz iniciatlrabajo tomara entonces la forma mostrada en la figura 11.7. Ahora esta interfase es cohesiva,
y se concentra en una sola funcin. Las interfaces asociadas con TrabajoProduccion, ordenTrabajo y FilaTrabajo tienen una sola funcin.
Paso 3c. Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos. En general, las estructuras y los tipos de datos con
que se describen atributos se definen dentro del contexto del lenguaje de programacin que habr de usarse para la implementacin. UML define el tipo de datos de un
atributo empleando la siguiente sintaxis:
nombre : tipo-expresin = valor-inicial {propiedad cadena}
donde nombre es nombre del atributo y tipo-expresin es el tipo de datos; valor-inicial es

el valor que toma el atributo cuando se crea un objeto y propiedad cadena define una
propiedad o caracterstica del atributo.
Durante la primera iteracin de diseo al nivel de componentes, los atributos suelen describirse por nombre. Tomando como referencia una vez ms la figura 11.1, la
lista de atributos de Trabajolmprenta slo incluye los nombres de los atributos; sin
embargo, a medida que avanza la elaboracin del diseo, cada atributo se define
empleando el formato de atributos UML indicado. Por ejemplo, Tipo-pesoPapel se define de la siguiente manera:
Tipo-pesopapel: strlng
= "A"{contiene 1 de 4 valoree: A, B. C o D}
334
PARTE DOS
PRC':lCA DE LA INGENIERA DEI. SOf"!WARE
que define npo-pesopepel como una variable de cadena variable inicializada con el 1-lor A y que toma uno de cuatro valores del conjunto (A,B,C,D}.
Si un atributo aparece varias veces en varias clases de diseo, y tiene una estr.._
tura relativamente compleja, es mejor crear una clase separada para acomoda-atributo.
Paso 3-D. Describir de manera detallada el flujo de procesamiento dem:-:i

de cada operacin. Esto se logra empleando un seudocdigo basado en un ~
guaje de programacin (seccin 11 .5.5) o el diagrama de actividad UML. cada ce::
ponente de software se elabora mediante varias interacciones que aplican el
cepto de refinamiento paso a paso (captulo 9).
La primera iteracin define cada operacin como parte de la clase de disee Et
cada caso, la operacin debe estar caracterizada de manera que asegure una
sin elevada; es decir, la operacin debe realizar una sola funcin o sustitucir'
finida. La siguiente iteracin hace poco ms que expandir el nombre de la operaa:c
Por ejemplo, la operacin calcuJarcostoPapel() observada en la figura 11 .1 se e-"":E:
dira de la siguiente manera:
celculerCosfoPepel (peso, temeno, color): nurnerico
Esto indica que calcuJarcostoPapel( ) requiere los atributos peso, tamao y cob
entrada y devuelve un valor numrico (en realidad un valor en pesos) como sa..
[ 'la W. lllido ms~. habra esaito uno rorto ms corta.
Si el algoritmo requerido para implementar calcularCostoPapel( ) es simp e

comprende ampliamente, tal vez sea innecesario elaborar diseo adicional. E.
Lo eloborodn se uso
fJOS-O oposa men/ros
se refino el disea del

componente. Siempre
debe pregunturse:
Hoy uno manero de
simplificar estu mientras sigue orra;ondo el
mismo resultada r
niero de software responsable de la codificacin proporcionar el detalle n

para implementar la operacin. Sin embargo, si el algoritmo es ms comple~
creto, se requiere mayor elaboracin de diseo en esta etapa. En la figura 1
describe un diagrama de actividad UML para calcularCostoPapel( ). Cuando se
plean diagramas de actividad para especificacin de diseo al nivel de co,,,....--1'........,,.,
tes, suelen representarse en un nivel de abstraccin un poco ms elevado que
digo fuente. Ms adelante, en este mismo captulo, se analizar un mtodo el uso de seudocdigo para especificar el diseo.
Paso 4. Descnl>ir fuentes de datos persistentes (bases de datos y arc:!:!.I

e identificar las clases necesarias para manejarlas. Las bases de datos _
chivos suelen trascender la descripcin del diseo de un componente individ........_
casi todos los casos estos almacenes de datos persistentes suelen especifica,c
cialmente como parte del diseo arquitectnico. Sin embargo, a medida que_
la elaboracin del diseo, a veces resulta til proporcionar detalles adiciona.es
estructura y organizacin de estas fuentes de datos persistentes.
CAPiTuLO 11
335
DISEO AL NIVEL DE COMPONENTI:S
Paso 5. Desarrollar y elaborar representaciones del comportamiento de

una clase o un componente. Los diagramas de estado UML se usaron como parte del modelo de anlisis para representar el comportamiento del sistema que se observa externamente y el comportamiento ms localizado de clases individuales de
anlisis. Durante el diseo al nivel de componentes, suele ser necesario modelar el
comportamiento de una clase de diseo.
Al comportamiento dinmico de un objeto (la instanciacin de una clase de diseo mientras se ejecuta el programa) lo afectan eventos externos y el estado actual
del objeto (modo o comportamiento). Para comprender el comportamiento dinmico de un objeto, el diseador debe examinar todos los casos de uso relevantes durante el periodo de vida de la clase de diseo. Estos casos de uso proporcionan informacin que ayuda al diseador a delinear los eventos que afectan al objeto y a los
estados en que reside ste mientras pasa el tiempo y ocurren los eventos. La transi-
Diagrama de actividad UML para caicularCostoPapel( ).
Validar entrado
de atributos
occesarDBPopel(peso)
regreso a costoPapelPorPagina
Tamao= B
Tamao= C
costoPope!PorPagina =
costoBasePorPa ina*'l.4
=D
costoPapelPorPa_gino
costoBasePorPa i na* 1.6
Tamao
El color
es personalizado
IP p .
ar agino =
costoBasePorPagina* l. 14
>----- costo ape
El color es estndar
Oevvlve
(costoPopelPorPa ina)
336
PARTE DOS
PRACl1CA DE LA INGENIER1A DEL SOFTWARE
cin entre estados (impulsados por los eventos) se representan empleando una ~
fica de estado UML [BEN02] como se ilustra en la figura 11.9.
La transicin de un estado (representado por un rectngulo con esquinas red=
deadas) a otro ocurre como consecuencia de un evento que toma esta forma
nombre-evento (liste-parametros) [condicion-gueNlia) / expresion de accion
donde nombre-evento identifica el evento; liste-paremetros incorpora datos asoct

con el evento; condicin-guardia est escrita en lenguaje de restriccin de objeto
y especifica una condicin que debe cumplirse antes de que pueda ocurrir el
to , y expresion de accion define una accin antes de que ocurra cuando tier ~
gar la transicin.
Tomando como referencia la figura 11.9, cada estado puede definir acciones
trada/ y salida/ que ocurren mientras se presentan las transiciones de entrada.
!ida. En casi todos los casos, estas acciones corresponden a operaciones rele
para la clase que se est mcxlelando. El indicador hacer/proporciona un meca~
ra indicar las actividades que ocurren mientras se encuentra en el estado, y el
cador incluir/ proporciona un medio para elaborar el comportamiento al incr.:
ms detalle en la grfica de estado dentro de la definicin de un estado.
Fragmento de diagrama de es1ado para la clase Trabajolmprenta.
entrodoDotoslncomplelos
Comporlomenlo dentro del

estado construrDalos lroboo
conslruirDolosTrobajo
entrar/leerDotosTrobajo{ 1
solir/desplegorOalosTrobojo( l
hacer/revisorConsisllllncia( ) ,
incluir/entrodciDotos
...
entradoDotosCompletodo (todos los el~mentos de dolos

consistentes)/ desplegorOpcionesUsuono
cok:ulareostoTrabajo
.,
., ,
,,
' '
' '
''
'
enlror/colculorTrobao
soli1/9uordor cos!oTotolTrobao
costo TrobojoAceptodo (el el iente est a utorizado)

/ obtenerfirmoElectronico
1
formorTrobojo
enlror/construirTroboo
so!ir/guordor nmeroOT
hacer/
fechoEntregoAceptodo (el d ie nte est autorizado)/
estimodoTrobajolmpresion
1
1emitrTrobajo
entror/remitirTrobojo
solir/iniciorTrobajo
hacer/colocar en ColoTrobojo
trobajoRemitido (todos los autorizaciones adquiridos

imprimirOrdenTrobojo
CAPTULO 11
DISEO Al NIVEL DE COMPONENTES
337
Es importante observar que el modelo de componentes a menudo contiene informacin que no resulta inmediatamente obvia en otros de componentes 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 nabajolmprenta depende de dos aprobaciones del cliente, derivadas de los datos de costos y la calendarizacin del trabajo de impresin. Sin aprobaciones (la condicin guardia asegura que el cliente tiene
autorizacin para aprobar) no se remitir el trabajo de impresin porque no hay manera de alcanzar el estado remitiJTrabajo.
Paso 6 . Elaborar diagramas de despliegue para proporcionar detalles de la

implementacin adicional. Los diagramas de despliegue (captulo 9) se usan como parte del diseo arquitectnico y se representan en forma de descriptor. As, se
representan las principales funciones del sistema (a menudo representadas como
subsistemas) dentro del contexto del entorno de cmputo que las albergar.
Durante el diseo al nivel de componentes pueden elaborarse diagramas de despliegue para representar la ubicacin de paquetes clave de componentes. Sin embargo, por lo general los componentes se representan individualmente dentro de un
diagrama de componente. La razn de esto es evitar la complejidad del diagrama.
En algunos casos, los diagramas de despliegue se elaboraron en forma de instancias.
Esto significa que el hardware especifico y el o los entornos del sistema operativo
que se usarn son especficos y que se indica la ubicacin de los paquetes de componentes dentro de este entorno.
Paso 7 . Factorizar todas las representaciones del diseo al nive l de componentes y siempre deben considerarse alternativas. A lo largo del libro se ha
destacado que el diseo es un proceso iterativo. El primer modelo al nivel de componentes 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 realiza el trabajo de diseo.
Adems, un diseador no debe tener una visin estrecha. Siempre hay soluciones
opcionales para el diseo, y los mejores diseadores toman en cuenta todas (o casi
todas) antes de definir el modelo de diseo final. Desarrollan opciones y examinan
cada una de manera cuidadosa, empleando los principios del diseo y los conceptos
presentados en los captulos 5, 9 y 11.
La amplia variedad de diagramas disponible como parte de UML proporciona a un

diseador un rico conjunto de formas de representacin para el modelo de diseo.
Sin embargo, las representaciones grficas no suelen bastar. El diseador necesita
un mecanismo para representar explicita y formalmente la informacin que restringe
algn elemento del modelo de diseo. Es posible. por supuesto, describir restricciones en un lenguaje natural, pero este mtodo lleva invariablemente a la inconsisten-
338
PARTE DOS
PRcnCA DE LA INGENtERIA DEL SOr.WA.~
cia y la ambigedad. Por tanto, lo apropiado parece un lenguaje ms formal, que

me en cuenta la teora de conjuntos y los lenguajes formales de especificacin o-ptulo 28), pero que tenga una cantidad menor de sintaxis matemtica que un le-:i
guaje de programacin.
,ro.,
~~
cfAv1
El OCL proporciono gmmtico ysintoxis formoles poro desuibir los

elementos de diseo ol
nivel de componentes.
El lenguaJe de restriccin de objetos (OCL) complementa al UML al permitir que

ingeniero de software use gramtica y sintaxis formales para construir instruccio-.:::5
sin ambigedades relacionadas con varios elementos del modelo de diseo ejemplo, clases y objetos, eventos, mensajes, interfaces). En el OCL las instrucci<re5
se construyen en cuatro partes: 1) un contexto que define la situacin limitada ...._
que es vlida la instruccin; 2) una propiedad que representan algunas caracteru
cas del contexto (por ejemplo, si el contexto es una clase, una propiedad seria .:.
atributo); 3) una operadn (aritmtica, orientada a conjuntos) que manipula o ~
ca una propiedad, y 4) palabras clave (como if, then, else, end, or, not, implies) con <;=e
se especifican expresiones concticionales.
Como ejemplo simple de una expresin OCL, considrese la condicin guardia ~
locada en el evento costoTrabajoAceptado que causa una transicin entre los esta..
calcularCostoTrabajo y forma:J1rabajo dentro del diagrama de grfica de est=J:.
para la clase Trabajolmprenta (figura 11.9). En el ctiagrama, la condicin guase expresa en lenguaje natural y especifica que la autorizacin slo se presentara
el cliente est autorizado para aprobar el costo del trabajo. En el OCL, la expres
tomara la forma:
cliente
tiene.eutoridadAutorizaci6n
= "si"
donde un atributo booleano, autoridedAutorizecin, de la clase Cliente (en realidad

instancia especfica de la clase) debe tener el valor si para satisfacer la condk
guardia.
Cuando se crea el modelo de diseo suele haber instancias (consulte la secc
11 .2.1) en que deben satisfacerse las condiciones previas y posteriores antes
completar alguna opcin especificada en el diseo. El OCL proporciona una he-a.
mienta poderosa para especificar condiciones previas y posteriores de manera
mal. Como ejemplo, piense en una extensin al sistema de la imprenta (analizac.
lo largo de este captulo) en que el cliente proporciona un lmite de costo supe"'
para el trabajo de impresin y una fecha de entrega lmite, al mismo tiempo qto.::
especifican otras caractersticas del trabajo. Si el costo y la entrega estimada e
den esos lmites, el trabajo no se entregar y debe notificarse al cliente. En el ~
un conjunto de condiciones previas y posteriores se especificara de la siguiente~
nera:
confexf Trebajolmprente::velidate{lirniieSi.eperiorCosfo : lnteger, reqEnvioCliente :
lnteger)
pre: hmifeSuperiorCosfo > O
CAPTULO 11
DISEO AL NIVEL DE COMPONEN!tS
339
and reqEnvioCliente > O

and tiene.autorizacionlrabajo = "no"
post: if tiene.costolotalTrabajo <= lirnite8uperiorCosto
and tiene.fechaEnvio < = reqEnvioCliente
then
tiene.eutorizeclonTrabajo = "si"
endif
Esta declaracin OCL define una invariante (condiciones que deben existir antes (pre]
y despus [post] de algn comportamiento). Al principio, la condicin previa establece

que el cliente debe especificar el costo lmite y la fecha de entrega, y que la autorizacin debe estar en "no". Despus de determinar los costos y la fecha de envio, se aplica la condicin posterior. Tambin debe tomarse en cuenta que la expresin tiene.eutolizacionlrebejo = "si" no est asignando el valor "s"; en cambio, est declarando que
autorizecionlrebejo debe tener el valor "s" en el momento en que termine la operacin.
Una descripcin completa del OCL est ms all del alcance de este libro.5 Los
lectores interesados deben consultar [WAR98] y [OMGOIJ para conocer detalles adicionales.
UML/OCL
Obietivo: Existe una amplia variedad de he-
ArgoUML, distribuido por Tigress.org (http://orgouml.ti-
rramientas UML para ayudar al diseador en

las etapas del diseo. Algunas de estos herromientas
ooccionon soporte al OCL.
nica: Las herramientos de esta categora permiten a

- seador crear todos los diagramas de UML necesopara construir un modelo de diseo completo. Lo ms
:::parlante es que .muchas herramientas proporcionan uno
s y uno semntico slidos, verificacin y manejo de
"rol de versin y cambios (captulo 27). Cuando se pro;::icroono capacidad de OCL, los herramientas permiten
el diseador cree expresiones OCL y, en algunos ca
os "compile" poro varios tipos de evaluacin y
5
6
gris.org/), do soporte o UML y OCL completo, e incluye varios herramientas de ayudo poro el diseo, que
van ms all de lo generacin de diagramas UML y expresiones OCL.
Dresden OCL too/kit, desarrollado por Frank Finger en la

Universidad Tecnolgico de Dresden (http://dresdenod-sourceforge.net/), es un juego de herramientas basado en un compilador OCL que abarco varios
mdulos que analizan, revisan el tipo y normalizan los
restricciones OCL.
OCL parser, desorrollodo por IBM (http://www3.ibm.com/ software/ad/librory/ stondars/OCL-downlood. html),

est escrito en Java y est disponible gratuitamente po
ro lo comunidad orientada o objetos con el fin de que
se estimule el uso de OCL con modeladores UML.
Sin embargo, en el captulo 29 se presentar una exposicion ms amplia del OCL (presentada en el
contexto de los mtodos formales)
Las herramientas mencionadas aqu representan una muestra de esta categora. En casi todos los
casos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.
PARTE DOS
mACllCA DE LA lNGENIERA DO. SOFTWARE
11, 5 P&IIA PI GANPAMIBDI M!IIIMlQNILII

Los fundamentos del diseo al nivel de componentes para componentes conven..
nales de software 7 se integraron a principios de la dcada de 1960 y adquirieror
lidez con el trabajo de Edsgar Dijkstra y sus colegas ([BOH66J, [DIJ65). [DIJ76])
nales de esos aos. Dijkstra y otros propusieron el uso de un conjunto de const::"
clones lgicas restringidas, a partir de las cuales se pudiera formar cualquier prog:,ma. Las construcciones destacaban el ''mantenimiento del dominio funcional
decir, cada construccin tenia una estructura lgica predecible, a la que se ingrcsa-ba en la parte superior y se abandonaba en la inferior, lo que permita al lect<X
--,
'!e'
C~VE
lo progromoci6n es
lloclurodo es uno tcnico de dise~o que res
tringe el flujo de lo l-
gico otres construcciones: secueooo, cm

cin y repeticin.
guir con mayor facilidad el flujo del procedimiento.

Las construcciones son secuencia, condjcin y repeticin Secuencia implemer::::i
los pasos de procesamiento esenciales en la especificacin de cualquier algor.
Condicin proporciona las funciones para el procesamjento seleccionado con ~

en algn evento lgico, y repeticin permite los bucles. Estas tres construcciones
fundamentales para la programacin estructurada, que es una importante tcnicz.
diseo al nivel de componentes.
Las construcciones estructuradas se propusieron para restringir el diseo pl""'liJ!'
dimental del software a un nmero pequeo de operaciones. La complejidad de
mtricas (captulo 15) indica que el uso de las construcciones estructuradas ra..
la complejidad del programa y, por tanto, mejora las opciones de lectura, pruet
mantenimiento. El uso de un nmero limitado de construcciones lgicas tarr.
contribuye a un proceso de comprensin humana que los psiclogos llaman
mentocin. Para comprender este proceso, pinsese en la manera en que est lt:"
do esta pgina. No se leen letras individuales sino que se reconocen patrones o;-
pos de palabras o frases formados por varias letras. Las construcciones estruct
das son grupos lgicos que le permiten a un lector reconocer elementos p r ~
mentales de un mdulo, en lugar de leer el diseo o cdigo lnea por linea. La e
prensin se mejora cuando hay patrones lgicos fcilmente reconocibles.
11.5.1 Notacin grfica del diseo

Ya se ha analizado el diagrama de actividad UML en este capitulo y en los cap1
7 y 8 El diagrama de actividad permite a un diseador representar secuencia ~
dicin y repeticin (todos elementos de la programacin estructurada) y es el ...
cendiente de una representacin de diseo grfico anterior (an usado amplia.te) llamado diagrama de flujo.
Un diagrama de flujo, como uno de actividad, es muy simple grficamente
diamante representa una condicin lgica, y las flechas muestran el flujo de cor
7
Un componente de software convencional implementa un elemento de procesamiento que a

una funcin o subfuncin en el dominio del problema, o alguna capacidad en el dominio de
fraestructura . A menudo denominados mdulos, procedmuentas o subrotmas, los componentes
vencionales no encapsulan datos de la misma manera que los componentes orientados a oti,ct::
CAPTULO 11
.._. ._
Primera
.. torea
.._. . ._
Siguiente
.. tarea
Secuencia
341
DISEO AL NIVEL DE COMPONBITTS
Parte si_no (else)
......
.._
Porte entonces (then)
sientoncessi_no (interfaxthenelse)
Mientras hacer (do while)
Repetir hasta (repeat until}
Repeticin
En la figura 11.1 O se ilustran tres construcciones estructuradas. La secuencia se representa como dos cajas de procesamiento conectadas por una lnea (flecha) de control. La condicin, tambin llamada si-entonces-si.}10, se describe como un diamante
de decisin que, si es verdadero, causa que ocurra la parte-entonces del procesamiento, y si es falso, invoca la parte si_no. La repeticin se representa empleando dos
formas ligeramente diferentes. La parte hacer mientras prueba una condicin y ejecuta una tarea de bucle de manera repetitiva, siempre y cuando la condicin siga
siendo verdadera. Una parte repetir hasta ejecuta primero la tarea de bucle, luego
prueba una condicin y repite la tarea hasta que la condicin falla. La construccin
de seleccin (o seleccionar-caso) que muestra la figura es en realidad una extensin de
si-entonces-si_no. Sucesivas decisiones prueban un parmetro hasta que ocurre una
condicin verdadera y se ejecuta la ruta de procesamiento de la parte de caso.
En general, el uso dogmtico y exclusivo de las construcciones estructuradas introduce ineficiencia cuando se requiere un escape de un conjunto de bucles anidados o de condiciones anidadas. Lo que es ms importante, la complicacin adicional
de todas las pruebas lgicas junto con la ruta de escape llega a oscurecer el flujo de
control del software, aumenta la posibilidad de error y tiene un impacto negativo en
la legibilidad y la capacidad de mantenimiento. Qu podemos hacer?
Se le dejan dos opciones al diseador: 1) se redisea la representacin procedimental para que la "rama de escape" no sea necesaria en una ubicacin anidada del
flujo de control, o 2) se violan las construcciones estructuradas de una manera controlada; es decir, se disea una rama restringida fuera del flujo anidado. La opcin 1
es obviamente el enfoque ideal, pero la 2 puede acomodarse sin infringir el espritu
de la programacin estructurada.
342
PARTE DOS
PRACilCA DE LA INGENIERIA.DELSOF?WAR.E
11 .5.2 Notacin tabular del diseo

Debe usorse llfllJ roblo
de decisin cuondo IR1
conjunto complejo de
coomooes y ocdones
se encuentran dentro
de un componente.
En muchas aplicaciones de software tal vez se requiera un mdulo para evaluar

combinacin compleja de condiciones y seleccionar Jas acciones apropiadas ha::.:
das en esas condiciones Las tablas de decisin [HUR83J proporcionan una nota
que traduce acciones y condiciones (descritas en una narrativa de procesamient.:!
una forma tabular Es difcil malinterpretar una tabla, y hasta puede usarse como
trada legible para una mquina a un algoritmo orientado a tablas.
Una tabla de decisin se divide en cuatro cuadrantes El de la esquina superar
quierda contiene una sta de todas las condiciones. El cuadrante de la esquina inra
izquierda contiene una lista de todas las acciones posibles, basada en combina:l:..
nes de condiciones. Los cuadrantes de la derecha fonnan una matriz que
combinaciones de condicin y las acciones correspondientes que ocurrirn para ura
binacin especfica. Por tanto, cada columna de la matriz puede interpretarse
una regla de procesamiento. Los siguientes pasos se aplican para desarrollar r
bla de decisin.
l . Presentar una lista de todas las acciones que puedan asociarse con un
dimiento (o mduJo) especifico.
2 . Presentar una lista de todas las condiciones (o decisiones tomadas) du

ejecucin de un procedimiento.
3. Asociar conjuntos especificas con acciones especficas, eliminando co
dones especficas de condiciones; como opcin, desarrllese cada pose.e
pennutacin de las condiciones.
4. Definir reglas al indicar cuJes acciones ocurren para un conjunto de

dones
Para ilustrar el uso de una tabla de decisin, pinsese en el siguiente extracu
caso de uso informal que se ha propuesto para el sistema de la imprenta.
Tres tipos de clientes estn definidos, un cliente regular, uno de plata y uno de oro
tipos se asignan segun la cantidad de negocios que el chente realiza con la i m ~
un penodo de 12 meses). Un cliente regular recibe precios de impresin y fechas de
ga normales. Un cliente de plata obtiene un descuento de 8 por ciento sobre todas
tizaciones y se coloca adelante de los clientes regulares en la cola de impresin Un
de oro obtiene una reduccin del 15 por ciento sobre los precios cotizados y se coloca
!ante de los clientes regulares y de plata en la cola de trabajo. Es posible aphcar
cuento especial de x porcentaje adicional a los otros descuentos a la couz.a.ci=:
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 usa
nera efectiva para complementar otras notaciones de diseo procedmental
CAPTULO 11
343
DISEO AL NIVEL DE COMPONENnS
Reglas
Condiciones
2
V(T) V (T)
1
Cliente regular
Cliente plato
V (T) V (T)
Cliente especial
Sin de$cuento
V (T) V (T)
Cliente oro
Acciones
V (TJ
V (T)
V (T)
))
'
1~
"'"
-.,,;'
Aplicar 8 por ciento de descuento

Aplicar 15 por ciento de descuento
A plicar x porcentoje de descuento
adicional
.
..
!i-.,,;'
""' ""' ...,,,,.~
-.,,;'
11.5.3 Lenguaje de diseo de programas

El lenguaje de diseo de programas (PDL, por sus siglas en ingls). tambin denomi nado lenguaje comn estructurado o seudocdigo, es "un lenguaje rudimentario porque 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, algunas herramientas pueden traducirlo en un "esqueleto" 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 cruzada y otra informacin diversa.
Un lenguaje de diseo de programas puede ser una simple transposicin de un
lenguaje como Ada, e o Java. La sintaxis bsica de PDL debe incluir construcciones
para definicin de componentes, descripcin de interfaces, declaracin de datos, estructuracin de bloques y construcciones de condiciones, de repeticin y de entrada/salida. Debe tomarse en cuenta que PDL puede extenderse para incluir palabras
clave para multitareas, procesamiento concurrente (o ambas opciones). manejo de
interrupciones, sincronizacin de interprocesos y muchas otras caractersticas. El diseo 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 captulos anteriores. El sistema supervisa las alarmas para detectar fuego, humo, robo,
344
PARTE DOS
PRAcncA DE LA INGENIERA DEL SOflWARE
agua y temperatura (por ejemplo, rompimiento del horno cuando el propietario es.a
ausente en el invierno), produce un timbre de alarma y llama a un sistema de moc
tores, generando un mensaje de voz sintetizado. En el PDL siguiente ilustramos a.
gunas de las construcciones importantes anotadas en secciones anteriores.
Recuerde que PDL no es un lenguaje de programacin. El diseador puede ad~
tarlo como se requiera sin preocuparse por errores de sintaxis. Sin embargo, el diseo del software de supervisin tendria que revisarse (se observa algn problema>y refinarse antes de que pueda escribirse el cdigo. El siguiente PDL8 proporcio--.2
una elaboracin del diseo procedimental para una versin anterior de un CO!l\P'>
nente de manejo de alarmas.
componente manejoAlarma
El objetivo de este componente es manej81' los intemJptores y las entradas del panel
control a partir de los sensores por el tipo y actuar en cualquier condicin de alarma
sea encontrado.
establecer valores por def'ecto para estatus8istema (valor devuelto). todos los ~
tos de datos
inicializar todos los puertos del sistema II reiniciar todo el hardware
revisar interruptoresPanelConttol (ipc)
si ipc
= "probar" entonces invocar alarma fij81' en "encendido"
si ipc
= "alarmaApagado" entonces invocar alarma fijar en "apagado"
valor por defecto ipc = ninguno

restablecer todo valoresSeal e intem.iptores
hacer para
todos los sensores
invocar vermcar8ensor procedimiento regresa valor8eal

si valor8eal > lmite [tipoAlarma]
entonces telefono.mensaje
= mensaje [tipoAlarma]
fij81' timbreAlarma en "encendido" para alarmaTiernpo8egundos

fijar estatus sistema
= "condicinAlarma"
parernpieza
procedimiento al.arma con "encendido", alarmaTiernpo8egundos
invocar procedimiento telfono fijar en tipoAlarme, nrnerolelfono
partermina
si_no omitir
termina si
termina ha08t'par&
termine manejoAlarma
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
CAPTULO 11
345
Obsrvese que el diseador del componente de manejo de alarma ha usado las construcciones parempieza..partermina que especifica un bloque paralelo. Todas las tareas
especificadas en el bloque parempieza se ejecutan en paralelo. En este caso, no se toman en cuenta los detalles de implementacin.
Lenguaje de diseo de programas

Objetivo: Aunque la inmensa mayora de los
ingenieros de software que usa PDL o seudoc
cesorrolla una versin que se adopto del lenguaje de
acz:rarrlCJCin que trotan de emplear poro lo implementae...sten varias herramientas de PDL.
: En algunos casos, los herramientas aplican
inversa al cdigo fuente (uno triste realidad en
,.,Jo donde algunos programas no tienen absoluto" nguno documentacin). Otros permiten al diseoO'l!IOI' PDL con una ayudo automatizado.
..,....,.,,..;ia
-mientas representativas9
S ' desarrollado por Coine, Forber y Gordon
::-p://www.cfg.com/pdl81 /lpd.html), do soporte o lo
creacin de diseos con el uso de uno versin definida

de PDL.
DocGen, distribuido por Software lmprovment Group
(http://www.softwareimprovers.com/DocGen.htm),
es una herramienta de ingeniera inversa que genera
documentacin parecida o PDL o partir de cdigo
Ada y C.
PowerPDL, desarrollado por lconix (http://www.iconixsw.
com/SpecSheets/PowerPDL.html), le permite a un diseador crear PDL basado en diseos y luego traducir el
seudocdigo o formas que puedan generar otras re
presentaciones de diseo.
11 .5.4 Comparacin entre notaciones de diseo

La notacin de diseo debe llevar a una representacin procedimental fcil de com-
prender y revisar. Adems, la notacin debe mejorar la capacidad de "codificar en" para 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 mantenimiento
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 sera: Cul notacin es realmente 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, mejorando la documentacin y facilitando ms el mantenimiento del diseo. La edicin se hace en
cualquier editor de texto o sistema de procesamiento de palabras, ya existen procesadores automticos, y la posibilidad de "generacin automtica de cdigo" es buena.
Sin embargo, de esto no se desprende que cualquier otra notacin sea necesariamente inferior a PDL, o que "no sea buena" en atributos especficos. La naturaleza
Las herramientas expuestas aqu el autor no las respalda ; slo representan una muestra de las herramientas incluidas en esta categora. En casi todos los casos. los nombres de las herramientas son
marcas registradas de sus respectivos desarrolladores
346
PARTE DOS
PRCTICA DE LA INGENIERA DEI. SOFTWARE
grfica de los diagramas de actividad y los de flujo proporciona una perspectiva s.:tbre el flujo de control que muchos diseadores prefieren. El contenido tabular preo
so de las tablas de decisin es una herramienta excelente para aplicaciones orier
das a tablas. Y muchas otras representaciones de diseo (por ejemplo, nidos de ~
tri), no presentados en este libro, ofrecen sus propios beneficios nicos. En el ar
sis final, la eleccin de una herramienta de diseo estar relacionada de manera restrecha con factores humanos que con atributos tcnicos.
La accin de diseo al nivel de componentes abarca una secuencia de tareas qi..e
ducen lentamente el grado de abstraccin con que se representa el software S

seo al nivel de componentes describe finalmente el software en un grado de
traccin cercano al cdigo.
Es posible tomar dos enfoques distintos de diseo al nivel de componentes ,
depende de la naturaleza del software que habr de desarrollarse. El concepto
tado a objetos se enfoca en la elaboracin de clases de diseo que proviener
del problema como del dominio de la infraestructura. El concepto convenciop
fina tres tipos principales de componentes o mdulos: de control, de dornin;o
problema y de infraestructura. En ambos casos se aplican principios bsicos Cei
seo y conceptos que llevan a software de mayor calidad. Cuando se considera
de un punto de vista del proceso. el diseo al nivel de componentes se basa e,..
ponentes de software reutilizables y en patrones de diseo que son elementos
te de la ingeniera de software basada en componentes.
El diseo al nivel de componentes orientado a objetos se basa en clases.
principios y conceptos importantes guan al diseador a medida que se elatxr.:.
clases. Principios como el principio abierto-cerrado y el de inversin de la depe.;
cia, adems de conceptos como acoplamiento y cohesin, guan al ingeniero d..
ware en la construccin de componentes de software susceptibles de probarsr.
plementarse y mantenerse. Para realizar diseo al nivel de componentes c:contexto, las clases se elaboran al especificar detalles de los mensajes, identif...:..
terfaces apropiadas, elaborar atributos y definir estructuras de datos para imp
tarlos, describir el flujo de procesamiento dentro de cada operacin y represe--.:t:
comportamiento en un nivel de clase o componente. En todo caso, la iteracir'
seo es una actividad esencial.
El diseo al nivel de componentes convencional requiere la representacir
tructuras de datos, interfaces y algoritmos para un mdulo de programa con e
zc
lle suficiente para servir como gua en la generacin de cdigo fuente en leng:
programacin. Para lograr esto, el diseador usa una de varias notaciones c.:
o que representan detalles al nivel de componentes en formatos grficos, ld:..,.....;.;.111
o de texto.
CAPTULO 11
DISEO AL NIVEL DE COMPONEN'TES
347
La programacin estructurada es una filosofa de diseo procedimental que restringe el nmero y tipo de construcciones lgicas para representar el detalle del algoritmo. El objetivo de la programacin estructurada es ayudar al diseador a definir algoritmos que sean menos complejos y, por tanto, ms fciles de leer, probar y
mantener.
[AMB02] Ambler, S., "UML Component Diagramming Guidelines", disponible en http://www.modelingstyle.info/, 2002.
[BEN02] Bennett, S., S., McRobb y R. Farmer, Object-Oriented Analysis and Design. 2a. ed., McGraw-Hill, 2002.
[B0H66J Bohm, C. y G. Jacopini, "Flow Diagrams, Turing Machines and Languages with Only
l\vo Formation Rules", en CACM, vol. 9, nm. 5, mayo de 1966, pp. 366-371.
[CAl751 Caine, S. y K. Gordon, "PDL-A Too! for Software Design", en Proc. National Computer
Conference, AFIPS Press, 1975, pp. 271-276.
LDIJ65J Dijkstra, E., "Programming Considered as a Human Activity", en Proc. 1965 IFIP congress,
North-Holland Publishing Co., 1965.
[DIJ72) Dijkstra, E, "The Humble Programmer", 1972 ACM Turing Award Lecture, CACM, vol. 15,
nm. 10, octubre de 1972, pp. 859-866.
[DIJ76) Dijkstra, E., "Structured Programming", en Software Engineering, concepts and Techniques
u. Buxton et al., eds.), Van Nostrand-Reinhold, 1976.
[HUR83J Hurley, R. B., Decision Tables in Software Engineering, Van Nostrand-Reinhold, 1983.
[LETOIJ Lethbridge, T. y R. Laganiere, Object-Oriented Software Engineering: Practica/ Software
Development using UML and Java, McGraw-Hill, 2001.
[LTS881 Liskov, B., "Data Abstraction and Hierarchy", en SIGPLAN No/ices, vol. 23, nm. 5, mayo
de 1988.
[MAROOJ Martn, R., "Design Principies and Design Patterns", descargado de http:/ /www.objectmentor.com, 2000.
[OMGOJJ OMG Unijied Modeling Specijication. Object Management Group, version 1.4, septiembre de 2001.
[WAR98] Warmer, J. y A. Klepp, Object Constraint Language: Predse Modeling with UML, AddisonWesley, 1998,
11 .1. El trmino componente suele ser dificil de definir. Primero proporcinese una definicin
genrica y luego definiciones ms explcitas para software orientado a objetos y convencional.
Por ltimo, eljanse tres lenguajes de programacin con los que se est familiarizado e ilstrese la manera en que cada uno define un componente.
11 .2. Por qu son necesarios los componentes de control en el software convencional y no lo
son en el orientado a objetos?
11 .3. Descnbase el paradigma orientado a objetos mediante argumentos propios. Por qu es importante crear abstracciones que sirvan como interfaz entre componentes?
11 .4 . Descrbase el DIP mediante argumentos propios. Qu pasarla si un diseador depende
excesivamente de las concreciones?
11 .5. Seleccinense tres componentes que se hayan desarrollado recientemente y evalense
los tipos de cohesin de cada uno. Si se tuviera que definir el principal beneficio de una cohesin elevada, cul seria?
11.6. Seleccinense tres componentes que se hayan desarrollado recientemente y evalense

los tipos de acoplamiento de cada uno. Si tuviera que definir el principal beneficio de un acoplamiento elevado. cul sera?
348

11 . 7. Es razonable decir que los componentes del dominio del problema nunca deben trar acoplamiento externo? Si se est de acuerdo, cules tipos de componente mostraran ~
tipo de acoplamiento?
11 .8 . lnvestguese y desarrllese una lista de categoras tpicas para los componentes ck
fraestructura.
11.9. Qu es una condicin guardia y cundo se usa?
11.10. Cul es el papel de las interfaces en un diseo al nivel de componentes basa.:.
clases?
11 . 11 . Los trminos atributos pblicos y privados suelen usarse en trabajo de diseo al ru ,
componentes. Qu significa cada uno y cules conceptos de diseo tratan de im~
11.12. Qu es una fuente de datos persistentes?
11 .13. Desarrllese 1) una clase de diseo elaborada; 2) descripciones de interfaz; 3) i...grama de actividad para una de las operaciones dentro de la clase: 4) un diagrama de g:-:r:;
de estado detallado para una de las clases de HogarSeguro que se han analizado en cat"
anteriores.
11 . 14. Es lo mismo refinamiento por pasos que factorizacin? Si no, cules son sus di!c::::::
cias?
11 . 15. lnvestguese un poco y descrbanse tres o cuatro construcciones OCL u operadoc..s
no se hayan analizado en la seccin 11.4.
1 1.16. Seleccinese una pequea parte de un programa existente (de unas 50 a 75 li;-.:.c:...,
cdigo). Aslense las construcciones de programacin estructurada dibujando cajas alr
de ellas en el cdigo fuente. El extracto del programa tiene construcciones que violan .a
solfa de programacin estructurada? De ser as, redisese el cdigo para que se amok'.f
construcciones de programacin estructurada. De lo contrario, qu nota en los recuam
est dibujando?
Los principios de diseo, los conceptos, las lineas generales y las tcnicas para clases
ponentes orientados a objetos se revisan en muchos libros sobre ingeniera de softwart:
lisis y diseo orientados a objetos. Entre las muchas fuentes de informacin se en
Bennett y sus colegas [BEN02]. Larman (Applying UML and Pattems, Prentice-Hall, 200
ridge y Laganiere [LETOIJ y Nicola y sus colegas (Streamlined Object Modeling: Patterand Jmplementation, Prentice-Hall, 2001), Schach (Object-Oriented and Classical sojtl....
~
neering, quinta edicin, McGraw-Hill, 2001 ), Dennis y sus colegas (Systems Analysis a:Jt.
sign: An Object Oriented Approach wilh UML, Wiley, 2001), Graham (Object-Oriented
Principies and Practice, Addison-Wesley, 2000), Richter (Designing Flexible Object-Oner.
tems with UML, Macmillan, 1999), Stevens y Pooley (Using UML: SOflware Engineering
jects and Components, edicin revisada, Addison-Wesley, 1999) y Riel (Object-Orientol
Heuristics, Addison-Wesley, 1996).
El concepto de diseo por contrato es un til paradigma de diseo. Libros de Mitdd
Kim (Design by contract by Example, Addison-Wesley, 2001) y Jezequel y sus colegas
Pattems and Contracts, Addison-Wesley, 1999) analizan este tema en forma detallada
(Design Pattems Java Workbook, Addison-Wesley, 2002) y Shalloway y Ttott (Design Pt.
plained: A New PeISpecl'ive on Object-Oriented Design, Addison-Wesley, 2001) toman erel impacto de los patrones en el diseo de componentes de software. La iteracin de
esencial para la creacin de diseos de alta calidad. Fowler (Refactoring: Improving ;,
of EXisting Code, Addison-Wesley, 1999) proporciona una gua til que puede aplicarse z
da que evoluciona el diseo.
El trabajo de Linger, Milis y Wilt (Structured Programming-Theory and Practice "
Wesley, 1979) sigue siendo un tratado definitivo sobre el tema. El texto contiene un ~
adems de explicaciones detalladas de las ramificaciones de la programacin estr:
CAPTULO 11
DISEO AL NIVEL DE COMPONEN!ES
349
Otros libros que se concentran en los temas de diseo procedimental para sistemas tradicionales son los de Robertson (Simple Program Design, tercera edicin, Course Technology, 2000),
Farrell (A Guide to Programming Logc and Design, course Technology, 1999), Bentley (Program
ming Pearls, 2a. edicin, Addison-Wesley, i999) y Dahl (Structured Programming, Academic
Press, 1997).
Relativamente, pocos libros recientes se han dedicado en exclusiva al diseo al nivel de
componentes. En general, los libros de lenguaje de programacin atienden el diseo procedimental con algn detalle, pero siempre en el contexto del lenguaje que se introduce en el libro.
Hay disponibles cientos de ttulos.
Una amplia variedad de fuentes de informacin sobre diseo al nivel de componentes se
encuentra en Internet. Una lista actualizada de referencias en World Wide Web que resultan relevantes para el diseo al nivel de componentes se encuentra en el sitio Web de SEPA:
http:/ / www.mhhe.com/ pressman.
CAPTULO
12
CONCEPTOS
CLAVE
0<cesibi1iclod .315
anilsls ele
lo tarea ..... .35&
llllllsis del
fkljo de trabajo .364
eklborodn 11e
tarea ........363
fodlldod de uso. 3SS

Mklont$ de
ayuda .... ...373
i!lteri,aCOllw
ZO<ln ...... .376
lnterfar ... , . .354

anlisis de . .354
consistencia . .3SS
evaluadn . .377
IIIOdelos . .3S6
pasos de
diseo ...... 368
patrones .... .371

reglas ele oro . .3Sl
DISEO DE LA INTERFAZ
DE USUARIO
1 plano de una casa (su diseo arquitectnico) no estara completo sin
representacin de puertas. ventanas y conexiones de agua, electricidad
lfono {sin mencionar la televisin por cable). Las "puertas, ventanas )
nexiones" del software de computacin integran el diseo de la interfaz
usuario_
El diseo de la interfaz se concentra en tres reas: l} el diseo de inte
entre componentes de software; 2) el diseo de interfases entre el softv,
otros productores y consumidres de informacin que no son humanos (es
clr, otras entidades externas), y 3) el diseo de la interfaz entre un ser h
(es decir, el usuario) y la computadora. Este captulo se concentrar excl
mente en la tercera categora de diseo de Ja interfaz: la del usuario.
En el prlogo de su libro clsico acerca del diseo de interfaces de UStZ:
Ben Shneiderman (SHN90] afirma:
La frustracin y ansiedad son parte de la vida diaria de muchos usuarios de sist

de informacin computarizados Luchan por aprender el lenguaje de comandos o
sistemas de seleccin de mens que presuntamente deben ayudarles a realizar su
bajo. Algunas personas se encuentran con casos tan serios de choque de comp
ra, terror terminal o neurosis de red, que evitan el empleo de sistemas de cmp
Los problemas que refiere Shneiderman son reales. Es cierto que las
ces grficas de usuario, las ventanas, los iconos y las selecciones hechas
ratn han eliminado gran parte de los ms terribles problemas relaciona
las interfases. Pero aun en un "mundo de ventanas", todo mundo ha ene...___... ,
Qu es? El diseo de la interfaz de
usuoro crea un medio de comomco cin

efectivo entre un ser humano y
una computoclora. S19uiendo un con
junto de principios de diseo de
intertac-es, el dt$eiiodor identifica los obetos y
los acciones de la interfaz y luego crea un for
mato de pantalla que forma la base de un prototipo de interfaz: de usuario.
Quin lo hace? Un ingeniero de software diseo
la interfaz de usuario al oplkor un proceso iterativo basado en principios de diseo ampliamente aceptados.
Por qu es importante? Si el uso del software es
d fcil, si llevo al usuario o comefer errores o si
frustro sus esfuerzos por alcanzar sus ob

no le gvstor4, sin importar su copocidod
funciones qve ofrezca. lo nrerfoz tiene q
correcta porque moldea la percepcin del
ro acerco de1 software.
C~s son los pasos? El diseo lo nterfa=
usuario empiezo con la identificacin
requisitos de ste, la toreo y el ombien!e.
vez identificados los tareQs del usuario, se
y analizan los escenarios de ste poro de
conunto de objetos y acciones poro lo
Esto constituye fo base poro lo creacin
motos de pontal10 que representan el disen::
fico y la ubicacin de los iconos; lct defiru
texto descriptivo en pantalla; Jo especifi
CAPTULO 12
DISEO DE LA INTERFAZ DE USUARIO
351
interfases de usuario diflciles de aprender y usar, confusas, poco intuitivas, imperdonables y, en muchos casos, totalmente frustrantes. Sin embargo, alguien dedic
tiempo y energa a la construccin de tales interfaces, y es improbable que el constructor haya generado estos problemas a propsito.
El diseo de la interfaz de usuario requiere el estudio de las personas y el conocimiento tecnolgico adecuado. Quin es el usuario? Cmo aprende a interactuar
con un nuevo sistema de cmputo? Cmo interpreta la informacin que produce el
sistema? Qu espera del sistema? stas son slo algunas de las muchas preguntas
que deben plantearse y responderse como parte del diseo de la interfaz de usuario.
En su libro sobre el diseo de interfaces, Theo Mantel [MAN97] acu tres "reglas de
oro" para el diseo de la interfaz:
1. Dar el control al usuario.

2. Reducir la carga en la memoria del usuario.
3 . Lograr que la interfaz sea consistente.
Estas reglas de oro forman la base de un conjunto 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, durante la sesin de acopio de requisitos para un
nuevo e importante sistema de informacin, acerca de los atributos de la interfaz
grfica orientada a ventanas. "Lo que en verdad me gustara", dijo el usuario solemnemente, "es un sistema que me lea la mente. Que sepa lo que quiero hacer antes
de que deba hacerlo y que me permita hacerlo fcilmente. Eso es todo, y nada ms".
Mi primera reaccin fue mover la cabeza y sonrer, pero me detuve por un momento. No haba absolutamente nada de malo en la solicitud del usuario. Quera un
sistema que reaccionara a sus necesidades y que le ayudara a hacer las cosas. Quera controlar la computadora; no que sta lo controlara.
La mayor parte de las restricciones y limitaciones que impone el diseador a la
interfaz pretenden simplificar el modo de interaccion. Para quienes' En muchos ca-
352
PARTE DOS
PRCTICA DE LA INGENIEilA DEL SOFTWARE
sos, el diseador introduce limitaciones y restricciones para simplificar la impleme:

tacin de la interfaz. As, tal vez se tenga como resultado una interfaz fcil de com--
truir, pero cuyo uso resulta frustrante.

Mande! [MAN97] define varios principios de diseo que permiten al usuario r-tener el control:
Definir los modos de interaccin de forma que el usuario no realice acc:io--nes innecesarias o indeseables. un modo de interaccin es el estado actua..
la interfaz. Por ejemplo, si se elige corrector ortogrfico en un men de un proc:.s
dor de palabras, el software pasa a un modo corrector ortogrfico. No hay nin:,
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.
Proporcionar una interaccin flexible. Debido a que diferentes usuarios t.::.

distintas preferencias de interaccin, deben ofrecerse las opciones correspondi Por ejemplo, tal vez el software le permita al usuario interactuar mediante ..
miento del ratn, un lpiz digitalizador o comandos seleccionados con el tec ~
mediante reconocimiento de voz. Pero no todas las acciones son adecuadas pa."a
dos los mecanismos de interaccin. Por ejemplo, imagine la dificultad de utiliza;
mandos seleccionados con el teclado (o entrada de voz) para dibujar una
compleja.
Incluir las opciones de interrumpir y deshacer la interaccin del usilJilC:ia.l

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 interaccin a medida que aumentan los grados de dest:reD

permitir que se personalice la interaccin. Con frecuencia, los usuarios nan repitiendo la misma secuencia de interacciones. Vale la pena disear un
nismo de "macro" que permita a un usuario personalizar la interfaz para fad
interaccin.
Oculte al usuario ocasional los elementos tcnicos internos. La inter.z:be llevar al usuario al mundo virtual de la aplicacin; no es necesario que e
el sistema operativo, las funciones de administracin de archivos u otros secre'.':I
la tecnologa de cmputo. En esencia, la interfaz nunca debe requerir que el
interacte en el nivel "interno" del equipo (por ejemplo, nunca debe pedirse
usuario escriba comandos del sistema operativo desde el interior del sofu.
aplicacin).
Disear interaccin directa con los objetos que aparecen en la pantalli.

usuario siente que tiene el control cuando manipula los objetos necesarios palizar una tarea de manera parecida a como lo hara con un objeto material. Po
plo, una interfaz de aplicacin que permita al usuario "alargar" un objeto
su tamao) es una implementacin de manipulacin directa.
353
CAPTULO 12 DISEO DE LA INTERFAZ DE USUARIO
"Siempre he deseado quemi computadora seo Ion fl de monejor como mi telfono. Mi4ese4'~ ha vuelto realkfal
Ya no StlflO IJSflf mi telfono."
aa,ae Stroastnp (crea,+ir <++I
12.1.2 Reducir la carga en la memoria del usuario

Cuantas ms cosas tenga que recordar un usuario, ms probabilidades habr de que
cometa errores al interactuar con el sistema. Por ello, una interfaz de usuario bien
diseada no depender de la memoria de ste. Siempre que sea posible, el sistema
debe "recordar" la informacin pertinente y ayudar al usuario con un escenario de
interaccin que le facilite el uso de la memoria. Mande! [MAN97] define los principios de diseo que logran que una interfaz reduzca la carga de memoria que recae
en el usuario:
Reducir la demanda de memoria a corto plazo. Cuando los usuarios participan en tareas complejas, la demanda de memoria a corto plazo se torna importante. La interfaz se debe disear para que reduzca la necesidad de recordar acciones y
resultados anteriores. Esto se logra al proporcionar pistas visuales que permitan al
usuario reconocer acciones anteriores sin tener que recordarlas.
Definir valores por defecto que tengan significado. El conjunto inicial de valores por defecto debe tener un sentido para el usuario promedio, pero tambin contar con la posibilidad de especificar sus preferencias. Sin embargo, debe disponer de
una opcin "restablecer" que le permita volver a definir los valores por defecto originales.
Definir accesos directos intuitivos. Cuando se emplea la mnemotcnica para

aplicar una funcin del sistema (por ejemplo, alt-1 para solicitar la funcin de imprimir), debe estar unida a una accin de manera tal que resulte fcil de recordar (como la primera letra de la tarea que se solicita)
El formato visual de la interfaz debe basarse en una metfora tomada de la
realidad. Por ejemplo, en un sistema de pago de facturas se debe utilizar la metfora de la chequera y el talonario de cheques para llevar al usuario a recorrer el proceso del pago de facturas. Esto permite que el usuario dependa de pistas visuales que
comprende bien, en lugar de memorizar una misteriosa secuencia de interacciones.
Desglosar la informacin de manera progresiva. La interfaz debe organizarse jerrquicamente. Es decir, la informacin sobre una tarea, un objeto o algn comportamiento debe presentarse primero en un grado alto de abstraccin. Despus de
que el usuario se interese por seleccionar algo con el ratn, deben presentarse ms
detalles. Un ejemplo comn en muchas aplicaciones de procesamiento de palabras
es la funcin de subrayado. se trata de una entre varias funciones ubicadas en el men estilo de texto. Sin embargo, no aparecen todas las posibilidades de subrayado. El
usuario debe seleccionar subrayado para que se presenten a continuacin todas las
opciones disponibles (como subrayado sencillo, doble, de guiones, etc.) .
354
PARTE DOS PRcnCA DE LA INGENIERA DEI. SOFiWARE
Jamie: ~ b i e n , ~ lo listo. lapida o

Vinocl: Eso est mejor. Por lo IMIIOl , . ~. .
recordar cosas que podemos dar4e.
Jamie (pensando por un 111....-): Pero a ti la

gusla el plano, i<) nM
Vinod:Aj.
Jomie: iCul crw. que le guabfa o ~ l i o f

Vinod: bts bromeando, t.dadt
Jamie:No.
Vmocl; Uh... el que tiene el flash ...
1m
funciones otroctivas en l o s ~-- ffllas no t.
intereso cul es ms fca de construir.
Jamie (suspirando): Ha,y hten, tal._ '-9 un
e'ICOnton
prototipo de ambos.
Vinod: Buena ideo... Juego . . ., . que el dienla
decido.
12.1.3 Lograr que la interfaz sea consistente

La interfaz debe adquirir y presentar la informacin de manera consistente. Esto
plica que J) toda la informacin visual est organizada de acuerdo con un ~

de diseo que se mantenga en todas las presentaciones de pantalla; 2) los mea::::
mos de entrada se restrinjan a un conjunto limitado que se utilice de manera c~
tente en toda la aplicacin, y 3) los mecanismos para ir de una tarea a otra se ..._
definido e implementado de manera consistente. Mandel [MAN97] define un celo de principios de diseo que ayudan a construir una interfaz consistente:
"los am que tienen aspectos diferentes debenaduar de manerad"ISlinta. las que tienen el mismo aspecto, .W.
arigual.
Permitir que el usuario incluya la tarea actual en un contexto que ten~

gn significado. Muchas interfaces implementan capas complejas de nter.:.
nes con docenas de imgenes en pantalla. Es importante proporcionar indica:.
por ejemplo, ttulos de ventana, iconos grficos, cdigos de color consistentes
CAPTULO 12
DISEO DE LA INTERFAZ DE USU>JUO
355
permitan al usuario conocer el contexto del trabajo que realiza. Adems, el usuario
debe tener la capacidad de determinar de dnde viene y cules son sus opciones para la transicin a una nueva tarea.
Mantener la consiste ncia en toda una familia de aplicaciones. Un conjunto

de aplicaciones (o productos) debe implementar las mismas reglas de diseo para
mantener la consistencia en todas las interacciones.
Si modelos interactivos anteriores han generado expectativas en el usuario,

no hacer cambios a menos que haya razones inexcusables. Una vez que una
secuencia interactiva se ha convertido en un estndar de facto (como el empleo de
alt-G para guardar un archivo), el usuario espera esto en todas las aplicaciones que
encuentre. Un cambio (como el uso de alt-G para solicitar la funcin cambiar de tamao) creara confusin.
Los principios del diseo de interfases expuestos aqu y en secciones anteriores
proporcionan una gua para un ingeniero de sotlware. En la siguiente seccin se examinar el proceso de diseo de la interfaz.
En un brillante ensayo sobre la facilidad de

uso, larry Constantine [CON95) plantea una
:nto que tiene una fuerte relacin con el tema: "Al
oe cuentas, qu quieren los usuarios?" Responde as:
cue los usuarios realmente quieren son buenas
ientas. Todos los sistemas de software, desde los
operativos y los lenguajes hasta la entrada de
las aplicaciones de apoyo a la toma de decisiones,
soio herramientas. Los usuarios finales esperan de las
-~ientas que construimos para ellos lo mismo que
~ esperamos de las herramientas que usamos.
sistemas fciles de aprender y que les ayuden a
su trabajo. Quieren software que no los detenga,
'ie o confunda, que no les lleve a cometer errores o
~ tculte la terminacin del trabajo".
Constantine argumenta que la facilidad de uso no se
,o de mecanismos de interaccin estticos o modernos,
ae nteligencia integrada en la interfaz. En cambio,
cuando la arquitectura de la interfaz corresponde a
riecesidades de las personas que la usarn.
l..>la definicin formal de facilidad de uso es elusiva.

ue y sus colegas [D0N99) la definen de la siguiente
a: "Facilidad de uso es una medida de la manera en
un sistema de cmputo... facilita el aprendizaje;
~ a quienes aprenden a recordar lo que han
=-endido; reduce la posibilidad de errares; les permite ser
~tes y los deja 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 trabajar con eficiencia?
los mecanismos de interaccin se vuelven ms flexibles
a medida 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
usuaria 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 toda la interfaz?
La interaccin anticipo errores y ayuda al usuario a
carreg irlos?
La interfaz tolero los errores que se cometen?
La interaccin es simple?
356
PARTE DOS
PRCTICA DE LA INGallERlA DEL SOF1WARE
Si se responde afirmativamente a cada una de estas

preguntas, es probable que se haya alcanzado la facilidad
de uso.
Entre los numerosos beneficios mensurables derivados de
un sistema con facilidad de uso se encuentran [DON99):
mayor 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 capocitacin y documentacin, adems de
menos pcobabilidades de que los usuarios insatisfechos
entablen demandas.
12,2
de~-
jf:!Jii:'1
Uno excelentl fuente
,dseno. illalfes de
ilSIJCllio se lUl1IIIII
en www.flllt.
ca.
El proceso general para analizar y disear una interfaz de usuario empieza cor _
creacin de diferentes modelos de funcin del sistema (como se percibe desde el ~
terior). Luego se delinean las tareas orientadas al ser humano y el equipo que se -:-quieren para lograr el funcionamiento del sistema; se toman en cuenta los temas diseo que se aplican a todos los diseos de interfaces; se emplean herramientas-::-
ra crear prototipos e implantar finalmente el modelo de diseo, y los usuarios ti.les evalan la calidad del resultado.
12.2.1 Modelos del anlisis y diseo de la interfaz

Cuando se analiza y disea una interfaz de usuario entran en juego cuatro rnode
diferentes. Un ingeniero humano (o el ingeniero del software) establece un moc
del usuario; el ingeniero del software crea un modelo del diseo; el usuario final ~
sarrolla una imagen mental que suele denominarse modelo mental del usuario o_
cepcin del sistema, y quienes implementan el sistema crean un modelo de la i ~
mentacin. Por desgracia, es posible que estos modelos difieran significativame::::
entre s. El papel del diseador de la interfaz es reconciliar estas diferencias y~
var una representacin consistente de la interfaz.
"Si hay..- usar algn 'truco', 111 interfaz de usuario no es consistente.
El modelo del usuario establece el perfil de los usuarios finales del sistema. F
Hosro un usuario
principiante quiere
accesos directos;
hastu los usuarios
espordicos ycon
conocimiento suelen
necesiror una guio.
Hoy que dorles lo que
necesitan.
construir una interfaz de usuario efectiva, "todo diseo debe empezar por la o..
prensin de quines son los usuarios de destino, incluidos sus perfiles de edad
xo, habilidades fisicas, educacin, antecedentes culturales o tnicos, motivada-objetivos y personalidad" [SCH90]. Adems, es posible distribuir a los usuarios er
siguientes categoras:
Principiantes. No tienen conocimientos de la sintaxis' del sistema
y cuentar
escasos conocimientos de la semntica de la aplicacin o del uso de la comput..

ra en general.
En este contexto, conocimiento de sintaxis 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 '.;::ciones que se realizan, el significado de entrada y salida, y las metas y los objetivos del sister
CAPTULO 12
357
DISEO DE LA INTERFAZ DE USUA.RlO
usuarios espordicos y con conocimientos.
Tienen conocimientos razonables de
semntica, pero muestran una retencin relativamente baja de la informacin sobre

sintaxis necesaria para utilizar la interfaz.
Usuarios frecuentes y con conocimientos.
Cuentan con conocimientos de sintaxis y
semntica suficientes para llegar al "sindrome del usuario avanzado" (es decir. individuos que buscan combinaciones de teclas y mtodos abreviados para interactuar).
Un modelo del diseo de todo el sistema incorpora datos. arquitectura, interfaz y
representaciones procedimentales del software. La especificacin de requisitos establece ciertas restricciones que ayudan a definir el usuario del sistema, pero el diseo de la interfaz slo suele ser incidental en relacin con el modelo del diseo. 3
El modelo mental del usuario (percepcin del sistema) es la imagen del sistema
que los usuarios finales llevan en la mente. Por ejemplo. si se pidiera al usuario de
un sistema determinado de diseo de pginas que describiera la operacin, la percepcin del sistema determinara la respuesta. La precisin de la descripcin depender del perfil del usuario (por ejemplo, los principiantes daran cuando mucho una
respuesta incompleta) y de la familiaridad general con el software en el dominio de
la aplicacin. Un usuario que comprenda por completo el diseo de pginas, pero
que haya trabajado con el sistema una sola vez en realidad podra proporcionar una
descripcin ms completa de su funcionamiento que el principiante que ha pasado
semanas tratando de aprender el sistema.
"CPJreste 11t8fK!1 olo que hocen los usuarios, no o loque dicen."

Jakoli Nlelsen
El modelo de la implementacin combina la manifestacin externa del sistema de

cmputo (la apariencia de la interfaz) y toda la informacin de ayuda (libros. manuales. videocintas, archivos de ayuda) que describe la sintaxis y semntica del sistema.
Cuando coinciden el modelo de la implementacin y el modelo mental del usuario,
los usuarios suelen sentirse a gusto con el software y lo usan con efectividad. Para
lograr esta "combinacin" de los modelos. el modelo del diseo debi desarrollarse
para incluir la informacin del modelo del usuario, y el modelo de implementacin
debe reflejar con exactitud la informacin sintctica y semntica de la interfaz.
Los modelos descritos en esta seccin son "abstracciones de Jo que el usuario est haciendo o lo que piensa que est haciendo o Jo que alguien ms piensa que debera estar haciendo cuando usa el sistema interactivo". [MON84]. En esencia, estos
modelos permiten que el diseador de la interfaz satisfaga un elemento clave del
principio ms importante del diseo de la interfaz de usuario: Conoce al usuario y sus
tareas.
3
Asi 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
358
PARTE DOS PRC11CA DE LA INGENIERA DEL SOF1WARE
12.2.2
El proceso
El proceso de anlisis y diseo de las interfaces de usuario es iterativo y se represe:

ta con un modelo espiral parecido al que se analiz en el captulo 3. Tomando c~
referencia la figura 12.1, se observar que el proceso de anlisis y diseo de la ir faz de usuario abarca cuatro actividades distintas de marco de trabajo [MAN97:
1. Anlisis y modelado de usuarios, tareas y entornos.

2. Diseo de la interfaz.
3. Construccin (implementacin) de la interfaz.
4. Validacin de la interfaz.
La espiral que se muestra en la figura 12.1 indica que cada una de estas tareas .::;
rrir ms de una vez, y cada pasada por la espiral representa la elaboracin ad. nal de los requisitos y el diseo resultante. En casi todos los casos, la activida.:.
construccin incluye la creacin de prototipos (la nica manera prctica de v~
lo que se ha diseado).
El anlisis de la interfaz se concentra en el perfil de los usuarios que interac
rn con el sistema. Se registrarn el grado de habilidad, la comprensin del tra!:
y la disposicin general ante el nuevo sistema; y se definirn diferentes categ..
de usuarios.
"Es mejat mseiiar la experiencia del usuario que rectificorlo.

.toa . . .
Una vez definidos los requisitos generales se realiza un anlisis ms detallac
las tareas. Se identifican, describen y elaboran las tareas que el usuario reali za ..
ifrPifl
El proceso de
diseo dela
interfaz de
usuario.
Validacin
de lo interfaz
Implementacin
Anlisis del usuario,

lo toreo y el entorno
CAPTULO 12
359
alcanzar los objetivos del sistema (sobre un nmero de pasadas iterativas por la espiral). El anlisis de tareas se expone de manera ms detallada en la seccin 12.3.
El anlisis del entorno del usuario se concentra en el ambiente fisico de trabajo.
Entre las preguntas que deben responderse estn las siguientes:
Dnde se localizar fisicamente la interfaz?
El usuario estar sentado, de pie o realizar otras tareas sin relacin con la
interfaz?
El hardware de la interfaz tiene restricciones de espacio o iluminacin. o lo
afecta el ruido?
Hay factores humanos especiales determinados por factores ambientales?
La informacin reunida como parte de la actividad de anlisis se utiliza para crear
un modelo del anlisis para la interfaz. Tomando este modelo como base, se inicia
la actividad de diseo.
El objetivo del diseo de la interfaz es definir un conjunto de objetos y acciones
(Y sus representaciones en pantalla) que permitan que el usuario realice todas las tareas definidas, de manera tal que cumplan todos los objetivos de facilidad de uso que
define el sistema. El diseo de la interfaz se estudia con mayor detalle en la seccin
12.4.
Por lo general, la actividad de construccin empieza al crear un prototipo que permita evaluar los escenarios de uso. A medida que contina el proceso de diseo iterativo, pueden usarse herramientas de desarrollo de la interfaz de usuario (consulte
el recuadro de la seccin 12.4) para completar la construccin de la interfaz.
La validacin se concentra en 1) la capacidad de la interfaz para implementar correctamente todas las tareas del usuario, acomodar todas las variaciones de las tareas y cumplir todos los requisitos generales del usuario; 2) la facilidad del uso y el
aprendizaje de la interfaz, y 3) la aceptacin por el usuario de que la interfaz es una
herramienta til para su trabajo.
Como ya se ha observado, las actividades descritas en esta seccin ocurren de
manera iterativa. Por tanto, es innecesario tratar de especificar cada detalle (para el
modelo de anlisis o de diseo) en el primer paso. Los siguientes pasos del proceso
dan lugar al detalle de la tarea, la informacin del diseo y las caractersticas operativas de la interfaz.
4
Un principio clave de todos los modelos de procesos de ingeniera del software reza: es mejor comprender el problema antes de tratar de disear una solucin. En el ca4
Resulta razonable argumentar que esta seccin debi colocarse en el captulo 8, porque ali! se estudia 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.
360
PARTE DOS
PRCTICA DE LA INGENID'lA DEL SOFTWARE
so del diseo de la interfaz de usuario, comprender el problema significa comp,~

der 1) a las personas (los usuarios finales) que interactuarn con el sistema por :-!'
dio de la interfaz; 2) las tareas que los usuarios finales deben realizar para hace
trabajo; 3) el contenido que se presenta como parte de la interfaz, y 4) el entorne
que se realizarn estas tareas. En las secciones siguientes se examinar cada un"
estos elementos del anlisis de la interfaz con el fin de establecer una base s...
para el diseo de las tareas que siguen.
12.3. l
Cmo s lo
que los
usuarios quieren
de la interfaz?
tcONSU09'
Solxe todo, dedq,ese
tiempo abotu can
los IJS1JOIOS reales,

pero debe hacerse Cllll
cuidado. Uoo qj,
fuefte no necesatt
mente sign& ~ h
fOO'YOOO de las
USOOlOS est de
ocueroo.
Anlisis del usuario
Ya se ha indicado que cada usuario tiene una imagen mental del software (o perce
cin del sistema) que podra ser diferente de la imagen mental de otros. Adems
probable que la imagen mental del usuario sea muy diferente del modelo del d
que tiene el ingeniero. El diseador slo lograra que coincidan la imagen me:-'"
el modelo del diseo si trabaja para comprender a los propios usuarios, ademzs
la manera en que ellos usarn el sistema. Es posible usar informacin de una
variedad de fuentes disponible para lograr esto:
Entrevistas con el usuario. Es el enfoque ms directo. Representantes de

pode software se entrevistan con usuarios finales para comprender mejor sus
sidades, motivaciones, cultura de trabajo y gran cantidad de temas adicional~
to se logra mediante reuniones personales o con grupos de enfoque.
Informacin de ventas. El personal de ventas se rene con clientes y ~
de manera regular y obtiene informacin que ayudar al equipo de software a
ficar a los usuarios en categoras y a comprender mejor sus necesidades.
Informacin de mercadotecnia. El anlisis de mercado es invaluable en -1
mcin de los segmentos del mercado, al tiempo que proporciona una comprens:
la manera en que cada segmento usara el software de manera sutilmente difere::::
Informacin proveniente de soporte. El personal de soporte habla a
con los clientes. Esto los convierte en la fuente de informacin ms probable
lo que funciona y lo que no, lo que le gusta a los usuarios y lo que les disgusa
caractersticas que generan dudas y las que resultan fciles de usar.
El siguiente grupo de preguntas (adaptado de [HAC98] ayudar al disead
interfaz a comprender mejor a los usuarios de un sistema.
Los usuarios son profesionales capacitados, tcnicos, trabajadores de
u obreros?
Qu grado de educacin formal tiene el usuario promedio?
Los usuarios son capaces de aprender con materiales escritos o expres.-:::=
Cmo aprendemos
sobre lo demogrofio y
los coroctersticos de
los usuoos fino les?
su deseo de recibir capacitacin en el lugar?

Los usuarios son expertos para tipear o le tienen fobia al teclado?
Cul es la edad promedio de la comunidad de usuarios?
361
Los usuarios corresponden predominantemente a algn gnero?

Qu compensacin reciben los usuarios por su trabajo?
Los usuarios trabajan en horas normales de oficina, o siguen sus labores
hasta que hayan terminado lo que estn haciendo?
El software ser una parte integral del trabajo de los usuarios, o se emplear
ocasionalmente?
Cul es el idioma materno de los usuarios?
Cules seran las consecuencias si un usuario comete 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 respuestas a stas y otras preguntas similares permitirn que el diseador comprenda quines son los usuarios finales, qu los motiva y complace, cmo se agruparan en diferentes clases o perfiles de usuarios, cules son sus modelos mentales
del sistema, y cmo debe caracterizarse la interfaz de usuario para que satisfaga sus
necesidades.
12.3.2 Anlisis y modelado de tareas

El objetivo del anlisis de la tarea es responder las siguientes preguntas:
Qu trabajo 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 estas preguntas, el ingeniero de software debe basarse en las tcnicas de anlisis expuestas en los captulos 7 y 8; pero en este caso las tcnicas se aplican 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 alguna tarea especfica relacionada con el trabajo. Casi siempre, el caso de uso se escribe de manera informal {un solo prrafo) en primera persona. Por ejemplo, supngase que una pequea empresa de software quiere construir un sistema de diseo
asistido por computadora explcitamente para diseadores de interiores. Para comprender mejor cmo hacen su trabajo, se pide a diseadores de interiores reales que
describan funciones especficas del diseo. Cuando se les pregunta: "cmo decide
362
PARTE DOS PRCTICA DE LA INGENIERA DEL SOl'TWARE
el lugar en que colocar un mueble en una habitacin?", un diseador de intern

escribe el siguiente caso de uso informal:
Empiezo haciendo un borrador del plano de la habitacin, las dimensiones y la posicm
de las ventanas y puertas. Me preocupo por la manera en que entra la luz, por la vista ~
se tiene a travs de las ventanas (si es hermosa, me gustarla llamar la atencin hacia el.a
por el espacio que las paredes no tapan, por el flujo del movimiento en la habitacin. Luego observo la lista de muebles que mi cliente y yo hemos elegido (mesas, sillas, sillon~
vitrinas) y la lista de accesorios (lmparas. alfombras, cuadros, esculturas, plantas, pequ.eas piezas), y tambin observo mis notas sobre la manera en que mi diente desea que ~
distribuyan. Luego dibujo cada elemento de mis listas empleando una plantilla que se ta
dibujado a escala con el plano. Etiqueto cada elemento y uso lpiz porque siempre muevo 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.
Este caso de uso proporciona una descripcin elemental de una tarea de traba';.
portante para el sistema de diseo asistido por computadora. A partir de l, el
niero de software extraer tareas y objetos, adems del flujo general de la inte"ii:.
cin. Adems. tambin es posible concebir otras caractersticas del sistema
agradaran al diseador de interiores. Por ejemplo, podrian tomarse fotografias
tales del panorama de cada ventana. As, cuando se haga una representacir df
imagen de la habitacin se mostrara la vista real en cada ventana.
HOGARSEGURO
Vinod: Eso est bten. Es uno de los principal.

comportamientos de la interfaz de lo funcloo de
vigilancia. Pero lendremos qU4t examit\CII' lo(nbj6n el
comportomienlo clel administrodor del $lsflel:pa.
Jamie (irritada): T""1e$ rozn.
(Jamie solea buscar a ki penona de men:adotecnia.
Regreso unos- boros- m6s torde.J
Jamie: TIJ're suerte. Encontr a n ~ contoc:to de
mef"cadotecnia y traboj<JITl05 juntos el coso del
adminis!rodoc Bsicamente, definiremo5
' administracin' como una fuocln apliCQble Q fodm
funciones de Hogo,Seguro. He aqui lo que hicimos.
(Jamie ~ a Vinod el coso de uso inbmol.l
Aoque hiot fue que merc:odotecnio representara

pq,iebio que quiere ver un video.
cl.
Caso ele uso informal: Quiero l o ~ de

configurar o editor el formoto del sislamcl en uolqui.r
momento. Cuando configure el sistema sefec:cioncri la
funcin de adminstrocin. Me pregunta si quiel'O definir
una nueva configuracin. ~ afirmativamente.
CAPiTULO 12
363
de$pliego una pQllllla de dlbuo que me permite

el plono de lo c:ds(I en una cuadrcula. Habr
para paredes, ventanas y puertos que me
el dibujo. Solamente estiro los iconos poro que
la dimensin comida. El sistema qespleg<,r los
en pifls o melrol (pedo selec;cionQr el sistema
-.*i'~). Tengo la opcin de '$elecdooar se~res y
de UflO bibtlOtc:a y de ubicarlos en el plano.

poner una leyendo o cado uno, pero el si~emo
lo puede hoce,- ovtomticamente. Tungo le
de c:Wlnir los parmetros de sensorei y
mediante mens espt1Ciale$. Si fflecciono litor,
mover los sensores o 10$ 6maras, agregor nuevos
editor
o eliminar los que ya existen,

el pk;ino d lo cosa y
los valores de cmaras y sensores. En t<x:los los COSQS,
espero que el sistemo tengo consi~tricio y me ciyuc:I.! o
no cometer errores.
Vinod (despus de leer .i guin); Mvy bien. Tol
vez haya algunos patrones d diseo tiles o algunos
componentes reutilizables ~ podamos vaor en len
interfaces grficos de usuario tom~ de <dgn
progromg de di.wo, Te a~to lci comido o qw, IO$
usamos, podemos implementor par1e de fo interfaz i:W
c;idministr(Jcior, o
casi to.dd ello.
Jamie: Esly de a<:uerdo, djame revisarlo.
Elaboracin de la tarea. En el captulo 9, se analiz la elaboracin paso a paso (tambin denominada descomposicin funcional o refinamiento paso a paso) como
mecanismo para refinar las tareas de procesamiento requeridas para que el software realice alguna funcin deseada. El anlisis de la tarea para el diseo de la interfaz 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 manual o semiautomtica. Con el fin de comprender las tareas indispensables para alcanzar el objetivo de la actividad, un ingeniero humano5 debe comprender las tareas
que las personas realizan actualmente (al usar un mtodo manual) y luego relacionarlas con un conjunto similar (pero no necesariamente idntico) de tareas que se
implementan en el contexto de la interfaz de usuario. Como opcin, el ingeniero humano puede estudiar una especificacin existente para una solucin computarizada
y derivar un conjunto 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 software pretende construir un sistema de diseo asistido por computadora explcitamente 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 materiales, seleccin de tapices para paredes y cortinas para ventanas, presentacin (para el cliente), presupuesto y compras. Cada una de estas importantes tareas pueden
desglosarse en subtareas, Por ejemplo, de acuerdo con la informacin contenida en
5
En muchos casos, un ingeniero de software realiza las tareas descntas en esta seccin. Lo ideal es
que esta persona tenga capacitacin en ingeniera hwnana y en diseo de interfaces de usuario.
PARTE DOS
PRAcnCA DE LA INGNIERlA OO. SOfiWARE
el caso de uso, la distrtbucin del mobiliano se refinara de las siguientes tareas 1)

bujar un plano de la casa tomando como base las dimensiones de la habitacic.n _
ubicar las ventanas y puertas en los lugares adecuados; 3a) usar las plantil ...s
Aunque lo elaboracin
del c4sto seo tH, oo
debs usarse como un

enfoque~
diente. Lo voz del
usuorio debe tomarse
en cuento durante el
anlisis de la mrea.
muebles para dibujar contornos a escala en el plano; 3b) usar las plantillas de c1
sorios para dibujarlos a escala en el plano; 4) mover los contornos de los muebles
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 vtsa
dimensinal en perspectiva para el cliente. Un enfoque similar se usara para
una de las otras tareas importantes.
Es posible refinar an ms de la subtareas I a 7 De la I a la 6 se realizarn ~
nipular la informacin y ejecutar acciones dentro de la interfaz de usuario. Por
parte, el software tiene la capacidad de realizar automticamente la subtarea que representarta poca interaccin directa del usuario.6 El modelo del dise d!:
interfaz debe acomodar cada una de esas tareas para que sea consistente con d
delo del usuario (el perfil de un diseador de interiores "tpico") y la percepc
sistema (lo que el diseador de interiores espera de un sistema automatizado
Elaboracin del objeto. En lugar de concentrarse en las tareas que un

debe realizar, el ingeniero de software examina el caso de uso y otra informac'
tenida del usuario y obtiene los objetos fisicos que usa el diseador de interiores.
tos objetos pueden ordenarse en clases. Los atnbutos de cada clase y una e
cin de las acciones aplicadas a cada objeto proporcionan al diseador una .._
operaciones. Por ejemplo la plantilla de muebles se traduce en una clase 1
Mueble con atributos que podran incluir tamao. fonna, ubicacin y otras. El e
dor de mtenores seleccionarla el objeto de la clase Mueble, lo movera a una
en el plano (otro objeto en el contexto), dibujara el contorno de los muebles, c.
tareas selecaonar, mover y dibuar son operaciones. El modelo del anlisis d
terfaz de usuario no proporcionarla una implementacin para cada una d..
operaciones. Sin embargo a medida que se elabore el diseo se definirian los
!les de cada operacin.
Anlisis del flujo de trabajo. cuando distintos usuarios, cada uno repr~
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 del
trabajo. Esta tcnica permite que un ingeniero de software comprenda cmo
liza un proceso de trabajo cuando se involucran varias personas (y papeles
en una compaa que pretende automatizar el proceso de prescribir y envia
camentos que se venden con receta. Todo el proceso 7 girar alrededor de u-a
6 Sm embargo, tal vez ste no sea el caso. Es probable que el diseador de interiores quiera
car la perspectiva del dibujo, el tamao o el uso del color y otra informac16n. El caso de
cionado con las representaoones de dibuos en perspectiva proporcionarla la informad
necesita atender en esta tarea.
7 Este ejemplo se ha adaptado de [HAC98) .
CAPTULO 12 DISEO DE LA CNTERFAZ DE USUARIO
365
cacin Web disponible para mdicos (o sus asistentes), farmacuticos y pacientes. El

flujo de trabajo se representa de manera efectiva con un diagrama de lnea de flotacin 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 presenta 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 eventos (mostrados en la figura) permite que el diseador de la interfaz reconozca tres caractersticas clave:
l. Cada usuario implementa diferentes tareas con la interfaz; por tanto, el concepto 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 secundarias (como acceso a inventarios de farmacia y
a la informacin acerca de medicamentos alternos por parte del mdico), adems de desplegar esta informacin.
3. Es posible elaborar an ms muchas actividades indicadas en el diagrama de
lnea de flotacin mediante anlisis de la tarea, elaboracin de objetos, o ambas 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).
Representacin jerrquica. Cuando se analiza una interfaz ocurre un proceso

de elaboracin. Una vez establecido el flujo de trabajo se define una jerarqua de tarea para cada tipo de usuario. La jerarqua se deriva de una elaboracin paso a paso de cada tarea que el usuario haya identificado. Por ejemplo, pinsese en la tarea
de usuario solicitar que se resurta una receta. Se desarrolla la siguiente jerarqua de
tareas:
Solicitar que se resurta una receta

Proporcionar informacin de identificacin
Especificar nombre
- Especificar identidad de usuario
Especificar NIP y contrasea
Especificar nmero de receta
Especificarfecha en que se requiere el resurtido
Completar la tarea solicitar que se resurta una receta requiere definir tres subtareas.
Una de ellas, proporcionar informacin de identificacin incluye tres subtareas adicionales.
366
PARTE DOS
PRCTICA DE LA INGENlERiA DEI. SOFTWARE
Diagrama de linea de flotacin para la funcin de resurtido de recetas.
Farmacutico
Paciente
Solicila que se
Mdico
Delemtlno
resurto uno recela
eslatus de lo recela
Se rev$0 expediente
del paciente
Resurtidos
restantes
Se apruebo
resurtido
Reviso el inventario poro
Nose
permite resurtido
resurtido u otra opcin
Recibe notificacin
hoy existencias
Se evalo
meckocin alterna
Sin existencias
de que no
Alternativa
En existencia
Recibe fecho/hora
poro recoger
N inguno
Recoge
Se
el medicamento
re$Urte receto
@
Recibe soli<:itud
de 1r al mdico
disponible
CAPTULO 12
367
"Es mucho mejor odaptor lo tecnologa ol usuario que obligar a ste a adoptarse a lo tecnologa.
larry._
12.3.3 Anlisis del contenido de la pantalla
Las tareas del usuario identificadas en la seccin anterior llevan a la presentacin de
diferentes tipos de contenido. En el caso de aplicaciones modernas, el contenido de la
pantalla va de informes basados en caracteres (por ejemplo, hojas de clculo), pantallas grficas (por ejemplo, un histograma, un modelo 3-D, la fotografa de una persona) o informacin especializada (como archivos de audio o video). Las tcnicas
de modelado del anlisis estudiadas en el captulo 8 identifican los objetos de datos de
salida que produce una aplicacin. Estos objetos de datos son: 1) generados por componentes (no relacionados con la interfaz) en otras partes de la aplicacin; 2) adquiridas de los datos almacenados en una base de datos a la que se tiene acceso desde la
aplicacin, o 3) transmitida de sistemas externos a la aplicacin en cuestin.
En este paso del anlisis de la interfaz se consideran el formato y la esttica del
contenido (tal como se despliega en la interfaz). Entre las preguntas que se habrn
de plantear se encuentran las siguientes:
Hay diferentes tipos de datos asignados a ubicaciones consistentes en la
pantalla (por ejemplo, las fotos siempre aparecen en la esquina superior derecha de la pantalla)?
El usuario puede personalizar la distribucin del contenido en la pantalla?
Se ha asignado una apropiada identificacin en pantalla a todo el contenido?
Cmo se segmenta un informe largo para facilitar su comprensin?
Habr mecanismos disponibles para desplazar directamente al resumen de
informacin en conjuntos grandes de datos?
Se cambiar el tamao de la salida grfica para que quepa dentro de los lmites de la pantalla o el monitor que habr de usarse?
Cmo se usar el color para mejorar la comprensin?
Cmo se presentarn al usuario los mensajes de error y los avisos de precaucin?
A medida que se responden estas (y otras) preguntas se establecern los requisitos
para la presentacin del contenido.
12.3.4 Anlisis del entorno de trabajo

Hackos y Redish [HAC98] analizan la importancia del anlisis del entorno de trabajo cuando afirman:
La gente no trabaja aislada; la afectan la actividad que se realiza a su alrededo r, las carac-
tersticas fsicas del lugar de trabajo, el tipo de equipo que emplea y sus relaciones de trabajo con los dems. Si los productos que se disean no se amoldan al entorno, es posible
que su uso resulte dificil o frustrante.
368
PARTE DOS
En algunas aplicaciones la interfaz de usuario para un sistema de cmputo se c_

ca en un "lugar amigable para el usuario" (por ejemplo, iluminacin apropiada, t,-_
na altura de la pantalla. fcil acceso al teclado), pero en otros (como el piso de fbrica o la cabina de un avin). la iluminacin es deficiente, el ruido es importaun teclado o un ratn no son una opcin, la colocacin del monitor es menos
ideal. A1 diseador de la interfaz lo limitarn factores que atentan contra la faci
de uso.
Adems de los factores del entorno fsico, la cultura del lugar de trabajo tam
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 corr
tir informacin antes de que se proporcione una entrada? Cmo se dar sope
los usuarios del sistema? Es necesario responder stas y muchas otras preguntas
lacionadas antes de iniciar el diseo de la interfaz.
Una vez finalizado el anlisis de la interfaz, se han identificado con detalle todas
tareas (objetos o acciones) que requiere el usuario final, y comenzar la activida:!
diseo de la interfaz. Esta etapa, como todo el diseo de la ingeniera del so.
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 a:
res.
Aunque se han propuesto muchos modelos diferentes para el diseo de la
faz de usuario (por ejemplo, [NOR86J, [NIEOOJ), todos sugieren alguna comb
de los siguientes pasos:
1. Con base en la informacin desarrollada durante el anlisis de la infonr
{seccin J 2.3), definir los objetos y las acciones de la interfaz (operad .

2. Definir eventos (acciones del usuario) que cambiarn el estado de la in.
Modelar este comportamiento.

3. Representar cada estado de la interfaz tal como lo ver el usuario fina.
4. Indicar cmo interpreta el usuario el estado del sistema a partir de la in

proporcionada mediante la interfaz.
En algunos casos, el diseador de la interfaz puede empezar con borradores
da estado de la interfaz (es decir, el aspecto de la interfaz en distintas circu ~:...-111111111
y luego trabajar hacia atrs para definir objetos, acciones y otra informacir
tante para el diseo. Independientemente de la secuencia de las tareas de
ste debe 1) seguir siempre las reglas de oro analizadas en la seccin 12.1 , ~
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 herrami
desarrollo) en que habr de usarse.
CAPTULO 12
369
"El diseo interac!ivo[es) una mezcla integrado de ortes grficas, tecnologa y psicologa.n
12.4.1
Aplicacin de los pasos del diseo de la interfaz
Un paso importante en el diseo de la interfaz es la definicin de los objetos que sta tendr y las acciones que se les aplicarn. Para realizarlo se analizan los casos de
uso de manera muy parecida a la descrita en el captulo 8. Es decir, se escribe una
descripcin de un caso de uso. Luego se aslan los nombres (objetos) y los verbos
(acciones) para crear una lista de objetos y acciones.
Una vez definidos los objetos y las acciones, que se han elaborado de manera iterativa, se organizan por tipo. Se identifican objetos de destino. origen y aplicacin.
Un objeto de origen (como el icono de un informe) se arrastra y coloca en un objeto
de destino (por ejemplo, un icono de impresora). La implicacin de esta accin es
crear un informe impreso. Un objeto de aplicacin representa datos especficos de la
aplicacin que no se manipulan directamente como parte de la interaccin con la pantalla. Por ejemplo, en una lista de correo se almacenan nombres para un envio de
correspondencia. La propia lista podra ordenarse, combinarse o purgarse (acciones
de men), pero no arrastrarse ni colocarse mediante interaccin del usuario.
Una vez que el diseador queda satisfecho con un objeto importante y que se han
definido las acciones (para una iteracin de diseo) se realiza el formato de la pan talla. Como otras actividades de diseo de la interfaz. el formato de la pantalla es un
proceso interactivo; en l se elabora el diseo grfico y se colocan los iconos, la definicin de texto descriptivo en pantalla. la especificacin y la asignacin de nombres a las ventanas. adems de la definicin de los elementos primarios y secundarios de los mens. Si una metfora de la realidad es apropiada para la aplicacin, se
especifica en este momento, y el diseo se organiza de manera tal que satisfaga la
metfora.
Un breve ejemplo de los pasos del diseo indicados anteriormente se obtiene
imaginando el contexto en que se sita un usuario del sistema HogarSeguro analizado en captulos anteriores. A continuacin se presenta un caso de estudio preliminar (escrito por el propietario) para la interfaz.
Caso de uso preliminar. Quiero tener acceso a mi sistema Hogarseguro desde cualquier
lugar remoto va Internet. Empleando software de navegador que opera en mi notebook
(men tras estoy trabajando o viajando) puedo determinar el estado del sistema de alarmas,
armar o desarmar el sistema, reconfigurar zonas de seguridad y ver diferentes habitaciones 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
370
PARTE DOS PRCTICA DE LA INGENIERA DEL SOF'IWARE

seguridad, desplegar cada zona configurada actualmente y modificar zonas de acuerd...
con las necesidades. Puedo ver el interior de la casa con las cmaras de video coloca~
de manera estratgica. Puedo hacer acercamientos y desplazamientos con las cm~
para proporcionar diferentes vistas del interior.
Con base en este caso de uso se identifican las tareas del propietario, los objel s
los elementos siguientes:
tiene acceso al sistema HogarSeguro

ingresa un ID y una contrasea para acceso remoto
revisa el estatus del sistema
arma o desarma el sistema HogarSeguro
despliega el plano de la casa y las ubicaciones de los sensores
despliega zonas en el plano de la casa
cambia zonas en el plano de la casa
despliega ubicaciones de las cmaras de video o el plano de la casa
selecciona visualmente una cmara de video
ve imgenes de video
desplaza o acerca las cmaras de video
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, ubicacin de las cmaras de video (un objeto de origen
SE
tra y coloca en cmara de video (un objeto de destino) para crear una imagm:
video (una ventana que contiene el despliegue de video).
t<oNsuoS.
Aunque las
herramientas
outomaNzados son
hles en el desarrollo
de protohpos de
Formato, en ocasiones
todo lo que se
necesito es lpiz y
pope/.
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,
e, localizado en el plano de la casa desplegad:
ventana de monitoreo. En este caso se arrastra la ubicacin de una cmara~

en la sala, SA, y se coloca sobre el icono de cmara de video ubicado en la pe:
perior izquierda de la pantalla. Aparecer la ventana de imagen de video, d.___ --
do video de lujo continuo proveniente de la cmara ubicada en la sala (SA
troles deslizables de acercamiento y desplazamiento se emplean para con::

ampliacin y la direccin de la imagen del video. Para seleccionar una vista
cmara, el usuario simplemente arrastra y coloca un icono de ubicacin Je
8 Considrese que esto difiere de la implementacin de estas caractersticas en cap1tuJos

Esto podra considerarse un borrador del primer diseo y representa una opcin digna
en cuenta.
CAPTULO 12
371
,-Ac~s; Configurar
Sistema
Estatus Ver Supervisor
Hogar$eguro
Conector
Cmoro dt v.~
SA
Ci
Prime! piso
S ~SQr~Vt!l/tana
O Ot,~lor ~ mavimiefllc /ro;,,:> 111()S/radaj
C' IJbkf6.a de ,;Mk1ta 4B !lfdJ;o
Acercar DI 11, 11
zoom
/ H11111 Dezplozor
1111111 lll(A/eor
11 HI III U
diferente en el icono de la cmara emplazado en la esquina superior izquierda de la

pantalla.
El boceto del formato que se muestra tendra que complementarse con una expansin de cada elemento 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 bocetos para cada 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 surgido una amplia variedad de patrones de diseo de interfaces de usuario. Como se
observ al principio de este libro, un patrn de diseo es una abstraccin que prescribe una solucin de diseo a un problema de diseo especfico, bien delimitado.
Cada uno de los patrones de ejemplo (y todos los patrones de cada categora) presentados en el recuadro siguiente tambin tendra un diseo completo al nivel de
componentes, incluidos clases, atributos, operaciones e interfaces de diseo.
Un anlisis completo de los patrones de interfaz de usuario est ms all del alcance de este libro. El lector interesado debe consultar [DUY02]. [BORO 1], [WELO I Jy
[TID02] para conocer ms informacin.
372
PARTE DOS
PRcnCA DE LA INGOm:RA DEL S0f1WARE
Patrones de interfaz de usuario

En las ltimos dcados se han propuesto cientos de patrones de interfaz de usuario. lidwell
[TID02J y Van Welie [WELOl J proporcionan taxonomos9
de los patrones de diseo de interfaz de usuario que se
han organizado en l O colegoros. En este recuadro se presentan patrones de ejemplo de codo uno de estos categoras.
Interfaz de usuario completo. Proporciono lineas

generales de diseo poro estructuro y navegacin de alto
nivel.
Patrn: navegacin de olio nivel
Descripcin breve: Proporciono un men de ollo nivel,
o menudo acoplado o un logotipo o uno imagen de
identificacin que permite lo novegoc16n directa o cualquiera de los principales funciones del sisiiemo
Diseo de pgina. Atiende la organizacin general
de las pginos (poro sitios Web) o distintos despliegues de
pontollo (poro aplicaciones interodivos)
Patrn: pilo de corlas
Descripcin breve: Proporciono el aspecto de uno pilo
de cortos con pestaas; poro seleccionarlas se hoce die
en cado uno de ellas, que represento subfunciones especficos o categoras de contenido.
Formularios y entrada. Tomo en cuento diversos
tcnicos de diseo poro completar entrados al nivel de formularios.
Patrn: //ene los espacios en blanco
Descripcin breve: Permite el ingreso de datos alfanumricos en un "cuadro de texto".
Tablas. Proporciono guo de diseo poro la creacin y
manipulacin de todo tipo de datos tabulares.
Patrn: tabla que permite su ordenocin
Descripcin breve: Despliego uno largo listo de registros que se ordenan al seleccionar un mecanismo interruptor poro cualquier etiqueto de la columna.
Manipulacin directo de datos. Atiende lo edi
cin, modificacin y transformacin de datos.
Patrn: migas de pon
Descripcin breve: Proporciono uno ruto completo oe

navegacin cuando el usuario est trabajando con une
jerorquo completo de p6ginos o pontollos de despl~
Navegacin. Ayudo a l usuario en el recorrido de ns jerrquicos, pginas Web y pontollo de despliegue
teroctivo.
Patrn: edicin en el lugar
Descripcin breve: Proporciono lo copocidod de ~
cin simple de textos poro ciertos tipos de contenl:
el lugar en que se despliego.
Bsqueda. Permite bsquedas de contenido espec::&::,

mediante lo informacin mantenido en un sitio Web o c:r
tenido en almacenes persistentes de datos que eston ocr
sibles poro uno aplicacin interactivo.
Patrn: bsqvedo simple
Descripcin breve: Proporciono la capacidad de ba.-cor, en un sitio Web o uno fuente de datos pers,
un elemento simple de datos descrito por uno cada:c
al Fo numrico.
Elementos de pgina Implemento elementos
cos de un p6gino Web o pontolla de de$pliegue
Patrn: osislenle
Descripcin breve: Uevo al usuario poso o poso pt:r
uno toreo complejo, proporcionando guas poro
pletor la toreo mediante uno serie de ventanos
Comercio electrnico Especficos de sitios ~
patrones implementan elementos recurrentes de Ql:lltic:ca::
nes de comercio electrnico.
Patrn: camio de compras
Descripcin breve: Proporciono uno listo de e1e121:1:a
seleccionoclas en uno compro.
Varios Patrones que no caben fcilmente en len
ros onleriores. En algunos cosos, estos patrones dll:e
del dominio u ocurren poro doses especficos de
Patrn: indicador de programo
Descripcin breve: Proporciono uno indicooon
greso cuonclo se esl ~!izando uno operoa,:
12.4 .3 Temas de diseo

A medida que evoluciona el diseo de una interfaz casi siempre surgen cu.nrcomunes: tiempo de respuesta del sistema, funciones de ayuda para el
nejo de informacin de error y rotulado de comandos Por desgracia, mu
9
En (TID02J y [WELOI J se encontrarn descripciones de patrones completos (junto
otros patrones)
c~d:::::lalll
CAPTULO 12
373
adores no prestan atencin a estos temas hasta una etapa relativamente tarda del
proceso de diseo (en ocasiones el primer atisbo de un problema se presenta hasta
que se dispone de un prototipo operacional). como resultado, a veces se tiene iteracin innecesaria, demoras del proyecto y frustracin del cliente. Es mucho mejor
abordar cada uno como elemento de diseo y tomarlo en cuenta al principio del diseo de software, cuando los cambios son fciles y el costo es bajo.
un error comn que comete lo gente cuando trota de d~eor oigo a pruebo de tontos es subestimar la ingenuidad de
los verdaderamente tontos."
Doagla, Adams,
<;_.
nempo de respuesta. El tiempo de respuesta del sistema es la primera queja sobre muchas aplicaciones interactivas. En general, se mide desde el punto en que el
usuario realiza alguna accin de control (como oprimir la tecla Retum o hacer clic
con el ratn) hasta que el software responde con la salida o la accin deseada.
El tiempo de respuesta del sistema tiene dos caracteristicas importantes:

duracin y variabilidad. Si la respuesta del sistema se demora mucho, la frustracin y el estrs del usuario son inevitables. Variabilidad es la desviacin del tiempo
de respuesta promedio y, en muchos sentidos, es la caracteristica ms importante
del tiempo de respuesta. Una baja variabilidad permite que el usuario establezca un
ritmo de interaccin, aunque el tiempo de respuesta sea relativamente largo. Por
ejemplo, una respuesta de 1 segundo a un comando a menudo ser preferible a una
respuesta que vara de 0.1 a 2.5 segundos. cuando la variabilidad es significativa, el
usuario siempre se encontrar fuera de balance, siempre se pregur.tar si ha ocurrido algo "diferente" tras bastidores.
Funciones de ayuda. Casi todos los usuarios de un sistema de cmputo interactivo necesitan ayuda de vez en cuando. En algunos casos, basta con una simple pregunta dirigida a un colega con experiencia. En otros, tal vez la nica opcin sea una
investigacin detallada en un conjunto de varios volmenes de "manuales de usuario". Sin embargo, en casi todos los casos el software moderno proporciona funciones de ayuda en lnea que permiten al usuario obtener una respuesta a sus preguntas o resolver un problema sin dejar la interfaz.
Deben atenderse varios temas de diseo [RUB88] cuando se toma en cuenta una
opcin de ayuda.
La ayuda estar disponible para todas las funciones del sistema y en todo
momento durante la interaccin con ste? Entre las opciones se incluye ayuda
slo para un subconjunto de todas las funciones y acciones o ayuda para todas las funciones.
Cmo necesitar la ayuda el usuario? Entre las opciones se incluyen men
de ayuda, una tecla especial de funcin o un comando AYUDA.
374
PARTE DOS
PRCTICA DE LA INGENIERA DEL SOM'WARE
Cmo se representar la ayuda? Las opciones son una ventana separada,

una referencia a un documento impreso (menos que ideal) o una sugerencia
de una o dos lneas que aparece en un lugar fijo de la pantalla.
Cmo regresar el usuario a la interaccin normal? Entre las opciones se ."'cluyen un botn de regreso desplegado en la pantalla, una tecla de funcin ~
una secuencia de control.
Cmo se estructurar la informacin de ayuda? Las opciones son una estr...:
tura "plana" en que se tiene acceso a toda la informacin con el teclado, ll!'.21
jerarqua en capas de informacin que proporciona detalles crecientes a medida que el usuario la recorre, o el uso de hipertexto.
Manejo de errores. Los mensajes de error y los avisos de precaucin son rr."
noticias" que se entregan a los usuarios de sistemas interactivos cuando algo sale -En el peor de los casos, los mensajes de error y los avisos de precaucin ofrece
formacin intil o que puede malinterpretarse y que slo sirve para aumentar la
tracin del usuario. Algunos usuarios de computadora han encontrado un emx ~
forma "La aplicadn XXX se ha vistoforzada a cerrarse porque se ha encontrado u;del tipo 1023". En algn lugar debe existir una explicacin del error l 023; de lo ce
rio, por qu habran asignado los diseadores ese identificador? Sin emba.7
mensaje de error no proporciona una indicacin real de lo que estuvo mal ni
de buscar la informacin adicional. Un mensaje de error presentado de esta r-:
no hace nada por aliviar la ansiedad del usuario ni ayuda a corregir el probleir:.
oc
1.a illterfaz con el infierno: 'Para corregir este error yseguir adelante, e5Crlbo cualquier nmero prilllO de 11
tos. .."
En general, todo mensaje de error o aviso de precaucin que produzca tr

ma interactivo debe tener las sguentes caractersticas:
Qu
caractersticas
debe tener un
Nbuen mensaje
de error?
El mensaje debe describir el problema en un lenguaje que el usuario e El mensaje debe proporcionar consejos constructivos sobre la manera ~
cuperarse del error.
El mensaje debe indicar cualquier consecuencia negativa del error (por e:
la posibilidad de que se corrompan los archivos de datos) para que el u.sz:::::
asegure que no han ocurrido (o para que los corrija si ya ocurrieron).
El mensaje debe acompaase de una pista visual o auditiva. Es decir .::.
nerarse un bp junto con el despliegue del mensaje, o ste debe parpa..
momentneamente o desplegarse en un color que se reconozca fci!=
como "color de error".
El mensaje no debe contener juicios. Es decir, la redaccin nunca debe

al usuario.
CAPTULO 12
D!SEO DE LA INTERFAZ DE USUARIO
375
Como a nadie le gustan las malas noticias, a pocos usuarios le gustarn los mensajes de error, sin importar lo bien diseados que estn. Pero un enfoque adecuado para los mensajes de error har mucho por mejorar la calidad de un sistema interactivo y reducir de manera importante la frustracin del usuario cuando ocurran los
problemas.
Rotulacin de mens y comandos. El comando de texto escrito fue alguna vez

el modo ms comn de interaccin entre los usuarios y el software del sistema y se
usaba en aplicaciones de todo tipo. Hoy el uso de interfaces orientadas a ventanas,
con opcin de sealar y elegir, ha reducido la dependencia de los comandos escritos, pero muchos usuarios avanzados an prefieren este tipo de interaccin. varios
temas de diseo surgen cuando se proporcionan comandos de texto o etiquetas de
men como modo de interaccin:
Cada opcin de men tiene un comando correspondiente?
Qu forma tendrn los comandos? Entre las opciones se incluyen una secuencia de control (como alt-P). teclas de funcin o palabras escritas por el
usuario.
Qu tan difcil ser aprender y recordar los comandos? Qu puede hacerse
si se olvida un comando?
El usuario tiene la opcin de personalizar o abreviar los comandos?
Las etiquetas de los mens se explican por s solas dentro del contexto de la
interfaz?
Los submens son consistentes con la funcin indicada en un elemento principal del men?
Como se indic al principio de este captulo, es necesario definir convenciones para
usar comandos en toda la aplicacin. Es confuso para el usuario y a menudo lo lleva a cometer errores escribir alt-D cuando desea duplicar un objeto grfico en una
aplicacin y alt-D cuando quiere deshacer una accin en otra. Es obvio que esto propiciar errores.
Accesibilidad de la aplicacin. A medida que las aplicaciones de computadora

se vuelven ubicuas, los ingenieros de sotlware deben asegurarse de que el diseo de
la interfaz tenga mecanismos que permiten un fcil acceso a quienes tienen necesidades especiales. La accesibilidad es un imperativo moral, legal y comercial para los
usuarios (e ingenieros de software) que tienen problemas fsicos. Diversas lneas generales de accesibilidad (por ejemplo, [W3C03]), muchas diseadas para aplicaciones Web, pero a menudo aplicables a cualquier sotlware, proporcionan sugerencias
detalladas para el diseo de interfaces que alcanzan diferentes grados de accesibilidad. Otros (como [APP03), [MIC03]) proporcionan lneas generales especficas para
"tecnologa asistencial" que atiende las necesidades de quienes tienen discapacidades visuales, auditivas, de movilidad, del habla o de aprendizaje.
376
PARTE DOS PRCTICA DE LA INGENIEllA DEL SOF"rWARE
Internacionalizacin. Los ingenieros de software y sus administradores subestiman invariablemente el esfuerzo y las habilidades necesarias para crear interfases
de usuario que atiendan las necesidades de usuarios de otras localidades o que hablan diferentes idiomas. Con demasiada frecuencia, las interfases se disean para
una localidad y un idioma y luego se espera que funcionen en otros pases. El rete
para los diseos de interfases es crear software "globalizado"; las interfaces de usuario deben disearse para contener un ncleo genrico de funciones que se entregue.a todos los usuarios. caracteristicas adicionales de localidad penniten a la interfapersona1izarse para un mercado especfico.
Los ingenieros de software cuentan con varias pautas para la internacionalizacin (como [IBM03]). Estas pautas atienden amplios problemas de diseo (como la:
diferencias en formato de pantalla en varios mercados) y temas discretos de imple
mentacin (por ejemplo, diferentes alfabetos pueden crear rotulacin y requisitos de
espacio especiales). El estndar Unicode [UNI03]) se ha desarrollado para atender c.
desalentador desafio de manejar docenas de idiomas naturales con cientos de carac
teres y simbolos.
~ Desarrollo de interfases de usuario
~ Objetivo. Estos herromientos le permiten o un
HetTamientas de representacin 10
ingeniero de softwore crear uno sofisticado in

terfoz grfica de usuario empleando relotivomente escoso
desarrollo de software personolizodo. los herramientos proporcionan acceso o componentes reutilizables y convierte lo
creacin de una interfoz en una seleccin entre opciones
predefinidas que se ensamblan mediante la herramiento.
Mocromedia Authorware, desarrollado por Macromedia

lnc. (www.mocromedia.com/software/), se ha diseada para la creacin de interfoses y entornos de apren
dizaje electrnico. Emplea caractersticas sofisticadas
de construccin.
Mecnica. Las interfoses de usuario modernas estn
Motif Common Desktop Environment, desarrollado por The
construidas con un conjunto de componentes reutilizables

acoplados con algunos componentes personalizados desa
rrollados para proporcionar funciones especializadas. Ca
si todos las herramientos de desarrollo de interfoses de
usuario permiten que el ingeniero de software cree una interfaz empleando opciones de #arrostrar y colocar"; es de
cir, el desarrollador selecciono entre opciones predefinidas
(por ejemplo, constructores de formularios, mecanismos de
interaccin, capacidad de procesamiento de comandas) y
coloca esas opciones en el contenido de la interfaz que ha
br de crearse.
Open Group (www.osf.org/tech/desktop/cde/), es

uno interfaz grfica de usuario integrada para siste
mas abiertas de computacin de escritorio. Entrega
una interfoz grfica simple, estndar, poro la adminis
tracin de datos, archivos y aplicaciones.
PowerDesigner/PowerBvilder, desarrollado por Sybose

(www.sybose/produds/intemetoppdevtools), es un
conjunto muy completo de herromientos CASE, que in
duyen muchos opciones para el diseo y la construccin de interfo~ grficas de usuario.
1O Las herramientas expuestas aqu slo representan una muestra de esta categoria. En casi todos
CAPTULO 12
377
Una vez que se ha creado un prototipo de interfaz de usuario operacional, debe evaluarse y determinar si satisface las necesidades del usuario. La evaluacin puede
abarcar un espectro de grados de formalidad que va desde una "prueba de manejo"
informal, en la cual un usuario proporciona retroalimentacin informal, hasta un estudio diseado formalmente, el cual emplea mtodos estadsticos para la evaluacin
de cuestionarios que llena una poblacin de usuarios finales.
El ciclo de evaluacin de la interfaz de usuario asume la forma mostrada en la figura 12.4. Despus de completado el diseo se crea un prototipo de primer nivel. A
continuacin, el usuario evala este prototipo' 1 y hace comentarios directos al diseador acerca de la eficacia de la interfaz. Adems, si se utilizan tcnicas formales de
evaluacin (por ejemplo, cuestionarios, hojas de evaluacin), es probable que el diseador obtenga informacin de estos datos (por ejemplo, del 80 al 100 por ciento
de los usuarios rechaza el mecanismo para guardar archivos de datos). Las modificaciones al diseo se hacen basndose en la informacin que proporciona el usuario, y as se crea un prototipo de segundo nivel. El ciclo de la evaluacin contina
hasta que ya sean innecesarias ms modificaciones al diseo de la interfaz.
DiSo
preliminar
Construir
lnterfot
prototipo #1
Con$troir
interfaz
prototipo #n
El usuario
Se realizan
modificaciones
evaluo
lo interfaz
al diseo
Diseo de interfaz
El diseador
estudio
lo evaluacin
completo
11 Es importante notar que los expertos en diseos ergonmomico y de interfaz tambin pueden dirigir revisiones de la interfaz. Dichas funciones se llaman evaluaciones heursticas o ensayos cognitivos.
378
PARTE DOS
PRcnCA DE LA 1NGENlERA DEL SOFTWARE
El enfoque de creacin de prototipos resulta eficaz, pero es posible evaluar la calidad de una interfaz de usuario antes de construir un prototipo? Si se descubren pcr
sibles problemas y se corrigen en las primeras etapas, se reducir el nmero de bucles en el ciclo de evaluacin y se acortar el tiempo de desarrollo. Si se ha creadc
un modelo de diseo de la interfaz, es posible aplicar varios criterios de evaluacicr
[MOR81J en las primeras revisiones del diseo:
J.
La longitud y complejidad de la especificacin escrita del sistema y su interfa.:.
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 estados del sistema que indica el modelo de
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 manejo 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 da::.
cualitativos y cuantitativos que ayudarn a evaluar la interfaz. Para recopilar los da
tos cualitativos se pueden distribuir cuestionarios entre los usuarios del protot:".'
con preguntas que arrojan: 1) respuesta simple s/no, 2) respuesta numrica, 3)
res-
puesta con escala de valoracin (subjetiva), 4) escala de Likert (por ejemplo, CO'""
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 estrdio 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, t'E
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 P"'
dificacin de la interfaz.
Un anlisis completo de los mtodos de evaluacin de la interfaz de usuario ""f'c
basa el alcance de este libro.
se
puede consultar ms informacin en [LEA&
[MAN97] y [HAC98).
12 ,A Rgsuyu
Es posible afirmar que la interfaz de usuario es el elemento ms importante de sistema o producto de cmputo. Si la interfaz est mal diseada la capacidad ~
usuario se ver muy reducida para aprovechar las ventajas de una aplicacin :.
efecto, una interfaz dbil puede llevar al fracaso una aplicacin bien diseada y e
una implementacin slida.
CAPTULO 12
379
Tres principios importantes guan el diseo de una interfaz de usuario efectiva: 1)

dar el 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 estos principios requiere desarrollar un proceso de diseo organizado.
El diseo de la interfaz de usuario comienza con una serie de tareas de anlisis.
Entre stas se encuentra identificacin del usuario, tarea y anlisis y modificacin de
la tarea y el entorno. El anlisis del usuario define los perfiles de varios usuarios finales y aplica informacin recopilada de diferentes fuentes de negocios y tcnicas.
El anlisis de tareas define las tareas y acciones del usuario empleando un enfoque
elaborativo u orientado a objetos, aplicando casos de uso, elaboracin de tareas y
objetos, anlisis de flujo de trabajo y representaciones jerrquicas de tareas para
comprender plenamente la interaccin ser humano-computadora. El anlisis ambiental identifica las estructuras fisica y social en que debe operar la interfaz.
Una vez identificadas las tareas, se crean y analizan los escenarios para definir un
conjunto de objetos y acciones de la interfaz. Esto proporciona la base para la creacin del formato de pantalla, que representa el diseo grfico y la ubicacin de los
conos, la definicin de un texto descriptivo en pantalla, la especificacin de las ventanas y la asignacin de ttulos a stas, adems de la especificacin de los elementos primarios y secundarios del men. Mientras se refina el modelo de diseo, deben
tomarse en cuenta temas relacionados con el diseo, como tiempo de respuesta, estructura de comandos y acciones, manejo de errores y funciones de ayuda. El usuario dispone de varias herramientas de implementacin para construir un prototipo
que l mismo puede evaluar.
[APP03) Apple Computer, People with Spedal Needs, 2003, disponible en http://www.apple.com/
disability/.
fBAROl] Borchers, J.. A Pattern Approach to lnteraction 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.torUse.com.
[DON99J Donahue, G., s. Weinschenck y J. Nowicki, "Usability is Good Business" . Compuwarc
Corp., julio de 1999, disponible en http://ww w.compuware.com.
[DUY02J vanDuyne, D. , J. Landay y J. Hong, The design of Sitcs, Addison-Wesley, 2002.
[HAC981 Hackos, J. y J. Redish, U.ser and Task Ana/y.sis far Interface Design, Wiley, 1998.
[1BM031 IBM, OvemewofSojlvvare Globalizadon, 2003, disponible en http://oss.sottware.ibm.com
/icu/userguide/ I l 8n.html.
[LEA88] Lea, M., "Eva I ualing User Interfaces Designs", en U.ser Interface Design Jor Computer
systems, Halstead Press (Wiley), I 988.
[MAN97) Mande!, T., The Elements of Userlnterface DesJgn, Wiley, 1997.
[MIC03) Microsoft Accesability Technologyfar Everyone, 2003, disponible en htt:/ / www.micro sott.com/enable/.
fMON84J Monk, A. (ed). Fundamentals of Human -Computer lnteraction, Academic Prcss, 1984.
[MOR8 l J Moran, T. P., "The Command Language Grammar A Represcntation for the U.ser Interface oflnteraclive Computer Systems", en lnU. Joumalof'1an-MachineStudies, vol. 15, pp. 3-50.
[NJEOO] Nielsen, J.. Desgning Web Usability, New Riders Publishing, 2000.
[NOR86J Norman, D. A., "Cognitive Engineering. en Usercentered systems Design, Lawrence
Earlbaum Associates, 1986.
380
PARTE DOS
[RUB88) Rubn, T., User Interface Design for Computer Systems, Haldstead Press (Wiley), I 988.
[SHN90J Shneiderman. B., Desigmng lhe User Interface, Addison-Wesley, 3a. ed., I 990.
[TID991 Tidwell. J.. "Common Ground: A Pattem Language for HCI Design", disponible ~
http:/ /www.mit.edu/@jtidwell/ interaction_pattems.html, mayo de 1999.
[TID02J Tidwell, J., "IU Pattems and Techniques" disponible en http://time.tripper.com/mp,::. tems/index.html, mayo de 2002.
[UNI03J Unicode Inc., The Unicode Home Page, 2003, disponible en http://www.unicode.o~
[W3C03J World Wide Web Consortium, Web Content Accesability Guidelines, 2003, disponible ~
http://www.w3.org/TR/2003/ Vvord-WCAG20-20030624/.
[vVELOJJ vanWelle M., '1nteraction Design Pattems", disponible en http://www.welie.com/paf
tems/, 2001 .
PBQILIMA X PUNTOS A coxs1pp4p

12. l. Describir la mejor y la peor interfaz con que se haya trabajado alguna vez y critquense
en relacin con los conceptos presentados en este capitulo.
12.2 . Desarrollar dos principios de diseo adicionales que "den el control al usuario".
12.3 . Desarrollar dos principios de diseo adicionales que "reduzcan la carga en la mem .
del usuario".
12.4 . Desarrollar dos principios de diseo adicionales que "logren una interfaz consisten.e
12.5. Se ha pedido desarrollar un sistema de banco en casa para Web; desarrollar los modeb::
del usuario, del diseo y mental y la implementacin
12.6. Realizar un anlisis detallado de tareas para el sistema del problema 12.5. Utilizar
enfoque elaborativo u orientado a objetos.
12. 7. Agregar por lo menos cinco preguntas adicionales a la lista desarrollada para el an.3;::
de contenido de la seccin I 2.3.5.
12.8. Siguiendo con el problema 12.6, definir objetos y acciones de interfaz para la aplicao
Identificar cada tipo de objetos
12.9 . Desarrollar un conjunto de formatos de pantalla con una definicin de elementos pn: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.......,
rente del que se muestra para el formato de pantalla en la figura 15.3.
12.11. Describir un enfoque propio de las funciones 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 va
bilidad del tiempo de respuesta.
12.13. Desarrollar un enfoque que integre automticamente los mensajes de error }' funcin de ayuda para el usuario. Es decir, que el sistema reconozca automticamente el -de error y proporcione una ventana de ayuda con sugerencias para corregirlo. Realizar un d...
o de software razonablemente completo que tome en cuenta las estructuras de datos y los
goritmos apropiados.
12.14. Desarrollar un cuestionario de evaluacin de interfaces que contenga 20 pregur
genricas aplicables a la mayor parte de las interfaces. Pdase que I O compaeros de e'
completen el cuestionario para un sistema interactivo que todos usen. Resumir los resultad<
informar de ellos a su clase.
04s LEcpgAs X [YENTES PE JNf9BMAQJ6N

Aunque su libro no se relaciona especficamente con interfaces ser humano-computadora cho de lo que Donald Norman (The Design ofEveryday Thngs, edicin reimpresa, Currency/D
381
bleday, 1990) tiene que decir sobre la psicologa de un diseo efectivo se aplicar a las interfaces de usuario. Es una lectura recomendada para cualquier persona que tome con seriedad el
diseo de interfaces de alta 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 aplicacin de negocios, la interfaz de usuario proporciona una ventana al software. Por ello, abundan 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, adei;ns de que contienen
muchos ejemplos tiles: Galitz (The Essential Guide to User Inte,jace Design, Wiley, 2002), Cooper (About Face 2.0: The Essentials of User Interface Design, IDG Books, 2003), Beyer y Holtzblatt
(Contextual Design: A Costumer Centered Approach to systems Design, Morgan-Kaufmann, 2002).
Raskin (The Human lnte,jace, Addison-Wesley, 2000), Constantine y Lockwood (Sojhvarefor Use,
ACM Press, 1999) y Mayhew (The Usability Engineering lifecydc, Morgan-Kaufmann, 1999).
Johnson (GUI Bloopers: Don'ts and Do's for Soflware Developers and Web Designers, MorganKaufmann, 2000) proporciona una guia til para quienes aprenden mejor al examinar contraejemplos. un libro que se disfruta, de Cooper (The Inmates Are Running the Asylum, Sams Publishing, 1999). analiza por qu los productos de alta tecnologa nos atraen y la manera de disear
unos que no Jo hagan.
El anlisis y modelado de tareas son actividades fundamentales del diseo de interfaces.
Hackos y Redish (HAC98J han escrito un libro dedicado a estos temas y proporcionan un mtodo 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 interfaces y la transicin a las tareas de diseo.
La actividad de evaluacin se concentra en la facilidad de uso. Los libros de Rubin (Handbook of Usability Testing; How to Plan, Design, and Conducl EjJective Tests, Wiley, 1994) y Nielsen
(Usability Inspection Methods, Wiley, 1994) abordan el tema con gran detalle.
En un libro nico, que podra parecer muy interesante a los diseadores de producto, Murphy
(Front Panel: Designing SoflwareJor Embedded User Tnter[aces, 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 manejo de maquinaria pesada y las inlerfaces para
sistemas mdicos o de transporte. El diseo de la interfaz para productos incrustados tambin
se estudia en el libro de Garrett (Advanced Instrumentation and Computer 1/0 Design: Real-Time
System Computer Tnterfacc 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 para el diseo de la interfaz de usuario se encuentra en el sitio Web SEPA:
http:/ /www.mhhe.com/pressman.
CAPTULO
13
CONCEPTOS
CLAVE
aheriosde
finaltGda 389
depuracin .409
~pecificocin
de prueba 401
8$frategia
convendoctGI 386
estrategia
o(ientado
a olietos 402
GIP ........ .386
prma
ESTRATEGIAS DE PRUEBA
DEL SOFTWARE
na estrategia de prueba del software integra los mtodos de diseo de

caso de pruebas del software en una serie bien planeada de pasos que d
sembocar en la eficaz construccin de software. La estrategia propor
dona un mapa que describe los pasos que se darn como parte de la prueba.
indica cundo se planean y cundo se dan estos pasos, adems de cunto esfuerzo, tiempo y recursos consumirn. Por tanto, cualquier estrategia de prueba
debe incorporar la planeacin de pruebas, el diseo de caso de pruebas, la e,e,
cucin de pruebas y la recoleccin y evaluacin de los datos resultantes.
Una estrategia de prueba del software debe ser lo suficientemente flexiliJe
como para promover un enfoque personalizado. Al mismo tiempo, debe ser
adecuadamente rgido como para promover una planeacin razonable y
seguimiento administrativo del avance del proyecto. Shooman (SH083] analiz:
estos temas:
dt hllfflO 399
prteba de
rentes de pruebas vara tanto como los diferentes enfoques de desarrollo. Durame
integradn .. .394
muchos aos, la nica defensa contra los errores de programacin fueron el disefu>
prueba de
regresin .... .398
cuidadoso y la inteligencia natural del programador. Ahora estamos en la era en
En muchos sentidos, la prueba es un proceso autnomo, y el nmer-o de tipos dife-
las tcnicas modernas de diseo
que
y las revisiones de las tcnicas fnnalesJ nos estn
prueba ele
ayudando a reducir el nmero de errores i.rciales inherentes al cdigo. De maneras -
unidad .... 392
milar, diferentes mtodos de prueba estn empezando a apilarse en varios mtodos
pn1eba de
y filosofas distintos.
vctdacia .... .404

prueba del
sistema ..... .406
pruebas olfa/
beta ... . ... ,40S
Estos "enfoques y ftlosofias" conforman lo que se denomina estrategia. En

captulo 14 se presentar la tecnologa de prueba del software. Ese captulo
concentrar en la estrategia de la prueba del software.
VyV . .384
Qu es? El sotwore se pruebo po

ro descubrir errores cometidos sin
darse cuento al realizar su diseo y
construccin. Pero cmo se realizan
{qs prvebos? Debe desarrollarse un
pion formol para las pruebas? eDebe probarse
el programci como un todo o sto deben aplicar
se pruebas a uno porte pequeoi Deben volver
o realizarse las pruebas eecutados o medido
que se ogregan nuevos componentes o un sistema
de gran tamao? Cundo debe pedirse la por-
ticipocin del diente? stos y muchos otras preguntas se respondern cuando desarrolle una es
lro1egio de pruebo del software.
Quin lo hace? El efe de proyecto, los ingenieros de software o los especiolistas en pruebas
son quienes desarrollan la estrategia poro a
pruebo del software.

Por qu es importante? Con fre.Jencia, la
pruebo requiere uno mayor canttdod del esfue<zo dedcodo o1 proyecto que cualquier otro octi
vklad de ingeniera del sftwore. Si se realiza
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOF'iWARE
383
La prueba es un conjunto de actividades que se planean con anticipacin y se reali-
zan de manera sistemtica. Por tanto, se debe definir una plantilla para las pruebas
del software (un conjunto de pasos en que se puedan incluir tcnicas y mtodos
especficos del diseo de casos de prueba).
Se han propuesto varias estrategias de prueba del software en distintos libros;
todas proporcionan al desarrollador del software una plantilla para pruebas y todas
tienen las siguientes caracteristicas genricas:
Para realizar pruebas efectivas un equipo de software debe efectuar revisiones tcnicas formales y efectivas (captulo 26). Esto eliminar muchos
errores antes de que empiece la prueba.
La prueba comienza al nivel de componentes y trabaja "hacia fuera", hacia la
integraci6n de todo el sistema de cmputo.

Diferentes tcnicas de prueba son apropiadas en diferentes momentos.
La prueba la dirige el desarrollador del software y (en el caso de proyectos
grandes) un grupo independiente de pruebas.
La prueba y la depuracin son actividades diferentes, pero la segunda debe
incluirse en cualquier estrategia de prueba.
Una estrategia para la prueba del software debe incluir pruebas de bajo nivel (necesarias para confirmar la correcta implementacin de un pequeo segmento de cdigo fuente) y de alto nivel (que validen las principales funciones del sistema a partir
384
PARTE DOS PRCllCA DE LA INGENIERA DEL SOF'!WARE
de los requisitos del cliente). Una estrategia debe servir como gua para el pre.
nal y fijar un conjunto de guas para el jefe de proyecto. Debido a que los pas e:
la estrategia de prueba son simultneos, cuando empieza a aumentar la presi:':
las fechas lmite debe tenerse la opcin de medir los avances y buscar que los
blemas aparezcan Jo antes posible.
13.1.1 VerWcacin y validacin

La prueba del software es un elemento de un tema ms amplio que suele d
narse verificacin y validacin r,tyV). Verificacin es el conjunto de actividades
aseguran que el software implemente correctamente una funcin espe
Validacin es un conjunto diferente de actividades que aseguran que el so.
construido corresponde con los requisitos del cliente. 1 Boehm [BOE8 l J Jo est-:i
de otra manera:
Verificacin: "Estamos construyendo el producto correctamente?"
Validacin: "Estamos construyendo el producto correcto?"
La definicin de VyV abarca muchas de las actividades incluidas en el asegurcc=:::::
to de la calidad del software y se analiza de manera detallada en el captulo 2
No se deben tener
descuidos ni
considero! que los
pruebas son uno 'md
de seguridad' que
utropam todos los
errores que ocumJn
debido olo op/icocin
de prcticas dbiles de
ingeniera del
softwo1e. No lo son.
Debe pone/Se espedol
cuidado en lo calidad
y detecdn de emJ1es
en todo el proceso de
lo ingeniera del
software.
La verificacin y la validacin abarcan una amplia lista de actividades de ase:-:

ramiento de la calidad del software: revisiones tcnicas formales, auditoras o.e
dad y de configuracin, monitoreo del desempeo, simulacin, factibilidad, re,
de la documentacin y la base de datos, anlisis de algoritmos, pruebas de d
Uo, de facilidad de uso, calificacin y de instalacin [WAL89]. Aunque las acth
de prueba tienen un papel demasiado importante en VyV,
muchas otras actividades.
i'rabar es la parte inmtoble de cualquier esfuerzo responsable POf desarrollar un sistema df.softwofe:
Las pruebas son el ltimo bastin para la evaluacin de la calidad y, de rr

ms pragmtica. el descubrimiento de errores. Pero las pruebas no deben co
rarse como una "red de seguridad". Como suele decirse: "No es posible probar lz.
dad. Si no est ah antes de que empiece la prueba, no estar cundo se teTC"
La calidad se incorpora al software en todo el proceso de ingeniera. La apli apropiada de mtodos y herramientas, las revisiones tcnicas formales y efec:.
Debe indicarse que hay una fuerte divergencia de opinin acerca de los tipos de prueba que
tuyen una "validacin". Algunas personas creen que toda prueba es una verificacin, y que:..
dacin se realiza cuando el usuario revisa y aprueba los requisitos, y ms delante, cuando el SL
est en condiciones de operar otras personas consideran que ta prueba de la unidad y la ucin (secciones 13.3.1 y 13.3.2) constituyen la verificacin y que las pruebas de alto nivel
das ms adelante en este capitulo) son la validacin.
(a.
CAPinJLO 13
errRATEG!AS DE PRUEBA OO. SOFTWARE
385
junto con una administracin y una medicin slidas aportan la calidad, que se confirma durante las pruebas.
Miller [MIL77] relaciona la prueba del software con el aseguramiento de la calidad al afirmar: "lo que motiva la prueba de los programas es la confirmacin de la
calidad del software con mtodos que se puedan aplicar de manera econmica y
efectiva en sistemas grandes y pequeos".
13.1.2 Organizacin para las pruebas del software

En cualquier proyecto de software se presenta un conflicto de intereses cuando
comienzan las pruebas. Ahora se pide a las personas que han construido el software que lo prueben. En s, esto parece inofensivo; despus de todo, quin conoce
mejor un programa que la persona que lo desarroll? Por desgracia, a esos mismos
desarrolladores les interesa mucho demostrar que el programa est libre de errores,
que funciona de acuerdo con los requisitos del cliente y que se completar a tiempo
y sin rebasar el presupuesto. Cada uno de estos intereses mina las bondades de la
prueba.
"Boptmismo es ef peligro O<Upoonol de lo programacin; lo pruebo, el tratamiento.

Kttt Btik
Desde un punto de vista psicolgico, el anlisis y el diseo del software Ounto con la
codificacin) son tareas constructivas. El ingeniero del software analiza, modela y
luego crea un programa de computadora, junto con su documentacin. Como cualquier constructor, el ingeniero del software se sentir orgulloso del edificio que
acaba de construir y mirar con recelo a cualquiera que pretenda echarlo abajo.
Cuando comienza la prueba hay un intento sutil, pero definitivo, de "romper" lo que
ha construido el ingeniero del software. Al ponerse en los zapatos del constructor la
prueba parecer (psicolgicamente) destructiva. De modo que el constructor actuar con cuidado, diseando y ejecutando pruebas que demostrarn el buen funcionamiento del programa en lugar de descubrir errores. Por desgracia, los errores seguirn presentes. Y si el ingeniero del software no los encuentra, el cliente si lo har!
De las consideraciones precedentes suelen inferirse errneamente varias malas
interpretaciones: I) que el responsable del desarrollo no debera participar en el proceso de prueba, 2) que el software debe ponerse a salvo de extraos que lo prueben
sin misericordia, y 3) que quienes aplican las pruebas slo deben participar en el proyecto cuando vayan a darse los primeros pasos de esas pruebas. Todas estas afirmaciones son incorrectas.
El desarrollador del software siempre ser el responsable de probar las unidades
individuales (componentes) del programa y asegurar que cada una realice la funcin
o muestre el comportamiento para el que se dise. En muchos casos, el desarrollador tambin aplica la prueba de integracin (un paso que lleva a la construccin,
y la prueba, de toda la arquitectura del software . Slo despus de que la arquitectura del software est completa participar un grupo independiente de prueba.
386
PARTE DOS
PRCTICA DE LA INGEN:ERA OO. SOFTWARE
El papel de un grupo independiente de prueba (GIP) consiste en eliminar los 1blemas propios de dejar que el constructor pruebe lo que l mismo ha constn..._:
Si no existe un G/P
dentro de uno
organizacin, tendr
que odopta,se su
punto de vishJ propio.
Al aplicar lo pruebo se
debe traror de destruir
el software.
La prueba independiente elimina el conflicto de intereses que, de otra manera. es::
ra presente. Despus de todo, al personal del GIP se le paga para que encueerrores.
Sin embargo, el ingeniero del software no debe simplemente entregar el pr~
ma al GIP y alejarse. El desarrollador y el GIP deben trabajar unidos en todo el :-yecto de software para asegurar la realizacin de pruebas exhaustivas. Mier
stas se realizan, el desarrollador debe estar disponible para corregir los errores
se descubran.
.......
e primer error que comete lo gente es pensar que el equipo de pruebas es responsable de asegurar lo calidad:
El GIP es parte del equipo del proyecto de desarrollo del software, ya que pa:pa en el anlisis y diseo y adems sigue participando (al planear y especificar
cedimientos de prueba) en todos los pasos de un proyecto grande. Sin embarg:
muchos casos el GIP informa a la organizacin de aseguramiento de calidad del sware, por lo que obtiene un grado de independencia que sera imposible si
parte de la organizacin encargada de la ingeniera del software.
13.1.3. Estrategia de prueba para arquitechuas convencionales

del software
Sera factible considerar que el proceso de ingeniera del software es equipara:.:
la espiral que se ilustra en la figura 13.1. Al principio, la ingeniera del sistema
ne el papel del software y lleva al anlisis de los requisitos de ste, donde se
blecen el dominio de informacin, la funcin, el comportamiento, el desempee
restricciones y los criterios de validacin del software. Al desplazarse hacia el
rior de la espiral se llega al diseo y, por ltimo, a la codificacin. El desarrol
Cul es la
estrategia
general para la
prueba del
software?
software de computadora requiere recorrer la espiral hacia dentro, a lo largo de

linea bien definida que disminuye el grado de abstraccin tras cada vuelta.
Tambin es posible ver una estrategia para la prueba del software en el con _
de la espiral (figura 13.1). La prueba de unidad comienza en el vrtice de la esp_
se concentra en cada unidad (componente) del software, tal como se implemen_
el cdigo fuente. La prueba avanza al desplazarse hacia fuera, a lo largo de la _
ral, hasta llegar a la prueba de integracin, donde se atiende el diseo y la c o ~
cin de la arquitectura del software. Si se recorre otra vuelta hacia fuera en la ...
ral, se encuentra la prueba de validacin, donde se validan los requisitos establee
como parte del anlisis de requisitos del software, comparndolos con el so!l
que se ha construido. Por ltimo, se llega a la prueba del sistema, donde se pn..e;
como un todo el software y otros elementos del sistema. El software de compura se prueba recorriendo la espiral hacia fuera, por una linea bien definida, de m.r
que en cada vuelta se ensancha el alcance de la prueba.
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEI. S0f1WARE
387
Si se considera el proceso desde un punto de vista procedimental, en realidad la

prueba dentro del contexto de la ingeniera del software consiste en una serie de
cuatro pasos que se implementan de manera secuencial. Esos pasos se muestran en
la figura 13.2. Al principio, la prueba se concentra en cada componente individual,
asegurando que funciona de manera apropiada como unidad (por ello se le denomina prueba de unidad). La prueba de unidad emplea en forma recurrente las tcnicas
de prueba que recorren caminos especficos en una estructura de control del componente, lo que asegura una cobertura completa y una deteccin mxima de errores. Enseguida deben ensamblarse o integrarse los componentes para formar el
paquete de software completo. La prueba de integracin atiende todos los aspectos
asociados con el doble problema de verificacin y construccin del programa. Las
tcnicas de diseo de casos de prueba que se concentran en entradas y salidas son
Pruebas
7;,.-ito.,,.s_ _.____d_e_a_lto-r-ni-ve_l_ ___....__ __,

Diseo
Pruebo de integracin
/ ~---------------------..
Cdigo
"Direccin"
de la prueba
388
PARTE DOS PRcnCA DE LA INGENIEmA DEL SOFTWARE
ms dominantes durante la integracin, aunque podran usarse tcnicas que re

rren rutas especficas del programa para asegurar la cobertura de los princi~
caminos de control. Despus de que se ha integrado (construido) el software se a:"'C_
ca un conjunto de pruebas de alto nivel. Se deben evaluar los criterios de validac
establecidos durante el anlisis de requisitos. La prueba de validacin proporc
un aseguramiento final de que el software cumple con todos los requisitos fu."
nales. de comportamiento y desempeo.
El ltimo paso de la prueba de alto nivel queda fuera de los limites de la in~
ria del software, pero dentro de un contexto ms amplio de la ingeniera de los
temas de cmputo. El software, una vez validado, debe combinarse con otros
mentos del sistema (por ejemplo, hardware, personas. bases de datos). La prueba
sistema verifica que todos los elementos encajen apropiadamente y que se logre
funcin y el desempeo generales del sistema.
13.1.4 Estrategia de prueba del software para arquitecturas

orientadas a objetos
La prueba de sistemas orientados a objetos plantea un conjunto diferente de d
al ingeniero del software. La definicin de prueba debe ampliarse para incluir

cas de descubrimiento de errores (por ejemplo, revisiones tcnicas formales) q- e
Como los pruebos

convenonoles, los
oentodos oo~etos
em~ezon por lo
"pequeo". Sin
embargo, en casi todos
los casos, el elemento
ms pequeo probodo
es uno clase oun
paquete de doses que
colaboron entre s.
aplican para analizar y disear modelos. El grado al que se han completado y la

sistencia de las representaciones orientadas a objetos deben evaluarse a medida
se construyen. La prueba de unidad pierde parte de su significado, y las estra.~
de integracin cambian de manera importante. En resumen, las estrategias y las
ticas de prueba (captulo 14) deben ser responsables de las caractersticas nicas
software orientado a objetos.
La estrategia general para el software orientado a objetos tiene una filosofa
tica a la que se aplica a las arquitecturas convencionales, pero presenta difere
en el enfoque. Se empieza "probando lo pequeo" y se trabaja hacia el exterio:
bando lo grande" . Sin embargo, la atencin cambia cuando la prueba es peque--un mdulo individual (el concepto convencional) a una clase que abarca atrib
operaciones y que. adems, requiere comunicacin y colaboracin. A medida.:-
Doug: Me parece que no hc!rrudedicm:b el tiempo

suficiente o hablar de ia, pruebo$.
Ymod: rrazn, pero todc. heme emdo un

otoreodos. Y odems hernot pensado en elo...
realidad, hernot hecho m6s que penlOriO.
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOfiWARE
389
Jamie: Yo he estodo haciendo fo,mjsmo.

Vinod: Y he lomado el pap) de i n ~ ~ d. modo
que codo vez que uno de fo$1\'l~ me pe,,- un
componente, lo integrar y ~~r uno ;ee &t

pruebas de regresin en el pr~rQMQ p(lreA:llmente
integrado. He estado lrQbopndo ~ iji.eor un
conjunto de pruebo$ apropiodG pora' ccida funcin del
sistema.
Vinod: Todo} tos dhl.;. ho.sto ~ue $Ctir.ife9r! biOl'I el

sisliilma. O se, h<uki queJ()S,'inc;~ d e ~
que plollf!QmOs enltegor quede i ~ .
boug: Muchochos,,van ~ ~ mH
Vinod (sonriendo): Lo onticipatln lo es lbdo enel
negocio del software, .jefe.
integran clases dentro de una arquitectura orientada a objetos, se ejecuta una serie
de pruebas de regresin para descubrir errores debidos a la comunicacin y colaboracin entre clases (componentes) y a los efectos colaterales que origina la adicin
de nuevas clases (componentes). Por ltimo, se prueba el sistema como un todo para
asegurarse de que se descubran errores en los requisitos.
13.1.5 Criterios para completar la prueba

Cada vez que se analizan las pruebas del software surge una pregunta clsica:
cundo hemos terminado las pruebas (cmo sabemos que hemos probado lo suficiente)? Lo lamentable es que no hay una respuesta definitiva, sino que hay algunas
respuestas pragmticas y algunos intentos iniciales de sentar una gula emprica.
Una respuesta a la pregunta es: "nunca se termina de aplicar una prueba; la carga
simplemente se desplaza de usted (el ingeniero del software) a su cliente. Cada vez
que el cliente, el usuario, o ambos, ejecutan un programa de computadora, ste se
est probando. Este hecho incuestionable subraya la importancia de otras actividades del aseguramiento de la calidad del software.
Otra respuesta (un poco cnica, pero correcta) es: "la prueba se termina cuando se
agota el tiempo o el dinero".
Aunque algunos usarn esta respuesta como argumento. un ingeniero del software necesita criterios ms rigurosos para determinar que las pruebas han sido suficientes. Musa y Ackerman [MUS89) sugieren una respuesta basada en criterios estadsticos: "No, no podemos estar completamente seguros de que el software nunca
fallar. pero de acuerdo con un modelo estadstico teticamente slido y validado en
forma experimental, hemos realizado las pruebas suficientes como para afirmar, con
una confianza del 95%, que las probabilidades de tener mil horas de operaciones del
390
PARTE DOS
PRCilCA DE LA lNGENJERA DEL SOFl'WARE
CPU libres de fallas en un entorno definido de forma probabilstica es por lo rr

de 0.995." Empleando el modelado estadstico y la teora de la confiabilidad del
ware, pueden desarrollarse modelos de fallas del software (descubiertas durar.:.e
prueba) como una funcin del tiempo de ejecucin (por ejemplo, cons.
[MUS89], [S1N99l O [lEEOI]).
Al recopilar mtricas durante la prueba del software y usar modelos existente<:
la confiabilidad del software, es posible desarrollar directrices significativas para
ponder la pregunta: Cundo hemos terminado la prueba? Lo indiscutible es que
falta mucho trabajo antes de que puedan establecerse reglas cuantitativas pa,
prueba, pero los enfoques empricos existentes son considerablemente mejore:>
la simple intuicin.
Ms adelante, en este mismo captulo, se explorar una estrategia sistemtica ~

prueba del software. Pero hasta la mejor estrategia fallar si no atiende una sene
aspectos predominantes. Tom Gilb [GIL95l argumenta que deben atenderse los s"'
tes temas, si se desea implementar con xito una estrategia de prueba del soft\'a=:-
Cules
directrices
llevan a una
estrategia de
prueba del
software que
tengo xito?
E.specificar los requisitos del producto de manera cuantificable mucho antes d ~

empiecen las pruebas. Aunque el objetivo primordial de la prueba es encontrar
res, una buena estrategia de prueba tambin evala otras caractersticas de la
dad, como las opciones de llevarla a otra plataforma, adems de la facilidad de
tenimiento y uso (captulo 15). Esto debe especificarse de manera tal que pemedirlo para que los resultados de la prueba no resulten ambiguos.
Establecer explcitamente los objetivos de la prueba. Los objetivos especficos

prueba se deben establecer en trminos cuantificables. Por ejemplo, dentro de
de prueba deben establecerse la efectividad y la cobertura de la prueba, el t
medio de falla, el costo de encontrar y corregir defectos, la densidad o la free..
de las fallas restantes, y las horas de trabajo por prueba de regresin [GIL95]
Comprender cules son los usuarios del software y desarrollar un perfil par..
categora de usuario. Los casos de uso que describan el escenario de interaccicr
cada clase de usuario reducen el esfuerzo general de prueba, ya que concen::prueba en la utilizacin real del producto.
Desarrollar un plan de prueba que destaque la "prueba de ciclo rpido". Gilb
tG.
recomienda que un equipo de ingeniera del software "aprenda a probar en ~

rpidos (296 del esfuerzo del proyecto) los incrementos en el mejoramiento de cionaJidad, la calidad, o ambas, de manera que sean tiles para el cliente y Se
dan probar en el campo"_ La retroalimentacin que generan estas pruebas de
rpido se utiliza para controlar los grados de calidad y las correspondientes es
gias de prueba.
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOF1WARE
391
Construir un sojlware "robusto" diseado pa_ra probarse a s mismo. El software debe

disearse de manera tal que use tcnicas antierror (seccin 13.3. l ). Es decir, el software debe tener la capacidad de diagnosticar ciertas clases de errores. Adems, el
diseo debe incluir pruebas automatizadas y de regresin.
Usar revisiones tcnicas formales y efectivas como filtro previo a la prueba. Las revisiones tcnicas formales (captulo 26) llegan a ser tan efectivas como las pruebas
para descubrir errores. Por tanto, las revisiones reducen la cantidad de esfuerzo de
prueba que se requiere para producir software de alta calidad.
Realizar revisiones tcnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Las revisiones tcnicas formales posibilitan descubrir inconsistencias, omisiones y errores evidentes en el enfoque de la prueba. Esto ahorra tiempo y tambin mejora la calidad del producto.
Desarrollar un enfoque de mejora continua para el proceso de prueba. Es necesario

medir la estrategia de prueba. Las medidas reunidas durante la prueba deben usarse como parte de un enfoque estadstico de control del proceso para la prueba del
software .
..frobor nicomentt los requisitos del usuario final es como inspeccionar un edificio considerando nicamente el
traboo recdizodo por el diseador de interiores, ocosto de los cimientos, los vigas y lo plomera.n
13,3 l3tB4X1GJ4$ PI ERJlillt PARA t' IPE'OYARI couyNCJQBAb

En la prueba del software es posible aplicar muchas estrategias. En un extremo, un
equipo de software podra esperar hasta que el sistema est totalmente construido y
luego aplicar pruebas al sistema general esperando encontrar errores. Este enfoque,
aunque atractivo, simplemente no funciona. Arrojar un software plagado de errores, molesto para el cliente y usuario final. En el otro extremo, un ingeniero de software podra aplicar pruebas diariamente, sin importar la parte del sistema que se
construya. Este enfoque, aunque menos atractivo para muchos, es muy efectivo. Por
desgracia, la mayora de los desarrolladores de software dudan en usarlo. Qu hay
que hacer?
La estrategia de prueba que elige la mayor parte de los equipos de software se
ubica entre estos dos extremos. Toma un enfoque incremental de las pruebas; inicia
con la prueba de unidades individuales del programa pasa a pruebas diseadas para
facilitar la integracin de las unidades, y culmina con pruebas que realizan sobre el
sistema construido. En las siguientes secciones se expone cada una de estas clases
de prueba.
392
PARTE DOS
13.3.1
PRGnCA DE LA INGENJmA DEL SOF'IWARE
Prueba de unidad
La prueba de unidad se concentra en el esfuerzo de verificacin de la unidad ll'....S

pequea del diseo del software: el componente o mdulo de software. Tomanc.
como gua la descripcin del diseo al nivel de componentes, se prueban importa-tes caminos de control para descubrir errores dentro de los lmites del mdulo ::
alcance restringido que se ha determinado para las pruebas de unidad limita la re ;tiva complejidad de las pruebas y los errores que stas descubren. Las pruebas de 1.1.dad se concentran en la lgica del procesamiento interno y en las estructuras de da.
dentro de los lmites de un componente. Este tipo de prueba se puede aplicar e.
paralelo a varios componentes.
Consideraciones sobre la prueba de unidad. En la figura 13.3 se ilustrar manera esquemtica las pruebas que se aplican como parte de la prueba de unidad ~
interfaz del mdulo se prueba para asegurar que la informacin fluye apropiadamer _
hacia dentro y hacia fuera de la unidad de programa sujeta a prueba. Se examinan _
estructuras de datos locales para asegurar que los datos temporales mantenen la Lgridad durante todos los pasos de la ejecucin de un algoritmo. Se recorren todos
caminos independientes (caminos de base) en toda la estructura para asegurar C' ~
Cules
errores se
encuentran
comnmente
durante la prueba
de unidad?
Prueba de
urudad.
todas las instrucciones de un mdulo se hayan ejecutado por lo menos una vez. ~
prueban las condiciones lmite para asegurar que el mdulo opera apropiadame:en los lmites establecidos para restringir el procesamiento. Y, por ltimo, se pr_
ban todos los caminos de manejo de errores.
Es necesario probar el flujo de datos en la interfaz del mdulo antes de ini
cualquier otra prueba. Si los datos no entran ni salen apropiadamente, todas
dems pruebas resultarn intiles. Adems. durante la prueba de unidad deben r ~
rrerse las estructuras de datos locales y evaluarse (si es posible) el impacto le:
sobre los datos 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 cla..
incorrectos. comparaciones errneas o flujos de control inapropiados. Entre los e-
rtl
L:tJ
lnlerfoz
E.lrvcu' de doto. lcc:oles

Condoones tmae
Rutas lndependien1e,
Ruta. de moneo de err0<e1
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOFTWARE
393
res ms comunes en los clculos se encuentran los siguientes: l) aplicacin incorrecta o mal entendida de la precedencia aritmtica, 2) operaciones de modo mezcladas, 3) inicializacin incorrecta, 4) falta de precisin, y 5) representacin simblica incorrecta de una expresin. La comparacin y el flujo de control estn estrechamente acoplados entre s (es decir, el flujo cambia con frecuencia despus de una
comparacin). Los casos de prueba deben descubrir errores como: 1) comparaciones
entre diferentes tipos de datos, 2) operadores lgicos o precedencia de stos aplicados incorrectamente, 3) expectativa de igualdad cuando los errores de precisin
hacen que sea poco probable, 4) comparacin incorrecta de variables, 5) terminacin inapropiada o inexistente de bucles, 6) falla en la salida cuando se encuentra
una iteracin divergente, y 7) variables de bucle modificadas de manera inapropiada.
La prueba de lmites es una de las tareas ms importantes de la prueba de unidad.
Con frecuencia, el software falla en sus lmites. Es decir, a menudo los errores ocurren cuando se procesa el ensimo elemento de una matriz de n dimensiones, cuando se evoca la i-sima repeticin de un bucle con i pasos, cuando se encuentra 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 valores de datos ubicados apenas abajo de los mximos o mnimos, sobre stos y apenas arriba de ellos.
Un buen diseo impone que se prevean las condiciones de error y que se configuren rutas de manejo de errores para modificar la ruta o terminar limpiamente el
procesamiento cuando ocurra un error. Yourdon [YOU75J llama a este enfoque antierror. Por desgracia, existe la tendencia a incorporar el manejo de errores en el software y, con ello, a no probarlo nunca. Una historia real servir como ejemplo:
Un sistema de diseo asistido por computadora se desarroll bajo contrato . En un mdulo de procesamiento de transacciones, un bromista prctico puso el siguiente mensaje
de manejo de errores despus de una serie de pruebas condicionales que invocaban varias ramas del flujo de control: ERROR! NO HAY FORMA DE QUE PUEDA LLEGAR
HASTA AQUf. E~te "mensaje de error" lo descubri un cliente durante la capacitacin
del usuario!
Entre los posibles errores que deben probarse cuando se evale el manejo de
errores se encuentran los siguientes: 1) la descripcin del error es ininteligible, 2) el
error indicado no corresponde al encontrado, 3) la condicin de error causa la intervencin del sistema operativo antes de que se dispare el manejo de errores, 4) el procesamiento de la condicin de excepcin es incorrecto, 5) la descripcin del error no
proporciona informacin suficiente para ayudar a localizar la causa del error.
Procedimientos de prueba de unidad. La prueba de unidad suele considerarse

adyacente al paso de la codificacin. El diseo de las pruebas de unidad puede realizarse antes 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
394
PARTE DOS PRCTICA DE LA INGENIERA DEL SOf"IWARE
lfaihifi
Entorno de
n'8rl0z
prueba de
unidad.
Eslruduros de do10s locole.

Cond~lmi"'
R"'' ;,,depe<,dient..
R.U'fO:s de monefO de errores
diseo proporciona una gua para establecer casos de prueba que probable
descubrirn errores en cada una de las categoras analizadas. cada caso de p
debe relacionarse con un conjunto de resultados esperados.
Debido a que un componente no es un programa independiente, para cada
ba de unjdad se debe desarrollar software controlador, de resguardo, o de
tipos. En la figura 13.4 se ilustra el entorno para la prueba de unidad. En cas; p
Hoy situaciones en
que no se tendrn los

reCUfSOS paro hacer
uno pruebo de unidad
muy completa.
Entonces deben selec
cionorse mdulos
crticos y los que
rengan uno elevado
comple;idod en ciclos,
yslo sos deben
probarse.
las aplicaciones, un controlador no es ms que un "programa principal" que a..,

los datos del caso de prueba, pasa estos datos aJ componente (que habr de p;se) e imprime los resultados importantes. Los resguardos sirven para reerr.~
mdulos subordinados al componente que habr de probarse (o llamados por
Un resguardo o "subprograma simulado" usa la interfaz del mdulo subord
realiza una mnima manipulacin de datos, proporciona verificacin de la en
devuelve el control al mdulo de prueba.
Controladores y resguardos representan una sobrecarga de trabajo. Es
resulta necesario escribir ambos tipos de software (sin que suela aplicarse U!'
o formal), pero no se entregan con el producto .de software final. Si se les rr
ne en un njvel simple, la sobrecarga real es relativamente pequea. Por des:
no es posible aplkar adecuadamente una prueba de unidad a muchos compocon un "simple" software de sobrecarga. En muchos casos es posible pospr
prueba completa hasta el paso de prueba de integracin (donde tambin se u
controladores o resguardos).
La prueba de unidad se simplifica cuando se disea un componente cecohesin elevada. Cuando slo se atiende una funcin de un componente, el ro de casos de prueba se reduce y es ms fcil predecir y corregir los errores
13.3.2 Prueba de integracin

Un nefito en el mundo del software podra plantear una pregunta aparente
legtima, una vez que se haya aplicado una prueba de unidad a todos los
"Si todo funciona bien individualmente, por qu dudan que funcione cuan
CAPTULO 13 ESTRATEGIAS DE PRUEBA OELSOFIWARE
395
une?" El problema, por supuesto, consiste en "unir" (crear la interfaz). En una interfaz es posible perder datos, un mdulo 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 elementos 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 integracin es una tcnica sistemtica para construir la arquitectura del software mientras, al mismo tiempo, se aplican las pruebas para descubrir
errores asociados con la interfaz. El objetivo es tomar componentes 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
componentes por anticipado. Se prueba todo el programa como un todo. Y se produce el caos! Se encuentra una gran cantidad de errores. La correccin es dificil, porque resulta complicado aislar las causas debido a la extensin del programa completo. Una vez corregidos esos errores, aparecen otros nuevos y el proceso contina
en un ciclo que parece interminable.
La integracin incremental es la anttesis del enfoque del "big bang". El programa
se construye y prueba en pequeos incrementos, en los cuales resulta ms fcil aislar y corregir los errores, es ms probable que se prueben por completo las interfaces y se vuelve factible la aplicacin de un enfoque de prueba sistemtica. En los
siguientes prrafos se expondrn varias estrategias diferentes de integracin incremental.
Integracin descendente. La prueba de integracin descendente es un enfoque

incremental para la construccin de la arquitectura del software. Los mdulos se
integran al descender por la jerarqua de control, empezando con el mdulo de control principal (programa principal). Los mdulos subordinados al mdulo de control
principal se incorporan en la estructura de una de dos maneras: primero-en-profundidad o primero-en-anchura.
Tomando como referencia la figura 13.5, la integracin primero-en-profundidad
integra todos los mdulos de una ruta de control principal de la estructura del programa. 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 camino de la
izquierda, se integraran primero los mdulos M 1, M2 y M 5 . A continuacin, se integrara M8 o (si es necesario para el adecuado funcionamiento de M2) M6. Enseguida
se construyen las rutas de control central y a la derecha. La integracin primero-en
anchura incorpora todos los componentes directamente subordinados en cada nivel,
desplazndose horizontalmente por la estructura En el caso de la figura, se integraran primero los componentes M2, M3 y M4 Y les seguiran M5 , M6 , etc. El proceso de
integracin se realiza en una serie de cinco pasos
396
PARTE DOS
iiMlifiJ
Integracin
descendente.
-- -- --
-- --
r-:~-1
1
1
1
r-:;-1
Cules son
los pasos de
lo integracin descendente?
1 . El mdulo de control principal se utiliza como controlador de prueba, y se

sustituyen los resguardos en todos los componentes directamente subordP".ados al mdulo de control principal.
2 . Dependiendo del enfoque de integracin seleccionado (es decir, primero-e:-
profundidad o primero-en-anchura) se van reemplazando los resguardos s..

bordinados, uno por uno, con los componentes reales.
3. Se aplican pruebas cada que se integra un nuevo mdulo.
4. Al completar cada conjunto de pruebas, se reemplaza otro resguardo con t:.;

mdulo real.
5. Se aplica la prueba de regresin (que se analiza ms adelante, en esta misr

seccin) para asegurarse de que no se han introducido nuevos errores.
El proceso contina a partir del paso 2 hasta la construccin total de la estru
del programa.
La estrategia de integracin descendente verifica los principales puntos de c.
trol o decisin al principio del proceso de prueba. En una estructura de progra.:
bien elaborada, la toma de decisiones ocurre en los niveles superiores de la jeraIC"
y, por tanto, se encuentran primero. Si existen problemas de control importan....
resulta esencial reconocerlos desde el principio. Si se selecciona la integracin ..
mero-en-profundidad, es posible implementar y demostrar una funcin completa _
software. Por ejemplo, imagnese una estructura de transaccin clsica (captulo
en que una serie compleja de entradas interactivas se solicita, adquiere y valida medio de una ruta de entrada. Tal vez ese camino est integrado en forma desee
dente. Todo el procesamiento de entrada (para el envo de las siguientes transacc
CAPTULO 13
ESTRATEGIAS DE PRUEBA DEL SOF7WARE
397
nes) podra demostrarse antes de que otros elementos de la estructura se hayan integrado. La demostracin temprana de la capacidad funcional genera confianza en el
desarrollador y en el cliente.
La estrategia descendente no parece muy complicada, pero en la prctica llegan
a surgir problemas de logistica. El ms comn se presenta cuando se requiere procesamiento en los niveles inferiores de la jerarquia para probar de manera adecuada los niveles superiores. Al principio de la prueba descendente se reemplazan los
mdulos de bajo nivel con resguardos; por tanto, no fluirn datos importantes hacia
la parte superior de la estructura del programa. Quien aplica la prueba cuenta con
tres opciones: 1) retrasar muchas de las pruebas hasta que los resguardos sean
reemplazados con los mdulos reales, 2) desarrollar resguardos que realicen funciones limitadas que simulen los mdulos reales, o 3) integrar el software de la parte
inferior de la jerarqua hacia arriba.
El primer enfoque (retrasar las pruebas hasta no reemplazar los resguardos con
los mdulos reales) hace perder cierto control sobre la correspondencia entre prue-
bas especificas y la incorporacin de mdulos especlficos. Con esto se dificulta

determinar la causa de los errores y se tiende a violar la naturaleza altamente restringida del enfoque descendente. Es posible trabajar con el segundo enfoque, pero
puede llevar a un aumento importante de la sobrecarga de trabajo, a medida que los
resguardos se vuelvan ms y ms complejos. El tercer enfoque, denominado prueba
ascendente, se expondr en la siguiente seccin.
Integracin ascendente. La prueba de integracin ascendente, como su nombre lo

indica, empieza la construccin y la prueba con mdulos atmicos (es decir, componentes de los niveles ms bajos de la estructura del programa). Debido a que los
componentes se integran de abajo hacia arriba, siempre est disponible el procesamiento requerido para los componentes subordinados a un determinado nivel y se
elimina la necesidad de resguardos. Una estrategia de integracin ascendente se implementa mediante los siguientes pasos:
Cules son
los pasos
!fll'I IDO integra
-
IIS(tndente?
l. Se combinan los mdulos de bajo nivel en grupos (tambin llamados construcciones) que realicen una subfuncin especfica del software.
2. Se escribe un controlador (un programa de control para pruebas) con el fin de
coordinar la entrada y la salida de los casos de prueba.
3. Se prueba el grupo.
4. Se eliminan los controladores y se combinan los grupos ascendiendo por la

estructura del programa.
La integracin sigue el patrn ilustrado en la figura 13.6. Los componentes se
combinan para formar los grupos J, 2 y 3. cada uno de ellos se prueba empleando
un controlador (mostrado como un recuadro con guiones). Los componentes de los
grupos I y 2 estn subordinados a M 0 Los controladores C1 y C2 se eliminan y los grupos interaccionan directamente con M .,. De igual manera, se elimina el controlador
398
PARTE DOS
PRCTICA DE LA INGENIERA DEL SOFIWARE
iiMlifl
Integracin
ascendente.
Grupo 3
Grupo 1
Grupo 2
del grupo 3 antes de la integracin con el mdulo Mt>. M0 y M0 se integrarn fmente con el mdulo Me, y as sucesivamente.
C3
A medida que la integracin asciende se reduce la necesidad de controladores

prueba separados. En realidad, si los dos niveles superiores de la estructura del ;:
grama se integran de manera descendente, se reducir de manera importan..:
nmero de controladores y se simplificar enormemente la integracin de grup..
Prueba de regresin. Cada vez que se agrega un nuevo mdulo como panc
una prueba de integracin, el software cambia. se establecen nuevas rutas de
de datos, ocurren nuevas entradas y salidas y se invoca una nueva lgica de con
Estos cambios Uegan a causar problemas con funciones que antes funcionaban tA
Lo pruebo de
regresin es uno estrotegio importante poro
reducir *efectos
coloteroles*. Deben
aplicarse pruebas de
regresin codo vez
que se hago un
cambio importante o/
software (incluido lo
integracin de nuevos
componentes).
En el contexto de una estrategia de prueba de integracin, la aplicacin de una ~

ba de regresin consiste en ejecutar nuevamente el mismo subconjunto de pruc
que ya se ha aplicado para asegurarse de que los cambios no han propagado e
tos colaterales indeseables.
En un contexto ms amplio, si las pruebas (de cualquier tipo) tienen xit~
resultado es el descubrimiento de errores, y stos deben corregirse. Cada vez <rsoftware se corrige tambin cambia algn aspecto de la configuracin del sofi'
(el programa, su documentacin o los datos de soporte). La prueba de regresi'"
una actividad que ayuda a asegurar que los cambios (debidos a la prueba u ....
razones) no introduzcan comportamiento indeseable o errores adicionales.
La prueba de regresin se aplica manualmente, al ejecutar de nueva cuent:
subconjunto de todos los casos de prueba o al emplear herramientas automtica.
CAPTULO 13 ESTRATEGIAS DE PRUE:BA DD. SOF.WAm;
captura, reproduccin, o ambas. Las
heIIamientas de captura, reproduccin,
399
de
ambos tipos, permiten al ingeniero del software capturar casos de prueba y resultados para reproducirlos y compararlos despus. El conjunto de pruebas de regresin
(el subconjunto de pruebas que se aplicarn) contiene tres clases diferentes de casos
de prueba:
Una muestra representativa de pruebas que ejercern todas las funciones del
software.
Pruebas adicionales que se concentran en las funciones del software que
probablemente el cambio afectara.
Pruebas que se concentran en los componentes del software que han
cambiado.
A medida que avanza la prueba de integracin, la cantidad de pruebas de regresin
llega a volverse muy grande. Por tanto, el conjunto de pruebas de regresin debe
disearse para que slo incluya las que atienden una o ms clases de errores en cada
una de las funciones principales del programa. Resulta poco prctico e ineficiente
repetir cada prueba para todas las funciones del programa despus de que se ha presentado un cambio.
Prueba de humo. La prueba de humo es un enfoque de prueba de integracin que

suele utilizarse mientras se desarrollan productos de software. Est diseado como
mecanismo para marcar el ritmo en proyectos en los cuales el tiempo es crtico, lo
que permite que el equipo de software evale su proyecto con frecuencia. En esencia, el enfoque de la prueba de humo abarca las siguientes actividades:
1.
Los componentes de software traducidos a cdigo se integran en una "construccin", la cual incluye todos los archivos de datos, las libreras, los mdulos reutilizables y los componentes de ingeniera que se requieren para
implementar una o ms funciones del producto.
2.
Se disea una serie de pruebas para exponer errores que impedirn que la
construccin realice apropiadamente su funcin. El objetivo es descubrir errores "paralizantes" que tengan la mayor probabilidad de retrasar el proyecto de
software.
3.
el soflwore
La construccin se integra con otras construcciones, y diariamente se aplica

una prueba de humo a todo el producto (en su forma actual). El enfoque de la
integracin puede ser descendente o ascendente.
La aplicacin diaria de una prueba a todo el producto sorprender a algunos lecto-
res. Sin embargo, las pruebas frecuentes dan a los jefes de proyecto y participantes
una evaluacin realista del avance de las pruebas de integracin. McConnell
[MC096J describe as la prueba de humo:
400
PARTE DOS PRCTICA DE LA INGENlERA DEL S0f1WARE

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 hwr
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 proporciona varios beneficios cuando se aplica en proyect

ingeniera del software complejos y que dependen en forma crtica del tiempo
Se minimiza el riesgo en la integradn. Debido a que las pruebas de humo se

aplican diariamente, desde el principio se descubren las incompatibilidac..:s
otros errores paralizantes, por lo que se reduce la probabilidad de que t
un fuerte impacto en el calendario cuando se descubran errores.
Se mejora la calidad del producto final. Como el enfoque est orientado a

construccin (integracin). es probable que la prueba de humo descubra
errores funcionales, arquitectnicos y al nivel de componentes. Si estos
errores se corrigen desde el principio, se obtendr una mayor calidad er
producto.
Se simplifican el diagnstico y la correcdn de errores. Como todos los e"r
de prueba de integracin, es probable que los errores no descubiertos e
prueba de humo estn asociados con "nuevos incrementos de softwaresoftware que se acaba de aadir a la construccin es una posible causa
error recin descubierto).
El progreso es ms fcil de evaluar. Cada da que pasa se integra ms s....
y se demuestra que funciona. Esto mejora la moral del equipo y brinda a
jefes de proyecto una buena indicacin de que se estn logrando a v ~
Trate lo consttucrin diario como si fuero el corazn del proyecto. Si no fiene coroz6n, el proyecto est rooer1L
Jilll
Opciones estratgicas. Ha habido mucha discusin (por ejemplo, (BEISlas ventajas y desventajas relativas de las pruebas de integracin ascende:- ~
cendente. En general, las ventajas de una estrategia tienden a convertirse e:-
ih/ i1Htlf1
Apunmdores a
comen11Jrios sobre
eslrolegios de pruebo
se encontrorn en:
www.qalilks.<ot1.
tajas para la otra. La principal desventaja del enfoque descendente es la nec=~

resguardos y las dificultades de las pruebas asociadas. Los problemas reLaao::;
con los resguardos se compensaran con la ventaja de probar las principal~
nes de control en las primeras etapas. La principal desventaja de la rll1'-........
ascendente es que "el programa, como una entidad, no existe hasta que se
dicto el ltimo mdulo" (MYE79]. Esta desventaja la atena la mayor fa
disear casos de prueba y la falta de resguardos.
La seleccin de una estrategia de integracin depende de las caracten
software y, en ocasiones, del calendario del proyecto. En general, la mejor
un enfoque combinado (a veces denominado prueba sndwich) que usa p
CAPTULO 13 ESTRATEGIAS DE PRUEBA Dfl. SOFTWARE
401
cendentes para los niveles superiores de la estructura del programa, junto con pruebas ascendentes para los niveles subordinados.
a. es un
..ctulo crtico
, por qu
*nfificarse?
A medida que se realiza la prueba de integracin, el responsable debe identificar

mdulos crticos. Un mdulo crtico tiene una o ms de las siguientes caractersticas:
1) atiende varios requisitos del software, 2) tiene un alto grado de control (se encuentra 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 mdulos
crticos deben probarse lo antes posible. Adems, las pruebas de regresin se deben
concentrar en el funcionamiento de los mdulos crticos.
Documentacin de la prueba de integracin. Un plan general para la integracin del software y una descripcin de pruebas especficas se documentan en la
Especificacin de la prueba. Este documento que contiene un plan de prueba, un procedimiento de prueba, es un producto de trabajo del proceso de software y se vuelve parte de la configuracin del software.
El plan de prueba describe la estrategia general de integracin. La prueba se divide en fases y construcciones que atienden caractersticas especificas del funcionamiento y el comportamiento 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, representacin del despliegue, procesamiento de errores y representacin).
Manipulacin y anlisis de datos (creacin de smbolos, asignacin de dimensiones, rotacin, clculo de propiedades fisicas).
Procesamiento y generacin de despliegue (despliegues bi y tridimensionales,
imgenes y grficas).
Administracin de base de datos (acceso, actualizacin, integridad,
desempeo).
Cada una de estas fases y subfases (denotadas entre parntesis) delinean una amplia
categora funcional dentro del software y suelen relacionarse con un dominio especifico dentro de la arquitectura del software. Por tanto, las construcciones del programa (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 externas se prueban a medida

que cada mdulo (o grupo) se incorpora en la estructura.
Validez funcional. Se realizan las pruebas diseadas para descubrir errores funcionales.
Contenido de la informadn. Se aplican las pruebas diseadas para descubrir errores asociados con estructuras de datos locales o globales.
PARTE DOS
PRCTICA DE U>. INGENIERA DEL SOF'!WARE
Desempeo. Se realizan las pruebas diseadas para verificar los lmites de dese=
peo establecidos durante el diseo del software.
Un calendario para la integracin, el desarrollo de software de sobrecarga :
temas relacionados tambin se analizan como parte del plan de prueba. Se dete-::
nan las fechas de inicio y trmino para cada fase y se definen las "ventanas de _
ponibilidad" para los mdulos de prueba de unidad. Una breve descripcin del s.
ware de sobrecarga (resguardos y controladores) se concentra en las caractens1
que requieren esfuerzos especiales. Por ltimo, se describen el entorno y los re
sos de la prueba. Configuraciones poco comunes de hardware, simuladores exo_
y herramientas especiales de prueba son algunos de los muchos temas que tan:
podran analizarse.
A continuacin se describe el procedimiento detallado de prueba que se r
para completar el plan respectivo. Tambin se detalla el orden de integracir ~
pruebas correspondientes en cada paso de integracin. Adems, se incluyer
lista de todos los casos de prueba (anotados para referencia posterior) y los ~
dos esperados.
Una historia de resultados, problemas o peculiaridades de las pruebas r ~
registra en el Informe de prueba que puede adjuntarse a la Especificacin de
Si se desea, la informacin contenida en esta seccin ser vital durante el mar:::::
miento del software. Tambin se presentan referencias y apndices apropiad..s.
Como todos los dems elementos de una configuracin de software, el f..
de la especificacin de prueba puede amoldarse a las necesidades locales ~
organizacin de ingeniera del software. Sin embargo, es importante obsen.-a:r
una estrategia de integracin (contenida en el plan de prueba) y los detalles de
ba (descritos en el procedimiento de prueba) son ingredientes esenciales )
aparecer.
a mejor par1ipcllle de UllD pruebo no es el que encuen1TD ms errores... sino el que corrige lo mayor amtidad de ala:
CeaK_.,.
13.4 EstBhiliJAS PI PBVEIA PABA $9fTW6RI PBJIBtAPP A QB.JEJ f

El objetivo de probar, para definirlo de manera simple, es encontrar la mayO""
dad de errores aplicando una cantidad manejable de esfuerzo en un periodo
ta. Aunque este objetivo fundamental sigue sin cambio para el software orier
objetos, la naturaleza de este software cambia la estrategia y la tctica de las
bas (captulo 14).
13.4. l
Prueba de unidad en el contexto orientado a objetos
Al pensar en el software orientado a objetos cambia el concepto de unidz.::..

encapsulacin orienta la definicin de clases. Esto significa que cada clase e
cia de una clase (objeto) empaqueta atributos (datos) y las operaciones (fur
que manipulan estos datos. Una clase encapsulada suele ser el eje de las p,"""......___ ,
CAPTULO 13
ESTRATEGIAS DE PRUEBA OEl. SOf1WARE
403
unidad. Sin embargo, las unidades de prueba ms pequeas son las operaciones
dentro de la clase. Debido a que una clase puede contener varias operaciones diferentes y a que una operacin determinada puede existir como parte de varias clases
diferentes, deben cambiar las tcticas aplicadas para la prueba de unidad.
No es posible probar una sola operacin de manera aislada (el concepto convencional de prueba de unidad) sino como parte de una clase. Para ilustrarlo, considrese una jerarqua de clase en que se define una operacin X para la superclase y que
heredan varias subclases. Cada una de stas usa la operacin X, pero se aplica dentro del contexto de los atributos privados y las operaciones que se han definido para
la subclase. Dado que el contexto en que se emplea la operacin X vara en formas
sutiles, es necesario probar la operacin en el contexto de cada una de las subclases. Esto significa que si se prueba la operacin X de manera independiente (el enfoque de la prueba de unidad convencional) se podr usar de manera deficiente en el
contexto orientado a objetos.
La prueba de clase para el software orientado a objetos es el equivalente a la
prueba de unidad para el software convencional. A diferencia de sta, que tiende a
concentrarse en el detalle algortmico de un mdulo y en los datos que fluyen por la
interfaz del mdulo, la prueba de clase para el software orientado a objetos se orienta mediante las operaciones que encapsula la clase y en el comportamiento de estado de la clase.
13.4.2 Prueba de integracin en el contexto orientado a objetos

Debido a que el software orientado a objetos no tiene una estrategia obvia de control jerrquico, tienen poco significado las estrategias de integracin descendente y
ascendente tradicionales (seccin 13.3.2). Adems, integrar las operaciones una por
una en una clase (el enfoque convencional de la integracin incremental) suele
resultar imposible debido a las "interacciones directas e indirectas de los componentes que integran la clase" [BER93J.
Hay dos estrategias diferentes para la prueba de integracin de los sistemas orientados a objetos [B1N94]. La primera, la prueba basada en subprocesos, integra el conjunto de clases requerido para responder a una entrada o un evento del sistema.
Cada subproceso se integra y prueba individualmente. La prueba de regresin se
aplica para asegurar que no se presenten efectos colaterales. El segundo enfoque de
"tlO(esos son
...intos de doses
responden ouno
";:do oun evento.
;?Uebos basados
.A uso se
::-tentron en los
:WS que no
,dioron mucho con
-:is doses.
integracin, la prueba basada en el uso, empieza la construccin del sistema con la

prueba de esas clases (llamadas clases independientes) que usan muy pocas clases de
servidor (o ninguna). Despus de que se prueban las clases independientes, se prueba la siguiente capa de clases, llamadas clases dependientes, que usan las clases
independientes. Esta secuencia de capas de prueba de clases dependientes contina
hasta que se construye todo el sistema.
El uso de controladores y resguardos tambin cambia cuando se aplican pruebas
de integracin a los sistemas orientados a objetos. Con los controladores se prueban
operaciones al nivel ms bajo y grupos completos de clases. Un controlador tambin
PARTE DOS PRCTICA DE LA INGtNIERiA DEL SOFTWARE
404
se utiliza para reemplazar la interfaz de usuario, de modo que puedan aplicarse ~

pruebas de funcionalidad del sistema antes de la implementacin de la interfaz. ....
resguardos se usan en situaciones en que la colaboracin entre clases es necesa.pero en las cuales an no se han implementado por completo una o ms de las c.
ses que colaboran.
La prueba de grupo es un paso en la prueba de integracin del software orie..do a objetos. Aqu, un grupo de clases que colaboran entre s (determinadas ?
examen del CRC y el modelo objeto-relacin) se ejercita al disear casos de pn..:.:::::::
que tratan de descubrir errores en las colaboraciones.
13.5 2BVll6$ PI YALJPA,cr6N
&l
'~
c&v1
Como todos los dems

posos de pruebo, en lo
volidoci6n se troto de
descubrir errores, pero
el punto central est
en el nivel de los
requisitos (o los cosos
que sern
inmedotomente
evidentes poro el
usuario final).
Las pruebas de validadn empiezan tras la culminacin de la prueba de integra.::

cuando se han ejercitado los componentes individuales, se ha terminado de ens
blar el software como paquete y se han descubierto y corregido los errores de r
faz. En el nivel de validacin o sistema desaparece la distincin entre software
vencional y orientado a objetos. La prueba se concentra en las acciones visibles
el usuario y en la salida del sistema que ste puede reconocer.
La validacin se define de muchas formas, pero una definicin simple (a
vulgar) es que se alcanza cuando el software funciona de tal manera que satisf~
expectativas razonables del cliente. En este punto, un desarrollador de software e
rimentado protestaria: "Qu o quin decide lo que es una expectativa razonable
Las expectativas razonables se definen en la Especijicadn de requisitos da
ware (un documento que describe los atributos del software visibles para el ~
La especificacin contiene una seccin denominada Criterios de validacin. La
macin contenida en esa seccin integra la base del enfoque de la prueba de
dacin.
13.5.1
Criterios de la prueba de validacin
La validacin del software se logra mediante una serie de pruebas que demu
que se cumple con los requisitos. Un plan de prueba delinea la clase de prueba.;
se aplicarn, y un procedimiento de prueba define los casos de prueba espec.
Tanto el plan como el procedimiento se disean para asegurar que se satis.
todos los requisitos funcionales, que se alcanzan todas las caractersticas de
portamiento, que se cumple con todos los requisitos de desempeo, que la
mentacin es correcta y que se cumple tambin con todos los requisitos de facf:
de uso y otros requisitos especificados (por ejemplo, portabilidad, compatib..
recuperacin de errores, facilidad de mantenimiento).
Despus de que se ha dirigido cada caso de prueba de validacin, existir t-.
dos condiciones posibles: I) la caracteristica de funcionamiento o desempee
ple con la especificacin y se le acepta, o 2) se descubre una desviacin de la
cificacin y se crea una lista de deficiencias. La desviacin o el error descub,~
CAPTULO 13
ESTRATEGJASDEPRUEBAOEI..SO..~
405
esta etapa de un proyecto rara vez se corrige antes de la fecha de entrega. A menudo es necesario negociar con el cliente un mtodo para resolver las deficiencias.
13.5.2 Revisin de la configuracin

La revisin de la configuracin es un elemento importante del proceso de validacin;
su objetivo es asegurar que todos los elementos de la configuracin del software se
hayan desarrollado apropiadamente, estn catalogados y tengan el detalle suficiente para reforzar la fase de soporte del ciclo de vida del software. La revisin de la
configuracin, a veces denominada auditora, se analizar con ms detalle en el
captulo 27.
13.5.3 Pruebas alfa y beta

En la prctica es imposible que un desarrollador de software prevea cmo utilizar
el usuario realmente el programa. Es posible que se malinterpreten las instrucciones
de uso, que se utilicen con regularidad extraas combinaciones de datos, que una
salida en apariencia clara para el responsable de las pruebas sea ininteligible para
un usuario en el campo.
Al construir software personalizado para un cliente se aplica una serie de pruebas de aceptacin que permiten al cliente validar todos los requisitos. El usuario final
conduce, no los ingenieros del software, las pruebas de aceptacin, las cuales van
desde una "prueba de manejo" informal hasta una serie de pruebas planeadas y ejecutadas de manera sistemtica. En realidad, la prueba de aceptacin llega a durar
semanas o meses, por lo que es posible descubrir errores acumulativos que degradan el sistema.
"Si se rerurre o~ sufkientes, todos los errores sern superficiales (por ejemplo, si hoy unu buse kr Miderllemenfe
gnm4e de ~rsonos que realizan los pruebas beta y de codesarrollodores, cosi todo$ lS problemas se catferizarat,. 1
nipkfomente y 111 <Ofreccin ser obvia para alguien).
l!l ,)
,. ( ,,i/
Si el software se desarrolla como un producto que usarn muchos clientes, no es

prctico realizar pruebas de aceptacin formales para cada uno. La mayora de los
constructores de productos de software emplean procesos llamados prueba alfa y
prueba beta para descubrir errores que slo el usuario final podra detectar.
Los usuarios finales son quienes aplican la prueba alfa en el lugar de trabajo del
desarrollador. El software se utilza en un entorno natural mientras el desarrollador
"mira sobre el hombro" de los usuarios tpicos y registra los errores y los problemas
de uso. Las pruebas alfa se realizan en un entorno controlado.
Las pruebas beta se aplican en el lugar de trabajo de los usuarios finales. A diferencia de la prueba alfa, por lo general el desarrollador no est. Por tanto, la prueba
beta es una aplicacin "en vivo" del software en un entorno que no controla el desarrollador. El usuario final registra todos los problemas (reales o imaginarios) que
PARTE DOS
406
PRA.cnCA DE LA INGENIERA DEL SOFTWARE
encuentra durante la prueba y los informa de manera regular al desarrollador. C..

resultado de los problemas informados durante las pruebas beta, los ingenieros software Jo modifican y luego preparan la liberacin del producto de software ~
toda la base de clientes.
HoGARSEGURO
~
Prep4radn para validadn
~ 1a escena: Oficina de Doug

Mile,1 mientras (Ollln\a ef diseo al nivel de
componentes y empieza lo con~6n de ciertos
~-\os octeNs: Ooug Millet, jefe de ngenierio de
~ , Vll'IOd,Jamie, Ed y Shokiro, inlegrantes del
~ d ingenieria dl whware- HogarSegvro.
lj convertodn:
. ~ Et pnmer incremetrto estor lsto poro validacin
semanas~
VMdl Es corteclo. Lo integrocin w bien. Estamos
tilali~ pruebas de humo a diario, encontrando
~ n'OnlS, pero nada que no s e ~ monejor.
*"'*fflK
~ (l!l!t La9b ahora todo YO bien.

~~ un poc:o de la volidocin.
.. . . . . . . . . emplearemos todos los C0$0$ de uso

el diMo de nuesll'm pruebas. An no
he -.,..zado, pero estar desarmllondo pruebas poro
todos los CXJSOS de uso de los que ,cy responsable.
.--paro
lcl: Lo mismo yo.

JaMie: Yo tambin, pero tendremos que advar junios
paro lo prueba de aceplacin y tambin para los
~ offa y befa, wirdad~
Doug: S, en rJlidod he pensado que podomos tras

un contratislo que 11()$ ayude CIOl'l l o ~ -. . .
dinero en el .............. .-...... yno1doriounapenpeclila
,..~~
fresco.
od C
lo
~..1- 1..:.:
--~~-
Vtn : reo que lenemcl$ ,_....jo~Doug: Estoy seguro de 9$0, pero un grupo
iodependiente de pruebo nos dar un punlo de vista
autnomo sobre el sohware.

Jamie: Eslamos justos de lianpo aqui, Doug. Yo, en
personal, no tengo tiempo para cuidas: o nadie que
traigas o hacer el trobojo.
Doug: lo s, lo s. Pero si un GIP trobaja a partir el.

requisitos y cosos de uso, no requerir mucho ayudo
ustedes.
Yinod: Todovo pienso que lo lanemos todo bajo
Doug: Yo le oi, Vinod, pero me voy, a imponer en
Planeemos el encuentro con el rapesalkll del GF
adelante, esto mismo semono. Dejemos que empiect
veaffl()$ que nc>l lroe.
Yinod: Mvy bien, tal \19% aligere 1,11'1 poc:o la carga.
En el inicio de este libro se destac el hecho de que el software slo es un e

to de un sistema de cmputo ms grande. Al final, el software se incorpora ;:;
elementos del sistema (como hardware, personas, informacin), y se realt:.J
serie de pruebas de integracin del sistema y de validacin. Estas pruebas esta:"
all del alcance del proceso del software y no las realizan nicamente los i ..
ros del software. Sin embargo, los pasos dados durante el diseo y la prueba e,
ware mejorarn en gran medida la probabilidad de tener xito en la integraa
software en el sistema mayor.
"Al iglal que la muerte ylos impuestos, los pruebas son desogro-dobles e inevitables."
CAPTULO 13
ESTRATEGLAS DE PRUEBA DEL SCFIWARE
407
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 anticiparse a posibles problemas con la interfaz y I J disear rutas de manejo de errores que
prueben toda la informacin proveniente de otros elementos del sistema, 2) aplicar
una serie de pruebas que simulen datos incorrectos u otros posibles errores en la interfaz del software, 3) registrar los resultados de las pruebas como "evidencia" en el caso
de que se Je 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 propsito principal es ejercitar profundamente el sistema de cmputo. Aunque cada
prueba tiene un propsito diferente, todas trabajan para verificar que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones
apropiadas. En las siguientes secciones se examinarn los tipos de pruebas del sistema [BEI84J que valen la pena para sistemas basados en software.
13.6.1 Prueba de recuperacin

Muchos sistemas de cmputo deben recuperarse de fallas y reanudar el procesamiento en un tiempo determinado. En algunos casos, un sistema debe ser tolerante
con las fallas; es decir, las fallas de procesamiento no deben llevar a la cada del sistema. en general. En otros casos. una falla del sistema debe corregirse dentro de un
periodo especfico o se sufrir un fuerte dao econmico.
La prueba de recuperacin es una prueba del sistema que obliga al software a
fallar de varias maneras y a verificar que la recuperacin se realice apropiadamente. Si la recuperacin es automtica (la realiza el propio sistema) debe evaluarse que
sean correctos la reinicializacin, los mecanismos de respaldo del sistema, la recu peracin de datos y el nuevo arranque. Si la recuperacin requiere intervencin
humana, se debe evaluar el tiempo medio de reparacin (TMR) para determinar si se
encuentra dentro de lmites aceptables.
13.6.2 Prueba de seguridad

Cualquier sistema de cmputo que maneje informacin confidencial o que desencadene 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, empleados
disgustados que tratan de irrumpir como forma de venganza, e individuos deshonestos que buscan ganancias personales ilcitas.
La prueba de seguridad comprueba que los mecanismos de proteccin integrados
en el sistema realmente lo protejan de irrupciones inapropiadas. Para citar a Beizer
[BEI84]: "Por supuesto que debe probarse la seguridad del sistema para asegurar que
es invulnerable a los ataques frontales, pero tambin a los perpetrados por los flancos o la retaguardia".
408
PARTE DOS
PRAcnCA DE LA INGENIERA DEL SOFTWARE
Durante la prueba de seguridad, quien la aplica desempea el papel del individ-que desea entrar en el sistema. Todo se vale! Debe tratar de obtener contraserpor cualquier medio externo; podra atacar el sistema con software personaliza:::.
diseado para burlar cualquier defensa que se haya construido; podra saturar el s
tema, negando as el servicio a otros; podra producir errores intencionales en el SS'
ma para tratar de tener acceso durante la recuperacin; podra revisar datos sin ,;,leccin, con la idea de encontrar la clave de acceso al sistema.
Si se dan el tiempo y los recursos suficientes, una buena prueba de seguridad
minar por irrumpir en el sistema. El papel del diseador del sistema es que el ce
de la irrupcin sea mayor que el valor de la informacin que habr de obtenerse
13.6.3 Prueba de resistencia

Los pasos de prueba analizados antes, en este mismo captulo, llevan a una eva
cin completa de las funciones y el desempeo normales del programa. Las pruc
de resistencia estn diseadas para confrontar los programas con situaciones a.males. En esencia, la persona que realiza la prueba de resistencia se pregun
"Hasta dnde puedo llevar esto antes de que falle?"
La prueba de resistenda ejecuta un sistema de tal manera que requiera una
dad, una frecuencia o un volumen anormal de recursos. Por ejemplo: 1) s e ~
pruebas especiales que generen diez interrupciones por segundo, cuando la
promedio es de una o dos; 2) se aumenta l a frecuencia de entrada de datos ermagnitud que permita determinar cmo respondern las funciones de entrada
ejecutan casos de prueba que requieran el mximo de memoria u otros recufS('c
se disean casos de prueba que causen problemas de administracin de mer5) se crean casos de prueba que produzcan bsquedas excesivas de datos en el ~
En esencia, la persona que aplica la prueba tratar de sobrecargar el programa
"Si est tratando dt encontrar vtrdocleros errores del sistema y no ha sometido su software o una verdadera prua
de resistencia, entonces ste es el momentode empezar.
lorisW.
Una variante de la prueba de resistencia es una tcnica denominada prue__
sensibilidad. En algunas situaciones (la ms comn de ellas ocurre con los a =
mos matemticos), un rango muy pequeo de datos contendidos dentro de los
tes de los datos vlidos para un programa puede causar procesamiento extre-:::
incluso errneo, o una fuerte degradacin del desempeo. Las pruebas de sens
dad tratan de descubrir combinaciones de datos dentro de las clases de entrad:
das que causen inestabilidad o procesamiento inapropiado.
13.6.4 Prueba de desempeo

En sistemas en tiempo real e incrustados es inaceptable el software que pro
na la funcin requerida pero que no cumple los requisitos de desempeo. La
de desempeo est diseada para probar el desempeo del software en tiea-
CAPTULO 13 ESTRATEGIAS DE PRUEBA OO. SOFTWARE
409
ejecucin dentro del contexto de un sistema integrado. La prueba de desempeo se

aplica en todos los pasos del proceso de la prueba. Incluso al nivel de la unidad, el
desempeo de un mdulo individual debe evaluarse mientras se realizan las pruebas.
Sin embargo, no es sino hasta que se encuentran totalmente integrados todos los elementos del sistema que es posible asegurar el verdadero desempeo del sistema.
Con frecuencia las pruebas de desempeo se vinculan con pruebas de resistencia
y suelen requerir instrumentacin de software y hardware. Es decir, a menudo resulta necesario medir con exactitud la utilizacin de recursos (por ejemplo, los ciclos de
procesador). Mediante instrumentacin externa pueden vigilarse de manera regular
los intervalos de ejecucin, los eventos 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.
Planeaein y administracin
de pruebas
Objetivo: Estos herramientas ayudan al
de software a planear la estrategia de prueba que
"'O de elegirse y a manejar el proceso de prueba a
oo que se aplica.
llacnica: las herramientas de esta categora atienden
.oneacin y el almacenamiento de la prueba, la
x:- ...,stracin y el control, el seguimiento de los
sitos, la integracin, el rastreo de errores y la
z-erocin de informes. Los jefes de proyecto las uson
complementar las herramientas de planeacin.
.enes aplican las pruebas usan estas herramientas para
:t:near actividades de prueba y controlar el flujo de
~cin a medida que avanza el proceso de prueba.
Herramientas representativa s2
OTF (Object Tesfing Framework), desarrollado por MCG
Software lnc. (www.mcgsoft.com), proporciona un
marco conceptual para la administracin de conjuntos
de pruebas para objetos Smalltalk.
QADirector, 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 lnc.
(www.soft.com/Products/index, html), contiene un
conjunto plenamente integrado de herramientas de
prueba, incluidas algunas que sirven poro el manejo y
la generacin de informes de las pruebas.
La prueba del software es un proceso que puede planearse y especificarse sistem-
ticamente. Se disea el caso de prueba, se define una estrategia y se evalan los

resultados frente a las expectativas prescritas.
La depuracin ocurre como consecuencia de una prueba realizada con xito. Es
decir, cuando un caso de prueba descubre un error, la depuracin es la accin que
lo elimina. Aunque la depuracin puede y debe ser un proceso ordenado, sigue siendo un arte. Un ingeniero del software, al evaluar los resultados de una prueba, suele
Las herramientas expuestas aqu slo representan una muestra de esta categora. En casi todos los
410
PARTE DOS
PRCTICA DE LA INGDIIERA DEL SOF1WARE
enfrentarse con una indicacin "sintomtica" de un problema de software. Es decc_

tal vez la manifestacin externa del error y su causa interna no tienen una relac
obvia. La depuracin es el proceso mental que conecta un sntoma con una causa.
"En cuanto empemmos la programocin, descubrimos, pero nuestra sorpresa, que no ser fcil conseguir el progrque tenemos en men1e. Es necesariodesmbrir lo depuracin. Reoierdo el momento exocto en que me di C1J8111o de que
magastar gran parte de mi vida, opartir de ese momento, en encontror los errores de mis propios programas.
Mnrke Wilkes, clescabre 11 depttadt ea 1Mt
13.7.1
El proceso de depuracin
La depuracin no es una prueba, pero siempre ocurre como consecuencia de t=:a

Si se toma como referencia la figura 13.7, el proceso de depuracin comienza c ~
ejecucin de un caso de prueba. Se evalan los resultados y se encuentra una

de correspondencia entre el desempeo esperado y el real. En muchos casos
datos que no corresponden son sntoma de una causa que an no aparece. La d
racin trata de relacionar el sntoma con la causa, Jo que conduce a corregir el err::
La depuracin siempre arroja dos resultados: 1) se encuentra y se corrige la
o 2) no se localiza la causa. En este ltimo caso, la persona encargada de la de'.7
cin debe sospechar la causa, disear uno o ms casos de prueba que ayuden a validar esa sospecha y avanzar hacia la correccin del error de manera iterati\a..
El proceso de
depuracin.
Cosos
de prueba
Pruebas
adicionales~
Pruebas
de regresin
"-
Correccione~
Causas
sospechados
~--------
Resultados
Depuracin
Causas _ _ identificados
....__ _ __.
3 Al hacer esta afirmacin se toma el concepto ms amplio posible de la prueba. No slo el d

llador prueba el soltware antes de la liberacin, sino que el cliente, el usuario, o ambos, pruoc:
software cada vez que lo usan!
CAPTULO 13 ESTRATEGIAS DE PRUEBA oa sonwARE
411
Por qu es tan dificil la depuracin? Con toda probabilidad, la respuesta se rela ciona ms con la psicologa humana (consulte la siguiente seccin) que con la tecnologa del software. Sin embargo, ciertas caractersticas de los errores ofrecen
algunas pistas:
1. El sntoma y la causa pueden estar separados geogrficamente. Es decir,

aqul aparece en una parte del programa mientras sta se ubica en un sitio
distante. Los componentes con un fuerte acoplamiento (captulo 11) exacerban esta situacin.
2. Es posible que el sntoma desaparezca (temporalmente) al corregir otro error.
3. Es probable que el sntoma no lo cause algn error (como en el caso de inexactitudes al redondear cifras).
4. El sntoma podra deberse a un error humano difcil de localizar.

5. El sntoma podra deberse a problemas de tiempo y no de procesamiento.
6. Tal vez sea dificil reproducir con exactitud las condiciones de entrada (por
ejemplo, una aplicacin en tiempo real en que no est definido el orden de
entrada).
7. El sntoma podra presentarse intermitentemente. Esto suele ser comn en

sistemas empotrados que acoplan el hardware y el software de manera inextricable.
8. Probablemente el sntoma se debe a causas distribuidas entre varias tareas

que se ejecutan en diferentes procesadores [CHE90].
Durante la depuracin se encuentran errores que van de medianamente molestos
(como un formato de salida incorrecto) a catastrficos (por ejemplo, el sistema falla
y causa serios daos econmicos o fisicos). A medida que aumentan las consecuencias de un error, tambin se incrementa la presin para encontrar la causa. A menudo, debido a la presin, un desarrollador del software introduce dos errores ms al
tratar de corregir uno.
-iodos soben que depurar es dos veces ms difcil que escribir el programo. Por tonto, si oplto todo su inteligeilcio
poro-tittibitlo, cmo espera siquiera depurarlo?#
13. 7 .2
'.f
Consideraciones psicolgicas
Por desgracia, hay evidencia de que las destrezas para la depuracin son innatas en
el ser humano. Ciertas personas son buenas para ella; otras no. Aunque la evidencia
experimental sobre la depuracin est abierta a muchas interpretaciones, se han
reportado grandes variaciones en la habilidad para la depuracin en programadores
con educacin y experiencia similares.
412
PARTE DOS
PRACTICA. DE LA INGDII!JlA DEL SOFTWARE
Al comentar los aspectos humanos de la depuracin, Shneiderman [SHN80] a

La depuracin es una de las partes ms frustrantes de la programacin. Incluye elern
tos de resolucin de problemas o de retos mentales, junto con el molesto reconocim1er

de que se ha cometido un error. La creciente ansiedad y escasa voluntad de aceptar la e~
tencia de errores aumentan la dificultad de la tarea. Por fortuna, se presenta un gran a
vio y la tensin decrece cuando el error finalmente ... se corrige.
Aunque sea dificil "aprender" a depurar, se proponen varios enfoques para el

blema. Se examinarn en la siguiente seccin.
HOGARSEGURO
.~
m.llii
Depuradn
LG escena: Cubculo de Ed
~ s e ~ lo codillcacio y la prueba de unidad.
1- 1!dOrNt Ed y Shokito, integrantes del equipo de
~ OEII software de HogarSeguro.
LG conversacin:
Shakins (asomndose a lo entrada del
Id: S, pero...
Shakira (enhunclo en el cubicul9): A ver, plll
el problema?
Ed: Es complic:odo. Yadems he edodo revisando_..
durante, cunto?, cinco horas. No vos o encontrarto.
Shakira: Perdname... tai6! es el ~

(Ed le explico el problema o Shakiro, que lo mira
30 segundos sin hablar.)
M&Juab caqui... lrobajondo.

Shakito: Te~ mol... qu es lo que poso?
su rostro): Miro, justo oqui, lo '-IOrioble
cvbiculo): Hey.. tdnde eslabas a la hora del
Ecl (suspirando con fuerza): He estado trabojando

en esta <bieep> error porque lo descubr a los 9:30 de la
maana, y son los 2 :45 y on no tengo una pisto.
Shaldrcr. Pens que estbamos de acuerdo en no
dedicar ms de una hora a depurar cosas por nuestra

wenlQ. fn ese coso, tendramos que busoar ayudo, o no?
Shakira (empiezo a pintarse una sonrisa

estabfecerCondicionAlormo. 2No deberlo ponerse en
#falso anle$ de qU4I inic~ el bucle?
(Ed se quedo viendo la panlallo 1in owrfo,.se inclina
hacia delante y empiezc o golpeQr su cabeza
gentilmente contra el monitor. Shakira, ohoro sonriendi,
ampliamente, se levanto y sok,.J
13.7.3 Estrategias de depuracin

Sin importar el enfoque que se adopte, la depuracin tiene un objetivo prima
encontrar y corregir la causa de un error del software. El objetivo se logra c
nando la evaluacin sistemtica, la intuicin
as el enfoque de la depuracin:
y la suerte. Bradley [BRA85] des.:
La depuracin es una aplicacin simple y directa del mtodo cientfico desarrollado ~
2 500 aos. La esencia de la depuracin consiste en ubicar la fuente del problema

causa] mediante particin binaria, manejando hiptesis de trabajo que predigan nue
valores que habrn de examinarse.
Tomemos un ejemplo sencillo, sin relacin alguna con el sonware: en mi casa no fi..:
ciona una lmpara. Si no funciona nada en la casa, la causa debe ser un fusib le fundid
una falla en el suministro de energa elctrica Miro alrededor para ver si hay luz en el
CAPTULO 13 ESTRATEGIAS DE PRUEBA DEL SOf'!Vt"AR!

cindario. Conecto la lmpara bajo sospecha en un enchufe que funcione
413
y un aparato en
buen estado en el enchufe bajo sospecha Y as_se siguen alternando hiptesis y pruebas.
En general, se han propuesto tres estrategias de depuracin [MYE79]: 1) fuerza

bruta, 2) seguimiento hacia atrs y 3) eliminacin de la causa.
I",
jp primilr poso poru torregir un programa es hacer que folle repetidamente (enel ejemplo ms simple ~ble)}ii
1,
' T. Dff
"
Tcticas de depuracin. La categora de depuracin por la fuerza bruta tal vez
sea el mtodo ms comn y menos eficiente para aislar la causa de un error del software. Los mtodos de depuracin por la fuerza bruta se aplican cuando todo Jo
dems falla. Al aplicar una filosofia de "dejemos que la computadora encuentre el
error", se hacen descargas de memoria, se invocan seales en tiempo de ejecucin
y se carga el programa con instrucciones de salida. En algn lugar del pantano de
informacin que se produce se espera encontrar una pista que pueda conducir a la
causa de un error. Aunque la gran cantidad de informacin producida conduzca
finalmente al xito, lo ms frecuente es que haga desperdiciar tiempo y esfuerzo.
El rastreo hacia atrs es un enfoque de depuracin muy comn, que se utiliza con
xito en pequeos programas. Empezando en el sitio donde se ha descubierto un
sntoma, se recorre hacia atrs el cdigo fuenle (manualmente) hasta hallar el sitio
de la causa. Por desgracia, a medida que aumenta el nmero de lneas del cdigo, la
cantidad de caminos hacia atrs se vuelve tan grande que resulta inmanejable.
El tercer enfoque para la depuracin (eliminacin de causas) lo determina la induccin o deduccin e introduce el concepto de particin binaria. Los datos relacionados
con el error se organizan para aislar las causas posibles. Se elabora una "hiptesis
de la causa" y se aprovechan los datos ya mencionados para probar o desechar la
hiptesis. Como opcin, se elabora una lista de todas las causas posibles y se aplican pruebas para eliminar cada una de ellas. Si las pruebas iniciales indican que
determinada hiptesis de causa es prometedora, se refinan los datos para tratar de
aislar el error.
Depuracin automatizada. Cada uno de los enfoques de depuracin anteriores
complementan las herramientas de depuracin que proporcionan soporte semiautomatizado al ingeniero de software mientras se intentan estrategias de depuracin.
Hailpern y Santhanam (HAI02J resumen el estado de estas herramientas cuando
indican: " ... se han propuesto muchos nuevos enfoques y se dispone de muchos
entornos de depuracin comerciales. Los entornos de desarrollo integrado (EDI) proporcionan una manera de capturar algunos de los errores por defecto especficos del
lenguaje (por ejemplo, caracteres faltantes de fin-de-instruccin, variables indefinidas, etc.) sin requerir compilacin." Un rea que ha atrapado la imaginacin de la
industria es la visualizacin de las construcciones de programacin necesarias como
medio de anlisis de programas [BAE97] Se cuenta con una amplia variedad de
compiladores de depuracin, ayudas dinmicas para la depuracin ("trazadores"),
generadores automticos de casos de prueba y herramientas de correlacin de refe-
414
PARTE DOS PRCTICA DE LA INGENIERA DE. SOFTWARE
~ Depuracin
~ Objetivo: Estas herramientos proporcionan
ayudo automatizada o quienes deben depurar
problemas de sofiware. El objetivo es proporcionar
conocimiento dificil de obtener si se afronto el proceso de
depuracin manualmente.
corodersticos de depuracin ayudan al diogn~

los errores encontrados.
GidEMe&c, desarrollado por NewPlanet Dolwore

(www.newplcr.etsoftwre.com/medie/), proporciono ,s-;
grfica poro el depurador UNIX eslndor, gel,
~ , ie, ila sus coroderisticos ms ~ntes . .Ac!ua:-?:a
gel, da sopor1e a C/C++, Javo, PolmOS, -.arios s i ~
incrustados, lenguaje ensomblador, FORTRAN y M:xJ..c-
imenaz
Mecnica: Casi lodos las herromientos de depuracin son

especficas del lenguaje de progromocin y del enlomo.
Herramientas representativas:4
Jprobe ThreadAnalyzer, desarrollado por Sitraka
(www.sitroka.com), ayudo en la evaluacin de
problemas de subprocesos: bloqueos, detenciones y
condiciones de carrera que representan serios peligros
para el desempea en aplicaciones de Java.
C++ Test, desarrollado por Parasoft (www.porasaft.com),
es una herromiento de pruebo de unidad que soporto
un amplio rango de pruebas en cdigo C y C++. los
BugCo/ledor Pro, cborrolkxlo por Nesbitt Software (.a,;:

(www.nesbitt.com/), implemento uno base de datos
multiusuario que ayudo ol equipo de software regisra
errores repor1ados y otros solicitudes de montenimienD
odministrocin de Rujo de trabajo de depuracin.
GNATS, uno aplicacin freewore

(www.gnu.org/ software/gnats/), es un conjunto~
herramientas poro registrar informes de error.
rencias cruzadas. Sin embargo, las herramientas no son un sustituto de la e,

cin cuidadosa basada en un modelo de diseo completo y un cdigo fuente
El factor humano. Ningn anlisis de los enfoques y las herramientas de
cin estara completo sin mencionar un poderoso aliado: los dems Un pu-::vista fresco, despejado de horas de frustracin, puede hacer maravillas.5 Una
ma final para Ja depuracin sera: "Cuando todo lo dems falJe, pida ayuda!
13.7.4 Correccin del error

Cuando se encuentra un error debe corregirse.
corregir un error pueden introducirse otros y, por lo tanto, causar ms dar.
solucionar el problema. Van Vleck [VAN89J sugiere tres preguntas simples que
ra plantearse todo ingeniero del software antes de hacer la "correccin" que
ne la causa del error:
1 . La causa del error se repite en
otra parte del programa? En muchas situad

un error se produce en un programa debido a un patrn errneo de lgica
podra repetirse en cualquier lugar. La consideracin explcita del patrn
gico puede llevar al descubrimiento de otros errores.
Cuando corri
ja un error,
qu preguntas
debo hacerme?
Las herramientas expuestas aqu representan una muestra de esta categora. En cas todos
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._
gramacin extrema analizado en el captulo 4) proporciona un mecanismo para la depuracir

tras se disea y codifica el software.
CAPTULO 13
rSI'RATEGIAS DE PRUEBA DEI. SOf7>VARE
415
2. Cul es el "siguiente error" que podra mtroducirse con la correccin que est a
punto de realizarse? Antes de la correccin se debe evaluar el cdigo fuente (o
mejor an, el diseo) para evaluar el acoplamiento entre las estructuras lgicas 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 aseguramiento de la calidad del software (captulo 26). Si se corrige el proceso junto
con el producto, se eliminar el error del programa actual y de todos los programas futuros.
La prueba ocupa el mayor porcentaje del esfuerzo tcnico en el proceso del software. 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 software es descubrir errores; se cumple planeando y
ejecutando una serie de pasos (pruebas de unidad, integracin, validacin y sistema). Las pruebas de unidad e integracin se concentran en la verificacin funcional
de cada componente y en la incorporacin de componentes en la arquitectura del
software. La prueba de validacin demuestra el cumplimiento con los requisitos del software, 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 di ferencia de la prueba (una actividad sistemtica y planeada), la depuracin
debe considerarse un arte. La actividad de depuracin empieza con la indicacin sintomtica de un problema y debe rastrear la causa del error. Entre los muchos recursos
disponibles durante la depuracin, el ms valioso es el consejo de otros integrantes
del equipo de ingeniera del software.
La necesidad de crear software 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 basaban el anlisis, el diseo y la codificacin.
En este captulo se ha examinado el espacio de prueba estratgico, tomando 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.
416
PARTE DOS
PRcnCA DE LA INGENIERA DEI. SOFIWARE
(BAE97] Baecker, R., C. DiGiano y A. Marcus, "Software Visualization of Debugg~

CommunicatonsoftheACM, vol. 40, nm. 4, abril de 1997 y otros ensayos en la misma
[BEI84] Beizer, B., Software System Testing and Quality Assurance, Van Nostrand-Reinhold
[BER93J Berard, E., ESS0fS on Objecl-Oriented Software Engineering, vol. l , Addison-Wesl~
(BlN94) Binder, R., ''Testing Object-Oriented Systems: A Status Report", en American Pr<--,...,...
vol. 7, nm. 4, abril de 1994. ruta crtica, pp. 23-28.
[BOE81J Boehm. B., Software Engineering Economics, Prentice-Hall, 1981, p. 37.
(BRA85J Bradley, J.H., "The science and Art of Debugging", en Computerworld, 19 de agas::=
1985, pp. 35-38.
[CHE90] Cheung, W. H., J. P. Black y E. Manning, u A Framework for Distributed Oebugg-.,
IEEE Software, enero de I 990, pp. 106-115.
[DUN82] Dunn, R. y R. UUman, Quality AssuranceJor Computer Software, McGraw-Hill, 1982 .,
[GlL95J Gilb, T., "What We FaJ To Do In Our current en Testing Culture", en Testing Tect
News/etter (edicin en lnea, ttn@soft.com), Software Research, !ne., enero de
[HAl02J Hailpem, B. y P. Santhanam, "Software Debugging, Testing and Verification", eJl
systems Joumal, vol. 41, nm 1, 2002, disponible en http://www.research.ibm.com
joumal/sj/411 /hailpem.htrnl.
[IEEO 1J Software Re/iability Engineering, / 2U1 Tntemational Symposium, IEEE, 2001.
[MC096J McConnell, S., "Best Praclices: Daily Build and Smoke Test", en IEEE Software
nm.4,juliode 1996. pp. 143-144.
[MlL77] Miller, E., ''The Philosophy ofTesting", en Program Testng Techniques, IEEE C
Society Press, 1977, pp. 1-3.
[MUS89J Musa, J. D. y A. F. Ackerrnan, "Quantifying Software Validation: When to Stop li
en IEEE Software, mayo de 1989, pp 19-27.
[MYE79J Myers, G., The Art ofSojtware Testng, Wiley, 1979.
[SH083J Shooman, M. L., Software Engineering, McGraw- Hill, 1983.
[SHNSOJ Shneiderman, B., software Psychology, Winthrop Publishers. 1980, p. 28.
(SrN99] Singpurwalla, N. y s. Wilson, Statistical Meiods in Software Engineering: Reliab.
Risk, Springer-Verlag. 1999.
[VAN89l Van Vleck, T., "Three Questions About Each Bug You find", en ACM Software En0
Notes, vol. 14, nm. s. julio de 1989, pp. 62-63.
[WAL.891 Wallance, D. R. y R. U. Fujii, "Software Verification and Validation: An Overvie
IEEE software, mayo de 1989, pp. 10-17.
[YOU75J Yourdon, E., Techniques ofProgram Structure and Design, Prentice-Hall, 1975.
13. 1. Con palabras propias, descnbase la diferencia entre verificacin y validacin. l,

mtodos de diseo de casos de prueba y estrategias de prueba?
13.2. Elabrese una lista de algunos problemas que pudieran estar asociados con la CJ'Cide un grupo independiente de prueba. Lo integran las mismas personas que el groaseguramiento de la calidad del software?
13.3. Siempre es posible desarrollar una estrategia para probar software que i....
secuencia de pasos de prueba descrita en la seccin 13. J.3? Cules son las po:
complicaciones que podran surgir para sistemas incrustados?
13.4. Por qu es dificil aplicar pruebas de unidad a un mdulo altamente acop
13.5. El concepto de "anti error" (seccin 13.3.1) es una manera extremadamente efectl
proporcionar depuracin integrada cuando se descubre un error:
a)
b)
e)
Desarrollar un conjunto de directrices antierror.

Analizar las ventajas de usar esta tcnica.
Analizar las desventajas de usar esta tcnica.
CAPTULO 13 ESTRA!EG!AS DE PRUEBA DEL SOFiWARE
417
13.6. Cmo afecta la calendarizacin la prueba de integracin?

13. 7. La prueba de unidad es posible (o incluso deseable) en Lodas las circunstancias?
Proporcionar ejemplos que justifiquen la respuesta
13.8. Quin debe aplicar la prueba de validacin: el desarrollador o el usuario del software?
Justifiquese la respuesta.
13.9. Desarrollar una estrategia de prueba completa para el sistema HogarSeguro analizado
en todo el libro. Documntese en una Especificacin de prueba.
13. l O. Como proyecto de clase, desarrollar una Gua de depuracin 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 temas 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 (Jntroducing Software Testing, Addison-Wesley, 2002), Whittaker (How To
Break Software. Addison-Wesley, 2002), Jorgensen (Software Testing: A Crajtman's Approach, CRC
Press, 2002). Splaine y sus colegas (The Web Testing Handbook, Software Quality Engineering
Publishing, 2001), Palton (Software Testng, Sams Publishing, 2000), Kaner y sus colegas (TesUng
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
Example, Addison-Wesley, 2002) presentan estrategias y tcticas de prueba para Programacin
Extrema. Kamer y sus colegas (Lessons Leamed 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 Ojf-the Shelf Testing Pmcess,
Cambridge University Press, 200 I) establece un marco conceptual de prueba efectivo para todos
los tipos de software desarrollado y adquirido.
Lewis (Software Testing and Continuous Qualig, 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 (Practica/ Guide to Testing Object-Oriented Software, Addison-Wesley, 2001 ),
Bashir y Goel (Testing Object-Oriented Software, Springer-Verlag, 2000), Binder, Testing ObjectOriented ~lems, Addison-Wesley, I 999}. Kung y sus colegas (Testing Object-Oriented Software,
IEE Computer Society Press, 1998) y Marick (The Crajt 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 RulesJor Finding EVen The Most Elusive Hardware and Software Problems. AMACON,
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 depuracin. Younessi (Object-01iented Defect Management o/Software, Prentice-Hall, 2002} presenta tcnicas para administrar los defectos que se encuentran en sistemas orientados a objetos. Beizer
[BEI84J presenta una interesante "taxonoma de los errores que puede llevar a mtodos efectivos
para la planeacin de pruebas. Ball (Debuggmg 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:
http://www.mhhe.com/pressman.
CAPTULO
14
C O NCEPTOS
CLAVE
AVl .... . ....437
co11pltjidacl
cidomtlco 426
focilldlll de
pr11tbo 419
grficas de
flujo 423
prill
ICflYalntt ...436
patrones 4S6
pnebos
basados en el
tSCNio 444
basados en
fallas 443
ele 11.des 432
ele caja lilanca .423
ele a. _,.. .433
de lo estrvctlnl
de coatrol 430
de .nivel de
doft . .....447
TCNICAS DE PRUEBA
DEL SOFTWARE
as pruebas representan un interesante reto para los ingenieros de

re, quienes por naturaleza son personas constructivas Las pruebas
ren que el desarrollador descarte nociones preconcebidas de lo
"correcto" en el software y entonces disee dificiles casos de prueba para
perlo". Beizer (BE190J describe bien esta situacin cuando afirma:
Es un mito que si realmente iueramos buenos para programar no tendramos que
purar errores. Si tan slo pud ramos concentramos, s1 todos usaran p r ~
estructurada. diseo descendente o tablas de dee1sin, si los programas se e
ran en SQUISH. si tuviramos las balas plateadas correctas, entonces no habna
res Se es el m.1to. Hay errores, dice el mito, porque somos malos en lo que ha
y si somos malos en eso, debemos sentimos culpables Por tanto, el diseo de
bas y de casos de prueba es una admisin de la falla que instila una buena d
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
na? Por no distinguir entre lo que otro programador piensa y lo que dice? ,P'<lr
usar la telepatla? Por no resolver los problemas de las comunicaciones humanas
han estado presentes durante cuarenta siglos?
Las pruebas deben provocar culpa? ,Las pruebas son realmente des
La respuesta es no!
En este captulo se analizaran tcnicas para el diseo de casos de p
software. Este tipo de diseo se concentra en un conjunto de tcnicas
creacin de casos de prueba que cumplan con obetivos generales y con
trategias de prueba analizadas en el captulo 13.
ele rvfQ llsica .423

orientados
1
olljetos 441
bas de disefto que 11 compn,eben la lgca

na y
1m ~ de todo componente ~
Wln y 2) compn,eben los dominios de erurc~tll
aalida del programa paro descubrir errores
Md6n, ~ i e n l o y desempeo.
Qui6a lo a-t Durante los etapas inic
pmceso, un ingeniero de software realizo

1111 pruebca Sin embargo, o medido que
za_.. proceso se irn incorporando especci
tm en pn,ebas.
411
CAPTULO 14 TCNICAS DE PRUEBA DEL SOFTWARE
419
En el captulo 5 se analizaron los objetivos y principios fundamentales de las pruebas. Se recordar que el objetivo de las pruebas es encontrar errores y que una buena 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.
1'odo "'programo h0<e oigo bien; pero tal vezseo lo que no queremos que hago.
...
Facilidad de prueba. James Bach I 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 siguientes se usan con permiso de James Bach fcopynght 1994) y se han adaptado del
material que originalmente apareci publicado en el grupo de noticias comp.software-eng.
420
PARTE DOS
Cules
son las
caracterstkas de
la facirtclad de
prueba?
PRcnCA DE LA DIIGENIERA DEL SOFTWARE
Operatividad. "Cuanto mejor funcione, con mayor eficiencia podr probarse

un sistema est diseado e implementado con la calidad en mente, sern rela
mente escasos los errores que bloquearn la ejecucin de las pruebas, lo que pe
tir el avance de stas sin correcciones ni reinicias.
Observabilidad. "Lo que se ve es Jo que se prueba." Las entradas proporc:;~

das como parte de la prueba producen salidas distintas. Los estados y las vari....:
del sistema son visibles y pueden consultarse durante la ejecucin. La salida ;;rrecta se identifica fcilmente. Los errores internos se detectan y reportan en ~
automtica. El cdigo fuente es accesible.
Controlabilidad. "Cuanto mejor se controle el software, mejor se automaL
y mejorarn las pruebas." El ingeniero de pruebas controla directamente los esta:..
las variables de software y hardware. Las pruebas pueden ser convenientemen_
pecificadas, automatizadas y reproducidas.
capacidad para descomponer. Al controlar el alcance de la prueba, se _
rn los problemas ms rpidamente y se aplicarn las pruebas nuevamente CO""'
yor inteligencia. El sistema de software se construye a partir de mdulos in
dientes que tambin se prueban independientemente.
Simplicidad. "Cuanto menos haya que probar, ms rpido se har." El pr .,

debe mostrar simplicidad Jundonal (por ejemplo, el conjunto de caractersticas C!:
mnimo necesario para satisfacer los requisitos). simplicidad estructural (la arq
tura aparece en mdulos para limitar la propagacin de fallas) y simplicidad de
go (se adapta un estndar de codificacin para facilitar la inspeccin y el mar::
miento.)
Estabilidad. "Cuantos menos cambios haya, menores alteraciones habra
prueba." Los cambios al software son poco frecuentes, se controlan cuando oc;~,i,
y no invalidan las pruebas existentes. El software se recupera bien de las falki.
Facilidad de comprensin. "Cuanta mayor informacin se tenga, con ma:
teligencia se aplicar la prueba." Se comprenden bien el diseo de la arquitet.
las dependencias entre componentes internos, externos y compartidos. se tieceso instantneo a la documentacin tcnica. est bien organizada, es espe
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 configt::
de software (es decir, programas. datos y documentos) que sea sensible a la :-
"Los errores son ms comunes en el software, tienen ms capodod de expondirse y representan mas problemas
en otras tecnalogios.
caractersticas de la prueba. Y qu hay con las propias pruebas? Kaner

Nguyen (KAN93J sugieren los siguientes atributos para una buena prueba:
421
CAPTULO 14 TCNICAS DE PRUEBA DEL SOf"JV\,IE
1. Una buena prueba tiene una elevada probabilidad de encontrar un error. Alcanzar 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 posible en una interfaz grfica de usuario es la incapacidad de reconocer la posicin 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" [KAN9.3]. En un grupo de
pruebas con un objetivo similar y recursos limitados podra optarse por la ejecucin 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 posible efectos colaterales asociados con este enfoque podran enmascarar errores. En general, cada prueba debe ejecutarse por separado.
Vinod: Esta bien, pi,rd no veo mucho CQSQ e n ~

loi.- entrodds 12.3A y ~789 Son redund<mtes., , ~
.
lo mismo, o no?
,,
Ed: aueno, $0n valores d i ~ . .
"'
Vinocl: Es cierto, pero ~ 123.4.po ~ un"efTOI'...
~ , y ~ p,ueho controseas q $Ol1 po
mdcao lcorredcl, como 8081 y &180.
en otros polabr0$... lo c;perqcin ~ detecto que lo controwo no'~Vftd'o, as{ que l'IO es,
probable que 6789 nos mue$fre 'lgo nV!JVQ,
Ed: Yo s lo que quiel'es decir.
"
Vinod: No estoy trotando .d& ~r puntib... tt,lo,._
tenemos tiempo limitoclo poro fc:\s ~ s , d, moa'o qvt
es bueno ideo ejecutor pruebos que tengan uno olta prrr
bobiliclod de encontrar nuevos et~.
Ed: No hoy problema .. Pensar un p:o in6a en esto.
-~?
422
PARTE DOS
14,
PRAcncA DE LA iNGENIERL\ DEL SOFIWARE
2 PRVi lA$ PI CAJA MIGRA X CAJA ILAMCiA

Hay una de dos maneras de probar cualquier producto construido (y casi cualqcosa): 1) si se conoce la funcin especfica para la que se dise el producto, se et
can pruebas, que demuestren que cada funcin es plenamente operacional, mier
se buscan los errores de cada funcin; 2) si se conoce el funcionamiento intem,.
producto, se aplican pruebas para asegurarse de que "todas las piezas encajar
decir, que las operaciones internas se realizan de acuerdo con las especificac1-y que se han probado todos los componentes internos de manera adecuada. A.
mer enfoque de prueba se Je denomina prueba de caja negra; al segundo, pruet"!
caja blanca.2
Las pruebas de caja negra son las que se aplican a la interfaz del software
prueba de este tipo examina algn aspecto funcional de un sistema que tiene ,
relacin con la estructura lgica interna del software. La prueba de caja blanc
software se basa en un examen cercano al detalle procedimental. Se prueban ~
tas lgicas del software y la colaboracin entre componentes, al proporcionar-..
~,
de prueba que ejerciten conjuntos especficos de condiciones, bucles o ambos
CLAYE
Los pruebas de cojo
blanco slo pueden
disearse despus del
diseo al nivel de
componentes (o
cdigo fuente). Es
necesorio que los
detalles lgicos del
programo estn
disponibles.
...
, ,_
"Slo hay uno regla pcl"O disear casos de prueba: abarcar lodos los funciones, perono disear demasiados t1ISG5.
A primera vista, parecera que toda prueba de caja blanca completa llevar.:: programa 100 por ciento correcto. Todo lo que se necesita hacer es identifica
los caminos lgicos, desarrollar casos de prueba para ejercitarlos y evaluar 'l::
dos; es decir, generar casos de prueba para comprobar exhaustivamente la lgi,....
programa. Por desgracia, la prueba exhaustiva presenta ciertos problemas de
tica (consltese el anlisis del recuadro). Sin embargo, la prueba de caja bla!'
Prueba exhaustiva
Considrese un programo de cien lneas en
lenguaje C. Despus de alguno declaracin bsico de datos, el programo contiene dos bucles anidados
que se ejecutan de l o 20 veces codo uno, lo que depende
de lo condicin especificado en lo entrado. Dentro del bucle interno se requieren cuatro construcciones si-entonces
si_no (ifthenelse }. El programo tendr alrededor de 101'
posibles rulas de ejecucin!
Poner este nmero en perspectiva requiere suponer que
se ha desarrollado un procesador de pruebo mgico (m
gico" porque no existe) poro aplicar uno pruebo ~

va. El procesador desarrolla un caso de pruebo, lo e~
y evala los resultados en un milisegundo. Si trabo1a-:
horas diarias, 365 das al ao, necesitara 3 170 rr.:.
ra probar el programa. Esto causara, indudoblemer.,.
desastre en casi todos los calendarios de desarrollo
Por tanto, es razonable asegurar que resulto i
aplicar una pruebo exhaustiva en sistemas grandes oe
wore.
2 Los trminos prueba funcional y prueba estructurada suelen usarse en lugar de prueba de ~
y de caja blanca, respectivamente
CAPTULO 14 TCNICAS DE PRUEBA DEL SOFIWAllE
423
debe desecharse nunca como imprctica. Es posible seleccionar y comprobar un nmero limitado de rutas lgicas importantes; adems de probar la validez de las principales estructuras de datos.
La prueba de caja blanca, en ocasiones llamada prueba de caja de cristal, es un m-
todo de diseo que usa la estructura de control descrita como parte del diseo al nivel de componentes para derivar los casos de prueba. Al emplear los mtodos de
prueba de caja blanca, el ingeniero del software podr derivar casos de prueba que
1) garanticen que todos las rutas independientes dentro del mdulo se han ejercitado por lo menos una vez, 2) ejerciten los lados verdadero y falso de todas las decisiones lgicas, 3) ejecuten todos los bucles en sus lmites y dentro de sus lmites operacionales, y 4) ejerciten estructuras de datos internos para asegurar su validez.
Los etrote$pululan en los rincones yseacumulan enlos lmites.
La
prueba de la ruta bsica es una tcnica de prueba de caja blanca que propuso ini-
cialmente Tom McCabe [MCC76]. El mtodo de la ruta bsica permite que el diseador
de casos de prueba obtenga una medida de complejidad lgica de un diseo procedimental y que use esta medida como guia para definir un conjunto bsico de rutas de
ejecucin. Los casos de prueba derivados para ejercitar el conjunto bsico deben garantizar que se ejecuta cada instruccin del programa por lo menos una vez durante la prueba.
14.4.1 Notacin de grfica de flujo

Antes de tratar el mtodo de la ruta bsica, debe presentarse una notacin simple
para la representacin del flujo de control, llamado grfica de flujo (o grfica del programa).3 La grfica de flujo describe un flujo de control lgico empleando la notacin
ilustrada en la figura 14. l. Cada construccin estructurada (captulo 11) tiene su smbolo correspondiente en la grfica de flujo.
El uso de una grfica de flujo se ilustra considerando la representacin del diseo procedimental de la figura 14.2a. Aqu se describe la estructura de control del programa mediante un diagrama de flujo. En la figura 14.2b se correlaciona (o mapea)
el diagrama de flujo con su grfica de flujo correspondiente (suponiendo que no existen condiciones compuestas en los diamantes de decisin del diagrama de flujo). To3
En realidad, el mtodo de la ruta bsica se aplica sm el uso de las grficas de flujo. Sin embargo. sirven como notacin til para comprender el flujo de control e ilustrar el enfoque.
424
PARTE DOS
PRCTICA DE LA INGENIERIA DEL SOFIWARE
mando como referencia la figura 14.2b, cada crculo, llamado nodo de grfica de
jo, representa una o ms instrucciones procedimentales. Una secuencia de reG...rdros de proceso y un diamante de decisin se correlaciona con un solo nodo. Las:.
chas en la grfica de flujo, llamadas aristas o enlaces, representan el flujo de cony son anlogos a las flechas de los diagramas de flujo. Una arista debe terminar
un nodo, aunque el nodo no represente ninguna instruccin procedimental ~
ejemplo, vase el smbolo en la grfica de flujo para la construccin if-then-else de
figura 14.1 ). Las reas que limitan aristas y nodos se denominan regiones. Cua~
se cuentan las regfones se incluyen las reas ubicadas fuera de la grfica.4
ifrhitl
Los construcciones estructurodas en forma de grfica de Ruo:
Notacin de
grfica de
flujo.
Secuencio
Si
Mientras
Segn_seo
Hasta
Donde cada crculo represento uno o ms

instrucdnen LDP sin ramificaciones o de cdigo fuente
jfrj/
'f
a) Diagrama de
1719~
~
[~
.11
fiuJo y b) grfica de flujo.
[ I
]
a)
4 Un anlisis ms detallado de las grficas y su aplicacin se presentar en la seccin t 4.6.1
CAPTULO 14 TCNICAS DE PRUEBA DEL SOF'IWARE
425
Cuando se encuentran condiciones compuestas en un diseo procedimental. la

generacin de una grfica de lujo se vuelve ligeramente ms complicada. Una condicin compuesta ocurre cuando hay uno o ms operadores booleanos (OR. AND,
NAND, NOR) en una instruccin condicional. Tomando como referencia la figura
14.3, el segmento en LDP se traduce a la grfica de lujo mostrada. Obsrvese que se
crea un nodo separado para cada una de las condiciones a y b en la instruccin lF 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 Jo menos un
nuevo conjunto de instrucciones de procesamiento o una nueva condicin. Cuando
se explica desde el punto de vista de una grfica de flujo, una ruta independiente debe 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 flujo
de la figura 14.2b:
ruta l: l-11
ruta 2: 1-2-3-4-5-10-1-l l
ruta 3: l-2-3-6-8-9-10- l- l l
ruta 4: 1-2-3-6-7-9- 10- 1- 11
Obsrvese que cada nuevo camino ingresa una nueva arista. El camino
l -2-3-4-5- 10- 1-2-3-6-8-9-10-l-ll
no se considera una ruta independiente porque se trata simplemente de una combinacin de rutas ya especificadas y no recorre ninguna arista nueva.
Los caminos 1, 2, 3 y 4 constituyen un conjunto bsico para la grfica de flujo de
la figura 14.2b. Es decir, si se disean pruebas para forzar la ejecucin de esas rutas
IF a OR b
then procedimiento x
else procedimiento y
ENDIF
PARTE DOS PRCl'!CA DE LA INGENIERA DEL SOF1WARE
426
lD complejidad
cidomtico es uno
mtrico que resulto
til poro predecir
cules mdulos tienen
ms probabilidad de
contener errores. Se
empleo poro lo planeocin de pruebas
adems del diseo de
cosos de pruebo.
Cmo se
<al<ula la
<omplepdod ddo
(un conjunto bsico). se habrn ejecutado los lados verdadero y falso de cada C"Struccin del programa. Debe observarse que un conjunto bsico no es nico. En "5
lidad, es posible derivar varios conjuntos bsicos diferentes de un diseo proced..
mental determinado.
Cmo se sabe cuntas rutas buscar? El clculo de la complejidad ciclomtica p
porciona la respuesta. La complejidad ciclomtica es una m trica de software
proporciona una medida cuantitativa de la complejidad lgica de un progra;Cuando se emplea en el contexto del mtodo de prueba de la ruta bsica, el calculado mediante la complejidad ciclomtica define el nmero de rutas indepe:
dientes en el conjunto bsico de un programa, y proporciona un lmite superior
ra el nmero de pruebas que deben aplicarse para asegurar que todas las instruaJc;
nes se hayan ejecutado por lo menos una vez.
La complejidad ciclomtica se basa en la teora grfica y se calcula de una de
maneras:
1. El nmero de regiones corresponde a la complejidad ciclomtica.
2 . La complej idad ciclomtica, V(G), de una grfica de flujo, G, se define co~

V(G) =E - N
mti<a?
+2
donde E es el nmero de aristas, y N, el nmero de nodos de la grfica de

jo.
&'
"~
C~VE
Lo complepdod
domttco proporciono
el lmite superior del
nmero necesario de
cosos de pruebo poro
gorontizor que codo
instruccin del
programo se hoyo
ejecutado por lo menos
uno vez.
3 . La complejidad ciclomtica, V(G), de una grfica de flujo, G, tambin se d

como
V(G)
=P +
donde Pes el nmero de nodos predicado incluidos en la grfica de flujo e

Tomando como referencia una vez ms la grfica de flujo de la figura 14.2:
complej idad ciclomtica se calcula empleando cada uno de los algoritmos q.....
acaban de indicar.
1. La grfica de flujo tiene cuatro regiones.
2. V(G)
= 11
aristas - 9 nodos + 2
3. V(G) = 3 nodos predicado + 1
=4
=4
HoGARSEGURO
Utilizacin de la complejidad ddomtica

la escena: Cubculo de Shakira .
a....,..: Vinod y Shakira, integrantes del equipo

da angeniero del sohwore Ho(p'Seguro que trabaja en
ID pl&niaci6n de pruebas para la funcin de seguridad.
la conversacin:
Shakira: Mira.. S que debemos aplicar pruebas de

unidad a los componenles de le funcin de seguridad
pero hay demasiadas, y ~ lomas en cuenlo el nmero
operociones que deben ejercitom, no $ ...
ll Y$Z ~
427
CAPTULO 14 TCNICAS DE PRUEBA DEL S0f1WARE
olvidomo$cfe lo pruebo de <jq bf<:lgca, integrar to iniciar la e"fec:U<;irt de las pruehgs de caja negro.
vN'NNI: La comp1eidad ciclomatri IV deGt. S6fo~1o V(G) poro c:oclo operocin dentro de c~dn ~ n "
8CAMt$ q11e el ~ es insufici.,. poro probar

~ i $, ejerdtcir fsis ~ion.e$ 'f luego inte
te y vers cules tienen los ~lores mos e l ~ ~W$

son las que esln ms propensos ti error.
'
._tils.m. LQ lecha(f,nil9 J)Ql"Q el primer it1oremerito 8$16

c:erca de lo qu4t peiubamo,... s, cloro, $1oy preo
: 2Por qu no &~s t>OI' lo menos p ~
mio blanca en b operiorle$ ms P!l)ptnSQ5 o
son
(excasperada~ tY ~ e!Yjo
lS ms prflPeniOS Q ~
,
VdeG,
o,
Shaldra: Y c6mo cokulo Vefe

Vinod: Es muy fcil. Aqur ~e, u~ IJbro que.d e~~
cmo hacerlo.
Shakira ~ ) ; M.'!'/ bien, no ?Ol"Adi(rcit

lo probar. Las opetocil'le$ ~ lo V(G} m<s elevoda 1et'Ql'I
candidotas ,p a~ los pr.('iebo$: de C!lja bb!'li.
, ,
Vlndi Slo reuet'di que I\O hoy gorort~$, Un eo(!IP?:;

oenre: CI) ul'IQViGl bQi6 c;in ~ e$l(lr.propense o
errotes.
,.
Shaldra: .~ biefi. ~re por~ ~ s e$fQ n,e ~ ;(t

redvdr e1 ntne de~P9neotes cwe~rl,;unente
.~
10ll1eterse a 8 ~ de <:nja blanca,_
Q
: eOu'
Lo ms notable es que el valor de V(G) proporciona el lmite superior del nmero

de rutas independientes que forman el conjunto bsico; por implicacin, ofrece un
limite superior del nmero de pruebas que debe disearse y ejecutarse para garantizar la cobertura de todas las instrucciones del programa.
14.4.3 Derivacin de casos de prueba

El mtodo de prueba de la ruta bsica se aplica a un diseo procedimental o al cdigo fuente. En esta seccin se presentar la prueba de la ruta bsica como una serie de pasos. Se emplear el procedimiento promedio (descrito en PDL en la figura
14.4) como ejemplo para ilustrar cada paso en el mtodo de diseo de casos de prueba. Obsrvese que promedio, aun en el caso de un algoritmo extremadamente simple, contiene condiciones compuestas y bucles. Los siguientes pasos se aplican para
derivar el conjunto bsico:
l. Utilizando el diseo o el cdigo como base se dibuja la grfica de flujo correspondiente. En la creacin de una grfica de flujo se emplean los
simbolos y las reglas de construccin presentadas en la seccin 14.4. 1. Tom ando com o referencia el PDL para obtener promedio en la figura 14.4, se
crea una grfica de flujo numerando esas instrucciones en PDL, que se correlacionarn o mapearn en los nodos correspondientes de la grfica de flujo.
En la figura J 4.5 se muestra la grfica de Oujo resultante.
2. Determnese la complejidad cidomtica de la grfica de flujo resultante. La complejidad ciclomtica, V(G), 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 todas las instrucciones condicio-
428
PARTE DOS
iihIICI
PROCEDIMIENTO promedio:
PDLcon
&te p,ooeciruia.,lo coba el p,omodio do 100 o menoe

- - q u e ..... - . . _ ~ , lembin"""""" la
y .. loltl do ,.....,. ..licios
nodos
identificados.
INTERFACE RETURH8 p,omodio, lolahnmida, lolal.vaftdo:

INTB!fACE ACCEPTtl ..,,, h>Wlirno, maidmo:
TYPE Vlb{l:100} 111 IICAlAR ARRAY:
TYPE p,omodio, lotel.anhada, lonl.vo/ido;
roinimo, - . . . . ,.._ 111 9CAI.AR:
~~~~=0:2
1 {
4
c..ma=O:
------00 WHllE """'l1J < > .999 AH1> ..,._."'1ndo < 100 S
..,._,entn,da en 1:
.,.,...,_ta,
6- <ll EN
w..io.ro>=........,AADwlorf~<=mmno
-+
EUIEcxnlti,
e<
---.t.. lotel...ado en 1:
.....,. =
wlorfll
ENOIF
.._._, .. 1.. 1:
9 ENOOO
IF lotel.wlclo > O 10
lllEN p,omodio = ...,.. 1o191,velldo:

EUlE p,omodio = 999:
13 ENOIF
ENO p,omodio
l2
nales en el PDL (para el procedimiento promedio, las condiciones comp

cuentan como dos) y se suma I al resultado. Tomando como referencia ;:
gura 14.5,
= 6 regiones
V(G) = 17 aristas - 13 nodos+ 2
V(G)
V(G)
1.
= 5 nodos predicado +
=6
1=6
"&mes de hUlllll)OS, encontror un error es de d'aoses.'
3. Determnese un conjunto bsico de rutas linealmente independi

El valor de V(G) indica el nmero de rutas Linealmente independientes de
estructura de control del programa. En el caso del procedimiento prome....::
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: l -2-3-4-5-6-8-9-2-...
ruta 6: 1-2-3-4-5-6-7-8-9-2-...
429
CAPTULO 14 TtCNICAS DE PRUEBA DEL SOF'IWARE
Los puntos 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 1O son nodos predicado.
4. Preprense los casos de prueba que forzarn la ejecucin de cada ruta en el conjunto bsico. Es necesario seleccionar los datos de manera tal
que se establezcan apropiadamente 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 completados todos los casos, la persona que aplica la prueba puede estar segura de que todas las instrucciones del
programa se han ejecutado por lo menos una vez.
Es importante observar que es imposible probar algunas rutas independientes
(como la ruta l en nuestro ejemplo) por separado. Es decir, en el flujo normal del
programa no puede obtenerse la combinacin de los datos requeridos para recorrer
la ruta. En tales casos, estas rutas se ejercitan como parte de otra prueba del camino.
ecfado
nodo
'
5
Grfica de fluo
Matriz de grfica
430
PARTE DOS
PRcnCA DE LA INGENIER.A DEL SOFTWARE
14.4.4 Matrices de grficas

El procedimiento para derivar la grfica de flujo e incluso determinar un conjunto ...I!'
rutas bsicas es sensible a la mecanizacin. Una estructura de datos denomina..;:
matriz de grfica resulta muy til para desarrollar una herramienta de software =-ayude en la prueba de la ruta bsica.
Una matriz de grfica es una matriz cuadrada cuyo tamao (es decir, el nm~
de filas y columnas) es igual al nmero de nodos en la grfica de flujo. Cada f columna corresponde a un nodo identificado, y las entradas de la matriz correspden a las conexiones (una arista) entre nodos. En la figura 14.6 se muestra un e
Qu es una
matriz de
grfica y cmo se
extiende para
usarla en la
prueba?
plo simple de una grfica de flujo y su matriz de grfica correspondiente [BEl9C

Tomando como referencia la figura, cada nodo en la grfica est identificado
nmeros, mientras que cada arista se identifica con letras. Una conexin entre
nodos se indica creando una entrada de letra en la matriz. Por ejemplo, el nodo 3
conecta al nodo 4 con la arista b.
Hasta este punto, la matriz de grfica no es ms que una representacin ta:J
de una grfica de flujo. Sin embargo, al agregar un peso de enlace a cada una d~
entradas, la matriz de grfica se convierte en una herramienta poderosa para
luar la estructura de control del programa durante la prueba. El peso de enlace
porciona informacin adicional acerca del flujo de control. En su forma ms
el peso de enlace es l (existe una conexin) o O (no existe una conexin). Perca
pesos de enlace tambin se le asignan otras propiedades, ms interesantes:
La probabilidad de que se ejecute un enlace (arista).
El tiempo de procesamiento gastado durante el recorrido a un enlace.

La memoria requerida durante el recorrido de un enlace.
Los recursos requeridos durante el recorrido de un enlace.

Beizer [BE190] proporciona un tratamiento completo de algoritmos matenadicionales que son aplicables a una matriz de grfica. El empleo de estas tt:::.-.:
permite automatizar parcial o totalmente el anlisis requerido para disear cas
prueba.
4Jn ror dsico es pnstur ms olenn o la ejecu<in de lm pruebos que osu diseo.
La tcnica de prueba de la ruta bsica descrita en la seccin 14.4 es una de

tcnicas para la prueba de estructuras de control. Aunque la prueba de la nr...
ca es simple y efectiva, no es suficiente por s misma. En esta seccin se an.........:...1~
brevemente variaciones sobre la prueba de estructuras de control. stas ens.:.::.::a
la cobertura de las pruebas y mejoran la calidad de la prueba de caja blanca
CAPTULO 14 TCNICAS DE PRUEBA DEI. SOf'i\'rulE
431
14.5.l Prueba de condicin

La prueba de condicin [TAI89) es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en un mdulo del programa. Una condicin
simple es una variable booleana o una expresin relacional, tal vez precedida con un
operador NOT (-.). una expresin relacional toma la forma
E1 <Operador relacional> E2
donde E1 y E2 son expresiones aritmticas y <operador relacional> es uno de los siguientes: < ,~. =,*(desigual), > o;;,,. Una condicin compuesta la integran dos o
ms condiciones simples, operadores booleanos y parntesis. Se supone que entre
los operadores booleanos permitidos en una condicin compuesta se incluyen OR (I).
AND (&) y NOT (-.). Una condicin sin expresiones relacionales se considera una expresin booleana. Por tanto, los posibles tipos de elementos en una condicin incluyen un operador booleano, una variable booleana, un par de parntesis (que encierran una condicin booleana simple o compuesta). un operador relacional o una expresin aritmtica.
Si una condicin es incorrecta, entonces por lo menos un componente de la condicin es incorrecto. Por tanto, entre los tipos de errores en una condicin se incluyen los presentes en el operador booleano (operadores booleanos incorrectos/faltantes/adicionales), en la variable booleana, en los parntesis booleanos, en los
operadores relacionales y en la expresin aritmtica. El mtodo de prueba de condicin 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 mtodo de prueba delflujo 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 programa. El enfoque de prueba del flujo de datos se ilustra suponiendo que a cada instruccin de un programa se le asigna un nmero de instruccin, y que ninguna funcin modifica sus parmetros o variables globales. En el caso de una instruccin con
I como nmero de instruccin,
DEF(I) = {X I instruccin / contiene una definicin de XJ
USO(I) = {XI instruccin / contiene un uso de XJ
Si la instruccin/ es una instruccin if (s1) o loop (bucle), su conjunto DEF est vaco
y su conjunto USO se basa en la condicin de la instruccin/. Se dice que la definicin de la variable X en la instruccin / est viva en la instruccin /' si existe una ruta de la instruccin/ a la/' que no contiene otra definicin de X.
Una cadena definicin -uso (DU) de la variable X es de la forma [X, /, !'], donde l e
I' son nmeros de instruccin, X est en DEFIII) USO(!'), y la definicin de X en la
instruccin / est viva en la /'.
432
No es realista
asegurar que lo
prueba del flu;o de
dotos se usoro de
manero ex/enso
cuando se pruebo un
sistema grande.
Sin embargo, puede
usarse de uno manero
orientada oun blanco
en reas de software
que estn boio
sospecha.
PARTE DOS
PRcnCA DE LA INGENJEliA DEL SOF1WARE
Una estrategia simple de prueba de flujo de datos consiste en solicitar que e=.
cadena DU sea cubierta por lo menos una vez. Esta estrategia se denomina est.
gia de prueba DU. Se ha mostrado que sta no garantiza la cobertura de todas las
mas de un programa. Sin embargo, slo en raras situaciones no se garantiza que
rama est cubierta por una prueba DU, como en las construcciones if-then-else
entonces-si_no) en que la parte then no tiene definicin de alguna variable y la _
te else no existe. En esta situacin, la rama else de la instruccin ifno estn~
riamente cubierta por la prueba DU. se han estudiado y comparado varias es:.:gias de prueba de flujo de datos (por ejemplo, (FRA88]. [NTA88], (FRA931). A los
tares interesados se les recomienda que consideren consultar esas referencz.s
bliogrficas.
14.5.3 Prueba de bucles

Los bucles son la piedra de toque para la gran mayora de los algoritmos im
tados en software. Y aun as, a menudo se les presta poca atencin mientras se
lizan pruebas de software.
La prueba de bucles es una tcnica de prueba de caja blanca que se concer ':z
clusivamente en la validez de la construccin de bucles. Es posible definir cuz

ferentes clases de bucles [BEI90]: bucles simples, concatenados, anidados 1
tructurados (figura 14. 7).
Clases de
bucles.
Bucles anidados
Bucles simples
Bucles
concatenados
Bucles
no estructurados
CAPTULO 14 TCNICAS DE PRUEBA Da SOFTWARE
433
Bucles simples. El siguiente conjunto de pruebas se aplica a bucles simples, donde n es el nmero mximo de pasos que permite el bucle.
1. Omitir por completo el bucle.
2 . Slo un paso por el bucle.
J. Dos pasos por el bucle.

4. m pasos por el bucle, donde m < n.
5. n
= 1, n, n + l
pasos por el bucle
Bucles anidados. Si se fuese a extender el enfoque de prueba de los bucles simples a los anidados, el nmero de pruebas posibles crecera geomtricamente a medida que aumente el nivel de anidamiento. Esto generara un nmero poco prctico
de pruebas. Beizer [BEI90) sugiere un enfoque que ayudar a reducir el nmero de
pruebas:
1. Iniciar en el bucle ms interno. Asignar a todos los bucles los valores mnimos.
2 . Aplicar pruebas de bucle simple al ms interno mientras se mantienen los externos en los valores mnimos del parmetro de iteracin (como el contador
de bucles). Agregar otras pruebas para los valores fuera de rango o excluidos.
3. Trabajar hacia fuera, conduciendo pruebas para el siguiente bucle, pero manteniendo todos los dems bucles externos en valores mnimos y otros bucles
anidados en valores "tpicos".
4. Seguir mientras no se hayan probado todos los bucles.
Bucles concatenados. Los bucles concatenados se prueban empleando el enfo-
'ir probor
-~/os bucles
e ';;J(furodos.
~ro volver o
SE
=*is.
que definido para los bucles simples, si cada uno de los bucles es independiente. Sin
embargo, si dos bucles estn concatenados y el contador del bucle I se emplea como
valor inicial para el bucle 2, entonces los bucles no son independientes. Cuando los
bucles no lo son, entonces se recomienda el enfoque aplicado a los bucles anidados.
Bucles no estructurados. Siempre que sea posible, esta clase de bucles debe di searse nuevamente para reflejar el uso de las construcciones de programacin estructurada (captulo 11).
14,6 PBYIII PI CAJA; NIQIA

Las pruebas de caja negra, tambin denominadas, pruebas de comportamiento, se
concentran en los requisitos funcionales del software. Es decir, permiten al ingeniero de software derivar conjuntos de condiciones de entrada que ejercitarn por completo todos los requisitos funcionales de un programa. La prueba de caja negra no
es una opcin frente a las tcnicas de caja blanca. Es, en cambio, un enfoque complem entario que tiene probabilidades de descubrir una clase diferente errores de los
que se descubriran con los mtodos de caja blanca
434
PARTE DOS
PRCTICA DE LA INGEN!ERIA OO. SOFJWARE
Las pruebas de caja negra tratan de encontrar errores en las siguientes categ
ras: 1) funciones incorrectas o faltantes, 2) errores de interfaz, 3) errores en estt"turas de datos o en acceso a bases de datos externas, 4) errores de comportamie.
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 :r
prueba, las de caja negra tienden a aplicarse durante las ltimas etapas de la Pba (consltese el capitulo 13). Debido a que stas desatienden a propsito la esc-.c
tura de control, la atencin se concentra en el dominio de la informacin. Las p-...e
bas estn diseadas para responder las siguientes preguntas:
Cmo se prueba la validez funcional?
Cules
preguntas
responden las
pruebas de caja
negra?
Cmo se prueban el comportamiento 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 aslan los lmites de una clase de datos?
Cules tasas de datos y cul volumen tolera el sistema?
Qu efecto tienen combinaciones especficas de datos sobre la operacin
sistema?
Al aplicar tcnicas de caja negra se deriva un conjunto de casos de prueba q-..e
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!:
searse para alcanzar una prueba razonable, y 2) casos de prueba que indica.,
acerca de la presencia o ausencia de clases de errores, en lugar de un error
do slo con la prueba especifica a la mano.
14.6.1
Una grfico represento

los relaciones entre los
objetos de datos y los
de programa, lo que
permite derivar casos
de pruebo que
busquen errores
asociados con estas
relaciones.
Mtodos grficos de prueba
El primer paso en la prueba de caja negra es comprender los objetos5 modela

el software y la relacin entre ellos. una vez que se ha logrado, el siguiemc
consiste en definir la serie de pruebas que verifican que "todos los objetos t i ~
relacin esperada entre s" [BEI95] . Explicado de otra manera, la prueba de s.
re empieza al crear una grfica de objetos importantes y sus relaciones y luegr
una serie de pruebas que cubran la grfica de tal manera que se ejercite cada
to y relacin y que se descubran los errores.
Para dar estos pasos, el ingeniero de software empieza creando una grf,x:.
coleccin de nodos que representan objetos, enlaces que representan la relac
tre objetos, pesos de nodo que describen las propiedades de un nodo (como 1.1:'
de datos o un comportamiento de estado especfico) y pesos de enlace que d~-~-
algunas caractersticas de un enlace.
En este caso el trmino "objetos se considera en el contexto ms amplio posible. Abarca ob1e:
tos, componentes (mdulos) tradicionales y elementos orientados a objetos del software de e
CAPTULO 14
435
TCNICAS DE PRUEBA DEI. SOfTW'ARE
Peso del nodo

(valor)
Enloces paralelos
a}
lo seleccin del men genero
(tiempo de generacin < 1.0 seg)
b}
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 conectados por enlaces que toman 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 denominado enlace simtrico, indica que la relacin se aplica en ambas direcciones. Los enlaces paralelos se emplean cuando se establece un nmero diferente de relaciones
entre los nodos de la grfica.
Como ejemplo simple, considrese una parte de la grfica para una aplicacin de
procesamiento de palabras (figura 14.8b) donde
Objeto # I = nuevoArchivo (men seleccin)
Objeto #2 = ventanaDocumento
Objeto #3 == textoDocumento
Si se toma como referencia la figura, una seleccin del men en nuevoArchivo genera una ventana de documento. El peso del nodo de ventanaDocumento proporciona una lista de los atributos de la ventana que se esperaban cuando sta se gener. El peso del enlace indica que la ventana debe generarse en menos de 1.0 segundos. Un enlace indirecto establece una relacin simtrica entre la seleccin del
men nuevoArchivo y textoDocumento, y los enlaces paralelos indican las relaciones entre ventanaDocumento y textoD ocumento. En realidad, tendra que generarse una grfica mucho ms detallada como precursora del diseo de casos de
prueba. El ingeniero de software deriva entonces los casos de prueba al recorrer la
436
PARTE DOS
PRCTICA DE LA INGENIERiA DEL SOFIWARE
grfica y cubrir cada una de las relaciones mostradas. Estos casos de prueba se
searn en un intento de encontrar errores en cualquiera de las relaciones.
Beizer (BEI95] describe varios mtodos de prueba de comportamiento que us..::::
grficas:
Modelado del flujo de transaccin. Los nodos representan pasos de alguna tra=
saccin (por ejemplo, los pasos requeridos para hacer una reservacin en una ae:
lnea empleando un servicio en lnea) y los enlaces representan la conexin lg:
entre los pasos. El diagrama de flujo de datos (captulo 8) se utiliza para ayuda: .,.
la creacin de grficas de este tipo.
Modelado de estado finito. Los nodos representan los diferentes estados q~

usuario observa en el software (por ejemplo, cada una de las "pantallas" que a~
cen cuando un empleado toma un pedido por telfono) y los enlaces representar
transiciones que ocurren para ir de un estado a otro. El diagrama de estado (car
lo 8) ayuda a crear grficas de este tipo.
Modelado del flujo de datos. Los nodos son objetos de datos, y los enlaces s
las transformaciones que ocurren para traducir un objeto de datos en otro. Por e;:
plo, el nodo impuesto retenido por FICA (IRF) se calcula a partir de salario
to (SN) empleando la relacin IRF = 0.62 x SN.

Modelado relacionado con el tiempo. Los nodos son objetos de programa,
enlaces son las conexiones secuenciales entre esos objetos. Con los pesos de ece se especifican los tiempos de ejecucin requeridos mientras el programa se cuta.
Un anlisis detallado de cada uno de estos mtodos grficos de prueba se ene
tra ms all del alcance de este libro. El lector interesado debe consultar [BEI95
ra tener una cobertura completa.
14.6.2 Particin equivalente

La partidn equivalente es un mtodo de prueba de caja negra que divide el d
las condiciones de e1r

trodo son conocidos
en una e/upo relativamente temprano del
proceso de software.
Po, esto, debe empemse opensar en lo
a1dJo equivalente
Dfr1s se aeo el di-
nio de entrada de un programa en clases de datos a partir de las cuales puede!"

rivarse casos de prueba. Un caso de prueba ideal de manejo simple descubre
clase de errores (por ejemplo, procesamiento incorrecto de todos los datos de c.r
teres) que, de otra manera, requerira la ejecucin de muchos casos antes de qu.
observe el error general. La particin equivalente se esfuerza por definir un cas.
prueba que descubra ciertas clases de errores, reduciendo as el nmero total de
sos de prueba que deben desarrollarse.
El diseo de casos de prueba para particin equivalente se basa en una eva.
cin de las clases de equivalencia para una condicin de entrada. Con el uso d_
conceptos introducidos en la seccin anterior, si es posible enlazar un conjun
objetos mediante relaciones simtricas, transitivas y reflexivas, entonces existe
clase de equivalencia [BEl95). Una clase de equivalencia representa un conjun:
estados vlidos y no vlidos para las condiciones de entrada. Por lo general
CAPTULO 14 TCNICAS DE PRUEBA DEL SOr.V.'JlE
437
condicin de entrada es un valor numrico especfico, un rango de valores, un conjunto de valores relacionados o una condicin booleana. Las clases de equivalencia
se definen de acuerdo con las siguientes directrices:
1. Si una condicin de entrada especifica un rango, se definen una clase de equivalencia vlida y dos no vlidas.
2. Si una condicin de entrada requiere un valor especfico, se definen una clase
de equivalencia vlida y dos no vlidas.
3. Si una condicin de entrada especifica un miembro de un conjunto, se definen
una clase de equivalencia vlida y otra no vlida.
4 . Si una condicin de entrada es booleana, se definen una clase de equivalencia vlida y otra no vlida.
Al aplicar .estas directrices para la derivacin de clases de equivalencia, se desarrollarn y ejecutarn los casos de prueba para cada objeto de los datos del dominio
de entrada. Los casos de prueba se seleccionan de modo que el mayor nmero de
atributos de clase de equivalencia se ejercita una vez.
14.6.3 Anlisis de valores lmite

Es mayor el nmero de errores que se presenta en los lmites del dominio de entrada que en el "centro"; por ello se ha desarrollado el anlisis de valores lmite (AVL) como tcnica de prueba. El AVL lleva a una seleccin de casos que prueba los valores
limite.
El anlisis de valores lmite es una tcnica de diseo de casos de prueba que complementa la particin equivalente. En lugar de seleccionar cualquier elemento de
una clase de equivalencia, el AVL lleva a la seleccin de casos de prueba en las "aristas" de la clase. En lugar de concentrase exclusivamente en las condiciones de entrada, el AVL tambin deriva casos de prueba del dominio de salida [MYE79).
Las directrices para el AVL son muy similares a las proporcionadas para la particin equivalente:
l. Si una condicin de entrada especifica un rango limitado por los valores a y b,

los casos de prueba deben disearse con esos valores, adems de los que se
encuentran apenas arriba y abajo de ellos.
2. Si una condicin de entrada especifica diversos valores, deben desarrollarse

casos de prueba que ejerciten l os nmeros mximo y mnimo. Tambin se
prueban los valores ubicados apenas arriba y abajo de estos mximos y mnimos.
Cmo
puedo crear
casos de prueba
IYL?
3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ejemplo, supngase que una tabla que compara presin y temperatura se requiere como salida
de un programa de anlisis de ingeniera. Los casos de prueba deben disearse para crear un informe de salida que produzca el nmero mximo (y mnimo) permisible para las entradas de la tabla.
438
PARTE DOS
PRCllCA DE LA INGENIERA DE!. SOFIWARE
4. Si la estructura interna de datos del programa tiene lmites prescritos (por

ejemplo, una matriz que tiene un limite definido de cien entradas) debe di.se
arse un caso de prueba para ejercitar los lmites de la estructura de datos
La mayora de los ingenieros de software realizan intuitivamente el AVL, hasta::
to grado. Al aplicar estas directrices, la prueba de limites estar ms completa

tanto, tendr una mayor probabilidad de detectar errores.
"B cM Arialle Sesdl al despegar debido o unsimpledefecto (error} del software que se relacionaho con ID c. ,
versin de un valor de pl#IIO flotante de 64 bits en un entero de 16 bits. El cohete y sus cualro SCllilites cmean
SIIU'8 ymstaron 500 m~ de dlares. Una pruebo completo del sistema hubiera enconlnldo ti ert~ i-,o w '
11111a por 111Z0111S de presupuesto.
.
14.6.4 Prueba de tabla ortogonal
Hay muchas aplicaciones en las cuales el dominio de entrada es relativamente
tacto. Es decir, el nmero de parmetros es pequeo y los valores que cada ~
tro puede tomar estn claramente limitados. Cuando estos nmeros son muy .,
os (por ejemplo, tres parmetros de entrada toman tres valores discretos cacb
es posible considerar cada permutacin de entrada y probar exhaustivamente ;::
cesamiento del dominio de entrada. Sin embargo, a medida que crece el nlr:
valores de entrada, junto con el nmero de valores discretos para cada elem
&'
'~
c&v1
Lo pruebo de tablo
ortogonal permite
disear cosos de
pruebo que
proporcionan lo
mximo cobertura de
pruebo con un nmero
rozonoble de cosos de
pruebo.
prueba exhaustiva se vuelve poco prctica o imposible.

La prueba de tabla ortogonal se aplica en problemas en los cuales el dom
entrada es relativamente pequeo, pero demasiado grande para una prueba e
tiva. El mtodo de prueba de tabl a ortogonal resulta til sobre todo para ene
errores asociados con las fallas de regin (una categora de error asociada con
fectos de la lgica en un componente de software).
Ilustrar la diferencia entre la prueba de tabla ortogonal y los enfoques mas
cionales de "un elemento de entrada a la vez" requiere imaginar un sistema
elementos de entrada, X, Y y z. cada uno de estos elementos tiene tres valo.-cretos asociados. Hay 33 = 27 casos de prueba posibles. Phadke [PHA97] sug
concepto geomtrico, que se ilustra en la figura 14.9, para los posibles
prueba asociados con X, Y y Z. Si toma como referencia la figura, slo un e.e
de entrada podria variar a un mismo tiempo en la secuencia que sigue cada
entrada. Esto da como resultado un cobertura relativamente limitada del domink
trada (que representa el cubo de la izquierda de la figura) .
Cuando se presenta una prueba de tabla ortogonal se crea una tabla ortog
de casos de prueba, la cual tiene una "propiedad de equilibrio" [PHA97]. Es <k.
casos de prueba (representados con puntos azules en la figura) estn "uniforte 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 com::
CAPTULO 14
TCNICAS DE PRUEBA DEL SOfiWARE
439
xUn elemento de entrada a la vez
Tabla ortogonal L9
Para ilustrar el uso de la tabla ortogonal L9, considrese la funcin enviar de una
aplicacin de fax. se pasan cuatro parmetros, PI, P2, P3 y P4 a la funcin enviar.
Cada uno toma tres valores discretos. Por ejemplo, PI toma los valores:
P1 = 1, enviarlo ahora
PI
=2, enviarlo en una hora
PJ = 3, enviarlo a medianoche
P2, P3 y P4 tambin podran tornar los valores 1, 2 y 3, representando otras funciones de enviar.
Si se eligiera una estrategia de prueba "un elemento de entrada a la vez", se especificaran las siguientes secuencias de prueba (Pl, P2, P3, P4): (1, 1, 1, 1), (2, 1, 1,
1), (3, 1, 1, )), (1,2, 1, 1), (1,3, 1, 1), (1, 1,2, 1), (1, 1,3, 1), (), 1, l,2)y(1 , 1, 1,3).
Phadke [PHA97] evala estos casos de prueba al afirmar:
Estos casos de prueba slo son tiles cuando se est seguro de que los parmetros de
prueba no interactan. Detectarn fallas de lgica donde un solo valor de parmetro hace que el software funcione mal. Se trata defallas de modalidad simple. Este mtodo no detecta fallas de lgica que provoquen un mal funcionamiento cuando dos o ms parmetros
toman ciertos valores simultneamente; es decir, no detecta interacciones. Por tanto, su
capacidad para detectar fallas est limitada.
Dado el nmero relativamente pequeo de parmetros de entrada y valores discretos es posible aplicar una prueba exhaustiva. El nmero de pruebas requeridas es 34 =
81 (grande, pero manejable) . Se encontraran todas las fallas asociadas con permutacin de elementos de datos, pero el esfuerzo requerido es relativamente alto.
El enfoque de prueoa de tabla ortogonal permite proporcionar buena cobertura de
prueba con un nmero considerablemente menor de casos de prueba que la estrategia exhaustiva. En la figura 14.10 se muestra una tabla ortogonal L9 para la funcin enwar de fax.
A continuacin se presenta la evaluacin de Phadke [PHA97] acerca de las pruebas aplicadas con la tabla ortogonal:
PARTE DOS
440
Uh/lCIH
Tabla
ortogonal L9.
PRC11CA DE LA INGENIERA Ofl. SOFTWARE
Coso
Pormelros de pnebo
de pruebo
p
P2
P3
P,
.4
Detecta y aisla todas las fallas de modalidad simple. Una falla de modalidad 5C'.,
ple es un problema consistente con cualqwer nivel de cualquier parmetro simple
ejemplo. si todos los casos de prueba del factor PI = l causan una condicin de errar
trata de una falla de modalidad sunple. En este eemplo, las pruebas 1, 2 y 3 {figura 1~
mostrarn errores. Al analizar la informacin acerca de cules pruebas muestran erra::s.
se identifican cules valores de parmetros causan la falla . En este ejemplo, al notar
las pruebas 1, 2 y 3 causan errores. se aisla [el procesamiento lgico asociado con e:-mz
lo ahora {PI = 1)1 como la fuente del error. Este aislamiento de la falla es importar e
ra corregirla
Detecta todas las fallas de modalidad doble. S1 existe un problema conS1

cuando se presentan niveles especficos de dos parmetros al mismo tiempo, se l e ~
mina falla de modalidad doble. Por supuesto, se trata de una indicacin de incompa
dad de un par de valores o de interacciones dainas entre dos parmetros de prueba
Fallas multimodales. Las tablas ortogonales (del lipo mostrado) slo aseguran la
leccin de fallas de modalidad simple y doble Sin embargo, estas pruebas tambin~
tan muchas fallas mult1modales.
Un anlisis detallado de las pruebas de tabla ortogonal se encontrar en [PHAf:
Dlseo de casos de prueba

Objetivo: Ayudar al equipo de softwore o desarrollar un conjunto completo de cosos de
pruebo de cojo blanco y negro.
Mecnica : Estos herromienlc>s coen en dos amplios cale~ : pn,ebos estticos y dinmicos. Se emplean tres ti-
pos diferentes de herrcmientos de pruebo esttico ~

herramientas de pruebo basados en cdigo, lengua.a
pruebo especializados y herramientas de pruebo
en requisitos los herramientas de pruebo bosodos ~
digo aceptan cdigo fuente como entrado y reolizor"
rios onlisis que llevan a lo generacin de cosos de
CAPTULO 14 TCNICAS DE PRUEBA DEL SOFIWARE
. Los lenguajes de pruebo especializados (como

":>S permiten que un ingeniero de software escribo esiones detallados que describen codo coso de
y lo logstico poro su ejecucin. Los herramientas
prueba basados en requisitos aslan requisitos espedfioel usuario y sugieren cosos de pruebo (o clases de
) que ejercitarn los requisitos. Los herramientas
ices de pruebo interactan con un programo de eje
e,, revisando la cobertura del comino, probando los
iones relacionados con el valor de variables espece instrumentando de otra manera el ffujo de ejecucin
programo.
11T11mientas representativas6
Test, desarrollada por McCobe & Associates

.-w.mccabe.com), implemento diversos tcnicas de
:nieba de la ruto derivados de una evaluacin de lo
::ximplejidod ciclomtica y de otros mtricos de software.
441
Panorama, desarrollada por lnternotional Software Auto

motion, lnc. (www.softworeoutomation.com), abarco un
juego completo de herramientas para desarrollar software orientado a objetos, incluidm herramientas que
ayudan o disear cosos de pruebo y planear pruebas.
TestWorks, desarrollada por Software Research lnc. (www.
soft.com/Products), es un juego completo de herramien
las automatizadas de pruebo que ayudan al diseo de
casos de pruebo poro software desarrollado en C/C++ y
Java y proporcionan soporte o pruebas de regresin.
T-Vec Test Generation System, desarrollado por TVEC
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
pruebo empleando informacin contenida en una espe
cificocin de requisitos orientado o objetos.
La arquitectura del software orientado a objetos genera una serie de subsistemas separados en capas que encapsulan las clases que colaboran entre s. Cada uno de estos elementos del sistema (subsistemas y clases) realiza funciones que ayudan a
cumplir con los requisitos del sistema. Es necesario probar un sistema orientado a objetos en diferentes niveles para descubrir errores que podran ocurrir a medida que
las clases colaboran entre si y los subsistemas se comunican entre las capas de la
arquitectura.
En el aspecto estratgico, la prueba orientada a objetos es similar a la de los sistemas convencionales, pero es diferente en el aspecto tctico. Debido a que los modelos de anlisis y diseo orientados a objetos tienen una estructura y un contenido
similares al programa orientado a objetos resultante, la "prueba" podra empezar con
la revisin de estos modelos. Una vez que se ha generado el cdigo, la prueba orientada a objetos real empieza por Jo "pequeo", con una serie de pruebas diseadas
para ejercitar las operaciones de clase y examinar si existen errores a medida que
una clase colabora con otra. Cuando las clases se integran para formar un subsistema, se aplica la prueba basada en el uso, junto con los enfoques basados en fallas,
para ejercitar plenamente las clases que colaboran entre s. Por ltimo, se emplean
los casos de uso para descubrir errores al nivel de validacin del software.
El diseo convencional de casos de prueba lo determina el concepto entrada-proceso-salida del software o el detalle algortmico de mdulos individuales. La prueba
Las herramientas expuestas aqu slo representan una muestra de esta categorla. En casi todos los
442
PARTE DOS
PRCTICA DE LA INGENIEllA DEL S0f1WARE
orientada a objetos se concentra en el diseo de secuencias apropiadas de ope

para ejercitar los estados de una clase.
h~-
----~
ffiii h:iJN:'&1
cioo4t m1kules Yt&-
cuiso~ sobie pruebos

orlentodos ooi,eio~ ~
8'KanliiJl en
14.7.l
Implicaciones del concepto orientado a objetos en el diseo

de casos de prueba
A medida que la clase evoluciona mediante los modelos de anlisis y diseo se

ve un destino para el diseo de casos de prueba. Debido a que los atributos y las
raciones estn encapsulados, las operaciones de prueba fuera de la clase suele
improductivas. Aunque el encapsulamiento es un concepto de diseo esendorientacin a objetos, representa un obstculo menor cuando se prueba, como
dica Binder [B1N94J: "La prueba debe informar sobre el estado concreto y ~
de un objeto". Sin embargo, el encapsulamiento llega a dificultar la adquisi
esta informacin. A menos que se proporcionen operaciones integradas para
tar los valores de los atributos de clase, ser dificil obtener una instantnea Gd
tado 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 nu~oa
ba, aunque se haya alcanzado la reutilizacin. Adems, la herencia mltiple
plica la prueba ms all de aumentar el nmero de contextos que requiere:-::
prueba [BIN94). Si las subclases que se convierten en instancias a partir de u. perclase se usan dentro del mismo dominio del problema, es posible usar el e
to de casos de prueba derivado de la superclase cuando se prueba la sube.as
embargo, si sta se emplea en un contexto completamente nuevo, los casos ~
ba de la superclase no sern aplicables y ser necesario disear un nuevo c
de pruebas.
14.7.2 Aplicabilidad de mtodos convencionales de diseo de

de prueba
Los mtodos de prueba de caja blanca descritos en secciones anteriores pueG.:l::
carse a las operaciones definidas para una clase. Las tcnicas de flujo de d~
prueba de la ruta bsica o de bucle ayudan a asegurar que se han probado te
instrucciones de una operacin. Sin embargo, la estructura concisa de muct.as
raciones de clase hace que algunos argumenten que el esfuerzo aplicado a ..2
ba de caja blanca podria redirigirse mejor para probar un nivel de clase.
Los mtodos de prueba de caja negra son tan apropiados para los sistemas
tados a objetos como los sistemas que se desarrollan con mtodos conve:naa::
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
das en el estado lAMB95J.
7 Un concepto de orientacin a objetos que debe usarse con extremo cuidado.
443
CAPTULO 14 tCNICAS DE PRUEBA DEI. SOf.WARE
14. 7 .3
:,siste en
crear
"asis sobre un
:le fallos
.uego idear
;:::ro probar
_:esis,
Prueba basada en fallas8
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. Debido a que el producto o sistema debe cumplir con los requisitos del cliente, la planeacin preliminar requerida para realizar la prueba basada en fallas empieza con el modelo del anlisis. La persona que aplica la prueba busca fallas posibles (es decir. aspectos de la implementacin del sistema que generen defectos). Determinar si existen estas 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, entonces este mtodo
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, entonces 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 llamadas a operacin o en conexiones entre mensajes. Tres tipos de
fallas se encuentran en este contexto: resultado inesperado, operacin incorrecta/
mensaje empleado, invocacin incorrecta. Para determinar las fallas a medida que
se invocan las funciones (operaciones), debe examinarse el comportamiento de la
operacin.
La prueba de integracin se aplica a los atributos y a las operaciones. Los "comportamientos" 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 para distintos tipos de comportamiento de objeto.
Es importante observar que las prueba de integracin tratan de encontrar 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 manera de encontrar los requisitos de prueba que ejercitan el cdigo que llama.
"Si se quiere y espero que un programo funcione, lo ms probable es que se veo un programa funcionando (y que~;
pasen por oho los fullas)."
(em 1(1111er et "1.
De la seccin 14.7.3 a la 14. 7.6 se ha adaptado de un articulo de Brian Marick publicado en el grupo de noticias de Internet componente.testing Esta adaptacin se incluye con el permiso del autor. Para conocer mayor informacin sobre estos temas consltese [MAR941. Debe observarse que
las tcnicas analizadas de las secciones 14.7.3 a 14 7 6 son aplicables al software convencional.
444
PARTE DOS PRCTICA DE U\. INGENIERA DEI. SOF'IWARE
14.7.4
Casos de prueba y jerarqua de clase
La herencia no obvia la necesidad de una prueba completa de todas las clases~

vadas. En realidad, llega a complicar el proceso de prueba. Imagnese la siguien~
tuacin. Una clase Base contiene las operaciones heredado() y redefinido( ). Una
se Derivado define redefinido( ) para que sirva en un contexto local. Hay pocas
das de que debe probarse Derivedo::redefinido( ) porque representa un nuevo dise.;
un nuevo cdigo. Pero debe probarse de nuevo Oerivado::heredado( )?
Si Derivado::heredado( ) llama a redefinido( ) y el comportamiento redefinidO'
cambiado, es posible que Derivedo::heredado( ) maneje errneamente el nuevo
portamiento. Por tanto, se necesitan nuevas pruebas aunque no hayan cambia..
Aunque se hoyo
probodo por com~eto
uno clase de base, an
se tendr que probar
todos los doses
derivados de ello.
diseo ni el cdigo. Sin embargo, es importante observar que slo es posible re

zar un subconjunto de todas las pruebas de Oerivado::heredado( ). Si parte del c:l.ise:':c
el cdigo de heredado( ) no depende de redefinido( ) (es decir, no lo llama a J
ningn cdigo que lo llame indirectamente). es innecesario probar de nuevo ese
digo en la clase derivada.
Base::redefinidoO y Derivado::redefinido son operaciones distintas con diferentes
cificaciones e implementaciones. cada una tendra un conjunto de requisit'
prueba derivados de la especificacin y la implementacin. Esos requisitos de ;:-ba revisan fallas posibles: fallas de integracin, de condicin, de lmites, etc. SL
bargo, es probable que las operaciones sean similares; sus conjuntos de reqt..-_.:::
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 Derivado::redefinido( ) que no se satisfagan con las pruebas de ::redefinido( ).
En resumen, las pruebas de Base::redefinido() se aplican a objetos de la clase "
vado. Las entradas 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 basada en escencnios
~,
c&v1
lo pruebo bosoda en
escenarios descubrir
errores que ocurren
La prueba basada en fallas soslaya dos tipos importantes de errores: l) espec..

ciones incorrectas y 2) interacciones entre subsistemas. Cuando ocurren error~
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 comportamiento de u;sistema crea circunstancias {como eventos o flujo de datos) que causan la fa....z
otro subsistema.
~conel
La prueba basada en escenarios se concentra en lo que hace el usuario, no e

dueto. Esto significa que se deben capturar las tareas (mediante casos de uso) ::usuario tiene que realizar y luego aplicarlas, junto con sus variantes, como pn.
Los escenarios descubren los errores de interaccin. Pero esto se logra si 1~
~-
sos de prueba son ms complejos y realistas que las pruebas basadas en fall~
amlo ruolqui8f actor
CAPTin..0 14 TCNICAS DE PRUEBA DEL SOFTWARE
445
pruebas basadas en escenarios tienden a ejercitar varios subsistemas en una sola

prueba (los usuarios no se limitan al uso de un subsistema a la vez).
Como ejemplo, considrese el diseo de pruebas basadas en escenarios para un
editor de texto mediante la revisin de los siguientes casos de uso informales:
caso de uso: Corregir el borradorfinal.
Antecedentes: Es comn que se imprima el borrador "final", se lea y se descubran algunos errores molestos y confusos en la imagen en pantalla. Este caso de uso describe la secuencia 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 escenario describe dos cosas: una prueba y necesidades especficas del usuario.
Las necesidades del usuario son obvias: 1) un mtodo para imprimir pginas individuales, y 2) un mtodo para imprimir un rango de pginas. A medida que se aplica
la prueba, debe probarse la edicin despus 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 las dos funciones del software no tienen la independencia apropiada.
Caso de uso: Imprimir una nueva copia.

Antecedentes: Alguien pide al usuario una nueva copia del documento. Debe imprimirse.
1. Se abre el documento.
2. Se imprime.
3. Se cierra el documento.
una vez ms, el enfoque de la prueba es relativamente obvio, con la excepcin de

que este documento no aparece de la nada. Se cre en una tarea inicial. Aquella tarea afecta a sta?
En muchos editores modernos, los documentos recuerdan cmo se imprimieron
por ltima vez. Como opcin predeterminada, se imprimen de la misma manera la
siguiente ocasin. Despus del escenario Corregir el borradorfinal, con slo seleccionar "Imprimir" en el men y hacer clic en el botn Imprimir del cuadro de dilogo se
imprimir de nuevo la ltima versin corregida. De modo que, de acuerdo con el editor, el escenario correcto debe tener este aspecto:
caso de uso: Imprimir una nueva copia.
1. Se abre el documento.
2. Se selecciona "Imprimir" en el men.
446
PARTE DOS
3. se revisa si est imprimiendo un rango de pginas, si es as, se hace clic para

mir todo el documento.
4. Se hace clic en el botn Imprimir.
5. Se cierra el documento.
Pero este escenario indica un posible error de especificacin. El editor no hace :

el usuario espera razonablemente que haga. Los clientes con frecuencia o ~ revisin indicada en el paso 3. Se sentirn molestos cando vayan a la impres
encuentren una pgina cuando queran I OO. Los clientes molestos sealarn
de especificacin.
Un diseador de casos de prueba podra pasar por alto esta dependencia a!
ar la prueba, pero es probable que el problema surja durante la prueba. El
sable de sta tendra entonces que enfrentarse a la probable respuesta: "as
pone que debla funcionar'"
14.7.6 Estructuras de superficie y de fondo en pruebas
Estructura de superficie es la estructura observable externamente de un pr

orientado a objetos. Es decir, la estructura que resulta inmediatamente obvia
usuario final. En lugar de realizar funciones, se le dan objetos determinados a:I
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 ca
estas tareas requiere comprensin, observacin y comunicacin con usuaros
sentativos (y con todos los usuarios que no lo son que valga la pena tomar en
Seguramente habr algunas diferencias en los detalles. Por ejemplo, en
~
~~
cfAv1
Lo pruebo de
estructuro de superficie
es anlogo olo pruebo
de caja negro. Lo de
esttucturo de fondo es
similor a lo de cojo
blanco.
ma convencional con una interfaz orientada a comandos, el usuario podr1a

dos los comandos como lista de verificacin de una prueba. Si no existen e:SJ::c:JIIII
de prueba para ejercitar un comando, es probable que la prueba soslaye
alg-
reas del usuario (o que la interfaz tenga comandos intiles). En una interfaz
tada a objetos el responsable de la prueba podra emplear todos los objet--s
una lista de verificacin de una prueba.
Las mejores pruebas se derivan cuando el diseador observa el sistema
manera nueva o poco convencional. Por ejemplo, si el sistema o el prodlk.
una interfaz basada en comandos, las pruebas ms completas se derivarar;
seador del caso de prueba pretende que las operaciones sean independien=o.
objetos. Deben plantearse preguntas 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 eierestructura de superficie debe usar objetos y operaciones como pistas que cea tareas omitidas.
La estructura a fondo representa los detalles tcnicos internos de un p
orientado a objetos. Es decir, la estructura que se comprende al examinar e
el cdigo, o ambos. La prueba de estructura de fondo est diseada para eje~
pendencias, comportamientos y mecanismos de comunicacin que se har
CAPTULO 14
TCNICAS DE PRUEBA DEL SOFTWARE
447
cido como parte del modelo de diseo (captulos 9- 12) para el software orientado a
objetos.
Los modelos de anlisis y diseo son la base de la prueba de estructura de fondo.
Por ejemplo, el diagrama de colaboracin UML o el modelo de despliegue describe
las colaboraciones entre objetos y subsistemas que tal vez no sean visibles externamente. El diseador de casos de prueba pregunta entonces: hemos capturado (como prueba) algunas tareas que ejercitan la colaboracin indicada en el diagrama de
colaboracin? Si no es as, por qu?
1: "lo se fflt'giierice de lc!s el'l'Ol1S ni los convierto en crmenes."
En el capitulo 13 se indic que la prueba del software empieza por lo "pequeo" y

lentamente avanza hacia lo "grande". Se prueba en el pequeo entorno de una sola
clase y los mtodos que estn encapsulados en la clase. La prueba aleatoria y la particin son mtodos que se emplean para ejercitar una clase durante una prueba
orientada a objetos [K1R94].
14.8.1 Prueba aleatoria para clases orientadas a objetos

Para ilustrar brevemente estos mtodos, imagnese una aplicacin bancaria en que
una clase Cuenta tiene las siguientes operaciones: abrir(), configurar(), depositar(), retirar(), saldar(), sumar(), JimiteCredito() y cerrar() [KIR94]. Cada una de estas operaciones se aplica a Cuenta, pero hay ciertas restricciones (por ejemplo, la cuenta debe
abrirse antes de aplicar otras operaciones, y debe cerrarse despus de que se han completado todas las operaciones) relacionadas con la naturaleza del problema. Aun con
estas restricciones, hay muchas permutas en las operaciones. El historial de comportamiento mnimo de una instancia de cuenta incluye las siguientes operaciones:
abrirconfigurardepositarretirarcerrar
Esto representa la secuencia de prueba mnima para Cuenta. Sin embargo, podra presentarse una amplia variedad de comportamientos distintos dentro de esta
secuencia.
abrir configurar depositar [ depositar
I retirar I saldar I sumar I limifeCredifo]"retirar ce-
rrar
Es posible generar al azar varias secuencias diferentes de operaciones. Por ejemplo:
Caso de prueba r 1: abrir configurar depositar depositar saldar sumar retirar ce1Tar
caso de prueba r 2 : abrir configurar depositar retirar depositar saldar limiteCredito retirar cerrar
stas y otras pruebas de orden aleatorio se aplican para ejercitar diferentes historiales de instancias de clase.
448
PARTE DOS
PRC11CA DE LA lNGENJERA Dll. SOMWARE
HOGARSEGURO
l'nleba de da.se
la weaam Cubculo de Sholro.
IN ad, ... Jamie y Shakira, inllgronle$ del equipo
d. lrpno del soltwor. ,HogorSeguro que e$ln trobo, , . an el cli.i'io de cmos de prueba para lo funcin
de IIIQUriclad.
nr a
&a l'INlftlQ
o. cualquier manero, llene una in-
lw{J, odivor{J, desoctivar(}

'I ~ . Ai1'9s de que un sensor te,,go lo posib,lidod de
oc:tMane. Una '119% oclM:ldo, puede leerse y pro- - a poilile d.adiwarlo en cuolquer momento, o
- cw.
De_.
-,.cilaf6
lqa poc:esado uno condicin de alarmo

que cWnf una tK'UllllCia -.,le de pruebo que
1U hitlorial de compoi lal ,Mento
. .a
IMul*a Q Ja... la ...... secuencio.)
...
#2: activwp,obll- [IN,TuuDIW

#3: [IN,]"
- -O'lft cualro ope,ocioi.:
Shokira: lo s, lo l He aqu ollas . . . . . . que

eloboiado.
(Muestra o .lamie los siguienlas IICUendaa,)
#1: ......,....,....... . . , , .
........ Eso funcionar, pero 6 - que probar m6s
Shakira: En r.alidod no. En #4 . i - ha

do. lo que realnwnte pruebo #4 si lo o,,.acit
vor funciona como cW.ria. Si prw...., i.ro
f)f'obori) despus de dasa.:war(), cW. 911m
mensaje de error. Si no lo hoce,..__ . . . .
error en lo operacin desactYor.
Jamie: Estupendo. Slo recuerda que 1m adO
bo, tienen que apliane a cada tpode.....,
codo operoci6n puede.._ cM.wia . . .
diendo del tipo de sensor.
Shaldra: No .. preocua. &e ... plan
14.8.2 Prueba de particin al nivel de clase

La prueba de particin reduce el nmero de casos de prueba requeridos para
tar la clase de manera muy parecida a la particin equivalente (seccin 14 61
el software convencional. La entrada y la salida se ordenan en categoras y se
an casos de prueba para ejercitar cada categora. Cmo se derivan las c~-
Cvles
opciones de
prueba estn
disponibles al
aivel de dase?
de particin'
La particin basada en el estado ordena en categoras las operaciones de
partir de su capacidad para cambiar el estado de la clase. Si se piensa una
en la clase Cuenta, las operaciones de estado incluyen depositar() y rearar(
tras que las que no son de estado incluyen saldar( ), sumar( ) y limiteCred1
pruebas estn diseadas de manera que ejercitan por separado las operad
cambian de estado y las que no lo hacen. Por tanto,
Caso de prueba p 1: abrir configurardepositar depositarretitar retirar cerrar
Caso de prueba p~ abrirconfigurar depositar sumar &miteCreditoretirar c.,,_
CAPTULO 14
TCNICAS DE PRUEBA DEL SOfTNARE
El caso de prueba p1 cambia de estado. mientras que el caso de
449
prueba p2 ejercita
operaciones que no cambian de estado (aparte de las que se encuentran en la secuencia de prueba mnima).
La particin basada en atributos ordena en categoras las operaciones de clase basadas en los atributos que utilizan. En el caso de la clase cuenta, los atributos saldar
y limiteCredito se emplean para definir particiones. Las operaciones se dividen en
tres particiones: 1) operaciones que usan limiteCredito, 2) operaciones que modifican

limiteCredito, y 3) operaciones que no usan ni modifican limiteCredito. Entonces se disean secuencias de prueba para cada particin.
La particin basada en catego1ias 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 [abrir( ), configurar( )J, operaciones computacionales [depositar(), retirar( )], consultas [saldar(), sumar(), limiteCredito( )J y de terminacin [cerrar( )J
El diseo de casos de prueba se vuelve ms complicado cuando empieza la integracin del sistema orientado a objetos. En esta etapa debe empezar la prueba de colaboracin entre clases. Para ilustrar la "generacin de casos de prueba de interclase"
[KIR94], se expande el ejemplo del sistema bancario presentado en la seccin 14.8
para que incluya las clases y colaboraciones indicadas en la figura 14.11. La direccin de las flechas en la figura indica la direccin de los mensajes. Y las etiquetas individuales indican las operaciones que se invocan como consecuencia de la colaboracin indicada por los mensajes.
Como en la prueba de clases individuales, la prueba de colaboracin entre clases
se lleva a cabo al aplicar mtodos aleatorios y de particin, adems de pruebas basadas en el escenario 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 mensajes a

otras clases del servidor.
2 . En cada mensaje generado, determnese la clase colaboradora y la operacin

correspondiente en el objeto servidor.
3 . En cada operacin del objeto servidor (invocada por los mensajes enviados
desde el objeto cliente) determnense los mensajes que transmite.
4. En cada uno de los mensajes, detennnese el siguiente nivel de operaciones

invocadas e incorprelos en la secuencia de prueba.
450
Diagrama de
torjetolnsertodo
verificorCuenlo
contraseo
YerificorNIP
deposilor
verificorf'olitico
retirar
solicitorRetiro
$OlicitorDeposito
eslotusCuento
.----fo,--..,.de--.. terminar . . . - - - - - infoCuento - - - - lnlef z _,_
Cajero
Banco
uwor o ...,
Aulomotico
coero olllom1ico - - obrirCue nto
verificorEs1o"1u
" s- - - -depositolnic10""''""'"_ __
estotusDeposito
outonzorTorjeto
limiteCredito
delpochorf.ctivo
de$0ulorizor
tipoCuento
,mprimirEstodoCuenlo
cerrorCuenlo
soldar
leerlnloTo~eto
retira r
obtenerMontoEfectivo
deposita r
cerrar
colaboracin
de clases
para una
apllcac16n
bancaria
(adaptado de
CKIR94D.
Cojera
l
El
lnfo
Volidocion
Como ejemplo [KJR941. considrese una secuencia de operaciones para la

Banco relacionada con una clase cajeroAutomatico (figura 14 11):
verifica..Cuenta vetif1CarNIP [[ verlficarPolitica solictudRatiro] l solicitarDeposito Iaoli::Clila.
Cuenta]"
un caso de prueba aleatoria para la clase Banco sera
Caso de prueba rJ = verificarCuentaveriflcwNIPsolicttarOepos;to

Considerar a los colaboradores que participan en la prueba requiere toma ce
ta los mensajes asociados con cada una de las operaciones indicadas en el
prueba r3 Banco debe colaborar con infoValidacion para ejecutar virift
verijicarNIP( ). Banco debe colaborar con cuenta para ejecutar sohdtarDeJA,-11::(
tanto, se tiene un nuevo caso de prueba que ejercita estas colaboraciones:
Caso de prueba r4 = verif1C&rCuenta8anoo[validarCuentalnfoValidacion)

veriftCSrNIPBanco [ validarNIPlnfovat.dacion] solicitarOeposito [ depo&ltarcuenta]
El enfoque para la prueba de particin de clases mltiples es similar a ,...._.____

empleado para la de clases individuales. Como se analiz en la seccin 14 .e 2.
mete a particin una sola clase. Sin embargo. se expande la secuencia de
para incluir las operaciones invocadas mediante mensajes a las clases q.._
ran. Un enfoque alterno lleva a cabo la particin de las pruebas con base ec
p:::ea
terfaces de una clase determinada. Si se toma como referencia la figura 14 11

se Banco recibe mensajes de las clases cajeroAutomatico y cajero. Por
mtodos dentro de Banco se prueban al particionarlas entre las que sirven a
roAutomatico y a cajero. La particin basada en el estado (seccin 14 8 2
para refinar an ms las particiones
451
CAPTULO 14 TCNICAS DE PRUEBA DEL SOFTWARE
14.9.2 Pruebas derivadas de modelos de comportamiento

En el captulo 8 se analiz el uso del diagrama de estado como modelo para representar el comportamiento dinmico de una clase. El diagrama de estado de una clase ayuda a derivar una secuencia de pruebas que revisa el comportamiento dinmico de la clase (Y las clases que colaboran con ella). En la figura 14.12 [K1R94J se
muestra un diagrama de estado para la clase Cuenta que ya se analiz. Si se observa, las transiciones iniciales recorren los estados vaciar Cuenta y configurar cuenta.
Un retiro final y un cierre de la cuenta causan que la clase Cuenta haga transiciones a los estados cuentalnactiva y cuentaMuerta, respectivamente.
Las pruebas que se diseen deben cubrir todos los estados [KIR94]. Es decir, las
secuencias de operacin deben lograr que la clase Cuenta haga una transicin a todos los estados permisibles:
caso de prueba s,:
abrir configurCuenta depositar(inicial) retirar(final) ce1Tar
Debe notarse que esta secuencia es idntica a la secuencia de la prueba mnima tratada en la seccin 14.9.1. La secuencia de la prueba adicional se agrega a la sucesin mnima,
caso de prueba s,:
abrir configurarCuenta depositar(inicial) depositar saldar acreditar retirar(final) cerrar
Caso de prueba s2 :
abrir configurarCuenta depositar(inicial) depositar retirar infoCuenta retirar(final) cerrar
Es posible derivar an ms casos de prueba para asegurar que todos los comportamientos de la clase se hayan ejercitado adecuadamente. En situaciones en que el
comportamiento de la clase da como resultado la colaboracin con una o ms clases, se utilizan varios diagramas de estado para registrar el flujo del comportamiento del sistema.
Abrir
vocior
Cuento
configurar Cuento
configurar
CuerifQ
depositar (inicial)
depositar
soldor
Credito
infoCuento
retirar
retirar (final)
Cuento
muerta
Cuento
inactivo
452
PARTE DOS
PRCl'ICA DE LA INGENIERA DEL sonwARE
El modelo de estado puede recorrerse de una manera "primero-en-anc:h;...:i

[MGR94]. En este contexto, primero-en-anchura indica que un caso de pruebas
ejercita una transicin. Cuando debe probarse una nueva transicin slo se ut:it:r:
transiciones probadas previamente.
Imagnese que el objeto TarjetaCredito es parte del sistema bancario. El
inicial de TarjetaCredito es indefinido (es decir, no se ha proporcionado un n
ro de tarjeta de crdito). Tras leer la tarjeta durante una venta, el objeto toma U!"'
tacto dejinido; es decir, se definen los atributos numero, tarjeta y fecha veocimiento
to con los identificadores especficos del banco. La tarjeta de crdito es
cuando se le enva para autorizacin, y es aprobada cuando se recibe la autc
cin. La transicin de TarjetaCredito de un estado a otro se prueba derivand..:
sos de prueba que causen la transicin. Un mtodo primero-en-anchura para est..:::
de prueba no ejercitara remitida antes de indefinida o definida. En este caso, usana
siciones que no se han probado y, por tanto, violarla el criterio primero-en-ancr....n..
Los mtodos de prueba analizados en secciones anteriores suelen aplicarse e

dos los entornos, las arquitecturas y las aplicaciones, pero en ocasiones se pcionan directrices y enfoques nicos para las pruebas. En esta seccin se abo;-~
las directrices para prueba de los entornos, las arquitecturas y las aplicaciones
cializadas que suelen encontrar los ingenieros de software.
tcoNsuo9"
14.10.1
sese uno estrategia

de pruebo similor olo
o/eororio o de
particin (secd6n
14.8) poro disear
pruebas de interfaz de
IJSl/OriO.
interfaces grficas de usuario (GUI, por sus siglas en ingls) plantean ctesa:
teresantes a los ingenieros de software. Debido a los componentes reutilizables
porcionados como parte de los entornos de desarrollo de la GUI, la creacin de
terfaz de usuario consume menos tiempo y es ms precisa (captulo 12). Pero
mo tiempo ha crecido la complejidad de las GUJ, lo que dificulta ms el dise
ejecucin de casos de prueba.
Pruebas de interfaces grficas de usuario
Las
Debido a que muchas GUI modernas tienen un aspecto y un modo de uso
hlf:iiNii
En el siglJienle 5ilioc Web

se encontmrnn
nonoocioo y reoJSOS
iles pmo lo pruebo de
dmle/srilor.
...
www.ast-
:e
res, es posible derivar una serie de pruebas estndar. Las grficas de mod
estado finito se usan para derivar una serie de pruebas que ejerciten objetos
ficos de datos y programas que resultan relevantes para la GUI.
Debido al gran nmero de permutaciones asociadas con las operaciones
GUI, la prueba debe reducirse empleando herramientas automatizadas. En
mos aos ha aparecido en el mercado una amplia serie de herramientas de de GUI. Para un mayor anlisis al respecto consulte el captulo 12.
14. 10.2 Prueba de arquitecturas cliente/ servidor

La arquitectura cliente/servidor representa un importante desafio para
prueban el software. La naturaleza distribuida de los entornos cliente/sen
CAPTULO 14
453
TCNICAS DE PRUEBA DEL sonwA1ZE
aspectos de desempeo relacionados con el proceso de transaccin, la posible presencia de varias plataformas de hardware diferentes, la complejidad de la comunicacin en red, la necesidad de servir a varios clientes desde una base de datos centralizada (o, en algunos casos, distribuida) y los requisitos de coordinacin impuestos al servidor se combinan para que la prueba de las arquitecturas de software
cliente/servidor resulte considerablemente ms dificil que la prueba de aplicaciones
independientes. En realidad, estudios recientes de la industria indican un aumento
importante en el tiempo y costo de la prueba cuando se desarrollan entornos cliente/servidor.
En el temo de los prebos existe uno bueno dosis desimilitudentre lossistemas trodidonol yditntl!/~rvd0t .
KeltykirM ;.
En general, la prueba del software cliente/servidor se presenta en tres niveles diferentes: 1) aplicaciones de cliente individuales se prueban en una modalidad "desconectada"; la operacin del servidor y la red no se toman 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 arquitectura cliente/servidor, incluida la operacin y el desempeo de la red.
Aunque muchos tipos diferentes de prueba se conducen en cada uno de estos niveles de detalle, los siguientes enfoques de prueba suelen encontrarse para aplicaciones cliente/servidor:
Pruebas de funcionalidad de la aplicacin. La funcionalidad de las aplicaciones de cliente se prueba empleando los mtodos analizados en este captulo. En esencia, la aplicacin se prueba de manera independiente.
Pruebas de servidor. Se prueban las funciones de coordinacin y manejo de
datos del servidor. Tambin se considera el desempeo del servidor (tiempo
de respuesta y procesamiento total de los datos).
Pruebas de base de datos. Se prueba la exactitud e integridad de los datos
almacenados en el servidor. Se examinan las transacciones que realizaron las
aplicaciones de cliente para asegurar que los datos se almacenan, actualizan
y recuperan apropiadamente. Tambin se prueba la funcin de archivado.
Pruebas de transaccin. 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 procesamiento y en aspectos del desempeo (por ejemplo, tiempos de procesamiento de las transacciones y volumen de stas).
Pruebas de comunicaciones de red. Con estas pruebas se verifica que la
comunicacin entre los nodos de la red ocurre de manera correcta y que el
paso de mensajes, las transacciones y el trfico de la red relacionado se realiza sin errores. Tambin es posible realizar pruebas de seguridad de la red como parte de estas pruebas.
454
PARTE DOS
PRCTICA DE LA INGalIERA DEL SOflWARE
Para completar estos enfoques de prueba, Musa [MUS93] recomienda el desarro...c

de perfiles operadonales derivados de escenarios de uso de cliente/servidor. 9 Un pefil operacional indica la manera en que diferentes tipos de usuarios interoperan G.el sistema cliente/servidor. Es decir, los perfiles proporcionan un "patrn de us:r
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 imgenes de grandes cantidades de casos prueba preparados para ejercitar los programas de cmputo y los datos que maru:::-lan. Si se recuerda la definicin de software presentada en el primer captulo de ::s-te libro, es importante observar que la prueba tambin debe extenderse al tercer e._
mento de la configuracin del software: la documentacin.
Los errores en la documentacin son tan devastadores para la aceptacin del ;-grama como los errores en los datos o el cdigo fuente. Nada es ms frustrante ~ seguir una gua de usuario o una funcin de ayuda en lnea con toda pulcritud y
tener resultados o comportamiento que no coinciden con los descritos en la d...
mentacin. Por eso la prueba de la documentacin debe ser una parte significa:
de cualquier plan de prueba del software.
La prueba de la documentacin se aborda en dos fases. En la primera, revis;.o::
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
INFORMACIN
El diseo del documento (formato, tipo de letra, 5a'l'"
gras, imgenes) es apropiado poro comprender)' ::s
milor rpidamente lo informacin?
Es exacta la descripcin de codo secuencio de interoc

dones?
Los ejemplos son exactos?
la terminologa, las descripciones de men y los res
puestas del sistema son consistentes con el programo
real?
Es realmente fcil localiz.or uno guo dentro de lo documentacin?
El uso de lo documentacin facilita lo deteccin y reso
lucin de errores?
El contenido y el ndice del documento son exactos y
completos?
Todos los mensajes de error del software que se ae

pliegan poro el usuario estn descritos con ms ds:
en el documento? las acciones que deben emprer-:=se como consecuencia de un mensaje de error eslaromente delineadas?
Si se usan los vnculos de hipertexto, son exactos
completos?
Si se uso el hipertexfo, el diseo de lo novegocir
apropiado poro lo informacin requerida?
la nica manero viable de responder a estos preguncc
hacer que un tercero (por ejemplo, algunos usuarios
donados) pruebe lo documentacin en el contexto oe
del programo. Se habrn de indicar todos los discrep,:r
cios y definirse las reas dbiles o ambiguas del doc.:
to poro una posible reescritura.
9 Debe observarse que los perfiles operacionales pueden aplicarse para probar todos los tipos
quitecturas del sistema, no slo la cliente/ servidor.
CAPTULO 14 TCNICAS DE PRUEBA DEI. SOFTWARE
455
14.10.4 Prueba de sistemas de tiempo real

La naturaleza asincrnica, dependiente del tiempo, de muchas aplicaciones en tiempo real agrega un elemento nuevo (y dificil en potencia) a la mezcla de pruebas: el
tiempo. El diseador del caso de prueba no slo debe considerar los casos de prueba convencionales, sino tambin el manejo de eventos (es decir, el procesamiento
de interrupciones), la temporizacin de los datos y el paralelismo entre las tareas
(procesos) que manejan los datos. En muchas situaciones, los datos de prueba proporcionados cuando el sistema en tiempo real est en un estado producirn un procesamiento apropiado, mientras que los mismos datos proporcionados cuando el
sistema est en un estado diferente provocarn un error.
Por ejemplo, el software en tiempo real que controla una nueva fotocopiadora
acepta interrupciones del operador (es decir, el operador del equipo oprime teclas
como REINICIAR u OSCURECER) sin error cuando el equipo hace copias (en el estado copiar'). Si estas mismas interrupciones del operador se ingresan cuando el equipo se encuentra en el estado atasco, se perder la pantalla de visualizacin del cdigo de diagnstico (indicando la ubicacin del atasco), lo que representa un error.
Adems, la ntima relacin entre el software en tiempo real y su entorno de hardware llegan a causar problemas en la prueba. Las pruebas del software deben considerar el impacto de las fallas del hardware en el procesamiento del software. Resulta extremadamente dficil simular estas fallas de manera realista.
Los mtodos exhaustivos de diseo de casos de prueba para sistemas en tiempo
real siguen evolucionando. Sin embargo, es posible proponer una estrategia de cuatro pasos:
Prueba de tareas. El primer paso en la prueba del software 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 durante estas pruebas.) La prueba de tareas descubre
errores de lgica y funcionamiento, pero no de tiempo ni de comportamiento.
Prueba de comportamiento. Con el empleo de modelos del sistema creados con herramientas automatizadas es posible simular el comportamiento de
un sistema en tiempo real y examinarlo como una consecuencia de eventos externos. 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 intertareas. una vez que se hayan aislado los errores en tareas individuales y en el comportamiento del sistema, la prueba se desplaza hacia los
errores relacionados con el tiempo. Se prueban las tareas asincrnicas de las
cuales se sabe que se comunican entre s, empleando diferentes tasas de datos y cargas de procesamiento para determinar si ocurrirn errores de sincronizacin intertareas. Adems, se prueban las tareas que se comunican por
medio de la cola de mensajes o el almacn de datos para descubrir errores en
el tamao de estas reas de almacenamiento de datos.
456
PARTE DOS
PRcnCA DE LA INGENIERA DEL SOf"IWARE
Prueba del sistema . El software y el hardware estn integrados, de moc.

que se aplica un rango completo de pruebas del sistema (captulo 13) par:
tarde descubrir errores en la interfaz software/hardware. casi todos los s
mas en tiempo real procesan interrupciones. Por tanto, resulta esencial la
prueba del manejo de estos eventos booleanos. Por medio del diagrama _
estado y la especificacin de control (captulo 8). el responsable de la pTIA..
desarrolla una lista de todas 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 manejado apropiadamente las propiedades de int
cin?
- Se ha manejado correctamente el procesamiento de cada interrupcio:- El desempeo de cada procedimiento de manejo de interrupcion~
ejemplo, el tiempo de procesamiento) cumple con los requisitos?
-Un elevado volumen de interrupciones que llega en momentos crticos
problemas en la funcin o el desempeo?
Adems, deben probarse reas de datos globales que se emplean para
informacin como parte de un procesamiento de interrupciones, con el fin ce
luar la posibilidad de generacin de efectos colaterales.
-HMHiiUd1
\Ju!llodores oms de
70 patrones de pruebo
seexooflllrOn en
www~
~
~~
c&vE
Los potrones de pruebo
oyudon oun equipo de
software o
comunicarse mejor
sobre lo pruebo y
kmlin ocomprender
mep kis fuerzas que
fea OIII em,que
e5jjEtO de iruelxi.
En captulos anteriores se analiz el uso de patrones como mecanismo para

bir los bloques de construccin del software o situaciones de ingenieria del se.:
Estos bloques de construccin o situaciones se repiten a medida que se co,nc'--.
diferentes aplicaciones o que se realizan diferentes proyectos. Como sus cortes 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 softv.a; _
directriz til cuando empiezan las actividades de prueba, tambin proporcio..
beneficios adicionales descritos por Marick [MAR02J:
1. Proporcionan una terminologia a los encargados de la resolucin de los prob
" Hey, sabes?, debemos usar un Objeto Nulo.
2. Concentran la atencin en las fuerzas que se encuentran detrs del problema. Ese
mite a los diseadores [de casos de prueba] comprender mejor cundo se aplica
solucin, y por qu.
3. Estimulan el razonamiento iterativo. cada solucin crea un nuevo contexto para
ver nuevos problemas.
CAPTULO 14 TCNICAS DE PRUEBA DEL SOFJWARE
457
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
hoc. Si los patrones de prueba ayudan a un equipo de software a comunicarse de
manera ms efectiva, a comprender las fuerzas motivadoras que llevan a un enfoque especfico de prueba y a considerar el diseo de los casos de prueba como una
actividad en evolucin, se habr logrado mucho.
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 patrones de prueba (por ejemplo, [B1N99l, [MAR02]). Los siguientes tres patrones (presentados en forma resumida), proporcionan ejemplos representativos:
Nombre del pa'n: testigo par
Resumen: Patrn orientado a procesos, testigo par describe una tcnica anloga a la programacin par (captulo 4), en la cual dos responsables de una pruebas trabajan de manera conjunta para disear y ejecutar una serie de pruebas aplicables a actividades de prueba
de unidad, integracin o validacin.
Nombre del patrn: interfaz de prueba separada

Resumen: En sistemas orientados a objetos es necesario probar cada clase, incluidas las
"clases internas" (es decir, las clases que no exponen ninguna interfaz fuera del componente que las utiliza). El patrn interfaz de prueba separada describe la manera de
crear "una interfaz de prueba que permita describir pruebas especficas en clases que slo son visibles internamente para un componente" !LANOII.
Nombre del patrn: prueba de escenario

Resumen: Una vez que se ha aplicado una prueba de unidad o de integracin es necesario determinar si el software se comportar de manera tal que satisfaga al usuario. El patrn prueba de escenario describe una tcnica para ejercitar el software desde el punto
de vista del usuario. Una falla en este nivel indica que el software no satisface los requisitos de un usuario visible [KANOIJ.
Un anlisis completo de los patrones de prueba est ms all del alcance de este libro. El lector interesado debe consultar [BIN99] y [MAR02] para conocer mayor informacin sobre este importante tema.
14.12 IIIVMIH
El objetivo principal del diseo de casos de prueba consiste en derivar un conjunto
de pruebas que tenga la mayor probabilidad de descubrir errores en el software. Alcanzar este objetivo requiere emplear dos categoras diferentes de tcnicas de diseo de casos de prueba (aplicables a sistemas convencionales y orientados a objetos):
las pruebas de caja negra y de caja blanca.
Las pruebas de caja blanca se concentran en la estructura de control del programa. Los casos de prueba se derivan para asegurar que todas las instrucciones del
programa se ejecuten por lo menos una vez durante la prueba, y que todas las condiciones lgicas se ejerciten. La prueba de la ruta bsica, una tcnica de caja blan-
458
PARTE DOS
?RCTICA DE LA INGENIERIA DEL SOF!WARE
ca, aprovecha las grficas del programa (o matrices de grficas) para derivar un ~
junto de pruebas linealmente independientes que aseguren una cobertura. La Fba de condicin y de flujo de datos ejercitan an ms la lgica del programa _
prueba de bucle complementa otras tcnicas de caja blanca al proporcionar un
cedirniento para ejercitar bucles con grados diversos de complejidad.
Las pruebas de caja negra estn diseadas para validar requisitos funcional~
importar el funcionamiento interno de un programa. Estas tcnicas de pru~
concentran en el dominio de la informacin del software, derivando casos de .
ba mediante particin de los dominios de entrada y salida de un programa en '
tal que proporcione cobertura completa. La particin equivalente divide el dode entrada en clases de datos que probablemente ejercitarn una funcin espec..
del software. El anlisis de valores limite prueba la capacidad del programa para
nejar datos en los lmites de aceptabilidad. La prueba de tabla ortogonal pro:x:
na un mtodo eficiente y sistemtico de probar sistemas con nmeros pequef_
parmetros 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 a: l::
prueba del software convencional, la tctica para la prueba orientada a obje-~
fieren un poco. El concepto de prueba se ensancha para incluir la revisin de
delo de anlisis y diseo. Adems, el eje de la prueba se desplaza del comnr.-.__.
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 .;e
tos mtodos ejercita las operaciones encapsuladas por la clase. Las secue~
prueba estn diseadas para asegurar que se ejerciten operaciones relevan;.cs.
examina el estado de la clase, representado por los valores de sus atributos, pa;
terminar si existen errores.
La prueba de integracin se realiza mediante una estrategia basada en el us.=:
te tipo de prueba construye el sistema en capas, empezando con las clases
usan clase de servidor. Los mtodos de diseo de casos de prueba de int
tambin pueden emplear pruebas aleatorias y de particin. Adems, se utiliza.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 mtodos 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 documentacin y funciones de ayuda y de
mas en tiempo real requieren directrices y tcnicas especializadas.
Los desarrolladores de software con experiencia suelen decir: "La prueba
termina, slo se transfiere del ingeniero del software al cliente. cada vez q"-~
usa el programa, est realizando una prueba". Al aplicar el diseo de casos de
ba, el ingeniero de software logra pruebas ms completas y, por tanto, desecorrige el mayor nmero de errores antes de que empiecen las "pruebas del
CAPTULO 14 TCNICAS DE PRUEBA DEL SOF'IWARE
459
[AMB95J Ambler. S., "Using Use casesH, en SOftware Development, julio de 1995, pp. 53-61.
[BEI90} Beizer, B., Software TesUng Techniques, segunda edicin, Van Nostrand-Rcinhold, 1990.
[BEI95] Beizer, B., Black-Box TesUng, Wiley, 1995.
[BIN94] Binder, R. V., "Testing Object-Oriented Systems: A Status Report", en American Programmer; vol. 7, nm. 4, abril de 1994, pp. 23-28.
[BIN99] Binder, R., Testing Object-Oriented systems: Models, Patterns, and Too/s, Addison-Wesley,
1999
[DEU79] Deutsch, M., "Verification and Validation", en SOftware Engineering (R. Jensen y C. Tonies, eds.}, Prentice-Hall, 1979, pp. 329-408.
[FRA88) Frankl, P. G. y E. J. Weyuker, "An Applicable Family of Data Flow Testing Criteria", en
IEEE Trans. SOftware Engineeiing, vol. SE-14, nm. l O, octubre de 1988, pp. 1483-1498.
(FRA93] Frankl, P. G. y S. Weiss, "An Experimental Comparison of the Effectiveness of Branch
Testing and Data Flow", en IEEE Trans. Software Engineering, vol. SE-19, nm.8, agosto de
1993, pp. 770-787.
[KAN93] Kaner, C., J. Falk y H. Q. Nguyen, Testing Computer Software, segunda edicin, Van Nostrand-Reinhold, 1993.
[KANOI] Kaner, C., "Pattern: Scenario Testing" (borrador), 2001, disponible en http:/ /www.testing.com/test-pattems/patterns/pattem-scenario-testing-kaner.html.
[KIR94J Kirani, S. y W. T. Tsai, "Specification and Verification of Object-Oriented Programs",
Technical Report TR 94-64, Computer Science Department, University of Minnesota, diciembre de 1994.
[LANOIJ Lange, M., "lt's Testing Time! Pattems for Testing Software", junio de 2001, disponible
para descarga en http:/ /www.testing.com/test-patterns/pattems/index.html.
(LIN94] Lindland, O. l. et al.. "Understanding Quality in Conceptual Modeling", en IEEE Software,
vol. 11, nm. 4, julio de l 994, pp. 42-49.
[MAR94] Marick, B., The Crafl o/Software Testing. Prentice-Hall, 1994.
[MAR02J Marick, B., "Software Testing Pattems", 2002, http://www.testing.com/test-pattems/
index.html.
[MCC76J McCabe, T., "A Software Complexity Measure", en IEEE n-ans. SOftware Engneering, vol.
SE-2, diciembre de 1976, pp. 308-320.
[MGR94) McGregor, J. D. y T. D. Korson, "Integrated Object-Oriented Testing and Development
Processes", CACM, vol. 37, nm. 9. septiembre de 1994, pp. 59-77.
[MUS93J Musa, J.. "Operational Profiles in Software Reliability Engineering", en IEEE Software,
marzo de 1993. pp. 14-32.
[MYE79J Myers, G., The Art of SOJtware Testing, Wiley, 1979.
[NTA88J Ntafos, S. C., "A Cornparison of Sorne Structural Testing Strategies", en IEEE n-ans. Software Engineering, vol. SE- 14, nm.6, junio de 1988, pp. 868-874.
[PHA89] Phadke, M.S., Quality Engneering Using Robust Design, Prentice-Hall, 1989.
[PHA97] Phadke, M. S., "Planning Efficient Software Tests". Crosstalk, vol. 1o. nm. 1O, octubre
de 1997, pp. 11-15.
]TAI89J Tai, K. C., "What to Do Beyond Branch Testing". ACM Software Engineering Notes, vol. 14,
nm. 2, abril de 1989, pp. 58-61.
PIAILIMAI t fYl79$ A coNstpERAR

14.1. Myers [MYE79] aplica el siguiente programa como autoevaluacin de la capacidad propia para especificar pruebas adecuadas: un programa lee tres valores enteros. Los tres valores
se interpretan como si representaran las longitudes de los lados de un tringulo. El programa
imprime un mensaje que indica si el tringulo es escaleno, issceles o equiltero. Desarrllese
un conjunto de casos de prueba que se considere que prueben adecuadamente este programa.
14.2 . Disear e implementar el programa (con maneo de errores cuando sea apropiado) especificado en el problema 14 .1. Derivar una grfica de flujo para el programa y aplicar la prueba
de la ruta bsica para desarrollar casos de prueba que garanticen que se han probado todas las
instrucciones del programa. Ejecutar los casos y mostrar los resultados.
460
PARTE DOS
PRCTICA DE LA INGENlERA
oa sonwARE
14.3 . Al lector le es posible pensar en alguna prueba adicional de caractersticas que nanalizaron en la seccin 14.7?
14.4 . Seleccionar un componente de software que el lector haya diseado e implementad..
cientemente. Disear un conjunto de casos de prueba que aseguren que todas las instruc~
se hayan ejecutado con la prueba de la ruta bsica.
14.5 . Especificar. disear e implementar una herramienta de software que calcule la com:dad ciclomtica para el lenguaje de programacin que se elija. Aplicar la matriz de grfic
mo estructura operativa de datos en el diseo.
14.6. Lase Beizer [BEI95] y determnese la manera en que el programa que se desarro'
el problema 14.5 puede extenderse para acomodar varios pesos de enlace. Extindase la ..~
mienta para procesar probabilidades de ejecucin o tiempos de procesamiento de enlaces
14. 7. Disese una herramienta automatizada que reconozca bucles y los ordene en
rias, como se indica en la seccin 14.5.3.
14.8. Extindase la herramienta descrita en el problema 14.7 para generar casos de prucaa
ra cada categora de bucle, una vez encontrada. Ser necesario desarrollar esta funcin ::
nera interactiva con el encargado de la prueba.
14.9. Ofrzcanse por lo menos tres ejemplos en que la prueba de caja negra dara la ,q.r.;,c,..~
de que "todo est bienu, mientras que las pruebas de caja blanca descubriran un error por lo menos tres ejemplos en que suceda lo contrario: la prueba de caja blanca darla la
sin de que "todo est bien", mientras que las pruebas de caja negra descubriran un err.x:
u
14. 1o. La prueba exhaustiva (en caso de que sea posible en programas muy pequeos
tiza que el programa es totalmente correcto?
14.11 . En palabras propias, describase por qu la clase es la menor unidad razonable
prueba dentro de un sistema orientado a objetos.
14. 12. Por qu se tienen que volver a probar subclases que crean instancias a partlT
clase existente si sta ya se ha probado por completo? Es posible usar los casos de p
seados para la clase existente?
14. 13. Aplquense pruebas aleatorias y de particin a tres clases definidas en el dise"
tema HogarSeguro. Prodzcanse casos de prueba que indiquen las secuencias de operao::
se invocarn.
14. 14. Aplquense pruebas de clase mltiple y prubense derivados del modelo de c
miento para el diseo HogarSeguro.
14. 15. Prubese un manual de usuario (o una funcin de ayuda) de una aplicacin cr...e
con frecuencia. Encuntrese por lo menos un error en la documentacin.
Entre docenas de libros que presentan mtodos de diseo de casos de prueba se er

craig y Kaskiel (Systematic software Testing, Artech House, 2002), Tamres (Jntrodudng
Testing, Addison-Wesley, 2002), Whittaker (How to Break sojlware, Addison-Wesley. 2
gensen (SOjlware Testing: A Craftman's Approach, CRC Press, 2002), Splaine y sus coj,e
Web Testing Handbook, Software Quality Engineering Publishing, 2001), Patton (SOjh..c-:
Sams Publishing, 2000), Kaner y sus colegas (Testing Computer SOj!ware. segunda
ley, 1999). Adems, Hutcheson (SOjlware Testing Methods and Metrics: The Most Imxr
McGraw-Hill, 1997) y Marick (The Craft of SOjhvare Tesling: Subsystem Testing Indud;.Based and Object-Oriented Testing, Prentice-Hall, 1995) presentan tratamientos de m,
trategias de prueba.
Myers [MYE79] sigue siendo un texto clsico, que analiza las tcnicas de caja negrdetalle. Beizer [BEl90J proporciona una amplia cobertura de las tcnicas de caja bla:-
CAPTULO 14 TCNICAS DE PRUEBA DEI. SOF"TWAAE
461
duce u n nivel de rigor matemtico que a menudo se omite en otros tratamientos de pruebas. su
ltimo libro [BEI95] presenta un tratamiento conciso de mtodos importantes. Peny (Ejfective
Melhods Jor Software Tesling, Wiley-QED, 1995) y Friedman y Voas (Software Assessment: Reliablity, Safety, Testability, Wiley, 1995) presentan buenas introducciones a las estrategias y tcticas
de prueba. Mosley (The Handbook of MIS Application Software Testing, Prentice-Hall, 1993) analiza temas de prueba para sistemas de informacin grandes, y Marks (Testing Very Big Systems.
McGraw-Hill, 1992) analiza los aspectos especiales que deben tomarse en cuenta cuando se
prueban sistemas de programacin importantes.
Sykes y McGregor (Practica! Guide Jor Testng Object-Oriented Software, Addison-wesley,
2001), Bashir y Goel (Testing Object-Oriented Software, Springer-Verlag. 2000), Binder (Test.ing
Object-Oriented systems, Addison-Wesley, 1999), Kung y sus colegas (Testing Object-Oriented
Software, IEEE Computer Society Press. I 998). Marick (The Craft of Soflvvare Testng, PrenticeHall, 1997) y Siegel y Muller (Objecl-Oriented Software Testing: A Hierarchical llpproach, wiley,
1996) presentan estrategias y mtodos para probar sistemas orientados a objetos.
La prueba del software es una actividad que ocupa muchos recursos. Por ello, muchas organizaciones automatizan partes del proceso de prueba. Libros de oustin, Rashka y Poston (Automated Sojlware Testing: Introducton, Management, and Performance, Addison-Wesley, 1999),
Graham y sus colegas (Softvvare Test Automation, Addison-Wesley, 1999), y Poston (Automatng
Specijicaton-Based Software Testing, IEEE Computer Society, 1996) analizan herramientas, estrategias y mtodos para pruebas automatizadas.
Varios libros consideran los mtodos y las estrategias de prueba en reas de aplicacin especializadas. Gardiner (Testing Safety-Related Software: A Practica/ Handbook, Springer-Verlag,
1999) ha editado un libro que aborda la prueba de sistemas de seguridad crtica. Mosley (dient/
Server Software Testing on the Desk Top and the Web, Prentice-Hall, 1999) analiza el proceso de
prueba para clientes. servidores y componentes de red. Rubin (Handbook of Usability Testing, Wiley, 1994) ha escrito una gua til para quienes deben ejercitar interfaces humanas.
Binder JBIN99) describe casi 70 patrones de prueba que cubren mtodos de prueba, clases/
grupos. subsistemas, componentes reutilizables, marcos conceptuales y sistemas, adems de
automatizacn de pruebas y prueba de base de datos especializada. Una lista de estos patrones se encontrar en www.rbsc.com/pages/TestPattemList.htm.
Una amplia variedad de fuentes de informacin sobre los mtodos de diseo de casos de
prueba est disponible en Internet. Una lista actualizada de referencias en la World Wide Web
que tienen relevancia para las tcnicas de prueba se encuentra en el sitio Web SEPA:
http:/ /www.mbhe.com/ pressman.
CAPTULO
15
C O NCEPTOS
CLAVE
ailldclCl 464
fO<lom
lleM<CoB . 464
lndkadorts .. .461
1aedcin . 4J 1
atrllitos . 471
jlt'in<lpios , .469
mis ......467
cf, cdigo .493
clemC1Dtetti.mifflto 496
de madelo
de-anarists . 474
ele modelo
de diseo
479
orientadas
a objetos .. 481
prueba ele ..494

paradigma
OPM ........470
MTRICAS DEL PRODUCTO

PARA EL SOFTWARE
a medicin es un elemento clave en cualquier proceso de ingeniera
medidas se emplean para comprender mejor los atributos de los m ~
que se crean y evaluar la calidad de los productos de la ingenieria o de
sistemas que se construyen. Pero a diferencia de otras disciplinas de la ing
ra, la del software no se basa en las leyes cuantitativas bsicas de la fisica
medidas directas, como el voltaje, la masa, la velocidad o la temperatura no
comunes en el mundo del software. Debido a que las medidas y mtricas
software suelen ser indirectas estn expuestas al debate. Fenton !FEN91 Ja
este tema cuando afirma:
La medicin es el pr()(:eso mediante el cual se asignan nmerbS o slmbolos a los
butos de entidades reales para definirlas de acuerdo con reglas claramente establcci
das .. , En las ciencias fisicas, la medicina y, ms recientemente, las ciencias soc ahora podemos medir atributos que se consideraban imposibles de medir . Por
puest, estas mediciones no tienen el mismo refinamiento que casi todas tas de
ciencias flSicas... pero existen (Y muchas decisiones importantes se toman con
en ellas] Sentimos que la obligacin de tratar de "medir lo inmedible" para me
nuestra comprensin de entidades particulares es tan importante en la ingeniena
software como en cualquier otra disciplina.
Pero algunos miembros de la comunidad de software siguen argumentan

el software "es nmedible", o que deben posponerse los intentos de medirlo
ta que se comprenda mejor el propio software y los atributos que deben
se para describirlo. Esto es un error.
pintos
de funcin 474
Qu es? Por -so nturolezo, lo n

geniera es uno disciplino cuontitoti
vo. Los ingenieros usan nmeros co
mo apoyo poro el diseo y la evaluacin del producto que construirn.
Hoslo h<,cepoco, los ngenieros de software con
tabon eon escosas guias cuonlitotivos en su tra
bao, pero eso est cambiando. los mtricas del
producto los ayudan o conocer mejor el diseo y
lo construccin del software que elaboran. A d
ferencia de los mtricm, del proceso y el pro)'9C'.'
to que se aplican al proyecto (o ol proceso) co
mo un todo, las mtricas del prododo se cono,tron en atn'bufos especficos de los productos
trabajo de la iogenierio del software y se
Ion o medido que se realizan los tore:;
(anlisis, diseo, (odficacin y pruebo).
Quin lo hace? los ingenierotdesoftware
los mtricas del producto como apoyo
construir sohwore de mayor calidod.
Por qu es ifflPC"'lante? Siempre in
drn elementos cualitativos en la creac or
software. El problerno es que no bosta
evoluoci6n cualitativo. Un ingeniero de so
CAPTULO 15
MTRICAS DEL PROOUC'IO PARA Et SOFTWARE
463
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 capitulo se analizarn las mediciones con que se evala la calidad del producto mientras se disea o construye. Estas medidas de atributos internos del producto proporcionan al ingeniero de software una indicacin en tiempo real de la eficacia 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 construirse.
Hasta los desarrolladores de software exhaustos estn de acuerdo en que es importante 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 desarrollado profesionalmente.
Es indudable que esta definicin podra modificarse o extenderse y debatirse interminablemente. En cuanto a los objetivos de este libro, la definicin sirve para destacar tres puntos importantes:
1. Los requisitos del software son la base de las medidas de calidad. La falta 12
concordancia con estos requisitos es una falta de calidad.'
2. Los estndares especificados definen un conjunto de criterios de desarrd~
que guian la ingeniera del software. Si no se siguen los criterios, el resu'
ser, casi seguramente, la falta de calidad.
3. A menudo se soslaya un conjunto de requisitos implicitos (por ejemplo, e
seo de alcanzar la facilidad de uso). Si el sonware cumple con sus requis.
explicitas pero no con los implcitos, la calidad del sonware estar en dt.La calidad del software es una compleja combinacin de factores que variarr
diferentes aplicaciones y los distintos clientes que las solicitan. En las siguiente-dones se identifican los factores que afectan la calidad del software y se d..................
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 grupa:
los que se miden directamente (por ejemplo, defectos descubiertos durante ia
ba), y 2) los que slo se miden indirectamente (por ejemplo, facilidad de usr
mantenimiento). En cada caso debe presentarse una medicin. Se debe com software (programa, datos, documentos) con algn conjunto de datos y obte- algn indicio sobre la calidad.
McCall, Richards y Walters fMCC77] propusieron una clasificacin til de '
tares que afectan la calidad del software. Estos factores, que se muestran en ~
ra 15.1, se concentran en tres aspectos importantes de un producto de softwarecaractersticas operativas, su capacidad para experimentar cambios y su ca'3:::C:..II
para adaptarse a nuevos entornos.
Si se toman como referencia los factores indicados en la figura 15. l, Meca
colegas proporcionan las siguientes descripciones:
Factores de
la calidad
del software
deMcCall.
Facilidad de mantenimiento
Flexibilidad
Facilidad de pruebo
Portabilidad
Facilidad de reutilizacin
lnteroperabilidad
REVISIN DEL PRODUCTO
TRANSICIN DEL PRODUCTO
Correccin
Facilidad de uso
Confiabilidad
Eficiencia
Integridad
Es importante indicar que la calidad se extiende a las caractersticas tcnicas de los modele:
lisis y diseo, as como a la realizacin del cdigo fuente de stos. Modelos de alta calia:
sentido tcnico) darn lugar a software de alta cahdad, desde el punto de vista del cliente
CAPTULO 15 MTRICAS DEL PRODUC10 PARA a SOFIWARE
465
Correccin. El grado en que el programa cumple con su especificacin y satisface los ob-
jetivos que propuso el cliente.

Con.fiabilidad. El grado en que se esperara que un programa desempee su funcin con la
precisin requerida. [Debe observarse que se han propuesto otras definiciones de confiabilidad ms completas (consltese el captulo 26)).
Eficiencia. La cantidad de cdigo y de recursos de cmputo necesarios para que un progra-
ma realice su funcin.
Integridad. El grado de control sobre el acceso al software o los datos por parte de las personas no autorizadas.
Facilidad de uso. El esfuerzo necesario para aprender, operar y preparar los datos de en-
trada de un programa e interpretar la salida.

Facilidad de mantenimiento. El esfuerzo necesario para localizar y corregir un error en un
programa. (Una definicin muy limitada.)

Flexibilidad. El esfuerzo necesario para modificar un programa en operacin.
Facilidad de prueba. El esfuerzo que demanda probar un programa con el fin de asegurar
que realiza su funcin.

Portabilidad. El esfuerzo necesario para transferir el programa de un entorno de hardwa-
re o software a otro.
Facilidad de reutilizacin. El grado en que un programa (o partes de l) puede reutilizarse
en otras aplicaciones (en relacin con el empaquetamiento y el alcance de las funciones

que realiza el programa).
Jnteroperabilidad. El esfuerzo necesario para acoplar un sistema con otro.
La calad de un l(oduclo es uno funcin del bien quehoceal mundo.
Es dificil, y en algunos casos imposible, desarrollar medidas directas2 de estos factores de la calidad. En realidad, muchas de las mtricas que definen McCall et al. slo se miden subjetivamente. Es comn que las mtricas adquieran la forma de una
lista de comprobacin que se emplea para "asignar una graduacin" a atributos especficos del software [CAV78].
15.1.2 Factores de calidad del estndar ISO 9126

El estndar ISO 9 126 se desarroll como un intento por identificar los atributos de
calidad para el software de computadora. El estndar identifica seis atributos clave
de la calidad:
Una medida directa indica que slo es posible contar un valor que proporciona una indicacin directa del atributo que se examina. Por ejemplo, el "tamao" de un programa se mide directamente
al contar el nmero de lneas de cdigo.
PARTE DOS
Funcionalidad. El grado en que el software satisface las necesidades que in
los siguientes subatributos: idoneidad, exactitud, interoperabilidad, cumplimier.

seguridad.
Confiabilidad. La cantidad de tiempo en que el software est disponible para
lo segn los siguientes subatributos: madurez, tolerancia a fallas y facilidad de rcperacin.
Facilidad de uso. La facilidad con que se usa el software de acuerdo con los
guientes subatributos: facilidad de comprensin, facilidad de aprendizaje y ope.
lidad.
Eficiencia. El grado en que el software emplea en forma ptima los recurs05
sistema, como lo indican los siguientes subatributos: comportamiento en el tie:comportamiento de los recursos.
Facilidad de mantenimiento. La facilidad con que se repara el software de aa.
con los siguientes subatributos: facilidad de anlisis, facilidad de cambio, estaby facilidad de prueba.
Portabilidad. La facilidad con que se lleva el software de un entorno a otro
los siguientes subatributos: adaptabilidad, facilidad para instalarse, cumplinu

facilidad para reemplazarse.
Al igual que otros factores de calidad del software analizados en el captulo ...
seccin 15.l.J , los factores ISO 9126 no necesariamente se prestan a la medie recta. Sin embargo, proporcionan una base valiosa para las medidas indirectas .
lista de verificacin excelente para evaluar la calidad de un sistema.
1, Cidquier adividacl se vuelve oealivo ruando lopersono quehace las cosas las hco bien, omeo,:
15.1.3 La transicin a un concepto cucmtitativo
En las secciones anteriores se analiz un conjunto de factores cualitativos pa.:z
"medicin" de la calidad del software. El esfuerzo por desarrollar medidas pre
de la calidad del software en ocasiones se frustra por la naturaleza subjetiva
actividad. cavano y Mccall [CAV78] analizan esta situacin:
La determinacin de la calidad es un factor clave en todas las actividades diarias (conc"'"'
sos de cata de vinos, competencias deportivas [como la gimnasia). concursos de taler

etc.). En estas situaciones la calidad se juzga de la manera ms bsica y directa: coro-..
rando objetos que se encuentran juntos en condiciones idnticas y con conceptos pro...
terminados. El vino se juzga de acuerdo con su claridad, color, bouquet, sabor. etc. S
embargo. este tipo de juicios es muy subjetivo; para que tenga algn valor debe hace
un experto.
La subjetividad y la especializacin tambin se aplican para determinar la calidad
software. Se necesita una definicin ms precisa de la calidad del software para resol. _
CAPTULO 15
MTRICAS DEL PRODUCTO PARA EL SOF1WARE
467
este problema, adems de un medio para derivar medidas cuantitativas, a partir de la calidad del software, para realizar un anlisis objetivo ...
En las secciones siguientes se examina un conjunto de mtricas que se aplican en

la evaluacin cuantitativa de la calidad del software. En todos los casos las mtricas
representan medidas indirectas; es decir, nunca se mide realmente la calidad, sino
alguna manifestacin de sta. El factor que complica las cosas es la relacin precisa
entre la variable que se mide y la calidad del software.
Jst:tom0 la~n !1t lo temperatura empiezo con un dedo ndice.'. ydo lugar oescalos, hemimientas ylbkas
~ ClS1 s tambin con lo modurez en la medicin del software.
Como se indic en la introduccin de este captulo, la medicin asigna nmeros o

smbolos a atributos de entidades reales. Esto requiere un modelo de medicin que
abarque un conjunto consistente de reglas. Aunque la teora de la medicin (por
ejemplo, [KYB84)) y su aplicacin al software de computadora (por ejemplo,
[DEM8 I J, [BRI961, [ZUS97)) son temas que rebasan el alcance de este libro, vale la
pena establecer un marco conceptual y un conjunto de principios bsicos para la medicin de mtricas para el producto de software.
15.2. l
Medidas, mtricas e indicadores
Aunque medida, medicin y mtrica son trminos que suelen utilizarse de manera intercambiable, es importante observar las sutiles diferencias entre ellos. En el contexto de la ingeniera del software una medida proporciona una indicacin cuantitativa
de la extensin, la cantidad, la dimensin, la capacidad o el tamao de algn atributo de un producto o proceso. Medicin es el acto de determinar una medida. El Glosario de estndares del IEEE [IEE93] define mtrica como una "medida cuantitativa del
grado en que un sistema, componente o proceso posee un atributo determinado".
Cuando se ha recopilado un solo tipo de datos (por ejemplo, el nmero de errores
descubiertos dentro de un solo componente del software) se ha establecido una medida. La medicin ocurre como resultado de la recopilacin de uno o ms puntos de
datos (por ejemplo, se investigan varias revisiones de componentes y pruebas de unidad para reunir medidas del nmero de errores encontrados en cada uno). Una mtrica de software relaciona de alguna manera las medidas individuales (por ejemplo, el
nmero promedio de errores encontrados en cada revisin o prueba de unidad).
un ingeniero de software recopila medidas y desarroUa mtricas para obtener los
indicadores. Un indicador es una mtrica o una combinacin de mtricas que proporcionan conocimientos acerca del proceso del software, un proyecto de software
o el propio producto. Un indicador proporciona conocimientos que permiten al jefe
468
PARTE DOS PRCl'TCA DE LA INGENIERfA DEL SOFTWARE
de proyecto o los ingenieros de software ajustar el proceso, el proyecto o el pr' ;:.

to para que las cosas mejoren.
"U. ena tiene la mismo madurez que sus herramientas de medi<icio.

Llis P 1
15.2.2 El reto de las mtricas del producto
En las ltimas tres dcadas, muchos investigadores han tratado de desarrolla:"
sola mtrica que proporcione una medida completa de la complejidad del so _
Fenton [FEN94] caracteriza esta investigacin como una bsqueda del "sant...
imposible". Aunque se han propuesto docenas de medidas de complejidad [L.__
cada una tiene un concepto diferente de la complejidad y de los atributos de u:ma que llevan a la complejidad. Por analoga, considrese una mtrica para eva.
automvil atractivo. Algunos observadores destacaran el diseo de la carrocen.a,,
tomaran en cuenta caractersticas mecnicas y otros ms podran considerar e.
el desempeo, la economa de combustible o la capacidad de reciclarlo cuanw
to sea inservible. como cualquiera de estas caractersticas estara en desventa otras, resulta dificil derivar un solo valor de "atractivo". El mismo problema
U#lfildf1
Htwst Zuse ho
recOj)ilado ~on
contidod~
informacin sobre
mfcos de l)fOOIJ<IO
en tlt.o...._..
l,t/..ase/.
con el software de computadora.

Pero existe la necesidad de medir y controlar la complejidad del software
dificil derivar un solo valor de esta mtrica de calidad, debe tenerse la posib~
desarrollar medidas de diferentes atributos internos del programa (por ejemr,
dularidad efectiva, independencia funcional y otros atributos analizados del ca.al 12). Estas medidas y las mtricas derivadas de ellas se utilizan como indicaddependientes de la calidad de los modelos de anlisis y diseo. Pero aqul tamb
gen problemas. Fenton [FEN94] observa esto cuando afirma: "El peligro de encontrar medidas que caractericen tantos atributos diferentes es que inevitr
te las medidas tienen que satisfacer objetivos que entran en conflicto entre s. opone a la teora de que cada medicin debe ser representativa." Aunque la
cin de Fenton es correcta, muchas personas argumentan que la medicin del
realizada durante las primeras etapas del proceso del software proporciona a
genieros un mecanismo consistente y objetivo para evaluar la calidad.
Sin embargo, vale la pena preguntarse sobre la validez de las mtricas dueto. Es decir, qu tanto concuerdan las mtricas del producto, la confiat
largo plazo y la calidad de un sistema de cmputo? Fenton [FEN91] aborda
quietud de la siguiente manera:
A pesar de las conexiones intuitivas entre la estructura interna de los productos~
ware [mtricas del producto) y los atributos de su producto y su proceso externos. e::
lidad se han realizado muy pocos intentos cientficos por establecer relacones es,c,,..-__.
Esto es asi por varias razones: la que se cita con ms frecuencia es que resulta poc=
tico realizar experimentos relevantes.
CAPTULO 15
MTRICAS DEL PRODUCTO PARA El SOFTWARE
469
Cada uno de los "retos" indicados aqu debe tomarse con cautela, pero no hay razn para restarle mritos a las mtricas tcnicas. 3 La medicin es esencial si se desea alcanzar la calidad.
15.2.3 Principios de medicin

Antes de introducir una serie de mtricas del producto que 1) ayuden a evaluar los modelos de anlisis y diseo, 2) ofrezcan una indicacin de la complejidad de los diseos procedimentales y el cdigo fuente, y 3) faciliten el diseo de pruebas ms efectivas, es importante comprender los principios bsicos de la medicin. Roche
[ROC94J sugiere un proceso de medicin al que caracterizan cinco actividades:
Formulacin. La derivacin de medidas y mtricas apropiadas para la representacin del software que se considera.
Recoleccin. El mecanismo con que se acumulan los datos necesarios para
derivar las mtricas formuladas.
Anlisis. El clculo de las mtricas y la aplicacin de herramientas matemticas.
Interpretacin. La evaluacin de las mtricas en un esfuerzo por conocer mejor la calidad de la representacin.
Retroalimentacin. Recomendaciones derivadas de la interpretacin de las mtricas del producto transmitidas al equipo del software.
Las mtricas del software slo sern tiles si estn caracterizadas de manera efectiva
y se validan para probar su valor. Los siguientes principios [LET03J son representativos de muchos otros que podran proponerse para caracterizar y validar las mtricas:
Una mllica debe tener propiedades matemticas deseables. Es decir, el valor de la

mtrica debe estar en un rango significativo (por ejemplo, de cero a uno, donde
cero realmente significa ausencia, uno indica el valor mximo y 0.5 representa
el "punto medio"). Adems, una mtrica que pretende estar en una escala racional no debe contar con componentes que slo se miden en una escala ordinal.
Cuando una mtrica representa una caracterstica de software que aumenta cuando
se presentan rasgos posivos 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 mtrica debe medir el factor de inters, independientemente de otros factores. Debe "crecer"
para aplicarse en sistemas grandes y funcionar en diversos lenguajes de programacin y dominios de sistemas.
es proporoa:JIIO(imiento, no
~probacin
"""'ico slido.
3
Aunque la crtica de mtricas especficas es comun en la bibliografia, muchas de esas criticas se concentran en aspectos esotricos y pierden de ,'lSta el pnncipal 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 del producto.
470
PARTE DOS PR.CT1CA DE LA INGENIERA DEL SOFIWARE
Aunque la fonnulacin, caracterizacin y validacin son criticas, la recopilac>r

anlisis son las actividades que dirigen el proceso de medicin. Roche [ROC9-,
giere las siguientes directrices para estas actividades: 1) siempre que sea posib e
ben automatizarse la recopilacin de datos y su anlisis; 2) deben aplicarse tc
estadsticas vlidas para establecer relaciones entre los atributos internos del
dueto y las caracteristicas de calidad externas (por ejemplo, si el grado de co
dad de la arquitectura se correlaciona con el nmero de defectos informad s
aplicarla en produccin), y 3) para cada mtrica deben establecerse directrici::s
comendaciones para la interpretacin
15.2.4 Medicin del software orientado a objetivos
J-/f:ifr 6?1
Basili y Weiss [BAS84] desarrollaron el paradigma objetivo/pregunta/mtrica

como una tcnica para identificar mtricas significativas aplicables en cualqi
te del proceso del software. El OPM destaca la necesidad de 1) establecer U"l
vo de medicin explcito que sea especifico para la actividad del proceso o la..
tersticas del producto que se est evaluando, 2) definir un conjunto de pri~ur.::::::i
deben responderse con el fin de alcanzar el objeto, y 3) identificar mtricas
muladas que ayuden a responder esas preguntas.
Es posible emplear una plantilla de definicin de objetivos [BAS94] para d..
da objetivo de medicin. La plantilla toma esta forma:
Analizar [el nombre de la actividad o el atnbuto que se medir) con el propsito
objetivo general del anlisis~) en relad6n con [el aspecto de la actividad o atnbi
se en considera) desde el punto de vista de [la gente que tiene inters en la me....._ ,
en el contexto de [el entorno en que llene lugar la medicin)
Como ejemplo, considrese una plantilla de definicin del objetivo para

Seguro:
Analizar la arqwtectura del software HogarSeguro con el propsito de evaluarlos
ponenles arquitectnicos en relacin con la capacidad para lograr que Hoga',..;;,.......--ms extensible desde el punto de vista de los ingenieros de software que r
trabajo en el contexto de la mejora del producto en los siguientes tres aos.
una vez definido explicitamente el objetivo de la medicin, se desarrola

junto de preguntas. Las respuestas a stas ayudan al equipo de softwa.-.:
otros participantes) a determinar si se ha alcanzado el objetivo de med
las preguntas que se responden estn las siguientes:
P,:
Los componentes arquitectnicos estn caracterizados de m ~

aparecen por separado la funcin y los datos relacionados?
Van SOlingen y Berghout [SOL99) sugieren que el objetivo es casi siempre "comprencL.
mejorar" la actividad del proceso o el atributo del producto.
CAPTULO 15
MtrRJCAS DEL PRODUCTO PARA U SOFTWARE
471
La complejidad de cada componente se encuentra dentro de los lmites que

facilitarn su modificacin y extensin?
P2 :
cada una de estas preguntas debe responderse de manera cuantitativa, empleando una o ms medidas y mtricas. Por ejemplo, una mtrica que proporciona una indicacin de la cohesin (captulo 9) de un componente arquitectnico sera til para
responder P1 La complejidad ciclomtica y las mtricas analizadas en la seccin
15.4.l o 15.4.2 proporcionaran conocimientos a fondo para P2
En realidad, tal vez haya diversos objetivos de medicin con preguntas y mtricas
relacionadas. En cualquier caso, las mtricas elegidas (o derivadas) deben cumplir
con los principios de medicin analizados en la seccin 15.2.3 y los atributos de medicin analizados en la seccin 15.2.5. Si se desea obtener mayor informacin sobre
OPM, el lector interesado debe consultar [SHE98J o [SOL99].
15.2.5
Los atributos de las mtricas efectivas del software
Se han propuesto cientos de mtricas para el software de computadora, pero no todas proporcionan soporte prctico para el ingeniero de software. Algunas exigen
mediciones demasiado complejas; otras son tan esotricas que pocos profesionales
podran comprenderlas, y otras ms violan las nociones intuitivas bsicas de lo que
es el software de alta calidad.
Ejiogu [EJI91] define un conjunto de atributos que toda mtrica efectiva del software debe abarcar. La mtrica derivada y las medidas que llevan a ella deben ser:
Simples y calculables. Debe ser relativamente fcil aprender a derivar la mtrica,

y su clculo no debe exigir cantidades anormales de tiempo o esfuerzo.
Emprica e intuitivamente persuasivas. La mtrica debe satisfacer las nociones

intuitivas del ingeniero acerca del atributo del producto que se est construyendo.
Consistentes y objetivas. La mtrica siempre debe arrojar resultados que no

permitan ambigedad alguna.
Consistentes en el uso de unidades y dimensiones. El clculo matemtico de la

mtrica debe emplear medidas que no lleven a combinaciones extraas de
unidades.
Independientes del lenguaje de programacin. Las mtricas deben basarse en el

experiencia indico
slo se usar uno
:"'ffi(ij del producto si
~ inluitiva y fcil
2tlior.Sideben
KetSe da<enos de
\;Jliflf11s, es improbo i,e lo mtrico se
apte ampliamente.
modelo de anlsis o diseo, o en la estructura del propio programa.
Mecanismos efectivos para la retroalmentacin de alta calidad. Es decir, la mtrica debe llevar a un producto final de la ms alta calidad.
Aunque casi todas las mtricas de software satisfacen estos atributos, algunas mtricas de uso comn no cumplen con una o dos de ellas. Un ejemplo es el punto de
funcin (el cual se estudia en la seccin 15.3.1), que es una medida de la entrega de
"funcionalidad" por parte del software. Se puede argumentar5 que el atributo consis-
472
PARTE DOS
tente y objetiva falla porque tal vez un tercero, que sea independiente, no logre derr
el mismo valor del punto de funcin que un colega que utilice la misma informac
acerca del software. Debemos rechazar entonces la medida de punto de funcin~ respuesta es por supuesto que no! El punto de funcin proporciona conocimie;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 taxonomas mtricas, el sigu.esquema atiende las reas ms importantes de las mtricas:
Mtricas para el modelo de anlisis. Estas mtricas atienden varios aspectos

modelo de anlisis e incluyen:
FUncionalidad entregada: proporciona una medida indirecta de la fundo
que se empaqueta con el software.

Tamao del sistema: mide el tamao general del sistema, definido desde el ~
de vista de la informacin disponible como parte del modelo de anlisis.
Calidad de la especificacin: proporciona una indicacin de la especificidao
grado en que se ha completado la especificacin de los requisitos.
Mtricas para el modelo de diseo. Estas mtricas cuantifican los atribu.

diseo de manera tal que le permiten aJ ingeniero de software evaluar la caltaa:.
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 ~
software y otras caractersticas que impactan la calidad.

Mtricas de diseo de la interfaz: se concentran principalmente en la facilidad ir
Mtricas especializadas en diseo orientado a objetos: miden caractersticas
ses, adems de las correspondientes a comunicacin y colaboracin.
Mtricas para el cdigo fuente. Estas mtricas miden el cdigo fuente )

para evaluar su complejidad, adems de la facilidad con que se mantiene y
entre otras caractersticas:
Mtricas de Halstead: controversiales pero fascinantes, estas mtricas pr
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 tamao del software.
5 Podra usarse un contraargumento igualmente vigoroso.
software.
sa
es la naturaleza de las
CAPTULO 15
473
MTRICAS DEL PRODUCTO PARA EL SOFIWARE
Mtricas para pruebas. 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 concentran en encontrar 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 determinan a

medida que se aplican las pruebas.
En muchos casos las mtricas de un modelo pueden aplicarse en actividades posteriores de la ingeniera del software. Por ejemplo, las mtricas de diseo se utilizan para 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.
Vinod; N~, espero.~. aY_si.n$ofiom,n ~

JQmieJ 8C:mo,
,
Vinod; fvil~ retrQijajr.. Si ono mlrica,io.~

o eviwr v n ~ ittlp(ii'tuflteo inclUtOtm0
modero&,, r 0$0 oos (Wito retrabojor unopmte dlil
sis\en,o, ahorn:irei'hOs
tie,,po, ;o ~
,,
Ecf: E$ posible, W,otl90, ~ 2nos ~tzoa ~

alguno ~ko del pr!udo n o s ~ a ~ t l n .
problema?
Vinod: aY 1v me goral'!lit4$.~ nol'hort

Jomie: Bueno, 2qu ~ proponiendo,
Vinod: Creo quadecitrn< ~ u o o , ~
mtricos de disei\o, rol vu orienta~ o
y
dote,
oplicorlos como porte de rniestro ~ de terim&l

poro todos los c o ~ s q u e ~ ' . .
Ed: No estoy muy omilioritQ CQn faunlri*
orientados o objetos.
Vinod: VO'/ o dedicar un poco de tiempo a 1'8YSQfla$ 'f
o hocer algunos recomendaciones... 8e$16n d e ~
(Ed y Jomie asienten $n mucho enlusiasmo.J
PARTE DOS PRCTICA DE LA !NGENJERiA DEL SOF"IWARE
474
Aunque existen en la bibliografia relativamente pocas mtricas de anlisis y espeo

ficacin, es posible adaptar mtricas que se utilizan en la estimacin de proyectaaplicarlas en este contexto. Estas mtricas examinan el modelo de anlisis con la
tencin de predecir el "tamao" del sistema resultante. El tamao es, en ocasicr
(pero no siempre), un indicador de la complejidad del diseo y casi siempre res;..
un indicador de un mayor esfuerzo de codificacin, integracin y prueba.
15.3.1
....
Enlo$~-
w.ii.~
~
r1!111JCffllldelos
-fudn:
........
. ,....
.............
Mtricas basadas en la funcin
La mtrica de punto de funcin (PF), propuesta inicialmente por Albretch [ALB7

usa de manera efectiva como medio para medir la funcionalidad que entrega U!"
tema. 6 Empleando datos histricos. el PF se usa para 1) estimar el costo o el
zo requerido para disear, codificar y probar .el software; 2) predecir el nme:::r
errores que se encontrarn durante la prueba, y 3) pronosticar el nmero de c
nentes, de lneas de cdigo proyectadas, o ambas. en el sistema implementad.:
Los puntos de funcin se derivan empleando una relacin emprica basa.-:..:
medidas contables (directas) del dominio de la informacin del software y las
luaciones de la complejidad de ste. Los valores del dominio de la inforrnacir se
es
finen de la siguiente manera: 7

Nmero de entradas externas (EE). cada entrada externa se origina
usuario o es transmitida desde otra aplicacin y proporciona distintos datos e.dos a la aplicacin o informacin de control. Las entradas suelen emplearse ~
tualizar archivos lgicos internos (ALl). Las entradas deben distinguirse de .as
sultas, que se cuentan por separado.
Nmero de salidas externas (SE). Cada salida externa se deriva en el
de la aplicacin y proporciona informacin al usuario. En este contexto,
terna alude a informes, pantallas, mensajes de error, etc. Los elementos de

dividuales dentro de un informe no se cuentan por separado.
Nmero de consultas externas (CE). Una consulta externa se define entrada en lnea que lleva a la generacin de alguna respuesta inmediata r,x
del software, en la forma de salida en linea (a menudo recuperada de un A...t

Nmero de archivos lgicos internos (AU). cada archivo lgico interc
agrupamiento lgico de datos que reside dentro de los lmites de las aplica
que se mantiene mediante entradas externas.
Desde que Albrecht dio a conocer su trabajo original, se han escrito cientos de libros ertculos sobre PF. En [IEP03] se encontrar una bibliografia muy valiosa.
En realidad, la definicin de los valores del dominio de la informacin y la manera en q:z
tan son un poco ms complejas. El lector interesado deber consultar [IFPOI] para co
talles.
CAPTULO 15 MmICAS DEL PRODUCTO PARA El SOFTWARE
Valor del dominio

de informacin
475
Factor de ponderacin
Simple Promedio Complejo
Conteo
i::J
CJ
Consultas externas (CE)
i::::J
Archivos de lgica interna (ALI)
CJ
10
15
Archivos de interfaz externa (AIE)
[::::J
10
Entradas externas (EE)

Salidas externos (SE)
. C3
[:JE)
.u
-. [!:J
CJ
IZil
Total de conteos
Nmero de archivos de interfaz externos (AIE). Cada archivo de interfaz externo es un agrupamiento lgico de datos externo a la aplicacin pero que proporciona datos que podran usarse en sta.
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
mtodos de punto 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 puntos de funcin (PF) se usa la siguiente relacin:
PF
= conteo total x
[0.65 + o.o I x (F;))
(15.1)
donde conteo total es la suma de todas las entradas de PF obtenidas de la figura 15.2.
F; (i = l a 14) sonfactores de ajuste de valor basados en las respuestas a las siguientes preguntas [LON02]:
l. El sistema requiere respaldo y recuperacin confiables?

2 . Se requieren comunicaciones de datos especializadas para transferir informacin 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 entorno existente que tiene un uso pesado de
operaciones?
6. El sistema requiere entrada de datos en lnea?
7. La entrada de datos en lnea requiere que la transaccin de entrada se construya en varias pantallas u operaciones?
8 . Los ALI se actualizan en linea?
9. Las entradas, las salidas, los archivos o las consultas son complejos?
10. Es complejo el procesamiento interno?
11. El cdigo diseado ser reutilizable?
476
PARTE DOS
12. Se incluyen la conversin e instalacin en el diseo?

13. Est diseado el sistema para instalaciones mltiples en diferentes orga.ru:::
ciones?
14. La aplicacin est diseada para facilitar el cambio y para que el usuario lo
use fcilmente?
cada una de estas preguntas se responde empleando una escala que va de o (no portante o aplicabl e) a 5 (absolutamente esencial). Los valores constantes 1k
ecuacin (15.1) y los factores de peso que se aplican a los conteos del dominio de~
formacin se determinan empricamente.
Para ilustrar el empleo de la mtrica del PF en este contexto se ide la represe:-
Uno~dPf
.,.$8~
.,....,
$11 ......
"
f ........
fl/pa/fp/.
cin simple del modelo de anlisis, que se muestra en la figura 15.3. Ah se repre:9
ta un diagrama de flujo de datos (captulo 8) dentro del software HogarSeguro. La cin maneja la interaccin con el usuario aceptando una contrasea de ste para
tivar o desactivar el sistema, y permite consultas sobre el estado de las zonas de
guridad y varios sensores de seguridad. La funcin despliega una serie de mensa ...
enva seales de control apropiadas a varios componentes del sistema de segur.:
Se evala el diagrama de flujo de datos para determinar un conjunto de med..:'.ii::
clave del dominio de in formaci n que se requieren para calcular la mtrica del ~
to de funcin. En la figura se muestran tres entradas externas (contrasea,
de pnico y activar/ desactivar) junto con dos consultas externas (consulta
zona y consulta de sensor). Se muestra un ALI (archivo de configuracin
sistema). Tambin estn presentes dos salidas de usuarios (mensajes y es
del sensor) y cuatro AJE (sensor de prueba, configuracin de zona, activar
desactivar y alerta de alarma) . En la figura 15.4 se muestran estos datos, ._
con la complejidad apropiada.
El conteo total que se muestra en la figura 15.4 debe ajustarse empleando la ec
cin (15.1):
PF = conteo total x (0.65
+ 0.01 x 1: (F,)]
ii+i/lFI
Modelo de fiuJo
de datos para
el softwme
HogarSeguro.
U$vorio
Contrasea, sensores ...
SubslsteniO
monitoreo
y respuesto
Datos de c-0nfigurocin del sistemo l
CAPTULO 15
477
MTRICAS DEL PRODUCl'O PARA EL SOFTWARE
Valor del dominio

de informacin
factor de ponderacin
Simple Promedio Complejo
Conteo
Entrados externos (EE)
OJ
OJ
OJ
OJ
Solidos externos (SE)
WJ
Ol
CD
CD
10
15
10
Consultas externos (CE)

Archivos de lgico interno (ALI)
Archivos de interfaz externo (AIE)
()
Total de conteos
- CI}
!E
O!}
donde conteo total es la suma de todas las entradas de PF obtenidas de la figura 15.4,
y F; (i = 1a 14) son factores de ajuste de valor. Para los objetivos de este ejemplo, supngase que I (F) es 46 (un producto moderadamente complejo) . Por tanto:
PF = 50
[0.65 + (O.O 1 X 46)] = 56
Con base en el valor proyectado del PF derivado del modelo de anlisis, el equipo del proyecto puede estimar el tamao implementado general de la funcin de interaccin del usuario de HogarSeguro. Supngase que los datos del pasado indican
que un PF se traduce a 60 lneas de cdigo (se va a usar un lenguaje orientado a objetos) y que se producen 12 PF por cada persona-mes de esfuerzo. Estos datos histricos proporcionan al jefe del proyecto informacin importante que sirve para la
planeacin y que se basa en el modelo de anlisis ms que en estimados preliminares. Supngase, adems, que los proyectos anteriores han encontrado un promedio
de tres errores por punto de funcin durante las revisiones del anlisis y el diseo, y de
cuatro errores por punto de funcin durante las pruebas de unidad e integracin. Estos datos ayudarn a los ingenieros de software a evaluar el grado en el que han
completado sus actividades de revisin y prueba.
Uemura y sus colegas [UEM99) sugieren que los puntos de funcin tambin pueden calcularse a partir de diagramas UML de clase y secuencia (captulos 8 y I O) . El
lector interesado debe consultar [UEM99] para conocer ms detalles.
"& lugar dt slo musitar acerco de cul 'nuevo mtrico' podra aplicarse... debemos plonteqmos la PJegunkl bsim:
'qu hare.mos col! las mtricos?'
Mldta.l Mah y Lcmy htllilffl( "
15.3.2 Mtricas para la calidad de la especificacin

Davis y sus colegas [DAV93] proponen una lista de caractersticas con las cuales
puede evaluarse la calidad del modelo de anlisis y la correspondiente especificacin
478
PARTE DOS PRAcnCA DE LA INGENlERA DEL SOFIWARE

de requisitos: especificidad (falta de ambigedad), grado de avance, correccin, faa
dad de comprensin. facilidad de verificacin, consistencia interna y externa, facili<r

para alcanzar los objetivos, concisin, f acilidad para darle seguimiento, facilidad pe.;
modificarse, precisin y facilidad de reutilizacin. Adems, los autores [DAV931 obse.
van que las especificaciones de alta calidad deben estar almacenadas electrnic:;
mente, ser ejecutables o por lo menos interpretables, estar anotadas por importanc..:
relativa, ser estables, tener indicada la versin, estar organizadas, incluir referena.;;..
01
"~
c&v1
Al medir los
coroctersticos de lo
especificacin es
posible obtener un
conocimiento
cuantitativo de lo
especificidad y el grodo
de ovonce.
cruzadas y especificarse con el grado de detalle correcto.

Aunque, al parecer, muchas de estas caractersticas tienen una naturaleza cu.w-tativa, Davis et al. [DAV93] sugieren que cada una puede representarse emplea!'"una o ms mtricas. Por ejemplo, supngase que hay nr requisitos en una espec
cacin, de modo que
n, = n + nn
donde n es el nmero de requisitos funcionales y nnr el de no funcionales (como
desempeo).
Para determinar la especificidad (falta de ambigedad) de los requisitos, na.-.,
al. sugieren una mtrica basada en la consistencia de la interpretacin de los reres de cada requisito:
01=nu/n,
donde nwes el nmero de requisitos que todos los revisores interpretaron de la
ma manera. cuanto ms cercano est el valor de O a 1, menor ser la ambi de la especificacin.
El grado de avance de los requisitos funcionales se determina al calcular la
cin
0 2 = n/[n, x ns]
donde nu es el nmero de requisitos de funcin nica; n1, el nmero de entradas (
los) definidos o implcitos en la especificacin, y n5, el nmero de estados es
La relacin 0 2 mide el porcentaje de funciones necesarias que se han especifica:!:-
ra un sistema. Sin embargo, no se atienden requisitos que no son funcionales.

corporarlos a una mtrica general del grado de avance, se debe considerar el gra
validacin de los requisitos:
donde ne es el nmero de requisitos que se han validado como correctos, y rrequisitos que an no se validan.
"Mido lo que sea mensurable, ylo que no lo seo, vulvalo mensurable.
CAPTULO 15 MTRICAS DEL PRODUCTO PARA EL SOf"TWARE
479
Sera inconcebible que el diseo de un nuevo avin, un nuevo chip de computadora

o un nuevo edificio de oficinas se realizara sin definir las medidas del diseo, sin determinar las mtricas de diversos aspectos de la calidad del diseo y sin usarlas para guiar la manera en que evoluciona el diseo. Sin embargo, a menudo el diseo de
sistemas de software complejos suele avanzar casi sin medicin. La irona es que se
dispone de mtricas de diseo para el software, pero la gran mayora de los desarrolladores siguen ignorando su existencia.
Las mtricas de diseo para el software de computadora, como todas las dems
mtricas del software. no son perfectas. Sigue abierto el debate sobre su eficacia y
la manera en que deben aplicarse. Muchos expertos argumentan que se necesita
ms experimentacin antes de emplear las mediciones en el diseo. Sin embargo,
un diseo sin medicin es inaceptable.
15.4.1 Mtricas del diseo arquitectnico

Las mtricas de diseo arquitectnico se concentran en las caractersticas de la arquitectura del programa (captulo l O). y se destacan la estructura arquitectnica y la
efectividad de mdulos o componentes dentro de la arquitectura. Estas mtricas son
de "caja negra", en el sentido de que no requieren ningn conocimiento del funcionamiento interno de un componente de software en particular.
Card y Glass (CAR90] definen tres medidas de la complejidad del diseo del software: estructural, de datos y del sistema.
En el caso de las arquitecturas jerrquicas (por ejemplo, las arquitecturas de llamada y retorno). la complejidad estructural de un mdulo i se define de la siguiente
manera:
S(i)
=f 2out()
(l 5.2)
dondefou1(i) es la dependencia hacia fuera8 del mdulo i.

La complejidad de datos proporciona una indicacin de la complejidad de la interfaze interna de un mdulo i y se define como:
D(i)
= V(i)/fou1() + IJ
(15.3)
donde v(i) es el nmero de variables de entrada y salida que se pasan al mdulo i o

se reciben de ste.
Por ltimo, complejidad del sistema se define como la suma de las complejidades
estructural y de datos. especificada como:
C(i)
8
= S(i) + D(i)
Dependencia
hacia Juera
(15.4)
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. sera una variable ftn que indique el nmero de mdulos que invocan directamente al
mduloi.
480
PARTE DOS
PRCTICA DE LA INGENlERlA DEL SOFTWARE
A medida que aumentan estos valores, la complejidad arquitectnica general del

tema tambin lo hace Esto lleva a una mayor probabilidad de que aumenten los
fuerzas de integracin y prueba
Fenton (FEN9 I) sugiere varias mtricas simples de morfologa (es decir, de fo-t:"Z
que penniten la comparacin entre diferentes arquitecturas de programas emplee:::
do un conjunto de dimensiones directas. Si se toma como referencia la arquit
de llamada y retorno de la figura 15.5, se definirn las siguientes mtricas:
tamao =n + a
donde n es el nmero de nodos y a, el de arcos. En el caso de la arquitectura rn05-trada en la figura 15.5,
tamao = 17 +- 18 = 35
profundidad = 4, el camino ms largo desde el nodo raz (superior) a un n
hoja.
anchura = 6, nmero mximo 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 d:!::
acoplamiento de la arquitectura. En el caso de la arquitectura mostrada en la f i ~
15.5, r = 18/17 = l 06.
El comando de Sistemas de la Fuerza Area de Estados Unidos [USA87] ha des
rrollado varios indicadores de la calidad del software que se basan en las caracter-ticas de diseo que pueden medirse en un programa de computadora. Emplean:
conceptos similares a los propuestos en el IEEE Std. 982.1-1988 [IEE94). la Fueru
Area estadounidense emplea informacin obtenida del diseo de datos y arquitectnico para derivar un ndice de calidad de la estructura de diseo (ICED) que va ..e
O a 1. El clculo del ICED requiere determinar los siguientes valores [CHA89].
S1
= el nmero total de mdulos definidos en la arquitectura del programa
iiM/IFIJ
Mtricas de
morfologa.
Profundidad
481
CAPTULO 15 MTRICAS DEL PRODUCTO PARA EL SOF'IWARE
5 2 = el nmero de mdulos cuya funcin correcta depende de la fuente de entrada de datos o que produce datos que se usarn en otro lugar (en general, los mdulos de control. entre otros. no se contaran como parte de 5 2)
5 3 = el nmero de mdulos cuya funcin correcta depende del procesamiento
anterior
S4 = el nmero de elementos de base de datos (incluye objetos de datos y todos los atributos que definen objetos)
= el nmero total de elementos nicos de base de datos

5 6 = el nmero de segmentos de base de datos {registros diferentes u
S5
objetos
individuales)
57
= el nmero de mdulos con una sola entrada y salida (con excepcin del
procesamiento, no se considera una salida mltiple)
Una vez que se han determinado los valores del S 1 al S 7 para un programa de computadora, es posible calcular los siguientes valores intermedios:
Estructura del programa:
o,. donde 0 1 se define como sigue: si el diseo arquitec-
tnico se desarroll empleando un mtodo distinto (por ejemplo, diseo orientado al

flujo de datos u objetos), entonces 0 1
= 1; de lo contrario, D 1 =
O.
Independencia del mdulo: D 2 = 1 - (S2/51)

Mdulos no dependientes del procesamiento anterior: D3
=t-
(53 /S,)
Tamao de la base de datos: D 4 = 1 - (S1/54)

Divisin en compartimientos de la base de datos: D5 = l - (56/S4)
Caracterstica de entrada/salida del mdulo: D6
=l-
(57/51)
Una vez determinados los valores intermedios, se calcula el ICED de la siguiente manera:
ICED = !. wD
(15.5)
= 1 a 6, w; es el peso relativo de la importancia de cada uno de los valores

intermedios, y W; = 1 (si todo D tiene pesos iguales, entonces w; = 0.167) .
donde i
Se determina el valor de ICED para los diseos anteriores y se compara con un diseo que est en desarrollo. Si el ICED es significativamente menor que el promedio,
lo indicado es realizar trabajo de diseo y revisin adicionales. De igual manera, si se
van a realizar cambios importantes en un diseo existente, podr calcularse el efecto de esos cambios sobre el ICED.
.i!fs,.W.CXIISicMl'Clrque lo medicin es un desvo. Un desvo necesario, porque lo mayora de lsntlumOllOUO
cr,pllCl5 totMr 4*isiones cloros y objetivas (sin apoyo aiantifativo).
15.4.2 Mtricas para el diseo orientado a objetos

Gran parte del diseo orientado a objetos es subjetivo {un di seador experimentado
"sabe" cmo caracterizar un sistema orientado a objetos para que implemente efec-
482
PARTE DOS PRCllCA DE LA INGENIERA OO. SOFTWARE
tivamente los requisitos del cliente). Pero, a medida que aumenta el tamao .
complejidad del modelo de diseo orientado a objetos, un concepto ms objetive z
las caractersticas del diseo beneficiaria al diseador experimentado (que obtend:2
conocimientos adicionales) y al principiante (que obtendra una indicacin de la :.e
lidad que de otra manera no estara disponible) .
En un tratamiento detallado de las mtricas del software para sistemas orie:-_
dos a objetos, Whitmire (WH197] describe nueve caractersticas distintivas y mer.s>
rabies de un diseo orientado a objetos:
Cules
caraderisti
cas pueden medir
se cuando se eva
'la un diseo
orientado a obje
tos?
Tomao. El tamao se define a partir de cuatro conceptos: poblacin, volu~

longitud y funcionalidad. Pobladn se mide al tomar un conteo esttico de entida:.
orientada a objetos como clases u operaciones. Las medidas de volumen son idecas a las de la poblacin, pero se recopilan dinmicamente (en un momento da::
minado) . La longitud es una medida de una cadena de elementos de diseo intermnectados (por ejemplo, la profundidad de un rbol de herencia es una medida de 1:gitud). Las mtricas de.funcionalidad proporcionan una indicacin indirecta del \a.z
entregado al cliente en una aplicacin orientada a objetos.
Complejidad. Como el tamao, hay muchos conceptos diferentes de la comp

jidad del software [ZUS97] . Whitmire considera la complejidad desde el punto de-_:...
ta de las caractersticas estructurales, al examinar la manera en que se interrelac.=;
nan las clases de un diseo orientado a objetos.
Acoplamiento. Las conexiones fisicas entre los elementos de un diseo orier _

do a objetos (por ejemplo, el nmero de colaboraciones entre clases o el de mens:.ijes pasados entre objetos) representan el acoplamiento dentro de un sistema orie
tacto a objetos.
Suficiencia. Whitmire define suficiencia como "el grado en que una abstracc:
posee las caractersticas que se le piden, o el grado en que un componente de dis::
o posee caractersticas en su abstraccin, desde el punto de vista de la aplicaciw
actual". Expresado de otra manera, se pregunta: Cules propiedades debe tener e:,
ta abstraccin (clase) para que sea til? [WHI97]. En esencia, un componente de c.
seo (por ejemplo, una clase) es suficiente si refleja plenamente todas las propiec.:
des del objeto de dominio de la aplicacin que se est modelando (es decir, que
abstraccin, o clase, posee las caractersticas que debe tener).
__ ,.......
'1llldios las decisiones para las que tena que depender del foklore olos 111~ puedo lolllarlas ahn
Grado de avance. La nica diferencia entre el grado de avance y la suficienc:.

es "el conjunto de caractersticas contra las que comparamos el componente de ab5traccin o diseo" [WHI97] . La suficiencia compara la abstraccin desde el punto c...
vista de la aplicacin actual. El grado de avance considera varios puntos de vista
CAPTULO 15
MTRICAS DEL PRODUCO PARA EI. SOFiWARE
483
planteando la pregunta: Cules propiedades se requieren para representar plenamente el objeto del dominio del problema? Debido a que los criterios para el grado
de avance consideran diferentes puntos de vista, indican indirectamente el grado en
que puede reutilizarse el componente de abstraccin o diseo.
Cohesin. Como su contraparte en el software convencional, un componente

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 conjunto de propiedades que
posee es parte del dominio del problema o el diseo" [WHI97J.
Primitivismo. Una caracterstica similar a la simplicidad, el grado de primitivismo (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 operaciones contenidas dentro de una clase). Una clase que muestra un alto grado de
primitivismo slo encapsula operaciones primitivas.
Similitud. Esta medida indica el grado en que dos o ms clases son similares en
cuanto a su estructura, funcin, comportamiento o propsito.
Volatilidad. Como ya se ha visto en este libro, los cambios de diseo ocurren
cuando los requisitos se modifican o cuando las modificaciones se presentan en otra
parte de una aplicacin, lo que produce una adaptacin obligatoria del componente
del diseo en cuestin. La volatilidad de un componente de diseo orientado a objetos mide la probabilidad de que ocurra un cambio.
En realidad, las mtricas del producto para sistemas orientados a objetos no slo
se aplican al modelo de diseo, sino tambin al de anlisis. En las secciones que siguen se explorarn las mtricas que proporcionan una indicacin de la calidad al nivel 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 fundamental de un sistema orientado a objetos. Por tanto, las
medidas y mtricas de una clase individual, la jerarqula de clase y las colaboraciones de clase sern invaluables para un ingeniero de software que debe valorar la calidad del diseo. En captulos anteriores se vio que la clase encapsula operaciones
(procesamiento) y atributos (datos). La clase suele ser el "predecesor" de las subclases (a veces denominadas 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 [CHI94J propusieron uno de los conjuntos de mtricas de
sojtware orientado a objetos al que se hace referencia con mayor frecuencia. A me-
Debe observarse que an se debate en la bibliografia tcnica la validez de algunas de las mtricas
analizadas en este capitulo. Quienes defienden la teora de la medicin, exigen un grado de formalismo que algunas mtricas orientadas a objetos no proporcionan. Sin embargo. es razonable determinar que las mtricas indicadas proporcionan conoamientos tiles para el ingeniero de software.
484
PARTE DOS PRCTICA DE LA INGENIERA DD. SOFTWARE
nudo denominadas coleccin de mtricas de CK, los autores proponen seis mtrias
de diseo basado en clases para sistemas orientados a objetos. 10
El nmero de mtodos
y su complejidod esln
directo mente
conelocionodos con el
esfuerzo requerido
poro probar uno clase.
Lo herencia es ooo
corocterstico
extremadamente
poderoso que puede
cousor problemas si se
empleo sin cuidado.
sese el APH y otras
mtricos poro obtener
uno leduro de lo
compleidod de los
;erorquos de clase.
Mtodos ponderados por clase (MPC) . Suponga que n mtodos de complejida.:

c 1, C2, .. .,cn estn definidos por la clase c. La mtrica de complejidad especfica q- ~
se elija (por ejemplo, la complejidad dclomtica) debe normalizarse con el fin de que complejidad nominal de un mtodo tome un valor de 1.0.
MPC =
l;c,
para i = l a n. El nmero de mtodos y su complejidad son indicadores razonab...eE

de la cantidad de esfuerzo requerido para implementar y probar una clase. Aderr.
cuanto mayor sea el nmero de mtodos, ms complejo ser el rbol de heren...a
(todas las subclases heredan los mtodos de sus predecesores) . Por ltimo, confm..
me crece el nmero de mtodos de una clase determinada, es probable que se v-..&va ms y ms especfica de la aplicacin, lo que limita sus posibilidades de reutiliz...
cin. Por todas las razones mencionadas, MPC debe mantenerse lo ms bajo que ~
posble.
Aunque parezca relativamente simple desarrollar un conteo del nmero de m
dos en la clase, en realidad el problema es ms complejo de lo que parece. Debe:...
sarrollarse un enfoque de conteo consistente para los mtodos [CHU95].
rbol de profundidad de la herencia (APH). Esta mtrica es "la longitud rrull:l

ma desde el nodo hasta la raz del rbol" [CHI94]. Si toma como referencia la fign
15.6, el valor de APH para la jerarqua de clase mostrada es 4. A medida que ~..:.!'.
la APH, es probable que las clases de nivel inferior heredarn muchos mtodos
=-
Uhlifj.j
Jerarqua
deuna
clase.
e,
1o Chidamber y Kemerer usan el trmin o mtodos en lugar de operadones. La forma en que emplea: t:..
trmino se refleja en esta seccin.
CAPTULO 15 MTRICAS DEL PRODUCTO PARA EL SOFTWARE
485
to se presta a posibles dificultades cuando se trata de predecir el comportamiento 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.
Nmero de descendientes (NDD). Un descendiente es una subclase que se encuentra inmediatamente subordinada a otra en la jerarqua de clases. Si se toma como referencia la figura 15.6, la clase
c2 tiene tres descendientes {las subclases C21 ,
C22 y C23). A medida que crece el nmero de descendientes, se incrementa la reutilizacin, pero podra diluirse la abstraccin que representa la clase predecesora si alguno de los descendientes no es un miembro apropiado de la clase predecesora. A
medida que aumenta el NDD, tambin lo hace la cantidad de pruebas (requeridas pa-
ra ejercitar cada descendiente en su contexto operacional).
Acoplamiento entre clases de objetos (AECO). El modelo de conjunto de respuesta de una clase (CRC), expuesto 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. 11 A medida que AECO aumenta, 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 modificaciones se han hecho. En general, para cada clase deben mantenerse los valores de
AECO en el valor ms bajo que sea razonable. Esto es consistente con la directriz
general para reducir el acoplamiento en el software convencional.
rKeptos de
~toy
: :=i se aplican al
:n convencional
;;ienmdo a
'JS. Mantngase
ti oeoplomiento
'17 la cohesin de
i:2s yoperaciones.
Respuesta para una clase (RPC). El conjunto de respuesta para una clase es un
"conjunto de mtodos que tiene la posibilidad de ejecutarse como respuesta a un mensaje que recibe un objeto de esa clase" [CHI94]. La RPC es el nmero de mtodos en
el conjunto de respuesta. A medida que la RPC aumenta, 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 aumenta, se incrementa la complejidad del diseo general de la clase.
Falta de cohesin en mtodos (FCM). Cada mtodo dentro de una clase, e, tiene acceso a uno o ms atributos (tambin denominados variables de instancia). La
FCM es el nmero de mtodos que acceden a uno o ms de los mismos atributos. 12
Si ningn mtodo accede a los mismos atributos, entonces FCM = o. Para ilustrar el
caso donde FCM * o, 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 mtodos pueden acoplarse entre s mediante atributos. Esto aumenta la complejidad del diseo de clase. Aunque hay casos en que re-
11 Si las tarjetas de ndce CRC se desarrollan manualmente, el grado de avance y la consistencia deben evaluarse antes de determinar el AECO de manera confiable
12 La definicin formal es un poco ms compleja. Consltese CHl941 para conocer ms detalles
486
PARTE DOS PRCTICA DE LA INGENIERA DEL SOITWARE
sulta justificable un valor elevado para la FCM . Lo deseable es mantener alta la cohesin; es decir, conservar baja la FCM. 13
15.4.4 M1ricas orientadas a objetos: la coleccin de mtricas para a

diseo orientado a objetos
Harrison, Counsell y Nithi [HAR98] proponen un conjunto de mtricas para dise"'
orientado a objetos que proporcionan indicadores cuantitativos para las caractens
ticas del diseo orientado a objetos. A continuacin se presente una pequea muestra de estas mtricas:
13 La mtrica FCM proporciona conocimientos tiles en algunas situaciones, pero puede malintel'p"'tarse en otras. Por ejemplo, mantener el acoplamiento encapsulado dentro de una clase aumenta
cohesin del sistema como un todo. Por tanto, por Jo menos en un sentido importante, un FCM ir
elevado en realidad sugiere que una clase puede tener una mayor cohesin, no una menor.
CAPTULO 15 MTRICAS DEL PRODUCTO PARA U SOF1WARE
437
Mtodo del factor de herencia (MFH). El grado en que la arquitectura de clases

de un sistema orientado a objetos usa la herencia para mtodos (operaciones) y atributos se define como
MFH
=1
M; (C;)/1 Ma(C1)
donde la sumatoria se presenta desde i = 1 hasta Te. Te se define como el nmero total de clases en la arquitectura; e, es una clase dentro de la arquitectura y
Ma(C;)
= Md(C;) + M; (C,)
donde
Ma(C,)
= el nmero de mtodos que pueden invocarse en asociacin con C;.
MJC;)
= el nmero de mtodos declarados en la clase C;.
M,{C;) = el nmero de mtodos heredados (y no redefinidos) en C;.
El valor de MFH (el atributo de factor de herencia, AFH, se define de manera anloga) es un indicativo del impacto de la herencia en el software orientado a objetos.
'1l an61isis ~ sof1warecietlildo oolijetos poro evaluarsu calidad se est volviendo codovezm$ mporto:nfe ,t
. , ... el porodio,no forienlodo a objetos}sigueganando popularidad.
'
R~I Harnse, ,tlll.
Factor de acoplamiento (FA). Al principio de este capitulo se indic que el acoplamiento es una indicacin de las conexiones entre elementos de un diseo orientado a objetos. El conjunto de mtricas del diseo orientado a objetos define el acoplamiento de la siguiente manera:
FA
= L; l es_cliente (C;, C)l(T/ -
donde las sumatorias van desde i
Te)
= 1 hasta T, y desde j = l
hasta T,. La funcin
es_cliente = 1, si y slo si existe una relacin entre la clase cliente, Ce, y la clase servidor, C5 , y Ce * C5
= o, en cualquier otro caso

Aunque muchos factores afectan la complejidad, la facilidad de comprensin y el
mantenimiento del software, resulta razonable concluir que, a medida que aumenta
el valor de FA, tambin aumentar la complejidad del software orientado a objetos
y, como consecuencia, es posible que resulten afectadas la facilidad de comprensin y

mantenimiento, junto con la posibilidad de reutilizacin.
Harrison y sus colegas [HAR98J presenta:1 una anlisis detallado de MFH y FA,
junto con otras mtricas, y examinan su validez para emplearlos en la evaluacin de
la calidad del diseo.
488
PARTE DOS
15.4.5 Mtricas orientadas a objetos propuestas por Lorenz y Kidd

En su libro sobre mtricas orientadas a objetos, Lorenz y Kidd [LOR94] dividen las
mtricas basadas en clases en cuatro amplias categoras, cada una con un diseo al
nivel de componentes: tamao, herencia, valores internos y valores externos. Las
mtricas orientadas al tamao aplicadas a una clase de diseo orientado a objetos
se concentran en el conteo de atributos y operaciones de una clase individual, asi
como en valores promedio para el sistema orientado a objetos como un todo. Las
mtricas basadas en la herencia se concentran en la manera en que las operaciones
se reutilizan en la jerarqua de clases. Las mtricas para los valores internos buscan
cohesin y aspectos orientados al cdigo, y las mtricas de valores externos examinan el acoplamiento y la reutilizacin. A continuacin se presenta una muestra de
las mtricas propuestas por Lorenz y Kidd:
Tamao de la clase (TC). El tamao general de una clase se determina con las
siguientes medidas:
Durante lo revisin del

modelo de anlisis,
los tarjetas de ndice
CRC proporciono,n
uno indicacin
razonable de los
valores esperados
poro el tamoilo de lo
dase. Si se encuentro
una clase con un
nmero grande de
responsabilidades,
pinsese en dividirlo.
El nmero total de operaciones (de instancia heredada y privada) que estn

encapsuladas dentro de la clase.
El nmero de atributos (de instancia heredada y privada) que estn encapsulados por la clase.
La mtrica MPC que propusieron Chidamber y Kemerer (seccin 15.4.3) tambi..
es una medida ponderada de tamao de clase. Como ya se indic, los valores gra~
des de TC indican que tal vez una clase tenga demasiada responsabilidad. Esto "t
ducir la posibilidad de reutilizacin de la clase y complicar la implementacin )
prueba. En general, debe drsele ms peso a las operaciones y los atributos here<t
dos o pblicos para determinar el tamao de la clase [LOR94J. Las operaciones y.
atributos privados permiten la especializacin y estn ms focalizados en el dise...,.
Tambin deben calcularse los promedios para el nmero de atributos y operacion~
de clase. Cuanto menores sean los valores promedio para el TC, ms probable se
que las clases dentro del sistema puedan reutilizarse ampliamente.
Nmero de operaciones aadidas por una subclase (NOA) . Las subclases

especializan al agregar operaciones y atributos. A medida que el valor de NOA a_
menta, la subclase se aparta de la abstraccin implcita en la superclase. En gener
a medida que la profundidad de la jerarqua de clase aumenta (APH se vuelve rr
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 componentes del software convencional se a.centran en las caractersticas internas de un componente de software e incluyen C"
didas de cohesin, acoplamiento y complejidad del mdulo. Estas medidas ayuda:un ingeniero de software a juzgar la calidad de un diseo al nivel de componente
CAPTULO 15 MTRICAS DEL PRODUCTO PARA El. SOFTWARE
489
Las mtricas presentadas en esta seccin son de "caja de cristal", en el sentido de

que requieren conocimiento del funcionamiento interno del mdulo que se est considerando. Las mtricas de diseo al nivel de componentes se aplican una vez que
se ha desarrollado el diseo procedimental. Corno opcin, pueden demorarse hasta
que el cdigo fuente est disponible.
Mtricas de cohesin. Bieman y Ott [BlE94) 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 conceptos y medidas:
Porcin de datos. Definido simplemente, una porcin de datos es un recorrido

hacia atrs por un mdulo; busca valores de datos que afectan el estado del mdulo cuando comienza el recorrido. Debe indicarse que es posible definir las porciones del programa (que se concentran en instrucciones y condiciones) y las porciones de datos.
Muestras de datos. Las variables definidas para un mdulo se definen como
muestras de datos para el mdulo.
Seales de unin. Este conjunto de muestras de datos cae en una o ms porciones de datos.
Seales de superunin. Estas muestras de datos son comunes a todas las porciones de datos de un mdulo.
capacidad de unin. La capacidad de unin relativa de una seal de unin es directamente proporcional al nmero de porciones de datos que une.
Bieman y Ott desarrollan mtricas para cohesin funcional fuerte, cohesin funcional
dbil y adhesividad (que se relacona con el grado en que las seales de unin integran
las porciones de datos). Estas mtricas se interpretan de la siguiente manera [BIE94J:
Todas estas mtricas de cohesin abarcan valores de o a 1. Tienen un valor de o cuando
un procedimiento cuenta con ms de una salida y no muestra atributo alguno de cohesin
indicado por una mtrica particular. Un procedimiento sin seales de superunin (es decir, sin muestras comunes a todas las porciones de datos). tiene Ocohesin funcional fuerte (no hay muestras de datos que contribuyan a todas las salidas). Un procedimiento sin
seales de unin (es decir, sin muestras comunes a ms de una porcin de datos, en procedimientos con ms de una porcin de datos) muestra Ocohesin funcional dbil y O adhesividad (no hay muestras de datos que contribuyan a ms de una salida).
La cohesin funcional fuerte y la adhesividad se encuentran cuando las mtricas de
Bieman y Ott toman un valor mximo de l .
Mtricas de acoplamiento. El acoplamiento del mdulo proporciona una indicacin de la "conectividad" de un mdulo con otros mdulos. con datos globales y con
el entorno exterior. En el capitulo 9 se analiz el acoplamiento desde el punto de vista cualitativo.
490
PARTE DOS
PRC'nCA DE LA INGENIERA DEL SOFTWARE
Dhama [DHA95] ha propuesto una mtrica para el acoplamiento del mdulo qu:
abarca el acoplamiento de flujo de datos y de control, el global y el de entorno. La..
medidas necesarias para calcular el acoplamiento del mdulo se definen a partir d
cada uno de los tres tipos de acoplamiento indicados antes. En el caso del acopt:;
miento de flujo de datos y de control,
= nmero de parmetros de datos de entrada

Ce = nmero de parmetros de control de entrada
de
d5 = nmero de parmetros de datos de salida

c5 = nmero de parmetros de control de salida
En el caso del acoplamiento global:
gd = nmero de variables globales usadas como datos

8c = 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 ha

dentro)
con estas medidas se define un indicador de acoplamiento del mdulo, ma, de la

guiente manera:
ma = k/M
donde k es una constante de proporcionalidad y
M=~+~x~+~+~x~+~+~x~ + w+r
Los valores de k, a, by e deben derivarse empricamente.
A medida que el valor de ma aumenta, disminuye el acoplamiento general del ,..
dulo. Para lograr que la mtrica de acoplamiento suba a medida que aumenta el ::do de acoplamiento, se define una mtrica de acoplamiento revisada
e= l -ma
donde el grado de acoplamiento aumenta a medida que lo hacen las medidas eecuacin (15.6).
Mtricas de complejidad. Es posible calcular diversas mtricas del sot\l

para determinar la complejidad del flujo de control del programa. Muchas de es
se basan en la grfica de flujo. Como se analiz en el captulo 14, una grfia
una representacin compuesta de nodos y enlaces (tambin denominados aris.
Cuando los enlaces (aristas) estn dirigidos, la grfica de flujo es una grfica
gida.
CAPTULO 15
MmICAS DEL PRODUCTO PARA El SOFTWARE
491
McCabe y Watson [MCC94] identifican varios usos importantes para las mtricas
de complejidad:
Las mtricas de complejidad se utilizan para predecir la informacin crtica acerca de la
confiabilidad y la facilidad de mantenimiento de sistemas de software a partir del anlisis
automtico del cdigo fuente (o la informacin del diseo procedimental]. Las mtricas de
complejidad tambin ofrecen retroalimentacin durante el proyecto de software para ayudar a controlar [la actividad del diseo]. Durante las pruebas y el mantenimiento, ofrecen
una informacin detallada acerca de los mdulos de software para ayudar a detectar reas
de posible inestabilidad.
La mtrica de complejidad cuyo uso es el ms extendido (y debatido) para el

software de computadora es la complejidad ciclomtica, originalmente desarrollada por Thomas McCabe [MCC76l. [MCC89). y que se analiz con todo detalle en el
capitulo 14.
zuse ([ZUS90], [ZUS97]) presenta un anlisis enciclopdico de no menos de 18

categorias diferentes de las mtricas de complejidad del software. El autor presenta
las definiciones bsicas de mtricas en cada categora (por ejemplo, hay distintas variaciones de la mtrica de complejidad ciclomtica) y luego analiza y critica cada
una. El trabajo 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 dominante en los sistemas orientados a objetos,
se han propuesto pocas mtricas para operaciones que residen dentro de la clase.
Churcher y Shepperd [CHU95J analizan esto cuando afirman: "Los resultados de estudios recientes indican que los mtodos tienden a ser pequeos en cuanto al nmero de instrucciones y a complejidad lgica [WlL93]. 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 examinan las consultas promedio de mtodos (operaciones). Tres mtricas simples, propuestas por Lorenz y Kidd [LOR94J, resultan apropiadas:
Tamao promedio de operacin (TOprom) Aunque las lneas de cdigo podran usarse como indicador del tamao de operacin, la medida de lneas de cdigo adolece de una serie de problemas analizados en el captulo 22. Por ello, el
nmero de mensajes que enva la operacin proporciona una opcin al tamao de
operacin . A medida que aumenta el nmero de mensajes enviados por una sola operacin, es probable que las responsabilidades no se hayan asignado bien dentro de
la clase.
Complejidad de la operacin (CO). La complejidad de una operacin se calcula empleando cualquier mtrica de complejidad propuesta para el software convencional [ZUS90]. Debido a que las operaciones deben limitarse a una responsabilidad
especifica, el diseador debe esforzarse por mantener la CO lo ms baja posible.
492
PARTE DOS
Nmero promedio de parmetros de la operacin (NPOprom) Mientras ma

yor sea el nmero de parmetros de la operacin, ms compleja ser la colaboracil.
entre los objetos. En general, el NPOp,om debe mantenerse lo ms bajo posible.
15.4.8 Mtricas de diseo de la interfaz de usuario

Aunque hay obras importantes que tratan el diseo de inteaces ser humano/mqu:(captulo 12), se ha publicado relativamente poca informacin sobre mtricas que xporcionen conocimientos profundos sobre la calidad y la facilidad de uso de la interfa..
Sears [SEA93J sugiere que lo apropiado delformato (AF) es una mtrica de diseo
liosa para interfaces ser humano/mquina. Una GUI comn aplica entidades de fon:to (iconos grficos, texto, mens, ventanas, etc.) para ayudar al usuario a completar
reas. Para realizar una tarea determinada con una GUI, el usuario debe pasar de u;:
entidad de presentacin a la siguiente. La posicin absoluta y relativa de cada entJ
de presentacin, la frecuencia con que se emplea y el "costo" de la transicin de t=entidad de formato a la siguiente contribuirn a determinar lo apropiado de la inter.:-
,,. . . . ~lc!.l*OS un ptjncipio del diseo de interfaces de usuario si echa lo 'I"' en IHl laviidora. Si
. . . . . .. nod( quedar nmpio/
Los mtricos de
diseo de lo interfaz
son adecuados, pero
sobre todo lo dems,
es necesario asegurarse plenamente de
que lo interfaz le
gusto alos usuarios
fino/es y de que stos
se sienten cmodos
con los interacciones
requeridos.
Kokol y sus colegas [KOK95J definen una mtrica de cohesin para las panta.
de la interfaz de usuario que mide la conexin relativa entre el contenido de ._
pantalla y el de otra. Si los datos (o el contenido adicional) presentados en una ;::talla pertenecen a un solo objeto importante de datos (como se defini dentro
modelo de anlisis), la cohesin de la interfaz para esa pantalla ser alta. Si se.
sentan muchos tipos diferentes de datos o contenidos y esos datos se relacionan_
diferentes objetos de datos, la cohesin de la interfaz de usuario ser baja. Los
tores proporcionan modelos empricos para la cohesin [KOK95].
Adems, las medidas directas de la interaccin con la interfaz de usuario se e
centran en la medicin del tiempo requerido para alcanzar un escenario o una ... ~
racin especficos, el tiempo requerido para recuperarse de una condicin de e:los conteos de operaciones o tareas especficas requeridas para alcanzar un case
uso, el nmero de objetos de datos o contenido presentados en una pantalla, la e'..
sidad y el tamao del texto y muchos otros. Sin embargo, estas medidas directas de;
estar organizadas para crear mtricas de interfaz de usuario que tengan un sigcado y que lleven a mejorar la calidad, la facilidad de uso, o ambos elementos G:.
interfaz de usuario.
Es importante observar que la seleccin de un diseo de interfaz grfica de us
rio puede determinarse a partir de mtricas como AF o la cohesin de pantalla .
interfaz de usuario, pero el rbitro final debe ser la entrada del usuario basada
prototipos de interfaz grfica de usuario. Nielsen y Levy [NIE94] reportan que "se
ne una probabilidad razonablemente grande de xito si se elige entre las interf;a
CAPTULO 15
MTRICAS DEL PROOUCIO PARA EL SOITWARE
493
[diseos] basadas exclusivamente en las opiniones de los usuarios. El desempeo

promedio de las tareas de los usuarios y su satisfaccin subjetiva con una interfaz
grfica de usuario tienen una elevada correlacin".
La teora de Halstead de la "ciencia del software" [HAL77l propuso las primeras "le-
yes" analiticas para el software de computadora. 14 Halstead asign leyes cuantitativas al desarrollo de este software empleando un conjunto de medidas primitivas que
se derivan despus de que se ha generado el cdigo, o se estiman una vez que el diseo est completo. Las medidas son:
n 1 = el nmero de operadores distintos que aparecen en un programa.

n2 = el nmero de operandos distintos que aparecen en un programa.
N1
= el nmero total de veces que aparece el operador.
N2 = el nmero total de veces que aparece el operando.

Halstead aplica estas medidas primitivas para desarrollar expresiones relacionadas
con la longitud global del programa, el volumen mnimo posible para un algoritmo, el
volumen real (nmero de bits requeridos para especificar un programa), el nivel del
programa (una medida de la complejidad del software), el nivel del lenguaje (una
constante para un lenguaje determinado) y otras caractersticas como esfuerzo de desarrollo, tiempo de desarrollo y hasta el nmero proyectado de fallas en el software.
Halstead demuestra que la longitud N se puede estimar as:
N
= n, log2 n, + n2 log2 n2
y que el volumen de programa se puede definir como:

V
= N log2 (n, + n2)
Se debe observar que V variar de acuerdo con el lenguaje de programacin y que representa el volumen de informacin (en bits) necesario para especificar un programa.
11 can(unto de regios que sigue el cerebrohumano [para el desarrollo de algorilmos] es ms rigid11 de fo qwe suele
. pellSIN..
En teora, debe existir un volumen mnimo para un algoritmo determinado. Halstead define una relacin de volumen, L, como la relacin entre el volumen de la forma ms compacta de un programa y el volumen real del programa. En realidad, L
siempre debe ser menor que 1. Desde el punto de vista de las medidas primitivas. la
rel acin de volumen se 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 programacin seleccionados (por ejemplo, [FEL.89]1.
PARTE DOS
494
L = 2!n1
n2IN2
El trabajo de Halstead es sensible a la verificacin experimental, y se ha realizado una gran cantidad de investigacin sobre la ciencia del software. Para obtener
ms informacin, consltense [ZUS90], [FEN9l] y [ZUS97].
ua.,
MRIJCAI Ml6 IMIIM

Aunque se ha escrito mucho sobre las mtricas del software para pruebas (por ejemplo, [HET9.3)}, casi todas las mtricas propuestas se concentran en el proceso de
prueba, no en las caractersticas tcnicas de las propias pruebas. En general, quienes aplican las pruebas deben depender de las mtricas de anlisis, diseo y cdi~
como gua para el diseo y la ejecucin de los casos de prueba.
Las mtricas basadas en la funcin (seccin 15..3. l) se aplican para predecir el esfuerzo general de la prueba. Es posible recopilar varias caractersticas al nivel de
~
~~
C~VE
Los mtricos de pruebo
se agrupon en dos
amplios cotegorfos:
1) los que troton de
predecir el nmero
proboble de pruebas
que se requieren o
voos niveles de
pruebo, y 2} los que
se concentron en lo
cobertura de lo pruebo
poro un componente
determinado.
proyecto (como el esfuerzo y el tiempo para las pruebas, los errores descubiertos, e
nmero de casos de prueba producidos) de proyectos anteriores y correlacionarlas
con el nmero de puntos de funcin que produce un equipo de proyecto. Este equ
po tiene la opcin posterior de proyectar "valores esperados" de estas caracterstica:.
para el proyecto actual.
Las mtricas del diseo arquitectnico proporcionan informacin sobre la faci~
dad o la dificultad asociada con la prueba de integracin (captulo 13) y la necesida
de contar con software especializado en pruebas (por ejemplo, resguardos y contrr
!adores). La complejidad ciclomtica (una mtrica de diseo al nivel de componerles} cae en el eje de las pruebas de camino bsico, un mtodo de diseo de casos e.;;
prueba presentado en el capitulo 14. Adems, la complejidad ciclomtica se emp,c::..a
para determinar los mdulos que sern candidatos a pruebas de unidad ms exter
sas. Los mdulos con elevada complejidad ciclomtica son ms propensos a em:
que los que tienen una menor complejidad. Por ello, la persona responsable de
prueba debe realizar un esfuerzo superior al promedio para descubrir errores en es
tos mdulos antes de integrarlos en un sistema.
15.6. l
Mtricas de Halstead aplicadas a las pruebas
Tambin es posible estimar el esfuerzo que requieren las pruebas mediante mtrica..
derivadas de las medidas de Halstead (seccin 15.5). Si se aplican las definiciones d.::
volumen, V, y el nivel de un programa, NP, el esfuerzo de Halstead, e, se calcula:as:
NP = l/[(n 1/2) X (N2/n2)l

e= VINP
(15.-::
(15.7.:.
El porcentaje del esfuerzo general de prueba que se debe asignar a un k se estim:

ria con la siguiente relacin:
porcentaje de esfuerzo de prueba (k}
= e(k)/e(l)
donde e(k) se calcula para el mdulo k empleando las ecuaciones
(15.8
(15.7), y donde
CAPTULO 15
MTRICAS DEL PRODUCTO PARA El. SOFTWARE
495
sumatoria en el denominador de la ecuacin (15.8) es la suma del esfuerzo de Halstead en todos los mdulos del sistema.
15.6.2 Mtricas para pruebas orientadas a objetos

Las mtricas del diseo orientado a objetos expuestas en la seccin 15.4 proporcionan 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
Binder [B1N94] sugiere una amplia serie de mtricas de diseo que tienen una influencia directa sobre la "facilidad de prueba" de un sistema orientado a objetos. Las
mtricas toman en cuenta aspectos de encapsulamiento y herencia. A continuacin
se presenta una muestra:
Falta de cohesin en mtodos (FCM). ts Mientras mayor sea el valor de FCM, deben
probarse ms estados para asegurar que los mtodos no generen efectos colaterales.
Porcentaje pblico y protegido (PYP). Esta mtrica indica el porcentaje de atributos de clase que son pblicos o estn protegidos. Valores elevados de PYP aumentan 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 estos efectos colaterales.
Integrantes de acceso pblico a datos (APD). Esta mtrica indica el nmero
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 descubrimiento de estos efectos colaterales.
Nmero de clases raz (NCR). Esta mtrica es un conteo de las distintas jerarquas de clase descritas en el modelo de diseo. Deben desarrollarse conjuntos de
prueba para cada clase raz y para la jerarqua de clases correspondiente. A medida
que aumente el NCR, tambin aumentar el esfuerzo de la prueba.
Dependencia hacia dentro (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 operaciones a partir de una clase raz. Debe evitarse que FIN > 1 a toda costa.
Nmero de descendientes (NDD) y rbol de profundidad de herencia (APH). 17
Como se analiz en el captulo 14, es necesario volver a probar los mtodos 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 runguno de los atributos es pblico o privado; es decir,
PYP = O. 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 descripon de NDD y APH.
496
PARTE DOS PRCTICA DE LA INGENIERA DEL SOFTWA!lE
15,2 NIJ'BIQA$ RAB4 IL H4B1IBJMIIHI9

Todas las mtricas del software presentadas en este captulo se aplican tambin a.
desarrollo de nuevo software y al mantenimiento del existente. Sin embargo, se h~
propuesto mtricas diseadas explicitamente para actividades de mantenimiento
El IEEE Std. 982.1-1988 [IEE94] sugiere un ndice de madurez del software (IMS
que proporciona una indicacin de la estabilidad de un producto de software (basa
da en los cambios que ocurren con cada versin del producto). Se determina la si
guiente informacin:
MT
= el nmero de mdulos en la versin actual
Fe = el nmero de mdulos cambiados en la versin actual

Fa = el nmero de mdulos aadidos a la versin actual
Fd = el nmero de mdulos de la versin anterior que se eliminaron en la actu.::.
El ndice de madurez del software se calcula de la siguiente manera:
IMS
[MT- (Fa+ Fe + Fd)]I MT
A medida que el IMS se acerca a 1.0, el producto empieza a estabilizarse. El IMS ta.7
bin se aplica como mtrica para la planeacin de actividades de mantenimiento <k
software. El tiempo medio para producir una versin de un producto de softwa:puede correlacionarse con el IMS, y pueden desarrollarse modelos empricos para ..
esfuerzo de mantenimiento.
Mtricas del producto
~ Objetivo : 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 pruebo.
Mecnica : 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 lo mayor
parle de los casos, la herramienta de mtrico analiza uno
representacin del software (por ejemplo, un modelo UML
o el cdigo fuente) y desarrolla una o ms mtricos.
He rramientas representativa s 18
Krakafou Mefrics, desarrollada por Power Software
(www.powersoftware.com/ products). calculo mtricos
de complejidad, Holstead y otras relacionados poro

C/C++ y Javo.
Metrics4C, desarrollado por + 1 Software Engineering
(www.plus-one.com/Metrics4C-fact_sheet.htm1), calculo
varias mtricas arquitectnicas, de diseo y orientados
o cdigo, adems de otros orientados o proyecto.
Rational Rose, desarrollada por Rotionol Corporotion
(www.rotionol.com), es un conjunto de herramientas
completos poro el modelado UML que incorporo varios
caractersticos de anlisis de mtricos.
RSM, desarrollado por M-Squored Technologies
(msquoredtechnologies.com/ m2rsm/index. html),
calculo uno amplio variedad de mtricos orientadas a
configuracin para C, C++ y Java.
Undersfond, desarrollada por Scientific Toolworks, lnc.
(www.scitools.com), calculo las mtricas orientados o
cdigo poro diversos lenguajes de programacin.
18 Las herramientas expuestas representan una muestra de esta categora. En casi todos los casos la.
nombres de las mismas son marcas registradas de sus respectivos desarrolladores.
CAPTULO 15
MTRICAS DEL PRODUC'IO PARA EL SOFTWARE
497
Las mtricas del software proporcionan una manera cuantitativa de evaluar la calidad de los atributos internos de un producto, lo que permite que un ingeniero de
software evale la calidad antes de construirlo. Las mtricas proporcionan los conocimientos 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 software debe ser simple y calculable, 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 diseo consideran los aspectos del diseo de la arquitectura, al nivel de componentes
y de la interfaz. Las mtricas del diseo de la arquitectura consideran los aspectos estructurales del modelo de diseo. Las mtricas de diseo al nivel de componentes
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 proporcionan un indicio de la facilidad con que se usa la interfaz grfica del usuario.
Las mtricas para los sistemas orientados a objetos se concentran en la medicin
que puede aplicarse a las caractersticas de clase y diseo (localizacin, encapsulamiento, 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 fuente. Empleando el nmero de operadores y operandos presentes en el cdigo, se desarrolla una variedad de mtricas para evaluar la calidad del programa.
Pocas mtricas del producto se han propuesto para emplearlas directamente en
las pruebas del software y en el mantenimiento. Sin embargo, muchas otras mtricas del producto pueden aplicarse para guiar el proceso de prueba y como mecanismo 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 facilidad de prueba de un sistema orientado a objetos.
BIEBBINCiIA$
[ALB79) Albrecht, A. J., "Measuring Application Development Productivity", en Proc. JBM Application Development Symposium, Monterey, CA, octubre de 1979, pp. 83-92.
[ALB83] Albrecht, A. J. y J. E. Gaffney, "Software Function, Source Lines of Code and Development Effort Prediction: A Software Science Validation", en IEEE Trans. Software Engineering,
noviembre de 1983, pp. 639-648.
[BAS84) Basili, V. R. y D. M. Weiss, "A Methodology for Collecting Valid Sotlware Engineerng
Data", en IEEE Trans. Software Engineering, vol SE-IO. 1984, pp. 728-738.
[BER95] Berard, E., "Metrics for Object-Oriented software Engineering", publicacin de Internet
en comp.software-eng, 28 de enero, 1995
[BIE94J Bieman, J. M. y L. M. Ott, "Measuring Functional Cohesion" en IEEE 1rans. Software En
gineering, vol. SE-20, nm. 8, agosto de 1994. pp 308-320
498
PARTE DOS
[B1N94J Binder, R. v., "Object-Oriented Software Testng", en CACM, vol. 37, nm. 9, septiemb'
de 1994, p. 29.
[BR196J Briand, L. c., S. Morasca y v. R. Basili. "Property-Based Software Engineering Measure
ment", en IEEE Trans. SOftware Engineering. vol. SE-22, nm. 1, enero de 1996, pp. 68-85
(CAR90J Card, D. N. y R. L. Glass, Measuring Software Design Quality. Prentice-Hall, 1990.
(CAV78J Cavano. J. P. y J. A. McCall, "A Framework for the Measurement of Software QualitJ
Proc. ACM Software Qua/ity Assurance Workshop, noviembre de 1978, pp. 133-139.
[CHA89l Charette, R. N. SOftware Engineering Risk Analysis and Management. McGraw-Hill/lnk
text, 1989.
[CHl94] Chidamber, S. R. y C. F. Kemerer, "A Metrics Suite for Object-Oriented Design", en IEfr.
1tans. Software Engineering, vol. SE- 20. nm. 6, junio de 1994, pp. 476-493.
[CHl98J Chidamber, s. R., D. P. Darcy y C. F. Kemerer, "Management Use of Metrics for Objec
Oriented Software: An Exploratory Analysis", en IEEE Itans. Software Engineering. vol. SE-1~
nm. 8, agosto de 1998, pp. 629-639.
[CHU95J Churcher, N. l. y M. J. Shepperd. "Toward a Conceptual Framework for Object-Orien...
Metrics". en ACM Software Engineering Notes, vol. 20, nm. 2, abril de 1995, pp. 69-76.
[CURSO) Curts, W., "Management and Experimentation in Software Engineering", en Proc. IEEE.
vol. 68, nm. 9, septiembre de 1980.
[DAV93] Davis, A. et al., "ldentifying and Measuring Quality in a Software Requirements Spec
fication", en Proc. First lntl. Software Melrics Symposium, IEEE. Baltimore, MD, mayo de 19'<
pp. 141 - 152.
[DEM81J DeMillo, R. A. y R. J. Lipton, "Sotlware Project Forecasting", en Software Melrics (A
Perlis, F. G. Sayward y M. Shaw, eds.). MIT Press, 1981, pp. 77-89.
[DEM82J DeMarco, T., Controlling Software Projects, Yourdon Press, 1982.
[DHA95J Dhama, H., "Quantitative Models of Cohesion and Coupling in Software", en Joumc.
Systems and Software, vol. 29, nm. 4, abril de 1995.
[EJ191] Ejiogu, L., Software Engineering with Formal Melrics, QED Publishing, 1991.
[FEL89J Felican, L. y G. Zalateu, "Validating Halstead's Theory for Pascal Programs", en lE.
1tans. Software Engineering, vol. SE-15, nm. 2, diciembre de 1989, pp. 1630-1632.
[FEN91J Fenton, N., Software Metrics, Chapman and Hall. 1991 .
[FEN94] Fenton, N., "Software Measurement: A Necessary Scientific Basis", en IEEE Trans. S.
ware Engineering, vol. SE-20, nm. 3, marzo de 1994, pp. 199-206.
(GRA87J Grady, R. B. y D. L. caswell, Software Metrics: Establishing a Company-Wde Progrc:Prentice-Hall, 1987.
[HAL77J Halstead, M., Elements of Software Scence. North-Holland, 1977.
[HAR98) Harrison, R.. s. J. CounselJ y R. v. Nithi, "An Evaluation of the MOOD set of Oba.
Oriented Software Metrics", en IEEE 1tans. Software Engineering, vol. SE-24, nm. 6, junio
1998, pp. 491-496.
[HET93J Hetzel, B., Making Software Measurement Work, QED Publishing, 1993.
[IEE93J IEEE Standard Glossary o/software Engineering Terrninology, IEEE, 1993.
(IEE94J Software Engineering Standards, edicin 1994, IEEE, 1994.
[IFPO I J Function Point Counting Practices Manual, versin 4 .1.1, lnternational Function Pe
Users Group, 2001, disponible en http://www.ifpug.org/publications/manual.htm
[IFP03] Function Point Bibliography/Reference Library, lnternational Function Point Us.
Group, 2003, disponible en http:/ /www.ifpug.org/about/bibliography.htm
(KOK95) Kokol, P., J. Rozman y V. Venuti, "User Interface Metrics", ACM SIGPIAN Notices, vol
nm. 4, abril de 1995, puede descargarse de: http://portal.acm.org/.
[KYB84J Kyburg, H. E., Theory and Measurement, Cambridge University Press, 1984.
[LET03J Lethbridge, T., comunicacin privada sobre mtricas de software, junio de 2003.
(LON02] Longstreet, D. "Fundamental of Function Point Analysis", Longstreet Consulting, Ir
2002, disponible en http:/ /www.ifpug.com/fpafund.htm.
fLOR94] Lorenz, M. y J. Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994.
[MCC76J McCabe. T. J., "A Software Complexity Measure", en IEEE Itans. Software Engineerr
vol. SE-2, diciembre de 1976, pp. 308- 320.
(MCC77J McCall, J., P. Richards y G. Walters, "Factors in Software Quality", tres volmenes,
AD-A049-014. 015, 055. noviembre de 1977.
CAPTULO 15 MTRICAS DEL PRODUCTO PARA El SOFTWARE
499
[MCC89J McCabe, T. J. y c. w. Butler, "Design Complexity Measurement and Testing", en CACM,

vol. 32, nm. 12, diciembre de 1989. pp. 141 5-1 425.
[MCC94J McCabe, T. J. y A. H. Watson, "Software en Complexity", en Crosstalk, vol. 7, nm. 12,
diciembre de 1994, pp. 5-9.
[NIE94J Nielsen, J. y J. Levy, "Measuring Usability: Preference vs. Performance", en CACM, vol. 37,
nm. 4, abril de 1994, pp. 65-75.
[ROC94J Roche, J. M., "Software Metrics and Measurement Principies", en Software Engineering
Notes, ACM, vol. 19, nm. l, enero de 1994, pp. 76-85.
[SEA93) Sears, A., "Layout Appropriateness: A Metric for Evaluating User Interface Widget Layout", en JEEE 1rans. Software Engineering, vol. SE-19, nm. 7, julio de 1993, pp. 707-719.
[SHE98J Sheppard, M., Goal, Queslion, Metric, 1998, disponible en http://dec.bournemouth.ac.uk/
ESERG/mshepperd/SEMGQM .html
[S0L99] Van Solingen, R. y E. Berghout, The Goal/Queston/Metric Method, McGraw-Hill, 1999.
[UEM99) Uemura, T., S. Kusumoto y K. lnoue, "A Function Point Measurement Too! for UML Design Specifications", en Proc. OfSixth Intematonal Symposium on Software Metrics, IEEE, noviembre de 1999, pp. 62-69.
(USA87] Management Quali!JI Insight, AFCSP 800- 14 (U.S. Air Force), 20 de enero de 1987.
[WHI971 Whitmire, s., Object-Oriented Design Measurement, Wiley, 1997.
[WIL93J Wilde, N. y R. Huitt. "Maintaining Object-Oriented Software", en IEEE Software, enero de
1993, pp. 75-80.
[ZUS90) Zuse, H., Software Complexity: Measures and Methods, DeGruyter, 1990.
[ZUS97] Zuse, H., A Framework ofSoftware Measurement, DeGruyter, 1997.
15.1. La teora de la medicin es un tema avanzado que tiene una fuerte innuencia sobre las
mtricas del software. Utilizando [ZUS97). [FEN91], [KYB84J u otras fuentes, escribir un breve
ensayo que delinee los principales principios de la teora de la medicin. Proyecto individual: desarrollar una presentacin sobre el tema y presentarla ante la clase.
16 .2. Los factores de calidad de McCall se desarrollaron durante la dcada de 1970. Casi todos
los aspectos de la computacin han cambiado drsticamente desde que se desarrollaron; sin
embargo, los factores de McCall siguen aplicndose al software moderno. Podria llegarse a algunas conclusiones a partir de este hecho?
15 .3. Por qu no se puede desarrollar una sola mtrica que lo abarque todo para la complejidad o la calidad de un programa?
15.4. Trtese de desarrollar una medida o una mtrica tomada de la vida real que viole los atributos de las mtricas efectivas del software que se definieron en la seccin 15.2.5
15.5. Un sistema tiene 12 entradas externas, 24 salidas externas, campos para 30 consultas externas diferentes, maneja cuatro archivos lgicos externos y tiene interfaces con seis sistemas
heredados diferentes (6 AIE). Todos estos datos tienen una complejidad promedio, y el sistema
general es relativamente simple. Calclese el punto de funcin para el sistema.
16.6. El software para el Sistema X tiene 24 requisitos funcionales individuales y 14 no funcionales. Cul es la especificidad de los requisitos? En qu grado se ha completado?
15.7. Un importante sistema de informacin tiene 1140 mdulos; 96 mdulos realizan funciones de control y coordinacin, y 490 dependen de un procesamiento anterior. El sistema procesa
alrededor de 220 objetos de datos, cada uno con un promedio de tres atributos. Hay 140 elementos nicos de la base de datos y 90 segmentos diferentes de sta. Por ltimo, 600 mdulos
tienen puntos nicos de entrada y salida. Calclese el LCED del sistema.
15.8 . Una clase, X, tiene 12 operaciones. Se ha calculado la complejidad ciclomtica para todas las operaciones del sistema orientado a objetos, y el valor promedio de la complejidad del
mdulo es de 4. Para la clase X, la complejidad de la operacin I a la 12 es 5, 4, 3, 3, 6, 8, 2, 2,
5, 5, 4 y 4, respectivamente. Calclense los mtodos ponderados por clase.
500
PARTE DOS
PRCl1CA DE LA INGENIERA DEL SOF'!WARE
15.9. Desarrllese una herramienta de software que calcule la complejidad ciclomtica de u::mdulo de lenguaje de programacin. Elijase el lenguaje que se desee.
15.1 o. Desarrolle una pequea herramienta de software que realice un anlisis de Halstea.;
sobre cdigo fuente en el lenguaje de programacin que se desee.
15.11. Un sistema heredado tiene 940 mdulos. La ltima versin requiri que 90 de ese
mdulos cambiaran. Adems, se agregaron 40 nuevos mdulos y se eliminaron 12 de esos m....
dulos. Calclese el indice de madurez del software para el sistema.
Hay un nmero sorprendentemente grande de libros dedicados a las mtricas del soflware, a...
que la mayor parte de ellos se concentra en las mtricas del proceso y el proyecto, por lo e;:
excluyen las mtricas del producto. Kan (Metrics and Models in Software Qualicy Engineering,
dison-Wesley, segunda edicin, 2002). Fenton y Pfleeger (Software Metrics: A Rigourous and Pr:tical Approach, Brooks-Cole Publishing, 1998) y Zuse [ZUS97) han escrito tratamientos coro;:
tos de las mtricas del producto.
Libros de Card y Glass [CAR90). Zuse [ZUS90], Fenton [FEN9 I L Ejiogu [EJI91 J. Moeller y P.:
lish (Software Metrics, Chapman y Hall, 1993) y Hetzel [HET93] atienden las mtricas del pro..
to con algn detalle. Ornan y Pfleeger /Applyig Software Metrics, IEEE Computer Society
1997) han editado una antologa de artculos importantes sobre las mtricas del software. A.
ms, vale la pena examinar los siguientes libros:
Conte, S. D., H. E. Dunsmore y V. Y. Shen, Software Engineering Metrics and Models, Be:min-Cummings, 1984.
Grady, R. B., Practica/ Software Metrics Jor Project Management and Process Improvemenl, ~
tice-Hall, 1992. Sheppard, M., Software Engineering Metrics, McGraw-Hill, 1992.
Denvir, Herman y Whitty presentan la teora de la medicin del software en una colea:editada de artculos (Proceedings ofthe International BCS-FACS Workshop: Formal Aspects of'
surement, Springer-Verlag, 1992). Shepperd (Foundations of Software Measurement, Pre
Hall, 1996) tambin atiende con cierto detalle la teora de la medicin. El estado actual de:.;
vestigacin se presenta en los Proceedings ofthe symposium on Software Metrics (IEEE, pub:
dos anualmente).
Un resumen muy completo de docenas de mtricas de software tiles se presenta en {IEE
En general, un anlisis de cada mtrica se ha reducido a los "primitivos" (las medidas) eser
les necesarios para calcular la mtrica y las relaciones apropiadas para realizar el clculc
apndice proporciona un anlisis y muchas referencias.
Whitmire [WHl97) presenta el tratamiento ms completo y matemticamente sofisticad.
las mtricas orientadas a objetos que se haya publicado a la fecha. Lorenz y Kidd [LOR94) y'dersen-Sellers (Object-Oriented Metrics: Measures of Complexicy, Prentice-Hall, 1996) ofrea.
nico libro adicional dedicado a las mtricas orientadas a objetos. Hutcheson (Software 1l
Fundamentals: Methods and Metrics, Wiley, 2003) presenta una guia til para la aplicacir
uso de mtricas para la prueba del software.
Una amplia variedad de fuentes de informacin sobre mtricas del software se enCUb
disponible en Internet. Una lista actualizada de referencias en la World Wide Web relevante,.
ra las mtricas del software se encontrar en el sito Web de SEPA:
,,
APLlC ACI
DE LA INGENIERA
WEB
"
.,
n esta parte de Ingen.Je.riQ del SOftwllre: un enji:,qQe ~c_o,

se aprendern los principios, <;onceptos y mtodos con que
se crean aplicaciones Web de alta calidad. Las siguientes
preguntas se abordan en los captulos posteriores:

Las aplicacionesWeb {WebApps) son diferentes de otros
tipos de software?
Qu es la ingeniera Web y qu elementos de la prctica tl~

la ingeniera del software puede adoptar?
Cules son los elementos de un proeso de ingenierta Web? ,
Cmo se fonnula y planea u,n proyecto de ingeniera Web?
CtJ10 se analizan y modelan los requisitos las WebApps?
~ Qu conceptos y principios guan la prctica en el diseo .de
las WebApps?
.,
Cmo se dirigen la arqutectur, la intet:rase y el diseo de
l-
de
navegacin de las WebARps? ,
'
:~~
Qu tcnicas de construccin se pueden aplicar para implementar el modelo del diseo?

Qu conceptos, principios y mtodos de,prue,:ba son aplica~
bles .a la ingeniera Web?
Una vez respondidas estas preguntas se estar mejor preparado para realizar la ingeniera de aplicaciones Web de alta calidad.
CAPTULO
CONCEPTOS
CX..AV f:
tntrlO$
dualidad .. .513
lngeltlenl Web
herr'dffllntos ,508
todo, ... ..$07

proceso J07
marco~trDNJI>
del proceso . JQ9
lores
p,<tko$ .. S12
preguntas
bsicas .Sil
WebApps
atributos . .504
categorios . .506
_L
a World Wide Web y la Internet que la alimentan son, posiblemente, los d

sarrollos ms importantes en la historia de la computacin, Estas tecno.
glas han llevado a todos (con cientos de millones ms que eventualmen::
seguirn) a fa era de la infonntica; adems, se han cnvertdo en parte integra'.
de la Vida diaria en la primera dcada del siglo xx1.
Para quienes pueden recordar un mundo sin la Wb, el crecimiento cat
de la tecnlogale:ne su odgen en otra era: los primeros <las <!el software. En
una poca de poca disciplina pero enorme entusiasmo y creatividad. Eran tiem
pos en que 1osprogr_arnadores a menudo ingresaban a sistemas en conjunto, a , :
ces para bien, a veces para mal. La actitud prevaleciente pareca ser: "hazlo ra
pido y entra en el campo; nosotros lo llmpiaremos {y mejor entiende qu es
que realmente se necesita constru.ir} conforme avancemos'1 Suena familiar'
En una mesa redonda virtual publicada en 1EEE Software [PRE9S-J, mantm
fume mi posicin en relacin con la ingenerfa Web:
Me par~ce que cualquier producto o sistema importante. vale la pena una ingeniera
Antes de comeniar a construirla es {llejor que entienda el problema. di$efie una so-lucin factible, la implemente en una (onna slida yl ponga a prueba amplamente
Tal vez tambin tenga que controlar los cambios conf(:mn el trab9-jo avance y disponer de alg11n mecanismo para asegurar la calidad del resultado.final. Muchos desarrolladores de Web no estn de acuerdo con esto; ellos piensan que su mundo
realmente es diferente y que los enfoques ClWt\CiOnaleS de ngenera del software
simplem~l'lte no se aplican.
CAPTULO 16
INGENIERA WEB
503
Esto conduce a una pregunta clave: se pueden aplicar principios, conceptos y mtodos 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 enmaraada" conforme se adentra ms este nuevo siglo. Esta frase entraa un cmulo de
aplicaciones basadas en Web mal desarrolladas y que tienen muy altas probabilidades 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 sacudida. 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 aplicacin de sistemas basados en Web complejos y a gran escala, existe una apremiante 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 usuario que colocan desafos adicionales al desarrollo de aplicaciones basadas en Web.
La ingeniera Web (!Web) aplica "slidos principios cientficos, de ingeniera y de
administracin, y enfoques disciplinados y sistemticos para el desarrollo, despliegue y mantenimiento exitosos de sistemas y aplicaciones basados en Web de alta calidad" [MUR99].
504
PARTE TRES
APLICACIN DE LA INGENIERA WEB
En los primeros das de la World Wide Web (circa 1990 a 1995) los "sitios Web" consistan en poco ms de un conjunto de archivos de hipertexto ligados que presentaban informacin mediante texto y grficos limitados. Conforme el tiempo pas, e
HTML aument al desarrollar herramientas (por ejemplo, XML, Java) que permitieron a los ingenieros Web ofrecer capacidades de clculo junto con informacin. Nacieron los sistemas y aplicaciones' basados en Web (se les referir de manera colectiva como WebApps). En la actualidad, las WebApps han evolucionado en sofistica
das herramientas de computacin que no slo proporcionan funcin por s mismas
al usuario final, sino que tambin se han integrado con bases de datos corporativas
y aplicaciones de negocios.
.......
'Tlfe l ~ en que veamos ciertn espee de estabilizacin, lo Web se hobr convettido ena'lgo 0iij4" ! UIIII
"'
Existe poco debate en cuanto a que las WebApps son diferentes a las mucha:
otras categoras de software informtico analizadas en el captulo 1. Powell resllf"' _
las diferencias principales cuando establece que los sistemas basados en Web "im
lucran una mezcla entre publicacin impresa y desarrollo de software, entre man..
ting e informtica, entre comunicaciones internas y relaciones externas, y entre a.;
te y tecnologa" [POW98]. En la gran mayora de las WebApps se encuentran los
guientes atributos.
Intensidad de red. Una WebApp reside en una red y debe satisfacer las neco
Se {JIJede argumentar
que uno aplicacin
tradicional dentro de
wolquiero de los
dominios de software
trotodos en el captulo
1puede mostrar esto
listo de atributos. Sin
embargo, los
WebApps casi siemp1e
/o hacen.
dades de una variada comunidad de clientes. Una WebApp puede residir en la lnk.
net (y, en consecuencia, permitir una comunicacin mundial abierta). Altemati ~
mente, una aplicacin puede colocarse en una Intranet (lo que implementa la corr
nicacin en una organizacin) o en una Extranet (comunicacin inter-red).
Concurrencia. Un gran nmero de usuarios puede tener acceso a la WebAPf

mismo tiempo. En muchos casos, los patrones de uso entre los usuarios finales
riarn enormemente.
Carga hnpredecible. El nmero de usuarios de la WebApp puede variar en
denes de magnitud de da con da. El lunes pueden mostrarse 100 usuarios; el m.:.:
tes pueden usar el sistema 10 000.
En el contexto de este captulo, el trmino "aplicacin Web" (WebApp) abarca todo, desde unasple pgina Web que puede ayudar al consumidor a calcular el pago de arrendamiento de un a
mvil, hasta un amplio sitio Web que proporcione servicios de viaje completos para gen~
negocios y vacacionistas. Dentro de esta categora se incluyen los sitios Web completos, la fu:nalidad especializada dentro de los sitios Web y las aplicaciones de procesamiento de informa
que residen en la Internet o en una Intranet o Extranet.
505
CAPTULO 16 INGENIERA WEB
Desempeo. Si un usuario de WebApp debe esperar demasiado (para ingresar,

para procesamiento en el lado del servidor, para formateo y despliegue en el lado del
cliente) puede decidir irse a cualquier otra parte.
Disponibilidad. Aunque la expectativa de una disponibilidad del total es poco razonable, los usuarios de las WebApps populares con frecuencia demandan acceso
sobre una base de "2417 /365". Los usuarios en Australia o Asia pueden demandar
acceso durante momentos cuando las tradicionales aplicaciones de software domstico en Norteamrica pueden estar fuera de lnea por mantenimiento.
Gobernada por los datos. La funcin primordial de muchas WebApps es usar

hipermedia para presentar contenido de texto, grficos, audio y video al usuario final. Adems, por lo general, las WebApps se utilizan para tener acceso a informacin que existe en bases de datos que originalmente no eran parte integral del ambiente basado en Web (por ejemplo, comercio electrnico o aplicaciones financieras).
Sensibilidad al contenido. La calidad y naturaleza esttica del contenido sigue

siendo un importante determinante de la calidad de una WebApp.
Evolucin continua. A diferencia del software de aplicacin convencional. que

evoluciona a lo largo de una serie de planeadas liberaciones espaciadas cronolgicamente, las aplicaciones Web evolucionan de manera continua. No es raro que algunas WebApps (especficamente, su contenido) se actualicen sobre una agenda minuto a minuto, o que el contenido sea calculado de manera independiente para cada solicitud. Algunos argumentan que la evolucin continua de las WebApps hace
que el trabajo realizado sobre ellas sea anlogo a la jardinera. Lowe [LOW99] comenta esto cuando escribe:
La ingenieria trata de adoptar un enfoque consistente y cientfico, suavizado por un con-
texto prctico especifico, para el desarrollo y comisionado de sistemas o aplicaciones. Con

frecuencia, el desarrollo de sitios Web se relaciona mucho con la creacin de una infraestructura (sembrar el jardn) y luego con "cultivar" la informacin que crece y retoa dentro de este jardin. A lo largo del tiempo, el jardn (es decir, el sitio Web) continuar
evolucionando, cambiando y creciendo. Una buena arquitectura inicial debe permitir que
este crecimiento ocurra en una forma controlada y consistente...
El cuidado continuo y la alimentacin permiten que un sitio Web crezca (en robustez e importancia). Pero, a diferencia del jardn, las aplicaciones Web deben satisfacer (y adaptarse a) las necesidades de alguien ms que el jardinero.
Inmediatez. 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 puede ser cuestin de unos cuantos 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.
506
PARTE TRES APUCAON DE LA INGENIER!A WEB
mtodos de planeacin, anlisis, diseo, implementacin y puesta a prueba que har

sido adaptados a los apretados tiempos requeridos para el desarrollo de WebApps
Se guridad. Puesto que las WebApps estn disponibles mediante el acceso a l..
red, es dificil, 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
ofrecer modos seguros de transmisin de datos, se deben implementar fuertes me
dictas de seguridad a lo largo de la infraestructura que sustenta una WebApp y den
tro de la aplicacin misma.
Esttica. 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 come
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 todas las WebApps, pero con diferentes grados de influencia.
Pero qu hay de las WebApps por ellas mismas? Qu problemas abordan? En
trabajo !Web es usual encontrar las siguientes categorlas de aplicaciones [DAR99J
Qu catego
ras de Web
Apps se encueatrat1
en el trabajo
IWeb?
Informativo: se proporciona contenido de slo lectura con navegacin y enlaces simples.
Descarga: un usuario descarga informacin del servidor apropiado.

Personalizable: el usuario personaliza el contenido segn sus necesidades es
peclficas.
Interaccin: la comunicacin entre una comunidad de usuarios ocurre por m..:dio de cuartos de charla, tableros de anuncios o mensajera instantnea.
Entrada del usuario: la entrada con base en formularios es el principal mecanismo para las necesidades de comunicacin.
Orientada a transacciones: el usuario hace una solicitud (por ejemplo, realiza

un pedido) que ejecuta la WebApp.
Orientada a servidos: 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 datos y extrae informacin.
Almacn de datos: el usuario consulta una coleccin de grandes bases de datos y extrae informacin.
Los atributos comentados en esta seccin, y las categoras de aplicacin destaca
das lineas arriba, representan importantes hechos de vida para los ingenieros wet
La clave es vivir dentro de las restricciones que imponen dichos atributos y aun
producir una WebApp exitosa.
as
CAPTIJLO 16
INGENIERA WEB
507
El desarrollo de sistemas y aplicaciones basados en Web incorpora modelos de proceso especializados, mtodos de ingenierla del software adaptados a las caractersticas del desarrollo de WebApps y un conjunto de importantes tecnologas habilitadoras. Los procesos, mtodos y tecnologas (herramientas) proporcionan un enfoque
en estratos de la IWeb que es conceptualmente idntico a los estratos de la ingeniera del software descritos en la figura 2.1.
"lo illflllerlo Web trato con enfoques disciplinados y sistemticos paro el desorrollb, de$plil!9.0ty$l!Jlenillliento de
liis 5Sftll10$ yplicoc:ioncs bosados en Web."
' :
16.2.1 Proceso
rr.pre es incre-
Sin embargo,
'118 el modelo
;xJede elegirse
_moyotfo de los
":15 de inge.veb.
Los modelos de procesos !Web (que se tratan con detalle en la seccin 16.3) adoptan la filosofa del desarrollo gil (captulo 4). El desarrollo gil enfatiza un enfoque
de desarrollo riguroso que incorpora rpidos ciclos de desarrollo. Aoyama [AOY98J
describe la motivacin para el enfoque gil en la siguiente forma:
Internet cambi la prioridad principal del desarrollo de software de qu a cundo. El reducido tiempo para el mercado se ha convertido en el limite competitivo por el que luchan
las compaas lderes. En consecuencia, reducir el ciclo de desarrollo es ahora una de las
misiones ms importantes de la ingeniera del software.
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 iniciar un enfoque organizado de prueba. Sin embargo, dichas actividades del marco
de trabajo se deben definir dentro de un proceso que 1) adopte 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 sistemas que utilicen pequeos equipos de desarrollo, y 4) subraye el desarrollo evolutivo o incremental mediante el uso
de cortos ciclos de desarrollo [MCDO I J.
16.2.2 Mtodos
El panorama de los mtodos de !Web abarca un conjunto de labores tcnicas que
permiten al ingeniero Web comprender, caracterizar y luego construir una WebApp
de alta calidad. Los mtodos de !Web (que se tratan con detalle en los captulos 18
al 20) se pueden categorizar de la siguiente manera:
Mtodos de comunicacin: 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 durante la recoleccin de requisitos y siempre que
sea evaluado un incremento en la WebApp.
508
PARTE TRES
Es importante notar
que muchos mtodos
/Web se han adoptado
directamente de sus
contrapartes de ingeniera del software.
Otros estn en sus
etopos formativas.
Algunos de estas
sobrevivirn; otros
sern descartados
conforme se sugieran
mejores enfoques.
Mtodos de anlisis de requisitos: proporcionan una base para comprende

el contenido que entregar una WebApp, la funcin que proporcionar al usuario f.nal y los modos de interaccin que cada clase de usuario requerir mientras ocurr:.
la navegacin por medio de la WebApp.
Mtodos de diseo: abarcan una serie de tcnicas de diseo que abordan e.
contenido, la aplicacin y la arquitectura de informacin, as como el diseo de ir
terfase y la estructura de navegacin de la WebApp.
Mtodos de prueba: incorporan revisiones tcnicas formales -tanto del conte
nido y el modelo de diseo como de una amplia variedad de tcnicas de prueba qi...
abordan conflictos al nivel de componente y arquitectnicos-, pruebas de la na\e
gacin, pruebas de facilidad de uso, pruebas de seguridad y pruebas de configuracicr
Es importante sealar que, aunque los mtodos !Web adoptan muchos de los m...
mos conceptos y principios subyacentes a los mtodos de ingeniera del softwa.;
descritos en la parte 2 de este libro, los mecanismos de anlisis, diseo y prueba de
ben adaptarse para acomodar las caractersticas especiales de las WebApps.
Adems de los mtodos tcnicos que se han subrayado, es esencial una serie ..
actividades sombrilla (con mtodos asociados) para la ingeniera Web exitosa. .s_
incluye tcnicas de gestin de proyecto (por ejemplo, estimacin, calendarizacir
anlisis de riesgo), tcnicas de gestin de configuracin de software y de revisin
16.2.3 Herramientas y tecnologa
tHPH:iiii:'1
Seenwentran
txcelentes rerucsos
poro tecnologio IWeb
en webdeveloptr.
,om yen www.
eborwin.wm/
webni!lkfl',
A lo largo de la dcada pasada ha evolucionado un amplio conjunto de herramier

tas y tecnologa conforme las WebApps se han vuelto ms complejas y extendida:.
Dichas tecnologas abarcan un amplio conjunto de descripcin de contenido y ler
guajes de modelacin (por ejemplo, HTML, VRML, XML), lenguajes de programaciC'"
(por ejemplo, Java), recursos de desarrollo basados en componentes (por ejempl
CORBA, COM, Activex, .NET). navegadores, herramientas multimedia, herramien~
de autora de sitio, herramientas de conectividad de bases de datos, herramientas e!
seguridad, servidores y utilidades de servidor, y herramientas de administracin
anlisis de sitio.
Un tratamiento completo de las herramientas y tecnologa para la ingeniera Wr:.
est ms all del mbito de este libro. El lector interesado puede visitar uno o ma..
de los siguientes sitios Web: Web Deve/oper's Virtual Encyclopedia (www.wdlv.corr
WebDeveloper (www.webdeveloper.com), Developer Shed (www.devshed.com), We
knowhow.net (www.webknowhow.net) o WebReference (www.webreference.com).
16.3 , EL J>BQQSA pE . JNGJlfJIBIA WB

Los atributos de los sistemas y aplicaciones basados en Web tienen una profunda ir
fluencia sobre el proceso de !Web que se elija. En el captulo 3 se hizo notar que l..
ingeniero de software elige un modelo de proceso basado en los atributos del sol
CAPiTuLO 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 comercio electrnico) puede elegirse un modelo de proceso incremental (captulo 3) .
El desarrollo Web es un adolescente... al igual que lomayora de los adolescentes, quiere ser ceptado como lln
adulto ~fo,me intenta alejarse de sus podres. Si quiere alcanzar todo su potencial, debe tomor unas wonkls lecdl>lle$ del ms experimentado mundo del desarrollode software.*
D0119 Walloc ,tal.
La intensa naturaleza de las aplicaciones de la red en este dominio sugiere una
diversa poblacin de usuarios (que, por lo tanto, realizan demandas especiales acerca de respuesta y modelado de requisitos) y una arquitectura de aplicacin que puede 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 paralelas dentro del proceso IWeb e involucren un equipo de personal tanto tcnico como lego (por ejemplo, publicistas, diseadores grficos).
16.3.1 Definicin del marco de trabajo

Cualquiera de los modelos de proceso gil (por ejemplo, Programacin Extrema, Desarrollo de Software Adaptativo, SCRUM) presentados en el capitulo 4 se pueden
aplicar de manera exitosa como un proceso IWeb. El marco de trabajo del proceso
que se presenta aqu es una amalgama de los principios e ideas tratados en dicho
captulo.
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 realizarse, la informacin que se recolecte y cree, y los mtodos empleados para producir un
producto de alta calidad deben estar adaptados a la gente 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 !Web se debe reconocer que:
1.
Las WebApps con frecuencia se entregan de manera incremental. Esto es, las actividades del marco de trabajo ocurrirn de manera repetida conforme cada
incremento se someta a ingeniera y se entregue.
2 . Los cambios ocurrirnjiecuentemente. Estos cambios pueden ocurrir como resultado de la evaluacin de un incremento entregado o como consecuencia
de cambiar las condiciones de los negocios.
510
PARTE TRES
APUCACIN DE LA INGENIERA WEB
3. Los plazos son cortos. Esto aminora la creacin y revisin de voluminosa documentacin de ingeniera, pero no excluye la simple realidad de que el an1sis crtico, el diseo y la prueba deben registrarse en alguna forma.
Adems, se deben aplicar los principios definidos como parte del "Manifiesto para e
desarrollo de software gil" (captulo 4). Sin embargo, los principios no son los die..
mandamientos. A veces es razonable adoptar el espritu de dichos principios sin (lU;.
sea necesario atenerse a la letra del manifiesto.
Con estos conflictos en mente se aborda el proceso de lWeb dentro del proces
genrico de marco de trabajo presentado en el captulo 2.
01
'~
cihvE
El modelo de proceso
genrico (inlToducido
en el copltulo 2) es
aplicable olo
ingeniera Web.
Comunicacin con el cliente. Dentro del proceso !Web la comunicacin con _

cliente se caracteriza por medio de dos grandes tareas: el anlisis del negocio )
formulacin. El anlisis del negocio define el contexto empresarial-organizativo pa:
la WebApp. Adems, se identifican los participantes, se predicen los potencia!.
cambios en el ambiente o los requisitos del negocio, y se define la integracin en:::
la WebApp y otras aplicaciones de negocios. bases de datos y funciones. La Jorrr
]acin es una actividad de recopilacin de requisitos que involucra a todos los pa:cipantes. El intento es describir el problema que la WebApp habr de resolver (ju:con los requisitos bsicos para la WebApp) con el aprovechamiento de la mejor
formacin disponible. Adems, se intenta identificar reas de incertidumbre y de
de ocurrirn cambios potenciales.
Planeacin. Se crea el plan del proyecto para el incremento de la WebApp :

plan consiste de una definicin de tareas y un calendario de plazos respecto al riodo (usualmente medido en semanas) proyectado para el desarrollo del increme
to de la WebApp.
Modelado. Las labores convencionales de anlisis y diseo de ingenieria

software se adaptan al desarrollo de la WebApp, se mezclan y luego se funden er
actividad de modelado IWeb (cap[tulos 18 y 19). El intento es desarrollar anlisis pidos" y modelos de diseo que definan requisitos y al mismo tiempo represen
una WebApp que los satisfar.
Construccin. Las herramientas y la tecnologa IWeb se aplican para construi:

WebApp que se ha modelado. Una vez que se construye el incremento de Web\""
se dirige una serie de pruebas rpidas para asegurar que se descubran los errores
el diseo (es decir: contenido. arquitectura, interfase. navegacin). Pruebas ade
nales abordan otras caractersticas WebApp.
Despliegue. La WebApp se configura para su ambiente operativo, se entreg:
los usuarios finales y luego comienza un periodo de evaluacin. La retroalimer
cin acerca de la evaluacin se presenta al equipo de lWeb y el incremento se C'
difica conforme se requiera.
Estas cinco actividades del marco de trabajo !Web se aplican empleando un
de proceso incremental. como se muestra en la figura 16.1.
511
Pruebo de oceplo<:in
Uso del consumidor
Evoluocin del consumidor
Pion de ilerocin
Iteracin
Mode o de diseo
Contenido
Arquilectvro
Navegacin
lnlerfoz
Funcin
Configurocin
Ingeniera Web: preguntas bsicas

Lo ingeniera de cualquier producto involucro sutique no advierten inmediatamente quienes carecen de
cio sustancial. los caractersticos de los WebApps
..-zen o los ingenieros Web o responder uno diversidad
:,reguntas que deben abordarse durante las primeros
z- . dodes del morco de trobojo. Los preguntas estrotgi
_ relacionados con las necesidades del negocio y los
etrvos del producto, se trotan durante lo formulacin .
_. preguntas acerco de los requisitos, relacionados con
caractersticos y funciones, deben considerarse durante
e onlisis de modelado. Los preguntas especficos de dise
base, relacionadas con lo arquitectura de lo WebApp,
caractersticos de lo interfaz y los conflictos de navego
:xin se consideran conforme evoluciono el modelo de di
..-o. Finalmente, un conjunto de conflictos humanos,
::eoc:ionodos con lo formo en lo que un usuario realmente
:nerocto con lo WebApp, se abordan en formo continuo.
Suson Weinshenk [WEI02] sugiere un conjunto de pregun
u que se deben considerar conforme progresan el anlisis y el

2Eo. Aqu se anota un pequeo subconjunlo (odoptodo):
2Cun importante es lo pgina de inicio (home page)

de un sitio Web? Debe contener informacin til o uno
simple listo de enloces que conduzcan al usuario o mo
yores detalles en niveles inferiores?
Cu61 es lo plantillo de pgina ms efectivo (por ejem
plo, men arribo, o lo derecho, o lo izquierdo) y sto
vorior segn el tipo de WebApp que se desarrollar?
Qu opciones de medios audiovisuales tienen ms im

pacto? los gr6ficos son ms efectivos que el texto? El
video (o el audio) es uno opcin efectivo? Cundo se
deben elegir varios opciones de medios audiovisuales?
Cunto trabajo se puede esperar que realice un usuo
rio cuando busco informacin? Cuntos clics deseo ha
cer lo gente?
Cu6n importantes son los auxiliares de navegacin
cuando los WebApps son complejos?
Cun complejos pueden ser los entrados de formulario
antes de que se vuelvan irritantes poro el usuario? C
mo se pueden expedir los entrados de formulario?
Cun importantes son los capacidades de bsqueda?
Qu porcentaje de usuarios navego y qu porcentaje
uso bsquedas especficos? Cun importante es estruc
turar codo pgina en uno Forma que supongo un enloce
desde alguno fuente externo?
Lo WebApp se diseor en uno formo que seo accesible o quienes tengan discopocidodes fsicos o de algn
otro tipo?
No existen respuestos absolutos o preguntas como stos, e
induSO<Ninguno> deben abordarse conforme avance lo
IWeb. En los captulos 17 al 20 se consideror6n respuestos
po1enc!Oles.
512
PARTE TRES APLICACIN DE LA !NGENIER!A WEB
16.3.2 Refinamiento del marco de trabajo

Ya se ha advertido que el modelo del proceso !Web debe ser adaptable. Esto es, la
definicin de las tareas de ingeniera requeridas para refinar cada actividad del marco de trabajo se dejan a discrecional juicio del equipo de ingenieria Web. En algunos
casos, una actividad del marco de trabajo se dirige de manera informal; en otros, se
definir una serie de distintas tareas y las dirigirn miembros del equipo. En todo caso, el equipo es responsable de producir un incremento WebApp de alta calidad dentro del periodo acordado.
Es importante destacar que las tareas asociadas con las actividades del marco de
trabajo !Web pueden modificarse, eliminarse o extenderse con base en las caractersticas del problema, el producto, el proyecto y la gente en el equipo de ingeniera Web
~ illgun05 41, ROSC>lr0$ que-aten que los mejores prcticas poro el ilesatrollo d softwart SOll prdlaas y-.
CiA inlphimenttcKtn~Ykil!!lO liltisten algunos de nosotros que creen que las mejores prdkas SOi intefesalltetaw-
fa,~ . _, mosn> lo son poro el mundo real, muchos grados."
Todo desarrollador de WebApp utilizar el marco de trabajo y el conjunto de tarea

del proceso !Web definido en la seccin 16.3? Probablemente no. En ocasiones, 1
equipos de ingeniera Web estn sometidos a enorme presin respecto del tiempc
tratarn de tomar atajos (incluso si stos son imprudentes e implican ms esfuerzde desarrollo, en Jugar de menos). Pero se debe aplicar un conjunto fundamental
mejores prcticas -adoptado de las prcticas de ingeniera del software tratadas
lo largo de la Parte 2 de este libr~ si se han de construir WebApps con calidad Ldustrial.
Asegrese de que
rlJuie, hoya enunodo
con daridod los necesidades del negocio

po 1X10 WebApp. Si
es as, el (J(Oyecto
IWrb est en
1.15P).
l. Tomar tiempo para entender las necesidades del negocio y los objetivos del producto, incluso si los detalles de la WebApp son vagos. Muchos desarrolladores
de WebApps creen errneamente que los requisitos vagos (que son bastante
comunes) los liberan de la necesidad de asegurarse de que el sistema que estn a punto de someter a ingenieria tenga un propsito empresarial legtimo
El resultado final es (tambin con frecuencia) un buen trabajo tcnico que ccr
duce a la construccin del sistema equivocado por las razones equivocadas
para el pblico equivocado. Si los accionistas no pueden enunciar una neces
dad empresarial para la WebApp, debe procederse con extrema precaucin. s
los accionistas luchan por identificar un conjunto de objetivos claros para el
producto (WebApp), no debe procederse mientras ellos no concluyan.
2. Describir cmo interactuarn los usuarios con la WebApp aplicando un enfoquc
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 actores interactuarn con la WebApp. Entonces se pueden apro-
513
vechar dichos escenarios 1) para la planeacin y el rastreo del proyecto, 2) para guiar el anlisis y el modelado del diseo, y 3). como una entrada importante 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 participantes. 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 algn tiempo para modelar Jo que se construir. Por lo general, el anlisis total y los modelos de diseo no se desarrollan durante la ingeniera Web.
Sin embargo, la clase UML y los diagramas de secuencia, junto con otra notacin UML seleccionada (por ejemplo, diagramas de estado), pueden proporcionar una visin invaluable.
5. Revisar la consistencia y calidad de los modelos. Las revisiones tcnicas formales (capitulo 26) se deben dirigir a lo largo del proyecto IWeb. El tiempo empleado en las revisiones paga importantes dividendos porque usualmente
elimina reelaboraciones y resulta en una WebApp que exhibe alta calidad, lo
que aumenta la satisfaccin del cliente.
6. Utilizar herramientas y tecnologa que pennitan construir el sistema con tantos

componentes reutilizables como sea posible. Un amplio conjunto de herramientas WebApp estn a disposicin virtualmente para cada aspecto de la construccin WebApp. Muchas de dichas herramientas permiten que un ingeniero
Web construya porciones significativas de la aplicacin empleando componentes reutilizables.
7. No apoyarse en usuarios anteriores para depurar la WebApp; disense pruebas

amplias y ejectense antes de liberar el sistema. Los usuarios 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 plazos se
deben prolongar.
Criterios de calidad/ directrices para WebApps

Lo IWeb se esfuerzo en lo produccin de
~ de alto calidad. Pero, en este contexto, qu es
dad y qu directrices estn disponibles poro lograrlo?

s., artculo acerco de aseguramiento de lo calidad en si
Web, Quibeldey-Cirkel [QUI01 Jsugiere un amplio
unto de recursos en lnea que abordan estos conflictos:
W3C: guo de estilo paro hipertexto en lnea

www.w3.org/Provider/Style
Lo Guo Sevlod paro el diseo Web
www.WN.corn.au/wehzone/design/guide.osp
Pginas Web que Apeslan
wwwwebpogeslhatsud.com/index.html
514
PARTE TRES
APLICACTN DE LA INGENIERA WEB
Recursos acerca de estilo Web

www.westegg.com/ unmaintained/bodpages
Herramienta de evaluacin Web de Gortner
www.garlner.com/ebusiness/websile-ings
/BM Corp: directrices Web
www-3 .ibm.com/ibm/easy/ eou_exl.nsf/Publish/572
Facilidad de uso en la World Wide Web
ijhcs.open.oc.uk
Interfaz Saln de la Vergenza
www.iarchitect.com/ mshame. htm
El arte y el zen de los sitios Web
www.tlc-systems.com/webtips.shtml
Diseo para la Web: estudios empricos
www.microsoft.com/usobility/webconf.htm
useit.com de Nielsen
www.useit.com
Calidad de experiencia
www.qualityofexperience.org
Creacin de sitios Web asesinos
www.killersites.com/core.html
Todas los cosos en lo Web
www.pontos.org/atw
Nuevo diseo Web de SUN
www.sun.com/980113/ sunonnel
Tognazzini, Bruce: homepage
www.asktog.com
Webmonkey
hotwired .lycos.com/webmonkey/ design/?tw=design
Los meores sitios Web del mundo
www.worldbestwebsites.com
Ya/e University: gua de estilo Web de Yo/e
info.med.yale.edu/caim/manual
Es posible argumentar que el impacto de los sistemas y aplicaciones basados en We

es el suceso ms significativo en la historia de la computacin. Conforme la imp<Ytancia de las WebApps crece ha comenzado a evolucionar un enfoque IWeb disciPnado (adaptado de los principios, conceptos, procesos y mtodos de la ingeniera d.:
software).
Las WebApps son diferentes de otras categoras de software informtico; son em
nentemente de red, las gobiernan los datos y se encuentran en evolucin continuz
La inmediatez que dirige su desarrollo, la necesidad apremiante de seguridad en s
operacin y la demanda de esttica, asi como la entrega de contenido funcional, sofactores diferenciales adicionales. Al igual que otros tipos de software, las WebAPfpueden valorarse mediante una diversidad de criterios de calidad que incluyen fac
lidad de uso, funcionalidad, confiabilidad, eficiencia, capacidad de mantenimientn
seguridad, disponibilidad, escalabilidad y tiempo para comercializacin.
La JWeb se describe en tres estratos: proceso, mtodos y herramientas/tecnok.
gia. El proceso !Web adopta el enfoque de desarrollo gil que subraya un punto d .
vista de ingeniera "magro", riguroso, que conduce a la entrega incremental del sis
tema que ser construido. El proceso genrico del marco de trabajo -comunicacix"
planeacin, modelado, construccin y despliegue- es aplicable a la !Web. Dicha.
actividades del marco de trabajo se refinan en un conjunto de tareas IWeb que
s.:
adaptan a las necesidades de cada proyecto. A todos los proyectos IWeb se les ap
ca un conjunto de actividades sombrilla similar al aplicado durante el trabajo de ugeniera del software: SQA, SCM, gestin del proyecto.
CAPTULO 16
INGENIERA WEB
515
[AOY98] Aoyama, M., ''Web-Based Agile Software Development", en IEEE Computer, noviembrediciembre, 1998, pp. 56-65.
[DAR99J Dart, s., "Containing the Web Crisis Using Configuration Management", en Proc. First
ICSE Workshop on Web Engineering, ACM, Los Angeles, mayo de 1999. (The Proceedings ofthe
First ICSE Workshop on Web Enginee1ing se publican en lnea en http:/ /fistserv.macarthur.
uws.edu.au/san/icse99-WebE/ICSE99-WebE-Proc/default.htm).
[FOWOJJ Fowler, M. y J. Highsmith, "The Agile Manifesto", en Software Development Magazine.
agosto de 2001, http://www.sdmagazine.com/documents/s=844/sdm0J 08a/Ol 08a.htm.
[MCDOIJ McDonald, A. y R. Welland. Agile Web Engineering (AWE) Process. Department of Computer Science, University of Glasgow, Technical Report TR-2001-98, 2001, se puede descargar desde http://www.dcs.gla.ac.uk/-andrew/TR-2001-98.pdf.
[MUR99J Murugesan, S., WebE Home Page, http://fistserv.macarthur.uws.edu.au/san/WebEHome, julio de 1999.
[NOR99J Norton, K., "Applying Cross Functional Evolutionary Methodologies to Web Development", en Proc. Firsc !CSE Workshop on Web Engineering, ACM, Los ngeles, mayo de 1999.
[POW981 Powell, T. A., Web Ste Engineering, Prentice-Hall, 1998.
[PRE98J Pressman, R. S. (moderador), "Can lnternet-Based Applications Be Engineered?", IEEE
Software, septiembre de 1998, pp. l 04- 11 O.
[QUIOIJ Quibeldey-Cirkel, K., "Checklist for Web Site Quality Assurance", en Quality Week Europe, 200 l, se puede descargar desde www.lbi.fh-darmstadt.de/-quibeldey/Projekte/QWE2001 /Paper_Quibeldey_Cirkel.pdf.
[WEI02J Weinschenk, s.. "Psychology and the Web: Designing for People", 2002, http://www.weinschenk.com/learn/facts.asp.
16.1 Existen otros atributos genricos que diferencien a las WebApps de las aplicaciones de
software ms convencionales? Jntntese mencionar dos o tres.
16.2 Cmo juzga el lector la "calidad" de un sitio Web? Hgase una lista, en orden descendente de prioridad, de l O atributos de calidad que consideren los ms importantes.
16.3 Realizar un poco de investigacin y escribir un artculo de dos a tres pginas que resuma
una de las tecnologias anotadas en la seccin 16.2.3.
16.4 Empleando un sitio Web real como ejemplo, ilustrar las diferentes manifestaciones del
"contenido" de la WebApp.
16.5 Revisar los procesos de ingeniera del soltware descritos en los captulos .3 y 4. Existe(n)
algn(os) otro(s) proceso(s) -distinto(s) al modelo de proceso gil- que pueda(n) ser aplicable(s)
a la ingeniera Web? Si la respuesta es afirmativa, indicar cul(es) proceso(s) y por qu.
16.6 Revisar la exposicin del "Manifiesto para desarrollo de software gil" presentado en el
captulo 4. Cul de los 12 principios funcionara bien para un proyecto de dos aos (que involucra a docenas de personas) que construir un gran sistema de comercio electrnico para una
compaa automotriz? Cul de los 12 principios funcionara bien para un proyecto de dos meses que construir un sitio informativo para una pequea firma de bienes races?
16. 7 Elaborar una lista de "riesgos" que serian probables durante el desarrollo de una nueva
aplicacin de comercio electrnico que se disea para \'ender telfonos celulares y servicios directamente por medio de la Web.
516
PARTE TRES APLICACIN DE LA INGENIERA WEB
En aos recientes se han publicado cientos de libros que analizan uno o ms lemas de ingenie
ra Web, aunque relativamente pocos abordan todos los aspectos de la IWeb. Saruk.kai (Foundc
tions of Web Technology, Kluwar Academk Publishers, 2002) presenta una valiosa compilacir
de tecnologas que se requieren para la IWeb. Murugusan y Deshpande (Web Engineering: Me
naging Diversity and Complexity of Web Development, Springer-Verlag, 2001) han editado una ce
leccin de tiles articulas acerca de IWeb. Las actas de conferencias internacionales acerca ck
ingeniera Web y de ingeniera de sistemas de informacin Web las publica anualmente el lE.EI
Computer Society Press.
Flor (Web Business Engineering, Addison-Wesley, 2000) analiza el anlisis de negocios y
preocupaciones relacionadas que permiten al ingeniero Web comprender mejor las necesidade.
de los clientes. Bean (Engineering Global E-commerce Sites, Morgan Kaufman, 2003) presenta c.
reclrices para el desarrollo de WebApps globales. Lowe y Hall (Hypermedia and the Web: An E.
gineering Approach, Wiley, 1999) y Powell [POW98] ofrecen una cobertura razonablemente corpleta. u mar (Application Re-engineering: Building Web-Based Applications and Dealing with Leg<:Systems, Prentice-Hall, J997) aborda uno de los ms dificiles conflictos en la !Web: la reingen ~
ra de los sistemas heredados para hacerlos compatibles con los sistemas basados en Web. ~
Std. 2001-1999 define prcticas bsicas de JWeb.
EJ Internet hay disponible una gran variedad de fuentes de informacin acerca de ingen
ra Web. En el sitio Web de SEPA se puede encontrar una lista actualizada de referencias er
World Wide Web que son relevantes para la ingeniera Web:
http:// www.mhhe.com/pressman.
,,.
FORMULACIN Y PLANEACIN'
PARA INGENIERA WEB
urante.la tempestuosa dcada de 1990, el boom dela Internet gener ms
arrogancia que cualquier otro evento en la historia de las comput~d-Oras.
Los desarrolladores de WebApps en cientos de jvenes compaas punto-
.... .520
... . . .S36
...539
com argumentaban que habia surgido un nuevo paradigma para el de$arrollo de

software, que las Viejas reglas ya no se apli<;:aran ms. que el tiempo para el mercado dominaba todas las dems preocupaciones. Se rieron de la nocin de gue la
formula<;in y la planeacin cudadosas deban ocurrir antes de que comenzara
la construccin. Y quin poda rebatirlos? El dinero estaba en todas partes, los
jvenes de 24 a,s se volvieron multimillonaro.s (al menos en el papel}; til v~z
las cosas re~lmente hablan cambiado. Y entonces el suelo se vino abajo.
Conforme comenzaba el sglo xx1 empez a ser dolorosamente.evidente que
un enfoque de "constryelo y ellos vendrn" simplemente no funci<>naba, que la
formulacin del problema es esencial para garant1zar que una WebApp en ver~
di1d es necesatia, y que la planeacin vale el esfuerzo aun c\,lando el calendario
de desarrollo sea i!pretado. Constantine y Lckwood [CON021 advierten esta
situacin c1.1ando escriben:
A pesar de las dedaraciones radicales de que Ja wep representa un nuevo paradigma
definido por reglas nuevas, los desarrolladores profesionales se estn dando cuenta
de que las lecciones acerca del desarrollo de sot\ware, 1preMidas en los das ptellios
al Jnternet, todava se aplican. Las pginas Web son interfaces de usuario, taprogramaci611 HTML es programa<;in, y las aplicaciones desplegadas en el .navegador son
Qstemas de software que pueden benelidarse de les prittcipios bsicos de la ingenie
ra del software.
Entre los principios fundamentales de la ingeniera de software destaca el de:
comprender el problema antes de comenzar a resolverlo, y estar seguro de que la

soludn concebida es aquella que la gente realmente quiere. Esta es la base de la
formulacin. la primera gran actividad en la ingeniera Web. Otro principi fundamentaj de la Ingeniera de software es: planear el trapajo antes de comenzar a
realizarlo. Este es el enfoque que subyace a la planeadn de proyectos.
,ddad se conozco qu $e 11ecesito nacer.

Ambos en6oques son inapropiados y por dio k!s
des pnmero! actividades del morco de'iirnbaja
ingameno Web destacan lo formvlOGiny

planeacin Lo formulacin voforq lc:1 J:le<:est,.
~
de lo WebApp, las cc:aroder!ti'-:iones globales que desean los U$UCl\0$
518
17:l
.,
~~
C~VE
ln~enfoco
el sr:z ami>":
mIWP5ibles,
cqell'OS del pgocio
y~ iioo:mill
relocioncxlo.
foBMRLJ;t;J6H PI $1$%BMM 14$AP9$ lff Wa

La formulacin de sistemas y aplicaciones basados en Web representa una secuercia de acciones de ingeniera Web que comienza con la identificacin de las necesidades del negocio, se mueve hacia una descripcin de los objetivos de la WebApp
define grandes caractersticas y funciones y realiza la recopilacin de requisitos qul
conducen al desarrollo de un modelo de anlisis. La formulacin permite que 10!.
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 exitoso. El anlisis -una actividad tcnica que es una continuacin de la formulacinidentifica 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 existe
una respuesta sencilla para esta pregunta. La formulacin se enfoca sobre el "gran
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-
CAPTULO 17 FORMULACIN Y PLANEAON PARA INGENIERA WEB
5 19
cionalidad especfica, enumerar caractersticas especficas e identificar la forma en

que los usuarios finales interactuarn con la WebApp. Esto es formulacin o recopilacin de requisitos? Ambos es la respuesta.
17.1. 1 Preguntas de formulacin

Powell [POW98] sugiere un conjunto de preguntas que deben formularse y responderse al comienzo 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 estas simples preguntas debe establecerse tan sucintamente como sea posible. Por ejemplo, supngase que el fabricante de HogarSeguro'
ha decidido establecer un sitio Web de comercio electrnico para vender sus productos directamente a los consumidores. Un enunciado que describa la motivacin
para la WebApp puede ser:
HogarSegurolnc.com permitir a los consumidores configurar y comprar todos los componentes requeridos para instalar un sistema de administracin en su hogar o empresa.
Es importante advertir que en este enunciado no se proporcionan detalles. El objetivo 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:
HogarSegurolnc.com nos permitir vender directamente a los consumidores, lo que eliminar los costos de intermediacin y mejorar los mrgenes de utilidad. Tambin nos
permitir aumentar las ventas en un proyectado 25 por ciento sobre las ventas anuales actuales y penetrar en regiones geogrficas donde en la actualidad no tenemos puntos de
venta.
Finalmente, la compaa define la demografia para la WebApp: "Los usuarios proyectados de Hogarsegurolnc.com son los propietarios de viviendas y los dueos de
pequeos negocios."
Las respuestas establecidas lneas arriba implican metas especficas para el sitio
Web de HogarSegurolnc.com. En general, se identifican dos categorias de metas
[GNA99]:
Metas informativas: indican una intencin de proporcionar contenido informacin especficos al usuario final.
Metas aplicables: indican la habilidad para realizar alguna tarea dentro de la

WebApp.
1 El producto HogarScguro ya se us como ejemplo a lo la:go de las partes I y 2 de este libro.
PARTE TRES
520
En el contexto de la WebApp HogarSegurolnc.com, una meta informativa puede ser

El sitio proporcionar a los usuarios especificaciones de producto detalladas, que incluirn descripciones tcnicas, instrucciones de instalacin e informacin de precios.
El examen de las respuestas a las preguntas planteadas puede conducir al establecimiento de una meta aplicable:
HogarSegurolnc.com consultar al usuario acerca de la instalacin (es decir: casa, oficina,
espacio de venta al menudeo) que ser protegida y realizar recomendaciones personalizadas acerca del producto y la configuracin que se utilizar.
Una vez identificadas todas las metas informativas y aplicables, se desarrolla un perfil de usuario. El perfil de usuario captura "caractersticas relevantes relacionadas
con los usuarios potenciales, que incluye sus antecedentes, escolaridad, preferencias
e incluso ms" [GNA991. En el caso de HogarSeguroinc.com, un perfil de usuario
identificara las caractersticas de un comprador tpico de sistemas de seguridad
(esta informacin la suministrara el departamento de mercadotecnia).
............
~ -hackeando [WebAppsl probablementetuenfoque es'preparen, fueqo, apunien'. Si 15*-.PilallMI

f.911 ~ ~'et.be ser 'Pfeporen, apunten, fuego'."
Una vez que se han desarrollado las metas y perfiles de usuario, la actividad de
formulacin se enfoca sobre una afirmacin del mbito para la WebApp. En muchos
casos, las metas 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 temas de conectividad se consideran en esta etapa.
17.1.2 Recopilacin de requisitos para WebApps
Los mtodos para la recopilacin de requisitos se trataron en el capitulo 7. Aunque
esta actividad puede abreviarse para la ingeniera Web, los objetivos globales de la
recopilacin de requisitos propuestos para la ingeniera de software permanecen
inalterados. Adaptados para las WebApp, dichos objetivos se convierten en:
Identificar requisitos de contenido.
Identificar requisitos funcionales.
Definir escenarios de interaccin para diferentes clases de usuarios.
a. pasos
...... ,..
Los siguientes pasos de la recopilacin de requisitos se dirigen para lograr estos

objetivos:
tle re<opilo
CII tle rtcpNSltos
1. Pedir a los clientes que definan las categoras de usuario y describan cada ca-
lmw.Af,s?
2. Comunicarse con los clientes para definir los requisitos bsicos de la WebApp.
tegora .
CAPrruLO 17 FORMULACIN Y PLANEACIN PARA INGENIERlA WEB
521
3. Analizar la informacin recopilada y utilizar la informacin para realizar un
seguimiento con los clientes.

4. Definir casos de uso (capitulo 8) que describan escenarios de interaccin para
cada clase de usuario.
Definicin de las categoras de usuario . Se puede argumentar que la complejidad de la WebApp es directamente proporcional al nmero de categorias de usuario 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 relacin con el contenido
y lafuncionalidad 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.
Cmo 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 Je 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 conjunto razonable de clases de usuario. Conforme se avanza en la recopilacin de
requisitos, cada diferente clase de usuario debe encuestarse para obtener datos.
522
PARTE TRES
APLICACIN DE LA INGENIERlA WEB
<.
~ La ger~,ba ~idi~ qe constrvyomos un

~ - ~ -,rqjcoF9ro vender HqgorSegrJr.
~,JG.ibu;-~ N tenemos ~em~ pd!d hocer
~.. ~ ~tar!Qdos ~ehrobojo de software
d~.
. . ;ir-
*' ~ lo s,
la${t :;ubtoolfg_toreln0$ el desarrollo con

, !,lcJ c:Qmpol\"1(1 ~~f~ ~ ks CQhSlt<XOll de $\tOS
~co,
" ~ li.omerdo
Ellos.tl<)s dirn que lo tendrn
listo y ~ enn'.le00$ de un mc,s,.. m\!ch0$
'r QOmponenfes reutil~.
~ ~ . B i e n... ~~ por ql.lestoy oqul

DoU9# Part1 facllikir ~ ~ : quieren que ~oi
, ~ de b req,f)ilocin de requisitos poro el
SUIC).~ que le enlrevistM QOll 10$ diver1< diente$
p a r o ~ ~Si!Q e!'I formo mnimo, los
requisitos bc$sicJ,
Vltl ( Q ~ ) t Ooug,,. no me $ls
~ ,.. esto~ opretodoJ de tlemp y estQ...
.....~ ) ; Solo dale un da de to tiemx;,
Vincd. ~ o:>n los tipos de mrc~nio y
~ que especifiquen el contenido bsico, lo furich;
16 SM, el procedimiento usual.
,,
VltMicl {realgnodoJ: Est bien, Los 1kmor y . '' '

cxwaC91 tat algo parQ maoona, Fl'" no 'me ffrtas lo
vicia.
Dout (aonrie)! P-Ot'8$0 le l~s.~s'b{le 9ron~$.

Yinod: Cierto. .
Vind (ve o la f*'SCHIClde mercdII - ~

Dijiste que c_uero~ gulor a los uwarios o fNMkdl
PfOC~. eA}gn ~o.qiA especiotJ
.
Persona,Cle m ~ n i a -2: Guisn wtt:Uh
proceso poso o fld~, con e$f>OQQ$ en blonco ~
fesponder pr~llntos de ,requiJill;n bsicoJ. ~
tlespl~obles; es& tipo dE! co$Cls. Cado pm es uno
v~ntono:, y t0$ dom el, cod<,<Vet!tcmct $8 volldan . . . de
lllQVrse pi Pi~ si9\Jien"'.
Vmoch Has ~prolx;ido e$C> coo U$uorlos

repre$8rll(J1iY0S~
Persona .de m~bknia #2: No, pw-hcri

Viood: Uno tow rrys. e, acmo en<iOlltroro l'\Udro.sitio
un usuario'?
,.......,.. *rMNCl:lotecnkt 11:Comodie,
p a l ~ ,-,e el ~ Q * I ~ de personalizar
todoeisistltna ~ - T ~s: escpger

.
tenSOAII, ~ de~, corO(terMcos y func:'ion~,
h,ago-. uno ~~ta de motriole?' generodo
~ ' ~ k , cotZQ<;iq~'y tuego comprcir
o~d.ftitoW~. ,, '"
"'
. . . . . . . . . #2: s~mQ.$qv~el ,
~ & UlO (Osa 1Jf! un tc'tico, Q$
guorlo ~ ttcwi
o r;
&l proceso pd'sO
'
CAPTULO 17
FORMULACIN Y PLANEAON PARA INGENIERA WEB
523
Comunicacin con los clientes y usuarios finales. 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 nformacin recopilada slo de una o dos
personas como la base para la formulacin o el anlisis. Se deben considerar ms personas (y ms opiniones y puntos de vista).
La comunicacin se puede lograr aprovechando uno o ms de los mecanismos
siguientes [FUC02a]:
Grupo muestra/ tradicional. Un moderador entrenado se rene con un pequeo
(usualmente menos de l O 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 muestra] electrnico. Un debate electrnico moderado dirigido con un
grupo de usuarios finales y participantes representativos. El nmero de participantes puede ser mayor. Puesto que todos 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 contemporneo.
Entrevistas iterativas. Una serie de entrevistas breves, dirigida a usuarios repre-
sentativos y en la que se solicitan respuestas a preguntas especficas 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 exploracin. Encuesta basada en Web y ligada a una o ms
WebApps con usuarios similares a los que usarn la WebApp que se desarrollar. Los usuarios se enlazan a la entrevista y responden una serie de
preguntas (usualmente reciben alguna recompensa por participar).
Construccin de escenarios. A usuarios seleccionados se les pide crear casos
de uso informales que describan interacciones especficas con la WebApp.

Anlisis de la informacin recopilada. Conforme se recopila informacin se
categoriza en clase de usuario y tipo de transaccin, y Juego se valora segn su relevancia. El objetivo es desarrollar listas de objetos de contenido, operaciones que se
aplican a los objetos de contenido dentro de una transaccin de usuario especifica,
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 durante las actividades de comunicacin.
Fuccella y Pizzolato [FUC02bJ sugieren un mtodo simple (de baja tecnologa:
low-tech) para comprender cmo se deben organizar el contenido y la funcionalidad.
Se crea un paquete de "cartas" para los objetos de contenido, las operaciones aplicadas a los objetos de contenido, la funciones '..'ebApp y otros requisitos no funcio-
524
nales. Se barajan las cartas y luego se distribuyen a las personas representativas de

cada categora de usuario. se pide a los usuarios que ordenan las cartas en grupa.
que reflejan cmo les gustarla que se organizara el contenido y la funcionalidad dentro de la WebApp. Luego se solicita a los usuarios que describan cada agrupamier
to y las razones por las que son importantes para ellos. una vez que cada usuan
realiza este ejercicio, el equipo de ingeniera Web busca agrupamientos comune:o.
entre diferentes clases de usuarios y otros agrupamientos que sean nicos para un;:;
clase de usuario especfica.
El equipo IWeb desarrolla una lista de etiquetas que se usarn para apuntar
informacin dentro de cada uno de los agrupamientos derivados con el uso de los paqtk
tes de cartas. Entonces, a los diferentes usuarios representativos se les dan 1
paquetes de cartas y se les pide ubicar el contenido y la funcionalidad a cada una d.:
las etiquetas. Aqu el prposito es determinar cundo las etiquetas (enlaces dent:'
de la WebApp real) implican de manera adecuada el acceso al contenido y las fu:ciones que los usuarios esperan encontrar detrs de la etiqueta. Este paso se aplu
de manera iterativa hasta que se alcanza el consenso.
.,......
"$ lo que itskt hadendo no lo puedes describir como un proceso, entonces no sabes lo que tils haciendo.
tcoNsuoS.
En la Porte 2de este
Desarrollo de casos de uso. Los casos de uso2 describen cmo interactuar cr

la WebApp una categora de usuario especfica (llamada actor) para lograr uaccin especfica. La accin puede ser tan simple como adquirir contenido definid
o tan compleja como que el usuario realice un anlisis detallado de registros sele..
donados que se mantienen en una base de datos en lnea. Los casos de uso desaben la interaccin desde el punto de vista del usuario.
Aunque desarrollarlos y analizarlos toma tiempo, los casos de uso 1) ayudan
desarrollador a entender cmo perciben los usuarios su interaccin con la WebAp:2) proporcionan el detalle necesario para crear un modelo de anlisis efectivo
ayudan a dividir en compartimientos el trabajo de !Web; y 4) ofrecen una guia impc'
tante para quienes deben probar la WebApp.
libro se troturon con

detul/e los casos de
uso. Aunque muchos
abogan por el desarrollo de cosos de tJS()
muy lorgos, i11<IIJS()
uno norrodn informal

proporona algn
beneficio. Convenzo o
los usuarios poro que
escriban cosos de uso.
CONJUNTO DE TAREAS
a comunicactn con el cuente (Anltsts/ Formulacin)
1. Identifquense a los clientes del

negocio. tExoctomente quin es el
"cliente" de lo WebApp? Qu
ed
fu .
personas e neg~,o~ pu en nc,on~r como . ,

expertos y usuarios finales representahvos? eQu,en
f 6
b
f d1
por ,c,por como m,em ro oc 1vo e equipo.2
2. Formvlese el contexto del negocio. Cmo encojo lo

3.
WebApp en uno estrategia de negocios ms amplio~

.
Defnanse las melas y objetivos clave del negocio
poro la WebApp. Cmo se medir el xito de la

,., bA
a, .
. .
ne pp, tanto en termines evo11tahvos como
cuantitativos?
2 En los capltulos 7 y 8 se presentaron con detalle las tcnicas para desarrollar los casos de uso.
CAPTULO 17 FORMULACIN Y PLANEAON PARA INGENlERA WEB
Defnonse los metas informativos y aplicables. Qu
clase de contenido se proporcionar a los usuarios

finales? Qu funciones/toreas se lograrn cuando
se use lo WebApp?
Identifquese el problema. Qu problema especfico
resuelve lo WebApp?
525
6. Recop/ense requisitos. Qu toreas del usuctrio se

lograrn mediante el USCI de lo WebApp? Qu
contenido se desorrollor? Qu metforo de
interaccin se usor? Qu funciones
computacionales proporcionar lo WebApp? Cmo
se configurar lo WebApp poro su utilizacin en
red? Qu esquema de navegacin se desea?
17.1.3 El puente hacia el modelado de anlisis
(con la
de uno hoa
en lugar
UML Esto
todos/os
del eJl)po
los feJ/1)~
d contenido
entregada
me;o, el
. filo de
~ocurrir.
Como ya se ha sealado en este captulo, las actividades que conducen a un equipo

de ingeniera Web de la formulacin al modelado de anlisis representa un continuo.
En esencia, el grado de abstraccin considerado durante las primeras etapas 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, estos requisitos se modelan (con la utilizacin de casos de
uso y notacin UML).
Los conceptos y principios tratados para el anlisis de requisitos de software
(captulos 7 y 8) se aplican sin revisin para la actividad de anlisis de ingeniera
Web. Durante el anlisis se elabora el mbito definido durante la actividad de formulacin 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 capitulo 18 se exponen las tareas y tcnicas de
modelado asociadas con cada uno de estos anlisis.
Dada la inmediatez de las WebApps es razonable preguntar: en realidad se necesita gastar tiempo en la planeaciny administracin de un esfuerzo WebApp? No slo
se debera dejar evolucionar naturalmente a la WebApp, con poca o ninguna gestin
explicita? Ms de un desarrollador Web optara por poca o ninguna gestin, ipero
eso no hace que estn en lo correcto!
La figura 17. l presenta un cuadro adaptado de Kulik y Samuelson [KULOOJ que
indica cmo los "proyectos electrnicos" (e-projects, su trmino para los proyectos
WebApp) se comparan con los proyectos de software tradicionales. Al consultar la
figura, los proyectos de software 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 indicada 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 planea-
PARTE TRES
526
APLICACIN DE LA INGENIERiA WEB
Diferencias entre proyectos tradicionales y electrnicos (e-projects) [adaptado de KULOOJ.

P!9Cl~s proyecto.s
electrnicos
limitado
Ponoromo de~riplivo
M&ddq en mese$
Prueba l' a~u~miento Eofocodo e~ l99rar

de la alidoq
blancos de calioad
M&diada eo dfo$,
semoneis o me$es
En!O(;oda sobre control
derle~o
l:xplcito
Gestin de ~os
VidQ
inedio
De6al21'1\,eS
o m6,$ tl'to
de los enfregable
Riguroso
llet~olimentacin
Requere. esfuerzo
prooctivo
del ~liente despys

de la lib.tra<im
Expedito
Seobt1ene
autom4fi~mente <Je kl
iriterc:cl.11 con el usuario
Se obtiene tanto de
molltc aufbmltica como
p.or medio de sol1citud
de retroalimentacin
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
fracaso.
Un equipo de ingeniera Web exitoso mezcla una amplia variedad de talentos q

deben trabajar como equipo en un ambiente de proyecto con alta presin. Los p
zos son cortos, los cambios son inexorables y la tecnologa contina cambiando
creacin de un equipo que se consolide (vase el capitulo 21) no es asunto sene
en:ei 1IIUII actual,. ali,nentado por laWeb y centrado en lo red, uno necesito saber mudu, dt muchos femas.*
"'
17.3.1
Stot Tlefy ~ H...
Los actores
La creacin de una aplicacin Web exitosa demanda un amplio abanico de habi

des. Tilley y Huang [TIL99] abordan este tema cuando afirman: "Existen tantos d..
rentes aspectos del software de aplicacin [a la Web} que se ha dado el (re)surgime-
del renacentista, aquel que se siente cmodo trabajando en varias disciplinas

Aunque los autores estn en lo correcto, los "renacentistas" son relativame
pocos, y dadas las demandas asociadas con los grandes proyectos de desarrolle
WebApps, el conjunto de diversas habilidades requeridas puede ser mejor distr:
do entre un equipo de ingeniera Web.
Los equipos de ingeniera Web se pueden organizar, en gran medida, en la mi!
forma que los equipos de software tradicionales (captulo 21). Sin embargo, los a.:'
CAPTULO 17
FORMULACIN Y PLA.NEAON PARA INGENIERA WEB
527
res y sus papeles usualmente son bastante diferentes. Entre las muchas habilidades
que se deben distribuir entre los miembros del equipo !Web se encuentran: ingeniera del software basada en componentes. realizacin de redes, diseo arquitectnico y de navegacin, lenguajes/estndares de Internet, diseo de interfase humana,
diseo grfico, disposicin del contenido y pruebas de las webApps.
Los siguientes papeles3 se deben distribuir entre los miembros del equipo !Web:
Desarrolladores/ proveedores de contenido. Dado que el contenido controla inherentemente las WebApps, una funcin del equipo !Web se debe enfocar en la
generacin o recopilacin del contenido. Recurdese que el contenido abarca un
amplio abanico de objeto,s' de datos, por ello los desarrolladores/proveedores de
contenido pueden provenir de diversos mbitos (no de software).
Editores de web. El variado contenido que generan los respectivos desarrolladores/ 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 desarrolladores/proveedores de contenido sin conocimientos tcnicos. Este papel lo
satisface el editor de Web, quien debe entender tanto el contenido como la tecnologa de la WebApp.
Ingeniero Web. El ingeniero Web se involucra en un amplio rango de actividades durante el desarrollo de una WebApp, que incluyen la obtencin de requisitos, el
modelado 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 componentes, de las arquitecturas
cliente/servidor, de HTML/XML y de tecnologas de bases de datos, y un conocimiento prctico de los conceptos multimedia. de las plataformas hardware/software, de la seguridad de redes y de cuestiones de apoyo a sitios Web.
Expertos en dominios empresariales. Un experto en dominio empresarial
debe ser capaz de responder todas las preguntas relacionadas con metas, objetivos
y requisitos empresariales relacionados con la WebApp.
Especialista de soporte. Este papel se asigna a la persona (personas) que es
(son) responsable(s) del apoyo continuo a la WebApp. Puesto que las WebApps evolucionan continuamente, el especialista de soporte es responsable de las correcciones,
adaptaciones y mejoras al sitio, que incluyen actualizaciones de contenido, implementacin de nuevos procedimientos y formas, y cambios al patrn de navegacin.
Administrador. Usualmente llamado "web master", esta persona tiene la responsabilidad de la operacin diaria de la WebApp, lo que incluye: desarrollo e implementacin de polticas para la operacin de la WebApp, establecimiento de procedimientos de soporte y retroalimentacin, implementacin de seguridad y derechos de
acceso, medicin y anlisis de trfico del sitio Web coordinacin de los procedimientos de control de cambios (captulo 27) y coordinacin con el especialista de
3
Estos papeles se han adaptado de Hansen y sus colegas (HAN991
528
PARTE TRES
APLICAQN DE LA INGENIERA WEB
soporte. El administrador tambin puede estar involucrado en las actividades tcnicas que realizan los ingenieros Web y los especialistas de soporte.
17 .3.2 Construccin del equipo

fstus caractersticas
son usuales en los

equipos de colaboro
dores autoorganizodos
que han adoptado un
enfoque gil (captulo
4). Mientras meior
seo el equipo, mejor
ser el p,oducto de
sohwore que se
produzco.
En el captulo 21 se tratarn con cierto detalle los lineamientos para la construcci:exitosa de los equipos de ingenieria del software. Pero, estos lineamientos se apLcan 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 comp1..
tacin, Tracy Kidder [KIDOO] cuenta la historia del heroico intento de una compafde computacin por construir una computadora para enfrentar el reto de un nue,
producto que fabric un competidor ms grande. 4 La historia es una metfora del e(F
po de trabajo, del liderazgo y del aplastante estrs que todos los tecnlogos encuer
tran cuando los proyectos crticos no avanzan tan suavemente como se plane.
Un resumen del libro de Kidder dificilmente le hace justicia, pero los siguiente
puntos clave [PICOl] tienen particular relevancia cuando una organizacin constr..
ye un equipo de ingeniera Web:
se debe establecer un conjunto de directrices de equipo. Dichas direttces abarcan lo que se espera de cada persona, cmo se lidiar con los problemas
qu mecanismos existen para mejorar la efectividad del equipo conforme avanza .
proyecto.
El liderazgo fuerte es una obligacin. El lder del equipo debe guiar medite el ejemplo y el contacto. Debe mostrar un grado de entusiasmo que impulse a
otros miembros del equipo "a endosarse" psicolgicamente al trabajo que enfren
El respeto hacia los talentos individuales es crucial. Nadie es bueno .
todo. Los mejores equipos utilizan las fortalezas individuales. Los mejores lderes
equipo permiten que los individuos tengan libertad para seguir una buena idea.
Cada miembro del equipo se debe comprometer. El protagonista prina
en el libro de Kidder le llama a esto "endoso".
Es fcil comenzar, lo dificil es mantener el impetu. Los mejores equipos mr
dejan que un problema "insuperable" los detenga. Los miembros del equipo desa.llan una solucin "lo suficientemente buena" y proceden, con la esperanza de que
impetu del progreso pueda conducirlos a una solucin todava mejor en el largo pla.:.
Una vez realizada la formulacin y que se han identificado los requisitos bsicos
la WebApp, la empresa debe elegir una de dos opciones de ingeniera Web: l
WebApp es subconlratada (outsourced): la ingeniera Web la realiza un tercer prcr ~
4
El libro de Kidder, The Sou/ of a New Machine, originalmente publicado en 1981, es una leciu:-.
tamente recomendable para cualquiera que intente realizar una carrera en la computacin y~
quienes ya la tienen!
CAPTULO 17
FORMULACIN Y PLANEACIN PARA INGENIERA WEB
529
dor con experiencia, talento y recursos con los cuales no cuente la empresa; o 2) la
WebApp la desarrollan en casa ingenieros Web que sean empleados de la empresa.
Una tercera opcin (hacer algn trabajo de ingeniera Web en casa y subcontratar
otro trabajo) tambin es una posibilidad.
"(om&obsecv lbomas tlobbs en el siglo XVII, lo vida bojo los regios de los ponctdlos es slitorlo, pobre, pelig,ost,
atl8I 'f cerio. Lo vida en un PfOyecfo de softwore que corre pobremente; es solitooo, pobt&, pellgtow, (tuel y(Gil
difkvltedtlguno vei es lo sufjtjentemente corto.

El trabajo que debe realizarse sigue siendo el mismo sin importar si una WebApp
es subcontratada, desarrollada en casa o distribuida entre un proveedor externo y el
equipo de casa. No obstante, s cambian los requisitos de comunicacin, la distribucin de actividades tcnicas, el grado de interaccin entre clientes y desarrolladores,
y una diversidad de otros conflictos crucialmente importantes.
La figura 17.2 ilustra, respecto a las WebApps, la diferencia organizacional entre
subcontratacin y desarrollo en casa. ste (figura 17.2a) integra directamente todos
los miembros del equipo de ingeniera Web (el crculo punteado implica integracin).
La comunicacin se establece mediante los caminos de la organizacin. En cuanto
a la subcontratacin (figura 17.2b), es imprctico y desaconsejable que cada elemento de casa (por ejemplo, desarrolladores de contenido, accionistas, ingenieros
Web internos) tenga comunicacin directa con el subcontratista sin que exista algn
elemento de conexin para coordinar y controlar la comunicacin. En las secciones
que siguen se examinarn con ms detalle las planeaciones para la subcontratacin
y el desarrollo en casa.
a} Desarrollo en caso
bl De.arrollo subcontratodo
530
PARTE TRES APUCACIN DE LA INGENIEruA WEB
17 .4. l
No se supongo que,
puesto que se ha
subcontramdo uno
WebApp, las responsabilidades son
mnimos. Oe hecho,
es probable que se
requieron ms, no
menos, supervisin y
gestin.
Planeacin de WebApp: subcontratacin
Un porcentaje sustancial de las WebApps se subcontrata con proveedores que

(supuestamente) se especializan en el desarrollo de sistemas 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 subcontratista) se embarca en un esfuerzo por desarrollar una gran WebApp?
. . . ~ de lortune SOO hon descubierto ol software como un moclelo de semcio (subt:onb'otlldol yIS16a
l'llllratondCl "1!odelossimilores interno oexternamente.
Estas preguntas no siempre son fciles de contestar, pero vale la pena considera:
algunos lineamientos.
Inicio del proyecto. Si la subcontratacin se elegir como la estrategia para desarrollar la WebApp, la organizacin debe realizar una serie de tareas antes de
buscar una empresa subcontratista que haga el trabajo:
l . Realizar, internamente, muchas de las labores de anlisis tratadas en la seccin

17.1.3 (y en el captulo 18). Se identifica el pblico para la WebApp; se hace
una lista con los accionistas internos interesados en la WebApp; se definen y
revisan las metas globales para la WebApp; se especifican la informacin y
servicios que habr de proporcionar la WebApp; se destacan los sitios Web
competidores; y se identifican las "medidas" cualitativas y cuantitativas de
una WebApp exitosa. Esta informacin deber documentarse en una especificacin de producto que se entregar al subcontratista.
Algunos personas
argumentan que et
diseo aproximado
es innecesario. Vase
como uno primero
ofer/tJ que el
proveedor subcontrotis/tJ puede modificar
y me;orar. Al menos
est comunicando sus
ideos acerco de aqu
se debe parecer el
resu/tudo final.
2 . Desarrollar internamente un diseo aproximado de la WebApp. Obviamente, un

desarrollador Web experto crear un diseo completo, pero es posible ahorra;
tiempo y costo si la visin y el sentido general de la WebApp se identifican
para la empresa subcontratista (esto siempre puede modificarse durante las
etapas 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
procesamiento interactivo (por ejemplo, formatos. entrada de pedidos) que se
llevarn a cabo. Esta informacin deber agregarse a la especificacin del
producto.
Aunque es dificil encontrar datos industriales confiables, puede afirmarse que este porcentaje :::t
considerablemente mayor que el que se observa en el trabajo de software convencional. En el ca,~
tulo 23 se ofrece una exposicin adicional acerca de la subcontratacin.
CAPTULO 17 FORMULACIN Y PI.ANEAON PARA INGENIERA WEB
531
3. Elaborar un programa aproximado que incluya no slo las fechas finales de entrega, sino tambin fechas clave. Las fechas clave se deben adjuntar a las versiones de entrega (incrementos) de la WebApp conforme sta evolucione.
4. Crear una lista de responsabilidades para la organizacin intema y el subcontra-
tista. En esencia, esta tarea aborda qu informacin, contactos y otros recursos se requieren de ambas organizaciones.
5. Identificar el grado de supervisin e interaccin de la organizacin contratante

con el subcontratista. Esto debe incluir el nombre del contacto del vendedor y
la identificacin de las responsabilidades y autoridad del contacto, la definicin de los puntos de revisin de calidad conforme avance el desarrollo, y las
responsabilidades del subcontratista en relacin con la comunicacin entre
las organizaciones.
Toda la informacin generada durante estos pasos deber organizarse en una
solicitud de presupuesto que se entrega las empresas candidatas. 6
a varios
stas?
Seleccin entre los subcontratis tas candidatos. En los ltimos aos han surgido miles de compaas 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 !Web, pero muchas otras son poco ms
que hackers (intrusos informticos). Con la finalidad de elegir desarrolladores Web
candidatos. el contratante debe realizar algunas 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 esta persona tenga la obligacin contractual de estar involucrada
en su proyecto); y 3) examinar cuidadosamente ejemplos del trabajo del subcontratista que sean similares en apariencia y sentido (y rea de negocios) a la WebApp que
ser contratada. lncluso antes de que se ofrezca una solicitud de presupuesto, una
entrevista personal puede ofrecer un discernimiento sustancial de la "conexin"
entre el contratante y el subcontratista.
,a p o p ~, obtienes monos.
George Peppsd en el papel del <oronel John ..,Hannlal" Smith ,t1(serie televislva "- le, .._.,
Valoracin de la validez de las cotizaciones y la confiabilidad de las estimaciones. Puesto que existen relativamente pocos datos histricos y que el mbito de las WebApps es fluido en forma notoria, la estimacin es inherentemente res6
Si el trabajo de desarrollo de la WebApp Jo dirigir un grupo mtemo, no cambia nada! El proyecto

se inicia de la misma manera.
532
PARTE TRES
gosa. Por esta razn, algunos proveedores incorporarn mrgenes de seguridad sustanciales en cotizaciones para un proyecto. Esto es comprensible y apropiado. L:
pregunta no es si se ha obtenido la mejor solucin por la inversin. Ms bien, las pre
guntas deben ser:
La cotizacin de la WebApp ofrece un rendimiento sobre la inversin, direa...
o indirecto, que justifique el proyecto?

La empresa emisora de la cotizacin tiene el profesionalismo y la expe-
riencia que se requieren?

Si las respuestas a estas preguntas son afirmativas la cotizacin es justa.
Comprensin del grado de gestin del proyecto que puede esperar o reah
zar. La formalidad asociada con las labores de gestin del proyecto (que realizan
proveedor y la organizacin contratante) es directamente proporcional al tamar
costo y complejidad de la WebApp. Respecto a proyectos complejos y grandes se
necesario elaborar un programa del proyecto que defina las tareas del trabajo, .
puntos de comprobacin, el aseguramiento de la calidad del software, los product
de trabajo de ingeniera, los puntos de revisin del cliente y los hitos importantes
proveedor y el contratante tendrn que valorar el riesgo conjuntamente y elabo~
planes para mitigar, monitorear y manejar los riesgos considerados importanlf...:.
Los mecanismos para asegurar la calidad y el control de cambios se debern defi~
explcitamente por escrito. Se debern establecer mtodos para la comunicac
efectiva entre el contratante y el proveedor.
,,
&'
c&v1
En lo gestin del
mbito se congela el
trobojo que vaya o
reonzorse en un
ixremento. los
a::ibios se demoran
b::sm el 59riente
immenlo de lo
Evaluacin del programa del proyecto. Dado que los programas de desarro
de WebApps abarcan un periodo relativamente corto (por lo general menos de u:o dos meses para que se entregue el incremento), el programa para el desarro
debe tener una dosificacin muy precisa. Es decir: las tareas de trabajo y los h
menores se deben programar en un cronograma diario. Esta dosificacin prea:;
permite, tanto a la organizacin contratante como al subcontratista, reconoce:
hoja suelta de la agenda antes de que amenace la fecha de finalizacin.
Gestin del mbito. Como es enormemente probable que el mbito cambiar ce
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
mbito para un incremento, de modo que se pueda crear una liberacin operativa
la WebApp. El siguiente incremento puede abordar cambios en el mbito que ha
sugerido una revisin del incremento precedente, pero una vez que comience
segundo incremento el mbito nuevamente se "congela" de manera temporal. Es
enfoque permite que el equipo de la WebApp trabaje sin tener que acomodar tr
corriente continua de cambios, pero al mismo tiempo reconoce la evolucin cor
nua caracterstica de la mayora de las WebApps.
Los lineamientos sugeridos lneas atrs no intentan ser un recetario a prueba
tontos para la produccin a tiempo de WebApps de bajo costo. Sin embargo, ayuc..
CAPTULO 17
FOllMULACIN Y PLANEAaN PARA INGENIERiA WEB
533
rn tanto a la organizacin contratante como al subcontratista a iniciar el trabajo de

manera flexible con un mnimo de malas interpretaciones.
di, comerci ~ c a es
fa f.diodo... l trabajo
los usuorios pc!ll'$Ol)(lliCl!l'I el
Doug: Cloro.
17.4.2 Planeacin de WebApp: ingeniera Web en casa

Conforme las WebApps se vuelven ms extensas y estratgicas para los negocios,
muchas compaas han optado por controlar el desarrollo en casa. No sorprende que
la !Web en casa se gestione de manera un poco diferente a un esfuerzo de subcontratacin.
534
PARTE TRES
APLICACIN DE LA INGENIEmA WEB
La gestin de proyectos IWeb pequeos y de tamao moderado (es decir: mel""

de 3-5 meses de duracin) requiere un enfoque gil que quite el nfasis en la gestt
del proyecto pero no elimine la necesidad de planear. Todavia se aplican los pri~
pios bsicos de gestin de proyectos (capitulo 21), pero el enfoque global es m
parco y menos formal. Sin embargo, conforme crece el tamao del proyec>
WebApp, la gestin del proyecto de ingeniera Web se vuelve ms y ms como
gestin de proyectos de ingeniera del software (Parte 4 de este libro). Los pas
siguientes se recomiendan para proyectos IWeb pequeos y de tamao moderad..
Es importante
reconocer que los
posos analizados en
esta seccin se
pueden reo/izar rpidamente. En ningn
caso lo p/oneocin
/Web poro proyecros
de es/lJ tamao romo
ms del 5por ciento
del esfuerzo del
proyecro globo/.
Entender el mbito, las dimensiones de cambio y las restricciones del proyecto. Ningn proyecto, sin importar cun apretada sea la restriccin del tietr.
puede comenzar mientras el equipo del proyecto no entienda qu debe construir :.A
recopilacin de requisitos y la comunicacin con el cliente son precursores esenc
les para la planeacin efectiva de la WebApp.
Definir una estrategia de proyecto incremental. Ya se ha sealado 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 esta1-.
ce una estrategia de proyecto que defina incrementos (liberaciones) de WebApp
proporcionen contenido til y funcionalidad a los usuarios finales, el esfuerz,..
ingeniera puede enfocarse con mayor facilidad.
Realizar anlisis de riesgo. En el captulo 25 se presenta una exposicin dd>llada del anlisis de riesgo para proyectos tradicionales de ingeniera del softwa.--c
Todas las labores de gestin de riesgo se realizan para proyectos IWeb, pero su er-:
que se abrevia.
Los riesgos que entraan el programa y la tecnologa dominan la preocupac
de la mayora de los equipos de ingeniera Web. Entre las muchas preguntas rela...
nadas con el riesgo que el equipo debe formular y responder estn: Los incremer
WebApp planeados pueden entregarse en los plazos definidos? Estos incremer
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 he
mientas de ingeniera Web requeridos? La tecnologa disponible es adecuada pa:::
trabajo? Los cambios probables requieren la introduccin de nueva tecnologa?
Desarrollar una estimacin rpida. El eje de la estimacin para la mayora
los proyectos de ingeniera Web lo representan los conflictos macroscpicos, r
que los microscpicos. El equipo IWeb valora si los incrementos WebApp planea.:.
pueden desarrollarse con los recursos disponibles de acuerdo con las restriccicr
del programa definido. Esto se logra considerando el contenido y la funcin de <2
7 Aquellos lectores que no estn familiarizados con la terminologa y las prcticas bsicas de la
tin de riesgos debern consultar en este momento el captulo 25.
CAPTULO 17
FORMULAON Y PLANEAON PARA INGENIERA WEB
535
incremento como un todo. Normalmente no se realizan rompimientos "microscpicos", funcionales o de trabajo, del incremento que sean seguidos por el clculo de
estimaciones puntuales de mltiples datos (vase el captulo 23).
Elegir un conjunto de tareas (des cripcin del proces o ). Empleando un marco

de trabajo del proceso (captulo 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 tareas para que encaje en el desarrollo de cada incremento.
Establecer un programa. El programa de un proyecto JWeb tiene una dosificacin 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 entregarse los incrementos adicionales). Esto es, las tareas de ingeniera Web se distribuyen a Jo largo de la lnea de tiempo del proyecto para el incremento que se desarrollar. La distribucin de tareas para subsecuentes incrementos WebApp se demora
hasta la entrega del incremento programado.
Definir mecanismos de rastreo del proyecto. En un ambiente de desarrollo
gil, la entrega de un incremento operativo de software con frecuencia es la medida
primaria del progreso. Pero mucho antes de que el software liberable est disponible, el ingeniero Web enfrentar inevitablemente la pregunta: dnde estamos? En el
trabajo convencional de ingeniera del software el progreso se mide determinando
qu objetivos se han logrado (por ejemplo, la revisin exitosa de un producto de trabajo). Respecto a proyectos de ingeniera Web pequeos y de tamao moderado, los
objetivos pueden estar menos definidos, y las actividades formales de aseguramiento de la calidad pueden perder fuerza. En consecuencia, es posible derivar una respuesta 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 cuntos casos de uso se han implementado y
cuntos (para un incremento dado) permanecen sin implementarse. Esto proporciona una indicacin aproximada del grado relativo en que se ha completado el incremento del proyecto.
*8 ll'OQIISO se logni corrigiendo los errores resuhontes de lograr el progreso.
Establecer un enfoque de gestin del cambio. La gestin del cambio se facilita mediante la estrategia de desarrollo incremental que se recomend para las
WebApps. Puesto que el tiempo de desarrollo para un incremento es corto, con frecuencia es posible demorar la introduccin de un cambio hasta el siguiente incremento, con la consiguiente reduccin de los efectos de demora asociados con los
cambios que se deben implementar "al vueloM En el captulo 27 se presenta la gestin de la configuracin y el contenido para las WebApps.
PARTE TRES
536
Gestin de proyectos IWeb

Objetivo: Auxiliar al equipo de ingeniera
Web en lo ploneacin, gestin, control y rastreo
de proyectos de ingeniera Web.
M ecnica : Los herramientas de gestin de proyectos le
permiten o un equipo IWeb establecer un conjunto de
tareas de trabajo, asignar esfuerzo y especificar
responsabilidad o codo toreo, establecer dependencia de
toreos, definir un programo y rastrear y controlar los
actividades del proyecto. Muchos herramientas en esto
categora estn basados en Web.
Herramientas representativa s
Business Engine, desarrollado por Business Engine

(www.businessengine.com), es uno suite de
herramientas basados en Web que ofrecen facilidades
de gestin poro proyectos completos de IWeb y
proyectos de software convencionales.
lteomwork, desarrollado por iTeamwork.com
(www.iteomwork.com), "es uno aplicacin de equipo de
gestin de proyecto gratuito, en lneo y basado en

Web, que puede usar con su navegador web".
OurProect, desarrollado por Our Project

(www.ourproject.com), es uno suite de herramientas de
gestin de proyecto que son aplicables o lo IWeb y o
los proyectos de software convencionales.
ProjNet, desarrollado por Rotionol Concepts, lnc.
(www.rotionolconcepts.com), "implemento uno oficina
de proyecto virtual (VPO, virtual project office) poro
colobarocin y comunicacin".
StortWright (www.slortwright.com/project1 .htm) ha
desarrollado uno de los recursos ms completos de lo
Web poro herramientas e informacin, tonto poro
IWeb como poro gestin de proyectos de software
convencional.
Es necesario observar que muchos de las herramientas de
gestin de proyecto convencional (Porte 4 de este libro)
tambin se pueden aprovechar de manero efectivo en los
proyectos IWeb.
Los ingenieros Web desarrollan sistemas complejos
y, al igual que otros tecnl<>gl.
que realizan esta tarea, deben usar mediciones para mejorar el proceso de ingeniera Web y el producto. En el captulo 15 se analizaron los usos estratgicos y tcticc.:.
para la medicin de software en un contexto de ingeniera del software. Dichos USC'
tambin se aplican en la ingeniera Web.
En resumen, la medicin de software ofrece una base para mejorar el proceso ~
software, lo que aumenta la precisin de las estimaciones del proyecto, incremen
el rastreo del proyecto y mejora la calidad del software. La medicin de ingenier:
En general, el nmero
de medidos /Web que
se debe recopilar, ysu
compleiidod globo/,
debe ser direclllmenfe
Web, si se caracteriza de manera adecuada, podra lograr todos estos beneficios

tambin mejorar la facilidad de uso, el desempeo de la WebApp y la satisfaccin de
usuario.
En el contexto de la ingeniera Web, las mediciones tienen tres metas principales
1) proporcionar un indicador de la calidad de la WebApp desde el punto de vista tc
propordonol o/
tomoo de Jo WebApp
nico, 2) proporcionar una base para la estimacin del esfuerzo, y .3) proporcionar Ul'l.'?
que se construir.
indicacin del xito de la WebApp desde el punto de vista empresarial.
Las herramientas expuestas slo representan una muestra de esta categora. En casi todos los e:
sos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.
CAPTULO 17
537
FORMULACIN Y PLANEAON PARA INGENIERA WEB
En esta seccin se resume un conjunto de mediciones de esfuerzo comn y complejidad9 para las WebApps. Este conjunto puede destinarse al desarrollo de una
base de datos histrica para la estimacin del esfuerzo. Adems, la medicin de la
complejidad puede conducir a final de cuentas a una incapacidad para valorar cuantitativamente uno o ms atributos tcnicos de las WebApps discutidos en el captulo 16.
17.5.1
Mediciones para esfuerzo de ingeniera Web
Los ingenieros Web dedican esfuerzo humano al realizar una diversidad de tareas de
trabajo conforme evoluciona una WebApp. Mendes y sus colegas [MENO I J sugieren
algunas posibles medidas de esfuerzo para WebApps. Algunas de (o todas) ellas
podrta registrarlas un equipo de ingeniera Web y luego aprovecharse en una base
de datos histrica con fines de estimacin (captulo 23).
Aplicacin de las tareas de autora y diseo

Medida sugerida
Descripcin
esfuerzo de estructuracin
tiempo para estructurar la WebApp y/o lo arquitectura derivado
esfuerzo de intervinculocin
tiempo para intervinculor pginas y as construir la estructura de las

WebApp
ploneocin de interfaz
tiempo en que se planea la interfaz de la WebApp
construccin de interfaz
tiempo en que se implementa la interfaz de la WebApp
esfuerzo de pruebo de vnculos
tiempo en que se prueban todos los vnculos en la WebApp
esfuerzo de pruebo de los

medios oudiovisuoles
esfuerzo tota l
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 vnw
los + esfuerzo de pruebo de los medios audiovisuales
Esfuerzo de autora
Medida sugerida
Descripcin
esfuerzo de texto
tiempo en que se crea o reutilizo texto en una pgina
esfuerzo de vinculacin
de pgina
tiempo en que se crean vnculos en la pgina
esfuerzo de estructuracin
de pgina
tiempo en que se eslrucluro lo pgina
esfuerzo de pgina total
esfuerzo de texlo + esfuerzo de vinculacin de pgina

estructuracin de pgtno
Es importante notar que las mediciones IWeb todavia estan en su infancia.
+ esfuerzo de
538
PARTE TRES APLICAON DE LA INGENIERiA WEB
Autora de medios audiovisuales

Medida sugerida
Descripcin
esfuerzo de medio audiovisual
tiempo en que se crean o reutilizan archivos de medios audiovisuo
esfuerzo de digitalizacin de
medios audiovisuales
tiempo en que se digitalizan medios audiovisuales
esfuerza total de medios

audiovisuales
esfuerzo de medio audiovisual + esfuerzo de digitalizacin de

medios audiovisuales
Autora de programas
Medida sugerida
Descripcin
esfuerzo de programacin
tiempo en que se crean

relacionado
esfuerzo de reutilizacin
tiempo poro reutilizar/ modificar lo programacin existente
HTMl, Javo
o implementaciones de leng_
17 .5.2 Medic16n del valor de negocios

Uno melenla Mido
ocercu de RKhas
molerios relocioncm
con los negocios en
lnte1ne1~
www.lldnet.ca.
Es interesante advertir que la gente de negocios ha llegado considerablemente U'

que la ingeniera Web al desarrollo, la recopilacin y el empleo de la medicin p.:.:
las WebApps (por ejemplo, [STE02], [NOBOI]) . Al entender la demografia de
usuarios finales y sus patrones de uso, una compaia u organizacin puede des
rrollar la entrada inmediata para ms contenido WebApp significativo, ventas
esfuerzos de mercadotecnia ms efectivos, y mejorar la rentabilidad de los negoc
Los mecanismos requeridos con que se recopilan datos valiosos para la empre
usualmente los implementa el equipo de ingeniera Web, pero evaluarlos y las acc.
nes resultantes las realizan otros participantes. Por ejemplo, supngase la posib"
dad de determinar el nmero de vistas de la pgina para cada visitante nico. e
base en la medicin recopilada, los visitantes que llegan desde el motor de bsq..
da X promedian nueve vistas de pgina, mientras que los visitantes desde el port.::.
slo dos. Estos promedios los puede emplear el departamento de mercadotec
para ubicar un anuncio publicitario (banner) donde promueva presupuestos (la pu:
cidad en el motor de bsqueda X proporciona mayor exposicin, con base e;medicin recolectada, que la publicidad en el portal Y).
Mediciones Web
Objetivo: Valorar lo formo en lo que se utilizo
uno WebApp, los categoras de usuarios y lo
facilidad de uso de lo WebApp.
Mecnica: lo gran mayora de los herramientas de
medicin Web capturo lo informacin de uso uno vez q;a

lo WebApp est en lneo. Dichos herramientas
proporcionan uno amplio variedad de datos con los cUCM
se valoro qu elementos de lo WebApp se utilizan ms,
cmo se utilizan y quin los utilizo.
CAPTULO 17 FORMULACIN Y PL.ANEAON PARA iNGENIERlA WEB
ientas representativos10
, desarrollada por dicktracks.com
.-.clicktracks.com), es una herramienta de anlisis
archivos de acceso (log) que muestra el
=:r,x>rlamiento del visitante al sitio Web directamente
cginas de ste.
ce, desarrollada por Coremetrics
-.Coremetrics.com), es representativa de muchas
-:e--omientas que recopilan datos con los cuales se
539
valora el xito de los WebApps de comercio

electrnico.
Web Metrics Testbed, desarrollada por NIST

(zing.ncsl.nist.gov/WebTools/1, es uno 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 para
WebApps de todos los tipos.
Una revisin completa de la recopilacin y el empleo de las mediciones con valor

en los negocios (que incluya el debate actual acerca de la privacidad personal) est
ms all del mbito de este libro. El lector interesado deber examinar [INA02],
fEIS02], [PAT02] o [RJGOI].
En ocasiones, la mejor forma de aprender cmo hacer algo correctamente es examinar cmo no hacerlo! Durante la dcada pasada, muchas WebApps fracasaron
porque 1) un descuido del proyecto y el cambio en los principios de gestin (de cualquier manera informales) result en un equipo de ingeniera Web que "rebot en las
paredes"; 2) un enfoque ad hoc para el desarrollo de la WebApp fall y no produjo un
sistema operable; 3) un enfoque desdeoso hacia la recopilacin y anlisis de requisitos fracas en producir un sistema que satisfaciera las necesidades del usuario; 4)
un enfoque incompetente para el diseo fracas al intentar producir un desarrollo de
la WebApp que fuese utilizable, funcional, extensible (sustentable) y verificable; 5) un
enfoque equivocado para las pruebas fracas para producir un sistema que funcionase antes de su introduccin.
Con estas situaciones en mente, tal vez valga la pena considerar un conjunto de
las "peores prcticas" en la ingeniera Web, adoptadas de un articulo de Tom Bragg
[BRAOO]. Si su proyecto electrnico muestra cualquiera de ellas, es necesaria una
accin correctiva inmediata.
Peor prctica # 1: Se tiene una gran idea, as que se puede comenzar a construir
la WebApp ahora. No es necesario preocuparse en considerar si la WebApp est justificada por el negocio, si los usuarios realmente querrn usarla, si se comprenden
los requisitos del negocio. El tiempo es corto, tiene que comenzarse.
Realidad: Tmense unas cuantas horas o das y elabrese un caso de negocios
para la WebApp. Asegrese de que la idea la apoyan quienes la financiarn y quienes la usarn.
1O Las herramientas expuestas el autor no las respalda , slo representan una muestra de las herramientas incluidas en esta categora. En casi todos los casos los nombres de las herramientas son
marcas registradas de sus respectivos desarrolladores
540
PARTE TRES
Peor prctica #2: Las cosas cambiarn constantemente, as que no tiene caso tn:
tarde comprender los requisitos de la WebApp. Nunca se escriba algo (prdida de tierr
po). El apoyo debe basarse exclusivamente en la palabra oral.
Realidad: Es cierto que los requisitos de la WebApp evolucionan conforme cor
tinan las actividades de ingeniera Web. Tambin es ms rpido y simple obtenc
informacin de manera verbal. Sin embargo, un enfoque desdeoso respecto de
recopilacin y el anlisis de requisitos es un catalizador para ms cambio (inneu:
sario) todava.
Peor prctica #3: Los desarrolladores cuya experiencia dominante se relaciona ce

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 abanico de mtodos, tecnologias y herramientas. El entrenamiento y la expc
rienda con ellos es esencial. 11
Peor prctica #4: Burocratizarse. Insista en modelos de proceso pesados, ho~

rios, muchas e innecesarias reuniones "de progreso" y en lderes de proyecto q:
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 camino y permit..
trabajar. Si se deben recopilar datos relacionados con el proyecto (por razones les
les o el clculo de la medicin), el ingreso/recopilacin de datos debe ser tan no oc
tructivo y simple como sea posible.
Peor prctica #5: Pruebas? Por qu molestarse? Se le dar a unos cuantos UStarios finales y se dejar que ellos digan qu funciona y qu no.
Realidad: Con el tiempo, los usuarios finales s realizan "pruebas" exhausti
pero estn tan enojados por la falta de confiabilidad y el pobre desempeo que
dejan mucho antes de que los problemas sean corregidos (nunca regresan) .
En los captulos que siguen se considerarn los mtodos 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 metas y objet:J
del proyecto, las categoras de usuario final, las funciones y caractersticas principa.~
y el grado de interoperabilidad con otras aplicaciones. Mientras ms informacin de
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 datos col'"
cionales. En tales casos, los individuos slo con experiencia convencional pueden y deben ~
volucrados.
CAPTULO 17
FORMULACIN Y PLANEACIN PARA INGENIERA WEB
541
El equipo !Web lo integra un grupo de miembros tcnicos y no tcnicos organizados en una forma que les brinda considerable autonoma y flexibilidad. Durante la
ingeniera Web se requiere gestin del proyecto, pero las tareas 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 tanto 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 punto
de vista de los negocios.
[BRAOOJ Bragg, T., "Worst Practices for e-Business Projects: We Have Met the Enemy and He Is
Us!", Cutter IT Joumal, 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.
[ETS02] Eisenberg, B., "How to lnterpret Web Metrics", en ClickZToday, marzo de 2002, disponible en http://www.clickz.com/sales/traffic/article.php/992351 .
[FUC02a] Fuccella, J., J. Pizzolato y J. Franks, "Finding Out What Users Want from your Web
Site", 1BM developerWorks, 2002, http://www-106.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.html.
[GNA99J 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 Angeles, mayo de 1999.
[HAN99) Hansen, S., Y. Deshpande y S. Murugesan, "A Skills Hierarchy for Web
Tnformation System Development", en Proc. First ICSE Workshop on Web Engineering,
ACM, Los Angeles, mayo de 1999.
[INA02J Inan, H. y M. Kean, Measuring the Success ofYour Web Site, Longman Publishing,
2002.
[KlOOOJ Kidder, T., The Soul of a New Machine, Back Bay Books (edicin reimpresa), 2000.
[KULOOJ 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/eprojects.html.
[LOW98J Lowe, D. y W. Hall (eds.), Hypertext and the Web-An Engineering Approach, Wiley,
1998.
[MENO!] Mendes, E., N. Mosley y s. Counsell, "Estimating Design and Authoring Effort",
en IEEE Multimedia, enero-marzo de 2001 , pp. 50-57.
[NOBOIJ Nobles, R. y K. Grady, Web Site Analysis and Reporting, Premier Press, 2001.
[PAT02] Patton, S., "Web Metrics That Matter", en ero, 15 de noviembre de 2002. disponible en http://www.computerworld.com / developmenttopics/websitemgmt/story/
o, 10801,76002,00.html.
[PIC01J Pickering, C., "Building an Effective E-Project Team", en E-Project Management
Advisory Service, Cutter Consortium, vol. 2, nm. 1 2001, http://www.cutter.com/
consortium.
[POW98l Powell, T.A., Web Site Engineering, Prentice Hall, 1998.
542
PARTE TRES
APLICACIN DE LA JNGENIER!A WEB
[RIGOI] Riggins, F. y S. Mitra, "A Framework for Developing E-Business Metrics Through fun~
nality Interaction", enero de 200 I, se puede descargar de http://digitalenterprise
org/ metrics/metrics.html.
[STE02J Sterne, J., Web Metrics: Proven Methods far Measuring Web Site Success, Wile'!
2002.
[TIL99) Tilley, S. y S. Huang, "On the Emergence of the Renaissance Software Engineer'
Proc. 1st TCSE Workshop on Web Engneerng, ACM, Los Angeles, mayo de 1999.
17. l. En qu difiere la formulacin de la recopilacin de requisitos? En qu difiere la rorm

lacin del anlisis de requisitos y del modelado de anlisis?
17 .2. En la seccin 17.1.1 se encuentran tres preguntas fundamentales acerca de la formu_

cin. Existen algunas otras preguntas que se considere posibles de plantear en este punto? es as, cules son y por qu deberian hacerse?
17 .3. En el contexto de la recopilacin de requisitos, qu es una "categora de usuario"? Der
ejemplos de tres categoras de usuario para un vendedor de libros en lnea.
17.4. Considrese el sitio de comercio electrnico de HogarSeguro tratado en este capl:l...
Qu mecanismo de comunicacin con el usuario podra usarse para obtener requisitos del SJtema y por qu?
17.5. Con palabras propias, exponga cmo se "analiza" la informacin recopilada durante
comunicacin con el cliente y cul es el resultado de esta actividad.
17 .6. Qu beneficios se pueden derivar de requerir el desarrollo de casos de uso como p.:=!
de la actividad de recopilacin de requisitos?
1 7. 7. Revsese la tabla presentada en la figura 17.1. Agrguense tres hileras ms que ulterio~
distinguirn los proyectos tradicionales de los electrnicos.
1 7 .8. Con palabras propias, describa el papel del editor Web.
17.9. Revisense las caracterlsticas de los equipos de desarrollo gil analizados en el capitule
Se advierte que una organizacin en equipo gil es apropiada para la !Web? El lector realiza:z
algn cambio a la organizacin para el desarrollo de la WebApp?
1 7 .1 O. Descrbanse cinco riesgos asociados con la subcontratacin del desarrollo de Web ~
17 .11. Descr!banse cinco riesgos asociados con el desarrollo en casa de las WebApps.
17 .12. Considrense las mediciones para el esfuerzo de ingeniera Web tratadas en la secc
17.5.1. Intntese desarrollar cinco o ms mediciones adicionales para una o ms categoras
17. 13. La facilidad de navegacin a travs de un sitio Web es un indicador importante de la e
de la WebApp. Desarrllense dos o tres mediciones con las cuales pudiera indicarse la acilida<i
navegacin.
17 .14. Aprovechando una de las referencias sugeridas en la seccin 17.5.2, comente cm1.,
pueden aprovechar las mediciones con valor en los negocios para apoyar la toma de decisio:"'
pragmtica en stos.
Los mtodos para la formulacin de WebApps y la recopilacin de requisitos se pueden acta;

de anlisis de mtodos similares para el software de aplicacin convencional. Las otras lec
ras recomendadas en los captulos 7 y 8 contienen mucha informacin til para el ingen:...
Web.
CAPTULO 17
FORMULACIN Y PLANEActN PARA INGENIERA WEB
543
Flor (Web Business Engineering, Addison-Wesley, 2000) aborda el anlisis de negocios y las
preocupaciones relacionadas que permiten al ingeniero Web comprender mejor las necesidades
del cliente. La facilidad de uso de la WebApp es un concepto que subyace a mucha de la informacin definida como parte de la formulacin y la recopilacin de requisitos. Krug y Black
(Don't Make me Think: A Common sense Approach to Web Usability, Que Publishing, 2000) contiene muchas directrices y ejemplos que pueden ayudar al ingeniero Web a traducir los requisitos del usuario en una WebApp efectiva.
La gestin de proyecto para los proyectos IWeb parte de muchos de tos mismos principios y
conceptos aplicables en proyectos de software convencional. Sin embargo, agilidad es un lema.
wallace (Extreme Programmingfor Web Projects, Addison-Wesley, 2003) describe cmo se puede
aprovechar el desarrollo gil para la JWeb y contiene anlisis tiles de conflictos de gestin de
proyectos. Shelford y Remillard (Real Web Project Management, Addison-Wesley, 2003),
O'Connell (How to Run successfu/ Projects in Web Time, Arthec House, 2000}. Freidlein (Web
Project Management. Margan Kaufman, 2000) y Gilbert (90 Days to IAunch: Internet Projects on
Time and on Budget, Wiley, 2000) tratan una amplia variedad de temas de gestin de proyectos
para !Web. Whitehead (Leading a Software Development Team, Addison-Wesley, 200 t) presenta
muchos lineamientos tiles que pueden adaptar los equipos de ingeniera Web.
Las tcnicas para usar mediciones Web en la toma de decisiones empresariales se presentan en libros como los de Steme [STE02]. lnan [INA02], Nobles [NOB01l y Menasce y Almeida
(Capacity Planningfor Web services: Metrics, Models and Methods, Prentice-Hall, 2001 ). Las "peores prcticas" son consideradas por Ferry y Ferry {77 sure-Fire Ways to Kili a SOjtware Project,
iUniverse.com, 2000).
En Internet est disponible una amplia variedad de fuentes de informacin acerca de formulacin y planeacin para ingeniera Web. Una lista actualizada de referencias en la World Wide
Web, relevante para la formulacin y la planeacin, se encuentra en el sitio Web de SEPA:
CAPTULO
18
CONCEP'l'OS
CLAVE
anlisis
de navega<ln .56l
anlisis
le relacin 560
6{1,ol de datos, .552
ARN .. . 560
COSOS de SO ,$47
lrlll'(!UQ
de Uiarl9 , , .546
modelo
de anUslf , , .S45
modelo de
configuracin .5S9
modelo
de contenido .SS 1
modelo
de interaccin . .554
modelo
fvnclonal ... .557
relaciones de
contenido 552
MODELADO DE ANLISIS PARA

APLICACIONES WEB
primera vista, existe l,lna aparente contradiccin cuando se considera

modelado de anlisis dentro del contexto de la ingeniera Web. Despt.
de todo, se ha notado (captulo 16) que las WebApps tienen una irur
diatez y una volatilidad contraria al modelado detallado, ya sea en la etapa
anlisis o en la del diseo. Y s se realiza algn tipo de modelado, la f!Josofia
(un modelo de proceso adecuado para muchos proyectos de ingeniera Web)
giere que el modelado del anlisis se minimice en favor del modelado de dise
limitados. Franklin IFRA02l advierte esta situacin y esGribe:
Los sitios Wep, por to getier@L, son complejos y enormemente dinmicos. Requieren
fases de desarrollo cortas con la tlnalidad de tener listo el product y ejecutarlo rpidamente. Con fret!Uencia, los desarrolladores van directo hacia la fase d4codficacin
sin comprender qu estn tratando.de col).stru.ir o tm,o quieren construirlo. La coa ficacin respecto del servidor con frecuencia se hace <Id hoc, las tal>las de bases de
dato$ se agregan conforme se nece$tan y la arquitectura evoluciona en una forma a
veces no intencional. Pero algti,na ingeniera de software modelada y dtsciplinada

grar que el proceso de desarrollo de softl,yare sea m~cho ms suave y asegurar q e
el sistema Web sea ms sustentable en lo futuro.
Es posible tenerlo en las dos formas? Se puede hacer "alguna: ingenien~

software modelada y disciplinada'' y todava as trabajar efectivamente er
mundo donde reinan la inmediatez y la volatiJidad? La respuesta -es un cal
dosL
'
>
>
tQu es? 1 bndlisi, de llO potn- Pbt qu es importc:utte? A lo largo de este

libro-,se 60 resaltado to necesidod. de compreneiol oplic~.n Web se.. """"" ,".'' ""'
pregunku importante$: l J aque 1n!Qrder el problema antes de comenzar Q resolverb
0macir o; <;oritenid $ presenfQr q
El modeldo de onisis es importnle oo porque
!JiQi'lipular~; 2} qu funcones cili
, permrtp que 'Ull equjpo de ingeniera W~ desazar el usvorio fi"ool~; y 3} qu trilptlbiientos '
rrolle un ~lo i;qncrm de regvisitos WebApp
exhbr6 la Y{ebApp t<rtfurnre presente conteoi
,{los cosos cambian muy ftec::uentemtmte como
yrQGce M\ciones? tos respuestos se representan

como port de .un njpdelo de"anl(sis qlAI' abarco '
uno diversiclod de r~precsenta<;i~ UML
Quin lo hoce? Los ingenieros Web, los 4esa" ,
rrollodores de contenkld que n<;> $Ol1 t~nicos y -'
los clientes participan en la cre.qsron del modelo
de anlisis.
"
'ppri que esto sea uno ~ i v a recd1$tQ), sine

;<:ue, ms bien, ~rmte que n ingeniero Wr!J
defino aspectos fun9omentol@$ del problema:
elementos cuyo cCmbio nQ es probable (en
futor cerc:ono}. fl dise y fo construi6n se

fudUron '<:UQndo se comprenden e~contenido,
funcin y el <;ompOftom~nto fundomentales.
CAPTULO 18
MODELADO DE ANLISIS PARA APLICACIONES WEB
545
son los fMPOS? El.modelod de anhenfoco en los o ~J fundamentales del

: contenido, i!'lter'oo;in, funcin y conin. Et onlisrs de ccntenido identifica las
y colaboraciones d CQntenido. El anlisis
la interaccin descr~ los elernemo. b6~
la interoccin .del US\JQl'O, lo novegadn , los
....,inrtr,,mjenfos del Ststen'IO que ocurren. El
s de las funciones define las funciones de
w.bApp q u e ~ el usuario y lo secvende procesaminto que ocurre coMo >nw
Un equipo de ingeniera Web debe emprender el modelado de anlisis cuando se

cumplen la mayora o todas las condiciones siguientes:
La WebApp que se construir es grande o compleja.
El nmero de clientes es grande.

El nmero de ingenieros Web y otros colaboradores es grande.
Las metas y los objetivos (determinados durante la formulacin) para la
WebbApp afectarn la linea de referencia del negocio.
El xito de la WebApp tendr una fuerte conexin con el del negocio.
Si estas condiciones no estn presentes, lo que le resta importancia al modelado de
anlisis, aprovechar la informacin obtenida durante la formulacin y la recopilacin
de requisitos (captulo 17) sirve como base para la creacin de un modelo de diseo
para la WebApp. En tales circunstancias, tal vez se obtenga un modelado de anlisis limitado, pero que terminar incluido en el diseo.
El anlisis de requisitos para las WebApps abarca tres grandes tareas: formulacin,
recopilacin de requisitos, 1 y modelado de anlisis. Durante la formulacin se identifican la motivacin (metas) y los objetivos bsicos para la WebApp, y tambin se definen las categoras de usuarios. Cuando comienza la recopilacin de requisitos se
intensifica la comunicacin entre el equipo de ingeniera Web y los accionistas (por
ejemplo, clientes, usuarios finales). Los requisitos de contenido y funcionales se enlistan y se desarrollan los escenarios de interaccin (casos de uso) escritos desde el
punto de vista del usuario final. La intencin es establecer una comprensin bsica
de por qu se construir la WebApp, quin la usar y qu problema) resolver a sus
usuarios.
1 En el capitulo 17 se abordan con detalle la formulacin y la recopilacin de requisitos.
54
PARTE TRES
APLICACIN DE LA INGENIEruA WEB
"Los ptindpios de ingeniera acerca de planear antes de disear y diseor antes de cnslruir han resistido trufa transicntNno16gkoprevio; tambinsobrevivirn oesto transicin."
Y/Jltts ffphrey
18.1.1
La jerarqua de usuario
Las categoras de usuarios finales que interactuarn con la WebApp se identific.:.

como parte de las tareas de formulacin y de recopilacin de requisitos. En la mar
ra de los casos, las categoras de usuario son relativamente limitadas y no neces
tan una representacin UML. Sin embargo, cuando crece el nmero de categoras
usuario, a veces es aconsejable desarrollar una jerarqua de usuarios, como se mue..
tra en la figura 18.1. La figura muestra a los usuarios del sitio de comercio electrr"
co de HogarSegurolnc.com tratada en los captulos 16 y I 7.
Es bueno idea construir uno erorqufo de

usuario. Ofrll(e uno
visin instantneo de
lo poblacin de usuarios y uno morco de
verificacin que ayudarn aasegurar que
se han abordado los
necesidades de codo
usuario.
Las categoras de usuario (con frecuencia llamados actores) que se muestran e.:
la figura 18.1 indican la funcionalidad que ofrecer la WebApp; adems, sealan
necesidad de que se desarrollen casos de uso para cada usuario final (actor) an~
do en la jerarqua. En la misma figura, el usuario de Hogarsegurolnc.com en
parte superior de la jerarqua representa la clase (categora) de usuario ms gene.
y se refina niveles abajo. Un visitante es un usuario que visita el sitio pero no ser
gistra. Tales usuarios usualmente buscan informacin general, comparan compras
de alguna otra forma estn interesados en contenido o funcionalidad "gratuitos"
usuario registrado dedica tiempo para ofrecer informacin y se le considera
contacto (junto con otros datos demogrficos que solicitan las entradas de los i
mularios). Las subcategoras para los usuarios registrados incluyen:
Jerarqua de
usuarios para
Usuario de
HogarSegurolnc.com
HogarSegu-
rolnc.com.
Visitante
Usuario
registrado
Cliente
nuevo
Personal
de servicio
al cliente
Cliente
existente
CAPTULO 18
547
MODELADO DE ANLISIS PARA API.ICACIONES WEB
Cliente nuevo: usuario registrado que quiere personalizar y luego comprar

componentes de HogarSeguro (y, por tanto, debe interactuar con la WebApp
de funcionalidad de comercio electrnico).
Cliente existente: un usuario que ya posee componentes de HogarSeguro y

usa la WebApp para l) comprar componentes adicionales; 2) adquirir informacin de soporte tcnico; o 3) contactar con el soporte al cliente.
Los miembros del personal de s ervicio al cliente son usuarios especiales que
tambin pueden interactuar con el contenido y la funcionalidad de HogarSegurolnc.com conforme asisten a los clientes que han establecido contacto con el soporte al cliente de HogarSeguro.
18.1.2 Desarrollo de casos de uso

Franklin [FRAO 1] se refiere a los casos de uso como "haces de funcionalidad". Esta
descripcin captura la esencia de esta importante tcnica de modelado de anlisis. 2
Los casos de uso se desarrollan para cada categora de usuario descrita en la jerarqua 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
funcionolidod dej)efsonolizocin _ _ _ _ _
... ---,
L---L ----------------,
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 fut'IOOl'M) tdod vnefCtO electrnico _ _ _ _
Las tcnicas para desarrollar casos de uso se analizaron con detalle en capllulos anteriores de este
libro (vanse los captulos 7 y 8).
Aunque es posible desarrollar descripciones mas fonnales de casos de uso, la necesidad de agilidad
para la !Web con frecuencia excluye este enfoque
548
La figura 18.2 representa un diagrama UML de caso de uso para l a categora de

usuario cliente nuevo (figura 18.1). Cada valo en el diagrama representa un cas..
de uso que describe una interaccin especfica entre el cliente nuevo y la WebApp
Por ejemplo, la primera interaccin se describe con el caso de uso pedir acceso (log
in) a HogarSegurolnc.com. No se requerira ms de un solo prrafo para describir esta interaccin comn.
La funcionalidad de las grandes WebApp (y los casos de uso rel evantes para ella
se anotan adentro de recuadros con lneas punteadas en la figura 18.2. Tales recua
dros se conocen como "paquetes" en UMLy representan funcionalidad especfica. S:
advierten dos paquetes: personalizacin y comercio electrnico.
Como ejemplo, considrese el paquete personalizacin de casos de uso. Un nUc

vo cliente debe describir el ambiente domstico en el cual se instalar Hogarsegu.Para lograrlo, cliente nuevo inicia los casos de uso describir plano de la casa, sele
cionar componentes HogarSeguro y guardar configuracin. Considrense los siguie:tes casos de uso preliminares escritos desde el punto de vista de un cliente nuevo
caso de uso: describir plano de la casa
La WebApp formular algunas preguntas generales acerca del ambiente en el cual se pla-
Conforme aece el
tamao de uno
WebApp, ye/
modelado de anlisis
se vuelve ms
riguroso, los cosos de
uso preliminares
presentados aqu
sern expandidos poro
ajustarse de manero
ms cercana al
formato sugerido en
la seccin 8.5 del
capftu/o 8.
nea instalar Hogarseguro: nmero de habitaciones y su tamao, tipo de habitacin, nmero de pisos, nmero de puertas exteriores y ventanas. La WebApp permitir construir U:"
plano de la casa aproximado al conjuntar formas delineadas de las habitaciones para cada piso. El usuario ser capaz de nombrar al plano de la casa y guardarlo para una refe
rencia futura (vase caso de uso: guardar conjiguradn).
caso de uso: seleccionar componentes HogarSeguro
Entonces la WebApp recomendar componentes de producto (por ejemplo: paneles d.!
control, sensores, cmaras y otras caractersticas (por ejemplo, funcionalidad basada ~
PC implementada en software) para cada habitacin y la entrada exterior. Si el usuario snlicita opciones, la WebApp las proporcionar si existen. El usuario obtendr informac10.
descriptiva y de precios para cada componente de producto. La WebApp crear y mostrar una factura de materiales conforme se seleccionen varios componentes. El usua,..
tambin podr nombrar la factura de materiales y guardarla para referencia futura (vas,
caso de uso: guardar configuracin).
Caso de uso: guardar configuracin
La WebApp permitir guardar los datos de personalizacin de modo que el usuario puec
regresar despus. Podr guardar el plano de la casa y la factura de materiales HogarSeg:.
ro que eligi para l. Lograr esto requiere que el usuario proporcione un identificador.:.co para el plano de la casa y la factura de materiales. Tambin proporcionar u-u
contrasea (password) de configuracin especial que debe validarse antes de que puec
tener acceso a la informacin guardada.
CAPTULO 18
549
MO DELADO DE ANLISIS PARA APLICACIONES WEB
ltqlnar,q,sos ile. USQ para WebApps

11 escenario; OfcihO de Doug
Sharon: nene sentido.
describo.-,
Sharcn, me clci 911$10 tsCochir que 4os cosos van

bien. jEI modtllado de onli$is ~ casi
5am: Psdir al cliente,[va tfll~J que

habif(Jcin de kt casa e ngresdt kn d i ~ tA,f,..
habitacn y otras ~ $ t i ~ en tm gran fomw#oo
diseado especl&omtmte poro el p,r,ooal de
c;/'enfe. Uno v.et qix,. $$ hdyan / ~ dmN CWkt
,,,,_,.o1
cosa podrfJ 9vor<k,r,lo$ ~ CQn .,- nombrt, ()'1umeto

de telfono del -cliente.
S.horon: Som, hoJ sido urr tato lac6nico t'1 tU$ d.crip:,
dones preliminares de ca~ de uso. c:r., q u e . ~

que detallarlas un poco.
'
....-. S. b l,ll1'M por. CQITeQ c,Jectr6nic:o o

COR copio poro ti. Aqu ~t la. ver~ impresa.
o ~ y shoron unos hos de papel.)
Como lo vemos, quer8MOs usar el 1it1o Web de
llllr5et:IUl'l:alnc.com t:OtnO uno herramienta de soporte
lcdientes ordenen por ielfonO'. Nuestros repre
~ completarn tod4s ls formularios
, ele., y procesorn el pedid por el diente,
l!or q\t nG slo remitir <11 cliente ol sitio Web?
l>oug (a1lntiendo con la abu): b1oy de oc.ve,,,

do.
5am (molhumorod):
_PQt q~
;
'
<
$haron: Bueno... mencionas "vn ~~n ulorio dise,,

odo e~ifiOnlen~ poro et personal de -~
oJ
d1enJe"'. Vatnos a M<:iitor m& detalles,
5am: lo qqe quise decir fue que no oec:esitom$ ll~aht

t1uestros representarl* potfudo el preso como i.lrides.
lo hocen poro un cllWe en lneo. 1.1n gran formuloriQ ,...
solvero el ptohtero<>.
Sharon: Bosquejemos, cmo se >1.ero el fotmufqrio.
las partes trabajan para proporcionar suficiC!!Ole detolle

que permita al equipa de Sharen emplear en.formo efuc~
tivo el ca so de uso.
Aunque es posible ofrecer considerablemente ms detalle para cada uno de los

casos de uso, la descripcin textual informal ofrece una visin til. Descripciones similares se desarrollaran para cada valo en la figura 18.2.
18.1.3 Afinacin del modelo de caso d e uso

A la par que se crean los diagramas de caso de uso para cada categora de usuario,
se desarrolla una vista superior de los requisitos de la WebApp observables de ma-
PARTE TRES
550
nera externa. Los casos de uso se organizan en paquetes funcionales, y cada paquete se valora [CONOOJ para garantizar que es:
Cmo se
valoran los
paquetes de casos
de uso agrupados
por la funcin
usuario?
Comprensible: todos los clientes entienden el propsito del paquete.

Cohesivo: el paquete aborda funciones relacionadas cercanamente una con
otra.
Libremente acoplados: las funciones o clases dentro del paquete colaboran
una con otra, pero la colaboracin exterior del paquete se mantiene en un m nimo.
Jerrquicamente superficial: las jerarquas funcionales profundas son dificiles
de navegar y entender para los usuarios; en consecuencia, el nmero de niv1:les dentro de una jerarqua de casos de uso debe reducirse siempre que sea
posible.
Puesto que el anlisis de requisitos y el modelado son actividades iterativas, es p"O
bable que se sumen nuevos casos de uso a los paquetes que se han definido, que
casos de uso existentes sean refinados y que casos de uso especficos puedan re"
carse en paquetes diferentes.
18 2 EL MODELA,PQ PI
1
#Xiris ;;;wf'.iP,$
El modelado de anlisis para una WebApp se basa en la informacin que contie

los casos de uso desarrollados para la aplicacin. Las descripciones de los caSO"
uso se analizan gramaticalmente para identificar potenciales clases de anlisis .
operaciones y atributos asociados con cada clase. Se identifica el contenido que :sentar la WebApp y se extraen las funciones que se desarrollarn a partir de las
cripciones de caso de uso. Finalmente, los requisitos especficos de la implemen
se deben desarrollar de modo que el ambiente y la infraestructura que apoyan la
Apps puedan construirse.
Cuatro actividades de anlisis, cada una con su aporte a la creacin de un r.
lo de anlisis completo, son:
Qu tipos
de activida
des de anlisis
ocurren durante el
modelado de una
WebApp?
Anlisis de contenido: identifica todo el espectro del contenido que ofrec..

WebApp. El contenido incluye texto, grficas e imgenes, as como datos
video y audio.
Anlisis de interaccin: describe cmo interacta el usuario con la WebA,_
Anlisis de funciones: define las operaciones que se aplicarn al conteni1..
la WebApp y describe otras funciones de procesamiento, independientes contenido pero necesarias para el usuario final.
Anlisis de configuracin: describe el ambiente y la infraestructura en la
reside la WebApp.
CAPTULO 18
MODELADO DE ANLISIS PARA APUCACIONES WEB
551
La informacin recopilada durante las tareas de estos cuatro anlisis se debe re-
visar, modificar cuando se requiera y luego organizarse en un modelo que pueda pasarse a los diseadores de WebApp.
El modelo en s mismo contiene elementos estructurales y dinmicos. Los elementos estructura/es identifican las clases de anlisis y los objetos de contenido que se
requieren para crear una WebApp que satisfaga las necesidades de los clientes. Los
elementos dinmicos del modelo de anlisis describen cmo interactan los elementos estructurales, entre ellos y con los usuarios finales .
.,, M[Lcs WebAp,$] exilosos permiten que los clientes solisfagon mejor sus necesidades, ms rpido oms baroto por s
, mispos, que el ttobajor a 1Jovs del empleado [de una compaa] paro los usuarios finules."
El modelo de contenido contiene elementos estructurales que proporcionan una importante visin de los requisitos de contenido para una WebApp. Dichos elementos
estructurales incluyen objetos de contenido (por ejemplo: texto, imgenes grficas,
fotografias, imgenes de video, audio) que se presentan como parte de la WebApp.
Adems, el modelo de contenido incluye todas las clases de anlisis: entidades visibles para el usuario que se crean o manipulan conforme ste interacta con la WebApp.
una clase de anlisis incluye atributos que la describen, operaciones que afectan el
comportamiento requerido de la clase y colaboraciones que permiten la comunicacin de la clase con otras clases.
Al igual que otros elementos del modelo de anlisis, el modelo de contenido se
deriva a partir de un examen cuidadoso de los casos de uso desarrollados para la
WebApp. Los casos de uso se analizan gramaticalmente para extraer objetos de contenido y clases de anlisis.
18.3.1
'
c&v1
...aieto de contenido
~ ..ill~uier artculo de
~ocin cohesiva
se presentar a un
.s.xirio final. Usual
~te, los objetos de
::'lfenido se extroen
los casos de uso.
Definicin de objetos de contenido
Las aplicaciones Web presentan informacin preexistente -llamada contenido- a

un usuario final. El tipo y forma del contenido abarca un amplio espectro de elaboracin y complejidad. El contenido puede desarrollarse antes de la implementacin
de la WebApp, mientras sta se construye o mucho despus de que la WebApp se encuentra en operacin. En cada caso, se incorpora por medio de referencias de navegacin en la estructura global de la WebApp. Un objeto de contenido puede ser una
descripcin textual de un producto, un artculo que describa un evento noticioso,
una fotografia de accin tomada en un cotejo deportivo, una representacin animada de un logotipo corporativo, un breve video de un discurso o un recubrimiento de
audio para una coleccin de diapositivas Powerpoint.
Los objetos de contenido se extraen de los casos de uso al examinar la descripcin del escenario para referencias directas e induectas al contenido. Por ejemplo,
en el caso de uso seleccionar componentes HogarSeguro se encuentra la oracin:
552
PARTE TRES
Ser capaz de obtener informacin descriptiva y de precios para cada componente de producto.
Aunque no existe referencia directa al contenido. est implcita. El ingeniero Wet
podra reunirse con el autor del caso de uso y comprender en forma ms detallad..
lo que significa "informacin descriptiva y de precios". En este caso, el autor del cas...
de uso puede indicar que "informacin descriptiva" incluye 1) una descripcin general del componente en un prrafo; 2) una fotografia del componente; 3) una descripcin tcnica del componente en varios prrafos; 4) un diagrama esquemtico de
componente que muestre cmo encaja en un sistema HogarSeguro tpico; y 5) u:breve video que muestre cmo instalar el componente en una configuracin doms
tica tpica.
Es importante advertir que cada uno de estos objetos de contenido debe desarrc
liarse (con frecuencia a travs de desarrolladores de contenido que no son ingenie
ros Web) o adquirirse para integrarlo en la arquitectura de la WebApp (analizada e
el captulo 19).
i,
~wWeb: '8pto tontenido, ton poco tiempo."
18.3.2 Relaciones y jerarqua de contenido
&l
~~
C~VE
Un rbol de dotos
represento uno
jerorquo de objetos de
contenido.
En muchas instancias, una simple lista de objetos de contenido, pareadas con ur

breve descripcin de cada objeto, es suficiente para definir los requisitos para el ccr
tenido que deben disearse e implementarse. Sin embargo, en algunos casos, el m~
delo de contenido puede contener diagramas de relacin de entidades (captulo 8
rboles de datos [SRIOIJ que bosquejan las relaciones entre los objetos de contenic
o la jerarqua de ste que mantiene una WebApp.
Considrese el rbol de datos creado para el componente HogarSeguro que s.
muestra en la figura 18.3. El rbol representa una jerarqua de informacin con <r
DescripclnD!Mrkefing
rbol de
datos para un
componente
porteNmero
Fotogrof!o
porteNombre
Descripc611Tcnlco
HogarSeguro.
Esquema
componente
descripcin
\/ideo
precio
PrecioMoyoristo
PrecioMinoristo
CAPTULO 18
MODELADO DE ANIJSIS PARA APLIC ACIONES WEB
553
se describe el componente (ms adelante se ver que, en realidad, un componente

HogarSeguro es una clase de anlisis para esta aplicacin). Los articules de datos
simples o compuestos (uno o ms valores de datos) se representan como rectngulos sin sombreado. Los objetos de contenido se representan como rectngulos sombreados. En la figura, descripcin se define por medio de cinco objetos de contenido (los rectngulos sombreados). En algunos casos, uno o ms de dichos objetos se
refinar ms todava conforme se expanda el rbol de datos.
18.3.3 Clases4 de anlisis para WebApps

Como ya se ha sealado, las clases de anlisis se derivan al examinar cada caso de
uso. Por ejemplo, considrese el caso de uso preliminar: seleccionar componentes Ho-
garSeguro que se present en la seccin 18.1.2.

Caso de uso: seleccionar componentes HogarSeguro
Entonces la WebApp recomendar componentes de producto (por ejemplo: paneles de

control, sensores, cmaras) y otras caractersticas (por ejemplo, funcionalidad basada en
PC implementada en software) para cada habitacin y la entrada exterior. Si el usuario solicita opciones, la WebApp las proporcionar si existen. El usuario obtendr informacin
descriptiva y de precios para cada componente de producto. La WebApp crear y mostrar una factura de materiales conforme se seleccionen varios componentes. El usuario
tambin podr nombrar la factura de materiales y guardarla para referencia futura (vase
caso de uso: guardar configuracin).
Un rpido anlisis gramatical del caso de uso identifica dos clases candidatas (subrayadas): ComponenteDeProducto y FacturaDeMateriales. En la figura 18.4 se
muestra una primera descripcin de cada clase.
La clase ComponenteDeProducto abarca todos los componentes de HogarSeguro que se pueden comprar para personalizar el producto destinado a una instalacin particular. Es una representacin generalizada de Sensor, Cmara, Paneldecontrol y CaracteristicadeSOftware. Cada objeto de c omponenteDeProducto
contiene informacin que corresponde al rbol de datos que se muestra en la figura
18.3 para la clase. Algunos de estos atributos de clase son articules de datos sencillos o compuestos, y otros son objetos de contenido (vase la figura 18.3). Tambin
se muestran las operaciones relevantes para la clase.
La clase FacturaDeMateriales abarca una lista de componentes que cliente
nuevo ha seleccionado. FacturaDeM ateriales es en realidad un agregado de ArticuloFdM (muchas instancias de ArticuloFdM comprenden una FacturaDeMateriales): una clase que construye una lista compuesta de cada componente que se
comprar y de atributos especficos acerca del componente, como se muestra en la
figura 18.4.
4 En el captulo 8 se presentaron en forma deta llada los mecanismos para identificar y representar las
clases de anlisis. Si todava no se ha hecho, el captl.Ulo 8 debe revisarse en este momento.
554
Uhlli:i
Clases de
Foctu~DeMateriales
anlisis para
ComponentedeProclucto
el caso de
uso: seleccionar componentes
dentilcod<1r
f)f<;iOfolal
podeNmero
porteNombre
portellpo
descripcin
precio
creorNuevoArtculoO
obl'enerD<!scrtn()
obrenerEsp,!'11 cnco()
HogarSeguro.
,,"
~
&l
1
Cma!'(I
Pane1DeCon1Tol
~r
l '.~lculorPr~io{)
o
o.
l
Sensor
ogrearE'lltodaO
horrar!:ntrodoO
edlc:ir!:ntrodaO
nombreO
guorclorO
C11roctSc,ftware
ArtculQFdM
contidod
pr11cio
agr~orol&loO
l;,orrQrdefloO
Cada caso de uso identificado para HogarSeguroinc.com se analiza gramat....

mente para objetos de anlisis. Respecto a cada caso se uso se desarrollan mode
de clase similares al descrito en esta seccin.
18, 4 tL HPPBLP
QE;
JNTERA,cc16w
La gran mayora de las WebApps permite una "conversacin" entre un usuario ::

y la funcionalidad, el contenido y el comportamiento de una aplicacin. Este me
Jo de interaccin lo componen cuatro elementos: 1) casos de uso, 2) diagramas de~
cuenda, 3) diagramas de estado/> y 4) un prototipo de interfaz de usuario. Ader,de estas representaciones, la interaccin tambin se representa dentro del cante
del modelo de navegacin (seccin 18. 7).
Casos de uso. Los casos de uso son el elemento dominante del modelo de i'r
raccin para las WebApps. No es raro describir 1oo o ms casos de uso cuand<'
Es posible utilizar los

tcnicos asociados con
el anlisis de toreos
(captulo 12) poro
ayudarse odefinir los
modos de interaccin
del usuario.
analizan, disean y construyen grandes y complejas WebApps. Sin embargo, un p

centaje relativamente bajo de estos casos de uso describe las principales interacc.
nes entre las categoras de usuario final (actores) y el sistema. Otros casos de uso
finan las interacciones y proporcionan el detalle de anlisis necesario para guiar
diseo y la construccin.
Diagramas de secuencia. Los diagramas de secuencia UML ofrecen una re:;

sentacin abreviada de la forma en la cual las acciones del usuario (los elemen
dinmicos de un sistema que definen los casos de uso) colaboran con las clases
5 Cada uno de stos es una importante notacin UML que se describi en el captulo 8.
CAPTULO 18 MODELADO DE ANLISIS PARA APUCACIONES WEB
:Piona de
lo coso
Cliente
nuevo
1 Describir
Componente
de Produelo
555
:Factura De
Materiales
1
1
Almoc4~ dt
>lana de
lo coso
1
1
1
1
:
~------+-------
:
1
1
: habilacin t Colocar
1
: habitacin
1
1en plano de
1
1 la coso
Almacn
de FdM
1
r----!-,e--,----,'----,,,--,-L-,--,--,-.,---!----'
~- _____ ~Guardar conf~urocin pion~de la planto ~ ______ ~
1
Selecciona,; componente d~ producto
~ - - - - - - : - - - - - - : ------rar~5irofd~
!-_____ .L ___ Guord.,~ir focruro de "Lterioles

1
1
1
t
1
1
1
1
1
1
___ ______ -'- ___ __ J

1
1
1
1
1
1
1
1
1
1
anlisis (los elementos estructurales de un sistema que definen los diagramas de clase). 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 entre 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 (entidades estructurales). Conallen [CONOOJ seala esto cuando escribe: "La mezcla de
elementos 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 seleccionar componentes HogarSeguro. El eje vertical del diagrama muestra las acciones
que se definen dentro del caso de uso. El eje horizontal identifica las clases de anlisis que se usan conforme procede el caso de uso. Por ejemplo, un cliente nuevo primero debe describir cada habitacin de la casa (el asterisco a continuacin de "describir habitacin" indica que la accin es iterativa). Para lograr esto, el cliente nuevo
responde preguntas acerca del tamao de la habitacin, puertas y ventanas, etctera. 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 (guardar la configuracin del plano de la planta). El movimiento a travs y hacia abajo 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 clases 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.
Diagramas de estado. El diagrama de estado UML (captulo 8) ofrece otra representacin del comportamiento dinmico de Ja WebApp conforme sucede una nter-
556
Diagrama de estado parcial para interaccin con cliente nuevo.
o
A
...
'
-Volida, v~orio:
t,tdQ $1Slemo ;,m10do liSIQ

s:Cionar Moelro m4i "i,gt"'' i<I <lo u~Ji'
"occeso"' MvesJro: !!tSl ..tlgfetor cooffoleo'
elllt!ido/oeee"' !Qliciiodo
~Q<:93 oatirvolida<j~ de uJu(lrio
solido/labl..,orinte,ru~ (1Cc$
Cliente
nuevo
~SOQ(O
ersonolizocin completo
L,
LJ 1"1-
...
__J volidoda
u,uorio
c;:ontro$eO volidodo
'
/ Se~ciooot ctlin "'1Jorio
Sel&ccionor otros funcione$
Es1ad6 ,.,,.""' "{11<'Vlo li,i,

MueslrQ: "'e:fe:ione,:.de novegocin"' ,entrado/u,uorio ...,;ljdodo
hoc: v,ncula, oomo ,. .ollclto
$0l1da/accin u,uorio<11locdoilodo
'
1 Seleccionar funcionofidod comercio electrnico (comprol

Seleccionor' funcionolidod petsono1itaci6n
Siguiente ,eleccin
J'.r..,;oot,o,
~e6eccionor contenido
L-..J
Elmd<>,i,tooia' ~ P B,lo"
Moe,lrq; 1$lru<:eloo, 1'6,lta>
eroradd/~-,io vol,d<)do
h~: pr<e.o -.leccin llOlfl!rio
,alido/>er.!i\ali;i<:in i.o,,indo
~
descriptivo
D,,fi,,ithobil<>ticin
Hobitoein o definir
:;=,....n
~
GvoJor plqna de b ;o,o
Selec:donoc contenido
, de\criptivo
Estado ,i,~a '.ellra<lo li,to"
._
Mt.testro; ,1':dicodor olmocitnomienlQ
EstodQ ~i,temo ..entrado listo"

Mue~a: ventana del. l,oll,J9i"
~trodo/&.f. bab'**' S<1leoc,ooodo

Todo, lo, )\oce; cfr can~li<lbil<l,in
hobitociones bace: olm<><"ll voriobl~ hcbitodn
definido, !li.:l,a/hobitocin compl.tdo
....
Seleccionor guordor plooo de lo planto

Sel:tionor ingre~r hobitodn en plono de lo pJonto
Insercin hobitocin completodo
n1tod,;,/guordat hobllo<.i6n
-.l<cil)na</o "" pla09 de la ,Jonia
hoce;
Plo"9 de lo pk,,,10
~fid<>/9uordodo<:ample1lld<>
"""""
,. Ci>n,t,w, plono d. lo~
Seleco
cootr
'descr-
E,fo<lo ~- '$nfrqdo li,1<1
~;voolOoa piona a. la pk,,,la
entrod/plo"a de lo C050 Sl~~ionod

hoce: ln,erlor hobifein erl higo,
~ a , ,ori.obl&s pk,,io ~. lo plonlo
,
mS<Uci/1 "'1bilcl6,, oc,mplet<do ...
--
accin. Al igual que la mayora de las representaciones de modelado utilizadas eingeniera Web (o en la ingeniera del software), el diagrama de estado puede re-sentarse en diferentes grados de abstraccin. La figura 18.6 muestra la vista su
(mayor grado de abstraccin) de un diagrama de estado parcial para la interac
entre un cliente nuevo y la WebApp de Hogarsegurolnc.com.
En el diagrama de estado que se muestra se identifican seis estados observa::
externamente: validar usuario, seleccionar accin del usuario, personalizar, dejir
bitacin, construir plano de la casa y guardar plano de la casa. El diagrama de
indica las acciones que se requieren para mover al cliente nuevo de un estado a
la informacin que se muestra conforme se ingresa un estado, el procesamientc
ocurre dentro de un estado y la condicin de salida que provoca una transia...un estado a otro.
Puesto que los casos de uso, los diagramas de secuencia y los diagramas ~
tado muestran informacin relacionada, es razonable preguntar por qu son r
sarios los tres. En algunos casos no lo son. Los casos de uso tal vez sean sufi~
en algunas situaciones. Sin embargo, los casos de uso proporcionan una visi'"
bien unidimensional de la interaccin. Los diagramas de secuencia presenta:segunda dimensin que en esencia es ms de procedimiento (dinmica). Los
mas de estado proporcionan una tercera dimensin que se refiere ms al comp
miento y contiene informacin acerca de los patrones de navegacin potenG
CAPTULO 18
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 dimensin 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.
Prototipo de la interfaz de usuario. La plantilla de la interfaz de usuario, el contenido que presenta, los mecanismos de interaccin que implementa y la esttica
global de las conexiones usuario-WebApp, tienen mucho que ver con la satisfaccin
del usuario y la aceptacin global de la WebApp. Aunque se puede argumentar que
la creacin de un prototipo de interfaz de usuario es una actividad de diseo, es una
buena idea realizarla durante la creacin del modelo de anlisis. Mientras ms rpido 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 herramientas de desarrollo de la WebApp son abundantes, relativamente baratas y funcionalmente poderosas, es mejor crear el prototipo de la interfaz mediante tales herramientas. El prototipo debe implementar los principales vnculos de navegacin y representar la plantilla de pantalla global en gran parte como ser construida.
El modelo funcional aborda dos elementos de procesamiento de la WebApp y cada

uno representa un grado diferente de la abstraccin de procedimiento: l) funcionalidad observable respecto al usuario y que entrega al usuario final la WebApp, y 2)
las operaciones dentro de las clases de anlisis que implementan comportamientos
asociados con la clase.
La funcionalidad observable para el usuario comprende cualesquiera funciones

de procesamiento que ste inicia directamente. Por ejemplo, un sitio Web financiero
puede implementar una variedad de funciones financieras (como una calculadora
para fondo de matrcula universitaria o una calculadora para fondo de retiro). Dichas
funciones en realidad pueden implementarse mediante operaciones dentro de las
clases de anlisis, pero, desde el punto de vista del usuario final, la funcin (ms precisamente, los datos que proporciona la funcin) es el resultado visible.
En un grado inferior de abstraccin procedimental, el modelo de anlisis describe 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 calcularPreclO( J que forma parte de la clase de anli-
558
PARTE TRES APUCACIN DE LA INGENIERA WEB
Diagrama de
actividad para la operacin calcularPrecio< ).
Ningn componente permaoece en listofdM
Compone.me~ permanecen
enliitoFdM
Como alternativo,
tambin es posible
esuibir uno simple
narracin del procesomiento oreprasenl!J
ci6n en lenguoe de
programacin de
diseo (coplulo 11 ).
Sin embargo, muchos
personas prefieren
uno representacin
grfico.
sis FacturaDeMateriales.6 Como se anot en el captulo 8, el diagrama de activid..

es similar al diagrama de flujo, el cual ilustra el flujo de procesamiento y las decisl
nes lgicas del flujo. Debe notarse que, dentro del flujo procedimental, se invoc..
dos operaciones adicionales: calcCostoEmbarque( ), que calcula el costo de embarqdependiendo del mtodo que haya elegido el cliente, y determnarDescuento( ), que ~
termina cualquier descuento especial para los componentes HogarSeguro elegid
para comprar. Los detalles de construccin que indican cmo se solicitan estas o;:-:
raciones y los detalles de la interfaz para cada operacin no se consideran sino ha.a
ta que comienza el diseo WebApp.
6
Una revisin de la clase de anlisis FacturaDeMateriales puede determinar que, con la inten...
de cohesionar, la operacin calcularPreciO() puede colocarse mejor en una clase Facturas. Esta
gerencia tiene mrito. Sin embargo, permanece dentro de la clase de anlisis FacturaDeMa
les para los propsitos de este ejemplo.
CAPTULO 18
MODELADO DE ANLISJS PARA APUCACIONES WEB
559
Las WebApps se deben disear e implementar de forma que se acomoden a una diversidad 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 ambiente del sistema
operativo. Adems, se deben considerar aspectos de interoperabilidad en el lado del
servidor. Si la WebApp debe tener 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 complementaria necesaria.
El software del lado del cliente proporciona la infraestructura que permite el acceso a la WebApp desde la ubicacin del usuario. En general, el software de navegacin se utiliza para entregar el contenido y la funcionalidad de la WebApp que se
descargan del servidor. Aunque existen estndares, cada navegador tiene sus propias peculiaridades. Por esta razn, la WebApp debe someterse a una amplia prueba en cada configuracin de navegador que se especifique como parte del modelo de
conjiguracn.
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 elaboradas, varias complejidades de configuracin (por ejemplo: distribucin de carga entre mltiples servidores, arquitecturas de cach, bases de datos remotas, mltiples servidores que sirven a varios objetos en la misma pgina Web) pueden impactar el anlisis y el diseo. Es factible aprovechar el diagrama de despliegue UML (capitulo 1O) en
situaciones en las cuales se deban considerar arquitecturas de configuracin complejas.
Los elementos 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
implementar la interaccin con el usuario. Conforme el anlisis evoluciona en diseo, dichos elementos se vuelven parte de la arquitectura de la WebApp. En el contexto de las aplicaciones Web, cada elemento arquitectnico tiene el potencial de
vincularse con todos los otros elementos arquitectnicos. Pero, conforme aumenta
el nmero de vnculos, la complejidad de navegacin a travs de la WebApp tambin
crece. Entonces, la pregunta es cmo establecer los vnculos apropiados entre los
objetos de contenido y las funciones que proporcionan las capacidades que requiere el usuario.
7
El lado del servidor hospeda la WebApp y todas las caractersticas de sistema relacionadas que permiten a mltiples usuarios tener acceso a la WebApp via 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.
560
PARTE TRES
APLICACIN DE LA INGENJERA WEB
[l.o novegodn] no slo es la accin de soltar de pgina o pgina, sino lo ideo de moverse o trltis de U'ft ujll(io de
infol"JllG(ln,"
A. R yJ. Torres
El anlisis relacin-navegacin (ARN) proporciona una serie de pasos de anlis:..
que luchan por identificar relaciones entre los elementos descubiertos como parte d
la creacin del modelo de anlisis. 8 Yoo y Bieber (YOOOO) describen un ARN del me
do siguiente:
El ARN proporciona a los analistas de sistemas una tcnica sistemtica para delerminar la
estructura de relacin de una aplicacin, lo que les ayuda a descubrir las relaciones potencialmente tiles en los dominios de la aplicacin y que se pueden implementar como
vnculos ms adelante. El ARN Lambin ayuda a determinar las estrucluras de navegacin
apropiadas sobre estos vinculos. El ARN fomenta la comprensin de los desarrolladores
de sistemas en tomo a los dominios de la aplicacin al ampliar y profundizar su modelo
conceptual del dominio. Entonces los desarrolladores pueden mejorar su implementacin
al incluir vnculos, metainformacin y navegacin adicionales.
El enfoque ARN se organiza en cinco pasos:

Anlisis de los participantes: identifica las diversas categoras de usuario (como se describe en la seccin 18. l) y establece una apropiada jerarqua de par
ticipantes.
Anlisis de elementos: identifica los objetos de contenido y los elementos ft.:
cionales de inters para los usuarios finales (como se describe en las secciones 18.3 y 18.5).
Anlisis de relaciones: describe las relaciones entre los elementos WebApp
Anlisis de navegacin: examina cmo los usuarios pueden acceder a elementos individuales o grupos de elementos.
Anlisis de evaluacin: considera temas pragmticos (por ejemplo: costo/be
neficio) asociados con la implementacin de las relaciones definidas con l.J'terioridad.
Los primeros dos pasos en el enfoque ARN se trataron en prrafos anteriores de e.
te captulo. En las siguientes secciones se consideran mtodos para establecer
relaciones entre los objetos de contenido y las funciones.
18.7.1
Yoo
Anlisis de relaciones: preguntas clave
y Bieber [YOOOO] sugieren una lista de preguntas que un ingeniero Web o ar
lista de sistemas deben responder acerca de cada elemento (objeto de contenid1..
8 Se debe sealar que el ARN es aplicable a cualquier sistema de informacin y originalmente se

sarroll para los sistemas hipermedia en general. Sin embargo, es posible adaptarlo muy bien
ingeniera Web.
CAPTULO 18
56 1
funcin) identificado dentro del modelo de anlisis. La siguiente lista, adaptada para WebApps, es representativa [YOOOOJ :
El elemento es miembro de una categora de elementos ms amplia?
Qu atributos o parmetros se han identificado para el elemento?
Ya existe informacin descriptiva acerca del elemento? Si es as, dnde est?
El elemento 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 elemento es miembro de una coleccin de elementos mayor? Si es as,
cul es y cul es su estructura?
Al elemento lo describe una clase de anlisis?
Otros elementos son similares al elemento considerado? Si es asi, es posible
que pudieran combinarse en un elemento?
El elemento se usa en un ordenamiento especfico de otros elementos? Su
aparicin depende de otros elementos?
Otro elemento siempre sigue a la aparicin del elemento considerado?
Qu condiciones previas y posteriores se deben satisfacer para utilizar el elemento?
Categoras de usuario especficas aprovechan al elemento? Las diferentes
categoras de usuario emplean de manera diferente al elemento? Si es as,
cmo?
El elemento puede estar asociado con una meta u objetivo de formulacin
especfico? Con un requisito WebApp especfico?
Este elemento siempre aparece al mismo tiempo que aparecen otros elementos? Si es asi, cules son los otros elementos?
Este elemento siempre aparece en el mismo lugar (por ejemplo, misma ubicacin de la pantalla o pgina) que otros elementos? Si es as, cules son los
otros elementos?
Las respuestas a stas y otras preguntas ayudan al ingeniero Web a posicionar el elemento en cuestin dentro de la WebApp y a establecer relaciones entre elementos.
Es posible desarrollar una relacin taxonmica y categorizar cada relacin identificada 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 elementos se han desarrollado. relaciones definidas dentro del
modelo de anlisis, el ingeniero Web debe considerar los requisitos que dictan cmo
navegar cada categora de usuario de un elemento (por ejemplo, objeto de cante-
562
PARTE TRES
APLICACIN DE LA lNGENJEruA WEB
nido) a otro. Los mecanismos de navegacin se definen como parte del diseo. En
esta etapa, los desarrolladores deben considerar requisitos de navegacin globales.
Las siguientes preguntas se deben plantear y responder:
Qu pre
guntas se
deben plantear
para comprender
mejor los requisl
tos de navega
ci6n?
Ciertos elementos deben ser ms fciles de alcanzar (es decir, requieren menos pasos de navegacin) que otros? Cul es la prioridad de presentacin?
Ciertos elementos deben resaltarse para forzar a los usuarios a navegar en
su direccin?
Cmo se manejarn los errores de navegacin?
La navegacin hacia grupos de elementos 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 elementos se deben presentar a los usuarios con base en el contexto
de acciones de navegacin previas?
El acceso a la navegacin debe mantenerse para los usuarios?
En cada punto de la interaccin del usuario debe estar disponible un mapa o
Mientras se analizan
los requisitos de navegacin, recurdese
que el usuario siempre
debe sober dnde
est y odnde va.
Poro lograrlo el
usuario necesito un
mapa.
men de navegacin completo (en oposicin a un simple vnculo de "retroceso" o puntero dirigido)?
El diseo de la navegacin debe nutrirse de los comportamientos de usuario
ms comnmente esperados o mediante la importancia percibida de los elementos 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 manejarn los vnculos externos a la WebApp? Superponiendo la
ventana de navegador existente? Cmo una nueva ventana de navegador1
Cmo un marco separado?
stas y muchas otras preguntas se deben plantear y responder como parte del ana
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 elementos ms importantes (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 definidos de dichos elementos (por ejemplo, un usuario tal vez desee acceder a todas las
fotografias de una constmccin especifica o a todas las funciones que permitan e
clculo del peso)?
CAPTULO 18
MODELADO DE ANLISIS PARA APUCAOONES WEB
563
La formulacin, la recopilacin de requisitos y el modelado de anlisis se llevan a cabo como parte del anlisis de requisitos para las WebApps. El propsito de dichas actividades 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 actividades de modelado. Adems, pueden organizarse en paquetes funcionales, y cada
paquete se valora para garantizar que es comprensible, cohesivo, libremente acoplado y jerrquicamente superficial.
Cuatro actividades de anlisis contribuyen a la creacin de un modelo de anlisis
completo: el anlisis de contenido identifica todo el espectro de contenido que proporcionar la WebApp; el anlisis de interaccin describe la forma en la que el usuario interacta con la WebApp; el anlisis de funciones define las operaciones que se
aplicarn al contenido de la WebApp y describe otras funciones de procesamiento
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 modelo de contenido describe el espectro de los objetos correspondientes que
sern incorporados en una WebApp. Dichos objetos de contenido se deben desarrollar o adquirir para integrarlos en la arquitectura de la WebApp. Es factible utilizar un
rbol de datos 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 modelo de interaccin se construye con casos de uso, diagramas de secuencia
UML y diagramas de estado UML para describir la "conversacin" entre el usuario y
la WebApp. Adems, se construye un prototipo de la interfaz que auxilie en el desarrollo de la plantilla y los requisitos de navegacin.
El modelo funcional describe las funciones observables para el usuario y las operaciones de clase que emplean el diagrama de actividad UML. El modelo de configuracin describe el ambiente que requerir la WebApp, tanto 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
elementos funcionales, definidos en el modelo de anlisis, y establece requisitos para definir vnculos de navegacin apropiados a travs del sistema. Una serie de preguntas ayudan a establecer relaciones e identificar caractersticas que influirn sobre el diseo de navegacin.
[CONOOJ Conallen, J., Building Web Applications w1th UML, Addison-Wesley, 2000.
[F. .AOIJ Franklin, S., "Planning Your Web Site with UML", webReview, disponible en
http:/ /www.webreview.com/2001 /05_18/ de\'elopers/ indexo l .shtml.
564
PARTE TRES
[SRJOI] Sridhar, M. y N. Mandyam, "E!Tective Use ofData Models in Building Web Applications
2001, disponible en http://www2002.org/CDR0M/alternate/698/.
[Y0099] Yoo, J. y M. Bieber, "A Systematic Relationship Analysis for Modeling lnformation Domains", 1999, se puede descargar de http://citeseer.nj.nec.com/312025.html.
[YOOOOJ Yoo, J. y M. Bieber, "Toward a Relationship Navigation Analysis", en Proc. 33rd Hawai:
Conf on ~stem Sdences, vol. 6, IEEE, enero de 2000, se puede descargar de www.cs.njit.edu/-bieber /pub/hicss00/INWEB02 .pdf.
18. 1 Con base en el gran abanico de recursos acerca del desarrollo de software gil disponib.e
en la Web, investguese un poco y establzcase un razonamiento en contra del modelado de
anlisis para las WebApps. Se considera que la argumentacin resultante se aplica en todos 10!:
casos?
18.2 Si fuese forzoso a llevar a cabo un "modelado de anlisis ligero" (es decir, modelado de
anlisis mnimo), qu representaciones, diagramas e informacin se definiran durante esta ac
tividad de ingeniera Web 7
18.3 Mediante un diagrama similar al mostrado en la figura 18.1, establzcase una jerarqua ....
usuario para (a) un sitio Web de servicios financieros o (b) un sitio Web de venta de libros.
18.4 Qu representa un paquete de caso de uso?
18.5 Los casos de uso o los paquetes de caso de uso se valoran para garantizar que son cor
prensibles, cohesivos, libremente acoplados y jerrquicamente superficiales. Descn1>ase con pa;.;:

bras propias qu significan estos trminos.
Elijase una WebApp que se visite regularmente de una de las siguientes categoras: (a) notia.;:.
o deportes, (b) entretenimiento, (c) comercio electrnico, (d) juegos, (e) relacionados con
computacin, (f) una WebApp que recomienden los profesores. Reallcense las actividades in;.
cadas en los problemas del 18.6 al 18.12:
18.6 Desarrllense uno o ms casos de uso que describan un comportamiento de usuario c;.pecifico para la WebApp.
18. 7 Represntese una jerarqua de contenido parcial y deflnanse al menos tres clases de ar.
lisis para la WebApp.
18.8 Desarrllese un diagrama de secuencia UML y un diagrama de estado UML que descr:
una interaccin especifica con la WebApp.
18.9 Considrese la interfaz existente de la WebApp. Hgase un prototipo de cambio a la in~
faz que se considere susceptible de mejorar.
18.10 Elijase una funcin observable para el usuario que ofrezca la WebApp y modlese C'
diante un diagrama de actividad UML.
18.11 Eljase un objeto de contenido o funcin que sea parte de la arquitectura de la Web,,,y respndanse las preguntas relacin-navegacin mencionadas en la seccin 18. 7.1.
18.12 Considrese la WebApp existente y respndanse las preguntas relacin-navegac:
mencionadas en la Seccin 18.7.2.
Muchos libros dedicados al modelado de anlisis para software convencional (con partiu..
nfasis en los casos de uso y la notacin UML) contienen mucha informacin til susceptible
adaptarse fcilmente a la ingeniera Web. Los casos de uso forman los cimientos del mode
CAPTULO 18 MODELADO DE ANUSIS PARA M'UCAClONES WEB
565
de anlisis para \as WebApps. Los libros de Ku\ak. y sus colegas (Use Cases: Requirements tn Con
text, segunda edicin, Addison-Wes\ey. 2004), Bittner y Spence (Use Case Modeling, AddisonWesley, 2002), Cockbum (Wriling Ejfective Use Cases. Addison-Wesley, 2001), Armour y Miller
(Advanced Use-Case Modeling: Software .systems, Addison-Wesley, 2000), Rosenberg y Scott (Use
Case Driven Object Modeling with UML. A Practica/ Approcah, Addison-Wesley, 1999) y Schneider,
Winters y Jacobson (Applying use Cases: A practica/ Guide, Addison-Wesley, 1998) ofrecen una
gua valiosa en la creacin y empleo de este importante mecanismo de representacin de requisitos. Valiosas discusiones de UML han escrito Arlow y Neustadt (UML and lhe Unijied Process,
Addison-Wesley, 2002), Schmuller (Teach Yourself UML, Sams Publishing, 2002), Booch y sus colegas (The UML User Guide, Addison-Wesley, 1998), y Rumbaugh y sus colegas (The Unijied Modeling Language Reference Manual, Addison -Wesley, 1998).
Los libros dedicados al diseo de sitios Web con frecuencia contienen uno o dos captulos
que abordan temas de anlisis (aunque usualmente son discusiones superficiales). Los siguientes libros contienen uno o ms aspectos del anlisis dentro del contexto de la ingeniera Web:
Van Duyne y sus colegas (The Design of Sites, Addison-Wesley, 2002). Rosenfeld y Morville (lnfo1mation Archilecturefor lhe World Wide Web, O'Reilly & Associates, 2002), Wodtke (Tnformation
Architecture, New Riders Publishing, 2002), Garret (The Elements of User Experience: User Centered Design Jor the Web, New Riders Publishing, 2002), Niederst (Web Design in a Nutshe/1, O'Reilly
& Associates, 2001), Lowe y Hall (Hypertext and the Web: An Engineering Approach. Wilev, 1999),
y Powell (Web Site Engineering, Prentice-Hall, 1998) ofrecen una cobertura razonablemente
completa. Norris, West y Watson (Media Engineering: A Guide lo Developing Information Products,
Wiley, 1997), Navarro y Khan (Ejfective Web Design: Master lhe Essentials, Sybex, 1998) y Fleming
y Koman (Web Navigation: Designing the User Experience, O'Reilly & Associates, 1998) proporcionan gua adicional para anlisis y diseo.
En Internet hay disponible una gran variedad de fuentes de informacin acerca del modelado de anlisis para ingeniera Web. Una lista actualizada de referencias en la World Wide Web
se encuentra bajo "sol:ware engineering resources" en el sitio Web de SEPA:
CONCUTOS
CLAVE
arquted111a: dt
COllftni~Q , , ,
,586
tqllitectufG
MVC ... .... .$89
atrlliuos
n's u auto~zado_ libro acerca del dse:Web,.Jak~b ~else~ [NlEOO! a~IT.1E.

"En esencia~existen dos enfoques bsicos del diseno: el ideal artstico
.
expresarse uno mismo y el ideal de ingeniera de resolver un problema .
ra un cliente''- Our<1nte la primera dcada del desarro)lo Web, la Idea artstica
el enfoque que eligieron muchos desarrolladores, El diseo ocurri en una fo
ad hoc y usualmente era dii:igdo conforme se generaba el HTML, Ei diseo e~
lucin de una vhin artistica que en s misma evolucion confonne acuni
de,<alkW .$69
construccin de la We.bApp.
dis.eo al ni.ni 1ft

tomponentes 593
Incluso en la a:ctualidad, los ctefenso,res "radicalw' del desarrono de soft\i

gil (captulo 4J utilizan tas aplicaciones Web como car:tel de nios para "dis,_
Umitado". Argumentan que la inmediatezy la volatilidad de las WebApps _
nan el dsefl<1 fonnat que el diseo evoluciona conforme se construye (cod::':
ca} una aplicacin y ge se debe gastar reJativamente poco t~npo en la e
cin de up modelo d~ diseo detallaao, :s.ste argumentO' tiene merit, pero
par,a WebAp,ps relativamente sbnples. cuando el contenido y la funcin son
plejos, cu~ndo el tamao de la Web,App abarca cientos de objetos de conten
funciones y clases de anlisis, cuando el ,c:ito de la WebApp tendr un im
directo sobre el xt6 del 11egoqo, el diseo no puede r debe ser tomado a la
'
gera.
Esta realil,ad conduce at segUttdo enfoqu.e de Nielsen; "el ideal de inge
de resolver un problema para un cliente1. La ingeniera Web adopta esta ti
fia, y un enfoque tn; ri~roso del diseo Web,App permite a los desarrollad
,
lograrlo. ,
dlsefio
ircult<t~ 585
diseo
de.fiQnJe~ S84
clls
de la hiterfu .J73
diseo
de IMl'ltgacin .590
diseo esttko .582
MDHOO . ..595
mtricos ... 598
patrone, ... .S94
'
CAPTULO 19
MODELADO DE DISEO PARA APUCACJONES WEB
561
Cuando se aplica el diseo dentro del contexto de la ingeniera Web, se deben considerar cuestiones tanto genricas como especficas. Desde un punto de vista genrico, el diseo resulta en un modelo que gua la construccin de la WebApp. El modelo
de diseo, sin importar su forma, debe contener suficiente informacin para reflejar
cmo habrn de traducirse los requisitos de los participantes (definidos en un modelo de anlisis) en contenido y cdigo ejecutable. Pero el diseo tambin debe ser especfico. Debe abordar atributos clave de una WebApp en una forma que permita al
ingeniero Web construir y ponerla a prueba de manera efectiva.
19.1. l
Diseo y calidad de una WebApp
En captulos anteriores se seal que el diseo es la actividad de ingeniera que conduce a un producto de gran calidad. Esto conduce a una pregunta recurrente que se
presenta en toda las disciplinas de ingeniea: qu es calidad? En esta seccin se examinar la respuesta en el contexto de la ingeniera Web.
Toda persona que haya navegado en la Web o usado una Intranet corporativa tiene una opinin acerca de lo que hace una "buena" WebApp. Los puntos de vista individuales varan enormemente. Algunos usuarios disfrutan los grficos que bailan.
otros quieren texto simple. Algunos solicitan informacin copiosa. otros desean una
presentacin abreviada. A algunos les gustan las herramientas analticas sofisticadas o
los accesos a las bases de datos, a otros les gustan las cosas simples. De hecho, la percepcin del usuario de lo que es "bueno" (Y la resultante aceptacin o rechazo de la
WebApp como consecuencia) puede ser ms importante que cualquier discusin tcnica de la calidad de la WebApp.
568
PARTE TRES APLICACIN DE 1A INGENIERA WEB
Pero cmo se aprecia la calidad de la WebApp? Qu atributos debe exhibir para lograr ser buena a los ojos de los usuarios finales y al mismo tiempo mostrar las
caractersticas tcnicas de calidad que permitirn a un ingeniero Web corregir, adaptar, mejorar y apoyar la aplicacin a largo plazo?
En realidad, todas las caractersticas generales de la calidad de software tratadas
en los captulos 9, 15 y 26 se aplican a la WebApps. Sin embargo, las ms relevantes de dichas caractersticas -facilidad de uso, funcionalidad, confiabilidad, eficiercia y facilidad de mantenimiento- proporcionan una base til para valorar la calidac.
de los sistemas basados en Web.
-si los prOdU<tos se di$eon paro enaijar mejor en las tendencias naturales del <omportllmi.nlo hul'QOII01 '"'8n<lls ..
- tsler ms solisfed101 ms <ompleto yser ms productivo."
Olsina y sus colegas [OLS99] han preparado un "rbol de requisitos de calida

que identifica un conjunto de atributos tcnicos - facilidad de uso, funcionalida.:.
confiabilidad, eficiencia y facilidad de mantenimiento- que conducen a WebApps c...
gran calidad. 1 La figura 19. l resume su trabajo. Los criterios anotados en la figo;-:
son de particular inters para los ingenieros Web que deben disear, construir
mantener las WebApps a largo plazo.
Offutt [OFF02] extiende los cinco principales atributos de calidad anotados en
figura 19. l al agregar los atributos siguientes:
UM/llI
rbol de
requisitos de
calidad [OI.599).
Comprensibilidad global del sitio

Caractersticos de retroalimentacin en lneo y ayudo
Caractersticos de lo interfaz y esttica
Caractersticos especiales
Facilidad de uso
Capacidades de bsqueda y recuperacin

Caractersticos de navegacin y visualizacin
Caractersticos de lo aplicacin relacionados con el dom -
Funcionalidad
Calidad
de lo
aplicacin Web
Confiabilidad
----==-=====
- - - - - Correcto procesamiento de vnculos

Recuperacin de errores
Validacin y recuperacin de entrado de usuario
~ Desempeo en tiempo de respuesto
Eficiencia
--======e::::===== Rapidez
de generacin de pgina
Rapidez de generacin de grficos
Facilidad de
mantenimiento
.C::::::::
Fcil de corregir
Adopta~ildod
Extens,b,lidod
Estos atributos de calidad son 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.
CAPTULO 19
MODELADO DE DISENO PARA APUCAOONES WEB
569
Seguridad. Las WebApps se han convertido en una parte integral de las bases de
datos cruciales del gobierno y las empresas. Las aplicaciones de comercio electrnico extraen y luego almacenan informacin confidencial de los clientes. Por stas y
muchas otras razones, la seguridad de las WebApps es primordial en muchas situaciones. La medida clave de la seguridad es la habilidad de la WebApp y su ambiente
de servidor de rechazar el acceso no autorizado e impedir un franco ataque malvolo. Un anlisis detallado de la seguridad WebApp est ms all del alcance de este
libro. El lector interesado debe consultar [MCCOl]. [NOR02J o [KAL03J.
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 porcentaje del tiempo que una WebApps est disponible para usarla. El usuario
final comn espera que las WebApps estn disponibles las 24 horas de todos los das
del ao. Algo menos es considerado inaceptable.2 Pero "a tiempo" no es el nico indicador de disponibilidad. Offutt [OFF02] sugiere que "usar caractersticas disponibles slo en un navegador o una plataforma" hace que la WebApp no est disponible para quienes tengan una configuracin de navegador y plataforma diferente. El
usuario invariablemente se ir a otra parte.
Escalabilidad. La WebApp y su ambiente de servidor pueden escalarse para manejar 100, 1 000, 10 000 o 100 000 usuarios? La WebApp y los sistemas con los cuales est conectada manejan 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 volverse todava ms exitosa.
'Iiempo 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 punto de vista de los negocios. La primera WebApp en el mercado usualmente captura un nmero desproporcionado de usuarios finales.
Cientos de miles de pginas Web estn disponibles para quienes busquen informacin en la World Wide Web. Incluso las bsquedas Web mejor dirigidas resultan en
una avalancha de contenido. Con tantas fuentes de informacin de las cuales elegir,
cmo valora el usuario la calidad (por ejemplo, veracidad, precisin, integridad,
oportunidad) del contenido que se presenta dentro de una WebApp? Tillman [TILOOJ
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 necesidades del usuario?
2 Desde luego, esta expectativa es irreal Las grandes WebApps deben planificar el "periodo de inactividad" para reparaciones y actualizaciones.
570
Llsta de verificacin de la calidad del diseo de la WebApp

La siguiente listo de verificacin, adoptado de
la informacin presentado en Webreference.
com, proporciono un conjunto de preguntas que ayudarn
los tablas estn organizados y dimensionados en uno

formo que los hoce comprensibles y que se desplieguer
eficientemente?
tonto o los ingenieros Web como o los usuarios finales o

valorar lo calidad global de uno WebApp:
El HTMl est optimizado poro eliminar ineficiencias?

El d' - 1 bol d 1 , fo 1 1 1
1
,seno g o
e o pagino c, ,to o ecturo y o navegacin?
El contenido, la funcin o las opciones de navegacin

pueden ajustarse o las preferencias del usuario?
El contenido o lo funcionalidad se pueden personalizar
al ancho de bando en el cual se comunico el usuario?
Las grficas y los otros medios que no son textuales se
han usado de manero apropiado? El tamao de los archivos grficos est op~mizado poro que se desplie
guen con eficiencia?
Qu se
debera
considerar cuan
do se valore el
contenido de ca
hdad?
Todos los punteros (vnculos) proporcionan vnculos oo:informocin interesante poro los usuarios?
Es probable que lo mayora de los vnculos persistan
en lo Web?
lo WebApp est instrumentada con util idades de g~tin del sitio que incluyan herramientas para rastrear s..
uso, pruebo de vnculos, bsqueda local y seguridod?
Los antecedentes y la jerarqua de los autores del contenido se pueden identificar fcilmente?
Es posible determinar la precisin del contenido, la ltima actualizacin y
que fue actualizado?
El contenido y su ubicacin son estables (es decir, permanecern en la UR....
de referencia) 7
Adems de estas preguntas relacionadas con el contenido, se pueden aadir las
guientes:
El contenido es creble 7
El contenido es nico? Esto es, la WebApp proporciona algn beneficio ....
coa quienes la usen?
El contenido es valioso para la comunidad de usuarios a que se dirige?
El contenido est bien organizado? Est en un ndice? Es fcilmente acc
sible?
La lista de verificacin anotada en esta seccin slo representa una pequea m-
tra de los asuntos que deben abordarse conforme evolucione el diseo de una Web
Una meta importante de la ingeniera Web es desarrollar sistemas en los que se porcionen respuestas afirmativas a todas las preguntas relacionadas con la cah"'
CAPTULO 19
MODELADO DE DISEO PARA APUCACIONES WEB
571
19.1.2 Metas de diseo

En su columna regular acerca del diseo Web Jean Kaiser [KAI02) sugiere las s1
guientes metas de diseo, que son aplicables virtualmente a toda WebApp sin importar el dominio, tamao 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.
Consistencia. Esta meta de diseo se aplica virtualmente a cada elemento del

modelo de diseo. El contenido se debe construir de manera consistente (por ejemplo, el formato del texto y los estilos de fuente deben ser los mismos a lo largo de todos los documentos de texto; el arte grfico debe tener una apariencia consistente,
esquema de color y estilo). El diseo grfico (esttica) debe presentar una apariencia 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 mecanismos de navegacin deben usarse de manera consistente
a travs de todos los elementos de la WebApp.
Identidad. La esttica, la interfaz y el diseo de navegacin de una WebApp deben 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 sentido diferente al de una WebApp diseada para una compaa de servicios financieros. 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 contribuyentes de diseo) deber trabajar para establecer una identidad para la WebApp por medio del diseo.
Robustez. Con base en la identidad establecida, usualmente una WebApp hace

una "promesa" implcita al usuario. El usuario espera contenido y funciones robustas que sean relevantes para sus necesidades. Si dichos elementos estn perdidos o
son insuficientes es probable que la WebApp fracase.
Navegabilidad. Ya se ha sealado que la navegacin debe ser simple y consistente. Tambin debe estar diseada de modo que sea intuitiva y predecible. Esto es, el
usuario debe entender 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 estticas. Es indudable que la belleza (aparien._ a visual) est en el ojo del observador, pero
muchas caractersticas de diseo (por ejemplo. la apariencia y sentido del conteni
572
PARTE TRES APJJCACIN DE LA INGENIERA WEB
do, la plantilla de la interfaz, la coordinacin del color, el equilibrio del texto, los gu
ficos y otros medios audiovisuales, los mecanismos de navegacin) s contribuyen aspecto visual.
Compatibilidad. Una WebApp se utilizar en una diversidad de ambientes
(p:
ejemplo, diferentes equipos, tipos de conexin a Internet, sistemas operativos, na\

gadores) y se debe disear para que sea compatible con cada uno.
"'Para ali,uitos, el diseo Web se enfoco en lo apariencia y sentido visuales... paru blros, el diseo We~ tralu de la es-
........
trut1~ nfotlllodn y la nav.egacin a travs del espacio del dO<\Jmenta. Otros indU5C> pueden timidel'Qr que
"ttl' ~ Web trllta Ocet'CO de lo Jecnolog~ empleado para construir apli<O(iones Web interoctvas. & reald~ al &
RO incluye fOdqs e$10S foctotes y acoso mas."
.
--,
'lo.'
CLAVE
Lo IWeb abarco seis
diferentes tipos de
diseo. Codo uno
contTibuye olo calidad
global de lo WebApp.
Qu es diseo en el contexto de la ingeniera Web? Esta pregunta simple es ms

ficil de responder de lo que uno puede creer. El diseo conduce a un modelo
contiene la mezcla adecuada de esttica, contenido y tecnologa. La mezcla var
dependiendo de la naturaleza de la WebApp, y, como consecuencia, las activid
de diseo tambin variarn .
La figura 19.2 muestra una pirmide de diseo para la ingeniera Web. cada r
de la pirmide representa una de las siguientes actividades de diseo:
Diseo de la interfaz: describe la estructura y organizacin de la interfaz de
usuario. Incluye una representacin de la plantilla de pantalla, una defi.ruc._.:_
de los modos de interaccin y una descripcin de los mecanismos de na\e.
cin.
Diseo esttico: tambin llamado diseo grfico, describe la "apariencia y
sentimiento" de la WebApp. Incluye esquemas de color, plantilla geomtrc
tamao de texto, fuente y ubicacin, uso de grficos y decisiones estticas
lacionadas.
Diseo de contenido: define la plantilla, la estructura y el bosquejo de todc
contenido que se presenta como parte de la WebApp. Establece las relacicr
entre los objetos de contenido.
Diseo de navegacin: representa el flujo de navegacin entre los objetos
contenido y para todas las funciones de la WebApp.
Diseo arquitectnico: identifica la estructura hipermedia global para la
WebApp.
Diseo de componentes: desarrolla la lgica de procesamiento detallado e;
se requiere para implementar componentes funcionales.
En las secciones que siguen se consideran con mayor detalle cada una de e,
actividades de diseo.
CAPTULO 19
573
MODELADO DE DISEO PARA APUCAOONES WEB
Diseo de navegacin
Diseo arquitectnico
Diseo de componentes
tecnologa
Toda interfaz del usuario -ya sea diseada para una WebApp, una aplicacin de
soflware tradicional, un producto de consumo o un dispositivo industrial- debe presentar 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 mtodos
de diseo de la interfaz brindan al ingeniero Web las herramientas requeridas para
lograr esta lista de atributos.
En el capitulo 12 se observ que el diseo de la interfaz comienza no con una
consideracin de la tecnologa, sino ms bien con un cuidadoso examen del usuario
final. Durante el modelado de anlisis para la ingeniera Web (Captulo 18), se desarrolla una Jerarqua de usuario. Cada categora de usuario puede tener necesidades
sutilmente diferentes, tal vez quiera interactuar con la WebApp en diferentes formas
y quiz requiera funcionalidad y contenido nicos. Esta informacin se deriva durante el anlisis de requisitos, pero se revisa como el primer paso en el diseo de la interfaz.
"Si un sitio ts perfedomente utilizable pero carece de un esh1o de diseo elegante yadecuado, fracosar.
Cwt Oollilpr
Dix fD1X99J argumenta que un ingeniero Web debe disear una interfaz de modo
que responda tres preguntas primanas para el usuario final:
La mayora de, si no es que todas, las ctirec:triCcs prcsentaas en el capitulo 12 se aplican igualmen-
te al diseo de interfases WebApp S1 todava no Ice d capinto 12, ha11ato en este momento.
574
Si es probable que los

usuarios puedan en
tror osu WebApp en
varios ubicaciones y
niveles en lo erorquo
de contenido, asegrese de disear codo
pgina con coracters
ticos de navegacin
que conduzcan o/
usuario olos otros
puntos de inters.
Dnde estoy? La interfaz debe 1) ofrecer una indicacin de que se ha tenido acceso a la WebApp4 y 2) informar al usuario de su ubicacin en la jerarqua de contenido.
Qu puedo hacer ahora? La interfaz siempre debe ayudar al usuario a entende.
sus opciones actuales: qu funciones estn disponibles, qu vnculos estn vivos
qu contenido es relevante.
Dnde he estado, a dnde voy? La interfaz debe facilitar la navegacin. En consecuencia, debe proporcionar un "mapa" (implementado en una forma fcil de entender
de dnde ha estado el usuario y qu rutas puede tomar para moverse a cualquie
parte dentro de la WebApp.
La interfaz de una WebApp efectiva debe proporcionar respuestas a cada una de es-
tas preguntas conforme el usuario final navega a travs del contenido y la funcioru.
lidad.
19.3. 1 Principios y directrices del diseo de la interfaz

Bruce Tognozzi [TOGOl] define un conjunto de caractersticas fundamentales q:
deben presentar todas las interfaces y, al hacerlo, establece una filosofia que dei:-
--,
Q'
C~VE
Uno buenointerfaz
WebApp escomprensible e indulgente, y
ofrece al usuorio uno
sensacin de control.
seguir todo diseador de interfaz de WebApp:

Las interfaces efectivas son visualmente aparentes e indulgentes, e implantan en sus
usuarios una sensacin de control. Los usuarios ven rpidamente la envergadura de sus or
d ones, comprenden cmo lograr sus metas y hacen su trabajo.
Las interfaces efectivas no preocupan al usuario con los trabajos internos del sistema
El trabajo se guarda de manera cuidadosa y continua, con la opcin total de que el usuario deshaga cualquier actividad en cualquier tiempo.
Las aplicaciones y servicios efectivos realizan un mximo de trabajo mientras demandan un mnimo de informacin a los usuarios.
Con la finalidad de disear interfaces que muestren dichas caractersticas, ~nozzi [TOGOl] identifica un conjunto de principios de diseo primordiales:
Anticipacin. una WebApp se debe disear de modo que anticipe el siguiente w

miento del usuario. Por ejemplo, considere una WebApp de soporte al cliente de
rrollada para un fabricante de impresoras para computadora. Un usuario ha solici:
un objeto de contenido que presenta informacin acerca de un controlador de
presora para un sistema operativo lanzado recientemente. El diseador de
WebApp debe anticipar que el usuario pueda solicitar una descarga del controla.:.
4 Todas las personas han marcado alguna pgina de un sitio Web, slo para volver a visitarla m.:::
de y no tener que dar indicaciones del sitio Web o del contexto de la pgina (asi como para e
moverse hacia otra ubicacin dentro del sitio) .
5 Los principios originales de Tognozzi se han adaptado y extendido con el fin de aprovechar!.
este libro. Vase [TOGOIJ para mayores detalles acerca de estos principios.
CAPTULO 19 MODELADO DE DISEO PARAM'I.ICACIONES WEB
575
y debe proporcionar facilidades de navegacin que permitan hacerlo sin solicitarle al

usuario una bsqueda de esta capacidad.
Comunicacin: la interfaz debe comunicar el estado de cualquier actividad que haya

iniciado el usuario. La comunicacin puede ser obvia (por ejemplo, un mensaje de
texto) o sutil (por ejemplo, una hoja de papel que se mueva a travs de una impresora para indicar que la impresin est en camino). La interfaz tambin debe comunicar el estado del usuario (por ejemplo, la identificacin del usuario) y la ubicacin
dentro de la jerarqua de contenido de la WebApp.
Consistencia: el uso de los controles de navegacin, mens, conos 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 contenido nunca debe incorporar texto subrayado en azul que no implique un vinculo. Toda 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 navegacin establecidas para la aplicacin. Por ejemplo, la navegacin hacia porciones
seguras de la WebApp se deben controlar con la identificacin del usuario y su contrasea, y no debe existir mecanismo de navegacin que permita al usuario dar la
vuelta a dichos controles.
Eficiencia: el diseo de la WebApp y su interfaz deben optimizar la eyiciencia laboral

del usuario, no la eficiencia del ingeniero Web que la disea y la construye o el ambiente cuente-servidor que la ejecuta. Tognozzi [TOGO I] seala esto cuando escribe: "Esta simple verdad es por lo que es importante para todos los involucrados en un proyecto de software el apreciar la importancia de hacer propia la meta de productividad del usuario y entender la diferencia vital entre construir un sistema eficiente y
fortalecer a un usuario eficiente."
Flexibilidad: la interfaz debe ser Jo suficientemente flexible como para permitir que algunos usuarios realicen tareas directamente y otros exploren la WebApp en una forma
un tanto aleatoria. En todo caso, debe permitirle al usuario entender 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? 1Porque 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 [TOGO I J seala que la nica forma de garannzar que las expectativas del usuario se comprendan adecuadamente es mediante una amplia~ por parte del usuario (captulo 20).
PARTE TRES
576
Ley de Fitt: "El tiempo para adquirir un objetivo es una funcin de la distancia a fa que
se halla y de su tamao" [TOGO I J. Con base en un estudio realizado en la dcada dt:
1950 [FIT54), la ley de Fitt "es un mtodo 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 objetivd' [ZHA02). Si una tarea del usuario define una secuencia de selecciones o entrada:
estandarizadas (con muchas opciones diferentes dentro de la secuencia), la primer.:
seleccin (por ejemplo, seleccin de ratn) debe estar fisicamente cerca de la siguierte seleccin. Por ejemplo, considere la interfaz de la pgina de inicio de una WebAp:en un sitio de comercio electrnico que vende aparatos electrodomsticos.
Cada opcin del usuario implica un conjunto de elecciones o acciones de segu:.
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
Ullli~ffllo
W~bd-rirlltD
li!$riis~es;
poi
paqWts,
1ntlllfmes v
Aelen~
.........
oCOM,DCOMy
libreos tipo en
a&
gora del producto (por ejemplo, equipo de audio, televisores, reproductores de DV::
aparece como un men desplegable tan pronto como se selecciona "comprar un pr~
dueto". En consecuencia, la siguiente eleccin es inmediatamente obvia (est cerc::;:
y el tiempo para adquirir es despreciable. Si, por otra parte, la eleccin aparece a:
un men ubicado en el otro lado de la pantalla, el tiempo para que el usuario lo a.;,
quiera (Y luego realice la eleccin) ser demasiado.
Objetos de intefaz humana:
se ha desarrollado una gran librera de objetos de inCl:
faz humana reutilizables para WebApps. selas. Es posible adquirir, de varias libre:-
de objetos, cualquier objeto de interfaz que pueda ser "visto, escuchado, tocado o_
algn otro modo percibido" [TOGO l J por un usuario final.
Reduccin de latencia: Ms que obligar al usuario a esperar el fin de alguna
opc.
cin in tema (por ejemplo, descargar una imagen grfica compleja), fa WebApp debe
la multitarea en una forma que permita al usuario proceder con el trabajo como .s:
operacin hubiese sido completada. Adems de reducir la latencia, las demoras det
reconocerse de modo que el usuario comprenda lo que est ocurriendo. Esto inc
ye 1) proporcionar retroalimentacin de audio (por ejemplo, un "clic" o campan
cuando una seleccin no genera una accin inmediata de la WebApp; 2) desple;
un reloj animado o barra de progreso para indicar que el procesamiento est en II'
cha; 3) ofrecer algn entretenimiento (por ejemplo, una animacin o presentacir
texto) mientras ocurra un procesamiento largo.
emejor vicije ~ el que flene el menor nmerode posos. Acorte lo distancia entre ~ usuario ysu lllta."
Facilidad de aprendizaje: La inteifaz de una WebApp se debe disear para min~
el tiempo de aprendizaje y, una vez aprendido, reducir el reaprendizaje requerido cu..
do se vuelve a visitar la WebApp. En general, la interfaz debe acentuar un diseo
ple e intuitivo que organice el contenido y la funcionalidad en categoras obvias ra el usuario.
CAPTULO 19
577
Metforas: una interfaz que utilice una metfora de interaccin es ms fcil de aprender y de usar, en tanto la metfora sea apropiada para la aplicacin y el usuario. Una
metfora debe llamar imgenes y conceptos de la experiencia del usuario, pero no
necesita ser una reproduccin exacta de una experiencia del mundo real. Por ejemplo,
un sitio de comercio electrnico que implementa el pago de cuentas automatizado para una institucin financiera usa una metfora de lista de verificacin (no de manera
sorprendente) para asistir al usuario en la especificacin y la calendarizacin de los
pagos de cuentas. Sin embargo, cuando un usuario "escribe" un cheque, no necesita
ingresar el nombre completo del pagador sino que puede elegir de una lista de pagadores o hacer que el sistema seleccione con base en las primeras letras escritas. La
metfora permanece intacta, pero el usuario obtiene 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 guardarse de manera automtica de modo que no se perder si ocurriese un error Todo mundo
ha experimentado la frustracin asociada con el hecho de completar un gran formulario WebApp slo para que el contenido se pierda debido a un error (que comete el
usuario, la WebApp o la transmisin de cliente a servidor). Para evitar esto la WebApp
se debe disear para autoguardar todos los datos especificados por el usuario.
Legibilidad: toda la informacin presentada a travs de la interfaz debe ser legible para Jvenes y viejos. El diseador de la interfaz debe enfatizar los estilos de letra legible, tamaos de fuente y opciones de fondo de color que mejoren el contraste.
Estado de rastro: Cuando sea adecuado, el estado de la interaccin del usuario debe
rastrearsey almacenarse de modo que un usuario pueda saliry regresar ms tarde al Jugar de donde sali. En general, las cookies se pueden disear para almacenar informacin de estado. Sin embargo, las cookies son una tecnologa controvertida, y otras
soluciones de diseo pueden ser ms aceptables para algunos usuarios.
Navegacin visible: una interfaz de WebApp bien diseada proporciona '1a ilusin de
que los usuarios estn en el mismo lugar, y que se les lleva el trabajo hasta sus lugares"
[TOGOl). Cuando se usa este enfoque la navegacin no es preocupacin del usuario.
En lugar de eso, el usuario recupera objetos de contenido y selecciona funciones que
se despliegan y ejecutan por medio de la interfaz.
La comranad6m
Doug: Vinod, el equipo y t tuwNrt:iri.i
revisa,; el proeolipo de la inllrfaz ele

ele HogarSegurolnc.com,
Vanocl: Si . todos lo exparim&N1w
578
PARTE TRF.S
Cuando selecciones MIIG

~ N > . . MIC:11~
opciones:
Nielsen y Wagner [NIE96] sugieren unas cuantas directrices pragmticas en e: .

seo de interfases (basados en su rediseo de una gran WebApp) que proporcior:
un buen complemento a los principios sugeridos prrafos atrs en esta seccin.
La rapidez de lectura en un monitor de computadora es aproximadamente 2
por ciento ms lenta respecto de la lectura en impresos. En consecuencia, l'I

fuerce al usuario a leer voluminosas cantidades de texto, en particular cuan-_
se explica la operacin de la WebApp o se ofrece ayuda en la navegacin.
Evite los signos de "en construccin", crean expectativas y provocan un vnet=:
innecesario que es seguro para la decepcin.
Los usuarios prefieren no desplazarse. La informacin importante debe esta:
dentro de las dimensiones de una ventana tpica de navegador.
Los mens de navegacin y los encabezados deben estar diseados de mant.
ra consistente y deben estar disponibles en todas las pginas que estn dispc
CAPTULO 19
579
nibles para el usuario. El diseo no debe descansar en las funciones del navegador para asistir en la navegacin.
La esttica nunca debe sustituir la funcionalidad. Por ejemplo, un simple botn puede ser una mejor opcin de navegacin que una imagen o un icono
estticamente placenteros pero vagos, cuya intencin no es clara.
Las opciones de navegacin deben ser obvias, incluso para el usuario casual.
El usuario no debe tener que buscar en la pantalla para determinar cmo vincularse con otro contenido o servicio.
Una interfaz bien diseada mejora la percepcin del usuario del contenido o servicios que proporciona el sitio. No necesariamente tiene que ser ostentosa, sino que
siempre debe estar bien estructurada y ergonmicamente saludable.
, t,gtAle ti... muy poco paciencia con los sitios WWW pobrementediseados."
Jakob Nlels y ~ W...
19.3.2 Mecanismos de control de la interfaz

Los objetivos de la interfaz de una WebApp son 1) establecer una ventana consistente con el contenido y la funcionalidad que proporciona, 2) guiar al usuario a travs
de una serie de interacciones con la WebApp, y 3) organizar las opciones de navegacin y el contenido disponible para el usuario. Lograr una interfaz consistente requiere que el diseador use primero el diseo esttico (seccin 19.4) con el fin de establecer una "apariencia" coherente para la interfaz. Esto abarca muchas caractersticas, pero debe subrayar la plantilla y la forma de los mecanismos de navegacin.
Para guiar la interaccin del usuario, el diseador de la interfaz puede emplear una
metfora apropiada 7 que permita al usuario adquirir una comprensin intuitiva de la
interfaz. Las opciones de navegacin las implementa el diseador seleccionando de
entre varios mecanismos de interaccin:
Mens de navegacin: mens clave (organizados vertical u horizontalmente)

que mencionan contenido o funcionalidad clave. Dichos mens se pueden implementar de modo que el usuario pueda elegir de una jerarqua de subtemas
que se despliegan cuando se selecciona la opcin de men primario.
Iconos grficos: botn, interruptores e imgenes grficas similares que permiten al usuario seleccionar alguna propiedad o especificar una decisin .
Imgenes grficas: alguna representacin grfica que el usuario pueda seleccionar y que implemente un vnculo hacia un objeto de contenido o funcionalidad de la WebApp.
7
En este contexto, una metfora es una representaan fexlraida de la experiencia del mundo real del
usuario) que puede modelarse dentro del contexto de la interfaz Un ejemplo simple puede ser un
interruptor deslizable con que se controla el volumen audiuvo de un archivo .mp3.
580
PARTE TRES
Es importante anotar que uno o ms de dichos mecanismos de control debe propcionarse en cada nivel de la jerarqua de contenido.
19.3.3 Flujo de trabajo en el diseo de la interfaz
Aunque un anlisis detallado del diseo de la interfaz para WebApps es mejor deiz.;
lo a libros de texto que se dedican a la materia (por ejemplo, [GAL02J, [RASOC
[NIEOO]), vale la pena echar un vistazo a las tareas de diseo clave. En el captulo
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 tare
del usuario, se crean y analizan sus escenarios (casos de uso) para definir un ejunto de objetos y acciones de interfaz. Este trabajo se representa como parte
modelo de anlisis de la WebApp tratado en el captulo 18.
Las siguientes tareas representan un flujo de trabajo rudimentario para el dise
de la interfaz WebApp.
1. Revisar la informacin contenida en el modelo de anlisis y refmam

conforme se requiera.
2. Desarrollar un bosquejo aproximado de la plantilla de la interfaz de
WebApp. Como parte de la actividad de modelado del anlisis se pudo ha:-desarrollado un prototipo de la interfaz (que incluya la plantilla). Si ya exist:
la plantilla, debe revisarse y refinarse conforme se requiera. Si no se ha desarrollado la plantilla de la interfaz, el equipo de ingeniera Web debe trabajar
con los participantes para desarrollarla en este momento. En la figura 19.3 -.e
muestra una primera versin de un bosquejo de plantilla.
Correlacin
de los objetivos del usuario en las acciones de la
interfaz.
Borro de men
de funciones principoe
lista de obetivos
del usuario
Grfico, logotipo y nombre de lo compoo
Objeli\l#l
Obetivo J#2
Obetivo#3
Obetivo #4
-...-
Ob~liv~ #5
Grfico
Objelivo #n
Texto de lo pgino inicial
navegacin
CAPTULO 19
MODELADO DE DISENO PAl<A APl.ICACIONES WEB
531
3. Correlacionar los objetivos del usuario con acciones especficas de la

interfaz. Para la gran mayora de las WebApps, el usuario tendr un conjunto
relativamente primario de objetivos primarios (usualmente entre cuatro y siete). stos deben correlacionarse con acciones especficas de la interfaz, como
se muestra en la figura 19.3.
4. Definir un conjunto de tareas de usuario que estn asociadas con ca da accin. Cada accin de la interfaz (por ejemplo, "comprar un producto")
est asociada con un conjunto de tareas de usuario. Dichas tareas se identificaron durante el modelado de anlisis. Durante el diseo deben correlacionarse interacciones especficas que abarquen asuntos de navegacin, objetos
de contenido y funciones WebApp.
5. Elaborar bosquejos con imgenes de la pantalla para cada accin de

la interfaz. 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 contenido (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 . Refinar la plantilla de la interfaz y los bosquejos con el uso de entradas desde el diseo esttico. 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 . Identificar los objetos de la interfaz del usuario que se requieran para

implementarla. Esta tarea puede requerir una bsqueda en una librera de
objetos existente para encontrar aquellos objetos reutilizables (clases) apropiados para la interfaz de la WebApp. Adems, en este momento se especifican cualesquiera clases de personalizacin.
8. Desarrollar una representacin de procedimiento de la inte raccin

del usuario con la interfaz. Esta labor opcional usa diagramas de secuencia UML o diagramas de actividad (estudiados en el captulo 18) para esbozar
el flujo de actividades (y decisiones) que ocurren conforme el usuario interacta con la WebApp.
9. Desarrollar una representacin de l comportamiento de la interfaz. Esta tarea opcional utiliza diagramas de estado UML (estudiados en el capitulo
18) para representar las transiciones de estado y los eventos que las causan.
Se definen los mecanismos de control (es decir, los objetos y acciones disponibles con que el usuario altera el estado de una WebApp).
1O. Describir la plantilla de la interfaz para cada estado. 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 estado de la WebApp descrito en la
tarea 9.
582
PARTE TRES
1 1. Refinar y revisar el modelo de diseo de la interfaz. La revisin de la interfaz se debe enfocar en la facilidad de uso (captulo 12).
Es importante notar que el conjunto de tareas finales que haya elegido un equipo de
ingeniera Web se debe adaptar a los requisitos especiales de la aplicacin que se va
a construir.
~NSEJOS.
No Jooo ingeniero Web

(o ingeniero de softwae)
liefle tolento Oflisti(o
(estlico). Si se est en
es/O rofefpkl, romrfese
w~grofiro
experrr,enlrldo poro d
tmlxi;ode<iseo
El diseo esttico, tambin llamado diseo grfico, es un esfuerzo artstico que complementa los aspectos tcnicos de la ingeniera Web. Sin l, una WebApp puede se
funcional, pero sin atractivo. Con l, una WebApp lleva a sus usuarios a un mund_
que los incluye en un mbito tanto emocional como intelectual.
Pero, qu es esttica? Existe un viejo dicho: "la belleza existe en los ojos de quie:la ve". Esto es particularmente apropiado cuando se considera el diseo esttico para las WebApps. Para realizar un diseo esttico efectivo, de nuevo se regresa a l.:
jerarqua de usuarios desarrollada como parte del modelo de anlisis (captulo 18)
se pregunta quines son los usuarios de la WebApp y qu "apariencia" desean.
esttico.
*mG!dl:lln!OS ~te la g!flte rQpidomente evalo un sitio slopor sudiseo vis.uoJ."

,
Directrkes Stanford paro la
e~ .. N
19.4.1 Cuestiones de la plantilla

Toda pgina Web tiene una cantidad limitada de "bien inmueble" que puede usal'Sl.
para dar soporte a la esttica no funcional, caractersticas de navegacin, contenid
de informacin y funcionalidad dirigida al usuario. El "desarrollo" de este bien irmueble se planea durante el diseo esttico,
Al igual que las cuestiones estticas, no existen reglas absolutas cuando se disea una plantilla de pantalla. Sin embargo, vale la pena considerar algunos linea
mientes generales de plantilla:
No temerle al espacio vaco. No es aconsejable rellenar cada centmetro cuadrad
de una pgina Web con informacin. El amontonamiento resultante dificulta que e.

usuario identifique la informacin o caracteristicas necesarias y crea un caos visua.
desagradable.
Resaltar el contenido. Despus de todo, sta es la razn por la cual el usuario es
t aqu. Nielsen [NIEOO] sugiere que la tpica pgina Web debe ser 80 por ciento cor
tenido con el resto del bien inmueble dedicado a navegacin y otras caractersticas
organizar los elementos de plantilla de arriba a la izquierda hacia abajo a la derecha
La gran mayora de los usuarios explorarn una pgina Web en gran parte de la misma forma en que exploran las pginas de un libro: de arriba a la izquierda hacia aba-
CAPTIJLO 19
MODELADO DE DISEO PARA APUCAC!ONES WEB
583
jo a la derecha.8 Si los elementos de plantilla tienen prioridades especficas, los elementos de mayor prioridad deben colocarse en la porcin superior izquierda de la
pgina bien inmueble.
Agrupar navegacin, contenido y funcin geogrficamente dentro de la pgina. Los

humanos buscan patrones virtualmente en todas las cosas. Si no existen patrones
discernibles dentro de una pgina Web, es probable que aumente la frustracin del
usuario (debido a la bsqueda innecesaria de la informacin requerida).
No extender el bien inmueble con la barra de desplazamiento. Aunque con frecuencia el desplazamiento es necesario, la mayora de los estudios indican que los usuarios preferiran no desplazarse. Es mejor reducir el contenido de la pgina o presentar el contenido necesario en varias pginas.
Considerar la resolucin y el tamao de la ventana de navegador cuando disee plantillas. En vez de definir tamaos fijos dentro de una plantilla, el diseo debe especificar
todos los artculos de la plantilla como un porcentaje del espacio disponible [NIEOO).
19.4.2 Cuestiones de diseo grtico

El diseo grfico considera cada aspecto de la presentacin y percepcin de una
WebApp. El proceso de diseo grfico comienza con la plantilla (seccin 19.4 .1) y
procede hacia la consideracin de esquemas de color globales, tipos de fuentes, tamaos y estilos, el uso de medios audiovisuales complementarios (por ejemplo, audio, video, animacin) y todos los dems elementos estticos de una aplicacin. El
lector interesado puede obtener sugerencias y directrices de diseo en muchos sitios
Web que se dedican al tema (por ejemplo, www.graphic-design.com, www.grantasticdesigns.com, www.wpdfd.com) o de una o ms fuentes impresas (por ejemplo,
[BAGO!). [CLOOIJ o [HEI02)).
Sitios Web bien diseados

En ocasiones, lo mejor formo de comprender el
buen diseo de los WebApps es observar unos
:os ejemplos. En su artculo "The Top Twenty Web De~ ps" (las mejores 20 sugerencias poro el dseo
Morcelle Toor (http://www.grophic-design.com/
feoture/tips.html) sugiere los siguientes sitios Web
ejemplos de buen diseo grfico:
www.pbs.org/riverofsong: sere de televisin poro lo rado

y lo televisin pblicos acerco de lo msico
estadounidense
www.RKDINC.com: firmo de dseo con un portafolios en
lneo y buenos sugerencias de diseo.
"'primo.com: firmo de diseo encabezado por Primo

.i.ngeli.
www.commorts.com/coreer/index.html: revsta Commvni

cotion Arts, uno publicacin peridico poro diseado
res grficos. Uno bueno fuente poro otros sitios bien
diseados
~ workbook.com: este slio sirve como aparador poro
www.btdnyc.com: firmo de diseo encabezado por Beth
el trabajo de ilustradores y diseadores.
Toudreau.
Existen excepciones basadas en la cultura y el idioma pero esta regla se aplica a la mayora de los
usuarios.
584
PARTE TRES
19.5 Dsgjo PIJ, coNTJNrpo

El diseo del contenido se enfoca en dos asuntos de diseo diferentes. cada uno
abordan individuos con distintos conjuntos de habilidades. El diseo del conten _
desarrolla una representacin de diseo para los objetos de contenido y represer
los mecanismos que se requieren para que establezcan sus relaciones uno con otro.
Esta actividad de diseo la dirigen los ingenieros Web.
Adems, el diseo de contenido se ocupa de la representacin de la informac
dentro de un objeto de contenido especfico: actividad de diseo que dirigen los po-blicistas, los diseadores grficos y otros que generan el contenido de una WebAp;:
"los buenos diseodores pueden crear normalidad a partir del caos; pueden comunicar los Ideos con claridad por
dio de la organizacin yel manejo de las palabras y los dibujos:
19.5.l
Objetos de contenido
La relacin entre objetos de contenido, definida como parte del modelo de an
WebApp (por ejemplo, figura 18.3), y los objetos de diseo que representan con...
do es anloga a la relacin entre las clases de anlisis y los componentes de dis,
descritos en el capitulo 11. En el contexto de la ingeniera Web un objeto de cor
do est alineado de manera ms cercana con un objeto de dato para software
ComponenredeProduclo
Representacin
del diseo de
los objetos de
contenido.
portNme,o
por11Nombte
porteTipo
-e Es porle de
descnpc16n
prec,o
creorN1>11voArtculoO
desplego,OescripconO
de'f'le9ar E'l"'(Ticnoca
t
1
Sensor
Cmoro
Ponel de Control
CoroctSof1woro
0 .. 1
, I
11
kolo, le,lo
e.iilo fvont
"*''
tomoo lineo
$fXJOodO
lomoilo-u.o
color fondo
.. .
0..
Eoquemo
d,i/ie,,u6n horiznlol
dimensin v.rlw:al
e,lilo bo<de
..
'
fologtoflo
DescripcrnDeMari<et,,,g
Oe>Cr1pcindeCompo111;n1e
,,
Video
d,mensin horlzomal
dunen.s,n -l>col
w,lobo.de
..
1
,1
..
d,monsin hO(ltontol
,
O.scr,pci6nT" . color le~lo
dimen~ v,er 1 K:d
.,,,lo ru.n,.
..hloborde
Yoivmen audoo
pOCamitlo .,..
tomoo fueni,
latna/io texlo ,,..
eolot fanclo
CAPTULO 19
MODELADO DE DISEO PARA APLICACIONES WEB
585
vencional. Un objeto de contenido tiene atributos que incluyen informacin especifica de contenido (normalmente definida durante el model ado de anlisis WebApp)
y atributos especficos de implementacin que se especifican como parte del diseo.
como ejemplo, considrese la clase de anlisis que se desarroll para el sistema
de comercio electrnico HogarSeguro llamado ComponentedeProducto que se desarroll en el capitulo 18 y se representa como aparece en la figura 19.4. En el captulo 18 se mencion un atributo descripcin que aqu se representa como una clase
de diseo llamada DescripcindeComponente, compuesta de cinco objetos de
contenido: DescripcinDeMarketing, Fotografia, DescripcinTcnica, Esquema y Video, que se muestran como objetos sombreados en la figura. La informacin
que contiene el objeto de contenido se registra como atributos. Por ejemplo, Fotografia (una imagen .jpg) tiene los atributos dimensin horizontal, dimensin
vertical y estilo de borde.

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 Descripcindecomponente para cada instancia de la clase componentedeProducto. DescrlpcindeComponente est
integrado por los cinco objetos de contenido mostrados. Sin embargo, la multiplicidad de notacin que se muestra indica que Esquema y video son opcionales (es posible que se presenten cero ocurrencias), se requieren una DescripcinDeMarketing y DescripcinTcnica, y se aplican una o ms instancias de Fotografia.
19.5.2 Cuestiones del diseo de contenido

Una vez modelados todos 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 objeto de contenido al proporcionar un esbozo de la informacin que se entregar y
una indicacin de los tipos de los objetos de contenido genricos (por ejemplo, texto descriptivo, imgenes grficas, fotografias) mediante los cuales se entregar la informacin. Tambin se puede aplicar el diseo esttico (seccin 19.4) para representar la apariencia y percepcin adecuados para el contenido.
Conforme se disean, los objetos de contenido se "despedazan" [POWOO] para
formar pginas de la WebApp. El nmero de objetos de contenido que se incorporan
en una sola pgina es en funcin de las necesidades 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 desplazamiento que el usuario tolerar .
El diseo arquitectnico est enlazado con las metas establecidas para la WebApp, el
contenido que se presentar, los usuarios que la visitarn y la filosofia de navega9 Ambas representaciones se discuten en el capitu!o 8..
586
PARTE TRES
APUCACIN DE LA INGENIERIA WEB
cin que se establezca. El diseador arquitectnico debe identificar la arquitectur.::

de contenido y la arquitectura de la WebApp. La arquitectura de contenido 10 se centra en la forma en la que los objetos de contenido (u objetos compuestos como las
pginas Web) se estructuran para su presentacin y navegacin. La arquitectura d..
WebApp aborda la forma en la que la aplicacin se estructura para gestionar la interaccin del usuario, manejar las tareas de procesamiento internas, efectuar la navegacin y presentar el contenido.
.,.....,...
"[IJcJ estrud8r.O a,quited(lnko de un sitio bien diseado no siempre es aparente poro el usuorio.. nl,O .telte ~--
En la mayora de los casos, el diseo arquitectnico se dirige en paralelo con '"

diseo de la interfaz, el esttico y el de contenido. Puesto que la arquitectura Wet
App puede tener una fuerte influencia sobre la navegacin, las decisiones tomada,
durante esta actividad de diseo influirn en el trabajo dirigido durante el diseo :
navegacin.
19.6.1 Arquitectura de contenido

El diseo de la arquitectura de contenido se centra en la definicin de la estructura I"
permedia global de la WebApp. El diseo se puede elegir de cuatro diferentes estn..c
turas de contenido [POWOOJ:
Las estructuras lineales (figura 19.5) se encuentran cuando es comn una secuer
ca predecible de interacciones (con alguna variacin o desviacin). Un ejemplo el.;,
sico puede ser una presentacin tutorial en la que las pginas de informacin jun~
con grficos relacionados, videos cortos o audio se presentan slo despus de <rse ha presentado informacin de prerrequisitos. La secuencia de la presentacin c.
contenido est predefinida y, por lo general, es lineal. Otro ejemplo puede ser ur
secuencia de entradas para comprar un producto, en la cual se debe detallar infcmacin especfica en un orden especfico. En tales casos, son apropiadas las estn....
turas mostradas en la figura 19.5. Conforme el contenido y el procesamiento se vue
ven ms complejos, el flujo meramente lineal mostrado a la izquierda de la figura c..
paso a estructuras lineales ms complejas en las que se puede llamar contenido a.
ternativo u ocurre una desviacin para adquirir contenido complementario (estru:
tura mostrada a la derecha de la figura 19.5).
Las estructuras en retcula (figura 19.6) son una opcin arquitectnica aplicabcuando el contenido de la WebApp est organizado categricamente en dos (o ma..
dimensiones. Por ejemplo, considrese una situacin en la cual un sitio de cornera
electrnico vende palos de golf. La dimensin horizontal de la retcula representa ~
tipo de palo que se vende (por ejemplo, madera, hierro, wedges, putters). La dimer
1O El trmino arquitectura de informacin tambin se utiliza para sugerir estructuras que conducer
una mejor organizacin, etiquetado, navegacin y bsqueda de objetos de contenido.
CAPTULO 19 MODELADO DE DISEO PARA APLICACIONES WEB
587
lineal
lineal con
flujo
opcional
lineal
con
derivaciones
sin vertical representa las ofertas de varios fabricantes de palos de golf. En consecuencia, un usuario puede navegar la retcula horizontalmente para encontrar la columna putters y luego verticalmente para examinar las ofertas de aquellos fabricantes
que venden putters. Esta arquitectura de WebApp slo es til cuando se encuentra
contenido altamente regular [POWOOJ .
Las estructuras jerrquicas (figura 19.7) son indudablemente las arquitecturas WebApp
ms comunes. A diferencia de las jerarquas de software factorizadas -que se estudiaron 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 horizontalmente, a travs de las ramas verticales de la estructura. Por lo tanto, el contenido
presentado en la rama de la extrema izquierda de la jerarqua puede tener vnculos
588
ii+HICI
Estructura
Jerrquica.
de hipertexto que conduzcan a contenido que existe en la rama de en medio o a :a

derecha de la estructura. Sin embargo, se debe sealar que, aunque tales ramificz.
ciones permiten la navegacin rpida a travs del contenido de la WebApp, puedeconducir a confusin en la parte del usuario.
Una estructura en red o "Web pura" (figura 19.8) es similar en muchos sentidos
la arquitectura que evoluciona para los sistemas orientados a objetos. Los comx::
nentes arquitectnicos (en este caso, pginas Web) estn diseados de modo qt.;.
pueden pasar el control (va vnculos de hipertexto) virtualmente a cualquier ot:
componente en el sistema. Este enfoque permite una considerable flexibilidad en navegacin, pero al mismo tiempo puede ser confusa para el usuario.
Las estructuras arquitectnicas comentadas en los prrafos precedentes se pi.le"
de combinar para formar estructuras compuestas. La arquitectura global de una Wet
App puede ser jerrquica, pero parte de la estructura puede mostrar caractersti~
lineales, mientras que otra parte puede estar en red. La meta para el diseador a:
quitectnico es emparejar la estructura WebApp con el contenido que se presenta:-:
y el procesamiento que se llevar a cabo.

19.6.2
Arquitectura de WebApp
arquitectura de WebApp describe una infraestructura que permite a un sistema

aplicacin basados en Web lograr sus objetivos de negocios. Jacyntho y sus coleg.:..
La
UAC02] describen las caractersticas bsicas de esta infraestructura en la forma s.

guiente:
Las aplicaciones deben construirse con el uso de capas en las que se tomen en cuenta las
diferentes preocupaciones; en particular, los datos de la aplicacin se deben separar de los
contenidos de la pgina (nodos de navegacin), y dichos contenidos, a su vez, deben estar claramente separados de la apariencia y la percepcin de la interfaz (pginas).
CAPTULO 19
589
.,
-
Los autores sugieren una arquitectura de diseo en tres capas que desacople la
interfaz de la navegacin y del comportamiento de la aplicacin, y argumentan que
mantener la separacin de la interfaz, aplicacin y navegacin simplifica la implementacin y mejora la reutilizacin.
La arquitectura de modelo-vista-controlador (MVC) [KRA88J 11 es uno de varios modelos de infraestructura WebApp sugeridos para desacoplar la interfaz del usuario de
la funcionalidad y el contenido de informacin de la WebApp. El modelo (a veces llamado "objeto modelo") contiene todo el contenido especfico de la aplicacin y la lgica de procesamiento, e incluye todos los objetos de contenido, el acceso a fuentes
de datos/informacin externas y toda la funcionalidad de procesamiento que son especficos de la aplicacin. La vista contiene todas las funciones especficas de la interfaz y habilita la presentacin del contenido y la lgica de procesamiento, e incluye todos los objetos de contenido, acceso a fuentes de datos/informacin externas
y a toda la funcionalidad de procesamiento requerida por el usuario final. El controlador gestiona el acceso al modelo y a la vista y coordina el flujo de datos entre ellos.
En una WebApp, "la vista la actualiza el controlador con datos provenientes del modelo con base en la entrada del usuario" [WMT02J. En la figura 19.9 se muestra una
representacin esquemtica de la arquitectura MVC.
En referencia a la figura, las solicitudes o datos del usuario se manejan 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 comportamiento al modelo, que implementa la funcionalidad o recupera el contenido requerido para acomodar la solicitud. El objeto modelo puede
tener acceso a datos almacenados en una base de datos corporativa, como parte de
11 Se debe destacar que MVC es en realidad un patron de diseo arquitectnico desarrollado por el am biente Smalltalk (vase http://www.cetus-links.org/oo_smalltalk.htmlJ y se puede usar para cual quier aplicacin interactiva.
PARTE TRES
590
ifrP. (&
APUCACIN DE LA INGENJERA WEB
La arquitectura MVC (adaptada de [JAC02]).
Controlador
Gestiono los solicitudes
deh.1s1Jario
Selecciona
comportamiento
de rno,klo
Sel~C]OhC resj:>uesto visto
--- -------
Seleccin de visto
Solicitud de
comportomiento
(cambio de estado)
1
1
1
1
Modelo
Encapsulo funcionolidd
Encapsulo objetos de contenido.__ _,
111corpora todos los estodps
deWebApp
----------
Datos
del modelo
I
Ybta
Prepara datos del ~lo

Acl\idliza solicitvdes
Solicitud
actualizado
Datos externos
del modelo
Pre$8nlo vi$t0 selecdo,;ada
por el controlador
Servidor
un almacn de datos local o como una coleccin de archivos independientes.

datos que desarrolla el modelo debe formatearlos y organizarlos el objeto vista
cuado y luego transmitirlo del servidor de la aplicacin de vuelta al navegador do en el cliente para que se despliegue en la mquina de ste.
En muchos casos, la arquitectura de WebApp se define dentro del contexto
ambiente de desarrollo en el que la aplicacin habr de implementarse (por ejem:.
ASP.net, JWAA o J2EE). El lector interesado debe ver [FOW03] para una exp05"...
ulterior acerca de los ambientes de desarrollo modernos y de su papel en el e:!&.
de las arquitecturas de aplicaciones Web.
Una vez establecida la arquitectura de WebApp y la identificacin de los compo:tes (pginas, guiones, applets y otras funciones de procesamiento). el diseador
be definir las rutas de navegacin que habiliten para los usuarios el acceso al cenido y las funciones de la WebApp. Para lograr esto el diseador debe l) idenc;la semntica de navegacin para diferentes usuarios del sitio y 2) definir la mee
ca (sintaxis) que logra la navegacin.
~lo espero, Gretel.hosta que lo lona se eleve, entonces veremos los troz-OS de po~ que hede$p1111.....io, ellos
11.iromultnur'o'thamino ocoso."
,, '
t....- .......,
591
CAPTULO 19 MODELADO DE DISEO PARA AP'...lCA.ClONES WEB
19. 7 .1 Semntica de navegacin

Al igual que muchas actividades de ingeniera Web, el diseo de navegacin comienza 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
conjunto de clases que abarcan uno o ms objetos de contenido o funciones de la
WebApp. conforme cada usuario interacta con la WebApp, encuentra 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 subconjunto de requisitos de usuario relacionados" [CAC02].
Gnaho y Larcher [GNA99] describen la USN en la forma siguiente:
La estructura de una USN est compuesta de un conjunto de subestructuras de navega-
cin que se llamarn formas
de navegacin (FdN). Una FdN representa la mejor forma o
ruta de navegacin para los usuarios con ciertos perfiles para lograr su meta o submeta
deseada. En consecuencia, el concepto de FdN est asociado con el concepto de Perfil de
Usuario.
La estructura de una FdN est integrada con un conjunto de nodos de
relevantes conectados por vnculos de
navegacin (NN)
navegacin, que en ocasiones incluyen otras FdN.
Esto significa que las FdN pueden, en si mismas, ser agregadas para formar una FdN de
nivel superior, o pueden anidarse en cualquier profundidad.
Para ilustrar el desarrollo de una FdN, considrese el caso de uso seleccionar componentes Hogarseguro descrito en la seccin 18.1.2 y que se reproduce a continuacin:
Caso de uso: seleccionar componentes
HogarSeguro
Entonces la WebApp recomendar componentes de producto (por ejemplo, paneles de

control, sensores, cmaras) y otras caracteristicas (por ejemplo, funcionalidad basada en
PC implementada en software) para cada habitacin y la entrada exterior. Si el usuario
solicita opciones, la WebApp las proporcionar si existen. El usuario obtendr informa-
cjn descriptiva y de precios para cada componente de producto.
La WebApp crear y
mostrar una factura de materiales conforme se seleccionen varios componentes. El

usuario tambin podr nombrar la factura de materiales y guardarla para referencia futura (vase caso de uso: guardar conjiguradn).
Los artculos subrayados en la descripcin del caso de uso representan clases y objetos 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 Hogarseguro.
La figura 19. 1O bosqueja un anlisis semntico parcial de la navegacin que implica el caso de uso
seleccionar componentes HogarSeguro.
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 paquete
592
1j: jlj '' (1)
PARTE TRES APUCAC!N DE LA INGENIERA WEB
Creacin de una USN .

<<vnculo de navegacin>>
solicitar alternativa
<<vnculo de navegacin>>
mostrar descripcin
<<vnculo de navegacin>>t--------1
ver FacturaDeMateriales
Descripii!nDeComponente
DescripcinDeMarketing
DescripcinTcnica
esquema
fotografa
video
de objetos de contenido llamado DescripcinComp, un atributo de la clase ComponentedeProducto). Dichos articulos son nodos de navegacin. Cada una de
flechas representa un vnculo de navegacin 12 y est etiquetado con la accin <rinicia el uso que causa que el vnculo ocurra.
El diseador de la WebApp crea una unidad semntica de navegacin (USN) p.1L.
cada caso de uso asociado con cada papel de usuario [GNA99]. Por ejemplo
cliente nuevo (figura 18. I) puede tener tres diferentes casos de uso, y todos res
tan en acceso a diferente informacin y funciones de la WebApp. Para cada meta
crea una USN.
Durante las etapas iniciales del diseo de navegacin se valora la arquitectura
contenido de la WebApp para determinar una o ms FdN para cada caso de uso. e
mo se anot anteriormente, una FdN identifica los nodos de navegacin (por ejer:
plo, contenido) y los vnculos que permiten la navegacin entre ellos. Entonces
FdN se organizan en USN.
"'Berohlema de lo novegocili en el sitio Web es conceptual, tcnico, espacial, filosfico ylogistko. (o ~

115.soludonts tienden o pedit combinociones de orle, ciencia ypsicologioorgonizocionol improvsudas yaJlllplejas."
Jnlforta
19.7.2 Sintaxis de navegacin
Conforme el diseo se lleva a cabo se define la mecnica de navegacin. Entre r
chas posibles opciones estn:
Vnculo de navegacin individual: vnculos basados en texto, iconos, botones
interruptores, y metforas grficas.
12 En ocasiones, a stos se les conoce como vnculos semnticos de navegadn (VSN) [CAC02J.
CAPTULO 19
MODELADO DE DISEO PARA APUCAC10NES WEB
593
Barra de navegacin horizontal: lista de las principales categoras de contenido o funcionales en una barra que contiene vnculos adecuados. En general,
se mencionan entre cuatro y siete categoras.
Columna de navegacin vertical: 1) lista de las principales categoras de conte-
nido o funcionales, o 2) lista de virtualmente todos los principales objetos de

contenido dentro de la WebApp. Si se elige la segunda opcin, tales columnas
de navegacin se pueden "expandir" para presentar objetos de contenido como parte de una jerarqua.
Pestaas: una metfora que no es ms que una variacin de la barra o colum-
na de navegacin, que representa las categoras de contenido o funcionales

como marcas que se seleccionan cuando se requiere un vnculo.
Mapas de sitio: proporcionan una tabla de contenido incluyente para la nave-
gacin hacia todos los objetos de contenido y funcionalidad contenidos en la

WebApp.
Adems de elegir los mecanismos de navegacin, el diseador tambin debe establecer convenciones y auxiliares de navegacin adecuados. Por ejemplo, iconos y
vnculos grficos que deben parecer "oprimibles" mediante el biselado de los bordes
para que la imagen tenga una apariencia tridimensional. Debe disear retroalimentacin visual o de audio para ofrecer al usuario un indicador de que ha elegido una
opcin de navegacin. En la navegacin basada en texto debe usarse color para indicar los vinculas de navegacin y proporcionar un indicador de los vnculos ya recorridos. stas son slo algunas de las docenas de convenciones de diseo que hacen la
navegacin amigable al usuario.
Las modernas aplicaciones Web entregan funciones de procesamiento cada vez ms

elaboradas que 1) realizan procesamiento localizado para generar capacidad de
contenido y navegacin en una forma dinmica; 2) ofrecen capacidades de computacin o procesamiento de datos que son adecuadas para el dominio de negocios de
la WebApp; 3) proporcionan cuestionamientos y acceso sofisticados a bases de datos, 4) establecen interfases de datos con sistemas corporativos externos. Para lograr
estas (y muchas otras) capacidades, el ingeniero Web debe disear y construir componentes de programa que sean idnticos en forma a los componentes de software
para el software convencional.
En el captulo 11 se considera con cierto detaJle el diseo al nivel de componentes. Los mtodos de diseo estudiados en el capitulo 11 se aplican a los componentes
WebApp con poca, si acaso, modificacin . El ambiente de implementacin, los lenguajes de programacin y los patrones de reutilizacion, marcos de trabajo y software pueden variar un poco, pero el enfoque de diseo global permanece igual.
594
PARTE TRES
Los patrones de diseo aplicados en la ingeniera Web abarcan dos grandes clas..:
1) patrones de diseo genrico que son aplicables a todos los tipos de software ,.ejemplo, [BUS96] y [GAM95]) y 2) patrones de diseo hipermedia que son especlk.
de las WebApp. En el captulo 9 se trataron los patrones de diseo genrico. AL
vs de Internet se puede tener acceso a varios catlogos y almacenes de patrones ~
hipermedia. 13
Cda polfo S uno reglo de tres portes que expreso uno relacin entre cierto contexto, un ptoblflltl y uno solucin."
Clrlsto,-Altx_..
Como se apunt antes en este libro, los patrones de diseo son un enfoque geneco para resolver algn pequeo problema de diseo que se puede adaptar a una '
riedad mucho ms amplia de problemas especficos. En el contexto de los sisterr.basados en Web, German y Cowan [GEROOJ sugieren las siguientes categoras de p
trones:
Patrones arquitectnicos. Estos patrones auxilian en el diseo del contenido y

arquitectura de la WebApp. Las secciones I 9.6. l y 19.6.2 presentan patrones arq...
tectnicos para el contenido y la arquitectura de la WebApp. Adems, estn dispor
bles muchos patrones arquitectnicos relacionados (por ejemplo, Java Blueprints e
java.sun.com/blueprints/) para los ingenieros Web que deben disear WebApps L
una diversidad de dominios de negocios.
Patrones de construccin de componentes. Estos patrones recomiendan mt....

dos para combinar componentes WebApp (por ejemplo, objetos de contenido, f~
ciones) en componentes compuestos. Cuando se requiere la funcionalidad de procc
samiento de datos en una WebApp, son aplicables los patrones de diseo arquita
tnico y al nivel de componente que proponen [BUS96J, [GAM95] y otros.
Patrones de navegacin. Estos patrones auxilian en el diseo de USN, vnculos d~

navegacin y el flujo global de navegacin de la WebApp.
Patrones de presentacin. Estos patrones auxilian en la presentacin del contenido como se presenta al usuario va la interfaz correspondiente. Los patrones en es
ta categora abordan cmo organizar las funciones de control de la interfaz del usuario para una mejor facilidad de uso; cmo mostrar la relacin entre una accin de l.:
interfaz y los objetos de contenido que afecta; cmo establecer jerarquas de contenido efectvas; y muchas otras.
Patrones de interaccin comportamiento/usuario. Estos patrones auxilian er

el diseo de la interaccin usuario-mquina. r_os patrones en esta categora abordar
13 Vase la barra lateral al final de esta seccin.
CAPTULO 19 MODELADO DE DISEO PARA APUCAClONES WEB
595
cmo la interfaz informa al usuario de las consecuencias de una accin especfica; cmo un usuario expande el contenido con base en el conLexto de uso y sus deseos;
cmo describir mejor el destino que implica un vnculo; cmo informar al usuario
acerca del estado de una interaccin en marcha y otros.
Las fuentes de informacin acerca de los patrones de diseo hipermedia se han
expandido en forma sustancial en aos recientes. Los lectores interesados deben
consultar [GAR97]. [PER99l y [GEROOJ.
Almacenes de patrones de diseo hipermedia

El sitio Web lAWiki (http://iowiki.net/WebsitePotterns) es un espacio de discusin conjunto
formacin de los arquitectos y que contiene muchos
tiles. Entre ellos estn vnculos o vorios catlogos
-xenes de patrones hipermedio tiles. Estn represencientos de patrones de diseo:
n de patrones de diseo hipermedia
.w.tW.designpattern.lu.unisi.ch/
ctionPalterns de Tom Erickson
.w.tW.pl iant.org/ personal/Tom_Erickson/lnterac_1erns.html
es de diseo Web de Martijn vanWelie
"VIW.welie.com/patterns/
Mejora de los sistemas de informacin Web

con patrones de navegacin
http://www8.org/w8papers/5b-hypertextmedio/impro
ving/improving. html
Un patrn de lenguaje HTML 2,0
http:/ /www.onomorph.com/docs/patterns/default.html
Terreno comn
http://www.mit.edu/-jtidwell/interoction_potterns.html
Patrones para sitios Web personales
http://www.rdrop.com/-half/Creotions/Wrilings/Web.
patterns/index. html
ndice de lenguajes patrn
http://www.cs.brown.edu/-rms/lnformotionStructures/
lndexing/Overview.html
Durante las pasadas dcadas se propusieron varios mtodos de diseo para aplicaciones Web. A la fecha, ningn mtodo es el dominante. En esta seccin se presenta un breve panorama de uno de los mtodos de diseo WebApp ms ampliamente
analizados: MDH00. 14
El mtodo de diseo hipermedia orientado a objetos (MDHOO) lo propusieron originalmente Daniel Schwabe y sus colegas [SCH95, SCH98J. El MDHOO est compuesto
de cuatro 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 estas actividades de diseo y en las secciones que siguen se discuten
brevemente.
19.10. l
Diseo conceptual por el MDHOO
El diseo conceptual mediante el MDHOO t.ea una representacin de los subsistemas, clases y relaciones que definen el dominio de aplicacin para la WebApp. Se
14 Koch [KOC99J ha desarrollado una amplia COf11pilicldn de los diez mtodos de diseo hipermedia.
596
CAPTULO 19
Resumen del mtodo MDHOO (adaptado de [SCH95]).
biseo de navegacin
l ab~ l
de lo in~z
Implementacin
Nodos, vnculos,
" estructuras
d. occe501 contextos
den~in,
IJansformociones
deru:i~i6n
Correlocin entre
'ii,bietos co~les
y, de flCiVe9llei6n
l.c:urs
propol'ionado
por Qmbente
puede usar 15 UML para crear diagramas de clase adecuados, agregados y represe.
taciones de clase compuestas, diagramas de colaboracin y otra informacin q-.. _
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 HogarSeguroinc.com. En la figura 19.
se muestra un "esquema conceptual" parcial para Hogarsegurolnc.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 relaciones entre clases.
19.10.2 Diseo de navegacin mediante el MDHOO

El diseo de navegacin identifica un conjunto de "objetos" que se derivan de las da
ses definidas en el diseo conceptual. Se define una serie de "clases de navegacir
o "nodos" para encapsular dichos objetos. Se puede usar UML para crear casos ck
uso adecuados, grficos de estado y diagramas de secuencia, todos ellos auxilian a
diseador a comprender mejor los requisitos de navegacin. Adems, es posibl.=
aplicar los patrones de diseo para el diseo de navegacin conforme el diseo St
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 es comn cuando Sit
aplica este mtodo.
CAPTULO 19
597
Esquema conceptual parcial para HogarSeguroinc.com.

cliente selecciona componente
recomendociqn de componente
solicitada
Coo,ponentedel'roduclo
parteNmero
po,ieNombte
porteTipo
descrpcioo
precio
qeorNuevoArtlculo{ }
oblene(Demipcin! )
ob~ecTcnica
hobilacinl\lQ(llbt~
dimensiones
-iorV&ntcm9s
_,orPuert<
Cmara
intidod
porteNmero
parteN>mbre
pQrteTipo
precio
pedic:IQNmero
l)ltntelnfu
fadurc,0.1',\Qterioles
-borquelnfo
cobronl:qlnfo
dos, vnculos, anclas y estructuras de acceso [SCH98]. Las estructuras de acceso son
ms elaboradas e incluyen mecanismos como un ndice de la WebApp, un mapa de
sitio o un paseo guiado.
Una vez definidas las clases de navegacin, el MDHOO ''estructura el espacio de
navegacin mediante el agrupamiento de los objetos de navegacin en conjuntos
llamados contextos" [SCH98J. Schwabe describe un contexto en los trminos siguientes:
Cada definicin de contexto incluye, adems de los elementos que estn incluidos en l,
la especificacin de su estructura de navegacin interna, un punto de entrada, restricciones de acceso en trminos de clases de usuario y operaciones, y una estructura de acceso asociada.
Se desarrolla una plantilla de contexto (anloga a las tarjetas CRC estudiadas en el capitulo 8) y se emplea para rastrear los requisitos de navegacin de cada categora de usuario a travs de varios contextos definidos en el MDHOO. Al hacer esto surgen rutas
especficas de navegacin (que se llamaron FdN en la seccin 19.7.1).
19.10.3 Diseo abstracto de la interfaz e implementacin

La actividad de diseo abstracto de la inteifaz 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 daws (VAD) se utiliza para representar la re-
598
PARTE TRES
!acin entre objetos de la interfaz y objetos de navegacin, y las caractersticas d

comportamiento de los objetos de la interfaz.
El modelo VAD define una "plantilla esttica" [SCH98J que representa la metfo-:
de la interfaz e incluye una representacin de los objetos de navegacin dentro c.
la interfaz y la especificacin de los objetos de la interfaz (por ejemplo, mens, lY'
tones, iconos) que auxilian en la navegacin y la interaccin. Adems, el mode
VAD contiene un componente relacionado con el comportamiento (similar al diagr.;
ma de estado UML) que indica cmo los eventos externos "disparan la navegacir _
qu transformaciones de la interfaz ocurren cuando el usuario interacta con la a;
cacin" [SCHOJ]. Una exposicin detallada del VAD el lector interesado puede hal';:;
la en [SCH98] y [SCHOIJ .
La actividad implementacin del MDHOO representa una interaccin de dise
que es especfica al ambiente en el que operar la WebApp. Las clases, la nav~;
cin y la interfaz son caracterizadas en una forma que puede construirse para el a:;
biente cliente/servidor, sistemas operativos, software de soporte, lenguajes de p
gramacin y otras caractersticas del entorno relevantes respecto del problema.
....,-------
19. 11 Mttt;As 'n psfto RABA W11APP$

Las mtricas de diseo se deben caracterizar en una forma que proporcione a los
genieros Web un indicador de calidad en tiempo real. En esencia, un conjunto til
medidas y mtricas ofrece respuestas 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 inforr.
cin con el menor esfuerzo?
La navegacin es eficiente y directa?
La arquitectura de la WebApp se ha diseado para acomodar las metas y ....
jetivos especiales de los usuarios de la WebApp, la estructura de contenido
funcionalidad, y el flujo de navegacin requerido para usar el sistema de m;:;
nera efectiva?
Los componentes estn diseados en una forma que reduce la complejida...
de procedimientos y aumenta la exactitud, la confiabilidad y el desempeo~
En la actualidad, cada una de estas preguntas se puede abordar de manera cua.
tiva, 16 pero todava no existe un conjunto validado de mtricas que ofrezcan ;e
puestas cuantitativas.
16 Vase el captulo 16 (seccin 16.4) y la seccin 19.1. 1 para una exposicin cualitativa de la
de una WebApp.
CAPTULO 19
MODELADO DE DISENO PARA Al'"..IC,\CIO NES WEB
599
Las mtricas para el diseo de WebApps estn en desarrollo y pocas se han validado ampliamente. El lector interesado debera consultar [IVOO I J y [MENO I J para
una muestra de las mtricas propuestas para el diseo de WebApps.
Mtricas tcnicas para WebApps

Objetivo: Apoyar o los ingenieros Web en el
desarrolla de mtricos WebApp significativos
cir-ezcan una visin acerco de la calidad global de
::iplicaci6n.
mientas representativas 17
echanic Toals, desarrollada por Netmechanic (www.
-e:mechonic.com), es uno coleccin de herramientas
,.ie ayudan o mejorar el desempeo de un sitio Web;
,e enfoco sobre los temas especficos de lo implemento- Web Metrics Tesfbed, desarrollado por The Notionol
'lslilute of Stondords and Technology {zing.ncsl.nist.
gov/WebTools/), abarco la siguiente coleccin de he
-amientos tiles que estn disponibles poro descargar
las:
Web Static Analyzer Too/ {WebSAT}: verifico el HTML de

lo pgino web contra los lineamientos de facilidad de
uso tpicos.
Web Category Analysis Too/ {WebCAT): permite al ingeniero de facilidad de uso construir y dirigir un anlisis
de categora Web.
Web Variable lnstrumenter Progrom (WebVIP}: instrumenta un sitio Web para capturar un registro de interaccin de usuario.
Fromework for Logging Usability Dota {FLUD): implemen
ta un formateodor y analizador gramatical de archivos
para representar los registros de interaccin de usuo
rio.
VisVIP Too/: produce una visualizacin tridimensional de
las rulos de navegacin del usuario a travs de un sitio
Web.
TreeDec: agrega auxiliares de navegacin a las pginas
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 tiempo en el mercado- se introduce durante 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 mecanismos 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 conjunto de lineamientos de diseo grfico proporciona la base para un enfoque de diseo.
l 7 Las herramientas anotadas son una muestra de esta categona
600
PARTE TRES APLICACIN DE LA INGENIEruA WEB
El diseo de contenido define la plantilla, la estructura y el subrayado de todo ~

contenido que se presenta como parte de la WebApp; adems, establece las relaciones entre objetos de contenido. El diseo de contenido comienza con la representacin de los objetos de contenido, sus asociaciones y relaciones. Un conjunto de corsideraciones elementales establece las bases para el diseo de navegacin.
El diseo de arquitectura identifica la estructura hipermedia global para la WebApp y abarca tanto la arquitectura de contenido como la de WebApp. Los estilos aquitectnicos para el contenido incluyen estructuras lineal, en retcula, jerrquica .
en red. La arquitectura de la WebApp describe una infraestructura que permite a Lsistema o aplicacin basado en Web lograr sus objetivos de negocios.
El diseo de navegacin representa el flujo de navegacin entre los objetos de
contenido y para todas las funciones de la WebApp. La navegacin se define al des
cribir un conjunto de unidades semnticas de navegacin. cada unidad est COI"'
puesta de formas de navegacin y de vnculos y nodos de navegacin. Los mecani.s
mos de sintaxis de navegacin se aplican para afectar la navegacin descrita coll"'
parte de la semntica.
El diseo de componentes desarrolla la lgica de procesamiento detallada que ~
requiere para implementar los componentes funcionales de la WebApp. Las tcnicas
de diseo descritas en el captulo 11 se aplican a la ingeniera de componentes Web
App.
Los patrones para el diseo de WebApps abarcan patrones de diseo genric1.
que se aplican a todos los tipos de software y patrones hipermedia especialmente re
levantes para las WebApp. Se han propuesto patrones de diseo arquitectnico, de
navegacin, de componentes, de presentacin y de comportamiento/usuario.
El mtodo de diseo hipermedia orientado a objetos (MDHOO) es uno de vare mtodos propuestos para el diseo WebApp. El MDHOO sugiere un proceso de diseo que incluye diseo conceptual, diseo de navegacin, diseo abstracto de la irterfaz e implementacin.
Las mtricas de diseo para ingeniera Web estn en desarrollo y todava tiene.
que validarse por completo. Sin embargo, se han propuesto varias medidas y mmcas para abordar cada una de las actividades de diseo reanalizadas en este captulo
es
[AME96) Amento, B. et al., "Fitt's Law",

5724: Models and Theories of Human-Computer In~
ractions, Virginia Tech, 1996, disponible en http://ei.cs.vt.edu/-cs5724/g 1/ .
[BAGO!] Baggerman, L., y S. Bowman, Web Design That Works, Rockport Publishers, 2001.
[BUS96J Buschmann, F. et al., Pattem-Oriented software Architecture, Wiley, 1996.
[CAC02] Cachero, C. et al., "Conceptual Navigation Analysis: a Device and Platform lndepender
Navigation Specification", Proc. 2nd ln. Workshop on Web-Oriented Technology, junio de
2002, se puede descargar de www.dsic.upv.es/- west/iwwost02/papers/cachero.pdf.
[CLOOI] Cloninger, C., Fresh Stylesfor Web Designers. New Riders Publishing, 2001.
[DIX99J Dix, A., "Design ofUser Interfaces for the Web", Proc. 0/User Interfaces lo Data Systems Co11ference, septiembre de 1999, se puede descargar de http://www.comp.lancs.ac.uk/computing.
users/dixa/topics/webarch/.
CAPTULO 19
601
[FIT54J Fitts, P., "The lnformation Capacity o the Human Motor System in Controlling the Amplitude of Movement", enfoumal o/Experimental Psychology. vol. 47, 1954, pp. 381-391.
[FOW03J Fowler, M. et al., Pattems of Enterpri.se Applicaon Architecture. Addison-Wesley. 2003.
LGAL02J Galitz, W., The Essenal Guide to User Interface Design, Wiley, 2002.
LGAM95] Gamma, E. et al., Design Pattems, Addison-Wesley, 1995.
[GAR97) Garrido, A., G. Rossi y D. Schwabe, "Pattems Systems for Hypermedia", 1997, se puede
descargar de www.inf.puc-rio.br/-schwabe/papers/PloP97.pdf.
[GEROOJ German, D. y D. Cowan, "Toward a Unified Catalog of Hypermedia Design Pattems",
Proc. 33rd Hawaii Jnll. Conf. on system Sciences, IEEE, vol. 6, Maui, Hawaii, junio de 2000, se
puede descargar de www.turingmachine.org/-dmg/research/papers/dmg_hicss2000.pdf.
[GNA991 Gnaho, C. y F. Larcher, "A User-Centered Methodology for Complex and customizable
Web Engineering", Proc. Jst ICSE Workshop on Web Engineering, ACM, Los Angeles, mayo de
1999.
[HE!02J Heinicke, E., Layout: Fast So/utions Jor Hands-on Design, Rockport Publishers, 2002.
IJVOOIJ Ivory, M., R. Sinha y M. Hearst, "Empirically Validated Web Page Oesign Metrics", ACM
SJGCHI '01, Seattle, WA, abril de 2001, disponible en http://www.rashmisinha.com/articles/
WebTangoCHIO 1.html.
UAC02] Jacyntho, D., D. Schwabe y G. Rossi, "An Architecture for Structuring Complex Web Applications", 2002, disponible en http://www2002.org/CDROM/altemate/478/.
[KAI02J Kaiser, J., "Elements of Etfective Web Design", About, !ne., 2002, disponible en http:/ /webdesign.about.com/library/weekly/aa09 l 998.htm.
[KAL03) Kalman, S., Web Security Fie/d Guide, Cisco Press, 2003.
[KOC99) Koch, N., "A Comparative Study of Methods for Hypermedia Development", Technical
Report 9905, Ludwig-Maximilians Universitat, Munich, Alemania, 1999, se puede descargar
de http:/ /www.dsic.upv.es/-west2001 /iwwostO l /files/contributions/NoraKoch/hyp dev.pdf.
[KRA88J Krasner, G. y s. Pope, "A Cookbook for Using the Model-View Controller User Interface Paradigm in Smalltalk-80",Jouma/ ofObject-Oriented Programming, vol. 1, nm. 3, agosto-septiembre de 1988, pp.26-49.
[LOW98) Lowe, D., y W. Hall (eds.). Hypertexl and the Web-An Engneering Approach, John Wiley
& Sons, 1998.
[MCCOIJ McClure, s. J. Scambray y G. Kurtz, Hacking Exposed, McGraw-Hill/Osbome, 2001.
[MENOIJ Mendes, E., N. Mosley y s. Counsell, "Estimating Oesign and Authoring Effort", en IEEE
Multimedia, enero-marzo de 2001, pp. 50-57.
[MILOOJ Miller, E., "The Website Quality Challenge", Software Research, lnc., 2000, http://www.
soft.com/eValid/Technology/White.Papers/website.quality.challenge.html.
[NIE96] Nielsen, J. y A. Wagner, "User Interface Design for the WWW", Proc. CH/ '96 Conf On Human Factors in Computi.ng systems, ACM Press, 1996, pp. 330-331.
[NIEOOJ Nielsen. J., Designing Web UsabiliOJ, New Riders Publishing, 2000.
[NOR02) Northcutt, S. y J. Novak, Network lntrusion Detection, New Riders Publishing, 2002.
[OFF02) Offutt, J., "Quality Attributes of Web Software Applications", en IEEE SOflware, marzoabril de 2002, pp. 25-32.
[OLS98] Olsina, L., "Building a Web-Based lnformation System Applying the Hypermedia Flexible Process Modeling Strategy", Proc. 1st Ind. Workshop on Hypermedia Development, 1998.
[0LS99] Olsina, L. et al., "Specifying Quality Characteristics and Attributes for Web Si tes", Proc.
1st ICSE Workshop on Web Engineering, ACM, Los Angeles, mayo de 1999.
[PER99J Perzel, K. y D. Kane, "Usability Pattems for Applications on the World Wide Web", 1999,
se puede descargar de http://jeny.cs.uiuc.edu/-plop/plop99/proceedings/Kane/perzel
kane.pdf.
[POWOO] Powell, T., Web Design, McGraw-Hill/Osbome, 2000.
[RASOOJ Raskin, J., The Humane Interface, Addison-Wesley, 2000.
[RH098J Rho, Y. y T. Gedeon, "Surface Structures in Browsing the Web", Proc. Australasian Computer Human lnteraction Conference, IEEE, diciembre de 1998.
[SCH95) Schwabe, D. y G. Rossi, "The Object-Otiented Hypennedia Oesign Model", en CACM, vol.
38, nm. 8, agosto de 1995, PP. 45-46.
602
PARTE TRES
[SCH98) Schwabe, D. y G. Rossi. "Developing Hypermedia Applications Using OOHDM", Proc

Workshop on Hype1media Developmenl Process, Melhods and Models, Hyperlext '98, 1998, se
puede descargar de http:/ / citeseer.nj.nec.com / schwabe98developing.html.
[SCHOl] Schwabe. D., G. Rossi y S. Barbosa, "Systematic Hypermedia Application Design Using
OQHDM", 2001, disponible en http://www-di.inf.puc-rio.br/-schwabe/HT96W\o\TW
section l .html.
[TILOO] Tillman, H. N., "Evaluating Quality On lhe Net", Babson College, 30 de mayo de 2000, disponible en http://www.hopetillman.com/ findqual.hlml#2
(TOGOIJ Tognozzi, B., "Firsl Principies", askTOG, 2001, disponible en http://www.asktog.com
basics/firstPrinciples.html.
[WMT02J Web Mapping Testbed Tutorial, 2002, disponible en http:/ /www.webmapping
org/vcgdocuments/vcgTUtorial/.
[ZHA02] Zhao, H., "Fitt's Law: Modeling Movement Time in HCI", Theories in Computer Huma:'
lnteraction, University of Maryland, octubre de 2002, disponible en http:/ /www.cs.umd.edu
class/fall2002/cmsc838s/tichi/fitts.html.
19. l. Por qu el "ideal artstico" es una filosofa de diseo insuficiente cuando se construye
las WebApps modernas? Existe un caso en el que el ideal artstico sea la mosofia que debe St
guirse?
19.2. En este captulo se analiz una amplia variedad de atributos de calidad para las WebApps. Eljanse las tres que se considere como las ms importantes y elabrese un argumer.
que explique por qu cada uno debe resaltarse en el trabajo de diseo de ingeniera Web.
19.3. Agrguense al menos cinco preguntas adicionales a la "Lista de verificacin de la calici:
del diseo de la WebApp" presentada en una barra lateral en la seccin 19.1.1.
19.4. Revisar los principios de diseo de la interfaz de Tognozzi tratados en la seccin 19.3
Considerar cada principio para una WebApp operativa con la cual se est familiarizado. Ca1..
car la WebApp (sense calificaciones A, B. C, D o F) en relacin con el grado en el cual ha
grado el principio. Explicar la razn para cada calificacin.
19.5. Disear una interfaz prototipo para la WebApp de Hogarsegurotnc.com. Intntese ser::novador pero, al mismo tiempo, se debe asegurar que la interfaz se ajusta a los principios ~
el buen diseo de la interfaz.
19.6. Se han encontrado mecanismos de control de la interfaz que sean diferentes a los al\'
tactos en la Seccin 19.3 2? Si es as, describanse brevemente.
19. 7. El lector es el diseador WebApp para una compaa de enseanza a larga distancia
intencin es implementar un motor de aprendizaje" basado en Internet que le permitir ent:
gar contenido del curso a los estudiantes. El motor de aprendizaje ofrece la infraestructura 1:
sica para entregar contenido de aprendizaje de cualquier materia (diseadores de conteni_
prepararn el contenido adecuado). Desarrllese un diseo de interfaz prototipo para el mo..
de aprendizaje.
19.8 . Cul es el sitio Web estticamente ms agradable que el lector haya ha visitado y por qi..
19.9. Considerar el objeto de contenido pedido, generado una vez que un usuario de Hog:.
Segurolnc.com ha completado la seleccin de todos los componentes y est listo para finaliz
su compra. Desarrollar una descripcin UML de pedido junto con todas las representaciones
diseo apropiadas.
19. 1o. Cul es la diferencia entre arquitectura de contenido y arquitectura de WebApp'
19 . 11. Reconsidrese el "motor de aprendizaje" descrito en el problema 19.7, seleccinese i.
arquitectura de contenido que sera apropiada para la WebApp. Ccomntese por qu se hizo
cha eleccin.
CAPTULO 19 MODELADO DE DISEO PARA APUCACION'ES WEB
603
19.1 2. Con UML desarrllense tres o cuatro representaciones de diseo para objetos de contenido que podran encontrarse conforme se disea el "motor de aprendizaje" descrito en el problema 19.7.
19. 13 . Hacer un poco de investigacin adicional acerca de la arquitectura MVC y decidir si sera una arquitectura WebApp apropiada para el "motor de aprendizaje" mencionado en el problema 19.7.
19. 14. Cul es la diferencia entre sintaxis de navegacin y semntica de navegacin?
19. 15. Definir dos o tres USN para la WebApp de Hogarsegurolnc.com. Describir cada una con
cierto detalle.
19. 16. Hacer alguna investigacin y presentar a su clase dos o tres patrones de diseo hipermedia completos.
Aunque se han escrito cientos de libros acerca del "diseo Web", muy pocos abordan algunos
mtodos tcnicos significativos para realizar el trabajo de diseo. Cuando mucho, se presentan
varios lineamientos tiles para el diseo de la WebApp, ejemplos valiosos de pginas Web y se
muestra programacin Java, y se analizan los detalles tcnicos importantes para implementar
WebApps modernas. Entre los muchos que se ofrecen en esta categora, vale la pena considerar la discusin enciclopdica de Powell [POWOO]. Adems, los libros de Galitz [GAL02l, Heinicke [HEI02J, Schmitt (Designing CSS Web Pages, New Riders Publishing, 2002), Donnelly (Designing Easy-to-Use Websites, Addison-Wesley, 2001) y Nielsen (NIEOO] proporcionan una gua til.
La visin gil del diseo (y otros tpicos) para WebApps la presentan Wallace y sus colegas
(Extreme Programmingfor Web Projects, Addison-Wesley, 2003). Conallen (Building Web Applica
tions with UML, segunda edicin, Addison-Wesley, 2002) y Rosenberg y Scott (Applying Use-Case Driven Object Modeling with UML, Addison-Wesley, 2001) presentan ejemplos detallados de
WebApps modeladas con la aplicacin de UML.
Van Duyne y sus colegas (The Design ofSites: Pattems, Principies and Processes, Addison-Wesley, 2002) escribieron un libro excelente que cubre los aspectos ms importantes del proceso de
diseo en la ingeniera Web. Se cubren en detalle los modelos de proceso de diseo y los patrones de diseo. Wodtke (lnjormation Architecture, New Riders Publishing, 2003). Rosenfeld y Morville (Information Architecturefor the World Wide Web, O'Reilly & Associates, 2002), y Reiss (Practica] Tnformation Architecture, Addison-Wesley, 2000) abordan la arquitectura de contenido y
otros tpicos.
Las tcnicas de diseo tambin se mencionan en libros escritos acerca de ambientes de desarrollo especficos. Los lectores interesados deben examinar libros acerca de J2EE, Java, ASP.NET,
CSS, XML, Peri y una diversidad de aplicaciones de creacin de WebApps (Dreamweaver, Home
Page, Frontpage, GoUve, MacroMedia Flash , etc.) para comentarios de diseo tiles.
En Internet est disponible una gran variedad de fuentes de informacin acerca de diseo
para ingeniera Web. Una lista actualizada de referencias en la World Wide Web se encuentra en
el sitio Web de SEPA:
http:/ / www.mhhe.com/pressman.
"E
xiste una urgencia .que siempre perinea el proc;eso di? ingenie na Web. C<r
aira<tristiIJ
dumr
..... .606
.,
dhJtell$iones
de lll!lldad .... .60S
eslmtegia . 607
prllehos
dtbasecle
datos .. ; .. ,.613
cle<l'.~ .....633
d D!lftguNldII 628
de corrttnlclo ..6J 2
de desempeo 6l J
de fodlidad
'
deuso .....620
de interfoz
dnsuario ..616
ele navegacin 62S

ele aivel de
componentes 623
de prueba de com-
patibdiclad 622
forme se ct.rigen la formulacin, la planeacin, el anlisis, el diseo y

consttuccin, los participantes-preocupados ace.rca de la competencia
1 otras WebApps;: fustigad<:>s por las demandas de los cliente~ e inttanquilos por
perdern 1,ma ventana eri el mercado- presionan para pqner la WebApp en Hne2
Como consec~ncia, las actividades tcnicas que usualmente ocurren en las lt
mas etapas del prceso de ingeniera Web, como la prueba de la WebApp, en o
siones reciben poca atencin, Esto puede ser un error catast:rfieo. Para evita
el equpo de in8enierfa Web debe asegurarse de que cada producto de trabac
IWb muestre alta cali(lad. Wallace ~ sus colegas fWA.l03J advierten esto cua:
~M~:
Uevar a cabo la prueba'n<> debe esperar hasta que termine et proyecto, Comience a
probar antes de'e:scribfr u11a lnea <le cdigb. Pruebe con~tante y efectivamente y desarrollar un sitio Web much.o ms durable.
Dado que las modelos de an~lisis y diseo no pueden ponerse a prueba en

sentido clsico, el equipo de ingenieria Wel:> ge.be dirigir revisiones tcnicas ;o:
males (captulo 26), asi como pruebas ejecutables, El objetivo es descubrir y corregir errores antes de que la Web/1.pp se po;iga a disposicin de sus usuarios
nales,
de te1sl1 .. .633
~o
pn,,bo brel~
~ . ......ea,1 uno
'".ma
. sola
me..
"
Jivdddes
Qu e,? Etpt<)C8$<> d
u.(IQ
. ..
to: de.scubrir ores.en el eonlenida,. tQ
.
. \ncQn~ lo fadlilad de tllOt lo J1<M90,
bilidoa, el dsempeor fo copacidxly - ~
de Id ~bApp. fsto se lgfa a lo l<Jtgq d to el
proc~ Je ingeniera Web ~ani. Jo gpli(aci6n

de una e~lrotegia de ~ qoe, obarco tanto rew
siones como prnebas.e~uk!bles.
Quin fo llo<e? Los ingenieros Webyotros participantes ~t proxecto (gerEITT~, clieQlel, usua
ros fnalesl toman porte eo el proceso a pt()bar
laWebApp.
Por qu es imPQrtante? Si los !l$U<Jrfos fino
les encuentron -errores <t' ofuten so confionzt:l
en lo WebApp, .se irn d oo.olquier trc;i porte
por el contenid }' ltr funcin que necesik:m, y lo

WebApp frocos.ar, 4?or eslQ' rozn,.los lilgenieros. Web debfin 1rabajor paro eliminar tontos
errores como seo ~sible antes de qve lo WebApp e$l ,en 1rnea,
Clesc .ton ._ ,paso,? El proceso <le pruebo
de ,lo ~ ,comientQ .CJI enfocarse sobre
aquellos ~ ~ que son vi$ibles para
el tJJuc;irio y proc:ed.ct (\ probar dkho tecnologa
e inlrciestn.lctur. I.Q pruei)Q ~oosta de $iete eta
pm: contenido, interfaz, n~~in, CC>fllpo
nenkt, conngurQCiOli, ~peo y pruebo de

seguridad,
Cual es .r .proclu<to obtenido? Eri cdgunos
casos$$ produce uh plan de pruebo de ta WebApp, En todos lo$ CQJ05 se desarrollo un confun
to de c;asos~ pal'Q (OG(I etopo de b prue
CAPTULO 20
CMO PROBAR APLICACIONES WEB
605
la MgUridad de q!JEt lo puesto ~ prvebQ.ha

c:f.aDerto errores {y qve stos se han correg-
e): Adems, ti se ha establecido un plan de

..._,!*"
wrificarse J)Qro CISguror que
81--lltfJl-l!Dlli11tzc1G1adc10t todoa ldJ.pruebas planeados.
.$G
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 fundamental 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 celulares). plataformas de hardware, protocolos de comunicaciones y aplicaciones "de
cuarto trasero", la bsqueda de errores representa un desafio significativo para los
ingenieros Web.
La comprensin de los objetivos de las pruebas dentro de un contexto de ingeniera Web requiere considerar las diversas dimensiones de la calidad WebApp. 1 En el
contexto de esta exposicin se consideran las dimensiones de calidad que son particularmente relevantes en cualquier debate de las pruebas para el trabajo de ingeniera Web. Tambin se considera la naturaleza de los errores que se encuentran como consecuencia de las pruebas,
descubrir dichos errores.
y la estrategia de poner a prueba aplicable para
20.1 . 1 Dimensiones de calidad

La calidad se incorpora en una aplicacin Web como consecuencia de un buen diseo. se eval a al aplicar una serie de revisiones tcnicas que valoran varios elementos 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 siguientes dimensiones de calidad [MILOOJ :
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 exactitud (de la informacin presentada), la consistencia (a travs de todos los objetos de contenido y objetos relacionados. y la falta de ambigedad.
La funcin se prueba para descubrir errores que indiquen que no hay concordancia con los requisitos del cliente. cada funcin de la WebApp se valora en
1 En el captulo 19 tambin se consder la calidad de la web:1.pp.
606
cuanto a exactitud, inestabilidad y concordancia general con los estndares de

implementacin apropiados (por ejemplo, estndares de lenguaje Java o XML)
La estructura se valora para asegurarse de que entrega adecuadamente conte-
nido y funcin de la WebApp, que es extensible y puede sostenerse conforme

se aade nuevo contenido o funcionalidad.
Lafacilidad de uso se prueba para garantizar que a cada categoria de usuario
la soporta la interfaz; puede aprender y aplicar toda la sintaxis y semntica de
navegacin requerida.
La navegabldad se pone a prueba para garantizar que toda la sintaxis y se-
mntica de navegacin se ejercen para descubrir cualquier error de navegacin (por ejemplo, vnculos rotos, vnculos inadecuados, vnculos errneos).
El desempeo se prueba en una diversidad de condiciones operativas, configt.
raciones y cargas para asegurar que el sistema responde a la interaccin del
usuario y maneja cargas extremas sin que haya una degradacin operativa
inaceptable.
La compatibilidad se prueba al ejecutar la WebApp en varias configuraciones
husped, en los lados tanto del cliente como del servidor. El objetivo es encontrar errores especficos respecto a slo una configuracin husped.
La interoperabilidad se prueba para asegurar que la WebApp realiza interface..
adecuadas con otras aplicaciones o bases de datos.

La seguridad se prueba al valorar las vulnerabilidades potenciales e intentar
explotar cada una de ellas. Cualquier intento de penetracin exitoso se cons

dera una falla en la seguridad.
En este captulo se estudian, ms adelante, una estrategia y algunas tcticas que _
han desarrollado para poner a prueba cada una de las anteriores caractersticas ...
calidad de una WebApp.
,O i1111ovod6n es un osunto 119ridulce poro quienes ponen aprueba el soflwore. Justo cuando parece qtl se sabe
<!fflO probaru1Jo 18!:00logo particular, llego una nuevo [WebApp] ytodas 1~ apues~ se pierden."
l
20.1.2 Errores dentro de un ambiente WebApp

Ya se ha sealado que el intento primario de realizar pruebas en cualquier cante}"
de software es descubrir errores (y corregirlos). Los errores encontrados como co
secuencia de la prueba exitosa de la WebApp tienen varias caractersticas niea:
[NGUOOJ:
1. Puesto que muchos tipos de pruebas de WebApp descubren problemas que s
evidencian primero en el lado del cliente (es decir, a travs de una interfaz
implementada en un navegador especfico, una PDA o un telfono celular), e
ingeniero web ve un sntoma del error, no el error en s.
CAPTULO 20 CMO PROBAR APLICACIONES WEB
607
2. Puesto que una WebApp se implementa en varias configuraciones diferentes y

dentro de distintos ambientes, puede ser dificil o imposible reproducir un
error afuera del ambiente en el que el error se encontr originalmente.
3. Aunque algunos errores son resultado de un diseo incorrecto o una codificacin HTML impropia (o algn otro lenguaje de programacin), muchos errores
pueden rastrearse hacia la configuracin de la WebApp.
4. Puesto que las WebApp residen dentro de una arquitectura cliente/servidor, el

rastreo de los errores puede ser dificil a travs de las tres capas arquitectnicas: el cliente, el servidor o la red en si.
5. Algunos errores se deben al ambiente operativo esttico (es decir, la configuracin especfica en la que se desarrolla la prueba), mientras que otros son
atribuibles al ambiente operativo dinmico (es decir, la carga instantnea de
recursos o los errores relacionados con el tiempo).
Estos cinco atributos de error sugieren que el ambiente desempea un importante
papel en el diagnstico de todos los errores descubiertos durante el proceso de ingeniera Web. En algunas situaciones (por ejemplo, prueba de contenido), el sitio del
error es obvio, pero en muchos otros tipos de pruebas de WebApp (por ejemplo,
pruebas de navegacin, de desempeo, de seguridad) la causa subyacente del error
tal vez sea considerablemente ms dificil de determinar.
20.1 .3
Estrategias de pruebas
La estrategia para probar una WebApp adopta los principios bsicos para todas las
pruebas de software (captulo 13) y aplica una estrategia y las tcticas que se recomendaron respecto de los sistemas orientados a objetos (capitulo 14). Los siguientes pasos resumen el enfoque:
1. Se revisa el modelo de contenido de la WebApp para descubrir errores.

2. Se revisa el modelo de la interfaz para asegurarse que todos los casos de uso
pueden acomodarse.
3. Se revisa el modelo de diseo de la WebApp para descubrir errores de navegacin.
4. Se prueba la interfaz del usuario para descubrir errores en la presentacin o

los mecanismos de navegacin.
5. Componentes funcionales seleccionados se prueban en forma individual.
6. Se prueba la navegacin a travs de toda la arquitectura.

7. La WebApp se implementa en diversas configuraciones ambientales y se
prueba su compatibilidad con cada configuracin.
8. Se realizan pruebas de seguridad con el objetivo de explotar vulnerabilidades

en la WebApp o dentro de su ambiente.
608
PARTE TRES
1mifo,fru11
Se~jh(-
exclllenlisriub
ocemilos pruebas. de ,
~1111
''"'
www.silckytliJll,il.
fttstfiJ;tisP.
APUCACI N DE LA INGENIERA WEB
9. Se llevan a cabo pruebas de desempeo.

1O. La WebApp se prueba en una poblacin controlada y monitoreada de usuari ~
finales; los resultados de su interaccin con el sistema se evalan para buse2
errores de contenido y navegacin, relacionados con la facilidad de uso, cor
la compatibilidad y con la confiabilidad y el desempeo de la WebApp.
Puesto que muchas WebApps evolucionan continuamente, la prueba de la Web/ .
es una actividad de seguimiento que dirige el equipo de soporte Web, que utL.:
pruebas de regresin derivadas de las pruebas desarrolladas cuando la WebApp
someti a ingeniera por primera ocasin.
20.1.4 Planeacin de las pruebas

El empleo de la palabra planeacin (en cualquier contexto) es anatema para algu:desarrolladores Web. Como se anot en capitulas anteriores. dichos profesionz..
slo comienzan, pues temen el surgimiento de algn saboteador de WebApps. Un
geniero Web reconoce que la planeacin establece un mapa vial para todo el t:rcc
jo que sigue. Vale la pena el esfuerzo.
En su libro acerca de las pruebas de las WebApps, Splaine y Jaskiel [SPLO 1] afinr
~,
&1
c&v1
El pion de pruebo
identifico un conjunto
de toreos de pruebo,
los productos de
trobojo que se
desorrollorn y lo
formo en lo cual los
resultados se evalan,
registron y reutilizan.
Excepto por el ms simple de los sitios Web, rpidamente se vuelve aparente que es necesaria cierta especie de planeacin de pruebas. Con demasiada frecuencia, el nmero m
cial de errores que se encuentran a partir de una prueba adecuada es lo suficienteme~
grande como para que no todos se fijen la primera vez que se detectan. Esto pone una presin adicional sobre la ge nte que prueba los sitios y aplicaciones Web. No slo deben crr
jurar nuevas pruebas imaginativas, tambin deben recordar cmo se ejecutaron .a.
pruebas anteriores con la finalidad de volver a probar con confiabilidad el sitio/la aplia:
cin Web, y asegurarse de que los errores conocidos se han removido y que no se han ""-troducido otros nuevos.
La pregunta para todo ingeniero Web es: cmo "conjuro nuevas pruebas irr:
nativas" y en qu se deben enfocar dichas pruebas? La respuesta se encuentra .:;
tro de un plan de pruebas.
Un plan de pruebas WebApp identifica 1) un conjunto de tareas2 que se aplicz.
cuando comience la prueba, 2) los productos de trabajo que se generarn confc
se ejecute cada tarea de prueba, y 3) la forma en la que los resultados de las zbas se evalan, registran y reutilizan cuando se realicen pruebas de regresin. Er
gunos casos, el plan de pruebas se integra con el plan del proyecto; en otros, el ~
de pruebas es un documento separado.
2 Los conjuntos de tareas se estudian en el capitulo 2. En este libro tambin se ha empleado 1r

mino relacionado - flujo de trabajo- para describir la serie de tareas necesaria para completa:
actividad de ingeniera del software.
609
Los procesos de prueba para ingeniera Web comienzan con pruebas que ejercitan
el contenido y la funcionalidad de la interfaz que es inmediatamente visible para los
usuarios finales. conforme se realizan las pruebas, se ejercitan los aspectos de la arquitectura de diseo y la navegacin. El usuario puede o no conocer estos elementos de la WebApp. Finalmente, el foco se cambia a las pruebas que ejercitan las capacidades tecnolgicas que no siempre son aparentes para los usuarios finales: la in fraestructura de la WebApp y cuestiones de instalacin/implementacin.
La figura 20. l yuxtapone el proceso de prueba WebApp con la pirmide de diseo examinada en el captulo 19. Ntese que, conforme se desarroll el flujo de pruebas, de izquierda a derecha y de arriba abajo, los elementos del diseo WebApp visibles para el usuario (elementos superiores de la pirmide) se prueban primero, seguidos por los elementos de diseo de infraestructura.
',,
----Prueba de
configuracin
''
' '\
tecnologa
1
1
- -- -----.J
Pruebo de
mpeo
dese
,,
\
''
Pruebo de
segurida d
,,
I
''
/
/
', .......... _________ ,,.,.
/
-///
610
PARTE TRES
APUCACJN DE LA INGENIERA WEB
La prueba de contenido (y las revisiones) intentan descubrir errores en el cante:"

do. Esta actividad de prueba es similar en muchos aspectos a la copia-edicin de Ldocumento escrito. De hecho, un gran sitio Web puede reclutar los servicios de un c1.
rrector de estilo profesional para descubrir errores tipogrficos, equvocos grama_
cales, errores en la consistencia del contenido, inexactitudes en las representaciolk:
grficas y fallas en las referencias cruzadas. Adems de examinar el contenido esL
tico en busca de errores, esta etapa de las pruebas tambin considera el contera.:.
dinmico derivado de los datos conservados como parte de un sistema de base
datos integrado a la WebApp.
La prueba de la interfaz ejercita los mecanismos de interaccin y valida los aspee
tos estticos de la interfaz del usuario. El objetivo es descubrir los errores que rest.
tan de mecanismos con una pobre implementacin de interaccin, u omisiones, inccsistencias o ambigedades que se han introducido a la interfaz en forma inadvertida
La prueba de navegacin aplica casos de uso, derivados como parte de la act:J
dad de anlisis, en el diseo de casos de prueba que ejerciten cada escenario de i...,.
contra el diseo de navegacin.
Los mecanismos de navegacin (por ejemplo, barras de men) implementaa

dentro de la plantilla de la interfaz se prueban contra casos de uso y USN (capt....
19) para garantizar que los errores que impiden completar un caso de uso se ider
fiquen y corrijan.
La prueba de componentes ejercita el contenido y las unidades funcionales der
de la WebApp. Cuando se consideran las WebApps, cambia el concepto de uru (introducido en el captulo 13). La "unidad" de eleccin dentro de la arquitectura
contenido (capitulo 19) es la pgina Web. Cada pgina Web encapsula conteru
vnculos de navegacin y elementos de procesamiento (formatos, guiones, apple.
Una "unidad" dentro de la arquitectura WebApp puede ser un componente funciodefinido que proporciona servicio directamente a un usuario final o un componede infraestructura que posibilita que la WebApp desarrolle todas sus capacidad.:
cada componente funcional se prueba, en gran parte, en la misma forma que
prueba un mdulo individual en el software convencional. En la mayora de los sos, las pruebas estn orientadas a las cajas negras. Sin embargo, si el procesamie;to es complejo, tambin se pueden usar pruebas de cajas blancas. 3 Adems de
prueba funcional, tambin se ejercitan las capacidades de bases de datos.
Lo estrategia paro la
pruebo de integracin
depende de lo
orquitec11Jro de la
WebApp elegida
tboote el diseo.
Conforme se construye la arquitectura de la WebApp, las pruebas de la nave:;

cin y los componentes se utilizan como pruebas de integracin. La estrategia pa;
la prueba de integracin depende del contenido y la arquitectura WebApp que se t:
ya elegido (captulo 19). Si la arquitectura de contenido se disea con estructura
neal, retcula o jerrquica simple, es posible integrar pginas Web en gran parte _
la misma forma como se integran mdulos para el software convencional. Sin ebargo, si se usa una estructura de jerarqua mixta o de red (Web), la prueba de in ~
3
Las tcnicas de pruebas de caja negra y caja blanca se examinan en el captulo 14.
CAPTULO 20
CMO PROBAR APUCAOONtS WEB
611
gracin es similar al enfoque usado para los sistemas OO. Las pruebas basadas en
ligas (capitulo 14) se pueden aprovechar para integrar el conjunto de pginas Web
(se puede usar una USN para definir el conjunto apropiado) requerido para responder a un evento de usuario. cada liga se integra y pone a prueba individualmente.
Mediante las pruebas de regresin se asegura que no ocurran efectos colaterales.
Las pruebas de agrupamiento integran un conjunto de pginas asociadas (determinadas mediante el examen de los casos de uso y la USN). Los casos de prueba se derivan para descubrir los errores en las colaboraciones.
Cada elemento de la arquitectura WebApp se prueba de manera unitaria en la medida de lo posible. Por ejemplo, en una arquitectura MVC (captulo 19), los componentes modelo, vista y controlador se prueban cada uno de manera individual. Despus de la integracin, el flujo de control y datos a travs de cada uno de estos elementos se valora en detalle.
Las pruebas de configuracin intentan descubrir los errores que son especficos
respecto de un cliente o ambiente de servidor particulares. Se crea una matriz de referencia cruzada que define todos los probables sistemas operativos, navegadores,4
plataformas de hardware y protocolos de comunicacin. Entonces las pruebas se encaminan a descubrir los errores asociados con cada posible configuracin.
La prueba de seguridad incorpora una serie de pruebas diseadas para explotar las
vulnerabilidades en la WebApp y su ambiente. El objetivo es demostrar la posibilidad
de una brecha en la seguridad.
La prueba de desempeo abarca una serie de pruebas diseadas para valorar 1)
cmo afecta el aumento del trfico de usuarios la respuesta en tiempo y confiabilidad de la Web, 2) cules componentes de la WebApp son responsables de la degradacin del desempeo y qu caractersticas de uso provocan que ocurra la degradacin, y 3) cmo la degradacin del desempeo impacta los objetivos y requisitos globales de la WebApp.
1. Revisor los requisitos de los

participantes. Identificar los metas y
objetivos de los usuarios. Revisor los
cosos de uso respecto de codo
categora de usuario.
::slablecer prioridades poro asegurar que codo meto
objetivo de usuario se probarn de manero
::oecuodo.
3. Definir lo estrategia de pruebo de lo WebApp al

describir los tipas de pruebas (seccin 20.2) que se
realizarn.
4. Desarrollar un pion de prueba.
Definir un calendario de pruebas y asignar
responsabilidades a coda prueba.
Especificar herramientas automatizados para
realizar las pruebos.
Los navegadores son notables porque implementan sus propios estndares", sutilmente diferentes
en las interpretaciones de HTML y Javascnpt.
612
Definir criterios de aceptacin poro codo clase

de pruebo.
Especificar mecanismos de rastreo de defectos
Definir mecanismos de reporte de problemas.
5. Realizar pruebas HunitariasH.
Revisor el contenido para errores de sintaxis
y semntica.
Revisor el contenido poro clarificaciones y permisos
adecuados.
Probar los mecanismos de lo interfaz para uno
operacin correcto.
Probar codo componente (por ejemplo, guin) paro

asegurar el funcionamiento adecuado.
6. Realizar pruebas de "integracin".
Probar la semntico de lo interfaz respecto de los
casos de uso.
Dirigir pruebas de navega cin.
7 Realizar pruebas de configuracin.
Valorar lo compatibilidad de configuracin en el
lodo del cliente.
Voloror configuraciones en el lodo del servidor.
8. Dirigir pruebas de desempeo.
9. Dirigir pruebas de seguridad.
Los errores en el contenido de la WebApp pueden ser tan triviales como errores
pogrficos menores o tan significativos como informacin incorrecta, organizac.
Aunque los revisiones
tcnicos farmo/es no
son porte de IJl1(I
pruebo, se deben
llevar ocabo revi-
siones de contenido
JXXD garontiztx lo
cofml del contenido.
~,
C~VE
los objetivos de lo
p,uebo de contenido
son l) descubrir errores
sintcticos en el
contenido, 2) descubrir
err01es semnticos y 3)
encontrar errores
estructurales.
impropia o violacin de las leyes de propiedad intelectual. La prueba del conteru:.:::

intenta descubrir stos y muchos otros problemas antes de que el usuario los e::;
cuentre.
La prueba del contenido combina tanto revisiones como la generacin de casos ~
prueba ejecutables. La revisin se aplica para descubrir errores semnticos en el e
tenido (examinados en la seccin 20.3.1 ). La prueba ejecutable se aprovecha para des
cubrir errores de contenido susceptibles de rastrear hacia contenido dinmicame
derivado que hayan suministrado los datos adquiridos de una o ms bases de dat-..s..
20.3.1 Objetivos de la prueba de contenido

La prueba del contenido tiene tres objetivos importantes: 1) descubrir errores sinta.
ticos (por ejemplo, errores tipogrficos, equvocos gramaticales) en los documen

basados en texto, representaciones grficas y otros medios audiovisuales, 2) descbrir errores semnticos (es decir, errores en la precisin de la informacin o que ea
ta sea incompleta) en cualquier objeto de contenido presentado conforme ocurra
navegacin, y 3) hallar errores en la organizacin o estructura del contenido que
presenla al usuario final.
El primer objetivo se logra empleando verificadores de ortografia y gramtica a
tomatizados. Sin embargo, muchos errores sintcticos evaden la deteccin mediate tales herramientas y debe descubrirlos un revisor humano (examinador). Como
anot en la seccin anterior, la correccin de estilo es el mejor enfoque para enea:
trar errores sintcticos.
La prueba semntica se centra en la informacin presentada dentro de cada o.;
jeto de contenido. El revisor (examinador) debe responder las siguientes pregunta..
La informacin realmente es precisa?
La informacin es concisa y exacta?
CAPTIJLO 20
CMO PROBAR APUCAClONES WEB
613
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 internamente 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 complementan 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 estas preguntas en una WebApp grande
(que contiene cientos de objetos de contenido) puede ser una labor atemorzante.
Sin embargo, el fracaso para descubrir errores semnticos 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 organizacin de la arquitectura del contenido se prueba para garantizar que el contenido requerido se presenta al usuario final en el orden y las relaciones adecuados. Por ejemplo, la WebApp HogarSegurolnc.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 tcnicas, una representacin fotogrfica e informacin relacionada. Las pruebas de la arquitectura de contenido de HogarSeguroinc.com se esfuerzan por descubrir errores
en la presentacin de esta informacin (por ejemplo, una descripcin del Sensor X
se presenta con una fotografia del Sensor Y).
20.3.2 Prueba de las bases de datos

Las modernas aplicaciones Web hacen mucho ms que presentar objetos de contenido estticos. En muchos dominios de aplicacin, la interfaz de las WebApps con
bases de datos sofisticados gestionan sistemas y construyen objetos de contenido dinmicos que se crean ~n tiempo real aprovechando datos adquiridos de una base de
datos.
Por ejemplo, una WebApp de servicios financieros puede producir compleja informacin basada en texto, tabular y grfica acerca de una participacin accionaria especfica (por ejemplo, fondos de acciones o de inversin colectiva). El objeto de contenido compuesto que presenta esta informacin se crea dinmicamente despus de
5
La WebApp Hogarsegurolnc.com se ha utihzaoo como ejemplo a lo largo de la Parte 3 de este libro.
61 4
PARTE TRES APLlCACIN DE LA INGENIERA WEB
que el usuario ha consultado informacin acerca de una participacin accionaria especifica. Esto se logra mediante los siguientes pasos: 1) se consulta una gran base
de datos de participaciones accionarias, 2) se extraen datos relevantes de la base de
datos, 3) los datos extrados se deben organizar como un objeto de contenido, y .,
este objeto de contenido (que representa informacin personalizada solicitada paun usuario final) se transmite al ambiente del cliente para su despliegue. Los errorec:
pueden ocurrir, y de hecho lo hacen, como consecuencia de cada uno de estas etapas. El objetivo de probar la base de datos 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, [SQL, por sus siglas e:ingls]) que pueda introducirse en un sistema gestor de bases de datos (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.
Qu conflic
tos comphcan
la prueba de
bases de datos
para WebApps?
2. La base de datos quiz sea remota al servidor que hospeda la WebApp. Por lo
tanto, se deben desarrollar las pruebas que descubran los errores en la comunicacin entre la WebApp y la base de datos remota. 6
3. Los datos brutos adquiridos de la base de datos se deben transmitir al servidor de
la WebApp y formatearse adecuadamente para su transmisin subsecuente al

cliente. En consecuencia, se deben desarrollar pruebas que demuestren la validez de los datos brutos que recibe el servidor WebApp, y tambin se deben
crear pruebas adicionales que demuestren la validez de las transformaciones
aplicadas a los datos 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 estos cuatro factores, se deben aplicar los mtodos de diseo de casos de prueba para cada uno de los "estratos de interaccin" [NGUOIJ anotados 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
correctamente y extraiga o formatee adecuadamente datos del usuario; 3) los datoc
del usuario pasen correctamente a una funcin de transformacin de datos en el lado del servidor para formatear consultas apropiadas (por ejemplo, SQL); 4) las col'-
Dichas pruebas se vuelven complejas cuando se encuentran bases de datos distribuidas o cuan::
se requiere el acceso a un almacn de datos (captulo 10).
615
CAPTULO 20 CMO PROBAR APUCAClONES WEB
Estrato del diente: interfaz de usuario

guiones HTML
Estrato del servidor: WebApp
Datos del usuario
EJttoto del servidor: transfOfmqcin de <lotos

Datos del usuario -SQL
Datos brutos
SQL
Estroto de bas~ de dotos: acceso de datos
Base de datos
sultas pasen a un estrato de gestin de datos7 que se comunique con rutinas de acceso a bases de datos (potencialmente ubicadas en otra mquina).
Los estratos de transformacin de datos, gestin de datos y acceso a bases de datos, que se muestran en la figura 20.2, usualmente se construyen con componentes
reutilizables que se han validado por separado y como paquete. Si ste es el caso,
las pruebas de la WebApp se centran en el diseo de casos de prueba para ejercitar las interacciones entre el estrato del cliente y los primeros dos estratos del servidor (WebApp y transformacin de datos) mostrados 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 adecuadamente al lado del servidor. La capa WebApp en el lado del servidor se prueba para asegurar que los datos del usuario se extraen adecuadamente
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 datos se prueban para asegurar que se crea
el SQL correcto y que pasa a componentes apropiados de gestin de datos.
una exposicin detallada de la tecnologa subyacente que se debe entender para
disear apropiadamente dichas pruebas de bases de datos est ms all del alcance
de este libro. El lector interesado debe consultar [SCE02], [NGUOJJ y [BROOIJ.
7 La capa de gestin de datos por lo general mcorpora una interfase SQL al nivel de llamada (SQL
CLI) como puede ser Microsoft OLE/ AOO o la Conectividad de Bases de Datos Java oava Database
Connectivity, JDBC)
616
PARTE TRES
APLICACIN DE LA INGENIERlA WEB
~-
*Ciar!)diente$ e.(lrnicos (yo seo de negocios oconsumo) es improbo que tengomqs conflanzo '11111 !llfoN
que su&,''~ frecuentes periodos de inactividad, cuelgo olo mitad de uno transaccin otiene un mot'senfldo,a 11
fdda4 de uso. Los pr1141bos, por lo tonto, tienen unpapel importantsimo en el procllSO de d_,. gloW.*
. 2 P1 2BVIIA RI
t;A, .JlfillfAI
PIL PIPAIJQ
La verificacin y validacin de la interfaz del usuario de una WebApp ocurre en tres

puntos distintos durante el proceso de ingeniera Web. Durante la formulacin y e
anlisis de requisitos (captulos 17 y 18) se revisa el modelo de la interfaz para garantizar que se ajusta a los requisitos del cliente y a otros elementos del modelo d..
anlisis. Durante el diseo (captulo 19) se revisa el modelo de diseo de la intea.:
para garantizar que se han alcanzado los criterios genricos de calidad establecidos para todas las interfaces de usuario, y que los conflictos en el diseo de l a interfaz especficos de la aplicacin se han abordado adecuadamente. Durante las pruebas, e
enfoque se cambia a la ejecucin de los aspectos especficos de la aplicacin de la irteraccin del usuario segn se manifiestan mediante la sintaxis y la semntica de ..:
interfaz. Adems, las pruebas proporcionan una valoracin final de la facilidad de use
20.4.1
Estrategia de prueba de la interfaz
La estrategia global para la prueba de la interfaz es l) descubrir los errores relacionados con mecanismos especficos de la inteaz (por ejemplo, errores en la ejecticin adecuada de un vnculo de men o la forma en que los datos ingresan en U."
formulario), y 2) descubrir los errores en la forma en que la interfaz implementa a;:
semntica de navegacin, la funcionalidad de la WebApp o el despliegue de contenido. El cumplimiento de esta estrategia requiere lograr varios objetivos:
Las caractersticas de la inteifaz se prueban para asegurar que las reglas del diseo, la esttica y el contenido visual relacionado estn a disposicin del usuario s::error alguno. Las caractersticas incluyen tipo de fuentes, uso de color, marCon excepdn de
especificidades o,ien
todos o lo WebApp, lo
estrategia de lo
interfaz anotado oquf
es oplicoble o todos
los tipos de software
diente/servidor.
cos, imgenes, bordes, tablas y elementos relacionados que se generan conforme procede la ejecucin de la WebApp.
Los mecanismos individuales de la interfaz se prueban en una forma anloga a Je

prueba unitaria. Por ejemplo, las pruebas estn diseadas para ejercitar todas
las formas, creacin de guiones en el lado del cliente, HTML dinmico, guiones CGI, clasificacin por niveles de contenido y mecanismos de interfaz especficos de la aplicacin (por ejemplo, un carrito de compras para una
aplicacin de comercio electrnico). En muchos casos, las pruebas se pueden
enfocar exclusivamente en uno de dichos mecanismos (la "unidad") para excluir otras caractersticas y funciones de la interfaz.
Cada mecanismo de la inteifaz se prueba dentro del contexto de un caso de uso o

USN (captulo 19) para una categora de usuario especfica. Este enfoque de
617
CAPTULO 20 CMO PROBAR APUCAClONES WEB
pruebas es anlogo a las pruebas de integracin (capitulo 13) en que las pruebas se llevan a cabo conforme los mecanismos 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 USN selecc,onadas
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 conformidad con la semntica especifica 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 configuracin.
20.4.2 Prueba de mecanismos de la interfaz

Cuando un usuario interacta con una WebApp, la interaccin ocurre por medio de
uno o ms mecanismos de la interfaz. En el prrafo siguiente se presenta un breve
panorama de las consideraciones de prueba para cada mecanismo de la interfaz
[SPLOl).
Vnculos. 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 todos los vnculos asociados con la plantilla de la interfaz (por ejemplo, barras de men.
artculos indice) y luego ejecuta cada uno de manera individual. Adems, se deben
ejercitar los vnculos dentro de cada objeto de contenido para descubrir malas 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.
Formatos. En el mbito microscpico las pruebas se realizan para garantizar que 1)

las etiquetas identifican correctamente los campos dentro del formato y que los campos obligatorios estn identificados visualmente para el usuario; 2) el servidor recibe
toda la informacin contenida en el formato y ningn dato 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 funciones del navegador (por ejemplo, la flecha "retroceso") no corrompen los datos ingresados en un formato; y 5) los guiones que reahzan verificacin de error en los datos
ingresados funcionan de manera adecuada
y ofrecen mensajes de error significati-
vos.
En un nivel ms dirigido, las pruebas deben garantizar que 1) los campos del for
mato tienen ancho y tipos de datos adecuados; 2) el formato establece salvaguardas
apropiadas para evitar que el usuario ingrese cadenas de texto ms largas que cier-
Dichas pruebas se pueden llevar a cabo como parte de pruebas o de la inteaz o de navegacin.
618
tcoNsuoS.
Los pruebas de
creacin de guiones
en el lodo del diente

y los pruebas
osododos con el
HTML dinmico se
deben repetir siempre
que se libere uno
nuevo versin de un
navegador popular.
to mximo predefinido; 3) todas 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 entrada de datos; 5) la tecla de tabulador (o alguna otra) inicia el movimiento adecuado entre campos de formato.
Creacin de guiones en el lado del cliente. Las pruebas de caja negra se llevar
a cabo para descubrir los errores en el procesamiento confonne se ejecuta el guir
(por ejemplo, Javascript). Dichas pruebas usualmente se acoplan con pruebas de formatos, ya que la entrada del guin por lo general se deriva de los datos proporcionados como parte del procesamiento de los formatos. Se debe realizar una prueba
de compatibilidad para garantizar que el lenguaje de guin elegido funcionar adecuadamente en la configuracin ambiental que soporta la WebApp. Adems de poner a prueba el guin mismo, Splaine y Jaskiel [SPLOI] sugieren que "debe asegurarse
que los estndares de su compaia [WebApp] establecen el lenguaje preferido y la
versin del lenguaje de creacin de guiones que se usar para la creacin de guiones en el lado del cliente 0J en el lado del servidor)".
HTML dinmico. Cada pgina Web que contenga HTML dinmico se ejecuta par.:
garantizar que el despliegue dinmico es correcto. Adems, se debe llevar a catx.
una prueba de compatibilidad para garantizar que el HTML dinmico funciona adecuadamente en la(s) configuracin(es) ambiental(es) que soporta la WebApp.
Ventanas pop-up.9 Una serie de pruebas garantizan que I) la pop-up est ubicad
de manera adecuada y tiene un tamao apropiado; 2) la pop-up no cubre la ventara
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 desplazamiento y otros mecanismos ck
control agregados a la pop-up funcionan, estn ubicados adecuadamente y trabaja:
como se requiere.
Guiones CGI. Las pruebas de caja negra se dirigen centrndose en la integridad <k
los datos (conforme los datos pasan al guin CGI) y en el procesamiento del gui.~
una vez que los datos validados se han recibido. Adems, se pueden llevar a catx
pruebas de desempeo para asegurarse de que la configuracin del lado del sen .dar se puede ajustar a las demandas de procesamiento de invocaciones mltiples <L
los guiones CGI [SPLOJ].
Clasificacin por niveles del contenido. Las pruebas deben demostrar que la clasificacin por niveles de los datos est actualizada, se despliega adecuadamente y S'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 cookie est construid;;
de manera adecuada (contiene datos correctos) y se transmite de modo apropiado a.
La utilizacin de las pop-up se ha extendido mucho y son uno de los principales motivos de irrit:
cin para muchos usuarios. Deben usarse juiciosamente o evitarlas por completo.
CAPTULO 20
6 19
lado del cliente cuando se solicita contenido o funcionalidad especficos. Adems, se

prueba la propia persistencia de la cookie para garantizar que su fecha de expiracin
es correcta. En el lado del cliente, las pruebas determinan si la WebApp une adecuadamente las cookies existentes a una solicitud especfica (enviada al servidor).
Mecanismos de la interfaz especficos a la aplicacin. Las pruebas conforman

una lista de verificacin de funcionalidad y caractersticas que se definen mediante
el mecanismo de la interfaz. Por ejemplo, Splaine y Jaskiel [SPLOIJ sugieren la siguiente lista de verificacin para la funcionalidad carrito de compras definido para
una aplicacin de comercio electrnico:
La frontera (capitulo 14) prueba los nmeros mnimo y mximo de artculos
que pueden colocarse en el carrito.
Probar una solicitud de "verificacin" para un carrito vaco.
Probar el borrado adecuado de un artculo del carrito.
Determinar mediante prueba si el contenido del carrito se vaca con una compra.
Determinar mediante prueba la persistencia del contenido del carrito de compras (esto se debe especificar como parte de los requisitos del cliente).
Determinar mediante prueba si la WebApp puede recuperar el contenido del
carrito en alguna fecha futura (suponiendo que no se ha realizado compra alguna) si el usuario solicita que el contenido se guarde.
20.4.3 Prueba de la semntica de la interfaz

Una vez que cada mecanismo de la interfaz se ha probado de manera "unitaria", el
enfoque de la prueba de la interfaz cambia para considerar la semntica de sta. La
prueba de la semntica de la interfaz "evala cun bien el diseo se ocupa de los
usuarios, ofrece direccin clara, entrega retroalimentacin y mantiene consistencia
de lenguaje y enfoque" [NGUOIJ.
Una revisin exhaustiva del modelo de diseo de la interfaz puede ofrecer respuestas parciales a las preguntas implcitas en el prrafo anterior. Sin embargo, se
debe probar cada escenario de caso de uso (para cada categora de usuario) una vez
implementada la WebApp. En esencia, un caso de uso se convierte en la entrada para el diseo de una secuencia de pruebas. La finalidad de la secuencia de pruebas es
descubrir los errores que le impedirn al usuario lograr el objetivo asociado con el
caso de uso.
Conforme se prueba cada caso de uso, el equipo de ingeniera Web mantiene una
lista de verificacin para asegurarse de que todo artculo del men se ha ejercido al
menos una vez, y que todo vnculo anidado dentro de un objeto de contenido ha sido empleado. El objetivo es determinar si la WebApp ofrece un efectivo manejo del
error y recuperacin.
620
20.4.4 Prueba de la facilidad de uso

La prueba de la facilidad de uso es similar a la prueba de la semntica de la interfa(seccin 20.4.3) en el sentido de que tambin evala el grado en el cual los usuarr
pueden interactuar efectivamente con la WebApp, as como el grado en el cual
WebApp gua las acciones de los usuarios, proporciona retroalimentacin significa
tiva y fortalece un enfoque de interaccin consistente. Ms que enfocarse fijamer
en la semntica de algn objetivo interactivo, las revisiones y pruebas de la facilidz._
de uso se disean para determinar el grado en el cual la interfaz de la WebApp fac.
lita la vida del usuario. 10
Las pruebas de facilidad de uso puede disearlas un equipo de ingeniera w~
App, pero las pruebas mismas las llevan a cabo los usuarios finales. Se aplica la
guiente secuencia de pasos [SPLO 1}:
1. Definir un conjunto de categoras de prueba de facilidad de uso e identificar

las metas para cada una.
2 . Disear pruebas que permitirn evaluar cada meta.
3. Seleccionar los participantes que dirigirn las pruebas.
4 . Instrumentar la interaccin de los participantes con la WebApp mientras se

lleva a cabo la prueba.
5. Desarrollar un mecanismo para valorar la facilidad de uso de la WebApp.

La prueba de la facilidad de uso puede llevarse a cabo en varios grados de abst::
cin: 1) se puede valorar la facilidad de uso de un mecanismo de la interfaz espec:
co (por ejemplo, un formulario); 2) se puede evaluar la facilidad de uso de una pa
na Web completa (abarcando mecanismos de la interfaz, objetos de datos y rurnes relacionadas); o 3) se puede considerar la facilidad de uso de la WebApp ~
pleta.
Q11 cara<
teristicas de
fadlidod de no se
vuelven el foco de
las pruebas, y qu
objetivos especfi
cos se abordan?
El primer paso en la prueba de la facilidad de uso es identificar un conjunto de

tegoras de facilidad de uso y establecer objetivos de prueba para cada categora
siguientes objetivos y categoras de prueba (escritos en forma de pregunta) ilus:
este enfoque: 11
Interactividad: los mecanismos de interaccin (por ejemplo, mens desplegat.

botones, punteros) son fciles de entender y usar?
Plantilla: los mecanismos de navegacin, contenido y funciones estn coloa
en una forma que permiten al usuario encontrarlos rpidamente?
1O En este contexto se ha usado el tnnino "amigable para el usuario". Desde luego, el problema o
la percepcin de un usuario de lo que es una interfaz "amigable" puede ser radicalmente dc
de la de otras.
11 Para preguntas adicionales acerca de la facilidad de uso, vase "Facilidad de uso" en el captu..
CAPTULO 20
CMO PROBAR APUCAOONES WEB
621
Legibj}jdad: el texto est bien escrito y es comprensible? 12 Las representaciones

grficas son fciles de entender?
Esttica: la plantilla, el color, los caracteres y las caractersticas relacionadas
conducen a un uso ms sencillo? Los usuarios "se sienten cmodos" con la apariencia y la percepcin de la WebApp?
Caractersticas de despliegue: la WebApp utiliza en forma ptima el tamao y la
resolucin de la pantalla?
sensibilidad del tiempo: las caractersticas, funciones y contenido importantes
pueden utilizarse o adquirirse de manera oportuna?
Personalizacin: la WebApp se ajusta por s misma a las necesidades especificas
de las diferentes categoras de usuario o usuarios individuales?
Accesibilidad: Ja WebApp es accesible a las personas con discapacidades?
Dentro de cada una de estas categoras se disea una serie de pruebas. En algunos
casos, la "prueba" puede ser una revisin visual de una pgina Web. En otros, se
puede ejecutar de nuevo la prueba de semntica de la interfaz, pero en esta ocasin
son ms importantes las preocupaciones por la facilidad de uso.
Como ejemplo, considrese la valoracin de la facilidad de uso para la interaccin
y los mecanismos de la interfaz. Constantine y Lockwood [CON03] sugieren que se

revise y pruebe la facilidad de uso de la siguiente lista de caractersticas de la interfaz: animacin, botones, color, control, dilogos, campos, formularios, marcos, grficos, etiquetas, vnculos, mens, mensajes, navegacin, pginas, selectores, texto y
barras de herramientas. Conforme se valora cada caracterstica, los usuarios que
realizan la prueba la califican en una escala cualitativa. La figura 20.3 muestra un
Fcil de usar
F6cil de aprender
Complicada
Difcil de aprender
Engaoso
12 Se pueden aprovechar el Indice de Legibilidad FOG y otros para proporcionar una valoracin cuantitativa de la legibilidad. Vase para ms detalles httpH developer.gnome.org/documents/usabilty/
usability-readability.html
622
PARTE TRES APLICACIN DE LA INGENIER!A WEB
posible conjunto de "calificaciones" de valoracin que pueden seleccionar los ust.e

rios. Estas caHficaciones se aplican a cada caracterstica individualmente, a una p.:.
gina Web completa o a la WebApp como un todo.
~,
fo.l
c&v1
los WebApps se
ejewton dentro de uno
voriedod de ambientes
en el lodo deldiente.
El objetivo de los
pruebes de
compotibilidod es
descubrir errores
osociodos con un
ambiente especfico
(por ejemplo,
navegador).
20.4.5 Pruebas de compatibilidad

Las WebApps deben operar dentro de ambientes que difieren uno de otro. Diferer
tes computadoras, dispositivos de despliegue, sistemas operativos, navegadores
velocidad en las conexiones de red tienen una influencia significativa en las veloo
dades de procesamiento en el lado del cliente, la resolucin de despliegue y las ve
cidad de conexin. Las variaciones en el sistema operativo pueden provocar conc..
tos en el procesamiento de la WebApp. En ocasiones, los diferentes navegad~
producen resultados ligeramente diferentes, sin importar el grado de estandart:,;
cin HTML dentro de la WebApp. Los plug-in requeridos pueden o no ser fcilrner
accesibles para una configuracin particular.
En algunos casos, los pequeos conflictos de compatibilidad no representan P'"'>
blemas significativos, pero en otros se pueden encontrar serios errores. Por ejemr
las velocidades de descarga pueden volverse inaceptables; la falta de un plug-in -equerido puede hacer que el contenido no sea disponible; la diferencias en cuantr
navegador pueden cambiar drsticamente la plantilla de pgina; los estilos de fuec:
tes se pueden alterar y volverse ilegibles, o los formatos pueden estar organizad
de manera inadecuada. La prueba de compatibilidad se esfuerza para descubrir
chos problemas antes de que la WebApp est en lnea.
El primer paso en la prueba de compatibilidad es definir un conjunto de confif':
raciones de computadoras "encontrado comnmente" en el lado del cliente y sus
riantes. En esencia, se crea una estructura de rbol que identifica cada platafor-;
de computadora. los dispositivos de despliegue tpicos, los sistemas operativos s
portados en la plataforma, los navegadores disponibles, las probables velocid de conexin a Internet e informacin similar. A continuacin, el equipo de inger
ra Web produce una serie de pruebas de validacin de compatibilidad, derivadas
las pruebas de la interfaz existentes, pruebas de navegacin, pruebas de desem;
o y pruebas de seguridad. La finalidad de estas pruebas es descubrir errores o p:
blemas de ejecucin que se pueden rastrear hasta las diferencias de configuracicr.
623
=-
e, ' ............,..
GIi ... 11p11te t6cnico
Pero sigue louutau le ~ ho$la"'
Las pruebas al nivel de componentes, tambin llamadas pruebas de funcin, se enfocan sobre un conjunto de pruebas que intentan descubrir errores en las funciones de
la WebApp. Cada funcin WebApp es un mdulo de software (implementado en algn lenguaje de programacin o guiones) y se puede probar empleando las tcnicas
de caja negra (y, en algunos casos, de caja blanca) examinadas en el captulo 14.
Los casos de prueba al nivel de componentes con frecuencia se alimentan con entrada al nivel de formularios. Una vez definidos los datos de los formularios, el usuario selecciona un botn u otro mecanismo de control para iniciar la ejecucin. Son
comunes los siguientes mtodos de diseo de casos de prueba (captulo 14):
Particin de equivalenda. El dominio de entrada de la funcin se divide en ca-
tegoras o clases de entrada a partir de las cuales se derivan los casos de

prueba. La forma de entrada se valora para determinar qu clases de datos
son relevantes para la funcin. Los casos de prueba para cada clase de entrada se derivan y ejecutan mientras otras clases de entrada se mantienen constantes. Por ejemplo, una aplicacin de comercio electrnico puede
implementar una funcin que calcule los cargos de embarque. Entre la diver-
624
PARTE TRES
APLICACIN DE LA INGENIERIA WEB
sidad de informacin de embarque proporcionada mediante un formulario,

est el cdigo postal del usuario. Los casos de prueba se disean con la fina..
dad de descubrir errores en el procesamiento del cdigo postal al especificar
valores de cdigo postal que puedan descubrir diferentes clases de errores
(por ejemplo, un cdigo postal incompleto, un cdigo postal correcto, un coc
go postal inexistente, un formato de cdigo postal errneo).
Anlisis de valores lmite. Los datos de los formularios se prueban en sus lmites. Por ejemplo, la funcin de clculo de embarque sealada anteriormente
solicita el nmero mximo de das requerido para la entrega del producto. E:
el formulario se anotan un mnimo de 2 das y un mximo de 14. Sin embargo, las pruebas de valor de lmite pueden ingresar valores de o, 1, 2, 13, 14 )
15 para determinar cmo reacciona la funcin frente a los datos en y fuera c..
los lmites de las entradas vlidas. 13
Pruebas de ruta. Si la complejidad lgica de la funcin es alta, 14 se puede errplear la prueba de ruta (mtodo caja blanca de diseo de caso de prueba) pa:
garantizar que se ha ejercitado toda ruta independiente en el programa.
Adems de estos mtodos de diseo de casos de prueba, se utiliza una tcnica
mada prueba de error forzado {NGUOll para producir casos de prueba que delibe
damente conducen los componentes de la WebApp hacia una condicin de error
propsito es descubrir los errores que ocurren durante el manejo de los errores .
ejemplo, mensajes de errores incorrectos o inexistentes, falla de la WebApp C..
consecuencia del error, salida errnea producida por entrada errnea, efectos ce
terales relacionados con el procesamiento del componente).
Cada caso de prueba al nivel de componentes especifica todos los valores de .
trada y la salida esperada que proporcionar el componente. La salida real prod..
da como consecuencia de la prueba se registra para referencia futura durante et _
porte y el mantenimiento.
En muchas situaciones la ejecucin correcta de la funcin de una WebApp esta
gada a una interfaz adecuada con una base de datos que puede ser externa a la v_
App. En consecuencia, la prueba de la base de datos se vuelve una parte integral
rgimen de prueba de componentes. Hower [HOW97} examina esto cuando eser
Los sitios Web alimentados con bases de datos pueden involucrar una interaccin compleja entre navegadores Web, sistemas operativos, aplicaciones plug-in, protocolos de co-
13 En este caso, un mejor diseo de entrada puede eliminar errores potenciales. El mximo nmer
das se podra seleccionar de un men desplegable, con lo que se evita que el usuario espedr
una entrada ti.lera de los lmites.
14 La complejidad lgica se puede determinar al calcular la complejidad ciclomtica del algorVase el capitulo 14 para detalles adicionales.
CAPTULO 20
625
municacin, servidores Web, bases de datos, programas [lenguaje de guin] ... , mejoras a
la seguridad y cortafuegos.
Tal complejidad imposibilita probar todas las posibles dependencias y todo lo que podra ir mal con un sitio. El tpico proyecto de desarrollo de un sitio Web tambin estar en
un calendario agresivo, de modo que el mejor enfoque de prueba emplear anlisis de
riesgo para determinar dnde enfocar los esfuerzos de prueba. Los anlisis de riesgo debe incluir consideracin de cunto coincidir el ambiente de prueba con el ambiente de
produccin real... Otras consideraciones tpicas en el anlisis de riesgo incluyen:
Cul funcionalidad en el sitio Web es ms crucial para su propsito?
Cules reas del sitio requieren la ms dura interaccin con la base de datos?
Cules aspectos de los CGI, applets, componentes Activex, etc., del sitio son
los ms complejos?
Qu tipos de problemas causara la mayora de las quejas o la peor publicidad?
Qu reas del sitio sern las ms populares?
Qu aspectos del sitio tienen los mayores riesgos de seguridad?
Cada uno de los asuntos relacionados con el riesgo que examina Hower deben considerarse cuando se diseen casos de prueba para componentes WebApp y funciones de bases de datos relacionadas.
Un usuario viaja a travs de una WebApp en gran medida como lo hace un visitante
al caminar por una tienda o un museo. Existen muchas rutas que se pueden tomar,
muchas paradas que se pueden realizar, muchas cosas que aprender y ver, actividades
por iniciar y decisiones por tomar. Como ya se ha comentado, este proceso de navegacin es predecible en el sentido en que todo visitante tiene un conjunto de objetivos cuando llega. Al mismo tiempo, el proceso de navegacin puede ser impredecible
porque el visitante, influido por algo que ve o aprende, puede elegir una ruta o iniciar
una accin que no es tpica para el objetivo original. El trabajo de probar la navegacin es 1) garantizar que todos los mecanismos que permiten al usuario de la WebApp viajar a travs de ella son funcionales, y 2) validar que cada unidad semntica de
navegacin (USN) pueda ser alcanzada por la categora de usuario adecuada.
1:~- - ~En&emom~ oo retodeubkodn."

20.6.1 Prueba de la sintaxis de navegacin
La primera fase de la prueba de navegacin en realidad comienza durante la prueba
de la interfaz. Los mecanismos de navegacin se prueban para asegurar que cada
626
PARTE TRES
APUCAON DE LA INGEN!EruA WEB
uno realiza la funcin que se busca. Splaine y Jaskiel [SPLO I J sugieren que se de..
probar cada uno de los mecanismos de navegacin siguientes:
Vnculos de navegacin. Se deben probar los vnculos internos dentro de la

WebApp, los vnculos externos hacia otras WebApps y las anclas dentro de
una pgina Web especfica para garantizar que se alcanzarn el contenido o
la funcionalidad adecuados cuando el vnculo se elija.
Redirigir. Dichos vnculos entran en juego cuando un usuario solicita una UR:..
inexistente o selecciona un vinculo cuyo destino se ha removido o cuyo nol!"
bre ha cambiado. Se despliega un mensaje al usuario y la navegacin se red.
rige hacia otra pgina (por ejemplo, la pgina de inicio). La redireccin se
debe probar al solicitar vnculos internos incorrectos o URL externas y valora.
cmo maneja la WebApp dichas solicitudes.
Bookmarks. Aunque los bookmarks son funcin del navegador, se debe probar la WebApp para asegurar que se puede extraer un ttulo de pgina signif
cativo cuando se cree el bookmark.
Marcos y conjuntos de marcos. Cada marco contiene el contenido de una pg:na Web especfica; un conjunto de marcos contiene mltiples marcos y perr.
te el despliegue de mltiples pginas Web al mismo tiempo. Puesto que es
posible anidar marcos y conjuntos de marcos uno dentro de otro, se deben
probar dichos mecanismos de navegacin y despliegue para un contenido arrecto, plantilla y tamao adecuados, desempeo de descarga y compatibilidad de navegador.
Mapas de sitio. Las entradas se deben probar para garantizar que el vnculo
lleva al usuario hacia el contenido o la funcionalidad adecuados.
Motores de bsqueda internos. Las WebApps complejas usualmente contienecientos o incluso miles de objetos de contenido. Un motor de bsqueda interno permite al usuario realizar una bsqueda por palabra clave dentro de la
WebApp para encontrar el contenido necesario. La prueba del motor de bsqueda valida la precisin y qu tan completa es la bsqueda, las propiedades
de manejo de errores del motor de bsqueda y las caractersticas de bsque'avanzada (por ejemplo, el uso de operadores booleanos en el campo de bsqueda).
Algunas de estas pruebas pueden desarrollarse mediante herramientas automatizz
das (por ejemplo, verificador de vnculos), mientras que otras se disean y ejecuta:
de manera manual. La finalidad de todo esto es asegurar que los errores en las me
cnicas de navegacin se encuentren antes de que la WebApp est en lnea.
20.6.2 Prueba de la semntica de navegacin

En el captulo 19 se defini una unidad semntica de navegacin (USN) como "u::"
conjunto de estructuras de informacin y navegacin relacionadas que colaboran e--
CAPTULO 20
627
el cumplimiento de un subconjunto de requisitos de usuario relacionados" [CAC02].

Cada USN se define mediante un conjunto de rutas de navegacin (llamadas "formas
de navegar") que conectan nodos de navegacin (por ejemplo, pginas Web, objetos de
contenido o funcionalidad). Tomada como un todo, cada USN permite al usuario lograr requisitos especficos definidos por medio de uno o ms casos de uso para una
categora de usuario. La prueba de navegacin ejercita cada USN para asegurar que
dichos requisitos son asequibles.
Conforme se prueba cada USN, el equipo de ingeniera Web debe responder las siguientes preguntas:
La USN se logra en su totalidad sin error?
Todo nodo de navegacin (definido para una USN) es asequible dentro del
contexto de las rutas de navegacin que define la USN?
Si la USN puede alcanzarse empleando ms de una ruta de navegacin, se
ha probado cada ruta relevante?
Si la interfaz del usuario proporciona una gua para ayudar en la navegacin,
las direcciones son correctas y comprensibles conforme se realiza la navegacin?
Existe un mecanismo (distinto a la flecha "retroceso" del navegador) para regresar al nodo de navegacin precedente y hacia el comienzo de la ruta de
navegacin?
Los mecanismos de navegacin dentro de un gran nodo de navegacin (es
decir, una gran pgina Web) funcionan adecuadamente?
Si una funcin se ha de ejecutar en un nodo y el usuario elige no proporcionar
entrada, se puede completar el resto de la USN?
Si una funcin se ejecuta en un nodo y ocurre un error en el procesamiento
de la funcin, se puede completar la USN?
Existe una forma para descontinuar la navegacin antes de que se hayan alcanzado todos los nodos, pero entonces regresar a donde se descontinu la
navegacin y proceder desde ah?
Todo nodo se alcanza desde el mapa de sitio? Los nombres de los nodos
son significativos para los usuarios finales?
Si un nodo dentro de una USN se alcanza desde alguna fuente externa, es
posible proceder hacia el siguiente nodo en la ruta de navegacin? Es posible
regresar al nodo previo en la ruta de navegacin?
El usuario entiende su ubicacin dentro de la arquitectura de contenido conforme se ejecuta la USN?
La prueba de navegacin, como las pruebas de la interfaz y facilidad de uso, se
debe dirigir en tantos participantes diferentes como sea posible. Las primeras etapas
628
PARTE TRES
de las pruebas las dirigen los ingenieros Web, pero etapas ulteriores las deben dgir otros participantes del proyecto, un equipo de prueba independiente y, a finaJ. cuentas, usuarios sin calificacin tcnica. La finalidad es ejercitar ampliamente
navegacin de la WebApp.
La variabilidad y la inestabilidad de la configuracin son factores importantes q:

hacen de la ingeniera Web un desafio. Hardware, sistemas operativos, navegadore.
capacidad de almacenamiento, rapidez de comunicacin de la red y una diversid.:
de otros factores del lado del cliente son dificiles de predecir para cada usuario. A.
ms, la configuracin para un usuario dado puede cambiar (por ejemplo, actualz;
dones de sistema operativo, nuevo ISP y rapidez de conexin) con regularidad. El R.
sultado puede ser. en el lado del cliente, un ambiente proclive a errores, tanto Sl..
les como significativos. La impresin que un usuario tenga de la WebApp y la fol't:'
en la que interacta con ella puede diferir significativamente de la experiencia
otro usuario, si ambos no trabajan dentro de la misma configuracin del lado c.:
cliente.
La labor de probar la configuracin no es ejercitar toda posible configuracin _
lado del cliente. Ms bien, es probar un conjunto de probables configuraciones de k
lados del cliente y del servidor para garantizar que la experiencia del usuario ser
misma en todos ellos y para aislar errores que puedan ser especficos de una co~
guracin particular.
20.7 .1 Conflictos en el lado del servidor

En el lado del servidor, los casos de prueba de configuracin se disean para velt'
car que la configuracin de servidor proyectada (es decir: servidor WebApp, servid
de base de datos, sistemas operativos, software cortafuegos, aplicaciones cona;
Qu pre
guntas se
deben plantear y
responder confor
'me se lleva a
cabo la prueba de
coeflguradn en
el lodo del servl
w?
rrentes) pueden soportar la WebApp sin error. En esencia, la WebApp se instala der
tro del ambiente del lado del servidor y se prueba con la intencin de encontrar erre
res relacionados con la configuracin.
Conforme se disean la pruebas de configuracin del lado del servidor, el inge
niero Web debe considerar cada componente de la configuracin del servidor. Entre
las preguntas que es preciso plantear y responder durante la prueba de configuracin del lado del servidor se encuentran:
La WebApp es totalmente compatible con el sistema operativo del servidor?
Los archivos de sistema, directorios y datos de sistema relacionados se crear
correctamente cuando la WebApp es operativa?
Las medidas de seguridad del sistema (por ejemplo, cortafuegos o encriptado) permiten a la WebApp ejecutarse y dar servicio a los usuarios sin interferencia o menoscabo del desempeo?
CAPITULO 20
CMO PROBAR APUCACIONIS WEB
629
La WebApp se ha probado con la configuracin de servidor distribuido 15 (si

existe uno) que se haya elegido?
La WebApp est adecuadamente integrada con software de base de datos?
La WebApp es sensible a diferentes versiones del software de base de datos?
Los guiones de la WebApp en el lado del servidor se ejecutan adecuadamente?
Los errores del administrador del sistema se han examinado para ver su
efecto sobre las operaciones de la WebApp'
Si se usan servidores proxy, las diferencias en sus configuraciones se han
abordado con pruebas en el sitio?
20.7.2 Conflictos en el lado del cliente

En el lado del cliente las pruebas de configuracin se centran principalmente en la
compatibilidad de la WebApp con las configuraciones que contienen una o ms permutaciones de los siguientes componentes [NGUOl] :
Hardware. CPU, memoria, almacenamiento y dispositivos de impresin.

Sistemas operativos. Linux, Macintosh, Microsoft Windows, un sistema operativo con base mvil.
Software de navegacin. Internet Explorer, Mozilla/Netscape, Opera, Safari y

otros.
Componentes de la interfaz del usuario. Activex, applets Java y otros.

Plug-ins. QuickTime, RealPlayer y muchos otros.
Conectividad. Cable, DSL, mdem regular, TI.
Adems de estos componentes, otras variables incluyen el software de red, las variaciones del ISP y aplicaciones que corren al mismo tiempo.
Al disear pruebas de configuracin en el lado del cliente el equipo de ingenieria
Web debe reducir el nmero de variables de configuracin hacia un nmero manejable. 16 Por tanto, se valora cada categora de usuario para determinar las probables
configuraciones que se encontrarn dentro de la categora. Adems, se pueden utilizar los datos compartidos en el mercado industrial para predecir las combinaciones ms probables de componentes. Entonces la WebApp se prueba dentro de estos
ambientes.
15 Por ejemplo, se puede usar un servidor de aplicacin y uno de base de datos por separado. La comunicacin entre las dos mquinas ocurre por medio de una conexin de red.
16 Ejecutar pruebas en toda posible combinacin de componentes de configuracin consume demasiado tiempo.
630
PARTE TRES
La seguridad de las WebApps es una materia compleja que debe entenderse

completo antes de que se pueda lograr una prueba de seguridad efectiva. 17 Las
Apps y los ambientes en el lado del cliente y en el lado del servidor en los que ~
hospedadas representan un blanco atractivo para hackers, empleados descante'"
competidores deshonestos y cualquiera otro que desee robar informacin se
modificar contenido maliciosamente, disminuir el desempeo, deshabilitar la fu;nalidad o poner en apuros a una persona, organizacin o negocio.
Las pruebas de seguridad estn diseadas para probar las vulnerabilidades e-:ambiente del lado del cliente, las comunicaciones de red que ocurren mientras
datos pasan del cliente al servidor y de vuelta, y el ambiente del lado del sen'".:.
Cada uno de estos dominios puede recibir ataques, y es labor de quien prueba la
guridad descubrir las debilidades que pueden explotar quienes tengan la intenc
de hacerlo.
En el lado del cliente, las vulnerabilidades con frecuencia se pueden rastrear r
ta errores preexistentes en los navegadores, programas de correo electrnico o se
ware de comunicacin. Nguyen [NGUOlJ describe un hoyo de seguridad tpico:
Si la WebApp es w
cial en el negacia,
canservo datos sensi
bles oes un probable
blanco de hockers, es
bueno ideo subcontro111, los pruebas de seguridad con uno
empreso especializado
en esm lobor.
Uno de los errores mencionados comnmente es el desbordamiento del buffer. Esto permite que un cdigo malicioso se ejecute en la mquina cliente. Por ejemplo, al ingresa
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 navegador no tiene cdigo de deteccin de error para validar la longitud de la URL ingresada. 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.
Otra vulnerabilidad potencial en el lado del cliente es el acceso no autorizado

cookies colocadas dentro del navegador. Los sitios Web creados con intenciol'lQ
maliciosas pueden adquirir informacin contenida dentro de cookies legitimas y us:;.;
esta informacin en formas que ponen en juego la privacidad del usuario, o peor, es
tablecen el escenario para el robo de identidad.
Los datos comunicados entre el cliente y el servidor son vulnerables a la simula
cin (spoojing). sta ocurre cuando un extremo de la ruta de comunicacin lo su!;
17 Los libros de Trivedi [TRE03], McClure y sus colegas [MCC03) y Garfinkel y Spafford [GAR02) ofre
cen informacin til acerca del tema.
631
vierte una entidad con intenciones maliciosas. Por ejemplo, a un usuario puede engaarlo un sitio Web malicioso que acta como si fuese el legtimo servidor de la WebApp (idnticos en apariencia y percepcin). La intencin es robar contraseas, informacin de propiedad o datos de crdito.
En el lado del servidor, las vulnerabilidades incluyen ataques de negacin de servicio y guiones maliciosos que pueden pasar al lado del cliente o empleados para
deshabilitar las operaciones del servidor. Adems, se puede tener acceso, sin autorizacin, a bases de datos en el lado del servidor (robo de datos).
La proteccin contra stas (Y muchas otras) vulnerabilidades requiere implementar uno o ms de los siguientes elementos de seguridad [NGUOI]:
Cortafuegos: mecanismo de filtrado -combinacin de hardware y softwareque examina cada paquete de informacin entrante para garantizar que llega
de una fuente legitima y bloquea cualquier dato sospechoso.
Autentificacin: mecanismo de verificacin que valida la identidad de todos
los clientes y servidores, y permite que la comunicacin ocurra slo cuando
ambos lados son verificados.
Encriptado: mecanismo de codificacin que protege los datos sensibles mediante su modificacin en una forma que imposibilita la lectura de quienes
tengan intenciones maliciosas. El encriptado se fortalece empleando certificados digitales que permiten al cliente verificar el destino al cual se transmiten
los datos.
Autorizacin: mecanismo de filtrado que permite el acceso al ambiente del
cliente o el servidor slo a aquellos individuos con cdigos de autorizacin
apropiados (por ejemplo, identificacin del usuario y contrasea).
La finalidad de las pruebas de seguridad es exponer los hoyos en dichos elementos de seguridad que podran explotar quienes tengan intenciones maliciosas. El diseo actual de las pruebas de seguridad requiere un conocimiento profundo de los
trabajos internos de cada elemento de seguridad, as como una extensa comprensin de un amplio rango de tecnologas de red. En muchos casos, las pruebas de seguridad se subcontratan con firmas que se especializan en dichas tecnologas.
Nada es ms frustrante que una WebApp que tarda minutos en cargar contenido
cuando los sitios de la competencia descargan contenido similar en segundos. Nada
es ms agraviante que el intento de entrar en una WebApp y recibir un mensaje de
"servidor ocupado", que se acompaa con la sugerencia de intentarlo ms tarde. Nada es ms desconcertante que una WebApp que responde instantneamente en algunas situaciones, y luego, en otras ocasiones parece irse a un estado de espera infinita. Todos estos hechos suceden en la '11.'eb todos los das, y todos estn relacionados con el desempeo.
632
PARTE TRES
Las pruebas del desempeo se aplican para descubrir problemas de desempeo

que se presentan debido a falta de recursos en el lado del servidor, ancho de banda
de red inapropiado, capacidades inadecuadas de base de datos, defectuosas o dbi
les capacidades del sistema operativo, funcionalidad WebApp mal diseada y otros
conflictos de hardware o software que pueden conducir a un pobre desempeo
cliente-servidor. La finalidad es doble: 1) comprender cmo responde el sistema a la
carga (es decir, nmero de usuarios, nmero de transacciones o volumen de datos
global), y 2) recolectar mtricas que conducirn a modificaciones de diseo para mejorar el desempeo.
20.9 .1 Objetivos de las pruebas del desempeo

Las pruebas del desempeo se disean con el fin de simular situaciones de carga de
mundo real. Conforme crece el nmero de usuarios simultneos de la WebApp, o au
menta el nmero de transacciones en lnea, o se incrementa la cantidad de datos
(descargados o cargados), las pruebas de desempeo ayudarn a responder las s
guientes preguntas:
El tiempo de respuesta del servidor se reduce hasta un punto donde es apreciable e inaceptable?
Algunos aspectos del

tksetnpsoo tk i1 WebApp, o/ menos como
los perciben los usuarios finales, son ciffo.
les de probar, incluso

lo co,go de red, los
voriociones del hollf
ware que estublece
uno intedoz coo lo red
y tpicos simRores.
En qu punto (en trminos de usuarios, transacciones o carga de datos) el

desempeo se vuelve inaceptable?
Qu componentes del sistema son responsables de la reduccin del desempeo?
Cul es el tiempo de respuesta promedio para los usuarios en una variedad
de condiciones de carga?
La reduccin del desempeo tiene impacto sobre la seguridad del sistema?
La confiabilidad o la precisin de la WebApp se afectan conforme crece la
carga del sistema?
Qu ocurre cuando se aplican cargas que rebasan la capacidad mxima del
servidor?
Para desarrollar respuestas a estas preguntas, se dirigen dos pruebas de deserr
peo diferentes:
Prueba de carga: la carga en el mundo real se prueba en una diversidad de niveles de carga y en una variedad de combinaciones.
Prueba de tensin: la carga se aumenta hasta el punto de ruptura para determinar cunta capacidad puede manejar el ambiente de la WebApp.
cada una de estas estrategias de prueba se considera en las secciones siguientes
CAPITULO 20 CMO PROBAR APUCAOONES wm
633
20.9.2 Pruebas de carga

El objetivo de las pruebas de carga es determinar cmo la WebApp y su ambiente del
lado del servidor respondern a varias condiciones de carga. Conforme proceden las
pruebas, las permutaciones a las siguientes variables definen un conjunto de condiciones de prueba:
N, el nmero de usuarios concurrentes
T, el nmero de transacciones en lnea por usuario por unidad de tiempo
D, la carga de datos procesada por el servidor por transaccin
En cada caso, estas variables se definen dentro de los lmites operativos normales del sistema. conforme se corre cada condicin de prueba, se recopilan una o ms
de las siguientes medidas: la respuesta de usuario promedio, el tiempo promedio para descargar una unidad de datos estandarizada o el tiempo promedio para procesar
una transaccin. El equipo de ingeniera Web examina estas medidas para determinar si una disminucin precipitada en el desempeo se puede rastrear hasta una
combinacin especfica de N, T y D.
La prueba de carga tambin se aplica para valorar la velocidad de conexin recomendada para los usuarios de la WebApp. La cantidad de informacin global procesada en una unidad de tiempo, P, se calcula de la forma siguiente:
P = NXTXD
como ejemplo, considrese un popular sitio de noticias deportivas. En un momento dado, 20 000 usuarios concurrentes realizan una solicitud (una transaccin, T) una
vez cada dos minutos en promedio. Cada transaccin requiere que la WebApp descargue un nuevo artculo que promedia 3 Kbytes de longitud. En consecuencia, la
cantidad de informacin procesada en una unidad de tiempo se puede calcular como:
P (20 000 x 0.5 x 3 Kb]/60 = 500 Kbytes/seg

= 4 megabits por segundo
Por lo tanto, la conexin de red para el servidor tendrfa que soportar esta tasa de
datos y se debera probar para garantizar que la tiene.
20.9.3 Pruebas de tensin

La prueba de tensin (captulo 13) es una continuacin de la prueba de carga, pero
en esta instancia las variables N, T y D se fuerzan para alcanzar y luego superar los
limites operativos. La finalidad de estas pruebas es responder cada una de las pre-
guntas siguientes:
El sistema se degrada "gentilmente" o el servidor se desconecta cuando se
rebasa su capacidad?
El software del servidor genera mensajes de "servidor no disponible"? De
manera ms general: a los usuarios se les advierte que no pueden alcanzar
el servidor?
634
PARTE TRES
APLICAON DE LA INGENIERA WEB
El servidor pone en cola las solicitudes de recursos y vaca la cola una vez
que la capacidad demanda disminucin?
Las transacciones se pierden conforme se rebasa la capacidad?
La integridad de los datos se afecta cuando se rebasa la capacidad?
Qu valores de N, T y D fuerzan el fallo del ambiente del servidor? Cmo s.
manifiesta la falla en si misma? Las notificaciones automticas se envan a:
equipo de soporte tcnico en el sitio del servidor?
Si el sistema falla, cunto tardar en estar en lnea de nuevo?
Ciertas funciones de la WebApp (por ejemplo, calcular funcionalidad intens
capacidades de flujo de datos) se descontinan cuando la capacidad alcanz.::
el nivel de 80 o 90 por ciento?
A una variacin de la prueba de tensin a veces se Je refiere como prueba p
rebote [SPLO I J. En este rgimen de pruebas la carga se lleva hasta su punto mx1 re:;
de capacidad, luego se baja rpidamente hasta condiciones de operacin norma ce!
y Juego se sube de nuevo al pico. Al rebotar la carga del sistema un examinador puede determinar cun bien el servidor puede poner en orden los recursos para satis.fa..
cer la demanda muy elevada y luego liberarlos cuando reaparecen las condiciones
normales (de modo que estn listas para el siguiente pico) .
Taxonoma de herramientas para pruebas de WebApp

En su artculo ocerco de lo pruebo de los siste
mos de comercio electrnico, lam [LAMOI J
presenta una til taxonoma de las herramientas automati
zados que tienen aplicabilidad directa en la realizacin
de pruebas en un contexto de ingeniera Web. En cado
categora se indican herramientas representativas. 18
Las herramientas de configuracin y de gestin
del contenido gestionan la versin y cambian el control
de los objetos de conteniclo y de los componentes fundo
nales de la WebApp.
Herramienlo(s) representotiva{s):
En www.daveeoton.com/scm/CMTools.html se encuen
Ira una extensa listo.
Las herramientas de desempeo de bases de
datos miden, por ejemplo, el tiempo para realizar con
sultos a bases de datos seleccionadas. Estos herramientas
Focilitan el mejoramiento de la base de datos.
Herromiento{s) representotivas(s): BMC Software
(www.bmc.com)
Los programas depuradores (debuggers) son herramientas
de programaci6n comunes que encuentran y resuelven ~
fectos de software en el cdigo. Forman porte de la mayora de los ambientes modernos de desarrollo de aplicociones.
Herramiento(s) representotiva(s):
Accelerated Tedmology (www.occeleratedtechnology.corlBM Visvo/Age Environment (www.ibm.com)
JDebug Too/ (www.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 esporcido y las tasas de resolu
ci6n de defectos.
Herromienlo(s) representotiva(s):
EXCEL Quickbugs (www.excelsoftware.com)
18 Las herramientas expuestas aqu slo representan una muestra de esta categoria. Adems, los norrbres de las mismas son marcas registradas de las compaflas mencionadas.
CAPTULO 20
CMO PROBAR APUCAClONES WEB
TRUETrack (www.mccobe.com)
"'IOI ClearOuest (www.rotionol.com)
ii.Tamientas de supervisin de red vigilan el
.:11! lrfico de lo red. Son ti les poro identificar los
de botella" de lo red y probar los vnculos entre
de entrado y de solido.
- iento(s) representafiva(s}:
......... sloc. stonford.edu/ xorg/nmtf/ nmtf-tools.html se
Ira uno extenso listo.
MrTamientas de pruebas de regresin oleosos y dotas de pruebo y se pueden volver o

paro cosos de pruebo despus de cambios de soft
miento(s) represenfotiva(s):
ore QARun (www.compuwore.
P<oducts/qocenter/ qorun)
cnol Visua/Test (www.rotionol.com)
Software (www.seque.com)
lilllnomientas de supervisin de sitio vigilan

ais-,pe;-o de un sitio, usualmente desde uno perspecti
c.suorio. sense poro compilar estadsticos como el
ele respuesto de extremo o extremo y lo cantidad
cin procesado en uno unidad de tiempo, as
poro verificar peridicamente lo disponibilidad de
ienta(s) representativa(s):
Systems (www.keynote.com)
herramientas de tensin ayudan o los desorro

o explorar el comportamiento del sistema en con
de niveles elevados de uso operativo y o encon
a puntos de quiebre de un sistema.
mienta(s) represenfotiva(s):
ry lnteroctive (www.mercint.com)
Technologis (www.scopotech.com)
635
res y del software de servidores Web; vigilan los recursos lo

les como el espacio de disco, el uso del CPU y lo memoria.
Herramienta(s) representativa(s):
Successful Hosting.com (www.successfulhosting.com)
Quest Software Foglight (www.quest.com)
Las herramientas de generacin de datos de

pruebo auxilian a los usuarios en dicho toreo.
Herramienta(s} representativa(s):
En www.softworeqatest.com/qotweb 1.html se encuentro
una extensa lista.
Los comparadores de resultados de pruebas
ayudan o 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.
Herramienta(s} representativo(s}:
En www.aptest.com/resources.html se encuentra uno lis
ta til.
Los monitores de transaccin miden el desempeo

de los sistemas de procesamiento de transacciones de alto
volumen.
Herramienta(s) representativa(s}:
QuotiumPro (www.quotium.com)
Software Research eVolid (www.soft.com/eValid/in
dex.html)
Los herramientas de seguridad de sitios W eb

ayudan o detector potenciales problemas de seguridad.
Con frecuencia pueden configurar herramientas de pruebo
y supervisin de la seguridad poro que corran sobre una
base colendarizoda.
Herramienla(s) representativa{s}:
En www.timberlinetechnologies.com/products/www.html
se encuentro una extenso listo.
sistemas de supervisin de recursos son poro mayora de los sistemas operativos de los servido
La meta de probar las WebApp es ejercitar cada una de las muchas dimensiones de
la calidad WebApp con la finalidad de encontrar errores o descubrir conflictos que
pudieran conducir a fallas en la calidad. Las pruebas se centran en contenido, funcin, estructura, facilidad de uso, navegabilidad desempeo, compatibilidad, interoperabilidad, capacidad y seguridad. Las pruebas tambin incorporan revisiones que
ocurren conforme se disea la WebApp.
La estrategia de prueba de la WebApp ejercita cada una de las dimensiones de calidad al examinar inicialmente "unidades de contenido funcionalidad o navegacin.
una vez que las unidades individuales han sido validadas, el enfoque se cambia a
636
PARTE TRES
APLICACIN DE LA INGENIERiA WEB
pruebas que ejerciten la WebApp como un todo. Esto se logra derivando muchas pruebas de las perspectivas de los usuarios y se alimentan con la informacin contenid;
en los casos de uso. Se desarrolla un plan de prueba de ingeniera Web y se identiti
can los pasos de prueba, los productos de trabajo (por ejemplo, casos de prueba)
los mecanismos para la evaluacin de los resultados de prueba. El proceso de prueba abarca siete tipos diferentes de pruebas.
La prueba del contenido (Y las revisiones) se centra en varias categoras de contenido. La finalidad es descubrir errores tanto semnticos como sintcticos que afee
ten la precisin del contenido o la forma en la que se presenta al usuario final. l..i.
prueba de la interfaz ejercita los mecanismos de interaccin que permiten que u;usuario se comunique con la WebApp y valida los aspectos estticos de la interfa.:
El objetivo es descubrir errores que resulten de mecanismos de interaccin mal iir
plementados, u omisiones, inconsistencias o ambigedades en la semntica de la t.terfaz.
La prueba de navegacin aplica casos de uso, derivados como parte de la act' dad de anlisis, en el diseo de casos de prueba que ejercitan cada uno de los esetnarios de uso frente al diseo de navegacin. Los mecanismos de navegacin s,,
prueban para garantizar que se identifican y corrigen los errores que impiden e
completar un caso de uso. La prueba de componentes ejercita las unidades de ccr
tenido y funcionales dentro de la WebApp. cada pgina Web encapsula contenict=
vnculos de navegacin y elementos de procesamiento que forman una "unida.:
dentro de la arquitectura de la WebApp. Se deben probar dichas unidades.
La prueba de configuracin intenta descubrir los errores o los problemas de compatibilidad especificas de un ambiente particular de cliente o servidor. Entonces se
llevan a cabo pruebas para descubrir los errores asociados con cada posible con,.
guracin. La prueba de la seguridad incorpora una serie de pruebas diseadas para
explotar las vulnerabilidades en la WebApp y en su ambiente. La finalidad es encontrar hoyos de seguridad. La prueba de desempeo abarca una serie de pruebas <rse disean para valorar el tiempo de respuesta de la WebApp y la confiablidad coc
forme aumenta la demanda en la capacidad de recursos en el lado del servidor.
[BROOI] Brown, B., Oracle9i Web Development, McGraw-Hill, 2a. ed., 2001.
(CAC02J cachero, C. et al., "Conceptual Navigation Analysis: A Device and Platforrn lnd
pendent Navigation Specification", Proc. 2nd lntl. Workshop on web-oriented technolq,_
junio de 2002, se puede descargar de www.dsic.upv.es/-west/iwwost02/papers
cachero.pdf
[CON03J Constantine, L. y L. Lockwood, Software/ar Use, Addison-Wesley, 1999; vea.se
tambin http://www.foruse.com/.
[GAR02] Garfinkel, S. y G. Spafford, Web 5ecurity, Privacy and Commerce, O'Reilly & Ass.
dates, 2002 .
(HOW97] Hower, Rick, "Beyond Broken Unks", Internet Systems, 1997, disponible e
hltp://www.dbmsmag.com/9707i03.html.
[l.AMOIJ Lam, W., "Testing E-Commerce Systems: A Praclical Guide", en IEEE 1T Pro, ma:
zo-abril de 2001, pp. 19-28.
CAPTULO 20
CMO PROBAR AP'.JCACJONES WEl!
637
[MCC03l McClure, S., s. Shah y S. Shah, Web Hacking: Attacks and Defense, Addison-Wesley, 2003.
[MILOO] Miller, E., "WebSite Testmg", 2000, disponible en http:I /www.soft.com/eValid/
Technology/White.Papers/website.testing.html.
[NGUOO] Nguyen. H., "Testing Web-Based Applications", en Software Testing and QualifY
Engineering, mayo-junio de 2000, disponible en http:/ /www.stqemagazine.com.
[NGUOll Nguyen, H., Testing Applications on the Web, Wiley, 2001.
[SCE02] sceppa, D., Microsoft ADO.NET, Microsoft Press, 2002.
[SPLOl] Splaine, S. y S. Jaskiel, The Web Testing Handbook, STQE Publishing, 2001.
[TRE03] Trivedt R.. Professional Web services SecurifY, Wrox Press, 2003.
[WAL03] Wallace, D., l. Raggett y J. Aufgang, Extreme ProgrammingJor Web Projects, Addison-Wesley, 2003.
20. l. Existen algunas situaciones en las cuales las pruebas de la WebApp deban ignorarse por
completo?
20.2 . Con argumentos propios, comntense los objetivos de la realizacin de pruebas en el
contexto de la ingeniera Web.
20.3. La compatibilidad es una importante dimensin de calidad. Qu debe ponerse a prueba
para garantizar que existe compatibilidad para una WebApp 7

20.4 . Qu errores tienden a ser ms serios: tos errores del lado del cliente o los errores del lado del servidor? Por qu?
20.S. Qu elementos de la WebApp pueden "probarse de manera unitaria"? Qu tipos de
pruebas se deben llevar a cabo slo despus de que estn integrados los elementos de la WebApp?
20.6 . Siempre es necesario desarrollar un plan de prueba escrito de manera formal? Explque-
se la respuesta.
20. 7. Es justo decir que la estrategia global de pruebas de la WebApp comienza con los ele-
mentos visibles para el usuario y se mueve hacia los elementos de tecnologfa? Existen excepciones a esta estrategia?
20.8. La prueba del contenido realmente es una prueba en el sentido convencional del trmi-
no? Explicar la respuesta.

20.9 . Describir los pasos asociados con la prueba de las bases de datos para una WebApp. La
prueba de las bases de datos es una actividad predominantemente del lado del cliente o del lado del servidor?
20.10. Cul es la diferencia entre las pruebas que estn asociadas con los mecanismos de la
interfaz y las pruebas que abordan la semntica de la interfaz?

20.11 . Suponer que se est en el desarrollo de una farmacia en lnea (FannaciadelaEsquina.com)
que intenta satisfacer los deseos de pacientes geritricos. La farmacia proporciona las funciones usuales, pero tambin mantiene una base de datos para cada cliente de modo que puede
ofrecer informacin de medicamentos y advertencias de potenciales interacciones respecto de
medicamentos. Comentar algunas pruebas especiales de facilidad de uso para esta WebApp.
20. 12. Suponer que se ha implementado una funcin de verificacin de interaccin de medi-
camentos para FarrnaciadelaEsquina.com (problema 20. 11 ). Examine los tipos pruebas al nivel
de componente que tendrian que llevarse a cabo para garantizar que esta funcin trabaja de
manera adecuada. [Nota: se tendra que usar Wla base de datos para implementar esta funcin.)
638
PARTE TRES APLICACIN DE LA INGENIERIA WEB

20.13. Cul es la diferencia entre probar la sintaxis de navegacin y probar la semntica
navegacin?
c.c:
20.14. Es posible probar cada configuracin que probablemente encuentre la WebApp en

lado del servidor? En el lado del cliente? Si no, cmo un ingeniero Web selecciona un conju:to significativo de pruebas de configuracin?
20.15. Cul es el objetivo de las pruebas de seguridad? Quin lleva a cabo esta actividad .:.e
prueba?
20.16. FarmaciadelaEsquina.com (problema 20.11) se ha vuelto exitosa y el nmero de ~
rios ha aumentado de manera significativa en los primeros dos meses de operacin. Dibuje ir
grfica que muestre el tiempo de respuesta probable como funcin del nmero de usuarios p
ra un conjunto fijo de recursos en el lado del servidor. Rotule la grfica para indicar puntos ..
inters en la "curva de respuesta".
20.17. En respuesta a su xito, FarmaciadelaEquina.com (problema 20.11) ha implementa
un servicio especial exclusivamente para manejar el resurtido de recetas. En promedio, 1 ~
usuarios concurrentes giran una solicitud de resurtido una vez cada dos minutos. La Webi\;:
descarga un bloque de datos de 500 bytes como respuesta. Cul es la cantidad de informac
aproximada que se necesita procesar por una unidad de tiempo para este servidor, en megabpor segundo?
20.18. Cul es la diferencia entre prueba de carga y prueba de tensin?
La literatura para las pruebas de WebApps todava est en evolucin. Los libros de Ash (The
Testing Companion, Wiley, 2003), Dustin y sus colegas (Quality Web Systems, Addison-Wesi.:
2002), Nguyen INGUOIJ y Splaine y Jaskiel [SPLOIJ se encuentran entre los que, publicados~
ta la fecha, presentan los tratamientos ms completos del tema. Mosley (Client-Server Sojh
Testing on the Desktop and the Web, Prentice-Hall, 1999) aborda asuntos de prueba tanto~
lado del cliente como en el lado del servidor.
Stottlemeyer (Automated Web Testing Too/kit, Wiley, 2001) presenta informacin til acerca
los mtodos y estrategias en la prueba de las WebApps, asi como un valioso anlisis de las
rramientas de prueba automatizadas. Graham y sus colegas (Software Test Automation, AddJs,;;.oc
Wesley, 1999) presentan material adicional acerca de las herramientas automatizadas.
Nguyen y sus colegas (Testing Applications Jor the Web, segunda edicin, Wiley, 2003) de-rrollaron una gran actualizacin [NGUOIJ y ofrecen una gua nica para probar aplicacicr~
mviles. Aunque Microsoft (Peiforrnance Testing Microsoft .NET Web Applications, Mi~
Press, 2002) se enfoca predominantemente en su ambiente .NET, sus comentarios acerca de
pruebas de desempeo pueden ser tiles para cualquier interesado en la materia.
Splaine (Testing Web security, Wiley, 2002), Klevnsky y sus colegas (Hack l.T. : Sea:Through Penetration Testing, Addison-Wesley, 2002), Chirillo (Hack Attacks Revealed, seguedicin, Wiley, 2003) y Skoudis (Counter Hack, Prentice-Hall, 2001) ofrecen mucha informac.
til para quienes deben disear pruebas de seguridad.
En Internet est disponible una gran variedad de fuentes de informacin acerca de las pr..
bas para ingeniera Web. En el sitio Web de SEPA se encuentra una lista actualizada de referc"
cias en la World Wide Web:
GESTIN DE PROYECTOS
n esta parte de Ingeniera del sojtWafe: .un enfoque prctico se

consideran las tcnicas de gestin necesarias para planear,
~rganizar, supervisar y controlar los proyectos de software.
En los ~aptulos que siguen se abordan las siguientes- preguntas:
Cmo se deben gestionar el personal, el proceso y 1os problemas durante un proyecto de p0ftware?
Cmo pueden emplearse l~sJntricas de software para gestionar ;un proyecto de software yel respectivo proceso?
:,,.
Cmo se estiman el esfuerzo, el costo y la duracin del proyecto?

Qu tcnicas pueden aplicarse para evaluar formalmente los ,
riesgos que p~eden incidir en el xito del proyec;to?
Como selecciona un gestor de proyectos un tcmjuntQ d tareas de trabajo de ingeniera del software?
Cmo se crea el programa cronolgico de un prdyecto?
Qu es Ja gestin de calidad?
.Pot qu son tan importantes las revisiones tcnicas forma~
les?
, Cmo se gestionan los cambios durante el desarrollo del
software de computadora y despus de entregarlo al cliente?
Una v~z que se respondan estas preguntas se estar mejor pre..

parado par(J gestionar proyectos de so rare en una forma que
c:onaucir a l: entrega puntual de un prod cto de alta calidad.
CAPTULO
21
CONCEPTOS
C-t,AV:B
jimbllodel
oflware ,651
coordln.11cill 6SO
des<omposld11
del problema 6S2
eqtiipo,do
software 645
equipo,
a,1es . .649
lideres de
equp~ .644
portklpo11tes 644
personal , .643
prctkas
uticas 658
principio
W5HH .......657
PfO<eso 653
proyecto . , .686
CONCEPTOS DE
GESTIN DE PROYECTOS
q.
n el prefacio de su libro acerca de la gestin de proyectos de software, M

Ter Page-:Tones CPAGesJ hace una afirmacin a la que pueden sumarse m
cho!} asesores en ingeniera del software:
.,
He visitado dqc:enas de llendas comerciales, tanto buenas como malas, y he observad<> regis\ros de gerente1 <le procesamiento de datos, de nuevo tanto buenos corr
malS_ Con mU:cha fre<;uencii he visto con horror como dichos geren\es luchaban
ntilrhente conl)royectos de pesadilla, sufriendo por fechas limites imposibles o sJStemas eptregados que indignaron a sus usuarios y devoraron enormes cantidades de
tiempo de mantenJmiento..
Lo que Page-)ones describe son sntomas que resultan de una serie de prob
mas de.gestin y tcnicos. Sin embargo, sl se realizara una autopsia de
proyecto, es m4y probable que se encontrara un tema consistente: la gestin
proy~<;to fue dbil.
En este captulo y en los seis sguientes, se.consideran los .conceptos e

que conducen a un~ gestin efectiv.a de pro,yectos de software. Este cap
considera conceptos y principios bsicos de gestin de proyectos de software
captulo 22 presenta mtricas del proceso y del proyecto, la base para una di
tiva toma de decisiones de $estin, En los capfttdos 23 y 24 se analizan las t
nicas con que se estiman, se .define un calendatio realista y se establce un p
efeclivo para el proyecto. Ef\J;~l capitulo 2sse presentan las actividades de ~
tin ,que conducen a una e(ectiva supervisin, reduccin y gestin del riesgo
nalmente, en los capf tulos 26 y 27 se consideran tc;nicas para asegurar la e
dad confome un proyecto se Uewi a cabo y se gestionan los cambios a lo
de la vida de una aplicacin.
Qu es? Aunque muchot (~ $U$
momento$ m$ oscurps) lonlan lo

vls&. de 's,,,Jin" de Oilbett,
,
siend una adividod muy necesono
,
cu:dndo l& i:onst~ ftemos y
ptluct~ bo$0dos en computdoras. lo ges.
tin ci 'proyectos iovofucro la plonificocin,
supervisin X.control del personaJ1 el presQ y
tos evel\tos que ocurren m1enlr'as ei soffware
evoluciono desde uo conc,epto pr~iminor host,;,
uno irnplementad6~ operativo.
Quin lo hace? Tok>t r.gestionort en derta
medida, pero el 6mbito de las activ1dode$ de
gestin vario entre, las personas in,rolocradas

en un.proyecto de software. Un ingeniero de
software gestiono sus actividades drarios, y
pkirnflcct, su~rviso y contro[o los labores tcru
cos. lo$ gs~ de proyedo pfonifioon, super
visan y c<>fllrokm el trabajo de un upo de
,inger,i111ros de software. Los gestores., eje(:.utivos
coordinc:m lo reloejn ~ntre el negodo y los
profesionQles dehoftwore.
Por.qll esimporta"te? La construccin de
software de comptJtadoro ~ vno empre$o complejo, en P9rtiet.1lor snvofucro a mvqha gente
que trobaja dvron'te uf.\ tiemPQ rekitivomente
CAPTULO 21
641
CONCEPTOS DE GESTlN DE PROYECTOS
La gestin eficaz de la gestin de proyectos de software se enfoca sobre las cuatro
P: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que olvida que el trabajo de ingeniera del software es una empresa intensamente humana nunca tendr xito en la gestin de proyectos. un gestor que fracasa en alentar
la comunicacin amplia con los participantes en etapas tempranas de la evolucin
de un proyecto se arriesga a construir una solucin elegante para el problema equivocado. El gestor que presta poca atencin al proceso corre el riesgo de colocar mtodos y herramientas tcnicos competentes en el vaco. El gestor que se embarca sin
un plan de proyecto slido arriesga el xito del producto.
21.1.1
El personal
La formacin de personal de software motivado
y altamente calificado se ha debati-
do desde los aos 60 del siglo pasado (por ejemplo, [COU80], [WIT94], [DEM98l) . De
hecho, el "factor humano" es tan importante que el Software Engineering Institute ha
desarrollado un modelo de madurez de la capacidad de gestin de personal (MMCGP)
para "aumentar la rapidez con la cual las organizaciones de software acometen las
aplicaciones cada vez ms complejas al ayudar a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software" [CUR94].
El modelo de madurez de gestin de personal define las siguientes reas clave
prcticas para el personal de software: reclutamiento seleccin, gestin del desem-
642
PARTE CUATRO GESTIN DE PROYECTOS DE SOFTWARE
peo, entrenamiento, retribucin, desarrollo de la carrera, diseo de la organizadoy el trabajo, y desarrollo de la cultura de equipo. Las organizaciones que logran a
tos niveles de madurez en el rea de gestin de personal tienen una mayor probab lidad de implementar efectivas prcticas de ingeniera del software.
El MMCGP es compaero de la Integracin del Modelo de Madurez de la capao
dad de Software (captulo 2) que gua a las organizaciones en la creacin de un pre
ceso de software maduro. Ms adelante en este capitulo se consideran tpicos asocia
dos con la gestin del personal y la estructura de los proyectos de software.
21 .1.2 El producto
En este contexto, el
trmino producto se
emplea para abarcar
cualquier software
que se cooslruye a
solicitud de otros. No
slo incluye productos
de software estando,~
zodo, sino tambin

sist8mos basados en
computadoras, saft.
ware anidado, WebApps ysoftware de
resalucin de xoblemos (por ejemplo,
programas poro 1es1r
lucin de problemas
de ingenierio y oentf.
ficos).
Antes de planear un proyecto se deberian establecer los objetivos y el mbito dcl

producto, considerar soluciones alternativas e identificar las restricciones tcnicas J
de gestin. Sin esta informacin es imposible definir estimaciones razonables (y pre
cisas) del costo, una valoracin efectiva del riesgo, una divisin realista de las tarea.
del proyecto o un calendario de proyecto manejable que ofrezca una indicacin f12
ble del progreso.
El desarrollador del software y el cliente se deben reunir para definir los objetive-<'
y el mbito del producto. En muchos casos, esta actividad comienza como parte o
la ingenieria del sistema o de la ingeniera del proceso de negocio (captulo 6) y cor
tina como el primer paso en la ingeniera de requisitos de software (captulo 7) LC5
objetivos identifican las metas globales del producto (desde el punto de vista de
cliente) sin considerar cmo se lograrn. El mbito identifica los datos primarios, la..
funciones y los comportamientos que caracterizan al producto y, ms importante, le;
intentos por enlazar tales caractersticas en una forma cuantitativa.
Una vez entendidos los objetivos y el mbito del producto se consideran solucio
nes alternativas. Aunque se trata relativamente poco detalle, las alternativas posib
litan que los gestores y practicantes seleccionen un "mejor" enfoque, cumplan l<L
restricciones que imponen las fechas lmites de entrega, las restricciones presupues
tarias, la disponibilidad del personal, las interfases tcnicas y miles de factores ms
21 .1.3
El proceso
tc0Nsuo9'
Un proceso de software (capitulas 2, 3 y 4) proporciona el marco de trabajo desde e

cual se puede establecer un plan detallado para el desarrollo del software. Un peque-
Ouienes se odhiefen o
o nmero de actividades del marco de trabajo es aplicable a todos los proyectos d~

software, sin importar su tamao o complejidad. Algunos conjuntos de tareas diferentes (tareas, hitos, productos de trabajo y puntos de control de calidad) permiter
que las actividades del marco de trabajo se adapten a las caractersticas del proyecto de software, as como a los requisitos del equipo del proyecto. Finalmente, las activtdades protectoras (como el control de calidad del software, la gestin de configuracir
fa filosofo de/ f)IO<BSO

6gil (captulo 4) arg,r
menflJn que sus proce-
sas san ms magros

que otros. Esto puede
se, cierto, pero ellos
lodovfo tienen un pr1r
ceso, yla 111genierfo
de sdrme 6gH1do. , P.l1,el! ~ .
del software y la medicin) cubren el modelo del proceso. Las actividades protectoras
son independientes de cualquier actividad del marco de trabajo y ocurren durante todo el proceso.
CAPTULO 21
643
CONCEPTOS DE GES'JJN DE r.!OY'"..C.OS
21.1.4 El proyecto
Los proyectos de software se realizan de manera planificada y controlada por una
razn principal: es la nica forma conocida de gestionar la complejidad. Incluso los
esfuerzos continuarn. En 1998, los datos industriales indicaron que el 26 por ciento de los proyectos de software fracasaron por completo, y que el 46 por ciento rebasaron sus costos y y tiempos de entrega [REE99]. Aunque la tasa de xito para los
proyectos de software ha mejorado un poco, la tasa de fracaso de proyectos permanece ms elevada de lo que debiera. 1
"JII ~ es tomo un viaje por carretero. Algunos proyedos son simples y ronarios, como cQnducir li,xio la tia,n,
di oplena lur del dio. Pero 1(1 mayora de los proyectos quevale lopena realizar sonms parecidos o:coodudr un <rimin enfo carretera, en la montaa, de noche.#
Cem Kaner, James Bqch y Bret Pettkhenl.

Para evitar el fracaso del proyecto, un gestor de proyecto de software y los ingenieros de software que construyen el producto deben eludir un conjunto de seales
de advertencia comunes, comprender los factores de xito crticos que conducen a
una buena gestin del proyecto y desarrollar un enfoque de sentido comn para planificar, supervisar y controlar el proyecto. Cada uno de estos tpicos se tratan en la
seccin 2 I .5 y en los captulos siguientes.
En un estudio que public el IEEE [CUR88] se les pregunt a los vicepresidentes de

ingeniera de tres grandes compaas tecnolgicas cul era el contribuyente ms importante para un proyecto de software exitoso. Respondieron de la siguiente forma:
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 desarrollo de software 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. verdadero buen personal, y que hago crecer al buen personal, y que proporciono un ambiente en el que el buen personal puede producir.
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 sustancial de estos proyectos "fallidos" estuvo. en pmner lugar, mal concebido. Los clientes pierden inters rpidamente (porque el producto solicitado no fue en realidad tan importante como lo que
pensaron primero) y los proyectos se cancelan
644
PARTE CUATRO GESTIN DE PROYECl'OS DE SOFTWAAE
De hecho, ste es un testimonio convincente acerca de la importancia del personal

en los procesos de ingeniera del software. Y sin embargo, todos, desde los vicepresidentes de ingeniera hasta el profesional ms modesto, usualmente no prestan
atencin al personal. Los gestores argumentan (como lo hace el grupo anterior) que
las personas son lo principal, pero sus acciones con frecuencia contradicen sus palabras. En esta seccin se examinan los participantes en el proceso de software y la
forma en que se les organiza para realizar una ingeniera de software efectiva.
21.2.1
Los participantes
El proceso de software (y cualquier proyecto de software) lo integran participantes

que pueden clasificarse dentro en una de cinco categoras:
1. Gestores ejecutivos, que definen los aspectos del negocio que usualmente tie-
nen una influencia significativa en el proyecto.

2. Gestores (tcnicos) del proyecto, quienes planifican, motivan, organizan y con-
trolan a los profesionales que realizan el trabajo de software.

3. Profesionales, quienes proporcionan las habilidades tcnicas necesarias para
realizar la ingeniera de un producto o aplicacin.

4 . dientes, quienes especifican los requisitos para la ingeniera del software y
otros elementos que tienen un inters mnimo en el resultado.
s. Usuarios finales, quienes interactan con el software una vez que se libera pa
ra su uso productivo.
Todo proyecto de software lo integran personas que se clasifican en esta taxoru:ma.2 Para ser eficaz, el equipo de proyecto debe estar organizado en una forma q-.. ~
maximice las capacidades y habilidades de cada persona. Y esta es la labor del lide
del equipo.
21.2.2 Lderes de equipo

gestin del proyecto es una actividad intensamente humana; por tanto, los profe:
sionales competentes con frecuencia no son buenos lderes de equipo. Simplemente r
tienen la mezcla correcta de habilidades con el personal. Adems, como Edgem1.
afirma: "Desafortunadamente, y con demasiada frecuencia, los individuos simple
mente caen en un papel de gestor de proyecto y se vuelven gestores de proyecto a..
cidentales" [EDG95].
En un excelente libro acerca del liderazgo tcnico, Jerry Weinberg [WEI86) sugi~
re un modelo MOi de liderazgo:
La
Motivacin. La habilidad para alentar (mediante "empuje o jaln") al persor.

tcnico para que produzca segn su mejor capacidad.
2 Cuando se desarrollan las aplicaciones Web (Parte 3 de este libro), en la creacin de contenido p...
den involucrarse otras personas no tcnicas.
CAPTULO 21
CONCEPTOS DE GESTIN DE PROYECIOS
645
Organizacin. La habilidad para adecuar los procesos existentes (o inventar

unos nuevos) que permitirn que el concepto inicial sea traducido en un producto final.
Ideas o innovacin. La habilidad para alentar a la gente a crear y sentir creativamente, incluso cuando deben trabajar dentro de los limites establecidos por un
producto o aplicacin de software particular.
Weinberg sugiere que los lderes de proyecto exitosos aplican un estilo de gestin
de resolucin de problemas. Esto es: un gestor de proyecto de software debe concentrarse en entender el problema que ser resuelto, gestionar el flujo de ideas y, al
mismo tiempo, hacer que todos los que forman el equipo conozcan (con palabras y,
mucho ms importante, con acciones) que la calidad es relevante y que no ser comprometida.
*En loS: tmrilJCISms wnples, un Uder es aquel que sobe adnde quier.e ir, y s. levooto yVCI.
Otra visin [EDG95] de las caractersticas que definen un gestor de proyecto eficiente resalta cuatro rasgos clave:
Resolucin de problemas. Un gestor de software eficiente puede diagnosticar

los conflictos tcnicos y organizativos ms relevantes, estructurar de manera sistemtica una solucin o motivar adecuadamente a otros profesionales para desarrollar la solucin, aplicar en las nuevas situaciones las lecciones aprendidas en proyectos pasados, y mantenerse lo suficientemente flexible como para cambiar de direccin si los intentos iniciales en la solucin del problema son infructuosos.
Dotes de gestin. Un buen gestor de proyecto debe encabezarlo y dirigirlo. Debe tener la confianza de asumir el control cuando es necesario y la seguridad para
permitir que los buenos profesionales tcnicos sigan sus instintos.
Incentivos. Para optimizar la productividad de un equipo de proyecto, un gestor

debe recompensar la iniciativa y los logros; adems, demostrar con sus propias acciones que la toma de riesgos controlada no ser penalizada.
Influencia y fomento de la cultura de equipo. Un gestor de proyecto eficaz

debe ser capaz de "leer" a la gente; de entender las seales verbales y no verbales y
reaccionar a las necesidades de la gente que las enva. El gestor debe mantener el
control en situaciones de alta tensin emocional.
21.2.3 El equipo de software

Existen casi tantas estructuras organizacionales de profesionales para el desarrollo
de software como organizaciones que tiene el mismo fin. Para bien o para mal, la
estructura organizacional no puede ser fcilmente modificada. Las preocupaciones
acerca de las consecuencias prcticas } politicas del cambio organizacional no es-
PARTE CUATRO GESTIN DE PROYECTOS DE SOF1WARE
646
tn dentro del mbito de responsabilidad del gestor del proyecto de software. s

embargo, la organizacin de la gente directamente involucrada en un proyecto
software est dentro del mbito del gestor del proyecto.
"No todo grupo es un equipo, y no todo equipo es eficiente.
La "mejor" estructura de equipo depende del estilo de gestin de cada organ1.:2cin, del nmero de personas que integrarn el equipo y de sus grados de habih~
as como de la dificultad global del problema. Mantei [MAN81J describe siete faC'
res de proyecto que deberan considerarse cuando se planifica la estructura de
equipos de ingenieria del software:
Qu
factores se
deben considerar
cuando se elige la
estructura de un
equipo de
software?
La dificultad del problema que se resolver.

El "tamao" del programa(s) resultante(s) en lneas de cdigo o puntos de
cin (capitulo 22).
El tiempo que el equipo estar junto (vida del equipo).
El grado en el que el problema puede separarse en mdulos.
La calidad y confiabilidad requeridos del sistema que se construir.
La rigidez de la fecha de entrega.
El grado de sociabilidad (comunicacin) que requiere el proyecto.
"Si quiere sercodo vez meior:seo competilivo. Si quiere ser exponencialmente mejof: sea cooperutiw.
Constantine [CON93] sugiere cuatro "paradigmas organizacionales" para los~

pos de ingenier[a del software:
Qu
opciones se
tienen cuando
se define la
estructura de IR
equipo de
software?
1. Un paradigma cerrado estructura un equipo a lo largo de una jerarqua tradicional de autoridad. Estos equipos pueden trabajar mejor cuando produce.software muy similar a los proyectos anteriores, pero ser menos probable
que sean innovadores cuando trabajen dentro del paradigma cerrado.
2 . Un paradigma aleatorio estructura un equipo libremente y depende de la iniciativa individual de los miembros del equipo. Cuando se requieren innovacin o adelantos tecnolgicos, los equipos que siguen el paradigma aleatcsern excelentes. Pero estos equipos pueden luchar cuando se requiere "desempeo ordenado".
3. Un paradigma abierto intenta estructurar un equipo en una forma que logre
gunos de los controles asociados con el paradigma cerrado, pero tambin
mucha de la innovacin que ocurre cuando se aplica el paradigma aleator::.>.
CAPTULO 21
CONCEPTOS DE GESTIN DE PROYECTOS
647
El trabajo se desarrolla en colaboracin. La slida comunicacin y la toma de

decisiones basada en el consenso son las marcas caractersticas de los equipos de paradgma abierto. Las estructuras de equipo de paradigma abierto se
adecuan bien a la solucin de problemas complejos, pero no pueden desempearse de manera tan eficiente como otros equipos.
4. Un paradigma sincrnico se apoya en la compartimentalizacin natural de un

problema y organiza a los miembros del equipo para trabajar en partes del problema con poca comunicacin activa entre ellos.
r con la gellte es dificil, mos no imposible.#

como nota histrica, una de las primeras organizaciones de los equipos de software fue una estructura de paradgma cerrado originalmente llamada equipo programador jefe. Esta estructura la propuso originalmente Harlan Milis y la describi Baker
(BAK72]. El ncleo del equipo lo compone un ingeniero ejecutivo (el programador jefe), quien planifica, coordina y revisa todas las actividades tcnicas del equipo; personal tcnico (por lo general, de dos a cinco personas), quienes dirigen las actividades
de anlisis y desarrollo; y un ingeniero de respaldo, quien apoya al ingeniero ejecutivo en sus actividades y puede reemplazarlo con mnima prdida en la continuidad del
proyecto.
Al programador jefe pueden asistirlo uno o ms especialistas (por ejemplo, expertos en telecomunicaciones, diseador de bases de datos), personal de apoyo (por
ejemplo, escritores tcnicos, personal administrativo) y un bibliotecario de software.
Como contraparte a la estructura de equipo programador jefe, el paradigma aleatorio de Constantine [CON93) sugiere un equipo de software con independencia
creativa cuyo enfoque para trabajar puede denominarse mejor como anarqua innovadora. Aunque se ha apelado al enfoque de libre espritu para el trabajo de software, la canalizacin de la energia creativa hacia un equipo de alto rendimiento debe
ser una meta central en una organizacin de ingeniera del software. Para lograr un
equipo de alto rendimiento:
Los miembros del equipo deben tenerse mutua confianza.
La distribucin de las habilidades debe adecuarse al problema.
Tal vez los disidentes deban ser excluidos del equipo si ha de conservarse su
cohesin.
Sin importar la organizacin del equipo, el objetivo de cualquier gerente de proyecto es apoyar la creacin de un equipo que muestre cohesin. En su libro, Peoplewa
re, DeMarco y Lister [DEM98] examnan este tpco:
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 muchos de estos grupos no parecen equipos. Mn uenen ,ma definicin comn de xito o al-
648
gn espritu de equipo identificable. Lo que se ha perdido es un fenmeno que llamamos

cuajar (je/JJ.
Un equipo cuajado es un grupo de personas tan fuertemente unido que el todo es ma
yor que la suma de las partes...
Una vez que un equipo comienza a cuajar, la probabilidad de xito aumenta. El equipo puede volverse imparable, un monstruo destructivo para lograr el xito ... No necesita
ser gestionado en la forma tradicional, y ciertamente no necesita ser motivado. Tiene lmpetu.
Por q,
fracasan los
equipos que
buscaa cvajar?
DeMarco y Lister sostienen que los miembros de los equipos cuajados son significa
tivamente ms productivos y estn ms motivados que el promedio. Comparten urmeta comn, una cultura comn y, en muchos casos, un "sentimiento elitista" qu
los hace nicos.
Pero no todos los equipos cuajan. De hecho, muchos equipos sufren de lo que
Jackman UAC98] denomina "toxicidad de equipo". Ella define cinco factores que "fomentan un ambiente de equipo potencialmente txico": I) una atmsfera de traba
frentica, 2) alta frustracin que provoca friccin entre los miembros del equipo, :
un proceso de software "fragmentado o pobremente coordinado", 4) una definici<n
poco clara de los papeles del equipo de software, y 5) "continuas y repetidas expOSi ciones al fracaso".
Para evitar un ambiente de trabajo frentico, el gestor del proyecto debe tener a
certeza de que el equipo tiene acceso a toda la informacin requerida para realizar
el trabajo y que las metas y objetivos, una vez definidos, no deben modilcarse a menos que sea absolutamente necesario. Un equipo de software puede evitar la frustr.:cin (y el estrs) si se le da tanta responsabilidad en la toma de decisiones como se:J
posible. un proceso inadecuado (por ejemplo, tareas de trabajo innecesarias o abn
madoras o productos de trabajo mal elegidos) se puede evitar si se comprende L
producto que se construir y al personal que realiza el trabajo, y al permitir al equ
po seleccionar su propio modelo de proceso. El equipo debe establecer por s misl'T'
mecanismos para su responsabilidad (revisiones tcnicas formales y la programacin por pares son excelentes formas de lograrlo) y definir una serie de enfoques correctivos cuando un miembro del equipo falle en su desempeo. Y, finalmente, la clave para evitar una atmsfera de fracaso es establecer tcnicas basadas en el equi>"
para la realimentacin y resolucin de problemas.
:er ono hacer. No existe intentar.
Adems de las cinco toxinas que describe Jackman, un equipo de software usualmente enfrenta los diferentes rasgos humanos de sus miembros. Algunos miembros
del equipo son extrovertidos; otros, introvertidos. Algunas personas recopilan informacin intuitivamente; separan los conceptos amplios de los hechos disparatados
CAPTULO 21
CONCEPTOS DE GESTIN DE PROYECTOS
649
Otros procesan la informacin linealmente, renen y organizan detalles minuciosos

de los datos proporcionados. Algunos miembros del equipo se sienten cmodos al
tomar decisiones slo cuando se presenta un ordenado argumento lgico. Otros son
intuitivos, por lo que desean tomar decisiones con base en el "sentimiento". Algunos
profesionales prefieren una planificacin detallada que incluya tareas organizadas
que les permitan lograr el cierre de algn elemento del proyecto. otros prefieren un
ambiente ms espontneo en el que los temas abiertos son bien vistos. Algunos trabajan duro para hacer que las cosas estn listas mucho antes de una fecha limite, y
por consiguiente evitan la tensin conforme la fecha se aproxime, mientras que
otros se sienten vigorizados por la prisa de lograrlo en el ltimo minuto del plazo.
Un examen detallado de la psicologa de estos rasgos y las formas en las cuales el Jfder experimentado del equipo puede ayudar a la gente con rasgos opuestos para trabajar en conjunto est ms all del mbito de este libro. 3 Sin embargo, es importante destacar que el reconocimiento de las diferencias humanas es el primer paso hacia la creacin de equipos que cuajan.
21.2.4 Equipos giles

En aos recientes se ha propuesto el desarrollo del software gil (captulo 4) corno
antdoto para muchos de los problemas que perjudican el trabajo de los proyectos de
software. En sntesis, la filosofia gil alienta la satisfaccin del cliente y la temprana
entrega incremental de software; pequeos equipos de trabajo enormemente motivados; mtodos informales; mnimos productos de trabajo de ingeniera del software; y simplicidad global de desarrollo.
El pequeo equipo de trabajo enormemente motivado, tambin llamado equipo
gil, adopta muchas caractersticas de los equipos de proyecto de software exitosos
tratados en la seccin precedente y evitan muchas de las toxinas que crean problemas. Sin embargo, el enfoque gil subraya la competencia individual (miembros del
equipo) en conjuncin con la colaboracin del grupo como factores de xito cruciales para el equipo. Cockbum y Highsmith [COCO!] destacan esto cuando escriben:
Si el personal en el proyecto es lo suficientemente bueno, pueden usar casi cualquier proceso y lograr su cometido. Si no es lo suficientemente bueno, ningn proceso reparar su
incapacidad: "persona mata proceso" es una forma de decir esto. Sin embargo, la falta de
apoyo del usuario y el ejecutivo pueden aniquilar un proyecto: "politica mata persona". El
apoyo inadecuado puede incluso evitar que el buen personal logre la tarea .. .
Para aprovechar en forma eficiente las competencias de cada miembro del equipo y fomentar la colaboracin eficaz a lo largo de un proyecto de software, los equipos giles son autoorganizados. Un eqwpo autoorganizado no necesariamente man-
Una excelente introduccin a estos temas. relatadas por eqwpos de proyecto de software, se puede
encontrar en (FER98].
650
PARTE CUATRO GFSnN DE PROYOCTOS DE sonwAAE
tiene una sola estructura de equipo, sino que ms bien aprovecha elementos de
paradigmas aleatorio, abierto y sincrnico de Constantine tratados en la seccL
21.2.3.
la propiedad coladiw no es ms que uno porti<ulorizo<in de la ideo de que los produ<tos deben ..,.... ..
...., [6gl1], l1l> CI los individuos que integraron el equipo."
ut
&~
~~
C~VE
Un equipo 6gil as un
equipo aulOOIQO!lizodo
que tiene autonoma

poro planear y tomo,
decisiones tcnicos.
Muchos modelos de proceso gil (por eJemplo, Scrum) brindan al equipo gil 1...
autonoma significativa para realizar la gestin del proyecto y tomar las decision
tcnicas requeridas para cumplir el trabajo. La planificacin se mantiene en el m1
mo, y al equipo se le permite seleccionar su propio enfoque (por ejemplo, proce
mtodos. herramientas) , slo restringido por los requisitos del negocio y los est..
dares organizacionales. Conforme el proyecto avanza el equipo se autoorganiza , ..
ra enfocar la competencia individual en una forma que sea ms benfica para el p
yecto en un punto dado en el tiempo. Para lograrlo, un equipo gil puede dirigir bi .e
ves reuniones de equipo diarias para coordinar y sincronizar el trabajo que se d
lograr ese da.
Con base en la informacin obtenida durante estas reuniones, el equipo ada..
su enfoque de forma tal que logra un incremento de trabajo. Conforme pasa~
da, la autoorganizacin continua y la colaboracin mueven al equipo hacia la c
clusin de un incremento de software.
21.2.5 Conflictos de coordinacin y comunicacin

Existen muchas razones por las cuales los proyectos de software se vuelven pro... e-mticos. La escala de muchos esfuerzos de desarrollo es grande, lo que conduc.. a
complejidad, confusin y dificultades significativas en la coordinacin de los mie
bros del equipo. La incertidumbre es comn, lo que genera una corriente contr
de cambios que mueve gradualmente en una sola direccin al equipo del proyec
La interoperabilidad se ha convertido en una caracterstica clave de muchos siSl
mas. El nuevo software debe comunicarse con el anterior y adecuarse a las rest~
ciones predefinidas que impone el sistema o producto.
Estas caractersticas del software moderno -escala, incertidumbre e interope
bilidad- son aspectos de la vida. Para lidiar con ellos en forma eficaz, un equipo
ingeniera de software debe establecer mtodos eficientes para coordinar al pers.
nal que realiza el trabajo. Para lograrlo se deben establecer mecanismos para la c
municacin formal e informal entre los miembros del equipo y entre mltiples eq
pos. La comunicacin formal se logra por medio de "escritos, reuniones estructur das y otros canales de comunicacin relativamente no interactivos e impersonale
[KRA95J. La comunicacin informal es ms personal. Los miembros de un equipo G.
software comparten ideas sobre una base ad hoc, piden ayuda cuando surgen p
blemas e interactan unos con otros diariamente.
CAPTULO 21
CONCEPTOS DE GESTIN DE PilOTI:C'iOS
651
Vinod: Y oon cddad,
Jamie: ~
El gestor de un proyecto de software se enfrenta con un dilema desde el principio

mismo de un proyecto de ingeniera del software. Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de informacin slida. Un anlisis
detallado de los requisitos de software proporcionarla la informacin necesaria para las estimaciones, pero, con frecuencia, el anlisis toma semanas o meses en completarse. Peor an, los requisitos pueden ser fluidos, y cambian regularmente conforme el proyecto avanza. Ms todava, se necesita un plan "ahora"!
En consecuencia, se deben examinar el producto y el problema que se intenta resolver al inicio del proyecto. Como mnimo, se debe establecer y acotar el mbito del
producto.
21.3.1
mbito del software
La primera actividad de gestin de un proyecto de software es la determinacin del

mbito del software. El mbito se define al responder las siguientes preguntas:
652
Si no puede acotar
uno caroctetfstico del
software que intento
construir, anote la ca
ractenstica como un
riesgo del proyecto
(captulo 25).
PARTE CUATRO
~N DE POOYECTOS DE SOFTWARE
Contexto. Cmo encaja el software que se desarrollar en un sistema ms gra:de, producto o contexto de negocios, y qu restricciones se imponen corno resul'..:.
do del contexto?
Objetivos de informacin. Qu objetos de datos visibles al usuario (capitulo ~
se producen como resultado del software? Qu objetos de datos se requieren de etrada?
Funcin y desempeo. Qu funciones realiza el software para transformar
datos de entrada en salida? Existen algunas caracteristicas de desempeo especf.:.
les que deban abordarse?
El mbito del proyecto de software no debe ser ambiguo ni incomprensible a nive :l
de gestin y tcnico. Se debe acotar un enunciado del mbito del software. Esto ~
se establecen de manera explicita los datos cuantitativos (por ejemplo, nmero .k
usuarios simultneos, tamao de la lista de correo, tiempo de respuesta m)d:permitido); se anotan las restricciones o limitaciones (por ejemplo, el costo del p;
dueto restringe el tamao de la memoria) y se describen los factores que redu ~
riesgos (por ejemplo, los algoritmos deseados se comprenden bien y estn dispc
bles en C++).
21.3.2 Descomposicin del problema
El desarrollo de un
plan de proyedo row
noble requiere des
componer el
problema. Esto se
puede lograr emp/eo11do uno listo de funciones ode cosos de uso
o, en el trabajo gil,
historias de usuario.
La descomposicin del problema, a veces llamada particin o elaboracin del pro ..

ma, es una actividad que se asienta en el ncleo del anlisis de requisitos de sofh
re (captulos 7 y 8). Durante la actividad de fijacin del mbito no se realiza intealguno por descomponer completamente el problema. Ms bien, la descomposic
se aplica en dos grandes reas: 1) la funcionalidad que debe entregarse y 2) el f
ceso que se emplear para entregarla.
Los seres humanos tienden a aplicar una estrategia de divide y vencers cuar
enfrentan un problema complejo. Dicho con simplicidad, un problema complejc
divide en problemas menores que resultan ms manejables. sta es la estrategia ::;se aplica cuando comienza la planificacin del proyecto. Las funciones de softwa;
descritas al enunciar el mbito, se evalan y refinan para proporcionar ms deta!. _
antes del comienzo de la estimacin (captulo 23). Puesto que las estimaciones
costo y planificacin temporal estn funcionalmente orientadas, con frecuencia _
til cierto grado de descomposicin.
Por ejemplo, considrese un proyecto que construir un nuevo procesador de L
tos. Entre las caractersticas nicas del producto estn la entrada continua med.:
te voz, as como por teclado, funciones muy sofisticadas de "edicin automtica
copia", capacidad de diseo de pgina, ndice y tabla de contenido automticos
otras. El gestor del proyecto primero debe establecer un enunciado del mbito e
acote estas caractersticas (as como otras funciones ms usuales como la edici
la gestin de archivos, la produccin de documentos y otras parecidas). Por ejemr
la entrada continua de voz requiere que el usuario del producto lo "entrene"?
CAPTULO 21 CONCEPTOS DE GESTIN DE PROvtCTOS
653
cficamente, qu capacidades proporcionar la caracterstica de edicin de copia?

Cun sofisticada ser la capacidad de diseo de pgina?
Conforme evoluciona el enunciado del mbito ocurre naturalmente un primer nivel de particin. El equipo del proyecto aprende que el departamento de mercadotecnia ha hablado con los clientes potenciales y encontr que las siguientes funciones deben integrarse a la edicin automtica de copia: 1) comprobacin ortogrfica,
2) comprobacin gramatical, 3) comprobacin de referencias para documentos
grandes (por ejemplo, la referencia a una entrada bibliogrfica se encuentra en la
lista de entradas en la bibliografa?) y 4) validacin de referencias de seccin y captulo para documentos grandes. Cada una de estas caractersticas representa una
subfuncin que debe implementarse en el software. Cada una todava puede refinarse ms si la descomposicin simplifica la planificacin.
Las actividades del marco de trabajo (capitulo 2) que caracterizan al proceso de software son aplicables a todos los proyectos de software. El problema es seleccionar el
modelo de proceso apropiado para que un equipo de proyecto someta al software a
ingeniera.
El gestor del proyecto debe decidir cul modelo de proceso es ms adecuado para 1) los clientes que han solicitado el producto y el personal que har el trabajo; 2)
las caractersticas del producto mismo, y 3) el ambiente del proyecto en el que trabaja el equipo de software. Cuando se ha seleccionado un modelo de proceso, entonces el equipo define un plan de proyecto preliminar con base en el conjunto de
actividades del marco de trabajo del proceso. Una vez que se establece el plan preliminar, comienza la descomposicin del proceso. Esto es, se debe crear un plan
completo, que refleje las tareas de trabajo requeridas para cubrir las actividades del
marco de trabajo. Estas actividades se exploran brevemente en las secciones siguientes, y en el captulo 24 se presenta una visin ms detallada.
21 .4.1 Combinaci6n del producto y el proceso

La planeacin del proyecto comienza con la combinacin del producto y el proceso.
cada funcin que el equipo de software someter a ingeniera debe pasar a travs
del conjunto de actividades del marco de trabajo definidas para una organizacin de
software. Supngase que la organizacin ha adoptado el siguiente conjunto de actividades del marco de trabajo (captulo 2): comunicaciones, planificacin, modelado,
construccin y despliegue.
Los miembros del equipo que trabajan en una funcin de producto le aplicarn
cada una de las actividades del marco de trabajo. En esencia, se crea una matriz similar a la mostrada en la figura 21.1 . cada funcin de producto principal (en la figura se anotan funciones para el software del procesador de textos comentado anteriormente) se menciona en la columna izquierda. Las actividades del marco de tra-
654
PARTE CUATRO
GESTIN DE PROYECTOS DE SOFIWARE
ifaiP.61
Combinacin
del problema
y el proceso.
/lf,11//1
~
d'
ACTIVIDADES COMUNES DEL MARCO

DE TRABAJO DEL PROCESO
Toreo< de inaeniero de wfwore
f.vnti-dl p~llt:to
En1r:,,;ki de 1ldo
Edicin v fi;,{n\dteado
<.i
%,~
..ff
..P->
.'o
!t>
.fl
~e-#
"
Edicic;,n- outom61it.:i 4e cooia
C1;1ooeid!ld de """'tillo d J:>6oillo

ndlce"v :ft,bit, ti,,, collt6i!ido ufomlkos
Gesfln ..le orch,vo,
'-"
Prodv<:dn ;l.. d<!uMento " '
"
;;_.,,
''.Je
. , --
i'"
.,.
-~ --
~
~~
c&v1
El morco de trobojodel
roceso estoblece llll
l!Slpl8le1o JXJro lo pion.
fiaxm del proyecto.
Se ~ li mr un
cocjmlo de toreos ode-
;;,,,
,.
''
bajo se mencionan en la hilera superior. Las labores de trabajo de ingenieria del se,
ware (para cada actividad del marco de trabajo) se ingresaran en la hilera siguie""
4
te. El trabajo del gestor del proyecto (y de otros miembros del equipo) consiste
estimar los requisitos de recursos para cada celda de la matriz, fechas de inicio y
nal para las tareas asociadas con cada celda, y los productos de trabajo que pr ~
eir cada tarea. Dichas actividades se consideran en el capitulo 24.
21.4.2 Descomposicin del proceso
amas IXlll e1 ~
Un equipo de software debe tener un grado significativo de flexibilidad al elegt- .
yedo.
modelo de proceso de software que sea mejor para el proyecto y las tareas de irg
niera del software que integren el modelo de proceso una vez elegido. Un proye...::
relativamente pequeo similar a otros que se hayan realizado puede lograrse me
si se utiliza el enfoque secuencial lineal. Si se imponen restricciones de tiempo ;;ceidas y el problema se puede compartimentalizar mucho, tal vez el modelo de
sarrollo rpido de aplicaciones (DRA) sea la opcin correcta. Si la fecha lmite es ceida que la funcionalidad completa no pueda alcanzarse, tal vez sea mejor una e
trategia incremental. De igual modo, los proyectos con otras caractersticas :ejemplo, requisitos inciertos, avances en la tecnologa, clientes dificiles, signifi...J
tivo potencial de reutilizacin) conducirn a la seleccin de otros modelos de p.
ceso. 5
una vez elegido el modelo de proceso, el marco de trabajo respectivo se adaa l. En cualquier caso se puede aplicar el marco de trabajo genrico comentado p-
se debe destacar que las tareas de trabajo tienen que adaptarse a las necesidades especficas
proyecto.
Recurdese que las caractersticas del proyecto tambin tienen una fuerte influencia en la estro:::=
ra del equipo de software (seccin 2 1.2.3).
CAPTULO 21
CONCEPTOS DE GESTlN
m: PROYECTOS
655
viamente: comunicacin, planificacin, modelado, construccin y despliegue. Funcionar para modelos lineales, iterativos e incrementales, as como evolutivos e incluso para modelos concurrentes o de ensamble de componentes. El marco de trabajo del proceso es invariable y sirve como base para todo el trabajo de software que
realiza una organizacin de software.
Pero las tareas de trabajo real varan. La descomposicin del proceso comienza
cuando el gerente de proyecto pregunta: "Cmo logramos esta actividad del marco
de trabajo'" Por ejemplo, un proyecto pequeo y relativamente simple puede requerir las siguientes tareas de trabajo para la actividad de comunicacin:
l. Desarrollar una lista de conflictos que deben clarificarse.

2 . Reunirse con los clientes para abordar los conflictos que deben clarificarse.
3 . Desarrollar en conjunto un enunciado del mbito.
4 . Revisar el enunciado del mbito con todos los implicados.

5 . Modificar el enunciado del mbito segn se requiera.
Estos sucesos pueden ocurrir en un periodo menor a 48 horas. Representan un proceso de descomposicin adecuado para el proyecto pequeo y relativamente simple.
Ahora, considrese un proyecto ms complejo, el cual tiene un mbito ms amplio y un impacto comercial ms significativo. Este proyecto puede requerir las siguientes tareas de trabajo para la actividad de comunicacin:
l . Revisar la peticin del cliente.

2. Planificar y programar una reunin formal con el cliente.
3. Llevar a cabo investigaciones para especificar la solucin propuesta y los enfoques existentes.
4 . Preparar un "documento de trabajo" y una agenda para la reunin formal.

5 . Celebrar la reunin.
6. Desarrollar en conjunto miniprospectos que reflejen los datos, funcin y caractersticas de comportamiento del software. Alternativamente, se desarrollan casos de uso que describen al software desde el punto de vista del
usuario.
7. Revisar cada miniprospecto o caso de uso para valorar su correccin, consistencia y falta de ambigedad.
8. Ensamblar los miniprospectos en un documento ms amplio.
9. Revisar el documento ms amplio o coleccin de casos de uso con todos los

implicados.
l O. Modificar el documento ms amplio o casos de uso segn se requiera.

Ambos proyectos realizan la actividad del marco de trabajo que se llama "comunicacin", pero el primer equipo de proyecto efectu la mitad de las tareas de trabajo de ingeniera de software que realiz el segundo.
656
21 ,5 EL eovco
La gestin de un proyecto de software exitoso requiere entender qu puede salir rr
(de modo que sea factible evitar los problemas). En un excelente articulo acerca <'.e
proyectos de software, John Reel [REE99] define 10 seales que indican que un pr
yecto de sistemas de informacin est en peligro:
Cules son
las seales
de que un
proyecto de
software est en
pefigro?
1. El personal de software no entiende las necesidades de sus clientes.

2. El mbito del producto est mal definido.
3. Los cambios se gestionan mal.
4. La tecnologia elegida cambia.

5. Las necesidades comerciales cambian [o estn mal definidas].
6. Los plazos de entrega no son realistas.

7. Los usuarios se resisten.
8 . se pierde el patrocinio fo nunca se obtuvo de manera adecuada].
9 . El equipo de proyecto carece de personal con las habilidades apropiadas.

1 o. Los gestores [y los profesionales] evitan las mejores prcticas y las lecciones
aprendidas.
Los profesionales industriales muy experimentados con frecuencia se refieren me-dio frvolamente) a la regla 90-90 cuando estudian proyectos de software part1cu
mente dificiles. El primer 90 por ciento de un sistema absorbe el 90 por ciento del es-fuerzo y el tiempo asignados. El ltimo 1O por ciento toma el otro 90 por cient
esfuerzo y el tiempo asignados [ZAH94J. Las causas que conducen a la regla del
90 estn contenidas en las seales anotadas en la lista precedente.
"No tenemos tiempo poro detenemos por combustible, ya vamos tarde:
M.O..
Pero basta de negatividad! Cmo acta un gestor para evitar los problemas recin sealados' Reel fREE99J sugiere un enfoque de sentido comn de cinco pa
para proyectos de software:
1. Comience con el pie derecho. Esto se logra trabajando duro (muy duro) para
entender el problema que ser resuelto y entonces establecer objetivos y e pectativas realistas para todos los que estarn involucrados en el proyecto
Esto se refuerza mediante la construccin del equipo correcto (seccin 21 l.
y al darle al equipo la autonoma, autoridad y tecnologa necesarios para hacer el trabajo.
2 . Mantenga el mpetu. Muchos proyectos tienen un buen comienzo y luego le"'
lamente se desintegran. Para mantener el lmpetu, el gestor del proyecto det:
proporcionar incentivos para conservar los reveses del personal en un mm.-
CAPTULO 21
CONCEPTOS DE GESTIN DE l'ROYECrOS
657
mo absoluto; el equipo debe resaltar la calidad en cada tarea que realiza, y los
gestores ejecutivos debe hacer todo lo posible por mantenerse fuera del camino del equipo. 6
3. Rastree el progreso. En un proyecto de software el progreso se rastrea conforme se elaboran los productos de trabajo (por ejemplo, modelos, cdigo fuente, conjuntos de casos de prueba) y se aprueban (mediante revisiones tcnicas
formales) como parte de una actividad de aseguramiento de la calidad. Adems, se pueden recopilar y aplicar procesos del software y medidas del proyecto (captulo 22) para valorar el progreso contra los promedios establecidos
por la organizacin que desarrolla software.
4. Tome decisiones inteligentes. En esencia, las decisiones del gestor del proyecto
y del equipo de software deben encaminarse a "mantenerlo simple". Siempre
que sea posible, decdase a emplear software comercial ya desarrollado o
componentes de software existentes, decdase a evitar interfases personalizadas cuando estn disponibles enfoques estndar, decidase a identificar y luego evitar riesgos obvios, y decdase a asignar ms tiempo que el que
considere necesario a las tareas complejas o riesgosas (necesitara cada minuto).
5. Realice un anlisis de resultados. Establezca un mecanismo consistente para
extraer lecciones aprendidas por cada proyecto. Evale la planificacin real y
la prevista, recolecte y analice mtricas de proyecto de software, obtenga realimentacin de los miembros del equipo y de los clientes, y registre los hallazgos en forma escrita.
En un excelente articulo acerca de los procesos y proyectos de software, Barry

Boehm [B0E96J establece: "Usted necesita un principio organizador que escale hacia abajo para proporcionar planes [de proyecto] simples para proyectos simples".
Boehm sugiere un enfoque que aborde los objetivos del proyecto, los hitos y planificacin, responsabilidades, gestin y enfoques tcnicos y recursos requeridos. Boehm
lo llama el principio W 5HH, en honor a una serie de preguntas que conducen a una
definicin de las caracteristicas claves del proyecto y al plan de proyecto resultante:
Por qu se desarrolla el sistema? La respuesta a esta pregunta permite a todas las

partes evaluar la validez de las razones del negocio para el trabajo de software. Dicho de otra forma: el propsito del negocio justifica el gasto de personal, tiempo y
dinero?
La implicacin de este enunciado es que la burocraaa se reduce al mnimo, las reuniones extraas
se eliminan y la adherencia dogmtica a los procesos y reglas del proyecto se eliminan.

debe ser autoorganizado y autnomo.
El equipo
658
PARTE C UATRO
GESTIN DE PROYECTOS DE SOFTWARE
Qu se har? La respuesta a esta pregunta establece el conjunto de tareas que

requerir para el proyecto.
Cundo se har:> La respuesta a esta pregunta ayuda al equipo a establecer

planificacin del proyecto al identificar cundo se realizarn las tareas del proye
y cundo se alcanzarn los objetivos.
Quin es el responsable de una fu-ncin? Prrafos atrs se anot que el papel
responsabilidad de cada miembro del equipo de software deben estar definidos
respuesta a esta pregunta ayuda a lograrlo.
Dnde estn ubicados en la organizacin? No todos los papeles y responsabilk:.
des residen en el equipo de software. El cliente, los usuarios y otros participar
tambin tienen responsabilidades.
Cmo se har el trabajo desde los puntos de vista tcnico y de gestin? Una vez ....
tablecido el mbito del producto se debe definir una estrategia de gestin y tc~
para el proyecto.
Cunto de cada recurso se necesita? La respuesta a esta pregunta se deriva al ~
sarrollar estimaciones (capitulo 23) con base en las respuestas a las preguntas ar.
riores.
El principio W5HH de Boehm se aplica sin importar el tamao o la complejidad de
proyecto de software. Las preguntas anotadas proporcionan un excelente lineam;,e
to de planificacin para el gestor del proyecto y el equipo de software.
El Airlie CounciI7 ha elaborado una lista de "prcticas crticas de software para

gestin basada en el desempeo". Dichas prcticas son "empleadas consistenteme
te por, y consideradas crticas por, proyectos de software muy exitosos y por orga.zaciones cuya 'lnea base' de desempeo es mucho mejor que los promedios de
industria" [AIR99] .
Las prcticas crticas8 incluyen: gestin de proyecto basado en mtricas (capn:.
22), costo emprico y estimacin de la planificacin (captulos 23 y 24), seguimier
del valor ganado (captulo 24). gestin del riesgo formal (capitulo 25), seguimiento
defectos frente a objetivos de calidad (captulo 26) y gestin al tanto del persor
(seccin 21.2) . Cada una de estas prcticas crticas se aborda a lo largo de la parte
de este libro.
El Airlie Council es un equipo de expertos en ingenieria de sonware que reclut el Departamento

Defensa de los Estados Unidos de Amrica para ayudar a desarrollar lineamientos para mejore
prcticas en la gestin de proyectos de software y de ingeniera del software.
Aqu slo se anotan las prcticas crticas asociadas con la "integridad del proyecto".
CAPTULO 21
CONCEPTOS DE GESTIN DE PROVECYOS
659
Herramientas de software para gestores de proyectos

Las "herramientas" mencionados aqu son ge
nricos y se aplican o un amplio rango de octi
que realizan los gestores de proyecto. En los
captulos se consideran herramientas de gestin
.-edos especficos (por ejemplo, herramientas de
in, estimacin, de onlisis de riesgo).
ientas representativos9
~ r e Progrom Monoger's Network (www.spmn.com)

-,;;; desarrollado uno herramienta simple llamado Pro
! Control Panel que ofrece o los gestores de proyec
e.. un aviso directo del estado del proyecto. La
herramienta tiene calibradores" muy parecidos o un

tablero y est6 implementado con Microsoft Excel. Est6
disponible poro descargo en http://www.spmn.com/
products_softwore.html.
Gonfheod.com ha desarrollado un conjunto de tiles lisies

de verificacin para gestores de proyecto que se puede
descargar de http://www.gonttheod.com/.
lttoolkit.com (www.ittoolkit.com) ofrece "uno coleccin de
guas de plonificocin, plantillas de proceso y hojas de
clculo inteligentes" disponibles en CD-ROM.
La gestin de proyectos de software es una actividad protectora dentro de la ingeniera del software. Comienza antes de iniciar cualquier actividad tcnica y contina
a lo largo de la definicin, el desarrollo y el soporte del software de computadora.
Las cuatro P que tienen una influencia sustancial en la gestin de proyectos de
software: personal, producto, proceso y proyecto. El personal debe estar organizado
en equipos eficientes, motivados para hacer un trabajo de software de alta calidad y
coordinados para lograr una comunicacin eficaz. Los requisitos del producto se deben comunicar del cliente al desarrollador, ser divididos (descompuestos) en sus
partes constitutivas y distribuirse para que trabaje el equipo de software. El proceso
debe adaptarse al personal y al problema. se selecciona un marco de trabajo de proceso comn, se aplica un paradigma de ingeniera de software adecuado y se elige
un conjunto de tareas de trabajo para llevar a cabo el trabajo. Finalmente, el proyecto debe estar organizado en una forma que permita triunfar al equipo de software.
El elemento central en todos los proyectos de software es el personal. Los ingenieros de software pueden organizarse en diferentes estructuras de equipo, que van
desde las jerarquias de control tradicionales hasta los equipos de "paradigma abierto". Se pueden aplicar varias tcnicas de coordinacin y comunicacin para apoyar
el trabajo del equipo. En general, las revisiones formales y la comunicacin informal
de persona a persona son las ms valiosas para los profesionales.
La actividad de gestin del proyecto abarca medidas y mtricas, estimacin y planificacin, anlisis de riesgos, seguimiento y control. Cada uno de estos tpicos se
considera en los captulos siguientes.
9
Las herramientas registradas aqu son una muestra de esta categora. En la mayora de los casos los
nombres de las mismas son marcas registradas por sus respectivos desarrolladores.
660
PARTE CUATRO
RIURIMA'1M
[AIR99] Airlie Council, "Performance Based Management: The Program Managers Guide Base
on the 16-Point Plan and Related Metrics", Draft Report, 8 de marzo, 1999.
[BAK72] Baker, F. T., "Chief Programmer Team Management of Production Programming", e:
IBM Systems Journal, vol. 11, nm. 1, 1972, pp. 56-73.
[BOE96J Boehm, B., "Anchoring the Software Process", en IEEE Software, vol. 13, nm. 4, jul...'.
de 1996, pp. 73-82.
[COCOl] Cockbum, A. y J. Highsmith, "Agile Software Development: The People Factor", en IEE:
Computer, vol. 34, nm. 11 , noviembre de 2001, pp. 131 - 133.
[CON93] Constantine, L., "Work Organization: Paradigms for Project Management and Orgar
zation", en CACM, vol. 36, nm. 10, octubre de 1993, pp. 34-43.
[COU80] Cougar, J. y R. Zawacki, Managing and Molivating Computer Personnel, Wiley, 1980.
[CUR88] Curts, B. et al., "A Field Study of the Software Design Process for Large Systemsff ...
JEEETrans. Software Engineering, vol. SE-31, nm. 11, noviembre de 1988, pp. 1268-1287
(CUR94] Curts, B. et al., People Managemenl Capability Maturity Model, Software Engineering tr;;::
titute, 1994.
[DEM98] DeMarco, T. y T. Lister, Peopleware, 2a. ed., Dorset House, 1998.
[EDG95] Edgemon, J., "Right Stuff: How to Recognize lt When Selecting a Project Manager"
Application Development Trends, vol. 2, nm. 5, mayo de 1995, pp. 37-42.
(FER98J Ferdinandi, P. L., "Facilitating Communication", en IEEE Software, septiembre de 1
pp. 92-96.
UAC98] Jackman, M., "Homeopathic Remedies for Team Toxicity", en IEEE Software, julio
1998, pp. 43-45.
.
[KRA95] Kraul, R. y L. Streeter, "Coordination in Software Development", en CACM, vol. 38, n::l:
3, marzo de 1995, pp. 69-81.
[MAN81J Mantei, M., "The Effect of Programming Team Structures on Programming Tasks~ e
CA.CM, vol. 24, nm. 3, marzo de 1981, pp. 106-1 13.
[PAG85] Page-Jones, M ., Practica! Project Management, Dorset House, 1985, p. vii.
[REE99] Reel, J. S , "Critica! Success Factors in Software Projects", en IEEE SOftware, mayo .
1999, pp. 18-23.
[WEI86] Weinberg, G., On Becoming a Technica/ Leader, Dorset House, 1986.
[WIT94J Whitaker, K, Managing Software Maniacs, Wiley, 1994.
[ZAH94] Zahniser, R., "Timeboxing for Top Team Performance", en Software Developmenl, ~
zo de 1994, pp. 35-38.
21. l. Con base en la informacin contenida en este capitulo y la experiencia propia, desarr
llar "1 O mandamientos" para alentar el potencial de los ingenieros de software. Esto es: elab
rar una lista de I O lineamientos que conducirn al personal que desarrolla software a ejercer
potencial completo.
21.2. El modelo de madurez de la capacidad de gestin de personal (MMCGP) del Sollware E;gineering Institute realiza un estudio organizado de las "reas prcticas clave" (APC) que Cu1..
va el buen personal de sollware. El instructor asignar una APC para analizar y resumir.
21.3. Describir tres situaciones de la vida real en las cuales el cliente y el usuario final son
mismo. Describir tres situaciones en las cuales son diferentes.
21.4. Las decisiones que toman los gestores ejecutivos pueden tener un impacto significaw
en la eficacia de un equipo de ingenieria del software. Proporcionar cinco ejemplos que ilustre
que esto es cierto.
21.5. Repasar el libro de Weinberg [WE186J y escribir un resumen de dos o tres pginas de
tpicos que deben considerarse al aplicar el modelo MOi.
CAPITULO 21
CONCEPTOS DE GESTIN .>E FROn:cros
661
2 1 .6. Usted ha sido nombrado gestor de proyecto dentro de una organizacin de sistemas de
informacin. Su labor es construir una aplicacin que sea bastante similar a otras que ha construido su equipo, aunque sta es mayor y ms compleja El cliente ha documentado ampliamente los requisitos. Qu estructura de equipo elegira y por qu? Qu modelo(s) de proceso de
sollware elegira y por qu?
21 . 7. Usted ha sido nombrado gestor de proyecto en una pequef'\a compai'lfa de productos de

sollware. Su labor es construir un producto de avanzada que combine hardware de realidad virtual con software de ltima generacin Puesto que la competencia en el mercado del entretenimiento casero es intensa. existe una presin significativa para completar el trabajo. ,Qu estructura de equipo elegira y por qu? Qu modelo(s) de proceso de software elegirla y por qu?
2 1.8 . Usted ha sido nombrado gestor de proyecto en una gran compaia de productos de software. Su labor es gestionar el desarrollo de la versin de siguiente generacin de su software
de procesamiento de textos ampliamente utilizado. Puesto que se deben generar nuevos ingresos, se han establecido y anunciado fechas limite precisas. Qu estructura de equipo elegira y
por qu? Qu modelo(s) de proceso de software elegirla y por qu?
21.9. Usted ha sido nombrado gestor de proyecto de software para una compaia que atiende
al mundo de la ingeniera gentica. Su labor es gestionar el desarrollo de un nuevo producto de
sollware que acelerar el ritmo de la clasificacin de genes. El trabajo est orientado l+D, pero
la meta es elaborar un producto dentro del siguiente ao. Qu estructura de equipo elegira y
por qu? Qu modelo(s) de proceso de software elegira y por qu?
21 . 1o. A usted se le pide desarrollar una pequea aplicacin que analice los curso que ofrece
una universidad y reporte la calificacin promedio obtenida en el curso (para un periodo determinado) Escriba un enunciado del mbito que abarca este problema.
21 . 11 . Realice una descomposicin funcional de primer nivel de la funcin plantilla de pgina
tratada brevemente en la seccin 21.3.2
El Project Management lnstitute (Gude to lhe Project Management Body of Knowledge, PMI, 2001)
cubre todos los aspectos importantes de la gestin de proyectos Murch (ProJecl Management
Besl Practcesfor IT Professonals, Prentice-Hall. 2000) ensea habilidades bsicas y proporciona
una gula detallada para todas las fases de un proyecto de TI. Lewis (Project Managers Desk Reference, McGraw-Hill, 1999) presenta un proceso de 16 pasos para planificar, supervisar y controlar cualquier tipo de proyecto. McConnell (Professional software Development, Addison-Wcsley, 2004) ofrece consejos pragmticos para "lograr planes ms cortos, productos de mayor calidad y proyectos ms exitosos".
Una excelente serie de cuatro volmenes escritos por Weinberg (Quality software Management, Dorset House, 1992, 1993, 1994, 1996) introduce conceptos bsicos de pensamiento y gestin de sistemas; explica cmo usar mediciones efectivamente; y aborda la "accin congruente", la habilidad de establecer "acoplamiento" entre las necesidades del gestor, las necesidades
del equipo tcnico y las necesidades del negocio. El libro brindar informacin til a los gestores tanto nuevos como experimentados. Futrell y sus colegas (Qualty SOjtware Project Manage
ment, Prentice-Hall, 2002) presentan un voluminoso tratamiento de la gestin de proyectos
Phillips (/T Project Management: On n-ackjrom Start to Fimsh, McGraw-Hill/Osborne, 20021,
Charvat (Project Management Nation, Wiley, 2002). Schwalbe (lnformation Technology ProJect Managemenl, 2a. ed., Course Technology, 2001) y Holtsnider y Jaffe (IT Manager's Handbook. Morgan Kaufmann Publishers, 2000) son representativos de los muchos libros que se han ese ito
acerca de la gestin de proyectos de software. Brown y sus colegas (AntiPattems m Proect Management, Wiley, 2000) examinan qu no hacer durante la gestin de un proyecto de softwl e.
Brooks (The Mythcal Man Monlh, Anmversary Edition, Addison-Wesley, 1995) ha actualizado su libro clsico para ofrecer una nueva visin en los temas de proyecto de solhvare y gestin. McConnell (SOjh,vare Project Swvi1 1 Guide, M1crosoll Press, 1997) presenta una excelente
gua pragmtica para quienes deben ges1 1nar pro;'t"ctos de software. Purba y Shah (How to M11-
662

nage a Successful Software Proect, 2a. ed., Wiley, 2000) presentan varios casos de estudio que indican por qu algunos proyectos tienen xito y otros fracasan. Bennatan (On nme Wlhm Bud
gel, 3a. ed.. Wiley, 2000) presenta sugerencias y lineamientos tiles para gestores de proyectos
de software.
Se puede argumentar que el aspecto ms importante de la gestn de proyectos de software
es la gestin de personal. Cockburn (Agile Software Development, Addison -Wesley, 2002) presenta uno de los meores anlisis del personal de sonware escrito hasta la echa. DeMarco y Liste:
[DEM98J han escrito el libro definitivo acerca del personal de software y los proyectos respectivos. Adems, en aos recientes se han publicado los siguientes libros en esta materia y vale la
pena examinarlos:
Beaudouin-Lafon, M .. Computer Supported Cooperative Work, Wiley-Llss, 1999.
Carmel, E., Global Software Teams: Collaborating Across Borders and 71me zones, Prentice HaU.
1999.
Constantine, L., Peopleware Papers: Notes on the Human Side ofSoftware. Prentice-Hall, 200'
Humphrey, W. S. Managing Tochnical People. Jnnovation, Teamwork and the Software Process
Humphrey, w. S., Jntroduction to lhe Team Software Process. Addison-Wesley, 1999.
Jones, P. H., Handbook of Team Design: A Practitioners Guide to Team Systems Developmen
McGraw-Hill, 1997.
Karolak , D. S., Global Software Development: Managing Vrtual Teams and Environments, lEEf.
Computer Society, 1998.
Ensworth (The Accidental Project Manager, Wiley, 2001) ofrece profusamente gulas tiles
quienes deben sobrevivir "la transicin de tcnico a gestor de proyecto". Otro excelente libro de
Weinberg [WEJ86J es una lectura obligada para todo gestor de proyecto y todo lder de equipo
Este libro le brindar el conocimiento y la guia que le permitirn hacer su trabajo de mane
ms eficiente.
Aun cuando no se relacionan especlficamente con el mundo del software, y en ocasiones se
bresimplifican y generalizan en extremo, los libros de "gestin" ms vendidos de Bossidy (Ei.~
cution The Discipline of Getting Things Done, Crown Publishing, 2002), Drucker (Managemen:
Challengesfor the 21st Century, Harper Business, 1999), Buckingham y COITman (First, Break"'the Rules: What lhe World's Greatest Managers Do Dijferently, Simon and Schuster, 1999) y Chns
tensen (The Jnnovator's Dilemma, Harvard Business School Press, 1997) resaltan "nuevas reglas
que define una economa rpidamente cambiante. Los tltulos viejos como Who Moved My Cho..
se?, The One-Minute Manager e In search ofExcellence continan ofreciendo valiosa informacil..
que pueden ayudarle a gestionar personas y proyectos de manera ms eficaz.
En Internet est disponible una amplia variedad de fuentes de informacin acerca de la ges
tin de proyectos de software. Una lista actualizada de referencias en la World Wide Web seercuentra en el sitio Web de SEPA:
MTRICAS DE PROCESO
Y PROYECTO
a medicin permite obtener una visin del proceso y el proyecto pues pro-
porciorta un mecanismo para lograr una evaluacin objetiva. Lord Kelvin

dijo una_ vez:
cuando puede medir aquello de lo que est hablando y expresarJo en nmeros sabe
algo acerca de ello; pero c~do no puede medir, cuando M puede expresado en n
meros, su ci:onoctmento ~s escaso, deficente: puede serel comenzo del conoclmien
to, pero, en SUS pensamientos, apenas est ~\lanzado al m't)itO de 1a Ciencia.
...676
La comunidad de la ingeniera del software ha tomado en serio las palabras de

lord KeMn. Mas no sin rrustracin y algo ms que un poco de controversia!
La mdicin se aplica al proceso de software con la finalidad de mejorarlo de
manera continua. La medicin se utillta a 1o largo de un proyecto de software
como apoyo en l estimacin, el control de calid;:ld, la valoracin de la productividad y el contrl del proyecto. Finalmente, la medicin la aplican los ingenieros
de software como auxiliar en la evaluacin de la calidad de los productos de trabajo y pata apoyarla toma de decisiones tctica confotme avanza un proyecto
(captulo I 5).
...666
....666
.614
En St..J guia acerca de la medicin de software, Park, Ooethert y Florac [PAR%

apuntan las.razones por la$ que se mide: 1} para carattenzat en un esfuerzo por
comprender acerca "de los procesos, prodtictos, recursos y entornos, y para establecer lneas.base para comparaciones con evaluaciones futuras" 2) para
tN<tluat "determinando el estado con respecto a los planes"; 3) para predecir me
dante ''la comprensin de relaciones entre procesos y productos y constru1r mo-
Cluilohot? Los gestores de softwore onoli

zon y evalan JO$ mtricos del software. O,n fre
~io, lo$ ingen$!'0} de softwqre re<;oplon }o$
!Md'idos
fw qu es im""nte? .S, no $e r~liuin

mediciones el juicio $lo ~ bso en evi;:ilvacin
subjetiva Lo medicin permite destcor lo$ ten
dencios (yo sean buena$ o moiosl y hocet mejo
mociones, y con el tiempo se pt,ede fogror
wrdadero mejoro.
0.611 r son los pasos? Se .comienza ~fnlen
con unto l,mitodo de medidos del preso
proyecto que puedan recopilarse (;Ot\ foci
medidos por lo general S norma
emDletnodo mtricos orientodds al tamao
663
664
PARTE CUATRO
GESTIN DE PROYECTOS DE sonwARE
delos de dichas relaciones"; y 4) para me;orar al "identificar barricadas, causas ra...

ineficiencias y otras oportunidades para mejorar la calidad del producto y el deser
peo del proceso" .
La medicin es una herramienta de gestora. Si se lleva a cabo adecuadame:
proporciona visin al gestor del proyecto. Y, como resultado, apoya al gestor del p:-oyecto y al equipo de software a tomar decisiones que conducirn a un proyecto e
toso.
&'
"~
c&v1
Los mtricos del

proceso tienen impocto
Olorgo J*IZO. Su
o~etivo es meoror el
proceso en si. Con
lrecuencio, los mtricos
del proyedO
contribuyen ol
desarrollo de mtricos
del proceso.
Las mtricas del proceso se recopilan en el curso de todos los proyectos y durante la=
gos periodos. Su objetivo es proporcionar un conjunto de indicadores de proceso q
conduzcan a la mejora de los procesos de software de largo plazo. Las mtricas
proyecto permiten que un gestor de proyecto de software 1) valore el estado de
proyecto en curso; 2) rastree los riesgos potenciales; 3) descubra las reas proble
antes de que se vuelvan "criticas"; 4) ajuste el flujo de trabajo o las tareas. y 5) e\
le la habilidad del equipo del proyecto para controlar la calidad de los productos
trabajo del soflware.
Las medidas que recopila un equipo de proyecto y las que convierte en mtpara emplearlas durante un proyecto tambin se pueden transmitir a quienes tie _
la responsabilidad de mejorar el proceso de software. Por esta razn, muchas de
mismas mtricas se usan tanto en el dominio del proceso como en el del proyec
22.1 .1 Mtricas del proceso y mejora del proceso de software

La nica forma racional de mejorar cualquier proceso es medir sus atributos espe
ficos, desarrollar un conjunto de mtricas significativas con base en dichos atribu
y luego emplear las mtricas para ofrecer indicadores que conducirn a una estra
gia de mejora. Pero antes de estudiar las mtricas de software y su impacto en la rr~
jora del proceso de software es importante destacar que el proceso slo es uno
varios "factores controlables en la mejora de la calidad del software y el desempeorganizacional" [PAU94].
En la figura 22.1 el proceso se asienta en el centro de un tringulo que canee
tres factores con una profunda influencia en la calidad del software y el desempe.
organizacional. La destreza y la motivacin del personal [BOE8 l J se muestran co
CAPTULO 22
665
MTRICAS DE PROCESO Y PROYEC'l'O
Producto
Personal
Tecnologa
el factor individual ms influyente en la calidad y el desempeo. La complejidad del

producto puede tener un impacto sustancial sobre la calidad y el desempeo del equipo. La tecnologia (es decir, los mtodos y herramientas de la ingeniera del software) que reside en el proceso tambin tiene un impacto.
Adems, el tringulo de proceso existe dentro de un crculo de condiciones ambientales que incluyen el entorno de desarrollo (por ejemplo, herramientas CASE),
condiciones del negocio (por ejemplo, fechas lmite, reglas comerciales) y caractersticas del cliente (por ejemplo, facilidad de comunicacin y colaboracin).
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce
un conjunto de mtricas basadas en los resultados que se derivan del proceso. Los
resultados incluyen medidas de errores descubiertos antes de liberar el software, los
defectos que detectan y reportan los usuarios finales, los productos de trabajo entregados (productividad), el esfuerzo humano gastado, el tiempo de la planificacin
consumido, concordancia con la planificacin y otras medidas. Tambin se deducen
mtricas de proceso al medir las caractersticas de tareas especificas de ingeniera
del software. Por ejemplo, se mide el esfuerzo y el tiempo utilizados al realizar las
actividades genricas de la ingeniera del software descritas en el captulo 2.
1
"la$ milri(Q$ de softwlire le permiten conocer cundo re' y amlo llorar.
Grady [GRA92] argumenta que existen usos privados y pblicos" para diferentes
tipos de datos de proceso. Como es natural que los ngenieros de software especiales sean sensibles al uso de las mtricas recop :adas sobre una base particular, di-
666
PARTE CUATRO
C1l es
la d"ifertnda
entre ISOS
privados y
pblim de las
mttricas de
software?
chos datos deben ser privados para el individuo y funcionar como un indicador slo
para l. Los ejemplos de mtncas privadas incluyen Indices de defecto por individuo
ndices de defecto por componente de software y errores encontrados durante el desarrollo.
La filosofia de "datos de proceso privados" se ajusta bien al enfoque de proceso personal del software (captulo 2) que propone Humphrey [HUM95]. Humphrey reconOC'!
que la mejora en el proceso de software puede y debe comenzar en el nivel individua..
Los datos de proceso privados pueden funcionar como un importante promotor pa.,
que el trabajo individual del ingeniero de software mejore.
Algunas mtricas de proceso son privadas para el equipo del proyecto de software, pero pblicas para todos los miembros del equipo. Los ejemplos incluyen defe.:tos que reportan las grandes funciones de software (las cuales desarrollaron varios
profesionales), errores detectados durante las revisiones tcnicas formales y lneas
de cdigo o puntos de funcin por mdulo o funcin. 1 Dichos datos los revisa d
equipo para descubrir indicadores que mejoren su desempeo.
Las mtricas pblicas por lo general asimilan informacin que originalmente era
privada para los individuos y equipos. Los ndices de defecto al nivel del proyecto
(que no se atribuyen por ningn motivo a un individuo), esfuerzo, planificacin y da-tos relacionados se recopilan y evalan con la finalidad de descubrir indicadores q-_~
pueden mejorar el desempeo del proceso organizacional.
Las mtricas del proceso de software ofrecen beneficios significativos conforr.- _
una organizacin trabaja en mejorar su grado global de madurez del proceso. sembargo, como todas las mtricas, stas pueden emplearse mal y crear ms prob...
mas de los que solucionan. Grady [GRA92J sugiere un "conjunto de reglas de etique.a
para las mtricas de software", adecuado tanto para gestores como para profesionales conforme instituyen un programa de mtricas del proceso:
Ov
hneamlentos
se deben aplicar
cuando se
recopila llltrkas
de software?
Aplique sentido comn y sensibilidad organizativa cuando interprete datos

mtricos.
Ofrezca retroalimentacin regular a los individuos y equipos que recopilan
medidas y mtricas.
No utilice las mtricas para evaluar a los individuos.
Trabaje con los profesionales y equipos para establecer metas claras y las mt!tricas que se emplearn para conseguirlas.
Nunca use mtricas para amenazar a los individuos o equipos.
Los datos mtricos que indican una rea problema no deben considerarse
"negativos". Dichos datos slo son un indicador de la mejora del proceso.
No se obsesione con una sola mtrica y excluya otras mtricas importantes.
1 Las mtricas de lineas de cdigo y punto de funcin se estudian en las secciones 22.2.1 y 22.2.2.
CAPTULO 22
MTRICAS DE PROCESO Y PROY-r.Cl'O
661
Conforme una organizacin se siente ms cmoda con la recopilacin y el empleo

de las mtricas de proceso, la deduccin de indicadores simples da la pauta para un
enfoque ms riguroso llamado mejora estadstica del proceso de software (MEPS). En
esencia, el MEPS aplica el anlisis de falla de software para recopilar informacin
acerca de todos los errores y defectos2 que se encuentran aJ desarrollar y utilizar una
aplicacin, sistema o producto.
22.1 .2 Mtricas del proyecto

A diferencia de las mtricas del proceso de software que se utilizan con propsitos
estratgicos, las mtricas del proyecto de software son tcticas. Es decir, un gerente
de proyecto y un equipo de software emplean las mtricas del proyecto y los indicadores que se deducen de ellas para adaptar el flujo de trabajo del proyecto y las actividades tcnicas.
La primera aplicacin de las mtricas del proyecto en la mayoria de los proyectos de
software ocurre durante la estimacin. Las mtricas recopiladas de los proyectos
previos se aprovechan como base desde la cual se realizan estimaciones de esfuerzo y tiempo para el trabajo de software actual. Conforme el proyecto avanza, la medidas de esfuerzo y tiempo utilizados se comparan con las estimaciones originales
(y la planificacin del proyecto) . El gestor del proyecto emplea dichos datos para su-
pervisar y controlar el progreso.

Mientras comienza el trabajo tcnico, las otras mtricas del proyecto comienzan
a tener significado Se miden los ndices de produccin representados en trminos
de modelos creados, horas de revisin, puntos de funcin y lneas fuente entregadas.
Adems, se les da seguimiento a los errores descubiertos durante cada tarea de ingenieria del software. Conforme el software evoluciona desde los requisitos hasta el
diseo, se recopilan mtricas tcnicas para valorar la calidad del diseo y mejorar
los indicadores que influirn en el enfoque que se adopte para la generacin y prueba del cdigo.
La finalidad de las mtricas del proyecto es doble. Primero, se emplean para minimi zar el tiempo de desarrollo haciendo los ajustes necesarios para evitar demoras
y reducir los problemas y riesgos potenciales. Segundo, se utilizan para valorar la calidad del producto sobre una base actual y, cuando es necesario, modificar el enfoque tcnico para mejorar la calidad.
Conforme la calidad mejora los defectos se minimizan, y mientras esto sucede
tambin se reduce la cantidad de reelaboracin requerida durante el proyecto. Esto
conduce a una reduccin en el costo global del proyecto.
En este libro, un error se define como algn fallo en un producto de trabajo de ingeniera del software 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 usuano final Se debe advertir que otros no hacen esta distincin En el capitulo 26 se presenta un mayor al"llisls
668
22, 2 M1p1c16s QIL $AftW4RI

En el captulo 15 se indic que la medicin de software se clasifica en dos categoras: 1) medidas directas del proceso de software (por ejemplo, costo y esfuerzo ap
cadas) y del producto (por ejemplo, lneas de cdigo [LDC] producidas, rapidez d..
ejecucin y defectos reportados a lo largo de cierto periodo establecido) y 2) me.:.
das indirectas del producto que incluyen funcionalidad, calidad, complejidad, eficier
cia, confiabilidad, facilidad de mantenimiento y muchas otras "habilidades" tratada
en el capitulo 15.
CAPTULO 22
669
MTRICAS DE PROCESO Y PROYECTO
' ]totodo lo que puede ser contado cuenta, y no todo lo que cuento puede ser contado/
'
, .y.
Las mtricas del proyecto se consolidan con el fin de crear mtricas del proceso
que sean pblicas para la organizacin de software como un todo. Pero, cmo combina una organizacin las mtricas provenientes de diferentes individuos o proyectos?
Con fines ilustrativos, considrese un ejemplo simple. Los integrantes de dos diferentes equipos de proyecto registran y categorizan los errores que encuentran durante el proceso del software. Luego, las mediciones individuales se combinan para
desarrollar medidas de equipo. El equipo A encontr 342 errores durante el proceso
del software previo al lanzamiento. El equipo B encontr 184 errores. Si todas las dems cosas se mantienen iguales, qu equipo es ms eficiente al descubrir errores a
lo largo del proceso? Puesto que no se conocen ni el tamao ni la complejidad de los
proyectos, no se puede responder esta pregunta. Sin embargo, si las mediciones se
normalizan, es posible crear mtricas de software que posibiliten la comparacin a
promedios organizacionales ms amplios. De esta forma, las mtricas orientadas
tanto al tamao como a la funcin estn normalizadas.
22.2.1
Mtricas orientadas al tamao
Las mtricas del software orientadas al tamao preceden de la normalizacin de las

medidas de calidad o productividad considerando el tamao del software que se ha
producido. Si una organizacin de software mantiene registros simples es factible
crear una tabla de medidas orientadas al tamao, como la que se muestra en la figura 22.2. En la tabla se menciona cada proyecto de desarrollo de software que se
ha completado en aos pasados, as como las medidas correspondientes para dichos
proyectos. Como se advierte en la entrada de tabla (figura 22.2) para el proyecto alfa: 12 100 lneas de cdigo se desarrollaron con 24 personas-mes de esfuerzo a un
costo de 168 000 dolares. Se debe notar que el esfuerzo y el costo registrados en la
tabla representan todas las actividades de ingeniera del software (anlisis, diseo,
cdigo y prueba), no slo codificacin. Informacin adicional del proyecto alfa indica que se desarrollaron 365 pginas de documentacin, se registraron 134 errores
antes de que el software fuese liberado y se encontraron 29 defectos despus de la
liberacin al cliente dentro del primer ao de operacin. Tres personas trabajaron en
el desarrollo del software para el proyecto alfa.
El desarrollo de mtricas que se asimilen con mtricas similares procedentes de
otros proyectos requiere elegir lneas de cdigo como valor de normalizacin. A partir de los datos rudimentarios de la tabla se desarrolla un conjunto de mtricas simples orientadas al tamao para cada pro:.ceto: errores por KLDC (miles de lneas de
cdigo), defectos por KLDC, costo por KLOC, pgmas de documentacin por KLDC.
Adems, se pueden calcular otras mtricas interesantes: errores por persona-mes,
KLDC por persona-mes, costo por pgina de documentacin.
670
PARTE CUATRO
iihfifij
Mtricas
orientadas al
tamao.
llt'oyecto
o{fo
peto.
gommo
LDC
12100
27200
20200
24
62
43
168
440
314
&l
'"~
C~VE
Los mhico.s orientados

al tamaa son
ampliamente
utilizados, pero
contino el debote
acerco de su volidez y
aplicabilidad.
365
1 224
loso
134
,.
321
256
a5
'
'
las mtricas orientadas al tamao no se aceptan universalmente como la mejG

forma de medir el proceso del software UON86J. La mayor parte de la controvers;..
gira en tomo al uso de lneas de cdigo como medida clave. Los partidarios de la medida LDC afirman que stas son un "artefacto" de todos los proyectos de desarrO:.
de software que pueden fcilmente contarse, que muchos modelos de estimacin c.::
software existentes usan LDC o KLDC como entrada clave, y que ya existe un gra.cuerpo de bibliografia y datos publicados para LDC. Por otra parte, los detractores a:
gumentan que las medidas LDC dependen del lenguaje de programacin, que, cuado se considera la productividad, castigan los programas bien diseados, pero ~
cortos, que no pueden amoldar con facilidad lenguajes que no provienen del proce
so y cuyo empleo en la estimacin requiere un nivel de detalle que sera dificil de L
grar (es decir, el planificador debe estimar que las LDC se producirn mucho antede que el anlisis y el diseo se hayan completado).
22.2.2 Mtricas orientadas a la funcin

las mtricas de software orientadas a la funcin emplean corno un valor de nonre
lizacin una medida de la funcionalidad que entrega la aplicacin. la mtrica orier
tada a la funcin utilizada con mayor amplitud es el punto de funcin (PF). El cla.
lo del punto de funcin se basa n caractersticas del dominio de informacin y _
complejidad del software. la mecnica del clculo del PF se trat en el Captulo 15
El punto de funcin, al igual que la medida LDC, es controversia!. Los partidaria.
afirman que el PF es independiente del lenguaje de programacin, caracterstica <}4lo hace ideal para aplicaciones que utilizan lenguajes convencionales y no proced.
mentales, y que se basa en datos que es ms probable que se conozcan tempral"~
en la evolucin de un proyecto, lo que hace al PF ms atractivo como enfoque de es-
Vase la seccin 15.3.1 para una detallada exposicin del clculo de PF.
CAPTULO 22
671
MTRICAS DE PROCESO Y PROYECro
timacin. Los detractores afinnan que el mtodo requiere cierta "prestidigitacin" en

cuanto a que el clculo se basa en datos subjetivos ms que objetivos, que el conteo
del dominio de informacin (y otras dimensiones) puede ser dificil de recopilar despus del hecho, y que el PF no tiene significado fisico directo: es slo un nmero.
22.2.3 Reconciliacin de las mtricas LDC y PF

La relacin entre lneas de cdigo y puntos de funcin depende del lenguaje de programacin en que se implementan el software y la calidad del diseo. Varios estudios han intentado relacionar las medidas de PF y LDC. Por ejemplo Albrecth y Gaffney [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 debe estar correlacionada tanto con la cantidad de LDC que se desarrollar como con el esfuerzo de desarrollo necesario.
La tabla 5 siguiente [QSM02J ofrece estimaciones burdas del nmero promedio de l-
neas de cdigo que se requieren para construir un punto de funcin en varios lenguajes de programacin:
Una revisin de estos datos indica que una LDC de C++ proporciona aproximadamente 2.4 veces la "funcionalidad" (en promedio) de una LDC de C. Ms an, una
LDC de Smalltalk proporciona al menos cuatro veces la funcionalidad de una LDC de
un lenguaje de programacin convencional como Ada, COBOL o
c. La utilizacin de la
informacin contenida en la tabla permite "tomar como contrafuego" OON98J el software existente para estimar el nmero de puntos de funcin, una vez que se conozca el nmero total de enunciados del lenguaje de programacin.
Se ha encontrado que las mtricas basadas en puntos de funcin y LDC son indicadoras relativamente precisos del esfuerzo y el costo del desarrollo de software. Sin
embargo, emplear LDC y PF en la estimacin (captulo 23) requiere establecer una lnea de referencia histrica de informacin.
En contexlo del proceso y las mtricas del proyecto, la preocupacin principal la
generan la productividad y la calidad: medidas de la "salida" de desatTollo de software como funcin del esfuerzo y el tiempo aplicados y medidas de la "aptitud para
el uso" de los productos de trabajo obtenidos. Respecto a propsitos de mejora del
proceso y planeacin del proyecto, el inters es histrico. Cul fue la productividad
Es importante notar que "pormenorizar los grandes componentes" se puede interpretar en varias
formas. Los ingenieros de software que trabaan en un en torno de desarrollo orientado a objetos
usan el nmero de clases u objetos como el tamao de mtrica dominante. Una organizacin de mantenimiento puede considerar el tamao del p~cto en t rminos del nmero de pedidos de cambios
de ingeniera (captulo 27). Una organizaan de Sl-'-temas de mtormacin quiz vea el nmero de
procesos comerciales que afecta una apcactn.
Utilizado con permiso de Quantitative Softw are Ma..~ n 1 wwwqsm.com), copyright 2002.
672
PARTE CUATRO GESTIN DE PROYECI'OS DE SOFTWARE
de desarrollo del software en los proyectos pasados? Cul fue la calidad del software
que se produjo? Cmo se pueden extrapolar al presente la productividad y la calidad pasadas? Cmo puede ayudar a mejorar el proceso y planificar nuevos proyectos
con mayor precisin?
Lenguaje de
programacin
Access
Ada
APS
ASP 69
Ensamblador
e
e++
Clipper
COBOL
Cool:Gen/lEF
Culprit
DBose IV
Eosytrieve 1
Excel47
Focus
FORTRAN
FoxPro
Ideal
IEF/Cool:Gen
lnformix
Javo
JovoScripl
JCL
JSP
Lotus Notes
Montis
Mopper
Natural
Orocle
PeopleSoft
Peri
PL/1
Powerbuilder
REXX
RPG 11/111
SAS
Smolltolk
SQL
VBScript36
Visual Bosic
LDC por punto de funcin

Promedio
Mediana
Bajo
Alto
35
154
86
62
337
162
66
38
77
38
51
52
33
46
43
38
15
104
20
32
91
33
29
27
14
JO
47
205
184
127
694
704
178
70
400
180
42
25
31
32
41
63
56
35
52
31
31
53
63
123
25
34
10
24
77
42
26
35
203
180
57
22
27
81
52
35
32
15
22
16
22
4
30
25
250
245
141
217
40
67
31
22
11
263
105
49
41
19
37
27
42
24
33
10
7
50
16
155
49
55
110
32
66
38
42
63
58
91
59
21
71
118
60
30
33
60
78
32
67
61
40
26
40
34
47
83
3 15
109
53
39
77
31
34
75
150
158
CAPTULO 22
Mtm,cAS DE PROCESO v PROYECTO
6 73
22.2.4 Mtricas orientadas a objetos

Las mtricas de proyectos de software convencionales (LDC o PF) se aplican en la
estimacin de proyectos de software orientados a objetos. Sin embargo, estas mtricas no proporcionan suficiente granularidad para la planificacin y los ajustes de esfuerzo que se requieren conforme se itera a lo largo de un proceso evolutivo o incremental. Lorenz y Kidd [LOR94J sugieren el siguiente conjunto de mtricas para proyectos 00:
Nmero de guiones de escenario. Un guin de escenario (anlogo a los casos
de uso estudiados a travs de las partes 2 y 3 de este libro) es una secuencia detallada de pasos que describen la interaccin entre el usuario y la aplicacin. El nmero de guiones de escenario est directamente correlacionado con el tamao de la
aplicacin y con el nmero de casos de prueba que se deben desarrollar para ejercitar el sistema una vez que se construya.
Nmero de clases clave. Las clases clave son los "componentes enormemente independientes" [LOR94) definidos con antelacin en el anlisis orientado a objetos
(captulo 8). 6 Puesto que las clases clave son centrales respecto del dominio del problema, su nmero indica la cantidad de esfuerzo necesario para desarrollar el software. Tambin indican la potencial cantidad de reutilizacin que se aplicar durante el desarrollo del sistema.
Nmero de clases de apoyo. Las clases de apoyo son necesarias en la implementacin del sistema, pero no estn inmediatamente relacionadas con el dominio del
problema. Los ejemplos pueden ser las clases IU, los accesos a bases de datos y las
clases de manipulacin y las de clculo. Adems, las clases de apoyo se pueden desarrollar para cada una de las clases clave. El nmero de clases de apoyo es un indicio de la cantidad de esfuerzo indispensable para desarrollar el software, as! como
un indicio de la potencial cantidad de reutilizacin que se aplicar durante el desarrollo del sistema.
Nmero promedio de clases de apoyo por clase clave. En general, las clases
clave se conocen en etapas iniciales del proyecto. Las clases de apoyo se definen a
lo largo del curso de ste. Si se conociese el nmero promedio de clases de apoyo
por clase clave respecto de un dominio de problema dado, la estimacin (con base
en el nmero total de clases) se sjmplificara mucho. Lorenz y Kidd sugieren que las
aplicaciones con una GUI tienen entre dos y tres veces el nmero de clases de apoyo que las clases clave. Las aplicaciones sin GUI tienen entre una y dos veces el nmero de clases de apoyo que las clases clave.
Nmero de subsistemas. Un subsistema es un agregado de clases que apoyan
una funcin visible para el usuario final de un sistema. Una vez identificados los sub-
En la parte 2 de este libro a las clases clave se les ~fui como clases de anlisis.
674
sistemas es ms fcil extender una planificacin razonable en la cual se haya hectla particin del trabajo entre el equipo del proyecto.
La utilizacin eficiente en un entorno de ingeniera de software orientada a obe
tos requiere recopilar mtricas similares a las anotadas lineas arriba, junto con me
didas del proyecto tales como esfuerzo gastado, errores y defectos descubiertos
modelos o pginas de documentacin producidos. Conforme la base de datos era.:
(despus de completados varios proyectos), las relaciones entre medidas orientad...;
a objetos y medidas de proyecto proporcionarn mtricas que auxilien en la estirr.
cin del proyecto.
22.2.5 Mtricas orientadas a casos de uso

Parecera razonable aplicar el caso de uso7 como una medida de normalizacin 5
milar a la LDC o PF. Como el PF, el caso de uso se define en etapas tempranas .:
proceso de software, lo que permite emplearlo en la estimacin antes de iniciar las z .
tividades significativas de modelado y construccin. Los casos de uso describen
menos indirectamente) funciones y caractersticas visibles al usuario que son requ
tos bsicos para un sistema. El caso de uso es independiente del lenguaje de prog.macin. Adems, el nmero de casos de uso es directamente proporcional al tama
de la aplicacin en LDC, as corno al nmero de casos de prueba que tendrn que J:
searse para ejercitar completamente la aplicacin.
Puesto que los casos de uso pueden crearse con grados de abstraccin amp
mente diferentes, no existe tamao estndar para ellos. Sin una medida estndar aplicaci n corno medida de normalizacin (por ejemplo, esfuerzo empleado por ~
so de uso) es sospechosa. Aunque varios investigadores (por ejemplo, [SMI99l)
intentado obtener mtricas de caso de uso, todava queda mucho trabajo por ha<:8':.
22.2.6 Mtricas de proyectos de ingeniera Web

El objetivo de todos los proyectos de ingeniera Web (parte 3 de este libro) es co~
truir una aplicacin Web (WebApp) que propocione una combinacin de conteru_
y funcionalidad al usuario final. Las medidas y mtricas que se emplean en los p
yectos de ingeniera de software tradicionales son dificiles de traducir directamer
a la WebApp. Incluso, una organizacin de ingeniera Web debe desarrollar una t:
se de datos que le permita valorar su productividad y calidad internas a lo largo ..
varios proyectos. Entre las medidas que se pueden recopilar estn:
Nmero de pginas Web estticas. Las pginas Web de contenido esttico

decir, el usuario final no controla el contenido desplegado en la pgina) son las rr
comunes de todas las caractersticas WebApp. Estas pginas representan una cocplejidad relativa baja y por lo general requieren menos esfuerzo al construirlas Cfw
7 Los casos de uso se estudian a travs de las partes 2 y 3 de este libro.
CAPTULO 22
675
las pginas dinmicas. Esta medida proporciona un indicio del tamao global de la
aplicacin y el esfuerzo que se requiere para desarrollarla.
Nmero de pginas Web dinmicas. Las pginas Web de contenido dinmico

(es decir, las acciones del usuario final generan contenido personalizado que se despliega en la pgina) son esenciales en todas las aplicaciones de comercio electrnico, motores de bsqueda, aplicaciones financieras y muchas otras categoras de WebApp. Estas pginas representan una mayor complejidad relativa y requieren ms esfuerzo al construirlas que las pginas estticas. Esta medida proporciona un indicio
del tamao global de la aplicacin y el esfuerzo requerido para desarrollarla.
Nmero de vinculos internos de pgina. Los vnculos internos de pgina son
punteros que ofrecen un hipervnculo hacia alguna otra pgina Web dentro de la WebApp. Esta medida proporciona un indicio del grado de acoplamiento arquitectnico
dentro de la WebApp. Conforme aumenta el nmero de vnculos de la pgina, tambin lo hace el esfuerzo empleado en el diseo y construccin de la navegacin.
Nmero de objetos de datos persistentes. Una WebApp puede tener acceso

a uno o ms objetos de datos persistentes (por ejemplo. una base de datos o archivo de datos). Conforme el nmero de objetos de datos persistentes crece, tambin lo
hace la complejidad de la WebApp y el esfuerzo para implementarla aumenta proporcionalmente.
Nmero de sistemas externos en inteaz. Con frecuencia las WebApps deben hacer interfaz con aplicaciones comerciales "de cuarto trasero". Conforme crece el requisito para hacer interfaz, la complejidad del sistema y el esfuerzo de desarrollo tambin aumentan.
Nmero de objetos de contenido esttico. Los objetos de contenido esttico
abarcan informacin esttica basada en texto, grfica, video, ariimacin y audio que
se incorporan dentro de la WebApp. En una pgina Web sencilla pueden aparecer
mltiples objetos de contenido esttico.
Nmero de objetos de contenido dinmico. Los objetos de contenido dinmico se generan con base en las acciones del usuario final y abarcan informacin
generada internamente basada en texto, grfica, video, animacin y audio que se incorporan dentro de la WebApp. En una pgina Web sencilla pueden aparecer mltiples objetos de contenido dinmico.
Nmero de funciones ejecutables. Una funcin ejecutable (por ejemplo, un
guin o applet) ofrece cierto servcio computacional al usuario final. Conforme aumenta el nmero de funciones ejecutables, tambin aumentan los esfuerzos de modelado y construccin.
Cada una de estas medidas se puede determinar en una etapa relativamente temprana del proceso de ingeniera Web.
Por ejemplo, es posible definir una mtrica que refleje el grado de personalizacin
de usuario final que se requiere para la WebApp ) correlacionarla con el esfuerzo
676
PARTE CUATRO
empleado en el proyecto de !Web o los errores descubiertos conforme se llevan a cabo revisiones y pruebas. Para lograr esto, se define
Nsp
= nmero de pginas Web estticas
Ndp
= nmero de pginas Web dinmicas
Entonces,
ndice de personalizacin, e= Ndpl(Ndp + Nsp)
El valor de e vara de o a 1. Conforme e crece, el nivel de personalizacin de la WebApp se vuelve un conflicto tcnico significativo.
Es posible calcular y correlacionar mtricas similares de aplicaciones Web ar
medidas del proyecto, tales como el esfuerzo empleado, los errores y defectos des
cubiertos y los modelos o pginas de documentacin producidos. Conforme la base
de datos crece (despus de que varios proyectos se han completado), las relaciones
entre las medidas WebApp y las medidas del proyecto proporcionarn indicadores
que auxilien en la estimacin del proyecto.
~ Mtricas del proyecto y el proceso
liiiiiiii
Objetivo: Ayudar en lo definicin, recopila-
cin, evaluacin y reporte de medidos y mtricos de software.
Mecnica: Cado herramienta vara en cuanto o su aplicacin, pero todos ofrecen mecanismos poro recopilar y
evaluar datos que conduzcan al clculo de mtricos de
software.
Herramientas representativas
Function Pont WORKBENCH, desarrollado por Chorismo
tek (www.chorismatek.com.au), ofrece uno amplia va
riedad de mtricos orientados a PF.
MetricCenter, desarrollada por Distributive Software

(www.distributive.com), soporto recopilacin automoti
zodo de datos, anlisis, formateo de grficos, genera
cin de reportes y otros toreos de medicin.
PSM lnsght, desarrollado por Procticol Software and Sys

tems Measurement (www.psmsc.com), auxilio en la
creacin y subsiguiente anlisis de una base de datos
de medicin del proyecto.
SL/M too/ set, desarrollado por QSM {www.qsm.com), proporciona un completo conjunto de mtricos y herra
mientas de estimacin.
SPR too/ sel, desarrollado por Software Productivity Re

seorch (www.spr.com), ofrece uno coleccin detallado
de herramientas orientados a PF.
TychoMefrcs, desarrollado por Predicate Logic, lnc. (www

predicote.com), es una suite de herramientas pora ges
tionar recopilacin de mtricas y reportes.
La meta primordial de la ingeniera del software es producir un sistema, aplicacir
o producto de alta calidad dentro de un marco temporal que satisfaga una necesida.:.
Las herramientas anotadas aqu son una muestra de esta categora. En la mayora de los casos
CAPTULO 22
MTRICAS DE PROCESO Y PROYECIO
677
del mercado. El logro de esta meta requiere que los ingenieros de software apliquen
mtodos eficaces acoplados con herramientas modernas dentro del contexto de un
proceso de software maduro. Adems, un buen ingeniero de software (y los buenos
gestores de ingeniera del software) debe medir si se lograr la alta calidad.
Las mtricas privadas reunidas por los ingenieros de software individuales se asimilan con los resultados ofrecidos en el mbito del proyecto. Aunque se pueden reunir muchas medidas de calidad, el impulso primario en el mbito del proyecto es medir los errores y defectos. Las mtricas derivadas de estas medidas proporcionan un
indicio de la efectividad de la garanta de la calidad del software y de las actividades
de control tanto de los individuos como del grupo.
Las mtricas como los errores en el producto de trabajo (por ejemplo, requisitos
o diseo) por punto de funcin, errores descubiertos por hora de revisin, y los errores descubiertos por hora de prueba ofrecen una visin de la eficacia de cada una de
las actividades implicadas en la mtrica. Los datos de error tambin se pueden emplear en el clculo de la eficacia en la eliminacin de defectos (EED) para cada actividad del marco de trabajo del proceso. La EED se estudia en la seccin 22.3.2.
22.3. l
Medicin de la calidad
Aunque existen muchas medidas de la calidad del software,9 la correccin, la facilidad de mantenimiento, la integridad y la facilidad de uso ofrecen indicadores tiles
para el equipo del proyecto. Gilb [GII..88] sugiere definiciones y mediciones para cada una de ellas.
Correccin. Un programa debe operar correctamente o proporcionar poco valor para sus usuarios. La correccin es el grado en que el software desempea la funcin para la que fue creado. La medida ms comn para la correccin es defectos
por KLDC, donde un defecto se define como una falta comprobada de concordancia
con los requisitos. cuando se considera la calidad global de un producto de software, los defectos son los problemas que reporta un usuario del programa despus de
que ste se liber para el uso general. Para los propsitos de la evaluacin de la calidad, los defectos se cuentan sobre un periodo estndar, usualmente un ao.
Facilidad de mantenimiento. El mantenimiento del software justifica ms esfuerzos que cualquier otra actividad de la ingeniera del software. La facilidad de
mantenimiento es la sencillez con la que un programa puede corregirse si se encuentra un error, adaptarse si su entorno cambia, o mejorar si el cliente desea un
cambio en los requisitos. No existe fonna de medir directamente la facilidad de mantenimiento; en consecuencia, se deben emplear medidas indirectas. Una simple medida orientada al tiempo es el tiempo medio de cambio (TMC), el tiempo que toma
analizar el cambio solicitado, disear una modificacin apropiada, implementar el
En el capitulo 15 se present una discusin detallada de los factores que influyen en la calidad del
software y las mtricas que se pueden usar para valorar la calidad del software.
678
cambio, probarlo y distribuir el cambio a todos los usuarios. En promedio, los programas susceptibles de mantenimiento tendrn un TMC bajo (para tipos de cambios
equivalentes) que los programas que no lo son.
Integridad. La integridad del software se ha vuelto cada vez ms importante e

la edad de los ciberterroristas y hackers. Este atributo mide la habilidad de un sistema para resistir ataques (tanto accidentales como intencionales) a su seguridad. Le
ataques se pueden realizar en los tres componentes del software: programas, data;
y documentos.
La medicin de la integridad requiere definir dos atributos adicionales: amenaz1
y seguridad. Amenaza es la probabilidad (que puede estimarse o deducirse de evider
cia emprica) de que un ataque de un tipo especifico ocurrir dentro de un tiem!)'
dado. seguridad es la probabilidad (que puede estimarse o deducirse de evidenC'
emprica) de que se repela el ataque de un tipo especifico. Entonces, la integridad e!
un sistema se puede definir como:
integridad
=I
- (amenaza
(1 - seguridad))
Por ejemplo. si la amenaza (la probabilidad de que un ataque ocurrir) es 0.2!l J

la seguridad (la posibilidad de repeler un ataque) es 0.95, la integridad del sistema s
0.99 (muy elevada). Si, por otra parte, la probabilidad de amenaza es o.so y la p~
bilidad de repeler un ataque es slo 0.25, la integridad del sistema es 0.63 (inacepk
blemente baja) .
Facilidad de uso. Con frecuencia, un programa que no es fcil de usar est co

denado al fracaso, incluso si las funciones que realiza son valiosas. La facilidad
uso es un intento por cuantificar la sencillez de la aplicacin al utilizarla y se pue
medir en trminos de las caractersticas presentadas en el captulo 12.
Los cuatro factores apenas descritos slo representan una muestra de los que
han propuesto como medidas para la calidad del software. El capitulo 15 conside
este tpico con mayor detalle.
22.3.2 Eficacia en la eliminacin de defectos

Una mtrica de calidad que ofrece beneficios tanto en el mbito del proyecto cor,.
en el del proceso es la eficacia en la eliminacn de defectos (EED) . En esencia, la EE."J
es una medida de la habilidad de filtrar las actividades de la garanta de cualidad
de control conforme se aplica a travs de todas las actividades del marco de traba
del proceso.
Cuando se considera un proyecto como un todo, la EED se define de la mane
siguiente:
EED = E/(E + D)
donde E es el nmero de errores encontrados antes de entregar el software al usu.;
rio final, y D es el nmero de defectos encontrados despus de la entrega.
CAPTULO 22
679
El valor ideal de la EED es 1. Esto es: no se encuentra defecto alguno en el software. En realidad, D ser mayor que O, pero el valor de EED todavia puede acercarse a
l. Conforme E aumenta (para un valor dado de D), el valor global de EED comienza
a acercarse a 1. De hecho, conforme E aumenta, es probable que el valor final de D
disminuya (los errores se filtran antes de que se conviertan en defectos}. Si se utiliza como una mtrica que proporciona un indicador de la habilidad de filtrado de las
actividades de control y aseguramiento de la calidad, EED alienta a un equipo de
proyecto de software a instituir tcnicas para encontrar tantos errores como sea posible antes de la entrega.
La EED tambin se puede aplicar en el proyecto para valorar la habilidad de un
equipo de encontrar errores antes de que pasen a la siguiente actividad del marco de
trabajo o a la siguiente tarea en la ingenieria del software. Por ejemplo, la tarea de anlisis de requisitos produce un modelo de anlisis que se revisa para encontrar y corregir errores. Aquellos errores que no se encuentran durante la revisin del modelo de anlisis pasan al diseo (donde pueden o no encontrarse}. Cuando se aplica en
este contexto la EED se redefine como
EED; = El(E; +E + 1)
donde E1 es el nmero de errores encontrado durante la actividad i de ingeniera de
software y E; . 1 es el nmero de errores encontrado durante la actividad i + 1 de ingeniera del software que se puede seguir para llegar a errores que no fueron descubiertos en la actividad i de ingeniera del software.
Un objetivo de calidad para un equipo de software (o un ingeniero de software individual} es lograr una EED1 que se acerque a 1. Esto es: los errores deben filtrarse
antes de que pasen a la siguiente actividad.
lamia: Me gusta la EED como mtrico, 1

demos emplearta en todo el proyecto.
aplicarlo C01dor ,,ie nos movamos de uno
mora, da trabao a la siguiente. Eso noa
ei1CU1D1 errores en cado poso
680
PARTE CUATRO
La mayora de los desarrolladores de software todava no miden y, por des~
muchos tienen poco deseo de comenzar. Como se ha sealado en este captu.~

problema es cultural. El intento de recopilar medidas donde nadie lo ha hecho en e.
sado con frecuencia genera resistencia. "Por qu tenemos que hacer esto?" pn 6
ta un gestor de proyecto acosado. "No le veo el caso", se queja un profesiona:
exceso de trabajo.
En esta seccin se consideran algunos argumentos para las mtricas de sofu
y se presenta un enfoque para instituir un programa de recopilacin de mtricas
una organizacin de ingeniera del software. Pero antes de comenzar, conviene e
siderar [GRA87] algunas palabras de cordura de Grady y Caswell:
Algunas de las cosas que describimos aqu sonarn bastante sencillas. En realidad, sn
embargo, el establecimiento de un programa de mtricas de software exitoso en el Jnbo
to de la compaia es un trabajo duro. Cuando decimos que se debe esperar al menos tres
aos antes de que estn disponibles tendencias organizacionales amplias, se obtiene ~guna idea del mbito de tal esfuerzo.
Vale la pena prestar atencin a la advertencia que sugieren estos autores, pero
beneficios de la medicin son tan convincentes que el trabajo duro vale la pena
22.4.1 Argumentos para las mtricas del software

Por qu es importante medir el proceso de ingeniera del software y el produ..
(software) que elabora? La respuesta es relativamente obvia. Si no se mide, no e _
te una forma real de determinar si se est mejorando. Y si no se mejora, se est ~
dicto.
Al cuestionar y evaluar la productividad y las medidas de calidad, un equipo
software (y su gestin) puede establecer metas significativas para mejorar el proc.;
so del software. En el captulo I se apunt que el software es un tema comercial ~
CAPTULO 22
681
tratgico para muchas compaas. S el proceso con el cual se desarrolla puede me

jorarse, se producir un impacto directo en lo sustancial. Pero para establecer ob
tivos de mejora es preciso comprender el estado actual del desarrollo de software
Por lo tanto, la medicin se emplea para establecer una lnea base de proceso a ~r
lir de la cual se evalan las mejoras.
"Glstionamos las cosas mediante los nmeros en muchos aspectos de nuestros vidas.. Estos nmeros nos brnla
padlW de juicio y nos ayudan a dirigir nuestros acciones.
Los rigores cotidianos del trabajo del proyecto de software dejan poco tiempo para ejercitar el pensamiento estratgico. Los gestores de proyectos de software estn
preocupados con temas ms concretos (aunque igualmente importantes) desarrollar estimaciones de proyecto significativas, producir sistemas de alta calidad, tener
el producto en circulacin a tiempo. Si se emplea la medicin para establecer una linea base del proyecto, cada uno de dichos temas se vuelve ms manejable. Ya se ha
mencionado que la lnea base sirve como fundamento para la estimacin Adicional
mente, la recopilacin de mtricas de calidad permite que una organizacin sintonice" su proceso de software para remover las causas "poco vitales" de los defectos
que tienen el mayor impacto sobre el desarrollo del software. 10
22.4.2 Establecimiento de una lnea base

Con el establecimiento de una lnea base de mtricas se obtienen beneficios en los
mbitos del proceso, del proyecto y del producto (tcnico) . Incluso la informacin
que se recopila no necesita ser fundamentalmente diferente. Las mismas mtr :as
pueden servir a muchos maestros. La lnea base de mtricas consiste de datos re :opilados en proyectos previos de desarrollo de software y pueden ser tan simples ..orno la tabla presentada en la figura 22.2 o tan complejos como una base de datos detallada que contiene docenas de medidas de proyectos y las mtricas derivadas de
stos.
Para ser un auxiliar eficaz en el proceso de mejora o de costo y esfuerzo, los ct...os
de la lnea base deben tener los siguientes atributos: l) los datos deben ser razonablemente precisos: se deben evitar las "conjeturas" acerca de los proyectos pasa~
2) los datos deben recopilarse para tantos proyectos como sea posible; 3) las md1das deben ser consistentes, por ejemplo una linea de cdigo debe interpretarse c.,nsistentemente a travs de todos los proyectos para los que se recopilan los datos 4)
las aplicaciones deben ser similares al trabaJo que se estimar: tiene poco sentdo
emplear una lnea base en un trabajo de sistemas de informacin en bloque para estimar una aplicacin anidada en tiempo real.
10
En el capitulo 26 se tratan con detalle estas ideas, formalizadas en un enfoque denominado gar,m-
ta estodistJCa de calidad del scjtvvare
682
ifrhifi
Proceso de
recopilacin
de mtricas
de software.
Evaluacin
de mtricos
~
~~
c&v1
los datos de mtricos
ele tineo hose deben
recopilorse de uno gran
muestro representativo
de proyectos de
software previos.
Si se est comen
zondo ore<opilor
dolos de mtricos,
rl/QJrdese mantenerlos simples. Si los
lbs abroman los
tWefZDS de mtricas
tm5!JII.
22.4.3 Recopilacin, clculo y evaluacin de mtricas

En la figura 22.3 se ilustra el proceso con el que se establece una linea base de mc:tricas. De manera ideal, los datos necesarios para hacerlo se han recopilado confo:
me se avanza. Por desgracia, esto rara vez es el caso. En consecuencia, la recopila
cin de datos requiere una investigacin histrica de los proyectos previos para reconstruir los datos requeridos. una vez que se han recopilado las medidas (incuestionablemente el paso ms dificil) es posible calcular las mtricas. Dependiendo dela amplitud de las medidas recopiladas, las mtricas pueden abarcar una amplia ga
ma de mtricas orientadas a la aplicacin (por ejemplo, LDC, PF, orientada a objetos
WebApp). as como otras orientadas a la calidad y al proyecto. Finalmente, las metricas deben evaluarse y aplicarse durante la estimacin del trabajo tcnico, el cortrol del proyecto y la mejora del proceso. La evaluacin de las mtricas se centra e:las razones subyacentes de los resultados obtenidos y produce un conjunto de in<icadores que guan el proyecto o proceso.
La gran mayora de las organizaciones de desarrollo de software tiene menos de 2'

empleados. Es irracional, y en la mayora de los casos irreal, esperar que tales organizaciones desarrollarn programas detallados de mtricas de software. Sin embargo, es razonable sugerir que las organizaciones de software de todos los tamao.
miden y luego emplean las mtricas resultantes para ayudar a mejorar sus proceso:;
de software locales y la calidad y la puntualidad de los productos que elaboran.
Un enfoque de sentido comn respecto de la implementacin de cualquier actividad relacionada con el proceso de software es mantenerlo simple, personalizarlo para
satisfacer las necesidades locales y asegurarse de que agrega valor. En los prrafos
CAPTULO 22
MTRlCAS DE PROCESO Y PROYECTO
683
que siguen se examina cmo estos lineamientos se relacionan con las mtricas para pequeos negocios. 1:
"Mantenerlo simple" es una directriz que funciona razonablemente bien en muchas actividades. Pero, cmo se deduce un conunto "simple" de mtricas de software que aun as proporcione valor, y cmo se garantiza que dichas mtricas simples satisfarn las necesidades de una organizacin de software particular? Un buen
comienzo consiste en enfocarse no sobre las mediciones sino ms bien sobre los re
sultados. Al grupo de software se le entrevista para definir un objetivo sencillo que
requiere mejora. Por ejemplo, "reducir el tiempo para evaluar e implementar los
cambios solicitados". Una organizacin pequea puede seleccionar el siguiente conjunto de medidas que se recopilan con facilidad.
Tiempo (horas o das) transcurrido desde el momento en que se hizo una sohcitud hasta que la evaluacin est completa, leo/a
Esfuerzo (persona-horas) para realizar la evaluacin, Tl'\<11.
Tiempo (horas o das) transcurrido desde que se completa la evaluacin hasta
la asignacin del pedido de cambio al personal, t, ,1.
Esfuerzo (persona-horas) requerido para hacer el cambio, Tcamh,,,.
Tiempo requerido (horas o dias) para hacer el cambio, t,..
Errores descubiertos durante el trabajo para hacer el cambio, Ecamt>,o
Defectos descubiertos despus de que el cambio es liberado a la base de
clientes, Dcamt>lo
Una vez que se han recopilado dichas medidas para varios cambios solicitados
es posible calcular el tiempo transcurrido total promedio desde que el cambio se solicit hasta la implementacin del cambio y el porcentaje del tiempo transcurndo absorbido por la cola de espera inicial, la evaluacin y la asignacin y la implementac
del cambio. De igual modo, es posible determinar el porcentaje del esfuerzo que re
quieren la evaluacin y la implementacin. Estas mtricas se evalan en el conto.1
"y D, nJ:>u Los porcentajes proporcionan conocim1en

de los datos de calidad, E
detallado de dnde se vuelve lento el proceso de solicitud de cambio y conduce a pa
sos de mejora del proceso para reducir t..,:.,, Te.vi, t, ,1, T,1mN,, o Emmh"' Adems la efica
cia en la de eliminacin de defectos se puede calcular como
EED = E mNol(E".0,-ibic + Drumt,w)
EED se compara con el tiempo transcumdo y el esfuerzo total para determinar el im
pacto de las actividades de aseguramiento de lil calidad en el tiempo y el esfuerzo
requeridos para realizar un cambio.
11 Esta exposicin es igualmente relevante para los equ pos de sollware que han adoptado un procc
so de desarrollo de software , gil (capitulo 4
684
El Software Engineering Institute (SEi) ha elaborado una gua detallada [J>AR96] para establecer un programa de mtricas de software "dirigido por metas". La gua Sugiere los siguientes pasos:
fOiH5rn1
AGlile fiw 6oal Ckw&n
'SdtwtnAfeasmmelll
se pi,ede desa,p de:
WWlllr..i.cm .
1.
Identificar los objetivos de la empresa.
2.
Identificar lo que se quiere conocer o aprender.
3.
Identificar los subobjetivos.
4.
Identificar las entidades y atributos relacionados con los objetivos secundarios
5.
Formalizar los objetivos de la medicin.
6.
Identificar preguntas cuantificables y los indicadores relacionados que se emplearn como apoyo para l ograr los objetivos de sus mediciones.
7.
Identificar los elementos de datos que se recopilarn para construir los indicadores que ayudarn a responder las preguntas.
8.
Definir las medidas que se emplearn y hacer que estas definiciones sean
operativas.
9.
Identificar las acciones que se tornarn para implementar las medidas.
1 O.
Los mtcos de
softwore que se elijan

deben estor basados
en los metas de
negocios y tcnicos
que se deseon lograr.
Preparar un plan para implementar las medidas.
Una exposicin detallada de estos pasos mejor se deja para el libro del SEi. Sin embargo, bien vale la pena dar un breve vistazo a los puntos clave.
Puesto que las funciones comerciales de apoyo del software diferencian los sistemas o productos basados en computadora, o actan como un producto en si mismo
las metas definidas para las empresas casi siempre pueden seguirse hacia abajo hasta metas especficas al nivel de la ingeniera del software. Por ejemplo, considrese
una compaa que fabrica avanzados sistemas de seguridad para el hogar que tiene
contenido de sonware sustancial. Al trabajar como equipo, la ingeniera del software y los gestores del negocio pueden confeccionar una lista de metas priori zadas de!.
negocio:
l.
Mejorar la satisfaccin de los clientes con los productos.
2.
Hacer que los productos sean ms fciles de usar.
3.
Reducir el tiempo que toma poner un producto en el mercado.
4.
Simplificar el soporte para los productos.
5.
Mejorar la obtencin global de utilidades.
La organizacin de software examina cada meta de negocios y pregunta: Qu acti-
vidades se gestionan o ejecutan y qu se quiere mejorar de dichas actividades? Para

responder estas preguntas el SEi recomienda la creacin de una "lista entidad-pregunta" en la que se anoten todas las cosas (entidades) dentro del proceso de softwa-
CAPTULO 22
685
MmICAS DE PROCESO Y PROYICTO
re que se gestionan o en las que influye la organizacin de software. Los ejemplos

de entidades incluyen recursos de desarrollo, productos de trabajo, cdigo fuente,
casos de prueba, solicitudes de cambio, tareas de ingeniera del software y planificaciones. Para cada entidad en la lista el personal de software desarrolla un conjunto
de preguntas que evalan caractersticas cuantitativas de la entidad (por ejemplo, tamao, costo, tiempo de desarrollo). Las preguntas que se derivan de la creacin de
una lista entidad-pregunta conducen a la derivacin de un conjunto de subobjetivos
que se relacionan directamente con las entidades creadas y las actividades realizadas como parte del proceso del software.
Considrese la cuarta meta: "Simplificar el soporte para los productos". Para esta
meta se puede derivar la siguiente lista de preguntas [PAR96):
La solicitud de cambio del cliente contiene la informacin requerida para
evaluar adecuadamente el cambio y luego implementarlo en una forma oportuna?
Cun grande es el registro de peticin de cambio?
El tiempo de respuesta para fijar los bugs es aceptable con base en las necesidades del cliente?
Se sigue el proceso de control de cambios (captulo 27)?
Los cambios de alta prioridad se implementan en forma oportuna?
Con base en estas preguntas la organizacin de software puede deducir el siguiente
subobjetivo: mejorar el desempeo del proceso de gestin de cambio. Se identifican las
entidades y los atributos del proceso de software relevantes respecto del subobjetivo, y se delinean las metas de medicin asociadas con ambos elementos.
El SEi [PAR96] proporciona una guia detallada para los pasos 6 al 1O de su enfoque de medicin orientado a objetivos. En esencia, se aplica un proceso de refinamiento paso a paso en el que los objetivos se refinan en preguntas que posteriormente se refinan en entidades y atributos que entonces se refinan en mtricas.
Establec1miento de un programa de mtricas

El Software Productivity Center (www.spc.ca)
sugiere un enfoque de ocho pasos para
er 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.6.
e-ifoque se resume a continuacin.
Entender el proceso de software existente.
Se definen las actividades del marco de trabajo
(captulo 2).
Se describe la informacin de entrada para cada
actividad.
Se definen los tareas asociadas con coda

actividad.
Se anotan las funciones de aseguramiento de la
calidad.
Se hace uno lista con los productos de trabajo
producidos.
2. Defi,, r los objetivos que se logrorn mediante el
~
:--ier1o de un programo de mtricas.
~
: mejorar la precisin de la estimacin,
mejorar la colidod del producto.
686
PARTE CUATRO
3. Identificar las mtricos requeridos paro lograr los

objetivos.
Se definen los preguntas que deben responderse;
por ejemplo, cuntos errores encontrados en
una actividad de morco de trabajo pueden
seguirse hasta lo actividad del morco de trabajo
precedente?
Crear medidos y mtricos que sern recopilados y
calculados.
Qu mecanismos de validacin se aplican poro

garantizar que los datos sean correctos?
6. Adquirir herramientas adecuados poro apoyar lo
recopilacin y evaluacin.
7.
Establecer uno base de datos de mtricos.

Se establece lo complejidad relativa de lo base de
datos.
Se explora el empleo de herramientas
relacionados (par ejemplo, un almacn SCM,
captulo 27).
Se evalan los productos de base de datos
existentes.
8.
Definir mecanismos de realimentacin adecuados.
4. Identificar los medidos y mtricos que sern

recopilados y calculados.
5. Establecer un proceso de recopilacin de medidos

respondiendo los siguientes preguntas:
Cul es lo fuente de los mediciones?
las herramientas se pueden emplear en lo
recopilacin de los datos?
Quin es responsable de lo recopilacin de
datos?
Cundo se recopilan y registran los datos?
Cmo se almacenan los datos?
22, 7
Quin requiere informacin de mtricos en

marcho?
Cmo se entregar la informacin?
Cul es el formato de lo informacin?
Uno descripcin considerablemente ms detallado de eslos
ochos posos se puede descargar de
http://www.spc.co/resources/ metrics/.
REsuyEN
Las mediciones permiten que los gestores y profesionales mejoren el proceso~
software; auxilien en la planificacin, seguimiento y control de un proyecto de se
ware; y evalen la calidad del producto (software) que se produce. Las medidas alributos especficos del proceso, proyecto y producto se utilizan para calcular m~
tricas de software. Dichas mtricas se pueden analizar para ofrecer indicadores q
guen las acciones de gestin y tcnica.
Las mtricas del proceso permiten que una organizacin adopte una visin estr
tgica al proporcionar informacin detallada de la eficacia de un proceso de soth _
re. Las mtricas de proyecto son tcticas; permiten que un gestor de proyecto ada;-te el flujo de trabajo del proyecto y un enfoque tcnico realista en trminos de tiempLas mtricas orientadas tanto al tamao como a la funcn se aplican a Jo larg
de toda la industria. Las mtricas orientadas al tamao emplean la lnea de cd .,,
como un factor de normalizacin para otras medidas como persona-mes o defect1..
El punto de funcin se deduce de las medidas del dominio de la informacin y de u;valoracin subjetiva de la complejidad del problema. Adems, se pueden utilizar ~.:;...
mtricas orientadas a objetos y las mtricas de aplicacn Web.
Las mtricas de calidad del software, como las mtricas de productividad, se e"
focan sobre el proceso, el proyecto y el producto. Al desarrollar y analizar una lnc:
CAPTULO 22 MTRICAS DE PROCESO Y PROYEC'!O
687
base de mtricas para la calidad una organizacin puede corregir aquellas reas del
proceso de software que causan defectos de soltware.
La medicin resulta en cambios culturales. La recopilacin de datos, el clculo y
el anlisis de mtricas son los tres pasos que preciso implementar para comenzar un
programa de mtricas. En general, un enfoque orientado a objetivos ayuda a que una
organizacin se enfoque en las mtricas correctas para su negocio. Al crear una lnea base de mtricas -una base de datos que contiene mediciones de proceso y
producto- los ingenieros de soltware y sus gestores pueden comprender mejor el
trabajo que hacen y el producto que elaboran.
[ALB83] Albrecht, A. J. y J. E. Gaffncy, "Software Function, Source Unes of Code and Development Effort Prediction. A Software Science Validation", en IEEE n-ans. Sojlware Engineering,
noviembre de 1983, pp. 639-648.
[B0E8 IJ Boehm, B., Sojlware Engineering Economics, Prentce-Hall, 1981.
[GRA87) Grady, R. B. y D. L. CasweU, Sojlware Metrics: Establishing a Company-Wide Program,
Prentice-Hall, 1987.
[GRA92] Grady, R. G., Practica/ Sojlware Metrics Jor Project Management and Process lmprovement,
Prentce-Hall, 1992.
[GIL88) Glb, T., Principies ofSojlware Project Management, Addison-Wesley, 1988.
[HET93] Hetzel, W. 1 Making Sojlware Measurement Work, QED Publishing Group, 1993.
{HUM95] Humphrey, W., A Disciplinefor Sojlware Engineering, Addison-Wesley, 1995.
[IEE931 IEEE Sojlware Engneering Standards, Standard 610.12-I 990, pp. 47-48.
U0N86J Jones, C., Programming Productivity, McGraw-Hill, 1986.
[JON91J Jones, c., Applied Sojlware Measurement, McGraw-Hill, 1991.
(JON98] Jones, C., Estimating Sojlware Costs, McGraw-Hill, 1998.
[LOR94J Lorenz, M. y J. Kidd, Object-Oriented Sojlware Metrics, Prentice-Hall, 1994.
[PAR96) Park, R. E., W. B. Goethert y W. A. Florac, Goal Driven Sojlware Measurement -A Guidebook, CMU/SEl-96-BH-002, Software Engineering Inslitute, camegie Mellon University,
agosto de 1996.
tPAU94] Paulish, D. y A. Carleton, "Case Studies of Software Process Improvement Measurement", en Computer, vol. 27, nm. 9, septiembre de 1994, pp. 50-57.
(QSM02) "QSM Function Point Language Gearing Factors", Versin 2.0, Quantitative Software
Management, 2002, http://www.qsm.com/ FPGearing.html.
[RAG95] Ragland, B., "Measure, Melric or lndicator: What's the Difference?", en Crossta/k, vol. 8,
nm. 3, marzo de 1995, pp. 29-30.
[SMl99J Smith, J., "The Estimation of Effort Based on Use-Cases", un artculo de Rational Corporation, 1999, se puede descargar de http://www.rational.com/products/rup/whitepapers.jsp.
22.1. Descrbir con palabras propias la diferencia entre mtricas del proceso y del proyecto.
22.2. Por qu algunas mtricas de software deben conservarse "privadas"? Ofrecer ejemplos
de tres mtricas que deban ser privadas. Ofrecer ejemplos de tres mtricas que deban ser pblicas.
22.3 . Qu es una medida indirecta y por qu tales medidas son comunes en el trabajo de mtricas del software?
22.4 . Grady sugiere un conjunto de reglas de enqueta ara las mtricas de soflware. El lector
puede agregar tres reglas ms a las menaonadas c:o la seccin 22.1. 1?
688
PARTE CUATRO GESTIN DE PROYECTOS DE SOFIWARE
22.S El equipo A encontr 342 errores durante el proceso de ingeniera del software previo a
la liberacin. El equipo B encontr 184 errores. Qu medidas adicionales tendran que realizar
los proyectos A y B para determinar cul de los equipos elimin los errores de manera ms eficiente? Qu mtricas podran proponerse para ayudar a realizar la determinacin? Qu datos
histricos pueden ser tiles?
22.6. Presentar un argumento contra las lneas de cdigo como medida para la productividad
de software. El caso se sostiene cuando se consideran docenas o cientos de proyectos?
22.7. Calcular el valor de punto de funcin para un proyecto con las siguientes caractersticas
de dominio de informacin:
Nmero
Nmero
Nmero
Nmero
Nmero
de entradas externas: 32
de salidas externas: 60
de consultas externas: 24
de archivos lgicos internos: 8
de archivos de interfaz externos: 2
Suponer que todos los valores de ajuste de complejidad son promedios. Utilizar el algoritmanotado en el captulo 15.
22.8. Emplear la tabla presentada en la seccin 22.2.3 para elaborar un argumento contra
utilizacin del lenguaje ensamblador basado en la funcionalidad entregada por enunciado d.:
cdigo. Vase de nuevo la tabla y comentar por qu C++ presentara una mejor alternativa que e
22.9. El software utilizado para controlar una fotocopiadora requiere 32 000 LDC de C y 4 2"
lneas de Smalltalk. Estimar el nmero de puntos de funcin para el software dentro de la ro
piadora.
22.1 O. Un equipo de ingeniera Web ha construido una WebApp de comercio electrnico <rcontiene 145 pginas individuales. De estas pginas 65 son dinmicas; esto es, se generan c.
manera interna con base en la entrada del usuario final. Cul es el ndice de personalizac:k:"",
para esta aplicacin?
22.11. Una WebApp y su entorno de soporte no han sido completamente reforzados con.."""'.I
ataques. Los ingenieros Web estiman que la probabilidad de repeler un ataque slo es del 30 :-::ciento. El sistema no contiene informacin sensible o controversia!, as que la probabilidad ..
amenaza es de 25 por ciento. Cul es la integridad de la WebApp?
22.12. En la conclusin de un proyecto que utiliz el Proceso Unificado (Captulo 3) se del.e"
min que 30 errores se encontraron durante la fase de elaboracin, y 12 errores hallados dUra:"
te la fase de construccin podan seguirse hasta errores que no fueron descubiertos en la Ca:..
de elaboracin. Cul es la EED para estas dos fases?
22. 13. un equipo de software entrega un incremento de software a los usuarios finales. ts:.descubren ocho defectos durante el primer mes de uso. Antes de la entrega, el equipo de sa'
ware encontr 242 errores durante las revisiones tcnicas formales y todas las tareas de pn...
ba. Cul es la EED global para el proyecto?
La mejora del proceso de software (MPS) ha recibido una cantidad significativa de atencin d
rante las dos dcadas pasadas. Dado que la medicin y las mtricas de software son clave p&:
mejorar exitosamente el proceso de software, muchos libros acerca de la MPS tambin tratan
mtricas. Las fuentes valiosas de informacin acerca de las mtricas de procesos incluyen:
Burr, A. y M. Owen, Stalistical Methods for Software Qualify, lnternational Thomson Puh
hing, 1996.
El Emam, K. y N. Madhavji (eds.), Elements of Software Process Assessment and lmproveme:
IEEE Computer Society, 1999.
CAPTULO 22
689
w. A. y A. D. carleton, Measunng lhe Sojhvare Process: Statistical Process Control Jor

Software Process Improvement, Adclison-Wesley, 1999.
Garmus, D. y D. Herron, Measuring the Software Process: A Practica/ Guide to FUnctiona/ Measurements, Prentice-Hall, 1996.
Humphrey, W., Introduction to the Team Software Process, Addison-Wesley/Longman, 2000.
Kan, S. H., Metrics and Models in Software Qua/ity Engineering, Addison-Wesley, 1995.
McGarry y sus colegas (Practica/ Software Measurement, Addison-Wesley, 2001) presentan consejos a profundidad para valorar el proceso de software. Haug y sus colegas (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, AddisonWesley, 1999) y Fenton y Pleeger (Software Metrics: A Rigorous and Practica/ Approach, revisado,
Florac,
Brooks/Cole Publishers, 1998) tratan cmo se pueden emplear las mtricas de sofiware para
proporcionar los indicadores necesarios para mejorar el proceso de software.
Putnam y Myers (Five Core Metrics, Dorset House, 2003) estudian una base de datos de ms
de 6 000 proyectos de software para demostrar cmo cinco mtricas centrales - tiempo, esfuerzo, tamao, confiabilidad y productividad de proceso- se pueden emplear para controlar los
proyectos de software. Maxwell (Applied Statistics for Software Managers, Prentice-Hall, 2003)
presenta tcnicas para analizar datos del proyecto de sofiware. Munson (Software Engineering
Measurement, Auerbach, 2003) estudia un amplio abanico de temas de medicin de ingeniera
del software. Jones (Software Assessments, Benchmarks and Bes/ Practices, Addison-Wesley,
2000) describe tanto medidas cuantitativas como factores cualitativos que ayudan a una organizacin a valorar sus procesos y prcticas de sofiware. Garmus y Herron (Function Point Analysis: Measurement Practicesfor Successful Software Projects, Addison-Wesley, 2000) examinan las
mtricas de proceso con nfasis en el anlisis de los puntos de funcin .
Lorenze y Kidd (LOR94J y DeChampeax (Object-Oriented Deve/opment Process and Me/res,
Prentice-Hall, 1996) consideran el proceso 00 y describen un conjunto de mtricas para valorarlo. w.hitmire (Object-Oriented Design Measurement, Wiley, 1997) y Henderson-Sellers (ObjectOrienled Metrics: Measures of Complexity, Prentice-Hall, 1995) se enfocan en las mtricas tcnicas para el trabajo 00, pero tambin consideran medidas y mtricas que se pueden aplicar en
el mbito del proceso y del producto.
Se ha publicado relativamente poco acerca de las mtricas para el trabajo de ingeniera Web.
Sin embargo, Stem (Web Meics: Proven Methods for Measuring Web Site Success, Wiley, 2002),
lnan y Kean (Measuring the Success of Your Website, Longman, 2002) y Nobles y Grady (Web Site
Analysis and Reporting, Premier Press, 2001) abordan las mtricas Web desde una perspectiva de
negocios y de marketing.
Lo ms reciente en la investigacin en el rea de mtricas lo resume el IEEE (Symposium on
Software Melrics, publicado anualmente). En Internet est disponible una amplia variedad de
fuentes de informacin acerca de las mtricas de proceso y proyecto. Una lista actualizada de referencias en la World Wide Web se encuentra en el sitio Web SEPA:
http:/ /www.mhhe.com/ pressman.
23
CONCEP'l'OS
CLAVE
iml!ritq "
,693
complejiclod 703
fftimad4,t
bo$aclo
enlDC ....700
basoda ell Pf 702
basada
811 p(OC8S0S
104
e11sos uso Jos

conceptos. ,698
recon<iliaci11 70&
fadlbilldad . .693
planlfiaidn ele
proyecto ... .692
recursos . .. .. .694
tamao
del software . .698
UN VISTAZO
RPIDO
ESTIMACIN PARA
PROYECTOS DE SOFTWARE
a gestin del proye,to de software comienza con un conjunto de activicb
des que en grupo se denominan planiji.Caci6n del proyecto. Antes de que
proyecto comience el gestor del proyecto y ~l equipo de software deben es
timar el trabajo que habr de realizarse, los recursos que se requerirn y e1 tiemrc
que transcurrir desde el princpio hasta el final. Una vez que se eompleten est:actividades, el equipo de software debe establecer un plan del proyect<t que d
fina las tareas y fechas dave de la ingeniera del software, que idenfique qui e
es responsable de dirigir cada tarea y especifique 1as dependencias entre tareas
que pueden ser detenninantes en el progreso.
En una excelente gua para "sobrevivir el proyecto de software", Steve McConr,
(MCC98Ipresenta una visin del mundo real de la planificacin del proyecto:
Mucho~ trabajadores tcrcos pteferrn realizar el trabajo t,nico en lugar <le pa-
sar l tiempo en la planitkadn. Muchos gestores tcnicos no tienen suficiente entrenamento en la gestin tcnica para sentirse seguros de que su planificacir
mejorar el resultado de un proyecto. Puesto que ninguna parte quiere hacer la planificacin, con frecuencia no se realiza.
Pero las fallas para planificar es u,no de los mayotes errores que un proycto pueda
cometer... se necesita la planificacin eficaz para resolver los problemas corriente
arriba [temprano en el proyect) a bajo costo, mas que corriente abajo {tarde en el
proyecto! a alto costo. El proyecto promedio gasta 80 por ccnto de su tiempo en reelaboracin: corrigiendo errores que $~ ometiei:on en etapastempranas del proyecto
CAPTULO 23
ESTIMACIN PARA PROYiCTOS DE SOFTWARE
691
McConell argumenta que cualquier proyecto puede encontrar el tiempo para planificar (y adaptar el plan a lo largo del proyecto) simplemente tomando un pequeo
porcentaje del tiempo que se habra gastado en la reelaboracin que ocurre debido
a que no se planific.
La planificacin requiere que los gestores tcnicos y los miembros del equipo de
software establezcan un compromiso inicial, aun cuando sea probable que este
"compromiso" pruebe estar equivocado. Siempre que se realizan estimaciones se
atisba al futuro y se acepta automticamente algn grado de incertidumbre. Para
citar a Frederick Brooks [BR075)
[N]uestras tcnicas de estimacin estn pobremente desarrolladas. Ms seriamente, re flejan una suposicin no expresada que es bastante incierta, es decir: que todo ir bien .. .
Puesto que no estamos seguros de nuestras estimaciones, con frecuencia los gestores de
software carecen de la corts testarudez para hacer que la gente espere un buen producto
Aunque la estimacin es tanto un arte como una ciencia, esta importante actividad
no necesita realizarse en una forma improvisada. Existen tcnicas tiles para la estimacin de tiempo y esfuerzo. Las mtricas del proceso y del proyecto ofrecen la
perspectiva histrica y la energ1a para la generacin de estimaciones cuantitativas.
La experiencia (de toda la gente involucrada) puede auxiliar enormemente conforme
se desarrollan y revisan las estimaciones. Puesto que la estimacin coloca los
cimientos para las dems actividades de planificacin del proyecto, y sta proporciona la ruta para la ingeniera del software exitosa, se estara mal aconsejado si se
embarcara sin ella.
1.os MnOS enfoques de estimacin y los datos hisams sWos tfrecan la mejor esperanm de que en reolldad st
..._. sofn demandas imposibles.
692
La estimacin de recursos, costo y programa de trabajo para una tarea de ingeniera de software requiere experiencia, acceso a buena informacin histrica
(mtricas) y el valor para comprometerse con predicciones cuantitativas cuando la
informacin cualitativa es todo lo que existe. La estimacin implica riesgo inherente, 1 y ste conduce a la incertidumbre
La disponibilidad de informacin histrica tiene una fuerte influencia en el riesgo
de la estimacin. Al mirar en retrospectiva, se pueden emular las cosas que funcionaron y mejorar las reas donde surgieron problemas. Cuando hay disponibles
amplias mtricas de software (captulo 22) de proyectos previos, las estimaciones se
hacen con mayor seguridad, los programas de trabajo se pueden establecer para evitar dificultades pasadas y el riesgo global se reduce.
"II IIIIUdlrlsllm de INIII mente instruido es descansar satisfecho con el grvdo de presi611.- la . . . . . .
alillh, yao liusair la eXlldilucl cuando slo es posible unoaproximacin de lo ~
........
El riesgo de la estimacin se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas para recursos, costos y programa de trabajo. Si e
mbito del proyecto se comprende en forma deficiente o los requisitos del proyeo. estn sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimacin se
incrementan peligrosamente. El planificador y, en forma ms importante, el clienre
deben reconocer que la variabilidad en los requisitos del software significa inestabilidad en costo y programa de trabajo.
Sin embargo, un gestor de proyecto no debe obsesionarse con las estimaciones.
Los modernos enfoques de ingeniera del software (por ejemplo, modelos de proceso incremental) asumen una visin iterativa del desarrollo. En tales enfoques es
posible, aunque no siempre aceptable polticamente, reexaminar las estimaciones
(cuando se conozca ms informacin) y modificarlas cuando el cliente cambia los
requisitos.
tcoNIIJOS.
Mientras m6s
conozco, mejor
estimar. En
consecuen<io,
octuofice sus
estimodones
crrfo,-ne avance el
,rr,yecto.
El objetivo de la planificacin del proyecto de software es proporcionar un marco de

trabajo que permita al gestor estimar razonablemente recursos, costo y programa
de trabajo. Adems, las estimaciones deben intentar definir los escenarios de meJor.
peor caso de modo que los resultados del proyecto se puedan acotar. Aunque ex1s1un grado inherente de incertidumbre, el equipo de software se embarca en un plaestablecido como consecuencia de las tareas de planificacin. Por lo tanto, el plan se
debe adaptar y actualizar conforme avance el proyecto. En las secciones siguientes
se estudiar cada una de las actividades asociadas con la planificacin del proyec: j
de software.
1 En el capitulo 25 se presentan tcnicas sistemticas para el anlisis del riesgo.
CAPTULO 23
ESTIMACIN PARA PROYECTOS DE SOFIWARE
693
Conjunto de tareas para la planil1cacin del proyecto

l. Estoblecer el mbito del proyecto.
2. Determinar la factibilidad.
3. Analizar los riesgos (captulo 25).

Defi 1
'd
n,r os recursos requeri os.
a . Determinar los recursos humanos requeridos.
b. Definir los recursos de software reutilizables.
c.
Identificar los recursos del entorno.
Estimar costo y esfverzo.

a . Descomponer el problema.
b.
Desarr~llar dos o ms es~imaciones empleando

tamano, puntos de hmc16n, 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 poro
desarrollar un cronograma.
d. Definir mecanismos de seguimiento del
programa de trabajo.
El mbito del software describe las funciones y caracteristicas que se entregarn a los
usuarios finales, los datos que son entrada y salida, el "contenido" que se presenta a
los usuarios como consecuencia de emplear el software, asi como el desempeo, las
restricciones, las interfases y la confiabilidad que acotan el sistema. El mbito se define al usar una de las dos tcnicas siguientes:
1. Despus de una comunicacin con todos los participantes se desarrolla una

descripcin narrativa del mbito del software.
2. Los usuarios finales desarrollan un conjunto de casos de uso.2
Las funciones descritas en el enunciado del mbito (o dentro de los casos de uso) se
evalan y en algunos casos se refinan para proporcionar ms detalles antes de
comenzar la estimacin. PUesto que las estimaciones de costo y programa de trabajo
estn funcionalmente orientadas, con frecuencia es til cierto grado de descomposicin. Las consideraciones del desempeo abarcan los requisitos de procesamiento
y tiempo de respuesta. Las restricciones identifican los lmites colocados en el software por el hardware externo, la memoria disponible u otros sistemas existentes.
una vez identificado el mbito (con la participacin del cliente) es razonable preguntar: es posible construir software para satisfacer este mbito? El proyecto es
factible? Con mucha frecuencia los ingenieros de software soslayan estas preguntas
(o gestores o clientes impacientes los presionan para hacerlo). slo para verse enredados en un proyecto condenado al fracaso. PUtnam y Myers [PUT97a] abordan este
conflicto cuando escriben:
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.
694
tcc,NSIJOS.
Lo factibilidad del
proyecto es impar
tonte, pe,o una consideracin de los
necesidades del
negocio es incluso
ms imponante. No
es bueno construir un
sistema opradocto de
alto tecnologa que
nadie quiere.
PARTE CUATRO
GESTIN DE PROYBCTOS DE SOITWARE
[NJo todo lo imaginable es factible, incluso ni en sonware, tan evanescente como puede
parecer a los extraos. Por el contrario, la factibilidad del sofiware tiene cuatro dimensiones slidas: Ternologa: ,el proyecto es tcnicamente factible? Est dentro del terreno de
la disciplina? Los defectos se pueden reducir a tal grado que se emparejen con las necesidades de la aplicacin? Finanzas:
,es financieramente factible? Se puede completar el
desarrollo a un costo que la organizacin de sonware, su cliente o el mercado puedan enfrentar? -nempo: ,el proyecto llegar al mercado antes y vencer a la competencia? Recursos: la organizacin tiene los recursos necesarios para triunfar?
Putnam y Myers sugieren, acertadamente, que el mbito no es suficiente. Una \

que el mbito se comprende, el equipo de software y otros deben trabajar para detC"
minar si se puede hacer dentro de las dimensiones anotadas lineas arriba. sta
una parte crucial, aunque con frecuencia ignorada, del proceso de estimacin.
La segunda tarea de la planificacin es la estimacin de los recursos necesarios p"ra

completar el esfuerzo de desarrollo del software. La figura 23.1 muestra las t :s
grandes categoras de los recursos de ingeniera del software: personal, compone
tes de software reutilizables y el entorno de desarrollo (hardware y herramientas Se
software). Cada recurso se especifica con cuatro caractersticas: descripcin dE:
recurso; un informe de disponibilidad; cundo se requerir el recurso; tiempo durante el cual el recurso se aplicar. Las ltimas dos caractersticas se pueden ver comG
iihif!i
Recursos del
proyecto.
CAPTULO 23
ESTIMACIN PARA PROVECTOS DE S0f1WARE
695
una ventana de tiempo. La disporubilidad del recurso para una ventana especfica
debe establecerse lo ms pronto posible.
23.4.1
Recursos humanos
El planificador comienza evaluando el mbito del software y seleccionando las habilidades requeridas para completar el desarrollo. Se especifican tanto la posicin
organizacional (por ejemplo, gestor, ingeniero de software ejecutivo) como la especialidad (por ejemplo, telecomunicaciones, base de datos, cliente/servidor). En proyectos relativamente pequeos (unos pocos persona-meses) un solo individuo puede
realizar todas las tareas de ingeniera del software y consultar con especialistas conforme se requiera. En proyectos mayores el equipo de software puede estar geogrficamente disperso en varios sitios. Aqu se especifica la ubicacin de cada recurso
humano.
El nmero de personas que requiere un proyecto de software slo se determina
despus de que se ha hecho una estimacin del esfuerzo de desarrollo (por ejemplo,
personas-mes). Las tcnicas para estimar el esfuerzo se tratarn ms adelante en
este captulo.
23.4.2 Recursos de software reutllizables

La ingeniera del software basada en componentes (captulo 30) enfatiza la reutili-
zacin; es decir, la creacin y reutilizacin de bloques de construccin de software

[H0091]. Tales bloques, usualmente llamados componentes, deben catalogarse para
consultarlos con facilidad, estandarizarse para facilitar su aplicacin y validarse
para integrarlos fcilmente.
Bennatan [BEN92] sugiere cuatro categoras de recursos de software que deben
considerarse conforme avanza la planificacin:
varios compo
de reufilizocin
Componentes ya desarrollados. El software existente se puede adquirir de un tercero o se desarroll internamente para un proyecto previo. Los CCYD (componentes comerciales ya desarrollados) se compran de un tercero, estn listos para emplearlos en el proyecto actual y han sido ampliamente validados.
Componentes experimentados. Especificaciones, diseos, cdigo o datos de prueba existentes que se desarrollaron para proyectos previos son similares al software que
se construir para el proyecto actual. Los miembros del equipo de software actual ya
tienen experiencia en el rea de aplicacin que representan dichos componentes. En
consecuencia, las modificaciones que requieran los componentes experimentados
sern relativamente de bajo riesgo
Componentes de experiencia parcial Especificaciones, diseos, cdigo o datos de
prueba existentes que se desarrollaron para proyectos previos estn relacionados
con el software que se construir para el proyecto actual pero requerirn modificaciones sustanciales. Los miembros del equipo de software actual slo tienen experiencia limitada en el rea de aplicacin que representan dichos componentes. Por
PARTE CUATRO GESTIN DE PROYECTOS DE S0f1WARE
lo tanto, las modificaciones que requieren los componentes de experiencia parcia.

tienen un grado considerable de riesgo.
Componentes nuevos. El equipo de software debe construir los componentes G.

software especficamente para las necesidades del proyecto actual.
Irnicamente, con frecuencia los componentes de software reutilizables son despn:
ciados durante la planificacin, slo para convertirse en una preocupacin impo:tante durante la fase de desarrollo del proceso de software. Es mejor especific;:
cuanto antes los requisitos de recursos de software. De esta forma se puede llevar
cabo la evaluacin tcnica de las alternativas y puede ocurrir la adquisicin oportun;.
23.4.3 Recursos del entorno

El entorno que soporta un proyecto de software, con frecuencia denominado ent~
de ingeniera del software (EIS). incorpora hardware y software. El hardware propc:-ciona una plataforma que soporta las herramientas (software) con que se product:r:.
los productos de trabajo basados en una buena prctica de la ingeniera del sofu':lre.3 Puesto que la mayor parte de las organizaciones de software tienen mltiples
constituyentes que requieren acceso al EIS, el planificador de proyecto debe prescbirla ventana de tiempo requerida por el hardware y el software, y verificar que est"'
recursos estarn disponibles.
Cuando un sistema basado en computadora (que incorpora hardware y softwa ~
especializados) se someter a ingeniera, el equipo de software quiz requiera acce~
so a elementos de hardware que estn desarrollando otros equipos de ingenier.
Por ejemplo, el software de un contador numrico (CN) utilizado en un tipo r.e
mquinas-herramienta tal vez requiera una mquina-herramienta especfica (P,:
ejemplo, un CN de tomo) como parte del paso de prueba de validacin; un proyec
de software para plantilla de pgina avanzada quiz necesite una impresora de a' i
calidad en algn punto durante el desarrollo. El planificador del proyecto de softv re debe especificar cada elemento de hardware.
El software es el elemento ms caro de virtualmente todos los sistemas basados e

computadora. En sistemas complejos, personalizados, un gran error en la estm.:
cin del costo puede hacer la diferencia entre beneficio y prdida. Rebasar el cost.
puede ser desastroso para el desarrollador.
!&f 1!1111 ro dtsubtontrotocin y competencia creciente, lohabilidad para estimar con mu~ predsln....:hewgido
(Ql10 un fa<tot d xito tlllcioi poro muchos grupos de TI."
'
. . lr-..tt
3
Otro hardware -el entorno objetivo- es la computadora en la que el software se ejecutar cuan.:.
haya sido liberado al usuario final.
CAPTULO 23
ESTIMACIN PARA PROYtC70S DE sonwARE
697
La estimacin del costo y el esfuerzo nunca ser una ciencia exacta. 4 Demasiadas
variables -humanas, tcnicas, ambientales polllicas- pueden afectar el costo final
del software y el esfuerzo aplicado a desarrollarlo. Sin embargo, la estimacin del
proyecto de software se puede transfonnar de una prctica oscura en una sene de
pasos sistemticos que proporcionan estimaciones con riesgo aceptable. Para lograr
estimaciones confiables de costo y esfuerzo se tienen varias opciones:
1. Demorar la estimacin hasta ms tarde en el proyecto (obviamente, se puede

lograr 100 por ciento de estimaciones precisas despus de que el proyecto
est terminado!)
2 . Basar las estimaciones en proyectos similares que ya hayan sido completados
3. Emplear tcnicas de descomposicin relativamente simples para generar estimaciones de costo y esfuerzo del proyecto.
4 . Utilizar uno o ms modelos empricos en la estimacin de costo y esfuerzo

Desgraciadamente, la primera opcin, aunque atractiva, no es prctica. Las estimaciones de costos se tienen que proporcionar "por adelantado" No obstante, se debe
reconocer que, mientras ms se espere ms se conocer, y mientras ms se conozca menos probable es que se cometan serios errores en las estimaciones.
La segunda opcin puede funcionar razonablemente bien si el proyecto en curso
es muy similar a los previos y a otras inluencias del proyecto (por ejemplo, el equipo de software, el cliente, las condiciones del mercado, el EIS, las fechas limite) son
aproximadamente equivalentes. Por desgracia, la experiencia no siempre ha sido un
buen indicador de los resultados futuros.
Las opciones restantes son enfoques viables para la estimacin del proyecto de
software. Idealmente, las tcnicas mencionadas para cada opcin deben aplicarse
juntas. cada una empleada como una marca de verificacin para la otra. Las tcnicas de descomposicin asumen un enfoque de "divide y vencers" respecto de la
estimacin del proyecto de software. Al descomponer un proyecto en funciones principales y actividades de ingeniera del software relacionadas, las estimaciones de
costo y esfuerzo se pueden realizar en forma escalonada. Los modelos de estimacin empirica son tiles para complementar las tcnicas de descomposicin y ofrecer un enfoque de estimacin potencialmente valioso por su propio derecho. Estos
modelos se estudian en la seccin 23.7.
Cada una de las opciones viables de estimacin de costo del software ser tan
buena como lo sean los datos histricos en que se basa la estimacin. Si no existen
datos histricos, la estimacin del costo se basar en un fundamento muy tambaleante. En el captulo 22 se examinan las caracter slicas de algunas de las mtricas
de software que proporcionan la base para los da ~s histricos de estimacin.
4
Bennatan [BEN03) reporta que 40 poreientOde los desarrolladores de sonware continan luchando
con las estimaciones y que el tamao del ~-are y d tiempo de desarrollo son muy dilciles de estimar con precisin.
698
PARTE CUATRO
La estimacin del proyecto de software es una forma de resolver problemas; en 1::

mayora de los casos, el problema que debe resolverse (es decir, el desarrollo de un;;.
estimacin de costo y esfuerzo para un proyecto de software) es muy complejo com~
para considerarlo una sola pieza. Por esta razn se descompone el problema, reca
racterizndolo como un conjunto de problemas ms pequeos (y, esperanzadoramente, ms manejable).

En el captulo 2 1 se examin el enfoque de descomposicin desde dos diferentes
puntos de vista: descomposicin del problema y descomposicin del proceso. La
estimacin emplea una o ambas formas de particin. Pero antes de que pueda rea
!izarse una estimacin, el planificador del proyecto debe entender el mbito del sor
ware que se construir y generar una estimacin de su "tamao".
23.6.1
,r.,
'"'
c&v1
8 "11Jmoo" del
softwore que se
construir puede
estinme~
meooo directo,
LDC, ouno mdire<l1l,
Pf.
ll10
Tamao del software
La precisin de la estimacin de un proyecto de software se manifiesta en varios fa.__-
tores: 1) el grado con el cual el planificador ha estimado adecuadamente el tamat

del producto que se construir; 2) la habilidad para traducir la estimacin del tarr'o en esfuerzo humano, programa de trabajo y dinero (una funcin de la dispon~
lidad de las mtricas de software confiables a partir de proyectos previos); 3) el graJn
en el cual el plan del proyecto refleja las habilidades del equipo de software; y 4 la
estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo d:
ingenierla del software.
En esta seccin se considera el problema del tamao del software. Puesto que
estimacin de un proyecto slo es tan buena como la estimacin del tamao del rabajo para realizarlo, el tamao representa el primer gran desafio del planificador 2
proyecto. En el contexto de la planificacin del proyecto, tamao se refiere a
resultado cuantificable del proyecto de software. Si se asume un enfoque direct-.
tamao se puede medir en lneas de cdigo (LDq. Si se elige un enfoque indirecu
el tamao se representa como puntos de funcin (PF).
Putnam y Myers [PUT92] sugieren cuatro diferentes enfoques al problema
tamao:
Cmo se
111lde el
tamao del
software que se
planea constrvir?
Tamao de "lgica difusa". La aplicacin de este enfoque requiere que el plaroficador identifique el tipo de aplicacin, establezca su magnitud en una e ~
cualitativa y luego refine la magnitud dentro del rango original.
Tamao de punto defuncin. El planificador desarrolla estimaciones de las
caractersticas del dominio de la informacin tratadas en el captulo 15.
Tamao de componentes estndar. El software se compone de varios "com~
nentes estndar", los cuales son diferentes y genricos de una rea partcula:
de la aplicacin. Por ejemplo, los componentes estndar de un sistema de
informacin son subsistemas. mdulos, pantallas, reportes, programas inte:--
CAPiTULO 23
ESTIMACIN PARA POOYEC.OS DE SOFTWARE
699
activos, programas por lotes, archivos, LDC e instrucciones al nivel de objeto.

El planificador del proyecto estima el numero de ocurrencias de cada componente estndar y luego aplica datos de proyectos histricos para determinar el
tamao de entrega por componente estndar.
Tamao del cambio. Este enfoque se aplica cuando un proyecto incluye la utilizacin de software existente que debe modificarse en cierta forma como parte
de un proyecto. El planificador estima el nmero y tipo (por ejemplo, reutilizacin, cdigo de adicin, cdigo de cambio, cdigo de borrado) de las modificaciones que se deben lograr.
Putnam y Myers sugieren que los resultados de cada uno de estos enfoques de tamao se combinen estadsticamente para crear una estimacin de tres puntos o del valor
esperado Esto se logra desarrollando valores optimistas (bajos), ms probables y

pesimistas (altos) para el tamao y combinndolos con la ecuacin (23-1) descrita
en la siguiente seccin.
23.6.2 Estimacin basada en el problema

En el capitulo 22, las lineas de cdigo y los puntos de funcin se describieron como
medidas a partir de las cuales se calculan las mtricas de productividad. Los datos
de las LDC y los PF se uWizan en dos formas al estimar el proyecto de software: 1)
como una variable de la estimacin para el "tamao" de cada elemento del software, y 2) como mtricas de lnea base recolectadas a partir de proyectos previos y utilizados en conjuncin con variables de estimacin para desarrollar proyecciones de
costo y esfuerzo
Las estimaciones de LDC y PF son distintas tcnicas de estimacin. aunque ambas
tienen varias caractersticas en comn. El planificador del proyecto comienza con un
enfoque acotado del mbito del software y a partir de ah intenta descomponer el
software en funciones problema que puedan estimarse individualmente. Entonces se
estiman las LDC o PF (las variables de estimacin) para cada funcin. De manera
alternaliva, el planificador puede elegir otro componente para tamao, como clases
u objetos, cambios o procesos de negocios afectados.
Entonces se aplican las mtricas de la lnea base de productividad (por ejemplo,
LDC/pm o PF/pm 5) a la variable de estimacin apropiada, y se deriva el costo o esfuerzo de la funcin. Las estimaciones de funcin se combinan para producir una estimacin global del proyecto completo.
Sin embargo, es importante notar que con frecuencia existe una dispersin sustancial en las mtricas de productividad de una organizacin, lo que hace sospechoso el uso de una sola mtrica de lnea base de productividad. En general, el dominio
del proyecto debe calcular los promedios de LDC/ pm o PF/pm Es decir, los proyectos deben agruparse por tamao de equipo, rea de aplicacin, complejidad y otros
Las siglas pm significan persona-mes de esfuerzo
700
PARTE CUATRO Gl'STIN DE PROYEC'T05 DE SOF'TWARE
parmetros relevantes. Luego se tienen que calcular los promedios de dominio loca:
cuando se estima un nuevo proyecto primero debe ubicarse en un dominio, y lueg;
aplicar el promedio del dominio apropiado para la productividad y as generar la estimacin.
~,
&1
C~VE
En los estimaciones PF
lo descomposicin se
enfoco sobre los
coroctersticos del
dominio de
mformocin.
Cmo se
cabla ti
valor esperado*
para el tamao de
software?
Las tcnicas de estimacin LDC y PF difieren en en cuanto al detalle requerid

para descomposicin y el objetivo de la particin. Al emplear LDC como variable d:
estimacin la descomposicin es absolutamente esencial y con frecuencia se lleva ..
grados considerables de detalle. Mientras mayor sea el grado de particin es ma.
probable que se desarrolle una estimacin razonablemente precisa de LDC.
En las estimaciones de PF la descomposicin funciona de manera diferente. Mcb.
que enfocarse sobre la funcin, se estima cada una de las cinco caractersticas d..
dominio de informacin, as como los 14 valores de ajuste de complejidad estudia
dos en el captulo 15. Entonces se pueden utilizar las estimaciones resultantes par
derivar un valor de PF que se pueda ligar a datos previos y empleados para genera:
una estimacin.
Sin importar la variable de estimacin que se utilice, el planificador del proyec:.o
comienza estimando una gama de valores para cada funcin o valor de dominio de
informacin. Al emplear datos histricos o (cuando todo lo dems falla) intuicin. e
planificador estima un valor de tamao optimista, ms probable, y pesimista par..
cada funcin o cuenta para cada valor de dominio de informacin. Cuando se espt:
cifica un rango de valores se proporciona un indicio implcito del grado de incert
dumbre.
Entonces se puede calcular un valor de tres puntos o uno esperado. El valor espe--,
rado para la variable de estimacin (tamao), S, se calcula como un promedio ponderado de las estimaciones optimista (S0 p1), ms probable (Sm) y pesimista (Spe5). Por
ejemplo,
S = (S0 p1 + 4Sm
+ 5i,cs)/6
(23-'
brinda la credibilidad ms fuerte a la estimacin "ms probable" y sigue una distr

bucin de probabilidad beta. Se supone que existe una probabilidad muy pequea d
que el tamao real resultante se ubique fuera de los valores optimista y pesimista
Una vez determinado el valor esperado para la variable de estimacin se aplicalos datos de productividad histrica de LDC o PF. Son correctas las estimaciones~
La nica respuesta razonable a esta pregunta es: no se puede estar seguro. Cualquie
tcnica de estimacin, no importa cun sofisticada sea, debe contrastarse con otn,
enfoque. Incluso entonces deben prevalecer el sentido comn y la experiencia.
23.6.3 Un ejemplo de estimacin basada en LDC

Como ejemplo de tcnicas de estimacin de LDC y PF basadas en el problema, considrese un paquete de software que ser entregado para una aplicacin de disee
asistido por computadora (CAD, por sus siglas en ingls) destinado a componente
mecnicos. El software se ejecutar en una estacin de trabajo de ingeniera y debe
CAPTULO 23 ESTIMACIN PARA PROYECTOS DE SOFTWARE
701
tener interfaz con varios perifricos que incluyen ratn, digitalizador. monitor de
color de alta resolucin e impresora lser. Se puede elaborar una descripcin preliminar del mbito del software:
El software CAD mecnico aceptar del ingeniero datos geomtricos de dos y tres dime nsiones. El ingeniero interactuar y controlar el sistema CAD a travs de una interfaz del
usuario que exhibir caractersticas de buen diseo de interfaz humano-mquina. Todos
los datos geomtricos y otra informacin de soporte se conservarn en una base de datos
CAD. Se desarrollarn mdulos de anlisis de diseo para producir la salida requerida, la
cual se desplegar en una diversidad de dispositivos grficos. El software se disear para
controlar e interactuar con dispositivos perifricos que incluyen ratn, digitalizador, impresora lser y plotter.
Esta descripcin del mbito es preliminar, no est acotada. Se tendra que expandir
cada oracin para ofrecer detalle concreto y acotacin cuantitativa. Por ejemplo,
antes de que comience la estimacin, el planificador debe determinar qu significa
"caractersticas de buen diseo de interfaz humano-mquina" o cules sern el
tamao y la complejidad de la "base de datos CAD".
En cuanto a los propsitos actuales, se supone que se ha llevado a cabo ms refinamiento y que estn identificadas las grandes funciones de software mencionadas
en la figura 23.2. Al continuar con la tcnica de descomposicin para LDC se elabora 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 estimaciones
LDC para la funcin de anlisis geomtrico 30 es: optimista, 4 600 LDC; ms probable, 6 900 LDC; y pesimista, 8 600 LDC. Al aplicar la ecuacin 23-1 el valor esperado
para la funcin de anlisis geomtrico 30 es 6 800 LDC. Otras estimaciones se derivan 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.
tiihff!f
!ahlade
estimacin
;:,ara mtodos
:.oc.
Funci6n
U>C estimadas
Focllidades ele interfaz del usuario y control (FIUC)

An6lisis geomtrico bidimensional (AG2D)
2 300
5 300
Aniiss geomtrico tridimensional (AG3D)

Gestin de base de datos (GBO)
facilidades ele presentacin grfico de
computadora (FPGC)
6 800
3350
4950
funcin de control perif ico (fCP)
2 100
8 400
Mdulos de anlisis de diseo VMDt
Lneos de cdigo astimodm
.,
i,
'
33 200
702
PARTE CUATRO
Una revisin de los datos histricos indica que el promedio organizacional de ~

ductividad para sistemas de este tipo es de 620 LDC/pm. Con base en una tar'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 product.
vidad, el costo total estimado del proyecto es de 431 000 dlares y el esfuerzo es
mado es de 54 personas-mes. 6
con lo cabeza): M"'f bien, pero no

ningn incremento todava.
, pero es por eso por lo que neceJitomos
23.6.4 Un ejemplo de estimacin basada en PF

La descomposicin de la estimacin basada en PF se centra en los valores de dominio
de informacin ms que en las funciones de software. Al consultar la tabla presentada en la figura 23.3 el planificador del proyecto estima entradas externas, salidas
externas, consultas externas, archivos lgicos internos y archivos de interfaz externos para el software CAD. Los PF se calculan usando la tcnica estudiada en el cap-
Las estimaciones estn redondeadas a 1 000 dlares y a la persona-mes ms cercanos. Mayor precisin es innecesaria e irreal, dadas las limitaciones de precisin de la estimacin.
703
CAPTULO 23 ESTIMACIN PARA PROYECTOS DE SOFTWARE
Estimacin de valores de dominio de informacin.
Conteo
Conteo.
Optim. Pnmable Pesim.

Nmer() de emrdm exlltmas
Nm"'o de
emm.
Pelo
PF
4 .
97
20
24
30
24
0
12
15
22
78
16
' 22
2$
22
. 8&
10
42
,okdot extttrnQs
Nmero d p~vntos exiemas

Nmero de archivos 16gk< nJernos
';.;
Nmero de archivo$ de interfuS externos 2

Conteo total
tulo 15. En cuanto a los propsitos de esta estimacin se supone que el factor ponderado de complejidad es el promedio. La figura 23.3 presenta los resultados de esta
estimacin.
Se estima cada uno de los factores ponderados de complejidad y el valor del factor ajustado se calculan como se describe en el captulo 15:
Valor
Factor
1. Respaldo y recuperacin
2. Comunicaciones de datos
3 . Procesamiento distribuido
4. Desempeo crtico
5.
6.
7.
8.
9.
1O.
1 1.
12.
13.
14.
Entorno operativo existente

Entrada de datos en lnea
Transaccin de entrado sobre pantallas mltiples
ILF actualizado en lnea
Complejo de valores de dominio de informacin
Complejo de procesamiento interno
Cdigo d iseado paro reutilizacin
Conversin/instalacin en diseo
Instalaciones mltiples
Aplicacin diseado paro cambio
5
3
5
5
4
3
5
5
Factor de ajuste de valor
1.17
Finalmente, se deriva el nmero estimado de PF:
= conteo total
Pfesllmado = 375
Pfeslimado
(0.65 _.. 0.01
! (F)J
La productividad organizacional promedio para sistemas de este tipo es 6.5 PF/pm.

Con base en una escala salarial de 8 000 dlares por mes, el costo por PF es aproximadamente 1 230 dlares. Con base en la est.imadn de PF y los datos de producti-
704
,..CONIUOSi el tiempo lo
permite, use lo granu-
laridad fino cuando

especifique las IIJreos
en lo f;pa 23.4. Por
ejemplo, divido el
on6/sis en sus IIJreos
prindpoles yestime
codo uno {)Of
seporodo.
PARTE CUATRO
Gl:STlN DE PROYEC'la; DE SOFIWARE
vidad histricos, el costo total estimado del proyecto es de 461 000 dlares, y e
esfuerzo estimado es de 58 personas-mes.
23.6 .5 Estimacin basada en el proceso

La tcnica ms comn para estimar un proyecto es basar la estimacin en el proceso 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 proceso comienza con un bosquejo de las funciones del software obtenidas a partir dl.
mbito del proyecto. cada funcin requiere realizar una serie de actividades del marc
de trabajo. Las funciones y actividades7 del marco de trabajo relacionadas se prt.
sentan como parte de una tabla similar a la presentada en la figura 23.4.
;:..g.
Tabla de
esttmacin
basada en
procesos.
Adividad
.,_~
ce
~
- --
-'
....
.....
AUC
AG20
AG30
FPGC
GBD
0.5%
0.25
0.5%
025
0.5%
IC ...
Di.., ,(".Jidinn Prueba
2.50
4.00
0.40
0.60
5.00 n.o
2.00 n a
8.40
7 35
O.SO
4.00
3.00
300
2.00
2.00
1.00
1.00
0.75
0.50
0.50
3.00
na
LSO
no
8.50
6.00
1.50 n/a
5.75
1.50 n/o
2.00 n/a
4.25
5.00
3.50 20.50
4.75
16.50
45%
10%
36%
o.so
0.2.'i
ele
cOftlfrcci6n
0,50
0.'.75
0.50
0.25
MAD
%eduerzo
-li1i1
o.~o
fCP
Tolales
lngenlerio
8%
CC = comunicacin del cliente EC evaluacin
46.00
del diente
Una vez que se combinan las funciones del problema y las actividades del proc
so, el planificador estima el esfuerzo (por ejemplo, personas-mes) que se requer
para lograr cada actividad del proceso de software en cada funcin. Estos dat
constituyen la matriz central de la tabla en la figura 23.4. Entonces se aplican J..s
tasas de trabajo promedio (es decir, costo/unidad de esfuerzo) al esfuerzo estimapara cada actividad del proceso. Es muy probable que la tasa de trabajo vare e
cada tarea. El equipo veterano est enormemente involucrado en las actividad
7
Las actividades del marco de trabajo que se ehgen para este proyecto difieren un poco de la act
dades genricas tratadas en el captulo 2, que son la comunicacin con el cliente (CC), la planifi-.
cin el anlisis de riesgos. la ingeniera y la construccin-liberacin.
CAPTULO 23
ESTIMACIN PARA PROYECTOS DE SOFTWARE
105
tempranas del marco de trabajo y generalmente es ms costoso que el equipo menos

experimentado involucrado en la construccin y liberacin.
Los costos y el esfuerzo para cada funcin y actividad del marco de trabajo se calculan como el ltimo paso. Si la estimacin basada en el proceso se realiza independientemente de la estimacin de LDC o PF, ahora se tienen dos o tres estimaciones para costo y esfuerzo que se pueden comparar y armonizar. Si ambos conjuntos
de estimaciones muestran una concordancia razonable, existe una buena razn
para creer que las estimaciones son confiables. Si, por otra parte, los resultados de
dichas tcnicas de descomposicin muestran poca concordancia, se debe llevar a
cabo mayor investigacin y anlisis.
!'fslllWlf carnprenderel lnlsfondode una estimacin antes de utlizorlo."
23.6.6 Un ejemplo de estimacin basada en el proceso

Para ilustrar el uso de la estimacin basada en el proceso considrese de nuevo el
software CAD introducido en la seccin 23.6.3. La configuracin del sistema y las
funciones del software permanecen invariables y las indica el mbito del proyecto.
En la tabla basada en el proceso que se muestra en la figura 23.4 las estimaciones del esfuerzo (en personas-mes) para cada actividad de ingeniera del software se
proporcionan para cada funcin del software CAD (abreviadas para mayor rapidez).
Las actividades de ingeniera y de liberacin de construccin se subdividen en las
principales tareas de ingeniera del software que se muestran. Las primeras estimaciones de esfuerzo corresponden a comunicacin con el cliente, planificacin y anlisis de riesgos, las cuales se registran en la hilera total al final de la tabla. Los totales
horizontal y vertical ofrecen un indicio del esfuerzo estimado que se requiere para
anlisis, diseo, cdigo y prueba. se debe sealar que 53 por ciento del esfuerzo se
emplea en las tareas de ingeniera del sistema de salida (anlisis de requisitos y diseo), lo que indica la importancia relativa de este trabajo.
Con base en la escala salarial promedio de 8 ooo dlares por mes, el costo total
estimado del proyecto es de 368 000 dlares , y el esfuerzo estimado es de 46 personas-mes. Si se desea, los promedios de trabajo pueden asociarse con cada actividad
del marco de trabajo o tarea de ingeniera del software y calcularse por separado.
23.6.7 Estimacin con casos de uso
Por qu es
ctifcil desa
J:'llar una tcnica
a estimacin con
ases de uso?
Corno se ha sealado a lo largo de las partes 2 y 3 de este libro, los casos de uso permiten que un equipo de software comprenda el mbito del software y los requisitos.
Sin embargo, desarrollar un enfoque de estimacin con casos de uso es problemtico por las siguientes razones [SMI99J:
Los casos de uso se describen empleando muchos formatos y estilos diferentes; no existe un formato estndar.
706
PARTE CUATRO GESTIN DE PROm:ros DE SOFJWARE
Los casos de uso representan una visin externa (la visin del usuario) del
software y con frecuencia estn escritos con diferentes grados de abstraccir
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 punto de funcin, el "caso de uso" de una persona W
vez requiera meses de esfuerzo mientras que el de otra quiz se implemente en v
da o dos.
Aunque varios investigadores han considerado los casos de uso como una entt?
da a la estimacin, a la fecha no ha surgido ningn mtodo de estimacin probad
Smith [SMI99] sugiere el empleo de los casos de uso en la estimacin, pero slo
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 c ....
no ms de 1O casos de uso. Cada uno de stos abarcara no ms de 30 escenan s
distintos. Obviamente, los casos de uso que describen un sistema grande estn ese- tos con un grado mucho mayor de abstraccin (y representan considerablemene
ms esfuerzo de desarrollo) que aquellos que describen un solo subsistema. En ce
secuencia, antes de que los casos de uso se empleen en la estimacin, se establee
el nivel en la estructura jerrquica, se determina la longitud promedio (en pgina
de cada caso de uso, se define el tipo de software (por ejemplo, tiempo real, de neg: cios, de ingenieria/cientfico, anidado) y se considera una arquitectura comn d
sistema. Una vez establecidas dichas caractersticas, los datos empricos se aprO\
chan para establecer el nmero estimado de LDC o de PF por caso de uso (para ca...
nivel de la jerarquia). Entonces se utilizan los datos histricos para calcular el esfue
zo necesario para desarrollar el sistema.
Enseguida se ilustra cmo realizar este clculo; por tanto, considrese la siguier
te relacin: 8
LDC estimada= N X LDCrom + [(50 /Sh - 1) + (P0 /Ph - !)) X LDCauste
(23-2
donde
N
LDCprom
= nmero real de casos de uso

= promedio histrico de LDC por caso de uso para este tipo de subs1s
tema
Es importante sealar que la expresin (23-2) se emplea slo con propsitos ilustrativos. Al i ~
que todos los modelos de estimacin, debe validarse localmente antes de que se le pueda utilizar
con segundad.
CAPTULO 23
707
ESTIMACIN PARA PROYECIOS DE sonwARE
LDCa;usie = representa un ajuste con base en n por ciento de LDCirom donde n

se define localmente 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
Pa
Ph
= pginas reales por caso de uso

= pgina promedio por caso de uso para este 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 ajustado mediante el nmero de escenarios
y la longitud de la pgina de los casos_de uso. El ajuste representa hasta n por ciento del promedio histrico de las LDC por caso de uso.
23.6.8 Un ejemplo de estimacin basada en casos de uso

El software CAD presentado en la seccin 23.6.3 est compuesto 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 to escenarios y tiene una longitud promedio de seis pginas.
El grupo de subsistema de ingeniera lo describen 1O 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 Jo 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 datos histricos indican que el software lU 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-
jijij/ffij
Estimacin de caso de uso.
Subsistema de interfaz del usuario

Grupo de subsistema de ingeniera
Grupo de subsistema de infraestructura
Total LDC estimados
cosos
de uso
escenarios
6
10
5
10
20
3 366
31 233
7 970
pginos;n;~m2~~~_:.,y;~
LDC estimados
.42 568
708
PARTE C UATRO GESTIN DB PROYECTOS DE SOFTWARE
nas. Estos datos se ajustan razonablemente bien para el sistema CAD. As pues, l.:
estimacin de LDC para el subsistema de interfaz del usuario se calcula mediante la
expresin (23-2). Si se aplica el mismo enfoque, se realizan estimaciones para los
grupos de subsistemas de ingeniera e infraestructura. La figura 23.5 resume las estimaciones e indica que el tamao global del software CAD se estima en 42 500 LDC
Si se utilizan 620 LDC/pm como la productividad promedio en los sistemas de
este tipo y una escala salarial de 8 000 dlares por mes, el costo por linea de cdigo
es aproximadamente de 13 dlares. Con base en la estimacin de caso de uso y los
datos histricos de productividad, el costo total estimado del proyecto es de 552 00:
dlares, y el esfuerzo estimado es de 68 personas-mes.
23.6. 9 Reconciliacin de estimaciones

Las tcnicas de estimacin estudiadas en las secciones precedentes dan por resultad=
mltiples estimaciones que deben reconciliarse para producir una sola estimadode esfuerzo, duracin del proyecto o costo. Este procedimiento de reconciliacin se
ilustra considerando de nuevo el software CAD presentado en la seccin 23.6.3.
11,a ......,_i'OIIIPficados no produzcan uno estimodn ms preciso, parlkmottlllllle aJIIND lea

pueden incorporar su propio intuicin en loestimon.
'
:.
"
... ,11.... ,,
El esfuerzo estimado total para el software CAD vara desde un bajo de 46 perscnas-mes (obtenido empleando el enfoque de la estimacin basada en el procese
hasta un alto de 68 personas-mes (derivado con la estimacin de caso de uso). L:.
estimacin promedio (que utiliza los cuatro enfoques) es de 56 personas-mes. La variacin de la estimacin promedio es aproximadamente 18 por ciento en el lado baic
y de 21 por ciento en el lado alto.
Qu ocurre cuando la concordancia entre las estimaciones es insuficienteResponder esta pregunta requiere reevaluar la informacin con que se hicieron ~
estimaciones. Las estimaciones ampliamente divergentes con frecuencia puederastrearse hasta una de dos causas:
1. El planificador no ha comprendido adecuadamente o ha malinterpretado el

mbito del proyecto.
2 . Los datos de productividad que utilizan las tcnicas de estimacin basadas e:el problema son inapropiados para la aplicacin, obsoletos (pues ya no reflejan con precisin la organizacin de ingeniera de software) o se han aplicad!:
mal.
El planificador debe determinar la causa de la divergencia y luego reconciliar las
estimaciones.
CAPTULO 23 ESTIMACIN PARA. PROYOC'IOS OE SOFTWARE
709
Tcnicas de estimactn automatizada para proyectos de software

Los herromientos de estimoci6n outomotizodos
permiten que plonificodor estime costo y
:.ierzo y realice onlisis si. .. entonces respecto de
~ntes voriobles del proyecto, como lo fecho de
.-,go o lo plantillo de persono!. Aunque existen muchos
mientas de estimacin outomotizodo (vase el
~ r o ms adelante en este coptulo), todos presentan
..,,;smo.s coroctersticos generales y reolizon los
- entes seis funciones genricos [JON96):
4.
Tamao de /os entregobles del proyecto. Se estimo el
6.
1omoo de uno o ms prodvctos de trabajo del

software. Los prodvctos de trabajo incluyen lo
representacin externo del software (por ejemplo,
pontollos, reportes), el software en s mismo (por
ejemplo, KLDC), funcionalidad entregado (por
ejemplo, puntos de funcin) e informacin descriptivo
(por ejemplo, documentos).
Seleccin de los actividades del proyecto. Se
selecciono el morco de trabajo del proceso
adecuado y se especifico el conjunto de toreos de
Predicci6n de los niveles del personal. Se especifico el

nmero de personas que eslor disponible poro realizar
el lroboo. Puesto que lo relacin entre el personal
disponible y el trabajo (esfuerzo pn,cftcho) es
enofmemente no lineol, slo es uno entrado imporlonte.
s~
C~VE
modelo de
ts1mJCi reflejo lo
~ de proyectos
oo1e la que se ho
""1VOdo. Por lo tonto,
modelo es sensible
dominio.
Prediccin del esfuerzo de software. Los

herromientos de estimacin emplean uno o ms
modelos (seccin 23.7) que relocionon el tamao de
los entregobles del proyecto con el esfver20
requerido poro producirlos.
5. Prediccin del coslo del software. Dados los

resultados del poso 4, los costos se cokulon
relacionando los ndices de trabajo con los
actividades del proyecto anotados en el poso 2.
Prediccin del programo de trabao del softwore.
Cuando se conocen el esfuerzo, el nivel del persono!
y las actividodes del proyecto es posible producir un
anteproyecto de programo ol ubicar el trabajo o
travs de los octividodes de ingeniera del software
con base en los modelos recomendados poro la
distribucin del esfuerzo estudiados en el captulo 24.
Lo aplicacin de diferentes herromientos de estimacin o

los mismos datos de proyecto permite encontrar uno
variacin relotivomente grande en los resultados
estimados. M/:Js importonte todovo, en ocasiones los
valores predichos son significotivomente diferentes de los
valores reoles. Esto refuerzo lo nocin de que las salidos
de los herromientos de estimacin se deben emplear como
un punto de datos o portir del cual se derivan las
estimaciones, no como la nica fuente poro uno
estimacin.
un modelo de estimacin para software de computadora utiliza frmulas obtenidas

empfricamente para predecir el esfuerzo como una funcin de LDC o PF.9 Los valores de LDC o PF se estiman mediante el enfoque descrito en las secciones 23.6.3 y
23.6.4. Pero, en lugar de emplear las tablas descritas en dichas secciones, los valores resultantes para LDC o PF se colocan en el modelo de estimacin.
Los datos empricos que apoyan la mayora de los modelos de estimacin proceden de una muestra limitada de proyectos. Por esta razn, ningn modelo de estimacin es apropiado para todas las dases de software ni en todos los entornos de
desarrollo. En consecuencia, los resultados obtenidos a partir de tales modelos se
deben emplear juiciosamente
9 En la seccin 23 6. 7 se sugiere un modelo emprico que utiliza casos de uso como la variable independiente. Sin embargo, a la fecha han a;,a:ecido relativamente pocos en la respectiva b1blografia
PARTE CUATRO
710
GES11N DE PROVECTOS DE S0f1WARE
Un modelo de estimacin debe calibrarse para reflejar las condiciones locales

modelo debe probarse mediante la aplicacin de los datos recopilados a partir
proyectos completados, colocar los datos en el modelo y luego comparar los resl.
taos reales con los predichos. Si la concordancia es insuficiente, el modelo debe a
narse y ponerse a prueba nuevamente antes de que se pueda utilizar.
23. 7 .1 La estructura de los modelos de estimacin

Un modelo de estimacin tpico se deriva mediante el anlisis de regresin de
datos recopilados de proyectos de software previos. La estructura global de tal!S
modelos toma la forma [MAT94]
E
=A + B
(23-
(evf
donde A , B y e son constantes obtenidas empiricamente, E es el esfuerzo en pers ~

na-mes y ev es la variable de estimacin (ya sea LDC o PF). Adems de la relac: ""
anotada en la ecuacin (23-3). la mayora de los modelos de estimacin tiene al6
na forma de componente de ajuste del proyecto que permite ajustar E por ouis
caracteristicas del proyecto (por ejemplo, complejidad del problema, experiencia
personal, entorno de desarrollo). Entre los muchos modelos de estimacin orier
~ONSUO-
dos a LDC propuestos en la bibliografia se encuentran

(KLDC) 91
lm(plo de estos
E = 5.2
modelos se debe
emplea sil IIIO cof.
lxoci6n a.ma a
E= 5.5 + 0.73 x (LOC)1.16
~ enlomo.
E= 3 2 X (KLDC) 1 os
E
= 5.288 X
(KLOC) 1 457
modelo Walston-Felix
modelo Bailey-Basili
modelo simple de Boehm
modelo Doty para KLDC > 9
Tambin se han propuesto modelos orientados a PF. Entre stos se incluyen:
E = - 91.4 + 0.355 PF
E= - 37 + 0.96 PF
E = - 12.88 + 0.405 PF
modelo de Albrecht y Gaffney

modelo de Kemerer
modelo de regresin para proyecto pequeno
Un rpido examen de estos modelos indica que cada uno producir un result!'.;.
diferente para los mismos valores de LDC o PF. La implicacin es clara. Los m cx;.
los de estimacin deben calibrarse para las necesidades locales!
23. 7 .2
CH iBi :iiii:'"
s- 1
.,,.,,..
WI
(u
.......
........
.......
........
1
....
-CDCDIWll.
El modelo COCOMO U
En su libro clsico acerca de "economia de la ingeniera del software", Barry Boeh[B0E81J introduce una jerarqua de modelos de estimacin de software que lleva .
nombre de COCOMO, por COnstructive cose MOdel (Modelo Constructivo de costos
El modelo COCOMO original se volvi uno de los ms ampliamente utilizados y est
diados modelos de estimacin de costo de software en la industria. Adems, ha e'.
lucionado a un modelo de estimacin ms amplio, llamado COCOMO 11 [BOE
BOEOOJ. Al igual que su predecesor, COCOMO II es en realidad una jerarqua dmodelos de estimacin que aborda las reas siguientes:
CAPTULO 23
ESTIMACIN PARA PROYEC.'OS OE SOFt'WARE
Modelo de composidn de la aplicadn.
711
se emplea durante las primeras etapas
de la ingenieria del software. cuando son primordiales la elaboracin de

prototipos de las interfases de usuario, la consideracin de la interaccin del
software y el sistema, la valoracin del desempeo y la evaluacin de la
madurez de la tecnologa.
Modelo de etapa de diseo temprano. se utiliza una vez que se han estabili-
zado los requisitos y se ha establecido la arquitectura bsica del software.

Modelo de etapa posterior a la arquitectura. Se emplea durante la construccin
del software.
Al igual que los modelos de estimacin del software, los modelos COCOMO II requieren informacin de tamao. Como parte de la jerarqua del modelo hay disponibles
tres opciones diferentes de tamao: puntos objeto, puntos de funcin y lneas de
cdigo fuente.
El modelo COCOMO II de composicin de la aplicacin emplea puntos objeto, una
medida indirecta de software que se calcula mediante conteos del nmero de 1) pantallas (en la interfaz del usuario), 2) reportes y 3) componentes que probablemente
se requieran para construir la aplicacin. Cada instancia de objeto (por ejemplo, una
pantalla o reporte) se clasifica en uno de tres niveles de complejidad (es decir, simple, medio o difcil) aplicando criterios sugeridos por Boehm [B0E96J. En esencia, la
complejidad es una funcin del nmero y origen de las tablas de datos del cliente y
el servidor que se requieren para generar la pantalla o reporte, y el nmero de vistas o secciones presentadas como parte de la pantalla o el informe.
Una vez que se ha determinado la complejidad, el nmero de pantallas, informes
y componentes se pondera de acuerdo con la tabla ilustrada en la figura 23.6.
Entonces se determina la cuenta de puntos objeto al multiplicar el nmero original
de instancias de objeto por el factor de ponderacin en la figura y se suma para obtener una cuenta total de puntos objeto. Al aplicar el desarrollo basado en componentes o la reutilizacin general de software se estima el porcentaje de reutilizacin
(%reut) y se ajusta la cuenta de puntos objeto:
NPO = (puntos objeto) x [(100 - %reut)/I00J
donde NPO se define como nuevos puntos objeto.
Para obtener una estimacin del esfuerzo con base en el valor NPO calculado, se
debe calcular una "tasa de productividad". La figura 23.7 presenta la tasa de productividad
PROD
= NPO/persona-mes
para diferentes niveles de experiencia del desarrollador y madurez del entorno de

desarrollo. Una vez determinada la tasa de productividad se puede obtener una estimacin del esfuerzo del proyecto del modo siguiente:
esfuerzo estimado = NPO/PROD
712
ifrP.61
.....
.......
...._ ele coplellclocl

Medio
. Dtflcll
Tipo ele
Ponderacin de
complejidad
parattposde
objeto [BOE96J.
Pontollo
Repo,..
10
Compo11ente JGL
IMlfiY
Tasa de producttvtdad por puntos objeto [BOE96).
Experiencio/capaciclacl clel
desarrollador
Maclurn/capaciclacl . . entwno
TASA PRODUCTIVIDAD (PROD)
Bajo
Nominal
Alta
Muy
Muy
bojo
Bajo
Nominal
Alta
Muy
..
13
25
50
Muy
bojo
oha
olla
En modelos COCOMO II ms avanzados' se requieren varios factores de esca :a..

controladores de costo y procedimientos de ajuste. El lector interesado debe leef
[BOEOOJ o visitar el sitio Web de COCOMO 11.
23.7.3 La ecuacin del software
biii 1d fr FM 1
En .........
llldl-
...........
......
-- -
......... ,..,
eslilllld6n. -
La ecuacin de software [PUT92] es un modelo multivariable que supone una dist:bucin especfica del esfuerzo a lo largo de la vida de un proyecto de desarrollo e_
software. El modelo procede de datos de productividad recopilados de casi 4 O~

proyectos de software contemporneos. con base en estos datos, un modelo de es::imacin de la forma
E= [LDC x B 333 /PJ3 X (1//:4)
(23--.
., ICIICld6II del
SGflrMR.
donde
E = esfuerzo en personas-mes o personas-ao
t = duracin del proyecto en meses o aos

B
= "factor especial de habilidades"11
1o Como se anot anterionnente, estos modelos utilizan conteos de PF y KLDC para la variable tarnr
11 B aumenta lentamente conforme "crecen la necesidad de integracin, las pruebas, la garantla de c.
lidad, la documentacin y las habilidades de gestin" [PUT92) Para programas pequeos (KLOC a 15), B '" 0.16. Para programas ms grandes que 70 KLDC, B " 0.39.
CAPTULO 23
ESTIMACI N PARA PROnx::ros DE SOFTWARE
= "parmetro
713
de productividadff 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 utilizados, el estado del entorno 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 software anidado de
tiempo real; P = 10 ooo para software de telecomunicaciones y sistemas; P = 28 ooo
para aplicaciones de sistemas de negocios. El parmetro 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 parmetros independientes: 1) una estimacin del tamao (en LDC) y 2) una estimacin de la duracin
del proyecto en meses o aos calendario.
Putnam y Myers [PUT92) sugieren un conjunto de ecuaciones derivadas de la
ecuacin del software para simplificar el proceso de estimacin y emplear una forma
ms comn para su modelo de estimacin. El tiempo mnimo de desarrollo se define como
= 8.14(LDC/P).43 en meses para
tmin > 6 meses

E = l 80Bt3 en personas-mes para E 2: 20 personas-mes
tm;n
(23-5a)
(23-5b)
Ntese que t se representa en aos en la ecuacin (23-5b).

Al utilizar las ecuaciones (23-5) con P = 12 ooo (el valor recomendado para software cientfico) para el software CAD estudiado previamente en este captulo,
tmin
= 8.14(33 200/12 000).43
4nin = 12.6 meses calendario

E= 180 X 0.28 X (l.05) 3
= 58 personas-mes
Los resultados de la ecuacin del software corresponden favorablemente con las

estimaciones desarrolladas en la seccin 23.6. Al igual que el modelo COCOMO
sealado en la seccin precedente, la ecuacin del software ha evolucionado durante la dcada pasada. En [PUT97b] se puede encontrar una detallada exposicin de
una versin extendida de este enfoque de estimacin .
Vale la pena complementar los mtodos convencionales de estimacin de costo del

software con un enfoque diseado explcitamente para software OO. Lorenz y Kidd
[LOR94) sugieren el enfoque siguiente
1. Desarrollar estimaciones aplicando la descomposicin de esfuerzo, anlisis de

PF y cualquier otro mtodo que sea aplicable en aplicaciones convencionales.
714
2. Aplicar el modelado 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 (llamadas clases de anlisis en el capitulo 8).
4. Categorizar el tipo de interfaz para la aplicacin y desarrollar un multiplicad

para las clases de soporte:
Tipo de interfaz
Multiplicador
Sin IUG
2.0
2.25
2.25
Interfaz del usuario basado en texto
IUG
IUG complejo
3.0
Multiplicar el nmero de clases clave (paso 3) por el multiplicador para obtener una estimacin del nmero de clases de soporte.
5. Multiplicar el nmero total de clases (clave + soporte) por el nmero promedio de unidades de trabajo por clase. Lorenz y Kidd sugieren de 15 a 20 pers;>nas-da por clase.
6. Comprobar de manera cruzada la estimacin basada en clase al multiplicar d

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 puedeaplicar en cualquier proyecto de software. Sin embargo, cuando un equipo de so;
ware encuentra una duracin de proyecto extremadamente corta (semanas ms <rmeses) -que probablemente tengan una continua corriente de cambios- la piar~
cacin del proyecto en general y la estimacin en particular se deben abreviar. 1 ~
las secciones siguientes se examinan dos tcnicas de estimacin especializadas.
23.9.1 Estimacin para desarrollo gil

Puesto que los requerimientos para un proyecto gil (capitulo 4) se definen como~
conjunto de escenarios de usuario (por ejemplo, "historias" en programacin extre
ma) es posible desarrollar un enfoque de estimacin informal, aunque razonable
mente 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 q
abarca los pasos siguientes:
12 "Abreviar" no significa eliminar. Incluso los proyectos de corta duracin deben planificarse, y la 5-timacin es el fundamento de la planificacin slida.
CAPTULO 23
ESTIMACIN PARA PROYECroS ot SOFiWARE
715
l. Cada escenario de usuario (el equivaJente de un minicaso de uso creado en el

comienzo mismo de un proyecto por los usuarios finales u otros participantes)
se considera por separado respecto de propsitos de estimacin.
2. El escenario se descompone en el conjunto de funciones y las tareas de ingeniera del software que se requerirn para desarrollarlo.
3a. Cada tarea se estima por separado. Nota: la estimacin se puede basar en datos histricos, en un modelo emprico o en la "experiencia".
3b. Alternativamente, el "volumen" (tamao) del escenario se puede estimar en
09'
LDC, PF o alguna otra medida orientada a volumen (por ejemplo, puntos objeto).
4a. Las estimaciones de cada tarea se suman para crear una estimacin para el
escenario.
4b. Alternativamente, el volumen estimado para el escenario se traduce en esfuerzo mediante la aplicacin de datos histricos.
5. Las estimaciones de esfuerzo acerca de todos los escenarios que se implementarn para un incremento de software dado se suman con el fin de desarrollar el esfuerzo estimado para el incremento.
Puesto que la duracin del proyecto requerido para el desarrollo de un incremento
de software es bastante corta (usualmente de 3-6 semanas), este enfoque de estimacin tiene dos propsitos: 1) asegurar que el nmero de escenarios que se incluirn en el incremento se integra con los recursos disponibles, y 2) establecer una base
para ubicar el esfuerzo conforme se desarrolla el incremento.
23.9.2 Estimacin para proyectos de ingeniera Web

Como se asent en el captulo 16, los proyectos de ingeniera Web con frecuencia
adoptan el modelo de proceso gil. Es factible emplear una medicin de punto de
funcin modificada, en conjunto con los pasos subrayados en la seccin 23.9.1, con
el fin de desarrollar una estimacin para la WebApp.
Roetzheim [ROEOO] sugiere los siguientes valores de dominio de informacin
cuando se adaptan puntos de funcin (captulos 15 y 22) para la estimacin WebApp:
Entradas son cada pantalla o formato de entrada (por ejemplo, CGI o Java),
cada pantaJJa de mantenimiento y, si en alguna parte utiliza una etiqueta de
metfora de cuaderno, cada etiqueta.
Salidas son cada pgina Web esttica, cada guin de pgina Web dinmica
(por ejemplo, ASP, ISAPI u otro guin DHTML) y cada reporte (ya sea que est
basado en Web o sea del todo administrativo).
Tablas son cada tabla lgica en la base de datos ms, si emplea XML para
almacenar datos en un archivo, cada objeto XML (o coleccin de atributos
XML).
716
PARTE CUATRO GESTIN DE PROYECTOS DE S0f1WARE
Las interfaces retienen su definicin como archivos lgicos (por ejemplo,

formatos de registro nicos) en las fronteras exteriores del sistema.
Consultas son cada interfaz publicada externamente o utiliza una interfaz

orientada al mensaje. Un ejemplo tpico son las referencias externas DCOM o
COM.
Los puntos de funcin (calculados empleando los valores de dominio de informacir
anotados) son un indicador razonable del volumen para una WebApp.
Mendes y sus colegas [MENOIJ sugieren que el volumen de una WebApp se determina mejor mediante la recopilacin de medidas (llamadas "variables predictoras
asociadas con la aplicacin (por ejemplo, conteo de pgina, conteo de medios
audiovisuales, conteo de funcin), las caractersticas de su pgina Web (por ejemple
complejidad de pgina, complejidad de vinculacin, complejidad grfica), sus caractersticas de medios audiovisuales (por ejemplo, duracin de los clips) y caractersticas funcionales (por ejemplo, longitud de cdigo, longitud de cdigo reutilizado
Dichas medidas se pueden emplear en el desarrollo de modelos de estimacin emp: -
Estimacin de estuerzo y costo

Obietivo: 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.
Mecnica: En general, las herramientas de estimacin de
costo utilizan uno bose de datos histrica procedente de
proyectos locales, datos recopilados a travs de la
industria y un modelo emprico (por ejemplo, COCOMO 11)
que se empleo para calcular estimaciones de esfuerzo,
duracin y costo. Las caractersticos del proyecto y el
entorno de desarrollo son entrados, y lo herramienta
proporciona un rango de estimacin de salidas.
Costar, desarrollado por Sottstar Systems

(www.softstarsystems.com), emplea el modelo
COCOMO II poro desarrollar estimaciones de
software.
Cost Xpert, desarrollado por Cost Xpert Group, lnc.

(www.costxpert.com), integra modelos de estimacin
mltiples y uno base de datos histrica de proyectos.
Estmate Professional, desarrollado por el Software

Productivity Center, lnc. (www.spc.com). est bosado en
COCOMO II y en el Modelo SLIM.
Knowleclge Plan, desarrollado por Software Productivity
Reseorch (www.spr.com), utilizo lo entrado de punto de
funcin como el controlador primario poro un paquete
de estimacin completo.
Price S, 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 escalo.
SEER/SEM, desarrollado por Golorath lnc.
(www.galoroth.com), proporciona uno capacidad de
estimacin completa, anlisis de sensibilidad,
valoracin de riesgo y otras caractersticas.
SL/M-Estimate, desarrollado por QSM (www.qsm.com),
echa mano de "bases de conocimiento industrial"
detalladas poro 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
CAPTULO 23
717
ESTIMACIN PARA PROYECTOS m: SOFIWARE
rica para esfuerzos de proyecto total, de creacin de pgina, de creacin de medios

audiovisuales y de creacin de guiones. Sin embargo, todava falta realizar ms trabajo antes de que tales modelos puedan emplearse con confianza.
A menudo, en muchas reas de aplicacin de software es ms rentable adquirir que

desarrollar software de computadora. Los gestores de ingeniera del software
enfrentan una decisin de desarrollar-comprar que tal vez se complique an ms por
varias opciones de adquisicin: 1) el software se puede comprar (o adquirir la licencia) ya desarrollado, 2) los componentes de software de "experiencia completa" o
"experiencia parcial" (vase la seccin 23.4.2) se pueden adquirir y luego modificar
e integrar para satisfacer necesidades especficas, o 3) el software se puede construir
de manera personalizada por medio de un contratista externo para satisfacer las
necesidades del comprador.
Los pasos involucrados en la adquisicin los definen lo crucial del software que
se comprar y el costo final. En el anlisis final, la decisin desarrollar-comprar se
realiza basndose en las siguientes condiciones: 1) El producto de software estar
disponible antes que el software desarrollado de manera interna? 2) El costo de
adquisicin ms el costo de personalizacin ser menor que el costo de desarrollar
el software de manera interna? 3) El costo del soporte externo (por ejemplo, un contrato de mantenimiento) ser menor que el costo del soporte interno? Estas condiciones se aplican a cada una de las opciones de adquisicin.
23.10.1 Creacin de un rbol de decisin

Los pasos recin descritos se pueden aumentar mediante tcnicas estadsticas tales
como el anlisis del rbol de decisin [BOE89]. Por ejemplo, la figura 23.8 bosqueja un
rbol de decisin para un sistema basado en software, X. En este caso, la organizacin de ingeniera del software puede 1) construir el sistema X desde cero, 2) reuti / tizar componentes existentes de "experiencia parcial" para construir el sistema, 3)
comprar un producto de software disponible y modificarlo para satisfacer las necesidades locales, o 4) contratar el desarrollo de software con una empresa externa.
Si el sistema se construir desde cero existe un 70 por ciento de probabilidad de
que el trabajo sea dificil. Al emplear las tcnicas de estimacin estudiadas antes en
este captulo, el planificador del proyecto estima que un esfuerzo de desarrollo dificil costar 450 000 dlares. Un esfuerzo de desarrollo "simple" se estima que costar
380 ooo dlares. El valor esperado para el costo, calculado a lo largo de cualquier
rama del rbol de decisin, es
costo esperado
=r
(probabilidad de la ruta)
x 1costo estimado de la ruta),
donde i es la trayectoria del rbol de decisin Para la trayectoria de construccin,

costo esperadOconstruir
= 0.30(380K dbla."'eS) -
0.70(4SOK dlares) = 429K dlares
718
PARTE CUATRO
iihiifi:j
__::=~::.:.:.::!.----=- 380 000 dlares
rbol d e decls16n
para apoyar la
declsi6n
desarrollm
oomprm.
450 000 dlores

275 000 dlares
31 O 000 dlares
Cambias menares
~
.,
Cambias mayares (0.30)
_Y=-----
210 000
dlo
res
400 000 dlares
350 000 dlares
l,Cb'(O)
500 000 dlares
on cam ,as 0.4
Al seguir otras trayectorias del rbol de decisin tambin se muestran, en un..
diversidad de circunstancias, los costos proyectados para reutilizacin, compra
contratacin. Los costos esperados para dichas trayectorias son
costo esperadoreutdiZar
costo esperadOcomprar
costo esperadO.:ontratar
= 0.40(275K dlares) = 0.60[0.20(31 OK dlares) + 0.80(490

dlares)] = 382K dlares
= 0.70(210K dlares) + 0.30(400Kdlares) = 267K dlares
= 0.60(350K dlares) + 0.40(500K dlares) = 4 IOK dlares
Con base en la probabilidad y los costos proyectos que se han anotado en la figur..
23.8, el costo esperado ms bajo es la opcin "comprar".
Sin embargo, es importante sealar que se deben considerar muchos criterios -n...
slo costo- durante el proceso de toma de decisin. Disponibilidad, experiencia de:
desarrollador-vendedor-contratista, concordancia con los requisitos, "pollticas
locales y la probabilidad de cambiar son slo algunos de los criterios que pueder
incidir en la decisin final de construir, reutilizar. comprar o contratar.
23.10.2 Subcontratacln
Tarde o temprano, cualquier compaa que desarrolla software de computadora se:
plantea una pregunta fundamental: existe una forma de conseguir los sistemas .,
software 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: sub
contratacin.
Como concepto. la subcontratacin es extremadamente simple. Las actividades
de ingeniera del software se contratan con una tercera parte que realiza el trabajo
CAPTULO 23
ESTIMACIN PARA PROYECTOS OE SOFTWARE
719
a un costo ms bajo y, as se espera mayor calidad. El trabajo de software llevado a

cabo dentro de una compaa se reduce a una actividad de gestin de contratos. 14
pip. l a ~ requiere induso ms gestin experto que el clesarrolfo en casa;
La decisin de subcontratar puede ser estratgica o tctica. En el mbito estrat-
gico, los gestores comerciales consideran si una porcin significativa de todo el trabajo de software se puede contratar con otros. En el plano tctico, un gestor de proyecto determina si parte o todo un proyecto puede lograrse mejor al subcontratar el
trabajo de software.
Sin importar la amplitud de la visin, la decisin de subcontratar usualmente es
financiera. Una exposicin detallada del anlisis financiero de la subcontratacin
est ms all del mbito de este libro y mejor se deja a otros (por ejemplo, [MIN95)).
Sin embargo, vale la pena una breve revisin de los pros y contras de la decisin.
En el lado positivo, usualmente es factible ahorrar en el costo reduciendo el
nmero de personal de software y las instalaciones (por ejemplo, computadoras,
infraestructura) que los soportan. En el lado negativo, una compaa pierde cierto
control sobre el software que necesita. Dado que el software es una tecnologa que
diferencia sus sistemas, servicios y productos, una compaa corre el riesgo de poner
el destino de su competitividad en las manos de una tercera parte.
t 4 La subcontratacin se puede considerar, ele manera mas ~raJ. como cualquier actividad que con-
duce a la adquisicin de software o algunos ele sus a:a;ioucilles con una fuente externa a la organizacin de ingeniera del software.
720
PARTE CUATRO GESTIN DE PROYECTOS DE S0F1WARE
El planificador del proyecto de software debe estimar tres factores antes de que E.
proyecto comience: cunto tiempo tomar, cunto esfuerzo requerir y cunto personal estar involucrado. Adems, el planificador debe predecir los recursos (hardware y software) que se requerirn y el riesgo involucrado.
La descripcin del mbito ayuda al planificador a desarrollar estimaciones emplea~
do una o ms tcnicas que se clasifican en dos amplias categorlas: descomposia
y modelado emprico.
Las tcnicas de descomposicin requieren un bosquejo de las principales funcnnes del software, seguido por estimaciones de 1) el nmero de LDC, 2) valores sele:-cionados dentro del dominio de informacin, 3) el nmero de casos de uso, 4 d
nmero de personas-mes requerido para implementar cada funcin, o 5) el nmero
de personas-mes requerido para cada actividad de ingenierla del software. Las tc
nicas empricas usan expresiones para esfuerzo y tiempo obtenidas empricamentepara predecir estas cantidades del proyecto. Se pueden utilizar herramientas aut
matizadas para implementar un modelo empirico 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 cola aplicacin de diferentes tcnicas, el planificador tiene ms probabilidad de calcu-
CAPTULO 23
721
lar una estimacin precisa. La estimacin del proyecto de software nunca ser una
ciencia exacta, pero una combinacin de buenos datos histricos y tcnicas sistemticas puede mejorar la precisin de la estimacin.
[BEN92J Bennatan, E. M., Software Project Management: A Practitioner's Approach, McGraw-Hill,

1992.
[BEN03] Bennatan, E. M., "So What is the State of Software Estimation?" en The Cutter Edge (hoja
infonnativa en lnea), 11 de febrero de 2002, disponible en http://www.cutter.com.
[B0E8 l l Boehm, B., Software Engineering Economcs, Prentice-Hall, 1981.
[BOE89J Boehm, B., Risk Management, IEEE computer Society Press, 1989.
[BOE96] Boehm, B., "Anchoring the Software Process", en IEEE Software, vol. 13, nm. 4, julio
de 1996, pp. 73-82.
[BOEOOJ Boehm, B. et al., Software Cost Esrimation n COCOMO ll, Prentice-Hall, 2000.
[BR075] Brooks, F., The Mythcal Man-Month, Addison-Wesley, 1975.
[GAU89J Gause, D. C. y G. M. Weinberg, Exploring Requirements: Quali(Y Before Design, Dorset
House, 1989.
[H0091 J Hooper, J. y R. O. Chester, Software Reuse Guidelines and Methods, Plenum Press, 1991 .
[JON96J Jones, C., "How Software Estimation Tools Work", en American Programmer, vol. 9, nm.
7, julio de 1996, pp. 19-27.
[LOR94J Lorenz, M . y J. Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994.
[MAT94J Matson, J., B. Barrett y J. Mellichamp, "Software Development Cost Estimation Using
Function Points", en IEEE Ttans. Software Engineering, vol. SE-20, nm. 4, abril de 1994, pp.
275-287.
[MCC98) McConnell, S., Software Project Surviva/ Gude, Microsoft Press, 1998.
[MENO!) Mendes, E., N. Mosley y S. Counsell, "Web Metrics-Estimating Design and Authoring
Effort", IEEE Multimeda, enero-marzo de 2001, pp. 50-57.
{MIN95J Minoli, D., Analyzng Outsourcing, McGraw-Hill, 1995.
[PH198J Phillips, D., The Software Project Manager's Handbook, IEEE Computer Society Press,
1998.
[PUT78] Putnam, L., "A General Empirical Solution to the Macro Software Sizing and Estimation
Problem", en IEEE Trans. Software Engineering, vol. SE-4, nm. 4, julio de 1978, pp. 345-361.
[PUT92J Putnam, L. y w. Myers, Measures Jor 'EXcellence, Yourdon Press, 1992.
[PUT97a] Putnam, L. y W. Myers, "How Solved Is the Cost Estimation Problem?", en IEEE
Software, noviembre de 1997, pp. 105-107.
[PUT97bJ Putnam, L. y W. Myers, Industrial Strength Software: E.ffective Management Using
Measurement, en IEEE Computer Society Press, 1997.
[ROEOOJ Roetzheim, W., "Estimating Internet Development", en Software Development, agosto de
2000, disponible en http://www.sdmagazine.com/documents/s=741/sdm0008d/0008d.htm.
[SMI99] Smith, J., "The Estimation of Effort Based on Use Cases", Rational Software Corp., 1999,
se puede descargar de http://wwwrational.com/ media/ whitepapers/finalTPl 71.PDF.
23. l. Suponga que es el gestor de proyecto de una compaa que construye software para
robots caseros. Se le ha contratado para construir el software destinado a un robot que corta el
pasto. Describa por escrito el mbito del software. Asegrese de que la descripcin del mbito
est acotada. Si no est familiarizado con los robots, investigue un poco antes de comenzar a
escribir. Adems, establezca sus suposiciones acerca del hardware que se requerir.
Alternativa: sustituya el robot que corta el pasto por otro problema robtico que le interese.
23.2. La complejidad del proyecto de software illlluye en la precisin de la estimacin.
Desarrollar una lista de caractersticas de so!tv.~ (Par' ejemplo. operacin concurrente, salida
grfica) que afecten la complejidad de wt p r ~ EstahJecer prioridades en la lista.
722
PARTE CUATRO
GESTIN DE PROYECl'OS DE SOFTWARE
23.3. El desempeo es una consideracin importante durante la planificacin. comentar c1

se puede interpretar de manera diferente el desempeo, dependiendo del rea de aplicacin
software.
23.4. Haga una descomposicin funcional del software robtica que describi en el prob1t:
23.1. Estime el tamao de cada funcin en LDC. Suponga que su organizacin produce "
LDC/pm con una escala salarial de 7 000 dlares por persona-mes. Estime el esfuerzo y c
requeridos para construir el software empleando la tcnica de estimacin basada en LDC c!.::scrita en este capitulo.
23.5. Emplear el modelo COCOMO II en la estimacin del esfuerzo que requiere la construc
del software para una simple ATM que produce 12 pantallas, 1o reportes y requerir aproxima.:..Jmente 80 componentes de software. suponer complejidad promedio y madurez desarrolla.:.
entorno promedio. Emplear el modelo de composicin de aplicacin con puntos objeto.
23.6. Utilizar la ecuacin del software para estimar el software del robot que corta pasto
problema 23.1. Suponer que las ecuaciones (23-5) son aplicables y que P .. 8000.
23.7. Comparar las estimaciones de esfuerzo obtenidas en los problemas 23.4 y 23.6. Cu...
la desviacin estndar y cmo afecta el grado de certidumbre acerca de la estimacin?
es
23.8. Utilizar los resultados obtenidos en el problema 23. 7 para determinar si es razona'bk
esperar que el software se construya dentro de los siguientes seis meses y cunto personal se
tendria que emplear para realizar el trabajo.
23.9. Desarrollar un modelo de hojas de clculo que implemente una o ms de las tcnica de
estimacin descritas en este capitulo. Alternativamente, adquirir de fuentes basadas en Wct:
uno o ms modelos en lnea para la estimacin de proyectos de software.
23.10. Para un equipo de proyecto, desarrollar una herramienta de software que implem~
cada una de las tcnicas de estimacin desarrolladas en este capitulo.
23.11. Parece extrao que las estimaciones de costo y programa de trabajo se desarro k::!
durante la planificacin del proyecto de software, antes de que se haya llevado a cabo un <i.seo o un anlisis detallado de los requisitos de software. Por qu cree que se haga esto? ~
circunstancias en las cuales no se deba hacer?
23.12. Vuelva a calcular los valores anotados para el rbol de decisin en la figura 21
Suponga que cada rama tiene una probabilidad de 50-50. Esto cambiarla su decisin final~
La mayora de los libros de gestin de proyectos de software incluyen anlisis de la estima
de proyectos. El Project Management lnstitute (PMBOK Guide, PMI, 2001). Wysoki y sus colt:gas
(Effective Project Management, Wiley, 2000), Lewis (Project Planning Scheduling and Control. tercera edicin, McGraw-Hill, 2000), Bennatan (On Time, Within Budget: Software Pro,:t
Management Practices and Techmques, tercera edicin, Wiley, 2000) y Phillips [PHl98J ofrecen nles directrices de estimacin.
Jones (Estimating Software Costs, McGraw-Hill, 1998) ha escrito uno de los tratamientos ms
completos de la materia publicados a la fecha. Su libro contiene modelos y datos aplicables ;a
estimaciones de software en cualquier dominio de aplicacin. Coombs (/T Project Estimatlr.
Cambridge University Press, 2002), Roetzheim y Beasley (Software Project Cost and Sched 1:
Estimating: Best Practices, Prentice-HaU, 1997) y Wellman (Software Costing, Prentice-Hall, 1gqr,
presentan muchos modelos tiles y sugieren directrices paso a paso para generar las mejores
estimaciones posibles.
El detallado tratamiento de Putnam y Myers de la estimacin de costo del software ([PU"N:
y [PUT97b]) y tos libros de Boehm acerca de economa de ingenieria del software (fB0E81 J
COCOMO 11 [BOEOO)) describen modelos de estimacin empricos. Estos libros proporcionan i=
anlisis detallado de datos derivados de cientos de proyectos de software. Un libro excelente de
CAPTULO 23
723
DeMarco (Controlling Software Projects, Yourdon Press, 1982) ofrece un valiosa visin de gestin,
medicin y estimacin de proyectos de software. Lorenz y Kidd (Object-Oriented Software
Metrics, Prentice-Hall, 1994) y Cockbum (Surviving Object-Oriented Projects. Addison-Wesley,
1998) consideran la estimacin para sistemas orientados a objetos.
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de estimacin de software. Una lista actualizada de referencias en la World Wide Web se encuentra en
el sitio Web de SEPA:
CAPTULO
24
CONCEPTOS
CLAVE
on65sls
del~ ...737
cronogranos . .73&
.-v11PNR .. 730
demora .. .72S
cllstribudn de
esfverzo .. J32
ptrsC!IIQI y
esfuerzo . 729
p"""los
llsicos ... .728
red de tortCI$ . .73S
r....._.ode
tareas . , .. .734
JeflIINl10 .739
tiolHGxi,,g .. .740
,olor ,-lo . .742
724
(ALENDARIZACIN
DE PROYECTOS DE SOFTWARE
finales de los de los aos 60, un joven y brillante ingeniero fue elegid
pata "escribir" un programa de computadora para una aplicacin indus
rial automatizada La rc1zn por la cual se le eligi fue simple: era la
ca persona en el grup<;> tcnico que haba asistido a un seminario de programa
cin de computadoras. l conocla las entradas y salidas del lenguaje ensamb
dor y de FORTRAN, pero nada acerca de ingeniera del software, e incluso me
nos acerca de calendarizacin y seguimiento de proyectos.
su jefe le dio los manuales apropiados y una descripcin verbal de lo que te
na que hacer. Se le infonn que el proyecto deba terminarse en dos meses
El ngenero ley los manuales, consider su enfoque y comenz a escribir
cdigo. Despus de dos semanas, el jefe lo llam a su oficina y le pregunt cmo iban las cosas,
"Realmente bien", dijo el joven ingeniero con entusiasmo juvenil. "Esto fi
mucho ms simple de lo que pens. Probablemente he terminado cerca del
por ciento."
El jefe sonri y alent al joven ingeniero a segulr trabajando bien. Planeara;:
reunirse de nuevo en una semana.
Una semana despus, el jefe llam al ingeniero a su oficina y le pregun
"Dnde estamos?"
"Todo marcha bien", dijo el joven, "pero me he encontrado con algunos pequ
os obstculos Los solucionar y regresar al ritmo de trabajo muy pronto."
"Cmo ves la fecha lmite?'', pregunt el Jefe.
CAPTULO 24
CALENDARIZAON DE PROYECra; DE SOFTWARE
725
"No hay problema", dijo el ingeniero. "Estoy cerca de terminar el 90 por ciento."
Si se ha trabajado en el mundo del software durante unos cuantos aos se es capaz de terminar la historia. No ser sorpresa que el joven ingeniero 1 haya permanecido en el 90 por ciento durante todo el proyecto y terminado (con la ayuda de otros)
un mes despus.
Esta historia se ha repetido decenas de miles de veces con desarrolladores de
software durante las pasadas cuatro dcadas. La gran pregunta es por qu.
Aunque existen muchas razones por las cuales el software se entrega con retraso, la
mayora se encuadra en una o ms de las siguientes causas:
una fecha lmite irrealizable establecida por alguien externo al grupo de ingenieria del software e impuesta a los gestores y profesionales del grupo.
Cambio en los requisitos del cliente que no se reflejan en modificaciones a la
calendarizacin.
Una subestimacin razonable de la cantidad de esfuerzo o de recursos que se
requerirn para realizar el trabajo.
Riesgos predecibles o impredecibles que no se consideraron cuando comenz
el proyecto.
Dificultades tcnicas que no pudieron preverse.
Dificultades humanas imprevisibles.
Falta de comunicacin entre el personal del proyecto, lo que genera demoras.
Una falla en la gestin del proyecto porque no reconoci el retraso ni emprendi una accin para corregir el problema.
1 En caso de que el lector se lo pregunte, ta historia es autobiogrfica.
726
PARTE CUATRO GfSl'IN OE PROYECTOS OE S0f1WARE
.......
" l a ~ excesivas oirracionoles probablemente son lo fuerzo parliallar m6s sarudht.t
Las fechas lmite muy audaces (lase "irrealizables") son un hecho de la vida en d
negocio del software. En tales ocasiones las fechas limite se demandan por razon1.
legtimas, desde el punto de vista de la persona que las establece. Pero el sentido c
mn establece que la legitimidad tambin la deben advertir las personas que hac1.,
el trabajo.
Napolen dijo alguna vez: "Cualquier comandante en jefe que pretenda llevar a
cabo un plan que considera defectuoso comete un error; debe exponer sus razone
insistir en que el plan debe cambiarse y finalmente presentar su renuncia en lug..:.r
de ser el instrumento de la destruccin de su ejrcito". Estas son palabras fuertes q.. e
muchos gestores de proyectos de software deben considerar.
Las actividades de estimacin estudiadas en el captulo 23 y las tcnicas de caler
darizacin descritas en ste con frecuencia se implementan atendiendo la restril.
cin de una fecha lmite definida. Si las mejores estimaciones indican que la fed l
limite es irrealizable, un gestor de proyecto competente debe "proteger a su equ1r>
de la presin excesiva [de la calendarizacin] ... [y] devolver la presin a quienes a
originan" [PAG85].
Para ilustrarlo, supngase que a un equipo de ingeniera del software se le ha pe. dido construir un controlador en tiempo real para un instrumento de diagnst. .>
mdico que ser introducido al mercado en nueve meses. Despus de una estimacin y un anlisis de riesgo cuidadosos (capitulo 25), el gestor del proyecto llega a ::
conclusin de que el software, como se solicit, requerir 14 meses para crearlo co:el personal disponible. Cmo procede el gestor del proyecto?
[ .... ~ ....~- ...... - ...... ,,holodl,o,..,.,,..,

Es irreal presentarse en la oficina del cliente (en este caso el probable cliente ec;
mercadotecnia-ventas) y demandarle que cambie la fecha de entrega. Las presiones
externas del mercado han dictado la fecha, y el producto debe liberarse. Es igual
mente torpe rechazar el trabajo (desde el punto de vista profesional). As! que, que
hacer? En esta situacin se recomiendan los siguientes pasos:
1. Realizar una estimacin detallada empleando datos histricos de proyectos

previos. Determinar el esfuerzo y la duracin estimados para el proyecto.
2. Aplicar un modelo de proceso incremental (captulo 3) y desarrollar una estrategia de ingeniera de software que entregar la funcionalidad crtica en la fecha lmite impuesta, pero demorar otra. Documente el plan.
CAPTULO 24 CALENDARIZAC!N DE PROYlCTOS DE SOFTWARE
Qu se
debe hacer
..to la gestin
..ta quese
aapla con vna
Ida timite qve
111 illlposible?
727
3. Reunirse con el cliente y, con la estimacin detallada, explicarle por qu la fecha lmite impuesta es irrealizable. Asegrese de sealar que todas las estimaciones estn basadas sobre el desempeo en proyectos previos. Tambin
asegrese de indicar el porcentaje de mejora que se requerira para lograr la fecha lmite vigente. 2 Son apropiados los siguientes comentarios:
"Creo que podemos tener un problema con la fecha de entrega para el software controlador XYZ. Le he dado a cada uno de ustedes un anlisis abreviado de
las tasas de produccin en proyectos previos y una estimacin que hemos hecho en algunas formas diferentes. Notarn que he supuesto un 20 por ciento de
mejora respecto de ritmos de produccin precedentes, pero todava tenemos
una fecha de entrega que est a 14 meses en lugar de 9."
4 . Ofrezca la estrategia de desarrollo incremental como alternativa:
"Tenemos unas cuantas opciones y me gustara que tomase una decisin con
base en ellas. Primero, podemos aumentar el presupuesto y conseguir recursos adicionales de modo que tendremos mucho xito en lograr que este trabajo est hecho en nueve meses. Pero comprenda que esto aumentar el riesgo
de una calidad deficiente debido a la apretada fecha lmite.3 Segundo, podemos
remover varias de las funciones y capacidades de software que est solicitando. Esto har que la versin preliminar del producto sea un poco menos funcional, pero podemos anunciar toda la funcionalidad y luego entregarla en el
periodo de 14 meses. Tercero, podemos prescindir de la realidad y esperar que
el proyecto se complete en nueve meses. Terminaremos con nada que se pueda entregar a un cliente. La tercera opcin, espero que est de acuerdo, es inaceptable. La historia y nuestras mejores estimaciones indican que es irreal y un
boleto hacia el desastre."
Habr algunos gruidos, pero si se presentan estimaciones slidas basadas en
buenos datos histricos es probable que se elegirn versiones negociadas de las opciones I o 2. La fecha lmite irreal se evapora.
A Fred Brooks, el bien conocido autor de The Mythical Man-Month (BR095]. se Je pregunt una vez cmo se retrasaban los proyectos de software en la calendarizacin.
su respuesta fue tan simple como profunda: "Un da a la vez."
2 Si la mejora requerida es de 1Oa 25 por oento, de hecho tal vez sea posible tener listo el trabajo.
Pero, con mayor probabilidad, la mejora requenda en el desempeo del equipo ser mayor que el
50 por ciento. Esta es una expectativa inea1
3 Tambin puede agregar que el aumento en d 11':lClerode personas no reduce proporcionalmente
el tiempo.
728
Las tureos requeridas

poro logro, el obetivo
de uno gestin de
proyecto no se deben
llevar acabo manua~
mente. Existen
muchas excelentes
herramientas de
calendorizan.
selas.
PARTE C UATRO
GE"STIN DE PROYECTOS DE SOPTWARE
La realidad de un proyecto tcnico (ya sea que involucre la construccin de una

planta hidroelctrica o el desarrollo de un sistema operativo) es que cientos de pequeas tareas deben realizarse para lograr una meta mayor. Algunas de tales tareas
estn fuera de la corriente principal y se pueden completar sin preocuparse acerca

de su impacto sobre la fecha de terminacin del proyecto. Otras tareas se encuentran en la "trayectoria critica". Si estas tareas "crticas" se retrasan en la calendarizacin, la fecha de terminacin del proyecto se pone en riesgo.
El objetivo del gestor es definir todas las tareas del proyecto, construir una red que
bosqueje sus interdependencias, identificar las tareas cruciales dentro de la red y luego seguir su progreso para garantizar que la demora se reconoce "un dia a la vez
Para lograrlo el gestor debe tener una calendarizacin que se haya definido en u:grado de resolucin que permita supervisar el progreso y controlar el proyecto.
La calendarizacin del proyecto de software es una actividad que distribuye estima-
ciones de esfuerzo a travs de la duracin planificada del proyecto al asignar el esfuerzo a tareas especficas de ingeniera del software. Sin embargo, es importante
sealar que la calendarizacin evoluciona a lo largo del tiempo. Durante las primeras etapas de la planificacin del proyecto se desarrolla una calendarizacin macroscpica. Este tipo de calendarizacin identifica las principales actividades del marco
de trabajo del proceso y las funciones de producto a las que se aplican. Conforme e
proyecto transcurre, cada entrada en la calendarizacin macroscpica se refina er
una calendarizacin detallada. Aqu se identifican y calendarizan tareas especficas
del software (requeridas para completar una actividad).
"11111 mlendarizacili demasiado optimista no genero uno colendarizocin reol lll(J$ mta, $IIO una ._.,,.
'
Slwt
acc.:r-
La calendarzacin para proyectos de ingeniera de software 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 computadora. La organizacin de software est restringida a distribuir esfuerzo dentro del marco temporal prescrito. La segunda visin de la calendarizacin de software supone que se han comentado
limites 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 fmal se define despus de un anlisis cuidadoso del software. Por desgracia, la primera situacin se encuentra con mucha ms frecuencia que la segunda.
24.2.1
Principios bsicos
Al igual que otras reas de ingeniera del software, varios principios bsicos guan la
calendarizacin de los proyectos:
Compartimentacin. El proyecto debe dividirse en compartimentos en varias actividades, acciones y tareas manejables. Lograrlo requiere decomponer tanto el producto como el proceso.
CAPITULO 24
CALENDARIZACIN CE pgora::;os DE SOftWARE
729
Interdependencia. Se debe determinar la interdependencia de cada actividad, accin o tarea compartimentada. Algunas tareas deben ocurrir en secuencia mientras
que otras pueden ocurrir en paralelo. Algunas acciones o actividades no pueden comenzar mientras no est disponible el producto de trabajo producido por otros.
Otras acciones o actividades pueden ocurrir de manera independiente.
Asignacin de tiempo. A cada tarea por calendarizar se le debe asignar cierto nmero de unidades de trabajo (por ejemplo, personas-da de esfuerzo). Adems, a cada 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 trabajo sea realizado con base en
tiempo completo o parcial.
vaHdacin del esfuerzo. 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 nmero de personas calendarizadas. Por ejemplo, considere un proyecto que tiene tres ingenieros de software asignados (por ejemplo, tres personas-da estn disponibles
por da de esfuerzo asignado). 4 En un da dado se deben completar siete tareas al
mismo tiempo. Cada tarea requiere 0.50 personas-da de esfuerzo. Se ha asignado
ms esfuerzo que el nmero de personas para hacer el trabajo.
Dqinicin de responsabilidades. Toda tarea calendarizada se Je debe asignar a un

miembro especfico del equipo.
Definicin de resultados. Toda tarea calendarizada debe tener un resultado definido. En proyectos de software el resultado normalmente 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.
Definicin de hitos. Cualquier tarea o grupo de tareas 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 estos 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 software una sola persona puede analizar
los requisitos, realizar el diseo, generar el cdigo y dirigir las pruebas. Conforme
aumenta el tamao de un proyecto, ms gente resulta involucrada. (Rara vez se
puede dar el lujo de acometer un esfuerzo de I O personas-ao con una persona que
trabaje durante I O aos!)
En realidad, hay disponibles menos de t r e s ~ de esfuerzo debido a las reuniones no relacionadas, enfermedades, vacaciones y una di\"e151dad de otras razones. Sin embargo, para los propsitos del texto, se supone una disponibilidad de 100 pcx cJe11to
730
PARTE CUATRO GESTIN DE PROYECTOS DE SOFl'WARE
Si se deben agregar
persones aun
proyedo re/rosado,
asegrese de que se
les ha osignodo
trobojo enormemente
comportimentado.
ifrU68
Existe un mito comn que todava creen muchos gestores responsables del es
fuerzo de desarrollo del software: "Si nos retrasamos en la calendarizacin, siemr_
podemos incorporar ms programadores y recuperamos ms adelante en el proya
to". Desgraciadamente, agregar ms personas en etapas tardias de un proyecto ce
frecuencia tiene un efecto perturbador sobre ste. lo que provoca que la calendarzacin se desfase an ms. Las personas que se agregan deben aprender el sisterr.;;.
y la gente que les ensea es la misma que estaba haciendo el trabajo. Durante la er
seanza no se realiza trabajo y el proyecto experimenta mayores retrasos.
Adems del tiempo que tarda en aprender el sistema, ms personal aumenta e:.
nmero de rutas de comunicacin y la complejidad de sta a lo largo de un proye..
to. Aunque la comunicacin es absolutamente esencial para el xito del desarro..
de software, cada nueva ruta de comunicacin requiere un esfuerzo adicional y, p...r
lo tanto, tiempo suplementario.
A lo largo de los aos, los datos empricos y el anlisis terico han demostrac.
que las calendarizaciones de proyecto son elsticas. Es decir, es posible comprirren cierta medida la fecha de terminacin deseada del proyecto (al aadir recul"Sf.'5
adicionales). Tambin es posible extender la fecha de terminacin (al reducir el n_
mero de recursos).
La CuNa Putnam-Norden-Rayleigh (PNR) 5 proporciona un indicio de la relacin e-tre el esfuerzo aplicado y el tiempo de entrega para un proyecto de software. En .a
figura 24.1 se muestra una versin de la curva, que representa el esfuerzo del prcyecto como funcin del tiempo de entrega. La curva indica un valor mnimo, t0 , q1..: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 t0 (es decir, conforme intenta acelerar la entrega), la curva se eleva en forma no lineal.
Rela cin entre esfuerzo y tiempo de entrega.
Costo
de
esfuerzo
E0
m (td'4/t0 4)
Eo esfuerzo en personas-mes
td tiempo de entrego nominal poro colendorizor
to = tiempo de entrego ptimo (en trminos de costo)
to = tiempo de entrego real deseado
Tiempo de desarrollo
En [NOR70J y (PUT78) se puede encontrar investigacin original.
CAPTULO 24 CALENDAR!ZAON DE PROYEClOS DE SOFTWARE
~~
C~VE
11 entrego puede
P"lOforse, lo curvo
indico que los
~ del proyecto se
nreducir
~iolmente.
731
Como ejemplo, supngase que un equipo de proyecto ha estimado un nivel de esfuerzo E0 que se requerir para lograr un tiempo de entrega nominal, td, que es ptimo en trminos de calendarizacin y recursos disponibles. Aunque es posible acelerar la entrega, la curva se eleva muy pronunciadamente hacia la izquierda de td. De
hecho, la curva PNR indica que el tiempo de entrega del proyecto no se puede comprimir ms all de 0.75 td. Si se intenta una mayor compresin, el proyecto se mueve 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, t0 = 2td. La implicacin aqui
es que la demora en la entrega del proyecto puede reducir los costos significativamente. Desde luego, esto debe sopesarse frente al costo del negocio asociado con la
demora.
La ecuacin del software [PUT92), introducida en el capitulo 23, se obtiene de la
curva PNR y demuestra la relacin enormemente lineal entre el tiempo cronolgico
para completar un proyecto y el esfuerzo humano aplicado a ste. El nmero de lneas de cdigo entregadas (enunciados fuente), L, se relaciona con el esfuerzo y el
tiempo de desarrollo mediante la ecuacin:
donde E es el esfuerzo de desarrollo en personas-mes; P, un parmetro de productividad que refleja una diversidad de factores que conducen a trabajo de ingeniera del
software de alta calidad (los valores tpicos de P varian entre 2 000 y 12 000); y t, la
duracin del proyecto en meses calendario.
Al reordenar esta ecuacin del software se puede llegar a una expresin para el
esfuerzo de desarrollo E:
(24-1)
donde E es el esfuerzo utilizado (en personas-ao) durante el ciclo de vida para el

desarrollo y mantenimiento de software, y t es el tiempo de desarrollo en aos. La
ecuacin para el esfuerzo de desarrollo se puede relacionar con el costo del desarrollo al incluir un factor de escala salarial (costo/persona-ao).
Esto conduce a unos resultados interesantes. Considrese un complejo proyecto
de software de tiempo real estimado en 33 ooo LDC, 12 personas-ao de esfuerzo.
Si se asignan ocho personas al equipo del proyecto, ste se puede completar en
aproximadamente 1.3 aos. Sin embargo, si se extiende la fecha final a l. 75 aos,
la naturaleza enormemente no lineal del modelo descrito en la ecuacin (24-1) produce:
E= L3 /(P3 t4)
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 obtener beneficios al emplear menos personal durante un periodo un poco ms largo para .lograr el mismo objetivo.
732
24.2.3 Distribucin del esfuerzo

Cmo se
debe distrl
bvir el esfverio a
lo largo del flujo
de trabajo del
proceso de soft
ware?
cada una de las tcnicas de estimacin de proyectos de software estudiadas en e

capitulo 23 conduce a estimaciones de unidades de trabajo (por ejemplo, personas
mes) requeridas para completar el desarrollo del software. Una distribucin reco
mendada del esfuerzo a travs del proceso de software con frecuencia se conoce com
la regla 40-20-40. Cuarenta por ciento de todos los esfuerzos se asignan al anlisis.
el diseo de sistemas de entrada. Un porcentaje similar se aplica en poner a prueb,~
los sistemas de salida. Usted puede inferir correctamente que la codificacin (20 po:
ciento del esfuerzo) no tiene tanto nfasis.
Esta distribucin del esfuerzo se debe usar solamente como gu1a.6 Las caracteris
ticas de cada proyecto deben dictar la distribucin del esfuerzo. El trabajo realizad
en la planeacin del proyecto rara vez explica ms de 2-3 por ciento del esfuerzo, z
menos que el plan comprometa a una organizacin a grandes gastos con alto ries
go. Los anlisis de requisitos pueden comprometer t 0-25 por ciento del esfuerzo de
proyecto. El esfuerzo empleado en el anlisis o elaboracin de prototipos debe au
mentar en proporcin directa con el tamao y la complejidad del proyecto. Un inte valo del 20 al 25 por ciento de esfuerzo normalmente se aplica al diseo de software
Tambin se debe considerar el tiempo utilizado en la revisin del diseo y la subs,
guiente iteracin.
Debido al esfuerzo aplicado al diseo de software, el cdigo debe seguir con re
lativamente poca dificultad. Se puede lograr un rango de 15-20 por ciento del esfuer
zo global. Las pruebas y la subsiguiente depuracin explican el 30-40 por ciento de
esfuerzo de desarrollo del software. El carcter crucial del software con frecuenc
dicta la cantidad de pruebas que se requieren. Si el software se clasifica desde e
punto de vista humano (es decir, la falla del software puede resultar en prdida d\.
vidas), son usuales porcentajes todava ms altos.
En la parte 1 de este libro se describieron varios modelos de proceso diferentes. Sm

importar si un equipo de software elige un modelo secuencial lineal, un modelo incremental, un modelo evolutivo o alguna combinacin, el modelo de proceso est
poblado de un conjunto de tareas que le permiten a un equipo de software definir
desarrollar y, a final de cuentas, brindar soporte al software de computadora.
Ningn conjunto de tareas es apropiado por si solo para todos los proyectos. El
conjunto de tareas que sera apropiado para un sistema complejo y grande probable-
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.
CAPTULO 24 CALENDARIZAON DE PROYECTCS DE SOF'IWARE
733
mente se apreciara como demasiado destructivo para un producto de software pequeo y relativamente simple. En consecuencia, un proceso de software eficaz debe
definir una coleccin de conjuntos de tareas, cada una diseada para satisfacer las
necesidades de diferentes tipos de proyectos.
Como se mencion en el captulo 2, un conjunto de tareas es una coleccin de tareas de trabajo de ingeniera del software, hitos y productos de trabajo que se deben
terminar para completar un proyecto particular. El conjunto cte tareas ctebe propor cionar suficiente disciplina para lograr alta calidad de software. Pero, al mismo tiempo, no debe abrumar al equipo del proyecto con trabajo innecesario.
El desarrollo de una calendarizacin del proyecto requiere distribuir un conjunto
de tareas a Jo largo de la lnea de tiempo del proyecto. El conjunto de tareas variar
segn el tipo de proyecto y el grado de rigor con el que el equipo de software decide realizar su trabajo. Aunque es dificil desarrollar una taxonoma completa de tipos de
proyecto de software, en la mayora de las organizaciones del ramo se encuentran
los siguientes proyectos:
1. Proyectos de desarrollo del concepto, los cuales se inician para explorar algunas
aplicaciones o conceptos de negocios de alguna nueva tecnologa.
2. Proyectos de desarrollo de nuevas aplicaciones, los cuales se llevan a cabo como consecuencia de una solicitud especifica del cliente.
3. Proyectos de mejora de la aplicacin, stos ocurren cuando el software existente experimenta grandes modificaciones en la funcin, el desempeo o las
interfases visibles para el usuario final.
4. Proyectos de mantenimiento de aplicacin, los cuales corrigen, adaptan o extienden el software existente en formas que no sean obvias inmediatamente
para el usuario final.
5. Proyectos de reingenierfa, stos 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 conjunto de tareas. Por ejemplo [PRE99] : tamao del proyecto, nmero de usuarios 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 anidadas y no anidadas, equipo del proyecto y factores de reingeniera. Cuando se consideran en conjunto, estos factores ofrecen un indicio del grado de rigor 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 mediante un modelo de
proceso lineal, secuencial, iterativo (por ejemplo, los modelos de elaboracin de prototipo o incrementales) o evolutivo (por ejemplo, el modelo espiral). En algunos casos,
734
PARTE CUATRO
un tipo de proyecto fluye suavemente hacia el siguiente. Por ejemplo, los proyect..
de desarrollo del concepto que triunfan con frecuencia evolucionan en proyectos e,
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 tanto natural corno predecible y ocurrir sin importar el rnode
de proceso que adopte la organizacin. En consecuencia, las principales tareas G..
ingeniera del software descritas en las secciones que siguen son aplicables a toda
los flujos de modelo de proceso. Corno ejemplo, considrense las tareas de ingenie::
ra del software para un proyecto de desarrollo del concepto.
Los proyectos de desarrollo del concepto se inician cuando se debe explorar el poter
cial para alguna nueva tecnologa. No existe certeza de que la tecnologa ser aplicab.c::
pero un cliente (por ejemplo, marketing) cree que existen beneficios potenciales. Los pr.c
yectos de desarrollo del concepto se enfocan en aplicar las siguientes tareas principales
1.1 La determinacin del mbito del concepto precisa el mbito global del
proyecto.
1.2 La planeacin preliminar del concepto establece la habilidad de la organizacin para acometer el trabajo que entrafia el mbito del proyecto.
1.3 La valoracin del riesgo de la tecnologia evala el riesgo asociado con

la tecnologia que se implementar como parte del mbito del proyecto.
1.4 La prueba del concepto demuestra la viabilidad de una nueva tecnologa

en el contexto del software.
1.5 La implementacin del concepto pone en prctica la representacin del concepto 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 reaccin del diente al concepto solicita realimentacin acerca de un con

cepto de nueva tecnologa y se dirige a aplicaciones especificas de los clientes
Una rpida exploracin de estas tareas debe producir pocas sorpresas. De hecho, e.
flujo de ingenierla del software para los proyectos de desarrollo del concepto (Y tambin para todos los otros tipos de proyectos) es poco ms que sentido comn.
24.3.2 Refinamiento de las tareas principales

Las tareas principales descritas en la seccin precedente se pueden utilizar para definir la calendarizacin macroscpica de un proyecto. Sin embargo, esta calendarizacin se debe refinar para crear una calendarizacin detallada del proyecto. El refinamiento comienza al tomar cada tarea principal y descomponerla en un conjunto
de subtareas (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 bosquejo 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.
CAPTULO 24 CALENDARJZACIN DE PROYECTOS DE SOFTWARE
735
Definicin tarea: Tarea l.1 Determinacin del mbito del concepto

1.1.1
Identificar necesidades, beneficios II olientes potenciales;
1.1.2 Definir eventos de salida/control II entrada deseados que

impulsen la aplicacin;
Comienza Tarea 1.1.2
1.1.2.1
RTF: Revisar la descripcin escrita de la necesidad7
1.1.2.2 Derivar una lista de salidas/entradas visibles al cliente

1.1.2.3 RTF: Revisar salidas/entradas con el oliente y modificar conforme se requiera
fintarea Tarea l. l.2
1.1.3 Definir la funcionalidad/comportamiento para cada funcin principal;
Comienza Tarea 1.1.3
1.1.3.1
RTF: Revisar los objetos de datos de salida II entrada derivados en la tarea
1.1.2;
1.1.3.2 Derivar un modelo funciones/comportamientos;
1.1.3.3 RTF: Revisar funciones/comportamientos con el oliente II modificar conforme se requiera;
fintares Tarea 1.1.3
1.1.4 Aislar aquellos elementos de la tecnologa que se implementar en el software;
1.1.5 Disponibilidad de investigacin del software existente;
1.1.6 Definir factibilidad tcnica;
1.1.7 Realizar estimacin rpida del tamao;
l.1.8 Crear una Definicin del mbito;
fintare& definicin: Tarea 1.1
Las tareas y subtareas anotadas en el proceso de refinamiento del lenguaje de diseo forman la base de una planeacin detallada de la actividad de determinar el
mbito del concepto.
f '
Las tareas y subtareas individuales tienen interdependencias basadas en su secuencia. Adems, cuando ms de una persona est involucrada en un proyecto de ingeniera del software, es probable que las actividades y tareas de desarrollo se realicen
en paralelo. Cuando esto ocurre, las tareas concurrentes deben estar coordinadas
de modo que se completarn cuando las tareas posteriores requieran sus productos de
trabajo.
Una red de tareas, tambin denominada red de actividad, es una representacin
grfica del flujo de tareas en un proyecto. En ocasiones se utiliza como el mecanismo mediante el cual la secuencia y dependencias de tareas son la entrada a una herramienta automatizada de calendazacin del proyecto. En su forma ms simple
7 RTF indica que se debe realizar una revision tttn::rll fa:ca1 (capttulo 26)
736
PARTE CUATRO
jflfrij f
Red de tareas para desarrollo del concepto.
GESTIN DE PROYECl'OS DE SOFTWARE
Peterminocr611
6mbito
l.
'Reaion
diente
(empleada cuando se crea una calendarizacin macroscpica), la red de tareas

muestra las principales tareas de la ingeniera del software. La figura 24.2 muestra
una red de tareas esquemtica para un proyecto de desarrollo del concepto.
La naturaleza concurrente de las actividades de ingeniera del software conduct:
a varios requisitos importantes de la calendarizacin. Puesto que las tareas paralelas ocurren de manera asncrona, el planificador debe determinar dependencias intertareas para asegurar el progreso continuo hacia la finalizacin. Adems, el gesto.del proyecto debe estar atento a estas tareas que se encuentran en la ruta crtica. Esto es, las tareas que se deben completar en la calendarizacin si el proyecto come
un todo se debe completar a tiempo. Ms adelante en este capitulo se tratan con ms
detalle estos temas.
Es importante notar que la red de tareas mostrada en la figura 24.2 es macroscr
pica. En una red de tareas 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 mostrar todas las tareas detalladas en el refinamiento de las tareas
1.1 . mostradas en la seccin 24.3.2.
La calendarizacin de un proyecto de software no difiere enormemente de la de
cualquier esfuerzo de ingeniera multitarea. En consecuencia, las tcnicas y herramientas generalizadas de calendarizacin de proyecto se pueden aplicar, poco modificadas, en proyectos de software.
La tcnica de evaluacin y revisin de programa (PERT, por sus siglas en ingls) y el
mtodo de ruta crtica (CPM, por sus siglas en ingls) son dos mtodos de calendarizacin de proyecto que se pueden aplicar al desarrollo de software. Ambas tcnicas
CAPTULO 24 CALENDARIZACIN DE PROYECTOS DE SOFIWARE
737
reciben impulso de la informacin ya desarrollada en actividades tempranas de la

planeacin del proyecto:
Estimacin del esfuerzo.
Descomposicin de la funcin del producto.
Seleccin del modelo de proceso y conjunto de tareas apropiados.
Descomposicin de tareas.
Las interdependencias entre las tareas se pueden definir empleando una red de tareas. Las tareas, en ocasiones llamadas la estructura de anlisis del trabajo (EAT, por
sus siglas en ingls), se definen para el producto como un todo o para funciones individuales.
,,.lt .,e tenemos que dedir es qu hacer con el tiempo quenos hon dado."
Gandalf en 8 s,w tlt Jos .-.S: t. Mlltl *11., illt
Tanto PERT como CPM ofrecen herramientas cuantitativas que permiten al planificador de software J) determinar la trayectoria crtica: la cadena de tareas que determinan la duracin del proyecto; 2) establecer las estimaciones de tiempo "ms
probables" para tareas individuales al aplicar modelos estadisticos; y 3) calcular los
"tiempos lmite" que definen una "ventana" de tiempo para una tarea particular.
fl!'IIIIIII
Calendarizacin de proyectos
liiiiil
Objetivo: El objetivo de las herramientas de

calendarizacin de proyectos es permitir que un
:,estor defina las tareas de trabajo, establezca sus dependencias, asigne recursos humanos a las tareas y desarrolle
JllO varedad de grficos, diag ramas y tablas que auxilian
en el seguimiento y el control del proyecto de software.
Mecnica: En general, los herramientas de colendarizacin de proyectos requieren la especificacin de una es'nJclura de a nlisis de trabajo o lo generacin de una red
de toreas. Una vez que se define el anlisis de la tarea (un
bosquejo) o red, a codo toreo se ligan fechas de inicio y fin,
recursos humanos, fechas lmite duras y otros datos. Entonces la herramienta genera una variedad de cronogramas y
otras tablas que le permiten a un gestor valorar el Rujo de
tareas de un proyecto. Dichos datos pueden actualizarse de
manera continua conforme el proyecto se lleva a cabo.
AM5 Rea/time, desarrollada por Advonced Management

Systems (www.amsusa.com), ofrece capacidades de calendarizacin para proyectos de todos los tamaos y tipos.
Microsoft Proect, desarrollada por Microsoft (www.microsoft.com), es la herramienta de calendarizacin de proyectos basada en PC ms ampliamente usada.
Viewpoint, desarrollada por Artemis lnternation Solutions
Corp. (www.atemispm.com), soporta todos los aspectos
de la planificacin del proyecto, incluso la calendarizacn.
Uno t.w dela1lada de empresas y productos de software

de gestin de proyectos se puede encontrar en www.infogoal.com/ pmc/ pmcswr.htrn.
Las herramientas expuestas representan U!lli ll'..aestr.l de esta categora En casi todos los casos los
nombres de las mismas son marcas regtstrad.lsdc&IS respecthos desarrolladores.
738
PARTE CUATRO
24.5.1 Cronogramas
Cuando se crea una calendarizacin de proyecto del software, el planificador
mienza con un conjunto de tareas (la estructura de anlisis del trabajo) . Si se e:
plean herramientas automatizadas, el anlisis del trabajo se introduce como una
de tareas o esbozo de tareas. Entonces se introduce el esfuerzo, la duracin y la
cha de inicio de cada tarea. Adems, las tareas se pueden asignar a individuos esr
cificos.
Como consecuencia de esta entrada, se genera un cronograma, tambin llam~
grfico Gantt. Es posible desarrollar un cronograma para todo el proyecto. De ma
ra alternativa, se pueden desarrollar cronogramas separados para cada funcin
proyecto o para cada individuo que trabaje en l.
Un crooogromo
permitedeterminar
~tnreosse
realizann en unpunto
dado en el tiempo.
UWHR!
La figura 24.3 ilustra el formato de un cronograma. Muestra una parte de la \o,

lendarizacin de un proyecto de software que resalta la tarea de determinacin
mbito del concepto para un producto de software procesador de palabra (PP) "'.'odas las tareas del proyecto (para la determinacin del mbito del concepto) se citan
la columna de la izquierda. Las barras hori zontales indican la duracin de cada .a-
EJemplo de cronograma
Tareas de trabajo
11 ldenlilicor necesidoclos y benehc,oo
R......,.. con d;enln
ldennhcor n:e,idodo y reslTicc,onos del proyecto

E11ablo, enunciado dol producto
Hilo enuncoodo del p,oduc,o dof,nido
1 1 2 o.linir KJl,dos/conol/O<ltroclo, 1sce1 desoodo,
Akooce do los lunc,onos dol 1oclodo
Alcance et. los funciones de entrada de voz
Alcance do los modal do ontwocci6n
Alconca del dognsli<o de d.xvm.nto>
Alcance de o tros fvnc.lof'!e.s del PP
SCf del documento

RTF Rev1116n de SCE con el cl,.nto
Modo~cor SCf confo<mo M requoera
H,lo: SCE c:1.1:n:da,

1. 1.J Definir lo funci6n/comporlomiento
O.finir funciones de *kdo
o.fonir func,.,.,.. de onirodo do YOZ
Oescribir modos de 1nt roeci6n
OtKribir verificoci6n or!'t6fico/gromoticol
Oe>eribir otros fvncia.., 1PP
RTF Rev,.a dehnicin SCE con el d,en1e
Mod1ficor conforme M requi,a
Hito: definlcl6n completa de SCE
1.1.d A,slomiento de elementos de toftwore
H,io elom.nlos de >Oltwo,e de/,nodos
l. 1.~ lnve,h90< d ..ponibolidod de wf1woro ex15lonle
fnvefigor componenfts de ediei6n de texto
ln\'estigor compon-ent.s de entrodo de voz
lnvesligor cornpooonto do odm,noslrocin do orch""'
l,,...tigor componentes de ve,1licoc16n onogrfoco/
gromolicol
l. l 6 Hdo: identiF,cor componenkl.s reu11l1zobles
O.Ion,, focb.lodod lknico
Semona 1
----
Semana 2
Semana 3
Semana4
Semana 5
_l_
_J
,__ r-
ip
fo-
....
fo-
......
fo-
- --t-- , -
e..,1uo, ..,,,odo de vor
Evaluar venficoc,n gramatical

11 7 H,10: foct,bilidod 14cnico ..,10,odo
11 8 EshlftOCin rpldo do lomoo
Croar uno dol,nicin de mbito
Revisor documento dt mbito con el cliente
Modifkor el documento conforme se requiero
" so docu,...nlo de 6tnbolo compl.io
'l-
I=
,__
r-
rr-
CAPTULO 24
739
CALENDARIZAON DE PROYa::TOS DE SOFTWARE
rea. Cuando en el calendario se presentan al mismo tiempo mltiples barras, se implica la concurrencia de la tarea. Los diamantes indican hitos.
Una vez ingresada la informacin necesaria para generar el cronograma, la mayora de las herramientas de calendarizacin de proyectos de software producen tablas de proyecto: una lista tabular de todas las tareas del proyecto, sus fechas de inicio
y conclusin, planeadas y reales, y una variedad de informacin relacionada (figura
24.4). Si se utilizan en conjunto con el cronograma, las tablas de proyecto permiten
que el gestor del proyecto d seguimiento al progreso.
24.5.2 Seguimiento de la calendarizacin

La calendarizacin del proyecto proporciona un mapa de carreteras al gestor del
proyecto de software. Si se ha desarrollado de manera adecuada, la calendarizacin

del proyecto define las tareas e hitos que se deben seguir y controlar conforme avance el proyecto. El seguimiento se puede hacer de diferentes maneras:
Con la realizacin peridica de reuniones para valorar el estado del proyecto
en las cuales cada uno de los miembros del equipo informa del progreso y los
problemas.
Con la evaluacin de los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniera del software.
Con la determinacin de si se han logrado los hitos formales del proyecto en
la fecha programada (los diamantes que se muestran en la figura 24.3).
Al comparar la fecha de inicio real con la fecha de inicio prevista para cada
tarea del proyecto mencionada en la tabla de recursos (figura 24.4).
Ejemplo de tabla de recursos.
ldeotili<or -..;dadn y b<;nelld(;1

....,lr
..
lde<,ta~ ,._,~,y t!!Jlri~~
Cl)ll'looc~
qel
P'<!Jl'ldO
~ o r ~ 4el1*odu<:1o
ffilo . .uncl<ldo do,! plOdclo ~
'
o.lintr sollda./conll'l/~... 1scf) "-o~,
Aleone; d. kl. f,,nctc-J dl>t ~
loonc dt lqo func~ et. on,r<ld o. !(~
AlcOllce .i. !<,o m~ et. mi..oc~
Ako- d,ol dlag,l6"" .i. d1><u~mo
AJ,:.,... d. o4Jo, lnc<>ne del l!P

Oocumenlo $CE
Rlf: ,evij\(\ i;. sq 900 .! e ~

ModtfcorS(;t: ~ ._ ..,....,
lttto:.SCE~
3 Do6mr la func:in/cornpo,laml-
llllffll,dl
"'"' l,d?
"""1,d2
<eml,d3
so..CUt3
5llm 1,.,3
ien, l,d3
..... l,d:J
' ..... l. &,e
., emZ,d?
!t<ffll),dl
"""l.dZ Ml(l>l,<12
"""11,c/3
.....
,.c/3
,eml,~3
,-l,d3
..... 1.d.d
em l,d2
,,m2,d2
m z, d3
se<i12,d2
em2, d3
sen,2,dl
,em2.d3
sem 2. d.t
Hrn2,dS
sem 1;d2
l.a delerminocin
del mbito
,oqveir<I m6,
fuerzo/!.empo
740
PARTE CUATRO GESTIN DE PROYECJ'OS DE SOFTWARE
Al reunirse de manera informal con los trabajadores para obtener su evaluacin subjetiva del progreso hasta la fecha y los problemas que se vislumbran
Con el uso del anlisis del valor obtenido (seccin 24.6) para evaluar el progreso cuantitativamente.
En realidad, todas estas tcnicas de seguimiento las utilizan los gestores de proyec
to experimentados.
El control lo emplea el gestor del proyecto para administrar los recursos del pro-
El me;o, indicador de
progreso es lo termt
nocin yrevisin
exitoso de un
producto de trabojo de
sohwu,e definido.
yecto, lidiar con los problemas y dirigir al personal del proyecto. Si las cosas van b
(es decir, el proyecto est dentro del calendario y del presupuesto, las revisiones
dican que se est realizando un progreso real y que los hitos se han alcanzado
control es ligero. Pero cuando ocurren problemas, el gestor del proyecto debe e
cer control para solucionarlos tan pronto como sea posible. Cuando se haya d
nosticado el problema se destinan recursos adicionales al rea correspondiente reu-bicando personal o redefiniendo la calendarizacin.
Cuando enfrentan severas presiones por ta fecha limite, tos gestores de proyect:
experimentados en ocasiones emplean una catendarizacin de proyecto y tcnica
control llamada time-boxing (encajonamiento de tiempo) [ZAH95) . Esta estrategia reconoce que el producto completo no podr entregarse en ta fecha limite programa-e
da. Por lo tanto, se elige un paradigma de software incremental (captulo 3) y se
bora una calendarizacin para cada entrega incremental.
Entonces se encajonan en el tiempo tas tareas asociadas con cada increm
Esto significa que la calendarizacin para cada tarea se ajusta al trabajar hacia a::
desde la fecha de entrega para cada incremento. Se coloca una "caja" alreded<X
cada tarea. Cuando una tarea se acerca al lmite de su caja de tiempo (ms o me:10 por ciento), et trabajo se detiene y comienza ta siguiente tarea.
La reaccin inicial al enfoque del encajonamiento de tiempo usualmente es neg,:tiva: si et trabajo se termina, cmo se proceder? La respuesta se encuentra en
forma en se realiza el trabajo. Cuando se llegue al lmite de la caja de tiempo, es
bable que se haya completado9 90 por ciento de la tarea. El restante 10 por cien::
aunque importante, puede 1) demorarse hasta et siguiente incremento o 2) corn;e
tarse ms tarde si se requiere. Ms que quedarse "empantanado" en ta tarea, el p-m
yecto avanza hacia ta fecha de entrega.
Un cinico puede recordar el dicho: el 90 por ciento del sistema toma I Opor ciento del tiempo. e
tante t O por ciento del sistema toma 90 por ciento del tiempo.
-=
CAPTULO 24 CALENDARIZAClN IX ffl:)ta..os IX SOFTWARE
74 1
24.5.3 Seguimiento del progreso en un proyecto 00

Aunque un modelo iterativo es el mejor marco de trabajo para un proyecto 00, el
paralelismo de las tareas dificulta el seguimiento del proyecto. El gestor del proyecto puede tener dificultades al establecer hitos significativos para un proyecto 00 debido a varias cosas diferentes que ocurren a la vez. En general, los siguientes hitos
principales se pueden considerar "completados" cuando se alcanzan los criterios
anotados.
Hitos tcnicos: anlisis 00 completado

se han definido y revisado todas las clases y la jerarqua de clase.
Se han definido y revisado los atributos de clase y las operaciones asociadas
con una clase.
se han establecido y revisado las relaciones de clase (captulo 8).
se ha creado y revisado un modelo de comportamiento (captulo 8).
Se han anotado las clases reutilizables.
Hitos tcnicos: diseo 00 completado

Se ha definido y revisado el conjunto de subsistemas (capitulo 9).
Las clases se han revisado y asignado a los subsistemas.
Se ha establecido y revisado la asignacin de tareas.
Se han identificado las responsabilidades y colaboraciones (captulos 8 y 9).
se ha creado y revisado el diseo de las clases.
Se ha creado y revisado el modelo de comunicacin.
Hitos tcnicos: programadn oo completada

Cada nueva clase se ha implementado en cdigo a partir del modelo de diseo.
se han implementado las clases obtenidas (de una librera de reutilizacin).
Se ha construido el prototipo o incremento.
Hitos tcnicos: prueba 00

Se han revisado la correccin y que estn completos el anlisis 00 y los modelos de diseo.
_, depuracin y
;ruebo son simu&rr
'U. Con frecueocio,
ti estado de la depumi se evala al

aXISideror el tipo y
ne,o de errores
oogs) "abiertas.
Se ha desarrollado y revisado una red clase-responsabilidad-colaboracin (captulo 8).

Se han diseado casos de prueba y se han llevado a cabo pruebas al nivel de
clase (captulo 14) para cada ciase.
Se han diseado casos de prueba, se han completado pruebas de agrupamientos (captulo 14) y se han integrado las clases.
Se han completado las pruebas al nivel de sistema.
PARTE CUATRO GESTIN DE PROYF.C'!'O; DE sonwAAE
Recurdese que el modelo de proceso 00 es iterativo, cada uno de estos hitos pi _

de revisarse conforme diferentes incrementos se entreguen al cliente.
Jamie: los cosos son
Vinod: AJl es.

Doug: tOuin hizo ....
24,6 A,uiu111 QIL YA\98 9AMAAA
fe'
C1'VE
El volar ganado onece
un indio ruonlitotivo
del progreso.
En la seccin 24 .5 se trataron algunos enfoques cualitativos en cuanto al seguim,..nto del proyecto. cada uno ofrece al gestor del proyecto un indicio del progreso, pero
una evaluacin de la informacin proporcionada es un poco subjetiva. Es razon~ ~
preguntar si existe una tcnica cuantitativa para evaluar el progreso conforme a
equipo de sotlware avanza a travs de las tareas de trabajo asignadas en la cale- darizacin del proyecto. De hecho, existe una tcnica para realizar anlisis cuantit:tivos del progreso. Se llama anlisis del valor ganado (AVG). Humphrey [HUM 0 r:
comenta el valor ganado en la forma siguiente:
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 horas totales para realizar todo el proyecto y a cada tarea se le da un valor ganado con base en su porcentaje estimado del total.
Enunciado en una forma ms simple, el valor ganado es una medida del progrese
Permite valorar el "porcentaje realizado" de un proyecto reempleando el anlisis
cuantitativo en lugar de apoyarse en una opinin personal. De hecho, Fleming y Kop-
CAPTULO 24 CALENDARlZACIN DE PROYEC'IOS DE SOF'IWARE
743
pleman [FLE98] argumentan que el anlisis del valor ganado "ofrece lecturas precisas y confiables del desempeo desde un momento tan temprano del proyecto como el IS por ciento realizado."
Para determinar el valor ganado se realizan los siguientes pasos:
1. Se determina el costo presupuestado para el trabajo calendarizado (CPTC) respecto de cada tarea de trabajo representada en la calendarizacin. Durante la
estimacin se planifica el trabajo (en personas-hora o personas-da) de cada
tarea de ingeniera. Por lo tanto, CPTe es el esfuerzo palnificado para la tarea
de trabajo i. Para determinar el progreso en un punto dado en la calendarizacin del proyecto, el valor de ePTC es la suma de los valores CPTC; para todas
la tareas de trabajo que deben estar completadas en dicho punto en el tiempo
en la calendarizacin del producto.
2. Los valores CPTC para todas las tareas de trabajo se resumen para obtener el
presupuesto a la tenninacin, PAT. Por lo tanto,
PAT
= I. (PTCkl para todas las tareas k.
3 . A continuacin se calcula el costo presupuestado del trabajo realizado (ePTR).

El valor de CPTR es la suma de los valores CPTC para todas las tareas de trabajo que en realidad se han completado en un punto en el tiempo en la calendarizacin del proyecto.
Wilkens [WIL99] seala que "la distincin entre CPTC y CPTR es que la primera representa el presupuesto de las actividades que se planearon completar, y la ltima,
el presupuesto de las actividades que en realidad se completaron" . Dados los valores de ePTC, PAT y CPTR, se pueden calcular importantes indicadores del progreso:
Indice de desempeo en la calendarizacin, mea = CPTR/ePTC
Varianza en la calendarizacin, ve = ePTR - CPT.C
IDCa es un indicador de la eficiencia con la que el proyecto utiliza los recursos calendarizados. Un valor mea cercano a 1.O indica una ejecucin eficiente del proyecto calendarizado. ve simplemente es un indicador absoluto de la variacin a partir
de la calendarizacin planeada.
Porcentaje calendarizado para terminacin
= CPTC/PAT
ofrece un indicador del porcentaje de trabajo que debe estar completado en el tiempo t.
Porcentaje de completado
= CPTiv PAT
ofrece una indicacin cuantitativa del porcentaje de avance del proyecto en un punto dado en el tiempo, t.
Tambin es posible calcular el costo real del trabaJO realizado, CRTR. El valor para
CRTR es la suma del esfuerzo realmente utilizado en las tareas de trabajo que se han
completado en un punto en el tiempo en la ca!endarizacin del proyecto. Entonces
es posible calcular
744
PARTE CUATRO
Gf.STIN DE PROYECTOS DE SOFIWARE
Indice de desempeo del costo, meo = CPTR/CRTR

Varianza del costo, ve = CPTR - CRTR
Un valor de IDCo cercano a 1.0 ofrece un fuerte indicador de que el proyecto est::
dentro de su presupuesto definido. ve es un indicador absoluto del ahorro en cost:
(contra los costos planeados) o recortes en una etapa particular de un proyecto.
Al igual que un radar en el horizonte, el anlisis del valor ganado ilumina las d.
ficultades en la calendarizacin antes de que puedan advertirse de alguna otra fo:ma. Esto permite que el gestor del proyecto de software tome medidas correctiva;;
antes de que se desarrolle una crisis en el proyecto.
La calendarizacin es la culminacin de una actividad de planificacin que es l.:

componente principal de la gestin del proyecto de software. Cuando se combir.;:.
con mtodos de estimacin y anlisis de riesgo, la calendarizacin establece un map:.
de carreteras para el gestor de proyectos.
La calendarizacin comienza con el proceso de descomposicin. Las caracterst.cas del proyecto se utilizan para adaptar un conjunto de tareas apropiado al traba
que se realizar. Una red de tareas bosqueja cada tarea de ingeniera, su depender
cia de otras tareas y su duracin proyectada. La red de tareas se utiliza para caJCLlar la trayectoria critica, un cronograma y una variedad de informacin del proyecL
Al usar la calendarizacin como gua, el gestor del proyecto puede dar seguimien~
y controlar cada paso en el proceso del software.
[BR095J Brooks, M., The Mythical Man-Month, edicin de aniversario, Addison-Wesley, 1995
[FLE98] Fleming, Q. W., y J. M. Koppelman, "Earned Value Project Management", Crossta/k, v.:.
ll, nm. 7, julio de 1998, p. 19.
[HUM95] Humphrey, W., A Discipline for Software Engineering, Addison-Wesley, 1995.
[NOR70J Norden, P., "Useful Tools for Project Management", en Management of Production, M K.
Starr (ed.), Penguin Books, 1970.
[PAG85) Page-Jones, M., Practica/ Project Management, Dorset House, 1985, pp. 90-91.
[PRE99] Pressman, R. s., Adaptable Process Model, R. S. Pressman & Associates, 1999.
[PUT78] Putnam, L, y W. Myers, Measuresfor Excellence, Yourdon Press, 1992.
[WIL99) Wilkens, T. T., "Eamed Value, Clear and Simple", Primavera systerns, 1 de abril de 1999, p.=.
[ZAH95] Zahniser, R., "Time-boxing for Top Team Performance", en Software Development, ma:
zo de 1995, pp. 34-38.
24.1. Las fechas lmite "irracionales" son un hecho de la vida en el negocio del software. C
mo se debe proceder si se enfrenta con una?
24.2. Cul es la diferencia entre una calendarizacin macroscpica y una calendarizacin detallada? Es posible gestionar un proyecto si slo se desarrolla una calendarizacin macroscpica? Por qu?
CAPTULO 24
CALENDAlliZACIN DE PROYECTOS DE SOFIWARE
745
24.3. Existe algn caso donde un hito de un proyecto de software no est ligado a una revisin? 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 productividad individual (LDC/persona-mes) y el resultado es menor productividad para el equipo. Ilustrar (cuantitativamente) cmo los ingenieros versados en las buenas prcticas de ingenieria 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 2040 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 nmero 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
linea 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 proporcionar 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 para el SRELC. Sugiera cmo:
a)
b)
e)
Definirla las actividades de trabajo paralelas durante el proyecto de SRELC.

Distribuira el esfuerzo a lo largo del proyecto.
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 software 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 calendarizacin para realizar este trabajo.
24.1 O. Si est disponible una herramienta automatizada de calendarizacin, determine la trayectoria critica para la red definida en el problema 24.9.
24.11. Mediante una herramienta de calendarizacin (si est disponible) o papel y lpiz (si es
necesario), desarrolle un cronograma para el proyecto del SRELC.
24.12. suponga que es gestor de proyectos de software y que se le ha pedido calcular las estadsticas 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 calendarizacin del proyecto indica que se tenian que haber completado 15. Estn disponibles los
siguientes datos de la calendarizacin (en personas-da):
Tarea
Esfuerro pmlsto
12.0
Esfwu .....
12.5
746
PARTE CUATRO
GESTIN DE PROYEC!OS DE SOFJWA!lE
Tarea
Esfuerzo previsto
Esfuerzo real
15.0
11.0
13.0
17.0
8.0
9.5
5
6
9.5
18.0
19.0
10.0
10.0
4.0
4.5
9
10
12.0
10.0
6.0
6.5
11
14.0
4.0
12
14.0
14.5
13
16.0
14
6.0
15
B.O
9.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 Gude, PMI, 2001), Wysoki y sus colegas (Ejfectve Project Management, Wiley, 2000), Lewis (Project Planning Schedulng and Control, 3a. ed., McGraw-Hill, 2000), Bennatan (On Time, Within Budget: Sofrvvare Projeci
Management Practces and Techniques. 3a. ed., Wiley, 2000), McConnell (Sofrvvare Projecl Cos.
Survval Guide, Microsoft Press, 1998) y Roetzheim y Beasley (Sofrvvare Project Cost and Schedule
Esdmating: Best Practices, Prentice-Hall, 1997) contienen anlisis valiosos del tema. Boddie
(Crunch Mode, Prenlice-Hall, 1987) ha escrito un libro para todos los gestores que "tienen 90
das para hacer un proyecto de seis meses".
McConnell (Rapid Development, Microsoft Press, 1996) presenta una excelente exposicin de
los conflictos que conducen a calendarizaciones de proyectos de software demasiado optimistas y qu puede hacer acerca de ello. oconnell (How to Run Successful Projects ll: The Si/ver
Bullet, 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 (Usng Eamed value: A Project Manager's Guide, Ashgate Publishing, 2003) y
Fleming y Koppelman (Earned Value Project Management, Project Management Institute Publicatons. 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 calendarizacin de proyectos de software. Una lista actualizada de referencias de la World Wide
Web se puede encontrar en el sitio Web de SEPA:
n su libro acerca del anlisis y la ge.stn de.l nesgo, Robert Charette
CONCEPTOS
(CHA89J presenta una definicin conceptual de riesgo:
CLAVfi:
Gllegoria~
riesgos 749
En primer lu~r. el nesgo se reladona con los acontecirpentos futuros. El hoy y el

ayer estn ms all de esta retacin, pues ya se ba cosechado lo que previamente se.
sembr con nuestras accions pasadas. La pregunta es: podemos, pr tanto, al cam
estrategia
prN<tivq , 148
estrateglca
19diyq .. ' .,
blar nuestras acdones presentes, creat eh lo futuro una oportunidad para una situa
ciOn diferente, y esperanzadoramente meior, para nosotros mismos? Est significa,
en ~egundo lugar, que el riesgo jmplica cambio, como f,:ambios de mentalidad, opinih, acciones o lugai:es... [en tercer lugar el .riesgo imptira eleccin y la incertidumbre que sta conlleva. Por ende, paradjicamente, e) riesgo, al igual que la muerte y
los impuestos, es una de las pocas certezas en la vida,
......_ ..157
cuando el riesgo se considera en el contexto de la ingenierla del software, las

tres bases conceptuales de Charette siempre se evidencian. El futuro es una
preocupacin de primer orden: qu riesgos causaran que el proyecto de software salga mat~ El cambio es una preocupacin central: cmb afectar;) la
actualidad y el xito gfobal los cambis en los requistos. del cliente, las tecnologas de desarrollo, los entornos que .se tienen como objetivo y todas las otras entidades vinculadas con el proyecto? Por ltimo, es necesario enfrentar las opciones:
qu mtodos y herramientas se deben sar, cuntas personas deben estar involucradas. cunto nfasis sobre la calidad es "suficiente"?
Peter Drucker [DRU75J dijo una vez: "Aunque es vano intentar eliminar el
riesgo, y cuestionable intentar minimizarlo, es esencial que los riesgos tomados
sean los riesgos correctos". Antes de identificar los ''rjesgos correctos" que se tomarn durante un proyecto de software, es importante identificar los rtesgos que
son obvios para los gestores y profesionales.
l"Yf(CII 154
....._to ...762
l5GI ........161
-,rilad
ritsgos 763
,....
riesgos ... 7$S
Q" es? El onli$is y lo gestin del
riesgo son uno serie de posos que

owdol\ o un ~uipo de software
comprenoery mhejar lo inc:emdumbre. Muchos problemas pueden des

bordar un proyecto de $0iwore. Un riesgo es
ptlblerna potendol: pvede ocurrir o no Pi
el rewlrodo, en reolidod es
bena idea rdentifi!rlo, evaluar lo probabi
sin mportar
~ad de que <>eurro, estimar sv.impocto y ~
cer un pon de conting~ncid n oosd de que> ef

problema se presente.
Quin lo hace? Todo$ lo$ irwolu.crodos en el
de software {gestores, inJ;1eni.eros y par

ntervienen en el on6hsJ: y k1 gestin
hcq:>anitesJ
Po, que es importante? Pin.sese oo .el lema

scout "estor preparadQ", El software
eso d fcil. Muchos cosos. pveden so
froncameote, con mucho frecuendo lo
747
748
PARTE CUATRO
Las estrategias de riesgo reactivas han sido jocosamente denominadas la "escuela

Indiana Jones de gestin del riesgo" [TH092]. En las peliculas de la dcada de 198
que llevaban su nombre, Indiana Jones, cuando enfrentaba alguna dificultad abrumadora, invariablemente deca: "No te preocupes, pensar en algo!". Al no preocuparse nunca por los problemas, sino hasta que ocurran, Indy reaccionaba en algt..na forma heroica.
"Si ustod no afata diYI!llontelos riesgos, ellos lo atacarn activamente."
Tristemente, el gestor promedio de proyectos de software no es Indiana Jones _

los miembros del equipo de proyecto de software no son sus confiables compaeros. Ms an, la mayora de los equipos de software se apoya exclusivamente en las
estrategias de riesgo reactivas. Los riesgos se apartan para tratarlos, lo que puede
convertirlos en problemas reales. Ms usualmente, el equipo de software no hace
nada acerca de los riesgos hasta que algo sale mal. Entonces el equipo se precipita
en la accin con la finalidad de corregir el problema rpidamente. Con frecuenci a ;
esto se le llama el modo bombero. Cuando esto falla, la "gestin de crisis" [CHA92
asume el control y el proyecto est en un verdadero peligro.
Una estrategia considerablemente ms inteligente para la gestin del riesgo es se
proactivo. Una estrategia proactiva comienza mucho antes de que se inicie el trabajo tcnico. Se identifican los riesgos potenciales, se valoran su probabilidad e impacto, y se les clasifica segn su importancia. Luego, el equipo de software establece ur
plan para gestionar el riesgo. El objetivo principal es evitar el riesgo, pero debido a
que no todos los riesgos pueden evitarse, el equipo trabaja para desarrollar un piar
CAPTULO 25
GESTIN DEL RIESGO
749
de contingencia que le permitir responder en una forma controlada y efectiva. A lo largo del resto del captulo se examina la estrategia proactiva para la gestin del riesgo.
Aunque hay un considerable debate en torno a la definicin propia para el riesgo de

software, existe un acuerdo general en que el riesgo siempre involucra dos caractersticas [HIG95J:
Incertidumbre: el riesgo puede o no ocurrir; esto es, no existen riesgos 10096

probables. 1
Prdida: si el riesgo se convierte en realidad, ocurrirn consecuencias o prdidas indeseables.

Cuando se analizan los riesgos es importante cuantificar el grado de incertidumbre
y el grado de prdida asociado con cada riesgo. Esto se logra considerando diferentes categorias de riesgos.
Qu tipos
ele riesgos
probable
_..,,ar
aforme se
astruye
mftware?
Los riesgos del proyecto amenazan el plan del proyecto. Es decir, si los riesgos del
proyecto se vuelven reales es probable que la calendarizacin del proyecto se altere
y que los costos aumenten. Los riesgos del proyecto identifican potenciales problemas en presupuesto, calendarizacin, personal (plantillas y organizacin), recursos,
participantes y requisitos, y su impacto sobre un proyecto de software. En el captulo 23 la complejidad, tamao y grado de incertidumbre estructural del proyecto tambin se definieron como factores de riesgo del proyecto (y de la estimacin).
Los riesgos
tcnicos amenazan la calidad y actualidad del software que se produ-
cir. Si un riesgo tcnico se vuelve real, la implementacin se torna dificil o imposible. Los riesgos tcnicos identifican potenciales problemas en diseo, implementacin, interfaz, verificacin y mantenimiento. Adems, tambin son factores de riesgo la ambigedad de la especificacin, la incertidumbre tcnica, la obsolescencia
tcnica y la tecnologa "de punta". Los riesgos tcnicos ocurren porque el problema
es ms dificil de resolver de lo que en un principio se pens que sera.
Los riesgos de negocios amenazan la viabilidad del software que se construir. Estos riesgos con frecencia ponen en peligro el proyecto o el producto. Los candidatos
para los cinco mayores riesgos de negocios son 1) la construccin de un producto o
sistema excelente que en realidad nadie quiere (riesgo de mercado). 2) la construccin de un producto que ya no encaja en la estrategia comercial global de la compaa (riesgo de estrategia), 3) la construccin de un producto que la fuerza de ventas
no sabe cmo vender (riesgo de ventas), 4) la prdida del apoyo de los altos ejecutivos debido a un cambio en el enfoque o en el personal (riesgo administrativo), y 5)
la prdida presupuestaria o del personal asignado lriesgo presupuesta!).
1 Un riesgo 100 por ciento probable es una ae.uiccilt sobre el proyecto de software.
750
Es extremadamente importante destacar que la simple clasificacin de los riesgos
no siempre funciona. Algunos riesgos simplemente son impredecibles.

Charette [CHA89] ha propuesto otra categorizacin general de los riesgos. Los
riesgos conocidos son aquellos susceptibles de descubrirse despus de una evaluacin cuidadosa del plan del proyecto, del entorno de negocios y tcnico dentro de los
cuales se desarrollar el proyecto, y otras fuentes de informacin confiables (pe
ejemplo, fechas de entrega irreales, falta de requisitos documentados o de mbito
del software, pobre entorno de desarrollo). Los riesgos predecibles se extrapolan de
la experiencia con proyectos previos (por ejemplo, cambios en el personal, mala comunicacin con el cliente, disminucin del esfuerzo del personal conforme se atierden las solicitudes de mantenimiento). Los riesgos impredecibles son el comodln de
la baraja. Pueden y de hecho ocurren, pero son extremadamente dificiles de identificar con antelacin.
cen un marco de trabajo poro lograr uno gestin de res

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 intento resolver.
Tener una visin previsora: pensar en los riesgos
que pudieron surgir en lo futuro (por ejemplo, debido o

cambios en el software); establecer piones de contingencia
de modo que los eventos futuros sean manejables.
Alentor la comunicacin abierta: si alguien estable
ce un riesgo potencial, no lo descarte. Si un riesgo se pro
pone de uno manero informal, considrelo. Aliente o todos
Integracin: en el proceso del software debe estor integrado uno consideracin de los riesgos.
Enfatizar un proceso continuo: el equipo debe eslor
atento o lo largo de todo el proceso de software, modificor
los riesgos identificados conforme se tengo ms informo
cin y agrega r unos nuevos o medido que se logre un mejor criterio.
Desarrollo de una visin conjunta del producto:
si todos los participantes comporten lo mismo visin del
software, es probable que ocurro mejor identificacin y
evaluacin de riesgos.
Alentar el trabajo en equipo: los talentos, habilidades y conocimiento de los participa ntes se deben mezclar
cuando se lleven o coba actividades de gestin de riesgos.
25.3 JpENTlflCACJ6N PI pgscos

La identificacin de los riesgos es un intento sistemtico encaminadc, a especificar
las amenazas al plan del proyecto (estimaciones, calendarizacin, carga de recursos
etc.). Al identificar los riesgos conocidos y predecibles. el gestor del proyecto da un
primer paso para evitarlos cuando es posible y a controlarlos cuando es necesario.
Existen dos tipos distintos de riesgos para cada una de las categoras que se han
presentado en la seccin 25.2: los riesgos genricos y los riesgos especificas del producto. Los riesgos genricos son una amenaza potencial para todo el proyecto de
software. Los riesgos especficos del producto los pueden identificar slo aquellos con
CAPTULO 25 GESTIN DEL RIESGO
,si
un claro conocimiento de la tecnologa. el personal y el entorno especfico del software que se construir. Los riesgos especficos del producto se identifican examinando el
plan del proyecto y la declaracin del mbito del software, as como desarrollando
una respuesta para la siguiente pregunta: "Qu caracteristicas especiales de este
producto podrian amenazar el plan del proyecto?".
,-. profldas sin riesgos reales son perdedores. Estos proyectos casi siempre estn desprovi$t0$.de lrnfidos; pot
. . . . . . reeb,dos aos atrs."
1-IWlillwy ......
:,que es importonte
::.isideror los riesgos
,nricos, los riesgos
e;eclficos del
P'fdJdO son los que
:,,wocon lo moyorfo
los dolores de
atbeza. Asegrese de
!fff]lear ffempo poro
.tenlifkor tontos
zsgos especlficos del
JOIJdo como seo
,rQJ/e.
Un mtodo para identificar riesgos consiste en crear una lista de verificacin de

riesgos. Con sta se pueden identificar riesgos y enfocarse en algn subconjunto de riesgos conocidos y predecibles en las siguientes subcategoras genricas:
Tamao del producto: riesgos asociados con el tamao global del software que
se construir o modificar.
Impacto en el negocio: riesgos asociados con las restricciones que impone la
gerencia o el mercado.
caractersticas del cliente: riesgos asociados con la sofisticacin del cliente y la
habilidad del desarrollador para comunicarse con l en una forma oportuna.
Definicin del proceso: riesgos asociados con el grado en el que se ha definido
el proceso de software y en que le da seguimiento la organizacin que lo de-
sarrolla.
En tomo de desarrollo: riesgos asociados con la disponibilidad y calidad de las
herramientas que se usarn en la construccin del producto.

Tecnologa que construir: riesgos asociados con la complejidad del sistema que
se construir y la "novedad" de la tecnologa que est empaquetada en el sistema.
Tamao y experiencia de la plantilla de personal: riesgos asociados con la experiencia global tcnica y en el proyecto de los ingenieros de software que harn
el trabajo.
La lista de verificacin de riesgos se puede organizar en diferentes formas. Las preguntas relevantes respecto de cada uno de los tpicos se pueden responder para
cada proyecto de software. Las respuestas a estas preguntas permiten que el planificador estime el impacto del riesgo. Un formato diferente de lista de verificacin de
riesgos simplemente menciona tas caractersticas relevantes para cada subcategora
genrica. Finalmente, se menciona W'l conjunto de "componentes y controladores de
riesgo" (AFC88] junto con su probabilidad de ocurrencia. Los controladores del desempeo, soporte, costo y calendazaci6n se estudian como respuesta a las ltimas
preguntas.
752
En la bibliografia se han propuesto varias listas de verificacin detalladas para

riesgos del proyecto de software (por ejemplo, [SEI93J. [KAR96]), las cuales proporcionan una visin til de los riesgos genricos para proyectos de software, y se deben usar siempre que se instituyan anlisis y gestin del riesgo. Sin embargo, se puede emplear una lista relativamente corta de preguntas [KEl98J para proporcionar un
indicio preliminar de si un proyecto est "en riesgo".
25.3.1 Evaluacin del riesgo global del proyecto

Las siguientes preguntas se basan en los datos de riesgo obtenidos al entrevistar, en
diferentes partes del mundo, a gestores de proyecto de software experimentados
[KEI98]. Las preguntas estn ordenadas segn su importancia relativa en el xito de
un proyecto.
El proyecto
de software
en el que adul
Mtlfe trabaja
enfrenta riesgos
serios?
1. Los altos ejecutivos de software y del cliente se han comprometido formalmente para apoyar el proyecto?
2. Los usuarios finales estn comprometidos con el proyecto y el sistema/producto que se construir?
3. Los requisitos los han entendido completamente el equipo de ingenierla de
software y sus clientes?
4. Los clientes estuvieron completamente involucrados en la definicin de los

requisitos?
5. Los usuarios finales tienen expectativas realistas?
6. ,El mbito del proyecto es estable?
..........
Y
..........
7. El equipo de ingeniera del software tiene la mezcla correcta de habilidades?
01 lii:iii Ud1
8 . Los requisitos del proyecto son estables?
.........
9. El equipo del proyecto tiene experiencia con la tecnologa que se implementar?
--......
.. ...
. w.. ...,
.,....,s.,..
-
1O. El nmero de personas en el equipo de proyecto es adecuado para realizar el

trabajo?
11 . Todos los votantes del cliente/usuario estn de acuerdo en la importancia

del proyecto y en los requisitos para el sistema/producto que se construir?
Si la respuesta a alguna de estas preguntas es negativa se deben instituir sin demora los pasos de reduccin, supervisin y gestin. El grado en el que el proyecto esb
en riesgo es directamente proporcional al nmero de respuestas negativas a estas
preguntas.
753
CAPTULO 25 GESTIN DEL RlESGO
25.3.2 Componentes y controladores del riesgo

La FUerza Area de Estados Unidos [AFC88) escribi un folleto con excelentes direc-
trices para la identificacin y supresin del riesgo de software. Este enfoque requiere que el gestor del proyecto identifique los controladores del riesgo que afectan los
componentes de riesgo del software: desempeo, costo, soporte y calendarizacin.
En el contexto de este estudio los componentes de riesgo se definen en la forma siguiente:
Riesgo de desempeo: grado de incertidumbre de que el producto satisfaga los

requisitos y se ajuste al uso que se pretende darle.
Riesgo de costo: grado de incertidumbre de que se mantenga el presupuesto

del proyecto.
Riesgo de soporte: grado de incertidumbre de que el software resultante ser

fcil de corregir, adaptar y mejorar.
,,
"
,"
1 -
f;f ~ ~ lo l0tisfucc:6ri cle los

1
"
requiii!ol n,sultarla -.; vn fraeo' cle
.t.....
lo mbi.11
Ciem reduccin
2
'
811
~ qu,e lio
P\lede IOpOltar
"'
Mlnimo a pequeo
reducci6n .. ..
Respuesio de
soporte ele
Recortes linanc:ierot
slgl,ific:otM,
~ *""''
flnandero$
B fiacmo al IClllillacer lo5 requisilos
..._
~
..
COI
lnolcorwible
~ superacin
del presupuesto
2 dwmpei\o t6cnic:o software
8 fro(g59 resuho n el 011me11fo ele COJIOS

y en demores en lo calendofiz01;i6', con
wlo,9$ ~~ Wf*OR SOQK dki
~ o no ,e ,
..
i11C111,.....,IIN o impadol no
Noto: 1 : Consecuencia potencio) de erro,es o lolm de software llO detectados.

2. Consecuencia potencial si el resullodo daeodo no se alcanzo.
Colendarizoc:i6n
olci,n:t0ble
1 yr~i5fa
754
PARTE CUATRO GESTIN DE PROYECTOS DE SOF'IWARE
Riesgo de calendarizacin: grado de incertidumbre de que se mantenga la calendarizacin del proyecto y de que el producto se entregue a tiempo.
El impacto de cada controlador de riesgo sobre el componente de riesgo se divide ercuatro categoras de impacto: despreciable, marginal, crtico o catastrfico. En la figura 25.1 [BOE89] se describe una caracterizacin de las consecuencias potenciales
de los errores (hileras etiquetadas 1) o una falla que no permite lograr un resultado
deseado (hileras etiquetadas 2). La categora de impacto se escoge con base en la caracterizacin que mejor encaje con la descripcin en la tabla.
del riesgo, tambin llamada estimacin del riesgo, intenta clasificar cada riesgo en dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real,)
2) las consecuencias de los problemas asociados con el riesgo, en caso de que ocurra. El planificador del proyecto, junto con otros gestores y personal tcnico, realizar
cuatro pasos en la proyeccin del riesgo:
La proyeccin
1. Establecimiento de una escala que refleje la posibilidad percibida de un riesgo.

2. Delineado de las consecuencias del riesgo.
iiMJffP
Ejemplo de
tabla de ries-
gos antes de
60%
la clasWcad6n.
30%
70%
40%
50%
40%
80%
30%
80%
38'.
60%
Valores de mpacto:
1: catastrfico
2: crlco
3: margnal
4: despreciable
755
3. Estimacin del impacto del riesgo en el proyecto y el producto.

4. Tomar nota de la precisin global de la proyeccin del riesgo de modo que no
haya malas interpretaciones.
La finalidad de estos pasos es considerar los riesgos en tal forma que conduzcan al
establecimiento de prioridades. Ningn equipo de software tiene los recursos para
enfrentar todos los riesgos potenciales con el mismo grado de rigor. Al priorizar los
riesgos el equipo puede asignar los recursos donde tengan el mayor impacto.
25.4.1
m~
ciilv1
tobla de riesgos
olenoda por
bt1idod e impacto
dos~icor los
qos.
Desarrollo de una tabla de riesgos
una tabla de riesgos ofrece al gestor de un proyecto una tcnica simple para la proyeccin de riesgos. 2 En la figura 25.2 se ilustra un ejemplo de tabla de riesgos.
Un equipo de proyecto comienza una lista de todos los riesgos (sin importar cun
remotos sean) en la primera columna de la tabla. Esto se logra con la ayuda de la lista de verificacin de riesgos mencionada en la seccin 25.3. Cada riesgo se clasifica
en la segunda columna (por ejemplo, TP implica un riesgo de tamao del proyecto,
NE implica un riesgo de negocios). En la siguiente columna de la tabla se registra la
probabilidad de que ocurra cada riesgo. El valor de la probabilidad de cada riesgo lo
pueden estimar individualmente los miembros del equipo. stos se encuestan en una
forma de "todos contra todos" hasta que su evaluacin de la probabilidad del riesgo
comience a convergir.
A continuacin se evala el impacto de cada riesgo. Cada componente de riesgo
se evala mediante la caracterizacin presentada en la figura 25.1, y se determina
una categora de impacto. Las categoras para cada uno de los cuatro componentes
de riesgo (desempeo, soporte, costo y calendarizacin) se promedian3 para determinar un valor de impacto global.
una vez completadas las cuatro primeras columnas de la tabla de riesgos, sta se
ordena segn la probabilidad y el impacto. Los riesgos de alta probabilidad y alto impacto se filtran hacia Jo alto de la tabla, y los riesgos de baja probabilidad caen al
fondo. Esto logra una priorizacin del riesgo de primer orden.
El gestor del proyecto estudia la tabla ordenada resultante y define una lnea de
corte. La lnea de corte (dibujada horizontalmente en algn punto en la tabla) implica que slo los riesgos ubicados sobre la lnea tendrn una atencin posterior. Los
riesgos debajo de la lnea se ree\>alan para lograr una priorizacin de segundo orden. En la figura 25.3 el impacto y la probabilidad de riesgo influyen de manera distinta en la gestin. Un factor de riesgo que tiene un alto impacto, pero una probabilidad de que suceda muy baja, no debe absorber una cantidad significativa de tiem-
2 Es posible implementar la tabla de nesgas como un modelo en hoja de clculo. Esto permite una
manipulacin sencilla y el ordenamiento de las ~..lradas
3 El empleo de un promedio ponderado es ac:t:h!e sl a!gn componente de riesgo tiene mayor relevancia para un proyecto.
756
PARTE CUATRO
po de gestin. Sin embargo, los riesgos de alto impacto con moderada a alta prob.a
bilidad y los riesgos de bajo impacto con alta probabilidad deben trasladarse a L.
pasos de anlisis de riesgo que siguen.
Todos los riesgos ubicados sobre la lnea de corte deben gestionarse. La colum:' a
rotulada RSGR contiene una referencia que apunta hacia un Plan de reduccin, SU-pe'
visin y gestin de riesgo o, alternativamente, una coleccin de hojas de informadn _
riesgo desarrolladas para todos los riesgos que estn sobre el corte. En las secciores
25.5 y 25.6 se examinan el plan RSGR y las hojas de informacin de riesgo.
La probabilidad del riesgo se determina realizando estimaciones individuales

luego desarrollando un solo valor de consenso. Aunque dicho enfoque es valioso ,;e
han desarrollado tcnicas ms elaboradas con las cuales determinar la probabilid.:a..
del riesgo [AFC88). Los controladores de riesgo se pueden evaluar sobre una e~
de probabilidad cualitativa que tiene los siguientes valores: imposible, improbab probable y frecuente. Entonces se asocia la probabilidad matemtica con cada va T
cualitativo (por ejemplo, una probabilidad de 0.7 a 0.95 implica un riesgo enom:_
mente probable).
iiMJffi
Riesgo y
preocupacio-
nes dela
gesUn.
Muyolto
Impacto
CAPTULO 25
GESTIN DEL RIESGO
757
25.4.2 Evaluacin del impacto del riesgo

Tres factores afectan las consecuencias que son probables si un riesgo ocurre: su naturaleza, mbito y tiempo. La naturaleza indica los problemas que son probables si
ocurre. Por ejemplo, una interfaz externa mal definida hacia el hardware del cliente
(un riesgo tcnico) evitar un diseo y prueba tempranos y tal vez genere problemas
de integracin de sistema ms tarde. El mbito combina la severidad (cun serio
es?) con su dstribucin global (cunto del proyecto se afectar, o cuntos clientes
resultarn daados?). Finalmente, el tiempo de un riesgo considera cundo y durante qu periodo se sentir el impacto. En la mayora de los casos un gestor de proyecto tal vez quiera que ocurran las "malas noticias" tan pronto como sea posible, pero
en algunos casos, mientras mayor sea la demora, mejor.
Regresando una vez ms al enfoque de anlisis de riesgo que propuso la Fuerza
Area de Estados Unidos [AFC88J, se recomiendan los siguientes pasos para determinar las consecuencias globales de un riesgo:
Cao se
valoran las
amecuendasde
riesgo?
l. Determinar el valor promedio de la probabilidad de que ocurra para cada

componente de riesgo.
2. Empleando la figura 25.1, determinar el impacto para cada componente, con
base en los criterios mostrados.
3. Completar la tabla de riesgos y analizar los resultados como se describe en las
secciones precedentes.
La exposicin
[HAL98]:
ER
al riesgo global, ER, se determina mediante la siguiente relacin
= P XC
donde P es la probabilidad de que ocurra un riesgo, y C, el costo al proyecto en caso de que ocurra el riesgo.
Por ejemplo, suponga que el equipo de software define un riesgo de proyecto en
la forma siguiente:
Identificacin del riesgo. De hecho, slo 70 por ciento de los componentes de

software calendarizados para reutilizacin se integra en la aplicacin. La funcionalidad restante tendr que desarrollarse de modo personalizado.
Probabilidad de riesgo. 80 por ciento (quiz).
Impacto del riesgo. Se planificaron 60 componentes de software reutilizables.
Si slo se puede emplear el 70 por ciento, 18 componentes tendrian que desarrollarse desde cero (adems de otro software personalizado que se ha calendarizado para desarrollo). Puesto que el componente promedo es 100 LDC y los datos locales
indican que el costo de ingeniera del software para cada uno es de 14.00 dlares, el
costo (impacto) global del desarrollo de los componentes seria 18 x 100 x 14 =
25 200 dlares.
Exposicin al riesgo. ER = O.SO x 2S 200 dlares - 20 200 dlares.
758
PARTE CUATRO Gl'Sl'IN DE PROYECTOS DE SOFIWARE
Comprese lo ER de
ll!dos los riesgos con
lo esffmocin de costo
poro el proyecfl!. Si lo
ER es moyo, que 50
por dento del cosfl!
del proyecfl!, lo viobi
lidod del proyecto
debe reevoluorse.
La exposicin al riesgo se puede calcular para cada riesgo en la tabla de riesgos

una vez que se estime el costo del riesgo. La exposicin al riesgo total para todos los
riesgos (sobre la linea de corte en la tabla) puede ofrecer un medio con que ajustar
la estimacin del costo final de un proyecto. Tambin se emplea para predecir el aumento probable en los recursos de personal que se requieran en varios puntos durante la calendarizacin del proyecto.
La proyeccin del riesgo y las tcnicas de anlisis descritas en las secciones 25.4.1
y 25.4.2 se aplican de manera iterativa conforme avanza el proyecto de software. El
equipo del proyecto debe revisar de nuevo la tabla de riesgos en intervalos regulares, reevaluar cada riesgo para determinar cundo nuevas circunstancias cambiarn
su probabilidad e impacto. Como consecuencia, tal vez sea necesario agregar nuevos riesgos a la tabla, eliminar algunos riesgos que ahora son irrelevantes y cambiar
las posiciones relativas de otros.
CAPTULO 25 GESTIN DEL RIF.SGO
759
Durante las primeras etapas de la planificacin del proyecto se puede establecer un

riesgo de manera muy general. Conforme pasa el tiempo y se aprende ms acerca
del proyecto y el riesgo, es posible refinar el riesgo en un conjunto de riesgos ms
detallados, cada uno un poco ms sencillo de refinar, supervisar y gestionar.
Una forma de hacer esto es representar el riesgo en el formato condidn-transicinconsecuencia (CTC) [GLU94]. Es decir, el riesgo se establece en la forma siguiente:
Dado que <condicin> entonces existe una preocupacin de que (posiblemente) <consecuencia>
Mediante el empleo del formato CTC en lugar del riesgo de reutilizacin anotado en
la seccin 25.4.2, se puede escribir:
Dado que todos los componentes de software reutilizables deben ajustarse con estndares de diseo especficos, y como algunos no Jo 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 ingeniera 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 concretado y tal vez no se ajuste con ciertos componentes reutilizables existentes.
Subcondicin 3. Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino.
Las consecuencias asociadas con estas subcondiciones refinadas siguen siendo las
mismas (es decir, 30 por ciento de los componentes de software tienen que someterse a ingeniera personalizada) , pero el refinamiento ayuda a aislar los riesgos subyacentes y puede conducir a un anlisis y respuestas ms sencillos.
Todas las actividades del anlisis de riesgo presentadas hasta el momento tienen
una sola meta: ayudar al equipo del proyecto a desarrollar una estrategia para luchar
con el riesgo. Una estrategia eficaz debe considerar tres temas:
Evitar del riesgo.
Supervisar el riesgo.
Gestonar el riesgo y los planes de contingencia.
Si un equipo de software adopta un enfoque proactivo hacia el riesgo, evitarlo
siempre es la mejor estrategia. sta se logra desarrollando un plan para reducir el
760
riesgo. Por ejemplo, supngase que una elevada movilidad en el personal se ano: como un riesgo del proyecto, r,. Con base en la historia y la intuicin administrati'. .:.
la probabilidad, 11, de una elevada movilidad se estima en 0.70 (70 por ciento, mas
bien alta) y el impacto, x 1, se proyecta como critico. Esto es: una tasa elevada de W>vilidad tendr un impacto critico en el costo del proyecto y la calendarizacin.
-S..... ...
Ch se
puede hacer
para redtdr 11
riesgo?
15 pnmuones, es porque no dejo nodo al azar:
Este riesgo se reduce si el gestor del proyecto desarrolla una estrategia para reducir la movilidad. Entre los posible pasos que se toman se encuentran:
Reunirse con el personal actual para determinar las causas de la movilidad
(por ejemplo, limitadas condiciones de trabajo, bajos salarios, mercado lab ral competitivo).
Reducir aquellas causas que se controlan antes de que comience el proyecto.
Una vez iniciado el proyecto, suponer que la movilidad ocurrir y entonces
desarrollar tcnicas que aseguren la continuidad cuando la gente se aleje
Organizar equipos de proyecto de modo que la informacin acerca de cada
actividad de desarrollo se disperse con amplitud.
Definir estndares de documentacin y establecer mecanismos que asegu'"Cr'l
que los documentos se desarrollen en una forma oportuna.
Llevar a cabo revisiones por pares de todo el trabajo (de modo que ms d~
una persona est "en ritmo").
Asignar un miembro de personal de respaldo por cada tecnologla crtica
Conforme avanza el proyecto se inician las actividades de supervisin del riesg.
gestor del proyecto supervisa los factores que pueden proporcionar un indicio e;_
el riesgo se est volviendo ms o menos probable. En el caso de la elevada tas:"
movilidad del personal, se pueden supervisar los siguientes factores:
Actitud general de los miembros del equipo con base en las presiones del
yecto.
El grado en el cual el equipo est cuajado.
Las relaciones interpersonales entre los miembros del equipo.
Potenciales problemas con las compensaciones y los beneficios.
La disponibilidad de empleo dentro y fuera de la compaia.
Adems de supervisar estos factores, un gestor de proyecto debe supervisar

efectividad de los pasos de reduccin del riesgo. Por ejemplo, un paso de reduc
del riesgo anotado lineas arriba pide la definicin de estndares de documenta
CAPTULO 25
GESTIN DEL RIESGO
761
y mecanismos para garantizar que los documentos se elaboran en forma oportuna.

ste es un mecanismo para asegurar la continuidad en caso de que un individuo crucial abandone el equipo. El gestor del proyecto debe supervisar los documentos cuidadosamente para asegurarse de que cada uno puede permanecer por s solo y que
cada uno contiene informacin que sera necesaria si una nueva persona se viera
obligada a unirse al equipo de software en algn momento a la mitad del proyecto.
La gestin del riesgo y los planes de contingencia suponen que los esfuerzos de
reduccin han fracasado y que el riesgo se ha vuelto una realidad. Continuando con
el ejemplo, el proyecto ya est bien avanzado y varias personas anuncian que renunciarn. Si se ha seguido la estrategia de reduccin, el respaldo est disponible, la informacin se ha documentado y el conocimiento se ha dispersado entre el equipo.
Adems, el gestor del proyecto puede reenfocar temporalmente los recursos (Y reajustar la calendarizacin del proyecto) hacia aquellas funciones completamente estructuradas, asi permite que los nuevos elementos que deben agregarse al equipo
"tomen el ritmo". A los individuos que deciden marcharse se les pide detener todo el
trabajo y pasar sus ltimas semanas "aprendiendo el modo de transferencia". Esto
puede incluir la adquisicin de conocimiento en videos, el desarrollo de "documentos comentados" o reuniones con otros miembros del equipo que permanecern en
Si lo El? poro un
;esgo especfico es
-.enor que el costo de

Greduccin del
'iesgo, no se intente
~!ir el riesgo sino
(I)f)finuor supervisn-
ilo.
el proyecto.
Es importante sealar que los pasos de reduccin, supervisin y gestin del riesgo (RSGR) generan costos adicionales en el proyecto. Por ejemplo, utilizar el tempo
para "respaldar" cualquier tecnologa crtica cuesta dinero. Por lo tanto, parte de la
gestin del riesgo consiste en evaluar cundo los beneficios que generan los pasos
RSGR se rezagan frente a los costos asociados con su implementacin. En esencia,
el planificador del proyecto realiza un clsico anlisis costo-beneficio. Si los pasos
con que se evita el riesgo de elevada movilidad de personal aumentaran tanto el costo del proyecto como su duracin en un estimado de 15 por ciento, pero el factor de
costo predominante es el "respaldo", el gestor puede decidir no implementar estepaso. Por otra parte, si los pasos con que se evita el riesgo se proyectan para aumentar los costos en 5 por ciento y la duracin en slo 3 por ciento, el gestor probablemente pondr todo en su lugar.
En un proyecto grande es posible definir 30 o 40 riesgos. Si para cada uno se identifican entre tres y siete pasos de gestin del riesgo, sta puede convertirse por si
misma en un proyecto! Por esta razn se adapta la regla 80-20 de Pareto al riesgo
de software. La experiencia indica que 80 por ciento del riesgo del proyecto global
(es decir, 80 por ciento del potencial para falla del proyecto) puede explicarse slo
con 20 por ciento de los riesgos identificados El trabajo realizado durante los primeros pasos del anlisis de riesgo ayudar al planificador a determinar cules de los
riesgos se encuentran en ese 20 por ciento (por ejemplo, riesgos que conduzcan a la
mayor exposicin al riesgo). Por esta razn, algunos de los riesgos identificados,
evaluados y proyectados pueden no incluirse en el plan RSGR, ya que no se ubican
en el crtico 20 por ciento (los riesgos con la mayor prioridad de proyecto).
762
PARTE CUATRO GEmN DE PROYECTOS DE SOFJWARE
i'HIH:liN'JQa
El riesgo no est limitado al proyecto de software. Los riesgos pueden ocurrir despus de que el software se ha desarrollado exitosamente y entregado al cliente. Estos riesgos estn tpicamente asociados con las consecuencias de la falla de software en el campo.
El anlisis de seguridad y peligros de software [LEV95] son actividades de aseguramiento de la calidad del software (captulo 26) que se enfocan en la identificacin y
evaluacin de los peligros potenciales que pudieran afectar al software negativamente y provocar una falla en todo el sistema. Si los peligros se pueden identificar
temprano en el proceso de ingeniera del software, las caractersticas de diseo de
software se pueden especificar de modo que eliminen o controlen los peligros potenciales.
llll~llidllYo
queconliel)IIIO~
enlnidos del ACi{
..
oceJ<iideP.re$gostil
Pblaue iillede
~ ,
~811
ii+Uffi
Hoja de informacin del
riesgo
Hoja de informacin . . riesgo

ID de riesgo: P02-4-32 1 Fecho: 9/5/04
1 Prob:
80%
(WIL97].
",'
lmpocto: alto
Descripcin:
Slo 70 por ciento de los componentes de software colendorizodos poro
reutilizacin de hecho se integrarn en lo aplicacin. Lo funcionalidad restante
tendr que desarrollarse de manero personalizado.
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 poro los componentes de interfaces no ha
sido solidificado y tal vez no concuerden con ciertos componentes reutilizables existentes.
Subcondicin 3 : Ciertos componentes reuti lizables se han implementado en un
lenguaje que no soporto el entorno destino.
Reduccin/ supervisin:
1. Contactar con el tercer participante poro determinar lo concordancia con los
estndares de diseo.
2 . Presionar poro completar los estndares de interfaz; considerar lo estructuro del
componente cuando se decido acerco del protocolo de lo interfaz.
3 . Verificar paro determinar el nmero de componentes en lo categora 3 de
subcondicin; verificar poro determinar si se puede adquirir el soporte paro el
lenguaje.
Gestin/plan de contingencia/disparador:
Lo ER se calculo en 20 200 dlares. Asignar esto cantidad dentro del costo de
contingencia del proyecto.
Desarrollar uno colendarizacin revisado suponiendo que se tendrn que construir
18 componen tes adicionales; asignar el personal en concordancia.
Disparador: los posos de reduccin son improductivos al 1/7/04.
Estado actual:
12/5/04: Inician los posos de reducc in.
Elabor:
D. Gogne
Asignado a:
B. Loster
CAPTULO 25
763
GESTIN DEL RIESGO
En el plan del proyecto de software se puede incluir una estrategia de gestin de riesgo o los pasos de gestin del riesgo organizarse por separado en un Plan de reduccin, supeNisin y gestin del riesgo. El plan RSGR documenta todo el trabajo realizado como parte del anlisis del riesgo y el gestor del proyecto lo emplea como parte
del plan global del proyecto.
Algunos equipos de software no elaboran un documento RSGR formal. En su lugar, cada riesgo se documenta individualmente mediante una hoja de informacin del
riesgo (HIR) [WIL97]. En la mayora de los casos la HIR se mantiene empleando un
sistema de base de datos, de modo que la creacin y las entradas de informacin,
ordenamiento de prioridades, bsquedas y otros anlisis se logran fcilmente. En la
figura 25.4 se ilustra el formato de la HIR.
una vez documentado el plan RSGR y que el proyecto ha comenzado, se inician
los pasos de reduccin y supervisin del riesgo. Como ya se ha comentado, la reduccin del riesgo es una actividad encaminada a evitar el problema. La supervisin del
riesgo es una actividad de seguimiento del proyecto con tres objetivos principales: 1)
valorar si los riesgos predichos de hecho ocurren; 2) asegurar que los pasos para evitar el riesgo definidos para ste se estn aplicando con propiedad; y 3) recopilar informacin que pueda usarse en futuros anlisis de riesgo. En muchos casos, a los
problemas que ocurren durante un proyecto es posible darles seguimiento hacia ms
de un riesgo. otra labor de la supervisin del riesgo es intentar ubicar el origen (qu
riesgos provocaron qu problemas a travs del proyecto).
Gestin del nesgo

Objetivo: El objetivo de las herramientas de
gestin del riego es ayudar al equipo del proyecto a definir los riesgos, valorar su impocto y probabilidad, y seguir los riesgos a travs de todo el proyecto de
software.
Mecnica: En general, los herramientas de gestin del
riesgo auxilian en lo identificacin de riesgos genricos al
proporcionar una lista de riesgos usuales de proyecto y de
negocios, ofrecer listas de verificacin u otros tcnicas de
entrevistan que auxilien en la identificacin de riesgos especficos del proyecto, asignar probabilidad e impocto a
cada riesgo, apoyar las estrategias de reduccin del riesgo

y generar muchos reportes relacionados con el riesgo.
Herramientas representantivas4
Rislcmon, desorrolloda en Arizona State University (www.

eos.asu.edu/-sdm/merrill/riskman.html), es un sistema
exper1o en evaluacin de riesgo que identifica riesgos
relacionados con el proyecto.
Rislc Rodar desorrollada por SPMN (www.spmn.com), auxi1io o los gestores de proyectos a identificar y gestionar riesgos.
Las herramientas anotadas aqu son una muc:sua de esta categorla. En la mayora de los casos los
nombres de las mismas son marcas registradas por- sus respectivos desarrolladores.
764
RiskTrak, desarrollado por RST (www.risktroc.com), apoyo

lo identificacin, el anlisis, el reporte y lo gestin de
riesgos o travs de un proyecto de software.
Risk+, desarrollado por C/S Solutions (www.CS-solutions.

com), se integra con Microsoft Projed poro cuantificar
costos e incertidumbres de colendorizocin.
X:PRIMER, desarrollado por GroFP Technologies (www.

grofp.com), es una herramienta genrico basado en
Web que predice qu puede salir mal en un proyecto e
identifico el origen de los causas de potenciales follas y
contromedidos efectivas.
Siempre que en un proyecto de software est mucho en juego, el sentido comn dicta el anlisis de riesgos. Sin embargo, muchos gestores de proyecto de software lo
hacen informal y superficialmente, si es que lo hacen. El tiempo empleado en identificar, analizar y gestionar el riesgo paga por s mismo dividendos en muchas formas: menos trastornos durante el proyecto, una mayor habilidad para seguir y controlar un proyecto, y la confianza que llega cuando se planifican los problemas antes de que ocurran.
El anlisis de riesgos puede absorber una cantidad significatva de esfuerzo de
planificacin del proyecto. La identificacin, proyeccin, evaluacin, gestin y supervisin toman tiempo. Pero el esfuerzo bien vale la pena. Para citar a Sun Tzu, el general chino que vivi hace 2 500 aos: "Si usted conoce al enemigo y se conoce a si
mismo, no necesita temer el resultado de cien batallas". El enemigo del gestor del
proyecto de software es el riesgo.
[AFC881 Software Risk Abatement, AFCS/ AFLC Pamphlet 800-45, U.S. Air Force, 30 de septiembre de 1988.
[BOE891 Boehm, B. W., Software Risk Management, IEEE Computer Society Press, 1989.
[CHA891 Charette, R. N., Software Engineering Ri.skAnalysis and Management, McGraw-Hill/Intertext, 1989.
[CHA921 Charette, R. N., "Building Bridges over Intelligent Rivers", en American Programmer, vol.
5, nm. 7, septiembre de 1992, pp. 2-9.
[DRU75] Drucker, P., Management, W. H. Heinemann, 1975.
[GIL.88] Gilb, T., Principles ofSoftware Engineering Management, Addison-Wesley, 1988.
[GLU94) Gluch, D. P., "A construct for Describing Software Development Risks", CMU/SEl-94TR-14, Software Egineering Institute, 1994.
[HAL98) Hall, E. M., Managing Risk: Methods for Software systems Development, Addison-Wesley,
1998.
fHIG95] Higuera, R. P., "Team Risk Management", en CrossTalk, U.S. Dept. of Defense, enero de
1995, pp. 2-4.
[KAR96J Karolak, D. W., Software Engineering Risk Managemenf. IEEE Computer Society Press,
1996.
f[(EI98J Keil, M . et al., "A Framework for Jdentifying Software Project Risks", en CACM, vol. 41 ,
nm. 1, noviembre de 1998, pp. 76-83.
[LEV95) Leveson, N". G., Software system Safety and Computers, Addison-Wesley, 1995.
[SEI93) "Taxonomy-Based Risk Identification", Software Engineering Institute, CMU/SEI-93-TR6, 1993.
765
[TH092) Thomsett, R., "The Indiana Jones School of Risk Management", en American Programmer, vol. 5, nm. 7, septiembre de 1992, pp. 10-18.
[WIL97] Williams, R. C., J. A. Walker y A. J. Dorofee, "Putting Risk Management into Practice", en
IEEE Software, mayo de 1997, pp. 75-81.
25.1. Ofrecer clnco 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 resultado puede entonces grabarse en DVD u otro medio audiovisual. Investigue un poco acerca de
sistemas de este tipo y Juego elabore una lista de riesgos tecnolgicos que enfrentara al comenzar un proyecto con estas caractersticas.
2 5.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.
2 5.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 anotados en la figura 25.2.
25.8 . Desarrollar una estrategia de supervisin de riesgo y especificar actividades de supervisin 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 probable.
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. 1o. 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 aJ 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 sera considerado como parte de su plan RSGR?
25.14. Describanse cinco reas de aplicacin de software en las que el anlisis de la seguridad
y los peligros del software serian una preocupacin principal.
La bibliografia de gestin del riesgo de software se ha expandido significativamente durante la

dcada pasada. DeMarco y Llster (Danang wrth &m's, 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 (Coping with IT/lS Risk 1 ~. Springer-Verlag, 2002) presenta consejos pragmticos de gestores de proyecto que 6diiul cminuamente con l. Royer (Project Risk
766
Management, Management Concepts, 2002) y Smith y Merrtt (Proactive Risk Management, ?r'"lductivity Press, 2002) sugieren un proceso proactivo para la gestin del riesgo. Karolak (SO.fh,
re Engineering Risk Managemenc, Wiley, 2002) ha escrito una gua que introduce un modelo anlisis de riesgo fcil de usar y que contiene valiosas listas de verificacin y cuestionarios cr-se apoyan en un paquete de software.
Schuyler (Risk and Decision Analysis in Projects, PMI, 2001) considera el anlisis de riesg
desde una perspectiva estadistica. Hall (Managing Risk: Methods far Software Systems Devd.. ;
ment, Addison-Wesley, 1998) presenta uno de los tratamientos ms exhaustivos de la mater _
Myerson (Risk Management Processing far Software Engineering Mode/s, Artech House, 1~
considera mtricas, seguridad, modelos de proceso y otros tpicos. Grey (Practica/ Risk ~
mentfor Project Management, Wiley, 1995) escribi un til manual de la evaluacin del riesg:
Su tratamiento abreviado ofrece una buena introduccin a la materia.
Capers Jones (Assessment and Control ofSOftware Risks, Prentice-Hall, 1994) presenta una e. posicin detallada de los riesgos de software que incluye datos recopilados a partir de cienl""S
de proyectos de software. Jones define 60 factores de riesgo que pueden afectar el resultado :!e
los proyectos de software. Boehm [BOE89] sugiere excelentes formatos de cuestionario y lisU.s
de verificacin que pueden resultar invaluables en la identificacin de riesgos. Charette [CHAc.
presenta un tratamiento detallado de las mecnicas del anlisis de riesgo, y utiliza teora de p~
babilidad y tcnicas estadsticas para analizar riesgos. En un volumen adicional, Charette ,,.;:
plication Strategies for Risk Anatysis, McGraw-Hill, 1990) analiza el riesgo en el contexto de _
ingeniera tanto de sistemas como de software, y sugiere estrategias pragmticas para la ge::
tin del riesgo. Gilb (Principies ofSoftware Engineering Management, Addison-Wesley, 1988) presenta un conjunto de "principios" (en ocasiones graciosos y a veces profundos) que pueden servir como una gua valiosa para la gestin del riesgo.
Ewusi-Mensah (Software Development Failures: Anatomy of Abandoned Projects, MIT Press,
2003) y Yourdon (Death March, Prentice-Hall, 1997) analizan lo que ocurre cuando los riesgos
abruman a un equipo de proyecto de software. Bernstein (Against the Gods, Wiley, 1998) presenta una entretenida historia del riesgo que se remonta a tiempos antiguos.
El Software Engineering Institute ha publicado muchos informes detallados y guas acerci
del anlisis y la gestin del riesgo. El folleto AFSCP 800-45 [AFC88J del Air Force systems eocmand describe las tcnicas de identificacin y reduccin de riesgos. Cualquier nmero del AC
SOjtware Engineering Notes tiene una seccin titulada "Riesgos para el pblico" (editor, P. G. NeJmann). Si usted quiere las ms recientes y mejores historias de horror de software, ste es el >gar al que tiene que ir.
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de gest:ic".:
del riesgo de software. Una lista actualizada de referencias en la World Wide Web se puede ercontrar en el sitio Web SEPA:
http://www.mhhe.com/presssman.
DE LA CALIDAD
CONCEPTOS
CLAVE
aplifkacll
defedos 11$
llidacl " .769
atrol
mlidoct 110
mto
l enfoque e ingeniera del software descrito en este libro se dirige hada

una sola meta: producir software de alt: calidad. Aunque a rrmchos lectores les pj:ttecer un reto ta pregunta; qu es calidad d~l software?
Philip Ctosby [CR079J, en su lil;,ro fundamental acerca ele calidad, ofrece una
respuesta Irnica a esta pregunta:
El problema de la gestin de la calidad no es lo que la gente lgnora i!Crca de ~!la. El
problema es lo que creen saber...
2000 .,,.n,,190
A este respecto, la calidad tiene mucho en comn con el sexo, Todo el mundolo
quere. (En certas ~ondkiones, desde Juego.) Todos sienten que lo en'tendert (Aun
cuando no quieran explicarlo.) todos piensan que su ejecucin slo es-cuestin de
seguir las inclinaciones naturales. (Despus cte todo, la gente se l.:ls arre$la de alguna fofitla.} Y, desde Juego, la mayora de tas personas piensa que los problemas en
estas reas los provocan otraa personas. (Si slo se tomaran el tiempo para hacer las
aestreo , 781
eosa.s bien.)
calidod. 71$
mstos
falos ..... J1l

Wiliclad .... ,786
ISO 9001:
Pla ele SQA 791

misiones
crm ....... J74

seguridocf de
raftware . 788
siplo ...78S
SQA estocliitkll 783
Algunos desarrolladores de software continan creyendo que la ca1idad de

ste es algo ert lo que se debe comenzar a preocupatsdlo despus de que se.haya generad el cdlg~. Nada podna estar ms alejado de la verdact1 ta gestin
de la caJktad (con frec;uencia llamada garanta de fa caldad del software) es una
actividad protectora o de sombrilla {captulo 2) que se aplica a lo largo del pro
ceso de software.
La gestin de la calidad abarca l) un proceso de garanta de la calidad del
software {SQA, por sus siglas en ingls), 2) tareas especficas de aseguramiento y
control de la calidad (que incluyen revisiones tcnicas formales y un~ estrategia
de pruebas de varos niveles); 3) prcticas efectivas de ingeniera del software
(mtodos y herramientas) 4) control de todos los product<;>s ele tr9bajo de1 soff-
Qu4 e?.~ eJ suficiente hablar

_P.Or hobl(jf dicndo que lo cal dad
oet soffwore es importante Se tiene
que 1) definir explcitamente que
quiere decir <;U(lndo dice co dad
del softwcir~, 2} <:rear un conjunto de activido-
das qu oyudorn Q osegurw que todo produc

io <fe trobojo de io~ierfo del software presa,
tQrq alta ccfidad, J) l'(;la}iwr actividades de
control y CS~romiento de lo colidod en coda
167
768
PARTE CUATRO
Gl:STIN DE PROYECTOS DE SOFIWARE
ware y los cambios que generan (captulo 27); 5) un procedimiento para garantizar
la concordancia con los estndares de desarrollo del software (cuando sea aplicable), y 6) mecanismos de medicin e informe.
Este captulo se centra en los temas de gestin y las actividades especficas de
proceso que permiten a una organizacin de software garantizar que hace las cosas
correctas en el momento justo y en la forma correcta.
26.1
~
"~
C~VE
El control de lo
variacin es lo clave
poro un producto de
alto calidad. En el
contexto del software
se lucho por controlar
lo variacin en el
proceso genrico que
se aplico y el nfasis
de calidad que permeo
el trobojo de ingeniera
del software.
conc1ema PI cAw1n 1
El control de la variacin es el corazn del control de calidad. Un fabricante quiere
minimizar la variacin entre los productos que se producen, aun cuando haga algc
relativamente simple como duplicar DVD. Seguramente, esto no puede ser un problema: la duplicacin de los DVD es una operacin simple de fabricacin, y es posible garantizar que siempre se creen duplicados exactos del software.
Se puede? Es necesario asegurarse de que las pistas se colocan en los DVD dentro de una tolerancia especificada de modo que la mayora abrumadora de los controladores de DVD pueda leer el medio. Las mquinas de duplicacin de discos pueden, y lo hacen, aceptar y rechazar la tolerancia. As que incluso un proceso "simple" como la duplicacin de DVD puede encontrar problemas debidos a la variacir
entre muestras.
Pero cmo se aplica esto al trabajo de software? Cmo puede una organizacin
de desarrollo de software necesitar controlar la variacin? De un proyecto a otro se
quiere minimizar la diferencia entre los recursos predichos necesarios para compleEsta seccin, escrita por Michael Stovsky, ha sido adaptada de "Fundamentals of ISO 9000", un libro
de trabajo desarrollado para
Esscntial Software Enginccring, un video currculum desarrollado por R.
S. Pressman & Associates, lnc. Reimpreso con permiso.
CAPTULO 26
769
GESTIN DE LA CALIDAD
tar un proyecto y los recursos reales utilizados, que incluyen personal, equipo y tiempo. En general, se quisiera estar seguro de que el programa de pruebas abarca un
porcentaje conocido del software, de una liberacin a otra. No slo se quiere minimizar el nmero de defectos que se liberan, sino que se quiere asegurar que la varianza en el nmero de bugs tambin se minimiza de una liberacin a otra. (Los clientes
probablemente se molestarn si la tercera liberacin de un producto tiene diez veces ms defectos que la liberacin previa.) Nos gustara minimizar las diferencias en
rapidez y precisin de las respuestas de la linea de soporte para los problemas de los
clientes. La lista puede continuar indefinidamente.
26.1.1
Calidad
El American Heritage Dictionary define calidad como "una caracterstica o atributo de

algo". Como un atributo de un elemento, la calidad se refiere a caractersticas mensurables, es decir: cosas que se pueden comparar para conocer estndares, como longitud, color, propiedades elctricas y maleabilidad. Sin embargo, el software, principalmente una entidad intelectual, es ms dificil de caracterizar que los objetos fisicos.
No obstante, existen las mediciones de las caractersticas de un programa. Dichas
propiedades incluyen complejidad ciclomtica, cohesin, nmero de puntos de funcin, lneas de cdigo y muchas otras examinadas en el captulo 15. Cuando se examina un elemento con base en sus caracterlsticas mensurables se pueden encontrar
dos tipos de calidad: calidad de diseo y calidad de concordancia.
La calidad de diseo se refiere a las caractersticas que los diseadores especifican
para un elemento. La calidad de concordancia es el grado en el que las especificaciones de diseo se aplican durante la fabricacin.
!J' .'\t...alwla cun rdpido hiciste un trobojo, pero siempre recuerdan cun bien lo lllste.
1
... . . . . . . . . ,,,
En el desarrollo de software, la calidad del diseo incluye requisitos, especificaciones y el diseo del sistema. La calidad de concordancia es un tema enfocado principalmente en la implementacin. Si sta sigue el diseo y el sistema resultante
satisface sus requisitos y metas de desempeo, la calidad de concordancia es alta.
Pero la calidad del diseo y la calidad de concordancia son los nicos temas que
deben considerar los ingenieros de software? Robert Glass [GLA98] argumenta que es
conveniente una relacin ms "intuitiva~:
satisfaccin del usuario = producto manejable + buena calidad
~ entrega dentro de presupuesto y tiempo
En el fondo, Glass afirma que la calidad es importante, pero si el usuario no est satisfecho, nada ms importa en realidac. DeMarco (DEM99J refuerza esta visin cuando afirma: "La calidad de un producto es una func,n de cunto cambia el mundo
para mejorar". Esta visin de la calidad afirma que si un producto de software pro-
770
porciona beneficio sustancial a sus usuarios finales, stos estn dispuestos a toler..:r
problemas ocasionales en confiabilidad y desempeo.
26.1.2 Control de calidad

Qu es
control de
catidad de
software?
'
El control de la variacin puede equipararse con el control de calidad. Pero, c1r"'

se logra el control de calidad? ste involucra la serie de inspecciones, revisiones
pruebas empleadas a lo largo del proceso de software para garantizar que cada pr
dueto de trabajo satisfaga los requisitos que se le han asignado. El control de cali~
incluye un bucle de retroalimentacin con el proceso que cre el producto de traba
La combinacin de medicin y retroalimentacin permite afinar el proceso cuando .
productos de trabajo creados fracasan en cuanto a satisfacer sus especificaciones
Un concepto clave del control de calidad es que todos los productos de trabajo te
nen especificaciones definidas mensurables con las cuales se puede comparar la sa
lida de cada proceso. El bucle de retroalimentacin es esencial para minimizar ! is
defectos producidos.
26.1.3 Garanta de la calidad
....
tj/f iihi.11
IIICnl$
so.
pl8datna111111r111
# ........
....
-tt,/,.1/Wn.
La garanta de la calidad consiste en un conjunto de funciones de auditoria e infw-
macin que evalan la efectividad y qu tan completas son las actividades de con;_
de calidad. La meta del aseguramiento de la calidad es brindarle al gestor los da s
necesarios para que est informado acerca de la calidad del producto, y por cor_
guiente que comprenda y confie en que la calidad del producto est satisfaciendo s.lS
metas. Desde luego, si los datos que ofrece el aseguramiento de la calidad iden;...'.:
can problemas, es responsabilidad del gestor abordarlos y aplicar los recursos necesarios para resolver los conflictos de calidad.
26.1.4
Costo de la calidad
El costo de la calidad incluye todos los costos que genera la bsqueda de calidaC:
que demanda el desarrollo de las actividades relacionadas con la calidad. Los eS ..
dios de costo de la calidad se llevan a cabo para ofrecer una linea base para el Cl.
to actual de la calidad, identificar oportunidades que reduzcan el costo de calida1..
proporcionar una base normalizada de comparacin. La base de la normalizac
casi siempre es monetaria. Una vez que se han normalizado los costos de la calid~
sobre una base monetaria, se tienen los datos necesarios para evaluar dnde se e
cuentran las oportunidades para mejorar los procesos. Ms todava, se puede e
Cules
son los
to11ponentes del
costo de calidad?
luar el efecto de los cambios en trminos monetarios.

Los costos de calidad se dividen en costos asociados con prevencin, evaluad
y fallas. Los costos de prevencin incluyen planificacin de la calidad, revisiones te
nicas formales, equipo de pruebas y entrenamiento. Los costos de evaluacin inc
yen actividades para comprender mejor la condicin del producto la "primera vez
travs de" cada proceso. Los ejemplos de costos de evaluacin incluyen inspecc
en el proceso y entre procesos, calibracin y mantenimiento de equipo y pruebas
CAPM'tJLO 26
771
1000
:i
,2
!::i
100
"t.g..
10
e
l
j
Req.
Diseo
C6di90
Des.
pruebas
Pruebas Operocin
de sistema de campo
Los costos de fallas son aquellos que desaparecerfan si no aparecieran defectos

antes de enviar un producto a los clientes. Estos costos se subdividen en costos de
fallas internas y externas. Se incurre en los costos de fallas internas cuando se detecta un defecto en el producto antes del envio. Los costos de fallas internas incluyen
reelaboracin, reparacin y anlisis en modo de falla. Los costos de fallas externas se
asocian con defectos detectados despus de que el producto ha sido enviado al
cliente. Los ejemplos de costos de fallas externas son la resolucin de las quejas, devolucin y reemplazo del producto, soporte de ayuda en lnea y trabajo de garantia.
Como se esperaba, los costos relativos para encontrar y reparar un defecto aumentan sustancialmente conforme se pasa de la prevencin a deteccin y de los de
falla interna a los de falla externa.
La figura 26.1, basada en datos recopilados por Boehm [B0E8 l] y otros, ilustra este fenmeno.
tllnlpo hac:w una coso bien que explicar por qu lo hiciste mol."
H.W.l ...,
Incluso los desarrolladores de software ms exhaustos estarn de acuerdo en que el

software de alta calidad es una meta importante. Pero cmo se define calidad? Un
bromista dijo una vez: "Todo programa hace algo bien, slo que puede ser la cosa
que no queremos que haga".
En la bibliografa se han propuesto muchas definiciones de la calidad del software. En cuanto a los propsitos del presente texto, la cahdad del software se define de
la siguiente manera:
772
Cmo se
define la
calidaddel
Concordancia con los requisitos funcionales y de desempeo explcitamente establecidos,

estndares de desarrollo explcitamente documentados y caractersticas implicitas que se
esperan de cualquier software desarrollado profesionalmente.
software?
No hay duda de que esta definicin puede modificarse o extenderse. De hecho, la de
finicin de calidad del software podrla debatirse interminablemente. En cuanto a las
propsitos de este libro, esta definicin sirve para resaltar tres puntos importantes
1. Los requisitos de software son la base de las medidas de la calidad. La falta de

concordancia con los requisitos es una falta de calidad.
2 . Los estndares especificados definen un conjunto de criterios de desarrollo

que guan la forma en que el software se elabora. Si no se siguen los criterios
casi seguramente resultar una falta de calidad.
3 . Con frecuencia no se menciona un conjunto de requisitos implcito (por ejemplo, el deseo de uso sencillo y facilidad de mantenimiento). Si el software corcuerda con sus requisitos explcitos pero fracasa al satisfacer los requisitos
implcitos, su calidad est en duda.
26.2. l Algunos antecedentes

El control y la garanta de la calidad son actividades esenciales en cualquier negoc
que elabore productos de consumo. Antes del siglo xx, el control de calidad era responsabilidad exclusiva del empresario que fabricaba un producto. La primera furcin formal de garanta y control de calidad la introdujeron los Laboratorios Bell
e'"
1916 y se extendi rpidamente a travs del mundo industrial. Durante el decenio ~

1940 se sugirieron enfoques ms formales del control de calidad, los cuales se
apo-
yaban en la medicin y la mejora continua de los procesos (DEM86J como los elementos clave de la gestin de la calidad.
En la actualidad, toda compaia tiene mecanismos que garantizan la calidad ~

sus productos. De hecho, las afirmaciones explicitas de la preocupacin de una compaa por la calidad se han convertido en una tctica de mercadotecnia durante las
dcadas pasadas.
La historia de la garantia de la calidad en el desarrollo de software avanza paralela a la de la calidad en la fabricacin de hardware. Durante los primeros das de J.:
computacin (dcadas de 1950 y 1960). la calidad era responsabilidad exclusiva de'.
programador. Los estndares de garanta de la calidad para el software se introdujeron en los contratos militares de desarrollo de software durante el decenio de l 97C
y se han extendido rpidamente en el desarrollo del software en el mundo de los negocios [IEE94J. Si se extiende la definicin presentada anteriormente, la garanta de
la calidad del software es un "patrn de acciones sistemtico y planificado" (SCH9S,
CAPTULO 26
773
que se requiere para garantizar alta calidad en el software. Numerosos y diversos

participantes tienen responsabilidad en la garanta de la calidad del software: ingenieros de software, gestores de proyecto, clientes, vendedores y los individuos que
participan en un grupo de SQA.
El grupo de SQA funciona como el representante en casa del cliente. Es decir, las
personas que realizan el SQA deben observar el software desde el punto de vista del
cliente. El software satisface adecuadamente los factores de calidad sealados en
el capitulo 15? El desarrollo de software se ha llevado a cabo de acuerdo con los estndares preestablecidos? Las disciplinas tcnicas han realizado adecuadamente
sus tareas como parte de la actividad de SQA? El grupo de SQA intenta responder
stas y otras preguntas para garantizar que la calidad del software se conserva.
26.2.2 Actividades de SQA

La garanta de la calidad de software se compone de una variedad de tareas asociadas con dos integrantes diferentes: los ingenieros de software que realizan el trabajo tcnico y un grupo de SQA que tiene la responsabilidad de planificar, supervisar,
guardar registros, analizar y reportar la garanta de calidad.
Los ingenieros de software abordan la calidad (y realizan actividades de aseguramiento y control de calidad) al aplicar slidos mtodos y medidas tcnicas, llevar a
cabo revisiones tcnicas formales y desarrollar pruebas de software bien planificadas. En este captulo slo se examinan las revisiones. Los tpicos de tecnologa se
tratan en las partes 1, 2, 3 y 5 de este libro.
La misin del grupo de SQA es auxiliar al equipo de software a conseguir un producto final de alta calidad. El Software Engineering lnstitute (SEi) recomienda un
conjunto de actividades de SQA que abordan la planificacin, supervisin, conservacin de registros, anlisis y elaboracin de informes de aseguramiento de la calidad.
Dichas actividades las realiza (o facilita) un grupo de SQA independiente que se encarga de las siguientes actividades:
l es ti
papel dt ..
"' dtSQA?
Preparar un plan de SQA para un proyecto. El plan se desarrolla durante la

planificacin del proyecto y lo revisan todos los participantes. Las actividades de
garanta de la calidad del equipo de ingeniera del software y del grupo de SQA las
rige el plan. ste identifica las evaJuaciones que se realizarn, las auditorias y revisiones para nevar a cabo, los estndares aplicables al proyecto, los procedimientos
para el infonne y seguimiento de errores, los documentos que debe producir el grupo de SQA y la cantidad de retroalimentacin proporcionada al equipo de proyecto
de software.
Participar en el desarrollo de la descrlpcin del proceso de software del

proyecto. El equipo de software selecciona un proceso para el trabajo que habr
de realizarse. El grupo de SQA revisa la descripcin del proceso para que concuerde
con las polticas organizacionales, los estandares internos de software, los estndares impuestos de manera externa (par ejemplo lS0-9001 ) y otras partes del plan de
proyecto del software.
774
PARTE CUATRO
Revisar las actividades de ingeniera del software para verificar que se ajuste al proceso de software definido. El grupo de SQA identifica, documenta y sigue las desviaciones del proceso y verifica que se hayan hecho las correcciones.
Audita productos de trabajo de software seleccionados para verificar que
se ajusten con los defmidos como parte del proceso del software. El grupo
de SQA revisa los productos de trabajo seleccionados, identifica, documenta y sigue
las desviaciones; verifica que se hayan hecho las correcciones; y peridicamente informa de los resultados de su trabajo al gestor del proyecto.
Garantiza que las desviaciones en el trabajo del software y en los productos de trabajo estn documentadas y se manejen de acuerdo con el procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripcin del proceso, en los estndares aplicables o en los productos
de trabajo tcnicos.
Registra cualquier falta de ajuste y lo informa al gestor ejecutivo.
mentos que no se ajustan se les da seguimiento hasta resolverlos.
A los ele-
Adems de estas actividades, el grupo de SQA coordina el control y la gestin del

cambio (capitulo 27) y ayuda a recopilar y analizar mtricas de software.
Los revisiones son

como filtros en el flu;o
Je lroboio del proceso
de software. Muy
poco yel flujo est
sudaH. Demasiada y
el f/uo se reduce oun
chorrito. Use mtricos
poro determinar qu
revisiones funcionan y
reslte/os.
Las revisiones del software son un "filtro" para el proceso de software. Esto es, las
revisiones se aplican en varios puntos durante la ingeniera del software y sirven para descubrir errores y defectos que Juego pueden eliminarse. Las revisiones del software "purifican" las actividades de ingeniera del software que se han denominado
anlisis, diseo y codificacin. Freddman y Weinberg [FRE90] abordan del modo siguiente la necesidad de las revisiones:
El trabajo tcnico necesita revisarse por la misma razn que los lpices necesitan gomas.
Errar es humano. 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 parte de la ingeniera del software se pueden llevar a cabo muchos tipos de
revisiones. Cada uno tiene su lugar. una reunin informal en torno a una mquina
expendedora de caf es una forma de revisin, si se examinan los problemas tcnicos. Una presentacin formal del diseo de software a un auditorio de clientes, gestores y personal tcnico tambin es una forma de revisin. Sin embargo, este libro
se enfoca sobre la revisin tcnica formal, a veces llamada comprobacin manual del
cdigo (wa/kthrough) o inspeccin. Una revjsin tcnica formal (RTF) es el filtro ms
efectivo desde un punto de vista de aseguramiento de la calidad. Dirigida por los ingenieros de software (u otras personas) para ingenieros de software, la RTF es un
medio efectivo para descubrir errores y mejorar la calidad del software.
CAPTULO 26
775
En este libro se ha hecho una clara distincin entre un
.ro, (un problema de calidad descubierto antes de que el

sottware sea liberado entre los usuarios finales) y un defect> {un problema de calidad detectado slo despus de que
e software ha sido liberado entre los usuarios finales). 2 Se
"tO hecho esta distincin porque los errores y defectos tie
-ien impactos econmicos, de negocios, psicolgicos y hu
-.anos muy diferentes. Como ingenieros de software se
=viere descubrir y corregir tantos errores como sea posible
antes de que el cliente o usuario final los encuentre. Se
"!Vieren evitar los defectos porque (justificadamente) hacen
w mal a la gente de software.
Sin embargo, es importante mencionar que la distincin temporal hecha en este libro entre errores y defectos
no es la tendencia predominante. El consenso general entre la comunidad de ingeniera del software es que defec
tos y errores, follas y bugs son sinnimos. Es decir, el
momento en que el problema se descubri no tiene impor
toncio en cuanto al trmino con que se describe el proble
ma. Parte del argumento en favor de esto visin es que o
veces es difcil distinguir con claridad entre preliberocin y
posliberocin (por ejemplo, considrese un procesa incremental utilizado en el desarrollo gil (captulo 4]1.
Sin importar cmo se elijo interpretar estos trminos,
reconzcose que el momento en que se descubre un problema s importo y que los ingenieros de software deben
intentar duro, muy duro, detector los problemas antes de
que los dientes y usuarios finales los encuentren. Si se tiene
un inters posterior en este temo, uno revisin razonablemente amplio de lo terminologa que rodeo o los HbugsHse
puede encontrar en www.softworedevelopment.co/bugs.
shtml.
M iifli
1
lllodelo de
::mpwtcacin
:.e defecto.
Poso de desarrollo
Defectos
Deteccin
Errores
provenientes
de posos previos
Errores que
pasan ol poso
siguiente
26.3.1 Impacto de los defectos de software en el costo

El objetivo principal de las revisiones tcnicas formales es descubrir los errores durante el proceso, de modo que no se conviertan en defectos despus de liberar el
software. El beneficio obvio de las revisiones tcnicas formales es el descubrimiento temprano de los errores de modo que ya no se propaguen al paso siguiente en el
proceso del software.
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 e1emplo, 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 ejemplo. mi modelo de diseo) se hubiese "liberado" hacia la
actividad siguiente.
116
El obetivo principal de
una RTF es encontrar
los errores antes de
que pasen aotro
actividad de ingenierfo
del sohwore osean
liberados o/ usuario
fino/.
varios estudios industriales (realizados por TRW, NEC y Mitre Corp., entre otros
indican que las actividades de diseo introducen entre 50 y 65 por ciento de los errores (y, a final de cuentas, de los defectos) durante el proceso de software. Sin embargo, las tcnicas de revisin formal han mostrado hasta 75 por ciento de efectivid~
UON86] al descubrir fallos en el diseo. Al detectar y eliminar un gran porcentaje de
dichos errores, el proceso de revisin reduce sustancialmente el costo de las act~ dades subsecuentes en el proceso de sofiware.
Para ilustrar el impacto en el costo de la deteccin temprana de errores, considc:::rese una serie de costos relativos que se basan en datos de costo real recopilada:.
para grandes proyectos de software [1BM81]. 3 Supngase que la correccin de u:error descubierto durante el diseo costar 1.0 unidad monetaria. En relacin ccr
este costo, el mismo error descubierto justo antes de que comience el periodo de
pruebas costar 6.5 unidades; durante las pruebas, 15 unidades; y despus de la Lberacin, entre 60 y l 00 unidades.
26.3.2 AmpWicacin y eliminacin del defecto

Se puede usar un modelo de amplificacin de defectos [IBM81] para ilustrar la generacin y deteccin de errores durante el diseo preliminar, el diseo de detalles y los
pasos de codificacin de un proceso de ingeniera del software. En la figura 26.2 se
ilustra esquemticamente el modelo. Un recuadro representa un paso de desarroL
del software. Durante el paso, los errores se pueden generar de manera inadvertida
La revisin puede fallar en descubrir errores generados de manera reciente y errores
de pasos anteriores, lo que resulta en cierto nmero de errores que se pasan por alto. En algunos casos, los errores que se pasan por alto desde pasos anteriores se aTT'-
.;;;:p.;.
AmpWicacin
de defecto sin
revisiones.
Pruebo de validacin
A integracin
Prueba de sistema
o
o
Errares latentes
Aunque estos datos tienen ms de 20 aos de antigedad, an son aplicables en un contexto mer
derno.
777
CAPTULO 26 GESTIN DE LA CAUDAD
ifrHfli
Diseo preliminar
Ampllficacin
de defecto con
revisiones.
Diseo detollodo
l 1.5
50%
25
24
Pruebo de integracin
Pruebo de volidocin
A inte9roci6n
Pruebo de sistema
Errores latentes
plifican (factor de amplificacin x) con el trabajo actual. Las subdivisiones de los recuadros representan cada una de estas caractersticas y el porcentaje de eficiencia
de la deteccin de errores, una funcin de la minuciosidad de la revisin.
Mam11~ h los midkos, son fciles de curar en sus iatios ounqu1 diltdllS4e....,...
aJ lielnpo, cuando no han sido reconocidos oprimero visto y trotodCI$, se-vllvt r.dM .. ......,
.Olllf..
,
La figura 26..3 ilustra un ejemplo hipottico de la amplificacin del defecto para un

proceso de software en el que no se llevan a cabo revisiones. En la figura se supone
que cada paso de prueba descubre y corrige, sin introducir nuevos errores, 50 por
ciento de los errores que llegan (una suposicin optimista). Diez defectos de diseo
preliminar se amplificaron a 94 errores antes de comenzar las pruebas. Doce defectos latentes se liberaron al campo. La figura 26.4 considera las mismas condiciones
excepto que la revisin del diseo y del cdigo se llevaron a cabo como parte de cada paso de desarrollo. En este caso, diez errores iniciales de diseo preliminar se
amplificaron a 24 errores antes de comenzar el periodo de pruebas. Slo existen tres
defectos latentes. Al considerar los costos relativos asociados con el descubrimiento y la correccin de errores se puede establecer el costo global (con revisin y sin
ella para el ejemplo hipottico). El nmero de errores descubiertos durante cada uno
de los pasos anotados en las figuras 26..3 y 26.4 se multiplica por el costo para eliminar un error (1.5 unidades de costo para diseo, 6.5 unidades de costo antes de las
pruebas, 15 unidades de costo durante las pruebas, y 67 unidades de costo despus
de la liberacin). Empleando estos datos, el costo total para desarrollo y mantenimiento es de 78.3 unidades cuando se re.aliz.an revisiones. Si no se realizan revisiones el costo total es de 2 177 unidades casj tres , eces ms costoso.
T/8
PARTE CUATRO
En las revisiones un ingeniero de software debe utilizar tiempo y esfuerzo, y la organizacin desarrolladora, dinero. Sin embargo, los resultados del ejemplo precedente no dejan duda acerca de pagar ahora o hacerlo ms tarde. Las revisiones tcnicas
formales (para el diseo y otras actividades tcnicas) ofrecen un beneficio demostrable en el costo. Se deben llevar a cabo.
Cuando se
llevan a cabo
RTF, cules son
los objetivos?
'
Una revisin tcnica formal (RTF) es una actividad de control de calidad del software que llevan a cabo los ingenieros de software (y otros). Los objetivos de una RTF
son 1) descubrir errores en la funcin, lgica o implementacin en cualquier representacin del software; 2) verificar que el software en revisin satisface sus requisitos; 3) garantizar que el software se ha representado de acuerdo con los estndares
predefinidos; 4) lograr software desarrollado en una manera uniforme; y 5) hacer
proyectos ms manejables. Adems, la RTF sirve como un campo de entrenamiento, pues permite que los ingenieros menos experimentados observen diferentes enfoques respecto del anlisis, el diseo y la construccin del software. La RTF tambin
funge como promotora del soporte y la continuidad, pues varias personas se familiarizan con las partes del software que de otra forma nunca veran.
La RTF es en realidad una clase de revisin que incluye recorridos, inspecciones.

revisiones cclicas y otro pequeo grupo de evaluaciones tcnicas de software. Cada
RTF se realiza en una junta y tendr xito slo si se planifica, controla y atiende apropiadamente. En las siguientes secciones se presentan directrices similares a las de
un recorrido (por ejemplo, [FRE90J, [GIL93]) que se presenta como una revisin tcnica formal representativa.
26.4. l
La junta de revisin
Sin importar el formato de RTF que se elija, cualquier junta de revisin debe atenerse a las siguientes restricciones:
En la revisin se deben involucrar (usualmente) entre tres y cinco personas.
Se debe preparar con anticipacin, pero sin que requiera ms de dos horas de
trabajo de cada persona.
La duracin de la junta de revisin debe ser menor a dos horas.
Dadas estas restricciones. debe ser obvio que una RTF se enfoca en una parte especfica (y pequea) del software total. Por ejemplo, ms que intentar revisar un diseo completo, se llevan a cabo recorridos para cada componente o grupo pequeo de
componentes. Al estrechar el enfoque, la RTF tiene una mayor probabilidad de descubrir errores.
.,~,
C~YE
..ni RTF se enfoco en
n porcin
~mente pequeo
3e uo producto de
-mojo.
f:o a~unas siluociones

1ts lxiena idea hacer
~ alguien distinto al
~rrecormel
,r,cto que experi-
Esto
-rllce ouno inter
:rmin /itero/ del
.=,ero de trabo;o y
l"'flll!J revisin.
JI meior reconocir'Bllo de los errores.
CAPTULO 26
779
El enfoque de la RTF se dirige a un producto de trabajo (por ejemplo, una porcin

de una especificacin de requisitos, un diseo detallado de componente, una lista de
cdigo fuente de un componente). El individuo que ha desarrollado el producto de trabajo -el productor- le informa al jefe del proyecto que el producto est completo y
que se requiere una revisin. El jefe del proyecto se pone en contacto con un jefe de
revisin, quien evala la disponibilidad del producto, genera copias del material del
producto y las distribuye a dos o tres revisores para que realicen sus observaciones
antes de la junta. se espera que cada revisor emplee entre una y dos horas en revi sar el producto, tomar notas y familiarizarse con el trabajo. Al mismo tiempo, el jefe de revisin tambin revisa el producto y establece una agenda para la junta de revisin, la que usualmente se programa para el da siguiente.
A la junta de revisin asisten el jefe de revisin, todos los revisores y el productor.
uno de los revisores asume el papel de registrador; es decir, el individuo que registra
(por escrito) los temas importantes que surjan durante la revisin. La RTF comienza
con una presentacin de la agenda y una breve introduccin a cargo del productor.
Entonces el productor procede a recorrer el producto de trabajo y explica el material,
mientras que los revisores exponen los problemas que descubrieron antes de la junta. Cuando se descubren problemas o errores vlidos el registrador anota cada uno.
Al final, todos los asistentes a la RTF deben decidir si l) aceptan el producto sin
modificaciones posteriores, 2) rechazan el producto debido a errores severos (una
vez corregidos se tiene que realizar otra revisin) o 3) aceptan el producto provisionalmente (se encontraron errores menores que es necesario corregir, pero no se requerir revisin adicional) . Cuando se tome la decisin, todos los asistentes a la RTF
llenan un documento de finalizacin en el que indican su participacin en la revisin
y su conformidad con los hallazgos del equipo revisor.
26.4.2 Informe de la revisin y conservacin de registros

Durante la RTF, un revisor (el registrador) registra activamente todos los problemas
que hayan surgido. stos se resumen al final de la junta de revisin y se genera una
lista de problemas de revisin. Adems, se llena un informe re.sumen de la revisin tcnica formal. Un informe resumen de la revisin responde tres preguntas:
1. Qu se revis?
2 . Quin lo revis?
3. Cules fueron los hallazgos y conclusiones?
El informe resumen de la revisin es un formato de una sola pgina (con posibles
anexos). Se vuelve parte del reg:.stro tustrico del proyecto y es posible distribuirlo
entre el jefe del proyecto y otras partes interesadas.
La lista de problemas de la revisin cumple dos propsitos: 1) identificar reas
problema en el producto y 2) funcionar como lista de verificacin de elementos de
accin que guan al productor conforme se hacen las correcciones. Normalmente al
informe resumen se anexa una lista de problemas.
780
PARTE CUATRO
GESTIN DE PROVECfOS DE SOF1WARE
Es importante establecer un procedimiento de seguimiento para garantizar que

los elementos en la lista de problemas se han corregido adecuadamente. A menos
que esto se haga, es posible que los problemas surgidos "caigan entre las grietas
Un enfoque consiste en asignar la responsabilidad del seguimiento al jefe de re\1sin.
- - rN!i6n es un suteso en el que se toman los minutos yse pierden ~ horas.ft
26.4.3 Directrices de la revisin

Las directrices para realizar las revisiones tcnicas formales es necesario establecerlas con anticipacin, distribuirlas entre todos los revisores, suscribirlas y luego se
guirlas. Una revisin descontrolada usualmente es peor que carecer de una. Las s.
guientes representan un conjunto mnimo de directrices para las revisiones tcnica.5
formales:
No seale los errores

de manero hiriente.
Una formo de ser
gentil es preglHlfrlr
oigo que permitrJ ol
produdor descubrir el
error.
1. Revisar el producto, no al productor. Una RTF involucra personas y egos. Realizada con propiedad, la RTF debe dejar a todos los participantes con un clido
sentimiento de logro. Si se lleva a cabo de manera inadecuada, la RTF puede
tomar un aura inquisitorial. Los errores se deben sealar con gentileza; el ter
no de la junta debe ser relajado y constructivo; la finalidad no debe ser avergonzar o menospreciar.
2. Establecer una agenda y respetarla. Un mal clave de las juntas de cualquier tipr...
es la divagacin. Una RTF tiene que mantener el rumbo y seguir el programa
El jefe de revisin tiene la responsabilidad de mantener el programa de la jUI:ta y no vacilar en llamar la atencin de la gente cuando se empiece a divagar
3. Umitar el debate y la impugnacin. Cuando un revisor plantee un problema, ta.
vez no haya un acuerdo universal sobre su impacto. En lugar de perder tiempo debatiendo la cuestin, el problema se debe registrar para tratarlo informalmente despus.
4. Enunciar reas de problemas, pero no se intente resolver todos los que se hayan
sealado. Una revisin no es una sesin para resolver problemas. Esto se debe
posponer hasta despus de la junta de revisin.
5. Tomar notas. En ocasiones es buena idea que el registrador tome notas en ur.::
pizarra, de modo que las palabras y las prioridades puedan evaluarlas otros
revisores conforme se registra la informacin.
6. Umitar el nmero de participantes e insistir en la preparacin anticipada. Dos cabezas piensan mejor que una, pero 14 no necesariamente son mejores que
cuatro. Mantngase el nmero de personas involucradas en el mnimo necesario. Sin embargo, todos los miembros del equipo revisor deben prepararse
por anticipado. El jefe de revisin debe solicitar comentarios escritos (lo que
ofrece un indicio de que el revisor ha analizado el material).
CAPITULO 26 GESTIN DE LA CAUDAD
781
7. Desarrollar una lista de verificacin para cada producto que tenga probabilidad
de ser revisado. Una lista de verificacin ayuda al jefe de revisin a estructurar

la junta de RTF, y a cada revisor a enfocarse en los problemas importantes.
8.
Asignar recursos y programar las KTF. Las revisiones sern efectivas si se programan como una tarea del proceso de software. Adems, se debe programar
tiempo para realizar las inevitables modificaciones que ocurrirn como resultado de una RTF.
9. Realizar un entrenamiento significativo de todos los revisores. Los participantes

en la revisin sern eficientes si reciben algn entrenamiento formal. El entrenamiento debe subrayar tanto los problemas relacionados con el proceso
como el lado psicolgico y humano de las revisiones.
1 o.
Analizar las revisiones previas. La junta es beneficiosa para descubrir problemas en el proceso de revisin mismo. El primer producto que se haya revisado debe establecer las directrices de revisin.
Puesto que muchas variables (por ejemplo, nmero de participantes, tipo de productos de trabajo, tiempo y duracin, enfoque especfico de revisin) inciden en una
revisin provechosa, una organizacin de software debe experimentar para determinar qu enfoque funciona mejor en un contexto local. Porter y sus colegas [POR95]
ofrecen una excelente gua para este tipo de experimentacin.
26.4.4 Revisiones basadas en muestras

En un contexto ideal, cada producto de trabajo de ingeniera del software debera experimentar una revisin tcnica formal. En el mundo real de los proyectos de software, los recursos son limitados y el tiempo es corto. Como consecuencia, usualmente las revisiones se soslayan, aunque se reconozca su valor como mecanismo
de control de calidad. Thelin y sus colegas [THEOlJ abordan este tema cuando afirman:
Las inspecciones [RTFJ slo son vistas como efientes si se encuentran muchas fallas durante su bsqueda. Si en los artefactos (productos de trabajo] se encuentran muchas fallas, las inspecciones son necesarias. Si, por otra parte, slo se encuentran pocas fallas, la
inspeccin ha sido una prdida de UemJX> para muchas personas involucradas en la tarea.4 Ms an, los proyectos de software que estan atrasados con frecuencia disminuyen
el tiempo de las actividades de in.specoon lo que conduce a una falta de calidad. Una so-
Desde luego, se puede argumentar que al~-a:r a'Gib:>rens:ones. se alienta a los productores a enfocarse en la calidad, incluso si no se encuectr.lr. ~
782
PARTE CUATRO GemN DE POOYECJ'OS DE SOFTWARE

lucin sera asignar jerarquas a los recursos para las actividades de inspeccin y, en consecuencia, concentrar los recursos disponibles en los artefactos ms proclives a las fallas.
Los revisiones toman

tiempo, pero es
tiempo bien
empleado. Sin
embargo, si el tiempo
es corto y no se tiene
otro op6n, no se
dispensen las revisiones. En su lugar
utilfcense revisiones
bosodos en muestras.
Thelin y sus colegas sugieren un proceso de revisin basado en que muestras de te

dos los productos de trabajo de ingeniera del software, stas se inspeccionan par:.
determinar qu productos de trabajo son ms proclives al error. Entonces los rectrsos de las RTF completas se enfocan slo en aquellos productos de trabajo con probabilidad (basndose en los datos recopilados durante el muestreo) de ser proclives
al error.
Para ser eficaz, el proceso de revisin basado en muestras debe intentar cuant:i!:
car aquellos productos de trabajo que sean objetivos principales para las RTF c01rpletas. Para lograrlo se sugieren los siguientes pasos [THEOIJ:
l. Inspeccionar una fraccin a de cada producto de trabajo de software i. Registre el nmero de fallas f encontradas dentro de a.
2. Desarrollar una estimacin bruta del nmero de fallas dentro del producto de
trabajo i al multiplicarJi por 1/a;.
3. Ordenar los productos de trabajo en forma descendente de acuerdo con la estimacin bruta del nmero de fallas en cada uno.
4. Enfocar los recursos de revisin disponibles en aquellos productos de trabajo

con el mayor nmero estimado de fallas.
La fraccin con la que se ha hecho un muestreo del producto de trabajo debe 1) se
representativa del producto de trabajo como un todo, y 2) ser lo suficientememe
grande de tal manera que sea significativa para los revisores que realicen el muestreo. Conforme a1 aumenta, la probabilidad de que la muestra sea una representacin vlida del producto de trabajo tambin crece. Sin embargo, tambin aumenta.los recursos requeridos para levantar la muestra. Un equipo de ingeniera del software debe establecer el mejor valor para a segn los tipos de productos de traba~
producidos. 5
Thelin y sus colegas han realizado una simulacin detallada que puede ayudar a tomar esta determinacin. Vase [THEOIJ para detalles.
CAPTULO 26
783
Durante las dos dcadas pasadas, un pequeo, pero ruidoso, segmento de la comunidad de ingeniera del software ha argumentado que se requiere un enfoque ms
formal de la garanta de la calidad del software. Se puede argumentar que un programa de computadora es un objeto matemtico [SOMOlJ. En cada lenguaje de programacin se definen una sintaxis y una semntica rigurosas, y existe un enfoque riguroso respecto de la especificacin de requisitos de software (captulo 28) . Si el modelo de requisitos (especificacin) y el lenguaje de programacin se representan en
una forma rigurosa, debe ser posible aplicar pruebas matemticas de exactitud para
demostrar que un programa concuerda exactamente con sus especificaciones.
Los intentos encaminados a probar la exactitud de los programas (captulos 28 y
29) no son nuevos. Dijkstra [DJJ76J y Linger, Milis y Witt [LIN79]. entre otros, aconsejaron pruebas de exactitud de programa y los vincularon con la aplicacin de conceptos de programacin estructurada (captulo l l ).
La garanta de la calidad estadstica refleja
lUla
tendencia, creciente en la industria,
por adoptar un enfoque ms cuanntativo acerca de la calidad. Para el software, la

garanta de la calidad estadstica implica los pasos siguientes:
784
Qu pasos
se requieren
para realizar SQA
estaclistlco?
1. La informacin acerca de los defectos de software se recopila y clasifica.

2. Se intenta determinar la causa subyacente de cada defecto (por ejemplo, falta
de concordancia con las especificaciones, errores de diseo, violacin de estndares, deficiente comunicacin con el cliente).
3. Mediante el principio de Pareto (80 por ciento de los defectos se encuentra en

20 por ciento de todas las causas posibles) se asla un 20 por ciento (los "vitales").
4. Una vez que las causas vitales han sido identificadas, se corrigen los problemas que han provocado los defectos.
Este concepto relativamente simple representa un paso importante hacia la creacin
de un proceso de software adaptable en el que los cambios se hagan para mejorar
aquellos elementos del proceso que introducen errores.
,,o_.denl tlel ldigo tin 80 por cientode los errores. Encuntrelos, corrijalosl'
'
26.6.1 Un ejemplo genrico

Para ilustrar la aplicacin de los mtodos estadsticos en el trabajo de ingeniera del
software, supngase que una organizacin de ingeniera del software recopila informacin acerca de defectos durante un ao. Algunos de los defectos se descubren
cuando el software est en desarrollo; otros, despus de que se ha liberado entre sus
usuarios finales, Aunque se descubren cientos de diferentes defectos, todos tienen
una (o ms) de las causas siguientes:
Especificaciones incompletas o errneas (EIE).
Mala interpretacin de la comunicacin del cliente (MCC).
Desviacin intencional de las especificaciones (DIE).
Violacin de los estndares de programacin (VEP).
Errores en la representacin de los datos (ERD).
Interfaz de componente inconsistente (ICI).
Error en la lgica del diseo (ELD).
Prueba incompleta o errnea (PIE).
Documentacin imprecisa o incompleta (DII).
Error en la traduccin del diseo al lenguaje de programacin (TLP).
Interfaz hombre-computadora ambigua o inconsistente (IHC).
Miscelneo (MIS).
Para aplicar el aseguramiento de la calidad estadstica del software se construye la
tabla de la figura 26.5. La tabla indica que EIE, MCC y ERD son las causas vitales que
CAPTULO 26
-..:Olecci6n
datos
pmaSQA
,
co.
Total
Error
785
Serios
Moderados
Nm
Nm
Nm
22%
27%
17%
34
12
5%
IHC
205
156
48
25
130
58
45
95
36
60
28
3%
14%
6%
5%
10%
4%
6%
3%
MIL
..Q
Totales
942
--
EIE
MCC
DIE
VEP
ERO
ICI
ELD
PIE
011
TLP
__.....
....
100%
~
Menores
Nm
68
18%
103
24%
9%
68
18%
76
17%
1%
0%
20%
11%
9%
2%
12%
2%
6%
4%
18%
5%
3%
9%
5%
5%
4%
23
10
36
31
19
48
14
26
8
5%
2%
26
9
14
12
2
15
24
15
68
18
12
35
20
19
17
4%
11%
3%
6%
2%
_.Q!
-1
_4.1
-2l.
100%
379
100%
435
100%
7%
...
-=
128
.,,...
~'
. . . . . ..tml}I!
,.,,.. .
---
8%
7%
explican el 53 por ciento de todos los errores. Sin embargo, se debe observar que
EIE, ERO, TLP y ELD se seleccionarfan como las causas vitales si slo se consideraran los errores serios. Una vez determinadas las causas vitales, la organizacin de
ingeniera del software puede comenzar la accin correctiva. Por ejemplo, para corregir MCC, el desarrollador de software puede implementar tcnicas que faciliten la
recopilacin de requisitos (captulo 7) para mejorar la calidad de la comunicacin y
las especificaciones del cliente. Para mejorar ERO, el desarrollador puede adquirir
herramientas para el modelado de datos y ejecutar revisiones de diseo de datos
ms rigurosas.
Es importante anotar que la accin correctiva se enfoca principalmente en las vitales. Conforme stas se corrigen, nuevas candidatas ocupan la parte superior de la
clasificacin.
Las tcnicas de garanta estadstica de la calidad para software han demostrado
que ofrecen una mejora sustancial en la calidad [ART97J. En algunos casos, las organizaciones de software han alcanzado so por ciento de reduccin anual en los defectos despus de aplicar estas tcnicas.
La aplicacin del SQA estadstico y el principio de Pareto se pueden resumir en
una sola oracin: Emplee su tiempo enfocndose en las cosas que realmente importan,
jpero primero asegrese de entender qu es lo que realmente importa!

Un detallado anlisis del SQA estadstico est ms all del mbito de este libro.
Los lectores interesados deben consultar (GOH02J (SCH98J o [KAN95].
26.6.2 Seis sigma para ingeniea del software
Seis sigma es la estrategia ms ampliamente empleada en la actualidad para el aseguramiento de la calidad estadstico en la industria. Originalmente popularizada por
186
PARTE CUATRO
Motorola en el decenio de 1980, la estrategia seis sigma "es una metodologia rigurosa y disciplinada que utiliza anlisis de datos y estadstico para medir y mejorar e
desempeo operativo de una compaia al identificar y eliminar los 'defectos' en la
fabricacin y los procesos relacionados con el servicio" [ISI03]. El trmino "seis sigma" se deriva de seis desviaciones estndar -3.4 instancias (defectos) por milln de
ocurrencias-, lo que implica un estndar de calidad extremadamente elevado. La
metodologa seis sigma define tres pasos centrales:
Cules son
los pasos
centrales de la
metodologa seis
sigma?
Definir los requisitos del cliente, entregables y metas del proyecto por medio
de mtodos bien definidos de comunicacin con el cliente.

Medir el proceso existente y su salida para determinar el desempeo de cali-
dad actual (recopilacin de mtricas de defecto).

Analizar las mtricas de defecto y determinar las causas poco vitales.
Si un proceso de software existente est en marcha, pero se requiere mejora, seis

sigma sugiere dos pasos adicionales:
Mejorar el proceso eliminando las causas originales de los defectos.
Controlar el proceso para garantizar que el trabajo futuro no vuelva a introdu-
cir las causas de defectos.

Estos pasos centrales y adicionales a veces se conocen como el mtodo DMAMC
(definir, medir, analizar, mejorar y controlar).
Si una organizacin est desarrollando un proceso de software (en lugar de mejorar un proceso existente), los pasos centrales se aumentan de la siguiente manera:
Disear el proceso para l) evitar las causas originales de los defectos y 2)
sa-
tisfacer los requisitos del cliente.

Verificar que el modelo de proceso, de hecho, evitar los defectos y satisfar
los requisitos del cliente.
A esta variacin a veces se le llama mtodo DMADV (definir, medir, analizar, disear y verificar).
Una exposicin detallada de seis sigma se encuentra en las fuentes bibliogrficas
dedicadas a la materia. El lector interesado debe consultar nsI03], [SNE03J _
[PANOO] .
La fiabilidad del software, a diferencia de otros factores de calidad, se puede medir

dirigir y estimar empleando datos histricos y de desarrollo. La fiabilidad del software se define en trminos estadsticos como "la probabilidad de la operacin libre de
fallas de un programa de computadora en un entorno especfico durante un tiempc
especfico" [MUS87]. Con fines ilustrativos, se estima que el programa X tiene una
CAPTULO 26
787
fiabilidad de 0.96 durante un periodo de ocho horas de procesamiento. En otras palabras, si el programa X fuese ejecutado 100 veces y requiriese un total de ocho horas de tiempo de procesamiento (tiempo de ejecucin), es probable que operara correctamente (sin falla) 96 veces.
mevitlblt de 111 fiabilidad es lo simplicidad."
Siempre que se estudia la fiabilidad del software, surge una pregunta central: qu
significa el trmino falla? En el contexto de cualquier anlisis de calidad y fiabilidad
del software, la falla es la falta de concordancia con los requisitos del software. Sin
embargo, incluso dentro de esta definicin, existen gradientes. Las fallas slo pueden ser molestas y catastrficas. Una falla puede corregirse en segundos, mientras
que otra tal vez requiera semanas o incluso meses. Para complicar el tema an ms,
la correccin de una falla puede, de hecho, resultar en la introduccin de otros errores que a final de cuentas resultan en otras fallas.
26.7.1 Medidas de fiabilidad y disponibilidad

Los primeros trabajos en la fiabilidad del software intentaron extrapolar las matemticas de la teora de fiabilidad del hardware (por ejemplo, [ALV64J) a la prediccin de
la fiabilidad del software. La mayora de los modelos de fiabilidad relacionada con el
hardware tratan acerca de las fallas debidas al uso ms que a las que se deben a defectos de diseo. En el hardware, las fallas que se deben al uso fisico (por ejemplo,
los efectos de la temperatura, la corrosin, los choques elctricos) son ms probables que una falla relacionada con el diseo. Desdichadamente, lo opuesto es cierto
para el software. De hecho, todas las fallas de software se originan en problemas de
diseo o implementacin, el uso (captulo 1) no entra en el cuadro.
Ha habido debates acerca de la relacin entre conceptos clave en la fiabilidad del
hardware y su aplicabilidad al software (por ejemplo, [LIT89]. fR0090J) . Aunque todava se tiene que establecer un vnculo irrefutable, vale la pena considerar unos
cuantos conceptos simples que se aplican a elementos de ambos sistemas.
Si se considera un sistema basado en computadora, una simple medida de fiabilidad es el tiempo medio entre fallas (TMEF), donde
TMEF '' TMDF + TMDR
Las siglas TMDF y TMDR significan tiempo medio de falla y tiempo medio de reparacin, respectivamente.6
Muchos investigadores argumentan que el TMEF es con mucho ms fcil de medir que los defectos/KLDC o los defectos/ PF. Establecido de manera simple, el usuario final est preocupado por las fallas, no por el conteo total de errores. Debido a
6
Aunque se pueda requerir la depuracin (Yaxtt:Cl.alilcS relacionadas) como consecuencia de una falla, en muchos casos el software t r a b a j a r ~ despus de un reinicio sin otro cambio.
188
Algunos aspectos de
lo disponibilidad (no
estudiados aquO no
tienen nodo que ver
con los folios. Por
ejemplo, los recortes
en lo colendorizon
(para funciones de
soporte) provocan que
el sohware no est
diseonib/e.
que cada defecto contenido dentro de un programa no tiene la misma tasa de falla
la cuenta de defectos totales ofrece poca informacin de la fiabilidad del sistema.
Adems de una medida de fiabilidad, se debe desarrollar una medida de dispon:.
bildad. La disponibijjdad del software es la probabilidad de que un programa opere
de acuerdo con los requisitos en un punto dado del tiempo, y se define como
Disponibilidad= [TMDF/(TMDF + TMDR)] x 100%
La medida de fiabilidad TMEF es igualmente sensible a TMDF y TMDR. La medida d..
disponibilidad es un poco ms sensible a TMDR, y es una medida indirecta de la fa..
cilidad de mantenimiento del software.
26.7 .2 Seguridad del software

La seguridad del software [LEV86) es una actividad de aseguramiento de la calidad de,
software que se enfoca en la identificacin y evaluacin de los peligros potenciales

que pueden afectar negativamente al software y provocar una falla de todo el sistema. Si los peligros se pueden identificar temprano en el proceso de software, las caractersticas de diseo de software se pueden especificar de modo que eliminarn e
controlarn los peligros potenciales.
.....
"lo ,-lo inlaginr alguno <Olldidn que provoqueque este barcose hundo. Lo industria IIOYiera maderne il a
como parte de la seguridad del software se llevan a cabo procesos de modeladc
y anlisis. Inicialmente, los peligros se identifican y clasifican por importancia y riesgo. Por ejemplo, algunos de los peligros asociados con un control basado en computadora para la conduccin de un automvil pueden ser:
Provoca aceleracin descontrolada que no se puede detener.
No responde a la presin del pedal de freno (al apagarlo).
No responde cuando el interruptor se activa.
Pierde o gana rapidez lentamente.
Una vez identificados estos peligros en el nivel del sistema, mediante tcnicas de
anlisis se asignan severidad y probabilidad de ocurrencia. 7 Para ser eficaz, el software debe analizarse en el contexto de todo el sistema. Por ejemplo, un sutil error
de entrada de usuario (las personas son componentes del sistema) tal vez lo magnifique una falla del software para producir datos de control que posicionan de manera inadecuada un dispositivo mecnico. Si se rene un conjunto de condiciones 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 conflictos tecnolgicos, ms que en los tpicos relacionados con el proyecto.
CAPTULO 26 GESTIN DE LA CALIDAD
Oi11H5M1
u.a~... 1
.......
.........
.....
,.
IIIIIJYOStQICCi
..Wdesoftwai
bien tales externas (y slo si ellas se renen), la posicin inadecuada del
789
dispositivo
mecnico provocar una falla desastrosa. Las tcnicas de anlisis, como el anlisis
del rbol de fallas [VES8 l J, la lgica de tiempo real OAN86] o los modelos de red de
Petri [LEV87]. se emplean para predecir la cadena de eventos que pueden provocar
peligros y la probabilidad de que cada uno de los eventos ocurrir para crear la cadena.
Una vez identificados y analizados los peligros, se especifican los requisitos relacionados con la seguridad del software. Esto es, la especificacin puede contener
una lista de eventos indeseables y las respuestas deseables del sistema ante dichos
eventos. Entonces se indica el papel del software en la gestin de los eventos indeseables.
Aunque la confiabilidad del software y su seguridad estn estrechamente relacionadas, es importante entender las sutiles diferencias entre ellas. La confiabilidad del
software utiliza anlisis estadstico para determinar la probabilidad de que ocurrir
una falla del software. Sin embargo, el hecho de que ocurra una falla no necesariamente resulta en un peligro o percance. La seguridad del software examina las formas en las cuales las fallas resultan en condiciones que pueden conducir a un percance. Esto es, las fallas no son consideradas en el vaco, sino que se evalan en el
contexto de todo un sistema basado en computadora y en su entorno. Aquellos lectores con mayor inters deben remitirse al libro de Leveson [LEV95] para profundizar en el tema.
Es posible definir un sistema de garana de la calidad como la estructura organizacional, responsabilidades, procedimientos, procesos y recursos para implementar la
gestin de la calidad [ANS87]. Los sistemas de garanta de calidad fueron creados
~o describe lo
2 debe hocer poro
!"'llll~oble, pero no
-3 cmo se debe
para ayudar a las organizaciones a garantizar que sus productos y servicios satisfacen las expectativas de los clientes al cumplir sus especificaciones. El estndar ISO
9000 describe un sistema de garanta de la calidad en trminos genricos que se aplican a cualquier negocio sin importar los productos o servicios ofrecidos.
El registro en uno de los modelos de sistema de garanta de la calidad contenidos
en ISO 9000 requiere que los sistemas y operaciones de calidad de una compaa los
sometan a escrutinio auditores de una tercera entidad respecto de su concordancia
con el estndar y de su funcionamiento eficaz. Antes del registro exitoso, los auditores le extienden a la compaa un certificado de la organizacin de registro que representan. Entrevistas de auditoria semianuales garantizan la concordancia continua con el estndar.
Esta seccin, escrita por Michael
Stovsky se ha aaptado de "Fundamentals of ISO 9000", un libro
de trabajo desarrollado por Essen/Jal Software Eng:ne:nng, un video currculum elaborado por R S.
Pressman & Associates, !ne. Reimpreso a:m p;:m::so.
790
El estndar de garanta de la calidad que se aplica a la ingeniera del software es

el ISO 9001 :2000. El estndar contiene 20 requisitos que deben estar presentes par:.
un sistema eficiente de garanta de la calidad. Puesto que el estndar ISO 9001 :200
es aplicable a todas las disciplinas de ingeniera, se ha desarrollado un conjunto especial de directrices ISO (ISO 9000-3) que ayudan a interpretar el estndar para emplearlo en eJ proceso de software.
Los requisitos que delinea ISO 9001 :2000 abordan tpicos como responsabilidad
de la gestin, sis~ema de calidad, revisin de contrato, control de diseo, control de
documentos y datos, identificacin y seguimiento de producto, control de proceso
inspeccin y pruebas, acciones correctivas y preventivas, control de registros de calidad, auditoras de calidad interna, entrenamiento, servicio y tcnicas estadsticas
una organizacin de software obtendr el registro ISO 9001 :2000 si establece polticas y procedimientos para abordar cada uno de los requisitos anotados lneas arriba
(y otros) y, adems, ser capaz de demostrar que se siguen dichas polticas y procedimientos. Para mayor informacin acerca de ISO 9001, el lector interesado debe consultar [HOY02], [GAAOIJ o [CIAOIJ.
Definir un pion de calidad que aborde objetivos, respon

sabilidodes y autoridad.
Informacin ms amplio acerco del estndor se puede ob
lener de lnlernotionol Organizotion for Stondordizotion
(www.io.ch) y en otro fuentes de Internet (por ejemplo,
www.praxiom.com).
Edobl~r los lementos de un sistema de gestin de coli

dad.
Definir mecanismos de comunicacin entre los portici

pontes.
Establecer mecanismos de revisin poro el sistema de gestin de calidad.
Identificar mtodos de revisin y mecanismos de retroalimentacin.
Desarrollar, implementar y mejorar el sistema.
Definir procedimientos de seguimiento.
Definir uno poltico que enfatice lo importancia del siste

mo.
Identificar recursos de calidad que incluyan personal,

entrenamiento, elementos de infraestructura.
Documentar el sistema de calidad.
Establecer mecanismos de control.
Describir el proceso.
Poro ploneocin.
Producir un manual operativo.
Poro requisitos del cliente.
Desarrollar mtodos poro controlar (actualizar) los docu

mentos.
Poro actividades tcnicos (por ejemplo, onlisis, diseo,

pruebos).
Establecer mtodos poro lo conservacin de registros.
Poro supervisin y gestin del proyecto.
Soporte del control y lo garanta de calidad.

Promover lo importancia de lo calidad entre todos los
porticipontes.
Enfocarse en la satisfaccin del diente.
Definir mtodos poro correccin.

Valorar los datos y mtricos de calidad.
Definir enfoques poro procesos continuos y mejoro de lo
calidad.
CAPTULO 26
791
El plan de SQA proporciona un mapa para instituir la garanta de la calidad del software. Desarrollado por el grupo de SQA (o el equipo de software si no existe un grupo SQA), el plan funciona como plantilla para las actividades de SQA que se instituyan para cada proyecto de software.
En el IEEE [JEE94) se ha publicado un estndar para planes de SQA. El estndar
recomienda una estructura que identifica: 1) el propsito y mbito del plan; 2) una
descripcin de todos los productos de trabajo de ingeniera del software (por ejemplo, modelos, documentos, cdigo fuente) que caen dentro del alcance del SQA; 3)
todos los estndares y prcticas aplicables que se aprovechan durante el proceso de
software; 4) acciones y tareas de SQA (incluso revisiones y auditoras) y su ubicacin
a travs del proceso de software; 5) las herramientas y mtodos que soportan las acciones y tareas de SQA; 6) procedimientos de gestin de configuracin de software
(captulo 27) para gestionar el cambio; 7) mtodos para ensamblar, salvaguardar y
mantener todos los registros relacionados con el SQA; y 8) papeles y responsabilidades en la organizacin relativas a la calidad de producto.
Gesn de la calldad del software

Objetivo: El obetivo de las herramientas de
.
.
SQA es aux1l1ar al equipo de proyecto para va
.
.
.
aorar y me1orar la calidad del producto de traba10 de soft.
Mecnica: La mecnica de las herramientas vara. En
general, la finalidad es valorar la calidad de un producto
de trabajo especfico. Nota: con frecuencia, dentro de la
categora de herramientas de SQA, se incluye una amplia
omiedad de herramientas de prueba de software (captulos
13y 14).
Herramientas representarivas9
ARM, desarrollado por la NASA (satc.gsfc.nasa.gov/tools/index.htmll, ofrece medidas con las cuales se evala
lo calidad de un documento de requisitos de software.
QPR ProcessGuide ond Scorecord, desarrollado por QPR
I'"\..
J1y Tcoos Gookbook, desarro11a do por Sytsma and

M 1 (
/tq tool /tq tool me
an ey www.sytsma.com m s m
html)
.
d

't'I d h
nu.
, proporciona escnpc1ones u I es e erra
mientas clsicas de gestin de calidad tales como los
diagramas de control, diagramas de dispersin, dio
gramas de afinidad y diagramas de matriz.
\XuO,
Qualily Tools ond Templotes, desarrolladas por iSixSigma

(http://www.isixsigma.com/tt/), describe una amplia
variedad de herramientas y mtodos tiles para gestin
de calidod.
TQM Tools, desarrollado por Bain & Company (www.bain.

cam), brinda descripciones tiles de una variedad de
herramientas de gestin usadas por TQM y relaciono
das con los mtodos de gestin de calidad.
Software (www.qpronline.com), ofrece soporte para

seis sigma y otros enfoques de gestin de calidad.
Las herramientas expuestas slo representan una muestra de esta categora. En la mayora de los
casos los nombres de las mismas son marcas regxstradas por sus respectivos desarrolladores.
792
La gestin de la calidad del software es una actividad protectora o de somb

-que incorpora tanto control como aseguramiento de la calidad- que se aplic. a
cada paso en el proceso del software. La SQA abarca procedimientos para la ap "
cin eficaz de mtodos y herramientas. revisiones tcnicas formales, estrategia:.:.
tcnicas de pruebas, procedimientos para control del cambio, procedimientos ~-a
garantizar la concordancia con los estndares y mecanismos de medicin y repor e..
La SQA la complica la naturaleza compleja de la calidad del software, un atri~
to de los programas de computadora que se define como "concordancia con os
requisitos especificados explicita e implcitamente". Pero cuando se considera de
manera ms general, la calidad de software abarca muchos productos diferentes
factores de proceso y mtricas relacionadas.
Las revisiones de software son una de las actividades de control de calidad ms
importantes. Las revisiones sirven como filtros a travs de todas las actividades de
ingeniera del software, que eliminan los errores mientras son relativamente poco
costosos de encontrar y corregir. La revisin tcnica formal es una junta que ha demostrado ser extremadamente eficaz para descubrir errores.
La actividad adecuada para garantizar la calidad del software requiere recopilar
evaluar y distribuir los datos acerca de los procesos de ingeniera del software. La
SQA estadistica ayuda a mejorar la calidad del producto y el proceso de software es mismo. Los modelos de fiabilidad del software extienden medidas, lo que permite
recopilar datos de defecto para extrapolarlos en las tasas de falla proyectadas y tas
predicciones de fiabilidad.
En resumen, recurdense las palabras de Dunn y Uliman [DUN82]: "El aseguramiento de la calidad del software es el mapeo (correlacin) de los preceptos gerenciales y tas disciplinas de diseo de la garanta de calidad en el espacio gerencial y
tecnolgico aplicable de la ingeniera del software". La habilidad para garantizar la
calidad es la medida de una disciplina de ingeniera madura. Cuando el mapeo se logra de manera exitosa, el resultado es la ingeniera de software madura.
Blf1BIKAJ6I
'. t
tALV64J Alvin, w. H., von (ed.), Reliabili!}' Engineering, Prentice Hall, 1964.
[ANS87J ANSI/ASQC A3 1987, Quality systems Terminology, 1987.
[ART92] Arthur, L. J., Improving Software Quality: an lnsider's Guide to TQM, Wiley, 1992.
[ART97] Arthur, L. J. "Quantum lmprovements in Software System Quality, en CACM, vol. 40,
nm. 6, junio de 1997, pp. 47-52.
[BOE8 l J Boehm, B. Software Engineering Economics. Prentice-Hall, 1981.
!ClAOlJ Cianfrani, C. A . et al., ISO 9001:2000 Explained, 2a ed., American Society for Quality,
2001.
[CR079] Crosby, P., QualifY Is Free, McGraw-Hill, 1979.
[DEM86J Deming, W. E., Out oftl1e Crisis, MlT Press, 1986.
[DEM99J DeMarco, T., "Management Can make Quality (lm)possible", Cutter 1T Summit, Boston,
abril de 1999.
CAPTULO 26
793
[DIJ76J Dijkstra, E., A Discipline of Programmng, Prentice-Hall, 1976.

[DUN82J Dunn, R., y R. Ullman, Quality Assurance Jor Computer Software, McGraw-Hill, 1982.
[FRE90) Freedman, D. P. y G. M. Weinberg, Handbook of Walklhroughs, lnspections and Technica/
Reviews, 3a. ed., Dorset House, 1990.
[GAAOIJ Gaal, A., JSO 9001 :2000 Jor Small Business, Saint Lucie Press, 2001.
[GIL93] Gilb, T., y D. Graham, Software Inspections, Addison-Wesley, 1993.
[GLA98] Glass, R., "Defining Quality lntuitively", en JEEE Software, mayo de 1998, pp. 103- 104, 107.
(GOH02] Goh, T., V. Kuralmani y M. Xie, StaUstica/ Mode/s and Control ChartsJor High Qua/iy Processes, Kluwer Academic Publishers, 2002.
[HOY02] Hoyle, D., ISO 9000 Quality Systems Development Handbook: A Systems Engineering Approach, 4a. ed., Butterworth-Heinemann, 2002.
(1BM8IJ "Implementing Software lnspections", notas de curso, IBM Systems Sciences Institute,
IBM Corporation, 1981.
[IEE94] Software Engineering Standards, 1994, IEEE Computer Society, 1994.
[ISI03] iSi.xSigma, LLC, "New to Six Sigma: A Guide for Both Novice and Experienced Quality
Practilioners", 2003, disponible en http://www.isixsigma.com/library/content/six-sigmanewbie.asp.
(JAN86J Jahanian, F. y A. K. Mok, "Safety Analysis of Tming Properties of Real-Time Systems",
en IEEE Trans. Software Engineering, vol. SE-12, nm. 9, septiembre de 1986, pp. 890-904.
[JON86J Jones, T. C., Programming Productiviy, McGraw-Hill, 1986.
[KAN95] Kan, S. H., Metrics and Models in Software Qualty Engineering, Addison-Wesley, 1995.
[LEV86J Leveson, N. G., "Software Safety: Why, What, and How", en ACM Compuling Surveys, vol.
18, nm. 2, junio de 1986, pp. 125-163.
[LEV87J Leveson, N. G. y J. L. Stolzy, "Safety Analysis Using Petri Nets", en IEEE Trans. Software
Engineering, vo\. SE.- 12>, nm. 3, marzo de 1987, pp. 386-397.
[LEV95J Leveson, N. G., Safeware: System Saje!}' and Computers, Addison-Wesley, 1995.
[LIN79J Linger, R., H. Milis y B. Witt, Structured Programming, Addison-Wesley, 1979.
[LIT89] Littlewood, B., "Forecasting Software Reliability", en Software Reliabili(y: Modeling and
ldenUficalion (S. Bittanti, ed.), Springer-Verlag, 1989, pp. 141-209.
[MUS87] Musa, J. D., A. lannino y K. Okumoto, Engineering and Managing Soflvvare with Reliability Measures, McGraw-Hill, 1987.
[PANOO] Nande, P. et al.. The Six Sigma Way, McGraw-Hill, 2000.
[POR95J Porter, A., H. Siy, C. A. Toman y l. G. Votta, "An E.xperiment to Assess the Cost-Benetits of Code Inspections in Large Seale Software Development", en Proc. Third ACM SJG-SOFT
Symposium on the Foundalions of Software Engineering, Washington, D.C., octubre de 1995,
ACM Press, pp. 92- 103.
[R0090) Rook, J., Softvvare Reliabiliy Handbook, Elsevier, 1990.
[SCH98] Schulmeyer, G. c. y J. l. McManus (eds.), Handbook of Software Quali(y Assurance, 3a.
ed., Prentice-Hall, 1998.
[SOMOlJ Somerville, l., Software Engineering, 6a. ed, Addison-Wesley, 2001.
[SNE03J Snee, R. y R. Hoerl, Leading Six Sigma, Prentice-Hall, 2003.
[THE01J Thelin, T., H. PeterssonyC. Wohlin, "Sample Driven Inspections", enProceedings Works
hop on Jnspection in Software Engineering (WISE'OJJ, Pars, Francia. julio de 2001, pp. 81 -9 1,
se puede descargar de http://www.cas.mcmaster.ca/wise/wiseO 1/thelinPetersson-Woh lin.pdf.
[VES8 I J Veseley, W. E. et al., Fault Tree Handbook, U.S. Nuclear Regulatory Commission, NUREG0492, enero de 1981.
A GQMIWIRII
26.1. En las primeras pginas de este capttwo se anot que "el control de la variacin es el corazn del control de calidad". Dado que cualquier programa que se crea es diferente de todos
los otros programas, cules son las vanaaones que se buscan y cmo se les controla?
26.2 . Es posible valorar la calidad del software si el diente cambia con frecuencia lo que se
supone debe hacer?
794
PARTE CUATRO GESTIN DE PROYECTOS DE SOF'!WARE
26.3. La calidad y la fiabilidad son conceptos relacionados pero fundamentalmente difereru.=

en varias formas. Comntense.
26.4. Puede un programa ser correcto y an as no ser fiable? Explquese.
26.5. Puede un programa ser correcto y an as no mostrar buena calidad? Expllquese.
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 ~
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 software 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. C..
mo reconoce en la revisin a un participante que no est preparado? Qu hace si usted es e
jefe de revisin?
26.1 o. 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 errores serios y moderados. Sugiera acciones correctivas empleando la informacin presentada er
otros captulos.
26.12. Investigue la bibliografa acerca de la fiabilidad del software y escriba un ensayo qt.,c
describa un modelo de fiabilidad de software. Asegrese de proporcionar un ejemplo.
26.13. El concepto de TMEF para software est abierto a criticas. Puede pensar en algunas razones 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 directamente con las fallas de software.
26.15. Adquiera una copia de ISO 900 I :2000 e ISO 9000-3. Prepare una presentacin que ex.amine tres requisitos ISO 9001 y cmo se aplican en un contexto de software.
Los libros de Moriguchi (S0jlware Excel/ence: A Total Quality Managemenl Guide, Productivilj
Press, 1997) y Horch (Practical Guide to SOflware Qua/ig Management, Artech Publishing, 1996
son excelentes presentaciones, en el mbito gerencial, de los beneficios de los programas formales de aseguramiento de la calidad del software de computadora. Los libros de Deming
[DEM86). Juran (!uran on Qua/ig by Design, Free Press, 1992) y Crosby ([CR079] y Qua/ig Is Sllli
Free, 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 (EVery
day Heroes ofthe Qualig Movement, Dorset House, 1993) humanizan los temas de calidad al contar la historia de los actores en el proceso de calidad. Kan (Metrics and Models in Software Qualigt Engineering. Addison-Wesley, 1995) presenta una visin cuantitativa de la calidad del software.
Cianfani y sus colegas (ISO 900 I :2000 E:xplained, segunda edicin, American Society for Quality, 2001) y Gaal (ISO 900 I :2000for Small Business: Implementing Process-Approach Quality Management, St. Lude Press, 2001) estudian el estndar de calidad ISO 9001:2000. Tingley (Comparing ISO 9000, Malcolm Baldrige, and the SEi CMMfor Software, Prentice-Hall, 1996) ofrecen
una gua til para las organizaciones que luchan por mejorar sus procesos de gestin de calidad.
Los libros de George (Lean Six Sigma, McGraw-Hill, 2002), Pande y sus colegas (The Six Sigma Way Fieldbook, McGraw-Hill, 2001) y Pyzdek (The Six Sigma Handbook, McGraw-Hill, 2000)
CAPiTuJ.O 26
795
describen seis sigma, una tcnica estadstica de gestin de calidad que conduce a productos que
tienen muy bajas tasas de defectos.
Radice (High Qua/i~ Low Cost software lnspections, Paradoxicon Publishers, 2002), Wiegers
(Peer Reviews in SOftware: A Practica) Guide, Addison-Wesley, 2001). Gilb y Graham (SO}tware Jnspection, Addison-Wesley, 1993) y Freedman y Weinberg (Handbook ofWa/kthroughs, lnspections
and Technica/ Reviews, Dorset House, 1990) ofrecen directrices valiosas para llevar a cabo revisiones tcnicas formales efectivas.
Musa (SO}tware Reliability Engineering: More Reliab/e Software, Faster Development and Testing,
McGraw-Hill, 1998) ha escrito una gua prctica para tcnicas de fiabilidad de software aplicado. Kapur el al. (Contributions to Hardware and SOjtware Reliability Modeling, World Scientific Publishing Co., 1999), Gritzalis (Reliability, Quality and safety ofSoflware-Tntensive ~tems, Kluwer
Academic Publishers, 1997) y Lyu (Handbook o/software Reliability Engineering, McGraw-Hill,
1996) han editado antologas de importantes ensayos acerca de la fiabilidad del software.
Hermann (Software Safety and Reliabi/ity, Wiley-lEEE Press, 2000), Storey (Safety-Cntical Computer Systems, Addison-Wesley, 1996) y Leveson [LEV95) continan siendo los estudios ms detallados de la seguridad del software publicados a la fecha. Adems, van der Meulen (Deji.nitions
Jor Hardware and SOftware Safety Engineers, Springer-Verlag, 2000) ofrece un compendio completo de importantes conceptos y trminos de fiabilidad y seguridad. Gartner (Testing safety-Re/ated Software, Springer-Verlag, 1999) ofrece una gua especializada para probar sistemas cruciales de seguridad. Friedman y Voas (SOftware Assessment: Reliability Sajety and Testability, Wiley, 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 gestin de calidad de software. Una lista actualizada de referencias en la World Wide Web se puede encontrar en el sitio Web SEPA:
CAPTULO
27
CONCEPTOS
CLAVE
auditotia, 8t 3
aanliio ......797
contn,I
de la versin . .822
contn,I
dtlmmbio .. .810
depsito ..... .803
ECS 801
estndares .. 824
GC WebApp .. 814
gestin
del COltenicla
817
idelrlifimcia 807
lllforae
dt estado ... .814
liea~ ... .aoo

olitetos de
co1fipracil . 80 7
promo de GCS ,806
svc ....... ..809
GESTIN
DEL CAMBIO
l cambio es inevitable cuando se construye software de computadora. Y el
catnbio aumenta el grado de confusin entre los ingenieros de software que
trabajan en un proyecto. La confusin surge cuando los cambios no se ana
!izan antes de realizarlos, no se registran antes de implementarlos, no se repor
tan a quienes deben saberlo o no se controlan en una forma que mejorar la
calidad y reducir el error Babich (BAB86J aborda esto cuando afirma
El arte de coordinar el desarrollo de software para minimizar.. la confusin se llama

gestin de la configuracin La gesun d{' la configuracin es el arte de ident1flcar, organizar y controla:r modifkaciones al software que se construye por mcdo de un
equipo de programacin. La meta es maximizar la productividad al minirrnzar las
equivocaciones
La gestin del cambio, ms usualmente llamada gestin de la conjiguradn del
sojtware (GCS o GC), es una actividad protectora (Sombrlla) que se aplica a lo

largo del proceso de software. Puesto que el cambio puede ocurrir en cualquier
momento, las actividades de GCS se desarrollan para I) identificar el cambio, 2
controlar el cambio, 3) garantizar que el cambio se implementar de manera
adecuada, y 4) reportar los cambios a otros que pudieran estar interesados.
Es importante distinguir con claridad entre soporte de software y gestin de
la configuracin del software. El soporte es un conjunto de actividades de ingeniera del soflware que ocurren despus de que ste se ha entregado al cliente y
fue puesto en operacin La gestin de la configuracin del software es un conjunto de actividades de seguimiento y control que se inician cuando comienza
un proyecto de ingeniera del software y terminan slo cuando ste se retira de
operacin.
CAPTULO 27 GESTIN DEL CAMBIO
797
Una meta primordial de la ingenieria del software es mejorar la facilidad con la

que los cambios se pueden acomodar y reducir el esfuerzo cuando los cambios se
deben realizar. En este captulo se estudian las acciones especficas que permiten
gestionar el cambio.
La salida del proceso de software es informacin que se puede dividir en tres amplias
categorlas: l) programas de computadora (tanto al nivel de fuente como de formas

ejecutables); 2) productos de trabajo que describen los programas de computadora
(dirigidos tanto a profesionales tcnicos como a usuarios), y 3) datos (internos o
externos al programa). Los elementos que comprenden la informacin producida
como parte del proceso de software se denominan colectivamente conjiguradn del
software.
Si cada elemento de configuracin simplemente condujera a otros elementos
habra poca confusin. Por desgracia, otra variable entra en el proceso: el cambio.
ste puede ocurrir en cualquier momento, por cualquier razn. De hecho, la primera ley de la ingenierla de sistemas [BERBOJ afirma: "No importa dnde se encuentre
en el ciclo de vida del sistema, el sistema cambiar y el deseo de cambiarlo persistir a lo largo de todo el ciclo de vida" .
. ....
,._,.,,........ 11....:
Cul es el origen de estos cambios? La respuesta es tan variada como los cambios mismos. Sin embargo, existen cua1rO fuentes fundamentales de cambio:
798
PARTE CUATRO
Cul es el
origen ele los
cambios que se
requierett para el
software?
GESTIN DE PROYECTOS DE SOFIWAJIB
Nuevas condiciones en el negocio o mercado dictan los cambios en los reqi..sitos del producto o las reglas del negocio.
Nuevas necesidades del cliente demandan la modificacin de los datos que
producen los sistemas de informacin, de la funcionalidad que entregan los
productos o los servicios que entrega un sistema basado en computadora.
La reorganizacin o el crecimiento o reduccin del negocio provocan camblOS
en las prioridades del proyecto o en la estructura del equipo de ingenieria de.
software.
Restricciones presupuestales o de calendarizacin inducen una redefinicin
del sistema o producto.
La gestin de la configuracin del software es un conjunto de actividades que se hadesarrollado para gestionar el cambio a lo largo del ciclo de vida del software ec
computadora. La GCS se considera como una actividad de aseguramiento de la c:a...dad del software que se aplica a lo largo del proceso respectivo. En las secciones.
siguientes se examinan las principales tareas de la GCS y conceptos importantes q-...c
ayudan a gestionar el cambio.
27. 1. 1 Un escenario de GCS1
Cules SOII
las aetas y
las actividades
realliadas por
'cada uno de los
partklpantes
ilvolucraclos en la
tfflln del cam
liio?
Un tpico escenario operativo de GCS involucra un gestor de proyecto a cargo de u:grupo de software; un gestor de configuracin a cargo de los procedimientos y pooticas de GC; los ingenieros de software responsables del desarrollo y mantenimierto del producto de software, y el cliente que emplea el producto. En el escenario
supngase que el producto es pequeo e involucra cerca de 15 000 lneas de cdigc
que desarrollar un equipo de seis personas. (Ntese que son posibles otros escenarios cte equipos menores o mayores, pero, en esencia, existen conflictos genricos
que cada uno de estos proyectos enfrenta en relacin con la GC.)
En el mbito operativo el escenario involucra diversos papeles y tareas. La meta
del gestor del proyecto es garantizar que el producto se entregue dentro de cierto
periodo. En consecuencia, el gestor supervisa el progreso del desarrollo y reconoce
y reacciona ante los problemas. Esto se hace al generar y analizar los informes acerca del estado del sistema de software y al realizar revisiones en el sistema.
Las metas del gestor de configuracin son garantizar que se siguen los procedimientos y polticas para crear, cambiar y poner a prueba el cdigo, as como posibilitar el acceso a la informacin acerca del proyecto. La implementacin de tcnicas
para mantener el control sobre los cambios de cdigo requiere que este gestor introduzca mecanismos para solicitar oficialmente cambios, evaluarlos (mediante una
junta de control de cambios, que es la responsable de aprobar los cambios al siste1 Esta seccin procede de [DARO I J. El permiso especial para reproducir "Spectrum of Functionality in
CM Systems" de Susan Dart [DAROIL 2001 por Carnegie Mellon University, lo otorg el Software
Engineering lnstitute.
CAPTULO 27
G.1!S'l'IN DEL CAMBIO
799
ma de software) y autorizarlos. El gestor crea y distribuye las listas de tareas para los
ingenieros y bsicamente crea el contexto del proyecto. Adems, el gestor recopila
estadsticas acerca de componentes en el sistema de software, por ejemplo: la informacin que determina cules componentes son problemticos en el sistema.
La meta de los ingenieros de software es trabajar con eficiencia. Esto significa que
no interfieren de manera innecesaria unos con otros en la creacin y prueba del
cdigo ni en la produccin de los documentos de soporte. No obstante, al mismo
tiempo, intentan comunicarse y coordinarse de manera eficiente. Especficamente,
los ingenieros utilizan herramientas que ayudan a construir un producto de software consistente. Ellos se comunican y coordinan al notificarse mutuamente las tareas
que se requieren y las tareas cumplidas. Los cambios se propagan por medio del trabajo de cada uno mediante archivos fusionados. Existen mecanismos para asegurar
que, respecto de los componentes que experimentan cambios simultneos, existe
alguna forma de resolver los conflictos y fusionar los cambios. La historia de la evolucin de todos los componentes del sistema se mantiene junto con un registro de
las razones de los cambios y otro de lo que cambi en realidad. Los ingenieros tienen su propio espacio de trabajo para crear, cambiar, probar e integrar cdigo. En
cierto punto, el cdigo se convierte en una lnea base a partir de la que contina el
desarrollo posterior y desde la que se realizan las variantes para otras mquinas que
tambin sean el objetivo.
El cliente emplea el producto. Dado que el producto lo controla la GC, el cliente sigue
procedimientos formales para solicitar cambios e indicar los bugs en el producto.
Idealmente, un sistema de GC utilizado en este escenario apoyara todas estas
funciones y tareas; esto es, las funciones determinan la funcionalidad requerida de
un sistema de GC. El gestor del proyecto ve una GC como un mecanismo de auditora;
el gestor de configuracin, como un mecanismo de creacin de control, seguimiento y polticas; el ingeniero de software, como un mecanismo de control del cambio,
la construccin y el acceso; y el usuario, como un mecanismo de garantia de la calidad.
27.1.2 Elementos de un sistema de gestin de la coruiguracin

En su detallado artculo acerca de la gestin de la configuracin del software, Susan
Dart [DAROIJ identifica cuatro importantes elementos que deben estar presentes
cuando se desarrolla un sistema de gestin de la configuracin:
Elementos de componentes: conjunto de herramientas acopladas dentro de un
sistema de gestin de archivos (por ejemplo, una base de datos) que permiten
el acceso y la gestin de cada elemento de configuracin del software.
Elementos de proceso: serie de procedmentos y tareas que definen un
enfoque eficaz con el cual gestionar el cambio (y actividades relacionadas)
para todos los participantes en la gestion. ingeniera y utilizacin del software
de computadora.
Elementos de construccin: conjunto de herramientas que automatizan la

construccin del software al asegurar que se ha ensamblado un conjunto
adecuado de componentes validados (es decir: la versin correcta).
Elementos humanos: la implementacin de una Ges eficaz requiere que el
equipo de software utilice un conjunto de herramientas y caractersticas de
procesos (que abarcan otros elementos de GC).
Estos elementos (que se estudiarn con ms detalle en secciones venideras) no son
mutuamente excluyentes. Por ejemplo, los elementos de componentes trabajan er
conjunto con los de construccin conforme avanza el proceso de software. Los elementos de proceso guan muchas actividades humanas que se relacionan con Ges
y, por tanto, tambin pueden considerarse elementos humanos.
27 .1.3 Lneas base

la mayora de los
cambios de software
estn justificados, osf
que no hoy razn
poro quejarse acerco
de ellos. Ms bien, es
necesario asegurarse
de que se tienenlos
mocomsmos op(IJ
piados poro mo~
jorlos.
El cambio es un hecho de vida en el desarrollo del software. Los clientes quieren

modificar los requisitos. Los desarrolladores quieren modificar el enfoque tcnico
Los gestores quieren modificar la estrategia del proyecto. Por qu todas estas modificaciones? La respuesta, en realidad, es bastante simple. Conforme pasa el tiempo
todos los participantes saben ms (acerca de lo que necesitan, qu enfoque sera el
mejor, cmo hacerlo y aun as obtener dinero). Este conocimiento adicional es la
fuerza impulsora detrs de la mayora de los cambios y conduce a una expresin dificil de aceptar para muchos profesionales de la ingeniera del software: ila mayora
de los cambios estn justificados!
Una lnea base es un concepto de gestin de la configuracin del software que
ayuda a controlar el cambio sin impedir seriamente el cambio justificable. El IEEE
(IEEE Std . No. 610.12- 1990) define una lnea base 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.
,,
~
c&v1
Un producto de trabajo
de ingenierio del
s.1twoie se convierte
erdineo hose slo
teslls de que se ha
~,~.
Antes de que un elemento de configuracin del software se convierta en linea

base, es posible realizar el cambio rpida e informalmente. Sin embargo, una vez
establecida una linea base, metafricamente se pasa a travs de una puerta giratoria de una sola direccin. Los cambios se pueden realizar, pero se debe aplicar un
procedimiento especfico formal para evaluar y verificar cada uno.
En el contexto de la ingeniera del software, una lnea base es un hito en el desarrollo del software. Se marca una lnea base para la entrega de uno o ms elementos de configuracin del software (ECS) que se han aprobado como consecuencia de
una revisin tcnica formal (captulo 26). Por ejemplo, los elementos de un modelo
de diseo se han documentado y revisado. Se han encontrado errores y se han corregido. Una vez que todas las partes del modelo se han revisado, corregido y Juego
aprobado, el modelo de diseo se convierte en lnea base. Los cambios posteriores
a la arquitectura del programa (documentados en el modelo de diseo) slo se pue-
801
C APTULO 27 GESTIN DEL CAMBIO
den efectuar despus de que cada uno se ha evaluado y aprobado. Aunque las lneas base se pueden definir en cualquier grado de detalle, en la figura 27 .1 se muestran las lneas base de software ms comunes.
En la figura 27.1 tambin se muestra la progresin de eventos que conducen a
una lnea base. Las tareas de ingeniera del software producen uno o ms ECS.
:s preciso asegurarse
i? que lo base de
jts del proyecto se
-mtiene en uno
frocin central
::rrtrolado.
Despus de que stos se revisan y aprueban se colocan en una base de datos del proyecto (tambin llamada librera del proyecto o depsto de software, que se examinan
en la seccin 27.2). Cuando un miembro de un equipo de software quiere modificar
un ECS que se ha convertido en lnea base, se copia de la base de datos del proyecto en el espacio de trabajo prvado del ingeniero. Sin embargo, este ECS extrado
slo se puede modificar si se siguen los controles de la GCS (tratados ms adelante
en este captulo). Las flechas en la figura 27. l ilustran la trayectoria de modificacin
para un ECS convertido en linea base.
27. 1.4 Elementos de configuracin del software

Un elemento de configuracin del software (ECS) es informacin que se crea como
parte del proceso de ingeniera del software. En el extremo, se puede considerar que
un ECS es una sola seccin de una gran especificacin o un caso de prueba de un
gran conjunto de pruebas. De manera ms realista, un ECS es un documento, un
conjunto completo de casos de prueba o un componente de un programa dado (por
ejemplo, una funcin C++ o un applet de Java).
Adems de los ECS provenientes de los productos de trabajo de software, muchas
organizaciones de ingeniera del software tambin colocan las herramientas respectivas bajo control de configuracin. Esto es: versiones especficas de editores, com-
ECS convertidos
en lnea base y
baSe de datos del
proyecto.
Modificado
---~
(
Toreos de
ingeniera
de soflware
Revisiones
__.. -
Base de datos del proyecto
Aprobodo
~
tcnicos _,. ~
formoles
- /
Alm-do
Exlra,do
Controles ~ . - ~ ~ - - ~
de GCS
LNEAS BASE:
Especificacin del sistema

Requisitos de soflwore
Especificacin del diseo
Cdigo fuente
Piones/ procedimientos/
dolos de pruebo
S,stemo operativo
802
PARTE CUATRO Gl:STIN DE PROYECTOS DE SOFTWARE
piladores, navegadores y otras herramientas automatizadas se "congelan" c

parte de la configuracin del software. Puesto que dichas herramientas se utiliza.para producir documentacin, cdigo fuente y datos, deben estar disponibles al re
tizar cambios en la configuracin del software. Aunque los problemas son raros
posible que una nueva versin de una herramienta (por ejemplo, un comptla
produzca resultados diferentes a los de la versin original. Por esta razn, las h ~
mientas, al igual que el software que ayudan a producir, pueden convertirse en 11:"
base corno parte de un proceso global de gestin de configuracin.
En realidad, los ECS estn organizados para formar objetos de configuracin susceptibles de catalogar en la base de datos del proyecto con un solo nombre. Un ot;:
to de conjiguradn tiene un nombre, atributos y est "conectado" con otros obje
por medio de relaciones. Si se observa la figura 27.2, los objetos de configuraa
EspecificacionDiseo, ModeloDatos, ComponenteN, CodigoFUente
EspecificaclonPrueba estn definidos por separado. Sin embargo, cada uno de
objetos se relaciona con los otros como lo muestran las flechas. Una flecha a.e-~
indica una relacin de composicin. Esto es: ModeloDatos y ComponentcN
parte del objeto EspeclflcacionDisefto. Una flecha recta con doble punta indo
una interrelacin. Si se realizase un cambio al objeto CodigoFUente, las interrela--ciones permiten que un ingeniero de software determine qu otros objetos (y E~
pueden afectarse. 2
ifrhffij
Objetos de
configuracin.
dsello ele~
_.a;,..---
cliaello arqullect6nico
c:li~ ele m6dulos - - - - - -dis.o de inllnQ%
Estas relaciones se definen dentro de la base de datos. La estructura de la base de datos (almace
se estudia con mayor detalle en la seccin 27.2.
CAPTULO 27
GESTIN DEL CAMBIO
803
En los primeros das de la ingeniera del software los elementos de configuracin se

conservaban como documentos de papel (io tarjetas perforadas!), que se colocaban
en cartapacios o carpetas de anillos y se almacenaban en archiveros metlicos. Este
enfoque era problemtico por muchas razones: J) con frecuencia era dificil encontrar un elemento de configuracin cuando se Je necesitaba; 2) usualmente era un
reto determinar cul elemento haba sido cambiado, cundo y por quin; 3) la construccin de una nueva versin de un programa existente consumta mucho tiempo y
era proclive al error; 4) la descripcin de relaciones detalladas o complejas entre elementos de configuracin era virtualmente imposible.
En la actualidad, los ECS se conservan en una base de datos o depsito del proyecto. El diccionario Webster define la palabra depsito como "cualquier cosa o persona que se considera como centro de acumulacin o almacenamiento". En los inicios
de la ingeniera del software, el depsito de hecho era una persona: el programador,
quien tena que recordar la ubicacin de toda la informacin relevante para un proyecto de software; adems, tena que recuperar la informacin que nunca se haba
respaldado por escrito y reconstruir la informacin perdida. Tristemente, emplear a
una persona como "centro de acumulacin y almacenamiento" (aunque concuerde
con la definicin del diccionario) no funciona muy bien. Hoy el depsito es una
"cosa": una base de datos que acta como el centro tanto de la acumulacin como
del almacenamiento de la informacin de ingeniera del software. El papel de la persona (el ingeniero de software) es interactuar con el depsito mediante las herramientas que tiene integradas.
27 .2.1 El papel del depsito

El depsito de ECS es el conjunto de mecanismos y estructuras de datos que permite que un equipo de software maneje el cambio en una forma eficaz. El depsito proporciona las funciones obvias de un sistema de gestin de base de datos pero, adems, el depsito realiza o impulsa las siguientes funciones [FOR89]:
Qu
f.nciones
.,a..entaun
-,isito de ECS?
La integridad de los datos incluye funciones para validar las entradas al
depsito, garantizar la consistencia entre objetos relacionados y automticamente realizar modificaciones "en cascada" cuando un cambio en un objeto
demanda algn cambio a los objetos relacionados con l.
El compartir informadn ofrece un mecanismo para distribuir la informacin
entre mltiples desarrolladores y herramientas, manejar y controlar los
accesos a los datos por parte de mltiples usuarios y cerrar y abrir los objetos
de modo que los cambios no sean trasladados inadvertidamente hacia otros.
La integracin de herramientas establece un modelo de datos al que se puede tener
acceso mediante muchas herramientas de ingeniera del software, controlar el

acceso a los datos y realizar funciones adecuadas de gestin de la configuracin.
804
PARTE CUATRO
GESTIN DE PROYECTOS DE SOITWARE
La integracin
de los datos brinda funciones de base de datos que permiten
que varias tareas de GCS se realicen en uno o ms ECS.

El fortalecimiento
de la metodologa define un modelo de entidad-relacin
guardado en el depsito que implica un modelo de proceso especfico para .:.

ingeniera del software; como mlnimo, las relaciones y objetos definen un
conjunto de pasos que se deben llevar a cabo para construir los contenidos
del depsito.
Estandarizacin de los documentos es la definicin de los objetos en la base <k

datos que conduce directamente a un enfoque estndar para la creacin de
documentos de ingeniera del software.
El depsito se define en funcin de un metamodelo. Para lograr estas funciones ~
metamodelo determina cmo se guarda la informacin en el depsito, cmo se tie"_

acceso a los datos mediante las herramientas y cmo los visualizan los ingenieros c.
software, cun bien se puede mantener la seguridad e integridad de los datos, y eua.;
fcilmente se puede ampliar el modelo existente para adecuar las nuevas necesiddes. Para mayor informacin, el lector interesado debe consultar [SHA95J y [GRJ95l
27.2.2 Caractersticas y contemdo generales

Las caractersticas y el contenido del depsito se comprenden mejor si se les obse"
va desde dos perspectivas: qu se guardar en el depsito
y qu servicios esped:"""
cos ofrece ste. En la figura 27.3 se presenta un anlisis detallado de los tipos
representaciones, documentos y productos de trabajo que se guardan en el depsit;::
Uhffii
Contenido
del depsito.
Co,os de u,o
Modelo de an6lisis
Diagramas basodos en escenario
, .
Regios del negocio
C?<'!9 fuente_
Diagramas orientados a flujo
funciones del negocio
Diagramas basados en dase
Cdigo_ de obeto
.,
.
f51rucruro de lo or:onizocin Diagramas comportomentales
Instrucciones de construcc,on del Sistema
. ,',
Arquitectura de informacin
Modelo de diseo. , .
~ido~
Diagramas orqu1tectn1cos
N!Nec:iltn
Diagramas de interfaz
.
Diagramas al nivel de componentes '
Cosos de pruebo
Mtricos tcnicos
Guiones de pruebo
Resultodos de pruebo
Mtricos de calidad
Estimaciones del proyecto

Colendorizoci6n del proyecto
Requisitos de GCS
Solicitudes de cambio
Informes de cambios
Requisitos de SQA
Informes de proyecto/informes de auditora
Mtricos del proyecto
Pion del proyecto

Pion GCS/SQA
Especificaciones del sistemo
Especificaciones de requisitos
Documento de diseo
Pion y procedimiento de pruebo
Documentos de soporte
Manual del usuario
CAPfTtn.o 27
GESnN DEL CAMBIO
805
Un depsito robusto proporciona dos clases diferentes de servicios: 1) los mismos

tipos de servicios que se pueden esperar de cualquier sistema sofisticado de gestin
de base de datos, y 2) servicios especficos del entorno de la ingeniera del software.
Un depsito que atienda a un equipo de ingenierla de software debe 1) integrarse con o directamente apoyar las funciones de gestin de proceso; 2) apoyar reglas
especficas que rigen la funcin de GCS y los datos conservados dentro del depsito;
3) ofrecer una interfaz a otras herramientas de ingeniera del software; y 4) acomodar el almacenamiento de datos sofisticados (por ejemplo, texto, grficos, video.
audio).
27.2.3 Caractersticas de la GCS

El apoyo a la GCS requiere que el almacn o depsito tenga un conjunto de herramientas que ofrezca soporte para las siguientes caractersticas:
Versiones. Conforme un proyecto progrese se crearn muchas versiones (seccin
~~VE
eclep6sito debe ser
:::ipoz de mantener los
ECS relacionados con
~versiones
aferentes del
11!Wore. MOs
~nte,debe
cirecer los meconismos
,mu ensomi.ir 5chos
ECS en ooo
coofigurocin
especifico de versin.
27 .3.2) de productos de trabajo individuales. El depsito debe ser capaz de guardar

todas estas versiones para permitir la gestin eficaz de las liberaciones de producto
y permitir que los desarrolladores regresen a versiones anteriores durante las pruebas y la depuracin.
El depsito debe ser capaz de controlar una amplia variedad de tipos de objetos,
incluso texto, grficos, mapas de bits, documentos complejos y objeto nicos como
definiciones de pantallas e informes, archivos de objeto, datos de prueba y resultados. Un depsito maduro sigue las versiones de los objetos con grados arbitrarios de
granularidad; por ejemplo, se puede seguir una sola definicin de datos o un conjunto de mdulos.
Gestin del seguimiento de la dependencia y del cambio. El depsito gestiona una amplia variedad de relaciones entre los objetos de configuracin que guarda.
Se incluyen relaciones entre entidades y procesos empresariales, entre las partes de
un diseo de aplicacin, entre componentes de diseo y la arquitectura de informacin del proyecto, entre elementos de diseo y otros productos de trabajo, etctera.
Algunas de estas relaciones son meramente asociaciones, y algunas son dependencias o relaciones obligatorias.
La habilidad con que se da seguimiento a todas estas relaciones es crucial para la
integridad de la informacin guardada en el depsito y la generacin de productos de
trabajo basados en ella, y es una de las aportaciones ms importantes del concepto
de depsito a la mejora del proceso de desarrollo de software. Por ejemplo, si se
modifica un diagrama de clase UML, el depsito puede detectar si las clases relacionadas, las definiciones de inteaz y los componentes de cdigo tambin requieren
modificacin y pueden colocar en la atencin del desarrollador los ECS afectados.
seguimiento de requisitos. Esta funcin especial ofrece la habilidad de seguir

todos los componentes y entregables de diseo y construccin que resulten de una
determinacin especifica de requi.sltos (seguimiento hacia adelante o seguimiento
propiamente dicho). Adems, proporciona la habilidad de identificar qu requisitos

generaron algn producto de trabajo dado (seguimiento hacia atrs o rastreo).
Gestin de la configuracin. Una gestin de la configuracin facilita la conservacin del rastro de una serie de configuraciones que representan hitos especficos
del proyecto o liberaciones de produccin.
Rutas de auditoria. Una ruta de auditora establece informacin adicional acerca

de cundo, por qu y por quin se hicieron los cambios. La informacin acerca de la
fuente de los cambios se puede ingresar como atributos de objetos especficos en el
depsito.
El proceso de gestin de la configuracin del software define una serie de tareas que
tienen cuatro objetivos principales: 1) identificar todos los elementos que colectivamente definen la configuracin del software; 2) gestionar los cambios a uno o ms
de dichos elementos; 3) facilitar la construccin de diferen tes versiones de una aplicacin; y 4) garantizar que la calidad del software se conserva conforme la configuracin evoluciona a lo largo del tiempo.
Un proceso que logra estos objetivos no necesita ser burocrtico y molesto, pero
s debe caracterizarse en una forma que permita que un equipo de software desarrolle respuestas a un conjunto de preguntas complejas:
Cmo identifica un equipo de software los elementos discretos de una configuracin de software?
Pera
responder a
qu pregntas se
dm dinur un
'proceso de GCS?
Cmo gestiona una organizacin las numerosas versiones existentes de un

programa (y su documentacin) en una forma que permita que el cambio se
acomode eficientemente?
Cmo controla una organizacin los cambios antes y despus de que el

software se libere al cliente?
Quin tiene la responsabilidad de aprobar y clasificar los cambios?
Cmo se garantiza que los cambios se hayan realizado adecuadamente?
Con qu mecanismo se val oran otros cambios que se realizan?
Estas preguntas conducen a la definicin de las cinco tareas de la GCS ilustradas en
la figura 27.4: identificacin, control de la versin, control del cambio, auditora de la
configuracin e informe.
En la misma figura las tareas de la GCS se aprecian como capas concntricas. Los
ECS fluyen hacia afuera a travs de dichas capas a lo largo de su vida til, y a final
de cuentas se convierten en parte de la configuracin del software de una o ms versiones de una aplicacin o sistema. Conforme un ECS se mueve a travs de una
capa, las acciones que implica cada capa de proceso de la GCS pueden o no aplicarse. Por ejemplo, cuando se crea un nuevo ECS debe ser identificado. Sin embargo, si
CAPTULO 27
GESTIN DEL CAMBIO
807
iiMJffi
capas
del
;:iroceso de
:;es,
no se solicitan cambios para el ECS, la capa de control de cambio no se aplica. El

ECS se asigna a una versin especfica del software (entran en juego mecanismos de
control de la versin). Se conserva un registro del ECS (su nombre, fecha de creacin, designacin de versin, etc.) para propsitos de auditora de la configuracin e
informes a quienes necesiten saberlo. En las secciones siguientes se examinan con
ms detalle cada una de estas capas del proceso de GCS.
27.3.1 Identiflcacln de objetos en la corulguracin del software

El control y la gestin de elementos de configuracin del software requiere nombrar
cada uno por separado y luego organizarlo mediante un enfoque orientado a objetos. Es posible identificar dos tipos de objetos [CH089]: bsicos y agregados.3 Un
objeto bsico es una unidad de informacin creada por un ingeniero de software

durante el anlisis, el diseo, el cdigo o las pruebas. Por ejemplo, un objeto bsico
puede ser una seccin de una especificacin de requisitos, parte de un modelo de diseo, cdigo fuente para un componente, o un conjunto de casos de prueba que se utilizan para ejercitar el cdigo. Un objeto agregado es una coleccin de objetos bsicos
y otros objetos agregados. En la figura 27 .2 EspedficacionDisei\o es un objeto agregado. Conceptualmente, es posible verlo como una lista nombrada (identificada) de
punteros que especifican objetos bsicos como son ModeloDatos y ComponenteN.
El concepto de objeto agregado [GUS89) .se lha propuesto como un mecanismo para representar una
versin completa de una configuracin de ~
808
PARTE CUATRO
cada objeto tiene un conjunto de caracterlsticas distintivas que lo identificar

manera exclusiva: un nombre, una descripcin, una lista de recursos, y una "rw
zacin". El nombre del objeto es una cadena de caracteres que identifican al ob
Los interrelociones
estoblecidos poro los
o~etos de
configuracin permiten
que un ingeniero de
software evale el
impacto del cambio.
sin ambigedades. La descripcin del objeto es una lista de elementos de datos

identifican el tipo de ECS (por ejemplo, elemento modelo, programa, datos) cr,
representa el objeto, un identificador de proyecto e informacin de cambio y/o ~er
sin.
La identificacin del objeto de configuracin tambin puede considerar las relaci. .nes entre los objetos nombrados. Por ejemplo, con la utilizacin de notacin simp.e
DiagramadeClase < parte de> ModeloAnalisis;
ModeloAnalisis < parte de> EapeclficacionRequisitos:
tc0Nsuo9'
lootJSO si lo base de
datos del proyecto

ofrece lo habilidad
poro estoblecer dichos
relocion6s, is1os
COOS1111611 tinpo en
su establecimiento y
difiaJtrm mantener k,
ocldzocm. Alnpe
SUfl fTlt/( vtll,s pera d
anlisis de inpadD,
no son esenoo/es
paro la~ ;ol,d
de/cambio
se crea una jerarquia de ECS.

En muchos casos, los objetos estn interrelacionados a travs de ramas de jera:qua de objetos. Dichas relaciones estructurales cruzadas se representan en la fofl"';
siguiente:
ModeloDatos < lnterrelaciOl'l8do> ModeloFlujoDatos
ModeloDaios <lntefflllacionado> CasoPruebaClaseM
En el primer caso la interrelacin es entre un objeto compuesto, mientras que .a

segunda relacin es entre un objeto agregado (ModeloDatos) y un objeto bsicc
(casoPrUebaClaseM).
El esquema de identificacin para los objetos de configuracin debe reconoce.
que los objetos evolucionan a lo largo del proceso de software. Antes de que u:objeto se convierta en lnea base puede cambiar muchas veces, e incluso despus de
establecida una lnea base los cambios quiz sean muy frecuentes.
27.3.2 Control de la versin

El control de la versin combina procedimientos y herramientas para gestionar diferentes versiones de objetos de configuracin que se crean durante el proceso del
~~VE
Uno focilidod * de
hechura" permite o un
ingeniero de softwore
obtener todos los

'*-1etos de
confi!ocin
Alemtes y construir
im ven6n especfico
SItWln.
software. Un sistema de control de la versin implementa o est directamente integrado con cuatro grandes capacidades: 1) una base de datos del proyecto (depsito)
que guarda todos los objetos de configuracin relevantes; 2) una capacidad de gestin de la versin que almacena todas las versiones de un objeto de configuracin (o
permite que se construya cualquier versin empleando diferencias de versiones
anteriores); 3) una facilidad de hechura que permita al ingeniero de software recopilar todos los objetos de configuracin relevantes y construir una versin especfica
del software. Adems, los sistemas de control de la versin y de control del cambio
con frecuencia implementan una capacidad de seguimiento de conflictos (tambin llamada seguimiento de bugs) que permiten al equipo registrar y hacer el seguimiento
del estado de todos los conflictos destacados que se asocian con cada objeto de configuracin.
CAPTULO 27
.....
809
GESTIN DEL CAMBIO
~ camilo, induso uno poro mejorar, est acompaado con inconveniel!m e i11a1111odkk1das. ''\
"
Varios sistemas de control de la versin establecen un conjunto de cambio -una

coleccin de todos los cambios (con cierta configuracin de lnea base)- que
requiere la creacin de una versin especfica del software. Dart [DAR91 J advierte
que un conjunto de cambios "captura todos los cambios de todos los archivos en la
configuracin junto con la razn para los cambios y detalles de quin los hizo y
cundo".
Es posible identificar varios conjuntos de cambio nombrados para una aplicacin
o sistema. Esto permite que un ingeniero de software construya una versin del software al especificar los conjuntos de cambio (por nombre) que se deben aplicar a la
configuracin de lnea base. Esto se logra aplicando un enfoque de modelado de sistema. El modelo de sistema contiene 1) una plantilla que incluye una jerarqua de
componentes y un "orden de construccin" para los componentes que describe
cmo se debe construir el sistema, 2) reglas de construccin y 3) reglas de verificacin.4
Durante las pasadas dos dcadas se han propuesto varios enfoques automatizados para el control de la versin. La principal diferencia en los enfoques es la sofisticacin de los atributos que se utilizan en la construccin de versiones especficas
y variantes de un sistema y los mecanismos del proceso de construccin.
~ El Sistema de Vers.tones Concurrentes (SVC)
liiiiiI
El empleo de herramientas con que lograr el

control de lo versin es esencial para uno
gestin del cambio eficaz. El sistema de versiones
concurrentes (SVC; CVS, Concurren! Versions System) es
una herramienta ampliamente empleado en el control de
versiones. Originalmente diseado poro cdigo fuente,
pero til para cualquier archivo basado en texto, el
sistema SVC 1) establece un depsito simple, 2) conservo
lodos los versiones de un archivo en un archivo con un
solo nombre ol almacenar slo los diferencias entre
versiones progresivos del archivo original, y 3) protege un
archivo contra cambios simultneos al establecer diferentes
directorios paro cado desarrollador, con lo que se aslan
uno de otro. El SVC mezclo los cambios cuando codo
desarrollador completo su trabajo.
Es importante notar que el SVC no es un sistema de
construccin"; esto es, no construye una versin especfico
del softwore. Esto se logro integrando ol SVC otras

herramientas (par ejemplo, Makefile). El SVC no
implementa un proceso de control de cambio (por ejemplo,
solicitudes de cambio, informes de cambio, seguimiento de
bugs).
Pese a sus limitaciones, el SVC "es un sistema
dominante en el control de versiones, transparente respecto
o la red y de fuente abierta [que] es til poro todos, desde
desarrolladores individuales hasta grandes equipos
segmentados [CVS02). Su arquitectura cliente/servidor
permite que los usuarios accedan o los archivos mediante
conexiones de Internet y su filosofa de fuente abierto
focilito su disponibilidad en la mayora de los plotoformas
populares.
El SVC est disponible sin costo paro entornos

Windows, Mocintosh y Unix. Vistese www.cvshome.org
paro mayores detalles.
Tambin es posible consultar el modelo de sistema para valorar cmo un cambio en un componente
impactar a otros componentes.
PARTE CUATRO
110
27.3.3 Control del cambio

La realidad del control del cambio en un contexto moderno de ingeniera del soft-
ware la resumi bellamente James Bach [BAC98J :

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 cdigo puede crear una gran falla en el producto. Pero tambin puede resolver una gran falla o permtir maravillosas nuevas capacidades. Nos preocupamos por los cambios porque
un solo desarrollador solitarlo podra hundir el proyecto; aunque en las mentes de dichos
solitarios se originan ideas brillantes, y un proceso de control del cambio gravoso podrla
desatentarlos efectivamente de realizar trabajo creativo.
Bach reconoce que se enfrenta un acto de equilibrio. Demasiado control del cambio
y se crean problemas; poco, y se crean otros problemas.
,t del~ es preservar el orden entre el cambio, y preservar el aunbio entre el orden.
........1,11
&,
~~
c&v1
Se debe des1oor que
so5cill.ies de
amliopai
Ull'iime 111111
....... tnlsolo
00 yque los 00
trullrnmto rClUl!on en
comlioso~
obfetos de
(Offl9A'OOOII.
lD ccdusin conduce
o8ffllfes, algunos de
,&,s bastanre S81ios.
8 control del acceso y
"' i, sroonizod6n
~,., conlusifl.
latlS ti, a,ntro/ de
,mi,nydel
tptillp/taalm.
En un gran proyecto de ingenierla de software el cambio incontrolado conduce

rpidamente al caos. Respecto a tales proyectos el control del cambio combina procedimientos humanos y herramientas automatizadas. En la figura 27.5 se ilustra
esquemticamente el proceso de control del cambio. Se emite una solicitud de cambio y se estima para evaluar los mritos tcnicos, los potenciales efectos colaterales,
el impacto global sobre otros objetos de configuracin y funciones del sistema, y el
costo proyectado del cambio. Los resultados de la evaluacin se presentan como un
informe de cambio, que lo utiliza una autoridad del control del cambio (ACq: una persona o grupo que toman la decisin final acerca del estado y la prioridad del cambio. Se genera una orden de cambio en la ingeniera (OCI) para cada cambio aprobado.
La OC! describe el cambio que se debe realizar, las restricciones insoslayables y los
criterios de revisin y auditora.
El objeto que se cambiar se coloca en un directorio que controle exclusivamente el ingeniero de software que realiza el cambio. Un sistema de control de la versin (vase el recuadro acerca de SVC) actualiza el archivo original una vez realizado
el cambio. Como alternativa, el objeto que se cambiar puede "salir" de la base de
datos del proyecto (depsito), realizar el cambio y aplicar las actividades apropiadas
de SQA. Luego el objeto "entra" a la base de datos y se aplican mecanismos adecuados de control de versin (seccin 27.3.2) para crear la siguiente versin del software.
Estos mecanismos de control de la versin, integrados en el proceso de control
de cambios, implementan dos importantes elementos de gestin del cambio: control
del acceso y de la sincronizacin. El control del acceso rige qu ingenieros de software estn autorizados para ingresar y modificar un objeto de configuracin particular. El control de la sincronizacin ayuda a garantizar que los cambios paralelos,
efectuados por dos personas diferentes, no se sobrescriben uno sobre otro[HAR89].
CAPITULO 27
811
GESTIN DEL CAMBIO
Algunos lectores quiz comiencen a sentirse incmodos con el grado de burocracia que implica la descripcin del proceso de control del cambio mostrada en la
figura 27.5. Este sentimiento es comn. Sin las salvaguardas adecuadas el control
del cambio puede retrasar el progreso y crear burocracia y papeleo innecesarios. La
mayora de los desarrolladores de software con mecanismos de control del cambio
(desafortunadamente muchos no los tienen) ha creado varas capas de control para
ayudarse a evitar los problemas mencionados aqui.
Antes de que un ECS se convierta en lnea base slo se necesita aplicar control de
cambio informal El desarrollador del objeto de configuracin (ECS) en cuestin tiene
Se reconoce lo nec.e$idod del cambio
D prooesode
centro! del
cambio.
Solicitud
de cambio
t
t
por porte del usuario
Evoluoci6n del desarrollado<
Se genero informe
de cambio
...---- ---....
lo outo<idod de control del cambio decide

Solicitud se pone en filo poro lo accin, se genero OCI
Se niego lo solicitud de cambio
t
Asignacin de individuos poro objetos de configuracin
Se informo el usuario
solido" de objetos de configuracin (elementos)
Se hoce el cambio
Revisin (auditora) del cambio
"Entrado" de los elementos de configuracin que han cambiado
Establecimiento de uno lneo base poro pruebas
+
t
Reolizoci6n de actividades de garanta
d. calidad y de p<uebos
" Promocin* de los cambios poro i ncluirlos en lo s,guenle liberacin (revisin)
+
+lodc los elem.itos de
t lo
t
de lo , - ~
Reconstruccin de lo versin op<opiodo del software

Revisin (oud,to<o) del comb,o poro
Inclusin de los cambios

Distribucin
e,i
~~
configuroci6n
812
ptese por un poco

ms de control de
cambio del que se
uea que necesitar.
Es probable que
demasiado ser lo
cantidad correclrJ.
la posibilidad de realizar cualesquiera cambios justificados por el proyecto y las

requisitos tcnicos (en tanto los cambios no afecten requisitos de sistema mas
amplios que se encuentran fuera del mbito de trabajo del desarrollador). una vez
que el objeto haya experimentado una revisin tcnica formal y haya sido aprobado
se puede crear una lnea base. 5 Una vez que un ECS se convierte en lnea base se
implementa un control de cambio a nivel del proyecto. Ahora, para realizar un cambio, el desarrollador debe obtener la aprobacin del gestor del proyecto (si el cambio
es "local") o de la ACC si el cambio afecta otros ECS. En algunos casos, la generacin formal de las solicitudes de cambio, los informes de cambio y las OC! se dist:rbuyen. Sin embargo, se lleva a cabo la evaluacin de cada cambio, y todos los cambios
se siguen y revisan.
Cuando el producto de software se libera entre los clientes se instituye el contra
de cambio formal. En la figura 27.5 se ha esbozado el procedimiento de control de
cambio formal.
'':f.fannfilb,11$,JnVilaM&, excepto poro los mquinas expendedoras."
'
La autoridad de control del cambio juega un papel activo en la segunda y tercera
capas del control. Dependiendo del tamao y carcter de un proyecto de software
la ACC puede estar compuesta de una persona (el gestor del proyecto) o varias per-
sonas (por ejemplo, representantes de software, hardware, ingeniera de bases de

datos, soporte, mercadotecnia). El papel de la ACC es tener una visin global, esto
es: evaluar el impacto del cambio ms all del ECS en cuestin. Cmo afectar el
cambio al hardware? Cmo afectar al desempeo? Cmo modificar la percepcin del cliente acerca del producto? Cmo afectar la calidad y fiabilidad del producto? Estas y muchas otras preguntas las aborda la ACC.
Se puede crear una lnea base tambin por otras razones. Por ejemplo, cuando se crean "construcciones diarias" todos los componentes que entran en un tiempo dado se convierten en la lnea base
para el trabajo del da siguiente.
CAPTULO 27 GESTIN DEL CAMBIO
813
cmo oana . . .
a.
CXJmbio.
.,.... Segundo,
de GCS nialmenl.
venidn.
27.3.4 Auditoria de la configuraci6n

La identificacin, el control de la versin y el control del cambio ayudan al desarro-
llador del software a mantener el orden en lo que de otro modo serla una situacin
catica e inestable. Sin embargo, incluso el mecanismo de control ms exitoso slo
sigue un cambio hasta que no se genera una OCI. Cmo se puede garantizar que el
cambio se ha implementado con propiedad? La respuesta es doble: l) revisiones tcnicas formales y 2) auditora de la configuracin del software.
La revisin tcnica formal (presentada con detalle en el captulo 26) se enfoca en
la correccin tcnica del objeto de configuracin que se ha modificado. Los revisores evalan el ECS para determinar su consistencia con otros ECS, omisiones o
potenciales efectos colaterales. Se debe realizar una revisin tcnica formal en casi
la mayora de los cambios triviales.
Una auditora de con.figuracin del software complementa la revisin tcnica formal al abordar las siguientes preguntas:
1. Se ha realizado el cambio especificado en la OCI? Se han incorporado modificaciones adicionales?

2 . Se ha realizado una revisin tcnica formal para evaluar la correccin tcnica?
3. Se ha seguido el proceso de software7 Se han aplicado adecuadamente los
estndares de ingeniera del software?
4. El cambio se ha resaltado en el ECS7 e.Se nan especificado la fecha y el autor

del cambio? Los atributos del ob1eto de configuracin reflejan el cambio?
PARTE CUATRO
814
GESTIN DE PROYECTOS DE SOFl'WARE
5. Se han seguido los procedimientos de GCS para destacar el cambio, registrarlo e informar de l?
6. Todos los ECS relacionados se han actualizado de manera adecuada?

En algunos casos, las preguntas de la auditora se plantean como parte de una resin tcnica formal. Sin embargo, cuando la GCS es una actividad formal, la aud::
ra de GCS la lleva a cabo por separado el grupo de aseguramiento de la calida:
Tales auditoras formales de configuracin tambin aseguran que los ECS correct.:....
(por versin) se han incorporado en una construccin especifica y que toda la dOC'mentacin est actualizada y es consistente con la versin que se ha construido
27.3.5 Informe de estado
Elabrese una lista de

*necesita conoce(
poro codo objeto de
configurod6n y
consrvese octuolf
zodo. Cuando se
reolke un cambio, es
necesario asegurarse
de que todos los de lo
lista sean notificados.
El informe de estado de la configuracin (a veces llamado contabilidad de estado es

una tarea de Ges que responde las siguientes preguntas: l) qu ocurri? 2) qu.c::r.:
lo hizo? .3) cundo ocurri? 4) qu otra cosa ser afectada?
En la figura 27.5 se muestra el flujo de informacin para el informe de estado de
la configuracin (IEC) . Cada vez que se le asigna una identificacin nueva o actua..zada a un ECS se efecta una entrada de IEC. Cada vez que la ACC aprueba un car::bio (es decir, se expide una OC!) se genera una entrada en el IEC. cada vez que se
realiza una auditora de la configuracin los resultados se reportan como parte de a
tarea de IEC. El resultado del IEC es posible colocarlo en una base de datos en line:
o en un sitio Web, de modo que los desarrolladores y los encargados del mantel' miento del software pueden tener acceso a la informacin del cambio median..:
categorias clave. Adems, se genera un IEC con regularidad y su finalidad es martener a los gestores y profesionales alertas ante de los cambios importantes.
Soporte de la ses
Objetivo: las herramientas de GCS
proporcionan soporte a una o ms de las

actividades del proceso estudiadas en la seccin 27.3.
Mecnica: la mayora de las modernas herramientas de
GCS funciona en conjunto con un depsito (un sistema de

base de datos) y ofrecen mecanismos para identificar,
control de la versin y el cambio, auditora e informe.
CCC/Harvest, distribuida por Compuler Associates

(www.cai.com), es un sistema de GCS multiplataforma.
ClearCase, desarrollado por Rational (www.rational.com),

ofrece una Familia de funciones de GCS.
Concurrent Versions System (SVC), una herramienta de
fvente abierta (www.cvshome.org), es uno de los
sistemas de control de versin ms ampliamente
empleados en la industria (vase un recuadro anterior).
PVCS, distribuido por Merant (www.merant.com), ofrece

un conjunto completo de herramientas de GCS que son
aplicables tanto en software convencional como en
WebApps.
}
Las herramientas mencionadas slo representan una muestra de esta categoria. En la mayora de
los casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores.
CAP'nJLO 27
GESTIN DEL CAMBIO
,(SourceForge, distribuida por VA Software

(sourceforge.net), ofrece gestin de versin,
capacidades de construccin, seguimiento de
problemas/bugs y muchas otros caractersticos de
gestin.
5.xrovndSCM, desarrollado por Seopine Software

(www.seopine.com), proporciono capacidades
completos de gestin del cambio.
815
Ves/o, distribuida par Compoc (www.vestosys.org), es un

sistema de GCS de dominio pblico que puede dar
soporte tonto o proyectos pequeos (< 1O KLDC) como
o grandes ( l 0,000 KLDC).
Una extenso listo de herramientas comerciales y entornos
paro GCS, se puede encontrar en
www.cmtodoy.com/yp/commerciol. html.
En la parte 3 de este libro se estudi la naturaleza especial de las aplicaciones Web

y el proceso de ingeniera Web necesario para construirlo. Entre las muchas caractersticas que diferencian a las WebApps del software convencional se encuentra la
naturaleza ubicua del cambio.
La ingeniera Web utiliza un modelo de proceso incremental iterativo (captulo 16)
que aplica muchos principios derivados del desarrollo de software gil (captulo 4).
Al utilizar este enfoque, un equipo de ingeniera con frecuencia desarrolla un incre-
mento de WebApp en un periodo muy corto mediante un enfoque basado en el cliente. Los incrementos subsecuentes agregan contenido y funcionalidad adicionales, y
tal vez cada uno implemente cambios que conduzcan a contenido aumentado,
mejor facilidad de uso, esttica mejorada, mejor navegacin, desempeo aumentado y mayor seguridad. En consecuencia, en el mundo gil de la ingeniera Web el
cambio se ve de manera un poco diferente.
Los ingenieros Web deben adoptar el cambio, e incluso un tpico equipo gil evita
todas las cosas que parecen pesados procesos, burocrticos y formales. Por lo general, se considera (aunque incorrectamente) que la gestin de la configuracin del
software posee estas caractersticas. Esta aparente contradiccin se resuelve al no
rechazar los principios, prcticas y herramientas de la GCS, sino ms bien moldendolas para satisfacer las necesidades especiales de los proyectos de ingeniera Web.
27.4. l Problemas en la gestin de la configuracin para WebApps
Qu
Impacto
5ltte un cambio
.scoatrolado
m e1na
WebApp?
Conforme las WebApps se vuelven cada vez ms importantes para la sobrevivencia

y el crecimiento de los negocios, crece la necesidad de la gestin de la configuracin.
Por qu? Porque sin controles eficaces los cambios inadecuados a una WebApp
(recurdese que la inmediatez y la evolucin continua son los atributos dominantes
de muchas WebApps) conduciran a la difusin no autorizada de informacin de un
nuevo producto; funcionalidad errnea o pobremente probada que frustra a los visitantes a un sitio Web; hoyos en la seguridad que ponen en peligro los sistemas internos de la compaa; y otras consecuencias econmicamente desagradables o incluso desastrosas.
816
PARTE CUATRO GESTIN DE PROYECl'OS DE SOF1WARE
Las estrategias generales para la gestin de configuracin del software (GCS) descritas en este captulo son aplicables, pero las tcticas y herramientas se deber
adaptar para que concuerden con la naturaleza nica de las WebApps. Se deben considerar cuatro temas cuando se desarrollen tcticas para la gestin de la configuracin de la WebApp: contenido, personal, escalabilidad y polticas.
Contenido. Una WebApp tpica contiene una amplia variedad de contenido: texto
grficos, applets, guiones, archivos de audio/video, formatos, elementos de pgina
activos, tablas, datos clasificados por niveles y muchos otros. El reto es organizar
este ocano de contenido en un conjunto racional de objetos de configuracin (seccin 27 .1.4) y luego establecer mecanismos de control de configuracin adecuados
para dichos objetos.
Personal. Puesto que un porcentaje significativo del desarrollo de la WebApp contina realizndose en una forma ad hoc, cualquier persona involucrada en la
WebApp puede (Y con frecuencia lo hace) crear contenido. Muchos creadores de
contenido no tienen conocimientos de ingeniera del software e ignoran por completo la importancia de la gestin de la configuracin. Por lo tanto, la aplicacin
crece y cambia en una forma descontrolada.
Escalabilidad. Las tcnicas y los controles aplicados a una WebApp pequea no
se escalan bien hacia arriba. No es inusual que una WebApp simple crezca significativamente conforme se implementan interconexiones con los sistemas de informacin existentes, bases de datos, depsitos de datos y portales. Conforme crecen
el tamao y la complejidad, los cambios pequeos pueden tener efectos de largo
alcance e imprevistos que pueden ser problemticos. En consecuencia, el rigor de
los mecanismos de control de la configuracin debe ser directamente proporcionales a la escala de la aplicacin.
Polticas. Quin "posee" una WebApp? Esta pregunta se plantea en compaas
grandes y pequeas, y su respuesta tiene un impacto significativo en las actividades
de gestin y control asociadas con la IWeb. En ciertas instancias, los desarrolladores
Web se ubican fuera de la organizacin TI, lo que crea potenciales dificultades de
comunicacin. Dart [DAR99J sugiere las siguientes preguntas para ayudar a entender las poHticas asociadas con la IWeb:
Cmo se
detennina
quin tiene la
responsabilidad
'de la GC de la
WebApp?
Quin asume la responsabilidad de la precisin de la informacin en el sitio

Web?
Quin asegura que se han seguido los procesos de control de calidad antes
de que la informacin se publique en el sitio?
Quin es el responsable de realizar los cambios?
Quin asume el costo del cambio?
Las respuestas a estas preguntas ayudan a determinar a las personas que, dentro
de una organizacin, deben adoptar un proceso de gestin de la configuracin para
las WebApps.
CAPTULO 27
GESTIN DEL CAMBIO
817
27 .4.2 Objetos de configuracin WebApp

Las WebApps abarcan una amplia gama de objetos de configuracin: objetos de contenido (por ejemplo, texto, grficos, imgenes, video, audio), componentes funcionales (por ejemplo, guiones, applets) y objetos de interfaz (por ejemplo, COM o CORBA).
Los objetos WebApp se pueden identificar (asignndoles nombres de archivo) en
cualquier forma que sea apropiada para la organizacin. Sin embargo, se recomiendan las siguientes convenciones para garantizar que se conserva la compatibilidad
entre plataformas cruzadas: los nombres de archivo deben estar limitados a 32 caracteres de longitud, se deben evitar los nombres con maysculas mezcladas o todas
maysculas, as como el uso de subrayados. Adems, las referencias URL (vnculos)
dentro de un objeto de configuracin siempre deben usar trayectorias relativas (por
ejemplo, .. ./productos/sensoresdealarma.html).
Todo el contenido de la WebApp tiene formato y estructura. Los formatos internos de archivo los dicta el entorno de cmputo en el que se almacena el contenido.
Sin embargo, el formato de representacin (usualmente llamado formato de desplie-
gue) se define con el etilo esttico y las reglas de diseo establecidas para la
WebApp. La estructura del contenido define una arquitectura de contenido; esto es:
define la forma en la que los objetos de contenido se ensamblan para presentar
informacin significativa a un usuario final. Boiko [BOI02] define la estructura como
"mapas que usted tiende sobre un conjunto de trozos [objetosl de contenido para
organizarlos y hacerlos accesibles a las personas que los necesitan".
27.4.3 Gestin del contenido

La gestin del contenido se relaciona con la gestin de la configuracin en el sentido
en que un sistema de gestin del contenido (SGC) establece un proceso (apoyado por
herramientas) que adquiere contenido existente (de un amplio ordenamiento de
objetos de configuracin de la WebApp), los estructura en una forma que permite
presentarlos a un usuario final y luego los ofrece al entorno del lado del cliente para
su despliegue.
El uso ms comn del sistema de gestin del contenido ocurre cuando se construye una WebApp dinmica. Este tipo de WebApp crea pginas Web "al vuelo". Es
decir, usualmente el usuario consulta la WebApp solicitando informacin especfica.
La WebApp consulta una base de datos. formatea la informacin en concordancia y
la presenta al usuario. Por ejemplo, una compaa musical ofrece una librera de CD
en venta. Cuando un usuario solicita un CD o su equivalente en msica electrnica,
se consulta una base de datos y una variedad de informacin acerca del artista, el
CD (por ejemplo, su portada o grfica). el contenido musical y muestras de audio se
descargan y configuran en una plantilla de contenido estndar. La pgina Web resul-
818
~,
~
c&v1
El subsistema de
coleccin abarco todos
los acciones que se
requieren poro creor,
adquirir oconvertir el
contenido en uno
formo que se puedo
presentar en el lodo
del cliente.
PARTE CUATRO
GESTIN DE PROYECTOS DE SOl'IWARE
tante se construye en el lado del servidor y pasa al navegador del lado del clien _
para que la examine el usuario final. En la figura 27.6 se muestra una representaciogenrica de esto.
En el sentido ms general, un SGC "configura" el contenido para el usuario fuu.
al invocar tres subsistemas integrados: de coleccin, de gestin y de publicaacr
[B0102].
El subsistema de coleccin. El contenido procede de los datos y la informacir

que debe crear o adquirir un desarrollador de contenido. El subsistema de colecciv,abarca todas las acciones que se requieren para crear y/o adquirir contenido, as:
como las funciones tcnicas necesarias para 1) convertir el contenido en una fo.mato que se pueda representar en un lenguaje de marcas (por ejemplo, HTML, XML
y 2) organizar el contenido en paquetes que se puedan desplegar con eficacia en e.
lado del cliente.
El subsistema de gestin. una vez que el contenido existe debe guardarse en Ir'
depsito, catalogarse para adquisicin y uso subsecuentes, y etiquetarse para defiru=
1) su estado actual (por ejemplo, el objeto de contenido est completo o en desarrollo), 2) la versin apropiada del objeto de contenido, y 3) los objetos de contenid..
relacionados. Por lo tanto, el subsistema de gestin implementa un depsito que
abarca los siguientes elementos:
Base de datos de contenido: la estructura de informacin que se ha establecido

para almacenar todos los objetos de contenido.
iii'IJff''
Sistema de
gestt6ndel
contenido
~--------------------------
1
1
(SGC).
Sistema de
gestin del
contenido
1
1
Plonlilfos
1
1
1
1
: lodo del servidor
Cdigo
HTML+ guiones
--------------------------~
Navegador lodo del diente
CAPTULO 27
c&v1
:s.csistemo de
implemento un
poro todo el
=1m. Lo gestin
t ClXlfigurocin se
1 cabo dentro de
s:bsistemo.
819
Gl'STIN DEL CAMBIO
capacidades de la base de datos: funciones que permiten al SGC buscar objetos

de contenido especficos (o categoras de objetos), almacenar y recuperar los
objetos, y gestionar la estructura de archivos que se ha establecido para el
contenido.
Funciones de gestin de la conjiguradn: los elementos funcionales y flujo de
trabajo asociado que soportan la identificacin del objeto de contenido,
control de la versin, gestin del cambio, auditora del cambio y creacin de
informes.
Adems de estos elementos, el subsistema de gestin implementa una funcin de
administracin que abarca los metadatos y reglas que controlan la estructura global
del contenido y la forma en la que recibe soporte.
El subsistema de publicacin. El contenido se debe extraer del depsito, convertirse en una forma que est dispuesta para la publicacin y formatearse de modo
que sea posible transmitirlo a los navegadores del lado del cliente. El subsistema de
publicadn logra estas tareas mediante una serie de plantllas. cada plantilla es una
funcin que construye una publicacin empleando uno de tres componentes diferentes [80102]:
s~
c&v1
Jmistemode
~
obtiene
:::::rik> del depsito
c1!ego olos
~
es en el lodo
dmte.
Elementos estticos: los textos, grficos, medios audiovisuales y guiones que

ya no requieren procesamiento ulterior se transmiten directamente al lado del
cliente.
5eNicios de publicacin: funcin que solicita servicios especficos de recuperacin y formateo que personalizan el contenido (mediante reglas predefinidas),
efectan conversin de datos y construyen vnculos de navegacin apropiados.
SeNicios externos: proporcionan acceso a infraestructura de informacin
corporativa externa como datos de la empresa o aplicaciones de "cuarto
trasero".
Un sistema de gestin de contenido que abarque cada uno de estos subsistemas es
aplicable a grandes proyectos de ingenieria Web. Sin embargo, la fi1osofla bsica y la
funcionalidad asociados con un SGC son aplicables a todas las WebApps dinmicas.
Gesttn del contenido
Objetivo: Auxiliar a los ingenieros de

software y desarrolladores de contenido a
onar el contenido que se incorpora en las WebApps.
"'8cnica: las herramientas en esta categora permiten

~ los ingenieros Web y proveedores de contenido
xtuolicen el contenido de uno WebApp en una formo
controlodo. la mayora establece un simple sistema de

Qe$1n de archivos que asigno actualizacin pgino por
pgino y permisos de edicin paro varios tipos de
contenido WebApp. Algunos mantienen un sistema de
YerSiones de modo que se pueden lograr versiones previos

de conlenido poro propsitos histricos.
820
Contenl Management Tools Sute, desorrollodo por

interoctivetools.com (www.interodivetools.com/), es un
conjunto de herramientas de gestin de contenido que
se enfoco en lo gestin del contenido poro dominios de
aplicacin especficos (por ejemplo, artculos nuevos,
avisos dosificados, bienes races).
Tower IDM, desarrollado por Tower Technologies

(www.towertech.com), es un sistema de procesomienlo
de documentos y depsito de contenido poro gestionar
todos los formas de informacin comercial no
estructurado: im6genes, formatos, informes generados
por computadora, cuentos y facturas, documentos
oficiales, correo electrnico y contenido Web.
ektronCMS300, desarrollado por ektron

(www.ektron.com), es un conjunto de herramientas que
ofrece copocidodes de gestin de contenido, as como
herramientas de desarrollo Web.
En los siguientes sitios Web se puede encontrar

informacin adicional acerco de lo GCS y los
herramientas de gestin del contenido poro ingeniera
Web:
OmnUpdate, desarrollado por WebsiteASP, lnc.

(www.omniupdote.com), es uno herramienta que
permite a los proveedores de contenido autorizados
desarrollar actualizaciones controlados de contenido
WebApp especificado.
Web Developer's Vrtual Encyclopedia (www.wdlv.com),

WebDeveloper (www.webdeveloper.com), Developer Shed
{www.devshed.com), webknowhow.net
{www.webknowhow.net) o WebReference
(www.webreference.com).
27 .4.4 Gestin del cambio

El flujo de trabajo asociado con el control del cambio para software convencional
(seccin 27.3.3) generalmente es demasiado laborioso para la ingeniera Web. Es
improbable que se logre la secuencia peticin de cambios, informe de cambio 'j
orden de cambio de ingeniera en una forma gil y aceptable para la mayora de los
proyectos de desarrollo WebApp. Entonces, cmo se gestiona una corriente continua de cambios solicitada para el contenido y la funcionalidad de la WebApp?
La implementacin de una gestin de cambio eficaz dentro de la filosofia "codifica y ve" que contine dominando el desarrollo de las WebApps requiere modificar el
proceso de control de cambios convencional. Cada cambio se debe clasificar en una
de cuatro clases:
Clase J: un cambio de contenido o funcin que corrija un error o mejore el contenido o funcionalidad locales.
Clase 2: un cambio de contenido o funcin que tenga impacto sobre otros objetos
de contenido o componentes funcionales.
Clase 3: un cambio de contenido o funcin que tenga amplio impacto a travs de
una WebApp (por ejemplo, gran ampliacin de la funcionalidad, mejora significativa
o reduccin del contenido, grandes cambios requeridos en la navegacin).
Clase 4: un gran cambio de diseo (por ejemplo, un cambio en el diseo de la
interfaz o enfoque de navegacin) que inmediatamente apreciarn una o ms categoras de usuarios.
Las herramientas expuestas slo representan una muestra de esta categora. En la mayoria de los
casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores.
821
CAPITULO 27 GESTIN DEL CAMD:>
iihifkj
'iest16n de
=mbfos
-:,ara
11ifebApps.
Comb,o close 1
Camb,o do.e A
Combios
,~ido.en
objeto>
relocionoclo
S. requiere
m,
ovoluocioo
De "*do
en reollzocl6n
Una vez clasificados los cambios solicitados se pueden procesar de acuerdo con
el algoritmo mostrado en la figura 27.7.
En la misma figura, los cambios de las clases 1 y 2 se tratan de manera informal
y se manejan en una forma gil. En un cambio de clase I el ingeniero Web evala el
impacto del cambio, pero no se requiere revisin o documentacin externa.
Conforme se realiza el cambio, los procedimientos estndar de entrada y salida se
refuerzan mediante las herramientas de configuracin de depsito. En cuanto a los
cambios de la clase 2, es obligacin del ingeniero Web revisar el impacto del cambio sobre objetos relacionados (o pedir a los desarrolladores responsables de stos
que lo hagan). Si el cambio es factible sin que se requieran cambios significativos en
otros objetos, la modificacin ocurre sin revisin o documentacin adicional. Si se
requieren cambios sustantivos, son necesarias evaluacin y planificacin ulteriores.
822
PARTE CUATRO
Los cambios de las clases 3 y 4 tambin se tratan en una forma gil, pero se
requieren alguna documentacin descriptiva y ms procedimientos de revisiones
formales. Los cambios de la clase 3 requieren el desarrollo de una descripcin deJ
cambio que ofrezca una breve evaluacin del impacto del cambio. La descripcin se
distribuye entre todos los miembros del equipo de ingeniera Web, quienes lo revisan para evaluar mejor su impacto. Tambin respecto a los cambios de la clase 4 se
desarrolla una descripcin del cambio, pero en este caso la revisin la llevan a cabo
todos los participantes.
Gesn del cambio

Objetivo: Auxiliar a los ingenieros Web y
desarrolladores de contenido a gestionar los
cambios conforme se realizan stos en objetos de
configuracin WebApp.
Mecnica: Las herramientas en esto categora

originalmente fueron desarrolladas para software
convencional, pero es pasible adaptarlas a la ingeniera
Web y realizar cambios controlados en las WebApps.
ChangeMon WCM, desarrollada par Serena
{www.serena.com), es una de un conjunto de
de ges~n del cambio que ofrece capacidades de GCS.
ClearCase, desarrollada par Rational (www.rational.com),

es un conjunto de herramientas que ofrecen
capacidades completos de gestin de configuracin
para WebApps.
PVCS, desarrollada par Merant (www.meront.com), es un

conjunto de herramientas que ofrecen capacidades
completos de gestin de configuracin para WebApps.
Source lnfegrity, desarrollada par mks (www.mks.com), es
una herramienta GCS que se puede integrar con
entornos de desarrollo seleccionados.
herromientos
27.4.5 Control de la verstn

Conforme una WebApp evoluciona por medio de una serie de incrementos, es posible que existan al mismo tiempo varias versiones diferentes. Una versin (la WebApp
operativa actual) est disponible para los usuarios finales por Internet; otra versin
(el siguiente incremento de la WebApp) quiz est en las etapas finales de prueba
previas al lanzamiento; una tercera versin est en desarrollo y representa una gran
actualizacin en contenido, esttica de interfaz y funcionalidad. Los objetos de configuracin deben estar claramente definidos, de modo que cada uno pueda estar
asociado con la versin adecuada. Adems, deben estar establecidos los mecanismos de control. Dreilinger [DRE99] aborda la importancia del control de la versin (y
del cambio) cuando escribe:
En un sitio descontrolado, donde mltiples autores tienen acceso para editar y contribuir,
surge el potencial para el conflicto y los problemas, ms an si los autores trabajan desde
8 Las herramientas expuestas slo representan una muestra de esta categora. En la mayora de los
c;asos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores.
CAPTULO 27
GESTIN DEL CAMi>
823
diferentes oficinas en distintos momentos del da y la noche. Usted puede pasar el da mejorando el archivo index.html para un cliente. Despus que ha realizado los cambios, otro
desarrollador, quien trabaja en su casa despus de su jornada laboral, o en otra oficina,
puede pasar la noche cargando su propia novedosa versin revisada del archivo
index.html, y sobrescribir por completo el trabajo que usted ha realizado, sin forma alguna
de retroceder!
Esta situacin debe sonar familiar a todos los ingenieros de software, as como a
todos los ingenieros Web. Para evitarlo, se debe establecer un proceso de control de
la versin.
l. se debe establecer un depsito central para el proyecto WebApp. El depsito contendr las versiones actuales de todos los objetos de configuracin de la WebApp (contenido, componentes funcionales y otros).
2. Cada ingeniero Web crea su propia carpeta de trabajo. La carpeta contiene
aquellos objetos creados o cambiados en algn momento dado.
3 . Los relojes en las estaciones de trabajo de todos los desarrolladores deben estar
sincronizados. Esto tiene como fin evitar los conflictos de sobrescritura
cuando dos desarrolladores realizan actualizaciones que estn muy cercanas
en el tiempo una de otra.
4. Conforme se desarrollan nuevos objetos de configuracin o se cambian los obje-
tos existentes se importan al depsito central. La herramienta de control de la

versin (vase el estudio precedente del svc en este captulo) gestionar todas las funciones de entrada y salida de las carpetas de trabajo de cada ingeniero Web.
5. Conforme los objetos se importan al o exportan del depsito se elabora un men-
saje automtico de registro cronometrado. Esto ofrece informacin til para auditora y se puede convertir en parte de un efectivo esquema de elaboracin
de informes.
La herramienta de control de la versin mantiene diferentes versiones de la WebApp
y puede revertirse a una versin ms antigua si se requiere.
27 .4.6 Auditora y elaboracin de informes

En bsqueda de agilidad, las funciones de auditora y elaboracin de informes no se
resaltan en el trabajo de ingeniera Web. Sin embargo, no se eliminan por completo.
Todos los objetos que entran o salen del depsito se anotan en un registro que puede
revisarse en cualquier punto en el tiempo. Es factible crear un informe de registro
completo de modo que todos los miembros del equipo de ingeniera Web tengan una
cronologa de los cambios sobre un periodo definido. Adems, se enva una notificacin automtica de correo electrnico (dirigida a los desarrolladores y participantes interesados) cada vez que un objeto entre o salga del depsito.
824
PARTE CUATRO GESTIN DE PROYECIOS DE SOFTWARE
INFORMACIN
Estndares de GCS
Lo siguiente lista de estndares GCS
(procedente en parte de www.12207.com) es
razonablemente extensa:
EIACMB6-1C
EIACMB6-3
Identificacin de configuracin
Estndares IEEE
standards.ieee.org/ catalog/
olis
EIACMB6-4
Control de configuracin
IEEE 828
Planes de gestin de configuracin

del software
EIACMB6-5
Libro de texto para contabilidad de

estado de configuracin
IEEE 1042
Gestin de configuracin del

software
EIACMB7-l
Intercambio electrnico de datos de

gestin de configuracin
Estndares ISO
www.iso.ch/iso/ en/
ISOOonline.frontpage
Estndares
militares
estadounidenses
www-library.itsi.disa.mil
ISO 10007-1995
Gestin de calidad, lineamientos

para GC
DoD MIL STD-973
Gestin de configuracin
Tecnologa de informacin;
procesos de ciclo de vida de
software
MIL-HDBK-6 l
Gua para gestin de configurocir
Otros estndares
ISO/IEC 12207
ISO/IEC TR 15271
Gua para ISO/IEC 12207
ISO/IEC TR 15846
Ingeniera del software; procesos

de ciclo de vida de software;
gestin de configuracin para
software
Referencias de gestin de
configuracin y dolos
DO-l78B
Directrices paro el desarrollo de

software de aviacin
ESA PSS-05-09
Gua para gestin de configuracioo

de software
AECL CE-1001-STD
rev. l
Estndar para ingeniera del

software de software de seguridad
crtico
Estndares EIA
www.eia.org/
EIA 6.49
Estndar de consenso nacional

para gestin de configuracin
DOE SCM lista de

verificacin
cio.doe.gov/ITReform/sqse/
download/cmcklst.doc
EIACMB.4-lA
Definiciones de gestin de la
configuracin para programas de
computadoras digitales
BS-6488
British Std., gestin de

configuracin de sistemas
basados en computadora
EIACMB4-2
Identificacin de configuracin
poro programas de computadoras
Mejores prcticas-RU Oficina de comercio

gubernamental: www.ogc.gov.uk
digitales
CMII
EIACMB4-3
libreras de software de
computadora
EIACMB4-4
Control de cambio de
configuracin para programas de
computadoras digitales
Instituto de mejores prcticas en

GC: www.icmhq.com
Uno Gua de recursos de gestin de configuracin ofrece

informacin complementaria para aquellos interesados en
procesos y prcticas de GC. Est disponible en
www.quality.org/config/cm-guide.html.
La gestin de configuracin del software es una actividad protectora que se aplica a

lo largo del proceso de software. La GCS identifica, controla, audita e informa modificaciones que invariablemente ocurren mientras se desarrolla software y despus de
CAPTULO 27
GESTIN DEL CAMBIO
825
que se le libera a un cliente. Toda la informacin producida como parte de la ingeniera del software se vuelve parte de una configuracin de software. La configuracin est organizada de forma que permite la gestin ordenada del cambio.
La configuracin del software est compuesta de un conjunto de objetos interrelacionados, tambin llamados elementos de configuracin del software, que se producen debido a alguna actividad de ingeniera del software. Adems de documentos,
programas y datos, el entorno de desarrollo que se utiliza para crear software tambin se puede colocar bajo control de configuracin. Todos los ECS se guardan en un
depsito que implementa mecanismos y estructuras de datos para garantizar la integridad de los datos, ofrece soporte de integracin para otras herramientas de software, apoya la distribucin de informacin entre los miembros del equipo de software
e implementa funciones en apoyo del control de la versin y del cambio.
Una vez desarrollado y revisado un objeto de configuracin se convierte en lnea
base. Los cambios a un objeto convertido en lnea base generan la creacin de una
nueva versin de dicho objeto. La evolucin de un programa puede seguirse al examinar la historia de revisin de todos los objetos de configuracin. Los objetos bsicos
y compuestos forman una piscina de objetos a partir de la que se crean las versiones. El control de la versin es el conjunto de procedimientos y herramientas para
gestionar el empleo de dichos objetos.
El control de cambios es una actividad de procedimiento que asegura la calidad y
la consistencia conforme los cambios se realizan en un objeto de configuracin. El
proceso de control de cambios comienza con una peticin de cambio, conduce a una
decisin para aceptar o rechazarla y culmina con una actualizacin controlada del
ECS que se cambiar.
La auditora de la configuracin es una actividad de SQA que ayuda a garantizar
que la calidad se conserva conforme se realizan los cambios. Los informes de estado ofrecen informacin acerca de cada cambio a quienes tengan necesidad de conocerla.
La gestin de la configuracin para ingeniera Web es similar en muchos aspectos a la GCS para el software convencional. Sin embargo, cada una de las tareas
principales de GCS se deben destacar para hacerlas tan simples como sea posible, y
se deben implementar provisiones especiales para la gestin del contenido.
[BAB86] Babich, W. A., SOftware Conjiguration Management, Addison-Wesley, 1986.

[BAC98J Bach, J., "The Highs and Lows of Change control", en Computer, vol. 31, nm. 8, agosto de 1988, pp. 113-115.
[BER80) Bersoff, E. H., V. D. Henderson y S. G. Siegel, Software Conjiguration Management,
Prentice-Hall, 1980.
[BOI02J Boiko, B., Content Management &ole, Hungry Minds Publishing, 2002.
[CH089J Choi, s. C., yW. scacchi. Assuring the correctness ofa Configured software Description",
Procs. 2nd Intl. Workshop on Software ConfigurotlDII Management, ACM, Ptinceton, NJ, octubre de
1989, pp. 66-75.
826
PARTE CUATRO GESTIN DE PROYECTOS DE SOFiWARE

(CVS02) Concurrent Versions System Web site, www.cvshome.org, 2002.
(DAR91] Dart, S., "Concepts in Configuration Management Systems", Proc. Third Internator,
Workshop on Software ConjiguraUon Managemenl, ACM SIGSOFT, 1991, se puede descarg,-.:
de:http://www.sei.cmu.edu/legacy/scm/abstracts/abscm_concepts.html.
[DAR99J Dart, S., "Change Management: Containing the Web Crisis", Proc. software ConjiguracrManagement Symposium, Toulouse, Francia, 1999, disponible en http://www. perforce.corr
perforce/ conf99 / dart.html.
(DAROJ] Dart, S., Spectrum of Functionality in Conjiguration Management Systems, Software Er
gineering Institute, 2001, disponible en http://www.sei.cmu.edu/legacy/scm/tech_ref'
TRI 1_90/TOC_TRI 1_90.html.
(DRE99] Dreilinger, S., "CVS Version Control for Web Site Projects", 1999, disponible er
http://www.durak.org/cvswebsites/howto-cvs/howto-cvs.html.
[FOR89J Forte, G., "Rally Round the Repository", en CASE Oullook, diciembre de 1989, pp. s-r
[GRI95J Grilfen, J.. "Repositories: Data Dictionary Descendant Can Extend Legacy Code lnvestment"
enApplication Development1rends, abril de 1995, pp. 65-71.
[GUS89] Gustavsson, A., "Maintaining the Evolution of Software Objects in an lntegratec.
Environment", Proc. 2nd Inll. Workshop on Software ConjiguraUon Management, AC~
Princeton, NJ, octubre de 1989, pp. 114-117.
[HAR89J Harter, R., "Configuration Management", en HP Professional, vol. 3, nm. 6, junio de 1989
[IEE94J Software Engineering Standards, edicin 1994, IEEE Computer Society, 1994.
UAC02J Jacobson, l., "A resounding 'Yes' to Agite Processes-But Also More", en Cutter IT Joum<E
vol. 15, nm. 1, enero de 2002, pp. 18-24.
[REl89J Reichenberger, C., "Orthogonal Version Management", Proc. 2nd Ind. Workshop on
Software ConjiguraUon Management, ACM, Princeton, NJ, octubre de 1989, pp. 137-140.
[SHA95J Sharon, D., y R. Bell, "Tools That Bind: Creating Integrated Environments", IEEE
Software, marzo de 1995, pp. 76-85.
[TAY85] Taylor, B., "A Database Approach to Configuration Management for Large Projects
Proc. Conf Software Maintenance-1985, IEEE, noviembre de 1985, pp. 15-23.
2 7. t. Por qu es cierta la primera ley de la ingeniera de sistemas? Ofrecer ejemplos especificos

de cada una de las cuatro razones fundamentales para el cambio.
27 .2. Cules son los cuatro elementos que existen cuando se implementa un sistema eficaz
de GCS? Comentar cada uno brevemente.
27.3. Con palabras propias, comntenselas razones para las lneas base.
27 .4. Suponga que usted es el gestor de un pequeo proyecto. Qu lineas base definira para
el proyecto y cmo las controlarla?
27 .5. Emplear UML agregados o compuestos (captulo 8) para describir las interrelaciones entre
los ECS (objetos de configuracin) en la lista de la seccin 27.1.4.
27.6. Disear un sistema de base de datos (depsito) de proyecto que le permitirla a un
ingeniero de software almacenar, realizar referencias cruzadas, rastrear, actualizar y cambiar
todos los elementos importantes de configuracin de software. Cmo manejara la base de
datos las diferentes versiones del mismo programa? El cdigo fuente se manejara de manera
diferente a la documentacin? Cmo se evitara que dos desarrolladores realizasen diferentes
cambios al mismo ECS en forma simultnea?
27.7. Investigar una herramienta existente de GCS y describir cmo implementa el control de
las versiones y los objetos de configuracin en general.
2 7 .8. Las relaciones <parte de> e <interrelacionado> representan relaciones simples entre
objetos de configuracin. Describir cinco relaciones adicionales que puedan ser tiles en el
contexto de un depsito de GCS.
CAPTULO 27
GESTIN DEL CAMlll:)
827
27.9. Investigar una herramienta existente de GCS y describir cmo implementa los
mecanismos de control de versiones. De manera alternativa, leer dos o tres de los artculos
acerca de GCS y describir las diferentes estructuras de datos y mecanismos de referencia que
se emplean para el control de las versiones
27.10. Con la figura 27.5 como gua. desarrollar un anlisis todava ms detallado para el
control del cambio. Describir el papel de la ACC y sugerir formatos para la peticin del cambio,
el informe del cambio y la OO.
2 7 .11. Desarrollar una lista de venficacin para emplearla durante las auditorias de la
configuracin.
27.12. Cul es la diferencia entre una auditoria GCS y una revisin tcnica formal? Sus funciones
se pueden juntar en una revisin? Cules son los pros y los contras?
27 .13. Describir brevemente las diferencias entre GCS para el software convencional y la GCS
para WebApps.
2 7 .14. Qu es la gestin del contenido? Emplese la Web para investigar las caracteristicas de una
herramienta de gestin del contenido y ofrzcase un breve resumen.
Lyon (Practica/ CM, Raven Publishing, 2003, disponible en www.configuration.org) ha escrito

una gua detallada para profesionales de GC que incluye directrices pragmticas para implementar cada aspecto de un sistema de gestin de la configuracin (actualizado anualmente).
Hass (Conjiguration Management: Principies and Practice, Addison-Wesley, 2002) y Leon (A Guide
to SOftware Conjiguration Management, Artech House, 2000) ofrecen exmenes tiles del tema.
White y Clemm (S0ftware Configuration Management Strategies and Rational Clearcase, AddisonWesley, 2000) presentan la GCS dentro del contexto de una de las ms populares herramientas
de GCS.
Mikkelsen y Pherigo (Practica/ Software Conjiguration Management: The Latenight Developer's
Handbook, Allyn & Bacon, 1997) y Compton y Callahan (Conjiguration Management Jor
Software, VanNostrand-Reinhold, 1994) ofrecen guas pragmticas acerca de importantes
prcticas de GCS. Ben-Menachem (Software Conjiguration Management Guidebook, McGrawHill, 1994) y Ayer y Patrinnostro (SOftware Conjiguration Management, McGraw-Hill, 1992)
presentan buenos panoramas para quienes necesitan mayor introduccin a la materia. Berlack
(S0jtware Conjiguration Management, Wiley, 1992) presenta un examen til de conceptos de
GCS, donde resalta la importancia del depsito y las herramientas en la gestin del cambio.
Babich [BAB86J proporciona un tratamiento abreviado, aunque eficaz. de temas pragmticos
en la gestin de configuracin del software. Arnold y Bohner (Software Change Tmpact Analysis,
IEEE Computer Society Press, 1996) han editado una antologa que estudia cmo analizar el
impacto del cambio al interior de sistemas complejos basados en software.
Berczuk y Appleton (S0jtware Conjiguration Management Pattems, Addison-Wesley, 2002)
presentan una diversidad de patro nes tiles que auxilian en la comprensin de la GCS y la
implementacin de sistemas de GCS eficaces. Brown et al. (,Anti-Pattems and Pattems in
SOjtware Conjiguration Management, Wiley, 1999) estudian las cosas que no se hacen (antipatrones) cuando se implementa un proceso de GCS y luego consideran sus remedios.
Buckley (lmplementing Conjiguratwn Management, IEEE Computer Society Press, I 993)
considera enfoques de gestin de la configuracin para todos los elementos del sistema
- hardware, software y firmware- con estudios de tallados de las principales actividades de
GC. Rawlings (SCM Jor Network Development Environments, McGraw-Hill, 1994) considera el
impacto de la GCS para desarrollo de soltware en un ento rno de red. Bays (Software Release
Methodology, Prentice-Hall, 1999) presenta una coleccin de mejores prcticas para todas las
actividades que ocurren despus de que se realizan cambios en una aplicacin.
Conforme las WebApps se vuelven mas dinmicas, la gestin del contenido se vuelve un
tpico esencial para los ingenieros Web los libros de Addey y sus colegas (Content Manage-
828
PARTE CUATRO
menl Systems, Glasshaus, 2003), Boiko tB0I02L Hackos (Content Managementfor Dynamic \~e.
Delivery, Wiley, 2002}, Nakano (Web Content Management, Addison-Wesley, 200!) presen~
valiosos tratamientos de la materia.
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de _
gestin de configuracin del software. Una lista actualizada de referencias en la World Wid.!
Web se puede encontrar en el sitio Web SEPA:
TEMAS AVAN?ADOS
EN
INGENIERA DEL SOF.TWARE
n esta parte de Ingeniera del software. Un enfoque prctico

se consideran varios temas avanzados que ampliarn la
comprensin del lector acerca de la ingeniera rlel software.
E'n los siguientes (;aptulos se abordarn las siguientes preguntas:

Qu notacin y preliminares matemticos ("mtodos formales") se requieren para especfier fonnalmente el soft-
ware?
Qu actividades tcnicas clave se llevan acab durante el
proceso de ingeniera del software de sala limpia?
Cmo se emplea la ingenierla del software basada en componentes para crear sistemas a partir de componentes reutilizables?
Qu actividades tcnicas se requieren para la reingeniera
del software?
Cules son las tendencias futuras de la ingeneria del $Oftware?
Una vez que se respondan estas preguntas, se entendern los
temas que tienen la posibilidad de tener un profund impacto
sobre la ingeneria del software durante la dcada siguiente.
'Los
4
Coa,,ct"PTOS
Ct.~VE
espedli,(*n
toll$trctlvb .831
especi,i~Jt .
fo;lltllf , ..... ,847
t$qlleitll3 ,, -'49
e$Jo~
.. , .. J34
.,
marillllle
,,
dl:datos,, .. J3S
lenguaje Z , . ,849
~l ..... : ..84$
operacl.ontt .!34
operadores de
conjuntos .... ,838
operadores
lgicos .... ..840

pre y
pow,aclldones .83S
mtod9s \ie la ingeniera del software se pueden clasificar sobre un ~-
pec;tro de "formalidad" ligeramente vinculado con el grado de rigor makmtico aplicado durante el anlisis y el dise. Por esta razn, los mtodos
l\~lisis y di~efio estudiads previamente en este libro se ubican en el extretho informal del espectro. En la creacin de modelos dp anlisis y diseo se u 1lizan combinaciones dfagramas, texto, tablas y natacin simple, pero se :a
i
" aplicadopocongor mat~~tico.
*
9e
de.
Considr:ese ~hota el otro extremo del espectro d fbrmaUdaq. .Aqu, una especif:acin y diseo s~ describen empleando sintaxis y semnticas formales
qve especifican la fund~n y el comportamiento del sistema. La especificacin es
matemtica en form (por ejemplo, el tl~uto -d predicados se utUiza cbmo ba, se para un lenguaje formal de especlficacin).
En su' estudio introductorio de 1os mtodos formale$, Anthony Hall '{HAL90
afirma;
LOS mtodos formafes son ont;overtidos. Sus prtidanos affrmrrque pueden revolucionar el desarrollo [del software]. Sus detractres. pi~san que son intreblemente dificiles.. Mientras tanto, para ta mayorla lit l gente,~$ m.\odS format~s son tan
poco familiares qiie es difkil1uzgJr las aflnnacones e~ competencia.
En este captulo se exploran los mtodos fopnales y se examinan sus potenciales impactos sobre laingenieria del software en los aos por venir.
;,1<
'<:"-<"
UN VISTAZO Qt.l es? li ~ ~

permiten qt.re un ~eniero de soh
RPIDO
re cre&''Unct'e$peeificacin ffls . ~
pleta, consisteote y preciso cp. los
que S pr:(?ducen empfectndo mtodos
.nvenconoles. Se vti1izcm lo notoc;;i~ de teora
de coniuntos y lgica para crear mt &tro ptan..

teomiento de hec:hos frequisi1o$). fato 8$f)eC~
(j()Jl !')'l(ll$rnqtico lueg(> se onolizo cpqro ~

to hidr;,so probar) $U c.<>rreccin y consiifel'lcia.
Puesl'9 que lo especifkacfn se treo medt\le
~JQei~n mQ~tit es inheientement mno$
de
Uf) precio elevado. Cuando d software

com
~ fallo es. p()Sibfe que $e pier~ti vidas o
$UQ(ffl .grav! consecuencias ~nmicas. En
$itua<:<>nS es esencial que fos errores sean
~ierlc>s on1es de <tue el software sea puesto n operocin. tos m ~ i formdfes reducen
wskmcia~ los errores de $$f)EICific<:1Ci6n y,
(OIYIO consecuencio,. sirven (X)mO b<lse p(lro que
el ~ , e ~ ton fX)S errores uno vez que
e1 diente comience o usorlo.

Cu61es son los pctfOJ? lo notocion-y heurstico de,: coniun1o$ y IQ $pe<:ifko<;l6r onstructivo
anblgu9 que los modos'fl'lfoonolesde~.
-operdores de coniuntos, operadores lgicos
Quin to fulc:? Un tl~niero de sof1wore . y sec:uencio$-formbJJ le, bme ~1os mtodos
cialmente entrenado creo uno espoclfkoci6n forformoles. tstos definen los &tos invoriantes,
mol.
estados y operaciones para fa funtin de un sisPor qu es importonte! 'en los sistemos de
tema al lraducir los requi$itos foflllQies del pro
seguridad o de misin crtkos, los fallas tientn
blemo.en una rep~ntcin m~ formol.
CAPTULO 28
MTODOS FORMALES
831
La Encyclopedia ofSoftware Engineering [MAR94] define as los mtodos formales:

Un mtodo es formal si tiene slidas bases matemticas, usualmente proporcionadas por
un lenguaje formal de especificacin. Esta base ofrece los medios de definir con precisin
nociones como consistencia y completud, y, con ms relevancia, especificacin, implementacin y correccin.
Las propiedades deseadas de una especificacin formal (consistencia, integridad
y falta de ambigedad) son los objetivos de todos los mtodos de especificacin. Sin
embargo, emplear mtodos formales resulta en una probabilidad mucho mayor de
lograr dichos ideales. La sintaxis de un lenguaje formal de especificacin (seccin
28.4) permite que los requisitos y el diseo se interpreten slo en una forma, lo que
elimina la ambigedad que con frecuencia ocurre cuando un lenguaje natural (por
ejemplo, ingls) o una notacin grfica debe interpretarlos un lector. Las facilidades
descriptivas de la teora de conjuntos y la notacin lgica (seccin 28.2) permiten un
planteamiento claro de los hechos (requisitos). Para ser consistente, los hechos planteados en un lugar en una especificacin no deben contradecirse en otro sitio. La
consistencia se garantiza probando matemticamente que los hechos iniciales pueden correlacionarse de manera formal (empleando reglas de inferencia) en planteamientos posteriores dentro de la especificacin.
tos mtodos forn,ales tienen un enorme potencial poro mejorar lo claridad y la precisin de las espedfkadones de
reqllisltos yporo tnConlrar los errores importantes ysutiles.
Steve lasterfitook ,t ,,l.
La completud es ditkil de lograr, aun cuando se apliquen los mtodos formales.
Algunos aspectos de un sistema tal vez queden indefinidos mientras se crea la especificacin; otras caractersticas quiz se omitan a propsito para permitir que los diseadores tengan cierta libertad de eleccin en el enfoque de implementacin; y,
finalmente, es imposible considerar cada escenario operativo en un gran sistema
complejo. Las cosas tal vez se omitan por error.
Aunque el formalismo que ofrecen las matemticas es atractivo para algunos ingenieros de software, otros (algunos dinan, la mayona) miran despectivamente la vi-
S32
PARTE CINCO TEMAS AVANZADOS EN INGENIERIA DEL SOF!WAAE
sin matemtica del desarrollo del software. Comprender por qu un enfoque fot':".
tiene su mrito requiere, primero, considerar las deficiencias asociadas con los mfoques menos formales.
28.1.1 Deficiencias de los enfoques menos formales 1
Aunque un buen
indice de documento
no puede efuninar las
contradicdones, si
puede ayudar adescubrirlas. Considrese lo
aeocin de 1111 indice
poro los especificr,ciones yotros documentos.
Los mtodos estudiados para el anlisis y el diseo en las partes 2 y 3 de ese libremplean ampliamente el lenguaje natural y una extensa gama de notaciones grficas. Aunque la aplicacin cuidadosa de los mtodos de anlisis y diseo, en conjunto con revisiones exhaustivas, puede conducir y de hecho conduce a software de alla
calidad, el descuido en la aplicacin de estos mtodos crea una diversidad de problemas. una especificacin de sistema puede contener contradicciones, ambigedades, vaguedades, planteamientos incompletos y grados mixtos de abstraccin.
Las contradicciones son conjuntos de planteamientos que divergen unos a..otros. Por ejemplo, parte de una especificacin de sistema puede afirmar que el S1S
tema debe supervisar todas las temperaturas en un reactor qumico, mientras <f...otra parte, que tal vez escribi otra persona, puede afinnar que slo deben supen'lsarse las temperaturas que ocurran dentro de cierto intervalo.
Las ambigedades son planteamientos que se interpretan en varias formas. Por
ejemplo, el siguiente planteamiento es ambiguo:
La identidad del operador consiste de su nombre y la contrasea; sta consiste de seis d-
gitos. Se debe mostrar en la UDV de seguridad y depositarse en el archivo de registro cuando un operador se registre en el sistema.
En este fragmento, se debe mostrar se refiere a la contrasea o a la identidad dd

operador?
Las vaguedades con frecuencia ocurren porque la especificacin de un sistema es
un documento muy voluminoso. Lograr un elevado grado de precisin consistente-
mente es una tarea casi imposible.
=:lllttfl'orlS'es humano. Repetirlos, tambin."
........ J
La incomp/etud es uno de los problemas que ocurren con mayor frecuencia cor
las especificaciones del sistema. Por ejemplo, considrese el requisito funcional:
El sistema debe conservar el nivel horario del depsito a partir de los sensores profundos
situados en el depsito. Dichos valores deben almacenarse respecto de los seis meses anteriores.
Esto describe la parte principal del almacenamiento de datos de un sistema. Si uno

de los comandos para el sistema fuese:
Esta seccin y otras en la primera parte de este captulo se han adaptado del trabajo de Darrel lnce
para la edicin europea de la quinta edicin de lngenieria del software. Un enfoque prcco.
CAPTULO 28
MTODOS FORMALES
833
La funcin del comando PROMEDIO es desplegar en una PC el nivel de agua promedio para un sensor particular entre dos tiempos.
U!S revisiones tcnicos
lonnales eficaces
:veden eliminar
mhos de estos
:roblemos. Sin
trnborgo, algunos no
setn descubiertos.
Debe estarse alerto de
en deficiencias
tUUnte el diseo, la
codificacin ylo
pies/o oprueba.
y si supone que no se presentan ms detalles para este comando, los detalles delcomando estaran seriamente incompletos. Por ejemplo, la descripcin del comando
no incluye lo que deberia ocurrir si un usuario de un sistema especifica un tiempo
que fuese mayor a seis meses antes de la hora actual.
Los grados mixtos de abstraccin ocurren cuando planteamientos muy abstractos
se mezclan al azar con planteamientos que tienen un grado mucho menor de detalle. Aunque ambos tipos de planteamientos son importantes en la especificacin de
un sistema, quienes la realizan con frecuencia manejan la mezcla en tal forma que
resulta muy dificil ver la arquitectura funcional global de un sistema.
28.1 .2 Matemticas en el desarrollo de software

Las matemticas tienen muchas propiedades tiles para los desarrolladores de grandes
sistemas. Una es que se puede describir sucinta y exactamente una situacin fisica,
un objeto o el resultado de una accin. Es posible desarrollar una especificacin de
un sistema basado en computadora empleando matemticas especializadas, en forma muy similar a la que un ingeniero elctrico aplica las matemticas para describir
un circuito. 2
Las matemticas sustentan la abstraccin y por ende son un excelente medio para el modelado. Puesto que se trata de un medio exacto, existe poca posibilidad de
ambigedad. Las especificaciones pueden validarse matemticamente para contradicciones e incompletudes, y se pueden eliminar las vaguedades. Adems, las matemticas se emplean para representar, en una forma organizada, grados de abstraccin
en la especificacin de un sistema.
Finalmente, las matemticas ofrecen un alto grado de validacin al emplearlas
como un medio de desarrollo de software. Es posible aplicar una prueba matemtica para demostrar que un diseo encaja en una especificacin y que el cdigo del
programa es un reflejo correcto de un diseo.
28.1.3 Conceptos de mtodos formales

La meta de esta seccin es presentar los principales conceptos involucrados en la especificacin matemtica de los sistemas de software, sin atiborrar al lector con demasiados detalles matemticos. Esto se logra empleado unos cuantos ejemplos simples.
Ejemplo 1: una tabla de simbolos. Un programa se emplea para mantener una

tabla de slmbolos, la cual se utiliza frecuentemente en diferentes tipos de aplicado-
En este momento es adecuada una advertenca Las especificaciones del sistema matemtico que
se presentan en este captulo no son tan sucmtas como una especificacin matemtica para uncircuito simple. Los sistemas de software san nolOnamente complejos y sera irreal esperar que se podran especificar en una lnea de matemAlicas.
PARTE CINCO
Un invoonte de datos
es un conjunto de
condiciones verdaderos
olo largo de lo
ejecucin del sistema
que contiene uno
coleccin de dolos.
Olra !arma de
observa, la nocin de
estada es decir que
los datos determinan
el estado. Esta es, se
pueden examinar los
datos poro ver en qu
estado est el
sistema.
TEMAS AVANZAOOS EN INGENIERA DEL SOFTWARE
nes. Consiste de una coleccin de elementos sin duplicacin alguna. En la figura 28

se muestra un ejemplo de una tabla de smbolos comn. En ella se representa la ta
bla que utiliza un sistema operativo para retener los nombres de los usuarios del sis
tema. Otros ejemplos de tablas incluyen la coleccin de nombres del personal de v
sistema de nmina o la coleccin de los nombres de computadoras en un sistema d..
comunicaciones en red.
Supngase que la tabla presentada en este ejemplo consiste de no ms de MaxJ,
miembros de personal. Este planteamiento, que coloca una restriccin en la tabla ~
un componente de una condicin conocida como invariante de datos, una importar,te idea que se retomar a lo largo de este captulo.
Un invariante de datos es una condicin verdadera a lo largo de la ejecucin de::
sistema que contiene una coleccin de datos. La invariante de datos que se mantiene para la tabla de smbolos apenas estudiada tiene dos componentes: l) que la tabla contendr no ms de Maxlds nombres y 2) que no habr nombres duplicados ela tabla. En el caso del programa de tabla de smbolos. esto significa que no importa cundo se examine la tabla durante la ejecucin del sistema, siempre contendr...
no ms de Maxlds identificadores de personal y no incluir duplicados.
Otro concepto importante es el de estado. Muchos lenguajes formales, como oc._
(seccin 28.5), utilizan la nocin de estado como se le estudi en los capitulas 7 y 8
es decir: un sistema puede estar en uno de varios estados, y cada uno de ellos representa un modo de comportamiento observable externamente. Sin embargo, una definicin diferente para el trmino estado se utiliza en el lenguaje z (seccin 28.6). Er
z (y en lenguajes relacionados), el estado de un sistema se representa mediante los
datos almacenados del sistema (por tanto, Z sugiere un nmero mucho mayor de estados, que representan cada posible configuracin de los datos). Al emplear la lt ma definicin en el ejemplo del programa de tabla de smbolos, el estado es la tabla
de smbolos.
El concepto final es el de operacin. sta es una accin que ocurre dentro de un
sistema y lee o escribe datos. Si el programa de tabla de smbolos est preocupado
ifrHfJ:88
.. ;,
l. Wilson
Tabla de
snbolos.
2. Simpsori
3. Abe!
1
Maxlds; 10
5.
6.
7.
8.
9.
10.
Femandez
.,.
)'
'
,,
.,
CAPTULO 28
835
MTODOS FORMAUS
por aadir y remover nombres de personal de la tabla de slmbolos, entonces estar

asociado con dos operaciones: una para aadir un nombre especifico a la tabla de
smbolos, y una para eliminar un nombre existente de la tabla. 3 Si el programa ofrece la capacidad de verificar si un nombre especfico est en la tabla, entonces habra
una operacin que regresara alguna indicacin acerca de la presencia del nombre
en la tabla.
lres tipos de condiciones se asocian con las operaciones: invariantes, precondiciones y poscondiciones. Un invariante define lo que est garantizado que no cambiar. Por ejemplo, la tabla de smbolos tiene un invariante que establece que el n-
i:!5
lcnicas de lluvia
~ ife(Js pueden
L.:anarbien cuando
2 debe desarrollar un
arrionte de datos
p,u una funcin rozo
-:blemente cample;o.
'.:;:oo miembro del
::;ipo de software
"ale que escribir los
'1/tes, reslriccianes y
~itociones paro lo
;;in y luego combf
-:;y/os y editarlos.
mero de elementos siempre ser menor o igual a Maxlds. Una precondicin define tas
circunstancias en las cuales es vlida una operacin particular. Por ejemplo, la precondicin para una operacin que aade un nombre a ta tabla de smbolos de identificadores de personal slo es vlida si el nombre no est en la tabla y tambin si en
sta existen menos de Maxlds identificadores de personal. La poscondicin de una
operacin define lo que est garantizado que ser cierto hasta completar una operacin. Esto lo define su efecto sobre los datos. En el ejemplo de una operacin que
aade un identificador a la tabla de smbolos de identificadores de personal, la poscondicin especificarla matemticamente que la tabla ha aumentado con el nuevo
identificador.
Ejemplo 2: un gestor de bloques. Una de las partes ms importantes del sistema operativo de una computadora es el subsistema que mantiene tos archivos que
hayan creado los usuarios. Parte del subsistema de archivado es el gestor de bloques.
Los archivos en el archivero estn compuestos de bloques de almacenamiento que
se mantienen en un dispositivo de almacenamiento de archivos. Durante la opera-
iiMJflf
Bloques no usados
Gestor de
bloques.
1 3 4 6 9
Bloques usados
25
8 10
....___..,1
11 12
Cuando se borran
los archivos, los bloques
fila para entrar en los bloques no usados se liberan a la fila
5 8 11
,__....._.
7
Archivo 11
Atdar.o ,2
Archivo #3
La colo de bloques Q)Mene bloques p,,,_,ienles de los archivos borrados
3
se debe sealar que aadir un nombre no puede ocurm en e l estado lleno, y que borrar un nombre
es imposible en el estado vacio
836
PARTE CINCO
TEMAS AVANZAIXJS EN INGENIERA DEL SOFTWARE
cin de la computadora, los archivos se crearn y borrarn, lo que requiere la adquisicin y liberacin de bloques de almacenamiento. El subsistema de archivado lidiar
con esto manteniendo un depsito de bloques no utilizados (libres) y dar seguimiento a los bloques que actualmente estn en uso. Cuando se borra un archivo, los
bloques liberados normalmente se agregan a una fila de bloques que esperan ser
agregados al depsito de bloques no utilizados. Esto se muestra en la figura 28.2. Er.
esta figura se muestran varios componentes: el depsito de bloques no utilizados
los bloques que actualmente constituyen los archivos que administra el sistema operativo y aquellos bloques que esperan agregarse al depsito. Los bloques en espera
se mantienen en una fila, y cada elemento de sta contiene un conjunto de bloques
provenientes de un archivo borrado.
En este subsistema el estado es la coleccin de bloques libres, la coleccin de bloques utilizados y la fila de bloques devueltos. El invariante de datos, expresado en
lenguaje natural, es:
Ningn bloque ser marcado a la vez como no utilizado y utilizado.
Todos los conjuntos de bloques mantenidos en la fila sern subconjuntos de
la coleccin de bloques actualmente usados.
Ningn nmero de bloque pertenecer a dos o ms elementos de la fila.
La coleccin de bloques utilizados y no utilizados ser la coleccin total de
bloques que configuran los archivos.

La coleccin de bloques no utilizados no tendr nmeros de bloque duplica-
dos.
La coleccin de bloques utilizados no tendr nmeros de bloque duplicados.
Algunas de las operaciones asociadas con el invariante de datos son: aadir() una
coleccin de bloques al final de la fila, eliminar() una coleccin de bloques utilizados del frente de la fila y colocarlos en la coleccin de bloques no utilizados, y verificar() si la fila de bloques est vacia.
La precondicin de la primera operacin es que los bloques que se aadirn deben estar en la condicin de bloques utilizados. La poscondicin es que la coleccin
de bloques ahora se encuentra al final de la fila. La precondicin de la segunda operacin es que la fila debe tener al menos un elemento en ella. La operacin final
- verificar si la fila de bloques devueltos est vaca- no tiene precondicin. Esto sig-
nifica que la operacin siempre est definida, sin importar de qu valor sea el estado. La poscondicin entrega el valor cierto si la fila est vaca y falso de cualquier otro
modo.
En los ejemplos tratados en esta seccin se introducen los conceptos clave de la especificacin formal. Esto se hizo sin resaltar las matemticas que se requieren para formalizar la especificacin. En la seccin 28.2 se consideran tales matemticas.
CAPTULO 28 MTODOS FORMALES
837
La aplicacin eficaz de los mtodos fonnales requiere que un ingeniero de software

tenga un conocimiento operativo de la notacin matemtica asociada con los conjuntos y las secuencias, y de la notacin lgica utilizada en el clculo de predicados.
La finalidad de la seccin es proporcionar una breve introduccin al tema. Para una
exposicin ms detallada, se recomienda al lector consultar libros dedicados a estos
temas (por ejemplo, [WIL87]. [GRI93) y [ROS95)).
28.2.1
Conjuntos y especif1cactn constructiva
Un conjunto es una coleccin de objetos o elementos, y se utiliza como piedra angular de los mtodos formales. Los elementos que contiene un conjunto son nicos (es
decir: no se permiten duplicaciones) . Los conjuntos con un nmero pequeo de elementos se escriben dentro de llaves, con los elementos separados por comas. Por
ejemplo, el conjunto
{C+ + , Smalltalk, Ada, COBOL, Java)
contiene los nombres de cinco lenguajes de programacin.
El orden en el que aparecen los elementos dentro de un conjunto es irrelevante.
Al nmero de elementos en un conjunto se le conoce como cardinalidad. El operador # proporciona la cardinalidad de un conjunto. Por ejemplo, la expresin
#{A, B, C, D}
=4
implica que se ha aplicado el operador cardinalidad al conjunto mostrado, con un re-
Qu es
especificacin
mnstn1<1iva de
mnjuntos?
sultado que indica el nmero de elementos en el conjunto.

Existen dos formas de definir un conjunto. Un conjunto se define enumerando sus
elementos (as se han definido los conjuntos mencionados) . El segundo enfoque
consiste en crear una especificacin constructiva de conjuntos. La forma general de los
miembros de un conjunto se especifica empleando una expresin booleana. La especificacin constructiva de conjuntos es preferible a la enumeracin porque ello
permite una definicin sucinta de conjuntos grandes. Tambin define explcitamente la regla que se aplic al construir el conjunto. Considrese el siguiente ejemplo de
especificacin constructiva:
{n : N I n < 3 n}
Esta especificacin tiene tres componentes: una firma, n
: N; un predicado, n < 3; y
un tnnino, n. La firma especifica el intervalo de valores que se considerarn cuando se fonne el conjunto; el predicado una expresin Booleana) define cmo se restringir el conjunto; y, finalm en te, el tnnmo brinda la forma general del elemento
del conjunto. En el ejemplo anterior, N representa los nmeros naturales; por lo tanto, se considerarn los nmeros naturales. El predicado indica que slo se incluirn
838
PARTE CINCO
TEMAS AVANZAJXJS EN INGENIERIA DEL SOF1WARE
los nmeros naturales menores que 3; y el trmino especifica que cada elemento ck
conjunto ser de la forman. En consecuencia, esta especificacin define el conjunt~
Es indispensable el
conocimiento de los
operaciones de
con;untos cuando se
desarrollen especificaciones formoles. Debe
posorse algn tiempo
familiarizndose con
codo uno, si se tiene
lo intencin de aplicar
mtodos formoles.
{O, 1, 2)
Cuando la forma de los elementos de un conjunto es obvia, el trmino se puede onu

lir. Por ejemplo, el conjunto precedente se podra especificar como
{n: NI n < 3)
Todos los conjuntos que se han descrito tienen elementos que son elementos individuales. Tambin se pueden formar conjuntos a partir de elementos que sean pares, ternas, etctera. Por ejemplo, la especificacin de conjunto
x,y :N lx + y= IO (x, y2)}

describe el conjunto de pares de nmeros naturales que tienen la forma (x,y2) y donde la suma de x e y es I O. ste es el conjunto
{(l, 81), (2, 64), (3, 49), ... )
Obviamente, la especificacin constructiva de conjuntos requerida para representar algn componente de software de computadora ser considerablemente ms
compleja que las anotadas aqu. Sin embargo, la forma y estructura bsicas permanecen iguales.
28.2.2 Operadores de conjuntos

En la representacin de operaciones de conjuntos y lgicas se utiliza simbologa especializada. El ingeniero de software que pretenda aplicar los mtodos formales de-
be comprender estos smbolos.

El operador~ indica la pertenencia de un conjunto. Por ejemplo, la expresin
xe X
tiene el valor verdadero si x es miembro del conjunto X y el valor falso en caso contrario. Por ejemplo, el predicado
12e {6, 1, 12,22)
tiene el valor verdadero dado que 12 es miembro del conjunto.
El opuesto del operador e es el operador e . La expresin
xex
tiene el valor verdadero si x no es miembro del conjunto X y falso en caso contrario.
Por ejemplo, el predicado
13e {13, 1, 124, 22)
tiene el valor falso.
Los operadores e y
AcB
tienen conjuntos como sus operandos. El predicado
CAPTULO 28
839
MTODOS FORMAI.ES
tiene el valor verdadero si los miembros del conjunto A estn en el conjunto By tiene el valor falso en caso contrario. Por lo tanto, el predicado
{l,2JC{4,3, 1,2}
tiene el valor
verdadero. Sin embargo, el predicado
{HD1, LP4, RC5} e (HDl, RC2, HD3, LPI, LP4, LP6}
tiene un valor de falso porque el elemento RC5 no est en el conjunto a la derecha

del operador.
El operador k es similar a
valor
c. Sin embargo, si sus operandos son
iguales, tiene el
verdadero. Por lo tanto, el valor del predicado

{HDl, LP4, RCS} ~ {HD1, RC2, HD3, LPl, LP4, LP6)
es falso, y el predicado
{HDl, LP4, RCS}
es
{HDl, LP4, RC5)
verdadero.
"lasestructuras matemticas estn entre los descubrimientos ms hermosos realizados por la l1llllfe humana."
Doegla, .......
Un conjunto especial es el conjunto vaco 0. ste corresponde a cero en las matemticas normales. El conjunto vaco tiene la propiedad de ser un subconjunto de
cualquier otro conjunto. Dos tiles identidades que involucran al conjunto vaco son
0UA=Ay 0nA=0
para cualquier conjunto A, donde u se conoce como el operador unin, a veces conocido como taza; n es el operador interseccin, a veces conocido como gorra.
El operador unin admite dos conjuntos y forma uno que contiene los elementos
de los dos conjuntos y elimina los duplicados. Por lo tanto, el resultado de la expresin
{Archivo!, Archivo2, Impuesto, Compilador) u (lmpuestoNuevo, D2, D3, Archivo2}
es el conjunto
(Archivo!, Arcruvo2, Impuesto, Compilador, ImpuestoNuevo, D2, D3)
El operador de interseccin admite dos conjuntos y forma uno que consiste de los
elementos comunes en cada conjunto. Por lo tanto, la expresin
12, 4, 99, IJ
n (l,
1.3, 12, 771
genera el conjunto {12, l ).

El operador diferencia de conuntos. \ como su nombre sugiere, forma un
conjunto al eliminar los elementos de su segundo operando de los elementos de su
primer operando. Por to tanto, el valor de la expresin
840
PARTE CINCO
TEMAS AVANl.AIXJS EN INGENIERA DEL SOFTWARE
{Nuevo, Viejo, Archivolmpuesto, ParamSis} \ {Viejo, ParamSis}

genera el conjunto {Nuevo, Archivolmpuesto}.
El valor de la expresin
{a, b, c, dJ n {x,y)
ser el conjunto vaco 0. El operador siempre proporciona un conjunto; sin embargo, en este caso no existen elementos comunes entre sus operandos, asi que el conjunto resultante no tendr elementos.
El operador final es el producto cruzado, x , a veces conocido como producto cartesiano. ste tiene dos operandos. El resultado es un conjunto de pares donde cada
par consiste de un elemento tomado del primer operando combinado con un elemento del segundo. un ejemplo de una expresin que involucra al producto cruzado es
{l, 2)
(4, 5, 6)
El resultado de esta expresin es

((1, 4), (1, 5), (1, 6). (2, 4), (2, 5), (2,6))
Ntese que cada elemento del primer operando est combinado con cada uno de los
elementos del segundo.
Un concepto importante en los mtodos formales es el de conjunto potencia. Un
conjunto potencia de un conjunto es la coleccin de todos los posibles subconjuntos
cte dicho conjunto. El smbolo que se utiliza para este operador de conjunto en este
captulo es UJ>. Se trata de un operador unitario que. cuando se aplica a un conjunto,
devuelve el conjunto de subconjuntos de su operando. Por ejemplo,
1P> {l, 2, 3}
= {0,
{l}, {2}. {3}. (1, 2), {1, 3}, (2, 3), {!, 2, 3))
ya que todos los conjuntos son subconjuntos de {l, 2, 3).
28.2.3
Operadores lgicos
Otro componente importante de un mtodo formal es la lgi_ca: el lgebra de expresiones verdaderas y falsas. El significado de los operadores lgicos comunes lo comprende bien cualquier ingeniero de software. Sin embargo, los operadores lgicos
asociados con los lenguajes de programacin comunes se escriben empleando smbolos disponibles fcilmente en el teclado. Los operadores matemticos equl\ralentes son
(\
-,
no
implica
La cuantificacin universal es una forma de elaborar un planteamiento acerca de

los elementos de un conjunto que resulta verdadero para cualquier miembro del
841
conjunto. La cuantificacin universal utiliza el smbolo v. un ejemplo de su utilizacin es

V i j ,N i > j => i 2 > j
en donde se establece que para cada par de valores en el conjunto de nmeros naturales, si i es mayor que j, entonces i 2 es mayor que j2.
28.2.4 Sucesiones
Una sucesin es una estructura matemtica que modela el hecho de que sus elementos estn ordenados. Una sucesin s es un conjunto de pares cuyos elementos varian de l al elemento de mayor nmero. Por ejemplo,
{(I, Jones), (2, Wilson). (3, Shapiro). (4, Estavez)}
es una sucesin. Los elementos que forman los primeros elementos de los pares se
conocen colectivamente como dominio de la sucesin, y la coleccin de segundos
elementos se conoce como el intervalo de la sucesin. En este libro, las sucesiones
estn indicadas mediante corchetes angulados. Por ejemplo, la sucesin precedente
normalmente se escribira como (Janes, Wilson, Shapiro, Estavez).
A diferencia de los conjuntos, la duplicacin se permite en una sucesin, cuyo orden es importante. Por lo tanto,
(Jones, Wilson, Shapiro) * (Jones, Shapiro, Wilson)
La sucesin vaca se representa como ().
En las especificaciones formales se utilizan varios operadores de sucesin. La
concatenacin, ~ , es un operador binario que forma una sucesin construida al
agregar su segundo operando al final de su primer operando. Por ejemplo,
(2, 3, 34, 1)
(12, 33, 34,200)
genera la sucesin (2, 3, 34, 1, 12, 33, 34,200).

Otros operadores que se aplican a las sucesiones son cabeza, cola.frente y ltimo.
El operador cabeza extrae el primer elemento de una sucesin; cola proporciona los
ltimos n - l elementos en una sucesin de longitud n; ltimo extrae el elemento final en una sucesin; y frente proporciona los primeros n - 1 elementos en una sucesin de longitud n. Por ejemplo,
cabeza (2, 3, 34, 1, 99, 101)
=2
cola (2, 3, 34, 1, 99, 101 > = (3, 34, 1, 99, 101)
ltimo (2, 3, 34, 1, 99, 101)
= 101
frente (2, 3, 34, 1, 99, 101) = (2, 3, 34, 1, 99)

Dado que una sucesin es un conjunto de pares, se pueden aplicar todos los operadores de conjunto descritos en la seccin 28.2.2. Cuando se emplea una sucesin en
un estado, se debe designar mediante la palabra seq. Por ejemplo,
ArchivoLista : seq ARCHIVOS
NumUsuarios: Fil
842
PARTE CINCO
TEMAS AVANZAIXY3 EN INGENIERA DEL SOFTWARE
describen un estado con dos componentes: una sucesin de archivos y un nmer

natural.
El empleo de la notacin matemtica en la especificacin formal de un componen~~

de software se ilustrar repasando el gestor de bloques presentado en la secci<r
28.1.3. Un importante componente de un sistema operativo de computadora mantiene los archivos que han creado los usuarios. El gestor de bloques mantiene un depsito de bloques no utilizados y tambin seguir los bloques actualmente en uso
Cuando se liberan bloques de un archivo borrado normalmente se aaden a una fila de bloques que esperan ser aadidos al depsito de bloques no utilizados. En la
figura 28.2 se ha bosquejado esto esquemticamente. 4
Cmo se
pueden
representar los
estados e
invariantes de
dotos empleando
los operadores
lgicos y de
conjuntosque
yo se han
introducido?
Un conjunto llamado BLOQUES consistir de todos los nmeros de bloque. TodosBloques es un conjunto de bloques que se ubica entre 1 y MxBloques. El estado lo
modelarn dos conjuntos y una sucesin. Los dos conjuntos son usados y libres. Ambos contienen bloques: el conjunto usados contiene los bloques que actualmente se
estn utilizando en los archivos, y el conjunto libres contiene los bloques disponibles
para los archivos nuevos. La sucesin contendr conjuntos de bloques que estn listos para ser liberados de los archivos que se han borrado. El estado se puede describir como
usados, libres: P BLOQUES

FilaBioques: seq 1P BLOQUES
Esto es muy parecido a la declaracin de variables de programa. Establece que usa-
dos y libres sern conjuntos de bloques y que FilaBloques ser una sucesin, cada
elemento de la cual ser un conjunto de bloques. El invariante de datos se puede escribir como
usados n libres = 01\
usados u libres = TodosBloques i\
Vi: dom FilaBloques FilaBloques i ~ usados i\
V i, j: dom FilaBloques i j => FilaBloques i n FilaBloques j = 0
Los componentes matemticos del invariante de datos se corresponden con cuatro

de los componentes de lenguaje natural marcados que se describieron anteriormente.
La primera lnea del invariante de datos establece que no existirn bloques comunes
en las colecciones de bloques usados y libres. La segunda lnea afirma que la colee-
Si no se recuerda bien el ejemplo del gestor de bloques, por favor vase de nuevo la seccin 28. 1.3
para revisar el invariante de datos, las operaciones, precondiciones y poscondiciones asociadas con
el gestor de bloques.
843
cin de bloques usados y libres siempre ser igual a toda la coleccin de bloques en
el sistema. La tercera lnea indica que el i-simo elemento en la fila de bloques siempre ser un subconjunto de los bloques usados. La lnea final afirma que. para cualesquier dos elementos de la fila de bloques que no son el mismo, no habr bloques
comunes en estos dos elementos. Los dos componentes finales de lenguaje natural del
invariante de datos se implementan en virtud del hecho de que usados y libres son
conjuntos y por lo tanto no contendrn duplicados.
La primera operacin que se definir es la que elimina un elemento de la cabeza
de la fila de bloques. La precondicin es que debe existir al menos un elemento en
la fila:
# FilaBloques > O,
La poscondicin es que la cabeza de la fila debe eliminarse y colocarse en la coleccin de bloques libres, y la Fila se debe ajustar para mostrar la eliminacin:
usados' = usados \ cabeza FilaBloques /\

libres' = libres u cabeza FilaBloques /\
FilaBloques' = cola FilaBloques
Una convencin que se utiliza en muchos mtodos formales es que al valor de una
variable despus de una operacin se le pone prima. Por lo tanto, el primer componente de la expresin precedente afirma que los nuevos bloques usados (usados' )
sern iguales a los antiguos bloques usados menos los bloques que se han eliminado. El segundo componente afirma que los nuevos bloques libres (libres') sern los
antiguos bloques libres ms la cabeza de la fila de bloques. El tercer componente es-
Cmo se
representan
1115 pre y
piS<Ondiclones?
tablece que la nueva fila de bloques ser igual a la cola del antiguo valor de la fila de
bloques; esto es: todos los elementos en la fila, menos el primero.
Una segunda operacin agrega una coleccin de bloques, Abloques, a la fila de
bloques. La precondicin es que Abloques sea actualmente un conjunto de bloques
usados:
Abloques (;;; usados

La poscondicin es que el conjunto de bloques sea aadido al final de la fila, y el
conjunto de bloques usados y libres permanezca invariable:
FilaBloques' = FilaBloques
usados' = usados /\
libres' = libres
Abloques /\
No existe duda de que la especificacin matemtica de la fila de bloques es considerablemente ms rigurosa que una narracin en lenguaje natural o un modelo grfi co. El rigor adicional requiere esfuerzo, pero los beneficios obtenidos a partir de la
consistencia y la completud mejoradas se pueden justificar para muchos tipos de
aplicaciones.
844
PARTE CINCO
TEMAS AVANZADC/3 EN INGENIERA DEL SOFIWARE
28.4
un lenguaje formal de especificacin usualmente est compuesto de tres componentes principales: 1) una sintaxs que define la notacin especfica con la que se representa la especificacin, 2) semntica para ayudar a definir un "universo de objetos" [WIN9C
que se emplear para describir el sistema, y 3) un conjunto de reladones que definen las
reglas que indican cules objetos satisfacen adecuadamente la especificacin.
Con frecuencia, el dominio sintctico de un lenguaje formal de especificacin se
basa en una sintaxis que se deriva de la notacin estndar de la teora de conjuntos
y el clculo de predicados. Por ejemplo, variables tales como x, y y z describen ur
conjunto de objetos que se relacionan con un problema (en ocasiones llamado der
minio del discurso) y se utilizan en conjunto con los operadores descritos en la seccin 28.2. Aunque la sintaxis usualmente es simblica, tambin se pueden utilizar
iconos (por ejemplo, smbolos grficos como cajas, flechas y crculos) si no son ambiguos.
El dominio semntico de un lenguaje de especificacin indica cmo el lenguaje representa los requisitos del sistema. Por ejemplo, un lenguaje de programacin tiene
un conjunto de semnticas formales que permite al desarrollador de software especificar algoritmos que transforman entrada en salida. Se puede utilizar una gramtJca formal (como BNF) para describir la sintaxis del lenguaje de programacin. Sin
embargo, un lenguaje de programacin no hace un buen lenguaje de especificacin
porque slo representa funciones de cmputo. Un lenguaje de especificacin debe
tener un dominio semntico ms amplio, es decir, debe ser capaz de expresar ideas
como "para toda x en un conjunto infinito A, existe una y en un conjunto infinito 8
tal que la propiedad P se mantiene para x y y" {WIN90J. Otros lenguajes de especificacin aplican semnticas que permiten la especificacin del comportamiento del
sistema. Por ejemplo, es posible desarrollar una sintaxis y una semntica para especificar estados y transiciones de estado, y eventos, junto con sus efectos sobre la
transicin de estado, la sincronizacin y la temporalidad.
Es posible usar diferentes abstracciones semnticas para describir el mismo sistema en diferentes formas. En el captulo 8 esto se hizo en una manera menos formal. Se representaron clases, datos, funciones y comportamiento. Se puede usar diferente notacin de modelado para representar el mismo sistema. La semntica de
cada representacin ofrece visiones complementarias del sistema. Para ilustrar este
enfoque cuando se usan mtodos formales, suponga que se usa un lenguaje formal
de especificacin para describir al conjunto de eventos que provocan que ocurra un
estado particular en un sistema. Otra relacin formal bosqueja todas las funciones
que ocurren dentro de un estado dado. La interseccin de estas dos relaciones proporciona una indicacin de los eventos que causarn que ocurran funciones especficas.
En la actualidad se emplean varios lenguajes formales de especificacin. OCL
[OMG03]. Z ([IS002]. [SPI88], [SPI92]), LARCH [GUT93] y VDM UON91] son lenguajes
845
CAPTULO 28 Mhooos FORMALES
formales de especificacin representativos que muestran las caractersticas anotadas con anterioridad. En este captulo se presenta un breve panorama de OCL y z.
El lenguaje restringido a objetos (OCL, por sus siglas en ingls) es una notacin formal desarrollada de modo que los usuarios de UML puedan conferirle mayor precisin a sus
especificaciones. El lenguaje dispone de todo el poder de la lgica y la matemticas
discretas. Sin embargo, los diseadores de OCL decidieron que en este lenguaje slo
deberan usarse caracteres ASCil (en lugar de notacin matemtica convencional) . Esto permite que el lenguaje sea ms asequible a las personas menos inclinadas a las
matemticas y que la computadora los procese con mayor facilidad. Pero esto tambin favorece que OCL sea un poco farragoso en algunos lugares.
28.5.1 Un breve panorama de la sintaxis y la semntica del OCL

La utilizacin del OCL requiere que un ingeniero de software comience con uno o
ms diagramas UML: las clases, estados o diagramas de actividad ms comunes. Por
lo tanto, se agregan expresiones OCL que establecen hechos acerca de los elementos
de los diagramas. Estas expresiones se llaman restricciones; cualquier implementacin derivada del modelo debe garantizar que cada una de las restricciones siempre
iMHbrn"
~ ....1
IDKII de OCl !lt Pllt:
...........,
.....,
..,,
deenconhlf411
....,
wltwtn/
........
permanezca verdadera.
Al igual que el lenguaje de programacin orientado a objetos, una expresin OCL
involucra operadores que operan sobre los objetos. Sin embargo, el resultado de una
expresin completa siempre debe ser booleana, es decir: verdadero o falso. Los objetos pueden ser instancias de la clase OCL Coleccin, de la cual conjunto y Su-
cesin son dos subclases.

El objeto self (propio) es el elemento del diagrama UML en cuyo contexto se evaluar la expresin OCL. se pueden obtener otros objetos al
navegar usando el sim-
bolo . (punto) del objeto self. Por ejemplo:

Si self es clase C, con atributo 8, entonces s elf.8 evala al objeto almacenado
en 8 .
Si c tiene una asociacin multvoca llamada
asoc con otra clase D , entonces
self.8soc evala un Conjunto cuyos elementos son del tipo D.
Finalmente (y un poco ms sutil), si D tiene un atributo b, entonces la expresin self.8soc.b evala el conjunto de todas las b que pertenecen a todas las D .
Esta seccin es una aportacin del profesor Timothy L.elhbridge, de la Universidad de Ottawa, y se
presenta aqu mediate autorizacin
PARTE CINCO
TEMAS AVANZAIX)S EN INGENIERA DEL SOFTWME
El OCL proporciona operaciones construidas que implementan las matemticas

descritas en la seccin 28.2,
y ms. En la tabla 28.1
se presenta una pequea mues-
tra de estas operaciones.
TABLA
28.1
RESUMEN DE NOTACIN CLAVE OCL
Notacin OCL
Significado
x.y
Obtiene lo propiedad y del objeto x. Uno propiedad puede se

un atributo. el conjunto de ob jetos al final de uno osociocir
el resultado de evaluar uno operacin u otros cosos que depe~
dan del tipo de diagrama UML Si x es un Conjunto, entonces
y se aplica a todo elemento de x; los resultados se juntan en un
nuevo Conjunto.
c->f( J
Aplica la operacin OCL incorporado fo lo Coleccin c mis

mo !en oposicin o codo uno de los objetos en c). Los ejemplos
de operaciones incorporados se presentan lneas abajo.
y, or, = , <>
y lgica, o lgico, igual, no igual.
p implies q
Verdadero si q es verdadero o pes falsa.
Muestro de operaciones sobre colecciones (incluye conjuntos y secuencias)

c->sizeO
Nmero de elementos en lo Coleccin c.
c ->esEmptyO
Verdadero si c no tiene elementos, falso de cualquier otro mc:r

do
e l - >ncludesAll(c2)
Verdadero si todo elemento de c2 se encuentra en c 1.
e l ->excludesAlllc2!
Verdadero si ningn elemento de c2 se encuentro en c l .
c l -> forAll(elem I boolexpr)
Verdadero si boolexpr [expresin booleano) es verdadera cua""

do 5e aplico a todo elemento de c. Conforme se evalo un el~
mento, se ligo o lo variable elem !elemento). que se puede usar
en boolexpr. Esto implementa cuontificocin universal, estudiodo previamente.
e- >forAll(elem 1. elem2 1boolexpr)
Lo mismo que antes, excepto que boolexpr se evala paro lodo posible por de elementos tomados de c, incluso cosos donde el por consiste del mismo elemento.
c- > is uniquelelem I exprl
Verdadero si expr (expresin! evalo un valor diferente cua ndo

se aplico o todo elemento de c .
Muestro de operaciones especficos o conjuntos

s l ->intersection(s2)
El conjunto de aquellos elementos que se encuentran

en sl y tambin en s2.
s l ->union(s2J
El conjunto de aquellos elementos que se encuentran

en sl o en s2.
s l - >excludinglx)
El conjunto s I con el objeto x omitido.
Muestro de operacin especfico o secuencias

seq - >lirst()
El objeto que es el primer elemento en la sucesin seq.
-------,
CAPITULO 28
Mtrooos FORMALES
847
28.5.2 Ejemplo de u.so del OCL

En esta seccin se utiliza el OCL para ayudar a formalizar la especificacin del ejemplo del gestor de bloques, introducido en la seccin 28.1.3. El primer paso consiste
en desarrollar un modelo UML. En este ejemplo se comienza con el diagrama de clase de la figura 28.3. Este diagrama especifica muchas relaciones entre los objetos in
volucrados; sin embargo, se deben agregar expresiones OCL que garanticen que
quienes implementen el sistema conozcan con mayor precisin qu deben asegurar
que permanezca verdadero conforme se desarrolle el sistema.
Las expresiones OCL que se agregarn corresponden a las seis partes del inva
riante tratadas en la seccin 28.1.3. Respecto de cada una se repetir el invariante
en espaol y luego se brindar la correspondiente expresin OCL. se considera una
buena prctica ofrecer el texto en espaol junto con la lgica formal; hacerlo ayuda
al lector a comprender la lgica, y tambin apoya a los revisores a descubrir errores,
por ejemplo: situaciones donde el espaol y la lgica no correspondan.
1. Ningn bloque se marcar al mismo tiempo como no usado y usado.

oonfext OestorBloqun inv:
(self.usados->lnf81'88ofion(selr.libres)) -> lsEmpfy(J
Ntese que cada expresin comienza con la palabra clave context (contexto) Esto indica el elemento del diagrama UML que la expresin restringe. En forma alterna, el
ingeniero de software podra colocar la restriccin directamente en el diagrama
UML, rodeada por llaves (}. La palabra clave self se refiere a la instancia de GestorBloques; en lo que sigue, como es permisible en OCL, se omitir self.
2 . Todos los conjuntos de bloques que se mantienen en la cola sern subconjun-
tos de la colecci n de bloques usados actualmente.

oontext OestorBloquea inv:
oolaBloques->forAll(aConjuntoBloques I uaados->inoludesAll(aConjuntoBloques))
ifrhili
Diagrama de
clase para un
gestor de
bloques.
Bloque
elementos
ConjuntoBloques
nmero
libres
usados
todos *
Bloques
----- - - - - {subconjunto}
{subconjunto 1
1
coloBloques
{ordenado}
PARTE CINCO
TEMAS AVAN'ZMX:.6 EN INGENIERlA DEL SOfiWARE
3. Ningn nmero de bloque pertenecer a dos o ms elementos de la fila.
context OeatorBloques inv:

oolaBloquea- > fotAll(conjunto81oques1,conjunto81oques2 1
conjuntoB1oques1 <> conjuntoB1oques2 implies
conjunto81oquea1.elementos.nmero - > excludeaAII( conj unto81oques2.
elementos.n6meroJJ
La expresin antes de implles (implica) es necesaria para asegurar que se ignoran los pares donde ambos elementos son el mismo bloque.
4. La coleccin de bloques utilizados y bloques sin usar ser la coleccin total de

bloques que constituyen los archivos.
context OeatorBloquea inv:
a11Blocks = usados- > unon(~breaj
5. La coleccin de bloques sin usar no tendr nmeros de bloques duplicados
context OestorBloquea inv:

librea- >18Unique(aB1oque
I a81oque.nmeroj
6. La coleccin de bloques utilizados no tendr nmeros de bloques duplicados

oontext OeatorBloques inv:
uaados->isUnique(aBloque
I eBloque.nmeroj
El OCL tambn se utiliza para especificar precondiciones y poscondiciones de

operaciones. Por ejemplo, considrense las operaciones que eliminan y agregan
conjuntos de bloques de la cola. La notacin x@pre indica que el objeto x existe an-
tes de la operacin; esto es, opuesto a la notacin matemtica expuesta con anterioridad, donde la x despus de la operacin es la que est designada especialmente
(como x').
context 088torB1oquea: :eliminarSloqueaO
pre: coleBloquea- > size(j > O

post: usados = usado@pre - colaBloquea@pre- > ftrstU and
libres = tibre@pre- > union(colaBloques@pre->first() and
colaBloques = coleBloques@pre- > excluding(colaBloques@pre- > firstj
context Oestor81oquea::agregarB1oquea(aConjunto8loques :ConjuntoBloquesj
pre: usados- > includesAll(aConjuntoBloques.elementosj
post: (ooleBloques.elementos = ooleBloques.elementoa@pre
- > eppend(aConjuntoBloquesjj
end usados = usado@pre
and librea = libre@pre
El OCL es un lenguaje de modelado, pero tiene todos los atributos de un lenguaje formal. Tambin permite la expresin de varias restricciones, precondiciones y poscon-
CAPTULO 28
MTODOS FORMALES
849
diciones, guardias y otras caractersticas que relacionan a los objetos representados

en varios modelos UML.
Z es un lenguaje de especificacin que ha evolucionado durante las dos dcadas pa-
sadas y hoy se utiliza ampliamente entre la comunidad de los mtodos formales. El

lenguaje z aplica conjuntos tipificados, relaciones y funciones dentro del contexto de
predicados lgicos de primer orden para construir esquemas, un medio para estructurar una especificacin formal.
idlJIH5'tW1
lliammJfl dldd, '
IUOldel~Z
ene
...........
pale
....__,.,..
.,.,t...ul,./
ea.
28.6. l
Breve panorama de la sintaxis y semntica Z
Las especificaciones Z estn organizadas como un conjunto de esquemas; es decir,

una estructura parecida a un recuadro que introduce variables y especifica la relacin entre stas. Un esquema es, en esencia, la especificacin formal anloga del
componente de lenguaje de programacin. En la misma forma que los componentes
se emplean para estructurar un sistema, los esquemas se utilizan al estructurar una
especificacin formal.
Un esquema describe los datos almacenados a los que un sistema accede y altera.
En el contexto de Z esto se denomina el "estado". La utilizacin del trmino estado
en Z es ligeramente diferente de la que se emplea en el resto de este libro.6 Adems.
el esquema identifica las operaciones que se aplican para cambiar estado y las relaciones que ocurren dentro del sistema. La estructura genrica de un esquema asume la forma:
---nombreEsquema-----declaraciones
invariante
donde las declaraciones identifican las variables que comprenden el estado del sistema, y el invariante impone restricciones en la forma en la que el estado puede evolucionar. En la tabla 28.2 se presenta un resumen de la notacin del lenguaje Z.
28.6.2 Un ejemplo que utiliza Z

En esta seccin se utiliza el lenguaje de especificacin z para modelar el ejemplo del
gestor de bloques introducido previamente en este captulo. El siguiente ejemplo de
un esquema describe el estado del gestor de bloques y el invariante de datos:
6 Recurdese que en otros captulos eslado se cmp.lea para identificar un modo de comportamiento
observable externamente para un sistema
850
PARTE CINCO
TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
---GestorBloques--- - - - - - - - -- - - - - usados, libres: P BLOQUES

FilaBioques: seq P BLOQUES
usados n libres = 0 /\
usados u libres = TodosBioques /\
Vi: dom ColaBloques FilaBloques i !;;; usados /\
'<li, j: dom ColaBloques i * j = > ColaBloques i n ColaBloques j = 0
TABLA
28 . 2
RESUMEN DE NOTACIN Z
Lo notacin Z se basa en teora de conjuntos tipificado y en lgica de primer orden. Z proporciono

constructo, llamado esquema, paro describir el espacio y los operaciones de estado de uno especificccin. Un esquema agrupo declaraciones de variable con una lista de predicados que restringen el postble valor de una variable. En Z el esquema X se define par la forma
--x--------------declorociones
predicados
los funciones globales y las constantes se definen por lo formo
declaraciones
predicados
Lo dedorocin brinda el tipo de lo funcin o constante, mientras que el predicado proporciona su valor
En esto tabla slo se presenta un conjunto abreviado de smbolos Z.
Conjuntos:
S: 1P' X
Ses declarado como conjunto de Xs.
x es miembro de S.
xeS
X El: 5
x no es miembro de S.
S es un subconjunto de T: todo miembro de S tambin est en T.
S!;;;T
Lo unin de S y T: contiene a todo miembro de So To ambos.
SnT
La interseccin de S y T: contiene a todo miembro que est tonto en S como en T.
S\T
La diferencia de S y T: contiene a todo miembro de S, excepto a aquellos que tambin
estn en T.
Conjunto vaco: no contiene miembros.
0
{x}
Conjunto unitario: slo contiene o x.
El conjunto de los nmeros naturales O, 1, 2, ...
N
S: IFX
Ses declarado como conjunto finito de X.
max [S)
El mximo del conjunto no vaco de nmeros S.
sur
Funciones:
f:XH
dom f
ron f
f {x t-t y}
dom f
f es declarado como uno inyeccin parcial de X o Y.

El dominio de f: el conjunto de valores x paro los cuales est definido f(xl.
El rango de f: el conjunto de valores que toma f(x) conforme x vara sobre et dominio de f.
Uno funcin que concuerda con f, excepto que x se correlaciona con y.
Una funcin como 1, excepto que x es eliminado de su dominio.
CAPTULO 28
Lgica:
P/\Q
P=Q
8 S'= e S
MTODOS FORMA!.ES
851
P y Q es verdadero si IOllto Pcomo Q son verdoderos

P ,mplico Q ; es ~dociefo $1 o Q es verdodero o P es falso
Ningn componenre oel esquemo S comb10 en uno operacin.
Como se ha sealado, el esquema consiste de dos partes. La parte sobre la lnea cen
tral representa las variables del estado, mientras que la parte debajo de la lnea central describe el invariante de datos. Siempre que el esquema especifica las operaciones que cambian el estado lo precede el smbolo J.. El siguiente ejemplo de esquema
describe la operacin que elimina un elemento de la cola de bloques:
- ---EliminarBloques- - -- -- 6
GestorBloques
#GestorBloques > O,
usados' = usados \ cabeza ColaBioques /\
libres' = libres u cabeza ColaBloques /\
ColaBloques = cola ColaBloques
La inclusin de 6 GestorBloques resulta en todas las variables que configuran el esta-
do que estar disponible para el esquema EliminarB/oques y asegura que el invariante

de datos se mantendr antes y despus de que la operacin se haya ejecutado.
La segunda operacin, que aade una coleccin de bloques al final de la cola, est representada como
---AadirBloque:s----- -- -6 GestorBloques
Abloques? : BLOQUES
Abloques? ~ usados
FilaBloques' - FilaBloques - (Abloques?) /\
usados' = usados /\
libres' = libres /\
Por convencin en z, una variable de entrada que se lee pero no forma parte del estado termina con un signo de interrogacin. Por ende, Abloques?, que acta como
parmetro de entrada, tennina con un signo de nterrogacin.
852
PARTE CINCO
TEMAS AVANZAOOS EN lNGENIEruA DEL SOFIWARE
Mtodos formales
Objetivo: El objetivo de los herramientas de

los mtodos formales es auxiliar ol equipo de
software en lo especificacin y verificacin de lo correccin.
Mecnica: Lo mec6nico de los herramientas varo. En
general, oyudon en lo especificacin y en lo pruebo auto

m6tica de lo correccin, usualmente al definir un lenguaje
especializado para lo pruebo de teoremas. Muchos herro
mientas no se comercializan y se hon desarrollado con
propsitos de investigacin.
de programacin con el que puede modelar sistemas de

cmputo, como uno herramienta paro ayudarlo o probar los propiedades de dichos modelos".
EVES, desarrollado por ORA Conod6 (www.oro.on.co/eves.html), implemento el lenguoie Verdi poro especificacin formol y un generador de pruebas
automatizado.
Una listo extensa con m6s de 90 herramientas de mtodos
formales se puede encontrar en
http://www.ofm.sbu.ac.uk/.
ACL2, desarrollado en la Universidad de Texas (www.cs.utexos.edu/users/ moore/acl2/), es "tonto un lenguaje
La decisin de usar mtodos formales en el mundo real no es una que se tome a la
ligera. Bowan y Hinchley [B0W95] han acuado "los diez mandamientos de los mtodos formales" como una guia para aquellos que estn a punto de aplicar este im-
portante enfoque de la ingeniera de software.8

1 . Elegirs la notacin apropiada. Para elegir con eficacia de una amplia variedad
de lenguajes formales de especificacin, un ingeniero de software debe considerar el vocabulario del lenguaje, el tipo de aplicacin que se especificar y la
amplitud de uso del lenguaje.
2. Formalizars pero no en exceso. Por Jo general no es necesario aplicar los mtodos formales en todos los aspectos de un gran sistema. Aquellos componentes cruciales para la seguridad son las primeras elecciones, seguidos por
los componentes cuya falla no puede tolerarse (por razones de negocios).
3. Estimars los costos. Los mtodos formales tienen elevados costos de arran-
que. El entrenamiento del equipo, la adquisicin de herramientas de apoyo y

la utilizacin de consultores redunda en altos costos al inicio. Es preciso considerar dichos costos cuando se examina el rendimiento sobre la inversin
asociada con los mtodos formales.
7 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.
8
Este tratamiento es una versin ms abreviada de 1B0W95J.
CAPTULO 28
MTODOS FORMAUS
853
4 . Tendrs un experto en mtodosformales a tu disposicin. El entrenamiento experto y la consultora de seguimiento son esenciales para el xito cuando se
emplean los mtodos formales por primera ocasin.
5. No abandonars los mtodos tradidonales de desarrollo. Es posible, y en muchos casos deseable, integrar los mtodos formales con mtodos convencionales u orientados a objetos (parte 2 de este libro). Cada uno tiene fortalezas y
debilidades. Una combinacin, si se aplica con propiedad, puede producir excelentes resultados. 9
6. Documentars suficientemente. Los mtodos formales proporcionan un mtodo conciso, sin ambigedades y consistente para documentar los requisitos
del sistema. Sin embargo, es recomendable que un comentario en lenguaje
natural acompae la especificacin formal y sirva como mecanismo para reforzar la comprensin del lector acerca del sistema.
7. No comprometers los estndares de calidad. "No hay nada mgico en los mtodos formales" [B0W95], y por esta razn debe continuar la aplicacin de
otras actividades de SQA (captulo 26) conforme los sistemas se desarrollen.
8. No sers dogmtico. Un ingeniero de software debe reconocer que los mtodos formales no regarantizan la correccin. Es posible (alguien dira, probable) que el sistema final, aun cuando se desarrolle empleando mtodos
formales, puede tener pequeas omisiones, bugs menores y otros atributos
que no satisfagan las expectativas.
9 . Probars, probars y probars de nuevo. La importancia de las pruebas del software se ha estudiado en los captulos 13 y 14. Los mtodos formales no absuelven al ingeniero de software de la necesidad de llevar a cabo pruebas
extensivas bien planeadas.
10. Reutilizars. A largo plazo, la nica forma racional de reducir los costos de
software y aumentar la calidad de ste es mediante la reutilizacin (captulo

30). Los mtodos formales no cambian esta realidad. De hecho, es posible que
los mtodos formales sean un enfoque apropiado cuando se han de crear

componentes para libreras de reutilizacin.
Aunque las tcnicas formales de especificacin basadas matemticamente no se

emplean con amplitud en la industria, s ofrecen ventajas sustanciales sobre las tcnicas menos formales. Liskov y Bersins [LIS86J resumen esto as:
La ingeniera de software de sala lunpia (capboo 29) es un ejemplo de un enfoque integrado que
utiliza mtodos formales y mtodos ele desanolJo mas convencionales.
854
PARTE CINCO
Las especificaciones formales se pueden estudiar matemticamente, pero no las informales. Por ejemplo, un programa correcto se prueba para satisfacer sus especificaciones. o
se puede probar que dos conjuntos alternativos de especificaciones son equivalentes ...
Ciertas formas de incompletud o inconsistencia se pueden detectar automticamente.
Adems, la especificacin formal elimina la ambigedad y alienta el mayor rigor en

las primeras etapas del proceso de ingeniera del software.
No obstante, los problemas persisten. La especificacin formal se enfoca principalmente en la funcin y los datos. La temporalidad, el control y los aspectos de
comportamiento de un problema son ms dificiles de representar. Adems, ciertos
elementos de un problema (por ejemplo, interfaces humano/mquina) se especifican mejor empleando tcnicas grficas o prototipos. Finalmente, la especificacin
que emplea mtodos formales es ms dificil de aprender que los mtodos que incorporan notacin UML y representan un significativo "choque cultural" para algunos
profesionales del software.
Los mtodos formales ofrecen un cimiento para los entornos de especificacin que
conducen a modelos de anlisis ms completos. consistentes y sin ambigedades
que aquellos producidos con mtodos convencionales u orientados a objetos. Las facilidades descriptivas de la teora de conjuntos y la notacin lgica permiten que un
ingeniero de software cree un planteamiento claro de hechos (requisitos) .
Los conceptos subyacentes que rigen los mtodos formales son 1) el invariante de
datos, una condicin verdadera a travs de la ejecucin del sistema que contiene
una coleccin de datos; 2) el estado, una representacin del modo de comportamiento observable externamente de un sistema, o (en Z y lenguajes relacionados) los
datos almacenados a los que un sistema tiene acceso y altera; y 3) la operacin, una
accin que tiene lugar en un sistema y lee o escribe datos a un estado. Una operacin est asociada con dos condiciones: una precondicin y una poscondicin.
Las matemticas discretas -la notacin y heursticas asociados con conjuntos y
la especificacin constructiva. operadores de conjuntos. operadores lgicos y sucesiones- forman la base de los mtodos formales. Las matemticas discretas se implementan en el contexto de los lenguajes formales de especificacin, tales como
OCL y z. Estos lenguajes tienen dominios tanto sintctico como semntico. El dominio sintctico utiliza una simbologa alineada de manera cercana con la notacin de
conjuntos y el clculo de predicados. El dominio semntico permite que el lenguaje
exprese los requisitos en una forma concisa.
La decisin de usar mtodos formales debe considerar los costos de arranque, as
como los cambios culturales asociados con una tecnologa radicalmente diferente.
En la mayora de las instancias, los mtodos formales tienen mayores rendimientos
respecto de los sistemas cruciales para la seguridad y los negocios.
CAPTULO 28
MTODOS FORMALES
855
[B0W95] Bowan, J. P., y M. G. Hinchley, "Ten Commandments of Formal Methods", en Computer, vol. 28, nm. 4, abril de 1995.
[GRI95] Gries, D., y F. B. Schneider, A Logical Approach to Discrete Math, Springer-Verlag, 1993.
[GUT93) Guttag, J. V., y J. J. Horning, Larch: Languages and Tools Jor Formal Specijication, Springer-Verlag, 1993.
[HAL90} Hall, A., "Seven Myths of Formal Methods", en IEEE Software, septiembre de 1990, pp.
11-20.
[HOR85] Hoare, C.A.R., Communicating Sequential Processes, Prentice-Hall lnternational, 1985.
[IS002J Z formal Specijication Notation-syntax, 1ype system and Semantics, ISO/IEC l 3568:2002,
lntl. Standards Organization, 2002.
[JON9IJ Jones, C. B., systematic Software Development Using VDM, 2a. ed., Prentice-Hall, 1991.
[US86J Liskov, B. H., y V. Berzlns, "An Appraisal of Program Specifications", en Software Specijication Techniques, N. Gehani y A. T. McKittrick (eds.), Addison-Wesley, 1986, p. 3.
[MAR94) Marciniak, J. J. (ed.} Encyclopedia o/Software Engineering, Wiley, 1994.
[OMG03J "Object Constraint Language Specification", en Unijied Modeling Language, v2.0, Object Management Group, septiembre de 2003, se puede descargar de www.omg.org.
[ROS95] Rosen, K. H., Discrete Mathematics and Its Applications, 3a. ed., McGraw-Hill, 1995.
[SPI88J Spivey, J. M., Understanding Z : A Specijication Language and Its Formal Semantics, Cambridge University Press, 1988.
fSPI92) Spivey, J. M., The z Notation: A Reference Manual, Prentice-Hall, 1992.
[WIL87] Wiltala, S. A., Discrete Mathematics: A Unijied Approach, McGraw-Hill, 1987.
[WIN90] Wing, J. M., "A Specifier's Introduction to Formal Methods", Computer, vol.23, nm. 9,
septiembre de 1990, pp. 8-24.
[YOU94] Yourdon, E., "Formal Methods", Guerrilla Programmer, Cutter Infonnation Corp., octubre de 1994.
2 8 . l . Revisar los tipos de deficiencias asociadas con los enfoques menos formales para la ingeniera del software de la seccin 28.1. I. Ofrecer tres ejemplos de cada uno a partir de la experiencia propia.
2 8 .2 . Los beneficios de las matemticas como mecanismo de especificacin se han tratado extensamente en este captulo. Existe algn aspecto negativo?
28.3. Usted ha sido asignado a un equipo que est desarrollando software para un fax mdem.
Su tarea es desarrollar la parte de "directorio" de la aplicacin. La funcin directorio permite que
almacenen hasta Ma.xNombres personas junto con los asociados de nombres de compaa, nmeros de fax y otra informacin relacionada. Empleando lenguaje natural defina
a) El invariante de datos
bJ El estado.
c) Las operaciones probables.
2 8.4. Usted ha sido asignado a un equipo que est desarrollando software, llamado Duplicador
de memoria, que ofrece mayor memoria aparente para una PC que la memoria fisica. Esto se logra al identificar, recopilar y reasignar bloques de memoria que se han asignado a una aplicacin existente pero que no se utilizan. Los bloques no utilizados se reasignan a las aplicaciones
que requieren memoria adicional. Con las suposiciones apropiadas y el uso de lenguaje natural,
defina
a) El invariante de datos.
bJ El estado.
e) Las operaciones probables.
28.5. Desarrolle una especificacin constructJva para un conjunto que contiene duplas de nmeros naturales de la forma (X,y, z2) tales que la suma de x y y es igual a z.
PARTE CINCO
TEMAS AVAN~ EN INGENIERA DEL SOFTWARE
28.6. El instalador para una aplicacin basada en PC determina primero si estn presentes ...
conjunto aceptable de hardware y recursos del sistema. Verifica la configuracin del hardwa:
para determinar si estn presentes varios dispositivos (de muchos posibles dispositivos) y determina si ya estn instaladas versiones especificas de software y controladores del sistema
Qu operador de conjunto se podria usar para lograr esto? Ofrecer un ejemplo en este con
texto.
28. 7. Intentar desarrollar una expresin utilizando operadores lgicos y de conjunto para el Siguiente enunciado: "Para toda x e y, si x es el padre de y y y es el padre de z, entonces x es a
abuelo de z. Todos tienen un padre." sugerencia: emplear las funciones P(x, y) y G(x. z) para representar las funciones padre y abuelo, respectivamente.
28.8. Desarrollar una especificacin constructiva de conjunto del conjunto de pares donde e
primer elemento de cada par es la suma de dos nmeros naturales distintos de cero, y el segundo elemento es la diferencia entre los mismos nmeros. Ambos nmeros deben estar entre 100
y 200, inclusive.
28.9. Desarrollar una descripcin matemtica para el estado y el invariante de datos del problema 28.3. Refinar esta descripcin en el lenguaje de especificacin OCL o Z.
28.1 o. Desarrollar una descripcin matemtica para el estado y el invariante de datos del problema 28.4. Refinar esta descripcin en el lenguaje de especificacin OCL o Z.
28.11. Mediante la notacin OCL o Z presentadas en las tablas 28.1 o 28.2, seleccionar alguna
parte del sistema de seguridad Hogarseguro descrito previamente en este libro e intentar describirla con OCL o Z.
28.12. Empleando una o ms de las fuentes de informacin que aparecen en las referencias de
este captulo o en "Otras lecturas y fuentes de informacin", desarrollar una presentacin de
media hora acerca de la sintaxis y la semntica bsicas de un lenguaje formal de especificacin
distintos a OCL o Z.
/\dems de los libros empleados como referencias en este captulo, durante la dcada pasada
se publicaron numerosos libros acerca de temas de mtodos formales. A continuacin se presenta una lista de algunos de los ms tiles:
Bowan, J.. Formal Specjication and Documentation using Z: A case Study Approach, lnternational Thomson Computer Press, 1996.
Casey, C., A Programming Approach to Formal Methods, McGraw-Hill, 2000.
Clark, T., et al. (eds.), Object Modeling with OCL, Springer-Verlag, 2002.
Cooper, D., y R. Barden,
z in Practice, Prentice-Hall, 1995.
Craigen, D., S. Gerhart y T. Ralston, Industrial Application of Formal Methods to Model, Design
and Analyze Computer ~tems, Noyes Data Corp., 1995.
Harry, A., Formal Methods Fact File: VDMy Z, Wiley, 1997.
Hinchley, M., y J. Bowan, Applications ofFormal Methods, Prentice-Hall, 1995.
Hinchley, M, y J. Bowan, Industrial Strenght Formal Methods, Academic Press, 1997.
Hussmann, H., Formal Foundations for Software Engineering Methods, Springer-Verlag, 1997.
Jacky, J., The Way of Z: Practica] Programming with Formal Methods, Cambridge University
Press, 1997.
Monn, F., y M. Hinchley, Understanding Formal Methods, Springer-Verlag, 2003.
Rann, D., J. Turner y J. Whitworth, Z: A Beginner's Guide, Chapman and Hall, 1994.
Ratcliff, B., lntroducing Specfication Using Z: A Practica/ Case Study Approach, McGraw-Hill,
1994.
CAPTULO 28
857
MTODOS FORMALES
Sheppard, D., An Introduction to Formal Specijication wilh
z and VDM, McGraw-Hill, 1995.
Wamer, J., y A. Kleppe, ObJect Constraint Language, Addison-Wesley, 1998.

Dean (fSSence ofDiscrete Malhematics, Prentice-Hall, 1996), Gries y Schneider [GRJ93) y Lipschultz y Lipson (2000 S01ved Problems in Discrete Mathematics, McGraw-Hill, 1991) presentan informacin til para quienes deben aprender ms acerca de las bases de los mtodos formales.
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de los mtodos formales. Una lista actualizada de referencias en la World Wide Web se puede encontrar
en el sitio Web SEPA:
CAPTULO
CLA'VII
tSJj!cifklQ611 c'6
cajo clustcido .866

espficli.dn
cl1tcqj!I ft1111i
P~ .....
;866
especlfkodll ele
net(O 86S
'*
espdli~lm ,
ele estructura
dttafls ......863
ttpecifi(O(l!,1
fundonl .. .a63
estrategkide
sala Umpia 860
prueba estadstico
de uso .......873
refiiocalento
de diseo .....867
W ~ l - -869
vlrifkocln .867
.E
I US 1ntg:rado del modelado convencional de ingenirfa del software

posiblemente los.mtodos fo~ajes), la verificacin de programas (prue
bas d~ correccin) y el SQA estadstic<>; se Jian combinado en upa tcnc
que pued~ COJldUcif a software de calda4 extremadamente alta. La ingeniera dd
software desala JJmpta es un enfoque que resalta la necesidad de construir la correc.ciit ~rrel software conforme se desarrolla. En lugar del clsico ciclo de an,lisis, 'disei\o, cdigo, Rtueba !J depuracin" el enfoque de sall:l limpia $Ugiere un
punt9 de Vist~ diferente [Lllil94]:
4"! tilosfia detr~s: de la ingenierta del Sbj'lwate de sala limpia con$Jste en evtar la dependencia de costosos proceso$ de eliminacin de defectos al esctjblr k>$ incremen, tos de c6Qigo.'corre<;tos ta primera vez y verificar su correccin antes de ponerlo a
prueo~,Su mo4e!Q. de proceso incotpora }i;l ,c;ertficadn e$tadfstica de calidad de los
incrementos de cdigo conforme se aeumulan en el sistema.
En muchos aspectos, ei enfoque de sala limpia e1eva la ingenietia de software a otro nivel. Al igual que lo!:i mtodos fottnales presentados ert ~l captulo 28
el proceso de sala limpia destaca el rigor en ta especificacin y el di~o, y la
verificacin formal de caaa elemento ~e diseo mediante pruebas de c0rrecdn
con bases matemticas, Al extender el enfoque adoptijdQ et) los mtodos formales, el enfoque ~e sala Jlmpia tambin resalta la,s t9nicas pata el control
estadlstico deJa calidad, incluso prueoas que s~bqsan en-el uso anticipado del
sottwarepor prte de los dientes. ,
. ". . .. , . ,
en'el mundo .real( aburidan }OS peJ~tOS inmediatos

y a largo pla~o. Los pengros seelacionan con la segundad humana, las prdi; das econrrt.fo:aso,la oper:acln efectiva del T).egqao y la infraestntcrura social.
Cuana,0 el sofot,1are fal
l,.<;11-fiseni~ra del sowwe de sal Umj:)ia ~ un,mo(lelo c;le PJQCeso que elimina
los defectos anres de que puedan generar peligros sertos,
UN VISTAZO
RPIDO
~~ 1
CAPTULO 29 INGENIERA DEL SOFTWARE DE SA!.A LIMPIA
859
La filosofa de la "sala limpia" en las tecnologias de fabricacin de hardware en rea-
lidad es bastante simple: es eficaz en cuanto a costo y tiempo para establecer un

enfoque de fabricacin que evite la introduccin de defectos de produccin. Ms que
fabricar un producto y Juego trabajar para eliminar los defectos, el enfoque de sala
limpia demanda la disciplina requerida para eliminar los errores en la especificacin
y el diseo y luego fabricarlo en una forma "limpia".
Mills, Dyer y Linger [MIL87] propusieron, durante el decenio de 1980, originalmente la filosofa de sala limpia para la ingeniera del software. Aunque las primeras experiencias con este enfoque disciplinado respecto al trabajo de software fueron significativamente prometedoras [HAU94J. no obtuvo gran difusin. Henderson
[HEN95] sugiere tres posibles razones:
1. Una creencia de que la metodologa de sala limpia es demasiado terica, demasiado matemtica y demasiado radical para aplicarla en el desarrollo de
software real.
2. No aboga por una prueba unitaria de parte de los desarrolladores, sino que la
sustituye con la verificacin de la correccin y el control estadstico de la calidad, conceptos que representan una gran desviacin de la forma en la que se
desarrolla actualmente la mayona del software.
3. La madurez de la industria de desarrollo del software. La utilizacin de los
procesos de sala limpia requiere la rigurosa aplicacin de procesos definidos
en todas las fases del ciclo de vida. Dado que gran parte de la industria conti-
860
PARTE CINCO
na operando en grados relativamente bajos de madurez del proceso, los ingenieros de software no han estado listos para aplicar las tcnicas de sala
limpia.
A pesar de los elementos de verdad en cada una de estas preocupaciones, los benc::
ficios potenciales de la ingeniera del software de sala limpia superan con mucho .a
inversin requerida para superar la resistencia cultural ubicada en el centro de estas
preocupaciones.
.....
111"'1ti 'arffll-de que en un programo ocurran los errores es que un autor los coloque ohL No ,e. . ..
. lllalnisnlos... la prctico correcto busco evitar la insercin de errores y, cuando '$1 fallo l respecte, ....... .
ifjbfia ocualquitra otro formo de ajecutor el programa.
29.1.1
La estrategia de sala limpia
El enfoque de sala limpia utiliza una versin especializada del modelo de proceso
incremental (capitulo 3). Mediante pequeos equipos de software independientes se
desarrolla una "lnea de incrementos de software" [LIN94]. Conforme cada incremento se certifica se integra en el todo. Por ende, la funcionalidad del sistema crece
con el tiempo.
En la figura 29. l se ilustra la sucesin de las tareas de sala limpia para cada incremento. Los requisitos globales del sistema o producto se desarrollan empleando los
ifri&fll
Modelo del
proceso ele
sala llnlpla.
Incremento 1
11
~11
1
Incremento 2
Incremento 3
pp
IS ingeniera de sistemas
RR = recopilacin de requisitos
EEC
DF
VC
= especificacin de estructura de cajas

= diseo formal
= verificacin de correccin
_ _ ,1
GC = generacin de cdigo
IC - inspeccin de cdigo
PEU - pruebo estadstico de uso
e = certificacin
PP = ploneocin de pruebas
CAPTULO 29
861
INGENIERA DEL SOFTWARE !:E SAL.A LIMPIA
mtodos de ingeniera del software estudiados en el captulo 6. La lnea de incrementos de sala limpia se inicia una vez que la funcionalidad se ha asignado al elemento de software del sistema. Se producen las siguientes tareas:
Cules SOII
las prlndpa
11s tareas lleva
415 a cabo como
_,e de la inge
aria del sohwa
n lle sala limpia?
Planificacin del incremento. Se desarrolla un plan de proyecto que adopta la

estrategia incremental. Se crean la funcionalidad de cada incremento, su tamao
proyectado y un plan de desarrollo de sala limpia. Se debe tener especial cuidado
para asegurar que los incrementos certificados se integrarn en forma oportuna.
Recopilacin de requisitos. Mediante tcnicas similares a las introducidas en
el captulo 7 se elabora una descripcin ms detallada de los requisitos del cliente
(para cada incremento).
Especificacin de la estructura de cajas. Se utiliza un mtodo de especificacin que emplea estructuras de caja [HEV93] para describir la especificacin funcional. Para ajustarse a los principios de anlisis operativo tratados en los captulos s y
7, las estructuras de cajas "aslan y separan la definicin creativa de comportamiento, datos y procedimientos en cada grado de refinamiento".
...... 1
.IDrmdi '
.u,spmalo
lplllfa del .....
se~
8Ulholenwww.
..........
Diseo formal. Empleando el enfoque de estructura de cajas el diseo de sala

limpia es una extensin natural y uniforme de la especificacin. Aunque es posible
establecer una distincin clara entre las dos actividades, la especificaciones (llamadas cajas negras) son iterativamente refinadas (dentro de un incremento) para volverse anlogas a los diseos arquitectnico y al nivel de componente (llamados cajas
de estado y cajas transparentes, respectivamente) .
Verificacin de la correccin. El equipo de sala limpia lleva a cabo una serie

de rigurosas actividades de verificacin de la correccin en el diseo y luego en el
cdigo. La verificacin (secciones 29.3 y 29.4) comienza con la estructura de caja de
nivel superior (especificacin) y se mueve hacia el detalle de diseo y el cdigo. El
primer nivel de verificacin de correccin ocurre al aplicar un conjunto de "preguntas de correccin" [LIN88J. Si stas no demuestran que la especificacin es correcta
se emplean mtodos ms formales (matemticos) en la verificacin.
Generacin de cdigo, inspeccin y verificaci n. Las especificaciones de

estructura de caja, representadas en un lenguaje especializado, se traducen al lenguaje de programacin apropiado. Entonces se utilizan comprobaciones manuales
estndar o tcnicas de inspeccin (captulo 26) que garantizan la conformidad
semntica del cdigo y las estructuras de cajas, as como la correccin sintctica del
cdigo. Luego se lleva a cabo la verificacin de la correccin para el cdigo fuente.
....
,O tngenlla dtl software efe solo limpiologro el control estoarstico de lo calidad sobre el dSorrl!II.tfel sofiawt 11#
saparar eslJirlame,nte ef PfOCBSO de diseo del proceso de pruebo en uno nneo de desarrollo ionememal de soffwan.
Planificacin de pruebas estadsticas. Se analiza el uso proyectado del software y se planifica y disea un conjunto de casos de prueba que ejercitan una "dis-
862
lo sala limpia destoca

las pruebas que
eje1citon la fo1ma en
que el saftwa1e es
reo/mente utilizado.
Los casos de uso
ofrecen uno introduccin al p,oceso de
p/aneaci6n de
pruebas.
PARTE CINCO
tribucin de probabilidad" de utilizacin (seccin 29.4). Como se muestra en la fig-..

ra 29.1, esta actividad de sala limpia se lleva a cabo en paralelo con la especificacin, la verificacin y la generacin de cdigo.
Prueba estadistica de la utilizacin. Como se recordar, la prueba exhaust.

va del software de computadora es imposible (captulo 14), por Jo que siempre e
necesario disear un nmero finito de casos de prueba. Las tcnicas estadsticas de.
utilizacin [P0088] ejecutan una serie de pruebas derivadas de una muestra estadstica (la distribucin de probabilidad anotada previamente) de todas las posibles
ejecuciones de programa por parte de todos los usuarios a partir de una poblacir
objetivo (seccin 29.4).
Certificacin. una vez completadas la verificacin, la inspeccin y las pruebas

de utilizacin (Y de que todos los errores hayan sido corregidos), el incremento se
certifica listo para la integracin.
Al igual que otros modelos de proceso de software tratados en otras partes de este
libro, el proceso de sala limpia se apoya sustancialmente en la necesidad de producir
anlisis de alta calidad y modelos de diseo. Como se ver ms adelante en este captulo, la notacin de estructura de cajas es simplemente otra forma en la que un ingeniero de software puede representar los requisitos y el diseo. La distincin real dei
enfoque de sala limpia es que la verificacin formal se aplica a los modelos de ingenieria.
29 .1.2
Qu hace diferente a la sala limpia?
Dyer [DYE92J alude a las diferencias del enfoque de sala limpia cuando define el proceso:
La sala limpia representa el primer intento prctico de someter el proceso de desarrollo de
software al control estadstico de la calidad con una estrategia bien definida para la mejora continua de los procesos. Con el fin de alcanzar esta meta se defini un ciclo de vida
nico de sala limpia, el cual se enfoca en la ingenierla del software basada en matemticas para corregir diseos de software y en la prueba de software basada en estadsticas
para la certificacin de la fiabilidad del software.
La ingeniera del software de sala limpia difiere de los mtodos convencionales y

orientados a objetos de la ingeniera del software porque:
l . Emplea en forma explicita el control estadstico de la calidad.
Los ms importontes
coroctersticos
<istintivos de lo salo
impo son lo pruebo
de lo C01Teccin y los
r:ielm eslooisticos de
i:t1zimL
2. verifica las especificaciones del diseo utilizando una prueba de correccin basada matemticamente.
3. Implementa tcnicas de prueba con una alta probabilidad de descubrir errores
de alto impacto.
Obviamente, el enfoque de sala limpia aplica la mayora, si no todos, los principios
y conceptos bsicos de la ingeniera del software presentados a lo largo de este libro.
CAPTULO 29
INGENIERA DEL SOITWARE DE SALA LIMPIA
863
Los buenos anlisis y procedimientos de diseo son esenciales si se quiere obtener

alta calidad. Pero la ingenierla de sala limpia difiere de las prcticas del software
convencional porque le resta importancia (algunos dirlan, elimina) al papel de la
prueba unitaria y la depuracin y reduce drsticamente (o elimina) la cantidad de
pruebas que realiza el desarrollador del software. 1
En el desarrollo de software convencional los errores se aceptan como un hecho
ineludible. Puesto que los errores estn condenados a ser inevitables, cada componente de programa debe probarse en forma individual (para descubrir los errores) y
luego depurarse (para eliminar los errores). Cuando finalmente se libera el software,
durante su utilizacin se descubren todava ms defectos y comienza otro ciclo ele
prueba y depuracin. La reelaboracin asociada con dichas actividades es costosa y
consume mucho tiempo. Peor an, puede resultar degenerativa: la correccin de errores tal vez conduzca (inadvertidamente!) a la introduccin de ms errores todava.
'"lhi asptdo turioso dt lo vida es que si te rehsas en absolutooaceptar lo mejor con freroendo lo obtienes."
w. Swrset ......
En la ingeniera del software de sala limpia la prueba unitaria y la depuracin se
sustituyen verificando la correccin y las pruebas basadas en estad[stcas. Dichas
actividades, combinadas con la conservacin de registros necesaria para la mejora
continua, hacen que el enfoque de sala !impa sea nico.
20.2
l&PIQlfJCASJlw fVMCJAMa\L
Sin importar el mtodo de anlisis elegido, se aplican los principios de anlisis operativo presentados en el captulo 7. Los datos, las funciones y el comportamiento se
modelan . Los modelos que se obtienen deben partcionarse (refinarse) para proporcionar cada vez mayor detalle. El objetivo global es moverse desde una especificacin (o modelo) que capture la esencia de un problema hasta una especificacin que
ofrezca sustanciales detalles de implementacin.
La ingeniera del software de sala limpia cumple con los principios de anlisis
operativo empleando un mtodo llamado especifi-cacin de estructura de cajas. Una
"caja" encapsula al sistema (o algn aspecto de ste) en algn grado de detalle. Por
medio de un proceso de elaboracin o refinamiento en niveles, las cajas se refinan
en una jerarqua donde cada una tiene transparencia referencial. Esto es: "el contenido de informacin de cada especificacin de caja es suficiente para definir su refinamiento, sin depender de la implementacin de alguna otra caja" [LIN94). Esto le
permite al analista partir un sistema jerrquicamente, moverse desde la representacin esencial en la parte superior hacia un detalle especfico de la implementacin
en el fondo. Se utilizan tres tipos de cajas.
t
La prueba la realiza un equipo de prueba ~ e
PARTE CINCO
864
Cmo se
logra ,1 refinamiento como

parte de una
espedficadn de
estructura de
cajas?
TEMAS AVANZADC/!, EN INGENJER!A DEL SOFIWARE
caja negra. La caja negra especifica el comportamiento de un sistema o de ur:a

parte de ste. El sistema (o parte de l) responde a estmulos especficos (eventos ..
aplicar un conjunto de reglas de transicin que correlacionan el estmulo con un:
respuesta.
caja de estado. La caja de estado encapsula los datos de estado y servicios (ope
raciones) en una forma anloga a los objetos. En esta visin de especificacin s..
representan las entradas a la caja de estado (estmulos) y las salidas (respuestas) . L.
caja de estado tambin representa la "historia de estimulo" de la caja negra, esto es
los datos encapsulados en la caja de estado que deben conservarse entre las transiciones implicadas.
Caja transparente. Las funciones de transicin que implica la caja de estado se
definen en la caja transparente. Enunciado de manera simple, una caja transparente contiene el diseo de procedimiento para la caja de estado.
La figura 29.2 ilustra el enfoque de refinamiento empleando la especificacin de
~,
fol
C~VE
El refinamiento de lo
Clrructuro de COIOl Ylo
veficocin de lo
cooecn ocurren
simultneamente.
estructura de cajas. Una caja negra (CN 1) define respuestas para un conjunto completo de estmulos. CN 1 se puede refinar en un conjunto de cajas negras, CN 1 1 hasta
CN 1 n, cada una de las cuales aborda una clase de comportamiento. El refinamiento
contina hasta que se identifica una clase cohesiva de comportamiento (por ejem
plo, CN 1 1.1). Entonces se define una caja de estado (CE 1 1.1) para la caja negra (CN 1 1 ,
En este caso, CE 1 1 1 contiene todos los datos y servicios que se requieren para implementar el comportamiento que define CNu 1- Finalmente, CE1 11 se refina en cajas
transparentes (CT 1 1 u,) y se especifican los detalles de diseo del procedimiento.
Conforme ocurre cada uno de estos pasos de refinamiento, tambin ocurre la
verificacin de la correccin. Las especificaciones de caja de estado se verifican para
UM/fti
CT11.1 . 1
Refincunlento
de estructura
de cajas.
CE1.1 1
CT1.1 .1.3
865
CAPITULO 29 INGENIERA DEL S0f'1"WAJ1E DE SALA LIMPIA
Uhlffi
Especificacin
de caja negra.
s---
f:S* _.R
---- R
garantizar que cada uno concuerda con el comportamiento definido por la especificacin padre de caja negra. De igual modo, las especificaciones de caja transparente se verifican contra la caja de estado padre.
se debe notar que los mtodos de especificacin basados en lenguajes como OCL
o z (captulo 28) es posible usarlos en conjuncin con el enfoque de especificacin
de estructura de cajas. El nico requisito es que cada grado de especificacin sea
verificable formalmente.
29.2.1
Especificacin de caja negra
una especificacin de caja negra describe una abstraccin, estmulos y respuesta

mediante la notacin mostrada en la figura 29.3 [MIL88J. La funcin/se aplica a una
sucesin, S*, de entradas (estmulos), s, y las transforma en una salida (respuesta),
R. Respecto a componentes de software simples/puede ser una funcin matemti-
ca, pero, en general.Jse describe usando lenguaje natural (o un lenguaje formal de

especificacin).
Muchos de los conceptos introducidos para los sistemas orientados a objetos
tambin son aplicables respecto de la caja negra. Las abstracciones de datos y las
operaciones que manipulan dichas abstracciones las encapsula la caja negra. Al
igual que una jerarqua de clase, la especificacin de caja negra puede exhibir el uso
de jerarquas en las cuales las cajas de nivel inferior heredan las propiedades de
cajas superiores en la estructura de rbol.
iiMJffi
Especificacin
de caja de
estado.
E,k>do
1
1
1
1
1
Co jo negro . g
h
1
1
1
1
1
PARTE CINCO
TEMAS AVANZAOOS EN INGENJERA DEL SOFTWARE
29.2.2 Especificacin de caJa de estado

La caja de estado es "una generalizacin simple de una mquina de estado" [MIL88)
Si se recuerda la descripcin del modelado de comportamiento y los diagramas de
estado del captulo 8, un estado es algn modo observable de comportamiento del
sistema. Conforme ocurren los procesamientos, un sistema responde a los eventos
(estmulos) mediante la realizacin de transiciones desde el estado actual hasta cierto estado nuevo. Conforme se realiza la transicin es posible que ocurra una accin.
La caja de estado utiliza una abstraccin de datos para determinar la transicin

hacia el siguiente estado y la accin (respuesta) que ocurrir como consecuencia de
la transicin.
Segn se muestra en la figura 29.4, la caja de estado incorpora una caja negra. El
estmulo, S, que ingresa a la caja negra llega desde alguna fuente externa y un conjunto de estados internos del sistema, T. Milis [MIL88) proporciona una descripcin
matemtica de la funcin,!, de la caja negra contenida dentro de la caja de estado:
g:S*XT*~RXT
donde ges una subfuncin ligada a un estado especfico, t. Cuando se consideran en

conjunto, los pares de subfunciones de estado (t, g) definen la funcin J de caja
negra.
29.2.3 Especificacin de caja transparente

La especificacin de caja transparente est cercanamente relacionada con el diseo
de procedimientos y la programacin estructurada (captulo 11). En esencia, la subfuncin g dentro de la caja de estado se sustituye con las estructuras de programa-
cin estructurada que implementa g.

como ejemplo, considrese la caja transparente que se muestra en la figura 29.5.
La caja negra, g, de la figura 29.4 se sustituye con una sucesin de estructuras que
incorpora una condicional. Estas estructuras, a su vez, se refinan en cajas transparentes de nivel inferior conforme procede el refinamiento en niveles.
iiM+itii
Especificacin
de caja
trcmsparente.
CAPTULO 29
INGENIERA DEL SOITNARE DE SALA LIMPIA
867
Es importante observar que puede demostrarse la correccin de la especificacin

de procedimiento descrita en la jerarqua de caja transparente. Este tema se considera en la seccin siguiente.
El enfoque de diseo utilizado en la ingeniera del software de sala limpia utiliza con
amplitud la filosofia de programacin estructurada. Pero, en este caso, la programacin estructurada se aplica mucho ms rigurosamente.
Las funciones de procesamiento bsico (descritas durante las primeras etapas del
refinamiento de la especificacin) se refinan utilizando una "expansin progresiva
de funciones matemticas en estructuras de conectivos lgicos [por ejemplo, if-thenelse] y subfunciones, donde la expansin [se] realiza hasta que todas las subfunciones identificadas puedan establecerse directamente en el lenguaje de programacin
usado para la implementacin" [DYE92]
El enfoque de programacin estructurada se emplea con eficacia para refinar la
funcin, pero qu hay acerca del diseo? Aqu se involucran varios conceptos fundamentales de diseo (captulos s y 9). Los datos de programa se encapsulan como
un conjunto de abstracciones que atienden las subfunciones. Los conceptos de encapsulado de datos, ocultamiento de informacin y clasificacin de datos se aprovechan para crear el diseo de datos.
29.3.1
~Qu ,ondl
<iones son
apli,ables para
probar q son
'oclecuadas las
estrudll'as
estruduradas?
Reftncuniento y verUicacin del diseo
Cada especificacin de caja transparente representa el diseo de un procedimiento

(subfuncin) necesario para lograr una transicin de caja de estado. Con la caja
transparente las estructuras de programacin estructurada y el refinamiento progresivo se utilizan como se ilustra en la figura 29.6. una funcin de programa.!, se refina en una sucesin de subfuncionesgy h. stas, a su vez, se refinan en estructuras
condicionales (if-then-else y do-while). El refinamiento adicional ilustra la continuacin del refinamiento lgico.
En cada nivel de refinamiento el equipo de sala limpia2 realiza una verificacin
formal de correccin. Esto se logra anexando un conjunto de condiciones de correccin genricas a las estructuras de programacin estructurada. Si una funcin f se
expande en una sucesin g y h, la condicin de correccin para cualquier entrada a
fes
g seguida de h hacef?
Cuando una funcin p se refina en un condicional de la forma if <e> then q, else r
(si <e> entonces q. de otro modo!), la condicin de correccin para cualquier entrada ap es
2
Puesto que el equipo completo est invotucrado en el proceso de verificacin, es menos probable
que se cometa un error al realizar la vericac:i(n
868
PARTE CINCO
TEMAS AVANZAOC/5 EN INGENIERA DEL SOFIWARE
ifrhiili
Refinamiento
progresivo.
Siempre que la condicin <e> es verdadera,
q hace p; y siempre que <e> es
falsa, r hace p?
Si el lector se limito
s6/c a los eslrucluras
eslructurodos
conforme desarrolla
un diseo de procedf
miento, lo pruebo de
coneccin es directo.
Si se violan los eslTuc
turas los pruebas de
coneccin son diffciles
oimposibles.
Cuando la funcin m se refina como un bucle las condiciones de correccin para

cualquier entrada a m son
La terminacin est garantizada?
Siempre que <e> es verdadera, n seguida de m hace m; y siempre que <e>
es falsa, soslayar el bucle todava hace m?
Cada vez que una caja transparente se refina al siguiente nivel de detalle se aplican
dichas condiciones de correccin.
Es importante sealar que la utilizacin de estructuras de programacin estructurada restringe el nmero de pruebas de correccin que se deben realizar. Una sola
condicin se verifica para las sucesiones; dos condiciones se prueban para if-thenelse; y tres condiciones se verifican para los bucles.
La verificacin de correccin de un diseo de procedimiento se ilustra empleando un ejemplo simple que introdujeron Linger, Milis y Witt [LIN79]. El objetivo es
disear y verificar un pequeo programa que encuentra la parte entera, y, de una
CAPTULO 29 INGENIERA DEI. SOF"TWARE DE SALA LIMPIA
iif P.ffP
869
sqrt
r-------- --------.- ~------~~~..,
Clculo de la
parte entera
1
1
1
1
de una raz
cuadrada
[UN79].
y :=0
1
1
1
1
l
raz cuadrada de un entero dado, x. El diseo de procedimiento se representa en la
figura 29. 7 empleando el diagrama de flujo.

verificar la correccin de este diseo requiere definir las condiciones de entrada
y salida como se indica en la figura 29.8. La condicin de entrada advierte que x debe
ser mayor que o igual a O. La condicin de salida requiere que x permanezca inalterada y que y satisfaga la expresin indicada en la figura. Probar la correccin del
diseo requiere comprobar que, en todos los casos, son verdaderas las condiciones
inicio, bucle, cuenta, s y salida que se muestran en la figura 29.8. En ocasiones, a
stas se les llama subpruebas:
l. La condicin inicio demanda que [x 2: O e y = O]. Con base en los requisitos del
problema se supone que la condicin de entrada es correcta. 3 En consecuencia,
se satisface la primera parte de la condicin inicio,x 2: o. segn el diagrama de
flujo, el enunciado que precede inmediatamente a la condicin inicio establece
y = o. Por lo tanto, la segunda parte de la condicin inicio tambin se satisface.
En consecuencia, inicio es verdadera.
&'
cfAvE
Probar que un diseo

es correcto requiere,
primero, identificar
todos los condiciones y
luego probar que codo
uno tomo el valor
booleano adecuado. A
estos condiciones se
les llamo subpruebos.
2. La condicin bucle se puede encontrar en una de dos formas posibles: 1) directamente a partir de inicio (en este caso, la condicin bucle se satisface directamente) o por medio del flujo de control que pasa a travs de la condicin
cuenta. Dado que la condicin cuenta es idntica a la condicin bucle, bucle es
verdadera sin importar la trayectoria de flujo que conduce a ella.
En este contexto, un valor negativo para la ratt cuadrada no tiene significado.
870
PARTE CINCO TEMAS AVANZAJXJS EN INGENIERA DEL SOFTWARE
ifaihffi:j
sqrt
Prueba de
entrado: [x:.: O)
r - - -- --:-- . . . --- '._""': _____ - -~---:;:--- ;-:---
que el diseo
es correcto.
Diseo con
subpruebas.
1,
1
1
y :=0
1, ..._.........
1
L
'
inicio: (x ~
o, y: oj
----
y:= y+ 1
.
lf---.----------....~- ....-------laiilil
solido: x no cambia y y2 s; x ~ (y+ 1)2
3 . La condicin cuenta se encuentra slo despus de que el valor de y aumenta en
1. Adems, la trayectoria del flujo de control que conduce a cuenta se puede invocar slo si la condicin s tambin es verdadera. Por lo tanto, si (Y+ 1)2 sx,
se sigue que y s x. La condicin cuenta se satisface.
4. La
condicin si se prueba en la lgica condicional mostrada. Por lo tanto, la

condicin s debe ser verdadera cuando el flujo de control se mueve a lo largo
de la trayectoria mostrada.
S . La condicin salida demanda primero que x no haya cambiado. Un examen del

diseo indica que x no aparece en ningn sitio a la izquierda de un operador de
asignacin. No existe llamado de funcin que use x. Por lo tanto, no cambia.
Dado que la prueba condicional (Y + 1)2 s x debe fallar para alcanzar la condicin salida, se sigue que (Y+ 1)2 s x. Adems, la condicin bucle todava debe
ser verdadera (es decir.y s x). En consecuencia, se pueden combinar (y+ 1)2 > x
y y2 s x para satisfacer la condicin salida.
Adems se debe garantizar que el bucle termina. Un examen de la condicin bucle
indica que, puesto que y aumenta y x ~ O, el bucle a la larga debe terminar.
Los cinco pasos apenas anotados prueban la correccin del diseo del algoritmo
indis;ado en la figura 29.7. Ahora se tiene certeza de que el diseo, de hecho, calcular la parte entera de una raiz cuadrada.
Es posible emplear un enfoque matemtico ms riguroso en el diseo de la verificacin. Sin embargo, una exposicin de este tema rebasa el mbito de este libro.
Los lectores interesados pueden consultar [LIN79J.
CAPTULO 29
Qu S8
gana al rea
Izar pn,ebas de
correccin?
871
!NGENIERlA DEL SOFTWARE DE SALA LIMPIA
29.3.2 Ventajas de la verificacin del diseo4

La verificacin rigurosa de la correccin de cada refinamiento del diseo de la caja
transparente tiene varias ventajas. Llnger [LIN94] las describe de la siguiente forma:
Reducen la verificacin a un proceso finito. La manera secuencial y anidada
en que se organizan las estructuras de control en una caja transparente define
con naturalidad una jerarqua que revela las condiciones de correccin que se
deben verificar. Un "axioma de reemplazo" [UN79] permite sustituir las
funciones proyectadas con sus refinamientos de estructura de control en la
jerarqua de las subpruebas. Por ejemplo, la subprueba de la funcin proyectada f1 de la figura 29.9 requiere probar que la composicin de las operaciones g 1 y g2 con la funcin proyectada f2 tiene el mismo efecto sobre los
datos que f1 . Ntese que f2 sustituye todos los detalles de su refinamiento en
la prueba. Esta sustitucin localiza el argumento de prueba con la estructura
de control que se esta estudiando. De hecho, deja que el ingeniero de
software lleve a cabo las pruebas en cualquier orden.
Es imposible sobreestimar el efecto positivo que la reduccin de la verificacin
a un proceso finito tiene sobre la calidad. Aun cuando todos los programas,
excepto los ms triviales,muestren un nmero esencialmente infinito de
trayectorias de ejecucin, pueden verificarse en un nmero finito de pasos.
8ubpl"Uebas:
Diseo con
subpruebas.
f1
[f1]
= [ DO gl: g2 : [f2] END] 'l
DO
gl
g2
[f2]
WHILE
f2
= [WHILE pl DO [f3] END] 7
f3
= [DO g3: [f4]: g8 END]
pl
DO [f3]
g3
[f4]
IF
p2
THEN [f6]
g4
g6
El8E [f8]
g8
f4 = [ IF p2 : THEN [f 6] EL8E [f8] END] 7
rs = [ DO g4: g6 ENO] 7
f8
= [DO g8: g7 END] 'l
g7
ENO
g8
ENO
ENO
4
Esta seccin y las figuras 29. 7 a 29.9 han sido adaptadas de [UN94) y se usaron con permiso.
872
PARTE CINCO
Permiten al equipo de sala limpia verificar cada lnea de diseo y cdigo. Los
Apesar del nmero

extremodomente
grande de troyectoos
de ejecucin en un
programo, el nmero
de posos poro probar
que el programo es
correcto es bostonte
p01ueo.
equipos pueden realizar la verificacin por medio del anlisis y la discusin

en grupo sobre la base del teorema de correccin, y son capaces de producir
pruebas escritas donde se requiere una confianza adicional en un sistema
crucial para la vida o la misin.
Resultan en un nivel de defecto cercano a cero. Durante una revisin de equipo

se verifica por tumos la condicin de correccin de cada estructura de
control. cada miembro del equipo debe estar de acuerdo en que cada
condicin es correcta, de modo que un error slo es posible si cada miembro
del equipo verifica de manera incorrecta una condicin. El requisito del
acuerdo unnime basado en la verificacin individual genera un software con
pocos o ningn defecto antes de su primera ejecucin.
Es escalable.
Cualquier sistema de software, sin importar cun grande sea,

tiene procedimientos de caja transparente de nivel superior compuestos de
estructuras de sucesin, alternacin e iteracin. Cada una de ellas usualmente
invoca un gran subsistema con miles de lneas de cdigo, y cada uno de
dichos subsistemas tiene sus propios procedimientos y funciones proyectadas
de nivel superior. De modo que las condiciones de correccin para tales
estructuras de nivel superior se verifican en la misma forma que las estructuras de nivel inferior. La verificacin en niveles superiores puede tomar, y
vale la pena, ms tiempo, pero no requiere ms teora.
Produce mejor cdigo que la prueba unitaria. La prueba unitaria verifica los
efectos de ejecutar slo las trayectorias de prueba seleccionadas entre

muchas trayectorias posibles. Al basar la verificacin en la teora de
funciones, el enfoque de sala limpia puede verificar cualquier efecto posible
sobre todos los datos porque, mientras un programa puede tener muchas
trayectorias de ejecucin, slo tiene una funcin. La verificacin tambin es
ms eficiente que la prueba unitaria. La mayora de las condiciones de verificacin se puede comprobar en unos cuantos minutos, pero las pruebas
unitarias requieren un tiempo sustancial en su preparacin, ejecucin y
comprobacin.
Es importante advertir que la verificacin del diseo debe, a final de cuentas, aplicarse al propio cdigo fuente. En este contexto, con frecuencia se le llama verifica-
cin de la correccin.
La estrategia y las tcticas de las pruebas de sala limpia son fundamentalmente dife-
rentes de los enfoques de prueba convencionales. Los mtodos convencionales

generan un conjunto de casos de prueba para descubrir errores de diseo y codificacin. La meta de las pruebas de sala limpia es validar los requisitos de software
CAPTULO 29 INGENIERA DEL SOFTWARE DE SALA LIMPlA
873
demostrando que una muestra estadstica de casos de uso (captulo 7) se ha ejecutado exitosamente.
29.4.1
mosinosees
mdario del enfoque
de solo limpio, vale lo
11]/IO considerar los
:ruebos estad/sticos
utilizacin como
:ate integral de su
estrategia de pruebas.
Pruebas estadsticas de uso
El usuario de un programa de computadora rara vez necesita entender los detalles

tcnicos del diseo. El comportamiento del programa que ve el usuario lo alimentan
entradas y eventos que con frecuencia l mismo produce. Pero, en los sistemas complejos, el posible espectro de entradas y eventos (es decir, los casos de uso) tal vez
sea extremadamente amplio. Qu subconjunto de casos de uso verificar adecuadamente el comportamiento del programa? Esta es la primera pregunta que aborda
la prueba estadstica de uso.
La prueba estadstica de uso "equivale a probar el software en la forma que los
usuarios intentarian usarlo" [LIN94]. Esto se logra si los equipos de prueba de sala
limpia (tambin llamados equipos de certificacin) determinan una distribucin de
probabilidad de uso para el software. La especificacin (caja negra) de cada incremento del software se analiza para definir un conjunto de estmulos (entradas o
eventos) que provocan el cambio de comportamiento del software. con base en
entrevistas con usuarios potenciales, la creacin de escenarios de uso y una comprensin general del dominio de la aplicacin, se asigna una probabilidad de uso a
cada estimulo.
Los casos de prueba se generan para cada conjunto de estimulos5 de acuerdo con
la distribucin de probabilidad de uso. Con fines ilustrativos, considrese el sistema
HogarSeguro estudiado previamente en este libro. La ingeniera del software de sala
limpia se aplica en el desarrollo de un incremento de software que gestiona la interaccin del usuario con el teclado numrico del sistema de seguridad. Respecto de
este incremento se han identificado cinco estmulos. El anlisis indica el porcentaje
de distribucin de probabilidad de cada estmulo. Con el fin simplificar la seleccin
de los casos de prueba dichas probabilidades estn se correlacionan con los intervalos numerados entre 1 y 99 [LIN94] y se ilustran en la tabla siguiente:
Estmulo del programa
Probabilidad
Habilitar/deshabilitar (HD)
Prueba [P)
50%
15%
15%
15%
Alarma(A)
5%
Fijar zona (FZ)

Consulta (C)
Intervalo
1-49
50-63
64-78
79-94
95-99
5 Es posible utilizar herramientas automatizadas para lograr esto Vase [DYE92Jpara mayor informacin.
874
PARTE CINCO
TEMAS AVANlAJXJS EN INGENIERIA DEL SOF'JWARE
Crear una sucesin de casos de prueba de uso que concuerde con la distribucin
de probabilidad de uso requiere generar nmeros aleatorios entre 1 y 99. Cada
nmero aleatorio corresponde a un intervalo en la distribucin de probabilidad precedente. Por lo tanto, la secuencia de casos de prueba de uso se define aleatoriamente, pero corresponde a la probabilidad correspondiente de presencia de estmulos
Por ejemplo, supngase que se generan las siguientes secuencias de nmeros aleatorios:
l 3-94-22-24-45-56
81-19-31-69-45-9
38-21-52-84-86-4
Al seleccionar los estmulos apropiados con base en el intervalo de distribucin que
se muestra en la tabla se derivan los casos de uso siguientes:
HD-P-HD-HO-HD-FZ
P-HO-HD-C-HD-HD
HD-HD-FZ-P-P-HD
El equipo de prueba ejecuta estos casos de uso y verifica el comportamiento del software frente a la especificacin del sistema. El tiempo para las pruebas se registra de
modo que sea posible determinar los tiempos de intervalo. Al usar tiempos de intervalo, el equipo de certificacin tiene la posibilidad de calcular el tiempo medio entre
fallas (TMEF). Si se lleva a cabo una larga secuencia de pruebas sin fallas, el TMEF
es bajo y es probable que la fiabilidad del software sea alta.
29.4.2 CerWicacin
Las tcnicas de verificacin y prueba ya descritas en este captulo llevan a componentes de software (e incrementos completos) que pueden certificarse. En el contexto del enfoque de ingeniera del software de sala limpia la certificacin implica
que la fiabilidad (medida en TMEF) se especifica para cada componente.
El impacto potencial de los componentes de software certificables va mucho ms
all de un solo proyecto de sala limpia. Los componentes de software reutilizables
se pueden almacenar junto con sus escenarios de uso, estmulos de programa y distribuciones de probabilidad. Cada componente tendra una fiabilidad certificada en
el escenario de uso y el rgimen de pruebas descritos. Esta informacin es invaluable para otros que intenten emplear los componentes.
El enfoque de la certificacin involucra cinco pasos [WOH94]:
1. Creacin de escenarios de uso.

2 . Especificacin de perfiles de uso.
Cmo se
3 . Generacin de casos de prueba a partir del perfil.
<erfitKG 1ft
"' ...... ele
4 . Ejecucin de pruebas y registro y anlisis de datos de fallas.
saftware?
5 . Clculo y certificacin de la fiabilidad.
CAPrruLO 29 INGENIERA DEL SOITWA.IZE DE SALA LIMPIA
875
Los pasos del l al 4 se han tratado en una seccin anterior. Esta seccin se concentrar en la certificacin de la fiabilidad.
La certificacin para la ingeniera del software de sala limpia requiere la creacin
de tres modelos [P0093J:
Modelo de muestreo. La prueba del software ejecuta m casos de prueba aleatorios y se certifica si no ocurren fallas o un nmero especfico de stas. El valor de
m se deriva matemticamente para asegurar que se logra la fiabilidad requerida.
Modelo de componentes. Se certificar un sistema compuesto de n componentes. El modelo de componentes permite que el analista determine la probabilidad
de que el componente i fallar antes de completarse.
Modelo de certificacin. La fiabilidad global del sistema se proyecta y certifica.
En el momento de completar las pruebas estadsticas de uso el equipo de certificacin tiene la informacin necesaria para entregar el software que tiene un TMEF
certificado, el cual se calcula empleando cada uno de dichos modelos.
Una descripcin detallada del clculo de los modelos de muestreo, componentes y
certificacin est ms all del mbito de este libro. El lector interesado hallar detalles adicionales en [MUS87J, [CUR86J y [P0093].
La ingenieria del software de sala limpia es un enfoque formal para el desarrollo de

software que puede llevar a software con calidad notablemente alta. Utiliza la especificacin de estructura de cajas (o mtodos formales) para el modelado de anlisis
y diseo y resalta la verificacin de la correccin, en lugar de las pruebas, como el
principal mecanismo para detectar y eliminar los errores. Se aplican pruebas estadsticas de utilizacin para desarrollar la informacin necesaria de tasa de fallas con
que certificar la fiabilidad del software entregado.
El enfoque de sala limpia comienza con los modelos de anlisis y diseo que utilizan una representacin en estructura de cajas. Una "caja" encapsula el sistema (o
algn aspecto de l) en un grado especfico de abstraccin. Las cajas negras se aprovechan para representar el comportamiento de un sistema observable de manera
externa. Las cajas de estado encapsulan datos y operaciones de estado. Una caja
transparente se emplea en el modelado del diseo de procedimiento que implican
los datos y operaciones de una caja de estado.
La verificacin de la correccin se aplica cuando se completa el diseo de la
estructura de cajas. El diseo de procedimiento para un componente de software se
divide en una serie de subfunciones. La prueba de la correccin de las subfunciones
requiere definir condiciones de salida para cada subfuncin y se aplica un conjunto
de subpruebas. Si cada condicin de salida se satisface el diseo debe ser correcto.
876
PARTE CINCO
TEMAS AVANl.AI:XYS EN INGENIERA DEL SOFTWARE
Una vez completada la verificacin de la correccin comienza la prueba estadstica de uso. A diferencia de tas pruebas convencionales, la ingeniera del software de
sala limpia no subraya la importancia de las pruebas unitarias o de integracin. En
vez de ello el software se prueba definiendo un conjunto de escenarios de uso
determinando la probabilidad de uso para cada escenario y definiendo entonces las
pruebas aleatorias que concuerden con las probabilidades. Los registros de error
resultantes se combinan con los modelos de muestreo, componentes y certificaciP
para pennitir el clculo matemtico de la fiabilidad proyectada respecto al componente de software.
La filosofa de sala limpia es un enfoque riguroso para la ingeniera del software.
Es un modelo de proceso de software que destaca la verificacin matemtica de la

correccin y la certificacin de la fiabilidad del software. La lnea fundamental es las
tasas de falla extremadamente bajas que serian difciles o imposibles de lograr
empleando mtodos menos formales.
[CUR86] Currit, P. A., M. Dyer y H. D. Milis, "Certifying the Reliability of Software", en IEEE n-ans.
Software Engineering, vol. SE- 12, nm. 1, enero de 1994.
[DYE92J Dyer, M., The Cleanroom Approach to Quality Software Development, Wiley, 1992.
[HAU94] Hausler, P. A., R. Linger y C. Trammel, "Adopting Cleanroom Software Engineering w ith
a Phased Approach", en fBM Systemsfourna/, vol. 33, nm. 1, enero de 1994, pp. 89-109.
[HEN95J Henderson, J., "Why isn't Cleanroom the Universal Software Development Methodology", en Crosstalk, vol. 8, nm. 5, mayo de 1995, pp. 11 - 14.
tHEV93J Hevne r, A . R., y H. o. Milis, "Box Structure Methods for system Development with Objects", en IBM Systems Joumal, vol. 31, nm. 2, febrero de 1993, pp. 232-251.
[LIN79] Linger, R. M., H. D. Milis y B. l. Witt, Structured Programming: Theory and Practice, Addison-Westey, 1979.
[LIN881 Lingcr, R.M., y H. D. Mills, "A Case Study in Cleanroom Software Engineering: The IBM
COBOL Structuring Facility", Proc. COMPSAC '88, Chicago, octubre de 1988.
[UN94J Linger, R., "Cleanroom Process Model", en IEEE Software, vol. 11, nm. 2, marzo de 1994,
pp. 50-58.
[MIL87J Mlls, H. o., M . Dyer y R. Linger, "Cleanroom Software Engineering", en fEEE Software,
vol. 4, nm. 5, septiembre de 1987, pp. 19- 24.
[MIL88J Milis, H. D., "Stepwise Refinement and Verification in Box Structured Systems", en Com puter, vol. 21, nm. 6, junio de 1988, pp. 23-35.
[MUS87J Musa. J. D, A lannino y K. Okumoto, Engineering and Managing Software with Reliability Measures, McGraw-Hill, 1987.
[P0088J Poore, J. H., y H. D. Milis, "Bringing Software Under Statistical Quality Control", en Quality Progress, noviembre de 1988, pp. 52-55.
[P00931 Poore, J. H., H. D. Milis y o. Mutchler, "Planning and Certifying Software System Reliability", en IEEE Software, vol. 10, nm. 1, enero de 1993, pp. 88-99.
1WOH94J Wohiin, C., y P. Runeson, "Certification of Software Components", en IEEE Trans. Software Engineerng, vol. SE- 20, nm. 6, junio de 1994, pp. 494-499.
29. l. Si se tuviese que elegir un aspecto de la ingeniera del software de sala limpia que la
hiciese radicalmente diferente de los enfoques convencionales de .ingeniera de software, cul
sera?
CAPITULO 29
INGENU:RlA
oa. sorr.v.ARE m
SALA LIMPIA
877
29.2 . Cmo trabajan en conjunto un modelo de proceso incremental y la certificacin para

producir software de alta calidad?
29.3 . Empleando la especificacin de estructura de cajas desarrllense modelos de anlisis "de
primer paso" y de diseo para el sistema HogarSeguro
29.4. Desarrllese una especificacin de estructura de cajas para una porcin del sistema
PHTRS presentado en el problema 8 .10
29.5 . Un algoritmo de ordenamiento en burbuja se define del modo siguiente:
procedure bubblesort;
var i , t, integer;
begin
repeat until t = a(l)
t: = a(l):
for j: = 2 to n do
a U- 1) > aUJ then begin
t: = aU- IJ;
aU- 1): = aUJ;
aUJ : = t;
end
endrep
end
Dividase el diseo en subfunciones y definase un conunto de condiciones que permitman probar que este algoritmo es correcto.
29.6 . Documntese una prueba de verificacin de correccin para el ordenamiento en burbuja tratado en el problema 29.5.
29. 7 . Seleccinese un componente de programa que se haya diseado en otro contexto (o uno
que haya asignado el instructor) y desarrllese respecto de l una prueba completa de correccin.
29.8 . Seleccinese un programa que se use regularmente (por ejemplo, un gestor de correo
electrnico, un procesador de palabra, un programa de hojas de clculo) y crese un conjunto
de escenarios de uso para el programa. Definase la probabilidad de uso para cada escenario y
luego desarrllese una tabla de estmulos de programa y de distribucin de probabilidad similar al que se muestra en la seccin 29.4.1.
29.9 . Para la tabla de estmulos de programa y distribucin de probabilidad desarrollada en el
problema 29.8, utilicese un generador de nmeros aleatorios con el fin de desarrollar un conj unto de casos de prueba para emplearlo en pruebas estadsticas de uso.
29.1 O. Con palabras propias, descnbase el intento de certificacin en el contexto de ingeniera
del software de sala limpia.
Prowell et al. (Cleanroom Software Engineenng Technology and Process, Addison-Wesley, 1999)
ofrecen un tratamiento detallado de los aspectos importantes del enfoque de sala limpia. Poore
y Trammell (Cleanroom Software Engmeering A Reader, Blackwell Publishing, 1996) han editado
exposiciones tiles de temas de sala limpia Becker y Wh1ttaker (Cleanroom Software Engmeering
Procaces, Idea Group Publishing, 1996) presentan un excelente panorama para quienes no estn
familiarizados con las prcticas de sala hrnp1a
The Cleanroom Pamphlet (Soflware Technology Support Center, Hill AFBase, abril de 1995) contiene reimpresiones de varios artculos importantes u, er (UN94J produjo una de las mejores
introducciones a la materia. El Data and Ana})'SlS Center ,r Soflware (DACS) (www.dacs.dtic.mil)
ofrece muchos artculos tiles, libros guia y otras fuenl ~ de informacin acerca de la ingenie
ra del software de sala limpia
878
PARTE CINCO TEMAS AVAN'ZADOS EN INGENIERiA DEL SOF1WME

Linger y Trammell ("Cleanroom Software E.ngineering Reference Model", SEi Technicai.
Report CMU/SEl-96-TR-022, 1996) han definido un conjunto de 14 procesos de sala limpia y 2C
productos de trabajo que forman la base para la SEi CMM de la ingenierfa de software de sala
limpia (CMU/SEI-96-TR-023).
Michael Deck de Cleanroom Software Engineering (www.cleansoft.com) ha preparado una
bibliografia acerca de temas de sala limpia. Muchos estn disponibles en formato descargable.
La verificacin del diseo mediante la prueba de las correcciones se encuentra en el centro
del enfoque de sala limpia. Los libros de Stavely (Toward Zero-Defect Software, Addison-Wesley
1998), Baber (Error Free Software, Wiley, 1991) y Schulmeyer (Zero Defect Sofl.ware, McGraw-Hill.
1990) abordan la prueba de correccin en forma muy detallada.
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de la ingenierla del software de sala limpia Una lista actualizada de referencias en la World Wide Web se
puede encontrar en el sitio Web SEPA:
INGEN IERA DEL SOFTWARE

BASADA EN COMPONENTES
CONCl:PTOS
CLAVE
odaptQdoll .888
(lllitic.'CICin $87
doslfkodon .892
D8C .3'6
entorao
de ret1tlha6n .894
ilgeliericJ
del dominio ...883

rsac . 879
llicldle,vare 890
t<OIOllia 805
proceso ..... .&$?
pantos
de esttldura 897
tipos de
<OlllpOl.l!ll ttS 881
n el contexto de la ingeniera del software la reutllzacin es una :idea tanto antigua como nueva. Los programadores han reutilizado ide<J.s, abstracciones y procesos desde los primeros das de la computacin, pero el
enfoque original para la reutilizacin era especfico. En la actualidad. los Complejos siste~as de alta calidad basados en computadoras se d,eben construir en
un tiempo muy corto y demanda un enfoque ms organizad de la reutihzacln.
La ingcnfc((a del software basada en componentes (lSBC) es un proceso qte
concede particular importancia al diseo y la construccin de sistemas basados
en computadoras que utilizan "componentes" <le software reutilizables. Cle~
ments {CLE95] describe asI la ISBC:

{la JSBCJ est cambiando la fonna en que se desanoUan lo$ grandes sistemas de software. (La ISBCJ encama la filosofla de "comprar, no construir'' de la cual son partidatios.Fred Brooks y otros. J;:n ta misma forma como las primeras subrutinas liberaron
al programador de pensar acerca de los- dtalles, Jla ISBCJ cambi el inters de programar software por el de componer sistemas de software. La implementacin ha dado paso a la Integracin corno cenlro del entbque. En sus cimientos est la suposicin
de que existe suficiente base comn entre muchos grandes sistemas de software para justificar el desarrollo de componentes reuliliz-ables para ex:p1otatla y satisfacerla.
,1'
Pero surgen varias preguntas. Es posible <;onstruir siSt-emas complejos mediante el ensamblado de componentes de software reutilizables proveQientes de
un catlogo? Esto se puede lograr en una forma eficaz tanto en costo como en
tiempo? Es posible es~blecer incentivos adecuados que alienten a los Ingenie~
ros de software a reutilizar en vez de reinventar? Los gestores tienen buena
disposicin para incurrir en el gasto adicional asociado con la creacin de componentes de software reutilizables? La biblioteca de. componentes es necesaria
para lograr que la reutilizacin se cree en una forma que $ea accesible a que
nes la necesitan? Los componentes que existen pueden encontrarlos quienes .
los necesiten?
880
PARTE CINCO
TEMAS AVANZATXYS EN INGENIERA DEL SOF'IWARE
Incluso en la actualidad, los ingenieros de software luchan con stas y otras preguntas acerca de la reutilizacin de componentes de software. En este captulo se
abordan algunas de las respuestas.
HHI i:ifr6V1
lnfonnoci6i\ id~m
delSBClJOIQ~
58 puede-- 8ft
. ...c.......
En la superficie, la ISBC parece bastante similar a la ingeniera del software orientada a objetos convencional. El proceso comienza cuando un equipo de software
establece requisitos para el sistema que se construir mediante tcnicas convencionales de investigacin de requisitos (captulo 7). Se establece un diseo arquitectnico (captulo 10), pero en lugar de dirigirse inmediatamente hacia tareas de diseo
ms detalladas, el equipo examina los requisitos para determinar qu subconjunto
est directamente dispuesto para la composicin, y no para la construccin. Es decir,
el equipo plantea las siguientes preguntas para cada requisito del sistema:
CAPTULO 30 INGENlElllA DEL SOf7WAIZE BASADA EN OOMPONENTES
881
Hay componentes comerciales de lnea (CDL) disponibles para implementar

los requisitos?
Hay disponibles componentes reutilizables desarrollados internamente para
implementar los requisitos?
Las interfases para los componentes disponibles son compatibles dentro de
la arquitectura del sistema que se construir?
El equipo tal vez intente modificar o eliminar aquellos requisitos del sistema que
no sea posible implementar con CDL o de desarrollo propio 1. Si el requisito no puede cambiarse o eliminarse se aplican los mtodos de ingeniera del software en la
construccin de aquellos nuevos componentes que deben desarrollarse para satisfacer los requisitos. Pero para los requisitos que se abordan con los componentes disponibles comienza un conjunto diferente de actividades de ingeniera del software:
cualificacin, adaptacin, composicin y actualizacin. Cada una de estas actividades de ISBC se examina con mayor detalle en la seccin 30.4.
En la primera parte de esta seccin se ha utilizado repetidamente el trmino componente, aunque falta una descripcin definitiva del trmino. Brown y Wallnau
[BR096J sugieren las siguientes posibilidades:
Componente: parte importante, casi independiente y reemplazable de un sistema que satisface una funcin clara en el contexto de una arquitectura bien
definida.
Componente del software en ejecucin: paquete dinmico de unin de uno o

ms programas gestionados como unidad y a los cuales se tiene acceso por
medio de interfases documentadas que se pueden descubrir en la ejecucin.
Componente de software: unidad de composicin que slo tiene dependencias

de contexto explcitas y especificadas en forma contractual.
Componente de negocio: la implementacin de software de un concepto o proceso de negocio "autnomo".

Adems de estas descripciones, los componentes de software tambin se pueden caracterizar con base en sus aplicaciones en el proceso de ISBC. Adems de los componentes CDL, el proceso de ISBC produce:
Componentes cualificados: evaluados por ingenieros de software para garantizar que no slo la funcionalidad, sino el desempeo, la fiabilidad, la facilidad
de uso y otros factores de calidad (captulo 26) concuerdan con los requisitos
del sistema o producto que se construir.
1 La implicacin es que la organizacin ajusta los requisitos de su negocio o producto de modo que
la implementacin basada en componentes se conS1ga sm que sea necesaria la ingenieria de personalizacin. Este enfoque reduce los costos y mqora el tiempo en que el producto llega al mercado,
pero no siempre es posible.
PARTE CINCO
882
TEMAS AVANZATX)S EN INGENIERA DEL SOFIWARE
Componentes adaptados: adaptados para modificar (accin tambin llamada et'mascarar o envolver) (BR096] caractersticas que no se requieren o indeseables
Componentes actualizados: sustituyen el software existente conforme estn
disponibles las nuevas versiones de los componentes.
El proceso de JSBC se caracteriza de tal forma que no slo identifica los componentes candidatos sino que tambin cualifica la interfaz de cada componente, adapta los
componentes para eliminar las equivocaciones arquitectnicas, ensambla los componentes en un estilo arquitectnico seleccionado y actualiza los componentes conforme los requisitos del sistema cambian [BR096). El modelo de proceso para la
ingeniera del software basada en componentes destaca las pistas paralelas en las
cuales la ingeniera del dominio (seccin 30.3) se lleva a cabo concurrentemente con
el desarrollo basado en componentes.
La figura 30.1 ilustra un modelo de proceso tpico que explicitamente acopla la
ISBC [CHR95J. La ingeniera del dominio crea un modelo del dominio de aplicacin
que se utiliza como base para analizar los requisitos del usuario en el flujo de ingeniera del software. Una arquitectura genrica de software proporciona la entrada
para el diseo de la aplicacin. Finalmente, despus de que los componentes reutilizables se han comprado, seleccionado de bibliotecas existentes o construido (co-
Modelo
MH.fdeti
proceso que
gpoya la
ISDC .
Depsito de
arteactos/
componentes
reutilizables
Anlisis
arquitectnico
CAPTULO 30 INGENIERiA DEL SOFTWARE BASADA EN COMPONENTES
883
mo parte de la ingeniera del dominio), estn disponibles para los ingenieros de software durante el desarrollo basado en componentes.
Los pasos de anlisis y diseo arquitectnico definidos como parte del desarrollo
basado en componentes (figura 30.1) se pueden implementar en el contexto de un paradigma de diseo abstracto (ADP, por sus siglas en ingls) [D0G03J. un ADP implica
que el modelo global del software -representado como datos, funciones y comportamiento (control)- se puede descomponer jerrquicamente. Conforme la descomposicin comienza, el sistema se representa como una coleccin de marcos de trabajo arquitectnico, cada uno compuesto de uno o ms patrones de diseo (captulo 10). Un refinamiento mayor identifica los componentes necesarios para crear cada patrn de diseo. En un contexto ideal, todos los componentes se adquiriran a
partir de un depsito (aplicando actividades de calificacin, adaptacin y composicin
de componentes). Cuando se requieren componentes especializados se aplica la ingeniera de componentes.
La finalidad de la ingeniera del dominio es identificar, construir, catalogar y disemi-
nar un conjunto de componentes de software que sean aplicables para el software

existente y futuro en un dominio de aplicacin particular. La meta global es establecer mecanismos que les permitan a los ingenieros de software compartir dichos
componentes -para reutilizarlos- durante el trabajo en sistemas nuevos y existentes. La ingeniera del dominio incluye tres grandes actividades: anlisis, construccin
y diseminacin.
1AI ....lo del dominio tnrto de eocontror los aspectos comunes entre los sistemas. poro identificar lS (Ol1lpOIJIIIM
. . posllile aplica, en muchos sistemas, y poro identificar familias de progromos que se posiclollet *t sacar lt
~ _,,.dedithoscomponentes.
El proceso de anlisis
estudiado en esto se<
cin se enfoco en los
componentes reutilizables. Sin embargo, el
anlisis de sistemos
COL completos (por
ejemplo, aplicaciones
de comercio eledrnf
co, aplicaciones de ou-tomotizacin de
fuerzo de ventas)
tombin puede ser
una parte del anlisis
del dominio.
Se puede argumentar que "la reutilizacin desaparecer, no por eliminacin, sino

por integracin" en la estructura de la prctica de la ingeniera del software [TRA95].
Como la reutilizacin cada vez tiene mayor auge algunos creen que la ingeniera del
dominio adquirir tanta importancia como la ingeniera del software durante la dcada siguiente.
30.3.1 El proceso de anlisis del dominio

El enfoque global para el anlisis del dominio usualmente se caracteriza en el contexto de la ingeniera del software orientada a objetos. Los pasos en el proceso se
definen como:
1. Definir el dominio que se investigar.

2. Categorizar los elementos extra.idos del dominio.
PARTE CINCO TEMAS AVANZADOS EN INGENIERlA DEL SOFTWARE
884
Qu
componentes
identificados
durante el anhsis
del dominio sern
candidatos para la
reutlhzacin?
3. Recopilar una muestra representativa de las aplicaciones en el dominio.
4. Analizar cada aplicacin en la muestra y definir las clases de anlisis.

5. Desarrollar un modelo de anlisis para las clases.
Es importante advertir que el anlisis del dominio es aplicable a cualquier paradigma de ingeniera del software, y que se puede aplicar al desarrollo convencional y a.
Aunque los pasos citados ofrecen un modelo til para el anlisis del dominio, no
brindan una guia para decidir cules componentes de software son candidatos a la
reutilizacin. Hutchinson y Hindley [HUT88] sugieren el siguiente conjunto de preguntas prcticas como una gua para identificar los componentes de software reutilizables:
En las implementaciones futuras se requiere la funcionalidad del componente?
Cun comn es la funcin del componente dentro del dominio?
Existe duplicidad de la funcin del componente dentro del dominio?
El componente depende del hardware? Si es as, el hardware permanece invariable entre las implementaciones o las especificaciones del hardware pueden trasladarse hacia otro componente?
El diseo est lo suficientemente optimizado para la siguiente implementacin?
se pueden establecer parmetros respecto de un componente no reutilizable
de modo que se vuelva reutilizable?
El componente es reutilizable en muchas implementaciones slo con cambios menores?

Es factible la reutilizacin por medio de la modificacin?
Un componente no reutilizable se puede descomponer para producir componentes reutilizables?
Cun vlida es la descomposicin de un componente para la reutilizacin?
Para informacin adicional acerca del anlisis del dominio vase [ATKOl], [HEIOI] y
[PRI9.3].
30.3.2 Funciones de caracterizacin

A veces es dificil determinar si un componente potencialmente reutilizable es de hecho aplicable en una situacin particular. Esta determinacin requiere definir un
conjunto de caractersticas del dominio que comparta todo el software dentro de un dominio. Una caracterstica del dominio define algn atributo genrico de todos los
productos que existen dentro de l. Por ejemplo, las caractersticas genricas podran incluir la importancia de la seguridad y fiabilidad, el lenguaje de programacin,
la concurrencia en el procesamiento y muchas otras.
CAPiTuJ.O 30 INGENIERA CE!. SOFTWARE BASADA EN COMPONENTES
ffil-llHN','~.
lmlllll!i6it. uai
del Qll($$ del domm
se~ anconlo en
www..- '
tliu/str/ "
. . .llelli/ "
IWoJitnil.
885
Un conjunto de caracterlsticas de dominio de un componente reutilizable se puede representar como (Dp], donde cada elemento, Dpi, en el conjunto representa una
caracterstica especfica del dominio. El valor asignado a Dp, representa una escala
ordinal que indica la relevancia de la caracterstica para el componente p. Una escala tpica [BAS94J podra ser
1: No es relevante si la reutilizacin es apropiada.
2: Relevante slo en circunstancias inusuales.
3: Relevante: el componente se modifica para usarlo, a pesar de las diferencias.
4: Claramente relevante, y si el nuevo software no tiene esta caracterstica, la
reutilizacin ser ineficiente pero tal vez sea posible.

5 : Claramente relevante, y si el nuevo software no tiene esta caracterstica, la
reutilizacin ser ineficiente y la reutilizacin sin dicha caracterstica no se recomienda.
Cuando dentro del dominio de aplicacin se construir nuevo software, w, se deriva
para l un conjunto de caractersticas del dominio. Entonces se comparan Dp, y Dwi
para determinar si el componente existente p se reutiliza con eficacia en la aplicacin w.
Aunque el software que se construir claramente existe dentro de un dominio de
aplicacin, los componentes reutilizables en l se deben analizar para determinar su
aplicabilidad. En algunos casos (con suerte, un nmero limitado), "reinventar la rueda" tal vez sea la mejor eleccin en cuanto a costo.
30.3.3 Modelado estructural y puntos de estructura

Cuando se aplica el anlisis del dominio el analista busca los patrones repetitivos en
las aplicaciones que residen dentro de un dominio. El modelado estructural es un enfoque de ingeniera del dominio basada en patrones que funciona bajo la premisa de
que cualquier dominio de aplicacin tiene patrones repetitivos (de funcin, datos y
comportamiento) que tienen un potencial de reutilizacin.
cada dominio de aplicacin se caracteriza mediante un modelo estructural (por
ejemplo, los sistemas avinicos de las aeronaves difieren enormemente en especificaciones, pero todo el software moderno en este dominio tiene el mismo modelo estructural). Por lo tanto, el modelo estructural es un estilo arquitectnico (captulo 10)
que puede y debe reutilizarse mediante las aplicaciones dentro del dominio.
McMahon (MCM95J describe un punto de estructura como "una estructura distinta dentro de un modelo estructural". Los puntos de estructura tienen tres caractersticas distintas:
Quesn
pllfo ele es
truct,ra y cules
SOlt SIS CCl'adt
'ristkas?
1. Un punto de estructura es una abstraccin que debe tener un nmero limitado

de instancias. Adems. la abstraccin debe recurrir a travs de las aplicaciones en el dominio. De otro modo no se justifica el costo de verificar, documentar y diseminar el punto de estructura.
PARTE CINCO
2. Las reglas que rigen el uso del punto de estructura deben comprenderse con
facilidad. Adems, la interfaz para el punto de estructura debe ser relativamente simple.
3. El punto de estructura debe implementar la ocultacin de informacin al ais-
lar toda la complejidad dentro del mismo punto de estructura. Esto reduce la
complejidad percibida del sistema globales conjunto.
'~
c&v1
Un punto de estructuro
es onlogo oun potrn
de diseo que se puede encontrar repetidomente en oplicociones
con un dominio especfico.
Como un ejemplo de puntos de estructura como patrones arquitectnicos de un sistema, considrese el dominio de software de sistemas de alarma. Este dominio puede
abarcar sistemas tan simples como HogarSeguro (descritos en captulos anteriores)
o tan complejos como el sistema de alarma para un proceso industrial. Sin embargo, en cada caso se encuentra un conjunto de patrones estructurales predecibles:
una interfaz que le permite al usuario interactuar con el sistema; un mecanismo de
establecimiento de lmites que le permite al usuario establecer lmites a los parmetros que se medirn; un mecanismo de gestin de sensores que se comunica con todos
los sensores de supervisin; un mecanismo de respuesta que reacciona a la entrada
proporcionada por el sistema de gestin de sensores, y un mecanismo de control que
Je permite al usuario controlar la forma en la que se realiza la supervisin. Cada uno
de estos puntos de estructura se integra en una arquitectura de dominio.
Es posible definir puntos de estructura genricos que trasciendan diferentes dominios de aplicacin [STA94]:
, Aplicacin frontal (cliente): la GUI que incluye todos los mens, paneles y entradas y ordena las funciones de edicin.
Bases de datos: el depsito para todos los objetos relevantes respecto del dominio de la aplicacin.
Motor de clculo: los modelos numricos y no numricos que manipulan datos.
Funcin de generacin de informes: la funcin que produce salidas de cualquier
tipo.
Editor de aplicaciones: el mecanismo para personalizar la aplicacin respecto a
las necesidades de usuarios especficos.
Los puntos de estructura se han sugerido como una alternativa a las lineas de cdigo y puntos de funcin para la estimacin del costo del software [MCM95]. En la seccin 30.6.2 se presenta una breve descripcin del empleo de los puntos de estructura en la cotizacin.
El desarrollo basado en componentes (DBC) es una actividad de ISBC que ocurre en

paralelo con la ingeniera del dominio. Al aplicar los mtodos de diseo de anlisis
y arquitectnico ya tratados en este libro, el equipo de software refina un estilo ar-
CAPTULO 30 INGENIERA DEL SOFTWAf!E BASADA EN COMPONENTES
887
quitectnico apropiado para el modelo de anlisis creado para la aplicacin que se

construir. 2
Una vez que la arquitectura se ha establecido, deben agregrsele componentes
que 1) estn disponibles en bibliotecas de reutilizacin 2) sean diseados para satisfacer las necesidades personales del cliente. Por tanto, el flujo de tareas para el desarrollo basado en componentes tiene dos trayectorias paralelas (figura 30. t). Cuando
los componentes reutilizables estn disponibles para su potencial integracin en la
arquitectura tienen que cualificarse y adaptarse. Cuando se requieren nuevos componentes es preciso disearlos. Entonces los componentes resultantes se "componen" (integran) en la plantilla arquitectnica y se prueban en forma minuciosa.
30.4.1 Calificacin, adaptacin y composicin de componentes

Como ya se ha visto, la ingeniera del dominio proporciona la biblioteca de componentes reutilizables indispensables para la ingeniera del software basada en componentes. Algunos de estos componentes se desarrollan especialmente para el dominio,
otros pueden extraerse de aplicaciones existentes e incluso otros pueden adquirirse
de terceras partes.
Desgraciadamente, la existencia de componentes reutilizables no garantiza que
puedan integrarse con facilidad o eficacia en la arquitectura elegida para una nueva
aplicacin. Por esta razn se aplica una sucesin de actividades de desarrollo basada en componentes cuando se propone el uso de un componente.
calificacin de componentes. Esta actividad garantiza que el componente candidato realizar la funcin requerida, "encajar'' adecuadamente en el estilo arquitectnico que especifica el sistema y mostrar las caractersticas de calidad (por
ejemplo, desempeo, fiabilidad, facilidad de uso) que requiere la aplicacin.
La descripcin de la interfaz suministra informacin til acerca de la operacin y
Q, facto
res se consi
deran durante la
callf'Kacin de
componentes?
la utilizacin de un componente de software, pero no proporciona toda la informacin que se requiere para determinar si un componente propuesto puede, en la prctica, reutilizarse con eficacia en una aplicacin nueva. Entre los muchos factores
considerados durante la cualificacin de componentes estn [BR096): interfaz de
programacin de la aplicacin (IPA); herramientas de desarrollo e integracin que
requiere el componente; requisitos de tiempo de ejecucin, que incluyen uso de recursos (por ejemplo, memoria o almacenamiento), tiempos o velocidad y protocolo
de red; requisitos de servicio, que incluyen interfases de sistema operativo y apoyo de
otros componentes; caractersticas de seguridad, que incluyen controles de acceso y
protocolos de autenticacin: suposiciones de diseo anidado, que incluyen el empleo de algoritmos numricos o no numricos especficos; y manejo de excepciones.
2 Se debe sealar que en el estilo arquttectmcoain fr~ncia influye el modelo estructural genrico creado durante la ingeniera del domm.io (\'a.se la ligura 30.1).
PARTE CINCO TEMAS AVANZADOS EN INGENIERA DEL SOFTWARE
cada uno de estos factores es relativamente sencillo de evaluar cuando se proponen componentes reutilizables que se han desarrollado especialmente para la aplicacin. Sin embargo, es mucho ms dilkil determinar la operatividad interna de as
COL o de componentes de provenientes de terceros porque la nica informacin disponible tal vez sea la misma especificacin de la interfaz.
Adaptacin de componentes. En un contexto ideal, la ingeniera del dominio

creara una biblioteca de componentes que podran integrarse fcilmente en una arquitectura de aplicacin. La implicacin de la "integracin fcil" es que 1) se han implementado mtodos consistentes de gestin de recursos para todos los componentes
en la biblioteca, 2) existen actividades comunes como la gestin de datos para todos
los componentes, y 3) se han implementado interfases dentro de la arquitectura .)
con el entorno externo en una forma consistente.
floNIIJOS.
Adems de valoro, si
es justifi<odo el costo
de odoptocin poro lo
reutilizodoo, el equipo
de software tumbin
evalo si lograr lo funcionolidod requerido y
el desempeilo se~
den hoc8f Blienle5
1/l!f)OtftJ dJ lDftD.
En realidad, incluso despus de que un componente se ha cualificado para emplearlo dentro de una arquitectura de aplicacin, es posible que haya conflictos en
una o ms de las reas indicadas. Estos conflictos usualmente se evitan utilizando una
tcnica de adaptacin llamada encubrimiento de componente [BR096]. Cuando un
equipo de software tiene pleno acceso al diseo interno y el cdigo de un componente (con frecuencia no es el caso cuando se utilizan componentes COL) se aplica el
encubrimiento de caja blanca. Al igual que su contraparte en la prueba de software
(captulo 14), el encubrimiento de caja blanca examina los detalles de procesamiento interno del componente y hace modificaciones en el cdigo para eliminar cual-
quier conflicto. El encubrimiento de caja gris se aplica cuando la biblioteca de componentes proporciona un lenguaje de extensin de componente o IPA que permite
eliminar o enmascarar los conflictos. El encubrimiento de caja negra requiere la introduccin de pre y posprocesamiento en la interfaz del componente para eliminar
o enmascarar los conflictos. El equipo de software debe determinar si el esfuerzo requerido para encubrir adecuadamente un componente est justificado o si, en lugar
de ello, debe disearse un componente personalizado (designado para eliminar los
conflictos encontrados).
Composicin de componentes. La tarea de composicin de componente ensambla componentes cualificados, adaptados y diseados con el fin de agregrselos
a la arquitectura establecida para una aplicacin. Esto se logra estableciendo una infraestructura que una los componentes en un sistema operativo. La infraestructura
(usualmente una biblioteca de componentes especializados) proporciona un modelo para coordinar los componentes y los servicios especificas que permiten que los
componentes se coordinen mutuamente y realicen tareas comunes.
Entre los muchos mecanismos que existen para crear una infraestructura eficaz
hay un conjunto de cuatro "ingredientes arquitectnicos" [ADL95] que debe estar
presente para lograr la composicin de componentes:
Modelo de intercambio de datos. Respecto de los componentes reutilizables

se deben definir mecanismos que permitan que los usuarios y aplicaciones interac-
CAPTULO 30
Qu ingre
dientes se
necesitan para lograr la composl
dn de componen
tes?
INGENlERA DEL SOFTWARE BASADA EN COMPONENTES
889
ten y transfieran datos (por ejemplo, arrastrar y soltar, cortar y pegar). Los mecanismos de intercambio de datos no slo permiten la transferencia de datos humano-software y componente-componente, sino tambin la transferencia entre recursos del sistema (por ejemplo, arrastrar un archivo a un icono de impresora para imprimirlo).
Automatizacin . Se deben implementar varias herramientas, macros y guiones

para facilitar la interaccin entre componentes reutilizables.
Almacenamiento estructurado . Los datos heterogneos (por ejemplo, datos
grficos, voz, video, texto y datos numricos) que contiene un "documento compuesto" deben estar organizados y ofrecer acceso como una sola estructura de datos
y no como una coleccin de archivos separados. "Los datos estructurados conservan
un ndice descriptivo de estructuras anidadas por las cuales las aplicaciones pueden
navegar libremente para ubicar, crear o editar contenidos de datos individuales segn ordene el usuario final" [ADL95J.
ld:lfrh'i'J
l.o~rntf18cientUr.tlal. COt-
BA se wedt ollreer
enwww.....,.
Modelo de objeto subyacente. El modelo de objeto asegura que los componentes desarrollados en diferentes lenguajes de programacin y que residen en diferentes plataformas pueden ser interoperables. Es decir, los objetos deben ser capaces
de comunicarse a travs de una red. Esto se logra si el modelo de objeto define un
estndar para la interoperabilidad de los componentes.
Puesto que el impacto potencial de la reutilizacin y la ISBC sobre la industria del
softw!-re es enorme, varias grandes compaas y consorcios industriales han propuesto estndares para el software de componentes:
OMG/ CORBA. El Grupo de Gestin de Objetos (OMG, por sus siglas en ingls)
ha publicado una arquitectura comn de distribucin de objetos (CORBA: por sus siglas
en ingls). Un distribuidor de objetos (ORB, por sus siglas en ingls) proporciona una
diversidad de servicios que permiten que los componentes reutilizables (objetos) se
comuniquen con otros componentes, sin importar su ubicacin dentro de un sistema.
COM de Microsoft. Microsoft ha desarrollado un modelo de objetos para componentes (COM, por sus siglas en ingls) que ofrece una especificacin para utilizar
componentes producidos por varias empresas dentro de una sola aplicacin que corra bajo el sistema operativo Windows. El COM incluye dos elementos: interfaces
COM (implementadas como objetos COM) y un conjunto de mecanismos que registra y pasa mensajes entre interfaces COM.
Componentes Sun JavaBeans. El sistema de componentes JavaBeans es una
infraestructura de ISBC porttil e independiente de la plataforma que utiliza y desarrolla empleando el lenguaje de programacin Java. El sistema de componentes JavaBeans incluye un conjunto de herramientas, llamado Kit de Desarrollo Bean (BDK,
Bean Development Kit), que permite a los desarrolladores l) analizar cmo funcionan
los Beans existentes (componentes), 21 personalizar su comportamiento y apariencia, 3) establecer mecanismos para coordinacin y comunicacin, 4) desarrollar
890
PARTE CINCO
Lol%iihM"~
inrolmlJCJII Jll6s re,
Beans personalizados para usarlos en una aplicacin especifica, y 5) probar y evaluar el comportamiento Bean.
...
ciente
ocert
*9:<
heons s,
pti0
l\e(8fl
,.~
,
~l'rl
TEMAS AVANZAJX)S EN INGENIER!A DEL SOFTWARE
Cul de estos estndares dominar la industria? En este momento no existe una

respuesta sencilla. Aunque muchos desarrolladores han adoptado uno de los estndares, tal vez las grandes organizaciones de software quieran optar por uno de los
tres estndares, segn las categoras de aplicacin y las plataformas que elijan.
que deben ser capaces de interactuar unos con otros den

tro de una solo mquina (diente o servidor) o a travs de
la red. Un distribuidor de objetos (ORB) es middleware
(software personalizado) que permite que un objeto residente en un diente enve un mensaje a un mtodo que est
encapsulado en un objeto residente en un servidor. En
esencia, el ORB intercpta el mensaje y maneja las actividades de comunicacin y coordinacin necesarias para
encontrar el objeto al cual fue dirigido el mensaje, invoca
su mtodo, paso los datos apropiados al objeto y transfiere
los datos resultantes de vuelta ol objeto que gener prime
ro el mensaje.
CORRA, COM y J(IVOBeoM implementan uno filosofa
de distribuidor de objetos. En este recuadro CORBA se
usar paro ilustrar el middlewore ORB.
En la figura 30.2 se ilustro lo estructuro bsico de uno

orqv;leclvco CORBA. Cvondo CORBA .., implementa en
un
sistema diente-servidor, los objetos servidores ambos se

definen utilizando un lenguaje de descripcin de interfase
(IDL, interface description language), un lenguaje de dedo
raciones que permite que un ingeniero de software defina
objetos, atributos, mtodos y los mensajes que se requieren
poro invocarlos. Poro que un objeto residente en el diente
acomode uno peticin para un mtodo residente en el ser
vidor se crean stubs (adaptadores) del IDL en el diente y el
servidor. Los stubs proporcionan lo compuerta o travs de
Puesto que los peticiones de objetos o travs de la red

ocurren en tiempo de ejecucin, se debe establecer un me
conismo para almacenar lo descripcin de objeto de modo
que la informacin pertinente acerca del objeto y su ubico
cin estn disponibles cuando se necesite. El depsito de
interfaz logro esto.
Cuando uno aplicacin en el diente debe invocar un
mtodo ubicado dentro de un objeto en cualquier parte del
sistema, CORBA utiliza invocacin dinmica paro 1) obtener informacin pertinente acerca del mtodo deseado a
partir del depsito de interfaz, 2) crear una estructura de
datos con parmetros que pasarn al objeto, 3) crear una
peticin para el objeto, y 4) invocar la peticin. Entonces
la peticin paso a l ncleo del ORB - uno porte del sistema
operativo de la red especfico de lo implementacin que
gestiono las peticiones- y se cumple lo peticin.
La peticin poso o travs del ncleo y lo proceso el servidor. En el sitio de ste un adoptador de objeto almaceno
informacin de lo clase y el objeto en un depsito de inter
foz residente en el servidor, acepta y gestiona los peticiones que llegan del diente y realiza uno diversidad de otros
funciones de gestin de objetos. En el servidor stubs del IDL
similores o los definidos en lo mquina diente se utilizan
como la interfaz paro lo implementacin del objeto real re
sidente en el sitio del servidor.
30.4.2 Ingeniera de componentes

Como ya se indic en este capitulo, el proceso de ISBC alienta el uso de componentes de software existentes. Sin embargo, hay ocasiones en que los componentes deben
disearse. Es decir, se deben desarrollar nuevos componentes de software e integrarse con los CDL ya existentes y con los componentes de desarrollo propio. Puesto que los nuevos componentes se integran a la biblioteca propia de componentes
reutilizables, deben disearse para su reutilizacin.
CAPTULO 30 INGENIERIA DEL SOFTWARE BASADA EN COMPONENTES
891
.;:..J,p
Arquitectura
CORBA bsica.
No hay nada mgico en la creacin de componentes de software reutilizables. Los

conceptos de diseo tales como abstraccin, ocultacin, independencia funcional,
refinamiento y programacin estructurada, junto con mtodos orientados a objeto,
pruebas de SQA y mtodos de verificacin de correccin, todos contribuyen a la
creacin de componentes de software reutilizables. 3 En esta seccin no se volvern
a tratar estos temas. Ms bien, se considerarn los temas especificos de la reutilizacin que complementan las prcticas slidas de ingeniera del software.
30.4.3 Anllsis y diseo para la reutilizacin

El modelo de anlisis se analiza para determinar aquellos elementos del modelo que
apuntan hacia los componentes reutilizables existentes. El problema es extraer informacin a partir del modelo de requisitos en una forma que conduzca a la "concordancia de especificaciones".
Si la concordancia de especificaciones produce componentes que se ajustan con
las necesidades de la aplicacin actual, el diseador puede extraer dichos componentes de una biblioteca (depsito) de reutilizacin y aplicarlos en el diseo de nuevos sistemas. Si no encuentra componentes de diseo, el ingeniero de software debe
aplicar mtodos de diseo convencional u 00 para crearlos. En este punto -cuando el diseador comienza a crear un nuevo componente- se debe considerar el diseo para la reutilizacin (DPR).
Como ya se indic, el DPR requiere que el ingeniero de software aplique slidos
conceptos y principios de diseo de software (captulo 9). Pero tambin se deben
Para aprender ms acerca de estos coocepcos vanse las partes 2 y 5 de este libro.
892
PARTE CINCO TEMAS AVANZADOS EN INGENIERiA DEL SOFTWARE
tcoNsEJo$
considerar la caractersticas del dominio de la aplicacin. Binder [BIN93J sugiere va-
El DPI? puede serbastante diffcil cuando los

componentes deben
estor en intedoz oin
tegrodos con sistemas
heredados ocon siste
mas mltiples cuya ar
quitecturo yprotocolos
de intedoz sean inconsistentes.
rios temas clave4 que forman una base para el diseo destinado a la reutilizacin.
Datos estndar. Se debe investigar el dominio de la aplicacin e identificar las

estructuras de datos globales (por ejemplo, estructuras de archivos o una base de datos completa). Entonces se pueden caracterizar todos los componentes de diseo
para aprovechar dichas estructuras de datos estndar.
Protocolos de interfaz estndar. Se deben establecer tres niveles de protocolo de interfaz: la naturaleza de las interfaces intramodulares, el diseo de interfaces
tcnicas (no humanas) externas y la interfaz hombre-mquina.
Plantillas de programa. El modelo de estructura (seccin 30.3.3) sirve como
una plantilla para el diseo arquitectnico de un programa nuevo.
Una vez establecidas las interfases, los datos estndar y las plantillas de programa, el diseador tiene un marco de trabajo en el que puede crear el diseo. Los nuevos componentes que se ajusten a este marco de trabajo tienen una mayor probabilidad de que se les reutilice posteriormente.
Considrese una biblioteca universitaria. Cientos de miles de libros, publicaciones

peridicas y otras fuentes de informacin estn disponibles para utilizarlos. Pero el
ingreso a dichas fuentes requiere desarrollar un sistema de clasificacin. Para navegar por este gran volumen de informacin, los bibliotecarios han definido un sistema
de clasificacin que incluye el cdigo de clasificacin de la Biblioteca del Congreso
(en los Estados Unidos de Amlica), palabras clave, nombres de autor y otras entradas de ndice. Todo esto permite que el usuario encuentre rpida y fcilmente la
fuente requerida.
Ahora, considrese un gran depsito de componentes. Cientos de miles de componentes de software reutilizable se hallan en l. Pero, cmo encuentra un ingeniero de software el componente que necesita? Para responder esta pregunta surge otra:
cmo se describen los componentes de software en trminos clasificables y sin ambigedades? slas son preguntas dificiles y todava no se ha desarrollado una respuesta definitiva. En esta seccin se exploran las tendencias actuales que permitirn a los
futuros ingenieros de software navegar entre las bibliotecas de reutilizacin.
30.5. l
Descripcin de los componentes reutilizables
Un componente de software reutilizables se describe en muchas formas, pero una

descripcin ideal incluye lo que Tracz [TRA90] ha llamado el modelo 3C: concepto,
contenido y contexto.
En general. se deben realizar preparativos para el DPR como parte de la ingeniera del dominio (seccin 30.3) .
CAPTULO 30
INGENIERIA DEL SOflWARE BASADA EN COMPONENiES
893
El concepto de un componente de software es "una descripcin de lo que hace el

componente" [WH195J. La inteaz con el componente est completamente descrita
y la semntica -representada dentro del contexto de las precondiciones y las poscondic1ones-, identificada El concepto debe comunicar la intencin del componente.
El contenido de un componente describe cmo se construye el concepto. En esencia, el contenido es informacin oculta para los usuarios habituales y que slo necesitan conocerla quienes quieran modificar o probar el componente.
El contexto sita un componente de software reutilizable en su dominio de aplicabilidad. Es decir, al especificar las caractersticas conceptuales, operativas y de
implementacin el contexto permite que un ingeniero de software encuentre el componente apropiado para satisfacer los requisitos de la aplicacin.
Para que sean tiles en la prctica, concepto, contenido y contexto se deben traducir en un esquema de especificacin concreto. se han escrito docenas de ensayos
y articulas acerca de los esquemas de clasificacin para componentes de software
reutilizables (por ejemplo, [LUCOIJ y [WHI95] contienen bibliografias extensas). Los
mtodos propuestos se pueden clasificar en tres grandes reas mtodos de biblioteconoma y de ciencias de la comunicacin, mtodos de inteligencia artificial y sistemas de hipertexto. La gran mayora del trabajo realizado hasta la fecha sugiere el
empleo de mtodos de biblioteconoma para la clasificacin de componentes.
La figura 30.3 presenta una taxonoma de los mtodos de indexacin en la biblioteconomla. Los vocabularios controlados de indexacin limitan los trminos o sintaxis
con que se clasifica un objeto (componente). Los vocabularios de indexacin no controlados no ponen restricciones en la naturaleza de la descripcin . La mayora de los
esquemas de clasificacin para los componentes de software se incluye en tres ca
tegoras.
Clasiflcacln enumerada. Los componentes se describen mediante una estruc

tura jerrquica en la cual se definen las clases y los niveles variables de subclases de
los componentes de software. La estructura jerrquica de un esquema de clasificacin enumerada facilita comprenderlo y utilizarlo. Sin embargo, antes de construir
una jerarqua se debe llevar a cabo la ingeniera del dominio de modo que haya suficiente conocimiento de las entradas adecuadas en la jerarqua.
Clasificacln por facetas. Se analiza una rea del dominio y se identifica un

conjunto de caractersticas descriptivas bsicas. Estas caractersticas, llamadas facetas, entonces se clasifican segun su importancia y se conectan con un componente.
Una faceta describe la funcin que el componente realiza, los datos que se manipulan, el contexto en el que se aplican o cualquiera otra caracterstica. El conjunto de
facetas que describe un componente se denomina descriptor de facetas. En general,
la descripcin por facetas se limita a no ms de siete u ocho facetas.
Clasificacin de valores y atributos. Un conjunto de atributos se define para

todos los componentes en cierta rea del dominio. Enseguida se asignan valores a
dichos atributos en una forma muy similar a la clasificacin por facetas. De hecho,
894
PARTE CINCO TEMAS AVANZADOS EN INGENIERA DEL SOF1WARE
.;m:p.. .
Indexacin
de vocabularios
Taxonoma de
los mtodos de
Indexacin
[FRA94].
Controlado
Por clases
Descontrolado
Palabra clave
t t
Trminos extrados
del texto
Enumerado
Descriptores
Por facetos
Encabezados
de materia
Trminos no
extrados del texto
L Con sintaxis
[
Sin sintaxis
Diccionario - - - - '
la clasificacin de valores y atributos es similar a la clasificacin por facetas, con las

siguientes excepciones: l) no se limita el nmero de atributos que se pueden utilizar, 2) no se asignan prioridades a los atributos, y 3) no se utiliza la funcin diccionario.
Con base en un estudio emprico de cada una de estas tcnicas de clasificacin,
Frakes y Pole
[FRA94J indican que no existe una tcnica claramente "mejor" y que

"ningn mtodo se desempe ms que moderadamente en la eficacia de bsqueda ... " Parecerla que todava falta realiza ms trabajo en el desarrollo de esquemas
de clasificacin eficaces para bibliotecas de reutilizacin.
30.5.2 El entorno de reutllizacin

La reutilizacin de componentes de software debe apoyarla un entorno que incluya
los siguientes elementos:
Una base de datos de componentes capaz de almacenar componentes de
software, as como la informacin de clasificacin necesaria para recuperarlos.
Un sistema de gestin de bibliotecas que ofrezca acceso a la base de datos.
Un sistema de recuperacin de componentes de software (por ejemplo, un
distribuidor de objetos) que permita que una aplicacin cliente recupere componentes y servicios del servidor de la biblioteca.
Herramientas de ISBC que apoyen la integracin de los componentes reutilizados en un nuevo diseo o implementacin.
Cada una de estas funciones interacta con o est incorporada en los confines de
una biblioteca de reutilizacin.
CAPTULO 30
INGENIERA DEL SOfiWARE RASADA EN COMPONENTES
895
La biblioteca de reutilizacin es un elemento de un depsito de software mayor

(captulo 27) y proporciona medios para el almacenamiento de componentes de software y una amplia gama de productos de trabao reutilizables (por ejemplo, especificaciones, diseos, patrones, marcos de trabajo, fragmentos de cdigo, casos de
prueba, guias de usuario). La biblioteca contiene una base de datos y las herramien-
n;;+11@ma
.
\
lltlQeimlltoleaI!
de IWSOS atelt de
lSBC se pulMl ~
tmren
tdtp://www.
......H /.
"
tas necesarias para consultarla y recuperar componentes de ella. Un esquema de

clasificacin de componentes (seccin 30.5.1) sirve como base para consultar la biblioteca.
Las consultas usualmente se caracterizan mediante el elemento contexto del modelo 3C ya descrito en esta seccin. Si una consulta inicial resulta en una extensa lista de componentes candidatos, la consulta se refina para reducirla. Entonces se extrae la informacin de concepto y contenido (despus de hallar los componentes
candidatos) para auxiliar al desarrollador en la seleccin del componente apropiado.
Una descripcin detallada de la estructura de las bibliotecas de reutilizacin y de
las herramientas que las gestionan es mejor dejrsela a las fuentes especializadas en
la materia. El lector interesado obtendr mayor informacin consultando [FISOOJ y
[LIN95J.
Desarrollo basado en componentes
~ Objetivo: Auxiliar en el modelado, diseo, re

visin e integracin de los componentes de softwore como porte de un sistema mayor.
Mecnico: Lo mec6nico de los herramientas varo. En

general, los herramientas de DBC auxilian en uno o m6s
de los siguientes copocidodes: especificacin y modelado
de lo orquiteduro del sohwore; navegacin y seleccin de
los componentes de sohwore disponibles; integracin de
componentes.
Herramientas representotivas 5
ComponentSource (www.componentsource.com) propor
ciono un amplio serie de componentes (y herramientas)
de sohwore CDL apoyado en muchos est6ndores de
componentes diferentes.
30,6
EQQNAM16 PI LA
Component Manager, desarrollado por Floshline (www

.floshline.com), "es uno aplicacin que posibilito, pro
mueve y mide lo reutilizacin de componentes de
sohwore"
Seled Component Factory, desarrollado por Select Busi

ness Solutions (www.seledbs.com/products), "es un
conjunto integrado de productos poro el diseo de software, revisin de diseo, gestin de servicios y compo
nentes, gestin de requisitos y generacin de cdigo".
Software Through PicturesACD, distribuido por Aonix

(www.oonix.com), permite el modelado integral em
pleondo UML poro lo orquiteclur<? que rige el modelo
OMG; un enfoque poro lo ISBC abierto e independien
te de lo empresa.
ISBC
La ingeniera del software basada en componentes tiene un atractivo intuitivo. En

teora, debe proporcionar a una organizacin de software ventajas en cuanto a cali-
Las herramientas expuestas slo representan una muestra de esta categora. En la mayora de los
casos los nombres de las mismas son rr.arras n-grstradas por sus respectivos desarrolladores.
896
PARTE CINCO
f ftlili:ifrh'::1
dad y oportunidad, Jo que debe traducirse en ahorros. Pero, existen datos reales que
apoyen esta intuicin?
mm pt11U et oec ylos
La respuesta a esta pregunta primero requiere entender lo que en realidad se puede

reutilizar en un contexto de ingenieria del software y luego cules son en realidad
los costos asociados con la reutilizacin. Corno consecuencia, ser posible desarrollar un anlisis costo-beneficio para la reutilizacin de componentes.
Uno divwfod de Ol1f

aMOS que OJe(n dlr~
siSlemos hilds en .
CDI se peoo,'MCMIIOI
e~ www.sti.an1.
tel11, ';,
>
TEMAS AVANZAIX>S EN INGEN!ERIA DEL SOFTWARE
30.6.1 Impacto sobre la calidad, la productividad y el costo

Existen numerosas evidencias, a partir de estudios de caso industriales (por ejemplo,
[ALL02]. [HEN95], [MCM95]), que indican la posibilidad de derivar sustanciales beneficios de negocios a partir de la reutilizacin vigorosa del software. Mejoran la calidad del producto, la productividad de desarrollo y el costo global.
Calidad. En un entorno ideal, un componente de software que se desarrolle para

reutilizacin se verificarla como correcto (vase el captulo 29) y no contendra defectos. En realidad, la verificacin formal no se lleva a cabo de manera rutinaria y
existe la posibilidad de que ocurran defectos, y de hecho ocurren. Sin embargo, con
cada reutilizacin los defectos se encuentran y eliminan, y, como resultado, mejora
la calidad del componente. Con el tiempo el componente queda virtualmente libre
de defectos.
En un estudio realizado en Hewlett-Packard, Lim [LIM94) report que la tasa de
defectos para el cdigo reutilizado es de 0.9 defectos por KLDC, mientras que la tasa para software desarrollado recientemente es de 4.1 defectos por KLDC. En una
aplicacin compuesta de 68 por ciento de cdigo reutilizado la tasa de defecto fue
de 2.0 defectos por KLDC, es decir: un 51 por ciento de mejora respecto de la tasa
esperada si la aplicacin hubiese sido desarrollada sin reutilizacin. Henry y Faller

[HEN95J reporta un 35 por ciento de mejora en la calidad. Aunque los reportes anecdticos abarcan un espectro razonablemente amplio de porcentajes de mejora en la
calidad, es justo afirmar que la reutilizacin ofrece un beneficio importante en cuanto a la calidad y fiabilidad para el software entregado.
Productividad. Cuando los componentes reutilizables se aplican a lo largo del

proceso de software, se dedica menos tiempo a la creacin de planes, modelos, documentos, cdigo y datos que se requieren para crear un sistema fiable. Por lo tanto, se entrega al cliente el mismo nivel de funcionalidad con menos esfuerzo, lo que
mejora la productividad. Aunque los reportes de mejora porcentual en la productividad son notablemente dificiles de interpretar,6 parece que la reutilizacin del 30 al
50 por ciento puede resultar en mejoras en la productividad en el rango del 25-40 por
ciento.
Muchas circunstancias atenuantes (por ejemplo, dominio de aplicacin, complejidad del problema,
estructura y tamao del equipo, duracin del proyecto, tecnologa aplicada) tienen un profundo impacto sobre la productividad del equipo del proyecto.
CAPTULO 30 INGENIERA DEL SOFTWARE BASADA D-1 COMPONENTES
897
costo. Los ahorros en el costo neto por la reutilizacin se estiman al proyectar el

costo del proyecto si ste fuese desarrollado desde cero, c0 , y luego se resta la suma
El costo de desarrollar
un cmnponente reutift
zoble con frecvendo
es mayor que el de
desarrollo, un componente especfico poro
uno aplicacin. Asegl}
rese de que en el futuro hobt uno
necesidad respecto del
componen/e reutilizable. Aqu es donde se
reallzo lo retribudn.
de los costos asociados con la reutilizacin, Cr, y el costo real del sofl:ware en el momento de la entrega, e ..
El factor C0 se puede determinar al aplicar una o ms de las tcnicas de estimacin estudiadas en el captulo 23 Los costos asociados con la reutilizacin, e,, incluyen
[CHR95J: anlisis y modelado del dominio, desarrollo de arquitectura del dominio,
aumento en la documentacin para facilitar la reutilizacin, soporte y mejora de los
componentes de reutilizacin, regalas y licencias para componentes adquiridos externamente, creacin o adquisicin y operacin de un depsito de reutilizacin, y entrenamiento del personal en diseo y construccin para reutilizacin. Aunque los
costos asociados con el anlisis del dominio (seccin 30.3) y la operacin de un depsito de reutilizacin pueden ser sustanciales, muchos de los otros costos indicados aqu abordan los conflictos que forman parte de una buena prctica de ingeniera
de software, ya sea que la reutilizacin sea o no una prioridad.
30.6.2 Anlisis de costo empleando puntos de estructura

En la seccin 30.3.3 se defini un punto de estructura como un patrn arquitectnico recurrente en la totalidad de un dominio de aplicacin particular. Un diseador de
software (o ingeniero de sistemas) puede desarrollar una arquitectura para una nueva aplicacin, sistema o producto al definir una arquitectura del dominio y luego do
tarla con puntos de estructura. stos son o componentes reutilizables individuales o
paquetes de componentes reutilizables.
Aunque los puntos de estructura sean reutilizables, sus costos de cualificacin,
adaptacin, integracin y mantenimiento no son insignificantes. Antes de proceder
a la reutilizacin el gestor del proyecto debe comprender los costos asociados con la
utilizacin de los puntos de estructura.
Dado que todos los puntos de estructura (y los componentes reutilizables en general) tienen una historia, es posible recopilar datos de costos de cada uno. En un
contexto ideal los costos de calificacin, adaptacin, integracin y mantenimiento
asociados con cada componente en una biblioteca de reutilizacin se mantienen para cada caso de utilizacin. Entonces se pueden analizar dichos datos para desarrollar los costos proyectados respecto del siguiente caso de reutilizacin.
Como ejemplo, considrese una nueva aplicacin, X, que requiere 60 por ciento
de cdigo nuevo y la reutilizacin de tres puntos de estructura: PE 1, PE2 y PE.1 . Cada
uno de estos componentes reutilizables se ha utilizado en muchas otras aplicaciones, y estn disponibles los costos promedio para cualificacin, adaptacin, integracin y mantenimiento
La estimacin del esfuerzo necesario para entregar X requiere determinar lo siguiente:
esfuerzo global - Enuevo
donde
+ E.:. + ~ ~ Ew.
898
PARTE CINCO TEMAS AVANl.AJX>S EN INGENIERA DEL SOFTWARE

Enuevo
= esfuerzo requerido para disear y construir nuevos componentes de

software (determinados empleando las tcnicas descritas en el captulo 23)
Eadapt
= esfuerzo requerido para calificar PE1, PE2 y PE3

= esfuerzo requerido para adaptar PE1, PE2 y PE3
Eint
= esfuerzo requerido para integrar PE1, PE2 y PE3
Ecalif
El esfuerzo requerido para cualificar, adaptar e integrar PE1 , PE2 y PE3 se determina
al tomar el promedio de los datos histricos recopilados para la cualificacin, adaptacin e integracin de los componentes reutilizables en otras aplicaciones.
La ingeniera del software basada en componentes ofrece beneficios inherentes en

la calidad del software, la productividad del desarrollador y el costo global del sistema. Sin embargo, falta superar muchos obstculos antes de que el modelo de proceso de ISBC se utilice ampliamente en la industria.
Adems de los componentes del software, un ingeniero de software puede adquirir
una amplia gama de artefactos reutilizables. Entre stos se encuentran representaciones tcnicas del software (por ejemplo, especificaciones, modelos arquitectnicos, diseos). documentos, patrones, marcos de trabajo, datos de prueba e incluso
tareas relacionadas con el proceso (por ejemplo, inspecciones tcnicas).
El proceso de ISBC incluye dos subprocesos concurrentes: la ingeniera del dominio y el desarrollo basado en componentes. La finalidad de la ingeniera del dominio
es identificar, construir, catalogar y diseminar un conjunto de componentes de software en un dominio de aplicacin especfico. Entonces el desarrollo basado en componentes califica, adapta e integra dichos componentes para emplearlos en un nuevo
sistema. Adems, el desarrollo basado en componentes disea los componentes
nuevos que se basan en los requisitos personalizados de un sistema nuevo.
Las tcnicas de anlisis y diseo para componentes reutilizables se basan en los
mismos principios y conceptos que forman parte de una buena prctica de ingeniera del software. Los componentes reutilizables deben disearse en un entorno que
establezca estructuras de datos estndar, protocolos de interfaz y arquitecturas de
programa para cada dominio de la aplicacin.
La ingeniera del software basada en componentes utiliza un modelo de intercambio de datos, herramientas, almacenamiento estructurado y un modelo de objeto subyacente para construir las aplicaciones. El modelo de objeto generalmente concuerda
con uno o ms estndares de componentes (por ejemplo, OMG/CORBA) que definen
la forma en que una aplicacin puede acceder a los objetos reutilizables. Los esquemas
de clasificacin permiten que un desarrollador encuentre y recupere componentes reu-
tilizables y se ajuste a un modelo que identifica concepto, contenido y contexto. La

clasificacin enumerada, la clasificacin por facetas y la clasificacin de valores y
atributos son representativas de muchos esquemas de clasificacin de componentes.
CAPTULO 30
INGENIERA DEL SOFTWARE BASADA EN COMPONENTES
899
La economa de la reutilizacin del software se aborda mediante una sola pregun-
ta: es efectivo en costo el construir menos y reutilizar ms? En general, la respuesta

es s, pero un planificador de proyectos de software debe considerar los costos importantes asociados con la calificacin, adaptacin e integracin de los componentes reutilizables.
[ADL95] Adler, R. M., "Emerging Standards for Component Software", en Computer, vol 28, nm.
3, marzo de 1995, pp. 68-77.
[ALL021 Allen, P., "CBD Survey: The State of the Practice", en The cutter Edge, marzo de 2002,
disponible en http://www.cutter.com/research/2002/edge020305.htm1.
[ATKOIJ Atkinson, c., el al., Component-Based Product Une Engineeringwith UML, Addison-Wesley, 2001.
[BAS94] Basili, V. R., L. C. Briand y W. M. Thomas. "Domain Analysis for the Reuse of Software
Oevelopment Experiences", Proc. Of the 19th Annual Software Engineering Workshop, NASAIGSFC, Greenbelt, MD, diciembre de 1994.
[BIN93J Binder, R., "Design for Reuse is far Real", en American Programmer, vol. 6, nm. 8, agosto de 1993, pp. 30-37.
[BR096J Brown, A. W., y K. C. Wallnau, "Engineering of Component-Based Systems", en Component-Based Software Engineering, IEEE Computer Society Press, 1996, pp. 7- 15.
[CHR95J 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 Development'', en American Programmer, vol. 8, nm. 11, noviembre de 1995.
[D0G03J Dogru, A., y M. Tanik, "A Process Model far Component-Oriented Software Engineering", en IEEE Software, vol. 20, nm. 2, marzo-abril 2003, pp. 34-41.
[FISOO] Fischer, B., "Specification-Based Browsing ofSoftware Component Libraries", en]. Automated Software Engineering, 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., y T. P. Pole, "An Empirical Study of Represenlation Methods far Reusable
Software Components", en IEEE Trans. Software Engineering, vol. SE-20, nm. 8, agosto de
1994, pp. 617-630.
[HE101] Heineman, G., y W. Councill (eds.), Component-Based Software Engineering, AddisonWesley, 200 l .
[HEN95] Henry, E., y B. Faller, "Large Scale Industrial Reuse lo Reduce Cost and cycle Time", en
IEEE Software, septiembre de 1995, pp. 47-53.
[HUT88] Hutchinson, J. W., y P. G. Hindley, "A Preliminary Study of Large Scale Software Reuse",
en Software Engineering Joumal, vol. 3, nm. 5, 1988, pp. 208-212.
[LIA931 Liao, H., y Wang, F., "Software Reuse Based on a Large Object-Oriented Library", en ACM
Software Engineering Notes, vol. 18, nm. l, enero de 1993, pp. 74-80.
[LIM94] Lim, W. C., "Effects of Reuse on Quality, Productivity, and Economics", en IEEE Software, septiembre de 1994, pp. 23-30.
[UN95] Linthicum, D. S., "Component Development (a Special Feature)", Application Development Trends, junio de 1995, pp. 57-78.
[LUC01] delucena, Jr., V., "Facet-Based Classification Scheme far Industrial Software Components", 2001, se puede descargar de http://research.microsoft.com/users/cszypers/events/WCOP200 l /Lucena pdf.
[MCM95] McMahon, P. E., "Pattem-Based Architecture: Bridging Software Reuse and Cost Management", en Crosstalk, vol. 8, nm. 3, marzo de 1995, pp. 10-16.
[ORF96] Orfali, R., D. Harkey y J. Edwards, 1he E.ssalllal Distributed Objects Survival Guide, Wiley,
1996.
[PRI93J Prieto-Daz, R. , "lssues and Expcrlcnces n software Reuse", en American Programmer,
vol. 6, nm. 8, agosto de 1994, pp. 6i-.S
900
PARTE CINCO
TEMAS AVANZADOS EN INGENIERA DEL SOFIWARE
[POL94J Pollak, w. y M. Rissman, "Structural Models and Pattemed Architectures", en computer

vol. 27, nm. 8, agosto de 1994, pp.67-68.
[STA94] Staringer, W., "Constructing Applications from Reusable Components", en IEEE Sofava.re, septiembre de 1994, pp. 61 -68.
[TRA90J Tracz, W., "Where Does Reuse Start?", Proc. Realities of Reuse Workshop, Syracuse Uruversity CASE Center. enero de 1990.
[TRA95] Tracz, W., "Third lnternational Conference on Software Reuse-Summary", en ACM Software Engineering Notes, vol. 20, nm. 2, abril de 1995, pp. 21-22.
[WHl95) Whittle. B., "Models and Languages for Component Description and Reuse", en AG\,
SoftwareEngineering Notes, vol. 20, nm. 2, abril de 1995, pp. 76-89.
[YOU98) Yourdon, E. (ed.), "Distributed Objects", en Cutter IT Joumal, vol. 11 , nm. 12, diciembre de 1998.
30.1. Uno de los obstculos clave para la reutilizacin consiste en hacer que los desarrolladores 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 ingenieros de software empleen la reutilizacin. Qu tecnologias deben existir para apoyar el esfuerzo de la reutilizacin?
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 reutilizar y cul es el beneficio de hacerlo?
30.3. Investiguese un poco acerca de la ingenieria del dominio y detllese el modelo de proceso esbozado en la figura 30.1. ldentiflquense las tareas que se requieren para el anlisis del dominio y el desarrollo arquitect6nico del software.
30.4. En qu son semejantes las funciones de caracterizacin para dominios de aplicacin y
los esquemas de clasificaci6n de componentes? En qu se diferencian?
30.5. oc::;arrollar un conjunto de caraclerlslicas 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 software de procesamiento de textos y publicacin.
30.7. Desarrollar un modelo estructural simple para un dominio de aplicacin que asigne individualmente el instructor o uno con el cual se est familiarizado.
30.8. Qu es un punto de estructura?
30.9. Adquirir i11formacin acerca del ms reciente estndar CORBA, COM o JavaBeans y elaborar 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 herramienta se ajusta al estndar.
30.1 O. Desarrollar una clasificacin enumerada para un dominio de aplicacin que asigne el
instructor o uno con el que se est familiarizado.
30.11. Desarrollar un esquema de clasificacin por facetas para un dominio de aplicacin que
asigne el instructor o uno con el que se est familiarizado.
30.12. Investguese en la bibliografla para obtener datos recientes de calidad y productividad
que apoyen el uso de la 1SBC. Presntense los datos a la clase.
CAPTULO 30
INGENIERA DEL SOFIWARE BASADA EN COMPONENTES
901
En aos recientes se han publicado muchos libros acerca del desarrollo basado en componentes y la reutilizacin de stos. Heineman y COuncill [HEIOll, Brown (Large sea/e Component-Based
Development, Prentice-Hall, 2000), Allen (Realizing e-Business with Components, Addison-Wesley,
2000), Herzum y Sims (Business Component Factory, Wiley, 1999) y Allen, Frost y Yourdon (Component-Based DevelopmentJor Enterprise Systems: Applying the Select Perspective, Cambridge University Press, 1998) cubren todos los aspectos importantes del proceso de !SBC. Apperly y sus
colegas (Service- and Component-Based Development, Addison-Wesley, 2003), Atkinson [ATKOIJ
y Cheesman y Oaniels (UML Components, Addison-Wesley, 2000) examinan la ISBC poniendo especial cuidado en UML.
Leach (SOjtware Reuse: Methods, Models, and Costs, McGraw-Hill, 1997) proporciona un anlisis detallado de los conflictos de costo asociados con la ISBC y la reutilizacin. Poulin (Measuring Software Reuse: Principies, Practices, and Economic Mode/s, 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 JSBC. A continuacin se
presenta una muestra de los tres estndares estudiados en este captulo:
CORBA
Bolton, F., Pure CORBA, Sams Publishing, 2001.

Doss, G. M., CORBANetworking Withfava, Wordware Publishing, 1999.
Hoque, R., CORBAjor Real Programmers, Academic Press/Morgan Kaufmann, 1999.
Siegel, J., CORBA Fundamentals and Programming, Wiley, 1999.
Slama, o., J. Garbis y P. Russell, Enterprise CORBA, Prentice-Hall, 1999.
COM
Box, D., K. Brown, T. Ewald y C. Sells, Ejfective COM: 50 way.s to lmprove Your COM- and MTSBased 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., COM+ Programming, Prentice-Hall, 2000.
Muchas organizaciones aplican una combinacin de estndares de componentes. Los libros de
Geraghty y sus colegas (COM-CORBA Interoperabi/ily, Prentice-Hall, 1999), Pritchard (COM and
CORBA Side by Side: Architectures, Strategies, and lmplementations, Addison-Wesley, 1999), y Rosen 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 }avabeans, tercera edicin, O'Reilly & Associates, 2001.
Roman, E., et al., Mastenng Enterpnse JQvabeans, 2a. ed., Wiley, 2001 .
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de la ingeniera del software basada en componentes Una lista actualizada de referencias en la World Wide
Web se puede encontrar en el sitio Web SEPA:
CAPTULO
n un relevante articulo publicado en la HatVatd :eusiness Review, Michael

Hami;ner [HAM90J sent las bases para una revolucin en el penSG1miento
administrativ acerca de los procesos de negocios y la computacin:
CONCEPTOS
CLAVE
anlisis de
Inventarlos .909
de dejar de pavimentar los senderos para vac~. En lugar de incrstqr procesos anticuados en silicio y software, debemos eliminarlos y comenzar de
Es el momento
Grq11itectra$
c/s ........ .920
nuevo. Debemos someter a "reingeniera" nuestros negocosi usar el poder de las
Grt(Ult,cturos
00 .........921
economa .....923
modernas tecnologiclS de la informacin para redisear radicalmente nuestros procesos de negocios con la finalidad de aicanzar mejoras ra<lJcales .en su d,esempeo,
lngenierla
Cualquier compaia opera de acuerdo con una gran cantidad de reglas desarticuladas... La ringenieria luch~ por separ,arse de las viejas reglas acerca de; cmo ot-
dired .......918
ganizar y dirigir nuestros negocios.
llgemetQ
!avenes ..... 912

lllOlltelli!llit11fo 906
modelo de
procesQ IIPN ,903
promo de
reingeniera .908
,y.
,;;t~
,, ,._,.
reestruduradn 916
;1:
Al igual que todas las revoluciones, el llamado a las armas de Hammer gener
cambios positivos y negativos. Durante et decento de 1990, algunas compaas
aplicaron un esfuerzo legitimo en la realizacin de rengenitlrla, y losresultados
las condujeron a mejorar su competitMdad. Otras se apoyaron exclusivamente
en el rectimens!onamiento y la S\lbcontratacin (en lugar de la reingeniera) para
mejorar sus lneas base; po lo lrtt, cQo, frecuencia resultaron organizaciones
' con poco ptericial para tm fe(:ii:ntento r-uturo [DEM9$},
Duraqte esta prjmera dcada del siglo xx1, la promocin exagerada de la .reinseijfod.i
d~caao, R~ro el" prc~o en ;i CQ[J~ina en compah~s grandes y
pequeas. Los nexos entre la reingenied~ de neg9cos e ipgenirla del software
"se encuentran en una revisin de sistema;
ha
CAPTULO 31
~,c&v1
REINGENIERA
903
&'
lo RPN con frecuencia

genero uno nuevo
funcionalidad de
software, mientros que
lo reingenieo del
software trnbojo poro
reemplazar lo
funcionalidad del
software existente con
un mejor software y de
mayor focilidod de
mantenimiento.
Usualmente el software es la realizacin de las reglas del negocio que Hammer

describe. Conforme cambien dichas reglas, el software tambin debe hacerlo. En la
actualidad, las grandes compaas tienen decenas de miles de programas de computadora que apoyan a las viejas reglas del negocio. A medida que los administradores
trabajen en la modificacin de las reglas y logren mayores efectividad y competitividad, el software debe mantener el ritmo. En algunos casos, esto implica la creacin
de mayores y nuevos sistemas basados en computadora. 1 Pero, en muchos otros,
significa la modificacin o reconstruccin de las aplicaciones existentes.
En este captulo se examina la reingeniera en forma descendente, comenzando
con un breve panorama de la reingeniera de procesos de negocio y despus se abordan con mayor detalle las actividades tcnicas que se llevan a cabo al realizar la
reingenierla del software.
La reingenieria de procesos de negocio (RPN) rebasa el mbito de las tecnologas de

la informacin y de la ingeniera del software. Entre las muchas definiciones (la
mayora un tanto abstracta) sugeridas para la RPN destaca una publicada en la revista Fortune [STE93]: "La bsqueda e implementacin de un cambio radical en el pro-
ceso de negocios para lograr resultados de vanguardia". Pero, cmo se lleva a cabo
la bsqueda y cmo se logra la implementacin? Ms importante an, cmo se
puede garantizar que el "cambio radical" sugerido conducir a "resultados de vanguardia" en lugar de caos organizacional?
1 La explosin de aplicaciones y sistemas basados en Web estudiados en la parte 3 de este libro es un
indicio de esta tendencia.
904
PARTE CINCO
TEMAS A V ~ EN INGENIERA DEL SOFTWARE
........
Enfr1111ar el mcilana con lo ideo de emplear los mtodos de ayer es visualizar la vida como una pcrimls!
31 .1.1
Procesos de negocios
Un proceso de negocio es "un conjunto de tareas lgicamente relacionadas que se

ejecutan para lograr un resultado de negocios especifico" [DAV90). Dentro del proceso de negocio, la gente, el equipo, los recursos materiales y los procedimientos del
negocio se combinan para producir un resultado especfico. Los ejemplos de procesos de negocios incluyen el diseo de un nuevo producto, la compra de servicios y
suministros, la contratacin de un nuevo empleado y el pago a proveedores. Cada
uno demanda un conjunto de tareas y tambin emplea diversos recursos dentro del
Como ingeniero de
software, su lTobajo lo
desempeo en lo base
de estrJ ;erorqu{o. Sin
embargo, asegrese
de que alguien ho
pensado setK1111Mfe
MI fM niv/os sup,riores. Si esto no ha
ocvmdo, su lroboJO
esro en nesgo.
negocio.
cada proceso de negocio tiene un cliente definido: una persona o grupo que recibe el resultado (por ejemplo, una idea, un informe, un diseo, un producto). Adems,
los procesos de negocios traspasan las fronteras de la organizacin. Esto requiere
que diferentes grupos de organizaciones participen en las "tareas lgicamente relacionadas" que definen el proceso.
En el captulo 6 se indic que todo sistema es en realidad una jerarquia de subsistemas. Un negocio no es la excepcin. cada sistema de negocio (tambin llamado una funcin negocio) est compuesto de uno o ms procesos de negocio, y a cada
proceso de negocio lo define un conjunto de subprocesos.
La RPN se puede aplicar en cualquier nivel de la jerarqua, pero conforme se
ampla su mbito (es decir, conforme uno se mueve hacia arriba en la jerarqula) los riesgos asociados con ello crecen sustancialmente. Por esta razn, la mayoria de los
esfuerzos de la RPN se enfoca en procesos individuales o subprocesos.

'111 proalO 51 nos presento oigo viejo en uno cosa nueva, nos tranquilizamos:
F.W.llltrrw
31 .1.2 Un modelo de RPN

-oceKO eleinfonnociaa
II RPN se
ideenaimuen
........
wwwJiirttt.aa/
Como la mayora de las actividades de ingeniera, la reingenieria de procesos de

negocio es iterativa. Las metas del negocio y los procesos con que se logran se
deben adaptar a un entorno de negocios cambiante. Por esta razn no existe principio ni fin para la RPN: se trata de un proceso evolutivo. En la figura 31.1 se muestra
un modelo de reingeniera de procesos de negocio. El modelo define seis actividades.
Definicin del negocio. Las metas del negocio se identifican denle el contexto
de cuatro controladores clave: reduccin de costo, reduccin de tiempos, mejora de
la calidad y desarrollo y fortalecimiento del personal. Es posible definir las metas al
nivel del negocio o respecto de un componente especfico del negocio.
Identificacin del proceso. Se identifican los procesos cruciales para lograr las
metas precisadas en la definicin del negocio. Luego podra clasificarse de acuerdo
CAPTULO 31
REINGENJEruA
905
con su importancia, necesidad de cambio o en cualquier otra forma que sea adecuada para la actividad de reingeniera.
Evaluacin del proceso. El proceso existente se analiza y mide exhaustivamente. Se identifican las tareas del proceso; se anotan los costos y el tiempo que consumen las tareas del proceso; y se aslan los problemas de calidad y desempeo.
Especificacin y diseo del proceso. Con base en la retroalimentacin obtenida durante las primeras tres actividades de la RPN, se preparan casos de uso (captulo 7) para cada proceso que ser rediseado. En del contexto de la RPN los casos
de uso identifican un escenario que entrega cierto resultado a un cliente. Con el cas de
uso como la especificacin del proceso se disea un nuevo conjunto de tareas para
el proceso.
Elaboracin de prototipos. Un proceso de negocio rediseado debe convertirse en prototipo antes de que sea integrado por completo en el negocio. Esta actividad "prueba" el proceso de modo que puedan llevarse a cabo refinamientos.
Refinamiento y particularizacin. Con base en la retroalimentacin del prototipo, el proceso de negocio se refina y luego se particulariza dentro de un sistema
de negocio.
En ocasiones, estas actividades de RPN se utilizan junto con las herramientas de
anlisis de flujo de trabajo. La finalidad de estas herramientas es elaborar un modelo de flujo de trabajo prctico, esfuerzo encaminado a analizar mejor los procesos
existentes. Adems, para implementar las primeras cuatro actividades descritas en
el modelo de proceso se pueden aplicar las tcnicas de modelado usualmente asociadas con las actividades de ingenieria de procesos de negocio (captulo 6) .
ifalP.fih
Modelo de RPN.
Definicin del
negocio
Refinamiento e
instonciocin
(personolizocin)
Eloborocin de
prototipos
Especilicocin
y diseo de
procesos
ldentificocin
de procesos
E-.oluocin de
procesos
906
PARTE CIN CO
TEMAS AVANZADOS
EN INGENJER!A DEL SOFTWARE
"
Reingenlera de procesos de negocio (RPN)
Objetivo: El objetivo de los herramientas de
lo RPN es apoyar el onlisis y lo evoluoci6n de

los procesos de negocio existentes y lo especificacin y el
eWork, desarrollado por Metastorm

(www.metostorm.com), opoyo lo gestin de procesos
de negocios en procesos manuales y automatizados.
diseo de unos nuevos.

Mecnica: lo mecnico de los herramientas varo. En
general, los herramientas de lo RPN permiten que un
lceTools, desarrollados por Blue Ice (www.blueice.com), es
analista de negocios modele los procesos de negocio

existentes en un esfuerzo destinado o evaluar los
ineficiencias del Rujo de trabajo o problemas funcionales.
Uno vez que se identifican los problemas existentes los
herromientos permiten que los onolistas elaboren
prototipos o simu1en procesos de negocio revisodos.
SpeeDev, desarrollado por NimbleStar Group
Extend, desarrollado por lmoginelhot, lnc.

(www.imoginethotinc.com), es uno herramienta de
simulacin poro el modelado de procesos existentes y
lo exploracin de unos nuevos. Extend proporciono
uno extenso capacidad "si. .. entonces" que permite
que un analista de negocios explore diferentes~
de proceso.
uno coleccin de plantillas de RPN poro Microsoft

Office y Microsoft Project.
(www.nimblestar.com), es uno de muchos herramientas
que permiten que uno organizacin modele Aujos de
trabajo de procesos (en este coso, Rujo de trabajo de
TI).
Workllow iools, desarrollados por MetaSoftwore
(www.metosoftwore.com), incorporo un conjunto de
herramientas poro modelado, simulacin y
colendorizocin del Rujo de trabajo.
Uno listo til de vnculos o herramientas de RPN se puede
encontrar en http:/ /www.donold
firesmith.com/Components/Produc81'$/Tools/BusinessProce
ssReengineeringTools.html.
El escenario es tan comn: una aplicacin ha cubierto las necesidades de negocios

de una compaia durante 10 o 15 aos. Durante ese lapso se ha corregido, adaptado y mejorado muchas veces. El personal enfrent este trabajo con las mejores
intenciones, pero las buenas prcticas de ingeniera del software siempre fueron
soslayadas (debido a la presin de otros asuntos importantes). Ahora la aplicacin
es inestable. Todava funciona pero, cada vez que se intenta un cambio, ocurren
efectos colaterales, inesperados y serios. Y la aplicacin todavia tiene que evolucionar. Qu hacer?
El software al cual no se le puede dar mantenimiento no es un problema nuevo.
De hecho, la importancia cada vez mayor que se le concede a la reingenierfa del software la han impulsado los problemas en el mantenimiento del software que han ido
creciendo durante ms de 40 aos.
Las herramientas expuestas el autor no las respalda; slo representan una muestra de las herramientas incluidas en esta categora. En la mayora de los casos, los nombres de las herramientas
son marcas registradas por sus respectivos desarrolladores.
CAPTULO 31
907
REINGENJERA
31.2.l Mantenimiento del software

Durante las tres dcadas pasadas el mantenimiento del software se caracteriz
[CAN72J como un "iceberg". Se esperaba que lo inmediatamente visible fuese todo
lo que haba, pero se saba que bajo la superficie se encontraba una enorme masa
de problemas y costos potenciales. A principios del decenio de 1970, el mantenimiento del iceberg era suficientemente grande como para hundir un portaaviones.
En la actualidad, ifcilmente podra hundir a toda la marina!
El mantenimiento del software existente explica casi el 60 por ciento del esfuerzo que emplea una organizacin de desarrollo, y el porcentaje contina elevndose
conforme se produce ms software LHAN93J. Los lectores con escasos conocimientos sobre el tema podran preguntarse por qu se requiere tanto mantenimiento y
por qu se dedica tanto esfuerzo. Osbome y Chikofsky [OSB90) ofrecen una respuesta parcial:
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 mayoa no lo eran]. se crearon cuando el tamao de los programas y el espacio de almacenamiento eran las principales 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 considerar lo suficiente la arquitectura global. El resultado es estructuras mal diseadas, codificacin deficiente, lgica inadecuada y escasa documentacin de los sistemas de
software por los que ahora se nos llama para mantenerlos en operacin ...
Otra razn respecto del problema del mantenimiento del software es la movilidad
del personal. Es probable que el equipo (o persona) de software que realiz el trabajo original ya no est. Peor an, las generaciones subsecuentes de personal han
modificado el sistema y lo han daado. En la actualidad, tal vez no haya nadie que
tenga algn conocimiento directo del sistema heredado.
Como se indic en el captulo 27, la naturaleza ubicua del cambio subyace en
todo el trabajo de software. El cambio es inevitable cuando se construyen sistemas
basados en computadora; en consecuencia, se deben desarrollar mecanismos para
evaluar, controlar y efectuar modificaciones.
i.a fedlidad de mantenimiento de los programas y lo romprensibilidod de los programas son conceptos patalelcis:
IIIIIIIS mOs cfifkil sea comprender un progromo, ms dificil ser su montenimienlo."
GeraWlerns
Despus de leer los prrafos anteriores un lector podra protestar: "Pero yo no
paso el 60 por ciento de mi tiempo componiendo errores en los programas que desarrollo". Desde luego, el mantenimiento del software es mucho ms que "componer errores". Es posible definir el mantenimiento describiendo cuatro actividades
[SWA76J que se realizan despus de que un programa es liberado para su utilizacin.
908
PARTE CINCO
~
~~
El mantenimiento del software se define identificando cuatro actividades diferentes:

mantenimiento correctivo, mantenimiento adaptativo, mejora o mantenimiento de
perfeccionamiento y mantenimiento preventivo o reingeniera. Slo cerca del 20 por
ciento del trabajo de mantenimiento se emplea en "componer errores". El restante
80 por ciento se dedica a adaptar los sistemas existentes a los cambios en su entorno externo, realizar las mejoras que solicitan los usuarios y redisear una aplicacin
para usarla en lo futuro. Al considerar que el mantenimiento incluye todas estas actividades es relativamente sencillo observar por qu absorbe tanto esfuerzo.
clilv1
El mantenimiento del
software incluye cuotra

actividades: co,reccin
de enor, adaptacin,
mejola yreingenierlo.
TEMAS AVANI.AD(;f, EN INGENJERiA DEL SOFTWARE
31.2.2 Un modelo de procesos de reingeniera del software
bi ii HN','Ha
Uno excelenre fuente
de !llfommn lkettO
de lo reingeniero del
softworese pede
encontrru ea
La reingeniera requiere tiempo, cuesta cantidades significativas de dinero y absorbe recursos que de otro modo se ocuparan en problemas inmediatos. Por todas
estas razones la reingeniera no se logra en unos cuantos meses, ni siquiera en unos
cuantos aos. La reingeniera de los sistemas de informacin es una actividad que

absorber recursos de la tecnologa de la informacin durante muchos aos. Por
tanto, toda organizacin necesita una estrategia pragmtica respecto de la reingenierfa del software.
El modelo de proceso de reingeniera incluye una estrategia operativa. El modelo
se tratar ms adelante en esta seccin, pero primero se presentarn algunos principios bsicos.
La reingeniera es una actividad de reconstruccin, y la reingeniera de los sistemas de informacin se comprende mejor si se considera una actividad anloga: la
reconstruccin de una casa. Considrese la siguiente situacin.
El lector compra una casa en otro estado. En realidad nunca ha visto la propie-
dad, pero la adquiri en un precio sorprendentemente bajo, con la advertencia de
que tal vez tenga que reconstruirse por completo. Cmo se precederla?
Antes de que se pueda iniciar la reconstruccin sera razonable inspeccionar

la casa. Determinar si es necesario reconstruirla requiere que el lector (o un
inspector profesional) elabore una lista de criterios de modo que la inspeccin
resulte sistemtica.
Antes de tirar y reconstruir toda la casa se debe tener la certeza que la estructura es dbil. Si la casa es estructuralmente slida tal vez sea posible "remodelarla" sin reconstruirla (a un costo mucho ms bajo y en mucho menos tiempo).
Antes de iniciar la reconstruccin se debe tener la certeza de que se entiende
cmo se construy la original. Eche un vistazo detrs de las paredes. Entienda
el alambrado, la plomera y los componentes estructurales. Incluso si se tiran
todos a la basura, la comprensin que se adquiera ser til cuando comience
la construccin.
Si se comienza a reconstruir slo se utilizarn los materiales ms modernos y
de larga duracin. Esto puede costar un poco ms ahora. pero ayudar a
evitar un mantenimiento costoso y tardado ms adelante.
CAPTULO 31
REINGENIERA
909
S se decide reconstruir es preciso disciplinarse en cuanto a ello. Utilcense

prcticas que redundarn en aJta calidad, hoy y maana.
Aunque estos principios se enfocan en la reconstruccin de una casa, tambin se
aplican igualmente bien a la reingeniera de sistemas y aplicaciones basadas en
computadoras.
La implementacin de estos principios requiere aplicar un modelo de proceso de
reingeniera del software que define seis actividades, como se muestra en la figura
31.2. En algunos casos dichas actividades ocurren en una secuencia lineal, pero ste
no siempre es el caso. Por ejemplo, tal vez la ingeniera inversa (comprender el funcionamiento interno de un programa) tenga que ocurrir antes de que comience la
reestructuracin de documentos.
El paradigma de reingeniera que se muestra en la figura es un modelo cclico.
Esto significa que cada una de las actividades presentadas como parte del paradigma pueden volver a visitarse. En algn ciclo particular el proceso quiz termine despus de cualquiera de dichas actividades.
Anlisis de inventarios. Las organizaciones de software deberan tener un inventario de todas sus aplicaciones. El inventario tal vez no sea ms que un modelo en
una hoja de clculo que contenga informacin que proporcione una descripcin
detallada (por ejemplo, tamao, edad, importancia para el negocio) de las aplicaciones activas. Al ordenar esta informacin -de acuerdo con la importancia para el
negocio, antigedad, facilidad actual de mantenimiento y otros criterios localmente
importantes- aparecen los candidatos para reingeniera. Entonces se pueden asignar los recursos a las aplicaciones candidatas para el trabajo de reingenera.
ifrHfif
Modelo de
proceso de la
reingeniera del
software.
Ingeniera
avanzado
Reestructuracin
de los datos
inverso
910
PARTE CINCO
floNsEJ05'
Es importante sealar que el inventario deber visitarse con regularidad. El estado

de las aplicaciones (por ejemplo, importancia respecto del negocio) puede cambiar
en funcin del tiempo y, como resultado, cambiarn las prioridades para la reinge-
Si el tiempo y los
recursos eslOsean,
puede considerar Jo
aplicacin del principio
de Poreto al software
que ser sometido o
ingeniera. Aplique el
proceso de reingenierla ol 20 por cien/o
del software que
explico el 80 por
ciento de los
problemas.
Cree solamente tonto

documenfvcin como
necesite poro
entender el software,
ni uno pbgioo ms.
TEMAS AVAN'l.AfX)S EN INGENIERA DEL SOFIWAR.E
niera.
Reestructuracin de documentos. La documentacin dbil es la marca de muchos sistemas heredados. Pero qu se hace acerca de ello? Cules son las opciones?
1. Crear documentacin consume muchsimo tiempo. Si el sistema funciona vivir
con lo que se tenga. En algunos casos ste es el enfoque correcto. No es posible recrear documentacin para cientos de programas de computadora. Si un
programa es relativamente esttico est llegando al final de su vida til, por lo
que es improbable que experimente un cambio significativo, djelo ser!
2. La. documentacin debe actualizarse, pero se tienen recursos limitados. Se utilizar un enfoque de "documentar cuando se toque". Tal vez sea innecesario
volver a documentar por completo la aplicacin. En cambio, se documentan
completamente aquellas porciones del sistema que en la actualidad experimentan cambios. Con el tiempo evolucionar una coleccin de documentacin til y relevante.
3 . El sistema es crucial para el negocio y debe volver a documentarse por completo.
Incluso en este caso un enfoque inteligente es recortar la documentacin a un

mlnimo esencial.
CD.da una de estas opciones es viable. una organizacin de software debe elegir la
ms apropiada para cada caso.
Ingeniera inversa. El trmino ingeniera inversa tiene sus orgenes en el mundo

del hardware. Una compaa desensambla un producto de hardware de un competidor con la finalidad de comprender sus "secretos" de diseo y fabricacin. Tales
secretos podran comprenderse fcilmente si se obtuviesen las especificaciones de
diseo y fabricacin del competidor. Pero dichos documentos estn patentados y no
estn disponibles para la compaa que realiza la ingeniera inversa. En esencia, la
ingeniera inversa exitosa obtiene una o ms especificaciones de diseo y fabricacin para un producto cuando se examinan especmenes reales del producto.
La ingeniera inversa para el software es bastante similar. Sin embargo, en ambos
casos el programa objeto de la ingeniera inversa no es el de un competidor, sino el
trabajo de la propia compaa (con frecuencia elaborado muchos aos atrs). Los
"secretos" que se comprendan sern oscuros, pues nunca se desarroll una especificacin. Por lo tanto, la ingeniera inversa del software es el proceso de analizar un
programa con la finalidad de crear una representacin del programa en un mayor
grado de abstraccin que el cdigo fuente. La ingeniera inversa es un proceso de
recuperacin de diseo. Las herramientas de la ingeniera inversa obtienen infor-
CAPTULO 31
Un onlenomieillo de
ream J111 lo
(Oll1irlod de '1'
--~pullde
............
'""""''
citenre11
llllilscN/.
REINGEN!ERA
911
macin del diseo de datos, arquitectnico y de procedimientos a partir de un programa existente.

Reestructuracin de cdigo. El tipo ms comn de reingeniera (en realidad, en
este caso el empleo del trmino reingenieria es cuestionable) es la reestructuracin
de cdigo. 3 Algunos sistemas heredados tienen una arquitectura de programa relativamente slida, pero los mdulos individuales se codificaron en una forma que dificulta comprenderlos, probarlos y mantenerlos. En tales casos se puede reestructurar
el cdigo dentro de los mdulos sospechosos.
Llevar a cabo esta actividad requiere analizar el cdigo fuente empleando una
herramienta de reestructuracin. Se indican las violaciones de las estructuras de
programacin estructurada y entonces el cdigo se reestructura (esto se puede hacer
automticamente). El cdigo reestructurado resultante se revisa y prueba para
garantizar que no se han introducido anormalidades. La documentacin del cdigo
interno se actualiza.
Reestructuracin de datos. Un programa con una arquitectura de datos dbil
ser dificil de adaptar y mejorar. De hecho, en muchas aplicaciones la arquitectura
de datos est ms relacionada con la viabilidad a largo plazo de un programa que el
cdigo fuente.
A diferencia de la reestructuracin de cdigo, que ocurre en un grado relativamente bajo de abstraccin, la reestructuracin de datos es una actividad de reingeniera a gran escala. En la mayora de los casos, la reestructuracin de datos
comienza con una actividad de ingeniera inversa. La arquitectura de datos actual se
analiza con minuciosidad y se definen los modelos de datos necesarios (capitulo 9).
se identifican los objetos de datos y los atributos, y despus se revisa la calidad de
las estructuras de datos existentes.
Cuando la estructura de datos es dbil (por ejemplo, actualmente se implementan
archivos planos, cuando un enfoque relacional simplificara enormemente el procesamiento), los datos se someten a reingeniera.
Puesto que la arquitectura de datos tiene una fuerte influencia sobre la arquitectura del programa y los algoritmos que lo pueblan, los cambios a los datos invariablemente resultarn en cambios arquitectnicos o al nivel de cdigo.
Ingenieria directa. En un mundo ideal, las aplicaciones se reconstruiran empleando un "motor de reingenieria" automatizado. El programa antiguo sera insertado
en el motor, analizado, reestructurado y luego regenerado en una forma que exhibiese los mejores aspectos de la calidad del software. A corto plazo es improbable
que tal "motor" aparezca, pero las empresas han introducido herramientas que
mejoran un limitado subconjunto de dichas capacidades que aborden dominios de
aplcacin especficos (por ejemplo , las apbcaciones que se implementan mediante
La reestructuracin de cdigo tiene algunos de los elementos de "refactorizacin", un concepto de

rediseo introducido en el capitulo 4 y tratado en otras partes de este libro.
912
PARTE CINCO TEMAS AVANZ.AJX)S EN INGENIERA DEL SOFTWARE
un sistema de base de datos especfico). Ms importante, dichas herramientas de

reingeniera se estn volviendo cada vez ms sofisticadas.
La ingeniera directa, tambin llamada renovacn o reclamacin [CHI90L no slo
recupera la informacin de diseo a partir del software existente, tambin utiliza
esta informacin para alterar o reconstituir el sistema existente con la finalidad de
mejorar su calidad global. En la mayora de los casos el software sometido a reingeniera vuelve a implementar la funcin del sistema existente y tambin aade nuevas
funciones o mejora el desempeo global.
La ingeniera inversa invoca una imagen de "ranura mgica". En la ranura se inserta
una lista fuente sin documentar y diseado casualmente, y del otro extremo sale una
descripcin (y toda la documentacin) completa del diseo para el programa de
computadora. Desdichadamente, la ranura mgica no existe. La ingeniera inversa
puede obtener informacin de diseo a partir del cdigo fuente, pero el grado de abstraccin, la completud de la documentacin, el grado en el que las herramientas y
un analista humano trabajan en conjunto, y la direcconalidad del proceso son enormemente variables.
El grado de abstraccin de un proceso de ingeniera inversa y las herramientas uti-
lizadas para efectuarlo se refieren a la sofisticacin de la informacin del diseo que

es posible obtener del cdigo fuente. Idealmente, el grado de abstraccin debe ser
tan alto como sea posible. Esto es, el proceso de ingeniera inversa debe ser capa z
de derivar representaciones de diseo de procedimiento (un grado de abstraccin
bajo) 1 informacin de estructura de programa y datos (un grado de abstraccin un
poco ms elevado), modelos de objeto, modelos de flujo de datos o control (un grado
de abstraccin relativamente alto) y clases UML, diagramas de estado y despliegue
(un grado alto de abstraccin) . Conforme el grado de abstraccin aumenta, el ingeniero de software obtiene informacin que le permitir comprender con ms facilidad el programa.
La completud de un proceso de ingeniera inversa se refiere al grado de detalle que
se ofrece en un grado de abstraccin. En la mayora de los casos, la integridad disminuye conforme el grado de abstraccin aumenta. Por ejemplo, dada una lista del
cdigo fuente, es relativamente sencillo desarrollar una representacin completa
del diseo del procedimiento. Tambin se pueden derivar representaciones sencillas
de diseo, pero es mucho ms dificil desarrollar un conjunto completo de diagramas
o modelos UML.
La completud mejora en proporcin directa con la cantidad de anlisis que efecta quien realiza la ingeniera inversa. La interactividad se refiere al grado en el que
el ser humano est "integrado" con las herramientas automatizadas para crear un
proceso de ingeniera inversa efectivo. En la mayora de los casos, conforme aumenta el grado de abstraccin la interactividad debe aumentar o la completud sufrir.
CAPnJLO 31 REINGENIERiA
913
ifaiUfii
Proceso de
ingerera
inversa.
Cdigo fuente sucio
~
~
ExlrOCQn d
ab$'1CICC1~s
Especificaci6n inicial
RefinomienlO y
$1MpljfkaciQn
--~,
c&v1
Se deben obordor tres

temas de lo ingenierto
inversa: grado de
obstraccin, integridad
y direccionolidod.
Especificacin final
Si la direccionalidad del proceso de ingeniera inversa es unidireccional, to1a la

informacin extrada del cdigo fuente se ofrece al ingeniero de software que e1 'tonces puede usarla durante cualquier actividad de mantenimiento. Si la direccionatidad
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 extraccin de abstracciones. El ingeniero debe evaluar el programa antiguo y, a partir del cdigo fuente
(con frecuencia sin documentar), desarrollar una especificacin significativa del procesamiento 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. l
Ingeniera inversa para comprender los datos
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 motor de rttStructuracin, una herramienta que reestructura cdigo fuente.
914
PARTE CINCO
TEl'v!AS AVANZADOS EN INGENIERA DEL SOFTWARE
como parte de un esfuerzo global de reingeniera. En el nivel del sistema las estructuras globales de datos (por ejemplo, archivos, bases de datos) con frecuencia se
someten a reingenieria para ajustarlos con los nuevos paradigmas de gestin de
bases de datos (por ejemplo, el movimiento desde los archivos planos hacia los sistemas de bases de datos relacionales u orientados a objetos) . La ingeniera inversa
de las actuales estructuras globales de datos establece el escenario para la introduccin de una nueva base de datos que abarque todo el sistema.
Los compromisos
aparentemente insignificantes en los
estrocturos de daros
pueden conducir o
problemas potencio/mente cafl1str6ficos en
aos futuros.
Considere como
e;emplo el problema
Y2K.
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 programa relacionadas. En muchos casos, la organizacin de los datos dentro del cdigo identifica tipos abstractos de datos. Por ejemplo, estructuras de registro, archivos,
listas y otras estructuras de datos con frecuencia ofrecen una indicacin inicial de las
clases.
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 reingenieria de un esquema de base de datos en otro requiere comprender los objetos existentes 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 candidatos 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 inversa para comprender el procesamiento

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 interoperabilidad 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 interaccin entre dichas abstracciones funcionales. Cada componente realiza alguna
CAPiTuLO 31
915
REINGENIERA
subfuncin y representa una abstraccin de procedimiento definida. Para cada componente se desarrolla una narrativa de procesamiento. En algunas situaciones ya
existen especificaciones del sistema, el programa y los componentes. Cuando ste
es el caso, las especificaciones se revisan para verificar si concuerdan con el cdigo
existente.5
:"frdde a pasi6il por la (01'11!)1'911Si, os como existe uno por lo m!.icd. Dkha pasin es mnomil lll
,,~,..mtls tarcll $1 pilllle en la mayora de los personas."
wllilios,
Las cosas se complican ms cuando se considera el cdigo dentro de un componente. El ingeniero busca las secciones de cdigo que representen patrones de procedimiento genricos. Casi en cada componente una seccin del cdigo prepara los
datos para el procesamiento (dentro del mdulo), una seccin diferente de cdigo
realiza el procesamiento y otra seccin del cdigo prepara los resultados del procesamiento para exportarlos desde el componente. Dentro de cada una de estas secciones se pueden encontrar pequeos patrones; por ejemplo, la validacin de los
datos y la verificacin de enlaces con frecuencia ocurre dentro de la seccin de cdigo que prepara los datos para el procesamiento.
En sistemas grandes la ingeniera inversa, por lo general, se logra utilizando un
enfoque semiautomatizado. Las herramientas automatizadas se utilizan para ayudar
al ingeniero de software a comprender la semntica del cdigo existente. Entonces
la salida de este proceso pasa a la reestructuracin y a las herramientas de ingeniera avanzada para completar el proceso de reingeniera.
31.3.3 Ingeniera inversa de interfaces de usuario
Las IGU sofisticadas ahora son indispensables en productos basados en computadora y en sistemas de todo tipo. En consecuencia, desarrollar de nuevo las interfaces
de usuario se ha vuelto uno de los tipos ms comunes de actividad de reingeniera.
Pero antes de que una interfaz de usuario se pueda reconstruir deber realizarse una
actividad de ingeniera inversa.
Entender por completo una interfaz de usuario existente requiere especificar la
estructura y el comportamiento de la interfaz. Merlo y sus colegas [MER93l sugieren
tres preguntas bsicas que se deben responder conforme comienza la ingeniera
inversa de la IGU:
Cules son las acciones bsicas (por ejemplo, presiones de tecla o clics de
ratn) que debe procesar la interfaz?
Con frecuencia, las especificaciones escntas en las primeras etapas en la historia de vida de un programa nunca se actualizan. Conforme los cammos se realizan, el cdigo ya no concuerda ms con
las especificaciones.
PARTE C INCO TEMAS AVANZADOS EN INGENJ.EruA DEL SOFIWARE
916
Cul es la descripcin compacta de las respuestas de comportamiento del

sistema a estas acciones?
Cmo
entender las
fun<iunes de una
interfaz de usuario existente?
Qu se entiende por "reemplazo" o, ms exactamente, qu concepto de equivalencia de interfaces es relevante en este caso?
La notacin de modelado de comportamiento (captulo 8) puede ofrecer un medio
para desarrollar respuestas a las primeras dos preguntas. Gran parte de la informacin necesaria para crear un modelo de comportamiento se puede obtener observando la manifestacin externa de la interfaz existente. Pero la informacin adicional
necesaria para crear el modelo de comportamiento se debe extraer del cdigo.
Es importante sealar que una GUI de reemplazo tal vez no refleje exactamente
la interfaz antigua (de hecho, quiz sea radicalmente diferente). Con frecuencia vale la
pena desarrollar nuevas metforas de interaccin. Por ejemplo, una GUI antigua
solicita que un usuario proporcione un factor de escala (que vara desde 1 hasta l O)
para encoger o ampliar una imagen grfica. Una GUI sometida a reingenieria puede
utilizar una barra de deslizamiento y un ratn para realizar la misma funcin.
~ IngenJera inversa
~ Objetivo: Ayudar o los ingenieros de software
o comprender lo estructuro de diseo interno de
los programas complejos.
Mecnica: En lo mayora de los cosos, los herramientas

de in9eniero inverso aceptan cdigo fuente como entrado
y producen uno diversidad de representaciones de diseo
astruclurol, procodimionto, dotos y comportomiento.
lmo9ix 4D, desorrollodo por lmogix (www.imogix.com),
Moyudo o los desarrolladores de software o comprender
software C y C++ complejo o heredado" a l someter o inge

niero inverso y documentar el cdigo fuente.
Understand,
desarrollado por Scientific Toolworks, lnc.

(www.sci tools.com), analizo gramaticalmente Ada,
Fortran, C, C++ y Javo Nporo realizar ingeniera inver
so, documentar outomticomente, calcular mtricos de
cdigo y auxiliarlo o comprender, navegar y mantener
el cdigo fuente".
Uno extenso listo de herramientas de ingeniera inverso se

puede encontrar em http://scgwiki.iom.unibe.ch:8080/
SCG/370.
La reestructuracin de software modifica el cdigo fuente o los datos con la finali-
dad de adecuarlos para futuros cambios. En general, la reestructuracin no modifica la arquitectura global del programa. Tiende a enfocarse sobre los detalles de diseo
de los mdulos individuales y en las estructuras de datos locales definidos dentro de
los mdulos. Si el trabajo de reestructuracin se extiende ms all de las fronteras
6
Las herramientas expuestas el autor no las respalda, slo representan una muestra de las herramientas incluidas en esta categora. En la mayora de los casos, los nombres de las herramientas
son marcas registradas por sus respectivos desarrolladores.
CAPTULO 31
REINGENIERIA
917
del mdulo y abarca la arquitectura del software, la reestructuracin se convierte en

ingeniera avanzada (seccin 31 .5).
La reestructuracin ocurre cuando la arquitectura bsica de una aplicacin es
slida, aun cuando el interior tcnico necesite trabajarse. Se inicia cuando grandes
partes del software son funcionales y slo un subconjunto de los componentes y
datos necesitan una modificacin extensa. 7
31.4.1
Reestructuracin del cdigo
La reestructuracin del cdigo se realiza para generar un diseo que produzca la
('0NS1Jo9"
Aunque la reestruc/lJrocin del cdigo
puede aliviar inmediatomente los
problemas asociados
con lo depuracin o
los cambios
pequeos, esto no es
reingenierfo. El
beneficio real se logro
slo cuando se rees
tructuran los datos y
lo arquiteclUro.
misma funcin que el programa original, pero con mayor calidad. En general, las tcnicas de reestructuracin de cdigo (por ejemplo, tcnicas de simplificacin lgica
de Warnier [WAR74]) modelan la lgica del programa utilizando lgebra booleana y
luego aplican una serie de reglas de transformacin que producen lgica reestructurada. El objetivo es tomar el "tazn de espagueti" de cdigo y derivar un diseo de
procedimiento que concuerde con la filosofia de la programacin estructurada (captulo 11).
Tambin se han propuesto otras tcnicas de reestructuracin para utilizarlas con
las herramientas de rengenieria. Un diagrama de intercambio de recursos correlaciona cada mdulo de programa y los recursos (tipos de datos, procedimientos y
variables) que se intercambian entre ellos y otros mdulos. Mediante la creacin de
representaciones del flujo de recursos se puede reestructurar la arquitectura del programa para lograr mnimos acoplamientos entre mdulos.
31 .4.2 Reestructuracin de los datos

Antes de comenzar la reestructuracin de datos se debe llevar a cabo una actividad
de ingeniera inversa denominada anlisis del cdigo fuente. Primero se evalan
todos los enunciados del lenguaje de programacin que contengan definiciones de
datos, descripciones de archivos, 1/0 y descripciones de interfaz. La finalidad es
extraer elementos y objetos de datos para obtener informacin acerca del flujo de
datos y comprender las estructuras de datos existentes que se han implementado.
Esta actividad a veces se denomina anlisis de datos [RIC89].
Una vez completado el anlisis de datos comienza el rediseo de datos. En su
forma ms simple, un paso de estandarizacin de registro de datos clarifica las definiciones de datos para lograr consistencia entre los nombres de elementos de datos
o formatos de registro fisicos dentro de una estructura de datos existente o formato
de archivo. Otra forma de rediseo, denominada racionalizacin del nombre de los
datos asegura que todas las convenciones de nombramiento de los datos concuerdan con el estndar local y que los pseudnimos se eliminan como flujo de datos a
travs del sistema.
7 A veces es dificil distinguir entre reestructuracin extensa y volver a desarrollar. Ambos son reingeniera.
PARTE CINCO
918
TEMAS AVANZ.AIX)S EN !NGENJE:RiA DEL SOF1WARE
Cuando la reestructuracin rebasa la estandarizacin y la nacionalizacin se realizan modificaciones fisicas a las estructuras de datos existentes para lograr que el
diseo de los datos sea ms efectivo. Esto puede significar una traduccin de un formato de archivo a otro o, en algunos casos, la traduccin desde un tipo de base de
datos a otro.
~ Reestructuractn de software
liii.I
Objetivo: El objetivo de los herromientos de
uno diversidad de capacidades de reestructuracin

poro COBOL, C/C++, Javo, FORTRAN 90 y VHDL.
reestructuracin es tronsformor el ontiguo software de computodoro corente de estructuro en lenguajes

de progromocin y estructvros de diseo modernos.
FORESYS, desorrolloda por Simulog (www.simulog.fr),
Mecnica: En genero!, el cdigo fuente se ingreso y trons
Function Encapsulation Too/, desarrollado en la Wayne
formo en un mejor programo estructurado. En algunos

cosos, lo tronsformocin ocurre dentro del mismo lenguaje
de progromocin. En otros cosos, un lenguaje de programo
cin ontiguo se transformo en un lenguaje ms moderno.
Herramientas representativos
DMS Software Reengineering Too/kit, desarrollada por

Semantic Design (www.semdesigns.com), proporciona
onolizo y transformo programas escritos en FORTRAN.

Stote University
(www.cs.woyne.edu/-vip/RefoctoringTools/), refoctori
za en C++ los antiguos programas en C.
p/usfORT, desarrollada por Polyhedron (www.polyhedron.
com), es un conjunto de herramientas de FORTRAN
que tiene copocidades poro reestructvror en FORTRAN
moderno o C estndar los progromos en FORTRAN
deficientemente diseados.
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:
Qu opciones existen
cuando se enfren
ta un programa
deficientemente
diseado e implementado?
1. Se puede trabajar modificacin tras modificacin, luchando con el diseo implcito y el cdigo fuente para implementar los cambios necesarios.
2. Se puede intentar comprender el extenso funcionamiento interno del programa 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.
Las herramientas expuestas slo representan una muestra de esta categora. En la mayoria de los
casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores.
CAPTULO 3 1 REINGENJERiA
919
4 . se puede redisear, recodificar y probar el programa completamente empleando

herramientas de reingenieria como auxiliares para comprender el diseo ac
tual.
No existe una opcin individual "correcta". Las circunstancias pueden dictar la pri
mera opcin, incluso si las otras son ms deseables.
En lugar de esperar hasta que se reciba la solicitud de mantenimiento, la organi
zacin de desarrollo o soporte utiliza los resultados del anlisis de inventarios para
seleccionar un programa que 1l se emplear durante un nmero determinado de
aos, 2) aclualmente se utilice con xito, y 3) es probable que experimentar grandes modificaciones o mejoras en el futuro cercano. Entonces se aplican las opciones
2, 3 o 4.
Este enfoque de mantenimiento preventivo lo introdujo Miller [MJL8 l l con el nombre de retrofit estructurado. Este concepto se define como "la aplicacin de las metodologas de hoy a los sistemas del ayer para apoyar los requisitos del maana".
A primera vista, la sugerencia de que se desarrolle de nuevo un gran programa
cuando ya existe una versin operativa puede parecer bastante extravagante. Antes
de emitir un juicio, considrense los puntos siguientes:
1. El costo de mantener una linea de cdigo fuente tal vez oscile entre 20 y 40
veces el costo de su desarrollo inicial.
La reingenierio es muy
2 . El rediseo de la arquitectura de software (estructura de programa o datos)

empleando conceptos modernos de diseo puede facilitar enormemente el
mantenimiento futuro.
parecido olo limpieza
dento/. Puede pensar

en miles de razones
poro demorarlo, ylo
oplozor muchos
3 . Puesto que ya existe un prototipo del software, el desarrollo de la productividad debe ser mucho mayor que el promedio.
veces. Pero eventualmente SIJS tcticas

ti/atonas reg,escu(m
poro provocarle dolor.
4 . El usuario ahora tiene experiencia con el software. En consecuencia, los nuevos requisitos y la direccin del cambio pueden afirmarse con mayor facilidad.
5 . Las herramientas automatizadas para reingenieria facilitarn algunas partes
del trabajo.
6 . Antes de terminar el mantenimiento preventivo existir una configuracin

completa del solware (documentos, programas y datos).
Cuando una organizacin de desarrollo de software vende software como producto, el mantenimiento preventivo se considera como "nuevas liberaciones" de un
programa. Un gran desarrollador de software local (por ejemplo, un grupo de desarrollo de software para sistemas de negocios destinados a una gran compaa con
sumidora de productos) puede tener 500-2 000 programas de produccin dentro de
El trmino
rctrojit (literalmente retroajUStC) recibe muchas denommaciones en espaol,
entre las
que destacan remodelado. modem1zad6n retrocambio. reajuste. modificacin retroactiva. Para no

generar confusin con otros conceptos y dcnommaclones stmilares, pero no relacionados, utilizar
el trmino Original, que por lo dems es ICCXIIIOCidodentro del medio (N .T.)
920
PARTE CINCO
TEMAS AVANZADOS EN INGENIERiA DEL SOFIWARE
su dominio de responsabilidad. Dichos programas pueden clasificarse segn su

importancia y luego revisarlos como candidatos para mantenimiento preventivo.
El proceso de ingeniera avanzada aplica los principios, conceptos y mtodos de
la ingeniera del software para recrear una aplicacin existente. En la mayora de los
casos, la ingeniera directa no simplemente crea el equivalente moderno de un programa antiguo. Ms bien, los nuevos requisitos de usuario y tecnologa se integran
en el trabajo de reingeniera. El programa que se desarrolla de nuevo ampla las
capacidades de la aplicacin anterior.
31.5. l
Ingeniera directa para arquitecturas cliente/ servidor
Durante las dcadas pasadas muchas aplicaciones para computadora central se han
sometido a reingeniera para adaptarlas a arquitecturas cliente/servidor (incluso
WebApps). En esencia, los recursos de cmputo centralizados (que incluyen software) se distribuyen entre muchas plataformas cliente. Aunque se pueden disear
varios entornos distribuidos diferentes, la aplicacin tpica de computadora central
que se somete a reingeniera en una arquitectura cliente/servidor tiene las siguientes caractersticas:
La funcionalidad de la aplicacin migra hacia cada computadora cliente .
En los sitios cliente se implementan nuevas interfases IGU.

Las funciones de base de datos se asignan al servidor.
La funci onalidad especializada (por ejemplo, anlisis intenso de cmputo)
puede permanecer en el sitio servidor.

Tanto en los sitios cliente como servidor se deben establecer nuevos requisitos de comunicaciones, seguridad, archivado y control.
Es importante sealar que la migracin desde la computadora central hacia el cmputo cliente/servidor requiere reingeniera tanto de negocio como de software. Adems,
se debe establecer una "infraestructura de red de empresa" UAY94J.
La reingeniera para aplicaciones cliente/servidor comienza con un amplio an-
En algunos casos, lo
migracin hacia lo
arquitectura clienteservidor no debe
enfocarse como rei11geniero, sino como
un nuevo esfuerzo de
desarrollo. La reingeniero ingreso al
cuadro slo cuando lo
funcionalidad especf
fa del sistema
1111~ se integrar
en 6, /klel'!l orquitec-
lisis del entorno de negocios que incluye la computadora central existente. Se pueden identificar tres capas de abstraccin. La capa de base de datos pone los cimientos
de una arquitectura cliente/servidor y gestiona las transacciones y consultas desde
aplicaciones cliente. Aunque dichas transacciones y consultas se deben controlar
dentro del contexto de un conjunto de reglas de negocios (definidas mediante un
proceso de negocio existente o sometido a reingeniera). Las aplicaciones cliente
ofrecen la funcionalidad deseada para la comunidad de usuarios.
Las funciones del sistema de gestin de bases de datos existente y la arquitectura de datos de la base de datos existente deben someterse a ingeniera inversa como
precursores del rediseo de la capa de base de datos. En algunos casos se crea un
nuevo modelo de datos (captulo 8). En cada caso la base de datos cliente/servidor
se somete a reingeniera para garantizar que las transacciones se ejecutan en forma
CAPTULO 31
REJNGENIERA
92 1
consistente, que todas Jas actualizaciones las realizan slo usuarios autorizados,
que las reglas centrales del negocio se refuerzan (por ejemplo. antes de que se borre
el registro de una empresa el servidor se asegura de que no haya cuentas por pagar,
contratos o comunicaciones relacionados con dicha empresa), que las consultas se
pueden ajustar eficientemente y que se ha establecido una capacidad completa de
archivado.
La capa de reglas de negocios representa el sofhvare que reside tanto en el cliente como en el servidor. Este software realiza tareas de control y coordinacin para
garantizar que las transacciones y consultas entre la aplicacin cliente y la base de
datos se ajustan al proceso de negocios establecido.
La capa de aplicaciones cliente implementa funciones de negocios que requieren
grupos especficos de usuarios finales. En muchas instancias, una aplicacin de
computadora central se segmenta en varias aplicaciones de escritorio ms pequeas
y sometidas a reingeniera. La comunicacin entre las aplicaciones de escritorio
(cuando es necesario) se controla mediante la capa de reglas de negocios.
un estudio completo del diseo y la reingeniera del sofhvare cliente/servidor es

materia de libros especializados. El lector interesado debe consultar [VAN02] ,
lCOUOO) y [ORF99].
31.5.2 Ingeniera directa para mquitecturas orientadas a objetos

La ingeniera del software orientado a objetos se ha convertido en la alternativa en
cuanto al paradigma de desarrollo para muchas organizaciones de software. Pero,
qu hay acerca de las aplicaciones existentes que se desarrollaron empleando
mtodos convencionales? En algunos casos la respuesta es dejar tales aplicaciones
"como estn". En otros, las aplicaciones viejas deben someterse a reingeniera de
modo que se integren con facilidad en grandes sistemas orientados a objetos.
La reingeniera del software convencional en una implementacin orientada a
objetos utiliza muchas de las mismas tcnicas estudiadas en la parte 2 de este libro.
Primero, el software existente se somete a ingeniera inversa de modo que sea posible crear modelos de datos. funcionales y de comportamiento apropiados. Si el sistema de reingeniera ampla la funcionalidad o el comportamiento de la aplicacin
original, se crean casos de uso {captuJos 7 y 8). Luego los modelos de datos creados
durante la ingeniera inversa se utilizan junto con el modelado CRC (captulo 8) para
establecer la base con que se definirn las clases. Enseguida se definen las jerarquas
de clases, los modelos de relacin de objetos, los modelos de comportamiento de
objetos y los subsistemas y entonces comienza el diseo orientado a objetos.
Conforme la ingeniera directa orientada a objetos progresa desde el anlisis
hasta el diseo se puede invocar un modelo de proceso ISBC {captulo 30). Si la aplicacin antigua se encuentra en un dominio que ya ocupan muchas aplicaciones
orientadas a objetos, es probable que haya una buena biblioteca de componentes y
que se pueda utilizar durante la ingeniera directa.
PARTE CIN CO
TEMAS AVANU\DOS EN INGEN!EIA DEL SOFTWARE
En aquellas clases que daban construirse desde el principio tal vez sea posible
reutilizar algoritmos y estructuras de datos de la aplicacin convencional existente.
Sin embargo, quiz sea preciso disearlos de nuevo para ajustarlos a la arquitectura orientada a objetos.
31.5.3 Ingeniera directa de interfaces d e usuario

Conforme las aplicaciones migran de la computadora central hacia el escritorio, los
usuarios ya no desean tolerar las interfaces de usuario misteriosas basadas en caracteres. De hecho, una porcin significativa del trabajo empleado en la transicin de la
computadora central a la computacin cliente-servidor se puede dedicar a la reingeniera de las interfaces de usuario de la aplicacin cliente.
Merlo y sus colegas [MER95] sugieren el siguiente modelo para la reingeniera de
interfaces de usuario:
tc0Nsuo9'
Qu pasos se deben
seguir poro someter a
reingeniero uno
intenaz de usuorio?
1. Comprender la interfaz original y los datos que se trasladan entre ella y el resto de
la aplicacin. La finalidad es entender cmo otros elementos de un programa
interactan con el cdigo existente que implementa la interfaz. Si se desarrollar una nueva GUI, los datos que fluyan entre sta y el programa restante
deben ser consistentes con los datos que actualmente fluyen entre la interfaz
basada en caracteres y el programa.
2. Remodelar el comportamiento implcito en la interfaz existente en una serie de
abstracc10nes que tengan sentido en el contexto de una GU!. Aunque el modo de
interaccin puede ser radicalmenle diferente, el comportamiento de negocios

que muestran los usuarios de las interfases vieja y nueva (cuando se le considera en trminos de un escenario de utilizacin) debe permanecer igual. Una
interfaz rediseada deber permitir que un usuario muestre el comporta
miento de negocios apropiado. Por ejemplo, cuando se consulta una base de
datos la vieja interfaz puede requerir una larga serie de comandos basados en
t\i-il i:ilii:W)
Un monool de l1Il5 de
300 pgmos ocerct1 de
los miones de
reilgeme!lo
(desorro lodo cQ(ll()

parle del proyecto
FAMOOS ESPRIT) se
iaiede desrorgor desde

www.........
cf,/~scg/
Aldm/t-s/
patttns/Wex3.
......
texto para especificar la consulta. La GUI sometida a reingeniera puede dirigir

la consulta a una pequea secuencia de elecciones con el ratn, pero el propsito y el contenido de la consulta permanecen intactos.
3. Introducir mejoras que hagan ms eficiente el modo de interaccin. Las fallas er-
gonmicas de la interfaz existente se estudian y corrigen en el diseo de la

nueva GUI.
4. Construir e integrar la nueva GUI. La existencia de bibliotecas de clases y herramientas automatizadas puede reducir significativamente el trabajo requerido
para construir la GUI. Sin embargo, la integracin con el software de la aplicacin existente puede requerir ms tiempo. Debe tenerse cuidado de garantizar
que la GUI no propagar efectos colaterales adversos en el resto de la aplicacin.
"Puede pagar poco dinero ohoro, opuede pagar mucho dinero ms adelante:
Anuncio de taller me<nko que sugiere un ateste
CAPTULO 31
923
REINGENIERiA
En un mundo perfecto, cualquier programa al que no se le pudiera dar mantenimiento sera retirado inmediatamente, y sera sustituido por aplicaciones de mayor
calidad con reingeniera desarrollada empleando modernas prcticas de ingeniera
del software. Sin embargo, se vive en un mundo de recursos limitados. La reingeniera demanda recursos que pueden utilizarse para otros propsitos del negocio. En
consecuencia, antes de que una organizacin intente someter a reingeniera una
aplicacin existente, debe realizar un anlisis costo-beneficio.
Sneed [SNE95J ha propuesto un modelo de anlisis costo-beneficio para la reingeniera. Se definen nueve parmetros:
P1
= costo de mantenimiento anual actual para una aplicacin
P2 = costo de operacin anual actual para una aplicacin

P3 = valor de negocios anual actual de una aplicacin
P4 = costo de mantenimiento anual predicho despus de la reingeniera
P5 = costo de operacin anual predicho despus de la reingeniera
P6 = valor de negocios anual predicho despus de la reingeniera
P7 = costo estimado de la reingeniera
P8 = fecha estimada de la reingeniera
P9 = factor de riesgo de la reingeniera (P9 = 1.0 es el valor nominal)
L = vida esperada del sistema

El costo asociado con el mantenimiento continuo de una aplicacin candidata (es
decir, si la reingeniera no se realiza) se puede definir como
(31 - 1)
Los costos asociados con la reingeniera se definen empleando la siguiente relacin:

(31-2)
Con la utilizacin de los costos presentados en las ecuaciones (31 - 1) y (31 -2) el
beneficio global de la reingeniera se puede calcular como
costo beneficio
= Creing -
Cmant
(31-3)
El anlisis costo-beneficio presentado en las ecuaciones se puede realizar para todas

las aplicaciones de alta prioridad identificadas durante el anlisis de inventario (seccin 31.2.2). Aquellas aplicaciones que muestren el mayor costo-beneficio podrn
destinarse a la reingenierfa, mientras el trabajo con otras se puede posponer hasta
que haya recursos disponibles.
La reingeniera se presenta en dos diferentes grados de abstraccin. En el mbito del

negocio, la reingeniera se centra en el proceso de negocios con el propsito de efec-
PARTE CINCO
TEMAS AVANZADOS EN INGENIERA DEL SOF'IWARE
tuar los cambios para mejorar la competitividad en alguna rea del negocio. En el
mbito del software, la reingeniera examina los sistemas y aplicaciones de informacin con la finalidad de reestructurarlos o reconstruirlos de modo que muestren
mayor calidad.
La reingeniera de procesos de negocio (RPN) define metas del negocio, identifica
y evala los procesos de negocios existentes (en el contexto de metas definidas),
especifica y disea procesos revisados, y elabora prototipos, los refina y particulariza dentro de un negocio. La RPN tiene un objetivo que va ms all del software. Su
resultado con frecuencia es la definicin de las formas en las cuales las tecnologas
de la informacin pueden apoyar mejor a los negocios.
La reingeniera de software comprende una serie de actividades que incluyen
anlisis de inventario, reestructuracin de documentos, ingeniera inversa, reestructuracin de programas y datos, e ingeniera directa. La finalidad de estas actividades
es crear versiones de programas existentes que sean de mayor calidad y tengan
mayor facilidad de mantenimiento (programas que sern viables ya muy avanzado
el siglo xxl).
El anlisis de inventarios permite que una organizacin evale cada aplicacin

sistemticamente, con la finalidad de determinar cules son candidatas a la reingenierla. La reestructuracin de documentos crea un marco de trabajo de documentacin
que e, necesario para brindar apoyo a largo plazo a una aplicacin. La ingeniera
1:,a es el proceso de analizar un programa con el propsito de obtener informal Ion de diseo de datos, arquitectnico y de procedimiento. Finalmente, la ingeniera directa reconstruye un programa empleando modernas prcticas de ingenieta
del software y la informacin aprendida durante la ingeniera inversa.
El costo-beneficio de la reingeniera se determina cuantitativamente. El costo del
statu quo, esto es, el costo asociado con el soporte y el mantenimiento actuales de
una aplicacin existente, se compara con los costos proyectados de la reingeniera y
la reduccin resultante en los costos de mantenimiento. En casi todos los casos en
los que un programa tenga una vida larga y en la actualidad muestre escasa facilidad de mantenimiento, la reingeniera representa una estrategia de negocios efectiva en cuanto al costo.
,. HltJRPJQJAS ..
!CAN72J Canning, R., "The Maintenance 'Iceberg'", en EDPAnalyzer, vol. 10, nm. 10, octubre
de 1972.
(CAS88J "Case Tools for Reverse Engineering", en CASE Outlook, CASE Consulting Group, vol 2,
nm. 2, 1988, pp. 1- 15.
[CHI90) Chikofsky, E. J. y J. H. Cross, 11, "Reverse Engineering and Design Recovery: A
TaxonomY', en IEEE Software, enero de 1990, pp. 13-1 7.
[COUOO] Coulouris, G., J. Dollimore y T. Kindberg, Distributed Systems: Concepts and Design, 3a.
ed., Addison-Wesley, 2000.
[DAV90J Davenport, T. H. y J. E. Young, "The New Industrial Engineering: lnformation
Technology and Business Process Redesign", en Sloan managementReviei-v, verano de 1990,
pp. 11-27.
CAPTULO 31
REINGENIERA
925
[DEM95J DeMarco, T., "Lean and Mean", en IEEE Software, noviembre de 1995, pp. l 01-102.
(HAM90J Hammer, M., "Reengineer Work: Don't Automate, Obliterate", en Harvard Business
Review, julio-agosto de 1990, pp. 104-112.
[HAN93] Manna, M., "Maintenance Burden Begging for a Remedy", en Datamation, abril de
1993, pp. 53-63.
UAY94J Jaychandra, V., Re-engineering the Networked Enterprise, McGraw-Hill, 1994.
[MER931 Merlo, E. et al., "Reverse Engineering of user Interfaces", Proc. Working Conference on
Reverse Engineering, IEEE, Baltimore, mayo de 1993, pp. 171-178.
[MER95J Merlo, E. et al., "Reengineering User Interfaces", en IEEE Sojhvare, enero de 1995, pp.
64-73.
[MlLSl] Miller, J., en Techniques of Program and System Maintenance, (G. Parikh, ed.) Winthrop
Publishers, 1981.
f0RF991 Orfali, R., D. Harkey y J. Edwards, Client/Server Suvival Guide, 3a. ed., Wiley, 1999.
[OSB90] Osbome, W. M. y E. J. Chikofsky, "Fitting Pieces to the Maintenance Puzzle", en IEEE
software, enero de 1990, pp. 10-11.
(PRE94J Premerlani, W. J. y M. R. Blaha, "An Approach for Reverse Engineering of Relational
Databases", en CACM, vol. 37, nm. 5, mayo de 1994, pp. 42-49.
[RIC89) Ricketts, J. A., J. C. DelMonaco y M. W. Weeks, "Data Reengineering for Application
Systems", Proc. Conf SoftwareMaintenance-1989, IEEE, 1989, pp. 174-179.
[SNE951 Sneed, H., "Planning the Reengineering of Legacy Systems", en IEEE Software, enero de
1995, pp. 24-25.
[STE93J Stewart, T. A., "Reengineering: The Hot New Managing Too!", en Fortune, 23 de agosto
de 1993, pp. 41-48.
[SWA 76) Swanson, E. B., "The Dimensions of Maintenance", Proc. Second Intl. Conf Sojhvare
Engineerng, IEEE, octubre de 1976, pp. 492-497.
[VAN02] Van Steen, M. y A. Tanenbaum, Distributed Systems: Principies and Paradigms,
Prentice-hall, 2002.
[WAR74J Wamier,J. D., LogcalConstruction ofPrograms, Van Nostrand-Reinhold, 1974.
31.1. Considerar cualquier empleo realizado en los ltimos cinco aos. Describir el proceso de
negocio en el que se particip. Emplear el modelo de RPN descrito en la seccin 31. l.3 para
recomendar cambios al proceso con la finalidad de hacerlo ms eficiente.
31.2. Investigar un poco acerca de la eficacia de la reingenieria de procesos del negocio.
Presentar argumentos en favor y en contra de este enfoque.
31.3. El instructor seleccionar uno de los programas que todos en la clase han desarrollado
durante este curso. Intercambie su programa en forma aleatoria con alguien ms en la clase.
No explique u ofrezca un "paseo" por el programa. Ahora, implemente una mejora (que haya
especificado el instructor) en el programa que ha recibido.
a) Realice todas las tareas de ingeniera del software, incluso una breve prueba manual
(mas no con el autor del programa).

b) Conserve un cuidadoso seguimiento de todos los errores encontrados durante las
pruebas.
e) Describa sus experiencias en clase.
31.4. Explorar la lista de verificacin del anlisis de inventario presentado en el sitio Web SEP e
intentar el desarrollo de un sistema cuantitativo de calficacin de software que pudiese aplicarse
a programas existentes con la finalidad de elegir programas candidatos para reingeniera. El
sistema debe rebasar el anlisis presentado en la seccin 31.6.
31.5. Sugerir opciones a la documentacin por escrito o electrnica convencional que
pudiesen servir como base para la reestructuracin de documentos. (Sugerencia: pinsese en
las nuevas tecnologas descriptivas que se pudieran usar para comunicar el propsito del
software.)
926
PARTE CINCO
31.6. Algunas personas creen que la tecnologa de inteligencia artificial aumentar el grado
de abstraccin del proceso de ingeniera inversa. Realizar algo de investigacin acerca de esta
materia (es decir, el uso de IA en la ingeniera inversa) y escribir un breve ensayo que contenga
una opinin acerca de este punto.
31. 7. Por qu la completud es dificil de lograr conforme aumenta el grado de abstraccin?
31.8. Por qu debe aumentar la interactividad si la completud aumenta?
31.9. Con base en la informacin obtenida va Internet, presente a su clase las caractersticas
de tres herramientas de ingeniera inversa.
31. 10. Existe una sutil diferencia entre reestructuracin e ingeniera directa. Cul es?
31.11. Investigue la bibliografia o fuentes de Internet para encontrar uno o ms escritos que
borden estudios de caso de reingeniera de computadora central a cliente-servidor. Presente un
resumen.
31.12. Cmo determinara de P4 a P7 en el modelo costo-beneficio presentado en la seccin 31.6?
Al igual que muchos temas apasionantes en la comunidad de negocios, las exageraciones que
rodeaban la reingeniera de procesos de negocio han dado paso a una visin ms pragmtica
de la materia. Hammer y Champy (Reengineering the Corporation, HarperBusiness, edicin revisada, 2001) precipit el inters temprano con el xito de ventas de su libro. Ms tarde, Hammer
(Beyond Reengineerng: How the Processed-Centered Organizaton Is Changing Our Work and our
Uves, HarperCollins, 1997) refin su visin al enfocarse sobre los temas "centrados en el proceso".
Los libros de Smith y Fingar (Business Process Management (BPM): The Third Wave, MeghanKiffer Press, 2003). Jacka y Keller (Business Process Mapping: lmproving customer Satifacton,
wiley, 2001), Sharp y McDcrmott (Workjlow Modeling, Artech House, 2001), Andersen (Business
Process lmprovement Toolbox, American Society for Quality, 1999) y Harrington et al. (Business
Process lmprovement Workbook, McGraw-Hill, I 997) presentan estudios de caso y directrices
detalladas para la RPN.

Feldmann (The Practica/ Guide to Business Process Reeingineering Using IDEFO, Dorset House,
1998) onolizo uno notacin de modelado que auxilia en la RPN. Berztiss (SOftware Metl1odsfor
Business Reengineering, Springer, 1996) y Spurr et al. (Software Assistancefor Business Reengineering,
Wiley, 1994) examinan herramientas y tcnicas que facilitan la RPN.
Secord y sus colegas (Modernizing Legacy Systems, Addison-Wesley, 2003), Ulrich (Legacy
~stems: rransformation Strategies, Prentice-Hall, 2002), Valenti (Successfal SOftware Reengineering, IRM Press, 2002) y Rada (Reengineering SOftware: How to Reuse Programming to Build new,
State-ofthe-Art Software, Fitzroy Dearborn Publishers, 1999) se enfocan en las estrategias y prcticas para la reingenierla en un contexto tcnico. Miller (Reengineering Legacy Software Systems,
Digital Press. 1998) "ofrece un marco de trabajo para mantener las aplicaciones de los sistemas
sincronizadas con las estrategias del negocio y los cambios tecnolgicos". Umar (Application
(Re)Engineering: Building Web-Based Applications and Dealing with Legades, Prentice-Hall, 1997)
ofrece lineamientos valiosos para las organizaciones que quieren transformar los sistemas
heredados en un entorno basado en Web. Cook (Building Enterprise Informaton Architectures:
Reengineering lnformation ~stems, Prentice-Hall, 1996) analiza el puente entre la RPN y la tecnologa de la informacin. Aiken (Data Reverse Engineering, McGraw-Hill, 1996) estudia cmo recuperar, reorganizar y reutilizar datos de la organizacin. Amold (Software Reengineering, IEEE
Computer Society Press, 1993) ha reunido una excelente antologa de los primeros ensayos que trataban acerca de las tecnologas de la reingeniera del software.
Una amplia variedad de fuentes de informacin acerca de reingenieria de software est disponible en Internet. Una lista actualizada de referencias en la World Wide Web se puede encontrar en el sitio Web SEPA:
C.ONCEPTOS
CJ.AVE
.Wtooel
camlli11 ..... ;.929
coaodmie11to , ,934
4atos ........W
itka ........9l6
.-,-~
cW ~llff
928
f!lt.nJlCld6'i , ..933
pel'SOIIIIS ,930
p,oceso ......931
teMlltda
J,cnolgi<os 936
n los 31 capitulas precedentes se: explor un proceso para la ingeniera del

software. Se presentaron tanto procedimientos de gestin como mtodos,, --1
tcnicos, principios bsicos y tcnicas esp~<:;iaU.zadas, activi9.a<;le$-orienta- , "

das a las personas y tp.reas adecuadas para automatizarlas, nQtacin de papel y
lpiz y herramientas de softWare, Se argument que la meddn, ta: disciplina y
una vigilancia estricta sobre la calidad generarn un software qu,e satisfag
necesidades de lo~ clientes; que sea fiable, que teng?l facilidad de mantenlmiento,
que sea mejor. Sin embargo, nunca se ha prometidQ que la ingeniera del soft~
fas
ware sea una panace~.

Conforme se contine el viaje en el nuevo siglo, las tecnologas de software
y sistemas seguirn siendo un desafio para los profesionales del software y las
comparuas qu construyan si$temas basados en computadoras. Aunque escribi
estas palabras con una Visin del siglo xx, Max Hopper [HOP901 describi con
precisin el estado actual del asunto:
Puesto que los cambios en la tecnologa de la infonnacin se estn volviendo tan rpidos e irpplacabl~, y las consecuencias d~ caer ante ellos son irreversibles, las .:om-
palas d0:minrt1 la tecnologa o morirn,_ Piense en ello com9 en un molino de

tecnologia. Las compaas tendrn que. correr~ vez ms rpli;!O pal'Gl permanecer
en su Jugar.
927
928
PARTE CINCO
TEMAS AVANZAJX)S EN INGENIERA DEL SOFTWARE
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 bastante 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 aplicacin 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 explorar 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 cambio y la forma en la que ste afectar el proceso de ingeniera del software en los
aos por venir.
32. l LA JMPQBtANCJA QEL $AEIYiAAI, SGuHpA, PARTE

La importancia del software de computadora se puede establecer en muchas fonnas.
En el captulo I el software se caracteriz como un diferenciador. La funcin que proporciona el software diferencia productos, sistemas y servicios, y ofrece una ventaja
competitiva en el mercado. Pero el software es ms que un diferenciador. Los programas, documentos y datos que constituyen el software ayudan a generar el producto
ms importante que cualquier individuo, negocio o gobierno pueda adquirir: informa-
cin. Pressman y Herron [PRE91] describen al software en la forma siguiente:

El software de computadora es una de slo unas cuantas tecnologas clave que tendrn
un impacto significativo en casi cualquier aspecto de la sociedad moderna ... Es un mecanismo para automatizar negocios, industrias y gobiernos, y un medio para transferir nueva
tecnologa, un mtodo de captura de experiencias valiosas para que las utilicen otros, un
medio para diferenciar los productos de una compaa de los de sus competidores, y una
ventana al conocimiento colectivo de una corporacin. El software es un pivote para casi
cualquier aspecto de los negocios. Pero, en muchas formas, el software tambin es una
tecnologa oculta. se encuentra software (usualmente sin darse cuenta de ello) cuando se
viaja al trabajo, se realiza alguna compra al menudeo, se detiene en el banco, se hace una
llamada telefnica, se visita al mdico o se realiza alguna de las cientos de actividades cotidianas 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.
C APiTuJ.O 32
929
EL CAMINO POR RECORRER
, . pllllcdones son nmy diWes de hacer, especialmente cuando se reloonon con el faturo.
Los cambos en la informtica durante los pasados 50 aos han sido dirigidos por
avances en las ciencias bsicas: flsica, qumica, ciencia de materiales e ingeniera
Esta tendencia continuar durante el primer cuarto del siglo xx1. El impacto de las
nuevas tecnologas es profundo: en las comunicaciones. la energa, el cuidado de la
salud, la transportacin, el entretenimiento, la economia, la industria manufacture
ra y la guerra, por mencionar slo unas cuantas.
,~ Tecnologas a observar. Las tecnologas para mirar.

~ los editores de PC Magazine [PCM03]
soldados para supervisar la presencia de armas
preparan un nmero anual de "Tecnologas del
Futuro que "(busco] a travs de todos los espacios de chal
(hay varios de ellos) identificar las 20 tecnologas ms
prometedoras del maana". Las tecnologas registradas
abarcan toda uno amplio goma, desde el cuidado de lo
salud hasta la guerra. Sin embargo, es interesante
observar que el software y la ingeniera del software tienen
un significativo papel que jugar en todos, ya seo como
impulsores de la tecnologa o como uno parte integral de
ellos. Las siguientes representan uno muestro de los
tecnologas registradas:
Nonotubos de carbono. Con uno fino estructuro

parecida al grafito, los nonotubos de carbono pueden
funcionar como alambres, para transmitir seales
desde un punto a otro, y como transistores, usondo
cambios de seal paro 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).
Biosensores. Los sensores microelectrnicos, externos o

implontables, yo se utilizan ampliamente en la
deteccin, desde ogentes qumicos en el aire que se
respira hasta niveles de sangre en pacientes cardiacos.
Conforme estos'sensores se vuelvan ms sofisticadas,
podrn implantarse en pacientes mdicos poro
supervisar uno variedad de condiciones relacionados
con la salud, o incorporarlos a los uniformes de los
biolgicas o qumicas.
Pantallas OLED. Un OLED (diada emisor de luz

orgnico) "utiliza una molcula diseadora con base
de carbono que emite luz cuando una corriente
elctrico paso o travs de ella. Junte muchos de estas
molculas y obtendr uno pantalla muy delgado de
asombrosa calidad; no requiere fuente de luz trasero
que provoca prdidas de energa" (PCM03) El
resultado: pantallas ultrodelgodas que se pueden
enrollar o doblar, extender sobre uno superficie curvo o
adaptarse de alguno otro formo a un entorno
especfico.
Retcula de cmputo. Esto tecnologa (disponible en lo

actualidad) creo uno red que aprovecho los miles de
millones de ciclos de CPU no utilizadas de cado
mquina en la red y permite que se completen toreos
de cmputo excesivamente complejos sin contar con
uno supercomputadoro. Vase un ejemplo prctico que
abarco 4.5 millones de computadoras en
http.//setiothome.berkeley.edu/.
Mquinas cognitivos. El "santo grial" en el campo de

la robtica es desarrollar m6quinos que estn
conscientes de su entorno, que puedan "recabar pistas,
responder a siluociones siempre cambiantes e
inleroduor con personas de modo natural [PCM03].
las maqunos cognitivos todava estn en los primeros
etapas de desarrollo, pero el potencial (si se logro
alguno \l'U) es enorme
930
PARTE CINCO
1tilf,ifrM1
A largo plazo, los avances revolucionarios en la informtica bien pueden dirigirlos las ciencias sociales: psicologa humana, sociologa, tilosofia, antropologia y
otras. El periodo de gestacin de las tecnologas informticas que se puedan derivar
de estas disciplinas es muy dificil de predecir, pero las primeras influencias ya han
comenzado (por ejemplo, las comunidades -una estructura antropolgica- de
usuarios, que son ramificaciones de las redes de pares a pares).
La influencia de las ciencias sociales quiz ayude a moldear la direccin de la
investigacin en informtica en las ciencias bsicas. Por ejemplo, el diseo de las
futuras computadoras tal vez Jo gue ms el conocimiento de la psicologa cerebral
que el de la microelectrnica convencional.
A corto plazo, los cambios que incidirn en la ingeniera del software durante la
siguiente dcada recibirn la influencia de cuatro fuentes simultneas: 1) las personas que realicen el trabajo, 2) el proceso que apliquen, 3) la naturaleza de la informacin y 4) la tecnologa informtica subyacente. En las secciones que siguen se
examinan con ms detalle cada uno de estos componentes: personas, proceso,
informacin y tecnologa.
l'llu mccione.s
IK8ICll del full.lo de lli"
l8cOOlogo yotro~
materias, vase
www.futlwtfattag.
CI&
El software que requieren los sistemas de alta tecnologia se vuelve ms complejo

cada ao, y el tamao de los programas resultantes aumenta proporcionalmente. El
rpido crecimiento en el tamao del programa "promedio" presentara pocos problemas si no fuese por un hecho simple: conforme aumenta el tamao del programa, tambin debe aumentar el nmero de personas que deben trabajar en l.
La experiencia indica que conforme aumenta el nmero de personas de un equipo de proyecto de software, tal vez la productividad global del grupo disminuya. Una
forma para resolver este problema consiste en crear equipos de ingeniera del software, y en consecuencia dividir al personal en grupos de trabajo individuales. Sin
embargo, conforme crece el nmero de equipos de trabajo de ingeniera del software, la comunicacin entre ellos se vuelve tan dificil y tardada como la comunicacin
entre los individuos. Peor an, la comunicacin (entre individuos o equipos) tiende
a ser ineficiente; es decir, se pasa demasiado tiempo transfiriendo muy poco contenido de informacin, y con mucha frecuencia la informacin importante "cae entre
las grietas".
a ~ue del.fulUro es la agotadora tensin ydesorientacin que inducimos en los indMduos olstieturlos 11
' 'le)liilsilldos (Qmbios'en un periodo demasiado corto."

-'
. "
, ,
Alvltwn.t
Si la comunidad de la ingeniera del software tiene que tratar con eficacia el dilema de la comunicacin, el camino que recorrern los ingenieros de software debe
incluir cambios radicales en la forma en que los individuos y los equipos se comunican entre s. El correo electrnico, los sitios Web y las conferencias de video centra-
CAPTULO 32
931
!izadas ahora son mecanismos comunes para conectar a un gran nmero de perso
nas a una red de informacin. La importancia de estas herramientas en el contexto
del trabajo de ingeniera del software no se debe sobrevaluar. Con un correo eleclrnico eficiente o un sistema de mensajera instantnea, el problema que encuentre un ingeniero de software en la ciudad de Nueva York puede resolverse con la
ayuda de un colega en Tokio. En realidad, las sesiones de conversacin (chatJ sobre
un tema particular y los grupos de noticias especializados se vuelven depsitos de
conocimiento que permiten que el saber colectivo de un gran grupo de tcnicos sea
aplicado para solucionar un problema tcnico o un conflicto de gestin
El video personaliza la comunicacin. En el mejor de los casos, permite que los
colegas en diferentes ubicaciones (o en diferentes continentes) se "renan" con cicr
ta regularidad. Adems, el video tambin ofrece otro beneficio: se puede usar como
depsito de conocimiento acerca del software y para entrenar a los recin llegados
a un proyecto.
"la,.....
III5lim aclecuodo ante lotecnologa digital es adoptarlo como uno nuevo ventano a todo lo
- - MICIIIO, y usmla con pasin, sabidura, temeridad y alegria."
Ralplit..re...
La evolucin de los agentes inteligentes tambin cambiar los patrones lab,xales
Msyms no
(Jl()gromod(){es estn
coostrvyendo sus
()(opios (pequeiios)
op/icociones. Esta
tendencia actual es
probable que se
acelere en lo futi.ro.
Estos civl1es
deberfon aplicar lo
tecnologfo estudiado
en este lilxo? Proooblemente no. Pero
debe,ron adoptor uno
filosofa de ingeniera
del software gil
iJuso si no odoptm
la pr6ctico.
de un ingeniero de software al extender sustancialmente las capacidades <le las

herramientas de software. Los agentes inteligentes mejorarn la habilidad del ingeniero al comprobar varias veces los productos de trabajo de ingenieria empleando
conocimiento especifico del dominio, realizando tareas administrativas, llevando a
cabo una investigacin dirigida y coordinando la comunicacin entre las personas.
Finalmente, la adquisicin de conocimiento est cambiando en forma radical. En
Internet, un ingeniero de software puede suscribirse a grupos de noticias que se
enfoquen en reas de tecnologa que le interesen directamente. Una pregunta enviada a un grupo de noticias precipita las respuestas de otras partes interesadas alrededor
del mundo. La World Wide Web ofrece a un ingeniero de software la ms grande
biblioteca del mundo de trabajos e informes de investigacin, manuales, comentarios y referencias acerca de la ingeniera del software.
Si la historia es un indicio, es acertado decir que las personas no cambiarn. Sin
embargo, las formas en las que se comunican, el entorno en el que trabajan, la
manera en la que adquieren conocimiento, los mtodos y herramientas que usan, la disciplina que aplican y, por lo tanto, la cultura general del desarrollo del software cambiarn en formas significativas e incluso profundas.
Es razonable caracterizar las pmeras dos dcadas de la prctica de la ingenieria del

software como la era del "pensamiento lineal". Fomentada por el modelo clsico del
ciclo vital, la ingeniera del software se enfoc como una actividad lineal en la que
932
PARTE CINCO TEMAS AVANZAIXJS EN INGENIERA DEL SOfTWARE
se podran aplicar una serie de pasos secuenciales con la finalidad de resolver problemas complejos. Sin embargo, los enfoques lneales acerca del desarrollo de software corren contra la forma en la que la mayora de los sistemas realmente se construye. En realidad, los sistemas complejos evolucionan terativamente, incluso en
forma incremental. Por esta razn, un gran segmento de la comunidad de ingeniera del software se desplaza hacia modelos ncrementales giles para el desarrollo
del software.
Los modelos de proceso incremental gil reconocen que la incertidumbre domina
la mayora de los proyectos, que los plazos de entrega con frecuencia son imposibles
de cumplir y cortos, y que la teracin proporciona la habilidad de dar una solucin
parcial, incluso cuando un producto completo no es realizable dentro del tiempo asignado. Los modelos evolutvos subrayan la necesidad de productos de trabajo incrementales, anlisis de riesgo, planeacin y luego revsin del plan, y retroalimentacin
con el cliente. En muchos casos el equipo de software aplica un "manifiesto gil"
(captulo 4) que subraya "los individuos e interacciones sobre los procesos y herramientas; el software operativo sobre la documentacin detallada; la colaboracin del
cliente sobre la negociacin de contratos; y la respuesta al cambio sobre el seguimiento de un plan" [BECOl].
11-prtpft:16n para.el buen trabajo moona es hacer un buen trobojofloy!
Las tecnolog1as de objetos, junto con la ingeniera del software basada en componentes (captulo 30), son una consecuencia natural de la tendencia hacia los
modelos de procesos incrementales y evolutivos. Ambos tendrn un profundo
impacto sobre la productividad del desarrollo de software y la calidad del producto.
La reutilizacin de componentes ofrece beneficios inmediatos y convincentes.
Cuando la reutilizacin se une con las herramientas CASE para los prototipos de una
aplicacin, los incrementos del programa se pueden construir mucho ms rpidamente que mediante los enfoques convencionales. La elaboracin de prototipos
involucra al cliente con el proceso. En consecuencia, es probable que los clientes y
usuarios se involucren mucho ms en el desarrollo del software. Esto, a su vez,
puede conducir a una mayor satisfaccin del usuario final y en general a mejorar la
calidad del software.
El rpido crecimiento en las tecnologas de red y multimedia (por ejemplo, el
aumento exponencial en las WebApps durante las pasadas dcadas) est cambiando tanto al proceso de ingeniera del software como a sus participantes. De nuevo,
se est ante un paradigma incremental gil que destaca la inmediatez. la seguridad
y la esttica, as como preocupacin por la ingeniera de software ms convencional. Los modernos equipos de software (por ejemplo, un equipo de ingeniera Web)
con frecuencia mezclan tcnicos con especialistas de contenido (por ejemplo, artistas, msicos, videogrfos) para construir una fuente de informacin destinada a una
CAPTULO 32
933
comunidad de usuarios grande e impredecible. El software que se ha desarrollado

con base en estas tecnologas ha generado radicales cambios econmicos y culturales. Aunque los conceptos y principios bsicos tratados en este libro son aplicables,
el proceso de ingeniera del software se debe adaptar.
A lo largo de la historia de la informtica ha ocurrido una transicin sutil en la ter

minologa con que se describe el trabajo de desarrollo del software realizado para la
comunidad de negocios. Hace cuarenta aos, el trmino procesamiento de datos era
la frase operativa para describir la utilizacin de las computadoras en un contexto
de negocios. En la actualidad, el procesamiento de datos ha dado paso a otra frase
-tecnologa de la informacin- que significa lo mismo pero presenta un sutil cambio en el enfoque. La importancia radica no slo en procesar grandes cantidades de
datos, sino en obtener informacin significativa de dichos datos. Obviamente, sta
fue siempre la finalidad, pero el cambio en la terminologia releja un cambio mucho
ms importante en la filosofia de la gestin.
Cuando en la actualidad se abordan las aplicaciones de software las palabras
datos e informacin aparecen repetidamente. La palabra conocimiento se encuentra
en algunas aplicaciones de inteligencia artificial, pero su utilizacin es relativamente escasa. Virtualmente nadie se refiere a la sabidura en el contexto de las aplicaciones de software.
Los datos son informacin en bruto: colecciones de hechos que deben procesarse para que sean significativos. La informacin se deriva al asociar los hechos en un
iihi.fA
Espectro de
"1n1ormactn".
Datos:
sin asociatividod
I>
Conocimiento:
osociotividod dentro de
mltiples contextos
Informacin:
asociatividod dentro
de un contexto
Sabidura:
creacin de principios
generalizados con
base en el conocimiento
procedente de fuentes
diferentes
934
PARTE CINCO TEMAS AVANl.ADOS EN INGENIERA DEL SOFTWARE
contexto dado. El conocimiento asocia la informacin obtenida en un contexto con

otra informacin obtenida en un contexto diferente. Finalmente, la sabidura se presenta cuando los principios generalizados se derivan de conocimientos dispares.
Cada una de estas cuatro visiones de la "informacin" se representa esquemticamente en la figura 32. J.
A la fecha, la gran mayora del software se ha construido para procesar datos o
informacin. Los ingenieros de software ahora estn igualmente preocupados con
los sistemas que procesan el conocimiento. 1 El conocimiento es bidimensional. La
informacin recopilada acerca de una diversidad de temas relacionados e inconexos
se relaciona para formar un cuerpo de hechos que se llamar conocimento. La clave
es la habilidad personal para asociar la informacin proveniente de diversas fuentes,
que tal vez no tengan alguna conexin evidente, y combinarla en una forma que
ofrezca algn beneficio distinto.
,a safJidorla es el pode, que permite utili2or el conocimiento poro el beneficio d lSOtros mismos y de ons."
,
; ,. .... lWfa
Para ilustrar la progresin desde datos hasta conocimiento, considrense los
datos censales que indican que los nacimientos en 1996 en Estados Unidos fueron
4.9 millones. Este nmero representa un valor de datos. Al relacionar esta pieza de
datos con las tasas de nacimiento para los 40 aos precedentes, se puede derivar
una til pieza de informacin: los cada vez ms viejos baby boomers de la dcada de
1950 y de principios de la de 1960 hacan un ltimo esfuerzo para tener hijos antes
del final de su vida reproductiva. Adems, los gen-Xers (miembros de la generacin
X) comenzaban su vida reproductiva. Los datos censales entonces pueden vincularse con otras piezas de informacin aparentemente no relacionada. Por ejemplo, el
nmero actual de profeso res de escuela elemental que se retirarn durante la
siguiente dcada, el nmero de estudiantes universitarios que se graduarn en educacin primaria y secundaria, la presin sobre los polticos para mantener bajos los
impuestos y, por lo tanto, limitar los aumentos salariales a los profesores.
Todos estos elementos de informacin se pueden combinar para formular una
representacin del conocimiento: existir una presin significativa sobre el sistema
educativo en Estados Unidos en la primera dcada del siglo xx1, y esta presin continuar durante una dcada. Con la utilizacin de este conocimiento puede surgir
una oportunidad de negocio. Quiz haya significativas oportunidades para desarrollar nuevos modos de aprendizaje que sean ms eficaces y menos costosos que los
enfoques actuales.
El rpido crecimiento de las tecnologas de extraccin y almacenamiento de datos refleja esta tendencia creciente.
CAPTULO 32
EL CAMINO POR RECO RRER
935
El camino que recorrer el software conduce a sistemas que procesan el conocimiento. Se han estado procesando datos empleando computadoras durante 50 aos
y extrayendo informacin durante ms de tres dcadas. Uno de los desafios ms significativos que enfrenta la comunidad de ingeniera del software es construir sistemas
que den el prximo paso a Jo largo del espectro: sistemas que extraigan conocimiento a partir de los datos e informacin en una forma prctica y beneficiosa.
La gente que construye y utiliza software, el proceso de ingeniera del software que
se aplica y la informacin que se produce resultan afectados por los avances en el
hardware y la tecnologa del software. Histricamente, el hardware ha servido como
el impulsor tecnolgico en la computacin. Una nueva tecnologa de hardware proporciona potencial. Entonces los constructores de software reaccionan a las demandas de los consumidores con la finalidad de aprovechar el potencial.
Es probable que las tendencias futuras de la tecnologa de hardware avancen por
dos trayectorias paralelas. A lo largo de una trayectoria las tecnologas de hardware
contnuarn evolucionando con rapidez. Ante la mayor capacidad que ofrecen las
arquitecturas de hardware tradicionales, las demandas a los ingenieros de software
continuarn creciendo.
Pero los cambios verdaderos en la tecnologa de hardware podran producirse en
otra direccin. El desarrollo de arquitecturas de hardware no tradicionales (por
ejemplo, nanotubos de carbono, microprocesadores EUL, mquinas cognitivas, reticulas de cmputo) podran provocar cambios radicales en el tipo de software que se
construir y cambios fundamentales en el enfoque hacia la ingeniera del software.
Dado que estos enfoques no tradicionales se estn madurando, es dificil determinar
cul tendr un impacto significativo e incluso es ms dificil predecir cmo cambiar
el mundo del software para adaptarse a ellos.
Las tendencias futuras de la ingeniera del software las impulsan las tecnologas
de software. La reutilizacin y la ingeniera del software basada en componentes
ofrecen la mejor oportunidad en cuanto a mejoras en la magnitud de la calidad de
los sistemas y en el tiempo en que llegan al mercado. De hecho, conforme pasa el
tiempo, el negocio del software puede comenzar a parecerse mucho al negocio de
hardware de la actualidad. Quiz haya empresas que construyan dispositivos discretos (componentes de software reutilizables), otras empresas que construyan
componentes de sistemas (por ejemplo, un conjunto de herramientas para la interaccin hombre-mquina) e integradores de sistemas que ofrezcan soluciones (productos y sistemas construidos de forma personalizada) para el usuario final.
La ingeniera del software cambiar de eso se puede estar seguro. Pero, sin
importar cun radicales sean los cambios, se puede estar seguro de que la calidad
nunca perder su importancia, y de que el anlisis y el diseo efectivos y las pruebas competentes siempre tendrn un lugar en el desarrollo de los sistemas basados
en computadoras.
PARTE CINCO TEMAS AVANZAfXYS EN INGENIERA DEL SOFIWARE
936
Tendencias tecnolgicas
P. Cripwell Associates (www.jpcripwell.com),
una firma de consultora 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.
Combinacin de tecnologas. Cuando dos

importantes tecnologas se funden, el impacto del resultado
con frecuencia es mayor que la suma del impacto de coda
una por separado. Por ejemplo, lo tecnologa de los
satlites GPS (sistemas de posicionamiento global) junto
con la capacidad de cmputo o bordo y los tecnologas de
pantallas LCD han permitido construir sofisticados sistemas
de localizacin en los automviles. los tecnologas con
frecuencia evolucionan a rutas separados, pero el impacto
en los negocios o social significativo slo ocurre cuando
alguien los combina paro resolver un problema.
Fusin de datos. 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 dolos son relevantes poro uno necesidad o fuente
particular, y qu datos se deben emplear poro la toma de
deci$iones. ste es el problema de lo usin de datos. J. P.
Cripwell utilizo como ejemplo un sistema avanzado de
superv:s:n de h-lifico aulomovilslico. Sensores digitales de
rapidez (en el comino) y c6moros digitales detectan un
occidente. lo severidod del occidente se debe determinar
(to travs de las cmaras?). Con bose 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 (rodio) deben difundir
advertencias; y debe informrseles o los automviles

individuales (si estn equipados con sensores digitales o
comunicacin inalmbrico). Poro lograrlo se debe tomar
una variedad de decisiones, con base en los datos
adquiridos a partir del sistema de supervisin (fusin de
datos).
Tecnologa de empuje. En aos posados surgi un

problema y se desarroll tecnologa para resolverlo. Puesto
que el problema era evidente para muchos personas, el
mercado poro la nuevo tecnologa estaba bien definido.
En lo actualidad, algunos tecnologas evolucionan como
soluciones que buscan problemas. Un mercado debe
empujarse poro reconocer que necesita lo nuevo
tecnologa (por ejemplo, telfonos mviles, PDA).
Conforme los personas reconocen lo necesidad, lo
tecnologa se acelera, mejoro y con frecuencia se
transformo conforme evoluciono la combinacin de
tecnologas.
Red y casualidad. En este contexto, red implico

conexiones entre personas o entre personas e informacin.
Conforme crece lo red, la probabilidad de sinergia entre
dos nodos de red (por ejemplo, personas, fuentes de
informacin) tambin crece. Uno conexin fortuito (casual)
puede conducir a una inspiracin y o nueva tecnologa o
aplicacin.
Sobrecarga de informacin. Un amplio ocano de
informacin est a disposicin de cualquiera con una
conexin de Internet. El problema, desde luego, es
encontrar la informacin correcto, determinar su validez y
luego traducirlo en una aplicacin prctica en un mbito
de negocios o personal.
La ingenierla del software ha evolucionado en una profesin respetada en el mbi-
!~~tl
O/SE
..ettetl,,J
t,t,q/10 t
to mundial. como profesionales, los ingenieros de software deben regirse por un

cdigo de tica que gue el trabajo que realizan y los productos que producen. Una
fuerza de trabajo conjunto ACM/IEEE-CS ha producido un Cdigo de tica y prctica
profesional para los ingenieros de software (versin 5.1) . El cdigo [ACM98J afirma:
Los ingenieros de software se deben comprometer a s mismos a convertir el anlisis, la
especificacin, el diseo, el desarrollo, la prueba y el mantenimiento del software en una
profesin beneficiosa y respetada. En concordancia con su compromiso con ta salud, la
CAPTULO 32
937
seguridad y el bienestar del pblico, los ingenieros de software deben adherirse a los siguientes Ocho Principios:
1. PBLICO. Los ingenieros de software deben actuar consistentemente con el inters del
pblico.
2. CUENTES Y EMPLEADORES. Los ingenieros de software deben actuar en una forma que
beneficie los intereses de sus clientes y empleadores y sea consistente con el inters pblico.
3. PRODUCTO. Los ingenieros de software deben garantizar que sus productos y modificaciones relacionadas satisfacen los mayores estndares profesionales posibles.
4. JUICIO. Los ingenieros de software deben mantener la integridad y la independencia en
su juicio profesional.
5. GESTIN. Los gestores y lderes de la ingeniera del software deben suscribir y promover un enfoque tico de la gestin del desarrollo y el mantenimiento del software.
6. PROFESIN. Los ingenieros de software deben promover la integridad y la buena reputacin de la profesin en una forma consistente con el inters pblico.
7. COLEGAS. Los ingenieros de software deben ser justos con sus colegas y apoyarlos.
8. COMPROMISO PERSONAL. Los ingenieros de software deben participar en un aprendizaje permanente en relacin con la prctica de su profesin y promover un enfoque tico
para su prctica.
Aunque cada uno de estos ocho principios es igualmente importante, aparece un

tema ms relevante: un ingeniero de software debe trabajar en pro del inters pblico. En el mbito personal, un ingeniero de software debe atenerse a las siguientes
reglas:
Nunca robar datos para beneficio personal.
Nunca distribuir o vender informacin patentada que haya obtenido como
parte de su trabajo en un proyecto de software.
Nunca destruir o modificar maliciosamente los programas, archivos o datos
de otra persona.
Nunca violar la privacidad de un individuo, grupo u organizacin.
Nunca atacar un sistema por deporte o beneficio.
Nunca crear o difundir un virus o gusano de computadora.
Nunca usar la tecnologla de computacin para facilitar la discriminacin o el
hostigamiento.
Durante la dcada pasada, ciertos miembros de la industria del software han
cabildeado por una legislacin protectora que [SEE03]:
1. Permita a las compaas liberar el software sin revelar los defectos conocidos.
2 . Exentar a los desarrolladores de responsabilidad penal por cualesquiera daos que resulten debido a dichos defectos conocidos.
938
PARTE CINCO TEMAS AVANZATX)S EN INGENIERA DEL SOFTWAA.E
3. Restringir a otros la revelacin de defectos sin permiso del desarrollador original.
4. Permitir la incorporacin de software de "autoayuda" dentro de un producto

que pueda desactivar (via comandos remotos) la operacin del producto.
5. Exentar a los desarrolladores de software con "autoayuda" de los daos en
caso de que el software lo desactive una tercera persona.
Al igual que con cualquier legislacin, el debate con frecuencia se centra en conflictos polticos, no tecnolgicos. Sin embargo, mucha gente (incluso este autor) considera que la legislacin protectora, si se propone de manera inadecuada, entra en conflicto con el cdigo de tica de la ingeniera del software al exentar indirectamente
a los ingenieros de software de su responsabilidad para producir software de alta
calidad.
Ya han pasado 25 aos desde que se escribi la primera edicin de este libro. Todava
me recuerdo sentado en mi escritorio como un joven profesor, escribiendo el manuscrito de un libro acerca de una materia de la que poca gente se preocupaba e incluso todavia menos realmente comprenda. Recuerdo las cartas de rechazo de los editores, quienes argumentaban (gentil, pero firmemente) que nunca habra un mercado para un libro acerca de "ingeniera del software". Afortunadamente, McGraw-Hill
decidi darle una oportunidact.2 y el resto. como dicen, es historia.

Durante los pasados 25 aos, este libro ha cambiado sustancialmente: en alcan-
ce, en tamao, en estilo y en contenido. Al igual que la ingeniera del software, ha

crecido y (espero) madurado con los aos.
Un enfoque de ingeniera para el desarrollo del software de computadora es ahora
sabidura convencional. Aunque el debate contina acerca del "paradigma correcto",
la importancia de la agilidad, el grado de automatizacin y los mtodos ms efectivos, los principios subyacentes de la ingeniera del software ahora son aceptados a
lo largo de la industria. Por qu, entonces, se ha visto su amplia aceptacin slo
recientemente?
La respuesta, creo, se encuentra en la dificultad de la transicin tecnolgica y el
cambio cultural que la acompaa. Aun cuando la mayora de las personas aprecian
la necesidad de una disciplina de ingeniera para el software, se lucha contra la inercia de la prctica pasada y se enfrentan nuevos dominios de aplicacin (y los desarrolladores que trabajan en ellos), que parecen listos a repetir los errores del pasado.
En realidad, el crdito corresponde a Peter Freeman y Eric Munson, quienes convencieron a McGrawHill de que vala la pena intentarlo.
CAPTULO 32
939
Para facilitar la transicin se necesitan muchas cosas: un proceso de software

gil, adaptable y sensible; mtodos ms efectivos; herramientas ms poderosas;
mejor aceptacin de los profesionales y apoyo de los gestores; y no pequeas dosis
de educacin y "publicidad". La ingeniera del software no ha tenido el beneficio de
la publicidad masiva, pero, conforme pasa el tiempo, el concepto se vende a s
mismo. De alguna manera, este libro es un "anuncio publicitario" para la tecnologla.
El lector tal vez no est de acuerdo con todos los enfoques descritos en este libro.
Algunas de las tcnicas y opiniones son controvertidas; otras debern ajustarse para
trabajar bien en diferentes entornos de desarrollo de software. Sin embargo, mi sincera esperanza es que Ingeniera del software. Un enfoque prctico haya delineado los
problemas que se enfrentan, demostrado la fuerza de los conceptos de la ingeniera
del software y ofrecido un marco de trabajo de los mtodos y herramientas.
Conforme se avanza en el siglo XXI, el software se ha convertido en el producto
ms importante y en una industria primordial en el escenario mundial. Su impacto e
importancia han transitado un largo camino. E incluso, una nueva generacin de
desarrolladores de software debe enfrentar muchos de los mismos desafos que
enfrentaron las primeras generaciones. Espero que las personas que enfrenten el
reto -ingenieros de software- tendrn la sabidurfa de desarrollar sistemas que
mejoren la condicin humana.
[ACM98J ACM/IEEE-CS Joint Task Force, Sflware Engineenng Code of Ethics and Professional
Practice, 1998, disponible en http://ww w.acm.org/serving/se/code.htm.
!BECO!] Beck, K. et al., "Manifesto for Agle Software Development", http://www.agilemanifesto.org/.
1BOL911 Bollinger, T. y C. McGowen, "A Critica( Look at software Capability Evaluations", en
IEEE Software, julio de 1991, pp. 25-41.
[GIL96J Gilb, T., "What is Leve! Six?", IEEE Sjlware, enero de 1996. pp. 97-98, 103.
[HOP90J Hopper, M. O., "Rattling SABRE, New Ways to Compete on lnformation", en Harvard Business Review, mayo-junio de 1990.
[PAU93] Paulk, M. et al., Capability Maturity Model far Sflware, Software Engineering Institute,
Camegie Mellen University, 1993
(PCM03J "Technologies to Watch", en PC Magazine, julio de 2003, disponible en http://www pcmag.com/article2/0,4149, l 130591.00.asp.
fPRE91J Pressman, R. s. y s. R. Herron, Sflware Shock, Dorset House, 1991.
[SEE03) The Software Engineering Ethics Research lnstitute, "UCITA Updates", 2003, disponible
en http://seeri.etsu.edu/default.htm
PpQIJ.IMAI S ISDJTO& + GONIJPIRAB

32. 1. Obtener una copia de las pnncipales revistas de negocios y noticias de esta semana (por
ejemplo. Newsweek, Time, Business Week). Elaborar una lista de cada elemento del articulo o
noticia que se pueda utilizar para ilustrar la importancia del software.
32.2 . Uno de los dominios ms reidos de la ap. cacin del software son los sistemas y aplicac1ones basados en Web. Estudiar cmo la gente, la comunicacin y el proceso tienen que evolucionar para adaptarse al desarrollo de las WebApps de "siguiente generacin".
PARTE CINCO
TEMAS AVANZADOS EN INGENIERA DEL SOFJWARE
32.3. Escribir una breve descripcin del entorno de desarrollo de un ingeniero de software
ideal hacia el 2010. Describir los elementos del entorno (hardware, software y tecnologias de
comunicacin) y su impacto sobre la calidad y el tiempo en que llega al mercado.
32.4. Revisar el estudio de los modelos de proceso incrementales giles en el capitulo 4.
Realizar una investigacin y recopilar artculos recientes acerca de la materia. Resumir las fortalezas y debilidades de los paradigmas giles con base en las experiencias subrayadas en los
artculos.
32.5. Intntese desarrollar un ejemplo que comience con la recopilacin de datos en bruto y
llvese a cabo la adquisicin de informacin, luego de conocimiento y, por ltimo, de sabidura.
32.6. Proporcionar ejemplos especficos que ilustren uno de los ochos principios ticos de la
ingeniera del software mencionados en la seccin 32.7.
Los libros que estudian las tendencias futuras del software y la computacin abarcan una
amplia variedad de temas tcnicos, cientficos, econmicos, pol!ticos y sociales. Sterling
(Tomorrow Now, Random House, 2002) recuerda que el progreso real rara vez es ordenado y eficiente. Teich (Techno/ogy and the Future, Wadworth, 2002) presenta reflexivos ensayos acerca
del impacto social de la tecnologa y cmo la cultura cambiante da forma a la tecnologa.
Naisbitt, Philips y Naisbitt (High Tech/High Touch, Nicholas Brealey, 2001) sealan que muchas
personas se han "intoxicado" con la alta tecnologa y que la "gran ironla de la era de la alta tecnologia es que la humanidad se ha esclavizado a los dispositivos que se supone brindaran libertad". zey (The Future Factor, McGraw-Hill, 2000) analiza cinco fuerzas que darn forma al destino
humano durante este siglo. Canton (Technofutures, Hay House, 1999) estudia cmo la tecnologa transformar los negocios en el siglo xx1. Robertson (The New Renaissance: Computers and
the Next Level of Civiliza/ion, Oxford University Press, 19981 argumenta que la revolucin en la
computacin puede ser el avance individual ms significativo en la historia de la civilizacin.
Broderick (Spike, Forge, 2001) analiza el impacto de las tecnologlas emergentes. Dertrouzos
y Gatcs (Whal Will be: How the New World oflnformation Will Change our Uves, Harper-Business,
1998) ofrecen un estudio detallado de algunas de las direcciones que pueden tomar las tecnologas de la informacin en las primeras dcadas de este siglo. Barnatt (Valueware: Technology,
Hwnanity and Organizalion, Praeger Publishing, 1999) presenta un intrigante estudio de una
"economa de ideas" y cmo el valor econmico se crear conforme evolucionen los cibernegocios. El de Negroponte (Being Digital, Alfred A. Knopf, 1995) fue un xito de ventas a mediados del decenio de 1990 y contina ofreciendo una interesante visin de la computacin y de su
impacto global.
Kroker y Kroker (Digital Delirium, New World Perspectives, 1997) han editado una controvertida coleccin de ensayos, poemas y humor que examinan el impacto de las tecnologas digitales sobre las personas y la sociedad. Brin (The Transparent Sociew: Will Technology Force Us to
Choose Between Privacy and Freedom?, Perseus Books, 1999) vuelven a revisar el continuo debate asociado con la inevitable prdida de privacidad personal que acompaa al crecimiento de
las tecnologas de la informacin. Shenk (Data Smog: Surviving the Informalion Glut,
HarperCollins, 1998) estudia los problemas asociados con una sociedad infestada de informacin" que se sofoca por el volumen de informacin que produce el software.
Brockman (The Ne.xt Fijly Years, Vintage Books, 2002) y Miller y sus colegas (21st Centwy
Technologies: Promises and Perils ofa Dynamic Future, Brookings Institution Press, 1999) han editado una coleccin de artculos y ensayos acerca del impacto de la tecnologa sobre las estructuras sociales, empresariales y econmicas. Para aquellos interesados en los temas tcnicos,
Luryi, Xu y Zaslavsky (Future nends in Microelectronics, Wiley, 1999) han editado una coleccin
de artculos acerca de las probables direcciones para el hardware de computadora, con nfasis
en las nanotecnologas. Hayzelden y Bigham (Software Agents Jor Future Communication
systems, Springer-Verlag, 1999) han editado una coleccin que analiza las tendencias en el
desarrollo de agentes de software inteligentes.
CAPTULO 32
941
Conforme el software se vuelve cada vez ms parte de la fabricacin de virtualmente todas

las facetas de la vida moderna, la "cibertica" ha evolucionado como un tema importante de
estudio. Los libros de Spinello (Cyberethics: Mora/ity and Law in Cyberspace, Jones & Bartlett
Publishers, 2002), Halbert e Ingulli (Cyberechics, South-Western College Publishers, 2001) y Baird
y sus colegas (Cyberethics: Social and Moral Issues in the Computer Age, Prometheus Books, 2000)
consideran el tema en detalle. El gobierno estadounidense ha publicado un voluminoso reporte en CD-ROM (2 / st Century Guide co Cybercrime, Progressive Management, 2003) que considera todos los aspectos del crimen computacional, conflictos de propiedad intelectual y el Centro
de Proteccin a la Infraestructura Nacional (NIPC, por sus siglas en ingls).
Kurzweil (The Age of Spiritual Machines, When Computers Exceed Human lnte/Jigence.
Viking/Penguin Books, 1999) argumenta que, dentro de 20 aos, la tecnologa de hardware tendr la capacidad de modelar por completo el cerebro humano. Borgmann (llolding on to Reality:
The Nature oflnformalion at the Turn of the Millenium, University of Chicago Press, 1999) ha escri
to una interesante historia de la informacin, y rastrea su papel en la transformacin de la cultura. Devlin (lnjoSense: Turning Information Into Know/edge, W. H. Freeman & Co., 1999) intenta
darle sentido al constante flujo de informacin que bombardea a la poblacin diariamente.
Gleick (Faster: The Acceleralion of fust About Everything, Pantheon Books, 2000) estudia la tasa
siempre en aceleracin del cambio tecnolgico y su impacto sobre todos los aspectos de la vida
moderna. Jonscher (The Evolution of Wired Ufe: From the Alphabet to the Soul-catcher Chip-How
Tnformation Technologies Change Our World. Wiley, 2000) argumenta que el pensamiento y la
interaccin humanas trascienden la importancia de la tecnologa.
En Internet hay disponible una amplia variedad de fuentes de informacin acerca de las
direcciones futuras en las tecnologas relacionadas con el software y la ingenierla de software
Una lista actualizada de referencias en la World Wide Web se puede encontrar en el sitio Web
SEPA:
http:/ / www.mhhe.com/pressman.
,
INDICE ANALTICO
ABC MPI, 37
Abstraccin, 252
Accesibilidad, 375
Acciones, 25
Acoplamiento, 260, 482
niveles de, 329
medicin, 487,489
Actividades, 24
Actividades de sombrilla, 24, 28
Actividades del marco de trabajo,
24, 26
genricas, 26
Actores, 173, 206
Agilidad, 79. Vase tambin
Proceso gil
definicin de, 79
factores humanos, 82
principios de la, 80
Almacenamiento de datos, 278
Ambiente de trabajo, 368
mbito, 112
mbito del software, 651 , 693
lmites, 693
Anlisis, 192. Vase tambin
Anlisis de los requisitos
orientado a objetos, 201
patrones, 183 (Vase tambin
Patrones)
reglas por experiencia, 194
Anlisis de inventario, 909
Anlisis de peligros, 762
Anlisis de requisitos, 192. Vase
tambin Anlisis
objetivos del, 193
ingeniera Web, 545
Anlisis de tareas, 361
Anlisis del rbol de decisin,
717
Anlisis del dominio, 194
Anlisis del flujo de trabajo, 364
Anlisis del usuario, mtodos
l?ara el, 361
Anlisis del valor de frontera,
437,624
Anlisis del valor ganado (AVG),
742
Anlisis gramtico, 212
Anlisis Relacin-Navegacin
(ARN), 589
Aplicaciones basadas en Web.
Vase WebApps
rbol de datos, 552
rbol de requisitos de la calidad,
WebApps, 568
Arquetipos, 289
Arquitectura, 253
anlisis de sensibilidad, 294
aplicaciones basadas en Web,

587
de datos, 140
descripcin de la, 276
importancia de la, 277
MVC, 589
Arquitectura de aplicacin, 8-9
Arquitectura de datos, 140
Arquitectura del agente para solicitud de objeto, 890
Arquitectura del contenido, 586
estructuras, 586
Aseguramiento de la calidad, 770
actividades, 773
estadstico, 783
historia, 772
plan, 791
Aseguramiento de la calidad del
software (SQA). Vase
Aseguramiento de la calidad
Asociaciones, 232
Atributos, 222
Atributos de los datos, 198
Auditora de configuracin, 813
aplicaciones basadas en
Web, 823
Auditoras, 806. Vase tambin
Auditora de configuracin
Autentificacin, 631
Autoridad del control del cambio
(ACC), 810
Autorizacin, 62
Base de datos del proyecto, 800.
Vase tambien Depsito
Caja de tiempo, 740
Calendarizacin, 724, 727, 736
conceptos, 725
principios, 728
seguimiento, 739
varianza, 743
Calidad
contexto de la 1SBC, 896
costo de la, 770
definicin de, 463, 769
determinantes, 665
directrices para la !Web, 5 13
factores, 464
factores del ISO 9 126, 465
medicin, 676
medidas de la, 677
Calidad de la concordancia, 769
Calidad del diseo, 769
Calidad del software. Vase
Calidad
Calificacin de componentes, 887
cambio, 6, 7, 114
mbito del, 929
impacto sobre el software, 6
origen del, 797
caos,48
Capital del software, 22
Caracterstica, definicin de, 95
Cardinalidad, 199. 232
Casos de prueba
caractersticas de los, 420
derivacin, 427
Categoras de usuario, definicin
de las, 521
Centro de transaccin, 306
Certificacin, 874
Clase
agregada compuesta, 230
multiplicidad, 232
Clase-responsabilidad-colaborador, 225. Vase tambin
Modelado CRC
Clases de anlisis
554
atributos, 221
caractersticas de las, 221
identificacin de las, 219
operaciones, 223
tipos de, 219. 226-227
Clases de controlador, 227
Clases de diseo, 259
caractersticas de las, 260
tipos de, 259
Clases de entidad, 226
Clases de frontera, 226
Clientes, 111
COCOMO 11, 71 O
Codificacin, 631
Codificacin, principios, 123
Cdigo fuente
a nivel de programa, 493
medicin, 493
volumen, 493
Cohesin, 260, 483
medicin para la, 489
niveles de, 326
Colaboracin, 83, 11 O
definicin de CRC, 228
Complejidad, 482, 490
medicin, 491
Complejidad ciclomtica, 426
componentes
adaptacin de, 888
basados en clases, 321
clasificacin de, 893
composicin de, 888
convencionales, 317, 340
943
944
INDICE ANALTICO
definicin de, 315,889

descripcin de, 892
ejemplo de diseo de, 321
ingeniera de, 890
nuevos,696
reutilizables, 695
visin 00, 316
Comprobacin de correccin,
867,868
Comprobaciones subordinadas,
869
Computacin ubicua, 1o
Comunicacin, 26, 110
conjunto de tareas, 112
del cliente, 523
ingenierla Web, 510, 523
principios de la, 11 O
Concurrencia, 286
Condicin posterior, 834
Condicin previa, 833
Configuracin del software, 797
Conjunto de base, 424, 425
Conjunto de cambios, 809
conjunto de tareas
comunicacin, 112
comunicacin con el cliente,
524
construccin, 124
definicin del, 27
despliegue, 128
diseo, 122
modelacin del anlisis, J 18
planeaci6n, 11{,
planeacin del proyecto, 693
prueba:;, 125-126
pruebas de aplicaciones basadas en la Web, 611
refinamiento del, 737
seleccin. 732
conocimiento, 9.34
consecuencias imprevistas, 1
Consejo Airlie, 658
Construccin, 26, 399

ingeniera Web, 510
prctica, 122
Construccin basada en componentes, 8
Construcciones estructuradas,
340
Control de calidad, 770
Control de la variacin, 768
Control de la versin, 805, 808
aplicaciones basadas en la
Web, 822
Control del cambio, 810
flujo de trabajo, 81 1
tipos de, 811
Controlador vista del modelo
(MVC), 589
controladores, 394
Correccin, 677
comprobacin de la, 868
condiciones, 869
verificacin de la, 867, 868
Cortafuegos, 631
Costo, varianza, 744
Costos de falla, 771
Costos de prevencin, 770
Costos de valoracin, 770
Cristal, 95
Curva de la baera, 5
Curva Putnam-Raleigh-Norden,
730
Curvas de falla, 7
Decisin de hacer la compra, 71 7
Defectos, 775
Dependencias, 232
Depsito, 801
caractersticas del, 804
contenido, 804
Depuracin, 408
consideraciones psicolgicas.
410
estrategias, 41 1
proceso de, 409
tcticas, 412
Desarrollo basado en componentes (DBC), 63, 886
Desarrollo conducido por la
caracterstica (DCC), 95
Desarrollo del software adaptativo (OSA), 89
Desarrollo orientado a aspectos,
65
Descomposicin del problema,
652
Descomposicin funcional, 362
Desgaste, s, 6
Despliegue, 26
principios, 126
ingeniera Web, 510
Despliegue de la funcin de calidad (QFD), 171

Deterioro, 6
Diagrama de caso de uso, 150
Diagrama de clase, 148, 223
Diagrama de contexto, 212
Diagrama de contexto de la arquitectura (DCA), 288
Diagrama de contexto del sistema, 145
Diagrama de despliegue, 148
Diagrama de estado, 181,216,
237,555
utilizacin de pruebas, 450
Diagrama de flujo, 340, 341
Diagrama de flujo de datos
(DFD), 212,299
Diagrama de flujo del sistema
(DFS), 146
Diagramas de actividad, 148,

180, 208,340
Diagramas de relacin de entidad, 200
Diagramas de secuencia, 238
Web, 554, 555
Diseo,245,275,314,350
a nivel de componente, 314,
593
Web, 566
arquitectnico, 275, 585
atnbutos de calidad, 251
comprobacin de la correccin del, 868
conjunto de tareas, 122, 252
directriz de calidad, 249
esttico, 582
hipermedia, 595
ingeniera del software de sala
limpia, 867
interfaces con el usuario, 350
interfaces para aplicaciones
basadas en Web, 573
medicin, 479
proceso, 250
verificacin, 867
Diseo al nivel de componentes,
314
593
directrices, 326
pasos,331
principios bsicos, 322
Diseo arquitectnico, 275, 287
Web, 585
complejidad del, 296
diagrama del flujo de datos,
297
evaluacin del, 294
refinamiento del, 290, 31 O
Diseo de datos, 26
a nivel arquitectnico, 278
a nivel de componente, 279
Diseo de interfaz, 350
anlisis del, 358
Web, 573
flujo de trabajo, 368, 580
patrones para el, 371,372
principios del, 351, 574
proceso del, 358
Diseo de la interfaz con el
usuario, 350
anlisis de tareas, 361
anlisis del flujo de trabajo, 364
aspectos del, 372
evaluacin del, 3 77
medicin, 492
principios del, 352
945
NDICE ANATICO
proceso, 358
pasos, 368
reglas de oro, 351
Diseo de navegacin, 590
Diseo del contenido, 584
Diseo esttico, 572, 582
582
aspectos de configuracin, 582
Diseo grfico. Vase Diseo
esttico
Disponibilidad, aplicaciones
basadas en Web, 569
Distribucin, 286
Distribucin del esfuerzo, 732
Dominio semntico, 844
ECS,803
Ecuacin del software, 712, 731
Eficacia en la remocin de defectos (EED), 678
Eficiencia, 466
Elaboracin, 159, 652
Elaboracin de objetos, 364
Elaboracin de tareas, 363
objetos, 364
tareas, 363
Elementos de configuracin del
software (ECS), 800
Elementos de diseo
arquitectnico, 264
componentes, 266
datos, 263
despliegue,267
interfaz, 264
Elementos del sistema, 134
Encubrimiento de componentes,
888
Ensayo, 774. Vase tambin
Revisiones
Entrega incremental, 81
Envoltura, 888
Equipo de medicin, MDOO, 485
Equipos
giles, 82,649
coordinacin, 650
cuajados, 83, 90, 647
ingeniera Web, 526
organizacin propia, 83
programador en jefe, 647
tipos de, 646
Equipos giles, 649
Equipos de software. Vase
Equipos
Errores, 775
correccin de, 414
costo relativo, 771
Escalabilidad, WebApps, 569
Escenarios del usuario, 172
Especificacin, 160
Especificacin constructiva, 837
Especificacin de caja de estado,
866
Espectficacin de caja negra, 865

Especificacin de caja transparente, 866
Especificacin de la estructura de
caja, 864
Especificacin del control (EC),
215
Especificacin del proceso (EP),
217
Especificacin formal, 842
Espectro de la informacin, 933
Estado, 833
Estereotipo, 232
Estilos arquitectnicos, 280
centrada en datos, 281 -282
estratificada, 284
flujo de datos, 281
llamada y retorno, 283
orientada a obetos, 284
taxonomla de os, 281
Estimacin, 690, 696
Factores de calidad de MccaJI,
463
Factores humanos, 82
Factorizacin, primer nivel, 302
Fiabilidad, 465, 786
medidas de, 787
Filtros, 283
Flujo de transformacin, 297
Formas de navegacin (FdN), 591
Formato de condicin-transmisin-consecuencia (CTq.
759
Formulacin, 510,517
de preguntas, 519
recopilacin de requisitos. 520
Fuente abierta, 10
Funcionalidad, 465
Funciones de ayuda, 373
Funciones de caracterizacin,
884
Fundamentos. 741
puntos de fijacin, 59
715
basada en PF, 702

basada en LDC, 700
basada en el problema, 699
basada en el proceso, 704
descomposicin, 698
desarroUo gil, 714
estimacin, 713
modelos, 71 O
modelos empricos, 709
observaciones, 691
proyectos 00, 713
tcnicas automatizadas, 709
uso-casos, 705
Estimacin del proyecto. Vase
Estimacin
Estimaciones
ingenieria Web, 534
reconciliacin, 708
Estructura de anlisis de trabajo
(EAT), 737
Estructura de superficie, 445
Estructura profunda, 445
tica, 936
cdi~o de, 936
consideraciones personales,
937
Evaluacin del riesgo, 752, 757
Eventos, 215, 235
Evolucin del software, 12
leyes de la, 13
Evolucin. Vase Evolucin del
software
Expos1c1n al riesgo, 757
clculo de la, 757
Extraccin de datos. 278
Facilidad de mantenimiento, 466,
677
Factibilidad, 693
GCS, 797,815
elementos de la, 799
escenario, 798
estndares, 824
estratos del proceso, 807
funciones, 805
gestin del cambio, 820
gestin del contenido, 817
identificacin, 807
ingenieria Web,
medicin, 598
medicin del valor de nego
cios, 538
modelo de anlisis. 580
objetos de configuracin, 81 7
jerarqua del usuario, 546
proceso, 806
pruebas de desempeo, 631
pruebas de navegacin, 625
pruebas de seguridad. 680
tipos de, 506
Gestin de la calidad, 767. Vase
tambin Aseguramiento de
la calidad
Gestin de la configuracin del
software. Vase GCS
Gestin de la configuracin,
829. Vase tambin SCM
Gestin de requisitos, 161
Gestin del cambio, 796. Vase
tambin GCS
815
Gestin del contenido, 817
Gestin del proyecto, 640
aspectos de la, 643
prcticas criticas, 658
Gestin del proyecto de software.
Vase Gestin de proyecto
Gestin del riesgo, 747
946
NDICE ANALTICO
Grfica de flujo, 423, 425

Grfica de la estructura, 320
Grfica de lnea de tiempo, 737
Graficacin de la transaccin,
306
Graficacin de la transformacin,
299
Graficacin del flujo de datos,
298
Grfico de estado, 336
Granularidad, 114
Grupo independiente de prueba
(GIP), 386
GUI, 451
facilidad de uso, 620
jerarqua de clase, 444
mediciones para, 494
mtodos 00, 44 1
modelacin del flujo de datos,
436
modelado del flujo de transaccin, 436
modelacin del estado finito,
435
modelos de comportamiento,
451
navegacin, 61 O
opciones, 400
particin, 447
particiones de equivalencia,
436
patrones, 455
principios, I 24
proceso para aplicaciones
ba5adas en Web. 609
ruta bsica, 423

servicios de ayuda, 454
sistemas en tiempo real, 455
tcnicas, 418
Herramientas, 24
almacenamiento de datos,
279
anlisis estructurado, 218

basadas en Web, 599
calendarizacin, 737
casos de uso, 78
DBC, 895
depuracin, 413
desarrollo de la interfaz con el
usuario, 376
desarrollo gil, 98-99
diseo de casos de prueba,
439
estimacin, 716
gestin de la calidad, 791
gestin del cambio, 822
gestin del contenido, 819
gestin del proceso, 66
gestin del proyecto, 659
gestin del proyecto de ingeniera Web, 536
~estin del riesgo, 763

ingeniera de los requisitos,
163
ingeniera inversa, 916
intermedias, 321
LDA. 297
medicin de aplicaciones
basadas en Web, 599
medicin del producto, 495
medicin del proceso y el proyecto, 676
mtodos formales, 852
minera de datos, 279
modelado de datos, 200
modelado del anlisis en
UML, 239
modelado del proceso, 43
modelado del sistema, 151
PDL, 344
planeacin de pruebas, 408
pruebas de aplicaciones basadas en Web, 633
reestructuracin, 918
RPN,905,906
simulacin del sistema, 139,
140
soporte de la GCS, 814
UML/OCL, 339
Herramientas del software. Vase
Herramientas
Historias del usuario, 85
Hogarseguro
rbol
datos, 552
carta ndice CRC, 226
ae
clases de anlisis. 220. 554

clases de diseo, 261
configuracin de pantalla, 371
DCA, 289
diagrama de ACTIVIDAD, 209,
558
diagrama de carriles, 21 o
diagrama de clase, 181, 225
diagrama de despliegue, 268
diagrama de estado, 216,237,
555
diagrama de flujo de datos,
212,213,300
diagrama de secuencia, 238,
554
diagrama uso-caso, 178, 208
diseo de componente, 344
EP, 217
esquema conceptual, 597
estructura arquitectnica, 292,
306,310
estructura de la funcin de
seguridad, 292
modelo CRC, 231
narrativa de procesamiento,
212
objetos del contenido, 584
relaciones de clase, 290
USN, 592
uso-casos, 175,205,369,549
HogarSeguro (cuadros al margen), 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
Hojas de informacin del riesgo,
757,762
Idiomas, 270
IMCM, 29
adopcin de la, 32
modelo continuo, 30
metas, 32
modelo por etapas, 32
niveles .de capacidad, 30
prcticas, 31
Impurezas, 775
Incremento. Vase Incrementos
del software
Incrementos de software, 51, 81
Independencia funcional, 256
Indicadores, 466
Indice de calidad de la estructura
del diseo (ICED), 480
Informacin, representacin de
la, 933
Informe de cambios, 810
Infraestructura, tecnologa, 141
Ingeniera de requisitos, 155
tareas de la, 157
Ingenierla de software de sala
limpia, 64, 850
certificacin, 874
diferenciacin de caractersticas, 862
diseo, 867
especificacin funcional, 863
estrategia, 860
pruebas, 872
Ingeniera del diseo, 245
Ingeniera del dominio, 883
Ingeniera del proceso de negocios (IPN), 903
jerarqua, 141
Ingeniera del producto, 142
Ingeniera del sistema
jerarqua, 136
visin mundial, 136
Ingeniera del software
definicin de la, 23
de sala limpia, 858
estratos, 24
tica, 936
futuro de la, 927
947
NDICE ANALTICO
prctica, 104. Vase tambin

Prctica
principios, 107
Ingeniera del software asistida
por computadora. Vase
Herramientas
Ingeniera del software basada
en componentes, 879,880.
Vase tambin ISBC
Ingeniera directa, 911, 918
cliente/servidor, 920
sistemas 00, 921
Ingeniera inversa, 910, 912
datos, 913-914
procesamiento, 914-915
Ingeniera Web (!Web}, 502
actividades del marco de trabajo, 509
caracteristicas del equipo, 527
casos de uso, 547
construccin del equipo, 528
desarrollo en casa, 533
directrices de calidad, 513
diseo a nivel de componente, 593
diseo arquitectnico, 585
diseo de interfaz, 573
diseo de navegacin, 590
diseo del contenido, 584
estimacin, 715
formulacin, 517 (Vase tambin Formulacin)
GCS, 815
herramientas, 508
las peores prcticas, 539
las mejores prcticas, 512
mtodos, 507
medicin, 536
medicin del diseo, 598
modelado del anlisis, 544
planeacin, 525
preguntas bsicas, 511
proceso,507,508,511
pruebas, 604,607,612
subcontratacin, 530
Ingeniera Web, pirmide de diseo, 572
Inicio, 157
Inmediatez, 505
Inspecciones, 774. Vase tambin
Revisiones
Integridad, 678
Intereses generales, 65
Interfaz con el usuario, 349.
Vase tambin Interfaz
anlisis, 359
,
carga de memoria, 353
consistencia, 354
contenido del despliegue, 367
control del usuario, 351
ingeniera inversa, 915

mecanismos de control, 579
modelo de anlisis, 356
patrones, 3 72
prototipo, 557, 580
pruebas, 616
Intermedio (middleware}, 322
Internacionalizacin, 375
Invariante de datos, 834
ISAC. Vase Herramientas
ISBC, 879
anlisis del costo, 897
economa de la, 895
proceso, 882
ISO 9000, 790
ISO 9001: 2000, 38, 790
esquema del. 790
Itinerario del proyecto. Vase
Calendarizacin
Jerarqua del contenido, 552
Jerarquas de usuario, 546
Lenguaje de diseo de programa.
Vase LDP
Lenguaje de especificacin Z,
849
ejemplo, 849
notacin, 850
Lenguaje de restriccin de objetos (LRO}, 338, 845
condiciones previas/posteriores, 337
ejemplo de, 84 7
invariante, 338
notacin, 846
visin general, 845
Lenguajes de descripcin arquitectnica (LOA), 296
Lenguajes de especificacin formal, 844
Ley de Oemter, 261
Ley de Fiit, 576
Lder del equipo, 644
Lnea de base, 800
definicin de, 800
medicin, 681
Lista de problemas, 169
Lista de verificacin
calidad del diseo de
WebApps, 570
validacin de requisitos, 161,
186
Lista de verificacin de elementos de riesgo, 750
Lista de verificacin para la validacin de requisitos, 161
Manejo del error, 374
Manifiesto, desarrollo de software gil, 77
Manifiesto gil, 77
Mantenimiento, 7. 12, 907

medicin del, 496
Mantenimiento del software, 7,
12,907. Vase tambin
Mantenimiento
Marcos de trabajo, 270
Matrices grficas. 430
MDHOO, 595
diseo abstracto de interfaz,
597
diseo conceptual, 595
diseo de navegacin. 596
MDSD, 91
rein~enier[a, 908
Medicion (mtricas), 467
acoplamiento, 487
anlisis de, 474
a nivel de componentes, 488
536,598,674
argumentos para la, 680
atributos de la, 471
basada en la funcin, 474
calidad, 677
calidad de la especificacin,
477
cdigo fuente, 492
cohesin, 489
complejidad, 491
definicin, 467
diseo, 479
diseo arquitectnico, 479
establecimiento, 684
etiqueta, 666
interfaz con el usuario, 492
lnea de base, 681
mantenimiento, 496
orientada a la clase, 486
orientada al tamao, 669
orientada a objetos, 481, 495,
673
orientada a la operacin, 491
organizaciones pequeas, 682
privada,666
proceso. 663, 682
productividad, 699
proyecto, 462, 472. 667
pruebas, 494
pblica, 666
retos, 468
tipos de, 471
Medicin de Halstead, 493
Medicin de la productividad,
699
Medicin de linea de cdigo
(LDC), 669
Medicin del software. Vase
Medicin
Mediciones CK, 482
Medidas, 467
directas, 668
indirectas, 668
NDICE ANALTICO
MEIEP, 37
Mejoramiento del proceso del
software (MPS), 664
estadstico, 667
Mel, 92
principios, 93
reuniones, 94
Metfora, 577
Mtodo de anlisis del cambio de
arquitectura (MACA), 294
Mtodos, 24
Mtodos formales, 64, 830
conceptos, 830, 833
definicin de, 830
directrices de los, 852
preliminares matemticas.
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, 51 O
Modelado gil, 97
principios del, 97- 98, 121
Modelado CRC, 225, 226
en PE, 86
Modelado de datos, 197
Modelado de Hatley-Pirbhai, 144
Modelado del anlisis, 159, 191
tu.1wdo en clai5ci5, 161, 21~
basado en escenarios, 179,
202

contenido, 551
del comportamiento, 181,234
enfoques, 196
ingeniera Web, 544
interaccin, 554
orientado al flujo, 182, 2 11
principios, 117
Modelado del diseo, principios,
119
Modelado del flujo de control,
215
Modelado del sistema, 137, 144
factores restrictivos, 138- 139
UML, 147
Modelado estructural, 885
Modelo clsico del ciclo de vida,
50
Modelo CRC
colaboraciones, 228
construccin, 225
responsabilidades, 227
revisin de directrices, 233
Modelo de amplificacin del
defecto, 776
lodelo de anlisis

550
elementos del, 179, 197
relacin con el diseo, 247
Modelo de comportamiento, 235
Modelo de desarrollo concurrente, 60
Modelo de espiral, 58
problemas con el, 59
Modelo de interaccin, 554
Modelo de la cascada, 50
problemas con el, 51
Modelo del contenido, 551
Modelo del diseo, 247
dimensiones del, 263
relacin con el anlisis, 247
Modelo ORA, 53
retrocesos, 54
Modelo funcional. 557
Modelos de proceso
gil,81
cascada, 50
Cristal, 95
DAR, 53
DAS, 89
DCC, 95
determinados por el riesgo, 58
desarrollo concurrente, 60
diferencias, 28-29
especializado, 63
espiral, 58
estados de bloqueo, 51
evolutivo, 54
incremental, 52
ISBC, 882
RPN,904
Programacin Extrema, 84
prescriptivo, 49
prototipos, 55
sala limpia, 859
Modelos evolutivos, 54-55
Modelos incrementales, 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
semntica, 591, 626
sintaxis, 590, 592, 625
Negociacin, 112, 160, 184
Nodos de navegacin, 591
Notacin del diseo
basada en texto, 242
comparacin de la, 345
grfica, 340
tabular, 342
Nueva economa,
lo
Objeto de los datos, 197

Objetos de configuracin, 802
817
Objetos de contenido, 551, 584
Obtencin, 158, 652
Obtencin de requisitos, 166
Ocultamiento de informacin,
256
OMG/CORBA, 889
Operaciones, 223, 833
identificacin, 223
Operadores de conjunto, 838
Operadores lgicos, 840
Orden del cambio, 810
Organizacin propia, 83-84
Orientado a ojetos
conceptos, 201
estimacin, 713
seguimiento del proyecto, 741
Paquetes, 234
Paquetes de anlisis, 234
Paradigma OPM, 469
Particin, 652
de equivalencia, 435, 623
Patrones, 108, t 19, 124
anlisis de, 183
arquitectnicos, 280, 281, 284
diseo, 254
diseo de hipermedia, 594
depsitos de hipermedia, 595
interfaz con el usuario, 371
plantilla de patrones para el
anlisis, 183
plantilla para los, 37
proceso, 36
pruebas, 455
Patrones arquitectnicos, 280
refinamiento de los, 287
tipos de, 586
Patrones de diseo, 254. Vase
tambin Patrones
descripcin de los, 269
plantillas, 269
uso de, 270
Patrones del proceso, 34
ejemplo de, 36
PE. Vase Programacin Extrema
(PE)
Persistencia, 286
Personal, 641, 930
aspectos de gestin, 64 J
relacin con el esfuerzo, 729
usuarios, 643
PERT/CPM, 736
Peso del vnculo, 429, 433
Plan de SQA, 791
949
NDICE ANATICO
Planeacin, 26, 655

Planeacin de pruebas, 381, 608
Planeacin del ciclo adaptativo
(PCA), 90
Planeacin del proyecto, 692
Plan RSGR, 761, 763
Plantilla modelo del sistema, 145
Portabilidad, 465
Prctica (ingeniera del software),
103-132
Preguntas, libres de contexto, 55
Primitivismo, 260, 482
Principio abierto-cerrado (PAC),
322
Principio de cerradura comn
(PCC), 325
Principio de equivalencia de la
reutilizacin (PER), 325
Principio de inversin de la
dependencia (PSI), 324
Principio de Pareto, 125
Principio de reutilizacin comn
(PRC), 325
Principio de segregacin de interfase (PSI), 324
Principio de sustitucin de Liskov
(PSL), 324
Principio W 5HH, 115, 657
Principios, 1 13, 655
anlisis, 1 17
codificacin, 123
comunicacin, 11 O
despliegue, 126
diseo, 119- 120
ingeniera del software, 107
JWeb, 511, 525
modelado gil, 121
planeacin, 1 13
pruebas, 124
Proceso, 24
aspectos de la gestin del proyecto, 653
aspectos de gestin, 642
descomposicin, 654
direcciones futuras, 931
evaluacin, 37
marco de trabajo, 24
medicin, 663
relacin con el producto, 43
Proceso gil, 81
poltica del, 81
Proceso del software en equipo
(PSE)
objetivos, 40
escritos, 41
Proceso del software personal
(PSP), 39
Proceso unificado (PU), 67
fases , 68
historia del, 67
productos del trabajo, 71
Procesos de negocios, 904
Producto, 651
aspectos de gestin, 642
del trabajo, 173
relacin con el proceso, 43
Producto esencial, 52
Programacin estructurada, 340
Programacin extrema (PE), 84
codificacin, 87
diseo, 86
planeacin, 85
pruebas, 88
Programacin par, 87
Prototipos, 55
problemas con los, 57
Proyectos
diferencias. 526
estimacin, 690
medicin 00, 673
medicin para, 667
problemas, 656
seguimiento, 739
tipos de, 733
Proyectos de software. Vase
Proyectos
Prudencia, 934
Prueba beta, 405
Prueba de caja negra, 422, 433
Prueba de ruta bsica, 423
ejemplo de, 428
Prueba de unidad, 88
Pruebas
aleatorias, 48
a nivel de componente, 610,
623
604
arquitecturas convencionales,
386
arquitecturas 00, 388
basadas en el uso, 403
basadas en escenarios, 444
basadas en faltas, 443
basadas en grficas, 434
basadas en la clase, 44 7
basadas en ligas, 403
base de datos, 613
caractersticas genricas, 383
contenido, 610,6 12
cliente/ servidor, 452
criterio de completitud, 389
de clase mltiple, 449
de uso estadstico, 873
documentacin, 454
especializadas, 452
estrategias, 383, 390
estrategias 00, 402
estructura de control, 430
estructura profunda, 446

estructura de superficies, 446
exhaustivas, 422
ingeniera del software de sala
limpia, 872
interfaces, 610,616,617,619
lmites, 43 7
tabla ortagonal, 438
Pruebas a la configuracin
611,628
del lado del cliente, 629
del lado del servidor, 628
Pruebas a la unidad, 388, 392
ambiente para las, 394
consideraciones de las, 392
procedimientos para las, 393
Pruebas a las bases de datos, 613
Pruebas al Oujo de datos, 431
Pruebas al sistema, 388, 406
Pruebas alfa, 405
Pruebas de aceptacin. 88
Pruebas de agrupamiento, 404
Pruebas de bucle, 431
Pruebas de caja blanca, 423
Pruebas de carga, 633
Pruebas de compatibilidad, 622
Pruebas de condicin, 431
Pruebas de desempeo, 408, 63 l
Pruebas de humo, 399
Pruebas de integracin, 388, 394
Pruebas del contenido, 612
Pruebas de tabla ortogonal, 438
ascendentes, 398
documentacin, 400
descendente, 396
estudio, 395
humo, 395
Pruebas de navegacin, 625
Pruebas de recuperacin, 407
Pruebas de regresin, 398
Pruebas de ruta, 624
Pruebas de software. Vase
Pruebas
Pruebas de tensin, 408, 633
Pruebas de validacin, 388, 404
criterios, 404
principios, 123
Pruebas estadsticas de uso, 873
PSE,40
PSP,39
Puntos de fijacin, 59.
Puntos de funcin, 474, 670
cmputo de, 476
lenguajes de programacin,
672
reconciliacin, 671
Puntos de la estructura, 885
anlisis del costo, 897
caracteristicas de los, 885-886
Puntos de objeto, 71 1
950
INDICE ANATICO
Puntos de prioridad, 165

Puntos vitales, 784-785
Recopilacin de requisitos
colaborativa, 167 (Vase tambin Obtencin)
directrices, 167
equipo, 168
Recopilacin de requisitos,
WebApps, 520
Recursos ambientales, 696
Recursos del proyecto, 694
Recursos humanos, 695
Red de actividad, 735
Red de tareas, 735
Reestructuracin
de cdigo, 917
de datos, 917
Reestructuracin de cdigo, 911
Reestructuracin de datos, 911
Reestructuracin de documentos,
910
Refabricacin, 87, 258
Refinamiento, 257
Refinamiento paso a paso, 257
Regla 40-20-40, 732
Reingeniera, 906
economa de la, 923
modelo del proceso, 908
Reingeniera del proceso de
negocios (RPN), 903
modelo del proceso, 904
Relaciones del contenido. 554
Reportes de estado, 814
R.equisitos de los aspectos. 65
Requisitos, validacion de los. 186

Resguardos, 394
Responsabilidades, definicin de
CRC, 227
Retraso, 93
Reutilizabilidad, 64
Reutilizacin, 8, 109, 269, 325,
894
anlisis y diseo, 891

medio ambiente, 894
Revisin de la configuracin, 405
Revisiones. Vase tambin
Revisiones tcnicas formales (RTF)
basadas en muestra, 781
conservacin del registro, 779
directrices, 780
junta de reunin, 778
reporte general, 779
reportes, 779
Revisiones basadas en muestra,
781
Revisiones del software, 774.

Vase tambin Revisiones
P.e\isiones tcnicas formales
RTFl 250, 577, 774. Vase
wmb1n Revisiones
Riesgo, 114
componentes, 753
estrategias, 74 7
formato CTC, 759
definicin de, 748
controladores, 753
identificacin, 750
impacto, 754, 757
planeacin, 759
proyeccin, 754
refinamiento del, 759
tipos de, 748
Rotulacin, mens y comandos,
374
Ruta crtica, 736
Rutas de accin, 306
Rutas independientes, 424
Salvaguarda del software, 762,
788
Seguimiento de conflictos, 808
Seguimiento de la dependencia,
805
Seguimiento de requisitos, 805
Seguimiento del proyecto, TWeb,
535
Seguridad, 407, 506
Web, 569
pruebas de, 407, 630
Servicios otorgados, 807
Sigma seis, 785
Similaridad, 482
Simulacin del sistema. 139
Sistema
definicin de, 134
elemento macro, 135
Sistema de versiones concurrentes (SVC), 809
Sistemas basados en componentes, 880
Sitios Web, bien diseados, 583
Software
aplicaciones heredadas, 11
caractersticas del, 5
definicin de. 4
mitos acerca del, 14
papel evolutivo del, 2
preguntas fundamentales, 4-5
referencias histricas, 4
Software de ingeniera y cientfico, 9
Software de Inteligencia
Artificial, 9- 1o
Software de lnea de producto, 9
Software de sistema, 8
Software heredado, 11
calidad del, 12
Software, categoras de aplicacin, 8-9
Software empotrado, 9
Solicitud de cambio, 81 O
Solucin de problemas, 106

Solucin pico, 86
Soporte, 126
SPlCE, 37
Sprint, 94
Subcontratacin, 718
ingeniera Web, 530
Sucesiones, 841
Suficiencia, 482
Susceptibilidad a las pruebas,
caractersticas de la. 420
Tabla de decisin, 342
Tabla de recursos, 739
Tabla de riesgo, 754
Tablas de rastreabilidad, 162
Tamao. 482
Tamao, proyectos de software,
698
Tecnologa del proceso, 42
Tecnologas, futuro, 929, 935
Tiempo de respuesta, 373
Tiempo en el mercado, aplicaciones basadas en Web, 569
Tiempo medio de reparacin
(TMDR), 787
Tiempo medio entre fallas
(TMDF), 787
Toxicidad del equipo, 648
Transaccin, 298
Tubos,282
UML
diagrama de actividad, 148,
180 209,335
diagrama de carriles, 209, 366
diagrama de caso de uso, 150,
178,547
diagrama de colaboracin,
332
diagrama de clase, 150, 180
diagrama de despliegue, 148,
268
diagrama de estado, 181,216,
247
diagrama de modelacin del
sistema, 148
diagramas de secuencia, 238
elaboracin del componente,
318
estereotipo, 233
grfica de estado, 336
OCL, 337, 845
paquetes, 234
representaciones de interfaz,
265,333
Unidad semntica de navegacin
(USN). 592, 626
Uso, casos de, 360
anlisis de tareas, 361
Web, 524,547,554
INDICE AMATICO
desarrollo del, 173

escritura, 202
identificacin de eventos, 235
medicin, 674
preguntas acerca del, 174175
usuario, 26, 643
identificacin del, l 73
puntos de vista mltiples, 173
usuarios finales, 111

Validacin, 161, 384
Velocidad del proyecto, 86
Verificacin, 384
Vnculos de navegacin, 591
Volatilidad, 483
WebApps, 9, 504
atnbutos de las, 504
Siglas espaol/ingls
Trmino equivalente en espaol
Trmino equivalente en ingls
ABC MPI (apreciacin basada en el CMM para el mejoramiento del proceso interno) 37
ACC (autoridad del control del cambio) 8 1O
ADP (paradigma de diseo abstracto) 883
AECO (acoplamiento entre clases de objetos) 485
AG2D (anlisis geomtrico bidimensional) 701
AG3D (anlisis geomtrico tridimensional) 70 I
AIE (archivos de interfaz externos) 475
ALI (archivos lgicos internos) 474
AOO (anlisis orientado a objetos) 201
APD (acceso pblico a datos) 495
APH (rbol de profundidad de la herencia) 484
ARN (anlisis relacin-navegacin) 560
AVCi (anlisis del valor ganado) 742
AVL (anlisis de valores lmite) 437
CAD (diseo asistido por computadora) 700
CCYD (componentes comerciales ya desarrollados)
CMM (based appraisal for interna! procces improvement

CBA IPI)
CCA (change control authority)
ADP (abstract design paradigm)
CBO (coupling between object classes)
2DGA (two-dimensional geometric analysis)
3DGA (three-dimensional geometric analysis)
EIFs (externa! interface files)
ILFs (interna! logical files)
OODA (object-oriented doma.in analysis)
PAD (public access to data members)
DIT (depth of the inheritance tree)
RNA (relationship-navigation-analysis)
EVA (earned value analysis)
BVA (boundary value analysis)
CAD (computer aided design)
COTS (comercial ofT-the-shel t)
695
CDL (componentes comerciales de lnea) 88 1
CE (consultas externas) 474
CN (Contador numrico) 6?6
CO (complejidad de la operacin) 491
coc oMO (modelo constructivo de costos) 7 LO
COM (modelo de objetos para componentes) 889
CORBA (arquitectura comn de distribucin de objetos)
COTS (comercial otr-the-shell)

EQs (externa] inquiries)
NC numerical control)
oc (operation complexity)
COCOMO (constructive cost model)
COM (component object model)
CORBA (common object request broker architecture)
889
CPTC (costo presupuestado para el trabajo

calendarizado) 743
CPTR (costo presupuestado del trabajo realizado) 743
CRC (clase-responsabilidad-colaborador) 225
CRTR (costo real del trabajo realizado) 743
CTC (condicin-transicin-consecuencia) 759
DAS (desarrollo adaptativo de software) 89
DBC (desarrollo basado en componentes) 63
DBMS (gestor de bases de datos) 614
D CA (diseo de contexto arquitectnico) 288
OCBD (descubrimiento de conocimiento en base
de datos) 278
DCC (desarrollo conducido por ca ractersticas) 95
DCS (diagrama de contexto del sistema) 145
DFD (diagrama de flujo de datos) 211, 298
DFS (diagrama de flujo del sistema) 146
DIE 1des11iacin intencional de las especificaciones) 784
on documentacin imprecisa o incompleta) 784
BCWS (budgeted cost of work scheduled)

BCWP (budgeted cost of work performedJ
FTR (formal technical reviews)
ACWP (actual cost of work performer)
CTC (condition-transition-consequence)
ASO (adaptative software development)
CBD (component based development)
DBMS (database manager system)
ACD (architecture context diagram)
KDD (knowledge discovery in databases)
FDD (feature driven development)
seo (system context diagram)

DFD (dala flow diagram)
SFD (system flow diagram)
IDS (intentional deviation from specifications)
UD (inaccurate or incomplete documentation)
fNDICE DE SIGLAS MS COMUNES EN INGENIERA DEL SOFTWARE
OMADV (definir, medir, analizar, disear y verificar) 786

OPR (diseo para la reutilizacin) 891
ORA (desarrollo rpido de aplicaciones) 53
OSOA (desarrollo de software orientado a aspectos) 65
OU (cadena definicin-uso) 431
EAT (estructura de anlisis del trabajo) 737
EC (especificacin de control) 215
ECS (elementos de configuracin del software) 800
EDI (entornos de desarrollo integrado) 413
EE (entradas externas) 474
EEO (eficacia en la eliminacin de defectos) 677
EIE (especificaciones incompletas o errneas) 784
EIS {entorno de ingenieria del software) 696
ELD (error de la lgica del diseo) 784
EP (especificacin de proceso) 217
EPI (equipos de producto integrado) 40
ER (exposicin al riesgo) 757
ERO (errores de la representacin de los datos) 784
FA (factor de acoplamiento) 487
FCM (falta de cohesin en mtodos) 485
FCP (funcin de control perifrica) 701
FON (formas de navegacin) 591
FIN (dependencia hacia dentro) 495
FIUC (facilidades de interfaz del usuario y control) 701
FPGC (facilidades de presentacin grfica de computadora) 701
GBO (gestin de bases de datos) 701
GCS (gestin de la configuracin del software) 796
GIP (grupo independjente de prueba) 386
GUls (interfaces grficas de usuario) 452
ICEO (ndice de calidad de la estructura de diseo) 480
ICI (interfaz de componente inconsistente) 784
ICOA (ingeniera de componentes orientada a aspectos)
953
OMADV (define, measure, analyze, design, and verify)

DFR (design for reuse)
RAD (rapid application development)
AOSO (aspect - oriented software development)
ou (definition-use chain)
WBS (work breakdown structure)
CSPEC (control specification)
sc1s (software configuration items)
IDEs (integrated development environment)
Els (externa! inputs)
ORE (deffect removal efficency)
IES (incomplete or erroneous specitication)
SEE (software engineering environment)
EOL (error in design logic)
PSPEC (process specification)
IPT (integrated product teams)
RE (risk exposure)
ERO (error in data representation)
CF (coupling factor)
LCOM (lack of cohesion in methods)
FCF (peripherat control function)
WoN (ways of navigating)
FIN (fan- in)
UICF (user interface and control facilites)
CGOF (computer graprucs display facilities)
DBM (database management)

SCM (software configuration management)
ITG (independent test group)
GUls (graphical user interfaces)
DSQI (design structure quality index)
ICI (inconsistent component interface)
AOCE (aspect-orienled component engineering)
65
meo (indice de desempeo del costo)
744
IHC (interfaz hombre-computadora ambigua o inconsistente) 784
IMCM (integracin del modelo de capacidad de madurez) 29
IMS (ndice de madurez del software) 496
IPA (interfaz de programacin de la aplicacin) 887
IPN (ingeniera de procesos de negocios) 140
IR (ingeniera de requisitos) 157
ISBC (ingeniera del software basada en componentes) 879
ISO (organizacin internacional de estandarizacin) 38
ro (interfaz con et usuario) 264
KLOC (miles de lneas de cdigo) 669
LOA (lenguaje de descripcin arquitectnica) 296
LOP (lenguaje de diseo de programas) 217
MA (modelado gil) 97
MACA (mtodo de anlisis de compensacin para la
arquitectura) 294
MAD (mdulos de anlisis de diseo) 701
MCC (mala interpretacin de la comunicacin del cliente) 784
MDHOO (mtodo de diseo hipermedia orientado a
objetos) 595
CPI (cost performance index)

HCI (human-computer interaction)
CMMI (capability maturity model integration)
SMI (software matur ity index)
API (application programming interface)
BPE (business processes engineering)
RE (requirements engineering)
CBSE (component based software engineering)
ISO (intemational organization for standardization)
UI (user interface)
Kl.OC (thousands lines of code)
ADLs (architectural description tanguages)
P OL (program design language)
AM (agile modeling)
ATAM (architecture trade-off analisis method)
OAM (design analysis modules)
MCC (misinterpretation of customer communication)
OOHDM (object-oriented rupermeilia design method)
954
NDICE DE SIGLAS MS COMUNES EN INGENIERfA DEL SOFTWARE
MDSD (mtodo de desarrollo de sistemas dinmicos) 91
DSDM (dynamic systems development methodJ
ME (metas especficas) 31
MEIEMP (mtodo de evaluacin de la IMCM estndar
SG (specific goals)
para el mejoramiento del proceso) 37

MEPS (mejora estadistica del proceso de software) 667
MFH (mtodo del factor de herencia) 487
MG (metas genricas) 32
MIS (miscelneo) 784
MMCGP (modelo de madurez de la capacidad de gestin
de personal) 641
MPC (mtodos ponderados por clase) 484
MRC (mtodo de ruta crtica) 736
MVC (modelo-vista-controlador) 589
NCR (nmero de clases raz) 495
NCSC (nuevos componentes de software comerciales)
63
NDD (nmero de descendientes) 485
NOA (nmero de operaciones aadidas) 488
NPO (nuevos puntos objeto) 711
NPOprom (nmero promedio de parmetros de la operacin) 492
OCI (orden de cambio de la ingenieria) 810
OCL (lenguaje de restriccin de objeto) 332
OMG (grupo de gestin de objetos) 889
OPM (objetivo/pregunta/mtrica) 470
ORB (distribuidor de objetos) 889
PAC (principio abierto-cerrado) 322
PCC (principio del cierre comn) 325
PCR (principio comn de la reutilizacin) 325
PDL (lenguaje de diseo de programas) 343
PE \Prcticas especlficas
31
PER (principio de equivalencia entre reutilizacin y ver-
sin) 325
PERI' (tcnica de evaluacin y revisin de programa)
SCAMPI (standard CMMI assessment method for process

improvement)
SSPI (statistical software process improvement)
MIF (rnethod inheritance factor)
GG (generic goals)
MIS (miscellaneous)
PM-CMM (people management capability maturity
model)
WMC (weighted methods per class)
CPM (critica! path method)
MVC (model-view-controller)
NOR (number of root classes)
NCSC (commercial off-the- self (COTS) software component)
NOC (number of children)
NOA (number of operations added by a subclass)
NOO (number of operations overridden by subclass)
NPavg (average number ofparameters per operation)
ECO (engineering change order)
OCL (object constraint language)
OMG (object management group)
GQM (goal/question/metric)
ORB (object request broker)

OCP (open closed principie)
CCP (common closure principie)
CRP (common reuse principie)
PDL (program design language)

SP (specific practices)
REP (release reuse equivalency principie)
PERI (program evaluation and review technique)
736
PF (punto de funcin)
474
FP (function points)
PG (prcticas genricas) 32
GP (generic practices)
PID (principio de inversin de la dependencia) 324

PI.E (prueba incompleta o errnea) 784
PNR (curva Putnarn-Norden-Rayleigh) 730
POA (programacin orientada a aspectos) 65
PSE (proceso de software en equipo) 40
PSI (principio de segregacin de la interfaz) 324
PSL (principio de sustitucin de Llskov) 324
PSP (proceso de software personal) 39
PU (proceso unificado) 67
PYP (porcentaje pblico y protegido) 495
QFD (despliegue de la funcin de calidad) 171
RPC (respuesta para una clase) 485
RSGR (reduccin, supervisin y gestin del riesgo) 76 l
RTF (revisin tcnica formal) 774
seer (sistema de clasificacin de cinta transportadora)
145
SE (salidas externas) 474
SEi (instituto de ingeniera del software) 29
SQA ,garanta de la calidad del software) 767
SQL (lenguaje de consultas estructurado) 614
DIP (dependency inversion principie)
IET (incomplete or erroneous testing)

PNR (Putnam-Norden-Rayleigh curve)
AOP (aspect-oriented programming)
TSP (team software process)
ISP (interface segregation principie)
LSP (Liskov substitution principie)
PSP (personal software process)
UP (unified process)
PAP (percent public protected)
QFD (quality function deployment)
RFC (response for a class)
RMMM (risk mitigation, monitoring and management)
CLSS (conveyor line sorting system)
EOs (eos (externa! outputs)
SEi (software engineering institute)
SQA (software quality assurance)

SQL (structured query language)
INDICE DE SIGLAS MS COMUNES EN INGENIERA DEL SOFl'WARE
SVC (sistema de versiones concurrentes) 809

488
TI (tecnologla de la informacin) 278
TLP (error de la traduccin del diseo al lenguaje de programacin) 784
TMC (tiempo medio de cambio) 677
TMDF y TMDR (tiempo medio de falla y tiempo medio
de reparacin) 787
1MEF (tiempo medio entre fallas) 787,874
TMR (tiempo medio de reparacin) 407
T O prom (tamao promedio de operacin) 491
UML (lenguaje de modelado unificado) 68
USN (unidad semntica de navegacin) 591
VAD (visin abstracta de datos) 597
ve (varianza del costo) 744
VEP (violacin de los estndares de programacin) 784
VyV (verificacin y validacin) 384
TC (tamao de la clase)
955
CVS (concurrent versions system)
es (class size)
rr (information technologies)
PLT (error programming language translation)
, MTIC (mean-time-to-change)
MTTC & MTTF (mean-time-to-charge) and (meantime-to-failure)
MTBF (mean time between failures)
MTTR (mean time to repair)
0S.v8 (average operation size)
UML (unified modeling language)
NSU (navigation semantic unit)
ADV (abstract data view)
CV (cost variance)
VPS (violation of programming standards)
V & V (verification and validation)
Siglas ingls/ espaol

Trmino en ingls
Trmino equivalente en espaol
3DGA (three-dimensional geometric analysis)

2 DGA (two-dimensional geometric anaiysis)
ACD (architecture context diagram)
ACWP (actual cost of work performer)
ADLs (architectural description languages)
ADP (abstract desing paradigm)
ADV (abstracl data view)
AM (agile modeling)
AOCE (aspect-oriented component engineering)
AG3D (anlisis geomtrico tridimensional) 701

AG2D (anlisis geomtrico bidimensional) 701
DCA (diseo de contexto arquitectnico) 288
CRTR (costo real del trabajo realizado) 743
LOA (lenguaje de descripcin arquitectnica) 296
ADP (paradigma de diseo abstracto) 883
VAD (visin abstracta de datos) 597
MA (modelado gil) 97
ICOA (ingeniera de componentes orientada
a aspectos) 65
POA (programacin orientada a aspectos) 65
DSOA (desarrollo de software orientado a aspectos) 65
IPA (interfaz de programacin de la aplicacin) 887
DAS (desarrollo adaptativo de software) 89
MACA (mtodo de anlisis de compensacin para la
arquitectura) 294
CPTR (costo presupuestado del trabajo realizado) 743
CPTC (costo presupuestado para el trabajo calendarizado) 743
IPN (ingeniera de procesos de negocios) 140
AVL (anlisis de valores lmite) 437
CAD (diseo asistido por computadora) 700
D B C (desarrollo basado en componentes) 63, 886
AECO (acoplamiento entre clases de objetos) 485
ISBC (ingeniera del software basada
en componentes) 879
ACC (autoridad del control del cambio) 81 O
PCC (principio del cierre comn) 325
FA (factor de acoplamiento) 487
FPGC (facilidades de presentacin grfica
de computadora) 701
AOP (aspect-oriented programming)

AOSD (aspect-oriented software development)
API (application programming interface)
ASD (adaptative software development)
ATAM (architecture trade-off analisis method)
BCWP (budgeted cost of work performed)
BCWS (budgeted cost of work scheduled)
BPE (business processes engineering)

BVA (boundary value analysis)
CAD (computer aided design)
CBD (component based development)
CBO (coupling between object classes)
CBSE (component based software engineering)
CCA (change control authority)
CCP (common closure principie)
CF (coupling factor)
CGDF (computer graphics display facilities)
956
INDICE DE SIGLAS MS COMUNES BN INGENIERA DEL SOFTWARE
COTS (comercial off-the-shell)

CLSS (conveyor line sorting system)
CMM (based appraisal for internal procces improvement
CBAIPI)
CMMI rcapability maturity model integration)
COCOMO (constructive cost model)

COM (component object model)
CORBA (common object request broker architecture)
CPI (cost performance index)
CPM (critica) path method)
CRP (common reuse principie)
es (class size)
CSPEC (control specification)
CTC (condition - transition - consequence)
CV (cost variance)
cvs (concurren! versions system)
DAM (design analysis modules)
DBM (database management)
DBMS (database manager system)
DFD (data flow diagram)
DFR (design for reuse)
DIP (dependency inversin principie)
DIT (depth of the inheritance tree)
DMADV (define, measure, analyze, design, and verify)
DRE (deffect removal efficiency)
D5DM (dynamic systems development method)

DSQJ (design structure quality index)
ou (definition-use chain)
ico (engineertng change orcter)

EDL (error in design logic)
Els (externa! inputs)
EIFs (externa! interface files)

EOs (externa! outputs)
EQs (externa\ inquines)
ERD (error in data representation)
EVA (earned value analysis)
FDD (feature driven development)
FIN (fan-in)
FP (function pointsJ
GG (generic goals)
GQM (goal/question/metric)
GP (generic practices)
GUJs (graphical user interfaces)
HCI (human-computer interaction)
ICI (inconsistent component interface)
IDEs (integrated development environments)
lDS (intentional deviation from specifications)
IES 'mcomplete or erroneous specification)
lET tincomplete or erroneous tesling)
CDL (componentes comerciales de linea) 695

SCCT (sistema de clasificacin de cinta
transportadora) 145
ABC MPI (apreciacin basada en el cmm para el
mejoramiento del proceso interno) 37
IMCM (integracin del modelo de capacidad de
madurez) 29
COCOMO (modelo constructivo de costos) 71 o
COM (modelo de objetos para componentes) 889
CORBA (arquitectura comn de distribucin de
objetos) 889
IDCo (indice de desempeo del costo) 744
MRC (mtodo de ruta crtica) 736
PCR (principio comn de la reutilizacin) 325
TC (tamao de la clase) 488
EC (especificacin de control) 215
CTC (condicin-transicin-consecuencia) 759
ve (varianza del costo) 744
svc (sistema de versiones concurrentes) 809
MAD (mdulos de anlisis de diseo) 701
GBD (gestin de bases de datos) 701
DBMS (gestor de bases de datos) 614
DFD (diagrama de flujo de datos) 21 1, 298
DPR (diseo para la reutilizacin) 891
PID (principio de inversin de la dependencia) 324
APH (rbol de profundidad de la herencia) 484
DMADV (definir, medir, analizar, disear
y verificar) 786
EED (eficacia en la eliminacin de defectos) 677
MDSD (mtodo de desarrollo de sistemas
dinmicos) 91
ICED (indice de calidad de la estructura de diseo) 480
DU (cadena definicin-uso) 431
OCI (orden de cambio de la ingeniera) 810
ELD (error de la lgica del diseo) 784
EE (entradas externas) 474
AJE (archivos de interfaz externos) 475
SE (salidas externas) 474
CE (consultas externas) 474
ERD (errores de la representacin de los datos) 784
AVG (anlisis del valor ganado) 742
DCC (desarrollo conducido por caractersticas) 95
FIN (dependencia hacia dentro) 495
PF (punto de funcin) 474, 670
CRC (clase-responsabilidad-colaborador) 225
RTF (revisin tcnica formal) 774
MG (metas genricas) 32
OPM (objetivo/pregunta/mtrica) 470
PG (prcticas genricas) 32
GUls (interfaces grficas de usuario) 452
IHC (interfaz hombre-computadora ambigua o
inconsistente) 784
ICI (interfaz de componente inconsistente) 784
EDI (entornos de desarrollo integrado) 413
DIE (desviacin intencional de las especificaciones) 784
EJE (especificaciones incompletas o errneas) 784
PIE (prueba incompleta o errnea) 784
NDICE DE SIGLAS MS COIIVNIS EN JNGilNIIZA DEL SOFTWAJII
UD (inaccurate or 1mcomplete documentation1

ILFS (interna! logical files)
IPT (integrated product teams)
ISO (intemational organization for standardization)
ISP (interface segregation principie)

1T (information technologies)
ITG (independent test group)
KDD (knowledge discovery in databases)
KLOC (thousands lines of code)
LCOM (lack of cohesion in methods)
lSP (Liskov substitution principie)
MCC (misinterpretation of customer communication)
MIF (method inheritance factor)

MIS (miscellaneous)
MTBF (mean time between failures)
MTTC & MTl'F (mean-time-to-charge) and (mean-time-
to-failure)
MTTC (mean-time to-change)
MITR (mean time to repa1r)
MVC (model-view-controller)
NC (numerical control)
NCSC (commerc1al off-the-self (COTS) software
component)
NOA (number of operations added by a subclass)
NOC (number of children)
NOO (number of operations overrdden by subclass)
NOR (number of root classes)
NPvi (average number of paramelers per operation)
NSU (navigation semantic umt)
oc (operalion complexity)
OCL (object constraint language)
OCP (open closed principie)
OMG (Object management group)
OODA (object-oriented domain analys1s)
OOHDM (object--0riented hipermedia design method)
ORB,(object request broker)

os.~ (average operation size)
PAD (public access to data members)
PAP (percent public and protected)
PCF (peripheral control function)
PDL (program design language)
PERT (program evaluation and review techn1que)
PLT (error programming language translation)
PM-CMM (peOple management capabihty maturity model)
PNR (Putnam -Norden-Rayleigh curve)

PSP (personal software process)
PSPEC (process specification)
QFD (quality function deployment)
RAD (rapid application development)
RE (requirements engineering)
RE (risk exposure)
957
DIJ (documentacin imprecisa o incompleta) 184

ALI (archivos lgicos internos) 474
EPI (equipos de producto integrado) 40
ISO (organizacin internacional
de estandarizacin) 38
PSI (principio de segregacin de la interfaz) 324
TI (tecnologa de la informacin) 278
GIP (grupo independiente de prueba) 386
DCBD (descubrimiento de conoc1m1ento en base de
datos) 278
KLDC (miles de lneas de cdigo) 669
FCM (falta de cohesin en mtodo:;) 485
PSL (principio de sustitucin de Liskov) 324
MCC (mala interpretacin de la comunicacin
del cliente) 784
MFH (mtodo del factor de herencia) 487
MIS (miscelneo) 784
TM.E F (tiempo medio entre fallas) 787
TMDF y TMDR (tiempo medio de falla y tiempo medio
de reparacin) 787
TMC (tiempo medio de cambio) 677
TMR (tiempo medio de reparacin) 407
MVC (modelo-vista-controlador) 589
CN (contador numrico) 696
NCSC (nuevos componentes de software
comerciales) 63
NOA (nmero de operaciones aadidas) 488
NDD (nmero de descendientes) 485
NPO (nuevos puntos objeto) 71 1
NCR (nmero de clases ralz) 495
NPOprom (nmero promedio de parmetros de la
operacin) 492
USN (unidad semntica de navegacin) 591
co (complejidad de la operacin) 491
OCL (lenguaje de restriccin de objeto) 332
PAC (principio abierto-cerrado) 322
OMG (grupo de gestin de objetos) 889
AOO (anlisis orientado a objetos) 20 t
MDHOO (mtodo de diseo hipermedia orientado a
objetos) 595
ORB (distribuidor de objetos) 889
TOpt'Om (tamao promedio de operacin) 491
APD (acceso pblico a datos) 495
PYP (porcentae pblico y protegido) 495
FCP (funcin de control perifrica) 701
lDP (lenguaje de diseo de programas) 217
PERT (tcnica de evaluacin y revisin de programa) 736
TLP (error de la traduccin del diseo al lenguae
de programacin) 784
MMCGP (modelo de madurez de la capacidad de gestin
de personal) 641
PNR (curva Putnam-Norden-Rayleigh) 730
PSP (proceso de software personal) 39
EP (especificacin de proceso) 217
QFD (despliegue de la funcin de calidad) 171
ORA (desarrollo rpido de aplicaciones) 53
IR (ingenieria de requisitos) 157
ER (exposicin al riesgo) 757
958
fNt>ICE DE SIGLAS MS COMUNES EN INGENIERfA DEL SOFTWARE
REP (release reuse equivalency principie)
PER (principio de equivalencia entre reutilizacin
RFC (response for a class)
RPC (respuesta para una clase)
y versin)
RMMM (risk mitigation, monitoring, and management)

RNA (relationship-navegation-analisys)
SCAMPI (standard CMMI assessment method for
process improvement)
SCD (system context diagram)
SCis (software configuration items)
SCM (software configuralion management)
SG (specific goals)
SEE (software engineering environment)
SEi (software engineering institute)
SFD (system flow diagram)
SMI (software maturity index)
SQA (software quality assurance)
SQL (structured query language)
SP (specific practices)
SSPI (statislical software process improvement)
TSP (team software process)
UI (user interface)
UICE (user interface and control facilities)
UML (unified modeling language)
UP (unified process)
V&V (verification and validation)
VPS (violation of programming standards)
WBS (work breakdown structure)
WMC (weighted methods per class)
WoN (ways of navegating)
325
485
RSGR (reduccin, supervisin y gestin del riesgo) 761
ARN (anlisis relacin-navegacin) 560
MEIEMP (mtodo de evaluacin de la IMCM estndar
para el mejoramiento del proceso) 37
DCS (diagrama de contexto del sistema) 145
ECS (elementos de configuracin del software) 800
GCS (gestin de la configuracin del software) 796
ME (metas especificas) 31
EIS (entorno de ingeniera del software) 696
SEi (instituto de ingeniera del software) 29
DFS (diagrama de flujo del sistema) 146
IMS (ndice de madurez del software) 496
SQA (garanta de la calidad del software) 767
SQL (lenguaje de consultas estructurado) 614
PE (prcticas especficas) 31
MEPS (mejora estadstica del proceso de software) 667
PSE (proceso de software en equipo) 40
IU (interfaz con el usuario) 264
FIUC (facilidades de interfaz del usuario y control) 701
UML (lenguaje de modelado unificado) 68
PU (proceso unificado) 67
vyv (verificacin y validacin) 384
VEP (violacin de los estndares de programacin) 784
EAT (estructura de anlisis del trabajo) 737
MPC (mtodos ponderados por clase) 484
FdN (formas de navegacin) 591
Los 32 captulos de lo sexto edicin se han organizado en cinco partes:
Parte l . El proceso del software, presenta diferentes perspectivas del proceso

del software y considera todos los modelos de proceso importantes; adems,
aborda el debate entre las filosofas del proceso prescriptivo y del proceso gil.
Parte 2. Prctica de la ingeniera del software, presenta mtodos de anlisis,
diseo y prueba con especial inters en las tcnicas orientadas a objetos y el
modelado UML.
Parte 3 . Aplicacin de la ingeniera Web, presenta un enfoque completo de
ingeniera para el anlisis, diseo y prueba de aplicaciones Web.
Parte 4. Gestin de proyectos de software, presenta temas relevantes para
quienes planean, gestionan y controlan un proyecto de software .
Parte 5. Temas avanzados en ingeniera del software, presenta captulos que
abordan mtodos formales, ingeniera del software de sala limpia, ingeniera
de software basada en componentes, reingeniera y tendencias futuras.
Adems de muchos captulos nuevos y significativamente revisados, la sexta

edicin incluye aproximadamente 120 recuadros que:
Permiten al lector seguir a un equipo de proyecto (ficticio) conforme planifica
y disea un sistema basado en computadora.
Proporciona estudios complementarios de temas selectos.
Subraya los "conjuntos de tareas" que describen el flujo de trabajo para
actividades selectas de ingeniera del software.
Sugiere herramientas automatizadas de inters para los temas de los captulos.
McGraw-HIII
lnteramerlcana
The McGrowHi/1 Compames
ISBN 970 - 10-5473-3
11111 11 111 1
9 789701 054 734
Visite nuestra pgina WEB

www.mcgraw-hill-educacion.com

Ingenieria Del Software - Roger Pressman 6th

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 Pressman 6th

Caricato da

Copyright:

Formati disponibili

/

El proceso del software 21

El proceso: una visin general

Modelos prescriptivos de proceso

Prctica de la ingeniera del software

La prctica: una visin genrica

Modelado del anlisis

Ingeniera del diseo

Diseo al nivel de componentes

Diseo de la interfaz de usuario

Estrategias de prueba del software

Tcnicas de prueba del software

Mtricas del producto poro el software

Aplicacin de la ingeniera Web 501

Software e ingeniera del software

Formulacin y planeacin poro ingeniera Web

Modelado de anlisis poro aplicaciones Web

Modelado de diseo para aplicaciones Web

Cmo probar aplicaciones Web

Gestin de proyectos de software 639

Conceptos de gestin de proyectos

Mtricas de proceso y proyecto

Estimacin poro proyectos de software

Calendarizacin de proyectos de software

Gestin del riesgo

Gestin del cambio

Temas avanzados en ingeniera del software 829

Ingeniera del software de sala limpia

Ingeniera del software basada en componentes

El camino por recorrer

SOFTWARE E INGENIERA DEL SOFTWARE

El papel evolutivo del software

La naturaleza cambiante del software

Calidad del software heredado

Evolucin del software

Mitos del software

Cmo inicia todo

Problemas y puntos a considerar

Otras lecturas y fuentes de informacin

EL PROCESO DEL SOFTWARE

EL PROCESO: UNA VISIN GENERAL

Ingeniera del software: una tecnologa estratificada

Marco de trabajo para el proceso

Integracin del modelo de capacidad de madurez (IMCM)

Patrones del proceso

Evaluacin del proceso

Modelos de proceso personales y en equipo

Proceso de software personal (PSP)

Procesos de software en equipo (PSE)

Tecnologa del proceso

Problemas y puntos a considerar

Otras lecturas y fuentes de informacin

MODELOS PRESCRIPTIVOS DE PROCESO 48

Modelos de proceso incrementales

El modelo de desarrollo concurrente

Un comentario fino! sobre los procesos evolutivos

Modelos especializados de proceso 63

Desarrollo bosodo en componentes

El modelo de mtodos formoles

Desarrollo del sohwore orientado o aspectos 65

Uno breve historio

Foses del proceso unificado 68

Modelos de proceso evolutivos