.

Un enfoque practico

CAPlTuLO 1

Software e ingenierio del software

PARTE UNO

EI proceso del software 21

CAPlTuLO 2 CAPlTuLO 3 CAPlTuLO 4
EI proceso: una vision general 22 48

Modelos prescriptivos de proceso Desarrollo agil 77

PARTE DOS

Practica de la ingenieria del software

CAPlTuLO 5 CAPITuLO 6 CAPlTuLO 7 CAPlTuLO 8 CAPlTuLO 9 CAPlTuLO 10 CAPlTuLO 11 CAPlTuLO 12 CAPlTuLO 13 CAPlTuLO 14 CAPlTuLO 15

103
104

La practica: una vision generica Ingenierio de sistemas Ingenieria de requisitos Modelodo del analisis Ingenieria del diseno Diseiio arquitectonico Diseiio 133 155 191 245 275

01

nivel de componentes

315 350 382 418 462

Diseiio de

10

interfaz de usuario

Estrategias de prueba del software Tecnicas de prueba del software

Metricas del producto pora el software

PARTE TRES

Aplicacion de la ingenieria Web 501

CAPlTuLO 16 CAPlTuLO 17 CAPlTuLO 18 CAPlTuLO 19 CAPlTuLO 20
Ingenieria Web 502 517 544 566

Formulacion y planeacion pora ingenieria Web Modelado de anal isis pora aplicaciones Web Modelado de diseiio pora aplicaciones Web Como probar aplicaciones Web 604

~ CUATRO

Gestion de proyectos de software 639

CAPlTuLO 21 CAPlTuLO 22 CAPlTuLO 23 CAPlTuLO 24 CAPlTuLO 25 CAPlTuLO 26 CAPlTuLO 27
Conceptos de gestion de proyectos Metricas de proceso y proyecto 640

663 690 724

Estimacion pora proyectos de software

Calendarizacion de proyectos de software Gestion del riesgo Gestion de

747 767 796 vii

10

calidad

Gestion del cambio

vill

CONTENIDO BREVE
Temas avanzados en ingenieria del software 829
CAPITuLO 28 CAPITULO 29 CAPITuLO 30 CAPITuLO 31 CAPITuLO 32
Metodos formales 830 858 879

PARTE CINCO

Ingenieria del software de sola limpia

Ingenieria del software basada en componentes Reingenieria 902 927

EI camino por recorrer

Pre/acio xxviii Recorrido xxxi

CAPiTuLo 1
1. 1 1.2 1.3 1.4

SOFTWARE E INGENIERlA DEL SOFTWARE

2 8 12 5 11 12

EI papel evolutivo del software Software

La naturaleza cambiante del software Software heredado 1.4 . 1 1.4 .2

Calidad del software heredado Evoluci6n del software 14 17

1.5 1.6 1.7

Mitos del software C6mo inicia todo Resumen 18 18

Referencias

Problemas y puntos a considerar

19 20

Otras lecturas y fuentes de informaci6n

PARTE UNO:

EL PROCESO DEL SOFTWARE CAPiTuLO 2

2. 1 2.2 2.3 2.4 2 .5 2 .6

21 22

EL PROCESO: UNA VISION GENERAL

23

Ingenieria del software: una tecnologia estratificada Marco de trabajo para el proceso Patrones del proceso Evaluaci6n del proceso 2 .6 . 1 2.6 .2 34 36 38 39 24

Integraci6n del modelo de capacidad de madurez (IMCM)

29

Modelos de proceso personales y en equipo Proceso de software personal (PSP)

Procesos de software en equipo (PSE) 42 43

40

2.7 2 .8 2 .9

Tecnologia del proceso Producto y proceso Resumen 45 44

Referencias

Problemas y puntos a considerar

46 47

Otras lecturas y fuentes de informaci6n

CAPiTuLO 3
3 .1 3.2 3 .3

MODELOS PRESCRIPTIVOS DE PROCESO 48

49 50 51 52

Modelos prescriptivos EI modelo en cascada 3.3.1 3.3.2

Modelos de proceso incrementales EI modelo incremental EI modelo DRA 53

1x

CONTENIDO

3.4

f..r'lodeIos de proceso evoIutrvos 54 3.4 1 ConslrLICciOn de prolollpos 55 3 '" 2 EI modeIo en espuol 58 3..4 3 EI modeb de desarrollo concullenlt'! 60 344 Un comenlOrio final sobre bs pr!Xe$O$ Mutivos 61
~

3.5

3.6

e5peCKllizodos de ploceso 63 Desarrollo bosodo eo componenlel 63 35.2 EI modeIo de metodos formoies 64 3.5.3 Desarrollo del sohwore ollentodo 0 o~ 65 EI p'ClCeSO uni~cado 67
3.5. I
3.6.1 3.6.2 Uoo breve historic 67 Foses del procer.o un ilicodo 68

36.3

ProcilJcto5 de (labolO del proceso umf>codo 71

3 .7

Resumen 72
0 conSlderO!

Referencias 73 Problemas y puntos

7.4
75

OlIOS lecturos y fueoles de InlofmociOn

CAPfruLo 4
.4 1

DESARROU.OAGIL

77

.4 2

aGue es 10 ogilidod? 79 aGue es un prOC85O 6gil?

.4 2, I

81

los poIilioos del de5mrollo 6gil 81

42.2
4.3
.4 3, I

Fodores humorlO$ 82
Progromoci6n exrremo Iff) 84
~

NIocIeIos 6grles de prOCE!$O 84

, 32
4 3.3

"''''''''''' ~ de """""" 10AS1 80 de desorrolo de SIstemas drn6miCoslMOSDI 91

4.34

4.3.5
.4 3.6

!Vela 92 Cristol 95 Desarrollo cooducido pot ccrocterisllCOS (OCC! 95

~

4 37
44 Resumen

6giliNoAI 97

99 10 1

Relerencios
Pr~emo$

I00
102
103

y pvnlos a conSldero!

OIfos lecturos y fuentes de mformoci6f1

PARTE DOS: mcnCA DE LA INGENIERiA DEL SOFTWARE

cAPITuLo 5
5 I

LA PRAC'I1CA: UNA VlSI6N GENtmCA 104

La pllxlico de b ingeniefia del ~re 105 5.11 loesenciodeloprootaJ 106 5.1 2 PrinoptOS e5etlCioles 107

52 53
54

Pr6d1COS de comurucoci60 109 Pr6dOCO$ de 10 pIoneociOn 1 13 Pr6chco del mcdeIodo 116

CONTENIOO
5.4.1 5.42 5.5 5.5.' 5.5 2 5.6 57
~iegue

XI

Princ,ptos

del modeIodo del on6!isi$ 117

119 123 122 124

Principi05demodelododeldi~

Pr6dico de 10 con5hua;i6n Pronciptos 126 128

Pr,nc,pios y concepb5 de codifiCoci6n

de los proebos

Resumen
129

Rel"erencias

Problemas y punlos 0 considerof O!Ios leclvros y

r 30 fuenle5 de infOfmociOo

I 31

cAPlnn.o.
6.1
6.2

INGENIERiA DE SISTEMAS 133

Sistemas baKldos en compvtoc:b-o 62.1 622

134

La ieforquio de 10 ingenierio de sistemas

I 36

NoodeIado del

sistema

137 139 140

SimulocK>f1 del sistema

6.3 6.4 6.5

Ingenieria de pfOce~ de r.egocoos uno vi$i6n generol Ingeniefla de prOOUCIa: uno visi6n generol 142 ModeIodo del si*mo 144

651 652 6.6 Resumen Rel"efenoos 152

ModeIocIo HotIeyf'irbhoi 144 tv\odeIodo del Slslerno con \JIv\L 147

151

Problemas Y punlos 0 comiderar

152 153

Otros
7.1 7 2

leduras y

fuenle5 de informoci6n

CAPfnn.o 7
Tareas

INGENIERiA DE REQUISITOS

155

Un puente hocia

eI dlsei\a Y Ia conSlrucci6n 156

157 158 158 159

de Ia

inge",eria de requiSl10s
I",cla

7.2.1 722

Ob4enci6n
Elaboroci6n
Negocklci6n

7 2.3
72.4 7.2.5 7.2.6

160 160 161

EspecificociOO

Vol;dociOn

73

7.27 Ges/i6n de requisitos 161 Inkio del prCoC:MO de Ia ingenieria de requisilos 7.3.1 7.32 7 33 7.34 IdentilkociOO de
Reconocimienlo

163
164

los inlerewclos 164 de mul~ples punlo.s de visla

164

Trobo;o con respedO a 10 coloboroci6n

7 4

Obtenci6n 74 1 742

7 <I 3

Formuloci6n de los pnmefas preguntos 165 de requisilos 166 Recopoloci6n conjunlo de requlsilOs 167 Despliegue de 10 funC16n de calodod 171 EsctJrIario$ del usuario 172

xU

CONnNlDO
744 Producbs de lIobolO de 10 OOtenci6n De50rrollo de 0000$ de lISO 173 173

75 76

Conslrucci6n del modeIo de an61,sis

179

77
78 79

Elementos del modele de oOOll$ls 179 183 NegoclOCi6n de requlsllo5 184 \IoI,daci6n de requisltos 186 76 1
7 6.2 Patrone! de 0001'51$
R:esomen

186

Refereocias

187

Problemas y puntos a consideror

I 88

OIfos lecturos y rueotes de informaciOn

189
191

cAPfnn.o
81

MODELADQ DEL ANAusIs

An6I,sis de requisites

192

82 83

Filosofia y obietivos generales 193 8.12 Regia! pr6cticos de orl6lisis 194 81.3 An6lisis de! domlt'lJo 194 Enloques de modeIodo del ooolisis 196
Conceplos dej modeIodo de doJos

811

197

84 85

R:eIociones 199 Cordl/lOl.dad y modolidod 199 An6I'sls aleIlIodo a obtetos 201 ModeIodo bosodo en escenorios 202 85 1 serillKa de cmos de U$O 202 Desonollo de un doogromo de octrvtdod 208 852

831 832 8.33 834

~dodok A/ribulos 198

197

85.3
86

fvI.odebdo Oflentxio 01
86_1 862 8.6.3 8.6.4

Doaglomosdeconil 209 Aup 21 t

87

CreociOO de un modeIo de Auto de dalO.t 211 Creoc!60 de un modelo de contrd del A(.I,o 2 14 bpecificoct6n de control 215 EspecificociOn de JXoce~ 217 !Y\:xIelodo basodo en closes 219

87 1
8.7 2

Identificoci6n

de doses de cooli!.! 219

222

Especificoci6n de olribulo5

87.3

Defmici6n de operociooes 223

88

8.7 4 NoocleIodo de Close-Repon50bllododCoIoborodolICRC) 225 B 7_5 AsocioOones y dependencicl5 232 876 Poqueles de on6I;$is 233 Cleoci6n de un modeIo de cOITlpo!"lomoenlo 234 88 J Idenlrococi6n de evenlQ5 con eI CO$O de 882 RepesenioclOOeS de e$IOdo 236 Resumen 239
U$O

235

89

CONTENIDO

x1JJ

ReferencKU

241

Pioblemas y punlO5 0 con.sode!ar 241 OtrO$ lecturo$ Y Iuen~ de IIllormoci6n 243

cAP!nn.o
91 92 93
Di~

INGENIERiADELDISENO 2<t5

dentro del cor1!exto de 10 ingenierio del sohwore 247 Proceso Ycol.dod del d,~ 249 ConcepIoS del diseiio 252 Q 31 Arulfacci6n 252 Q32 Arquitecturo 253 Q33 POlfooe$ 254 Q34 t..-'odulolldod 254 935 Oc:ulloci6n de inlormaci6n 256 IrodeperodeocKl ruocionol 256 Relil'lOmrento 257 Q38 Relobrkoci6n 258 Q3Q CIo$e$ de di$eoo 259 EI modeIo de di$eoo 262 941 Elernenlos del d,seno de dal~ 263
937 9.3.6

94

942 943
Q44
Q4 5 Q5

Di$eh:!
Q 5.1 Q 5.2

EIerner.Ios del diseno arquitecl6mco 264 Eiemenlos de diseno de intenoz 264 EIerner.Ie de diseno 01 nr..el de oomporrenle.s 266 E~ de d,seno 01 mYel del despliegoe 267 de sofrwore bo5Odo en polrOile$ 26Q Descripd6n de un pab6n de diselio 269 Ulilim<;i6n de poIrones en eI d,seno 270
Marcos de kObojo 270

QS3
Q

Resumen 271
272

ReferenciOs

Proble!TlI:u y put11e a corurderQ( 273 OliOS iec:kJros y fuentes de inlormaci6n 273

CAPinn.o 10 10 I DISENO ARQUlTECT6NICO 275 276

Arquitecturo del software

10.1 I

tOue 8$10 arquitoctura? 276

277

10 2

10.12 ePor q~ as importante 10 orquilecturo? Oiseno de dalos 278

10.2 1 10.2 2

Diserlo de dolo$ 01 nivel arquilecl6n,co 278 Di$800 de dole 01 nivel de comporrenles 219
280

103

Esrilos y porrone$ orquiledoolCO$

10 3.1 10 3 2

Uno br-eve klxonomio de 8$l,k orqu,tecl6nkO$ 281

10 4

Patrones orquited6fricos 284 1033 Orgonizoci6n y re/inam,enb 287 Di$8i\o orqu,l9d6nico 287
104 1 RepresenlOCi6n del ~i!>lerna en eI contexlo 288

...
10.4.2 10.4.3 10.4.4 10.5 Definici6n de orquetipo$ 289 Reiinomienb de 10 orquiledlJro en componenles 2QO Descripci6n de 10 creoci6n de insbocicu del slst&mO 292 294 EvoIuoci6n de diseiios CJI!lUiled6nicos ohefnos 294J 10.5. 1 Un rne.odo de on6lisi.s de comperuoci6n pora 10 orquitecturo 10.5.2 Complejidod orquiled6nico 296 lMiguoje5 de descripci6n orquiled6nico 296 10.5.3 10.6 eo.reloci6n del Rujo de doIos eo uno O/quitecluro del software 297 Flujo de lfoNlormaci6n 297 10.6. 1 Flujo de 1f0fUClCCi6n 298 10.6.2 Co.reloci6n de Irornbmociol'les 29Q 10.6.3 10.6.4 COI"reloci6n de IrofUClCCiOoes 306 10.6.5 Reiinomienlo del di$eoo Olquilecl6niCo 310 10.7 Re~umen 3 11 Reierencia5 312 Problemas y punlo5 0 CCln$idemr 312 OIro$ lecluro~ y ~ de inFormaci6n 313

cAJliTuLo 11 olSDio AL NIVEL DE COMPONINTES 11. 1 aGue es un componenIe? 316

1 1. 1. 1 11. 1. 2 11 . 1.3 11.2

315

Concepto orienlado 0 objeIo$ 317 EI concepIO corr.oerw;iOnoI 318 t.kI concepo reIocionodo con eI prOC8$O 321

Diseno de componeNe$ ~ en doses 322 11 .2. 1 Pfinciplo$b6sioosdediseiio 322 11 .2.2 Uneos de diseiio 01 niilel de c:ornponentM 325

gener.

11 .3 11.4 11 .5

11.2.3 Cohesi6n 327 11 .2.4 Ac.opIomienlo 329 Conducci6n del di$eno 01 nWel de componenle! 331 lMiguoie de re~tricci6n de objeto.s 337 Diw.a de Componen le5 convencKxlo~ 340 11 .5. 1 NoIoci6n gf6fiw del diseiio 340 11.5.2 NoIoci6n tabular del di$eoo 342

lenguoje de di~ de progromos 343 11.5.3 11 .5.,d Comporoci6n entre noIocior.es de diw.a 345 11 .6 Rewmen 346 Referenck 347

P,obIemas y ~ 0 cons\deror 347 Otros 1edur0$ y fuenle! de inlOl"maci6n 348

CAPiTuLo 12
12. 1

DISIHo DE LA INTERFAZ DE USUAltlO

350

Los regIos de 01"0 351 12. I. I Dar eI oonIrol 01 u!oUQrio 351 12. 1.2 12. 1.3
Reducir

10 corgo en 10 memoria dellI5IIOrio 353

Lagror que 10 in/erfoz sea consislerne 354

12.2

An6lisis y diseiio de 10 interfoz de usuoriO 356 12.2.1 12.2.2 An6lisisde 12.3.1 12.3.2

NIodeIo5 del an6lisi~ y diseno de 10 inllH/oz 356 EI pr<Xe$O 358 12.3 10 interfoz 359 An6IiSi$ delusuoriO 360 An6lisi$ Y modeIodo de brew 361 12.3.3 An6!isls del conlooido de 10 poo!OIIo 367 12.3.4 An6lisis del enbno de rrobojo 367 12.4 Poses del diseiio de 10 in!OOoz 368 12.4.1 Aplicoci6n de los pa$O$ del disei\o de 10 interfoz 369 12.4.2 PoIrone$ de diseno de 10 ifllerfoz de lJ$IJOriO 371 12.4.3 Temos de dileOo 372 12.5 EvokHXi6n del dir.eilo 377 12.6 R&$Uf\'!ef1 378 Relerer.cios 379 Problemas y punic a consideror 380 OIros Iecluros'y fuenles de inlanTloci6n 380

CAPiTuLo 13
13.1

ES'I'RAI'EGlAS DE JIRUEIlA Dm.. SOrrw'ARB 312

Un enloque molegico polo 10 prvebo del ~re 383 13.1.1 V8rificoci6n y volidoci6n 384

13.2 13.3

Organizoci6n para 1m pruel:x del ~Ut 385 hholegio de pruebo para orqlJiteduras convencionole5 del software 386 Eshotegio de pruebo del ~re pore CMqlJileClUfO:s OfientodoSa objeIru 388 13 . 1.5 Crilerios para compIetor 10 pruebo 389 Aspectos malllgicos 3Q() 13.1.2 13.1.3 13.1.4
EsIraIogku de pruebo para eI sclrwl".ue COflY8OCionOI 391 13.3.1 Pruebo de unidad 392

13.4

13.3.2 Pruebo de integroci6n 394 E$lrategios de pnoebo para .~re Ofieotodo a ~ 402 13.4.1 Pruebo de unidod en eI contelOo OI'ienIodo a objebs 402 13.4.2 Prueba de inlegroci6n en ~ COI"Itex\o a;en\odo a objelc 403 Prvebos de volidoci6n .404 13.5.1 CrilefiOs de 10 pwebo de'lOlidoci6n 404 13.5.2 Revisi6n de 10 conliguroci6n 405 13.5.3 Pruebos 01/0 y bera 405 Pruebo del sislemo 406 13.6.1 Pruebo de recuperoci6n 407 13.6.2 Prvebo de ~uridod 407 13.6.3 Pruebo de rft5islencio 408 13.6.4 Pruebo de desempeIlo 408 Bate d.1o depurod6n 409 13.7. 1 E1 procMO de depu.oci6n 4 10 13.7.2 Considerociones psicol6gicCl$ 4 11

13.5

13.6

13.7

CONTENIDO
13.7.3 13.7.4 13.8
EstrolegiO$

de depuroci6n
414

4 12

Conecci6n del enOl

Resumen 415
4 16

R:elerend os

ProbIemos y punlo$ 0 considerOt" 4 16 Otros leduros y fuentes de inbmoci60 4 17

CAPiTuLO ,.
14. 1 14.2 14.3 14.4

Tf:cNICAS DE PRUEIA DEL SOfTWARE

418

Fundomentos de 10.0; prueOOs del software 4 19 Pruebos de cojo negro y c:ojo blanco 422

Pruebos de cojo blanco 423 Proebo de 10 rula b6sicO 423 14.4.1 Notoci6n de gr6fk:o de Aujo 423 14.4.2 Rum independientes del progroma 425 14.4.3 Derivoc:i6n de C:050S de p'uebo 4 27
14,4.4

M.alfic:es de graficos 430

14.5

Pruebos de 10 estrvcturo de control 430 14.5,1 Pruebo de c:ondicioo 431

14.5 .2 14 .5.3 PruebodelRujodedolo6 431

14.6

Pruebo de budes 432 Pn)8bo de COjO negro 413 14.6.1 o'vIModo5 9f~ de pruebo 434 14 .6.2 Portici6nequNolenIe 436 14,6.3 Ao6Mis de wIores limile 437
14.6.4 Pruebo de 101*1 0110901101 438 NetocIos de pruebos aieniados 0 objeIos 44 I 14,7.1 Irnplioxiones del COflCeF*:I orienIado a objeb en eI c:IiMII'Io de CXl$OII de pruebo 442 14.7.2 Aplicobilidod de rnkldos CXIIlY8I'ICionoles de diseflo de cosos de pruebo 442 Proebo bosado en!ollos 443 14.7.3 CoSO$ de pruebo y jerorquio de dO$8 444 14.7,4 14.7,5 14.7.6 EstruclurO$

14 7

Pruebo ba.sodo en escenorios 444 de wp8ff;cie y de fondo en pfUebos 446

14.8

de prveb:l oplic:obles 01 nivel de c:bse 447

Pruebo oleolorkl poro do5es OIienloOos 0 objelo6 447 Proebo de porliCi6n 01 ni.-el de dose 448 14.9 Diw.o de coso de prvebo de inlerdo.5e 449 14.9.1 Pruebo de d05es mU~iples 449 14.9.2 Pruebos defivodos de I'IIOdeb de comporlOmienlO 4 51 14.10 ?ueba de enlornos ~kllizodc.a: OlquitedurO$ y oplicoc:iones 452
14.8.1 14 .8.2 14. 10. 1 14. 10.2 14. 10.3 14 . 10.4 14. 11 PotrOt'lM
~

de inlerloces gr6Iicos de UWOfio 452

Pruebodaorquiledurosdienle/-w:h 452

Pruebo de 10 documenllXi6n y las Iunci0ne5 de oyudo 454

Pruebodemlemosdetiemporeol 455

de pruebo 456

14. 12 Re$l,lmen 457

R-nciO$ 459

Problemas Y punlo$ 0 c.onsideror 459 Otros leclufus y fuentes de inlormoci6n 460

c.ufnn.o 15
15. 1

Jr.drmcAS DEL PIlODUCTO PARA EL SOI'TWARE

462

CoIidod general 463 15. 1.1 Foc:a:Jres de colidod de fvIcCon 464 15. 1.2 Foc:a:Jres de co~d:xl del esl6ndor ISO 9 126 465 15. 1.3 lo b"0Nici6n 0 un concepto OJOIlIik:rtiYo 466 15.2 Un marco conceplUOl poto las m8trico$ del pl"oduclo 467 15.2. 1 Nledidc, mblricos e irodicodaes 467 '15.2.2' EI reb de \0$ metricos del pmduc!o 468 15.2.3 Prir.cipial de medici6n 469 15. 2.4 Nledici6n de! ~e Oflenlado 0 ob;eiIYos 470 15.2.5 1m ollioolos de las metricos efectiYOs del ~re 471 15.2.6 Ponoromo de los mlItricos del prodocto 472 15.3 tv\eIrlcos poro el modeIo de onalisjs 474 15.3. 1 Nelricos bosodos eo 10 Noci6n 474 15 .3.2 N.6Iricos poro 10 colidod de 10 especificoci6n 477 15.4 ~Icos fJOfO eI modeIo de d~ 479 15.4. ~ .Ye/ric:os del d iseiio ocquitecl6olco 47Q 15.4.2 WInc:os fJOfo eI dbei'lo orien4odo 0 abjetos 48 1 15.4 .3 ~ orienIc:dos 0 closes: 10 coIecci6n de rn6Ificos de CK 483 15.4.4 M6Iric:os orier1bdos 0 objeIo$: 10 coIecci6n de rMlrlcos paro eI di$Mo orieolodo o objeIo5 486 15.4 .5 NIetrk:os orieWodos 0 objea pI"~ por lofeoz y Kidd 487 15.4 .6 M61ricos de diseno ollliYEtl de componeole5 487 15.4.7 M6tricos orienlodos 0 10 operocl6n 491 15.4 .8 Nlelricos de disena de 10 iIlIeffoz de uwario 492 15.5 Nlelricos para eI c6diga Neole 493 15.6 M.lttricos para prue/:la5 494 15 .6.1 ..v,&iricos de Halsleod opIicodas 0 Io.s pl"liebos 494 15 .6.2 ~ico$ paro pl"uebos orienlodos 0 ob~ 495 15.7 fv\eIricos poro eI mon!ef1imiento 496 15.8 Re5\II"!lef1 497 RefeferlCios 497 Problemw Ypulllo$ 0 consideror 499 Otros lecturos y fuenle5 de informrxi6n 500

PARTI1US:

APUCACJ6N DI LA DfGiIIrIIIIdA. WEB

501

cA>irvLo 16
16. 1 16.2

AIIibutos de los ~ y oplicociones bosodos eo V\Ieb 504 EaC*;lt de 10 Ingenieria de 'vVebApp 507

CONTENIDO 16.2.1
Proceso

507

16.2.2 16.2.3
10.3

""""'" 507
Henomienkls y

lecnoIogio

508

16,4

16.5 Refefeocios 515 Probiemo.s V ponlo.s a considerar 5 15 Otros Iecturos y fuentes de inloonoci6n 5 16

EI proceso de ingenieria Web 508 \6.3. 1 Oefinici6n dell1lQlCO de .obajo 5W 16.3.2 Refinomioolo del morro de IrObo;o 512 .M&jores pr6cticos en ingenierio Web 512 Resumen 514

CAPtnn.o 17
17. 1
17 . I. 1

FORIfULACl6N y PLAHEACl6N PARA INCiINIERIA WEB

Pregunlas de flxmvloci6n 5 19

517

Formuloci6n de sislemos b:cxh en Web 518

17.2
17.3

l1ecopiloci6n de reqvisilo5 paro W~ 520 17. 1 3 El puente hocie eI modeIodo de on6Jisis 525 f'Ioneoci6n de ployeclos de ingeniefio VVeb 525 EI equipo de ingenielia Web 526 17. 1.2
17.3. 1 Los odofes 526

17.4

17.5

17.6
17.7

17.3.2 Constrvcci6n del equipo 528 CoofIidos de gesti6n de pro)'edO paw ingenierio 'Neb 528 17.4 .1 PIone0ci6n de WebApp: subconIn:rtoci6 530 17.4 .2 PIoneoci6n de WebApp: ingenierio Web en coso 533 l'v\Idici6nporoingenierioWebyV\febApp$..536 17.5.1 Mediciones para mfuerzo de ingenierla Web 537 17.5.2 Wledici6n dehdor de negocil 538 Los "peores pr6dicos' pora proyeclo$ 'vVebApp 539

Resumen 540 Referencios 54 1

Problemas y puntos 0 comideror 542 OIros IeclurQ.S y fuefiles de infoflTloci6n 542

cAPfTuLo 18
18. 1

MODELADO DE ANAusls PARA APLICACIONES WEB 544

~

l1equisilos pora

on6!isis de los Web,to.pps 545 '

\ISO

18 . 1. 1 18 .1.2
18.1.3 18.2 18.3 El

La ieforquia de IJ$OOrio 546

Desarrollo de CCl$OS de

547
U$O

Afinoci6n del modeIo de coso de

549

E I ~ de on61Ws poro WebApps 550

modeIo de conlenido 551

Definic:i6ndeobjelosdecontenido 551

18.3. 1 18.3.2 18.3.3 18.-4 18.5 El

Relocionesyjerorquiocleconienido 552

Oases de CII"I6Iisl$ pclfO WebApps 553 modeIo de interoc:ci6n 554 El rnocWo funcionol 557

CGi'UWWO

EI modeIo de confIguroci6n 559 An6lisis reloci6n-novegoci6n 559 18.7.1 An6Iisis de r~: preguolcs clove 560 18.7.2 An6lisis de novegoci6n 561 18.S Resumen 563 Refefencios 563 Problemas y punlos a consIderor 564 OIros leduros y luenles de inlormoci6n 564

IS .6 IS.7

CA>Inn.o ,.
19.1

UODELADO DB DISDlo PARA APUCACIONES WEB

566

Temos de dise?lo poro ioger'lierio Web 567

19.1.1 Di.seno y colidod de una WebApp 567 19.1.2 MeIo$ded~ 571 19.2 Plr6rnide del disei\o l'vVeb 572 19.3 Disefio de 10 intenoz de 10 WebApp 573 19.3.1 Principios y direclrices del disef,o de 10 in~z 574 19.3.2 Neconismos de conlToi de 10 inlefioz 579 19.3.3 Aujo de Irobojo en eI disefio de 10 intenoz. 5S0 19.4 Disefio esIetico 582 19.4.1 Coe.slionesdeloplontillo 582 Cuestiooes de disei\o gr6fico 583 19.4.2 19.5 Disei\odelcontenido 584 19.5. 1 0bjeI0s de conlenido 584 19.5.2 ClJe$/iones del dlseno de conlenido 585 19.6 Oi-.oorquilecl6nieo 585 19.6.1 Arquileduro de conlenido 586 19.6. 2 Arquilecluro de WebApp 588 19.7 Di-.o cI& novegoci6n 590 19.7.1 Sem6ntioo de navegoci6n 591 19.7.2 Sinloxis de flO"Je9OCi6n 592 19.8 Diseno 01 niY&l de compooenles 593 19.9 PoIIone! de dlseilo hipeflnec!io 594 19. 10 .v.etodoOe diseOO hipeffnedio Ofienlodo a obietos (MOHOOI 595 19.10.1 Disenoooncepruolporoel.........oHOO 595 19.10.2 Di$8flo de oovegoci6n mediante eI f-IoDHOO 596 19.10.3 Diseno oU.hodo de 10 ioIerfoz e implementoci6n 597 19.11 lW!Iricos de diseno poro ~ 598
19. 12 R er.umen 599

R eferenclos &:Xl Problemas y punIO$ 0 oonsideror 002 Otros Iecturo y fv1res de inlormoci6n 603

CAPfTuto 20
20. 1

c6uo PIlOUJI:

APUCAClOHBS WEI 604

Pruebo de <::CI"ICepI05 poro ~ 005 20. 1.1 ~ de colidod 005

..
20.1.2 20.1.3 20.1..4 EI'TOf9$ dentro de un ombien\e 'v\feb4.pp 606

20.2 20.3

20.4

20,5 20,6

20.7

2O.S 20.9

E~oIegios de ~ 007 Plolleoci611 de 105 pruebo, 608 EI ~ de pn.rebo: Ufl panoromo tI:R Ptuebo del conlenido 612 20.3.1 c::>bjeIr.os de Ie pn.rebo de contenido 612 20.3.2 PruebCJ de las bases de datos 613 PrueOO de Ie interfoz del usuariO 616 20.4.1 E.strolegio de prur.tbo.s de 10 intedc.z 616 20.4.2 Pruebodemoconi$lTlO$de lointeffoz 617 20A .3 Pruebo de 10 sem6ntioo de b in!effa.z 619 20.4.4 pruei:xJ de 10 Iocilidod de usa 620 20.4.5 Prveb:ls de c:ompolibilidod 622 PrLl8bo 01 nive! de componentes 623 PrLlllbos de novegaci6n 625 20.0.1 Pruebo de 10 ~nklxis de 1'l<J'.Ie9OCi6n 625 Pruebo de 10 sem6n1ico de oovegcx::i6n 626 20.6.2 Pruebo de Ie conIiguroci6n 628 ConIIidos en ellodo del _vida! 628 20.7.1 20.7.2 ConfIiC:to$ en ellado del dieflle 629 Pruebos de seguridod 630 Pruel::nsdeldesempeno 631 20.9 .1 ~ de Iw prueJx. dol dooempoOO 632 20.9 .2 I'ruebos de corga 633

Pru.bo. de """"" 633 20.9 .3 20.10 Resumen 635

Relerenclos 636
I'robIetno$ Ypunlo5 '! coruideror 637 0Ir0s Iectvros y fuen/es de inbmoci6n 63 B
PAR'I'E CUMIIO:

GiISTI6N DI PROYZCTOS DE SOFTWAB

CAPfnn.o 21
21 . 1 EI especlfo de 10 gesliOO 21 1.1 EI per.sooal 21 .1.2 Elp!'oduclo EI proceso 2Ll .3 64 1 641 642 642 EI pt'''J'8C1o 643

639

CONCEPTCI6 DE GiESii6H

m I'IIOYICTOS

640

21.2

21. 1.4 Personal 21.2.1 21.2.2 21.2.3 21 .2.4

64A Lidere! de equipo 64A Et equipo de ritwq'e 645 Equipc 6giles 649
Los porticiponles

21 .2.5
21.3

Conflicm de ooordinaci6n Y CQmIlllicad6n 650

EI produd:J 651

21.3 . 1 21.3.2 21 .4

Ambito del software 651 0esc0mp0sici6n del problemo 652

EJ proceso
21 .4. 1 Combiooci6n del produdo y eI proo!SO 653 21 .4.2 ~delproceso 654 EI proyedo 656 EI principia W~HH 657 Pr6c:ticos csilicol 658 Re.wmefl 659

21.5 2 1.6 21.7 21 .8

Refereocios 6ti)

Problmnos y pufllos a oon.sidefm 6ffi Otro.s lectufo.s Y luenles de inlormoci6n 661

cAPfTtn.o 22
22.1 22.1 1 22.1.2

MiTRICAS DE PROCESO Y PROYECTO 663

N.etricos

Mefficos en los domink del proceso y Ell proyeclo 664

..'v\6!ricos

del proceoo y mejoro del proceoo de 50ftware 664 del proyedo 667 22.2 .v..ediCi6n del software 668 22 .2. 1 N.elricO$ orientodos 01 tomoilo 669 22.2.2 Melricos orientodos a 10 runci6n 670 22.2.3 Reconc~ioci6n de los metricos LOC y PF 671 22.2.4 Melrico.s orienlodos 0 objetos 673 22.2.5 ..v.!IIricos orientodo.s 0 COSO$ de UlO 674 22.2.6 ..v.!IIricos de PfO'J'I'C'C de inQenierio 'Neb 674 22.3 ~ para coIidod del ~fe 676 22.3. 1 M8dici6n de 10 colidod 677 22.3.2 'Eficocio en 10 elimiooci6n de defect;)$ 678 22.4 IntegfOCi6n de los ml!tricos denlro del prOCe50 de ~fe 680 22.4 .1 KI ArgumenIo5. JX)ra los ml!Iiico$ del ~e 680 22.4 .2 Esioblecimienlo de uno ~neo bose 6B 1 22 .4 .3 R ecopi1oci6n. c6kuk> y evo1uoci6n de ml!irico.s 682 22.5 N.elriCOs para orgonizociones peqllet'ios 682 22.6 btoblecimier11o de Uf1 progromo de melricos de ~re 684 22.7 Resumen 686 Referencios 687 Problemo.s y punlo5. a coo!o4deror 687 Otros ~s y ruenles de informoci6n 688

CAPtnn.o 23
23 . 1 23 .2 23 .3 23 .4

ESmU.CI6N PAllA PROY!C'I'05 DE SOFTWARE 690

Cbservociones ocerca de 10 estimoci6r1 691 EI proceso de pIonificoci6n del proceso 692 Ambito del software y foc:tibilidod 693 Recur-lOS 694 23.4.1 RecurlOS humonos 695 Recur$O$ de ~re revtilizobles 695 23.4.2

23.5 23.6
23.7

23.4 .3 l1eoJr~ del enIomo 696 E stimoci6n de proyectos de sofIwofe 696

T8cnic::m de ~ 698 23.6 . I Tomono del soI!wore 698

23.6 .2 23.6 .3
23.6.4

Estimaci6n bosodo en eI problema

Un ejemplo de esIimoci6n

t:RQ
700

Ixlsodo en lOC

23 .6.5
23 .6 ,6

Un ejemplo de es~moci6n bosoda en Pf 702 Estimaci6n bosoda en eI proceso 704

Un eiempIo de estimoci6n bosoda en eI PfOCMO 705 23.6] Eslimoci6n coo oosas de uso 705 23 .6 .8 Un ejemplo de e5timoci6n oosoda en CO.50S de uso 707 23 .6.9 li:econciliod6n de eslimociooes 708 fvIodeIo5 ernpiriCO$ de estimaci60 7ey:;

EI modeIo COCQNO II 710 La ecuoci6n del .softv..ore 71 2 23 .8 E5!imoci6n pore proyectos Ofientodos a objetos 713 23 .9 Tecnkos de eslimoci6n especiolizodos 714 23 .9.1 Estimoci6nporodesorrollo6gil 714 23 .9.2 Estimoci6n poro proyectos de ingeniefia Web 715 23.10 La decisi6n cIesorrolol'COmprOf 217 23 .10.1 Creoci6ndel,lllOrOOldedeeisi6n 717 23.10.2 Subcontralod6n 718

23.7.1 23.7.2 23.7.3

La estrocturo de ~

moc!eIos de estimoci6n 710

..

23 .11 Resumen 720

Referencios 721

Ptoblemos y puna Q consideror 72 ,

Otros lecturos y fuentes de inlormoci6n 722

24 . 1
24 .2

Conceplos b6slcos 725

Calendorizoc:iOO de P'oyecto

727

24.2.1 24.2.2 24,2.3 24.3

Definici6n

728 Rebci6n entre eI p8f~1 YeI esluerzo 729 Distriboci6n M esfuerzo 732 de un conjunlo de !oreos poro eI provectO de x:Jtware 732
Ejemplo de conjunlo de Icm~as 733 Refinamie/llo de los lareos ptincipales 734

Principios b6~

24.3. 1 24.3.2 24..4 24.5

Definlci6n

de una

red

de Ioreas 735

Colendaritoci6n 736
24.5. 1 24.5 .2 24.5.3 Cranagramos 738 Seguimienlo de

10 caIenOOri.toci6n 739

Seguimienlo del progreso en un proyecIO 00 741

24.6 24.7

An61i$i$ del YQJa, gonoda 742 Resumen 744

CONTINIDO
Referential" 744

GlESim DEL RIESGO 747

Problemas y pontes 0 coosideror 744

c:>h-as Ieduros y Iuer1Ies de informoci60 746

25. 1
25 ,2

Utrotegios

de rie$go

reodillOS y

prooctivos 7418

Riesg05 del $Ohware 749

25.3

25,4

25.5
25.6

25.7
25 .8

Idenrificoci6n de riesgo$ 750 25.3.1 EvoIuoci6n del riesgo global del proyedo 752 25.3.2 Componenles y cooIrolOOores del riesgO 753 Pf~i6n del riesgo 754 25.4 .1 Desarrollo de uno labia de ~ 755 25.4.2 E...aIuoci6n del impoclO del riesgo 757 Relinomlenlo del ri&sgo 759 Redl.lCc;oo, wpervisi6n y ges~6n del rie:.go 759 EI pion RSGR: 763
Resumen 764

Referencias 764 ProbIemos y punlO$ a coosideror 765 OIros Iecturos y ~ de inb~ 765

CAPtnn.o 26
26. 1

Gii!Si16N DE IA CA1lDAD 767

26.2

26.3

768 769 26. 1.1 Ca<klod 26.1.2 Control de coIidod 770 Goronlio de 10 colidod 770 26.1.3 ~Io de 10 colidod 770 26.1..4 Goronllo de 10 colidod del soltwore lSON 771 26.2. 1 AIguoo.s onlecedenles 772 Actividodes de SQA 773 26.2.2 RlrVisiooes del soltwore 774 26.3. 1 ImpodO de Ie defoctos de soltwore en eI c<lO 775 26.3.2 Ivnplif~i6n Y ~iminoci6n del deleclo 776
R evis;ones tecnfoo$ formales
26.4 ,1

~clecolidod

26.4

778

26.5

26.6

26.7

La ionia de revisi6n 778 Ink:nne de 10 revisi60 y COIlsefVOCl6n de reglslTos 779 26.4.2 26.4.3 Dir~ice5 de 10 revisi6n 780 26.4.4 l!eYisiones OOsodos en muestfas 781 Enloque IormoIei CICeIW del SQA 783 Goronlio de 10 coIidod eslod's/ico del soltwore 783 26.6 . 1 Un ejempIo genl!fico 784 26.6 .2 Seis sigma para ingenieria del ~e 785 Fiobilidad del software 786 26.7. 1 Medidas de fIobilidod y di$ponibilidod 787

26.7.2 SegUfidod del KJftwore 788 26.8 l.o.s esl6ndores de coIidod ISO QOOO 789 26.9 EI plan de SQA 791 26. 10 Rewmefl 792
Relerencio5 792

Problemas y punk 0 CCIn$ICIeror 793 OIros Iectuf(U y fuenlflli de informoci6n 194

cAPIruLo .7
27.1
27.1.1

GiiSlt6N DEL CAMBtO 196

GesIi6n de 10 configvraci6n del KItwore 197

Un

27.1. 2
27. 1.3 27.1 .4

de GCS 798 Elementos de un sistema de geJti6n de 10 configuroci6n 79Q

e~enorio

27.2

27.3

I.ioeos be", 800 EIemet1Io5 de con~guroci6n del sof!wore 801 EI dep6$ilO de ECS 803 27.2.1 EI popel de depcilo 803 27.2.2 Carocleristicos y contef1idos ger.ales 804 27.2.3 Caroclerl$licos de 10 GCS 805 EI pr~ de GCS 806 27_3 1 lden~ficoci6n de objeIos en 10 conIiguroci6n del $O&wo!'e 807 27,3 .2 Control de 10 _~ 80a'l1 27.3.3 27.3.4
27,3 .5

eon.oI del combio 810

Audib'1o de 10 conIiguroci6n 813
Infofmedeeslodo 814

27.4

Gesti6n de 10 conhguraci6n poro ingenierio VVeb 815

27.4.1 27.4.2 27.4 .3 27.4 .4 27 A .S 27.4.6

Problemos en 10 gesti6n de 10 configulOd6n poro WebApps 815 Objelos de configuroci6n ~ 817 Gesti6ncielconlenido 817 Gmti6n del combio 820 Conkel de 10 versi6n 822 , Audilorio y eIobaoci6n de inbmes 823

27.5 Rewmen 824 Ref9feOCios 825 Problemos Y ponlos 0 consideror 826 o.os Ieduros y Iuentes de inlormoci6n 827
PARTE CINCO: 'TD&AS AVANZADOS EN

c:.utrm.o 28
28. 1

INGmNIER1A DEL SOFTWARE a.droDos FORM AI IS 330

129

2S.2

Conceptos b6slcos 831 28 .1. 1 Deficiencios de 105 enfoquM met'lO\ lormoles 832 2S .1. 2 MoIern6Iicos en eI desarrollo de $(lfrv.'I;lIe S33 2S .1. 3 ConcepIos de rnetodos formoles S33 Preliminores moI8m6ticos S37 28 .2. 1 CaljI.Wllos Y especificoci6n coruIIudMJ 837

28.3 28.4 28.5

Sucesiones 84 I de 10 IIOOd6n motem6Iico pora 10 especilicoci6n formal 842 lenguo)es bmoles de especificoc!6fl 844
~icod6n

28.2.2 28 .2.3 28 .2.4

Operodones de con(unlO$ 838 Operodores l6gioos 840

lengooie 28.5.1 28.5.2

reslring~ 0

objelO$ (OCl) 845

28.6

Un breve panoroma de 10 sintoxis y 10 sem6ntico del OCL 845 EjempIo de LISO del OCt 847 E11eoguoje de especilicoci6n Z 849 29.6.1 8reve porroroma de 10 slnloxis y $em6nrico Z 949

28.6.2 Un elemplo que uIilizo Z 849 28.7 los die.z mandomienlO$ de Ie metodos Iormolel 852 28 .8 NI8todos Iormoles: eI camino po!" recorrer 853 28 .9 R esumen 954 Referenclos 855 Problemos y pvnIos 0 COI"I$ideror 855 Otros lecMos y fuentes de inlormoci6n 856

cAPfnn.o 29
29.1

INGIENIERIA. DEL SOfTWARE DE SALA UJDIA 858

29.2

EI enloque de solo Ilmpkl 859 29.1.1 to 8$IrOIegia de solo limpio 860 29. 1.2 ~Gue hoce dilerenle 0 10 solo IlmpioV 862 Espedlicoci6n func:iOnoI 863 29.2.1 Especilic:oci6rn:1e 0010 negro 865 29.2.2 Especificoci6n de cojc de MIodo 966 29.2 .3 Upecilic:oci6n de caio Ironsporenle 866 Diset'lo de solo limpio 867 29.3.1 ReFinorniento y "IIri1icoc16n del diseno 867 29.3.2 Venlojos de 10 verilicocl6n del di$ei'lo 87 1 Pruebos de solo Ilmpio 872 29.4 .1 29.4.2

29.3

29.4

Prvebos esb::Iistica.s de uso 873 Certific:oci6n 874

29.5 Resumen 875 Refefencios 976 ProbIemo.s y pvnk 0 conSideror 876 Otros ledurcu y Iuentes de inlOfmoci6n 877

cAPfruLo 30
30.1 30.2 30.3

DfCDNIERfA. DEL SOFTWARE BAS.ADA EN COMPONEN1'ES

879

Ingenierio de $islefnos bcuodo en componentes 8BO

EI pnxe3(l de Isse 882

Ingenierio del dominic 883

30.3.1

EI

ptOCe$O

de on61isis del dominio 883

885

30.4

30.3.2 FlJnciones de caraderizoci6n 884 30.3. 3 !V'odeIodo eslrucl\trol y punlos de estrucllJfO Clesorrollo basoda en COfnponet'lles 886

....
30.4 .1

CoIJicoci6n, odoptoci6n y cornpoaici6n de COI1\fXII*lIes 887

Ingenierio de ~ 890
891 An6lisi$ y d iseiio poro 10 reutiliZDci6tl

30.4.2
30.4 .3

30.5

c:1Iific:oci6n y recuperoci6n de c:otnpoI..,._ 892 30.5.1 Cle$crifXi6n de los c:omponenle$ relAilizoblM 892
30 .5 .2 E I enIomo de reutilizo06n 894 Economic de Ia lS8C 895

30.6

3D]

ImpacIo me 10 coIidod, 10 productMdod y eI com SQ6 30.6.2 An6lisis de coskl empleondo fJU'1D5 de estruduro 897 1I:8SUIlIef1 898
30.6. 1
89Q

Refefencios

Problemas y ponlos 0 coosideror QQO Otros leduras y fventes de inlormoci6n 90 \

CAPtnn.o 31
31 . 1

31 .2

de procesos de negocio 903 3 1 1. 1 Procesos de negocios 904 3 1.1 .2 Un II'lOdt.Io de RPN 904 I/:eingenlerlo del ~e 906 H7
Reingenierio

:)

31. 2. 1 31 .2.2
31.3

MlnIenimienlo dehd'woll~

Un modeIo de

procexlIS

907 de felngenierio del softwofe 908

Ingeoierio il'M!lnO 912

31 .3. 1 31 .3.2
3 1.3.3
31.4 31.4. 1

Ingenierio inYefso pora cornpIender 10$ dolos 913

Ingeniefio inYerso p::uo compender eI

916

~Ienb

9\ 4

Ingenierio irMwso de inIerfaces de I..I$UCIrlo 9 15

Rees/fuduroci6ndelc6digO 9\7

R l!IMInJduroci6n

J 1.4 .2
3 1.5 Ingenie60 diredo 91 8

3 \ .5 .1
31 .5.2

Ingenieria diredo para aquileduros dlente/seMdor 920

Ingenierio direclo pora orquil8cluros Ofienlodos 0

objeIos 921

31 .5.3
31 ,6 31.7

Ingeniedo dir6Cto de inleffoces de uwc :nio 922

La economic de 10 reingenierio 923 Rewmen 923

po nies a considerar

Referencios 924
Pr~5 y

925

OIfoslecrufos y Iveoles de inlormaci6n 926

CAPtruLo 32
32 .1 32.2 32.3 32.4 32.5 32 .6

D. CAJr.IINO POll ppcopprp 927

La importondo del soItwore. Segundo porte 928 EI6mbito del combio 929 los personas y Ie forma en Ie que consInJyen sistemas 930 EI "ntJf!YO" prOCMO de ingenieria del softwore 931 N\JI!IY05 mor:Ios de represenlcr 10 inlormoc::i6n 933 lo I9CnoIogia como impubor 935

CONTENlDO

32.7 t.o responsabilkh:! de 10 ingenieria del soft....oIe Q36 328 Un comentorio final Q38 Refen!lIlClO5 Q3Q Problemos y punlc)s 0 coosideror Q3Q Oros leduros y fuenle$ de informoci6n 9 40

Indice ana/frico 943 Siglas m6s comunes en ingenieria dd software 953

CAPiTULO

SOFTWARE E INGENIERiA DEL SOFTWARE

_ .-............ ........
CoNcEPTos
ct.AVE

....

... ........ 05

s comun darse cuenta que la invenci6n de una tecnologfa puede tener efectos profundos e inesperados en otras tecnologias con las que en apa-

-... .. Mftw.e .....

riencia no tiene ninguna relati6n, como en empresas comerciales. en personas y aun en la cullura en su conjunto. Este fen6meno a menudo se <lenomina "la ley de las consecuencias imprevistas". En la actualidad, eJ soltware de computadora es Ja tecnologla Individual mas importante en el ambito mundial. Tambien es uno de los ejemplos principales de Ia ley de las consecuencias imprevistas. Nadie en 1a decada de 1950 podria haber pre-

.............6

dicho que el software se convertiria en una tec.nologia indispensable en los negocios, J a cienda y la ingenieria; tampoco que el software permitiria la acad6n de
tecnologias nuevas (pOr ejemplo, la ingeniena genetical, Ia expansi6n de tecnologias existentes (como las telecomunicaciones), el fin de tecnologias antiguas (c0mo la industria de la impresi6n); que el software sena 1a fuerza conductora detrAs de la revoluci6n de las computadoras personales; que los productos empaquetados de software se podrian comprar en los centros comerciaies; que una compaiHa de software se vol verla muy grande y mas influyente que la mayorfa de las companias de la era industrial; que una gran red construida con software lIamada Internet cubrirla y cambiarfa todo, desde la investigaci6n bibliogrMICa hasta las compras de los consumidores y los Mbitos diarios de los j6venes (y no tan )6venes). Nadle podrla haber previsto que eJ software estatia reladonado can sistemas de todo tlpo: de transporte, medicos, de telecomunicaciones, militares, industriales, de entretenimiento, maqu inas para oficina <Ia lista parece no tener fin) .

.......... 12

..............1 __ ...... .. .14 ..tu ........ 11

. ......... .. .11

"'"""""" y 10 10 _ do w.dutIrioIimdo
cI;.-.
rna IftJ)' c:.c:ona trxb

,'-... _In.,,I.''' lis........

dos YIe he ~Gmi"_"''''' ",IMO y len octMdodoo _ ...

~oIIda.b
2

__ .w-

do.lo

...,

Y sl se toma en cuenta la ley de las consecuendas imprevistas, hay muchos crectos que todavla es imposibJe predecir en el trabajo diana. Por ultimo, nadie podrta habeT predicho que millones de programas de compuladora tendrian que corregirse, adaptarse y mejorarse confonne pasara el Uempo y que la labor de desarrollar estas actividades de ~ mantenimiento" absorberia mas gente y recursos que todo el trabajo aplicado para la creaci6n del software nuevo:

A medida que la importancia del software ha crecido, Ia comunidad del software ha intentado de manera continua desarrollar tecnologlas que hagan mas facil, mas
rapida y menos cara la construcci6n y el mantenimiento de programas de compu-

tadora de alta caUdad. Algunas de estas tecnologias se Iimltan al dominic de una

apllcaci6n especltica (por ejemplo, al dise~o y \a implementacl6n de sitios Web); atras se enfocan al dominio de una tecnologla (como la programacl6n orientada a obJetos y la programaci6n orientada a aspectos); yexisten otras con base general (por eJemplo, sistemas operativos como UNUX) . Sin embargo, aUn no se desarrolla una tecnologla de software que 10 haga lodo, y la probabilidad de que ~ta surja en el futuro es pequena. Aun asJ, las personas dejan sus trabajos, su seguridad y hasta sus vidas en manos del software de computadoras. Mas vale que ~e 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 con;unto de metodos y una serie de herramientas se llama ingenierlo dd software.

.... dIiiM

BdIwtnIes

~VI .:U.1
_ ..... m

klpIIII" ....

En la actualidad, el software tiene un papel dual. Es, a la vez, un producto y un vehlculo mediante el cual se entrega un producto. COmo producto, ofrece la patencia de c6mputo presentada como hardware de una computadora 0, de manera mas amplia, por una red de computadoras accesible mediante hardware local. Sin importar el lugar en que resida el software, ya sea en un celular 0 dentro de una compuladora central, este es un transformador de informaci6n; realiza la praducci6n, el maneto, la adquisici6n, la modificad6n, el despliegue 0 la transmlsi6n de la informaci6n que puede ser tan simple como un solo bit 0 tan compleja como una presentaci6n multimedia. En su papel de vehlculo para la entrega de un producto, el software actua como la base para el control de la compuladora (sistemas operativos) , Ja comunicaci6n de informaci6n (redes), y la creaci6n y el control de olras programas (utilerfas de software y ambientes) .

EI software entrega el producto mas importante de nuestro tiempo: informaci6n, nansforma los datos personaies (por ejemplo, las transacciones financieras de un individuOI de Iforma que los datos sean mas utiles en un contexto local; maneja informaci6n de negocios para mejorar la competitividad; proporciona una via para las redes de informacl6n alrededor del mundo (Internet) y proporciona los m e dios para adquirir Informaci6n en todas sus fonnas, EI papel del software de computadora ha experimentado un cambio slgnlficativo en un periodo un poco mayor a 50 afios, Las mejorfas sustanciates en el desempei'io del hardware, los cambios profundos en las arquitecturas de c6mputo, 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 mb elaborados y complejos basados en computadoras, Los Jibros populares pubJicados durante las decadas de 1970 y 1980 ofrecen una amplia visiOn hist6rica de la cambiante percepciOn de las computadoras y del software y su impacto en la cultura. OSborne [05B79] describi6 una "nueva RevoluciOn Industrial", Tomer [TOF8O]lIam6 al surgimiento de la microelectr6nlca parte de "la tercera ola del cambid' en Ja historia de la humanidaq., y Naisbitt [NAII82] predijo la transformaci6n de una sociedad industrial en una "sociedad de la Informaci6n", Feigenbaum y MCCOrduc\( [FEI83] sugirieron que la informaci6n y el conocimiento (controlados pot computado,ras) selian el punto de enfclQue para el poder en el siglo XXI, Y Stoll [ST089] argument6 que la ~comunidad electr6nica" creada por redes y software era la clave del intercambio de conoctmiento alrededor del mundo. Todos estos escri tores tenlan raz6n. AI comienzo de la dtcada de 1990, Tomer [TOF90] describi6 un "cambio de poder'" en el que todas las viejas estructuras (gUbernamentales, educativas, industriales, econOmicas y mllitares) se desintegrarlan a medida que las computadoras y el software condujeran a una ~democratizaci6n del conodmlento", Yourdon [YOU92) se preocupaba de que' las compai'\las estadounidenses pudieran perder su margen compeUUvo en negoclos relacionad05 con el software y predijo "Ia declinaciOn y calda del programador estadounidense", Hammer y Champy [HAM93) argumentaban que las tecnologlas de infprmaci6n representarian un papel primordial en la "reingenieria de la corporaci6n", A mediados de la decada de 1990 la penetraci6n de las computadoras y del software provoc6 el surgimiento de una serle de lIbros de "neoluditas" (como Resisting the Virtual Ufe, editado por James Brook y lain Boa\, y The Future Does Not Compute, de Stephen Talbot), Stos autores satanlzaban a la computadora al enfatlzar inquietudes Jegltimas, pero ignorando los grandes beneficios que ya se hablan obtenido (LEV95],

~IIIIIIO_
i"....... ,..

_.omdsdt.,.

............
.... 1IiIImI ..
- " " . , upeI'

.~ddsims.

.1Drm .. .b

. . . . oMnlDsy

...../os .-"fu.
... til
sistemas
. . Sf CMSIrt.oyJrtI,

........ C ..... Jr Iuntirt ,m.,


A finales de la d~cada de 1990, YourdoR (yOU961 evalu6 de nuevo a los candida-

tos a pro(esionales del software y sugiri6 el "'surgimiento y resurrecci6n ~ del programador estadounidense. A medida que Internet cobraba mayor importancia, el giro que habla dado Yourdon pareela ser el correcto. AI finalizar el sigla xx, el enfoque cambi6 nuevamente, esta vez con el impacto del Y2K, "bomba de tiempo" <:por ejempia [yOU98al. [KAR99]). Aunque las fata1es predicciones de aqueUos que vislumbra-

ban una catastrofe respecto al Y2K fueran falsas , sus populaces' escritos acarrearon la permanenda del software en la vida de los seres humanos.
Va iniciado el nuevo siglo, Johnson OOHO I ) explic6 el poder del "surgimlento" co-

mo un fen6meno que explica 10 que sucede cuanda Interconexiones presentes en entidades relativamente simples resultan en un sistema que "se autoorganiza para formac un comportamiento mas adaptable e inteligente". Yourdon [yOUR02j retom6 los tr.1gicos sucesos ocurridos el II de septlembre de 2001 en Nueva York para explicar el impacto continuo del terrorismo global en la comunidad InformAtica. Wolfram rwOL.D2] present6 un tratado sobre "un nuevo tIpo de denda" en donde expone una teoda unificadora basada sobre todo en elaboradas stmulaciones de software. Daconta y sus colegas [DAC03) explicaron la evolud6n de la "red semAntica", y c6mo esto camblar! el modo en que la gente interactUa a travcs de las redes globaies.

En la actualidad una enorme Industria del software se ha convert ida en un factor dominante en la economia del mundo industrlalizado. EI programador solitario de la era inidal ha side sustltuido por equipos de especialistas en software, en los que cada uno se enfoca en una parte de la tecnologla requerida para desarrollar una aplicad6n compleja. Hasta ahora, las preguntas formuladas at programador solitario son las mlsmas que se hacen cuando se construyen los sistemas basados en computadoras modemas:1 ,Por que tarda tanto la obtenci6n del software terminado? ,Por que son tan altos los costos de desarrollo del software?

,Por que es Imposible encontrar todos los errores en el software antes de entregarlo a los dientes?

I En un excelente Hbro de ensayos sobre el negoclo del software, Tom DeMarco IOEM95] ex:pone la Idea contraria. Expllca; ~En vet de cuestionarse por que cuesta tanto el software, uno debe preguntarse q~ se ha hecho para hacer que hoy el software cueste tan poco. La respuesta a esa pregunta ayudari a continuar con el exuaordinario nivel de logros que siempre ha di5tinguido a la Industria del software.

CAPlnn.o 1

SOFTWARE., INGENlERlA. DEL SOf'TWARE

,Por que se gasta" tanto tiempo y esfuerzo en el mantenimiento de los progTamas existentes?

,Por que es dil1cil medir el progreso a1 desarrollar y darle mantenimiento al software?

Estas y muchas atras preguntas demuestran la preocupaci6n de la industria por el software y por la manera en que este se desarrolla; una preocupaci6n que ha conducicto a 1a adopci6n de 1a practica de la ingenlerla del software.

En 1970, menos del uno por deRla de las personas podrlan haber deflnido 1 0 que signlficaba "software de computadora", En la actualldad, la mayoria de los profeslonales y muchos miembros del publico creen que entienden el software. Pero, .i.en realidad 10 haeen? Una definici6n de software en un libro de texto puede tener la siguiente ronna: el software ~ forma con I) las instrucdones (programas de compuwdoro) que al ejecutar51! proporcionan

las caracterisdcas, jimdones y eJ grado de desempdlo deseodos; 2) las estructuras de datos que permiten que los programas manipulen inJonnaci6n de manera adecuada; y 3) los documentos que describen la operad6n y el uso de los progmmas.

..........

Oscitwe 58 desooato, no

~VI

No existe duda de que se pueden encontrar deflniclones mas completas. Pero se requlere mas que una deflnici6n formal. Para entender el soft.ware (y la lngenieria del software), es Importante examlnar las caracteristicas que 10 hacen diferente de otras cosas que construye el seT humano. El software es un eiemento 16gico, en lugar de fisico, de un sistema . Por 1 0 tanto, el software tiene caractertstlcas muy diferentes a las del hardware:

I . El software 51! desarrolla 0 constnry'e; no se manuJactura en e/ sentido c1dsico.

A pesar de que existen similitudes entre el desarrollo del software y Ja manufactura del hardware, las dos actividades son diferentes en 1 0 fundamental. En ambas, la alta calidad se alcanza por medlo del buen dlsel'lo, pero la fase de manufactura del hardware puede indulr problemas de calidad inexistentes jO que son faciles de corregir) en el software . Ambas activldades dependen de las personas, pero la reJaci6n entre la gente utillzada y el trabajo realizado es dlferente por completo (V~se el capitulo 24) . Ambas actividades requieren ta construccl6n de un "prOOucto" , perc los enfoques son diferentes. Los costos del software se concentran en la ingenleria . Esto significa que los proyectos de software no se pueden mane!ar como sl fueran proyectos de manufactura.

2. EJ software no se -desgasta-.
En la figura 1.1 se muestra, para el hardware, la tasa de fallas como una funcl6n del tlempo. La relacl6n, Ilamada a menudo curva de la banera", indica
U

.
j
TIompo
que el hardware tiene un nUmero considerablemente alto de (alias al inicio de

su vida (a menudo estas se atribuyen a defectos de disef\o 0 manufactural. ! oespues, los defectos se carrigen y la tasa de Callas baja hasta un nivel estable

flan-S.

(se desea que este sea muy baja) por algt)n periodo. Sin embargo, canronne pasa el tiempo. la tasa de (alias se eleva de nuevo conforme los componentes
del hardware sufren los erectos acumulatlvos del polva, Ja vibraci6n, eJ abuso,

-""'-,
lIS naSoriI

Si SI desea reda tI

las temperaturas extremas y muchas atres males amblentales. Expresado en

forma mas simple, el hardware comienza a desgastarse.

"' .... _r,.

Uzt.
"'~m

~VI .-.....
,.,.fu! do .. ,."
V10 pendionte de 10 am ..... SI

"" ........ ~. ., _dO

..-"'~ "'" 1.2.

El software es inmune a los males ambientales que desgastan el hardware. Por 10 tanto, la curva de 1a tasa de Callas para el software deberia tener 1a forma de la "curva idealizada~ que se muestra en la ligura 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 comgen (en el mejor de los casos s in agregar otros errores) Y la curva se aplana como se muestra en la ligura 1.2. La curva idealizada es una simplilkaciOn burda del modelo de fallas real para el software (para mas informaciOn vease el capitulo 26) . Sin embargo, 1a implicaciOn es dara: el software no se desgasta, pero 51 se det.eriora. Esta contradicci6n aparente se puede explicar de mejor manera si se considera Ja "curva real" de la ligura 1.2 . Durante su vida,l e l software experimenta cambios. Confonne estos ocurren se presenta la posibilldad de introducir 0 que ocasiona que la curva de fallas tenga un pico, como se mueserrores, 1 tra 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, 1 0 que ocaslona que la

2 De heche, desde el momenta en que comienza el desarrollo, y mocha antes de que se entregue 11 primera versi6n, el cliente puede soIkitar cambk>s.

-.....

"""'" do

.. Klftwca .

-.

..,.. ... doI sdtwIn 51 (GIlt .". 0 kiln.." del

~YI

curva tenga alro picc. De esta manera, el nivel de (alias minima se comienza

a elevar; el software se deteriora debido a los camblos. otro aspecto del desgaste ilustra la diferencia entre el hardware y el software. Cuanda un componente del hardware se desgasta se sustituye con un
repuesto. Pero en el software no existen repuestos. Cualquier falla del software implica un error en el disei'io 0 el proceso mediante el cual se pas6 del diseno a1 c6digo m~quina ejecutable. Por 10 tanto, el-mantenimiento del software

ImpIica de rnanera considerable una complejidad mayor que el del hardware.

3. A pesar de que 10 industria tiene una tendencia haaa Ja construcci6n por componentes, Ja mayorfo del software aun ~ cons~ a 10 Jredida.
Considerese Ia forma en que se disena y construye un hardware de control para un producto de c6mputo. EI ingeniero de diseno dibuja un esquema sim pie del sistema de circuitos digital, realiza algunos analisis fundamentales pa ra asegurarse de que el diseno reaJizara las funclones apropiadas y despues busca en los catalogos de componentes digitales cada c1rcuito integrado de acuerdo con un numero de parte, una fund6n definida y valklada, una Interfaz bien definida y un conjunto estandarlzado de directrices de integradOn. Una vez seleccianado cada componente, puede solicitarsele para despues ensam blarlo. Cuando una disciplina de ingenierfa evoluciona se crea una colecdOn de disenos estandar de componentes. Los tamillos y los circuitos integrados son s610 dos ejemplos de los miles de componentes estandar que utilizan los in genieros mecAnicos y electricos al disenar sistemas nuevos. Los componentes reutilizables se han creada para que el ingeniero se pueda concentrar en los


elementos qu-e--en reaUdad son Innovadores e'n el dls:eno; es declr,.en las partes que representan alga nuevo. En el mundo del hardware, 1a reutllizacl6n de componentes es una parte natural del proceso de ingenierla. En eJ ambito de!'"
software, dicha actividad apenas se ha comenzado a extender.

Un componente de software se debe disei\ar e implementar de fonna que pueda utlllzarse en muchos programas diferentes. Los componentes reutiliza bles modemos encapsulan tanto los datos como el proceso que se apJica a !s

los, 10 que permlte 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 reutillzables que permiten la creaci6n de ventanas graficas,, menus despJegables y una amplia variedad de mecanismos de
interacci6n. Las estructuras de datos y los detalles de procesamiento requerldos para construir la interfaz estan contenldos en una IIbrerla de componentes reutillzables para la construccl6n de la interfaz.

En 1a actualidad existen siete grandes categorlas del software de computadora que. presentan retos continuos para los Ingenieros de software.
SOftware EI software de sistemas es una colecci6n de programas escritos para servir a otros programas. Algunos programas de sistemas (como los compiladores, editores y ulilerias para la administraci6n de archivos) procesan estructuras de informaci6n complejas pero detenninadas.4 Otras aplicaciones de sistemas (por ejemplo, componentes del sistema operatlvo, controladores, software de red, procesadores para telecomunicadones) procesan datos Indeterminados. En cada caso, el area de software de sistemas se caracteriza por una interacci6n muy intensa con el hardware de la computadora; utilizaci6n por multiples usuarios; operaci6n concurrente que requlere la gesti6n de itinerarios, de comparticl6n de recursos, y de procesos sofistlcados; estructuras de datos complejas y multiples interfaces extemas.

cIe.......

SOftware de apHcad6n. E1 software de apllcacl6n conslste en programas independientes que resuelven una necesidad de negocios especifica. Las aplicaciones en

3 La Ingenlet1a del software basado en componentes se presenta en el capitulo 30. .. El software es determinado.sl el orden y el Tltmo de las entradas, el procesamiento y las salldas son predecibles. EI software es indeterrrtinado 51 el orden y eJ rltmo de las entradas, eJ procesam1ento y
las salidas no se pueden predecir.

cAPfnn.o 1

SOFTWARE E INGENlD4A DEL SOFTWARE

esta area procesan datos empresariaJes 0 tecnicos de forma que fadlitan las operadones de negocios 0 la toma de decisiones tecnicas 0 de gesU6n. AdemAs del procesamiento de datos convendonal, el soft:ware de aplicaci6n se utiliza para controlar l~s funciones de negocios en tiempo real (pOr eJemplo, el procesamiento de transacdones en los puntos de venta y el control de procesos de manufactura en tiempo real.)

Softwue dentttko y de ina:enierla. El software cientlfico y de ingenieria, que se

caracterlzaba por ai goritmos ~devpradores de numeros", abarca desde Ja astronomla hasta la vulcanologia, desde el analisis de la tensi6n automotriz hasta la dinamica orbital de los transl?ordadores espadales, y desde la biologia molecular hasta la manufactura automatizada. Sin embargo, las aplicaciones modemas dentro del Area cientifica y de ingenieria se alejan en la actualidad de los algoritmos numericos convencionales. El disei'io asistido por computadora, 1a simulaci6n de sistemas y otras aplicaclones interactivas han comenzado a tomar caracteristicas de software en tiempo real e Incluso de software de sistemas.

SOftware emportado. EI software emportado reside dentro de la memoria de s610 lectura del sistema y con eJ se implementan y controlan caracteristicas y funciones
para el usuario final y el sistema mismo. EI software incrustado puede desempei'iar fundones Iimitadas y curiosas (como el control del teclado de un homo de microondas) 0 proporcionar capacidades de control y funcionamiento significatlvas (por ejemplo, las fundones digitales de un autom6vil, como el control de combustible, el despllegue de datos en el tablero, los sistemas de frenado, etcetera) .

Software de linea de productos. EI software de linea de productos, disei'iado para proporcionar una capaddad espedfica y la utilizad6n de muchos dientes diferentes, se puede enfocar en un nicho de mercado limitado (como en los productos para el control de invenlarios) 0 dirigirse hada los mercados masivos (pOr ejemplo, aplicadones de procesadores de palabras, hojas de calculo, graflcas por computadora, multimedia, entretenimiento, manejo de bases de datos, administraci6n de personal y flnanzas en los negocios).

ApIIcacIonet baNda. en Web. Las "webAppsH engloban un espectro amplio de

aplicaclones. En su forma mas simple, las WebApps son apenas un poco mAs que un conJunto de archlvos de hipertexto ligados que presenta infonnad6n mediante texto y algunas grallcas. Sin embargo, a medida que el comercio electr6nico y las aplicadones B2B adquieren mayor importancla, las WebApps evoludonan hacia ambientes computacionales sofisticados que no 561 0 proporcionan caracteristicas, funciones de c6mputo y contenidos independientes a1 usuario final, sino que es~n integradas con bases de datos corporativas y aplicaciones de negocios.

Software de

InteJlaenda artlfk:laJ.

Este software utiliza algoritmos no numeri-

cos en la resolucl6n de problemas complejos que es imposible abordar por medio de un anAlisis directo. Las aplicaciones dentro de esta area incluyen ta rob6tica, los sis-

10

cAPiTuLo

SOFTWARE E lNGENlERIA m. SOFlWARE

temas expertos, el reconocimiento de patrones (imagen y Voz), las redes neuronales

artificiales, 1a comprobaci6n de teoremas y los Juegos en computadora .
........ ; 7' n . . _ _ _ mmiIIl.

Existen millones de ingenieros de software que trabajan duro en una 0 mas de estas ca~ tegorias. En algunos casos se construyen sistemas nuevas, pero en a lros las aplicaciones exislentes se comgen, adaptan y mejoran. Es cornun ver a un joven ingeniero de software que trabaja en programas m<1s viejos que el mlsmo. Las generaciones pasadas de creadores de software han dejado un Jegado en cada una de las categorias que se han definido parrafos atras. Se espera que ei Jegado de la generaci6n actual facilite la tarea de los ingenieros de software del futuro. No obstante, en el horizonte han
aparecido fetos nuevas:

Computaci6n ubicua. EI crecimiento rapido de las redes inalambricas podrfa

conducir pronto a la verdadera computaci6n distribuida. EI reto para los ingenieros de software serA desarrollar software de si stema y de aplicacl6n que permita que dispositivos pequenos, computadoras personales y sistemas de empresa se comuniquen a traves de grandes redes.

Alimenlad6n de la red. La World Wide Web se convierte con rapidez en un dispos iti v~ computacional, asi como en un proveedor de contenldo. EI reto para los ingenieros de software es crear aplicaciones simples (por ejemplo, planeaci6n de las
finanzas personalesj y complejas que beneficlen a mercados de usuarios finales especlficos alrededor del mundo. "It . . . . es pdIe praID, ~o siempre es posiWe p"palll'Sl.w

Fuente abierta.

Existe una tendencia creciente que impulsa la distribuci6n del c6-

digo fuente para aplicaciones de sistemas (como sistem as operativos, bases de datos

y ambientes de desarrollo) de forma que los clientes hagan moditicaciones locales.

El reto para los ingenieros de software es construir un cMigo fuente que sea descriptivo en sf mismo, pero, aun mas importante, desarrollar tecnicas que permitan tanto a los clientes como a los disenadores conocer los camblos realizados y la forma en que se manifiestan dentro del software.
La "nueva economla". La locura del punto-com que se aflanz6 en los mercados

financieros hacia finales de la decada de 1990 y la subsigulente ruptura en los primeros anos del siglo
XXI

ha lIevado a mucha gente de negocios a creer que la nueva

economia esta muerta. La nueva economia est A viva y saludable, pero evolucionara. con lentitud; la caracterizara la comunicaci6n y la distribucl6n masiva . Andy Uppman IUP021 puntualiza esta situaci6n cuando escribe:

11

Estamos entrando en una era caracterizada por las comunicaciones entre las maquinas distribuidas y la genie dispersa, en lugar de 1a que define una conex\6n entre dos individuos 0

reliere a ~conexio nes con-; \a siguiente ola se refiere a conexiones entre". Por menclonar algunos ejernplos, se Ilene Napster, Ia mensajerla instantanea, los sistemas de mensa}e ccrlOS y las BlackBeentre un Individuo y una maquina. El 3ntiguo enfoque de la teleronla se

me.
EI reto para los ingenieros de software es construlr aplicaclones que faclhten la comunicaci6n y la distribuci6n de productos en masa mediante pnxluctos apenas en formad6n. cada uno de estos "nuevas Tetos" obedecen1 sin duda la ley de las consecuencias

imprevistas y tendrtm efectos (para la gente de negoclos, los Ingenieros de software

y los usuarios finales) que no pueden predecirse en la actualidad. Sin embargo, los
lngenieros de software se pueden preparar al iniciar un proceso que tenga la suficienle agilidad y adaptabilidad como para acoplarse a los camblos drasticos en la tecnologla y las reglas de negocias que can segurldad se presenlar6.n en \a decada siguiente.

Existen cientos de miles de programas de computadara y todos pertenecen a uno de los siete grandes dominios de aplicaci6n -software de sistemas, software de aplicaci6n, software cientifico y de ingenierfa, software empotrado, software de producto, WebApps y apJicaciones IA- que se expusieron en 1a secci6n 1.3. Algunos de estos programas son de vanguardia -s6la divulgados entre ciertas personas, industrias y gobiemos-, pero olros son mas viejos, y en algunos casos mucho mas vlejos. Estos programas viejos -can frecuencia referidos como software heredado- han sido el foeo de atencl6n y preoeupaci6n continua desde la decada de 1960. DayaniFard y sus colegas \DAY991 describen el software heredado de la siguiente forma:
Los sistemas de software heredado .. fueron desarroJlados hace decadas y han sido mo-

dificados en forma continua para cumplir los requerimientos de los cambios en los negocios y en las plataformas de c6mputo. La prolireraci6n 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 evoluciOn

Uu y sus colegas IUU98j extendieron esta descripci6n al escribir que N muchos sistemas heredados persisten como el soporte de las funciones centrales de negocios y son indispensables para las empresas" . Por 10 lanlo, al software heredado 10 caracterizan su longevidad y el ser cntico para los negocios

12

1.4 .1

Colidad del software heredado

1M 100"",

,eM" ....
poco mIi-

Por desgrada, existe una caracteristica adicional que tal vez este presenLe en el soft~ ware heredado: poco calidodf> Algunas veces, los sistemas heredados tienen disenos imposibles de extender, cMigo complicado, documentacl6n escasa 0 inexistente, casos de prueba y resultados que nunea fueron archivados, un historial de cambio m anejado con pobreza, etcetera; la !ista podrta seguir hasta tener una longitud considerable. No obstante, estos sistemas son el soporte de "las fundones centrales de negocios y son indispensables para las empresas" (UU98] . ,Que se puede haeer? La (mica respuesta razonable podria ser no hacer nada, al menos hasta que el sistema heredada experimente alglln cambia significativa. Perc si salisface las necesidades de sus usuarias y funciana de manera canfiable, el sistema no esta rola y no requiere arreglas. Sin embargo, canfanne pasa el tiempo, los sistemas heredadas evalucianan par una a mas de las razanes siguientes: El software debe adaptarse para satisfacer las necesidades de los nuevas ambientes a las nuevas tecnalogias de c6mputa.

(011

M .....

softW.'._

,HlJ 1
If IOftwar. .......1

tipas de mmbios '" M

El software debe mejararse para implementar los nuevos requerimientos de los negacios. EI software debe extenderse para hacerla operable con sistemas y bases de datos mas modemos. EI software debe rediseftarse para hacerlo viable dentro de un ambiente de red.

,._wo.
e ...... _,.
""",~.

Cuando suceden estas fonnas de evoluci6n en un software heredado, este debe someterse a una reingenieria (capitulo 3 1) de modo que conserve su viabilidad en el futuro. La meta de la ingenieria de software moderna es N imaginar metodologlas que se basen en la noci6n de la evaluci6nN; esto es, la noci6n de que N los sistemas de software cambian de manera continua, los nuevas sistemas de software se construyen a partir de los viejos, y... todos deben interaCluar y cooperar can los demas N

"'-""

C'lIp"/ ariio IS nattxri. No debe it

....

IDAY99!.

1,4.2 Evoluclon del softwCD'e

El software de computadora evoluciona a traves del tiempo, sin importar su dominia de aplieaei6n, tamano a eomplejidad. E[ cambio (que con frecuencia es lIamado

manfenimiento del software) conduce este proceso, y se presenta cuando se corrigen

errores, cuando el software se adapta a un nuevo ambiente, cuando el cliente soliclta caraeteristicas 0 funciones nuevas, y cuando la aplicaci6n experimenta una reingenieria para propareianar beneficios en un contexto medemo. Sam Williams IWlL021 refiere esta situaci6n cuando escribe:
5 En este caso, Ia caUdad se juzga con base en el pensamiento mCKIemo de la ingenieria del software, que en cierlo modo es un criterio injuslO, puesto que algunos conceptos y prtncipios modemos de la ingenieria del software alin no habfan sido bien entendidos ruanda se desarrollO el software heredado

cAPhtn.o

!OfTWARE E INGENlERfA DEl. SOFTWARE

13

Debido a que los programas a gran escala como windows y Solaris se expanden bien en
el inlervalo de 30 a 50 millones de Uneas de c6digo, los administradores de proyecto ex[tosos han aprendido a dedicar tanto tiempo a combinar los enredos de nuestro c6digo heredado como a agregar c6digo nuevo. Para decirlo de manera mas simple, en una decada en [a que el desempeno promedio del microchip de PC se incrementb cien veces, 1a inca-

pacidad de escalar el software induso a lasas lineales ha pasado de un pequeno secreto

a una enorme alleracibn en toda 1a Industria

En los ultimos 30 alios, 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 leona unificada para la evoluci6n del software. lOs detalles de dicho tTa -

bajo superan el enfoque del presente texto, 6 pero las leyes subyacentes derlvadas de su esludio son dignas de deslacarse ILEH97b):
La ley del cambio continuo (1974) . Los sistemas de tipo eleclr6nic0 7 deben adaplarse en forma continua, de 10 contrario se volveran menos satisfactorios a traves del tiempo.
La ley de la compleJldad creclente (1974) . Cuando un sistema de tipo electr6nico esta en evoluci6n, su complejidad se incrementa a menos que se realice el trabajo necesario para mantenerla 0 reducirla.

, ,s

,"''' ... '"

La ley de la autorregulad6n (1974) . El proceso de evo[uci6n de un sistema de tipo eleclr6nico se autorregula con la distribuci6n del producto y las mediciones del proceso cercanas a la normaL

La ley de la consetvad6n de la estabilidad organizacional (1980).

La

tasa

de actividad global efectiva promedio en un sistema de tipo electr6nico en evoluci6n 0 largo del periodo de vida del producto. no varia a 1

La ley de la conservad6n de la familiarldad (1980) . Cuando un sistema de tipo electr6nico esta en evo[uci6n y se quiere tener un desarrollo satisfactorio, lodos los involucrados can el sistema, como los desarrolladores, el personal de ventas y los usuarios, deben mantener el dominic sabre su contenido y comportamiento. EI ered miento excesivo disminuye ese dominio. Por tanio, el credmienlo promedio permaneee sin cambio durante la evoluci6n del sistema.
La ley del crecimlento continuo (1980). EI contenido funclonaJ de los siste-

mas de tipo electr6nlco debe incrementarse en forma continua pa ra mantener la satisfacci6n del usuario a [0 largo del periodo de vida del sistema.
La ley de la caUdad decredente (1996) . La caUdad de los sistemas de tipo electr6nico parecera dec[inar a menos que estos se mantengan y adapten en forma rigurosa de acuerdo can los cambios en su ambiente operacional

Para una clara explkad6n de la evolucl6n del software. elleaor interesado puede revisar {L.EHl)7al texto computacional del mundo real y que, por tanto. evoluclonaran a
trav~5

7 Los sistemas de flpo ekctrOnk:o son programas de software que han sido implementados en un con del tiempo

14

La

ley del sistema de retroalimentad6n 1996) . Los procesos de evoluci6n de

los sistemas de tipo electr6nico constituyen sistemas de retroaUmentaci6n con niveles, cidos y agentes multiples, y deben tratarse de fonna que se obtengan mejorias significativas sobre rualquier base razonable.
I... leyes que Lehman

y sus colegas han definido son una parte inherente de la

realidad de un ingeniero de software. En 1 0 sucesivo, en este texto se discutirtm modelos para el proceso del software, mttodos de ingenieria de software y tecnicas de gesti6n que pretenden mantener la calidad del software mienlras este se encuentra

en evoluci6n.

Los mitos del software --creenclas ace rca del software y de los procesos empleados para construirlo- se pueden rastrear hasta los prlmeros d[as de la computaci6n. Los

mitos lienen ciertos atributos que los convierten en insidiosos. Por ejemplo, los mitos parecen una relaci6n de hechos razonables (algunas veces contienen elementos verdaderos), se observan de manera intuitiva, y con frecuencia los promulgan practicantes experimentados, quienes ~conocen eJ terreno
H

"II . . . . ...,.. ......flb, 1111 indllSOllllM UIIllO II softwart . ....... las

7 '

En la actualidad, la mayoria de los profesionales reconocidos en 1a ingenierfa del software identifican los mitos en su real dimensi6n: actitudes equivocadas que han causado problemas serios a los administradores y a1 personal tecnico por igual. Sin embargo, las antiguas actitudes y viejos Mbitos son ditkiles de modificar, por 10 que aun subsisten creencias falsas sobre el sonware.

--

Mlt05 de la a drnlnlstra d6n , Los administradores con responsabilidades sobre el sonware, al igual que sus pares en la mayorla de las disciplinas, a menudo estan bajo presi6n por mantener los presupuestos, evitar que los itinerarios se extiendan y
D"""UIII~y

*SfIIIIoI_lkIio.

lIpadmrtlt.

- ..-.

mejorar la calidad. De la misma forma que una persona a punta de ahogarse se aferra a un tronco, can frecuencia el administrador del software se arena a un mito si siente que esta creencia reducira la presi6n (aun en forma temporal). MIto:

Yo se dene un Jibro IJeno de esrandores y procedimientos para 10 cons

trucd6n de software. iBio propordanaro a mi genie coda el canocimienta neccsario?

Realldad : Tal vez sea verdad que ellibrc de estandares existe, perc ~se usa? ~Los encargados de la construcci6n del software saben de su existencia? ,Ellibro refleja la practica modema de la ingenierla del software? ,Esta completo? ,Es adaptable? ,Esta dirigido al mejoramiento del tiem-

15

po de entrega sin dejar de enfocarse en la calidad? En muchas casos

Ja respuesta a todas estas preguntas es no.

Mito:
Si se estd otrosado en cJ itinerano es posible concracar mds programadores para as! lenninar a tiempo (algunos veces lIamado eI conceplo de fa

hordo mongolo).
ReaHdad: EI desarrollo de software no es un proceso mecAnico como [a manufactura. En palabras de Brooks (BR07S): HAgregar gente a un proyecto de software atrasado 1 0 a[rasa mas". De inleio, este enunciado po-.

dna parecer contrario a Ja intuici6n. Sin embargo, cuando se agregan nuevos integrantes a un equipo la gente que ya estaba trabajando debe invertir tiempo en la ensenanza a los rech~n lIegados, 10 cual reduce el tiempo dedicado al esfuerzo para el desarrollo productiv~. Sc puede agregar gente, pero 5610 de una manera planeada y bien coordinada,

Mito:

Sf decido 5ubcontmtar eI proyecro de sojhNare a un tercero, puedo relajanne y dejar que esa compania 10 construya.

ReaUdad: 5i una organizaci6n no entiende c6mo administrar y controlar internamente los proyectos de software, de manera invariable entrara en conflicto al subcontratar esle tipo de proyeclos.

...... lrutlt'

.......... ...
CDI*IlIr,

. ...

. - s no IS JJMi

-1iIIIIIs. PfIO fIfI"

."srSIIJIII,/III" _ 'SII fifsgo /PI Sf

,..en

Mltos del cUente. E[ c[iente que so[icita un software de computadora puede ser [a persona del escritorio de a[ lado, un grupo tecnico en el plso de abajo, el departamento de ventas a de mercadolecnia, 0 una compania exl ema que ha solicitado el software bajo contralo. En muchos casos, el cliente cree en mitos acerca del software porque los profesionales y administradores del software hacen muy poco para corregir la desinformaci6n. Los milos conducen a expeclalivas falsas (del clientej y en definitiva a insalisfacci6n con el desarrollador.

MIto:

Un enunciado general de los objetivos es sufidente para comenzar a escribir progmmas; los detaUes se pueden afinar desputs.

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 iterativaj se desarrollan s610 mediante la comunicaci6n continua y efectiva entre eJ cliente y el desarrollador.

Mito:

Los requerimientos del prayecw cambian de manera continua, pero el cambia puede ajusrarse con !aciJidad porque eJ sojhNare es flexible.

Realidad: Es verdad que los requerimientos del software cambian, pero el impacta del cambia varia de acuerdo con el momento en que este se introduce. Cuando los cambios en los requerimientos se solicitan en

16

CAPinn.o I

SOf'T\I{ARE E INGENlERlA DEL SOFTWARE

etapas tempranas (antes de iniciar con el disefio 0 el c6digo), el impacta en el costo es relativamente pequeno.' Sin embargo, conforrne pasa el tiempo, eJ impacto en el costo crece con rapidez -se han distribuido [os recursos, se ha establecido un marco general para eJ diseflo- y el cambia puede provocar una convulsi6n que requiera recur50S adicionales y una modificaci6n significativa en el disei'io.

Mitos del desarroUador. los mitos que aun subsislen entre los desarrolladores del software han permanecido a traves de 50 anos de cultura de programaci6n. Durante los primeros alios del software, la programaci6n era vista como una forma de arte; por ello, las viejas fonnas y actitudes son dificiles de eliminar. Mito:
Una vez que eJ programa ha sido escrito y puesto a jimcionar; eJ trabajo esta terminado.

Realidad: Alguien dijo alguna vez que entre mas rapido se comience a escribir
Siem{n ~ Sf (lien~ 00 Ir7y Iiefr90 pall lJ iIgeiioi1 dol
Sf

c6digo, mas tiempo pasara para que el programa este terminado. Los datos de la industria indican que entre 60 y 80 por dento de todo el esfuerzo aplicado en el software se realizara despues de que el sistema haya sido entregado al cliente por primera vez.
Mito:
Mientras eJ programa no se est~ ej~u/(Jndo, no existe Jonna de eva/uar su caUdad.

sohwutt, Sf debe coosidtta si hot.6

1IIAIM1.

..... "'" I.".. IDdo de

Realidad: Uno de los mecanismos mas efectivos para el aseguramiento de la ealidad del software se puede apliear desde el inicio de un proyeclO: la revisi6n tecniea formal. Las revisiones al software (descritas en el capitulo 26) son un ufillro de caUdad" que han probado ser mas efectivas que las pruebas para encontrar ciertas clases de errores en el software.

Mito:

El unico producro dellrobajo que puede entregarse pam tener un proyec(0 exitoso es eJ programa en juncionamiento.

Realidad: Un programa en funcionamiento es s610 una parte de la configuraci6n del software que [ncluye muchos elementos. La documentaci6n proporciona un fundamento para [a ingenieria exitosa y, aun mas importante, representa una gu[a para el mantenimiento del software. Wto:

La ingenierfa del so.fi'Nare obJigard a emprender /a creaci6n de una documentaci6n va/uminosa e innecesaria y de manera invariable tomara mas lenlo e/ proceso.

Realldad: La ingenieria del software no se retiere a la elaboraci6n de documenlos. Esta relacianada can la creaci6n de calidad. Una mejor calidad

8 Muchos ingenieros de softwa~ han adoplado un enfoque ~agil que adapla los cambios en rorma Incremental, con 10 que 5e conlroia su Impacto y COSIO. Los mtlodos agiles se exponen en el capi.
tulo <I

17

conduce a 1a reduccl6n de los trabajos redundantes. Y una menor cantidad de trabajos redundantes resulta en menores tiempos de entrega.

Muchos profesionales de los sistemas reconc>cen la falada de los mitos del soll.ware. Por el contrario, las actitudes y los metodos habituales conducen a adoptar malas practicas administrativas y tecnicas, a pesar de que 1a realidad exige un mejor enfoque. El reconocimiento de las realidades del soll.ware es el primer paso hacia la formulaci6n de soluciones practicas para la ingenieria del sonware.

Cualquier proyecto de software se inicia por alguna necesidad de negocios: la nece-

sidad de corregir un defecto en una aplicaci6n existente; el imperativo de adaptar un

sistema heredado a un ambiente de negocios cambiante; el requerimiento de exten der las funciones y caractensticas de una aplicad6n existente; 0 la necesidad de crear un producto, servido 0 sistema nuevos. Con frecuenda, en el inicio de un proyecto de ingenierla del software la necesidad de negocios se expresa de manera informal durante una simple conversaci6n. En el recuadro que esta abajo se presenta una conversaci6n tlpica. Con excepci6n de una referenda pasajera, el software no se mencion6 durante la conversaci6n. Aun as!. el software hara la diferencla en el futuro de la linea de productos HogarSeguro. EI mercado aceptara el produclo 5610 si el software incrustado en el satisface de manera apropiada las necesidades del cliente (que aun no ha side definido). En los capltulos subsecuentes se dan~ seguimiento a la ingenierla del soft ware en HogarSeguro.

LaI_,.
po . . . .

'I

~-

__ M!"':'~:'::::;::=;

9 El proyecio HogalSqiuro se usara a 10 largo de este lexlo para ilustrar los Irabajos mtemos de un equlpo de proyecto, mientras I!!ste CQIlstruyc un producto de software. La compania, el proyccto y las personas son flcticios, perc las situaciones y los problemas son reales

18

cAPinn.o 1

SOFrWARE E INGI:NIERiA

DEl.

SOFrWARE

.....
~ 5r

.... (Ii.... .'171 Jr lidad

cIt.-a __ ....

... .... ._11 ....."

a ......
~ Joe: ..........

.... o .... grN

"""

Oil. cit nwsIro

_"PC,,",
, ...... lMo.
~. podno

... ........,.

do ... _

......

"30rAO

E1 software se ha convertido en el elemento clave de la evoluci6n de los sistemas y productos basados en computadoras, as! como en una de las tecnologfas mas importanles en el ambito mundia!. En los pasados 50 anos, el software ha evolucionado des-

de ser una herramienta para la soluci6n de problemas especializados y el antdisis de informa ci6n, hasta convertirse en una industria par sl mismo. Todavia se lienen problemas aJ desarrollar software de alta caUdad a tiempo y dentro del presupuesto. EI sofiware -program as, datos y documentos- se dirige a un amplio espectro de tecnologias y areas de aplicad6n. En \a actuaiidad el software evoluciona de acuerdo con
un canjunlo de Jeyes que han permanecido inalteradas a 10 largo de 30 arios. La intenci6n de la ingenieria del software es proporcionar un marco general para construir software con una calidad mucho mayor.

REflllMCIAS

reR0751 Brooks, F., The MythicaJ Man-Month, Addison-wesley, 1995 [DACOJI Daconta, M., L Obrst y K. Smith, The Semantic Web, Wiley, 2003. IDAY991 Dayani-Fard. H. et aI. , - Legacy Sofiware systems, Issues, Progress, and Challenges", IBM Technical Report TR-74 165-k, abril de 1999, disponible en http, llww...... cas.ibm.com/ loronto/publicaliOns/"TR-74.165/k1legacyhlml IDEM9510eMarco, T., W1!Y Does sojtware Cast SO Much:>, Dorset House, 1995 IFEl83lFeigenbaum, E. A. Y P. McCorduck, The Fifth Generation, Addison-Wesley, 1983. IHAM93] Hammer, M y J Champy, Reeingmnng the Corporaaon, Harpercoilins Publishers, 1993.

cAPiTuLo 1

SOFTWARE INGENlRlA r:u SOFTWARE

.9

UOHO I] Johnson, S., Emeryence: The Connected uves 0/Ants, Brains, Cities and SOftware, Scrib ner, 2001. [KAR99] Karlson, E y J. Kolber, A Basic Introduction to Y2K: How Iheyear 2(}()() Computer Crisis Affts YOU, Next Era Publications, Inc, 1999 ]LEH97aj Lehman, M y L Belady, Program Evolution.' Processes o/SOftware change, Academic Press, 1997. ]LEH97b] Lehman, M et a/ , -Metrics and Laws of Sofiware Evolution-The Nineties View", en Proceedings a/the 4/h In/ernational software Metrics Symposium (METRICS '97). IEEE, 1997, puede descargarse de hltp://www,ece.utexas,edu/-peny/work/papers/feastl.pdf. [LEV95J Levy,S, "The Luddites Are Back~, en Ne\'llSWeCk, 12 de julio de 1995, p. 55. [UP02j Lippman, A, "Round 2.0", en Con/ext Magazine, agoslo de 2002, http://www.contextmag.com/. [UU98] Liu, K. et al., "Report on the First SEBPC Workshop on Legacy Systems, Durham University, febrero de 1998, disponible en http;//www.dur.ac.uk/CSM/SABAllegacywkspl / report.htm!. [05B79J Osborne, A . Running Wild-The Next Industrial Revolution, OSborne/McGraw-Hili. 1979. [NAI82J Naisbitt, J., Megatrends, Warner Books, 1982. [5T089] Stoll, C., The Cuckoo's E88, Doubleday, 1989. [TOF80]Toffier, A., The Third Wave. Morrow Publishers, 1980. {TOF90] Toffier, A PrJwershijl, Bantam Publishers. 1990 {WIL.D2j Williams. S. "A Unified Theory of Software Evolution", en salon.com, 2002. http://WWW. salon,com/tech/featurel2002/04/08/lehman/index.html. [W0l02] Wolfram,S., A Nav Kind a/SCience. Wolfram Media, Inc , 2002 IYOU921 Yourdon, E., The Declme and foil ofthe Ametlcan Programmer, Yourdon Press, 1992 IYOU%] Yourdon, E., The Rise and Resurrecfion o/fhe American Programmer, Yourdon Press,

1996
[YQU98a] Yourdon, E. y J. Yourdon, TIme Bomb 2000, Prentice-Hall, 1998. [YOU98bj Yourdon, E. DtxIth March Projects, Prentice-Hall, 1999. [YOU02] Yourdon, E., ~te War.s, Prentice-Hall, 2002.

1. 1. Encontrar al menos cinco ejemplos adiclonales de la manera en que la ley de las consecuencias imprevistas se aplica al software de computadora. 1.2. Encontrar algunos ejempJos (positivos y negativos) que indiquen eJ impacto del software en la sociedad aClual Revisar una de las referencias anteriores a 1990 en la secci6n 1 I, e mdicar las predicciones del aulor que resultaron correcias. asl como las Que rueron errOneas 1.3. Desarrollar sus propias respuestas a las preguntas formuladas en la secciOn 1 I Debtltanse con los companeros de clase. t .4. definiciOn de sofiware que se presenta en la secciOn 12 se aplica a los sitios Web? 5i la respuesta es afinnatlva, lndicar la suti! dlferencia entre un sitio Web y el software convencianal 1.5. Muchas aplicaclones modemas camblan frecuentemente (antes de presentarlas al usuario final y despu~s de que se empieza a uliUzar la primera versi6n). Sugi~ranse algunas formas de conslruir sofiware para detener el deterioro debido al cambia. 1.6 . Considerense las siete categorfas presentadas en la seccl6n 1.3. "Es posible aplicar el mismo enfoque de la ingenieria del software a cada una de ellas? Explicar la respuesta 1.7. Seleccianar alguna de los nuevos retos mencionados en la secciOn 1.3 (a algun desaflo aun mas nuevo que pudiera haber surgldo desde la impresiOn de este textol y escriblr un documento de una cuartilla que describa la tecnologla y los retos que representa para los ingenieros de software.

,La

20

1.8. Descnbir con palabras propias 10 1(:)' de 10 conservaciOn de 10 esflJbilidad organiZiJcional (secdOn 1.4 .21
1.9 . DeseribiT con palabras propias /0 It;y de /0 COn5ClWci6n de 10!amiliaridad (secci6n 1.4.2,).

1. 10. Describir con palabras propias Ia It;y de Ia ca/idod decrecieJ1te (secci6n 14.2.).

1. 11 . "medida que la presencia del software se vuelve mas generalizada, los riesgos al publi.
co (debido a las fallas en los programas) representan una preocupaci6n signincativa y creclen -

teo DesarroHar un escenario catastr6fico realista en el que 13 falla de un programa de cempuladora podrla producir un gran dane (ya sea econ6mico 0 humane),

1. 12. Exam[nar con atenci6n 31 grupo de noticias de Internet comp.risk y preparar un resu men de los riesgos al pu.blico que se han discuUdo recientemente. Fuente alternativa: Software Engineering No~ publicada por la ACM,

Existen miles de libros que tratan sabre el software de computadora. La inmensa mayoria discute los lenguajes de programaci6n 0 las aplicaciones del software, pero muy pocos tratan del software en 51 mismo. Pressman y Herron (Software Shock, Dorset House, 1991) presenlan uno de los primeros debates (dirigidos aJ publico en general) del software y de la forma en que los profesionales 10 construyen. Ellibro mas vendido de Negroponte (Being Digital, Alfred A. Knopf, Inc., 1995) ofrece una vlsi6n de la computaci6n y su impacto global en el siglo XXI. DeMarco IDEM95J ha escrito una colecci6n de ensayos divertidos y profundos acerca del software y del proceso a traves del cual este se desarrolla. Lns libros de Norman (The InvisJbk Computer, MIT Press, 1998) y Bergman (Infonnation Appliances and Ikyond, Academic Press/Morgan Kaufmann, 2000) sugieren que el impacto extendido de las PC dismlnuira conforme los inslIumentos de informaci6n y \a computaci6n omnipresen te conecten a lodos en el mundo industriallzado y casi cualquier H aparatoHque se posea este conectado a una nueva infraestruClura de Internet. Minasl (The Software Conspiracy: WIo/ Software Companies Put OUt Foulty Products. How They can Hun You, and What You can Do, McGraW-Hili, 2000) argumentaba que la Hplaga moderna H de las impurezas del software se puede eliminar y sugiere fonnas de iogrario. Compaine (Digital Divide: Facing a Crisis or Creating a Myth, MIT Press, 2001) escribe que la "brechaM entre aquelIos que tienen acceso a los recursos de informad6n (como la web) y los que no 10 tienen se esta reduciendo confonne avanza la primera decada del presente siglo. En Internet existe una amplia variedad de Fuentes de informaci6n sobre t6picos relacionados con el software y su administraci6n. Asimlsmo, en nuestro sltio web se puede enconlrar una UsIa actuaUzada de recursos en la red que son relevantes para el estudio del software:

http://_

,mhhe.com/ pre55man.

10 La secci6n Otrasleclurasy jue:nfe:s de inJorrnoci6n que se presenta allinal de cada capitulo ofrece un breve panorama de las fuentes impresas que pueden ayudar1e a aumentar su comprensi6n de los lemu prindpales presentados en eSle capitulo. Hemoscreado un sitio de internet muy extenso para apoyar /ngenictia del S<ljfware:: un e:n/oque pnfctico en http://www.mhhe.com/pressman. Entre los mudlOS t6picos illCluldos se encuentran referencias capitulo por capitulo sobre ingenieria del software exlstentes en II ~ que complementan del material presentado en cada capitulo. Con estas referencias se proporciona un enlace con Amazon,com para locaUzar los libros que se menclonan en cada seccl6n.

EL PROCESO DEL SOFTWARE

n esta parte de Ingcnierfa del software: un enJOque practico se para la practica de la ingenieria del software. En los capitu-

estudiara eJ proceso que proporciona un marco de trabajo

los sigUientes se responden estas preguntas: iQUe es un proceso de software?

<..Cuales son las actividades del marco general presentes en tod05 los procesos del software?
.i. C6mo se modelan los procesos y cuales son los patrones del

proceso?

iCuales son los modelos de proceso prescnptivo y cuales son sus fortalezas y debilidades?
iCu~les son las caracteristicas de los modelos incrementales que los haeen id6neos para los proyectos modemos de soft-

ware?

iQUe es eJ proceso unificado?

,Por que la "agilJdad" es un lema en el trabajo de la ingenierfa

modema del software?
iQUe es el desarrollo agiJ del software y c6mo difiere de los modelos de proceso mas tradicionales?

Cuando se respondan estas preguntas se estara mejor preparado para entender el contexto en el cual se aplica Ja practica de la mgenieria del software.

21

CAPiTULO

EL PROCESO: UNA VISION GENERAL

CONCEPTOS

CLAVE

. HI!,,"oc", ...36
IMCM 29

tM1Io1Jadu ...........2t

n un fascinante hbro que ofrece la visi6n de un economista sobre el software y la ingenierfa del software, Howard Baetjer. Jr. IBAE98) comenta 50bre el proceso del software:

lie twfft ... 21

ISO 9001: 2000 .38

tit! ""Ise .....24

..... trakfe

""-

Debido a que eJ software, como cualquier capital, es conocimiento materializado, y dado que el conodmiento en un inicio es disperso, tacltO, latenle y en gran medida incomplete, el desarrollo del software es un proceso de aprendizaje social, EI proceso es un dla;logo en el cual el conocimiento que el software debe convert!r ~ conJunta y se materiaUza en esle Ultimo. El proceso proporclona Interaccl6n entre los usuarios y las herramientas en evoluci6n, y entre 10$ dise/1adores y sus herramientas [tecnolog!aJ Es un p~so iterativo en el que la herramlenta en evoJucl6n sirve como un medlo para la comunicaci6n, en el roa! cada nueva etapa del diaJogQ Jogra obte~ ner mas conocimiento uti! de las personas impUcadas

"'".tH .... .34 !'Sf ..........40

De hecho, la construcd6n del software de computadora es un proceso iterativo de aprendizaje. y el resultado, alga que Baetjer lIamaria ~el capital del software", es una malerializaci6n del conocimiento recolectado, depurado y organizado conforme el proceso estuvo en ejecuci6n

........

PSI' ..........39

.. "..,. 42:

.QuO . .1 Cuando ..

trnboja panI construir un producto 0 sistema_ porlonle seguir uno wje d. potOIS pre-

,-_Ioo-,E.doooIo, ~_que
a . ' ..... ~ po-a tI'I Sistema

deables: uno &specie de mapa de OCt-

~.

adap. del soItwore que 58 esl6 cons-

rreMro$ que ayude a creer \.WI , . . . miIntiaI que \.WI Pf'CX*O distinto par ~ serio de alta colidad yo tiempo. EI mapad. ........a. .......... pcwa Ia Cf1ICJCi6n de un sitio Web. que debe ~uirMl MI tIoma ~ de ~. ,Cu6I .... prallucto obteniclo? Desde el lQuien 10 hoc.? los ingeniercs de soItwa.w punto 0. vWo del u'geniero de wHware, los y SUS tefes odoplan eI proceso a !.US~ ~ obt.ntdot son 10$ programas, docudespues 10 siSuerJ. Aciem6s, 1a gente que ho y datos que .. producen como (oose" licitodo el software liene uno nmo6n qW ""~"' de lot odividode, y tareas definida, sempenar en el proceso de defimlo. COMtrvIrlo y pmbado , - . . . . . . _ . . . - d e q... 10 he LPor que .$ importante? Porque ob.ce ..... Existen muchos meeabilidod, control y orgonizoci6n 0 UfMI ocom.lod .~ doI_ de soItwo.. q... que puede voIverMl coOtieo SI no .. conRIa '!"'~~ Q 1m organ 'zociones determiner Ie "maembargo, un enfoqve de ingenieno cW soItww. doI_ de - . . No ob....Ie, 10 modemo debe MIl' "6gil". Debe ,..,.., oI"""""...,."ndo, 10 viobilidod 0 10"" aquella! octividodes contl'oMs y doc:un....... ~-doI: ...,.Mto quo .. con..",.. "'" 10. mojo'"'' ~ porn eI oqu;po doI_ ~ "'Iea"",.. de Ia eficocio del proceso que 58 producto que ho de producirse

lM_ puedo .... ~ porn de Oeronoutica,

.... _.w.,,,,?

.-

22

CAPiTuLo 2 EL PROCESO UNA VISION GENERAL

23

Pera, (que es can exactitud un proceso de software desde un punta de vista tecnico? Dentra del contexto de este libra, un proceso de software se define como un marco de trabajo para las tareas que se requieren en la construcd6n de software de alta calidad. lEI proceso es un sin6nimo de ingenieria del software? La respuesta es Sl y no. Un proceso de software define el enfoque que se adopta mientras el software esta en desarrollo. Pero la ingenieria del software tambien abarca las tecnologlas que requiere el proceso (metodos tecnicos y herramientas automatizadas) . Aun mas importante es que la ingenieria del software la realizan personas creativas y can 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 dentos de autores han definido en forma individualla ingenieria del software, la definid6n que propuso Fritz Bauer INAU691 en una conferencia fundamental sobre la materia aun se puede utilizar como base para el debate:
[La ingenierfa del software esl el establecimiento y uso de principios s6lidos de la ingenie-

rfa para obtener econ6micamente un software conflable y que fundone de modo eficiente en maquinas reales.

casi cualquier lector se sentira tentado a sumar otras ideas a esta definici6n. Dice paco sobre los aspectos tecnicos de \a caUdad del software; no se refiere de manera directa a la necesidad de satisfacer aJ cJiente 0 aJ tiempo de entrega de un producto; amite mendonar la importancia de la medici6n y la metrica; no establece [a importancia de un proceso efectivo. No obstante, la definici6n de Bauer ofrece una idea basica. (Cuales son ulos principios s6lidos de la ingen ieria ~ que pueden aplicarse en e\ desarrollo del software de computadora? (De que manera se construye "econ6micamente" un software "confiable"? (Que se requiere para crear programas de computadora que funcionen ~de manera eficiente" no s610 en una, sino en varias "maquinas reales" diferentes? Estas interrogantes continuan siendo un reto para los ingenieros de software .
....._

. ...-'

~ LII

cuerpo de (onocimiento, Ia ingenilria 8'S un verbo, IIIICI paIaDta de . ., _ _

EI IEEE [lEE93J ha elaborado una definici6n mas comprensible al establecer:

Ingen!erla del software: \) La aplicac16n de un en foque sistematico, dlsclpllnado y cuanti flcable al desarrollo, operaci6n y mantenimiento del software; es decir, la aplicaci6n de ta

--

1rI-'twor.?

Ingenierfa al software. 2) El estUdlO de enfoques como en I).

Y aun asI, 1 0 que es ~sistematjco, disciplinado" y "cuantificable" para un equipo de software, puede ser gravoso para otro. Se requiere de disciplina, perc tambien de adaptabilidad y agilidad.

2.

PARTE UNO n PROCESO DEl. SOf'TWARE

Estratos de Ia Ingenleria de
software.

La ingenierla del software es una tecnologfa estratiflcada. Como se muestra en Ja

ligura 2.1, cualquier enfoque de la ingenierfa (incJuido el de la ingenieria del software) debe estar sustentado en un compromise con la caUdad. La Gesti6n de la CaUdad Total, Sigma Sels y enfoques similares fomentan una cultura de mejora continua del
~

~~

proceso, y es esta cultura Ja que al final conduce aJ desarrollo de enfoques muy efee-

-.

............
to_dO

C&VE

tivos para la ingenieria del software. La base que soporta la ingenieria del software es un enfoque en 10 calidad. La base de la Ingenierfa del software es el estrato del proceso. EI proceso de la ingenierfa del software es el elemento que mantiene juntos los estratos de la tecnolosla y que permite el desarrollo radonal y a tiempo del software de compuladora. EI proceso define un marco de trabajo IPAU93j que debe eSlablecerse para 1a entrega efectiva de Ja tecnologfa de la ingenierla del software. EI proceso del software forma la base para el control de la gesti6n de los proyectos de software y establece el contexto en eI cual se aplican los metodos tecnicos, se generan los productos del trabajO (modelos, documentos, datos, reportes, fonnatos, etcetera). se establecen los fundamentos, se asegura la caUdad, y el cam bio se maneja de manera apropiada. Los metodos de 1a ingenieria del software proporcionan los "c6mo" tecnicos para construir software. Los metodos abarcan un amplio espectro de tareas que incluyen la comunicaci6n, el analisis de requisitos, el modelado del diseno, la construcd6n del programa, la realizaci6n de pruebas yel soporte. Los metodos de la ingenieria del software se basan en un conjunto de principlos basicos que gobleman cada area de la teenologla e incluye actividades de model ado y otras tecnicas descriptivas.

IIIXeso, miIodos y

Las herramienftJs de la ingenieria del software proporcionan el soporte automatizado 0 semiautomatizado para el proceso y los metodos. Cuando las herramientas se integran de forma que la informaci6n que cree una de elias pueda usarla otra, se dice que se ha establecido un sistema para el soporte del desarrollo del software, que con freeuencia se denomina ingenierfa deJsojtware asistida por compuladora.
o
'f~'

,'0,

Un marco de rrabajo establece Ja base para un proceso de software completo aJ identificar un numero pequeno de actividades del marco de trabajo aplicables a todos los proyectos de software, sin importar su tamana 0 comp lejidad. Ademas, el marco de
rrabajo del proceso abarca un conjunto de activldades sombrilJa aplicables a 10 largo

des proceso del software.

cAPiTuLo 2

Il. moctSO: UNA

~N GENERAL

25

Un maroa de

Proceso del software Marco de trobajo del proceso Actividodes sombrillo

AClividod del morco de troboio # 1
occi6n de 10 ing8flieria de software 111 .1 _ . d.I"obojo producto. d-' Irobojo Conjunto punlos de o~vromienlo de lareos 0.10 colictod
~d.~

dllsoftwme.

....-

trabajo del

occi6n de 10 iogenierio de sohwore III _ . d.! lfoboio prodldoo del Irobopo Conjunlo delar80s

.10:.

pumoo 0. o"Y""""_

do """'"

~d.p"~

I
Adividod del morco de troboio #n
occi6n de 10 ingenierla del software #n. l Conjunto
lOtIO. d.llfobopo podudoo dill II'obop puntoo d. o-eufOl"lelllo 0.1a coIidod M1~ 0.1 proyoedo

de Ioreos

occi6n de 10 inge:nierio de sohware IIn.m

_ .w Irabojo

Conjvnto de toreos

produoos d.llrObojo

de Ia colidod

................ ,...-

po,IMoII de o~ ......1Q

Como se muestra en la figura 2.2. cada actividad dentro del marco contiene un conjunto de acdones de ingenierla del software; es decir, una serle de lareas relacionadas que produce un produclo del trabajo en la ingenierla del software (por ejemplo, el diseno es una acct6n de la ingenierla del software) . cada acci6n la forman (areas de /Tabajo individuales que campletan alguna parte del trabaja implicada por la acci6n .

...,... . . . . . . . hociendo qui.. NOndo y cOmo Iograrrierta 1IIIfa." I,. JooM... Gqjy _ , _ "

26
EI siguiente marco de trabajo generico del proceso (utilizado como base para la descripci6n de los modelos de proceso en los capitulos subsecuentes) se puede apli-

..... ..<e."....
, CHIn
",_oW

car en la inmensa mayoria de los proyectos de software:

ComunicaciOn. Esta actividad del marco de trabajo implica una intensa colaboraci6n y comunicaci6n con los clientes; 1 adem.1s, abarca la investigaci6n de requisitos y otras actividades relacionadas . Planeacl6n. Esla actividad establece un plan para el trabajo de la ingenieria del software. Describe las tareas tecnicas que deben realizarse, los riesgos probables, los recursos que seran requeridos, los proouctos del trabajo que han de producirse y un programa de trabajo. Modelado. Esta actividad abarca la creaci6n de modeJos que permiten a\ desarrollactor y al cliente entender mejor los requisitos del software y el diseno que lograra satisfacerlos. Construcci6n. Esta actividad combina la generaciOn del cOdigo (ya sea manual o automatizado) y la realizaci6n de pruebas necesarias para descubrir errores en el cOdigo. oespUegue. E.l software (como una entidad completa 0 un incremento completado de manera parcial) se entrega al cliente, qulen evalua el producto recibido y proporciona infonnaci6n basada en su evaluaci6n. Estas cinco actividades genericas del marco de trabajo son utiles durante el desarrollo de programas pequenos, la creaci6n de grandes aplicaciones en la red, y en la ingenieria de sistemas basados en computadoras grandes y complejas. Los detalles del proceso del software seran muy diferentes en cada caso, pero las actividades dentro del marco permaneceran iguales.

-'"

del prMtJO

Fn4_
Si se usa un ejemplo derivado del marco de trabajo generico del proceso, la actividad de elaboraci6n del modelo la componen dos acciones de la ingenieria del software: analisis y disefio. El analisis 2 abarca un conjunto de tareas de trabajo (por ejemplo. la investigaciOn, elaboraci6n, negociaci6n, especificaci6n y validaci6n de requisitos) que conducen a la creaci6n del modelo de analisls (0 a la especificaci6n de re-

Un ,limIt: es cualquier peT50na que Uene un interes en eI exilo del resultado del proyecto: gerentes de negociOS. usuanos finales, gente de apoyo, etcetera Rob Thomset bromea diciendo que ~un clknte (en Ingles smkdloldel') es una persona que soshene una estaca (stoke! grande y afiJada si no cuidas a tus clientes, ya sabes d6nde lenninara la estaca~ 2 EI analisis se explicari con mayor delenimiento en los capllulos 7 Y8

27

-.....-s.blQS.
",~_do

quisitos) . EI diseflo abarca tareas de tTabaja (diseno de datos, diseflo arquitect6nico, diseflo de interfaz y diseno al nivel de componentes) que crean un modele de diseno (una especificaci6n de diseiiO) ..) Como tambil~:n se aprecia en la figura 2.2, cada acci6n de la ingenierla del software [a representa un gran numero de direrentes conjunlos de lareas: una serie de tareas de tTabaja, productos relacionados, puntas para el aseguramiento de la calidad

ff>. C&VE

I_cit .....

_anbese., ........ yenlos _dol

y fundamentos de proyecto dentro de la ingenieria del sonware. EI conjunto de lareas que mejor se ajuste a las necesidades del proyecto y a las caracteristicas del equipo es el que se escoge a1 final. Esto implica que una acci6n de la ingenieria del software (como el disei'lo) se puede adaptar a las necesidades espedlicas del proyecto de software y a las caracteristicas del equipo de proyecto.

Con/unto de tareas
Un coniunlo cJ.loreas define eI trabajo real que debe realizorse pore cumplir los objetivos de uno occi6n de ingeniMla del softwgre. Pelf" ejemplo, la -reccpiloci6n de requilibs- as uno occi6n imporlOnle de 10 ~ierio del softwore que OC\Irre duronle Ia octividod de -.nicoc:i6n. 1.0 meto de 10 reuni6n de requilitos as .-.nder que desean los diltinbs di.,t.s del softwore que YO 0 conslNir.

3. Elaboror uno lisla preliminor de los funciones y corocieristicol basoOo' en 10 infom..oci6n que ofrezcon los dientes. 4. Hoeer un progremo de reuniones poro recopilar los reqvilitos.

5. Conducir leu reuniones.

6. Producir esc;enori05 informoles de los UIUOOos como porte de codo reuni6n .
7. Rennor esc;enorios de los usuorios con bene en eI inlercombio de infonnoci6n con los dienles.

!'oro uti pt"oyec:to pequeno, 01 po....-limple, eI GIrIjUOItl de Ioreos poro 10 recopiloci6n de requilitos p...de ser como M .,umero a continuoci6n:

8. Elobotor uno listo revisodo de 10, requilitos de los

dientes. 9. Utitizor t6cnicos de desptiegue de funciooes de colidod pore jerorquizor los requisitos.
10. ErnpoqueIor los requisitos pore que puedon entregone de monero inaemenlol.
I 1. Observor

Hocer uno li$lo de los dientes pore eI pro)"I'do.

2. InYikK 0 lodes los dienles 0 uno reuni6n informol.
3 "-:iir 0 coda diente que hogo uno lisb de cofoderliticos y funciones rwqueridcls.

EmbIecer un debale sobre los requi,itol Y eIobomr

uno tim fil"lOl. 5 Priorizor los requisite. 6 A.cMrtir los 6reas de incertidumbre.
fIaro uti proyeclo de softwtJre mayor y rOO, complejo, :Ie OWfArirla un conjunlo diferente de toreos. ~'Ie puede ..duir 10 siguienle tisla:

los re,lriccionel que -On puestos en eI

sistema.
12. Debotir metoda, pore VClJioor eI sistema.

1 Hoc.,.. uno lista de los dienles pore eI pro)"I'do.

2. Entrevhtor 0 coda uno de los dientes, por seporodo, para detrerminor de mooero generolsus deseos y

Ambos conjunlos de toreas conliguen 10 recopiloci6n de requisites, perc son muy dilerenles en cuonta 0 profundidod y formolidod. EI equipo de software eBge eI conjunto de toreal que permitira okonzor Ia meta de coda octividod del proceso y occiOn de ingeoierlo del software que monteogo 10 colidod y ogitidod.

.-.idado..
.} cabe aclararque "\a elaboraci6n del modelo~ debe inlerpretarse de un mododJrerentecucmdo se realiza el manlenimiento de un soRware eXJStente En algunos casos OC\lrre el mcxlelado del dlSei'lo yel anal isIS, peru en otras situaciolYS de mantenimiento se Ie utiliza para ayudar a enlender el software heredado. a\ igual que para representar adlciones 0 modiflcadones en bte

28

PARTE UNO

EL PROClSJ DL SOfTWARE

El marco de trabaja descrito en la visi6n general de la ingenierla de software 10 completa una serle de actividades S()mbrlllo. Las actividades Upicas en esta categorla induyen:

'~

C~VE

!.as II(IMdades sonDio oa.mn a 10

seguimlento y control del proyecto de software: permite que el equipo de software evalue el progreso comparandolo con el plan del proyecto y asi tamar las aceiones necesarias para manlener el programa.

Gesti6n de l rlesgo: evalua los riesgos que pudieran afectar los resultados del
proyecto 0 la calidad del producto.

.." dO I"""'" ~ sohwore ySol enfOUll

.. """"' ..... M

Aseguramiento d e la caUdad del software: define y conduce las actividades

10 QISIi6n, eI mstreo y
eI(llIl~deI~.

requeridas para asegurar la calidad del software.

Revisiones t~cnicas (annales: evalua los productos del trabaja de la ingenieria del software en un esfuerzo encaminado a descubrir y eliminar los errores antes de que estos se propaguen hacia la siguiente acci6n 0 actividad .
Medici6n: define y recolecta mediciones del proceso, el proyecto y el producto para ayudar al equipo a entregar software que satis(aga las necesidades del cliente; se puede usar en conjunto con todas las otras actividades del marco de trabajo 0 actividades sombrilla. Gesti6n de la configuraci6n del software: maneja los efeclos del cambio a traves del proceso del software . Gesti6n de la reutillzad6n: define los criterios para la reutilizaci6n de produclos del trabajo (se incluyen componentes del software) y establece mecanismos para la creaci6n de componentes reutilizables. Preparad6n y producd6n 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 capitulos posteriores de esle texlo. Todos los modelos de proceso se caracterizan denlro del marco del proceso mostrado en la figura 2.2. La aplicaci6n inteHgente de cualquler modelo de proceso del software debe reconocer que la adaptaci6n (al problema, proyeclo, equipo y a la eultura organizacional) es esencial para el exilo de esta actividad. Pero los modelos de proceso difieren de manera fundamental en: El Oujo global de aclividades y tareas, y las interdependencias entre las actividades y las tareas.

&~

''rf>.

to_dO

C~VE
es

......

j)'O(8S0 de sohwtre

".""", del p-oyecto.

_ . ,.. _.HI
-"'"

,De ..
Ii?

El grado en el euallas tareas de trabajo estan definidas dentro de eada actividad del marco de trabajo. El grade en el eual se identifican y se solicitan los productos de trabajo. La forma en [a que se ap[iean las actividades de aseguramiento de la calidad .
La manera en la que se aplican las actividades de seguimiento y control.

prO(lSO tIIttl

29

El grado general de detalle y el rigor con el que se describe el proceso. El grado en el que los clienles esta.n comprometidos con el proyecto. El grado de autonomla otorgado al equipo de proyecto de software.

I ..- .... ", ,.,.,.,. un_ .

.,.;;;~
que

El grado en el cual estim definidos la organizad6n y las responsabilidades en el equipo.

01.... .... ... ... '" . .. :::..~ ,

Los modelos de proceso que enfatizan Ja definici6n, Ja identificaci6n y la aplicaci6n detal!ada de las activldades del proceso han sido aplicados dentro de la comunidad

de la ingenieria del software en los ultimos 30 arias. La aplicaci6n de estos mode/os

presaiptivos inlenta mejorar la calidad del sistema, hacer que los proyeclos sean mas manejables, que las fechas de entrega y los costas sean mas predecibles, y guiar a los equipos de ingenieros de software mientras realizan ellrabajo que requiere conslruir un sislema. Por desgracia, ha habido ocasiones en que estos objetivos no se han a\canzado. Si los modelos prescriptivos se aplican en forma dogmatica y sin ni nguna adaptaci6n, estos pueden incrementar el grado de burocracia asociada con la construcci6n de sistemas basados en computadoras, y de manera inadvertida crear dificultades para los desarrolladores y los clientes. En ai'los recientes se han propuesto modelos de proceso que subrayan la agilidad del proyecto y siguen un conjunto de principios ,~ [as cuales conducen a un enfoque mas informal para el proceso del software (dicho enfoque no es menos efectivo, segtin argumentan quienes 10 propusieron). Estos mode/os agi/es del proccso resaltan la manejabilidad y adaptabilidad. Son apropiados para muchos tipos de proyectos y son titiles de manera particular cuando se desarrollan aplicaciones en la red . ,Cual de los enfoques para el proceso del software es el mejor? Esla pregunta ha ocasionado un debate emocional entre los ingenieros de software y se abordara en el capitula 4. Por ahora, es importante darse cuenta de que estos dos enfoques de proceso tienen una meta comun: crear software de alta calidad que satisfaga las necesidades del clienle, pero tienen perspectivas diferentes.

EI Instituto de Ingenierla del Software (SEI, por sus siglas en ingles) 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. 1 SEI sosliene que para lagrar estas capacidades una organizaci6n debe crear un modelo de proceso (figura 2.2) que se ajuste a las directrices establecidas por la integraci6n del modelo de capaddad de madurez (lMCM) [CMM02].
4
Los modclos agUes y

los prim::iplOS que los gutan se ~xphcan en ~I capItulo 4

30

PARTE UNO

EI. PRCX::eiO DEL SOFTWARE

PerW de capo.

cIdad del "'"" del procetIO de lalMCM [PHl02].

........... : """" :tt".:l: ,.,.

~.,.-,-

GO

y 0f06I;0;,
....

'- _

a6Iacj

dol ~ y 01 pA><8O<>

-o
-

I I

IN<.

.... .........
GC

N:J'P

<>11'01

La lMCM representa un modele completo de proceso en dos fonnas diferentes: I )

como un modelo continuo y 2)como un modele discreto. E1 modele continuo IMCM describe un proceso en dos dimensiones, como se ilustra en la figura 2.3. cada area del proceso (por ejemplo, la planeaci6n del proyecto 0 1a gesti6n de los requisitos)

se evalua de manera fannal contra las metas y practicas espedficas y se clasifica de

acuerdo con los siguientes niveJes de capacidad:

Nlvel 0: Incompleto. EI area del proceso (por ejemplo, la gesti6n de requisitos)

aun no se reaJiza 0 lodavia no alcanza todas las rnetas y objetivos definldos para el nivel I de capacidad. Nivel I: Realizado. Todas las metas especificas del area del proceso (como las defini6 Ja IMCM) han sida satisfechas. Las tareas de trabaja requeridas para pradu~ cir el praducta especUica han side realizadas. Nivel 2: Administrado. Todos los criterios del nivel I han sido satisfechas. Ademas, todo ellrabajo asociado con el area de proceso se ajusta a una politica organizacional definida; tada la gente que ejecuta eJ trabaja liene acceso a recursos adecuados para realizar su labor; los c1ientes estan implicados de manera acliva en el area de proceso, cuanda esta se requiere; tadas las tareas de trabajo y praductos estan "monitoreadas, contralados y revisadas; y son evaluadas en apego a la descripci6n del proceso" [CMM02]. Nivel 3 : Dennido. Todos los crilerios del nivel 2 se han cumplido. Ademas, el proceso esta "adaptado al conjunlo de procesos estandar de la organizaci6n, de acuerdo con las polftlcas de adaptaci6n de esta misma, y contribuye a Ja informaci6n de los praductos del trabaja, mediciones y atras mejorlas del proceso para los activas del proceso organizacianaJ" [CMM02\. Nivel 4 : Administrado en forma cuantitativa. Tados los crilerios del nivel 3 han side cumpJidos. Ademas, el area del proceso se conlrola y mejora mediante mediciones y evaluaci6n cuan titativa. "Los objelivos cuantitalivos para la calidad y el

3J

desempeno del proceso estan establecidos y se utilizan como un criterio para administrar el procesou ICMM02]. Ni vel 5 : Mejorado. Todos los criterios del nlvel 4 han side satisfechos. Ademas, el area del proceso Use adapta y mejora mediante el uso de medios cuantitativos (estadlsticos) para conocer las necesidades cambiantes del cliente y mejorar de manera continua la eficacia del area del proceso que se esta considerando" rCMM02].

~.RKtS.

_ ..... .... ,~

....... 1AICAl
5,

.-.....

I
'"

....... """..... --- ........

-

"criJi;t.I ...... ts~, mmo cuanda 00 dio: "Prefi.n, ... Wi ..... . . .

t:.....
~

La IMCM define cada Area del proceso en runci6n de "metas especificas" y de las

-.

"practicas especlficas" requeridas para a1canzar dichas metas. Las metas especljicas establecen las caracterlsticas que deben existir para que las actividades implicadas por un area de proceso sean efectivas. Las prdclicos e5JXXlficas convierten una meta en un conjunto de actividades relacionadas con el proceso . Por ejemplo, la planead6n del proyecto es una de las acho areas del praceso definidas por la IMCM para la categoria de "gesti6n del proyecto".5 Las metas espec!ficas (ME) y las practicas especlficas asociadas (PE) que se han definido para la pianeaci6n del proyecto son rCMM02] : ME 1 Establecer estimadones PE 1.1-1 Estimar el alcance del proyecto. PE 1.2- \ Establecer estimaciones para los atributos del producto y [as tareas del trabajo. PE 1.3- 1 Definir el cicio de vida del proyecto. PE lA - I Determinar estimaciones de esruerzo y costa. ME 2 DesarroUar un plan de proyect o 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 gesli6n de los datos. PE 2.4-\ planear los recursos del proyecto. PE 2.5-1 Planear los conocimientos y habiJidades que se requieren. PE 2.6-1 Pianear ia participaci6n del cliente. PE 2.7-1 Establecer e! plan de proyecto.

Jz::D1 cis

"",_del

5 atras areas del proceso definidas como "gesti6n del proyecto~ incluyen monitoreo y control del pro yecto, gesU6n de acuerdos con proveedores. gesti6n Integrada del proyecto para IPPD, gestion del riesgo, integraciOn del equipo, gesti6n de integraci6n del proveedor y gesti6n cuantitatlva del pro

>,0

32

PARTE UNO EL PII(X:ISO 00. SOFTWARE

ME 3 Comprometerse con la planead6n

PE 3. 1- 1 Revisar los planes que afectan el proyecto. PE 3.2-1 Conciliar el tTabaja y los niveles de recursos. PE 3.3-1 Comprometerse con la planeaci6n Ademas de las metas y pnkticas espedficas, 1a IMCM lambicn define una serie de cinco metas genericas y practicas relacionadas con cada area del proceso. cada una de las metas genericas corresponde a uno de los cinco niveles de capacidad. Por 10

tanto, para lograr un nivel de capacidad particula r se debe alcanzar la meta generi ca para ese nivel y las pnkticas genericas que corresponden a esa meta . Para ilustrar 10 anterior, a continuaci6n se enumeran las metas genericas (MG) y las practicas genericas (PG) para el area del proceso de pianead6n del proyecto [CMM02]:
MG I Alcanzar las metas especificas
PC 1.1 ReaHzar practicas base.

MG 2 Institudonalizar un proceso de gesti6n

PG 2.1 Establecer una polltica organizacional. PG 2.2 Planear et proceso. PG 2.3 Proporcionar recursos. PG 2.4 Asignar responsabilidades. PG 2.5 Capacitar gente. PG 2.6 Manejar configuraciones. PG 2.7 Identificar y hacer participar a clientes. PG 2.8 Monitorear y con trolar et proceso. PC 2.9 Evatuar la adherencia de un modo objetivo. PG 2. 10 Revisar el estatus con un alto grado de gesti6n.

MG 3 Institudonalizar un proceso deHnldo

PG 3.1 Establecer un proceso definido. PG 3.2 Recolectar inform aci6n de la mejoria .

MG " Institudonalizar un proceso manejado en lonna cuantitativa

PC 4. \ Establecer objetivos cuantitativos para el proceso. PG 4.2 EstabiJizar el desempeno del subproceso.

MG 5 Institucionallzar un proceso de meJoramlento.

PG 5. \ Asegurar la mejora continua del proceso. PG 5.2 COITegir las causas de los problemas desde la raiz El modelo discreto de la IMCM define las mismas areas. metas y practicas del proceso que el modelo continuo. La principal diferencia es que el modele discrete establece cinco niveles de madurez, en vez de cinco niveles de capacidad. Para lograr un nivel de madurez se deben conseguir metas y practicas especificas relaci onadas can un conjunto de areas del proceso. La relaci6n entre los niveles de madurez y las areas del proceso se muestran en la figura 24.

CAPh'uLo 2

.El1'ROCEK>:

UNA VlSi6N GENERAL

33

La IMCM: c.se debe 0 no hacer?

I,.g

IMCM ft Ufl modeIo Iotal del proceso. Defi-

mos grondes y compIe;os que impliqven docenos 0 cienlos de personas par vorios meses 0 enos. Es ~bIe que 10

ne (en olrededor de 700 plIgil1O$) len corode..-.:cs del ptOCeilO que deben exi~r si uno organizcx:i6n ~ aIobIecer- un proatilO de ~re~. I,.g PI'" . . . , que ,. he debotido cl.onn. uno d6codo e$ ,10 IMCM

IMCM sea corredo en cienos sitvociones, ~ 10 C\llturo argo-nimcionol es llexible hrl.. 0 ~ de proceso$ est6odores y Joe reolizo uno gesti6n poro lagror que sea un ~iIo. No omlonM, en oIros ~lucKiones 3$ ~bIe que 10 IMCM seo demosiodo poro que uno Of"9C'nizcx:i6n 10 osimile de monero 8Jlitoso. 6Ello significo que 10 IMCM es molo 0 demosiodo burocr6tico 0 que est6 posodo de mo' do, No. Ton s6Io signinco q .... 10 corredo pora Ia culturo de uno cornpoiiia puede no serlo paro oIro. I,.g IMCM es un lagro signincotivo por~ 10 ingeniefio del software. Proporciono una expo$iciOn inlegrol de las odividocIes Yocciones que deben estor presentes cvondo uno orgonizoci6n conslruye un software de computodora. Aun $i uno orgonizoci6n de software elige no odoptor sus detolies, todo eqvipo de iIOftware debe retomor su espirilu y aprender de sv exposici6n del pnx:eso y 10 pr6dica de 10 ingeniet-io del software.

- ...r.o9 Como 10 ITIO)'Or por1IJ de kn coms en 10 vida (y _ .. .oitwore) 10 ~ no es un ~mpIe si 0 no. Sempr. debe odoptone eI espritu de 10 IMCM. Fren\le fA nesgo de 10 simp!incoci6n excesivo, Joe orgumento que eI del software debe lomone con :5eI"iedod: debe pIIanecnI; debe conlrolorse de monero uniforme; debe ........--se con precisi6n; debe cooducirw de monero pro1.ionaI. o.be centrorse en los necesidodes de los dientes . . ptO)'8dO, los hobilidocles de los ingenieros de software Flo coIidod del producIo terminodo. Nodie debe poner en .a.Io estes ideos. 1.05 r.qui~1o$ detollodos de 10 IMCM deben Iomane en con ,.,.iedod si uno Of"9Onizcx:i6n constrvye ~sle-

_.010

--do --.
_dol

.....
De optimi_don o.stionodo de modo CUClnritativo

WI,_
conti_del
GestiOn

...... """""""

. ....Idas

pnx.-

--

......

..-des~iegue

InnovactOn argoni~ol y AnGli ..s Iu_1 Y ......udQn

cUGnlila'i",

EjMlICiOn . . procelO orgonisocional GesriOn cuontitativa cIeI proyedo

DeSCllrrol~ de ,-.quisitos SoIlICton "nka IntegrociOn del pt"Oducto Yerificodon YaliclaciOn Enfoque del proc:esa organlzocianal DefinicIOn del proc:esa organizacional CapacihJciOn OIlIanizacional G.s'iOn integrada del proyedo G.sPiOn Integrada del proveedor G."iOn del riesga AniIlisls Y "'SC11luciOn de lei dec ision Ambiente organisodonol para Ia Integrac:ion Equipa inr.grodo

Defjnido

fShJndorisociOn
del pnxe~

a.s~

Goes';';" Msko del "....

....

GestiOn de requ isitos Pki_iOn del proyec:to Monitor.a Y contTol del proyedo GesfiOn de ocuwdos del proveedof MediciOn yanoli.i "-Iuromiento de ~ calidad del produc:to Y del proceso GesriOn de Ia config_1On

E;.c:utodo

34

PARTE UNO

Il. m:;:c:DO 00. SOFTWARE

El proceso de software puede definirse como una colecd6n de patrones que definen un conjunto de actividades, acciones, tareas de trabaja
0

comportamientos relacio-

nados IAMB98] que requiere el desarrollo de un software de computadora. Dicho en terminos generales, un patron de proceso ofrece una planWla: un metoda consistente para describir una caracterfstica importante del proceso de software. Mediante la

combinaci6n de patrones, un equipo de software puede construir un proceso que satisfag3 10 mejor posible las necesldades de un proyecto.
_,~""""do_

Los patrones pueden definirse en cualquier grado de abstracci6n.' En algunos ca50S se puede utilizar un patron para describir un proceso complete (por ejemplo, un prototipo). En alras situaciones se utilizan los patrones para describir una actividad del marco de trabajo importante (como la planeaci6n) a una tarea dentro de una actividad del marco de trabajo (por ejemplo, la estimaci6n de un proyecto) . Ambler [AMB98J propuso la siguiente plantilla para describir un patr6n de proceso:

on.llII""
~lepolO

~ ~L""AVE u..,....doI,...,

Hombre del patron . Al patr6n se Ie asigna un nombre significativo que describa su funci6n dentro del software (como comurucad6n con eI cUente).

Prop6sito. Se describe can brevedad el objetivo del patr6n . Por ejemplo, el objetivo de la comunJcad6n con el cHente es ~establecer una relaci6n de colaboracl6n
con el c1iente en un esruerzo encaminado a definir el alcance del proyecto, los requisitos del negocio y otras condiciones del proyecto". EI prop6sito puede expandirse con textos explicatorios adicionales y diagramas apropiados. si se requieren.

desatWLIIP3'OO.

npo. Se especifica el tipo de patron. Ambler IAMB981 sugiere tres tipos:

Los patrones de torm definen una accl6n de la ingenierta del software 0
una tarea de trabajo que es parte del proceso y relevante para una prcktica exitosa de la ingenierta del software (por ejemplo, la recopilaci6n de requisilO$ es un patr6n de tarea).

Los patroncs de escenario definen una aclividad del marco de trabajo para el proceso. Debido a que una actividad del marco de trabajo reline multiples tareas de trabajo, un patr6n de escenario incarpora multiples patrones de tarea relevantes para el escenario (actividad del marco de trabaja).
Un ejempla del patron de escenario es la comunicad6n. Este patron incorporaria el patr6n de tarea reuni6n de requisilos y alTOS.

-6

Los patrones se aplican a muchas actividades de ingenierfa del software. El anAlisis. el dlsel'lo y los patrones de prueba !it: explican en los capltulos 1. 9. 10. 12 Y 14. 1o6 patrones y "antipatrones" para las actividades de gestiOn de proyectos se explican en la parte" de este libro.

35
Los patrones de lase definen la secuencia de actividades del marco de trabaja que ocurre junto con el proceso, aun cuando el flujo general de actividades es iterativo por naturaleza. Un e}emplo de un patron de puede

rase

ser un modelo en esplral

de construcdon de prototipos.1

Contexto inidal. Se describen las condiciones en las cuales se aplica el patron. Antes de iniciar este se debe cuestionar I ) que actividades organizadonales 0 relativas al equipo han ocurrido, 2) cual es el estado de entrada para el proceso, Y 3) que infonnaci6n de ingenierfa del software 0 informaci6n del proyecto ya existe. Por ejemplo, el patron de planead6n (un patron discreto) requiere que 1) los ciientes y los ingenieros de software hayan establecido una colaboraci6n en cuanto a comunicaci6n; 2) se haya completado con exilo un gran numero de patrones de tarea (especificados) para el patr6n de comunlcad6n con eJ cHente:; y 3) se conozcan los alcances del proyecto, los requisitos Mskos del negoc:io y las restricdones del proyecto. Problema. Se describe el problema que debe resolver el patr6n. Por ejemplo, e1 problema que debe resolver Ia comunkadlm con eI cHc:ntc: puede describirse de la sigulente manera : 1i1 comunic0d6n entre eJ desarrolladory d dienfc muchas veces es

inodecuodo poTtJue no se estobfece un formata efectivo para obtcner infonnad6n, no se

crea un meconismo litH para regislrarlo, y no se realiza una revisi6n significativa.
SOlud6n. Se describe la implementad6n del patr6n. En esta secci6n se discute c6mo el estado inidal del proceso (existente antes de que se haya implementado el patron) se modifica como consecuenda del inido del patron. Tambien se describe c6mo la informad6n de la ingenieria del software 0 1a informaci6n del proyecto, disponible antes de inkiado el patron, se transforma como consecuencia de la ejecuci6n exitosa del patr6n. COntexto resultante. Se describen las condiciones que habra una vez que el patr6n haya sido implementado con exilo. Para completar el patr6n deben realizarse las siguientes preguntas: I) t:que actividades organizacionales 0 relacionadas con el equipo debieron haber ocurridO?, 2) t:cual es el estado de salida para el proceso?, y 3) t:que informad6n de la ingenieria del sonware 0 informad6n del proyecto ha side desarrollada? Patrones re1adonados. Se propordona una U sta de too05 los patrones de proceso directamente relacionados con tste, en forma jerarquica a de alguna otra forma. Por ejemplo, el patr6n estadonario de comunJcad6n abarca los patrones de tarea reunJ6n del equJpo para eI proyc:cto, definjd6n de una linea de colaborad6n, aislamlento de: alcances, reuni6n de requisitos, descrlpd6n de: restricdones y una cread6n de un modelo mini-spec.

7 Estos patrones de fase se exponen en eJ capitulo 3.

36

PARTE UNO 11. PRCX::!3:) DEl. SOF1WAR

Usos conoddos/ EJemplos. se indican los ejemplos especlficos en los cuales el patrbn es aplicable. Por ejemplo, \a comunlcad6n es obligatoria at principia de cada proyecto de software; se recomienda por media del proceso de software, y es obligatoria una vez que la actividad de despUegue est~ realizada. Los patrones de proceso propordonan un mecanismo efectivo para describir

"" ..... _/,.._s

!os PIltrooes 6i
_w~.

cualquier proceso de software. Los patrones pennilen una organizaci6n de ingenieria del software para desarrollar un descripci6n del proceso jenirquico que comience en un alto grado de abstracci6n (un patr6n de fase). La descripci6n se retina hasta un canjunlo de patrones eslacionarios que describen actividades del marco de Ira baja, y mas tarde se retina de un modo jerarquico en patrones de tareas mas deta~ lIados para cada patr6n estacionario. Despues de que se han desarrollado los patrones de proceso, pueden reutilizarse para la definici6n de varianles de proceso; es decir, un equipo de software puede definir un modelo de proceso persona1izado usando patrones como bloques de construcci6n para el modelo de proceso .

.............Q

EjempJo de un patr6n. del proceso

de 5Oftwore. los elienles no IROn iegUf"O$ de 10 que de sean; .s decir, no pueden describir ningun delolle de los requisik)s del 5Oftwore. SoIucion. Aqui 58 presenkl uno descripci6n del proce50 de pro6olipo. Pore m6s cIetoIIes ..ease eI capitulo 3. Contexto resultant.. lot. d .....1M aprueban un prokIIipo de ~re que idenli~ca requisilos oosicos (por

~ EI siguienle patrOn de procl50 obreYiodo describe un enloque aplicable cuonOo los clientes lienen uno ideo general de 10 que debe hocene, pera no est6n segUt'Ol de los requisilos especificos del ~re.

Nom"'" del patrOn. Protoripo.

Propbsito. EI objelivo del potr6n 8$ con$hvir un modeIo (un prorotipo) que los dienles evclUen de modo ilef"olivo en un esfven.o encaminodo a idenli~car los requisilos del !rOitwore. Tipo. Patr6n de fa$e. Contexto iniciol. Deben cumplirse los liguienles coneli ciooes antes de iniciar 8$1e polr6n 1) los dienles hon sido idenli~codos; 2) $e he estoblecido un modo de comunicoci6n .... tre los dienles y eI equipo de Irobajo; 3) los dienles han tdenlificoda eI problema que he de resoIverse; 4) $e he de!rOrroilodo un entendimienlo inicial del olcance del proyeclo, los requisitos bOsicos del negocio y las reslricciones del proyecto. Problema. Los requisilos s.on YOgO$ 0 no exislen. No OOstonle, $e reconoce con doridod 10 existenc.ia de un problema, y !hie debe ir acomponodo de uno toIud6n

ejemplo, modeIos de interocci6n, rosgos compvtocionoles, funciones de prote$(lmiento). Despve$ 1) eI prototipo puede tyOludonor recorriendo uno $erie de incremento$ port! COflvertir$e en eI software de producci6n, 0 2) eI protoIipo sa des.corto y el software de pro' ducci6n 58 conslruye con otros potrones de prott$(). Poh'ones relacionodos. los siguienles patrones est6n re/ocionodos con este potr6n: comunicadon con el diente; diseno iterativo; desarrollo iterotivo; evoluacion del c1iente; extraccion de requisitos. Uso. conocidos/ejemplos. EI prototipo 58 recomiendo cvondo k requisilos son inseguros

2,5

EYALUACr6H

pEL 'RQCESQ

La exisiencia de un proceso de software no es garantia de que este sera entregado

a tiempo, de que salisrara las necesidades del cliente, 0 de que mostrara las caracteristicas tecnicas que conduciran a caracteristicas de caUdad a largo plazo (capitulo 26). Los patrones de proceso deben ir acompanados de una practica s6lida de [a

37

Es ...ominodo po<

!den"OCO oopociOOdes y riesgos de

IvoluaciOn ct.1
proceso de software

Condvce a
proceJ.O d. fOtt-o ...

Mejoramiento del

1-----,,-,,---------1
MoIivo

Dftenninacion
dot Ia capacidad

,..,

ingenierfa del software (parte 2 de este libra). Ademas, el proceso mismo debe evaluarse para asegurarse de que cumpla una serie de cri terios basicos del proceso que

~~

C{hVE
.1.....10000 58

han demostrado ser esenciales para una ingenieda de software exitosa. 8 La relaci6n entre el proceso de software y los metodos aplicados para la evaluaci6n y el mejoramlento se muestra en la figura 2.5. Se han propuesto vatios enfoques para la
~a

.......

. . . comprendet

. _ ""'" dO iJIIIB cit sdtvo, y

luaci6n del proceso de software en las decadas pasadas:

El metoda de evaluacl6n d e 1a IMCM estandar para e l mejoramiento del
pl"Oc eso (MEIEMP)ofrece un modele de cinco pasos para la evaluaci6n del proceso que incluye la iniciaci6n, el diagn6stico, el establecimiento, la acci6n y el aprendizaje. EI metodo ME1EMP utiliza el SEI IMCM (5ecci6n 2.3) como base para Ja evaluad6n [SElOO) .
La apredacl6 n basada en el CMM para el mejoramiento d el p roceso in-

-.

L..... tiolkas

~ ,..

. . . . . . p'lKtH

terno (ABC MPI) ofrece una t~cnica de diagn6stico para evaluar la madurez relativa de una organizaci6n de software mediante la ABC MPI (un precursor de [a lMCM, el cual se explic6 en la secci6n 2.3) como base para la evaluad6n [DUNO l J EI estandar SPICE (ISOJ IEClSS04) define un conjunto de requisitos para 10. evaluad6n del proceso de software; 10 que pretende es ayudar a las organizadones en el desarrollo de una evaluaci6n objetiva de la eficacia de cualquier proceso de software definido [SPI99]. EJ ISO 900 1 :2000 para so ftware es un estandar generico que se aplica a cualquier organizaci6n que desee mejorar 1a calidad general de los productos, sistemas
8

.ttw ?

La lMCM del SEI1CMM02] describe. en detalle y con amphtud, las caracterist icas de un proceso de
sonware y los criterios para un proceso exitoso

PARTE UNO

Q.PRCJCE!',OonsonwAllE
est~nda r

o servicios que provee. Por 1 0 tanto, el i1ias y organizaciones de software.

se aplica de modo direclo a compa-

Debido a que el ISO 900 I :2000 se usa de manera amplia en el ambito intemacional,
se examinara con brevedad en los parrafos que slguen .

La Organizaci6n Intemacional de Eslandarizaci6n (ISO, por sus siglas en ingles) ha estableddo el estandar ISO 900 I :2000 1150001 para definir los requisi tos de un sistema de gesti6n de calidad (capitulo 26) que sirva para elaborar produclos de mas alta caUdad y asl mejorar la satisfacci6n del cliente. 9
La estrategia fundamental que sugiere eliSa 9001 :2000 se describe de la slguien-

Ie manera:
EJ ISO 90012000 subraya la importancia que liene para una organizaci6n identlflcar, impie men tar. gestionar y mejorar de manera continua 111 efectividad de los procesos necesarios para el sistema de administraci6n de la caUdad, y geslionar las interacciones de estos
procesos para conseguir los objetivos de la organ[zaci6n.,

..""--.....,11.....
.. 150 9OO1:2(m

-r-

EliSa 900 1:2000 ha adoptado un cicio de H planear-haceHevisar-actuar" que se aplica a 105 elementos de gesti6n de caUdad 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 caUdad y una satisfacci6n del cliente; "hacer" implementa el proceso de software (incluidas las actividades del marco de trabajo y las actividades sombril1a); Hrevisar" monitorea y mide el proceso para asegurarse de que lodos los requisitos establecidos para la gestl6n de calidad hayan side cumplidos; Hactuar" inicia las actividades de mejoramienlo del proceso de software, el cual tiene una continuidad de trabajo para mejorar el proceso. Para un tralamiento mas detallado del ISO 900 I :2000 los lectores interesados en el tema deben consultar 105 estandares ISO 0 [CIAOIJ, [KETOl] 0 [MONOIj.

EI mejor proceso de software es el que esta cerca de la gente que realizara el tTabaja. Si un modele de proceso de software ha sido desarrol1ado en un ambito corporativo u organizacional, puede ser efectivo s610 si es en gran medida adaptable para satisfacer las necesidades del equipo del proyecto, que es el que en realidad Ileva a cabo el trabajo de ingenieria del software. En un escenario ideal, cada ingeniero de software crearla un proceso que Ilene 10 mejor posible sus propias necesidades, y al mis9 El aseguramlento de 13 calidad del soflware (ACS1, un elemento importante de la gest!6n de calidad. ha sido definido como una actividad sombnlla que se apllca 3 trav~s de todo el marco de lrabaio del proceso. 5e expone en detalJe en el capitulo 26

CAPiTuLo 2 EL PROCESO: UNA VISI6N GENERAL

39

I ..._ ...........
,U ']!i5M
2.6.1

mo tiempo satisfaga las amplias necesidades del equipo y la organizaci6n. De modo alternativo, el equipo mismo crearia su propio proceso, y al mismo tiempo cubrirla las necesidades mas reducidas de los individuas y las necesidades amplias de la or~ ganizaci6n. Watts Humphrey ([HUM97J y IHUMOOJj argumenta que es posible crear un "proceso de software personal" 0 un "proceso de software en equipo" Ambos re~ quieren de un arduo trabajo, capacitad6n y coordinaci6n, pero ambos se pueden conseguir. IO
y

ho"modo. h6bO, de 1>0<

., ,... ",I.

~ ~""~;;..';:'"

Proceso de software personal (PSP)

Cada desarrollador utiliza algun proceso para construir un software de computado~ ra. EI proceso puede ser fortuito 0 ad hoc, puede cambiar a diario, puede no ser efi~ dente, efectivo a hasta exitoso. pera existe un proceso. Watts Humphrey IHUM97j sugiere que para cambiar un proceso personal inefectiva, un individuo debe pasar por cuatro rases. en las cuales se requiere capacitaci6n e instrumentaci6n
cuidada~

sa, EI pTOCt:SO de software personal (PSP) resalta la medida personal del producta de trabaja que se produce y la calidad resultante del producto de lrabaja. Ademas. el PSP responsabiliza al profesional encargado de la planead6n del proyecta (por ejem ~ pia, la estimad6n y la pianificaci6nJ y Ie confiere el poder de controlar la calidad de todos los productos de trabaja del software que se desarrollan. El modelo PSP define cinco actividades del marco de tTabaja: planeaci6n, disei'lo de alto nivel, revisi6n del disei'lo de alto nivel, desarrollo y analisis de resultados. Planead6n. Esta actividad selecciona requisitos y, con base en estos, desarrolla el tamano y la estimaci6n de los recursos. Ademas, se estiman los defectos (el mero de defectos proyectado en el tTabajo). Todas las medidones se registran en
nu ~ ho~

_ ....... .-i Oli ....,..

_oW

.rsn

jas de trabajo 0 en plantillas. AI final. se identifican las tareas de desarrollo y se crea un pragrama del proyecto. otsefio de alto mvel. Se elaboran las especificaciones extemas para que cada componente sea construido y se crea un diseno del componente. Se construyen pro ~ tOlipos cuando existe incertidumbre. Todos los elementos se registran y rastrean Revisi6n del disefio de alto mvel. Los metodos formales de verificaci6n (capitulo 26) se aplican a errores descubiertos en el diseno. Las mediciones se mantienen para todas las tareas importantes y los resultados de trabajo. Desarrollo. EI diseno al nivel de componente se refina y revisa. se genera,
re~

visa, compila y prueba el c6<:ligo. Las mediciones se mantienen para todas las tareas importantes y los resultados de trabajQ.
10 Va le la pena menciOnar que los proponentesdel desarrollo .igll del software (capitulo 4) lambien argumentan que el proceso debe pennanecer cerca del eqUlpo Ellos propanen un m4!todo alternativo para lograrlo

40

PARTE UNO

EL ~ DEL SOfTWARE

AnaJisis de resultados. Mediante las mediciones y medidas recole<:tadas (una

cantidad sustancial de datos debe analizarse de manera estadlstica) se determina la efectividad del proceso. Las mediciones y medidas deben ofrecer una guia para modiflcar el proceso y asl mejorar su efectividad. EI PSP deslaca 1a necesidad que Hene cada ingeniero de software de identificar los errores desde el principia y la importancia de entender los tipos de errares que sue-

,....,

Ie comeler. Esto se lleva a cabo mediante una actividad de evaluaci6n rigurosa aplicada en lodes los produclos de tTabaja que genera el ingeniero de software.
El PSP representa un enfoque disciplinado, basado en medlciones, de 1a ingenie ~ ria de software que puede conducir a un choque de culturas a muchos proresiona ~ les. Sin embargo, cuando el PSP se presenta de un mOOo adecuado a los ingenieros de software [HUM%J, la mejoria resultante en la prOOuctividad de la ingenieria del software y [a calidad de este son significativas IFER971 . No obstante, la industria no ha adoptado con amplitud el PSP. Las razones, tristemente, tienen mas relaci6n con la naturaleza humana y la inercia organizacional que can las fuerus y debilidades del enfoque del PSP. Este ultimo es un reto intelectual y demanda un grado de com promise (por parte de los profesionales y sus jefes) que no siempre es posible obte~ ner. La capacitad6n es relativamente larga y sus costas son altos. En 10 cultural. el grado requerido de medici6n es dificiJ para mocha gente Involucrada can el software. Una interrogante es si el PSP puede usarse como un proceso de software efectivo a un nivel personal La respuesta es, sin duda, sl. Pero aun si eJ PSP no es adoptado en su totalidad. vale la pena estudiar muchos de los conceptos de mejora del so que este presenta.
proce~

"'*>-

nPSP des1Q(o 10

C&VE

necesidod De regish'or

""' "" dm;rolor estrotegKIS

~-. .........

yonoizor los ~ de &rIOI8S que se

...

2.6.2 Proceso de software en equtpo (PSE)

-lIt{onsI~o.

-~

IIPSEyelP9_ -..

--.~-. ",IIf/

Debldo a que muchas proyectos de software en el ambito industrial las dirige un equi~ po de profesionales. Walts Humphrey exl endi6 las lecciones aprendidas para la intro~ ducci6n del PSP y propuse un proceso de software en eqUlpo (PSE). La meta del PSE es construir un equipo de proyecto "autOOirigido" que se organice para prOOucir un soft~ ware de alta calidad. Humphrey \HUM98J define los siguientes objetivos del PSE: Construir equipos aUIOOirigidos que planeen y tengan un seguimiento de su tTabajo. establezcan metas y posean sus procesos y planes. Estos grupos pueden ser equipos de software puros 0 equipos de producto integrado (EPt) de.3 a 20 ingenieros. Mostrar a los jefes c6mo preparar y motivar a sus equipos y c6mo ayudar~ los a sostener un alto desempeno. Acelerar el mejoramiento del proceso de software at realizar. con el portamiento normal y esperado, el nivel 5 del MeM.
com~

Ofrecer una guia de mejoramiento a oTganizadones de alta madurez.

cAPiTuLo 2

E1 PROCESQ. UNA

VISIl'I GENI!AL

41

..... -wo .....-,dlbec.

.~

.... _
..

Facilitar la enseiianza universitaria de habilidades de equipo industrial de calidad . Un equipo autodirigido entiende en forma consistente sus metas y objetivos generales. Define funclones y responsabilidades para cada uno de sus miembros; registra datos cuantitalivos del proyecto (como productividad y calidad); identifica un praceso de equipo apropiado para el proyecto y una estrategia para implementar el proceso; define estandares locales aplicables a1 tTabajo de ingenierla de software del equipo, evalua en cada momenta riesgos y reacciones; y registra, gesliana y reporta el estatus del proyecto.

-, ....... ""

I
""PI(

~~ jugadores IS ftKil HDtItl" que juegIItn en ~ IS CItra historia:

C~VE
.. ...,y _dol
_dol

El PSE define las siguientes actividades del marco de tTabajo: !anzamiento, diseno de alto nivel, implementaci6n, integraci6n y prueba, y analisis de resultados. Al igual que sus contrapartes en el PSP (n6tese que la tenninalogia es diferente), estas activiclades permlten al equipo planear, di.senar y construir un software de una manera disciplinada al mismo liempo que miden de modo cuantitativo el proceso y el produClo . Los antllisis de resultados muestran el escenario para eJ mejoramiento del proceso EI PSE utiliza una amplia variedad de escritos, formas y estandares que sirven para guiar a los miembros del equipo en su tTabajo. Los escrilos definen actividades especificas del proceso {par ejemplo, lanzamienta, disefto, implementaci6n, integraci6n y prueba, y analisis de resultados del proyectol y otras funciones mas detaltadas del trabajo (como planeaci6n del desarrollo, desarrollo de requisites, gesti6n de la canfiguraci6n de software y prueba de unidad) que son parte del proceso del equipa. Con fin es ilustrativos, es util tamar en cuenta la actividad inicial del proceso: ellan-

zamienta del p~lO . cada proyecto es "Ianzado" con una secuencia de tareas (definida como un escri to) que permite al equipo estab lecer una base s61ida para iniciar eJ proyecto. Se recomienda el siguiente escrilo de lanzamiento (5610 de manera general) IHUMOOI
Revisar los objetivos del proyecto con la gesti6n y acordar y documentar las metas del equipo. Establecer las funcianes del equipo. Definir el proceso de desarrollo del equipo. Elabarar un plan de calidad y plantear los objetivas 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 detal1ados para cada ingeniero en la siguiente fase. Adaptar los planes individuales a un plan de equipo.

PARTE UNO

EL PRCICESO I n SCFJ'WARE

Haeer un balance de la eantidad de traba}o del equipo para obtener un programa minima en terminos generales. Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para cada riesgo clave.

Es importante senalar que la actividad de lanzamiento puede aplicarse antes de cada actividad del marco de trabajo del PSE, el cual se explic6 parrafos atras. 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 aetividades previas. EI 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 medlci6n y el analisis de las medidas recolectadas; ademas, trabajan de manera continua para mejorar el enfoque del equipo respecto de la ingenieria del software. AI igual que el PSP, el PSE es un enfoque riguroso para la ingenieria del software que ofrece beneflcios distintos y cuantiflcables en productividad y calidad. EI equipo debe comprometerse con el proceso y debe recibir capacitaci6n para asegurarse de que el enfoque se aplique de manera apropiada.

'

~""''''''''_P':;

..; H ' ' ' '

""'

'J.

, .

Los modelos genericos de proceso tratados en las secciones precedentes deben

adaptarse para que los utilice un equipo de proyeeto de software. Para lograrlo se han desarrollado hcrramienras de teenolaglo del proceso destinadas a ayudar a las organizaciones de sortware a analizar sus procesos actuales, organizar sus tareas, controlar y monitorear su progreso, y administrar su caUdad teenica [NEG99]. Las herramientas de tecnoiogia del proceso permiten que una organizaci6n de software construya un modele automatizado del marco de trabajo comun del proceso, de los conjuntos de tareas y las actividades sombrilla explicadas en la secci6n 2.2. EI modelo, que a menudo se representa como una red, entonces puede anaJizarse para detenninar el nujo de trabajo Upico y examinar las estructuras de proceso altemativas que podrian conducir a la reducci6n del tiempo 0 costa del desarrollo. Una vez creado un proceso aceptable es posible utilizar otras herramientas de tecnologia del proceso para localizar, monitorear e incluso controlar todas las tareas de ingenierla del software definidas como una parte del modelo del proceso. cada miembro del equipo de software puede emplear dichas herramientas en la elaboraci6n de una lista de verificaci6n de las tareas de trabaJo que se deben desarrollar, los productos del trabajo que es imperativ~ producir, y las actividades para el aseguramiento de la calidad que deben reali zarse. La herramienta de tecnologia del proceso tambien se puede aprovechar para coordinar el uso de otras herramientas de la ingenieria del sonware asistida por computadora que sean apropiadas para una tarea de trabajo particular.

43

. . . OIl. Ito de un pnxe50 de un negocio (0 de un ~

HeJTam1entas de modeJado del proceso

Obfetivo: Si unci orgcnw06n troboio en eI

.... til primer cbjetNo es .'Iei.de.b. Los herromienlas de 100' dO """"" I""""" Romodm Ie<ncicgio dO ~ 0 hetmmientos eM 98Sfi6n del proc:aso) sa utilimn _ ~Ior los eIeo,itMU dcr.e de un proce5O pare . . . . puedo enlendene con mtJ)'Of doridad. Toles herTa _ _ ~ oEr-, vfncuios con descripcionM del pro_ que ayvdon 0 quienes M inlefe5en en eI prnceso a . . . . los gc;c;iQne" y las torecu de Irobojo necesorios pom d.:sorn::.IIano. los I,., romieI,lU$ de modeIoci6n del procesa pqxwcionan vfnwlos con oftJs herromientos que ..... 1OJXlI1e a octividodes definidos del proceso.

Vnico (occlonn, ioreos, productos de Iroboiol. ofrecen uno guto detoIlodo del contenido 0 10 descripci6n de coda olemenlo del proce$O, y de5pves gestiooon eI proc~ mienlras M conduce. En ~ co_los herromienlos de IecnoIogio del proceso incorporon Ioreos de gMti6n del proyedo MlCnOor, como estimoci6n, itinerorio, roslreo y

control.
HetTamtental repntMntativol: 11 IfIrobc Proces, ToM, distriwidas po!" corel Corporotion (_.igrofx.com/products/pnxen), es uno $erie de herramienlos que pennilen 01 equipo orgoni:wr, medir y modeIor.I proceso de software . Objexis Team PortoI, desorroIIado
po!"

Obiexi$ Corporotion

- . nita: los herramieMm de em coIegorio permiten , "",~ d.~";, 10. """'""" do ~ modolo dO """""

(www.objexll.com).propordooolodetinlci6nyelcontrol compIetos del Rujo de trabajo del pnx:etO.

Si el proceso es debit. sin duda el producto final sufrira las conse<:uencias. Asimismo, una confianza excesiva en el proceso es peligrosa. En un breve ensayo Margaret Davis [OAV951 comenta sabre la dualidad del prcxlucto y el proceso:
Alrededor de cada diez anos, a \leces cada cinco, la comunidad del software reddine "el cambiando su enfoque de los aspectos del produCIO a los asuntos del proceso. Entonces se han oblenido lenguajes de programad6n estructurados (produCIO) seguidos por mttodos de analisis estructurado Cproceso) y encapsulaciOn de datos (producto), asl como eI enfasis actual en el Modelo de Madurez de capacidad para el Desarrollo de Software dellnslituto de Ingenierla del SOftware \procesoj tseguid05 por los metodo5 orienta dos a objet05 y el desarrollo agil de softwarel. Mientras la tendencia natural de un pendula es 11egar al reposo en el punto medio entre dos extremos, el objeti\lo de la comunidad del software cambia en forma constanle porque cada vez que una oscilad6n lermina se aplica una nueva fuerza. Estas oscilaciones son nodvas en sl mismas porque confunden al profesianal promedio del software con los cambios radicales en eI significado de hacer ellraba;o 0 dejar que tste se desarrol1e solo. Las asci/adones tampoco resue/ven -el problema-, pueslo que estan destinadas a fa 11ar mientras el produc\o y e / proceso sean tratados como sl formaran una dicotomia en lugar de una dualidad.

problema~

II las henamientas mencionadas &qui represenlan una muestra de esta ca tegor1a En]a mayoria de los casos los nombres son marcas registradas de sus respectivos desarrolladores.

..

PARTE UNO EL PIIOCfSO DEL SOfTWARI!

Existen precedenles en \a comunidad cientlfica haela las nociones de dualidad, cuan-

do las contradicciones en las observaciones no se pueden explicar por completo con una u alra Icoria compelidora. La naturaleza dual de la Juz, 13 cual pareee ser en forma simullanea una partlcula y una onda, ha side aceptada desde la decada de 1920, cuando Louis
de Broglie la propuso Creo que las observaciones posibles sobre \05 artefaclos del software y su desarrollo demuestran una duaUdad fundamental entre et producto y el proc:eso. No se puede l\egar a entender el artefacto completo, su contexto, usa, significado y valor 5i 5610 se ve como un proc:eso 0 unicamente como un produclo .. TOdas las achvidades humanas pueden verse como un proceso, pero cada seT humana tiene un senlldo de aulovaloraci6n de aquellas aclividades que generan una represenlaciOn que puede emplear 0 apreciar mas de una persona, emplear una y otra vez, 0 aprovechar en algirn otro conlexto. Es decir, el ser humano encuentra placer en reutiUzar

sus productos y en que olros los reutilicen.

Por 10 lanto, mientras la rapida asimilaciOn de reutilizar metas en el desarrollo de software aumema de manera polencialla satisfacci6n que expertmentan los profesionales de su lrabajo, lambltn aumenta la urgencia de aceptaci6n de la dualidad del prodUClO y el proceso. COnsiderar un aneraclo reutilizable como 5610 un producto 0 5610 como un proceso oscurece el contexto y las maneras de utili zaria, u oscurcce el hecho de que cada usa resulta en un producto que, a su tiempo, se aprovechara como entrada a alguna oua activldad de desarrollo de software. Poner un punto de vista sabre el otro reduce en forma sustanciallas oportunidades de reuti lizar y. por 10 tanto, pierde la oportunidad de incrementar la satisfacciOn del tTabajo .

.. ..., eI sisIIInD iIIMI, g 51 pudiero obIenIr, _III <Odigo tan fltliWt y. . . . ,.. ,.. ,...... III' ... .... c.t. siIIo06II COII(IiIiWe lIM reglo exDCfo. Pero 10 vida as demasaIo ~ pili . . . . . . ~
_ ..... 01 ........

La gente obtiene tanta (0 mas) satisfacci6n del proceso creativo que del producto final. Un pintor disfruta los trazos del pincel tanto como el resultado del cuadra. Un escritor disfruta la bUsqueda de una metMora apropiada tanto como ellibro terminado. Un profesional del software creativo debe sentir tanta satisfacci6n del proceso como del producto terminado. El tTabajo que realiza la gente de software cambiara en los af\os que siguen. La dualidad del producto y el proceso es un elemento importante para mantener a la gente creativa comprometida mienlras finaliza [a transicion desde la programaci6n hasla la ingenierla del software.

La ingenierla del software es una disciplina que integra al proceso, los metodos y las herramientas para el desarrollo del software de computadora. Se ha propueslo un gran numero de modelos de proceso para la ingenierla del software, pero lodos definen un conjunto de actividades del marco de trabajo, una colecdon de tareas con-

cAPinrLo 2

EL PROCESO UNA VlS!6N GENERAl

45

ducidas para realizar cada actividad, productos de {rabajo generados como consecuencia de las tareas y un conjunto de actlvldades sombri!la que acompal'\an el proceso entero. Los patrones de proceso pueden aprovecharse para definir las caracteristicas del mismo. La Integracl6n del modelo de capacidad de madurez (IMCM) es un modelo total del proceso, que describe las metas, practicas y capacidades espedficas con que debe contar un proceso de software maduro. EI SPICE Y otros estandares definen los requisitos para guiar una evaluad6n del proceso de software, y el estandar ISO 900 1:2000 examina la gesti6n de la caUdad dentro de un proceso.

Se han propuesto los modelos personal y en equipo para el proceso de software. Ambos destacan \a medid6n, la planeaci6n y la autodirecci6n como ingredientes clave para un proceso de software exitoso. Los principios, conceplos y metodos que permiten realizar el proceso lIamado ingenieria del software seran considerados en el resto de este libra.

-"..,
[AMB98\ Ambler, S., Process Patterns: Building wrge-SCa/e systems Using Objtxt Technology, cambridge university Press/SIGS Books, 1998. IBAE98\ Baeljer, Jr., H,. software as capital, IEEE Computer Soclely Press, 1998, p. 85. [CIAOII Cianfrani, C. et ai" ISO 9001:2000 Explained, American society of Quality, 2001 lCMM02j capability, Maturity Mode/Integration (CMMf), Versi6n 1.1, SOftware Engineering Inslitule, marzo de 2002, disponible en http://www.sei.onu.eelu/cmmil. (DAV95J Davis, M., ~Process and Product: Dichotomy or Duality'", en Software Engmeenng Notes, ACM Press, vol. 20, num. 2, abril de 1995, pp, 1718, [DUNOI\Dunaway, D. y S. Masters, CMM-Based Appraisal for Internal Process Improvement (CBA IPI Version 12 Method Description, SOftware Engineering InSlllute, 2001, puede descargarse de http://wwwsei.cmu.edu/ publications/documents/O I.reports/O I tr033 html [ELE98J EI Emam, K., J. Drouin y w. Melo (eels.), SPICE: The Theory and Practice of software Process Improvement and Capability Defennination, IEEE Computer Society Press, 1998 [FER97\ Ferguson, P. et ai, "Results of applying the personal software process, en fEEE Computet; vol 30, num 5, mayo de 1997, pp. 24-31. [HUM%I Humphrey, W., ~ using a Defined and Measuted Personal Software Process, en IEEE Software, vol. 13, num, 3, mayo-junio de 1996, pp. 77-88. [HUM97J Humphrey, W., Introduction to the Personal Software Process, Addison-wesley, 1997 , IHUM981 Humphrey, W , "The Three Dimensions of Process Improvement, Part 111 The Team Process, en Crosstalk, abril de 1998. Disponible en http://www.stsc.hill.afmil/crosstalk/ I 998/apr/ dimensions.asp. [HUMOOJ Humphrey, W., Introduction to the 7hJrn Software Process, Addison-Wesley, 2000. [IEE93\/EE Standards Colltxtion: Software Engineenng, lEE Standard 610.12-1990, IEEE, 1993, IlSOOO] 150 9001.'2000 Documenl Set, International Organization for Standards, 2000, http.// www.iso.ch/iso/en/is09000-14000/ lS090001 9OOOisoindex,html. [ISOOII "Guidance on the Process Approach to Quality Management Systems", Document ISO/TC I 76/SCl/N544R, International Organization for Standards, mayo de 2001 (KETOII Ketola, J. y K. Roberts, ISO 9001.2000 in a Nutshdl, 2a. ed., Palon Press, 2001 IMONDI] Monnich, H.,Jr, y H. Monnich, ISO 9001:2000 for Small-and Medium-Sized Businesses, American Society of Quality, 2001. [NAU691 Naur, P. y B. Randall (eds.), software Engmeering; ... Report on a conference Sponsored by the NATO Sdence COmltlee, NATO, 1%9. [NEG991 Negele, H., "Modeling of Integrated Product Development proceses", Proc, 9th Annual symposium ofINCOSE, Reino Unido, 1999.

PARTE UNO

EL ~ r:El. SCWTWARf:

IPAU9l) Paulk., Metal., Capabi1l~ Malum), Model for software, Software Engineering Institute,
carnegie Mellon University, Pittsburgh, PA, 1993. iPHI02] Phillips, M , ~C MMI VI.! TUtorial abril de 2002, disponible en http://www.sei.cmu.
H ,

edu/cmmil.
[SElOOI SCAMPI, VI.O SlOndard CMMI Asses.smcnf Meflwd jOr Process fmp~men/; Me/hod Descnpdon, SOftware Engineering Insti tute, Technical Report CMU/SEI -20(X)..TR-009.

disponible en http//www.sei.cmuedu/ publicationS/documents/OOreports/OOtr009.html

[SPI991 SPICE: SOftware Process Assessment, Part 1 Concepts and Introduction
H ,

VersiOn . 0.

lSOIlEe JTel. 1999.

2.1. En 1a introducd6n a este capitulo, Baetjer puntualiza: "EI proceso ofrece una interacci6n entre usuarios y disenadores, entre usuarios y herramienlas en evoluc\6n, entre diseftadores y
herramientas en evoluci6n [tccnologlaj". Haganse cinco preguntas respecto a a) 10 que los disefiadores deben preguntar a los usuarios; b) los usuarios deben preguntar a los disefiadores; c) 10 que los usuarios deben preguntarse a s[ mismos sobre el producto de software que se construira; y cf) 10 que los disefiadores deben preguntarse a sl mismos sobre el producto de software que se construira y el proceso que se utilizara para hacerlo. 2.2. En Ja figura 2.1 se coJocan los tres estratos de ingenierla del sofiware arriba de un estrato titulado "un enfoque en la caHdad". Esto impHca un programa de ca!idad de una organizaci6n amplla como gestibn de la calidad total. Realizar una peq~a investlgad6n y desarrollar una gula de los princ:ipios dave de un programa de gesti6n de caUdad total. 2.3. ,Exlste la posibilidad de que las actividades gentricas del proceso de ingenieria del software no se apliquen' SI es asl, descrlbase. 2 .4. Las aClividades sombrilla ocurren a 10 largo de todo el proceso del software. aplican de modo uniforme a Iraves del proceso 0 algunas estan concentradas en una 0 mas acti vidades del marco de trabajo? 2 .5. Oescnbase 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 lodos los proyectos, SIO importar el tamano y complejidad? Expllquese la respuesta. 2.6. Intente establecer un conjunlo de lareas para la actividad de comunJcaci6n. 2.7. lnvestigar un poco mas acerca de la IMCM y dlscutir las ventajas delos de la IMCM continuo y discreto.

,5e

y desventajas de los mo-

2.8. Desplegar la documentaci6n de Ja IMCM del sltio de la red del SEI y selecdonar un area del proceso que no sea la planeaci6n del proyecto. Hacer una lista de las metas especlficas (ME) y de las practicas espedficas (PE) asociadas que se definan mediante eJ area que se haya elegido. 2.9. Considerar la actividad de comunicaci6n dentro del marco de trabajo. Desarrol!ar un patr6n completo del proceso (podrla ser un patr6n discreto) aprovechando los principios descrilOS en la secci6n 2.4. 1..10. ,LCual es el prop6sito de Ja evaluaci6n del proceso? ,PoT que el SPICE ha sido desarrollado como un estandar para la evaluaci6n del proceso' 2.11. Invesligar mas sobre el PSP y preparar una breve presenlaci6n que indique los beneficios cuantitalivos del proceso. 2.12. La utihzaci6n de -c:scritos" (un mecanismo requerido en el PSE) no goza de gran aceptaci6n entre la comunidad del software. Hacer una !ista de las ventajas y desventajas mientras se loman en cuenta los escritos y sugerir al menos dos situadones en que seTian (Jtiles y otras dos Slluaciones en donde no lendrian tantos beneriClos

47

El estado actual de \a ingenierfa deL software y el proceso de software 10 determinan bien

pubHcaciones mensuales como fEEE software, computer, y IEEE Transactions on SOftware Engi ncering Publicaciones peri6diC3S como App/kerion DeveJopmenl 1tends y curter TT Journal a

cada ana en la Proceeding

menuda conlienen artlculos sobre lemas de ingenierla del software La disdplina se ~resume" oj the In/emotional Conference on Software Engmeenn,g, patrocinado por el IEEE y ACM, Y se dlscute a profundidad en publicaciones como AeM Transactions on Software Engineering and Methodology, ACM SOftware Engineering Notes y Annals of Software Engineering Miles de paginas de \a red estan dedJcadas a \a Ingenieria del software y al proceso de software. En los af\os recientes se han publ1cado muchas libros referentes al proceso de software y a la jngenlerla del software. Algunos presentan un panorama del proceso en su totalidad,
mientras atras centran su atenci6n en unos cuan\os temas importantes y ex.duyen otros. Entre las propuestas mas populares se encuentran: Abran, A y,. Moore, SWEBOK: Guide /0 the Software Enginemng 2002. Ahem. D, et aI., CMM( Distilled, Addison-wesley, 200 I. Chrisis, B et al_, CMM/; Gl1idelmes for Process Integraoon and Product Improvement, wesley, 2003.

Boc:fY of Knowledge.

IEEE.

Addison-

Christensen, M. y R. Thayer, A Project Manager's Guide to SOftware Engineering Best PrOctices, IEEE-CS Press (Wiley), 2002. Glass, R., Fact and Fallacies o[SOjhNore Enginemng, Addison-Wesley, 2002. Hunter, R. y R. Thayer (eds.). software Process ImprcJVrolent, IEEE-CS Press (Wiley), 2001 Persse, J., Implementing the capability Maturity Model, Wiley, 2001. POeeger, 5., Software Engineerifl8' Theory and Pmc/ke, 2a. ed., Prentice-Hall, 2001. Potter, N. y M. Sakry, Makif18 Process Improvancm WOrk, Addison-wesley, 2002 SOmmerville, I., software Engineering, 6a ed, Addison-wesley, 2000
En 1 0 que respecta a lecturas mas ligeras. un libro de Robert Glass (Software Conflict, Vourdon Press, 1991) presenta ensayos sorprendenles y conlroversiales sobre el software y el proceso de ingenierta del software. Vourdon (lka/h March ProjeCts, Prentice-Hall, 1997J expone 10 que sale mal cuando faHan grandes proyectos de software y cOmo evitar esos errores. Garmus (Measuring the software Process, Prendce-Nall, 1995) y Florae y Carlton (Measuring the software Process, Addison-wesley, 1999) explican cOmo evaluar de modo estadistico la eficacia de cualquier proceso de software se ha publicado una gran varie<lad de proce<limientos y estandares de la ingeniena del software desde la decada pasada. EI IEEE software Engineenng 5tandards contiene muchos estandares diferenles que cubren casl cada uno de los aspectos importantes de Ja tecnologla El conjunto de documentos ISO 9001:2000 propordona una guia a las organizadones de software que deseen mejorar sus actividades de gestiOn de caUdad Qtms estandares de ingeniena del software se pue<len obtener del Departamento de oefensa, la FAA y otras agendas gubemamentales y no lucralivas de Estados Unidos de America Fairclough (Software Engineering Guides, Prentice-Hall, 1996) ofrece una referencla detallada de estandares de ingenierla del software producida por la Agenda Espadal Europea (ESA, por sus siglas en Ingles). En Internet estil disponible una gran variedad de fuentes de infonnaciOn sobre ingenierfa del software y el proceso de software. Una !ista actualizada de referencias de la World Wide Web relevanles para el proceso de software puedc enconlrarse en cl 5itio; http://_ .mhhe.com / pressman.

CAPITULO

MODELOS PRESCRIPTIVOS DE PROCESO

CONCIPTOS CLAVE

.,

-_...
.......

prtl.rtpts ...55

.......

OS modelos prescriptivos de proceso se propusieron otiglnalmente para ordenar el caos del desarrollo de software La historia ha indicado que estos

modelos convencionales han lraido consigo eiena cantidad de estructuras

uWes para el trabajo en la ingenieria del software, y han proporcionado un ca-

(~IIIM M!

mino a seguir razonablemente efectivo para los equipos de software. Sin embargo, el trabaJo de la ingenieria del software y el producto resultante a(m

pennanecen "al borde del caos" [NOGOOJ_

hl1lllt,.......64 IDOdtIIDI< 63
..... 0......53 IIMIIoDSOA .6$

En un documento intrigante sabre la extrana reladOn entre el orden y eJ caos en el mundo del software, Nogueira y sus colegas establecen'
EI borde del caos

se

define como "un eslado natural entre el orden y el

caos,

una

...... "

relaci6n estrecha entre la estructura y la

sorpresa" lKAU%j, El borde del caos se puede

es inestable

.......... 50

....... ................
......
,....

vlsual!z.ar como un estado inestable, estructurado en forma parcial.

porque es atraldo de manera constanle hacia el caos 0 hada el orden absolulO,

......

un error La Investigad6n,

. .52

Se tiende a pensar que el orden es el estado ideal de la naturaleza Esto podrla ser apoya la teorla de que 1a operad6n lelOS del equilibrio genera creatividad, procesos organit.ados por 51 mismos y retroalimentaci6n ereciente lR0096I. EI orden absoluto Significa la aU5encia de variabilidad. 1 0 cual seria
una ventaja en ambientes impredeables EI cambio ocurre cuando eldste alguna es tructura para que pueda organiza1Se. dicha estructura no debe seT tan rlgida como

.... ~ ...49

.......

........... .... .54

para que eVite el cambio,

Por otro lado. demaslado caos puede ImposlbilitaT la coor-

dmaci6n y la coherenda, La falta de estructura no siempre slgniflca desorden

....... ... .61

Lau;. ..7 1.0.

de pm<e<O _ ... """""'" ,,10 de odMdodeo, __

modoIo.......-...-

1."11 no .. controIo puede vdvene co6ti~ modele de proceso pres-

__ a

fv,<iomenJo. y ~ de ........ que se requier.! para ct..orroIor software de alto colidod Eitol ".odeb .. procase no son perfecto$, perc prcpomonan gura util para el trobojo de 10 Ingenierio del waco. lQuie" 10 hac.? los ingenieros de IOItwore y

Adem6s, 10 sente que ho soIici1odo .. soffware hene un popel par ~ oonlonne Ie erieculo

sus gerentes odopton un modeIo pntKtiptiYO dct proceso a sus nece~ y Onpues, 10 seguen

l.Por

..

estobilidod. control YOI'gOnizoci6n a una odiVl

que importon..'

eI modeIo de soitwore

Porque

propor'ClOftCI

c:rip..... han rJ.ridocomo 'mode!os riguro50S fRCMO )'Q que a menudo incJuyen \os capocidodoo ......... pc< Ia IMCM I<opilulo 2). Sin ...",.,. todos los modelos de proc9$O se pued.n odopIor para usarlos de forma eFectiva y en un pr'O)*tO de software especifica. ,Cu6IM .... los ,...,., El proceso conduce a un equtpO de IOftwore a troves de un conjunlo de odividodM del marco de troboia ql./e se orgarwlrln en un Auto de procese, .,1 cuol puede ... Mea! ncrementoI a evoIutivo. lo terminologiG y Ie. deIoI. de codo modeIo de proceso 1R..n pero la, odlvidodes genericas del marco de trabajo pHmOfIecen razonoblemente
~

Las implicaciones fiJ0s6ficas de este argumento son significativas respecto de [a

ingenierta del software. Si los modelos presc.riptivos del proceso l buscan estructura y orden, ,estos resultan inapropiados para un mundo del software que se basa en el cambia? Ademas, 51 se rechazan los modelos convencionaies del proceso (y el orden que estos implican) y se reemplazan con algo menos estructurado, ,se imposibilita
alcanzar 1a coordinaci6n y la coherencia en el trabaJo del software?

No existen respuestas (aciles, perc exlsten opclones disponibles para los ingenieros de software. En este capitulo se examinara eJ enfoque del proceso prescriptivQ, en el eual el orden y 1a consistencia del proyecto son los aspectos dominantes. En el capitulo 4 se examinara eJ enfoque del proceso agil en el eual la organizaci6n propia, la colaboraci6n, la comunicaci6n y la adaptabilidad Clominan la filosofIa del proceso.
" ,. ". ..... !Ii"

...... aa

...

. .. ....
~

Cualquier organlzaci6n de ingenierla del software debe describir un conjunto unico de actividades dentro del marco de tTabajo (capitulo 2) para el (los) proceso(s) de software que adopte. Tambh~n debe lIenar cada actividad del marco de trabajo con un conjunto de acciones de ingenierla del software, y definir cada acci6n 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. Despues, la organizaci6n debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza especlfica de cada proyecto, a las personas que 10 realizaran. y el ambiente en el que se ejecutara el trabajo. Sin importar el modelo del proceso seleccionado, los ingenieros de software han elegido de manera tradicional un marco de trabajo genefico para el proceso, el cual incluye las siguientes actividades dentro del marco: comunicaci6n, planeaci6n, modelado, construcci6n y desarrollo.

F~D.I_ _
I

Los modelos prescriplivos de procesoa menudo $I! denomtnan modelos "convencionales" de proceso

PARTE UNO EL PRCCESO 00. SOFlWARt

.......
~.

SM/ presofiivo, /kI Sf

",_,Ii .-,Ii

ra_"o """"lS~lDs

debt astri"". 4sIt

En las secciones siguientes se examinaran varios de los modelos prescriptivos del

proceso de software. Se les llama ~p rescrip t ivos" porque prescriben un canjunto de elementos del proceso: actividades del marco de tTabaja, acclones de ingenieria del software. tareas, productos del tTabaja, aseguramiento de la calidad, y mecanismos de control del cambia para cada proyecto. cada modele de proceso prescribe tambien unjlujode trobajo; eslo es, la forma en la cuallos elementos del proceso se interrelacionan entre sf. Toclos los modelos de proceso del software se ajustan a las actividades genericas

de:! marco de tTabaja descritas en el capitulo 2, perc cada uno aplica una importancia diferente a estas actividades y define un flujo de tTabaja que invoca cada actividad del marco de trabajo (asi como acciones y tareas de la ingenieria 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 comunieaci6n a traves del despliegue de una manera casi lineal. Esta situaci6n se encuentra a veces cuando es necesario haeer adaptaciones 0 mejorias bien definidas a un sistema existente (pOr ejemplo, una adaptaci6n a un software eontable debido a los eambios en las regulaeiones del gobiemo). Esto puede ocurrir tambien en un numero Iimitado de proyectos de nuevos desarrollos, pero 5610 cuando los requerimientos estfm bien definidos y son eslables en forma rawnable. EI modeJo en cascada, algunas veces llamado el dc/o ck VIda cJdsico. sugiere un enfoque sistematico, secuencial1 hada el desarrollo del software, que se inicia con la especificaci6n de reQuerimientos del c1iente y que continua con la planeaci6n, eJ mcx:leJado, la construcci6n y el despliegue para culminar en el soporte del sonware terminado. EI mcx:lelo en cascada es el paradigma mas antiguo para la ingenieria del software. Sin embargo. en las decadas pasadas, las erlticas a este modelo de proceso han

El modelo en cascada.

ComunicaciOn
inic~ del proyIc

r.copdoci6n

d. rtqu,,,lQt

_...
~limoc:iOr1 ~ir\&r'Orio

MDd.ID,b
",,6Ii.i.

Con.tnKcton

s.euimiento

diieno

I- Dre.pli....

.....

,eII'ooli...."kIQbn

~-

A. pesa r de que el maido en cascada origmal. que propuso Winston Royce [ROY701. prevt': -ddos de retroalimentaci6n".la inmensa mayoria de lasorganizaclones que aplica este modelo de proceso 10 trata como si fuera estrictamente Imeal

51

ocasionado que aun sus mas fervientes practicantes hayan cuestionado su eficacla (HAN95J . Entre los problemas que algunas veces se encuentran al apiicar el modelo en cascada estAn : 1. Es rnuy raro que los proyectos reales sigan eJ flujo secuencial que propone el

modele. A pesar de que el modele lineal incluye iteraciones, 10 haee de manera

indirecta . Como resultado, los cambios confunden mientras el equipo de

proyecto actua.
2. Con frecuencia es dificil para el cliente establecer todos los requisitos de manera expllcita. El modelo en cascada 10 requiere y se enfrentan dificultades a1 incorporar la incertidumbre natural presente en el inicio de muchas proyectos. 3. EI cliente debe teneT paciencia. Una versi6n que fundone de los programas estara disponible cuando el proyecto este muy avanzado. Un error grave sera desastroso si no se detecta antes de la revisi6n del programa . En un analisis interesante de proyectos reales, Sradac [SRA94] concluy6 que la naturaleza lineal del modele en cascada conduce a Hestados de bloqueoHen los cua les algunos miembros del equipo del proyecto deben esperar a otres 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 mas comun al princlplo y al final del proceso secuencial. En la actualidad, el trabajo del software esta acelerado y sujeto a una cadena infi nita de cambios (de caracterlsticas, funciones y contenido de la informaci6n) . Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso utiJ en situaciones donde los requeri mientos estan fijos y donde el trabaJo se realiza, hasta su conclusi6n, de una mane ra lineal .

'>."

....

,~

.......

En muchas situaciones los requisit os iniciales del software estan bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Ademas. quiza haya una necesidad imperiosa de proporcionar de manera rapida un conjunto limitado de funcionalidad para el usuario y despues refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso disenado para producir el software en fonna incre mental.

"fM_~~"",,,~_,,,,~_,"'doI,Xb.,,

..

......... y mnIfa" rienlo."

_ba __

52

PARTE UNO EL PROCISO 00. SOFTWARE

3.3.1 E1 modele incremental

EI modele incremental combina elementos del modelo en cascada apJicado en forma iterativa. Como se muesl ra en la figura 3.2, el modelo incremental aplica secuencias

omOIWo ir'IoInwllG
enIlega lIlO sane cit

C&VE

.......

Ioozmienlos,

"'" IlfOPIWOOnon en Iormo lO!Jesiw m6s fln:ioIdOOdlKlrolos <ientes a meciOO "'" ~ IIltrega oxk! !flO de m inuemenlos.

lineales de manera escalonada conforme avanza el tiempo en el calendario. cada

secuencia lineal produce uincrementos" del software IMCD93J . Por ejemplo, el software procesador de texlo, desarrollado con el paradigma incremental en su primer incremento, podria realizar funciones basicas de administraci6n de archivos, edici6n

y producci6n de documentos; en el segundo incremento, ediclones mas sofisticadas, y

tendria funciones mas complejas de producci6n de documentos; en el tercer incremento, funciones de correcci6n ortografica y gramattcal; y en el cuarto, capacidades avanzadas de configuraci6n de pagina. se debe tener en cuenta que el flujo del praceso de cualquier incremento puede incorporar eJ paradigma de construcci6n de prototipos que se expone en la secci6n 3.4.1. A menudo, al utiJizar un modele incremental el primer incremento es un produc-

10

e.senciaJ. Es decir.

se incorporan los requisitos bAsicos, pero muchas caracteristi-

cas suplementarias (algunas conocidas, otras no) no se incorporan. EI producto

f"_IIlO" Si. _ _
10 fIII"6f1D MIllO

esenciaJ queda en manos del cliente (0 se somete a una evaluaci6n detallada). Como resultado de 1a evaluaci6n se desarrolla un plan para el incremento siguiente. EI plan afronta la modificaci6n del producto esencial con el fin de satisfacer de mejor manera las necesidades del diente y la entrega de caracteristicas y funcionalidad adicionales. Este proceso se repite despues de la entrega de cada incremento mientras no se haya elaborado el producto completo. EI modelo de proceso incremental, al igual que la construcci6n de prototipos y atros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcci6n de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones

" . BtJIr8jp. Il1O 0 IBt

iImrnIrIIIls fIOIO fSIJ ftdrI tfSIO dill

_r_ -""'"
r" """"""

r.m..-..

Elmodelo

incremental.

E3 MoO.k>cIo (on6!ioi diWloj

Con."..a:i6n

l<6<Ii"". prwbo)

[)..pI~""~.~i~J

""'_ '2

53

"incompletas" del producto final, pero praporcianan al usuario la funcionalidad que necesita y una plataforma para evaluarlo ..1 EI desarrollo incremental es util sobre todo cuando el personal necesario para una implementaci6n completa no esta disponible. Los primeros incrementos se pueden implementar can menos gente. 5i el producto esencial es bien recibido se agrega (si se requiere) mas personal para implementar el incremento siguiente. Ademas. [os incrementos se pueden planear para manejar los riesgos tecnicos. Par ejemplo, un sistema grande podrla requerir la disponibilidad de un hardware nuevo que esta en desarrollo y cuya fecha de entrega es inc[erta. Serla pesible planear los primeros incrementos de forma que se evlte el usa de este hardware, 10 que permitiria la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados.

3.3.2

El modelo DRA

EI desalTOllo rnpido de aplicaciones (ORA) es un modele de proceso de software incremental que resalta un cicio de desarrollo corto. EI modelo ORA es una adaptaci6n a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rapido mediante un enfoque de construcci6n basado en componentes. 51 se entienden bien los requlsitos y se limita el ambito del proyecto,4 el procesa ORA permite que un equipo de desarrollo cree un "sistema completamente fundonal" dentro de un periodo muy corto (por ejemplo, de 60 a 90 dlasj IMAR91J. Como otros modelos de proceso, el enfoque ORA cumple can las actividades genericas del marco de trabajo que ya se han presentado. La comunicaci6n trabaja para entender el problema de negocios y las caracterlsticas de informaciOn que debe incluir el software. La planead6n es esenclal porque varios equipos de software trabajan en paralelo sobre diferentes fundones del sistema. El modeJado incluye tres grandes fases -modelado de negocios, modelado de datos y modelado del proceso-- y establece representadones del disei\o que sirven como base para \a actividad de construcciOn del modelo ORA. La construcci6n resalta el empleo de componentes de software existente y la aplicaci6n de la generaci6n automatica de cMigo. Par ulti mo, el despliegue establece una base para las iteraciones subsecuentes, 51 esta5 son necesarias [KER94). EI modelo de proceso ORA se i1ustra en la figura 3.3. Es obvio que las restricciones de tiempo impuestas sobre un proyecto ORA exigen un "ambito de escalas" [KER94J. 5i una aplicacl6n de negocios se puede modular de forma que cada gran funci6n pueda completarse en menos de tres meses (mediante la aplicaclOn del enfoque ya

3 E.s Importante observar que para lodes los modelos de proceso Agiles que K tratan en el capitulo" tamb~n se utiliza una lilosotla incremental. 4 Estas condiciones no se pueden garantizar por ning(tn medio. De heche. muchos proye<:l05 de soft ware Ilenen los requisitos muy pobremente definidos a\ principle. En tales casos los enfoques de constnJcdOn de prol.oI.ipOS 0 evelullvQS (seccl6n 3.4) son mejores opdones de proce50. Vta.se
[REI95I .

.
El moct.lo
DRA.

PARTE UNO

L PROCESO 00. SOFTWARE

'-'"

e..- hili!.

~; '''''''''' , - ... .......

=:
,

.
I

_........ ,......,
,; oW ,
,

I ';

y ~
;

::...., .....
6().90 dial

descrito),

esta

es una candidata para elORA. cada gran funci6n se puede abordar

mediante un equipo de ORA por separado, para despues integrarlas y formar un todo.

desventoJas del _ORA?

-'"

Ie....

Como lodes los modelos de proceso, el enfoque ORA liene inconvenienles

[BUT94]; I) para proyectos grandes, perc escalables, elORA necesila suficientes recursos humanos para crear el mimero correcto de equipos ORA; 2) si los desarrolIadores y clientes no se comprometen con las actividades rapidas necesarias para

completar el sistema en un marco de tiempo muy breve, los proyectos de ORA fallaran; 3) si un sistema no se puede modular en forma apropiada, la construcci6n de los componentes necesarios para elORA sera problematica; 4) 51 el alia rendimien to es un aspecto importante, y se a1canzara al convertir lnterfases en componentes del sistema, el enfoque ORA podlia no funclonar; y 5) elORA selia inapropiado cuando los rjesgos tecnicos son altos (por ejemplo, cuando una aplicaci6n nueva aplica muchas nuevas tecnologlas).

El software, como todos los sistemas complejos, evoluciona con eJ tiempo IGIL88J. Los requisitos de los negoc.ios y productos a menudo cambian conforme se realiza el desarrollo; por 10 tanto, la ruta lineal que conduce a un producto final no sera real; las estrictas fechas tope del mercado imposibilitan la conclusi6n de un producto

55

completo, por 10 que se debe presentar una versi6n limitada para liberar la presi6n competitiva y de negocios; se tiene claro un conjunto de requisitos del producto 0 sistema esencial, pero todavia se deben definir los detalles de las extenslones del producto 0 sistemas. En estas y otras situaciones Similares, los ingenieros de software necesitan un modele de proceso que haya sido disei'iado de manera explicita para incluir un producto que evolucione con el tiempo.

Los mCKJdos ~ulivos son iterativos; los caracteriza la fanna en que permiten que los ingenieros de software desarrollen versiones cada vez mas completas del software.

3.4.1

ConstrucdOn de prototlpos

A menudo un cliente define un canjunto de objetivos generales para el software, perc no identifica los requisitos detal1ados de entrada, procesamiento 0 salida. En otros casas, el responsab\e del desarrollo del software esta inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo 0 de la forma que deberia tomar la interacci6n humano-maquina. En estas, y en muchas otras situaciones, un paradigma de construcci6n de prototipos puede ofrecer el mejor enfoque. A pesar de que la construcci6n de prototipos se puede utilizar como un modele de proceso independiente, se emplea mas comunmente como una tecnica susceptible de implemenlarse dentro del contexto de cualquiera de los modelos de proceso

--

....

expuestos en este capitulo. Sin importar la forma en que este se aplique, el para digma de construcci6n de prototipos ayuda al ingeniero de sistemas y a\ cliente a entender de mejor manera cuai sera el resultado de la construcci6n cuando los requisitos esten satisfechos. El paradigma de construcci6n de prototipos (figura 3.4) se inicia con \a comunicaci6n. EI ingeniero de software y el cliente encuentran y definen los objetivos glo-

a-do .

-~poI.

56

PARTE UNO

El.

PRIXE90 DEl. SOFTWARE

bales para el software, identifiean los requisitos conocidos y las areas del esquema

en donde es necesarla mas definlcl6n. Entonces se plantea con rapidez una iteraci6n de construcci6n de prototipos y se presenta el model ado (en la forma de un diseno

r.ipidal . El diseno rapido se centra en una representaci6n de aquellos aspectos del

software que seran visibles para el cliente 0 eJ usuario final (por ejemplo, la configuraci6n de la interfaz con el usuario y el formata de los despliegues de salida). El diseno rapido conduce a la construcci6n de un prototipo. Despues, el prototlpo 10 evalua eJ cliente/usuario y con 1a retroalimentaci6n se retinan los requisitos del software que se desarrollara. La iteraci6n ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarroJlador entienda mejor 10 que se debe hacer.

De manera ideal , el prototipo deberia 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 a aplica herramtentas (como generadores de informes, administradores de ventanas, etcetera) que permiten producir programas de trabajo con rapidez. Pero ,que debe hacerse con el prototipo una vez cumplido el pr0p6sito descrito? Brooks [BR075] ofrece una respuesta:

En la mayoria de los proyectos, el primer sistema construido apenas se utiliza. Tal vez sea demasiado lento, muy grande 0 torpe en su usc, 0 reuna las Ires caracteristicas a la vez. No existe otra opci6n que comenzar de nuevo, aunque sea doloroso, es 10 mejor, yconstruir una revisi6n redisenada en la que se resuelvan estos problemas ... Cuando se apUca un concepto nuevo de sistema 0 una tecnologia nueva, se Uene que construir un sIstema in servible y que sea necesatio ~har, porque incluso Ia mejor planeaci6n no es omnisciente como para que el sistema este perfecto desde la primera vez. Por 10 lanto, la pregunta de la administrad6n no es si debe construlrse un sistema piloto y desecharlo. Esto tendrA que hacerse. La unica pregunta es sl se planea la construcd6n de un dese<:hable 0 se promete entregarselo a los clientes.
EI prototipo puede servir como ~primer Sistema", el que Brooks recomienda desechar. Pero esta tal vez sea una visi6n idealizada . Es verdad que a los clienles y los desarrolladores les gusta el paradigma de construcci6n de prototipos. A los usuarios les gusta el sistema reat y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, 1a construcci6n de prototipos tambien se toma problematica por las siguientes razones: 1. EI cliente ve 10 que parece una versi6n en funcionamiento del software, sin saber que el prototipo est! unido "con chicle y cable para embalaje", que por

ResisIr1sI 0 .b {Xesi6Il pm cOlWlfft III ,IRlIOIIPI /WI III! III

ta prisa de hacerlo funcionar no se ha considerado la caUdad del software global 0 la facilidad de mantenimiento a largo plazo. Cuando se informa que el producto debe construirse otra vez para mantener los altos niveles de caU, dad, el cliente no 10 entiende y pide la aplicaci6n de Hunos pequenos ajustes~ para que se pueda elaborar un producto final a partir del prototipo. Es muy frecuente que la gesti6n del desarrollo de software sea muy lenta.

.-.C ...
~,rosi

.....

si6flvJte 10 aiiOOd se

.,
2 . A menudo, el desarrollador establece compromisos de implementaci6n para lograr que el prototipo fundone con rapidez. Tal vez se utilice un sistema operativo 0 lenguaje de programaci6n inadecuado s610 porque esta disponible

yes conocido; se puede implementar un algorilmo ineficiente 5610 para

mostrar capacidad, Oespues de un tiempo, el desarrollador quiza se (amiliance con estas selecciones y olvide las razones por las que son inapropiadas.
La selecci6n menos ideal ahara se convierte en una parte integral del sistema.

A pesar de que tal vez surjan problemas, la construcci6n de prototipos puede ser un paradigma

erective para

la ingenierla del software. La clave es definir las reglas

del juego desde el principia; 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 definid6n de requisitos, en que se descarte, a1 menos en parte, y en que despues se desarrolle el software real con un enfoque hacla 1a caUdad.

.... -

d. procao. --Jlllllil!-::~
I'aI'IioneI

w.

- . on CPt

. . -pnxloo-

-_...
"""
.... ...w.-dII
pllflto.)

para~ .

....

"'-

"'""'. _y._oIoii
bobIo.

""""$",.,n.. w.......
in>I .

- ... ~"-:.,~.=== .....

-&loy .....

-...
'-

..

PARTE UNO

El. PROClS:! on. SClf"TWARE

3.4.2 El modelo en espual

El mode1o en espiral, que Boehm (BOE88] propuso originaimente. es un modele de proceso de sofiware evolutivo que conjuga la naturaleza iterativa de la canstrucci6n

de prototipos con los aspectos controlados y sistematicos del modele en cascada.

Proporciona el material para eJ desarrollo rllpido de versiones incrementales del software. Boehm (BOEOI) describe este modelo de la siguiente manera :
E1 modelo de desarrollo en espiral es un generador del modelo de proceso gu!ado

poT el

riesgo que se emplea para conducir sistemas intensivos de ingenier1a del software (00-

currente y con multiples usuaJios. TIene dos caracterlsticas distintivas principales Una de

elias es un enfoque ciclico para eJ crecimiento incremental del grado de definid6n e implemenlaci6n de un sistema, mienlras disminuye su grado de riesgo. La otra es un conjunto de puntos de fiJad6n para asegurar el compromiso del usuario con soludones de

sistema que sean factlbles y mutuamenle satisfactorias.

~,

C&VE
8 modeIo en tsProI se

..... o"'"dO

""'" ado"" y em do .u. """". deLRl~,

desdo._dO
ton(epto ImIIl III
~.

Cuando se aplica el modele en espiral, el software se desarrol1a en una serie de entregas evolutivas. Durante las prtmeras iteraciones, la entrega tal vez sea un documento del modelo 0 un prototipo. Durante las ultimas iteraciones se producen versiones cada vez mas completas del sistema desarrol1ado . Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de ingenieria del software. Para pr0p6sitos ilustrativos se aprovechan las actividades genericas del marco de trabajo expuestas paginas atras.6 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 evolutiva el equipo de software realiza actividades implicadas en un circuito alrededor de la

PIo_iOn
Un modelo
Ml . .ptral

Istif'llOd6n
i~~io

tiplco.
ComunicaciOn

an61llil

de rielQOS

Madl lado
aoolilis

d,lIiio

EI modeloen espiral expuesto en esta seccI6n es una variaci6n del modelo que propuso Boehm. Para mas lnfonnacl6n sobre el modelo en espiral original, vtase [80E881 En IBOE98\ se puede encontrar una exposici6n mas reciente del modelo en espiral de Boehm

.
espiral que tiene una direcci6n en el sentido del movimiento de las manecillas del reloj, y que se inida desde e! centro. El rtesgo (capitulo 25) es un factor considerado en cada revoluci6n. Los puntas de Jijaci6n -una combinacl6n de productos de tTabaja y condiciones incluidas a \0 largo de la ruta de la espiral- se consideran para cada paso evolutivo. EI primer circuito alrededor de [a espiraJ quiza genere el desarrollo de una especificaci6n del producto; los pasos subsecuentes alrededor de la espiraJ se pueden aprovechar para desarrollar un prototipo y despues, en forma progresiva, versiones mas elaboradas del software. Cada paso a traves de la regi6n de planeaci6n resulta

en ajustes al plan del proyecto. Los costos y el itinerario se aJustan con base en la
retroalimentaci6n derivada de la relaci6n con el cliente despues de la entrega. Ademas, el admlnistrador del proyecto ajusta el numero de iteraciones planeado que se requiere para completar el software. A diferencia de otros modelos de proceso que terminan cuando se entrega eJ software, el modelo en espiral puede adaptarse y aplicarse a 10 largo de la vida del 5Oftware de computadora. Por 10 tanto, el primer circuito alrededor de la espiraJ podrla representar un Hproyecto de desarrollo del conceptoH , el cual se inicia en el centro de la espiral y continua por multiples Heraciones6 hasta que el desarrollo del concepto estt completo. 5i el concepto se desarrollara en un proclucto real, el proceso continua en la siguiente fase de la espiral y comienza un "proyecto de desarrollo de un producto nuevo". EI nuevo producto evolucionara a traves de un numero de iteradones alrededor de la espiral. Despues, un circuito alrededor de la espira\ se podrfa emplear para representar un "proyecto de mejoramiento del producto". En esencia, la espiral, cuando se caracteriza de esta forma, permanece operati va hasta que el software se retira. En ocasiones el proceso esta inactiv~, pero siempre que se inicie un cambio el proceso comienza en el punto de entrada aprobado (por ejemplo, mejoramiento del producto). EI 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 desalTOllador y eJ cliente entienden y reaccionan de mejor manera ante los riesgos en cada etapa evo[utiva. EI modele en espiral emplea la construcci6n de prototipos como un mecanisme encaminado a reducir riesgos pero, en forma mas importante. permite al desarrollador la aplicaci6n del enfoque de [a construcci6n de prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque sistematico de los pasos que sugiere el cicio de vida c1asico, pero 10 incorpora al marco de trabajo iterativo que reneja de forma mas verldica el mundo real. El modele en espiral exige una consideraci6n directa de los riesgos tecnicos en todas las etapas del proyecto y; sJ se ap/ica en (onna apropiada. debe reducir los riesgos antes de que se vue/van problem,Hicos.

Us tlechas que apuntan hada denlTO a 10 largo del eje que separa Ja regi6ll de tkspI~ de Ia de <omumcociOn indican una posibilidad de iletadon local a Jo largo de la mrsmiJ rola de la '!SprtiJ/

.~------------------------60
PARTE UNO EL PROCESO DEL SOfTWARE

Asl como alros paradigmas, el modele en espiral no es una panacea . Es dilleil convencer a los clientes (en particular en situaclones bajo centralo) de que el enfoque evoiutivo es controlable, ya que se requiere una habilidad considerable para evaluar el riesga y se contIa en dicha habilidad para obtener el exilo. Si un riesgo importante no se descubre y administra, sin duda surgirtm problemas.

3.4.3

El modelo de desarrollo concunente

EI modelo de desarrollo concurrenle, lIamado algunas veces ingemerfa concurrente, se

flONII'."
'""",*,,01-

representa en fonna esquemaliea como una serie de actividades del marco de tra~ bajo, acciones y tareas de 1a ingenierfa del sofiware y sus estados asociadas. Por ejemplo, 1a actividad de modeJado. definida para el modele en espiral, se lIeva a cabo al invocar las accianes siguientes: constcucci6n de protoUpos a modelado y especificaci6n del ana!isis y diseno.1 En la figura 3,6 se proporciona un esquema de una tarea de ingenierla de software relacionada can la actividad de modelado para el modele de proceso cancurrente.
La actividad -modelado- puede estar en alguno de los estados' destacados mencionados antes en cualquier momento dado. De forma similar, otras actividades 0 tareas (por ejemplo, la comunicaci6n y \a construcci6n) se representan de una manera analoga. Todas las actividades existen de forma concurrente, pero se encuentran en diferentes estados. Por ejemplo, al principia del proyecto la actividad de comunicad6n (no se muestra en l a figural ha completado su primera iteraci6n y existe en el estado de en espera de cambios. La actividad de mode/ado que existi6 en el estado ninguno mientras se reali zaba la comunicaci6n inicial, ahora reaJiza una transiciOn al estado en desarroUo. Sin embargo, si el cliente indica cambios en los requi-

-"'"

"""""" ~ ""
""""" do ri.... .....,

......

(""'" 61, ""'" .... """""' dt. ffItIIe:s IIQUiIo:s dt

sitos, la actividad de modeJado se mueve del estado en desarroUo al estado de en espera de cambios, EI modelo de proceso concurrenle define una serle de eventos que dispararan transiciones de estado a estado para cada una de las actividades, acciones tareas de la ingenierla del software. Por ejemplo, durante los primeros estados del diseiio (una acci6n de la ingenieria del software que ocurre en el curso de la actividad de modelaci6n) no se detecta una inconsistencia en el modelo del analisis. Esto gene-

ra eJ evento correcci6n del andlisis del modelo, el cual disparara la creaci6n del ana!isis desde el estado realizado hasta el estado de en espera de camblos. El modele de proceso concurrente se aplica a todos los tipos de desarrollo de software y proporciona una visi6n exacta del estado actual de un proyecto. En Jugar de confinar las actividades, acciones y tareas de la ingenierla del software a una secuencia de eventos, define una red de actividades. Cada actividad, acci6n 0 tarea en la red existe de manera simultanea con atras actividades, accianes 0 tareas. Los

7 Se debe notar que el anahsis y el disei'io son acclones complejas que requleren un debate sustancial. La pane 2 de este libro con5Jdera estos t6pkos en fonna detaJlada 8 Un t!SlLldo es alguna rOlTTla de comportamiento observable desde el exterior

6'

,
N. . . .

Actfv\dod de mod,lado

do_

..,

_, I

,.......
do """'"'"

'"

,.

~ En modificoci6n

""';.;i)n

/
do . . .

En ~'*'

........
estados.

eventos generados en un punta de 1 a red del proceso disparan translciones entre los

3.4.4

Un comentarlo final sobre los procesos evolutlvos

Va se ha deledado que al sofiware de computadoras modemo 1 0 caracteriza el cam

hie continuo, los tiempos de entrega muy reducidos, y una necesidad intensa de satisfacer al cliente/usuario. En muchos casos, el tiempo de Ilegada al mercado es el requisito de gesti6n mas importante. Si se pierde una ventana del mercado, el mismo proyecto de software puede perder su significado.'

...............
Los modelos evoiutivos de proceso se concibieron para abocarse a estos aspec-

los y. adem as, como modelos de proceso de clase general. Estos modelos tambien
tienen debilidades, las cuales resumen Nogueira y sus colegas INOGOO1 :

Sin embargo, es importante notar que lIegar en primer lugar a un mercado no garantiza el exito. De hecho, muchos productos de sot\ware muy exitosos han sido los segundos 0 hasta los terceros en liegar al mercado (al aprender errores de los antecesores).

.,

PARTE UNO

E!.

PRCCESO DEl. SOfiWARE

A pesar de los incuestionables benelicios de los procesos evolutivos de software, se tienen algunas dificultades con esl:e lipo de procesos. La primera dHicultad es que la construecibn de prototipos IY otros procesos evolutivos mas e laboradosl implican un problema para la planead6n del proyecIo debido a l numero inciel10 de ddos requeridos para consIruir e l producto. La mayoria de las tecnicas de gestiOn y estimaciOn de proyectos se basa en conliguraciones lineales de las actividades, por 10 que estas no se ajustan por completo.
La segunda dilicultad es que los procesos evolutivos de soRware no establecen la ve-

locidad maxima de la evoluciOn. Si las evoluciones suceden demasiado rapido, sin un periodo de relajaciOn, existe]a certidumbre de que e l proceso caera en el caos. Por otro lado, si la velocidad es demasiado lenta, se podria afeclar la produClivldad. Una tercera dificul tad es que los procesos de software se deben enfocar en la flexibilidad y extensibilidad en vez de en la alta calidad. Esta afirmaci6n suena atemorizante. Sin embargo, se debe priorizar \a velocidad del desa rrollo sobre los cero defectos. Si el desarrollo se extiende para a lcanzar una alta calidad, se producirla un retraso en la enlrega del prodUCIO, la cual se haria cuando el nicho de oportunidad ya haya desaparectdo. Este cambio de paradigma 10 impone la competencia en el borde de l caos.

En efecto, un proceso de software que se enfoca en la flexlbilidad y la velocidad del desarrollo por encima de la alta caJidad suena alemorizante. Aun asi, esta idea la ha propuesto cierto numero de respetados expertos en la ingenieria del software (por ejemplo, IYOU95j, [BAC97j). EI prop6sito de los modelos evolutivos es desarrollar software de alta calidad 'o de una manera iterati va 0 incremental. Sin embargo, es posible aplicar un proceso evolulivo para destacar la flexibilidad, extensibilidad y velocidad del desarrollo. EI reto para los equipos de son.ware y sus dirigentes es establecer un balance apropiado entre estos parametros criticos del proyecto y el producto, y el producto y la salisfacci6n del cliente (el arbitro final de la calidad del software) .

.kIecd6lI tie un modelo de proceso. $eguDIIR JNI'fe

-.clnorlcN Solo de reuniones soft....ote en (Pi
"""""'" do c:omwciol. t.Warr.!, ..... de ingenierio; Ooog . . . . de ....i.rio d.I software; Ed y Vinod, "U .. 00 . . . . . . . de ingenierio del software.
Ed: Ahcxa II.a """ Me inc:remental ti_ ..mido 'f de eM mcxWo en espiraI. &010

V1nocf: Elby deOCUlfdo. L*'sGiUlt

~dela,--.... . . . . . . . .

..... _.1 . . . .......,

. . . . ... dIe 1M ope.... de procM05

n.pIol14lOmos, Tombi6n ~ oiU5lo 0 ~ Ienet" olgo ~ eI rnercado nIU)' . . . fvndonolidod con aJdo VWIi6n. b .... con
incremento.

10 En este contexto. la calidad del software 5e deline oon mucha amplitud para abarcar no s610 La satlsfacciOn del cliente, SIno tambien una variedad de critenos ttcnicos tratados en el capitulo 26

63

Los modelos especializados de proceso adoptan muchas de las caracleristicas de

uno 0 mas de los modelos convencionales presentados en las secciones anteriores. Sin embargo, los modelos especiaJizados tienden a aplicarse cuanda se ha elegido
un enfoque de ingenieria del software definldo de una manera muy estrecha. 11

3.5.1

Desarrollo basado en componentes

Los nuevos componentes de software comerciales (NCSC), desarrollados por vende-

dores que los ofrecen como productos, se pueden emplear cuando el software esta
en proceso de construcci6n. Estos componentes proporcionan funcionalidad diriQi-

da con interfaces bien definidas que permiten que el componente se integre en el sofiware. El mcxlelo de desarrollo basado en COtn{XJlltYltes (DBC) (capitulo 30) incorpora muchas
de las caracteristicas del modelo en espiral. Es evo\utivQ por naturaieza [NIE92J yexige un enfoque iterative para la creaci6n del software. Sin embargo, el modelo configura aplicadones a partir de componentes de software empaquetados en forma previa, Las aclividades de modelado y construcci6n comienzan con la identificaciOn de los componentes candidatos. Estos componentes se pueden dlsef'iar como mOdulos de software convenciona\es 0 como c1ases 0 paquetes de clases orientados a objetoS.11 Sin Importar la tecnologla que se aplique en la creaci6n de los componentes, el modele de desarrollo basado en componentes incorpora los siguientes pasos (implementados mediante un enfoque evolutivO):

Los productos basados en componentes disponibles se investigan yevaluan para el dominio de aplicaci6n en cuesti6n.

Se consideran los aspectos de integraci6n de componentes. Se disei'la una arquitectura de software (capitulo 10) para adaptar los componentes.

II En algunos ca.sos estos modelos espedalizados de proceso se pueden describir de mejor manera como una colecctOn de tecnicas 0 una melodologla para alcanz.ar una meta espedflca del desarro-110 del software. Sin embargo, estas impllcan un proceso. 12 tAl tecnoioBla orientada a oI:jeIos se trata a 10 largo de Ja parte 2 de e51e JibTO. En e51e contexto, una carmt:ilp5Ula una ~ de datos y /os pnxaJimknt05 ~ proce:san dichos datos. un paqude de cfaX5 es una coIecci6rI de c1ases reladonadas que trabajan juntas para alcanz.ar alglin resultado final

PARTE UNO l. PRCCESO on SOFTWARE

lOs componentes (capitulo II) se integran en la arquitectura.

Se realizan pruebas detaliadas (capitulo II) para asegurar una funcionalidad

apropiada.
EI modele de desarrollo basado en componentes conduce a la reutilizaci6n del sofiware, la cual proporciona beneficios a los ingenieros de sofiware. Con base en estudios de reutilizaci6n, QSM Associates. Inc. informa que el ensamblaje de componentes conduce a una reducci6n de 70 por cienlo del cicio de desarrollo; 84 par cienta del costo del proyecto y un Indice de productividad de 26.2, comparado con una norma de la industria de 16.9 [YOU94J . A pesar de que estos resultados estan en

funci6n de la robustez de la biblioteca de componentes, no hay duda de que el

modele de desarrollo basado en componentes propordona ventajas significaUvas para los ingenieros de software.

3.5.2

El modelo de metodos formales

EI modelo de metodos fomales (capitulo 28) comprende un conjunto de actividades que conducen a la especificaci6n matematica del software de computadora. Los metodos formales permiten que un ingeniero de software especlfique. desarrolle y verifique un sistema basado en computadora al aplicar una notad6n matematica rigurosa. Algunas organizadones de desarrollo del software aplican en la actualidad una variad6n de este enfoque, lIamado ingenieria del software de sala limpia IMIL87, DYE92 j . Este modelo se explica en eJ capitulo 29.

......

Cuando se utili zan metodos formales durante el desarrollo, estos propordonan un mecanisme para eliminar muchos de los problemas ditkiles de superar con otros paradigmas de la ingenieria del software. La ambiguedad, el estado incompleto y la inconsistenda se descubren y corrigen can mayor facilidad -no mediante una revi sl6n ad hoc, sino a traves de la aplicad6n de un anallsis matematico-. Cuando los metodos formales se utili zan durante el disef'lo sirven como base para la verificaci6n de programas y, por consiguiente, permiten que el ingeniero de software descubra y corrija errores que de atra manera podrian no haberse detectado. A pesar de que aun no existe un enfoque estableddo, los modelos de metodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha men-

,...._..
to (onKdil 4tI
110 H Ittll H

cion ado una gran preocupaci6n acerca de su aplicabilidad en su enlomo de gesti6n: En la actuaJidad. el desarrollo de modelos formales es muy carc y consume mucho tiempo.

los !llilo-

softw.., por ...

Se requiere una capacitaci6n detallada, debido a que pocos responsables del

desarrollo de software cuentan con los antecedentes necesarios para aplicar metodos formales.

f. . extlltH?

o.
Es difidl la utilizaci6n de estos model05 como un mecanismo de comuni-

caci6n con clientes que no tienen muchos conocimientos

ttcnicos.

No obstante, tal vez el enfoque a traves de metodos fonnales haya ganado adeptos entre los desarrolladores de software que deben construir sistemas de alta seguridad (por qemplo, en los campos de Ia aeronautica y de los dispositivos medicos), y entre los desarroIladores que padecen severas penurias ef:on6micas cuando aparecen errores en el
software.

3.5.3

Desarrollo del software ortentado a aspectos

Sin importar el proceso de software que se eHja, los constructores de software complejo implementan de manera invariable un conjunto especlfico de caracteristicas, funciones y contenido de informaci6n. Estas caracterlsticas especlficas del software

se modelan como componentes (por ejemplo, c1ases orientadas a objetos) y despues se construyen dentro del contexte de una arquiteclura de sistema. Canforme los sistemas basados en campuladora se vuelven mas elaborados (y complejos), ciertos "inlereses" -propiedades requeridas para el cliente 0 areas de inleres tecnicoabarcan toda la arquiteclura. Algunos intereses son propiedades de alto nivel de un sIstema (por ejemplo. seguridad. falta de tolerancia). Olros intereses afectan las funclones (como la aplicaci6n de reglas de negoclos). mientras que otros son sistemicos (como la sincronizaci6n de lareas a la gesti6n de memoria). Cuando los intereses se relacionan can multiples funciones, caractensticas e inforrnaci6n del sistema, can frecuencia se denominan intereses gen~rales. Los requ~ rimienlos d~ aspectos definen estos intereses generales que ejcrccn un tmpacto a tra yes de la arquitectura del software. EI desnrroJJo de sopware orientado a aspectos (DSOA), refenda can frecuencia como programaci6n orlentada a aspectos (POA), es un paradigma de la ingenierla del software relativamente nuevo que proporciona un proceso y enfoque metodol6gico para definir, especificar, disenar y conslruir aspectos -~mecanismos mas alia de subrutinas y legados para localizar la expresi6n de un interes general" [ELRO 1[. Grundy IGRU02] explica can mayor profUndldad los aspectos en el contexto de 10 que eillama ingerueria de componentes orientada a aspt!Ctos [ICOAI:
La ICOA utiliza un concepto de capas horizon tales a traves de componentes de sofiware descompuestos en rorma vertical. Ilamados "aspectos", para caracterizar propiedades generales de los componentes. los cuales pueden seT funcionaies y no funcionales. Por 10 general. los aspectos slstemkos incluyen interfases con el usuario, trabaJo en colaboraci6n. distribuci6n, persistencia, gestl6n de la memoria, procesamiento de transiciones, seguridad, integridad yotros. Los componentes pueden proporcionaro requerir uno 0 mas "detalles de aspecto~ relacionados con un aspecto particular, como un mecanismo de visi6n, acceso extensible y tipo de interfase (aspectos de la inlerfase con el usuario): generaci6n, transportaci6n y recepd6n de eventos (aspectos de distribuci6n); almacenamiento/recuperad6n e indizaciOn de datos (aspectos de persistencia); autentificaci6n, codificacl6n y derechos de acceso (aspectos de seguridad): atomicidad de la transacci6n,

..

PARTE UNO

D.

I'II()C:E';()

eEl. sa'1WARE

control de concurrencia y control del transporte !aspectos de transacd6n), y as! sucesivamente. cada detalle de aspeclo tiene una serle de propiedades en relad6n con caracterlsticas ~rsonales y no runcionales del detalle.

Hasta ahara no se ha concretado un proceso orientado a aspectos diferenle. Sin embargo, es probable que tal proceso adopte caracterlsticas de los modelos de proceso en esplraJ

y concurrente

(seccianes 3.4.2

y 3.4.3),

La naturaleza evolutiva del

modele en espiral es apropiada cuando se identifican y construyen los aspectos. La

naturaleza paralela del desarrollo concurrente es esencial porque los aspectos se desarrotlan de manera independiente de los componentes del sonware localizados y. aun as!. los aspectos tienen un impacto directo sobre estos componentes. Por 10
tanto, resulta esencia! implementar una comunicaci6n asincr6nica entre las actividades del proceso de software aplicadas al desarrollo y la construcci6n de aspectos

y componentes,
Si se desea conocer una exposici6n detal!ada del desarrollo del software orientado a aspectos, se recomienda remitirse a Iibros dedicados a esta materia. El lector interesado puede consultar [GRA03], [KIS021 0 [ELROlj.

~
pro<e~

Gest16n deJ proceso Qbietivo: Ayudor en 10 definici6n, ejecuci6n

y ge$ti6n de

los modekn prescrip/ivo$ del

MecOnka: los herromi.-.lOs de gesIi6n del pnxeso p.<mifen q .... uno <><"9""iu.ci6n 0 equipo de softwore defino un rnoOeIo ~ de pt'OC8lO del software [octividodel dejmgn;:o de irtIbajo, Ioreas de o~rtlmienlo de 10 colidod, puntos de verificoci6n, fvndomenlos y pnxIuctos de Irobaio). Adem6s, los herromienlo! proporcionon uno guio mientros los ingcnieros de IOftwore hocen ellrabajo tecnico y uno plantillo para 105 gerenles, que deben rastrear y conlrolor II prQCe$O de software. Herramienta. repre.entatiYG. 11
La GDPA, uno serie de herromien/cJs para Jo clefinki6f1 del proceso cIe invesligociOn, ~rrollodo en 10

UliYenidod s..n.n .-. AIemonio (www.inbmotik.unibremen.de/uniformlgdpo/ home.hlmj,propotciona un omplio espedro de funciones pato.l 11Iadeiodo y 10 QO$ti6n del procmo.

s,-o..,

po< (www.~.coml. induy.

uno _ie de herromicnlos poro 10 definici6n del pnxflO, gesti6n de los requisiloS, resoIuci6n de corocterfllico5, pIoneoci6n del proyecto y seguimiento del mismg.

"""""'!ado

s,- "'" Co<pomt;on

Step Gale Pnxe", de$CIrrollodo por Objlxis (www.objexis.comj, inclvye muchas herromientos que ayudan en Ia automolizoci6n del Rujo de trobaja. En elsilio de Internet http://20S.2S2.62.38/English/ [).ProceuNototion.htm as posible enconlror uno valiOSQ exposici6n IIObre los 1MIodos y Ia notoci6n que WI puede U$CIr para dehnir y describir un modelo cornpIeto

<101_.

13 \.as herramientas mendonadas aqul representan un mue:streo de esta calegoria En 1a mayorfa de los casos 10$ nombres son marcas registradas de sus respectlvos desarrolladores

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 uguiado per los casos de usa, de arquitectura centrica, iterativo e incremental Estos autores establecen:
H

En la actuaJidad 131 tendencia en el software se encamina a sistemas mayores y comple)os Eso se de~ en parte al hecho de que las computadoras se volv\an mas poderosas cada 311'10, 10 que alentaba que los usuarios esperaran mas de elias Esta tendenda tambilm Ja

Impuls6 el uso expandido de Internet para el intercambio de todo tipo de informaci6n

Nuestro apetito por un software cada vez mas complejo erece en 131 medida en la que
aprendemos c6mo puede mejorarse un produc\o desde que sale uno hasta que Hega eJ

olIo. Necesltamos un software que se adapte mejor a nuestras necesidades, pero que, a su vez, haga el software mas complejo. En resumen, queremos mas.

De alguna manera, el proceso unificado (PU) es un 'ntento encaminado a reunir los mejores rasgos y caracterlsticas de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principlos del desarrollo ~gll de software (capitulo 4). EI proceso unificado reconoce la importancia de la
comunicad6n con el cliente y los metodas encaminados a describir el punta de vista del cliente can respecta a un sistema (por ejemplo, el caso de U50 1.) . EI PU enfatiza el importante papel de la arquitectura de software, y "ayuda al arquitecto a enfocarse en las metas correctas, como el entendimiento, el ajusle a los cambios futuros y la reutilizaci6n" UAC99]. Sugiere un flujo de proceso iterativQ e incremental y que propordona el sentido evolutivQ esencial en el desarrollo del software modemo. En esta secci6n se presenta una visi6n general de los elementos clave del proceso unificado. En la parte 2 de este texto se analizan los metodos que pueblan el proceso y las tecnicas y nolaciones complementarias del UML, le las cuales se requieren al aplicar el proceso unificado en el trabajo real de la ingenieria del software.

3, 6,1 Una breve historia

Durante la decada de 1980 y aJ principia de la decada siguiente, los metodos y lenguajes de programaci6n orientados a abjetos (00)16 obtuvieron una amplla difusi6n entre [a comunidad de Ja ingenierla del software. Durante el mlsmo perioda se pro-

14 Un caso de uso (capitulos 7 y 8) es un contexto narrativo 0 plantilla que describe una caracteristica o (undOn del sistema desde el punta de vi5l.a del usuario. El caso de uso 10 escribe el usuario Y sllve como una base para 15 El UML (urujitd Madding LD~ se ha convenido en ]a

1a creaci6n de un modelo de analisls mas completo. notacI6n mas utilizada para el modeLado del

an.ilisis Y el disdlo. RqKe5enta una uni6n entre Ires importantes notadones orientadas a 00jeI0s 16 Si ellector no se encuentra familiarizado con los metodos orientados a ob,etos. en los caprtulos 8 Y 9 se presenta una breve revisi6n general de ellos Para una presentaci6n m as detallada vease

IREf021lSTIOl] 0 IFOW99I

PARTE UNO EI. PROCESO DEL SOFTWAR!

puso una amplia variedad de antllisis y diseno orientados a objetos (AOO y 000) Y se introdujo un modele de proceso orientado a objetos de prop6sito general (similar a los modelos evolutivos presentados en este capitulo). AI igual que Ja mayorla de los paradigmas "nuevas" para la ingenieria del software, [as seguidores de cada uno de los metodos de ADO y 000 argumentaban acerca de cllal de ellos era el mejor, pero ningun metoda 0 lenguaje domin6 la escena de la ingenieria del software. AI principia de 1a decada de 1990, James Rumbaugh IRUM91!. Grady Booch 180094] e Ivar Jacobson UAC92] comenzaron a tTabajar en un "metoda unificado" que combinaria las mejores caracterlsticas de cada uno de sus metodos individuales

y adoptarfa caracteristicas adicionales que propusieran otros expertos (por ejemplo,

[WJR901l en el campo 00. EI resultado fue ellenguaje de modelado unificado (UML, por sus siglas en ingles) -que conliene una notaci6n robusla para el modelado y el desarrollo de sistemas 00-. Para 1997. el UML se convirti6 en un estlmdar de la industria para el desarrollo de software orientado a objelos. AI mismo tiempo. Rational Corporation y otras fionas desarrollaron herramientas automaticas para apoyar los m~todos del UML EI UML proporclona la tecnologla necesaria para apayar la pr.ictica de la ingenieria del software or\entada a obielos. pero no provee el marco de trabajo del proceso que gule a los equipos en la apUcaci6n de la tecnologla . En los arios siguientes. Jacobson, Rumbaugh y Booch desarrollaron el proccso unificodo. un marco de Irabajo para la ingenierfa del software orientada a objetos. mediante la utilizaci6n del UML. En la actualidad. el proceso unificade y el UML se emplean de forma amplla en proyectos 00 de todos los tipos. EI modele iterativo e incremental que propane el PU puede y debe adaptarse para satisfacer necesidades de proyecto espedficas. COmo consecuencia de la aplicaci6n del UML se puede prooucir un arreglo de productos de trabajo (por ejemplo, modelos y documentos) . Sin embargo. estos los reducen los ingenieros de software para lograr que el desarrollo sea mas agi] y reactivo ante el cambio.

3.6.2

Fases del proceso uniticadol7

se han analizado cinco actividades genericas del marco de trabajo y se ha explicado que estas se pueden aplicar para describir cualquier modelo de proceso del software. EI proceso unificado no es la excepcl6n. En la figura 3.7 se muestran las "rases" del proceso unificado (PU) y se relacionan con las actividades genericas que se trataron en el capitulo 2.
La rase de inido del PU abarca la comunicaci6n con el cliente y las actividades de planeaci6n. AI colaborar con los clientes y lISuarios finales se identifican los requisitos de negocios para el software, se propane una arquitectura aproximada para el

17 Algunas veces el proceso unificado se llama proceso unlf\cado racional (PURl despui!!s de que 10 respaldara la Rational Corporation. un contribuyente Importante en el des.arrollo y refinamiento del proceso y un constructor de ambientes completos ]herramienlas y tecnologla).

..
sistema, y se desarrolla un plan para la naturaleza Iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a traves de W\ c:onjunto preliminar de casos de usa que describen cuAles caracterlsticas y fun dones son deseables para cada clase importante de usuarios. En general, un case de usa describe una secuencia de acciones que desarrolla un aCior (por ejemp!o, una persona, una maquina. atro sistema) ruanda este interactua can el sonware. Los casas de usa ayudan a identificar el Ambito del proyecto y proporcionan una base para la planeaci6n de este. En este punto. la arquitectura no es mas que un esquema tentativo de los subsistcmas mas importantes y de las fundones y caracteristicas que los forman. Despues, 1a arquitectura se refinara y expandira en un (anjunto de modelos que representa ran visiones diferentes del sistema. La planeaci6n Identifica recursos, evalua los ries-

gos importantes, define un itinerario y establece una base para las fases que se aplicaran con forme se desarrolie el incremento del software, La fase de elaboraci6n abarca \a comunicad6n con el dienle y las actividades de modelado del modelo generico del proceso (figura 3.7). La elaboraci6n refina y expande los casos de uso preliminares que se desarrollaron como una parte de la fase de lnicio; ademas, expande \a representaci6n arquitect6nica para incluiT cinco
visiones diferentes del software : el modelo de caso de USO, el modele de analisis, el modele de diseno, el modele de implemenlaci6n y el modele de despliegue. En algunos casos, Ja elaboraci6n crea una ullnea de base arquitect6nica ejccutable~ iARLOZI que representa un sistema ejecutable en su ~primer corte",l$ la linea de base arquitect6nica demuestra la viabilidad de la arquitectura, pero no proporciona todas las

lanwmi."to

I'~-""""' I \
18 Es importante destacar que La directriz arquitect6nlca no es un prototJpo que se deseche (secci6n
3 .. I) . En lugar de ello la directriz se aprovecha durante la siguiente rase del PU

--

70

PARTE UNO

IJ. ~ DEL SOI"tWARf:

caracteristicas y fundones necesarias para utilizar el sistema. Adem;is, el plan se revisa de manera cuidadosa al termino de la rase de elaboraci6n para asegurar que
el ambito, los riesgos y los datos entregados a(m son razonables. las modificaciones a1 plan se deben hacer en este momento. La rase de conslrucci6n del PU es identica a la actividad de construcci6n definida para el proceso gentrieo del software. 5i se utiliza el modele arquitect6nico como entrada, la rase de construcci6n desarrolla 0 adquiere los componentes del softwa+ re que haran que cada caso de usa sea operativ~ para los usuarios finales. Lograr esto requiere que los modelos de analisis y disef'io iniciados durante la rase de elaboraci6n se completen para renejar la versi6n final del incremento del software. Todas las caracterfsticas y fundones ne<:esarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en cMlgo fuente. Confonne los componentes estan en proceso de implementaci6n, se dlsenan y ejecutan pruebas de unidad para cada uno de ellos. Ademas. se realizan las actividades de integraci6n (ensamblaje de componentes y pruebas de integraci6n). Los casos de uso se utHizan para derivar un conjunto de pruebas de aceptaci6n que se ejecutan antes del inicio de la siguiente rase del PU. La fase de transici6n del PU abarca las (ilUmas etapas de 1a activldad genertca de construcci6n y la primera parte de la actividad generica de despliegue. EI software se entrega a los usuaries finales para realizar pruebas beta, 19 Y 1a retroalimentaci6n del usuario reporta tanto defectos como cambios necesarios. Ademas, el equipo de software crea la infonnaci6n de soporte necesaria (por ejemplo, manuales del usuario, gufas de resoluci6n de problemas, procedlmientos de instalaci6n) para ellanzamiento. AI final de la fase de transici6n, el incremento de software se canvierte en un lanzamiento de software utilizable.
La fase de producci6n del PU coincide can 1a actividad de despliegue del proceso

generico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativ~ (infraestructuraJ, y se reeiben y evaluan los informes de defectos y los requerimientos de cambios. Es probable que mientras se realizan las fases de construccl6n, transici6n y producci6n ya se hayan iniciado los trabajos para el siguienle incremento del software. EsIO significa que las cinco fases del PU no suceden en una secuencia, sino en una concurrencia por etapas. A 10 largo de las fases del PU se distribuye un flujo de trabajo de ingenierla del software. En el contexte del PU, unjlujo de trabaJo es analogo a un conjunto de tareas (definida en el capitulo 2). Esto es. un flujo de trabajo ldentifica las tareas necesarias para completar una acci6n importante de ingenierla del software y los productos de

19 En ta prueba bdo, una acci6n de prucha controlada (capitulo 13), el sonware 10 utilizan usuarios fma-

Ies reales. con la intenciOn de descubrir defectos y deficicnaas Se establece un esquema de infonne de derectos y derlCiencias de manera ronnal. y e] eqwpo de software evalua la retroalimentaci6n.

cAPhvLo 3

MOOEL05 PRESCRlPIl'lOS DE PIIOCE3J

11

trabajo que se producen como consecuencia de la reallzaci6n exltosa de tareas. se debe destacar que no todas las tareas ldentificadas para un flujo de trabajo del PU se realizan para cualquier proyecto de software. EI equipo debe adaplar el proceso (acciones, tareas, subtareas y productos de trabajo) para satisracer sus necesidades.

3.6.3

Productos de trabajo del proceso unlflcado

En la flgura 3.8 se ilustran los productas de trabajo clave que se produjeron como consecuencia de las cuatro fases t~cnicas del PU. Durante la fase de inicio, el prop6sito es establecer una "visi6n" general para el proyecto, identificar un conjunlo de requisitos de negocios, fonnar un caso de negocios para el software y definir los riesgos del proyecto y del negocio que pudieran representar un abstacula para el exilO. Desde el punta de vista del ingeniero de software, el produclo de trabaja mas importante generado durante la etapa de inlclo es el moddo de coso de u.so: una colecd6n de casos de uso que describen la fonna en que actores externos ("usuarios" humanos y no humanos del software) interactuan can el sistema y abtienen valor a partir de ~ste . En esencia, el modelo de casos de usa es una colecd6n de esccnarios de usa con plantillas estandarizadas que implican caracterfsticas y funciones del software mediante la descripci6n de una serie de condiciones previas, un flujo de evenlO:l a un escenario, y un canjunlo de condiciones exteriores para la interacci6n represenlada. En un inido, los casos de uso describen requisitos a\ nivel del dominio de negocios (por ejemplo, el grado de abstracci6n es alto) . Sin embargo, el modele de casas de usa se retina y elabora conforme cada fase del PU se ejecuta y sirve como una entrada Importante para 1a creaci6n de productos de trabajo subsecuentes. Durante 1a fase de Inicio s610 se completa enlre el lOy 20 por ciemo de los casas de uso. Despues de la elaboraci6n, se ha creado entre un 80 y 90 por denio del modelo. La fase de elaboracl6n produce un conjunto de productos de trabajo que elabora requisitos (incluse requisltos no funcionales~, asl como una descripci6n arquitect6nica y un diseno preliminar. Cuando el ingeniero de software inicia con el analisis orientado a objetos, el objetivo primordial es detinir un conjunto de c1ases de analisis que describan en forma adecuada el comportamiento del sistema. El modelo de ami/isis del PU es un producto de lrabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y analisis (colecciones de clases) definidos como una parte del modelo de analisis se retinan despues en un modelo de diseno, el cual identifica dases de diseno, subsistemas y las interfases entre los subsistemas. los modelos de analisis y diseno expanden y retinan una representaci6n evoiutiva de 1a arquitectura del software. Ademas, en la fase de elaboraci6n se revisan los riesgos y el plan de proyecto para asegurar que cada uno de elias conserve su validez . La fase de construcci6n produce un modelo de implementaci6n que traduce las dases de diseno en componentes de software que se construiran para ejecutar el sis-

20 Rcqulslt05 que no se pueden deducir del modelo de caso de uso

72

PARTE UNO

El. PRO:ESO DEL SOFTWARE:

.... cI. inicio

p od""""" babajo poduddoo

o.x- de Ia viW6n
MocWo iniciol de coso do_ Gboroo ,nicioI
CO$O

,.. "'1

1'1

MocWode ~.- '*'

_acado tase del PU.

.... .....,nocloI ..
cWn.5g0

MgOcic>

&aIuoco6rl iouciaI

............ MocWo ..
pAOh..w.or

R ...... , I

~deJo

PIon 0. .-,..:10.
ModeIo del
Uno

Fo- iIwacionM
~io

Ii .. neceoario 0 ..0. protOIipcn

-~z:..o--;:
diMo\o
ftollde~~

UIID ___ de fiMp

-. _ _
. . ~ .... IIO

.,.=ioo.

,....

c_tn.ocdOtl

MocWo del d,oeo'io Coo''PO'_ del

,.. .... II'

--"
~u'

a.6Io...

.... -. .... -. ......... PIon proc.d"....,,1D

~

.....-do-'
......... "" pn.oeOot

do ........ COOOll de prueba

pig,. de ilwOO6ft 8ujo& dol w.bajo..",...

~

......
....

...........

...

..........

.....

I oIati600 ......

ptOdudo. Ncnic...

Mar.....I ....

mon ..... deI_1o ~. eN InllOloci6n d.K>'I~ del ille_1O oetuoI

p"....nar

tema, y un modelo de despliegue convierte los componentes en el ambiente fIsko de computaci6n. Por ultimo. un modele de prueba describe [as pruebas empleadas para asegurar que los casas de usa se reflejen de manera apropiada en el software que se ha construido.
La fase de transici6n entrega el incremento del software y evaJua los productos

de trabaja elaborados durante la elapa en que los usuarios finales trabajan con el software. En esta etapa se produce 1a retroalimentaci6n proveniente de las pruebas beta y los requerimientos cualitativos de camblo,

Los modelos prescriptivos del proceso de software se han aplicado durante muchos alios en un esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cada uno de estos modelos convendonales sugiere un Oujo de proceso que de alguna forma es diferente, pero todos realizan el mismo conjunto de actividades genericas del marco de trabajo: comunicaci6n, planeaci6n, modelado, construcd6n y despliegue. EI modelo en cascada sugiere una progresi6n lineal de actividades del marco de trabajo que a menudo resulta inconsistente con Ja realidad modema en el mundo del software (por ejempla, can el cambia con tinuo, los sistemas en evoluci6n, las fechas de entrega restrtngidas). Sin embargo, este modelo se puede aplicar en situacianes en las cuales los requisitos estan bien definidos y son estables.

73

Los modelos incrementales del proceso de software producen software como una
serie de entregas de incrementos. EI modelo ORA esta disef\ado para proyectos grandes que se deben entregar en marcos de tiempo muy reducidos.

Los modelos de proceso evolutivos reconocen la naturaleza evolutiva de la mayoria de los proyectos de ingenieria del software y eslan disei'lados para ajustarse al cambio. Los modelos evoluUvos, como el de conslruccl6n de prolotipos y el modele en espiral, generan productos de trabajo incrementales (0 versiones del software en funcionamiento) con rapidez. Estos modelos se pueden adaptar para aplicarlos a trav~s de todas las activldades de la ingenieria del software: desde el desarrollo de con-

ceptos hasta eJ mantenimiento del sistema a largo plazo.

EI modelo basado en componentes destaca la reutilizacl6n y ensambladura de

componentes. Los modelos de metodos formales conducen a la utilizaci6n de un enfoque basado en las matematicas para el desarrollo y la verlficacl6n del software. El modelo orientado a aspectos inc\uye los intereses generales que cubren la arquitectura total del sistema. EI proceso unificado es un proceso de software "guiado por los casos de uso, de arquitectura centrica, iterativo e incremental" disef\ado como un marco para los metodos y herramientas del UML. EI proceso unUlcado es un modele Incremental en el que se definen cinco rases: I) una rase de inicio que abarca la comunlcaclOn con el ,liente y las activldades de planeaci6n, y destaca el desarrollo y el refinamiento de casas de uso como un modele primario; 2) una rase de e/aborod6n que abarca la comunicad6n can el cHente y las actividades de modelado con un enroque en la creaci6n de modelos de analisis y disena, can cnfasis en las definiciones de ciase y representaciones arquitect6nicas; 3) una rase de constnJcd6n que retina

y despues traduce

el modele de disef\o en componentes de software implememados; til una rase de tronsici6n que transfiere el software del desarrollador al usuario tinal para realizar las pruebas beta y obtener la aceptaci6n; y 5) una fase de proclucci6n en la eua! se realiza el monitoreo continuo y el soporte.

[AMB02] Ambler, S. y L. Constantine, The Unified Process Inception Phase, CMP Books. 2002. [ARL021 Arlow, J. e I. Neustandt. UML and the unljled Process, Addison-wesley. 2002. [BAC97] Bach, J.. "Good Enough Quality: Beyond the Buzzword", en IEEE Computer, vol.30, num . 8, agosto de 1997, pp. 96-98. [WE881 Boehm. B.. "A spiral Model for Software Development Enhancement", en Compuler, vol. 21, num. 5. mayo de 1988. pp. 61-72. IBOE98] Boehm, B. "Using the WINWIN Spiral Model: A Case Study". en compuler, voU, num.7, Julio de 1998, pp. 33-34. lBaEOIJ Bohem. B, "The Spiral Model as a Tool for Evolutionary Software Acquisition", en Cross'nJlk, mayo de 2001, disponible en http://www.stsc.hill.afmil/crosstalkl2001/05/ boehm.html. IB00941 Booch, G . Objecl-Orienled Ana~s and Design. 2a ed . Benjamin Cummings. 1994. (BRA94] Bradac, M., D. PetTy YL votta. "Prolot)ping a Process Monitoring Experiment", en IEEE Th:m5. SqftwureEnginemrlg, vol. 20, nUrn. 10, octtiJre de 1994, pp. 774-784 IBR0751 Brooks, F., The Mythical Man-Month, Addison-wesley, 1975

74

PARTE UNO

El. PRIXESO DL SOFTWARE

IBUT94/ Butler, J., ~Rapid Application Development In Action", en Monag1ns ~em [)ev(!/opmt!nt, Applied COmputer Research, vol. 14, num.S, mayo de 1994, pp. 6-8. IDYE 921 Dyer, M ., The Cleonroom Approach 10 QualIty Software Development. wiley, 1992. IELROI] EJrad, T., R. Filman y A. Bader (eds). "AspectOriented Programminlf, en Comm. AeM, vol. 44, nUrn. la, oclubre de 2001, edici6n especial. IFOW991 Fowler, M y K. Scott, UML Distilled, 2a ed., Addison-wesley, 1999. IGIL..88J Gilb, T , PrinCIples Of Software Engm~ring Managemenl, Addison-wesley, 1998. IGRAOJI Gradecki, 1. y N. Lesiecki, Mastering ltsptJ' Aspecl-Onented Programming in Java, Wiley, 2003. IGRU021 Grundy, J., "Aspect-Qriented Component Engineering". 2002, http://www,cs. auckland.

lK.nzl -john-g/aspects.hlm!.
IHAN9S1 Hanna, M., "Farewell 10 Walerfalls~. en software Magazine, mayo de 1995, pp. 38-46. lHES96] Hesse, W., "Theory and Practice of the SoAware Process-A Field Study and ils Implications for Project Management", Software Process TechnoJogy, 5th EuropMn Workshop, EWSPT 96, Springer ilKS 1149, 1996, pp. 241-256, IHES011 Hesse, W., "Olnosaur Meets Archaeopteryx? Seven Theses on Rational's Unified Process (RUP)", en Proc. 8th Inti. workshop on Evaluation Of Modeling Methods in System Ana[ysis and Design, Ch. VII Interlaken, 200 I. [/AC92] Jacobson, I., Object-Oriented Software Engineering, Addison-WesJey, 1992. UAC'J9J Jacobson, I., Booch, G. Y J. Rumbaugh, Tile unified Software Development Process, Addison-wesley, 1999. [KAU95] Kauffman,S., At Home in /he Un~, Oxford, 1995 (KER941 Kerr,). y R. Hunter,lnside RAn, McGraw-Hill, 1991 . ]MAR91J Martin, j., Rapid Application Devdopmenl, Prentice-Hall, 1991. [McDE93] McDermid J. y P. Rook, ~Software Development Process Models" , en Software Engineer's Reference Book, CRC Press, 1993, pp. 15126-15128 [MILa7] Mills, H.D., M. oyer y R. Unger, "Cleanroom SOftware Engineering-, en IEEE Sojtware, septiembre de 1987, pp, 19-25, ]N1E92J Nierstrasz, 0 ., S. Gibbs Y D. Tsichritzis, "Component-Oriented SOftware Development", en ~CM, vol. 35, num, 9, scptiembre de 1992. pp. [60- 165 INOGOO] 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 2(0), disponible en htlpl lwww.dodccrp.orgI2000CCRTS/cd/html/pdCpapers/1l'ack....4/075.pdf. IREE02] Reed. P. lkVeloping Applico/Jons with Jova and UML. Addison -Wesley. 2002. IREI95J Reilly, J, P., "Does RAD Uve Up Ih the Hypew , en IEEE Software, septiembre de 1995, pp. 24-26. [ROO%J Roes, J., "The Poised Organization: Navigating Effectlvely on Knowledge Landscapes', 1996, disponible en hllp:llwww.imd.ch/fac/roos/paper..po.html [ROY70! Royce, W.w., "Managing the Development of Large Sonware Systems: Concepts and Techniques" en, Proc. WESCON, agosto de 1970. [RUM91] Rumbaugh, J. <=t al., Object-Oriented Modeling and Design, Prentice-Hall, 199\. [ST1011 Stiller, E. y C. leBlanc, Projecl-Based Soflware Engineering: An Object Oriented Approach, Addison -Wesley, 2001 . [WIR90] Wlrfs-Brock, R., B. Wilkerson y L Weiner, Designing Object-Oriented Software, PrenticeHall,199O. [YOU94] Yourdon, E., "SOftware Reuse", en Applicalion Development Strategies, vol. 6, nUm. 12, didembre de 1994, pp. 1-\6. fYOU9SJ Yourdon, E. , "When Goood Enough Is Best" , en IEEE Software, vol 12, num. 3, mayo de 1995, pp. 79-81

3.1, Leer (NOGOO] y escribir un documento de dos 0 tres paginas que trate sobre el impacto del "caos" en la ingenieria del software.

U. Dar tres ejemplos de proyectos de software que pudleran adaptarse al modelo en cascada Scr especifico.
3.3. Proporcionar tres ejemplos de proyectos de software que pudleran adaplarse al modelo Goe construcci6n de prototipos. SeT especlfico. 3.4. ,Cuales adaplaciones se requieren en el proceso $1 el prololipo evolucionara hacia un ....sttma 0 producto que puede entregarse? 3.5. Para lagrar un desarrollo rapido el modelo DRA asume la exislencia de una cosa. ,eual es

por que dicha suposici6n no siempre es verdadera?

3.6. Proporcionar Ires ejemplos de proyectos de software que pudieran adaptarse al modelo ncre:mental Ser espectfico.
3.7.,Que se puede decir acerca del software que esta en desarrollo rruentras se avanza hacia fuera del flujo de proceso en espiral?
0

en mantenimiento

3.8. posible combinar modelos de proceso? 5i la respuesta es alirmativa, menci6nese un rjmlplo. 3.'. El modelo concurrente del proceso deline un conJunto de "estados". Describir con palabras propias 10 que representan estos eSlados, y dcspues Indlcar c6mo entran en Jucgo denim del modelo concurrente del proccso. 3.10. ,Cutiles son las venlajas y desventajas de desarrollar software para el cualla caUdad es "10 $ulicientemente buena ~? Esto es, "que pasa cuando Sf'! resalta la veloddad del desarrollo sobre la caUdad del proyecto? 3.11. Proporcionar tres ejemplos de proyectos de software que pudieran adaptarse al modelo basado en componentes. Ser especlfico.
3.12. Es posible probaT que un componente de software 0 incluso un programa completo estti correclo. Entonces, "por que no todos 10 hacen?

,Es

3.13. Exponer con argumentos propios el significado de ~ intereses generale s- La ilerativa sobre el ADP se expande con rapidez. Investigar y escribir un documento breve sobre la siluaci6n actual.
3.14. ,EI proceso unificado y el UMLson la misma cosa? Explicar la respuesta.

3. 15. "Cutil es la diferencla entre una fase del PU Y un fluja de trabaja del PU?

La mayor parte de los texlos sobre ingenierta del software consideran los modelos prescrip tivos de proceso con algun detalle. Los libros de Sommerville (software Engineering. sexla edici6n, Addisonwesley, 2000), Ptleeger (software E:ngineering: Ttl~ry and Practice, Prentice Hall, 2001), y Schach (Object Qriented and QassicaJ Software Engineering, McGraw HIII, 2001) consideran los paradigmas convencionales y analizan sus fortalezas y debilidades. A pesar de que no se dedlca en forma especlfica al proceso, 8rooks (The MyIflicol Man -Montfl, segunda edicl6n, Addisonwesley, 1995) presenta la experiencla ganada en proyectos antiguos que Ilenen una gran relaci6n con el proceso. Firesmith y HendersonSellers (Ttle OPEN Process Framework: An Introduction, Addison-Wesley, 2001). presenta una plantilla general para crear "procesos de sofiware nexible, pero. aun asl. indisciphnados~ y analiza los atributos y objetivos del proceso.
Sflarpe y McDermott (l1t;lf~oW Modeling: 7lJoIs.for Process ImprrJIIen}{!fI/ and Application /kvdopmen(, Artectl House, 2001) presenlan herramientas para e/ mode/ado de procesos de 50ftware y negocios. Jacobson Griss y Jonsson (sqtwore R~, Addison.Wesley, 199n y McClure (Sojtwore Reuse ~niqlMS. PrenticeHall, 1997) presentan mucha informad6n util

7.

PARTE UNO

fl

PIlOCESO DEl. SOfiWARf

sobre el desarrollo basado en componentes. Heineman y Council tcomponml~Based Sojtwore Engineering, Addison-wesley, 2001) describen el proceso requerldo para Implementar sistemas

basados en componentes. Kenelt y Baker CSt?ftwan: Process Quality,

Man~ent

and Control,

Marcel Dekker, 1999) consideran la fanna en que la gesti6n de calidad y eI diseno de proceso estan coneclados en forma Intima entre sl Ambriola (Software Process 1h:hnoIogy, Springer-Verlag, 2001), Oemiame y sus colegas

(Sojhvare Process: PrindpJes. Methodology. and RdmoIogy, Springer-verlag, 1999) presenlan conferencias ediladas que induyen muchos aspectos te6ricos y de investigaci6n y que son
relevantes para el proceso de software.

Jacobson, Booch y Rumbaugh han escrito el libra fundamental sobre el proceso unificado
UAC99J. Sin embargo. los libros de Arlow y Neustadt [AR1.02] y una serle de tees volumenes de Ambler y Constantine [AMB02J ofrecen una excelente informacl6n complementaria, Krutchen (The Rational Unified Process, segunda edici6n, Addison-wesley, 2000) ha escrito una valiosa introducci6n al PU. La gesti6n de un prOye<:to dentro del contexto del PU esta escrita en detalle por Royce (SOftware Project Management: A unified Fram(:Vol(}rk, Addison-Wesley, 1998). La

descripci6n deflnitiva del PU la ha desarrollado la Rational Corporation y esta disponible en linea en www.ralional.com. En Internet exisle una amplia variedad de fuentes de infonnad6n sobre la lngenieria y e[ proceso del software. En el silio web de SEPA se puede encontrar una Usta actualizada de referencias en la red mundial que son relevantes para el proceso de software:

http://www.mhhe.com/pressman.

CAPiTULO

DESARROLLO AGIL

n 2001, Kent Beck y alros 16 notables desarrolladores, escritores y consul tores [BECOI) (conocidos como Ja ~Alianza Agiln) firmaron e! "Manifieslo para el desarrollo agil de software" el cual estableda:

.
n

H~mos descubierto mCJores formas de desarrollar software a\ construirlo por nueslra

cuenla y a)'ldar a olros a hacerlo. PQr mediO de este tTabajo hemos lIegado a valorar A los mdMJu(ls Y sus inferacdonCs sobre los procesos y las hClTamienlas AI

sojIware t'tl jimcionatniento sobre la documentaci6n extensa.

"
AI

A la co/aboraci6n del ditmte sobre la negociaci6n del centralo. Ala fr:5Pues1a a/ cambio sobre el seguimiento de un plan.

Eslo es, aunque 10$ terminos a la derecha tienen valor, nosotros valonlmos ma5 \os a5pe<tos de la izquierda

.. ....,
AI

Un manifiesto se asocia por 1 0 general con un movimiento politico emergen

_ _

..... .. .v

Ie: aquel que ataea a la vieJa vanguardla Y sUgIere un camblo revoluclonano (en eJ mejor de los casos para mejorar), De alguna (anna, esto es con exactltud de 10 que se Irala el desarrollo agil A pesar de que las ideas subyacenles que conducen al desarrollo agllilan es~ {ado presentes por muchos anos, no ha sido sino hasta la decada pasada que es~ tas ideas han cristalizado en un Hmovimienlo" En esencia, los me-Iodos agHes l
se desarrol1aron en un intento por superar 1[1:5 dcbmdadc5 advcrtldas y rcalcs en

la ingenieria del software convencional. El desarrollo agH proporciona beneficios importanles, pero es imposible aplicarlo en lodos los proyectos, productos, personas Y siluaciones.
LQue ..? La ingIrNena de taft..r.o. re Ogil combino una fito.ofIa y un con~de di~ d. cI.orroIo.
comuruaxi6n achvo y continuo entre

, ..... Ia ....., los ingenieros de software y to Q busca 10 _ dol otros porticipontlls del proyedO (gerenles, clian d;en,. y 10 _ _ _ de 00II,. Y UWQfIO' finales) trobojon juntos en un $quiwen incremental; equipos de proyedo peqIII"" po 6oi1 un equipo con orgonizoci6n propio y que controla IU propio destino. Un eqoipo 6g j( r.o. y con alto motivoci6n; I1'I6todot infDrmoIes; fomenID 10 c:ornunicoci6n Y10 c.oloboroci6n entre un ft'I nimo de pnxjudo$ de Inlbojo d. Ia .,... trodot lot que Irobajon en et, _ " del ""-'e; y uno . .;dad goneod dol de.. rroIla. to, <1;_ de .............. " . . . , . _ impartante? EI ambienle moderIan 60 entrego sabre eI cmfi.is Y., diSIIfto (CUI no lot negoc~ ocosiono que 10' sistemas bosados .. compuIodoros y los productos de que eslas octividades no 58 d.c:arbtl. y Ia

noItadom y"" cr........

los desa-

I II los ~todos 'gIles algunas v&\!:s se !es llama metodos ligffos o/ivianos

77

7.

PARTE UNO EL f'ROC!SO tEL SOFTWARE

No es la antltesis de la practica s6lida de la ingenieria del software y es posible aplicarla como una fllosofla predominante para cualquier trabajo de software. En la economia modema, a menudo resulta dillcil 0 imposible predeclr c6mo evo-

iucionartm con el tiempo los sistemas basados en computadoras (por ejemplo, las
aplicaciones Web). las condiciones del mercado cambian con rapidez, las necesida des de los usuarios finales evolucionan, y las nuevas amenazas competitivas emergen sin previa aviso. En muchas situaciones ya es imposible delin!r por completo los requisitos antes de que comience el proyecto. Los ingenieros de soltware deben seT tan aSUes como para responder a un ambiente de negocios fluido. <.1..0 anterior significa que el reconocimiento de estas realidades modemas ocasiona que se descarten los valiosos prtncipios, conceptos, metodos y herramientas de la ingenierla del software? No, jen 10 absolutOj COmo todas las disciplinas de ingenierla, la ingenierfa del software continua en evoluci6n . Se puede adaptar con faci lidad para enfrentar los retos que implica una exigencia de agilidad.

0.'
En un libro que invita a la reflexi6n y trata sobre el desarrollo agil de software, Alistair Cockburn (COC02a] argumenta que los modelos prescriptivos de proceso presentados en el capitulo 3 tienen una falla importante: oJvidan las fragilidades de las personas que cons~ d software de computadoro. lOs ingenieros de software no son robots. Ellos muestran una gran variedad en los estilos de trabajo y direrencias significativas en su grado de habiJidad. creatividad, orden, consistencia y espontaneidad . Algunos se comunican muy bien en forma escrita, olros no. Cockburn argumenta que los modelos de proceso pueden "enfrentar las debilidades comunes de la genIe con disciplina 0 toleranda lalguna de las dOSl~ (COC02a), y que los modelos

7.
de proceso mas prescriptivos eligen la disciplina. EI establece: "Como la consisten~
da en la acci6n es una debilidad humana, las metodologlas que exigen un alto grado de disciplina son fragiles ICOC02a).
N

Los modelos de proceso funcionartm si proporcionan un mecanisme realista que

romente la disciplina necesaria. 0 deben estar caracterizados de manera que mueslren "toleranda" por la gente que realiza el trabaja de la ingenierla del software. De manera invariable, la gente de software adopta Y sosliene mas facilmente las practicas tolerantes, pero (como COCkburn 10 admite) tal vez sea menos productiva. Como Ja mayorla de las cosas en Ja vida, se deben considerar los Intercambios.

<.Que es 1a agilidad en el contexto del trabaja de la lngenlerla del software? [var Ja~
cobson UAC02J propordona una definici6n util:
Agilidad se ha convenido aetualmente en la palabra de moda en cuanto:le describe un

modemo proceso de software. Cualquiera es agi!. Un equipo agH es un equipo rapido que responde de manera apropiada a los cambios. tstos son, en gran parte,la maleria del desarrollo de software, cambi05 en e\ software que se vo. 0. con5lrulr, eamblQ$ en Ire los miembros del equipo, camblos debidos a las nuevas tccnologla:5, camblO:5 (Ie to do tlPO que pueden incidir en el produeto que se eonstruyt: 0 en el proyeclo que erea el producto. En cualquier actividad de software se debe induir un soportc para los cam_ bios, esto es algo que adoptamos porque es el alma y el eoraz6n del software. Un eqUipo igil reconoce que el sonware 10 desarrollan individuos que lrabajan en equipo yque las aptitudes de esla genie, y su capacidad para colaborar. son esendaLes para eL ~" i . 10 del proyecto, De acuerdo con la visi6n de Jacobson. la insistenda en el cambia es el conductor primordial hacia la agilidad, lOs ingenieros de software deben tener pies vcloce5 51

quieren a;ustarse a los cambios r<ipidos que describe Jacobson.

Pero la agilidad es mas que una respuesta efectiva at cambio. Tambien incluye la filosofla del manifiesto enundado al principia de este capitulo. Estimula las estructuras y actitudes de los equipos para que la comunicad6n (entre los miembros del equipo, entre los tecnicos Y la gente de negocios, entre los ingenieros de software y sus gerentes) sea mas faci!. Resalta la entrega rapida del software operativo y Ie resta importancia a los productos de trabajo intermedio (10 cual no siempre es bueno); adopla al cJiente como una parte del equipo de desarrollo y trabaja para eliminar la actitud del tipo "nosotros y ustedes~ que aun perjudica a muchos proyectos de software; reconoce que la planeaci6n tiene sus limites en un mundo incierto y que el plan de proyecto debe ser nexible.

80

PARTE UNO EL PRCC'ESO DEL SOfTWARE

La Alianza AgilIAGI03] define 12 prindpios para quienes quieTen alcanzar la agi-

Iidad:
I . Nuestra mayor priori dad es satisfacer al c1iente mediante la entrega temprana

y continua de software valioso.

2. Bienvenidos los requisitos cambiantes, incluso en rases tardias del desarrollo. La estructura de los procesos agiJes cambia para la ventaja competiliva del cliente. 3. Entregar con frecuencia software en funcionamiento, desde un par de serna-

nas hasta un par de meses, con una preferencia por la escala de tiempo mas
carta. 4. La gente de negocios y los desarrolladores deben trabajar juntos a diaria a 10

largo del proyecto.

5. Construir proyectos alrededor de individuos motivados. Darles el ambiente y el soporte que necesitan, y contiaT en elias para obtener el tTabaja realizado. 6. El metodo mas eficiente y efectivo de transmitir InformaciOn hacia y dentro de un equipo de desarrollo es \a conversaciOn cara a cara. 7. EI software en funcionamiento es la medida primaria de progreso. 8. LDs procesos agiles promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un paso constante de manera indefinida. 9 . La atenciOn continua a la excelencia tecnica y al buen diseno mejora la agilidad. 10. La simplicidad -el arte de maximlzar la cantidad de trabajo no realizado- es esencial. 11. Las mejores arquitecturas, los mejores requisitos y los mejores disenos emergen de equipos autoorganizados. 12. A intervalas regulares el equipo refleja la forma en que se puede valver mas efectivo; entances su camportamiento se ajusla y adecua en concardancia. La agiHdad se puede aplicar en cualquier proceso de software. Sin embargo, para lograrJo es esencial que el proceso sea disenado en una forma que permita aJ equipo del proyecto adaptar y coordinar las tareas, conducir la planeaciOn en una fo rma que entienda la tluidez de un enfoque de desarrollo agi!. 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 rapido como sea faclible para el tlpo de producto y el ambiente operativo.

81

Cualquier proceso dgil de software se caracteriza de una manera que refiere lres suposiciones clave IFOW02] acerca de la mayoria de los proyectos de software:

I. Resulta dilleil predecir cuales requisitos del software petsistlran y cuates cambiartm. De iguaJ forma, es diflell presagiar cbmo cambiaran las prioridades del cliente mientras se ejecuta un proyecto. 2. Para muchas

tipos de software, el diseno y la construcci6n estan inlercalados.

Eslo es, ambas actividades se deben realizar de manera conjunta, de modo que los modelos de disei'io sean probados conforme se crean. Resuita dificil

predeclr cuanto diseno se necesita antes de que la construcci6n se utilice para probar el diseno.

3. EI analisis, el diselio y la construcci6n no son predecibles (desde eJ punto de

vista de la planeaci6n), 1 0 que seria deseable. Dados los puntas anteriores, surge una pregunta importante: ,c6mo se crea un proceso susceptible de manipular en forma impredeclble? La respuesta, como ya :se ha puntualizado antes, reside en la adaptabilidad del proceso (a un proyecto y a condiciones tecnlcas que cambian can rapidez). Por 1 0 tanto, un proceso agil debe ser

adaptable.
Pero una adaptaci6n continua sin un progreso logra muy poco. Por 1 0 tanto, un proceso agil de software debe adaptarse en forma

incremental.

Para lIevar a cabo

una adaptaci6n incremental, un equipo agil requiere de la retroalimentaci6n can eJ c1iente (para que sea factible realizar las adaptaciones apropiadas). Un catalizador efectivo para la retroalimentaci6n del cliente es un prototipo operacional 0 una porci6n de un sistema operacional. Por 10 tanto, debe instituirse una estrategia incremen-

tal de desarrollo.

Los incrementos de software (prototipos ejecutables a una porci6n de

un sistema operacional) deben entregarse en cortos periodos para que la adaptaci6n mantenga un buen ritmo con eJ cambia (imprevisibilidad). Este enfoque iterativo Ie pennite al c1iente evaluar el incremento del software de manera regular, proporcionar la retroalimentaci6n necesaria al equipo de software, e influir sobre las adaptaciones del proceso que se realizan para adecuar Ja retroalimentaci6n .

........... ,..Ia tlttoali..1bi6n riIpida, iii en tI proceso . . . . . . . . . tI "... ......

4.2.1 Las politlcas del desarrollo agll

--

Existe un debate considerable (a veces estrtdente) sobre los beneficios y la aplicabilidad del desarrollo agil del software como altemativa a procesos de ingenieria del software mas convencionales. Jim Highsmith IHIG02a] (a manera de broma) analiza los extremos cuando caracteriza el sentimiento del campo proagilidad ("agilitado-

82

PARTE UNO

El. PRO:ESO DEL SOI'TWAR

res~). "Los metod61ogos tradicionales son un conjunto de tipos que se arrastran en el lode y que prefieren producir documentad6n que no fluye, en vez de un sistema de trabaJa que cubra las necesidades del negocio." Como contraparte, establece la posici6n del campo de la ingenieria del software (de nuevo, en (orma de broma):

" Los metod610g0s 'Iigeros' y. eh, 'agiles' son un canjunto de intrusos informaticos que van a estar ahi para dar una maldita sorpresa cuando intenten elevar sus juguetes a1 nlvel de software de la empresa".

Al igual que todos los argumentos sabre la tecnologia del software, este debate
sobre la metodologla carre el riesgo de degenerar en una guerra religiosa. 51 estalla la guerra, desaparece el pensamiento racional. y las creencias, en vez de los hechos, guian la toma de decisiones. Nadie esta en contra de la agilidad. La pregunta real es: ,cual es la mejor manera de lograrla? Igual de importante es la pregunta : ,c6mo se construye un software que satisfaga hoy las necesidades de los clientes y muestre las caracterlsticas de caUdad que Ie permitan extenderse y escalar para cubrir a largo plazo las necesidades del c\iente? No existen respuestas absolutas para ninguna de estas preguntas. Aun dentro de 1a escuela agil se han propuesto varios modelos de proceso (secd6n 4.3), cada uno con un enfoque sutilmente diferente para el problema de la agilidad. Dentro de cada modele hay un conjunto de Mideas" (que los agilitadores sue len lIamar "tareas de trabaja; que representan una separati6n significativa de la ingenieria del software conventional. Y aun asl, muchos conceptos de agilidad son tan 561 0 adaptaciones de buenos conceptos de la ingeniena del software. COmo punto final, hay mucho que ganar sl se considera 1 0 mejor de ambas escuelas, y nada que ganar si se denigra alguno de los dos enfoques. Ellector interesado puede consultar fHIGOI I, [HIG02aJ y [DEM021 para un animado resumen de los aspectos tecnicos y politicOS importantes.

,... ..
..".",
de

No es TllKWIflD . .

..... _.Eo
,~

lflii. ogiIrh1 . . .

"""' " ;, 1IJitwn

!d.

......
qw _

4.2.2

Factores humanos

Los defensores del desarrollo agil del software resaltan la importancia de los "factores de las personas" en un desarrollo agil exitoso. Como establecen Cockburn y Highsmith [COCOI] : "El desarrollo agil se centra en los talentos y las habilidades de los individuos, puesto que el proceso se ajusta a personas y equipos especiflcos". El punta clave en esta afirmaci6n es que el proceso seajusra a las necesidades de las per-

sonas y del equipo, y no aJ reves.2

["R_ . . openm suficiemt polO un equipo es UCtSiYD Dinwfkiemt pan! MfD.

La mayoria de las organiladones de software cxitosas reconocen esta reaUdad sin importar el modelo de proceso que eiijan

.3
Si los miembros del equipo de software van a manejar las caracteristicas del pro-

..

ceso que se aplica para construirlo, debe existir un gran mlmero de rasgos clave entre la gente de un equipo <igil y el equipo mismo:
Com petenda. En eJ contexto de un desarrollo <igil (ai igual que en la ingenieria del software convencional), la "compete nda~ abarca un talento innato. habilidades

,.".

especlficas relaclonadas con el software, y un conocimlento general del proceso que eJ equipo haya elegido aplicar. La habilidad y el conocimiento del proceso pueden y deben ensenarse a toda la gente que runge como miembro de un equipo agH. Enfoque comtin. Aunque los miembros del equipo agil desempenen tareas diferentes y aporten distintas habilidades at proyecto, todos deben enfocarse en una meta : entregar al cHenle un incremento de trabajo de software dentro del tiempo establecldo. Alcanzar esta meta requiere que el equipo tambien se centre en adaptaclones continuas (pequef\as y grandes) mediante las cuales el proceso satisfara las necesidades del equipo. Colaboracl6n. La ingenierfa del software (sin considerar el proceso) induye evaluar, analizar y usar informaciOn que se comunjca al equipo de software; crear informaciOn que ayudara a\ cliente y a olros a entender el trabajo del equipo; y construir informaciOn (software de computadora y bases de datos relevantes) que ofrezca un valor comercial para eJ cliente. Estas tareas se cumpliran 5i los miem bros del equipo coiaboran, entre elias, can el cliente y con sus gerentes. Habilldad para la to ma de d ecisi o nes. Todo buen equipo de software (incluidos los equipos aglles) debe permitirse la libertad de controlar su propio destino. Esto implica que al equipo se Ie de autonomia, es decir, autoridad para tamar decisiones en cuanta a cuestiones tecnicas y del proyecto. C3pacldad de r-esoiudOn de problemas confusos. Los gestore5 de software deben reconocer que el equlpo agll enfrentara amhigOedades y sufrira golpes de manera continua debido al cambia. En algunos casas, el equipo debe aceptar que el problema que esta resolviendo hoy tal vez no sea el problema que debe rescl verse manana. Sin embargo, las lecciones aprendidas en cualquier actividad para la resoluci6n de problemas (incluidas aquellas que sirven para solucionar el problema err6neo) pueden beneficiar al equipo en rases posteriores del proyecto.

=B.....

-_.

Conflanza y respeta mutua. El equlpo agll se debe canvert!r en 10 que De Marco y Uster [DEM981l1aman un equipo "cuajado" (vease el capitulo 21) . Un equipo cuajado muestra la confianza y el respeto necesarlos para que "se unan con tanta fuerza, que el todo sea mayor que la suma de las partes" IDEM981 . organizad6 n propla. En eJ contexto del desarrollo agi! , la

..-,cpJI
, oIm

organizaci6n propia

implica tres factores: I) el equipo agH se organiza a sf misma para el trabaja que debe hacerse; 2) el equlpo arganiza el proceso que mejor se ajusta a su ambiente local; 3) el equipo organiza el pragrama de trabaje can el que se alcance de mejer

..

PARTE UNO EL PROCESO Dfl. SOFIWARE

manera la entrega del incremento del software. La organizaci6n propia tiene varios beneficios te-cnlcos, pero 10 mas importante es que meJora la colaboraci6n y eleva la moral del equipo. En esencia, el equipo sirve como su propla gestoria. Ken Sch-

waber ISCH02) puntualiza estos aspectos cuando escribe: "EI equipo selecciona la cantidad de ITabaja que cree que es capaz de haeer dentro de la iteraci6n, y el
equipo se compromete con el trabajo. Nada desaHenta mas a un equipo que al-

guien mas se comprometa por el Nada motiva mas a un equipo que aceptar 1a responsabilidad de cumplir los compromisos que el mismo hizo".

La historia de la ingenierta del software esta llena de decenas de descripdones y me-

tOOologla5, me-todos de modelado

y notaciones,

herramientas y tecnologlas ohso\e-

tas. Cada elemento surgi6 con notoriedad y despues 10 ecllps6 algo nuevo y (supuestamentel mejor. Con la introducci6n de un amplio espectro de modelos agiles de proceso -<ada uno en busca de su aceptaci6n dentro de la comunidad del desarrollo de software- el movimiento agil esta en la misma ruta hist6rica. l
I
a

tomOUI

En las siguientes secciones se presenta una visi6n general de derto numero de diferentes mode/os dgi/es de proceso. Existen muchas similitudes (en filosofia y practical entre estes enfoques. La intenci6n es subrayar aquellas caracterfsticas de cada metodo que 1 0 hacen unico. Es importante seiialar que todos los modelos agHes se ajustan (en mayor 0 menor grado) al Manifiesco para d desarrollo de software y a los principios enunciados en la secci6n 4.1 .

4,3.1 Programad6n extrema (PE)

A pesar de que los primeros trabajos sobre las ideas y los metodos asociados con la

programoci6n extrema (PE) se realizaron a finales de la decada de 1980, el trabajo

fundamental sobre la materia, escrito por Kent Beck [BEC99[, se public6 en 1999. Los libros subsiguientes de Jeffries er oJ. [JEFO I] sobre los detalles tecnicos de la PE, y el trabajo adicional de Beck y Fowler [BEeO 1bI sobre la planead6n de la PE expusieron los detalles del metodo.
La PE utiliza un enfoque orientado a objetos (parte 2 de este libro) como su para-

digma de desarrollo preferido. La PE abarca un conjunto de reglas y prckticas que ocurren en el contexto de cuatro actividades del marco de trabajo: planead6n, dise3 Esto no es algo malo. Antes de que uno 0 mas modelos 0 me!:odos sean aceptados como un estanda r de (acto, todos deben c:ompetir POT los corazones y Las mentes de los ingenieros de software. Los ~ganadores~ evolucionan con La mejorla que propordona La prKtica, mientras que los "perdedores~ desaparecen 0 se unen a los modelos "ganadores"

85

diWli'io simple

cortos CRC

5OIuciooes pico prolotipo'

historielS del usuQrio

va/ores

criler;os de los prueOos de ;/efoc;6n pIoll de iteroci60

_;"'- -7-'

( P"O,,"'oci, ell porejo

pruebo

de unidod
;ntegroc;6n cootinoo

de oceptacibn

no, codificaci6n y pruebas. En la f1gura 4.1 se ilustra el proceso de la PE y se observan algunas de las ideas y tareas clave asociadas con cada activldad del marco de trabajo. En los siguientes parrafos se resumen las actividades clave de la PE.

Planead6n . La actividad de planeaci6n comienza creando una serie de historias ((amblen llamadas historias del usuario) que describen las caracteristicas y la funcionaJidad requeridas para el software que se construira. Cada historia (similar a 105 ca50S de usa descritos en /05 cap/tulos 7 y 8) la escribe el c1iente y se co/oca en una carta Indice. El cliente Ie asigna un valor (es decir, una prioridadj a la historia basandose en los valores generales del negocio respecto de la caracteristica 0 la funcion .4 lOs miembros del equipo de la PE evaluan entonces cada historia y Ie asignan un casto, el cual se mide en semanas de desarrollo. 5i la historia requiere m~s de tres semanas de desarrollo, se Ie pide al cliente que la divida en historias menores, y se reallza de nuevo la asignaci6n del valor y el costa. Es importante destacar que las historias nuevas pueden escribirse en cualquier momenta. lOs clientes y el equipo de PE trabajan juntos para decidir c6mo agrupar las historias hacia el pr6ximo lanzamiento (el siguiente incremento de software) para que e) equipo de la PE las desarrolle. Una vez establecido el compromise b~sico (el acuerdo de las hlstorias que se incluir~n , la fecha de entrega y otras cuestiones del proyecto) para un lanzamiento, el equipo de la PE ordena las historias que se desarrollaran de una de las siguientes tres maneras: I) todas las historias seran imple4 EI valor de una hlstona puede depender tambien de la presencia de otra historia

..

PARTE UNO

il. I'RCIClSO DIJ. SOFTWARE

ffientadas de un modo inmediatc (dentro de pocas semanas); 2) las historias con va-

lor mas alto se moveran en el programa y se implementaran al principio; 0 3) las historias mas riesgosas se moveran denlro del programa y se implementaran al principio.

oespw!:s de que se ha entregado el primer lanzamiento del proyeclo (tambien lIamade incremento de SOnware). el equipo de la PE calcula la velocidad del proyecto. Oicho de un modo mas simple, la veJocidad del p~to es el numero de historias de los clientes implementado durante el primer lanzamiento. Enlances, la velocidad del proyecto puede utilizarse para I) ayudar a estimar fechas de entrega y el programa para lanzamientos subsecuentes, y 2) determinar 51 se ha hecho un compromiso excesivo en algunas de las historias de todo el proyecto de desarrollo. Si se presenta un compromisa excesivo, el contenido de los ianzamientos se modi fica 0 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 0 eliminarlas. Entonces el equi-

po de la PE considera de nuevo los lanzamientos restantes y modifica sus planes de

acuerdo con ello.

desarrolla cia sofrwtr, ....

Dlsefto. EI disefio de la PE sigue de manera rigurosa el principio MS (mantenerto simple) . Siempre se prefiere un diseno simple respecto de una presentaci6n mas compleja. Ademas, el diseno ofrece una gufa de implementaci6n para una histona como esta escrita. ni mas ni menos. Se desaprueba el disei'io de funcionalidad extra (porque el desarrollador supone que se requerira mas tarde).
La PE apoya el usa de tarjetas CRe (capftulo 8) como un mecanismo erectivo pa-

ra pensar en eJ software en un contexte orienlado a objet05. Las larjetas eRe (colaborador-responsabilidad-dase) identifican y oTganizan las clases orientadas al objet0 6 que son relevantes para el incremento del software actual. El equipo PE conduce el ejercicio del disefto por medio de un proceso similar al descrito en el capitulo 8 (secci6n 8.7.4.). Las tarjetas eRe san el unico producto de !rabajo realizado como parte del procesa de la PE. Si se encuentra un problema difkil de diseno como parte del diseno de la historia, la PE recomienda la creaci6n inmediata de un prototipo operacional de esa porci6n del diseno. El prototipo del disei'io, lIamado la solud6n pica, se implementa y evalua. EI pr0p6sito es re ducir el riesgo cuando comience la verdadera implementa5
Estas directrices de diseflo se deberian seguir en todo$ los metodos de ingeniena del software, aunque a veces las notaciones y termlnolog!as sofisticadas que se utilizan en el diseflo pueden emplearse de una manera mas simple. 6 En el capitulo 8. yak> Jargo de]a parte 2 dellibro. se estudian las clases orientadas a objetos.

87

ci6n y validar las estimaciones originaies en la historia que contiene e[ problema del diseno.
La PE apoya la re[abricaci6n, una tecnica de construcci6n que tambien 10 es de di-

sena. Fowler {FOWOO] describe la refabricaci6n de 1a siguiente manera:

Refabricaci6n es el proceso de cambiar un sistema de software de tal manera que no al -

tere el comportamlento extemo del c6digo y que mejore la estructura intema. Es una manera disciplinada de limpiar el c6d180 [y modificarlsimplificar el diseno interne], 10 que
minimiza las oportunidades de introducir errores. En esencia, al rerabricar, se mejora e\

diseflo del cMigo

despu~s

de que se ha escrito.

Oebido a que el disefio de la PE virtualmente no utiliza la notaci6n y produce, si acaso, muy pocos productos de trabaja, distintos a las tarjetas de eRe y soluciones pica, eJ diseno se considera como un artefacto que puede y debe modificarse de manera continua a medida que prosigue la construcci6n. EI prop6sito de refabricar es contralar estas modificaciones al sugerir pequenos cambios del disefio que "pueden mejorar de manera radical el diseno~ IFOWOOj. Sin embargo, debe notarse que el esfuerzo requerido para refabricar puede aumentar en forma drastica a medida que crece el tamano de la aplicaci6n. Una noci6n central en la PE es que el diseno ocurre tanto antes como despues del comienzo de la codificaci6n. Refabricar significa que el diseno ocurre de manera continua a medida que se construye el sistema . De hecho, la actividad de construcci6n misma te proporcionara at equipo de PE una gula sobre c6mo mejorar el diseno. Codificad6n. La PE recomienda que despues de disenar las historias y realizar e[ trabaja de diseno preeliminar el equipo no debe moverse hacia la codificacl6n, sino que debe desarrollar una serie de pruebas de unidad que ejerciten cada una de las historias que vayan a incluirse en eJ ianzamiento actual (incremento de sottware) J Una vez creada la prueba de unidad, el desarrollador es mas capaz de cenlrarse en 10 que debe implementarse para pasar la prueba de unidad. No se agrega nada exlrano (MS). Una vez que el c6digo esta completo, la unidad puede probarse de inmediato, y asl proporcionar una retroalimentaci6n instantanea a los desarrolladores. Un concepto clave durante la actividad de codificaci6n (y uno de los aspectos de la PE de los que mas se ha hablado) es la programaci6n en pareja. La PE recomienda que dos personas trabajen juntas en una estaci6n de trabajo de computadora para crear el c6digo de una historia. Esto proporciona un mecanisme para la resoluci6n de problemas en tlempo real (dOS cabezas piensan mejor que una) y el aseguramiento de la caUdad en las mismas condiciones. Tambien alienta que los desarrolladores se mantengan centrados en el problema que se tiene a la mana. En la practica, ca da persona tiene un papel sutilmente diferenle. Por ejemplo, una persona puede pen

7 E.ste enfoque es analogo a conocer las preguntas del examen antes de comenzar a estudlar Esto fa dlita mocha mas el estudio al enfocar Ia atenc16n s6Io sabre \as preguntas que seran fo rmuladas

.0

PARTE UNO

EL PROCESO DL 50nWARE

sar en los detalles de codificaci6n de una porci6n particular del disei'io, mientras que la otra se asegura de que se sigan los estandares de codificaci6n (una parte requerida de la PEl y que el c6digo que se genera "coindda" con el disel\o mas amplio de la historia. Cuando los programadores completan su trabajo el c6digo que desarrollaron se integra con el trabaja de alros. En algunos casos esto 10 lIeva a cabo diariamente el equipo de integraci6n. En alros casos, Ja pareja de programadores es la responsable de la integrad6n. Esta estrategia de "integraci6n continua" ayuda a evitar problemas de compalibilidad e interfaz y proporciona un ambiente de ~prueba de humo" (capitulo 13) que ayuda a descubrir los errores desde el principia.
PrUebas. Va se ha hecho notar que la creaci6n de una prueba de unidad8 antes de comenzar 1a codificaci6n es un elemento clave para el enfoque de la PE. Las prue~ bas de untdad que se crean deben implementarse con un marco de trabajo que per~ mita automatizarlas (por 10 tanto, pueden ejecutarse de manera facil y repetida). Esto apoya una estrategia de regresi6n de prueba (capitulo 13) cuando el c6digo se modifica (al cual a menudo se Ie confiere la filosofla de la PE de refabricar), Cuando las unidades individuales de prueba se organizan en un "conjunto universal de pruebas" [WEL99J. las pruebas de integraci6n y validaci6n del sistema pueden reallzarse a diario. Esto proporciona al equipo de PE una indicaci6n continua del progreso y tambien puede encender luces de emergencia previas si las cosas salen

1m ..... do
dellWlrio.

~~VE

ocapl!Ki\n III kJ PE Sf darMIIl dllas IIsIo.m

mal , Wells [WEL99J establece: "Arreglar problemas pequenos cada pocas horas toma menos tiempo que arreglar problemas enormes justa antes de la fecha Umite Las pruebas de aceprad6n de la PE, tambien llamadas pruebas del C/iente, las especifica el cliente y se enfocan en las caracterlsticas generales y 1a funcionalidad del sistema, elementos visibles y revisables por el c1iente. Las pruebas de aceptaci6n se derivan de las historias del usuario que se han implementado como parte de un lanzamiento de software.
H

-""""_ ......... ==~::S?.~ .__ ~do:".;

d desarrollo de

m;,......- ......

~ tfttIII

_s.o-

""" .... 01 "..,-

_.",

8 Las pruebas de unidad, que se tralan con detalle en el capitulo 13, 51:! enrocan sobre un componente individual del software, al ejercitar la interfaz de los componentes, lasesllUCluras de dalOS y La fundonalidacl en un esfuerzo por descubnr los errores locales en el componenle

-........ .. ......,"
""""'" .e.....
1MI!OIp ecio

PEt

do 10 .... 10 1' -Ooog. .....

Dove: to """ 1'10

.. araIiti.

Ia aa:i6ra ,... . . ..a6 ..

{los , . . . . . . . . . .

....

4.3.2 Desarrollo adaptOUvo de software (DAS)

EI desarrollo adapwdvo de software (DAS) 10 propuso Jim Highsmith [HIGOO] como una tecnica para construir software y sistemas complejos. Los apoyos filos6f1cos del DAS se enfocan en la colaboraci6n humana y la organizaci6n propia del equipo. Highsmith [HtG98] expone 10 anterior cuando escribe:
1...1 oTganizaciOn prop!a

es una propiedad de los sistemas adaptativos complejos, similar a

un "aJa" coJecUvo; es en e[ momento de energla creativa cuanda surge la soluci6n a algOn problema persistente. La organizad6n prop!a emersc: cuanda los individuos, /os agentes independiente5 (c~[ulas en un cuerpo, especies en un ecosislema, desarrolladores en un equipo de soflware) cooperan lcolaboranl para crear salidas emergenle5. Una salida emergente es una propie<lad mas alia de Ja capaddad de cualquier 3gcnte individual. PoT
ejemplo. las neuronas individuaJes del cerebra no pescen conciencla, pero en fanna colectiva generan Ja propiedad de la condencia. Tendemos aver este fen6meno del surgi-

miento colectivo como un accidente, 0 al menos como independiente y sin reglas El

estudio de ta ol'8antzacl6n propia demuestra que dicha visi6n es err6nea.

90

- ..

""""""'"

Recopi!ociOn

de requisilos

adapIativo de

planeociOn del cido adoplalivo

&nonciodo

JAD
fJ$pilicockJn.s mlnimas

cJe 10 misiOn resJriiones del proyecto

ff!tquisilos bchicos pion de lonzomienlo en 81 tiempe

t~~~~~~cl~~;JI~componentes

Implementodol/probodos

grope de .n/oque para retroolimenlad6n ,.....isiOll.s tecnicos forma/es posl mortem

Highsmith argumenta que un enfoque de desarrollo agil y adaptativo basado en la coJaboracl6n es "tanto como una fuen te de orden en las compJejas interacciones entre disciplina e ingenieria~. .1 define un "cicio de vida" del DAS (ligura 4.2), el cuai incorpora Ires fases: especulaci6n, colaboraci6n y aprendizaje.

Especulaci6n. En esta fase se inicla el proyecto y se conduce el dclo adaptativo de

planeocion. Este ultimo utiliza infonnaci6n de iniclo del proyecto -el enunciado de

LCtOIH lOll

las UlI'lKttristkal eM los ddos aHptlfival dol DAS?

la misi6n del cliente, restricciones de proye<:to (por ejemplo, fechas de entrega 0 descripciones del cliente) y los requisitos btlsicos- para definir eJ conjunto de ddos de lanzamiento (incrementos del sofiware) que se requerirtm para el proyecto. 9 Colaboracl6n. La gente motivada trabaja junta de una forma que multiplica su tao lento y sus salidas creativas mas ana de sus numeros absolutos. Este enfoque de colaboraci6n es un tema recurrente en lodos los metodos agiles, pero la cooperaci6n no es fadl . No es s6lo comunicaci6n, aunque la comunlcaci6n es parte de ella. No es s610 un asunto de trabajo en equipo, aunque un equlpo "cuajado" (capitulo 21) es esenciai para la presencia de la colaboraci6n real. No es un rechazo al individualism~, ya que la creatividad individual representa un papel importante en el pensamiento de colaboraci6n. Esto es, por encima de todo, una cuesti6n de confianza. las personas que trabajan juntas deben confiaT entre sl para I ) criticar sin animosidad;
9 ObsCrvese que el plan del cicio adaptativo puede adaplarse, y con probabilidad 10 hartl, al proyecto cambumte y a las condiciones del negocio

-,.., .. . _dol"",
IXlIIiII slliI:ui 51

nIMI em til denta

In,~

r uslid!ls".

9'
21 ayudar sin resentimientos; 3) trabajar tan duro 0 mas duro de 1 0 que ya 10 haeen;
41 tener el conjunto de aptitudes para contribuir al trabajo en curso; y 5) comunicar los problemas 0 preocupaciones en una forma que conduzca a la acd6n efectiva .

...._ .IIo.-_al""""' ...

..-lonoyoriodo ..... _ _
'

.....

AprendizaJe. Como miembros de un equipo de DAS se comienzan a desarrollar los componentes integrantes de un cicio adaptativo, la importancia radica en el aprendizaje y en el progreso a traves de un cicio completo. De hecho, Highsmith [HIGGOO] arsumenta que los desarrolladores de software a menudo sobreestiman su comprensi6n (de la tecnologla, el proceso y el proyecto). y que el aprendizaje Jes podrla ayudar a mejorar su grado de entendimiento real. Los equlpos del DAS aprenden de tres maneras: I . Grupos enfocados. El cliente 0 los usuarios finales proporcianan retroalimentacl6n sobre los inerementos de software que se entregan. Esto indica en forma directa la satisfacci6n 0 la insalisfacci6n de las necesidades del negocio. 2 . Revisiones tknicas fonnales. Los miembros del equipo del DAS revisan los componentes del software desarrollado mientras mejoran su cal1dad aprendizaje.

y su

3. Post mortem. EI equipo de DAS se vuelve introspectlvo a\ vigilar su propio

desempeno y proceso (can el pr6posito de aprender acerca de su enfoque y despues mejorarlo).

Es importante destacar que la filosotla del DAS es merilaria sin importar el modelo de proceso empleada. EI acenta general en la dinamica de la organizaci6n propia en los equipos, la colaboraci6n interpersonal y el aprendizaje Individual y par equipo conducen grupos de proyectos de software con una mayor poslbllidad de exilo.

4.3.3 Metodo de desarrollo de sistemas d1n6micos (MDSD)

EI metoda de desarrollo de sistemas dinamicos [STA97] es un enfoque de desarrollo de software agil que "proporciana un marco de trahajo para construir y manlener sistemas con restriccianes de tiempo muy estrechas mediante el empleo de la construcci6n de protoUpos incrementales en un ambiente de prayecto controlado" [CCS02]. Similar a algunos aspectos del proceso DRA descrito en el capItulo 3, el MDSD sugiere una filasofTa tomada de una modificaci6n del principio de Pareto. En este caso, 80 por ciento de la aplicaci6n se puede entregar en 2096 del Uempo que tamana entregar 100 por ciento de la aplicaci6n (sistema completa). AI igual que la PE y el DSA, el MDSD sugiere un proceso iterativo de software. Sin embargo, el enfoque del MDSD en cada iteraci6n sigue la regIa del 80 par ciento. Esto es, 5610 se necesita el trabajo suficiente para cada incremento y para facilitar el

.,

PARTE UNO EL PRCX:ESO Dfl. SOfi'HARE

movimiento hacia el nuevo incremento. Los detalles restantes se pueden completar posteriormente ruanda se conozcan mas los requlsitos de negocios 0 cuando los
cambios hayan side solicitados 0 ajustados. En la red mundial hay una organizaci6n (DSDM Consortium, www.dsdm.org) que de manera colectiva asume el papel de ~conservador" del metada. Esta organizaci6n
ha definido un modele agil de proceso, lIamado el cicio de vida del MDSD. Esle metoda define Ires ciclos ilerativos diferentes, a los cuales preceden dos actividades del

cicio de vida adicionales:

Studio de factibilidad: establece los requisitos bAsicos de negocio y las restriccio-nes asociadas con la aplicaci6n del metoda y para evaluar si la apJicaci6n es una

candidata viable para el proceso del MDSD.

Estudio de negocios: establece los requisitos funcionales y de informaci6n que permitinin que la apJicaci6n proporcione un valor al negocio; tambien define la arquitectura basica de la aplicaci6n.

lleraci6n de modele fundonal: produce una serie de prototipos incrementales que

demuestran la funcionalidad para el cliente (nota: lodos los prototipos del MDSD estan disenados para evolucionar hacia la aplicaci6n entregable). E1 prop6sito durante este cicio iterativo es recopilar requisitos adicionales mediante la retroalimentaci6n de 10 que obtiene el usuario, mientras este tTabaja con el prototipo.

lteraci6n de construcd6n y diseiio: revisa la construcci6n de prototipos durante la

iteraci6n del modelo funcional para asegurar que cada uno de eUos ha side desarrolIado de una manera que Ie permitira proporcionar un valor operativo de negocios para los usuarios finales. En algunos casas, la iteraci6n del modele funcional y el diseno y la iterad6n de construcd6n suceden en forma concurrente.

Implementacl6n: coloca el incremento de software mas reciente (un prototipo "operacionalizado") en el ambiente operativo. se debe destacar que I) el incremento puede no estar 100 por dento completo 0 2) se pueden requerir cambios cuando el incremento se coloca en el sitio. En cualquier caso, el trabajo de desarrollo del
MDSD continua al regresar a la actividad de iteraci6n del modele de funci6n. EI MDSD se puede combinar con la PE para obtener un enfoque conjunto que define un modele s6lido de proceso (el cicio de vida del MDSD) con los aspectos practicos (PEl necesarios para construir incrementos de software . Ademas, los conceptos del DAS de colaboraci6n y equipos autoorganizados se pueden adaptar a un modelo de proceso combinado.

4.3.4 Melli
Melt Mrmino derivado de una jugada de rugbylOj es un modele agil de proceso que desarrollaron JeflT Sutherland y su equipo a principios de la decada de 1990. En anos
10 Un gnrpo de jugadores se alinea alrededor del bal6n Y los compafteros de equipo trabajan juntos (algunas yeas de manera vioIenta) para dC'spJazar el bal6n hacia ellado contrario del campo de juego

93
recientes, Schwaber y Beedle [SCHOll han presentado el desarrollo posterior de los metodos de mele. Los principios de la melt'! IAOM96J son consistentes con el manifiesta agi!. Los equipos de tTabaja pequeiios estan organizados para ~ maximizar la comunicaci6n, minimlzar los gaslos generales y maximizar el hecho de compartiT conocimiento tacito e infonnal".

El proceso debe adaptarse a los cambios tecnicos y de negocios "para asegurar que se produzca el mejor producto posible". El proceso produce inerementos frecuentes de software "los cuales se pueden inspeccionar, ajustar, probaT, documentar y conslrui!"'.

Ellrabajo de desarrollo y la genie que 10 rcaliza estan divididos en "particiones 0 paquetes de bajo acoplamiento". Conforme se construye el producto se realizan pruebas y documentaci6n constantes.

Los procesos de mete proporcionan la "capacidad de decJarar un producto como 'realizado' siempre que esto se requiera (porque la competencia acaba de hacer un lanzamiento, porque la compaiHa necesita eI dinero, porgue cl usua
rio/cliente necesita las funciones, porque ya se esta en el momenta en que se prometi6 .. . IADM96J.
H

Con los principios de la meie se gulan las actividades denlro de un proceso que incorpora las siguientes actividades del marco de trabajo: requisitos, anali5i5, discno, evoluci6n y entrega. En cada actividad del marco de trabajo las tareas de trabajo suceden dentro del patron de proceso (tratado en el parrafo siguiente) lIamado

sprint

EI trabajo realizado dentro de un sprint (el numero requerido de sprint5 varian1 de acuerdo can eJ tamano y la complejidad del producto) se adapta OIl problema y con frecuencia 1 0 modifica en tiempo real el equipo de melt:. En la figura 4 ..3 se J]ustra eJ flute general del procesa de mele.

..........'"

La melt subraya el usa de un conjunlo de npatrones de proceso de software"

INOV02) que ha probado su efectividad en proyectos con tiempos de entrega muy reducidos, requisitos cambiantes y condiciones criticas 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 0 caracteristicas de proyecto que proporcionan un valor comercial para el c1iente. En cualquier momento se pueden agregar elementos a los retrasos (asl se introducen los cambiOS). EI gerente de producto evalua los retrasos y actualiza las prioridades de acuerdo con 10 requerido.

Of

PARTE UNO
Flu~

a PIKXESO DL .st::7WARF

de prOC85O de Ia meli.

MeU: .-.uni6n diorio de 15 minulos

\.en miembros del equipo responden o los preguntos b6*os 1) hk:iste desde 10 ultimo reunibni 2) .TI_, olgun obst6culoi 3) hor6s ontes de 10 pr6ximo reuni6n?

.0...

Retroso de sprint:
Coroclerislicos osigflOdos

Elementos

.au.

de reirc$O
expondid<

~.~I;~d
.. demueltra al final del sprint

Retroso del produdo.

Cofocletimcos del producto deseodos que lion fee.bido priomXx:l
pot'

eI doenle

~~

Sprint consiste en unidades de trabajo que se requieren para satisfacer un requisito detinido en los retrasos en un periodo predefinido (ellapso usual es de 30 dias) . En esta etapa, los elementos de los retrasos a los que se dirigen las unidades de trabajo del sprint estan congelados (es decir, durante el sprint no se introducen cambios). Por 10 tanto, el sprint permite a los miembros del equipo trabajar en un ambiente enfocado al corto plazo, pero estable, Reuniones de meie: son reuniones cortas (por 10 general de 15 minutos) y las realiza a diario el equipo de mele. Existen tres preguntas que plantean y responden todos los miembros del equipo. iQUe hiciste desde la ultima reuni6n? iCuales obstkulos encontraste? iQUe esperas lograr para la siguiente reuni6n del equipo? Un Hder de equipo, Ilamado "maestro de la mele~, preside la reuni6n y evalua las respuestas de cada persona. Cada reuni6n de melt ayuda al equipo a descubrir problemas potenciales tan pronto como sea posible. Estas reuniones diarias tambien conducen a la "socializaci6n del conocimiento" IBEE99] y, por ende, a promover una estructura de equipo con organizaci6n propia ,

C~VE

.,_dO !hisi6n dO trobo.," 10 IIIiOOdes de

~to,1o

La mel.! R:1WpOOI1Il (orPlto de IXIlrOlll5 de IJO(II5O qoa resolrD

Irnbojo, (orrooiroci6n V10

r.lrOciWneoIoci6I'I hlK\llente del dente.

95

lkmostraci6n: se entrega el incremento de software al cJiente de forma que estc

demuestre y evalue la funcionalidad implementada. Es importante sefialar que la demostraci6n quiza no contenga toda la funcionalidad planeada. sino aquellas funciones susceptibles de entregarse dentro del periooo establecido. Beedle y sus colegas [BEE99] presentan un ami!isis complete de estos patrones y establecen: "La MELE supone la existencia del ca05 .. ,", EI patr6n de proceso de la meie permite que un equlpo de desarrollo de software lrabaje de manera exitosa en un mundo donde la eliminaci6n de la incertidumbre es imposible.

4 .3.5

Crista!

Alistair Cockburn [COC02al y Jim Highsmith [HIG02bj crearon laJamilia cristal de los metodos dgiles l1 con el rin de lograr un enfoque de desarrollo de software que coloca un premia en la "manejabilidad" durante 10 que COCkburn caracteriza como "un juego cooperativo de inventiva y comunlcaci6n con recursos iimitados, con una meta primarta consistente en la entrega de software util y en funcionamiento y una meta secundaria de prepararse para el juego slguieme" [COC02bl. Para alcanzar la manejabilidad, COCkburn y Highsmilh definieron un conjunlo de metodologlas, cada una de elias con elementos esenciales comunes a tadas, y fun dones, palrones de proceso, productos de trabajo y practlcas unlcas en (ada una de eUas E.n realidad, la familia cristal es un conjunlo de procesos agiles, los cuales han probado su efectividad en diferenles lipos de proyectos. EI objetivo es permitir que los equipos agiles seleccionen el miembro de la familia cristal mas apropiado para su proyecto y ambiente.

4.3.6

Desarrollo conduc1do par caracteristicas (DCC)

8 desarrollo conducido por camcleristicas (ocq 10 concibieron origlnalmente Peter Coad y sus colegas [COA991 como un modelo de proceso practico para la [ngen[erl a del software orientada a objelos. Stephen Palmer y John Felsing [PAL02] han extendido y me;orado el trabajo de Coad, al describir un proceso adaptativo y agi\ que puedc aplicarse en proyeclos de sonware de tamano moderado y grande. En el contexto del DCC una camcteriSlica "es una funci6n valuada por el clienle que puede implementarse en dos semanas 0 menos" [COA991. La importancia que se Ie concede a la definid6n de caracterlsticas propordona los siguientes beneficios. Como las caractensticas son bloques pequeflos de funcionalidad entregable, los usuarios las describen con mayor fadJidad, pueden entender c6mo eslas se relacionan con otras con mayor rapidez, y pueden revisarlas de mejor manera en bUsqueda de ambiguedades, errores U omisiones. Las caracterlsticas se pueden organizar en un agrupamienlo jerarquico relacion ado con el negocio.
II EJ nombre "cristat se deriva de las caracterlstJcas de los crlstaJe5 geol6gi~, cads uno con su propio color, forma y dureza

 Como una caracterislica es el incremento de software entregable, el equipo desarrolla caracteristicas operativas cada dos semanas. Debido a que las caraclerlsticas son pequenas, sus disenos y representadones de cMigo son mas [tidIes de inspeccionar de manera efectiva.
La planeaci6n del proyecto, la elaboraci6n de su programa y su rastre o los

guia la jerarquia de la caracteristica, en lugar de hacerlo un canjunlo de tareas de ingenieria del software adaptado en fonna arbitraria. Coad y sus colegas [COA99] sugieren la siguiente piantil1a para definir una caracte-

ristica:
<8cdon> eJ <l'esultado> <})Oriparaldda> un <oblelo>
donde un <objelo> es "una persona , siUo 0 cosa (inc\uyendo papeles, momentos en

eJ tiempo 0 intervalos de tiempo. 0 descripciones del tipo de catalogo de entrada)". Los ejemplos de las caracteristicas para una aplicaci6n de comercio electr6nico podrlan ser:

Agregar eJproducto a un camto de supermercado. [)esp/egar las especijicadones teen/cas de un producto, Almacenar /a inJonnaci6n de navegad6n para un cliente.
Un conjunto de caracteristicas agrupa caracteristicas relacionadas en categorias relacionadas con el negocio y se define como [COA991:

<acdor\><-ar, -er, -il'> un <objeto>

Por ejemplo: hacer /a

venta del producro es un conjunto de caracteristicas que podria

abarcar las caracteristicas relacionadas can anterioridad y otras. EI enfoque del DCC define cinco actividades de "colaborac\6n" dentro del marco de trabaja (en el DCC estas se lIaman "procesos") como se muestra en la figura 4.4.

c_'"
(COA99]

""""'olio conduc1do pol

_con

Desarrollor

autortzad6nJ,

"" modelo
go_I

Eloborar una listo de coroderisticQI

Pia,
po< coroct.ristica

Diseiio
po<

coracMrislico

Consrru<:cioo po< caroderislico

j
(mOl formo que
contenidol

j
Uno lislO de
<;orocteris/icos ogrupooos en tonjuntos

j
Un pion de desol'follo Propielorios de dose
Propielorios del conjunto

J
Un poquete de diMno
(secuenciosl

J
FunciOn diente-volor

completodo

y 6reos de conle;nido

de coroderisticol

EI nee concede una mayor importanda a las directrices y tecnicas de la gesti6n del proyecto que muchos otros metodos agiles. Cuando los proyectos crecen en tamano y complejidad, con frecuenda la gesti6n ad hoc del proyecto es inadecuada. Resulta esendal para los desarrolladores, sus gerenles y el diente entender el estatus del proyecto: cuales logros se han lenido y cuales programas se han encontrado. Si la presi6n de la fecha limite es signiflcativa, resulta critico detenninar si los incremenlos de software (caracterfsticas) estan programados de manera apropiada. Para lograrlo el nec define seis puntos de fijaci6n duranle el diseno y la implemenlacl6n de una caracterislica: "ensayo del diseno, diseno, inspecci6n del diseno, c6digo, inspecci6n del c6digo, promocl6n de la construcci6n" [COA99I.

4 .3.7

Modelado Qgti (MAl

En muchas sltuaciones los ingenieros de software deben construir sistemas grandes y criticos para los negoclos. EI ambito y 1a complejidad de dlchos sistemas se deben rnadelar de Conna que 1) todas las circun.scripciones entiendan mejor 10 que se debe 10grar; 2) el problema se divida de manera efectiva entre la gente que 10 debe resolver; y 3) la caJidad se eva[ue en cada paso confonne eJ sistema se desarrolla y construye. En los ultimos 30 anos se ha propuesto una ampiia variedad de metodos y notaci6n para el mode[ado de ingenier!a del software en el analisis y diseno (tanto arquitect6nico como al nivel de componentes). Estos metodos tienen un merito significativo, pero se ha comprobado que su aplicaci6n enfrenta dificultades y es desafiante poderlos sostener (sobre muchos ProyectOSI. Parte del problema es el "peso" de estos metodos de modelado. Can esto se hace referencla al volumen de notaci6n requerida, el grado de formalismo sugerido, el tamana de [os modelos para proyectos grandes, y la dificultad para el mantenimiento del modelo confonne ocurren los cambios. Aun as!, el modelado del analisis y el diseflo tiene un beneficlo sustancial para los proyectos grandes: por ninguna otra raz6n que hacer que estos proyectos sean manejables en el sentido inteleclual. ,Existe un enfoque agil para el modelado de [a ingenierfa del sollware que pudiera proporcionar una altemativa? En el "SiUo alicial del modelado agil", SCott Ambler IAMB02) describe el mode/ado agil (MA) de la siguiente manera: EI modelado agil (MAl es una tecnologla basada en la practica para el modelado efectivo de los sistemas basados en software Dicho de una fonna mas simple. el modelado agil es una colecci6n de valores. principios y practicas para el modelado de software que puede aplicarse en un p~o de desarrollo de software de una manera efectiva y ligera Los modelos agiles son mas efectivos que los lradicionales porque son s610 10 suticientemenIe buenos, no tienen que ser perfe<:tos tAMB02j : Ademas de los valores consistentes con el manifiesto ~gil. Ambler sugiere valor y humiJdad. Un equipo ~gil debe tener el valor para tomar decisiones que ocasionar~n el rechazo y la refabricaci6n de un disef'io. Debe tener la humildad de reconocer que quienes manejan 1a tecnologla no tienen todas las respuestas, y que los expertos en negocios y otros participantes de la empresa son dignos de respeto y considerac16n.

PARTE UNO

D. PROCEiO Dll. SOFTWARE

A pesar de que el MA sugiere un arregla amplio de principios de modelado

"esenciales" y "suplementarios", los responsables de que el MA sea unice son los siguientes IAMB02J:

Mode/or con un prop6siro. Un desarrolJador que use el MA debe tener una meta especifica en mente (por ejemplo, comunicar informaci6n al cliente 0 ayudarle a entender mejer a[gun aspecto del software) antes de crear el modelo. Una vez identificada la meta para el modelo, el tipo de notaci6n que se usara y el grado de detalle
requerido seran mas obvios.

Usar multipJes modelos. Existen muchos modelos y notaciones diferentes con los
cuales describir el software. S610 un pequeno subconjunto es esenciaJ para Ja mayoria de los proyectos. El MA sugiere que para proporcionar 1a visi6n necesaria cada modelo debe presentar un aspecto diferente del sistema, Y s610 aquellos modelos que proporcionen un valor para la audiencia a 1a que estan dir!gidos deben usarse.

Viajar /igero. La realizad6n de trabajo de la ingenierta del software requiere cooselVar 5010 los modelos que propordonartm valor a largo plaza y descartar el resT. . """OW IS II!

"" """".-

"'" ... 0/ """ Sfitwrxt. (onsIruir

..... """"'" ,._doI

to. Cada producto de trabajo que se conserve debe redbir mantenimiento conforme se presentan cambios. Eslo representa un trabajo que reduce \a ve\ocidad del equipo. Ambler [AMB02) obselVa que
~cada

vez que se decide conservar un mode-

..-

10 se intercambia la agilidad por la conveniencia de tener la InformaciOn disponible para eJ equipo de una fonna ahstracta (por ende, existe una posihilidad de mejorar la comunlcaci6n dentro del equipo, asl como con los propietarios del proyectO) H .

i1Uaim6s,Ii

EJ contenido es mas imporli1nce que la represenraci6n. EI mode\ado debe comuni car informaci6n a la audiencia a \a que esta dirigido. Un modelo sintacticamente perfecto que comunique s610 un poco del contenido util no tiene tanto valor como un modelo can una nataci6n defectuosa que, sin embargo, comunique un contenido valioso para su audiencia. Conacer los mode/os y las herramienras can que se crean. Es necesario entender las fortalezas y debilidades de cada modelo y las herramientas con los que se cre6.

Adaptar enJorma local.

des del equipo agil.

EI enfoque del modelado se debe adaptar a las necesida-

~ DesarroUo

agu

~ Objetivo: EI objetiYo de los hermmientos del de.orrollo 6gi! as ayudar en uno 0 m6s

ospectos del dMorroIlo 6gi! con enfo~$ en 10 focililoci6n de 10 genemci6n ~ido de ~re operotiYo. EsIos

herrornienlos tombi.., WI puecIen urilizor cuondo WI opIk:oo 105 modeIos presc;riptivos de proc;eso (c;opilulo 3). M...6iii...... Lo mec:Cnica de los ~ \/One. En generoI, los c;onjunlm de hehomiellm ~ indvten opc7)'O 0IJb'naIiz0d0 pam 10 pblllOCi6n del proyedo, eI de5orroIo

CAPfTuLo 4

DESARROLLO }.GlL

99

oIo~,Io~oIo_. &"" \, 9II_oci6I, de o6digo y 10 reoIiwci6ro de ~

~ de un fJfotfM Ota,\ en

"ono.\ adMOaOes

h&cnico$ denk"a del proce~ . Ideog.omic UML, deKlrrollodo par Ideogl!JI"ic (www.ideogramic.com)asunconjunlodeherromienlos poro eI UMl creoclo en forma especifico paro uKlf"lo denlro de un proceso 6gil.

. ._ _ _

,..sentotivo~: lJ

Como eI desorroHo 6gil as un I6pico odual, Ie ..."ana de Ie vendedores de herromientos de ...... pretenden vender herromienlos que opayen eI
....,. 6g~ los herromienlos que Hi presenlon a oori6n Iienen corocIerisricos que los hocen Utiles ~ particular para las proyedos 6gilM.
&r-w, desorrolloda par Microtoal

Together Tool Set di)lribuido par Borland

fwww.bonond.comowww.logeIhersoftcom). p'oporciollCl un poquete de herromier1los que CIfXJYO muchm octividodes l6cnicos deniI'Q de Ie PE Y aires procetO! 6giles.

_-.iaoIoaI.com), proporciona ~ pal1l la

Una filosofla agil para la ingenieria del software se reladona can cuatro aspectos clave: la importanda de la arganizaci6n propia de los equipos, los cuales cantrolan el trabaja que realizan; camunicad6n y calaborad6n entre los micmbros del equipo y entre los profesionales y sus clientes; un reconocimiento de que el cambia representa una oportunidad; y un especial cuidado en la entrega rapida del software que satisfaga al cliente. LDs modelos de proceso agil se diset'laron para cumplir con cada uno de estos aspectos. La programad6n extrema {PEl es el proceso agil que mas se utiliza. organizada como cuatro actividades del marco de trabajo -planeaci6n, diseflo, codificad6n y pruebas-, la PE sugiere algunas tecnicas innovadoras y poderosas que permiten a un equipo agil crear frecuentes lanzamientos de software al entregar caracteristicas y funcionalidad que describe y despues prioriza el cliente. EI desarrollo de software adaptativo (DSA) destaca la colaborad6n humana y la organizaci6n propia del equipo. Organizado con tres actividades del marco de tTabajo --especu laci6n, colaboraci6n y aprendizaje-, el DSA utiHza un proceso iterativo que incorpora la planeaci6n del cielo adaptativo, metodos de recopilaci6n de requisitos relativamente rigurosos y un cielo iterativo de desarrollo que incorpora grupas enfocados en el c1iente y revisiones tecnicas formales como mecanismos de retroalimentaci6n en tiempo real. El metodo de desarrollo de sistemas dinamicos (MOSO) define tres diferentes cielos iterativos -iteraci6n funcional del modelo, iteraci6n de diseno y construcci6n e implementaci6n- precedidos por dos actividades del cicio de vida adicionales: estudio de factibilidad y estudio de negocios. El MDSD abo-

12 las herramienlas mencionadas aqul son 5610 una muestra de esta calegoria En casi todos los casos los nombres son marcas regisl.radas de sus respeclivos desarrol1adores

100

ga por el uso de programas y sugiere que s610 se requiere el trabaja suficiente para cada incremento de software y as! facilitar eJ movimiento hacla el incremento proximo. La mete subraya el uso de un canjunlo de patrones de proceso de software que han probado su efectividad en proyectos con Umites de tiempo muy ajustados, requisitos cambiantes y que son enticos para el negocio. cada patr6n de proceso define un canjunlo de tareas de desarrollo y permite al equipo de mete conslruir un proce-

so que se ada pte a las necesidades del proyecto. Cristal es una familia de modelos agiles de proceso que pueden adaptarse a las caracteristicas especlficas de un proyecto. Como atros enfoques agiles, cristal adopta una estrategia iterativa, pero se ajusta al rigor del proceso para incluir proyectos
de tamanos y complejidades diferentes. EI desarrollo conducido por caracteristicas (DCC) es algo mas "fonnal" que otTOS metodos agiles, pero aun asl mantiene la agilidad al enfocar al equipo de proyecto en el desarrollo de caracteristicas, fundones que evahla el cJiente y que se pueden implementar en dos semanas 0 menos. El DeC concede una mayor importanda al proyecto y a su gesti6n que otros enfoques agiles. El modelado agH (MAl sugiere que el modelado es esencial para todos los sistemas, pero que la complejidad, tipo y tamano del modele debe ajustarse al software que sera construido. Mediante la proposid6n de una serie de principios de modelado esenciales y complementarios, el

MA proporciona una guia util para los profesionales durante las tareas de analisis y
diseno.

lAOM961 Advanced Development Methods, Inc., ~Origins of Serum-, 1996, http://www.controlchaos.com/. IAc:.I03J The Agile Alliance Home Page, http://www.agileal1iance.org/home. lAMB02) Ambler,S., "What is Agile Modeling (AM)?~, 2002, http://www.agilemodeling.com/ index.htm. {BEC99] Be<:k, K .. Extreme Programming Explained: Embrace Change, Addison -wesley, 1m. [BEC01aj seck, K- et aI, "Manifesto for Agile Software Development", http://www.agilemanifesto.org/. IBECOIb] .Be<:k, K. Y M. Fowler, Planning Extreme Programming, Addison -Wesley, 2001. IBEE99] Beedle, M. et al., HSCRUM: An extension pattern language for hyperproductive software development incluido en: Pattern Languages o/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 volumenes, wiley, 1996, 2000. [COA99[ Coad, P, E. Lefebvre y J. Deluca, Java Modeling In Color with UML, Prentice-Hall, 1999 {COCO II Cockburn, A. y J. Highsmith, "Agile Software Development: The People Factor", IEEE Computer, vol 34, nO.m. II, noviembre de 2001, pp. 131-133. ICOC02a1 COCkburn, A., Agik.5<1M'are Developmenl, Addison-wesley, 2002 ICOC02bj COCkburn, A., "What is Agile and what Does ltlmpJy?", presentado en el Agile Development Summit en Westminster college en Salt Lake City, mano de 2002, httpllcrystalmethodologies.orgl [CCS021 C53 Consulting Services, 2002, httpJwwwcs3inc.com/DSDM. htm. [DEM98] DeMarco, T. y T Uster, Peopleware, 2a ed, Dorset House, 1998. {DEM02) DeMarco, T y B. Boehm, "The Agile Methods Fray", en IEEE Compuler, vol. 35, mlm. 6, junlo de 2002, pp 90-92
U ,

101

IFOWOO] Fowler, M. el ai., Rejacforinglmproving the Design ojExJstlllg Code, Addison-wesley, 2000. [FOWOI] Fowler M. y J Highsmith, "The Agile Maniresto~, Sojlware lkvelopmenl Magazine, agosto

de 2001, http://www.sdmsgazine.com/documents/s..844/sdmO l OSa_htm.

[FOW02l Fowler, M., "The New Methodology", junio de 2002, http://www.martinfowler.com/ articles/ newMethodology html.N8B IHIG98] Highsmith, J.. - Ufe-The Artificial and the Real-, Software ~Iopmenl. 1998, en

http.llwww.adaptivesd.com/artic1es/order.htmL
[HIGOO] Highsmith, J., Adaptive Sojhvare Development. An Evolufionary Approach lo Managing complex S)Slmls, Dorset House Publishing, 1998. [HIGOII Highsmith, j. (ed.). "The Greal Methodologies Debate: Part 1-, CUller fT Journal, vol [4.

num.12.diciembrede2001.
[HlG02a] Highsmith, J. (ed.l. "The Great Methodologies Debate: Part 2~. Cutter rr Journal, voL 15. num, I, enero de 2002, [HIG02bj H!ghsmith, J. .wile Software Development Ecosystems, Addison -wesley. 2002, UAC021 Jacobson, 1, "A Resounding 'Yes' to Agile Processes-But Also More~, Cutter frJoumal, vol 15. num. I. enero de 2002, pp, 18-24. UEFO l j Jeffries. R. ef al,. Extreme Programming fnswlled. Addison-wesley, 2001. [NOY02l Noyes, B., "Rugby. Anyone?", Managing Development (una publicacl6n en llnea de Fawcetle Technical Publications). Junia de 2002. http://wwwfawcetle.com/resources/managingdev/methodologies/scruml (PAL02/ Palmer, S. y J, Felsing, A Practical Guide to Feature Driven ~opmen/. Prentice-Hall, 2002. [SCHOll Schwaber, K, y M Beedle. Agile Software Development with 5CRUM. PrenUce-Hall. 2001 [SCH02l Schwaber. K. "Agile Processes and Self Organization". Agile Alliance, 2002, http://www.aanpo.org/articles/index ISTA97( Stapleton, J., DSDM-DynamIC system Development Method The Method in PmClJce. Addison wesley. 1997. [WEL99] Wells, D" "XP-Unit Tests 1999. http://www.extremeprogramming.org/rules/ unittestshtml.
ff

4 . 1. Lease de nuevo el "Manifiesto para el desarrollo agil de sonware~ al prlnclpio de este capitulo ,El lector puede pensar en una situaci6n en la que uno a mas de los cuatro "valores" pueda meter a un equipo de software en problemas' 4.2. Descrlbase agilidad (para proyectos de software) con palabras proplas. 4 .3. ,Por qu~ un proceso iterativo facilita mas manejar el cambio? ,Todos los procesos agiles tratados en este capitulo son iterativos' tEs posible conduir un proyecto en s6lo una iteraci6n y aun asl seguir siendo agi1? Expliquense las respuestas. 4.4. ,Podria cada uno de los procesos agi1es describirse recurriendo a las actividades genencas del marco de trabate mencionadas en el capitulo 2? constniyase una tabla que colaque las actividades genericas dentro de las actividades definidas para cada proceso agil 4 .5 . Tratese de idear un "principia de agilidad" adlcional que pudiera ayudar a una equipo de ingenieria del software a volverse aun mas maneJable. 4 .6. Selecci6nese un principio de agilidad de los enunciados de la secci6n 4.1 y tratese de determinar si cada uno de los modeios de proceso presentados en este capltulo mueslran el prlncipio. 4 .7. ,Por qut cambian tanto los requisitos? Desputs de todo. ,13 gente no sabe 10 que quiere? 4 .S. Considtrense los stele rasgos enunciados en la secci6n 4.2 .2 Ordenense [as rassos con base en su percepci6n desde 10 que es mas importante hasta 10 que tlene menor importancia 4 .9 . La mayoria de los procesos agUes recomiendan la comunicaci6n cara a cara Aun en la actualidad, los miembros de un equlpo de software y sus clientes pueden estar geograficamen-


102
PARTE UNO n
f'ROCESO

Dn SOFTWARE

Ie separados entre 51. "Esto implica la necesidad de evilar /a separaci6n geografica? /.Es pasiblt: pensar en formas de con/Tarrestar esfe problema? 4 . 10, Escnbase una historia del U5uario para PE que describa los "silios favori/os" 0 la caracteristica de ~favor'itos~ disponible en la mayorla de los exploradores Web 4. 11 . ,Que es una soluci6n pice en PE?

4. 12. Oescrlbanse los conceptos de PE re!abricad6n y programac/6n en pareja con palabras propias.
4.13. U\i1icese la planlilla del patr6n de proceso presentada en el capItulo 2 y desarr6l1ese un patr6n de proceso para cua lquiera de los patrones de meJe presentados en la secci6n 4 3.4 4. 14 . LPor que se dice que crista l es una/emilio de m~f()(}os d8/1ts? 4 . 15. Utilicese la plantilla de caraeteristiea para el DCC descrito en la secci6n 4.3.6 y definase un conjunto de caraclerislicas de un explorador Web. Ahora desarrollese un conjun lO de carac teriSlicas para el conjunlo mencionado anles

4 . 16. Visitese el sitlo olicial del modelado 'gil y hagase una lisla completa de tados los princi pios de MA esenciales y complementarios

La ftlosofla lotal y los principios subyacentes del desarrollo Agi! de software se consideran a profundidad. en los IIbros de Ambler !Agile Modeling, Wiley, 2002), Beck [BEC99]. Cockburn [COC021 y Highsmith [HIG02b\ loS libros de Beck IBEC99I. Jeffries y sus colegas (EXtr~ Programmmglnslalled, Addison weSley, 2000), Succi y Marchesi (EXl!eme Programming EXammed, Addison wesley, 200 1). New kirk y Martin ~trcme Programming in Practice, Addison wesley, 200 I) Y AVer y sus colegas (EXtreme Programming Applied Play to \in, Addison-wesley, 2001) ofrecen una exposici6n de los pros y contras de la PE junto con una gufa de la mejor forma de aplicarla McBreen (Ques tioning E>;lreme Programming, Addison Wesley, 20(3) asume una posid6n crilica con respeclo a la PE, al definir cuAndo y d6nde esla es apropiada. Por otro lado, McBreen (Pair Programming tJummatcd, Addison-wesley, 2003) presenta una consideraclon profunda de la programacion en pareja Fowler y sus colegas (Re/actorins: Improving /he Design of Existing Code, Addison-wesley. 1999) se enfoca en un nivel muy detallado en el importante concepto de la refabTicacibn dentro de la PE. McBreen (SoJhwre craftsmanship The Nav Imperative, Addison-Wesley, 2001) analiza el arte del software y aboga a favor de las alternativas agiles y la ingenlerta de software tradi donal. El DSA 10 aborda a profundidad Highsmith [HlGOOJ. Stapetlon realiz6 un Iralamiento valioso del MDSD (DSDM The Method in Practice, Addison-wesley. 1997). Palmer y Felsing IPAW2] presentan un tratamiento detallado del OCC. Carmichael y Haywood (Bdter sojtware FasJ.er Prentice-Hall. 2002) presentan otro util tratamiento del DCC que inc1uye un recuento paso a paso por la mecanica del proceso. SChwaber y sus colegas (Agile Software Development wi/h seRUM, Prentice-Hall, 2001) presentan un delallado tratamlenlo de la mele. Manin CAB,/e SOftware Developmen/, Prentice-Hail, 20(3) analiza los principiOS. patrones )' praclicas .3giles poniendo especial cuidado en la PE. Poppendieck y Poppendieck (l.6:2n De\It'lopment, An Agile TOOlkit for SOftware Development Managers, Addison-Wesley, 2003) propordona las directrices para manejar y controlar los proyectos agHes. Highsmith !Agile software Development Ecosystems, Addison-wesley. 2002) presenta una valiosa vision de principios. procesos y practicas agiles En Internet se dispone de una amplia varledad de fuentes de Informaci6n sobre el desarrollo agil de software. En el silio web de SEPA se puede encontrar una !ista actualizada de rererencias en la red mundial. las cuaJes son relevantes para el proceso agll http://www.mhhe.comJpressman.

PARTE

PRACTICA DE LA INGENIERiA DEL SOFTWARE

n esla parte de rngenierkl del software: un enJoque prdctico se apren. dera aeerca de los principios, conceptos y metodos que comprende la practica de la ingenietia del software En los capilulos siguientes se abordar~n las siguientes preguntas: ,Que conceptos y principios guian la practLca de la lngenlerla del soft

ware?
iDe que manera la ingenierfa de sistemas conduce a una ingenieria del
software efectiva? .i,Que es la ingenierfa de requisitos, y cuaies son los conceptos Telacionados que conducen a un buen analisls de requisilos?

,C6mo se erea el modelo de analisis y cuales son sus elementos?

,Que es ingenieria de disei'io y cuales SOn los conceptos relacionados

que conducen a un buen disefio?

,Que conceptos, modelos y me:todos se utiHzan para crear disei'ios arquitect6nicos, de interraz y al nivel de componenleS?

,Que estrategias son apHcables a la realizaci6n de pruebas de software? (Que metodos se utilizan para diseiiar casos de prueba efectivos? ,Que mediciones y melricas se usan para establecer la calldad de! ar.~li sis y los modelos de diseno, c6digo fuente y casos de prueba'

Una vez que estas preguntas hayan sido respondidas, habr~ una mejor preparaci6n para la pr~ctica de la ingenierla del software

103

PRACTICA: UNA VISION GENERICA

LA

-'" ........ .CLAVE

CONCEPTOS

n un libro que explora las vidas y los pensamientos de los ingenieros de software. Ellen Ullman IULL971 representa un rragmento de vida al relatar

105 pensamlentos de un practicante bajo presi6n:

........ .117 ......... 1'16

.I . . . . .119
.........1'lI

"-

No [engo idea de que hora es. No hay ventanas en e.ta olicina. tampoco reloj, SOia el LED parpadeanle en rojO de un homo de microondas. el eual parpadea 12:00, 12:00. 12:00. 12:00_}ee1 y yo hcmos eslado programando por dias. Tenemos un "bicho", eJ necio demonio de un error POT eso la pulsaciOn roja sin tiempo se sientc bieIl. como

una iectura de nuestros cerebros, los cuales se han smcronizado de alguna manera
a la misma vdoddad del parpadeo
(.En que estamos trabalando?
Los detalles se me cscapan ahora. Podriamos eSiar

1.~123

dill .......

1"

ayudando a genie pobre y enferma 0 ajustanda una serie de Minas de balo nivel para
ven/karbits en un protocolo de una base de datos dlstrihuida. no me importa. Me de herfa importar; ~n olra part~ de mi ser -mas tarde, quiza ruando salgamos d~ este cuarto Ileno de computadoras- me importara mucho por que, para quien y con que prop6s110 estoy escribiendo sonware, Pero ahora no. He pasado a trav~ de una membrana donde el mundo real y sus usos ya no importan. Soy un ingemerode soft ~ ware .

........ 107

....... ..- ..
~

1.,.....113 ......1.124

w'tIH ...... .lIS

............ .116

Sin duda, una imagen oscura de la pnktica de la ingenieria del software, pero con 1a que, despues de reflexionar, muchas de los lectores de este libra seran capaces de identificarse.

cW camino para IIegor .., d.tino. La pr6c:tica pro'

neceaitan para lran-

IDs bIoq..os del camino y

"""'" donde -.. _ ..iCIer lot COIICepIo$

COiiipi.tder Y segvir

cit manero segura y r6pida.

l1Iducir y

pr6ctico
\oftI

d6nde dela inge que se rea-

tI ""'-" ....uciono reaIidod .

......., 00'" tre! elementos que ,. aplMxm sin imponar el

pn:atO que Ie

MCOia

fltos son 105

'04

c APfnn.o 5

LA PRACTICA UNA VISl6N GENtiuCA

105

c:oncapIOi 'I princi-

.rdm .....

o.,.ue. ..

Las personas que crean software de computadora practican el arte. 1a maestrla a la disciplina l llamada ingenieria del software. Pera, ,que es 1a "pnkticu" de In ingenieria del software? En un sentido generico, la practica es una colecci6n de conceplos, principios. metodos y herramientas a las que un ingeniero de software recurre a diana. La practica permite a los gerentes coordinar proyect05 de software c ingcnicros de la especialidad para canstruir programas de computadara. La pn'tctica multiplica un modelo de proceso de software can los c6mos tecnicos y de gesti6n necesarlos para reaJizar el trabajo. La practica trans(orma un en(oque fortuilo en algo mas organizado, mas erectiva y can mas probabilidades de alcanzar eJ exito.

En el capitulo 2 se introdujo un modelo de proceso de software generico compuesto de una serle de actividades que establecen un marco de trabajo para la practica de la ingenieria del software. Las actividades genericas del marco de tnlbajo -cornu nicaci6n , planeaci6n. modelado. construcci6n y despliegue- y las actividades sombrilla establecen la arquitectura de una esqueleto para el trabajo de ingenieria del software. Todos los modelos de proceso de software presentados en los capltulos 3 y 4 pueden organizarse en este esqueleto arquitect6nico. , Pero que cabida tlene ahi la pr.ktica de la ingenieria del software? En las secciones siguientes se consideranin los conceptos y principlos genericos que se aplican a las actividades del marco de trabajo.l

Algunos escritores utilizan uno de eslos lermines y excluyen los otros. En realldad.la Ingenieria del dwa re es las Ires cosas a la vez 2 se exhorta al lector para que revise Ia.:5 secCiones relevantes denlTO de esle capitulo, conforme se dl!CUtan los I"l'telodos especlflWS de 13 ingenieria del software y las activldades sombrilla en \os capltulos posleriores del libro I

106

PARTE DOS

PRAcnCA DE IA lNGENIERiA 00. ~ARE

5.1.1 La esencia de 1a pract1ca

E.n un libra clasico, How to Solve It, escrito antes de que existleran las computadoras modern as, George Polya (POL45) puntualiz6 la esencia de la resoluci6n de proble-

.. 01""
I'Myo artSiSIUII

....-,_.
Sopo/fu_

mas y. en consecuencia, la esencia de la

practica de la ingenierfa del software:

I . Enlenderel problema (comunicaci6n y analisis).

2 . Pianear una soluci6n (modelado y diseno de software).
3. Uevar a cabo eJ plan (generaci6n de c6digo).

"""""em ...
IS COIIIOO IItIllI

fs 'Iffdod. Iwus

frr.ItttOO ctWI Ie ~ eI Wltido /10

rIU1do del rohwoJe.

4. Examinar e1 resultodo para probar 10 precisi6n (realizaci6n de pruebas y aseguramiento de la caUdad).

En el contexto de la ingenieJia del software estos pasos de sentido comun conducen a una serie de preguntas esenciales ladaptadas de POL45} ,
Ent ender e l problema.
.iA quitn Ie interesa la soluci6n del problema? Es decjr, ,quienes son los clientes?

tCualcs aspectos se desconocen? ,Que datos, funclones, caracterlsticas y

comportamientos se requieren para resolver de manera apropiada el problema?

tEl problema puede dividirse en calegorias? .i.Es posible representar problemas

menores que puedan entenderse con mayor facilidad?

tEl problema puede representarse de manem grdflca? .i.Se puede crear un

modelo de analisis?

Planear la soluci6n .
i5e habfan visla problemas similares anfes? ,Existen patrones reconocibles en una soluci6n potencial? ,Hay un software existente que implemente los datos, las fundones, las caracterlsticas y los comportamientos que se requieren?

t& ha resueiro un problema similar? 5i es as!, .i.los elementos de la so1uci6n

pueden reutilizarse?

tSe pueden deftnir los subproblemas? 5i es as!. ,las soluclones para los subproblemas parecen fa.d\es?

t& puede representor una so/uci6n de modo que conduzca a una implementad6n efectiva? .i.Se puede crear un modelo de diseno?

Uevar a cabo el plan.

(La soluci6n marcha conforme 01 plan? .i.E1 c6digo fuente

se puede seguir

con forme al modelo de disei'lo?

<.Es probable que coda parle de 10 soluci6n del componenle sea correcta? ,5e ha
revisado el disei'io y el c6digo, 0 mejor a(m, se han aplicado al algoritmo pruebas de correcci6n?

CAPiTuLo 5

LA PRACilCA. UNA 'IlSl6N GNRicA

107

Examinar el resu1tado .

iEs posible probar cada pane de la soludon del componente? ,Se ha implemenlado una estrategia de prueba razonable?
iLa solucion produce resultados acordes con los datos, ji.mdones, rasgos y comportamientos que se requieren? ,El software ha sido validado contra todos los requisitos de los cJientes?

5.1.2 Ptinclplos esenclales

EI dicdonario define la palabra principio como ~una ley 0 supuesto importante que se requiere en un sistema de pensamiento". A traves de este libra se examinan principios en muchos grados diferentes de abstracd6n. Algunos se enfocan en la ingenieria del software como un todo, otros consideran una actividad generica yespedfica del marco de tTabajo (por ejemplo, comunicaci6n can el c1iente) , y otros se centran en acciones de la ingenieria del software (como diseno arquitect6nico) a tareas tecnicas (escribiT un escenario de uso). Sin importar que tan especificos son, los principios ayudan a establecer un conjunto s61ido de practica de ingenierla del software. Por esa raz6n son importantes. David Hooker [HOO961 ha propuesto siete principios esenciales, los cuales se enfocan en la practica de la ingenierla del software como un tooo, que se reproducen enseguida. 3

EI primer prindpio: /0 raz6n por /0 que rodo existe

Un sistema de software existe por una raz6n: pam ojrecer un valor a sus usuarios. Todas las decisiones deben tomarse con esto en mente. Antes de espedficar un requisito de un Sistema, antes de sei'iaiar una pieza de funcionalidad del sistema, antes de detenninar las platafonnas del hardware 0 los proce:sos de desarrollo, uno debe hacerse preguntas como: ,eslo agrega un valor real al sistema? 5i la respuesta es negativa no se debe hacer. TOOos los demas principios estan apoyados en este.

El segundo prindpio: MS (manfenerlo simple)

EI diseno de software no es un proceso fortuito. Existen muchos factores que deben considerarse en cualquier esfuerzo de diseno. Rldo eJ diseflo debe ser tan simple como sea posible, pero no mas simple. Esto facilila un sistema de mas fadl comprensi6n y entendimiento. Eslo no quiere decir que las caracteristicas, hasta las intemas, deban descartarse en nombre de la simplicidad. Ademas, los disei'ios mas elegantes por 10 general son los mas simples. Simple tampoco significa ~rapido y malo~. De hecho, se

3 Reproducido con permiso del autor fHClO96I . Hooker define patrones para estos principios en http://c2.com/cgi/wiki?SevenPrinciplesOfSoI\wareDevc:lopment

loa

PARTE DOS PRACIiCA DE LA INGENIll!tA DEl. SOFlWAJll:

requiere de mucha renexi6n y trabaja sobre multiples iteradones para simplificar. EI

resuitado buscado es un software que se mantenga y sea menos propenso aJ error.

Io~. ~ruoI~.

""' ...

_.10_

El tercer principia: mantener la vision

Una vision clara es esendaJ para el 6cilo de un prqyecto de software. Sin la visi6n clara
el proyecto podrfa terminar con Ndos (0 mas) significados" en uno. Sin una integri~

dad conceptual un sistema amenaza con tomarse en una masa confusa de disefios incompatibles, unida por un tipo inadecuado de tamillas ... Arriesgar la visi6n arquitect6nica de un sistema de software debilita y aJ final Tompe hasta un sistema bien disenado. Tener a un arquitecto capaz de mantener la 0 acordado ayuda al aseguramiento de que un proyecto de softvisi6n y reforzar 1
ware sea exitoso.

1::1 cuarto prindpio: /0 que uno produzco, oeTOS 10 consumirdn

En muy pocas ocasiones un sistema de software con fuerza industrial se construye y utillza de manera aislada. De alguna u otra forma, alguien mas utilizara, mantendra, documentara 0 dependera de su capacidad de entender el sistema. Por 10 tanto, siempre debe especificarse. disenarse e implementarse con la idea de que alguien mas tendra que entender 1 0 que se realice. La audiencia de cualquier producto de software es potencialmente grande, por 1 0 que se debe especificar tomando en cuenta a los USU<l.rios. Se debe disenar teniendo en mente a quienes 10 implementen, asi como codificar considerando a aquellos que deben mantener y extender el sistema. Tal vez alguien tenga que depurar eJ c6digo escrito y eso 10 convertira en un usuario del c6digo. EI hecho de facilitar el trabajo a otro agrega valor al sistema.

Si eI softwore tiene 1Il m. Qc;/G COO1biaO c

In Iorgo de ru 'IiOO Cd. Por eso rnz6n, eI softwcre debe
COIlSITwse lie forma

~~VE

'II' room <b IIIIJnleoini8nto.

1::1 quinto principio: estar abierfo oJ futuro

Un sistema con una larga vida liene mas valor. En los ambientes computacionales de la actualidad, en los que las especificaciones cambian a cada momento y las plataformas de hardware son obsoletas despues de algunos meses, la vida del software se mide, de modo tipieo, en meses en lugar de aitos. No obstante, los verdaderos sistemas de software Neon fuerza i ndustrial" deben durar mas tiempo. Estos sistemas tendran exito si estan listos para adaptarse a estos y otros cambios. Los sistemas que logran el exito son aquellos que han sido diseftados de esta manera desde el principio. Nunca ~ debe disenar para lIegar a una esquina. Uno siempre se debe preguntar: ",que tal si?", y prepararse para todas las respuestas posibles, al crear sistemas que resuelvan el problema general, no un problema especifico.~ Es muy probable que esto conduzca a la reutilizaci6n de un sistema entero.
4 Nota del autor esta recomendaci6n puede ser pehgrosa si se lIeva Ilasta el extremo. El diseno para el "problema general- algunas veces requiere compromisos de desempenoy puede implicar un rna. yor esfuerzo para el proyecto

CAPiTuLo 5

LA PRAcnCA. UNA V1S16N GENI':RicA

109

El Sexto prlndpio: pJanear para Ja reutiJizad6n

La reutilizad6n ahorra tiempo y esfuerzo. 5 Al alcanzar un alto grado de reutilizad6n
se logra una de las metas mas dificiles en el desarrollo de un sistema de software.

La reutilizad6n de c6digo y disefios ha sido proclamada como un beneficio importante del uso de tecnologfas orientadas a objetos. Sin embargo, la recuperadon de la inversion no es automatica. Las posibilidades de reutilizadon que proporciona la programaci6n orientada a objetos (o convencional) se podrtm considerar si se tiene una vision a futuro y una planeaci6n. Existen muchas tecnicas para llevar a cabo la reutilizaci6n en cada etapa del proceso de desarrollo del sistema; las relativas al disefto detallado y al nivel de c6digo son muy conocidas y estan bien documentadas. La nueva bibliografia se esta enfocando en la reutilizaci6n del disei\o en la forma de patrones de software. Sin embargo, esto es s6lo una parte de la batai!a. La comunicaci6n de oportunidades para la reutilizaci6n a otros integrantes de la organizadon es primordial. ,C6mo se puede reutilizar algo cuya existencia se ignora? La planeadon adelanfilda JXIra la reutilizad6n reduce d costo e incremenfil eI valor de los componentes reutilizables y los sistemas en que dichos componentes se incorporan.

EI septimo prlndpio: pensar

Este ultimo principio tal vez sea el que mas se pasa por alto. CQSl siempre, cuando se tiene un pensamienta claro y campleta anles de la acdon, se producen los mejores resulfildos. Cuando se reflexiona acerca de algo existe una mayor probabilidad de hacer[0 bien. Siempre se obliene eonocimiento de la manera de haeerlo bien de nuevo. Si se piensa en algo y aun asi se haee mal, esto se eonvierte en una experieneia valiosa. Un efecta coiaterai del pensamiento e5 aprender a reconoccr, cuando algulen no sabe alga, en que punta se puede investigar la respuesta. Cuanda eJ pensamiento claro se ha introducido en el sistema es cuando surge su valor real. La aplicacion de los primeros seis principios requiere una reflexiCm Imen.sa, por 10 Que la5 rccompcw sas potenciales son enonnes. Si todos los ingenieros de software y todos los equipos de desarrollo tan s6lo siguieran los siete principios de Hooker, muehas de las difieultades que se han experimentado durante la eonstrucci6n de sistemas complejos basados en eomputadora se podrfan eliminar.

Antes de que los requisitos del cliente puedan analizarse, modelarse 0 especificarse, estos deben reeopilarse por medio de una actividad de eomuniead6n (tambien lIamada abrenci6n de requisitos). Un cliente liene un problema que se puede ajustar a
5 Nota del autor: aunque esto es cierto para quienes reutilizan el software en proyectos filturos, la reutilizaci6n puede resultar cara para quiene5 deben disei'lar y construir componente5 reutilizables. AJgullOS estudios indican que el disefio y \a construcd6n de componentes reutilizables pueden costar entre 2S y 200 par ciento mas que el software solicitado En algunos casas, \a diferencia de costo no se puede justificar

110

una soluci6n basada en computadora. Un desarrollador responde a la solicilud ayuda del dienle. La comunicaci6n ha comenzado. Pero eJ camino desde \a COlT'& nicaci6n hasta el entendimiento suele estar Ilena de baches.
La

comunicaci6n efectiva (entre pares tecniCOS, con el cliente u atros p~~~:~::

del software y con los gerentes de proyecto) est3. entre las actividades mas que enfrenta un ingeniero de software En este contexta se examinan los prindpios

conceplOS de comunicad6n de acuerdo con la manera en que se aplican en la c

nicaci6n can eI cliente. Sin embargo, muchos de los principios se aplican del

modo a las formas de comunicaci6n que ocurren denlrO de un proyecto de soA.~

Princlplo f I : SCUchaT. Se debe centrar la atenci6n en las paJabras de q habla , en vez de fannular la respuesta a dichas paJabras. Es necesario pedir
expJicaci6n si algo no esta clara, pero deben evitarse las intenupciones constanta Nunca se debe ser connictivo con palabras 0 actitudes (por ejemplo, dirigir la I1\Q da a los lados 0 sacudir la cabeza) cuando una persona habla.
Mte:s.C~5e

debe m. SIIpO de M1tBndtr eI pookJ de

"" do 11 fXl", * necllSib1as, r

OIJG III IIlD ()] !iII

Princlpio 12: PreparaTSe antes de comunicar. Se debe invertir algUn tie en entender el problema antes de reunirse con otros. 5i es necesario. se puede rea Iizar una investigaci6n para entender el negocio y dominar la jerga. 5i se tiene la res ponsabiJidad de conducir la reuni6n, es recomendable preparar una agenda del antes de la junta. Princlplo 13: Alguien deM fadlitDr /a acdvidad. Cualquier reuni6n de c nicaci6n debe tener un Ifder 0 mediador J) para mantener una conversaci6n din;,;, mica y en una direcci6n productiva; 2) para mediar en cualquier conllicto que
ITa; 3) para a5egurar que se sigan los olros principios
~

enlMCes (ffiJ.

Princlplo ' 4: La comunicad6n cara a caTQ es 10 mejor. Pera, por 10 general funciona mejor cuando esta presente otra representaci6n de la informaci6n relevanIe. Por ejemplo, un participante podria crear un esquema 0 un documento que sirva como foco de la discusi6n

Princlpio 1#5 : Tomar notas y documentar las dedsiones. Las cosas suelen caer en malentendidos. Alguien que participe en la comunicaci6n debe servir como ~grabadora~ y escribir todos las puntas y decisiones importantes. Princlpio ' 6 : BILSalT la colaborad6n. La colaboraci6n y el consenso se presentan cuando el conocimiento colectivo de los miembros del equipo se combina para describir las funciones a caracteristicas del producto 0 sistema. Cada pequena colaboraci6n sirve para construir confianza entre los mlembros del equipo y crear una meta comun para dicho equipo. Princlpio 117: ConselVaT el en!oque, uaminar un mlxlulo a la va. Entre mas gente este implicada en una comunicaci6n, mas posibilidades existen de que la

III

discusi6n salte de un t6pico a1 siguiente. EI mediador debe mantener \a conversaci6n

centrada en un m6dulo sin dejar un tema hasta que este haya side resueito (sin

embargo, vease el principia '9).

La dilerencia entre cllentes y usuarios tinales

los infIenieros de softwan. mmunico't con n'UChos porticipontM difetenle$, J-'O ~ dientes -..0005 finale! liMen eI i"lXJdO m6s iignifio:mvo .........~jo. "";00 que ~. En.nc CIHol eI yel uworio ~ uno mismo, pem en muchos dienle y eI u$UOrio finollOn penonas
piopolciouo

10,. requi~ b6~ del producto; A) c::oordino \0, recunos econ6micos pore eI PfO)'KIo. En un

:::::;;,;:::.:poro
e$

negocio de productos 0 si$!emc;H, con frecvencio eI dieote eI deportomenlo de merc.odotecnia. En un ombienle de n eI dienle puecIe ser un cxwnponenla 0 deportomenlo del negocio.
lIS

di~ ocImini~ WI
corulNir; 2) define 105

10 per100CI 0 grupo que: I) en un inicio

MI YO
(I

do """"""

.I softwore

MaIllS 10 penona 0 grupo que: II.., ndidad IIOftwore que se conslN)'e fXlra oIo:mor algUn prop6silo de negoc:ios, y 2) deflnira los dek.11es operativos del softwore de forma que eI ~Io del negocio puedo

Un usuorio
usar6 eI

negocios poro eI 5Oftware; 3)

""""=~

Prlndpio ' 8 : Si algo no esla daro, sc haec un dlbuJo. La comunicaci6n ver bal s610 lIega hasta cierto punto Con frecuencia un esquema 0 figura puede propor
donar claridad cuando las palabras (allan al realizar su trabajo.
Prindpio '9: a) Una vu que se llega a un acuerdo sobre algo, se debe ~on tmuar; b) sJ no se puetle llegar a un acuerdo, se debe (;ondnuar; <:) sl una aIracteristJaI o/Undon no ~tQ daro y no u puede clarijicar en eI momento, se debe cont/nuar. La comunicad6n, como cualquier actividad de ingenieria del software, requiere de tiempo. En lugar de que se [tere sin On, los paniclp(.IntC!i deben reconocer que hay muchos t6picos que requieren analisis (vease eJ princlpio #2) y que ~continuar" algunas veces es la mejor (onna agilitar la comunicacion

Prindpio ' 10: LA negododon no es un conrol"SO 0 un juego. Fundona mejor cuando ambas partes ganan. En muchas OQsiones los ingcnicros de :;on ware y el diente deben ncgodar rundone:; y caractcr1StiCIlS, prlorldadC3 y rccha~ cle entrega. 5i el equipo ha colaborado de buena forma. todas las partes tienen \Ina meta comUn. Por \0 tanto, la negociaci6n demandarA el compromise de toda3 la3 partcj .

Iota

de c.omuniaIci6n

Ed:

VIftOd: lo .-....N6n d. ;"ic:Io'" progt ..nodo poro kI

_ .......

;au. hon oido~ de .... ~ ..

pm.;mo-

112

PARTE DOS

PRAcncA DE LA INGENlRL\ 00. OCFTWARE

. . . .- . . . .~:-~::s~~;; o6Mo.--.
de 10 ,.,ni6n . "wIubOio.OI.a"
que op.Ju,.....
~d..i.-nas,

_ . .......-....
1m
_Iipod.
no

W: PICA"" -'cI o/ici~ ............. _ ...... ;"1 tipo d. CJIIIf1III

. . . AIIIbo. . . . . .

v.... Vi qui Doug Ilia ...

lWCJoIisib"
~

Podrio C!pCIID

".-do-

_ .......... .......'.iIIi
Vinod 1 mlll'llI 51, cbo..

Conjunto de

tCD'e<JS

genertcas para la comtulfcacfcSn

Solidos y entroOos resukornes.
Caroc:ll!Wisticas, funciones y comportomientos
importon~
RiMgO'

1. ldenlifioor 01diente primorio y otros

porticiponloes {secci6n 7.3.1).

2. Reunine con eI dine ptimorio pot'CI los "pregunlm libre~ de contwo" IMllXi6n 7.3..41. los 0J01es definMI:
los ~ y vaIores del negocio los conxterhtM;:os y neces.idades del usuario final
Ln KJlioos visible! que a

del ~.

de negocios definidos por eI clienle (MICci6n 25.3).

hayan requerido para

6. Dnon-oIIor una ~ descrip:i6n escrOO (por ejempIo, uno ~ de ~Mo$) de~,

soIioos/enlrodos, corode,hticos/funciones y rifl9O$.

eI uworio.
las restricciones delnfI9OCio.
7.

Iteror con eI dienle para refinor los MCeOOOos, soIicb/enImdos, corodefi1ticoslfunciones y I"ie$go$.
escenario del uworio, caracterbtica, ccmporiomienlo (Sci6n 7.A 2) .

3. I:>rMorrollor un enunciodo escrilo de uno pOgino wb.-e eI 6mbilo del proyedo, eI cool esiO sujeto a
reo-isiOn

en

8. ~ prioridodes definidos por eI clienle a coda

funci6n y

Revisor eI enunciodo d.I 6rnbi1o con 1m I~ ttl ~ y Ojuslorlo segUr! 10 requerido.

5. CoIabomr con definir'

eI clienlll Y eI usuario finol para

9. Reisar todo Ia iniormociOn recopilodo durant. 10 odiidod de eomunicoci6n con.l diente y otros porticipontel, y ojuwrio de 10 forma que HI
requiem.

E~ de V$O vi~~ para eI dienlll con eI V$O del fonnato esl6nda~ I~ 7.5).

10. Prepomne para 10 octividod de pIoneociOn

I"""""' 23 y 241

LoS formalos para escenarios de uso se dlSCUlen en d capilukl 8

cAPinn..o 5

LA PM.CTICA UNA VlSI6N GaltJucA

113

La actividad de comunicaci6n ayuda al equipo de software a definir sus metas y obje

tivos generales (por supuesto. sujeto al cambio conforme pasa el tiempo). Sin embargo. entender estas metas y objetivos no es 10 mismo que definir un plan para Ilegar a ellos. La actividad de pJaneacion abarca un conjunto de prokticas tecnicas y de gesti6n que penniten al equipo de software definir un mapa del camino mientras se viaja a traves de Sll meta estrategica y obJetivos ttlcticos

't 5

".DwIpID. a

Existen muchos enfoques diferentes para la planeaci6n. Algunas personas son "minimalistas". y argumentan que el cambio con frecuencia obvia la necesidad de un plan detallado. atros son tradicionalistas. y dicen que el plan proporciona un mapa efectivo del camino. y mientras mtls detallado sea este, Menor probabilidad habra de que el equipo pierda el rumbo. Ademas, atros son "agillstas" y argumcnlan que tal vez un "juego de planeacl6n" rtlpido sea necesario. pero que el mapa del camino sur gira ruando comience el "trabaja real" sobre el software. iQue hacer? En muchos proyectos la sobreplaneaciOn consume tiempo y no pro duce frulos (demasiadas casas cambian), pero la planeaci6n insuficiente es una receta para el caos. Como la mayorla de las cosas en la vida, la planeacl6n se debe produdr con moderaci6n, 10 suficienle para proporcionar una gulol ulll pilra cl cqui po -no mAs. no menos. Sin importar el rigor con el que se conduzca la planead6n, los si8uientes prim:i pios son validos en todo momento.

Prindpio ' 1: Entender los aleances del proyecto, Es imposible utilizar un mapa de carreteras si no se sabe el sitio a donde se quiere ir. EI hecho de entcnder
los alcances proporciona al equipo de software un destlno.

Principlo *2: Invo/ucror oj cllcnlc en 10 ocr/vldad de planead6n, EI clienl!: define prioridades y establece las restricciones del proyecto. EI ajuste de estas reali
dades a menudo requiere que los ingenieros de software negocien las 6rdenes de entrega. los limites de tiempo y otros asuntos relacionados con el proyecto.

Principlo 13: RtcOnocer que Ja pJanead6n es iteratlva. El plan de un pro yecto nunca se graba en una piedra. En cuanto comience el trabajo es muy probable que las cosas cambien. En consecuenda, debe ajustarse el plan para adaplarlo a los
cambios...-.demas. los modelos iterativos e Incrementales del proceso Qlctan la reDid neaci6n (despues de la entrega de cada incremento de software) basada en la retroa limentaci6n recibida de los usuarios.

"4
Principia 14: BdmDr con base en eJ conodmiento disponible. La finalidad de Ja estimaclOn es pr~rdonar un indicia del esfuerzo, costa y duradOn de las
tareas, con base en el conocimiento que el equipo liene del trabajo que se va a rea lizar. SI la infamad6n es vaga 0 poco confiable, las estimaciones tendrtm, de igual

[onna. poea confiabilidad.

Prindpla liS: Cons/derar el riesgo ruando se define el plan. 51 el equipo ha detinido riesgos que tienen un alto impacto y una alta probabilidad, es necesario un plan de contingencia. Ademas. el plan de proyecto (que induye e\ calendarioj se debe ajustar para incluiT la posibilidad de que uno 0 mas de estos riesgos se lome un problema real. Principia 116: Scr rea/ista. Las personas no tTabajan el 100 por dento de cada dia. E! ruido siempre entTa en cualquier comunicaci6n humana. Las omisiones y la ambiguedad son hechos de la vida. Los camblos ocurriran. Hasta los mejores ingenieros de software cometen errores. Estas y olras realidades deben considerarse mientras se establece el plan del proyecto.

I '8_d ....
&,
~'f>.

_0101 ........... _

.. 0101 ....

~... l

Prindpio *1: Ajustar la granuJaridad mielllras se define el plan . La granulandad se refiere al grado de detalle que se introduce conforme se desarrolla el plan

C~VE

Sf

EI !6mWIo probdod De ~ dede coo

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 Ngranularidad gruesa proporciona tareas de trabajo mas amplias, las cuales se planean en periodos mas largos. Por 10 general, la granularidad cambia de fina a gruesa conforme el tiempo limite del proyecto esta mas lejos de la fecha actual. En las siguientes semaH

. .. Ogoms

.........

-~.

'ef'esentoo 0 dngen.

nas 0 meses el proyecto se puede planear con detalle significativ~. Las adividades que no se realizaran por muchos meses no requieren una granularidad fina (hay demasiadas cosas que pueden cambiar) Princlplo ItS: Definlr como se intentara asegurar 10 colidad. El plan debe identilicar la forma en que el equipo de software pretende asegurar la calidad 5i habra revisiones tecnicas formales/ estas se deben calendarizar. En caso de que se utilice programaci6n en pareja (capitulo 4) durante la construcci6n esta debe estar definida de manera expllcita en el plan Principio 19: Dcscribir como se prefende lnduir el combio. Incluso a la mejor planeaci6n puede superarla el cambia incantralable. EI equipo de software debe identificar la forma en que se incluiran los cambias canforme se realiza el trabajo de ingenieria del software. Por ejempla, Gel cliente puede solicitar un cambia en
7

u.s revislones tecnicas formales se estu(lian en el capitulo 26

cAPinn.o 5

LA PRA.cncA UNA v!SION GDd:RIcA

115

cualquier momento? lSi se presenta una solieitud de cambio el equipo esta obligado a implementarlo de inmediato? lC6mo se evaluan el impacto y el costo del cambio?

Principia ' 10 : Adaptor e1 plan a menudo y hoar los ajusres wando 4!stos se requJeran. Dfa tras dla los proyectos de software van por detras del calendario
establecido. Por ello. es de mucha ayuda adaptar el progreso a diario. se deben buscar areas problematicas y situaciones en las que ellrabajo calendarizado no vaya de acuerdo con el trabaja que se ejecuta en realidad. CUando se encuentran desfases, el plan se ajusta en concordancia con ello. En la busqueda de mayor efectividad, todos los integrantes del equipo de software deben partieipar en la actividad de planeaci6n. S6lo entonces son miembros del equipo "compromelidos~ con el plan. En un excelente documento sobre procesos y proyectos de software, Barry Boehm IBOE96) establece: "Se necesita un principio de organizaci6n que se reduzca para proporcionar planes Ide proyecto) simples para proyectos simples." Boehm sugiere un enfoque dirigido a los objetivos, rundamentos y calendarios del proyecto, a las responsabilidades, enfoques tecnicos y de gesti6n y a los recursos requeridos tJ 10 lIam6 prindplO WHH (why, what, when , Who, where:, how, how), debido a una serie de preguntas que conducen a una definici6n de caracteristicas clave del proyecto y el plan de proyecto resuitante:

lPor qu~ esta en desarrollo este sbtema? Todasias partes deben evaluar III validez de las razones del negocio para el trabajo en el software Dicho de olra manera, ,e] pr0p6sito del negocia justifica el gasto de personal, tiempo y dinero?
se hari.? Se debe identificar la funcionalidad que se construira y, por ende, las tareas requeridas para realizar el trabajo.
iQU~

iCuAndo se termlnari? Es necesario establecer un nujo de trabajo y un ti<:mpo

limite para las tareas clave del proyecto, asl como IdenUficar los fundamcntu~ rcqueridos por el c1iente.
iQuI~n es e1 responsable de una fundOn? Se deben definir el papel y la responsabilidad de cada miembro del equipo df! software

lEn d6nde se ubtcan dentro de la organizad6n? No todos los papeles y res ponsabilidades residen dentro del mismo equipo de software. EI cliente, los usuarios y otros participantes tambien tienen responsabilidades. iC6mo se reallzari. d trabaJo en los sentidos t~cnico y de gestl6n? Una vez que se establece el ambito del producto. es necesario definir una estrategia tecniea y de gesti6n para c:I proyecto.

lcuAnto se neceslta de cadil recuno1' La respuesta a <:sta prcgl.lnt.ol s<: obti<: ne al desa.rroilar estimaciones (capitulo 23) con base en las respuestas a las pregunlas anteriores.

116

PARTE DOS PRAcncA DE I-' /IIIGENERiA Dfl. SClF1WAR

Las respuestas a las preguntas WHH de Boehm son importantes independientemente del tamano 0 la complejidad de un proyecto de software. Perc, ,como se inicia el proceso de planeacion?

. , . . . que los das.rollodorll$ de sottw-e mn perdiendo .....dDd mri: III mayoriIlIe I. .U ....... .... " .. han. Bas pien5an .-10 _ , pero no 11$ asi"

CONJUNTO DE TAREAS

--

Con/unto de tareas genericas para la pJaneac10n

1. ReeYOluar eI ambito del proyecto Iseedones 7.4 y 21.31. 2. Evoh.f(lr los rie5gO$ 1sec:ci6n 25.4).
8. Crear un pion con gronularidod fine poro 10 ilenxi6n octuoIjcapituios 23 y 24).

3. ~rroI!ar 0 refiner los 8SC81'1Orios del usuorio

IMCCiooos 7.5 Y 8.5).

Dennir Ioreos de Irol:.o;o pam c:odo funci6n Y oorocleristioo jsea:i6n 23.6).

Estimor eI esfuerzo para c:odo torea de Irobajo heeei6n 23.6}.
Asigf"lOr responsobilidod poro

4.

Exlroef fvnc:iooM Y c:oroderhlic:os 0 partir de los e~rios (secci6n 8.51.

c:ado torea de

5.

Definir los IVnciones y coroderislicos .acnicos que lorman Ia infroedruc:turo del ooHwan..

trobo;o (sec:ci6n 23.41. Definir los produdos de Irobojo que ser6n ldentific:or los metodos poro eI oseguromiento de 10 c;oIidod que 5e UKJrOn (copitulo 26). Oe5c:ribir los metodos poro eI con"bio en 10 gesli6n Ic:opitulo 27).
9 . Ra~r eI progreso de monero regular (sec:ci6n 24.5.2).
~,

6. Agrvpor los Nnciones y coroderistic:os (esc:enorios) de oc:ueroo con 10 prioridod del dienle.
7. Crear lin pion de proyec:to coo grueso (copitulos 23 y 24).
......,~.

""""do..

Uf"IO

gronuloridod

Deh"ir eI "Urn.o proyec:todo de inc:lWI'*1ios de

Estoblecer un coIencIorio general del proyedo

(capitulo 24). Esioblec:er los fecnos de entrego prnyectodas para c:odo incremento.

los areas problem6ticos (por ejemplo, eI

desfose del caiendorio). Hocer los ojuskts que 5e requieron.

Los modelos se crean para obtener un mejor entendimiento de la entidad real que se construira. Cuando la entidad es un objeto fisico (por ejemplo, un edificio, un avi6n, una maquina), se puede construir un modele identico en forma y tamano, perc en menor escala. Sin embargo. cuando la entidad es software, el modele debe tomar una fonna diferente. Debe ser capaz de representar la informaci6n que el software transforma, la arquitectura y las funciones que permiten que ocurra la transfonnacion, las caracteristicas que desean los usuarios, y el comportamiento del sistema conforme se realiza la transfonnaci6n. Los modelos deben cumplir estos objetivos en diferentes grados de abstracci6n (primero al presentar el software desde el punto de vista del cliente y despues al representar el software en un nivel mas tecnico).

117

En el trabajo de la ingenierta del software se crean dos clases de modelos: modelos de antllisis y modelos de disel'io. Los mode/os de anallSls representan los requisitos del cJiente al presentar el software en Ires dominios diferentes: el dominic de la

informad6n, el dominic funcional y el dominic del comportamiento. Los modefos de disdio representan caracteristicas del software que ayudan a los profesionales a construirlo de manera efectiva; la arquitectura (capitulo 10), la interfaz del u$uarlo
(capitulo 12), y el detalle al nivel de componentes (capitulo J I). En las .secciones siguientes se presentan los principios y conceptos basicQs que son relevantes para eJ modelado del analisis y el diseno. Los metodos tecnicos y la

notacl6n que penniten que los ingenieros de software creen modelos de amilisis y

diseno se presentan en los capitulos posteriores.

I "II_~doI.:-:-""""_"_~"""'''''~'_~-':- 1
5.4.1
Prtncipios del modelado del an6lls1s
En las pasadas tres decadas se ha desarrollado un gran numero de melodos de modelado del analisis. Los inve5tigadores han Identificado los protJlemas del an311

sis y sus causas y han desarrollado una variedad de notaciones de mcxlelado y los conceptos heuristicos correspondientes para manejarJas. cada metoda de analisis tiene un punto de vista (jnlco. Sin embargo, lodos los melodos cle analisis esra.n rela cionados por media de una serie de principios operalivos; Principio , .: El dominio de informad6n de un problema debe represen tar.se y entendeISe. EI dominio de mJormad6n 10 forman los datos que nuyen hacla el sistema (a partir de los usuarios finales, olros sistemas a dispositivos extemos), los datos que f1uyen desde el sistema (a traves de la interfaz del usuario, interfases de red, reportes, graficas y otros medios) y los aimacenamlentos de datos que se recopilan y reorganizan los objetos consistentes de ;nformacib" (es dedr, los datos. que se mantienen en forma permanente). Principia U: S4! deben definir las fundones que ejecuta el software. Las funciones del software proporcionan un beneficia dirccto a los usuarl03 finales y tambien aporta soporte intemo a aquellas caracteristicas visibles para eI usuario. Algunas fundones trans(orman los datos que f1uyen hacia el sistema. En alTOS casas, las fundones efectuan algun grado de control sabre el procesamiento intemo del software 0 elementos extemos del sistema. Las fundones se pueden describir en muchos gradas diferentes de abstracd6n, que van desde un enunciado general del pr0p6sito hasta una descripc:iOn detallada de los elememos del procesam!enw Que deben utilizarse. Principia f3: se debe represenrar e/ componamJenro del softWare (como uno co~endo de a.rentos e.xternos). AI com)X>l'tamiento del sofrware de compll tadora 10 guia su interacd6n con el ambiente extemo.
La

entrada que prupurctuncUl

lIB

PARTE DOS PRA.C'J1CA DE ~

~ 00. SOFTWARE

los usuarios finales, los datos de control que aporta un sistema extemo 0 los datos

de monitoreo que se recolectan a traves de una red ocasianan que el software se

comporte de una manera especifica.

Principio #4: Los moddos que presenlan informadon, fund6n y comporlamienlO de~ partirse de forma que descubron d detalle de una moneTa e5tratificada (0 jertirquica). EI modelado del analisis es el primer paso en la resoluci6n de problemas en la ingenierla del software. Esto permite al profesionai entender mejor el problema y establecer una base para la soluci6n (disei'iO). Los problemas complejos son difkiles de resolver por completo. Por esta raz6n, se utiliza una estrategia de ~divide y ganaras". Un problema grande y complejo se divide en subproblemas hasta que cada subproblema es relativamente fadl de entender. Este concepto se llama particion, y es una estrategia clave en el modelado del analisis.

Principio Its: La tarea del antiJisis debe moverse de 10 infonnad6n esendaJ hada el detalle de implementad6n. El modelado del analisis comienza con la
descripci6n del problema desde la perspectiva del usuario final. La ~esencia" del problema se describe sin ninguna consideraci6n de 1a forma en 1a que se implementara la soluci6n. Por ejemplo, un videojuego requiere que el jugador "instruya" al protagonista en que direcci6n seguir cuando este se mueve dentro de un laberinto peligroso. Esa es la esencia del problema. EJ detalle de implementaci6n (descrita en fonna nonnal como una parte del modelo del diseno) indica c6mo se implementara la esencia. Respecto del videojuego se podria aplicar la entrada de voz. De manera altemaliva, se podria digitar un camanda del teclado, 0 se podria apuntar un joystick (0 un mouse) en una direcci6n especifica.

ConJunto de tareas genericas para el modelado del anciUs1s

1. ReviKlr las reqUi5itos del negocio, las caroderigiC05/necesidodes del uworio, las Kllidos vi5ibles poro eI uworio, las reWlicciones del negocio, Y oIros requisito5 tecflicos que Sot hay.:!fl defem,ioodo duronle las octividodes de comunioxiOn coo el dientll y de plcmeoo6n. 2. Exporodi r y refinor los escenc:nios del usoorio (secci6n 8.5). Definir 0 lodc)S los odof"es. Represento r Ia Iormo en que los odore$ intllroctUofl COIl eI Klftwore. Extroer fuociones y coroc\erigicas 0 portir de las e5Cel1Orios del usoorio. Revisor los esc:enorios del uworio poro verificar que ester. completos y su exoctitud (seo:;i6n 26.4).
3. ModeIor eI domiflio de Ia ifllormociOn (secci6n 8.3). Representor todos los objelos imponontes de inlormoci6n.
Definir los otribvtos poro coda objeto de inlormoci6n.

Representor las reIociCJne$ entre los objekn de informoci6n. 4. N'iodeIar eI dominio func:ionol (secciOn 8.6). Mostror Ia Iormo en que las funciones modificon los objek>S de datos. RefiflOr las funciones poro proporcionor los detolles de 10 elabonxiOn. Escribir uno flOrrociOn del procesamiento que deKribo coda funci6n y subfunciOn. Revisor los modeIos func:ionoles (secd6n 26.4).

"9

(,

ModeIor eI dominio del CXlITIpOi h:,1ienao (leCCiOn 8.8),

lcIenti~cor

ReYisor

los modeIos de compot1omienlo (MCCiOn

26.1.
6. Analimr y modeIor Ia inter10se delvwono (copltulo

los _los exlemos que ocoJionon combios en eI comportomienlo denlro del sislema.

121 .
Dirigir eI on6Ii~$ de 101"$0$.

IcIentificor los Mtodos que reprwenkln coda fonno de cO"'f)Oftc,,,1ienIo ~ ~ eI exterior. Presentor' eI modo en eI cpHt un _10 IIea 01 ..sterno CI combior de un estado Q oIro.

crear proIotipos 0. 10 Imogen en poniollo,

7.

Reisor Iodos los ~ en CUCIrlIo (I que eslen <:OtTlpletos, 50 con~stencia y los omi~ones.

5.4.2 Prtndpios de modelado del dlseiio

EI modele de diseno del software es el equivalente al plano de una casa para un arquitecto. Comienza con la representaci6n de la totalidad del objeto que sera construido (por ejemplo, una reproducci6n tridimensional de la casal y con lentitud 10

retina para proporcionar una guia para construir cada detalle (por ejemplo, el diseno de la plomeria). En fanna similar, el modelo del diseno que se crea para el software proporciona una variedad de diferentes vistas del sistema .

.,..... . . . " . . "" ... y;.sto: I'NrigucIdo -. ,.,...,_;. par . . . . . . . . . .

_.....__

....,+ ,..

No hay poc05 metodos para denvar los diferentes elementos de un diseno de son ware. Algunos metodos se guian mediante los datos al permitir a la estructura de datos dictar la arquitectura del programa y los componentes de procesamiento resul tantes. A olroS los conduce el patron a/ utilizar infonnaci6n acerca del dominic del problema (el modelo de analisis) para desarrollar estilos ar9uitc<:;:t6nh;0$ Y p... troneG de procesamiento. Incluso otros esUln onentados a objetos, aJ Usaf los objetos del dominio del problema como los conductores para la creaci6n de estructuras de datos y los metodos para manipularlos. AUn asl, todos elias siguen un conjunto de princi pios de diseno que se pueden aplicar sin impertar el metodo que se utilice:
Prindpto t I : J diseilo debe SCI TQstreable haSCa el modelo de analisJ,. EI modelo de analisis describe el dominio de la informaci6n del problema , las funciones visibles para el usuario, el comportamiento del sistema y un conjunto de clases de analisis que empaqueta los objetos del negocio con los metodos que les sirven El modelo de diseno traduce esta inrormad6n a una ar9uite<:;:t..>.ra. un conjunto de subsistemas que implementan las funclones m.1s imponames y un conjunro de disenos al nivel de componentes que son la realizaci6n de las clases de analisis Excepto el modelo asociado con la in(raestruclura de software, 105 elementos del modelo de diseno deben ser rastreables has!a el modelo de analisls.

120
j

-I_I _I ..... .........,

~a._

Hi

%U5\'01

Prindpio .2: Siempre se debe considerar 10 orquilecfura del sistema que se va 0 const.ru.ir. La arquitectura del software (capitulo 10) es el esqueleto del sis lema que se va a construir. Este afecta las interfases, las estructuras de datos, eillujo
y el comportamienlo del control del programa, 1a manera en que se pueden realizar las pruebas, 1a facilidad de mantenimiento del sistema resultante, y mucha mas. Por todas estas razones, el diseno debe iniciarse con las consideraciones del diseno arquitect6nico. 5610 despues de que se ha estableddo la arquitectura. es posible

er;:1PI3~

poct5G"".
"'

. . . dtll

.. _ ......

considerar los aspectos al nivel de componentes.

Prlndplo 13: 1 disetJo de dalos es Ian Importance como el dlseiio de fundones de procesamiemo. EI diseno de datos es un clemento esenciai del diseno
arquitect6nlco. La manera en que se realizan los objetos de los datos dentro del diseno no puede dejarse a la suerte. Un di.seno de datos bien estructurado ayuda a simplificar el flujo del programa, facilita el diseno y la implementad6n de los componentes del software, y confiere mas efidencia al procesamiento en general.

Principia , -4: Las inttrj"ace:i (internos y enemos) deben disetJarse con cuJdado. La manera en que "uyen los datos entre los componenles de un sistema liene
mucha que ver con la eficiencia del procesamienlo, la propagad6n del error y la simplicidad del disefio. Una interfaz bien diseflada faeilita la Inl egraci6n y ayuda a quien realiza la prueba a validaT fund ones de eomponentes.

Principio '5: E1 disetJo de lnrer/az del usuorio debe a/usrarse 0 las nues/dades del usuorio final. Sin embargo, en cada coso, debe resalta~ 10 jacilidad del
uso. La interfaz del usuario es la manifestaei6n visible del software . Sin importar que tan sofislicadas sean sus funeiones inlemas, sin importar que Ian comprensibles sean las estrueturas de datos, no importa que tan bien disenada este su arquitectura, un disei'lo de lnterfaz pobre siempre conduce a la percepci6n de que el software esta "mal" hecho.

Princlpio 116: E1 disetJo 01 niveJ de componenres debe ser indepcndienle del modo jundonaJ. La independeneia funeional es una medida del "significado sendIlo~ de un componente de software. La funcionalidad que entrega un eomponente

debe ser cohesiva, es deeir, debe centrarse en una y 5610 una fund6n 0 subfunci6n. 8

Princlpio /17: Los componenles deben esfor apareados entre sf en forma minima y vincu1ados con el ambienle exlemo. El apareamiento se eonsigue de
muchas maneras: via interfaz de componente. por mensajes. a traves de datos globales. A medida que aumenta el nivel de apareamienlo, la probabilidad de propagaci6n del error tambien aumenta y la fadlidad de mantenimiento general del software disminuye. Por 10 tanto, el apareamienlo de componentes debe mantenerse tan bajo como sea posible

8 En el capitulo 9 se puede encontrar una exposid6n adicional acerca de Iii cohesi6n

121

Princlplo ' 8 : Las represcntod ones del diseifo (mode/os) dCMn ser /6dJmente compren sJbJes. EI pr0p6sito del disei'io es comunicar informaci6n a los proresionales que generaran c6digos, a aquellos que probaran e[ software, y a quienes tal vez mantengan el software en 10 futuro. Si el disefio es diOcii de entender, no ser'lira como un media erectivo de comunicaci6n.

Principia ' 9 : El disdto debe de:;oTTollaTSe de moneTa /teraUvo. En CQdo Iterad6n el d1$diadOT debe buscar la m ayor simplld dod. Como casi todas tas actividades creaUvas, el disefto ocurre de modo iterativo. Las primeras ileraciones sir'len para retinar el diseno y corregir errores, perc las iteraciones posteriores deben

husear que el disei'io sea tan simple como sea posible.

Cuando se aplican estos principios de manera apropiada, el ingeniero de software crea un diseiio que muestra los factores internos y externos de caUdad. Los foetores de coJidad cxlemos son aquellas propiedades del software que los usuarios pueden observar facilm ente (como velocidad, confiabilidad, correcci6n, facilidad de USO) . Losfaerares de caUdad internos son importantes para los ingenieros de software, ya que conducen hacia un disefio de alta calidad desde una perspectiva tecnica. Lograr fa clores de calidad internos requiere que el disef\ador entienda conceptos basicos de disei\o (capitulo 9).

Modelado agU En su libm IIObre modeIodo 6gil, Scott Ambler [M't8021 define uno Wlrie de princ:ipios' ...doloocuondo.l on6Iisis y eI c/i""", '" oano:Iuc:d.I conIeldo cIe 10 filosofio d.I dtiarreIo {,gil 0. lcopitulo 4).
....... ,\ : La meta prirnorio del equipo cIe ~ es mnstMr dwon. no cr...-~ .

Principia II 7 Truk>r

do. con ........ ~ .:...;1.., F-'"

oJ...idorse d. (Qnlhvir mod.I~ fCI~'

Pril'lClplO

'8: No ~ dogmOfic:o acetal de 10 ,;n\ox;1 del mocWo Si . . oomunico ..... .,.,..,..,.,ido do. ~ exiloso, Ia represenlociOO M secundaria .
9;

Principio ,

corredo aunque este luzc:o

~.

Si eI instimo indica que IWl modeIo no es eI bien en eI ~,

.....~, 2: VKJjar ligero; es dec:ir, no deb.n (reorw m6$ !nOCWos cIe los nec:esorios. _ _ , 3: !mentor producir eI mocWo m61 """"" qui' daoibir6 eI p'obiemo 0 eI toftwure.
_ _ , 4: Con$lrvir modeIos cIe

probab4emettte exj,1e una roz6n poro MIor

Principo. 10: <::Ibener sea posible.
r~mentociOn JOn

pron/tl como

_ _ 5: Ser copgz de enundar un prop6tilo expIicilo

portI coda modeIo que se (ree. _ _ ,., ~ 10. modoIo. de,ao,oIIodo. ~

""""""" ~ """'"'.

Iormo cp.Ie istos .....

Sin impor1or eI moddo de proceto que se elijo 0 kn pr6ctic:os espedficas de Ie ingenierio del sofrwore que se opIiquen, IDdos los equipos de sohwore quieren lei" Oglles. Por 10 101'110, ews principios WI deben oplicar sin irTlfX>l1Or eI modeIo de pwceso del :.oftwore que WI hoya
~.

stst.mo que se tiline en mono

9 los princlplos menclonados en esta secdOn se han abrev;ado y adaptado para los pr0p6sltcr.l de (sIc
libro

122

Conjunto da tareas g6n6rlcas para e1 dtseiio 1. Utilizar eI modeIo de on6li~il, Especificor 10 secuencia de occi6n con boWl en los
~ionar

(patrOn) opropiodo perc

un e~1o orquitred6nico eI Jtwore

(capilvlo 10J. 2. !>Md;r eI modele de onalisis .... M.CtiMem05 de di-.o 'f ubicor ews dentro de Ie otqUilrecturo

escenoricn del usoono. Crear un modeIo de componomienkl de Ie inlwf.ca. Dehnir los objeIos de 10 interfaz y meoanismos de
~1n>I.

(capitulo 101

T_1o cenezo de que coda wbsiwmo 1:$ coherente en eI sentido ful"lCiorlol.

Disenor interfmes de wlislemo. l.bicor 10, dows 0 funciones de g;ocjg wbl'Wrng.

RM_ III diw.o de 10 interfoz y ojuslotlo como tea necesorio (secci6n 26.4).
4.

Condudr.l diilMo aI or..! de camponllln"'.

Especihcor todo. los aIgoritmos en un "rode reIotivomente boio de abstn:xci6n.

on6I,,,, porc

Refinor 10 inler'faz de codo c;omponenle.

Defio'r 1M 8$lnJduros de dolo$ en eI niYe! de

Mediante 10 utilizoci6n del mocIeIo del dominio de

10 infonnoc:i6n, disenor nInJdvro$ de datos

<>f>">Po<loo. 3. Oi$t!lb" 10 intrerloz del usuono (copa.jo 121.

RoviWlr 1M ~ del ..rw!tlili. eM toreM.

cornponem. hecci6n 26..4 ',

Revisor eI disefto en eI on,,! de ~

1_26.'1.
5. DMam:IIIar un mod.Io de despliegue (secci6rt 9 . .5).

La aclividad de construcci6n abarca una serie de tareas de codificaciOn y realizaci6n

de pruebas que conducen a\ software operativo que esta listo para entregarlo al cliente 0 usuario final. En el trabaja de la ingenierta del software modem a la codificaciDn puede sere I) la cre.aci6n directa de c6digo fuente de un lenguaje de programaci6n ; 2) la generaci6n automatica de c6digo fuente al utilizar una representad6n intennedia del diseno del componente que sent construido; 3) la generaci6n automatica de c6digo mediante un lengua;e de programaci6n de cuarta generaci6n (por ejemplo, Visual C++) .

...-.. _ .
........ parte

III. .......,'.I.fonna ..
..... 0.

'* sido ,'."" ...........

lie

del softwatt, ~ 11m. ,. . . . . . . ._ joyu real, l1li progroma lien Uldammpat.... ts . . . . ,orpizaIIo" ...............

1Str1.Ir:InIo..........

E1 enfoque inidal de las pruebas esta al nlvel de componentes, con frecuencia lIamadas pruebas de unidad. Los otros niveles de prueba induyen: I) pruebas de integmci6n (realizadas mientras el sistema esta en construcd6n) 2) prucoos de vaiidacron, las cuales evaluan si los requisi tos han side satisfechos para el sistema completo (0 para el incremento de software); y 3) pruebas de oceprod6n, que realiza el cHente en un esfuerzo encaminado a ejerdtar las caracterlstlcas y fundones.

-...

123

Existe una serie de principios y conceptos aplicab\es a la codificaci6n y las pruebas. tstos se presentan en las secciones siguientes,

5.5.1

Principios y conc:eptos de cod1J1cac16n

Los principios y conceptos que guian la tarea de codificaci6n estan alineados de

manera muy cercana al estilo de la programaci6n, los lenguajes de la programaci6n

y los metodos de programaci6n. Sin embargo, existe un canjunlo de principies fundamentales que pueden establecerse:

Prlndptos de preparad6n: Antes de escribir una linea de cMigo se debe estar scgu rode'

1. Entender el problema que se intenta resolver.

2 . Entender los prindpios y conceptos basicos del diseflo. 3.

Escoger un lenguaje de programaci6n que satisfaga las necesidades del software que se va a construir y el a mbiente en el que este va a operar.

4 . 5elecdonar un ambiente de programaci6n que proporcione herramientas que fadliten el trabaja.

5 . Crear un conjunto de pruebas de unidad que seran aplicadas una vez que
complete el componente que se va a codificar.

se

Princlpios de codiflcad6n: Cuando se comience a escribir el c6digo se debe estar

segurode:

1. Restringir los algorttmos al segulr la practica de la programaclon estructuraaa

IBOHOOI.
2. Seleccionar las estructuras de datos que sallsfaran las nccesidadcs del dlscno.

J . Entender [a arquitectura del software y crear interfases que sean consistenles

con ella.

4 . Mantener la l6gica condidonal tan simple como sea posiblc.

5. Crear ciclos anidados en una forma que los haga faclles de probar

6. Seleccionar nombres de variables significaUvas y segulr otros estandares lOcales de codificaci6n

7. E.scribir c6digo que tenga documentaci6n propia. 8 . Crear una configuraci6n lineal (por ejemplo, sangrias y Uneas en blanco que
ayuden a la comprensi6n del c6digol

Principios de valldad6n: Dt:sputs de habet comp1etado los primeros pases de Codl

flcaci6n. se debe estor seg!ITO de

I . Conducir un ensayo de c6digo cuando <:ea aprnpiado
2 . Realizar pruebas de unidad y corregir los errores que

se hayan descublerto

3 . Refabricar el c6digo

124

Los libros sobre codificaci6n y los principios que la guian incluyen trabajos recien-

tes sobre el eslilo de programaci6n [KER78l, construcci6n practica de software

IMCC93). perlas de programad6n IBEN99L el ane de la programaci6n [KNU99]. aspectos de la programaci6n pragmatica IHUN99J, y muchos otros.

~
.

ConJunto de tareas genericas para 1a construcc16n

1. Conslruir 10 infroMtructuro
orquiled6nico (oopitvlo 10).
Revi5af

CocIificar ~ aIgori~ internos 'lias funciones de procesornl8nkl le*xoonadas. ReviKlr III c6d''90 conform. este MI escribe (secci6n 26 ..4\.

eI di-'o atquited6nico.

Codj~Ir 'I

proboc-Ios o:xnponenles que forman 10

infroeslrvduro grquilad6nic;a. Adquirir potrooe5 orquite06nicos I'8IJtiliwbles.

SuiCOr Ia exoctitud.

Asegumrse de que :Ie han manlenido los

esI6ndol'fl de codificoci6n.
Asegurorse de que miSITC.

in"9ridad de 10 m..no:r.. 2. ConW\lir un componenle del Klftwore (copitvIo II).

Revhar ttl di-'o 01 oi"" de COITlf'O"*'IIe.
Cr.or uno :wie de ~ de unid.xl porn eI componenle (wcciones 13.3.1 y 14.7).

Prober 10 infroeslrvduro para oseguror 10

eI c6digo 501 documenkl a sf

3. Reali mr~' de unidcx:l aI c:or'I'IpOr'*.ta. Dirigir todos las pruebos de unidod.

Corregir los errores ~.

Apl"1COr de nueYO las pruebos de unidod.

4. Integror eI componenle *"minodo a orquilrect6nica

Codihcar len e$lnldVrO$ de ~ y 10 imerfu:.e del "'"'1""'""10.

Ia infroe$lrvduru

5.5.2 Principios de las pruebas

En un libro cIi~sico sobre las prudXIs realizadas al software, Glen Myers [MYE79J establece una sene de reglas que bien pueden servir como objetivos de las pruebas: Las pruebas consisten en un proceso en el que se ejecuta un programa can la intenci6n de encontrar un error que aun no se descubre.

............
wttw?

,CHMs $011

1M Mjotk..

Un buen caso de prueba es aquel en el que hay una gran probabilidad de enconlrar un error que aun no se descubre_ Una prueba exilosa es aquella que encuentra un error que aun no se descubria. Estos objetivos implican un cambia radical desde el punta de vista de algunos desarralladares de software. Botos se aponen a la visi6n inusual de que la prueba exitasa es aquella en la que no se encuentran errares. EI objetiva aqui es di.senar pruebas que de manera sistematica descubran diferentes clases de errores y que 10 hagan con un gasto minima de tiempo y esfuerzo. Davis IDAV951 sugiere un canjunto de principios para las pruebas,10 el cual se ha adaptado para aprovecharlo en este libra:
10 Aqui se presenta s6Io un pequeno subconjunlo de los principios de Davis para las pruebas. Para ob lener mas lnfonnaci6n vease [DAV95J

'25
Principio '1: Tooas las pruchas de~n seT rastreables hasta los requisUos del diente. II EI objetivo de las pruebas realizadas al software es descubrir errores_

De aqul se desprende que los defectos mas severos (desde el punto de vista del elien-

tel son aquellos que haeen raHar el programa al tratar de salisfacer sus requisitos
Princlpio 112: LAs pruchas sc delx!n planear mucho antes de que comience
e1 PTOCeso de prueba. La planeaci6n de las pruebas (capitulo 13) puede comenzar

tan pronto como el modele de anaiislS este completo_ La definici6n detallada de los casos de prueba puede comenzar en cuanlO el modelo de diseno haya sido solidificado. Por tanto, todas las pruebas se pueden planear y disefiar antes de que se haya

generado cualquier c6digo. Principia ' 3: El prlndpio de Pareto es aplkQbJe para las pruchas de software. Para establecerlo de manera simple, el principio de Pareto implica que 80 por
dento de los errores descubiertos durante las pruebas con probabilidad sertm rastreables hasta 20 por dento de todos los programas. EI problema, por supuesto, es aislar estos componentes sospechosos y despues probarlos.

Principia '4: Las pruebas deben comenzar Hen 10 pequeno" y progresor hada "10 grande". Las primeras pruebas Que se planean y eJecutan. por 10 general,
se enfocan en los componentes individuates. COnfonne progresan las pruebas, el enfoque cambia en un intento de encontrar errores en grupos integrados de componentes y, por ultimo, en el sistema completo Principlo '5: Los pruebas exhausUvas no son posibles. EI numero de per mutaciones entre las rulas, Incluso de un programa con un tamano moderado, es excepcionalmente grande. Por esta raz6n es imposible ejecutar cada combinad6n de rutas para las pruebas Sin embargo, se puede cubrir de manera adecuada la 16gica del programa para asegurar que se hayan ejercitado todas las condiCiones al mvel de componentes (capitulo 14)

~
/

onjunto de tareas genencas para las pruebas

Aplicor de nveYO kl$ pruebas de \.K1idod.
2. Desarrollor una estrutegio de integroci60 [secci6n

I. OiWoor ~ d. unidod poro codo compooenle del ~re [5eCCi6n 13.3.1) Revisor codo prvebo de unidod poro asegufOl'" una

13.3.21.

Oingir 10 pruebo

"""""'" """"""",,. d.

unidod.

Corregir los effO(M descubiertos.

estoblecer eI orden y 10 IMIroIegio que Ie usorC poro 10 integtoci6n. Delinir Io~ -cor"lltruccionfn- y los prvebos requeridas para eiercitoMaS

II Este pnncipio sc rcflel"C a las pruebas }ilndonales; es decir. a las que :Ie c:nfocan cn los requisllos Las prucbas eslructuroles (que sc enfocan en los dctalJcs arqUltcclooicos 0 l6gicos) pucden no refe rirsc en rorma dlrcct.a a los rcqulSItos cspedflcos

126

PARTE DOS PAAC'OCA DE!A!NGENlEIZ!A on SOFTWARE

Dirigir prvebcl$ de humo a diorio.

Dirigir pruebos de regfe$i6n coda YeZ que sea nece$Orio.
3. Desarrollor uno esrrolegio de voIidoci6n (secci6n
13.5).

5. Ding;r los pruebos c;on mudlO~.

ReoIizor leu pruebos de fecuperoci6n (secci6n 13.6.1 ). Reaiizor los pruebos de seguridad (WlCCi6n 13.6.2).
Reaiizor los pruebos de Iensi6n (secci6n 13.6.3).

ESlobiecer

los crilenos de volidociOO.

Definir las pruebc]5 requeridas para validar eI softw.are.

4.

Realizor los pruebos de ~peilo (sea;i6n 13.6 ..4). 6. Coordinor con eI dienle los pn.tebc de oceploci6n (secci6n 13.5.3).

Dingir los pruebos de inlegroci6n y volidoci6n.

Corregir los errores deKvbierlo$.

Aplicor de nuevo los pruebos o:odo vez que sea nec&$Orio.

Como se mencion6 en el capitulo 2, la actividad de despJiegue abarca tres acciones:

entrega, soporte y retroalimentaci6n. Como el software modemo es evolutivo por

naturaleza. e[ despliegue no se presenta una sola vez, sino varias veces conforme eJ
software avanza hacia su terminaci6n. cada cicio de entrega Ie proporciona al clienIe y a los usuarios finales un incremento de software operativo que provee fundones y caracteristicas utiles. cada cicio de soporte proporciona documentad6n y asistenda humana para todas las fundones y caracteristicas introducidas durante todos los ciclos de despliegue que se han presentado hasta la fecha. Cada cicio de retroa limentaci6n ofrece al equipo de software una guia importante que conduce a modificaciones en las funciones, caracteristicas y el enfoque que se lorna para el siguienIe incremento.

La entrega de un incremento de software representa un fundamento importanle

para cualquier proyecto de software. Cuando eJ equipo se prepara para crear un incremento, se debe seguir una serie de principios clave:

s. ..... ..,.,.. ....... .,. .

iJ
IIf*-II'JIIs tilt rpI

Principia 1# 1 : se deben administrar l as expeclalivas que el diente tiene del software. Con demasiada frecuencia, el cliente espera mas de 10 que el equipo ha prometido entregar y de inmediato se presenta un desacuerdo. Esto genera una
retroalimentaci6n improductiva que arruina la moral del equipo. En su libra sobre la administraci6n de expectativas, Naomi Kartun IKAR94] establece: "El punta inicial para administrar las expectativas es volverse mas consciente ace rca de 1 0 que se comunica y de la fonna en que se hace~. Sugiere que un ingeniera de software debe ser cuidadoso de no enviar al clienle mensajes conflictivos (como promeler mas de 10 que se puede entregar de manera razonable en el marco de tiempo con el que se cuenta, 0 entregar mas de 10 que se promete para un incremento de software y despues menos de 10 prometido para el siguiente).

. . . . e1im_ de soItwore.
OM! 1fmIJfO,

.". ".....
eI

--"'" -.

121

PJindpio *2: Sc! debe ensmnblar y probar un paquele de entrega completo . Se debe ensamblar un CD-ROM u alro media que contenga todo el software ejecutable, archivos con los datos de soporte, documentos de soporte y atra informaci6n reievante para que despu~ 10 prueben los usuarios reales. TOOos los protocolos de

instalaci6n y otras caracteristicas operalivas se deben ejercitar posterionnente en

todas las configuraciones de c6mputo posibles (por ejemplo, hardware. sistemas operativos, dispositivos perifericos, arreglos de red).

Principia * 3: Se delH! ~ tQblecer un regimen de soporte antes de entregar d software. Un usuario final espera responsabllidad e informaci6n exacta cuando surja una pregunta 0 problema . Si el soporte es ad hoc 0, aun pear. inexistente, el

cliente se siente insatisfecho de inmediato EI 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 evaluaci6n categ6rlca de los tipos de soporte solicitados.

Prindpio ' 4: Sc debt! propordonar material inslru clivo aprop/ado 0 l os

usuanos finales. EI equipo de software entrega mas que el software en sl; en caso de ser necesario, se debe desarrollar un entrenamiento apropiado, se deben proporcionar directrices para la resoluci6n de problemas, y se deben pubHcar de~rip'iones
acerca de "cual

es la diferencia con este incremento de software".1l

Prindpio ' 5 : El software con errores se debe arrcgJar primero y entrcgarse despub. Ante la presi6n del tiempo, algunas organizaclones de software entregan incrementos de baja calidad con una advertencia para el c\iente de que los errores "se ellminaran en la pr6xima versi6n". Esto es un error. En el negocio del software se dice: "Los clientes olvidaran que se les entreg6 un producto doe alta calidad unos pocos dlas despues, pero nunca oMdaran los problemas que les causa un producto de baja caUdad. EI software se los recuerda tados los dlas". El software entregado proporclona un benenclo para el usuarlo nnal, pero lambien provee una retroaHmentaci6n util para el equipo de software Al utilizar el incremento, los usuarios finales deben ser motivados a comentar sobre las caracteristi cas y fundones, facllidad de USO, confiabllldad y cualesqulera otras caractelistlcas apropiadas. La retroalimentaci6n debe recopilarla y registrarla el equipo de softwa re y aprovecharla para 1) hacer madificaciones inmediatas aJ incremento entregado (si es necesario); 2) detinir los cambios que seran incorporados en el pr6ximo incremento planeado; 3) realizar las madificaciones necesarias al diseno para ajuslarlo a los cambios; y 4) revisar el plan (inc1uyendo el calendario de entrega) del pr6ximo incremento para renejar los cambios.

12

Du~te 1a acttvidad de comunk:aciOn d equlpO de software debe determlnar los tipos doe matena Ioes de ayuda que qukrm los usuanos

128

PARTE DOS

i'RAcn:.:A DE LA!NGNlRiA DL9:lf'TWARE

ConJunto de tareas genencas para eJ desp1Jegue 1. Crear medias de enlrego. EsIabIecer una bose de datos pol'Cl eI repone de
Ensomblor y probar todo~ b
on::hivos ejeevlcbles. En$llmblar y probor todos los archivos de datos.
3.
problemo~/ errores.

Estoblecer meconi$lTlO$ de retroolimenllxi6n del

usuorio. Mnir eI procl!$O de retroolimenloci6n.

Crear y probor toda 10 documentoc::i6n del usuorio.

Implementor los veoiones electn5nkos (po..;.mpio, pdij,

Implementor orchiVO$ de
"oyudo~

Definir kulormos de retroolimenloci6n (en popel

electr6nico)

con hiperteJdo.

hloblecef-Io bose de dokn. de rerroofimenloci6n.

Oefinir eI proce.so de evoluoci6n de Ia retroolimenloci6n.
A.
Di$el'llinor

Implemenlcf uno guio pam 10 resolutiOn de problemas.

P.obor 10$ .....dio. d..n1Nga con un grupo
petlueOo

los medias de entrego 0 todos los

de uwcrXn repre~lIJti'lt. encorgodo del

uworm.
5. Dirigir las funciooes de :IOpO(1e continuas. Proporc.ionor osis)encia en Ie inslalaci6n y eI initio.

2.

E~klbI~er Ie peoooa 0 grvpo ""'1"<>'1. hum<>nO.

Creor 10 documentocioo 0 los herramienfos de soporte por computodoro.

Esloblecer meconiSrTlO$ de conlodo [por ejemplo,
un sitio web, teIefooo, correa electr6nicoJ.
Eooblecer meo::oni~s para 10 locaIizoci6n de problemcs.
Establecer mecanimlOS para III repone de

de resolvci6n de problemas. 6. Recopilor Ia rerroalimenloci6n del uSUDrio Registrar Ie retroolimenloci6n.

Proporcionar osisklndo continua y

Evoluar 10 retroolimenloci6n.

problemas.

Comunicone coo los usuarios K>bre 10 retroolimentoci6n.

Ii

La practica de la ingenieria del software incluye conceptos, principios, metodos

herramientas que aplican los ingenieros de software durante el proceso de software. Cada proyecto de ingenieria del software es diferente, aun asi existe un conjunto de principios y tareas aplicables para cada actividad del marco de trabajo del proceso, sin importar el prayecto 0 producto. 5i se pretende dirigir una buena practica de la ingenieria del software, es necesario un conjunto de puntos esenciales tecnicos y de gesti6n. lOs puntos tecnicos incluyen la necesidad de entender los requisitos y las areas de incertidumbre del prototipo, asi como la necesidad de definir de manera explicita la arquitectura del software y el plan de integracion de componentes. Los puntos esenciales de gesti6n 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 [a ca[idad y el cambia.

129

Los principios de comunicaci6n con eJ cliente se enfocan en la necesidad de redu

ciT el Tuida y mejorar el canal de comunicaci6n conforme progresa Ja conversaci6n entre el desarrollador y el cliente. Ambas partes deben colaborar para que se establezca 1a mejor comunicaci6n Los principios de planeaci6n se enfocan en las directrices encaminadas a cons-

truiT el mejor mapa para reaiizar el tTabaja que conducirfl a terminar un sistema 0 producto. EI plan se puede disei'lar 5610 para un incremento de software, a se puede detinir respecto del proyeclo completo. Independientemenle de ello, el plan debe indicar que se hara, quien 10 hara y cutmdo se completarti el (Tabaja.
El modelado incluye tanto el analisis como el diser'i.o, al describir representacio-nes del software que se vuelven mas detalladas de manera progresiva La finalidad de los modelos es solidificar la comprensi6n del trabajo que se realizara y proporcionar una gula tecnica para quienes implementaran el software
La construcci6n incarpora un cicio de codificaci6n y pruebas en el cual primera se genera el c6digo fuenle y despues este se prueba para detectar errores. UI. inte-

graci6n combina los componentes individuales e involucra una serie de pruebas que

se enfocan en los aspectos del funcionamiento general y de las Interfases locales. lDS principlos de codificaci6n definen las aceiones geneticas que deben ocurrir antes
de que se escriba el c6digo. mientras este se crea y despues de que se haya completado. Aunque existen muchos principios para las pruebas, s610 uno es el dominante: las pruebas se fonnan can un proceso en el que un programa se ejecuta con el objetivo de encontrar un error DUrante el desarrollo del software evolutlvo St= presenta et desarrollo para cada incremento de software que se presenta al cliente. Los principlos clave para la entrega consideran administrar las expectativas del cliente y dotar al w:uario con in(nr maci6n de soporte para el software. 1 soporte necesita una preparaci6n previa. La retroalimentaci6n pennite al cliente sugerir cambios que tienen un valor de negocios

y proporcionan al desarrollador una entrada para el pri"cimo del" iter",t,v" ingenieria del software.

de b

[AMB02) Ambler, S. y R. Jeffries, Agile Modt:IinS. Wiley. 2002. [BEN99) Bentley. J., Programming Palris, 2a. ed , Addison-wesley. 1999 (BOE 961 Boehm, B. , -Anchoring the Sofiware Process~, en IEEE Software, vol 13, num 4, juliO de 1996, pp 73-82 IBOHOOI Sohl. M Y M Rin. Tbols for SlrtKtured DesIgn An Introduction /0 Programming LogIC, Sa. ed., Prentice-Hall, 2000. IDAV9S1 Davis, A., 201 Principles ofSoftwore lkvdopmen/, McGraw-HIli, 1995 IFOW991 Fowler. Metal., Re/ac/onng Improving the DesIgn oJ Exisung Code, Addison wesley.

1m

IGAR951 Garian, D y M Shaw.

~An InlroduCilon to Sofiware Archllecture", en Advances In Software Engineering and /(n(M!ledge Enginrlng, vol I (V Ambriola y G. Tortora, eds.J. World Scientific Publishing COmpany, 1995 JH1GOOJ Highsmith, J.. Niap~ Software Devdopmem An EvolUlJonary Approach /0 Managing Complex ~em.s, Dorsetllous(: Publishing, 2000.

130
[HOO96/ Hooker, D., 8$even Principles of Software Development8, septiembre de 1996, disponible en hltp- /1c2.com/cgi/wlkiSevenPrirw::iplesQfSoftwareDevelopment.
(HUN9$] Hunt, D , A. Bailey Y B. Taylor, TheArI a/Facilitalion. Perseus 800k Group , 1995 IHUN99] Hunt A. D. Thomas y W Cunningham, The PrrlBmalic Programmer, Addison-wesley.

1999
UUS99] Justice, T et 01.. T1IeFadlIW/OI'SFiddbook, AMACOM, 1999. IKAN931 Kanner, C. J Falk y H Q Nguyen, Tesling Computer software, 2a ed., Van Nostrand

Reinhold, 1993. lKAN96] Kaner,S et 01., The Facill/%r's GUide to PreparotOl)' DecIsion Making, New Society Publishing, ] 996. [KAR94J Karten, N . Monagmg ExptotiOllS, Dorset House, 1994 [KER78] Kernighan, B y P Plauger, The Elements ojProgrammmg Style. 2a ed, McGraW-Hili, 1978 [KNU98) Knuth, D., The Art oj COmputer Programmmg. 3 volumenes, Addison-wesley, 1998
[MeGJ] MCCOnnnell, S" Code CompJete, Microsoft Press, 1993. [MCC97] MCCOnnell. S.. ~Sonware's Ten Essentials", en IEEE Software, vol 14, num. 2, marzo-

1997, pp. 143-144. Myers, G., compOSlle SlrUCturaJ DesIgn, Van Nostrand, 1978. Myers, G., TheM of SOftware Testing, Wiley, 1979 Parnas, D.L, WOn Criteria to Be Used in Decomposing Systems into Modules", en CACM. vol. 14, num. I, abnl de 1972, pp 221227. IPOL45] Polya, G., Haw 10 SOlve 11, Princeton University Press, 1945 IROS751 Ross. D.. J. Goodenough y C. Irvine, SOftware Enginuring Process, Principles and Coals", en IEEE Compu/er, vol. 8, nUm. 5, mayo de 1975. [SHA9Sa] Shaw, M yD. Garlan, ~Fonnulations and Fonnalisms in SOftware Architecture", \obIume 10000Lrure Notes In Computer 5aence, Springer-verlag, 1995. ISHA950J Shaw, Meta/, ~Abstractions for SOftware Architecture and Tools to Support Them", en IEEE Ttans. SOftware EngInemng, vol. SE-21, num. 4, abril de 1995, pp 314335. [STE74[ Stevens. w., G. Myers y L Constantine, ~Slruclured Design", en IBM SystemsJoumal, vol 13, num. 2,1974, pp 115-139 !TAY901 Taylor D. A, ObJeCt Orkrlred Technology; A Managers Guide, Addison-Wesley, 1990 [ULL97J Ullman , E., Close to the Machine. TechnophlllO and its Discontents, City Ughts Books, 1997. {WIR71] Wirth, N., "Program Development by Stepwise Refinement", en CACM, vol. 14, mlm. 4, t971, pp 221-227. IW(X)951 Wood, J. y D Sllver,}Oint AppIicatJOn Des{yn, Wiley, 1995 [ZAH90] Zahniser. R A., "BllildLng SOftware In Groups", en Amencan Programmer, vol. 3, nums 7-8, julio-agosto de 1m. abril, (MYE7Sj [MYE79[ [PAR72]

5.1. ln1~ntese resumir en un pAnafo breve los "siele principios para el desarrollo de software" de David Hooker (secci6n 5.1), TTiHese de extraer la esencia de su gula en sblo unas cuantas oraciones y sIn usar las palabras de Hooker 5.2. ,Existen ooos puntos tecnkos "esenciales- que se puedan recomendar a los ingenieros de software' Enunciar cada uno de ellos y expbcar par que se han induido 5.3. ,ExlSlen olros PUniOS "esenciales" de gestl6n que se puedan recomendar a los ingenieros de software? Enundar cada uno de ellos y explicar por que se ha incluido. 5.4. Un principio importante de la comunicaci6n eSlable<:e Mprepare antes de comunicar"

iC6mo podrta esta preparaci6n manifeslarse por s[ misma en los primeros trabajos que se
realizan' ,Cuales produclOS de trabajo podrian resultar como consecuenda de 1a preparaci6n oportuna'

131 5.5. Hagase una investigaci6n de la Mfadlitad6n para la actividad de comunicaci6n (utillcense las referendas que se proporcionan u otras) y preparese un (anjunlO de directrices que se enroquen 561 0 en la racilitaci6n_
M

5.6. ,En que difieren la comumcaci6n agil y la comunicad6n de \3 ingenieria de sofiware Ira-

dicionaJ' ,En

que son similares?

5.7 . ,PoTque es necesario continuar?

5.8 . Rc:ahzar una investigad6n de la M negociaci6n" para la actividad de comunicaci6n y prepa-

rar un canjunlo de directrices que se enfoquen 561 0 en la negociaci6n

5.9. Oescribir 1 0 que significa gmnu/arldad en el conte-xlo de un caJendario de proyecto

5. to. ,Per que son importantes los modelos en el trabajo de \a !ngenieria de software? ,Siempre son necesarios' ,Son cahfacadores para su respuesta acerca de 13 necesldad?

5. 11 . ,CUllies son los Ires "dominios" que se consideran durante el modelado del analisis'
5. 12. natar de ci6n 5.6
a~ar

un principia adicional a los

~xilosa'1

~nunciados

para la codificaci6n

d~

la sec-

5. 13 . iQUe es una prueba

5. 14. ,Se esta de acuerdo con el siguiente enundado?; ~debido a que enlregamos mUlIiples incremenlos al clienl~. no debemos preocupamos por la calidad en los pnmeros incremenlos; los problemas se pueden ~ver en iteracione:s posteriores. ExpUquese la respuesta 5. 15. ,Por que es
Important~

la rc:troalimc:ntacl6n para eJ equipo de: soRwarc:'1

La comunicaci6n con el c1iente es una act1vidad muy importantc: en la ingc:nierla del sonware,

no obstante, algunos profesionaies no dedican tiempo a leer acerca <Ie ella. lOS hbrO$ de Pardee (1b SotsfY and Ddighllbur Costumer, Dorset House, 1996) y Karten IKAR941 proporcionan una
gran perspectiva de los metodos para la interacd6n efectiva con el ciienle En muchos libros sobre Ia gestiOn de proyet:tos se consideran los conceptos y principlos de 1a comunicaclOn y la planeaci6n Las ofertas \Jllles relallvas a ]a gestl6n de proyectos lncluyen: HUghs y COtterell (SOjtw<Jre Pro~ Mar'U1gemmr, segunda edici6n, McGraw-Hili, 1999), Phillips (The Software ProjeCt Manager's Handbook , ]EEE Compute r SOciety Press, 1998), McConnell (Sojhvare Projeel SUrviVal Guide, MkrosoR Press, 1996) y Gilb (prmoples OJ software Engineering Managemem, Addisonwesley, 1998), ca.si cuaJquier libra sobre ingenierfa del software cantlene una exposlci6n util sobre los conceptos y pnnCiplOS para el anal isis, el diseno y las pruebas. Entre las mejores ofertas estan los Iibros de Endres y sus colegas (Handbook ofSoftware and 5)'SIems Engmeenng, Addison-wesley, 2(03), SOmmerville (SOftware Engineering, sexta edicion, AddisonWesley, 2000), P11eeger (Software Engineering: Theoty and Practice, Prentice-Hall, 2001) y Schach (ObJt!Cf-onented and Classical Software EngIrlrJI18, McG raW-Hill, 200 1), Davis ha recopilado una amplia colee cion de prindpios de software en [DAV95J. Los conceptos y principios del modelado se consideran en mochos libros dedicados al analisls de requisitos 0 al disei\o de software Young (Effective ReqUirements Pracuces, AddlsonWesley, 2(0 1) resalta un -equipo cOl'ljunto de cliente:s y desarrolladores que e laboren los requ iSItos co)ectivamente Welgers ~re !quiremenrs, Microsoft Press, ]999) presenta muchos reqUlsitos clave de ingenierfa y requisilos de las practicas de gestion Sommerville y Kotonya (ReqUirements Engineenng' Process and Techniques. Wiley, 1998) analizan los eoneeptos y las teenleas de ~ob tenci6n~ y otros prindpios de la ingenieria de requisitQS Ellibro de Norman ~ DeQgn of~ Thmgs. Currency/Doubleday, 1990) es una leetura obligada para cualquier ingeniero de software que intente haeer el trabaio de di ~iio Winograd y sus colegas (Bnngil18 Design to Softwore, Addison-Wesley. 1996) han edilado una excelente colecci6n de ensa)'OS que tratan sobre los aspectos proklicos del diseiio de sofiw'He Constantine y L.ockwood (5ojtwarefor USIe, Addison-Wesley. 1999) presentan los eonceptos aso

dados con el "dlsefio centrada en el usuario". Tognazzini C1bg on SOftwrJre DesIgn, AddisonWesley, 1995) presenta una valklsa exposid6n fllos6tka de la naturaleza del diseno y ellmpac10 de las dectSlones sobre 1a calidad y la capaodad del eqUlpo para producir un software que propordone un gran valor a su clienle Hay dentos de Ubros que tratan sobre uno 0 mas elementos de 1a actividad de construcci6n Kernighan y Plauger [KER781 escribieron un texto clAsico sobre el eslilo de Pf08ramaci6n, McCOnnell [MCC93] presenla directrices pragrnilticas para Is construcd6n prjctica de software, Bentley IBEN99\ sugiere una amplia variedad de pcrlas de programaci6n; Knuth IKNU98] ha escrito una sene cJasica de tres volWnenes sobre el arte de la programad6n, y Hunt IHUN99I sugiere directnces pragmjtlcas de programaci6n. La bibhogratta sobre pruebas ha ftorecido en la decacla pasada Myers IMYE79\ se conserva como un clasico. Los libros de Whitaker (flow 10 Break SOftware, Addison-wesley, 2(02), Kaner y sus colegas (l.eSSOnS Learned In Softwa-re Tesnng, Wiley, 2(01) Y Marick (The Craft of SOftware nsbng, Prenlice+Hall, 19971 presentan concepios y principios Importantes sobre las pruebas, asf como una guta pragmMlca considerable En Internet existe una amplia variedad de fuentes de Informad6n sobre la prjctlca de 1a ingenieria del software. En e l sitio web de SEPA. se puede encontrar una lista actualizada de referencias en la red mundial, las cuales son relevantes para la prjctlca de la ingenieria de software: http;//www.mhhe.com / pressman.

CAPiTU L O

INGENIERiA DE SISTEMAS

-_

CONCEPTOS

- 1. AVE

."..... .. .142 . . ... .140

.. . IlS

"'UI&l .

.I47 .. . .144

-.
c, ' tc.

... .134

. .... .1lS

...-s .. .1lS
.. . . '36
...... .. .. 144 ___ 139

ace casi 500 atlos. Maquiavelo dijo: "No hay nada mas dificil de Uevar a cabo. mas peligroso de realizar 0 de exito mas incierto que encabezar la introducci6n de un nuevo orden de casas" Durante los 50 ultimos anos, los sistemas basados en computadora han introducido un nuevo orden. Aunque la tecnologia ha tenido varios avances desde la epoca de Maquiavelo. sus palabras alln siguen vigentes. La in geniena del software ocurre como consecuencia de un proceso lIamado ingt'lIIerio de sistemas. En lugar de concentrarse 5610 en el software. esta disci plina se centra en una vari edad de elementos mientras analiza, disefia y organiza aquel10s elementos de un sistema que pueden ser un producto, un servicio a una tecnologia para la transformad6n 0 control de informaci6n EI proceso de ingeniena de sistemas asume distintas fannas, segun el dominio de aplicaci6n en que se utilice. La mgenierio de proct!SOS de negodos se apli ca cuando el contexto del tfabaJo se enfoca en una empresa CUando se va a construir un producto (en este contexto un producto incluye todo, desde un teiefono inalambrico hasta un sistema de con trol de tratlco aereo), al proceso se Ie llama ingenieria de producto. Tanto la ingenieria de procesos de negocio como la de producto intentan poner orden en eJ desarroUo de sistemas basados en computadora Aunque cadd uno de ellos se utiliza en un dominlo de aphcaci6n diferente, ambos buscan poner al software en su contexto. Es decir, tanto la ingenieria de procesos de

10 eo ""'""""' _ _ .. aIojooMo general del siJtema; it!! debe identfficor 81 pap.I que tienen eI horciwore, eI software, Ica penonos, los bases de datos, los pioc:edim. . . y otros elementos del $istwno; Y Ie deben ~. cor, analizar, especificor. modeIar, WJlidar y gationar los apenxionoIet EsUl o::tMdodes son eI-"ICb.I8i" de Ia ingen-.. d.1tI-

4QoM ..? Ante. de que _ pooibIo constnJir eI ~, por....clio.1a ingenierio, '" debe .".... .1 ~ mo- en que Para .....

&Pel ... - -.-......,

Exi1o_

u n o n t:guo

'*,..

~ que dice: 10s 6rboles no deJan

lama yaos 6rboIes son Los eementos tecnoI6giem (induido eI software) que se reqoieren para

V8f eI bo.que-. En esee conlextO, eI "lx,sque- es eI sis

rdzar eI "skma. Si se constrvyen los elementos tecno16gicos de una monaro predpitada

c:rielcle entender.l sistema,

IIIn.'wI
M'I:)re5

sin dudo se come-

';tSitos

Antes de . . . . . eI bosque.
1M

que decepcionoren 01 clien". praxuporse poi" los ~ se debe

,CuM. MIll . . ,o..-? 5e identifican los 001ey roquititl operocionore, mCI3 delO!lodo)
U!

lema,.

.Ouien 10 hoc.? Un ingertiera de sistemas trobalO para entender los requisitos de un "sIIrno
trobaiar con eI dient.. usuorias ~yolros -..,do,

01 obtener mformac,on del dfente;

cornpIeto
y es consi~lenlre :
HI

anallzan
0

los requlsdos pam evoloor su doridad, si eU6

crea una especjfj-

co06n que par 10

general esl6 incorporoclo

III

134

...

..., .... d ,

negocios como la ingenieria de proclucto, I trabajan para asignar un papel al software de computadora y. al mismo tiempo, establecer los enlaces que unen al software con alros elementos de un sistema basado en computadora. Este capitulo se centrara en las necesidades de gesli6n y en las actividades espedficas del proceso que permitan a la ofganizaci6n de software asegurarse de hacer las casas correctas en el tiempo correcto y del modo carrecta.

La palabra

sistema tal vez sea el termino mas usado y del que mas se abusa en el

lexica tecnico. Se habla de sistemas politicos, sistemas educativos, de sistemas de aviaci6n y sistemas de fabricaci6n, de sistemas bancarios y sistemas de locomoci6n La palabra dice muy poco. EI adjetivo se utiliza para describir el sistema y asl entender el contexto en el que se usa 1a palabra. El diccionario webster define sistema de la siguiente manera:
I Un conjunto 0 disposid6n de cosas reladonadas que ronnan una unidad 0 un lOdo organko; 2. Una sene de hechos, principios, reglas, etcetera, dasificado y dispuestos de manera ordenada que muestran un plan l6gico de]a unl6n de las partes; 3 Un metoda 0 plan de clasificad6n 0 disposid6n; 4 Una manera establecida de haeer alga; metodo; procedimiento.

En el diccionario aparecen cinco definiciones mas, perc no se sugiere un sin6nimo preciso. Sis/erna es una paJabra especial. AI retomar la definici6n del diccionario Webster, un sistema basado en compUladora se define como:
Un conlunla 0 dlsposid6n de elementos que esl3n arganizados para cumplir una meta predefinida al procesar infonnaci6n

En rulidad, el tennmo ~l(".ria de.sistl"mas se emplea con fTecuencla en ~e contexto. Sin embargo, para los pr0p6:sitos de este Hbro 8ingenieria de sistemas8 es generico y abarca la ingenicna de proce50S del negocio Y Ia Ingenieria de producto

135

Es posible que la meta sea apoyar una funci6n de negocio 0 desarrollar un produc-

10 que pueda venderse para generar benefidos. Para cumplir 1a meta, un sistema basado en computadora emplea una variedad de elementos del sistema: SOftware. Programas de computadora, estructuras de datos y documentaci6n

que sirven para hacer efectivo el metoda, procedimiento 0 control 16gico que se requiere.
Hardware. Dispositivos electr6nicos que proporcionan capacidad de ,:tlculo, dispositivos de interconexi6n (por ejemplo, conmutadores de red, dispositivQS de telecomunicaci6n) que permiten el flujD de datos, y dispositivos electromecanicos (como sensores, motores, bombas) que proporcionan una (unci6n extema, del mundo real. Personas. Usuarios y operadores del hardware y software. Bases de datos. Una extensa y organizada recopilaci6n de informaci6n a la cual se tiene acceso a traves de software y que persiste a traves del tiempo. Documentacl6n. Informaci6n descriptiva (por ejemplo, modelos, especlflcacio nes, manuales. archivos de ayuda en linea, sitios web) que detalla el uso y operaci6n del sistema.

Proc.edimientos. Los pasos que definen el usa especifico de cada elemento del
sistema 0 el contexte de procedimiento en que reside el sistema. Estos elementos se combinan de varias maneras para transformar la informaci6n Por ejemplo, un departamento de mercadotecnia transforma la informaci6n brula de ventas en un perm del comprador tipico del producto; un robot transfonna un arch; vo de 6rdenes que contiene instrucciones espedficas en un conjunlo de senates de control que provocan alguna accKm flSica especlfica. La creaci6n de un sistema de infor mad6n para asesorar al departamento de mercadotecma y un software de control para el robot requlere de Ia ingenieria de sistemas

=,

~VE

Una caracteristica complicada de los sislemas basados en computadora es Gut: tal vez constituyen un macroelemenlo de un sistema aun mayor. El macfOfJemento es un sistema basado en computadora que es parte de un sistema mayor basado tam bien en computadora. Por ejemplo, un slSlema de QucomaCizacion de una jGor/ca se considera una jerarqula de sistemas. En el nivel mas bajo de la jerarqula se encuentra una maquina de control numerico, robots y dispositivos de entrada de informa ci6n. cada uno de eslOS es un SIstema basado en computadora por derecho proplo. Los elementos de la maquina de control numerico incluyen hardware electrnnic(l y electromec:inico (por ejemplo, procesador y memOria. mOlOres, sen!)()re~), !)()fl.wdre (para comunicaciones y control de [a maquina). personas (el operador de la maqui na), una base de datos {el programa de eN almacenadoj. documentaci6n y procedi-

136

PARTE DOS

I'RAc:n:A DE IA JNGDmlIfA 00. 5(FfWARE

dispositiv~ d~

mienlos Podria aplicarse una descomposici6n similar al robot y al

entrada de infonnaci6n. Todos son sistemas basados en computadora

En el siguiente nivel de la jerarqula se define una ctJula de !abricaci6n. Esta es un

sistema basado en computadora que puede tener elementos propios (por ejemplo

computadoras, instalaciones mecanicas), y tambien integra los macroelementos que se han denominado maquina de control numenco, robot y dispositivo de entrada de
informaci6n. En resumen, la celula de fabricaci6n y sus macroelementos estan compuestos de

elementos del sistema con las etiquetas genericas: software, hardware, personas. bases de datos, procedimientos y documentaci6n. En algunos casos los macroele mentos pueden compartir un clemento generico. Por ejemplo, el robot y la maquina
de eN podria operarlas el mismo operador (el elemento personas) En otros casos. los elementos gent,!ricos son exclusivos de un sistema. EI papel del ingeniero de sistemas es definir los elementos de un sistema especlfico basado en computadora en e\ contexto de la jerarquia global de sistemas (macroelementos). En las secciones siguientes se examinan las tareas que constituyen la ingenieria de sistemas de computadoras.

""'..... _de ....... -..........

uu ' ...

_. _.i
Be-

Lt ",t,aul. P' L. 'N9IM",I, P'

'''DM,'

Sin importar su dominio de enfoque, la ingenieria de sistemas abarca una serie de metodos para navegar de arriba hacia abajo y de abajo hacia arriba en la jerarquia ilustrada en la figura 6.1 El proceso de la ingenieria de sistemas por 10 general comienza con una "visi6n global" Es deck, se examina el dominic entero del negocio 0 proclucto para asegurarse de que se puede establecer el contexto tecnol6gico ode negodos apropiado. La visi6n global es refinada para enfocarse totalmente en un dominio especlfico de interes. Dentro de un dominio especial se analiza la necesidad de elementos del sistema (pOr ejemplo, informaci6n, software, hardware, personas) . AI final se inicia el analisis. diseno y construcci6n del elemento del sistema deseado. En la parte alta de la jerarquia se establece un contexto muy amplio, y en e1 de la parte baja se conducen actividades tecnicas detalladas, realizadas por la discipUna de ingenieria correspondiente (por ejemplo, ingenieria de hardware software).2 Dicho de una manera un poco mas forma\' la vi.s.i6n global (VG) la compone un conjunto de dominios (0,) en donde cada uno de ellos puede ser un sistema 0 un sistema de sistemas por derecho propio . VG - (0 " O:k OJ, ... , Onl cada domlnio 10 componen elementos (E,) especlficos. los cuales lIenen un papel para cumplir el objetivo y las metas del dominio 0 componente:

C~VE
I il.1tJ dJo

........ --tI ....

""'"'" '"
~

.,w-, ...... .

... II <OII1I'ensim

.lIsdlltktrecri:os.

2 Sin embargo. en algunas Sltuaciones los ingemeros del SIStema deben consl<ierar primero los elemenlos mdlviduales del siStema Medianle eI uso de este enfoque, los subslStemas se describen de abaJO hada aruba al considerar pnmero los componentes detalJados que rorman el subsistema

137
D, - (E,.
E~

EJ, __ ', ",1

Por ultimo, cada elemento se implementa al especificar los

componentes {Ckl tecni-

cos que logran la funci6n necesaria para un elemento:

E, - IC,. C;& C.,. ... Cd En el contexto de software un componente podrfa seT un programa de computadofa, un componente reulilizable de un programa, un m6dulo, una clase u objeto 0 incluso un enunciado en lenguaje de programaci6n .

..... WiaIlsa$15 mmid.ilodob til sa tunlulo m.5ato~: IllIG silo en Illl lUIII1o, Ul warIotllllllll

-. _

C1I51IIfI .~,. ~ "'"

wt..:

IW_

Es importante nolar que el ingeniero de sistemas estrecha mas el enfoque de trabajo confonne avanza hacia abajo en la jerarqula descrita. Sin embargo, la visi6n global muestra una clara definici6n de la fun cionalidad general que Ie permitira at

ingeniero entender el dominio y el sistema 0 producto en el contexto apropiado.

Dominic de negoeto

o de produclO
Dominio 0. in.es

Vi.iOn 810b01

Vision del elemento

6.2.1 Modelado del sistema

El modelado de sistemas es un elemento impertante del proceso de ingenieria de sistemas. Sin impertar que el enf<XIue este en la vlsi6n global 0 en la visi6n detallada, el ingeniero crea modelos que IM0T921_

133

Iogra (OIl ,I lIIodtlo lit Ia illgHieriide slst...s?

,Oui"

Definen \os procesos que satisfacen las necesidades de la visi6n que se considera Representen el comportamienlo de los procesos y los supuestos en los que se
basa el comportamiento. Definen de modo expllcito las enlradas ex6genas3 y end6genas de informaci6n al modelo. Representan todas las uniones (incJuidas las salidas) que permiten al ingeniero entender mejor la visi6n.

Al construir un modele del sistema el ingeniero debe considerar algunas restricciones

I. Supuestos que reducen el numero de permutaciones y variaciones posibles, 10

que pennite aJ modele reflejar el problema de una manera razonable. Por ejemplo, un producto de representaci6n tridimensional que utiliza la industria del entretenimiento para crear animaciones realistas. Un dominio del producto permite la representaci6n de formas humanas en Ires dimensiones. Las enlradas a este dominio comprenden la habilidad de adaptar movimiento de un actor humane vivo, de un video 0 de la creaci6n de modelos grarkos. El ingeniero de sistemas hace dertos supuestos sobre el intervalo de movimiento humano permitido (pOr ejemplo, las pie mas no pueden enrollarse alrededor del torso) de modo que pueda limitarse eJ proceso y la gama de entradas.

2. SimpJijicacioncs que permiten la creaci6n del modele a tiempo. Para ilustrarlo se puede considerar una companla de productos de oficina que vende y suministra una amplia variedad de fotocopiadoras, escaneres y equipos similares. El ingeniero de sistemas modela las necesidades de la organizaci6n suministradora y trabaja para entender el flujo de informaci6n que engendra una or-

.....,
~~

den de suministro. Aunque una orden de suministro puede orlginarse desde muchas fuentes, el ingeniero loma en cuenla s610 dos de elias: la demanda interna y la pelici6n exlerna. Esto permite una partici6n simplificada de entradas que se requiere para generar la orden de suministro.

C&VE
Unllgerierode

3. l.Jmitociones que ayudan a delimitar el sistema. Por ejemplo, se modela un sistema de aeronautica para un avi6n de pr6x.ima generaci6n. Como el avi6n tiene un diseiio de dos motores, el dominio de monitoreo para la propulsi6n sera modelado para acomodar un maximo de dos motores y sus numerosos sistemas asociados. 4. Restricoones que guian la manera de crear el modelo y lomar el enfoque al implementarlo. Por ejemplo, la infraestructura tecnol6gica para el sistema de representaci6n tridimensional descrito antes utiliza procesadores duales basados en GS. La complejidad de calcul0 de los problemas debe restringirse para encajar en los IImites de proceso que imponen estes procesadores.
3 Las entradas
o:~

-. .........,.
lIterfllliws:

sislM1aS (onsK\ero \os sijpJienl9S foctores aI

del!mli'a sWciooes

........,

reslnCOCIlI5y

ll'eferenOOs del dente.

unen un elemento de una VlSi6n dada con otros elementos en el mismo m

vel 0 en otms niveles. las enuadas end6go1as unen componoentes lodlViduales de un elemento en una VISion panicular

cAPiTuLo 6
5.

!HGDflERiA DE SISTDoV.S

13.

PreJerendas que indican la arquitectura preferida para lodos los datos. funciones y tecnologla 1...1 soluci6n preferida a veces enlra en confliclo can olros faclores reslrictivos. Sin embargo. la satisfaccl6n del c1iente muchas veces se lorna en cuenla hasla el punlO de realizar su enfoque preferido.

El modelo de sistema resultante (desde cualquier vlsl6n) puede reclamar una soluci6n automatica porcompleto. semiautomatica a un enfoque manual. De hecho. can frecuencia es posible caraclerizar modelos de cada tipo que silvan como soluciones ailemativas del problema que se tiene entre manos. En esenda, el ingeniero de sistemas tan s610 modifica la influenda relativa de diferentes elementos del sistema (personas, hardware, software) para crear modelos de cada tipo.

...., 1
6.2.2 Simulac16n del sistema
Muchas sistemas basados en computadora interactuan can 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, can base en estos evenlos, el sistema impone control sabre las maquinas, los procesos e incluso sobre la gente que genera los eventos. Los sistemas de tiempo real y sistemas empotrados a menudo pertenecen a la categoria de sistemas reactivos. Muchos sistemas de la categona de los reactivos controlan maquinas a procesos (como aerolineas comerciales 0 refinerias de petr61eo) que deben operar can un grade muy alto de confiabilidad. 51 el sistema (alia podrian ocurrir perdidas econ6 micas 0 humanas significativas. Por esta raz6n, el modelado del sistema y las herramientas de simulaci6n se utilizan para ayudar a eliminar sorpresas <.:uando se con&truyen sistemas reactivos basados en computadOra. EStas herramicnta5 sc apllean durante el proceso de ingenieria de sistemas, cuando se especifica eI papel del hardware, eI software, las bases de datos y las personas. El modelado y las hcrramienta.5 de simulaci6n permiten al ingeniero de sistemas probar una especificaci6n del sistema.

Herramientas de slmuIaci6n del sistema

Objetivo: Los henomienm de simulo06n del
funcionom~,

operoci6n y respueskl anlM de 10

01 ingInieto de ~ ... ' ' +dod de predecir eI ccmponomieo:'lto de ..., ~ de riempo I'JI onles de que ~'" HI COfI~. .t.d.rn65, .skis henomienkn penn. . 01 ingeniero de ..Itwore desorrollor moquetos del sislemo en riempo . , 10 que permite 01 dienle!Met uno visiOn cIeI
sistemo piopoicionon

imp!e.._.kx:i6n ,.,J.
Mecanica: Los he1T'omientcn. de eta COtegoriCl penn.ten 01 equipa delinir los elemenb$ de un ,1,1emg baKJda en cornpukJdoros, y dMpues eteCUklr YarlOS simvlcxiones para enler'ldM meier las col'tlCief"fsticCls operoc~ y eI ~peno general del sistema.

140

&.; ..... den cmpia. cotegorloi de iimulaci6n del Sls/emO: 1) herromienkls de prop6sitos generales que pueden rnodeIor de monero virtual cua/quier listemo bosodo en com~, y 21 herromientn de prop6$ilos ~io_, que e~ disa'iados pore empleorlos en un dominio de opIicociOn e~1ico (como en sistemas de oeroifneos, ~slemas de

Simia, de~rrollodo por Vlrtutech !www.virtutech.comtes

.......

una pIoIofonno de simulod6n de sislemo que puede modeIor y onolizor sislemCJs bosadc en hordwore y

monufocrura, sislemos electr6nicosl. Henomientas representativas CSIM, desarrollodo por Lockheed Mortin Ad-tonced Tech.--dogy Lobs (www.oIIextemoI.lnco.com).nun simlAodor de _los diKfeios de propO$itos geoeroles para si:llemos onenl\:Jckn 0 diogroolas de edific::ios

SLX, demrroI&oOo pol" Wof...enne Software 1_.woM.n,..com), proporciona bIoqves de oonstrvcci6n de prop6$ito general port! modeIar eI desempeilo de uno amplio yoriedod de siNemas.

En http://_.idsio.ch/-.oooreo/sirmools.html se puede
enconlfor uno serie de vioculos 0 YOrios simu&oci6n de ~lIIm::Js.

fventM de

La meta de la ingenieria de procesos de negocios (IPN) es definir arquitecturas que per-

mitan que un negocio utilice infonnaci6n de manera efectiva. Cuando las necesidades de tecnologia de informaci6n de una compai\fa se observan de manera global.

.. ........
,-11. II 1m

....twn ...

-,

casi no hay duda de que se requiera la ingenieria de sistemas. No 5610 se requiere Ia especificad6n de la arquitectura de c6mputo apropiada, sino tambil~n se debe desalTollar la arquitectura de software que puebla la configurad6n (mica de fuenles de c6mputo de la organizad6n. La ingenieria de procesos de negocios es un enfoque que crea un plan general para implementar la arquitectura de c6mputo ISPE93]. Se deben analizar y diseiiar tres arquitecturas diferentes dentro del contexto de objetivos y metas de negocios. Arquitectura de datos Arquilectura de apJicadones infraestrudura de la tecnologia
La arquilcctura de datos propordana un marco de trabaja para las necesidades de

informad6n de un negocio 0 de una funci6n de negocios. Los ladrillos de la arqui tectura son los objetos de datos que utiliza el negoclo. Un objelo de los datos conliene un conjunlo de atributos que define algun aspecto, cualidad. caracteristica 0 descriptor de los datos que se describen Una vez delinido un canjunlo de datos se idenlifican sus relaciones. Una relaci6n indica la forma en que los objetos estim conectados entre si. Como ejemplo se pue-

-4

LaS helTamJentas mostradas aqul.son una muestra de esta categoria. En 1a mayoria de 105 casos los

nombres est!n TegtStrados por sus fespectlVOS desalToiLadores

141

den considerar los objelos cHente y produClOA. Los dos objelos pueden coneclarse por la relaci6n compra; es decir, un cliente compm productOA 0 productOA es comprado por un cliente. Los objetos de datos (que pueden existir dentos a hasta miles para una actividad de negocios importante) fluyen entre funeiones de negocio, estan organizados dentro de una base de datos y se transforman para ofrecer infermaci6n que satisface las necesidades del negocio.
La arquitectura de apJicad6n abarca aquellos elementos de un sistema que transforman objetos denlro de 1a arquitectura de datos por algun prop6sito de! negocio En el contexte de este libra se considera que la arquitectura de apJicaci6n es el sistema de programas (software) que realiza esta lransformaci6n Sin embargo, en un contexte mas amplio, la arquitectura de apJicaci6n puede incorporar el papel de las personas (quienes son transform adores y usuarios de informaci6n) y procedimientos de negocios que no han sido automatizados La inJmestructum lecnol6glCo proporciona el fundamento para las estructuras de datos y de aplicaci6n. La infraestruclura comprende el hardware y el software con que se apoyan las aplicaciones y los datos Esto incluye computadoras, sistemas de operad6n, redes de computadora, enlaces de telecomunicaciones, te<:nologias de almacenamiento y la arquitectura (pOr ejemplo, cliente, servidor) disenada para imple-

mentar estas tecnologias. En la figura 6.2 se define e ilustra una jerarquia de proceso de negocios para modelar estas arquitecturas de sistema.

lo empr.iIO

astra '

PIa

d.1a in

Areo.... O' negocio

I
Un

,,,i:ttOr! 91

area de "'godo

AMli,,'" d.t de

area

I I I ,oq";';lod.~

I I I
/
sistema del
(vi_dol
n~io

("i$lOo de deminie)

~ocio

--

Si~de informaciOn.

Diseno

.I.mento)

On Jg~glimD ~n.,",,';.... .

Ingeniero d. sOftware

gg

.lnMgrcK

~1i:l.1

142

La meta de la ingenieria de producro es ttaducir el deseo del cliente, de una serie de

capacidades definidas. a un producto del tTabaja. Para conseguir esta meta 1a inge-

niena de produclo --<orno \a ingenierla 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 tecnologia requerida para unir los componentes y la informaci6n (como documentos, CD-ROM, video) que se emplea para dar soporte a los componentes.

....""""".
d.J prOlHIJ

Amn.d:lSf. III'lISl8 cm/eXlO eI

(~

3) r"I"N;w. de
""_dl~

COmo \0 muestra la figura 6.3, 1a visi6n global se consigue mediante la ingenierta de requisitos (capUulo 7). Los requisitos generales del producto se obtienen del clien tc. .stos requisitos comprendc:n necesidades de informad6n y control, funcionalidad del producto y comportamiento, desempei'\o general del producto, disei'\o, restnc ciones de Ja interfaz y otras necesidades especiales. Una vez que se conocen estos requlsitos, e\ trabaJo de la ingeniena de requlsltos es aslgnar funci 6n y comporta miento a cada uno de los cuatro componentes antes descntos. Una vez hecha la asignad6n comienza la ingenierfa de componentes del sistema La ingemerta de componentes del sistema es en realldad un conjunto de actividades concurrentes que dirige por separado cada uno de los componentes del sistema ingenieria de software, Ingenieria de hardware, ingenierfa humana e ingenierfa de

iIgerieti1 ""'" porr*ID. Sf _ WI

~-. cmut.
"....'" arIJ
II.! 1rl1iqo.

.............
La jerarquia de la mgem.riCl ~

EI produdo
,~

productOl.

......

Ingenieria de
~ui,ito,

CaPOC"~~~'~__~~:::JC:::;~r~
Hordware

_~nI

(visiOn global)

____-.

Ingeni.ria eM
com~nen"

r tJ[~:r:.::;~~~~~~ L,,_,-!
Requi:uto de prO(:IISO

dominio) (visiOn d.

funciOn

onili,i, y diseno {visiOn del

............ d.

010-1

Companan", de pn>gramo
L.J..J...J..J

Inve!'iero

doioftwo..
ConstructiOn inte:grociOn (vision detaUoda)

143

bases de datos. cada una de estas disciplinas de ingenieria lorna una visi6n de dam!

nio espedlica, perc es importante senalar que las disciplinas de ingenieria deben
eslablecer y mantener una comunicaci6n activa entre elias. Parte del papel de la
ingenieria de requisitos es establecer los mecanismos de interfaz que perroitan que

esto Sllceda. La visi6n de elemento para la ingenieria de prcxludo es la disciplina de ingenieria aplicada a un componente asignado. Para la ingenieria de software esto significa actividades de modelado del analisis y diseflo (cubierto en detalle en capitu[os posterioresl y actividades de construcci6n y despliegue que abarcan: generaci6n de c6digo. pruebas y tareas de soporte. Los modelos de analisi5 de tareas aSignan requi sitos a las representaciones de datos, funci6n y comportamienlo. EI diseiio convier te el modelo de analisis en disenos de datos, arquitect6nkos, de interfaz y en el nivel de componentes del software.

.... I.ozar, ~ ~ eqo:.oipo d. """ .....1 ...._, ,_1.0 dol ....... do EoI ......., ........ doI ...." . d o - .

'...........

_ _ tugor de traboto . . dtwore despu6s d. 10 ivnto

Ed: Yo Ies mande a 105 dos uno ccpIO pol' COI'ND eMctr6nieo. RIWi--.!a '11-ao Labl _
Vinod:

(Jenne y VIOOd recib eroo eI....,..1iI:XtO dB ElU

NoIo> .............. do b

_ ......
'bdo!:Ie

,au. .. ~ ~.Io COMicW

_iIundo<dkbf do

EI ,iVema vtiliwrO una 0 m05 PC,~~. o:md manuo~ y montabIes en 10 pend, l'Griot )efl5Ofe$ Y vorios oontrolcxtorfi de
di~tNos/opI~ comumcartln par

prOlCJWlos

(po<.,""""" 80211b)y ..... " ........... ~ consin.IcciOn de cosas 0ueY05 '110 opIicociM Ir'I COlOS
existenles.

Todo eI hardwa,., a excepci6n de nuestro I'KIeYO coja irooI6mbric:o, "tora fv.ra d.I anaqueI "'oc"",,,idod .,... dol ""'-" .....;do do ~
conYenOCiort de inicio. Funciones de ago-ridod de 10 COX!

,,,,,,,0- oti

au-, . .,.. miroron como si estuviero loco. peru _ .. do......,...,doI ........JIo ..... ~
~ ... hobIondo <;QIl.no,

.me. tomando noIos con mi PDA duronlelo

, ....... ~D

do ,"""",,",.,_

0u6 bon, d6jomo_

Sensor de !I'IO'I'imiento d. puerta/.......a.a pore monitor.ol"!,WI Qt;(eoo no ~ (robosl. Monitor.o delu.go y h"mo Monitor.o de oivool do gguo en ~ If'O'" :~, intKldaci6n a rompIMM!n1o del coMnIodor de oguol

144

PARTE DOS

PRAcncA DE LA INQNlIl!L.\

DEl.

SOFTWARE:

_.10_ """""'.... o.a.. .......

C:d ........IiD.

.Di~:::::::!::::~~!~
Coniottor ...Qdu,.. pcII'O

~. ""'"".

ConIrcIcr 0 uno 0 m6s c:6maro5 de vid.o coIoccx:b

OsrMIIrtrpaNllOllIO/ZOCn'I. bs c6mc1ro$ II'IOIIiIcno d.1os am:.ras ............ dela c6Inoro.., PC. . . . . OOI:MO a las tomos de 10 c6Mara via 1nMrnet. ...-cIgitaI y ............ Ios Iomoi de 10
, . . . . "'*"D It. IDrna5 de Ia o:lno'a.

Funciones de 10 gesti6n de ~

F.-.I0 ........ I0""".

c. HYAC

j~

Debido a que un sistema puede representarse con diferentes grados de abstracci6n (por ejemplo, la vision global, la vision de dominic, la vision de elementa), los modelos de sistema tienden a ser jerarquicos 0 estratificados por naturaleza. En la parte

mas alta de la jerarquia se presenta un modele del sistema completo (\a vision global). Los objetos principales de datos, las funciones de procesamiento y los compor~

tamientos se representan sin incluir el componente del sistema que implementara

los elementos del modelo de visi6n global. A medida que la jerarquia se retina 0 estratifica se modela el detalle al nivel de componentes (en este caso, representaciones de hardware, software, etcetera). AI final, los modelos de sistemas evolucionan a modelos de ingenieria (los cuales se retinan despues) que son especificos para la discipHna de ingenieria apropiada .

6.5.1

ModeJado Hatley-Pirbhai

Todo sistema basado en computadora puede modelarse como transfonnaci6n de la informaci6n al emplear una planliUa de entrada-proceso-saHda. Hatley y Pirbhai [HAT87J han ampliado esta vision para incluir dos caracteristicas adicionales del sistema: procesamiento de la interfaz del usuario y mantenimiento y procesamiento de

145

autocomprobacl6n. Aunque estas caracterlsticas adiciona les no esttm presentes en todos los sistemas basados en computadora. son comunes y su especificaci6n haee que cualquier modele de sistema sea m~s robusto. Con el uso de la representaci6n de entrada, procesamiento, salida, procesamientos de la interfaz del usuario y procesamiento de autocomprobaci6n, un ingeniero de sistemas puede crear un modele de componentes de sistema que deje un funda-

mento para etapas posteriores en cada una de las disdplinas de ingenieria. En el desarrollo de un modele de sistema se utiliza una plantilla modelo del sistema [HAT87). EI ingeniero de sistemas asigna elementos de sistema a cada una de las cinco regiones de procesamiento dentro de la plantilla: I ) interfaz del usuario, 2) entrada, 3) funcionamiento y control del sis tema, 4) salida, y 5) mantenimiento y autocomprobaci6n.

AI igual que casi todas las tecnicas de modelado utilizadas en la ingenieria de sistemas y de software, la p lanlilla modelo del s istema Ie permile al analista crear una jerarqula en de talle. En el nivel mas a lto de la jerarqula esta el diagrama de COnlexto del sistema (OCS). EI diagrama de contexte ~establece los limites de informaci6n entre el s istema que imple menta y el ambiente en el que opera el sistema" IHATS71 Es decir, el OCS define todos los productores extemos de informad6n que el sistema uUliza, todos los consumidores extemos de informaci6n que el sistema crea, y todas las entidades que se comunican a traves de la interfaz 0 reallzan mantenlmiento y autocomprobad6n.

Para ilustrar el uso del OCS se considerara un sistema de cJasijicadon de dnfa rransponadom (SCCT) descrito en la siguicntc dcclaraci6n (un tanto confusa) de: objetivos:
E1 SCCT debe desarroliarse de manera que las cajas que se mueven a 1 0 largo de la cinla

tra nsportadora sean identllkadas y ordenadas en uno de los seis contenedores al final de la cinta 1...15 caJas pasarlm a traves de una esta06n cLlSlficadora, donde se identificariin. COn base en un numcro de k1e nUncaclon Impreso en un laleral de la UlJa y un coolgo de barras, las cajas se mandaran a los conlenedores apropiados. Las cajas pasan en un orden aleatorio y estan igualmentc cspaciadA3. 14 lInea!iC mucvc con IcntituO Una computadora de escritOliO iocalizada en la estaci6n ciasifLCadora ejecuta lodo el software del seer. interactUa oon el lector de cOdigo de barras para leer numeros de parte en cada caja, interactUa con el equipo de monitoreo de la linea transportadora para oblener ]a veloddad de ]a linea transportadora. almacena todos los numeros de.': parte claslficados, inte.':ractua con un operador de la estad6n dastficadora para producir varios reportes y diagnOsticos, manda senales de control al hardware para clasificar las cajas, y Sc.': comunica oon un sistema de automatlzad6n central de la fabrka. EI OCS para e.': 1 SCCT" se muestra en la figura6.4. EI diagrama x divide e n cinco xI!: mentos principales. El segmento de arriba representa el procesamiento de 1 <1. interf<l.7 del usuario, y los segmentos de la izquierda y de la derccha mu~tran cl prOCC:liI miento de entrada y de salida, respectlvamente. EI segmento central contiene fun~ dones de control y proceso, y e l segmento de abajo se enfoca en eJ ma nte nimiento

146

PARTE DOS

PRA.CTX:A DE 1J\.1NGrnIil4A DD.SOfTWARE

,
Diagtama de contexto del slstemadel SCCT.
Proce50

de 10 interroz
dell.!soorio

Operodorde Ia eMotiOn de dosifkod6n

Peticion ~

TCOf\su\tos ComOnd05
de control .Y.econismo de

",,,,,de
cooigo de oorros C6digo de borros

sq_do
daoificaciOn

dosilicoci6n

... cinla

0010$ fot-moteodos del informe

Cinto Iransportodol"o

r
M.ontemmienlo Operodorde 10 ~loci6n de y closificaciOn Q'~

Eslrucluro

Indicodor de 10 Doll de diogn6$lico velocidodde 10 cinto

principol

PrOC8$Omienio

PrOC8somierllo

de entrada

comproboci6n

de $Olida

y Ja autocomprobaci6n. Cada caja que se muestra en Ja figura representa una entidad exlema; es decir, un productor 0 consumidor de infonnaci6n del sistema. Por
ejemplo, ellector de c&liga de barras produce informaci6n que es introducida aJ sis-

tema SCCT. El simbolo para el sistema completo (a, a niveles mas bajos. 5ubsistemas
principaJes) es un rectitngulo con las esquinas redondeadas. Par 10 tanto, el SCCT se representa en la regi6n de procesamienl o y control al centro del DCS. Las flechas etiquetadas que se muestran en el DCS representan informaci6n (datos y control) que va de un ambiente extemo hacia el sistema SCCT. La entidad extema lector de c6digo de barras produce entrada de informaci6n etiquetada como c6digo de barras. En esencia, el DSC coloca cualquier sistema en el contexto del ambiente extemo. El ingeniero de sistemas retina el diagrama de contexto de arquitectura al estudiar con mas detalle eI rectangulo sombreado de la figura 6.4. Se identifican los subsistemas principales que permiten funcionar al sistema c\asificador de cinta transportadora dentro del contexto definido por el DCS. Los subsistemas principales se definen en un

diagroma de flujo del sistema

(DFS) que se obtiene del DCS. El flujo de

inrormaci6n a traves de las regiones del DCS se utiliza para guiar al ingeniero de sistemas en el desarrollo del DFS, un esquema mas detallado del SCCT. EI diagrama de flujo del sistema muestra los subsistemas principales y el flujo de las Ilneas de informaci6n importantes (datos y control). Ademas, la plantilla del sistema divide el proceso del subsistema en cada una de las cinco regiones de proceso previamente estudiadas. En este punta, cada uno de los subsistemas puede contener uno 0 mas elementos del sistema (por ejemplo, hardware, software, personas) tal y como los ha asignado el ingeniero de sistemas.

'41

Dog omo de Rujo de mO$ olio nivel

, ,

de Ie

orqultectura

]
I- A
OfS deA

-g
f-'
DFS de B

l{

;.:::::;
ILJ

(J

1::.C

:r

"
LJ
'--'

OfS d.C

-n
]

!-

EI diagrama de flujo del sistema (DFS) inidal se convierte en el nodo superior de

una jerarquia de DFS Cada rectanguJo redondeado del OFS original puede expan dirse en atTa plantilla de arquitectura dedicada a ella en forma exclusiva E.ste procesc se ilustra de manera esquematica en la figura 65. cada uno de [os DFS del sis-

tema puede utilizarse como punto de partida de subsiguienlcs fa5C5 de lngenicrla para el subsistema que se describe. En los subsiguientes trabajos de ingenieria se pueden especificar (delimitOlr) los subsistemas y la inrormaci6n que Iluyen entre cllos. Un relato dc:scrlpllvo de cada
subsistema y una definid6n de todos los datos que nuycn entre los subsistemas son elementos importantes de la especilkaci6n del sistema.

6 .5.2 Mocielado del sistema con UML

EI UML propordona una cantidad impresionante de diagramas que pueden utilizar se para el analisis y diseno al nivel de software y del slstema. 5 Para el SCCT se modeIan cuatro elementos importantes del sistema I) el hardware que permite el seCT; 2) el software que implementa el acceso a la base de datos y la clasificaci6n; 3) el operador que acata varias peticiones del sistema; y 4) la base de datos que contiene inrormaci6n relevante del c6digo de barras y el destin~.

5 En Ioscapitulos del 8 ill II se presenta una ~xposici6n mas detallada de los dlagramas de UML Para una exposici6n compl~ta del UML ellector interesado debe consultar [SCH021, IUr.ROII oIBfN99\

I"
Diagrama de deopUegue del hardware

deSCCT.

EI hardware del seCT se puede modelar en eI nivel del sistema mediante un dia-

grama de desplicgue de UML, como se ilustra en la figura 6.6. Cada caja tridimensional muestra un elemento del hardware que es parte de la arquitectura flsica del sistema. En algunos casas, los elementos del hardware tendrtm que disefiarse y construirse como parte del proyecto. Sin embargo, en muchos cases los elementos del hardware se pueden adquirir ya construidos. EI reta para el equipo de ingenieria es realizar la

interraz de los elementos del hardware de manera apropiada.

Los elementos del soltware para el SCCT se pueden mode\ar en una variedad de

formas mediante eJ uso de UML Los aspectos de procedimiento del software del
SCCT

se pueden representar mediante un diagrama de actividad (figura 6.7). Esta

notaci6n del UML es similar al diagrama de flujo y se utiliza para representar 10 que sueede mientras eI sistema realiza sus (uneiones. Los reetangulos redondeados implican una funci6n especifica del sistema; las Ileehas representan eillujo a traves del sistema; el rombo de decisi6n representa una decisi6n ramificada (cada fleeha que sale del rombo esta etiquetada); las lineas s6lidas horizontales implican la rea lizacion de aetividades en paralelo. Otra notaei6n de UMLque se puede usar para modelar software es el diagrama de

dose (junto con muehos diagramas relacionados con las clases que se examinan en
apartados posteriores de este libro). En el nivel de la ingenieria del sistema las clases6 se extraen en un enunciado del problema. Para el SCCT las clases eandidatas

En capilulos anleriores 5e destac6 que una clase representa un conjunto de entidades que forman parte del dominio del sistema El sistema puede almacenar 0 tram;formar estas entidades 0 pueden 5elVir como un prodoctor 0 consumidor de la infonnad6n que el sistema produce.

cAPiTuLo 6

tNGDm:RlA DE SISTD.(AS

C6digo de boff05 vOlido

podrfan ser de: caja, linea de conducd6n , lector de c6digo de bruTas, contTolador de manlobras, soUdtud del operador. reporte, produc::to y otras Cada clase encapsula un conjunto de atributos que representa toda la informaci6n necesaria acerca de la cJase. Una descripci6n de clase tambi~n cantiene un canjunta de aperadones que se aplican a la clase en el contexto del SIstema SCCT En la ligura 6.8 se muestra un diagrama de clase de UML la clase caja. EI operador del SCCT se puede modelar can un diagrama de UML de tipo casos de uso coma se muestra en la figura 6.9 EI diagrama de caso de uso ilustra la forma en la que un actor (en este caso el operador que se represema con una ftgura aClherida) interactua can el sistema. cada 6valo etiquetado dentro de la caja (\a cual representa la frontera del sistema SCCT) implica un caso de uso -un escenaria escrita que describe una interacd6n can el sistema.

ISO

-.

Oiagrama de clasede UML para Ia clase

Cop . . . . .
0",",

~
V

Nombre de 10 dose

~jgo de barros o<idad ho<io dola... / '

ubicoc,On del cOtIdudor

ArriOOtos

.-.

proh.ndidod

contenioo
olfiblJlo,

lecNro dei c6digo de bonos{ I

odllotizoei6n

l- Operociones II< porenlesis

01 firMll del nombre indican 10 li.do de
atributo, que requiere 10 Of*'oci6n1

do """,dodl , lecture de ....iocidodf)

ocfI.IoI,j:wciOn

de 10 vhicociC"'l) lectura d. ubicociOnll obtenci6n de dimen~ione$1 ) ~"'_I 'NificaeiOn de cooteflido( I

Opo<odo< del sea

cAPiTuLo 6

INGENIERlA DE SISJD.(A5

151

Hellamientas de modeJado de sistemas Objetivo: Los herramientas de modeIoda de Ralional XDf and Rose, de~1'T'OI1odo por Rational sistemas proporcionan 01 ingeniero de software Technologies iwww.rotional.com). proporciooa una D c:apocidad de madelar Io:lIh los elemenlas de un odoptociOn bo~ en UML de herramientas de .....,., ba1Odo en camputadoras 01 VSOf" uno notociOn ~rroIlo y modeIodo para ~slemos boKJdos en .-ffiw para 10 herromienla. romputodoras, Ie eval se utilize de manera amplia . ....anteCl: Los mec:6nicas de los herromientas YOrion. Reo/-TIme SIvcIio, de!oQrToIlodo par Artisan Software 'liar 10 general, los herromientas de esta ootegoria oyudon i_ortisonsw.com) es una conjvnta de herramienkl$ irlgeniero de 5istemas a madelar 1) Ie estrvdura de de modeIado y ~rrollo que don soporte 01 IDdc.Ios elementos nl!"lcionaies del ~demo; 2) eI desarrollo de sistemas en tiempo real.
-....tumiento esl6tico y din6mico del5islema; 3) Ia ..-iaz mCquina-hvrnono. """""'mientaJ representcmvClJ 7 TeIeIogic Tov, deKJrTOlloda par TeIeIogic i-.te!eIogk.com), es un conjunto con herromientas bo~s en UML que do ~ 01 modeIodo de di~ YanaIisis, y tiene vincvlos con corocterhticos de construcci6n de soflwore.

DIItcnibe, ~rroIlodo par Embarcodero Technologies ....... embarcadero.com), es uno odapkxiOn de . . . . Q .....tas de modeIodo ba~s en UMlque puecIe ~r sistemos de software a sistemos compIetos.

Un sistema de alta tecnologla comprende varios componentes: hardware, software, personas, bases de datos y procedimientos. La ingenieria de sistemas ayuda a traducir las necesidades del cliente en un modelo de sistema que emplea uno 0 mas de estos componentes.
La ingenieria de sistemas comienza al adoptar una "visi6n global" Se analiza el dominio del negocio 0 producto para establecer todos los requisi tos basicos. El enfo-

que se reduce entonces a una "vision de dominio", dondc cada uno de 105 elemen tos del sistema se analiza en ronna individual. cada elemento se asigna a uno a mas componentes de ingenierta, los cuales se estudian aplicando la disciplina de ingenieria correspondiente . La ingenieria del proceso de negocios es un enfoque de la ingenieria de sistemas mediante el cual se definen arquitecturas que pennitan a un negocio utilizar la in(ormaci6n de manera eficaz. EI objetivo de la ingenieria del proceso de negocios es crear una arquitectura de datos, una arquitectura de aplicaci6n y una infraestructura de tecnologia comprensibles que satisragan las necesidades de la estrategia de negocio y los objetivos y metas de cada area del negocio. La ingenieria de productos es un enfoque de la ingenieria de sistemas que comienza con el antllisis del sistema. EI ingeniero de sistemas identifica las necesi-

7 Las herramienlas mostradas aqu[ son una rnuestra denlro de esla calegoria. En la mayona de los casos los nombres estan registrados por sus respectivos desarroJladores.

152

PARTE DOS PRAcncA DE l.A.1NGENIERL\ 00. 5a'TWAR

dades del cHente, del ermina \a factibilidad econ6mica y tecnica, y asigna funciones

y rendimientos al software, el hardware, las personas y las bases de datos; es decir

a [os componentes clave de la ingenieria.

[BEN99\ Bennett. S., S. McRobb Y R. Farmer, Obp:t-Orienled ~/em5 Analysis and Design USlTW
UML, McGraw-Hill, 1999. IHAR93J Hares, J. S. InJormation En~8for Advanced

Proctifioner, wHey, 1993, pp. 1213 [HAT871 Hatley, D. J. e I. A. Pirbha~ Strategies/or Reol-Time *,Iem Specification, Dorset House 1987. ILAROI J Lannan, C., lIpp/ylng UML and PatIentS; An Introduction /0 Objccl-Oriented Anatysis and

Dt::sign and the unified Process, 2a. ed., Prentice-Hall, mayo de 200 I.
[MAR901 Martin. I . In/onnalkm Engineering Book IJ~P/anning and Annlysis, Prentice-Hall, 1990 [M0T92] Motamarri, S., ~Systems Modeling and Description-, en Software Engineenns Notes, vol 17, num. 2, abril de: 1992, pp. 57-63. [SCH02ISChmul1er, J. 1a1ch YoursdjUML in 24 Hours. 2a. ed., Sams Publishing. 2002.

]SPE93] Spewak. 5 . En/erpnse Archilec/ure Planning. QED Publishing, 1993.

[TIIA97] Thayer, R. H. Y M. Dorfman, Software Requirements Engineering, 2a. ed., IEEE Computer SOCiety Press, t997.

6. 1. Encontrar tantos sin6nimos como se pueda de la palabra

~sistema~.

[Buena suerte'

6.2 . Construir un sistema de sistemas'" jerarquko para un sistema, producto 0 servicio con d cual se este fami liarizado. La jerarquia se debe extender hasta los elementos simples del sistema (hardware, software, etcetera) de aJ menos una rama de cada estructura. 6 .3. 5eleccionar un sistema 0 producto grande con eJ que este familiarizado. Definir el conjunto de dominios que definan la visi6n global del sistema 0 prCKIucto. Describir el conjunto de elementos que componen uno 0 dos de los dominios. Para un elemento, identificar los componentes tecnicos que deben desarrollarse. 6.4. 5eleccionar algUn sistema 0 producto grande con el cual este familiarizado. Establecer las suposkiones. simplificaciones, Iimitaciones. restricciones y preferencias que se deberfan hacer para construir un mCKIelo de sistema de modelo eficaz (y realizable). 6.S. La ingenierta de procesos del negoc:io requiere defini r datos, arquitt:elura de aplicadones, ademas de una mfraestructura de aplicadones. Describir cada uno de estos tenninos mediante un ejemplo. 6.6 . Un ingeniero de sistemas puede tener una de tres procedencias: el desarrollo de sistemas. el c1ienle 0 una organizaci6n enema. Oiscutir los pros y los contras de cada procedencia_ idea' _ Describir un ingeniero de sistemas H 6.7. EI profesor entregara una descripci6n de alto nivel de un sistema 0 producto basado en compuladoras. oj Desarrollar un conjunto de preguntas que se debena realizar como ingeniero de siste mas. bJ Proponer al menos dos ubicadones diferentes para el sistema con base en las respueslas a sus preguntas. cJ En clase, comparar sus ubicaciones con las de sus compafteros. 6.8 . Desarrollar un diagrama de contexta del sistema para el sistema basado en computadoras que se haya elegido (0 uno asignado par su profesor).

153
6.9 Aunque la informaci6n haSla este punto esta muy entrecortada, tratese de desarTOllar un diagrama de desarrollo, un diagrama de aclividad, un diagrama de cJase y un diagrama de caso

de uso con UML para d producto

~ro ,

6.10. Realizar una investigad6n bibliogrtllic.a y escribir un documento breve que describa
c6mo funeionan las herramientas de modelado y simulaci6n. Altemativa, recopUe bibliografia de dos 0 mas vendedores de hcrramienlas de modelado y simulaci6n y evalue sus similitudes y

diferencias 6.11. iExisten caracteristicas de un sistema que no se puedan establecer durante las actividades de la ingenieT1a de sistemas? Describir las caractcristicas, si existen, y explicar por que su considerad6n se debe retrasar a posteriores del desarrollo

rases

6.12. GExisten situaciones en las que la especlficaci6n formal del sistema se pueda abreviar 0

eliminar por completo? Expllquese la respuesla

Los libros de Hatley y sus colegas (Process for S}Stemsltn:hiltureand ReqwremenlS Engineering, Dorset House, 20011. SUede (1he Engineenng DesJgn ofSystetnS; Models and Methods, Wiley, 1999). Weiss Y sus colegas (SOftware Produa -line Enginemng, Addison-Wesley, 1999), Blanchard y Fabrycky ~em Engineenng and Ana!)':si5. la. cd., Prentice-Hall, 1998), i\rmstrong y sage (Introduction to S)'stmls Enginoenng, Wiley. 199n, y Martin (.S}'StemS Engineermg GulddxxJk, CRC Press, 1996) presentan el proceso de la ingenkrla del sistema (con un enrasis

distinto en la ingenter1a) y proporcionan una gula muy valiosa. Blanchard (,S}'srem Engrneenng
Management, segunda edicion, Wiley, 199n y Lacy /-S)'stem Engineering Managemenl, McGrawHill, 1992) exponen aspectos de gesti6n de la ingenieria del sistema Chorafas (Enterpt= Itn:hitture and ~ Generation S)'stmls, St. Lucie Press, 2001) presen-

ta ingenierla de Inr0nnad6n y arqUltecturas de $lStema para la ~slguiente generacl6n~ de soluciones de TI; se induyen sistemas basados en Internet. Wallnau y sus colegas (Building systerm from COInncial ComponennfS, Addison-wesley, 2001) .se enroca en los aspectos de ta lngenierla de sistemas basada en componentes para prodUCIOS y sislemas de informaciOn. Lozinsky (Enterprtse-WKIe Software Solutions: Integmlion Slrntegies and PmctJces. Addison-Wesley, 1998) abarca el uso de paquetes de software como una sotUCiOn que pennite a las companlas pasar de los sistemas heredados a kIs procesos de negocio moc1emos. Una exposid6n muy valiosa del riesgo y la ingenkrfa del siStema .se presenla en el !ibro de Bradley (Elimination of Risk In .syswns, Tharsis Boooks, 2002). Davis (Bu.sJness Process Modeling wtlh NiS; A ProcUcal GUkJe, sprlnger-verlag. 200t l. Bustard y sus colegas ~em Models for BusIness Process Improvement, Artech House, 2000), y Scheer (Bus.iness Process ErIgInnng ReferetHX MOdr:b for loolJ$Iiai CfllapriX::l, 5prlngcr-Vcrlag, 1<;1<;10) describen los mttodos de modelado del proceso de negodos para sistemas de infonnad6n y de tada una empresa. Davis y Yen {17Ie In/Ormaoon system consultant's Handbook. systemsAna~ and Design, CRC Press, 1998] pre.sentan una cobertura encic\oped.ica de los aspectos del .. nillUsts y dlseno (Ie ::.1::.temas en el dominic de los sistemas de informadon. Una ayuda excelente del IEEE por Thayer y Dorfman {THA97) discute Ia interrelad6n entre los analisis al nivel de sistema y al nivel de software. Law y sus colegas (Simulation Madding and Anatysl$, McGraw-Hill, 1999) analizan tecmcas de modelado y s[mulaci6n de sistemas para una amplia variedad de dominios de aplicaci6n Para los Jeclores invotucrados de manera activa en eJ trabajo de sistemas 0 que estan interesados en un tralamiento mAs elaborado del l6pico, los libros de Ge rald weinberg (An Introduction to Generol S}Stml Thinking, Wiley, [nterscience, 1976, y On the Design o f Stobie systems, Wiky-Interscience, 1979) se han convertido en clasiCos y of"recen una excelenle exposici6n sobre el "pensamiento general de sistemas~, 10 que de manera implidla condua a un enfoque general del atlliJjsjs y diseflo de sistemas. Otros libros mas recienles de wein~rg (Generall'linapks o/SyslmlS Design, Dorset House, 1998 y &flunkmg Systems Anatysis and ~n, Dorset HoUSt!, /998} continuan la tradidtm de este primer trabaja.

'54
En Int~met existe una ampha variedad de fucntes de lnformac:i6n sobre la ingenieria de satemas y matenas ~Iacionadas En el slllO Web de SEPA, http;II_ .mhhe.com/ pressmaa sc: puede encontrar una lista actualizada de referencias en la red rnundial que son relevantd para la mgenieria del sistema, 1a ingenieria de la informaci6n, \a ingenierla de proceso del nego cio y Ja mgcTueria del producto.

CAPiTULO

INGENIERiA DE REQUISITOS

L
.160 . 161
. IS1

a comprension de los requisites de un problema estti entre las tareas mas dificiles que enfrenta un ingeniero de software, Cuando se plensa por pri mera vez acerca de ella, la ingenieria de requi sitos no parece tan diflcil, Oespues de tode, c.el clienle no sabe 10 que se requiere' GLos usuarios finales no debenan entender bien las caracteristicas y funciones que les proporcionaran un beneficio" Es sorprendente, pero en muchas ocasiones la respuesta a estas pre. guntas es: a no.. Y aun si los clientes y usuarios finales son explicitos en sus necesidades, estos requisitos pueden cambiar durante el proyecto, La ingenierfa de requisitos es dificil, En el pr61ago a un libra de Ralph Young (YOUO I ] sobre las practicas efectivas en los requlsitos, el autor de este libra escribi6:
Es tu peor pesachlla Un cliente entra en tu oficina, se sienla, Ie mira directo a los 0j0s, Y dice: "Yo se que usted piensa que entlellde 10 que digo, pew 10 que usted no entiende es que Jo que dlgo no es reatmente Jo que quiero dear'" Esto sucede de manera mvanable ruando el proyecto esta avanzado, despues de que Sl! han realizado los compromlSOS relativos al tlempo de entrega, las rqRllaa0ne5 estAn en IUego y eI dmero esl1l en seno peliWO.

..1"
. 160
IS1

.113
.171

.In
.1.1

Todo$ios que hemO$ traba)ado en c:I negocio de lo:Isi:.tCIl"lo<U Y c1 ~(lftw!lre por mdS de unos cuanlOS anos hernos \'lvido esta pesadilla. y s6Io unos pocas de nosotros he: mas aprendido a contmuar aun con esta circunstancia. Nosotros tenemos dilkultades ruanda tralamos de nbkner requisilos de nue5tros chcntes Tenemos problemas 011 comprender la informact6n que adquirimos. Con frccucncla rcglSlramo:; 10:; n:-

LQue es? lo ingenier"a de requ's'tos ayudo a los ingeniero$ de softwo ra 0 entender major 81 problema en

tPor que

cuyo soIuci6n trobojor6n, Induye eI de !areas que condvcen a ,.......OOOM cv61 ser6 eI impocto del softwara
conjunto elneglXio, que es 10 qlJe el diente quiere il'ller"actuarol'l los usuanos ~.,ole con el

e s importon..? El disei\o y 10 construce/On de un elegonfe progromo de computodora que rewelvo eJ problema incorreclo 1'10

sotisfoce los nec:esidade, de nodie POl 10 tonto, ~ muy important. entender 10 que al clieole
quiere antes de comenzor a disenar y constrvir un sistema bosoda en computodora.
LCuOIes son los posos? lo ingenieria de requisit\ empieza con 10

hac.? los ingeniaros de

software como ingenieros de $IS-

fose de

inicio, 10 clIOl es

una toreo que de~ne el ombflo y

, en eI mundo de 10 TIl y otrcn (gerenles, elienles y usuarios firdes) en Ia ingeniano de requ sit.:

de ",obiema que debe ,.......... Despue. continua con 10 obenci6n, que e5 uno Ioreo que oyudo al eliente a de~nir sus netflidodes; postetiormente ~ con 10 eIoborac:i6n. que es 10
155

Ie

naluraleza

156

PARTE DOS

PRAcrr::A DE LA ~ Dll. SOFTWARE

me que __

con 10 lCu61 .......... . del_dolo da.Ie ....... deI ......oo.

pol..,.....

quisitos de una manera desorganizada e invertimos muy poco tiempo en veriticar 10 que registramos Permilimos que el cambio nos controle en lugar de establecer mecanismos para controlarlo. En resumen, rallamos al establecer un cimiento sOlido para el sistema 0 software. Cada uno de estos problemas representa un reto. CUando estos se combinan, la imagen es desalentadora induso para los gerentes y pro resionales del sofware mas experimentados. Pero existen soluciones.

Seria deshonesto decir que la ingenieria de requisitos es la " soluci6n~ para los Tetos que se han enunciado. Pera proporciona un enfoque s6lido para abordar dichos desafios.

Las actividades de diseflo y construcci6n de software de computadora son desafiantes, creativas y hasta divertidas. De hecho, la construcci6n es tan irresistible que muchos desarrolladores de software quieren entrar en ella antes de comprender con c1aridad de que es 10 que se necesita . Elias argumentan que las casas se aclararan mientras construyen; que los interesados en el software seran capaces de entender 0 despues de examinar las primeras iteraciones del softmejor las necesidades s61 ware; que las cosas cambian tan rapido que la ingenieria de requisitos es una perdida de tiempo; que la linea de base produce un programa que funciona y todo 10 demas es secundario. Lo que hace seductores a estos argumentos es que contienen elementos de verdad.1 Pero cada uno de ellos es imperfecto y puede conducir a un proyecto de software fallido.

En partkular, eSlO es cierto para los proyeaos chicos (menos de un rues) que implican un esfuen:o relativamenle pequeno. Conronne el software crece en lamano y complejidad. estos argumentos coruienzan a derrurubarse.

cAPiTuLo 7

INGEHiERlA DE RQUISfTOS

157

,.,... . . ~ COI'ISi1i" BIn de sotrwar. IS _ _ . . amInir. iIt.... porII ... tI __ ,....siM_ ......... ,arle IS_ tid.rdb~

tI I _ .... .........

La ingenierta de requisitos, como todas las demas actividades de la ingenieria 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 ingenierfa de requisitos (IR) es una acci6n de la ingenierta del software que comien~ za durante la actividad de comunicaci6n y continua en la actividad de modelado. En algunos casos se elige un enfoque abreviado. En olros, cada una de las tareas definidas para comprender los requisitos se debe l1evar a cabo de manera rigurosa SObre todo, el equipo de software debe adapl ar su en roque a la IR, 1 0 que no signifi ca abandono. Es esencial que el equipo de software haga un esruerzo real por entender los requisilOS de un problema antes de intentar resolverlo. La ingenierfa de requisitos tiende un puente hacia el diseno y la construcci6n. Pero ,d6nde se ongina el puente? se puede argumentar que comienza al pie de los partidpantes del proyedO (es decir, gerentes, clientes, usuarios finales), donde se definen las necesidades del negocio, se describen los escenarios de los usuarios. se de!inean las caracteristicas y runciones, y se identifican las restrlcciones del proyecto. Otros quiza sugieran Que comienza con la definici6n mas amplia del sistema, en el que el software es s61 0 un componente (capitulo 6) del dominio del sistema que es aun mayor. Pero sin importar el punla de inicia, el trabaja a 10 largo del puente se inicla en la parte alta del proyecto, 10 que pennite que el equipo de soAware exam; ne el contexto del trabaja de software que sera realizado; las necesldades espccificas que el diseno y la construcci6n deben abordar; las prioridades que indican cI orden en el que se debe completar el trabajo; y la informaci6n, las fundQncs y los comportamientos que tendr.1n un impacto prorunda en el (UseM resul tante .

La ingenieria de requisitos proporciona el mecanismo apropiado para entender 1 0

que el cliente quiere, analizar las necesidades, evaluar la faclibilidad, negociar una soluci6n razonable, especilicar la soluci6n sin ambiguedades, validar la especi ficaci6n, y administrar los requisitos confoone estos se transrorman en un sistema operacional {lliA97J. EI proceso de la ingenieria de requisitos se !leva a cabo a traves de siete distintas runciones: inicio, obtenci6n, elaboraCl6n, negociaci6n, especificaci6n,

validaci6n y gesti6n.
Resulta importante destacar que algunas de estas funciones de la ingenieria de requisitos ocurren en paralelo y que todas deben adaptarse a las necesidades del 0 que el cliente qUiere, y todas sirven para proyecto. Todas estan dirigidas a definir 1 establecer una base s6lida respecto del diseno y 1a construcci6n de 10 que obtendra el cliente.

158

PARTE DOS PRAcocA D IA.INGrnIDl!A 00. SOFTWARE

7.2.1

Inicto

,-C6mo se inleia un proyecto de sofiware? <.Es un evento aislado que se convierte en

eJ catalizador para un nuevo sistema 0 producto basado en computadora? GO la necesidad evoluciona con el tiempo? No exislen respuestas definitivas para estas

preguntas .
.,. ....... 1IIs _ _ de los cIesames mils importunles en software Sf silmlnl", m ,,;n..s .. -

... II (0IIIiInm dII proyIdII.-

En algunos casos, una conversaci6n informal es todD 10 que se necesita para precipitar un esfuerzo importante de ingenieria del software. Perc en general, la mayaria de los proyectos comienza cuando se identHica una necesidad de negocios 0 se descubre un nuevo mercado
0

servicio potencial. lDS participantes de la comunidad de

negocios (es decir, los gerentes, gente de mercadotecnia, gerentes de producto) definen un caso de negocios para Ja idea, tratan de identificar la amplitud y profundidad del mercado, hacen un analisis preliminar de factibilidad, e identifican una descripci6n funcional del ambito del proyeeto. Toda esla informaci6n esta sujeta a cambios (una situaci6n probable], perc es suficiente para suscitar conversaciones con la organizaci6n de ingenieria del sollware. l AI

inici03 del proyeclo los ingenieros de sallware hacen una serie de preguntas

libres de contexto, las cuales se exponen en la secd6n 7.3.4. E1 objetivo es establecer una comprensi6n basica del problema, las personas que quieren una saludon, la naturaleza de la saluci6n que se desea, y la efectividad de la comunicaci6n preliminar entre el cliente y el desarroUador.

7,2.2

Obtencion
0

En verdad parece muy simple preguntarle al cliente, a los usuarios y olros interesados cuales son los objetivos para el sistema producto, que es 10 que se debe lograr, de que forma el producto satisface las neeesidades del negocio y por ultimo c6mo se utilizara el sistema 0 producto dia a dia. Pero no es simple, es muy difiei!. Christel y Kang (CRI92] identifican una serie de problemas que ayudan a entender por que es ditkil la obtenci6n de requisitos:

c.-,re.der (on
...... Ioqu
..,. tI dienl.?
2

Problemas de ambito. EI limite del sistema esta mal definido 0 los clientes/usuarios especifican detalles tecnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos generales del sistema.
Si se va a construir un sistema basado en compuladora, Ial> discusiones comienzan con la ingenieria del sistema, una activldad que definll" la visi6n global y la visiOn de dommio para el sistema (ca pitulo6) 3
Los leclores del capitulo 3 recordaran que el proceso unificado define una "fase de inicio" mas com-

piela, la cual inc1uye las tareas de inlCio, obteru:i6n yelaboraci6n tal como se examinan en este capitulo

,
Problemas d e comprensi6 n. Los clientes/ u5uarios no esttm seguros por completo de que es 10 que se necesita, comprenden poco acerca de las capa cidades y Iimitaciones de su ambiente de c6mputo, no comprenden del todo

el dominic del problema , tienen dificultades al comunicar necesidades al ingeniero de sistemas, amiten informaci6n que consideran "obvia especi fican requisitos que chocan con las necesidades de atms clientes/ usuarios, 0 especifican requisitos ambiguos 0 inestables .
H ,

Problemas de volatilidad. los problemas cambian canfaone transcurre eJ

tiempo.

Para ayudar a superar estos problemas, los ingenieros de requisitos deben realizar
en forma organizada la actividad de recopilaci6n de requisitos.

7.2.3 Elaboracioo
La informaci6n conseguida con el cliente durante el inicio y la obtenci6n se expan-

de y se retina durante la elaborad6n. Esta actividad de Ia ingenierla de requisitos se enfoca en el desarrollo de un modelo tecnico refinado de las funciones, caracteristicas y restricciones del software.
La elaboraci6n es una acci6n del modelado del analisis (capitulo 8) y se compone de una serie de tareas de modelado y refinamiento. La elaboraci6n se conduce

mediante la creaci6n y el refinamiento de escenarios del usuario que describen la forma en que el usuario final (y otros actores) interactuaran con el sistema Cada escenaric del usuario se analiza para obtener clases de anAiisis: entidade5 det domlnio de negocios visibles para el usuario final Se definen los atributos de cada dase de analisis y se identifican los servidc$ que requlere cada c1ase. se identifican las relaciones y la colaboracl6n entre las (lases y se produce una varledad de Qia~rama5 de UML complementarios. EI resultado final de la elaboraci6n es un modelo de analisis que defi ne el dominic de la informaci6n, las fun(iones y eJ componamienlO del problema .

INFORMACI6N

Modelado del

cm6l.i.sis
op5cociona (w fobricomt, modeIo, nUmero y dimenllionesl. o.sp,es !Ie podrion e'PfICificor los cooll,apoo_ flomit.odo, granito, flkitMml, uniones de pIomeria, pisos y los Mchos. EsIc lim podria constiluir una especlficoci6n Uti!. pero no proporciono un modeIo de 10 que HI deMo. Poro c-ompIetor eI modeIo se podrfa crear
uno....,.--kIci6n tridimensional que mueslre 10 posici6n

Sup6ngaHi par un rnornento CfIe es nec:MOtio

especificor todos los requiWios para Ia de IXIO cocino gournw:t. Se conocen 1m 10 ubicoci6n de los puettol y
en 10 pared. completo 10 que !Ie va 0 construir de Iodos los gobinetes Y

~mbien

sc utilizan kls tenninos opt:rrJOOflCS y~.

de los gabinetes y op!icaciones y los reb:iones enlre ellos. A porlir del modeto, serio mO' f6c;18Y01uar 10 eficiencio

dol Aujo de trobajo (..... requi$ilo poro todoslos coc;nos), y 10 opariencia esretico del soI6n (un requisijo personal, pero
muy importcnte.) Los mocIeIos de analisis se conslruyen po!" una raz6n muy porecida a 10 del desarrollo de un plana de trabajo 0

una ~toci6n tridimensional para eI tow de 10 cocina. Es importonle evoluor coda oomponente del s;s!emo en relod6n ron 6 oIrO$. Eslo permite determiner c6mo encojon los requisites en esta visi6n y evaluar Ie e~ del sistema como he sida coocebido.

7.2.4 Negociac16n
Dados los recursos limitados del negocio, no resulla inusual que los clientes y usua~ rios pidan mas de 10 que se puede lograL Tambien es relativamente comun que diferentes clientes 0 usuarios propongan requisitos que entran en conllicto entre si al argumentar que su versi6n es ~ese ncial para nuestras necesidades especiales".

--............."
los ........
~

&1l1li negoOOOOtJ

e/iaz ., debe .".,

~ sa sotiIicD II!
"bfp" (00 /lJ que /as

El ingeniero de requisitos debe conciliar estos conllictos por media de un procesa de negociaci6n. Se pide a los clientes, usuarios y otros interesados que ordenen sus requisitos y despues discutan los conflictos relacionados con la priori dad. ~ identifican y analizan los riesgos asociados con cada requisito (para obtener mas detalles vease el capitulo 25). Se hacen "estimaciones" preliminares del esfuerzo requerido para su desarrollo y desputs se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el Hempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan, combinan 0 modifican de forma que cada parte a\cance derto grado de satisracci6n.
7 .2 .5 Espec1ficacion

C~VE la foordOxI y eI _do""

.~

En el contexto de los sistemas basados en computadora (y en software). el termino especificaci6n tiene signilicados diferentes para personas distintas. Una especificaci6n puede ser un documento escrito, un conjunto de modelos graficos, un modele matematico formal, una colecci6n de escenarios de usa, un prototipo 0 cualquier combinacion de estos.

-.

I!pI(imm moo con elltImcI'Io V10

",,"*"dO
KIfIwIn ~ sa \'Il 0

Algunos sugieren que para una especificaci6n se debe desarrollar y utilizar una "plantilla esLindar" [SOM97) argumentan que esto conduce a que los requisitos sean presentados de una manera mas consistente y por ende mas entendible. Sin embargo, algunas veces es necesario ser flexible mientras se desarrolla una especificaci6n. Respecto de sistemas grandes el mejor enfoque podria ser un documento escrito que combinara descripciones en ellenguaje natural y modelos graficos. Por otro lado, en cuanto a productos a sistemas mas pequeilos, podria ser que no se necesite mas que escenarios de uso, cuando dichos sistemas residan en ambientes tecnicos que se comprendan bien.
La especificacion es el producto de trabajo final que genera la ingenieria de requisitos. SilVe como base para las actividades de ingenieria de software subsecuentes.

161

Describe la funci6n y el desempeno de un sistema basado en computadora y las restricdanes que regiran su desarrollo.

7.2.6 Valldac16n
La calidad de los productos de tTabaja procedentes de la ingeniena de requisitos se

evalUa durante un paso de validad6n. La validad6n de requisitos examina la especificaci6n 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 estos han side corregidos, y que los productos de tTabaja cumplen con los estanda-

res establecidos para el proceso, proyecto y produclo.

El mecanismo primario para la validaci6n de requisitos es la revisi6n tecnica formal (capitulo 26). El equipo de revisi6n que valida los requisitos incluye ingenieros de software. clientes. usuarios y otTOS mteresados que examinan la especificaci6n y buscan errores en el contenido 0 la interpretaci6n, areas que tal vez requleran una clarificaci6n, infonnaci6n faltante, inconsistendas (que es un problema importante cuando se desarrollan productos
0

sistemas grandes) . conflictos entre los requisitos,

o requi sitos irreales (inaicanzables) .

IJsta de verlticad6n para la vaUdad6n de requ1s1tos Con frecuencio rewito Util exominor coda tEl requisito se puede probor' Sf el osi, 2!>e pueden r.qui~to fTenll a una wOe de ~b, ... e5pKificor- los pruebos (algunos YeCM IIomodos cnterias Wo de verificociOn. Enseguido HI present UfI de yolidociOn) pora ';ercitor III .-.quisitof
los preguntol que deben
~~k>5 esI6n estahIecidos de

manero claro'

tEl requisilo M roslnloble paro cualquier modeIo de lilNoma que hoyo sid.> creodo. tEl ~sito ft roMnlobIo poro Io~ objetiv03 gcncrob

/:*a pudn molinleopi eIoi ~

"-w del requililo (per ejempIo, una persona, uno ...,&oci6n 0 un reglornentol e$t6 identificoda. tEl _Iciodo fino! del requisitro he lido exominodo per 10
__ original 0 corropoI6I MWo COfI . .
jJ..-.,..isflo eW rmhingido en tinnil"ll cuonti~'

del )jemo 0

ala e!pKificoci6n ~ estrucruroda de uno forma que conduzco 0 IoU comprenliOn, ...r.,.....,;o y "oci""",:&. rocil ... prodI.ot;tol de trobojo m6slknic05f

ts- he. CROdo ~ irw::lice porn 10 especificoci6nf

al,o, requi~ik>5 a~iados con eI rendimienlo, eI desempeiio y Io! corocIeri!ticm operacionole! se han

otros requi~ e$lUn relacionodos con tiIet ~ regiltrodos de monenl daro por medio de uno -*tz de refet-encios cnJzodas u oro ~~ ;J ..quisito viola o~ rwricci6n del dominio del

eskJbIecido de IT"IOI'"III(Q claro? tCu6~ requisik>5

poI**I set"

-...

imp!kd01?

7.2.7 Gesti6n de requisites

En el capitulo 6 se estableci6 que los requisitos para los sistemas basados en computadoras cambian y que el deseo de cambiarlos persiste durante la vida del sistema.

La gesti6n de requisitos es un conjunto de actividades que ayudan al equipo de proyecto a identificar. controlar y rastrear los requisit05 y 105 l;ambio:5 a blO~ en ('uDI-

,.2

PARTE DOS

PRAcncA. DE LA ~ DEl. SOf"IWARE

quier momento mientras

sc: desarrolla el proyecto. s Muchas de estas actividades

identicas a las acUvidades de 1a gesti6n de la configuraci6n del software (GCS) qlk

se tratan en el capitulo 27.

La gesti6n de requisitos comienza con la identificacion . cada requerimiento

asigna a un solo identificador. Una vez identificados los requisitos se desarrollan tablas de rastreabilidad. En la figura 7. 1 se muestra de manera esquematica un& tabla de rastreabilidad, cada una de elias relaciona los requisitos con uno 0 mas aspectos del sistema 0 de su ambiente. Entre las muchas tablas de rastreabilidali.
posibles estiin las siguientes:

Tabla de rastreabilidad de las caracterlsticas. Muestra la manera en que I

Ci.K1lldo un sistema es

requisitos se relacionan con las caracteristicas del sistema/producto observables para el cliente, 11lbla de rastreabUidad de la fuente. Jdentifica la fuente de cada requisito. Tabla de rastreabilidad de dependencia. Indica la forma en que los requisitos e~tan relacionados entre sL Tabla de rastreabilidad del $ubsistema. Estabiece categorias entre los reqwsitos de acuerdo can el(los) subsistema(s) que gobierna(n). Tabla de rastreabilidad de la interfaz. Muestra la forma en que los requisitos se relacionan con las interfases intemas 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 buscarseles can rapidez para entender c6mo el cambia en un requisito afectara diferentes aspectos del sistema que se construira.

.... Y'''"''''', determinociOO da las

rooe.!ionfs trltrt los

fS(1,tiIrK twie ~

"" "" "h.<IJe, 56 Iomienda eluso

dsm~d&~

biiiOOd (WI foditrx I.fl

,",' 0/ ".,.,

Tabla

generlca de
rastreabWclacl.
Requisilo

Aspecto espec;ific:o del $istemo

su ombienle

AI

1101

102
103

1 05

....
5

La gcsti6n ronnal de requisitos se inicia $610 para proyc:ctos grarnks. los cuales tienen cientos de reo
quisitos identifiables_ En los pro~os pequei\os esta funci6n de la ingenieria de requisitos es bastante menos fonnaL

163

Ingenleria de requ1s1tos
Objetivo: uu henomienkn. de 10 ingenierio de ~ 10 recopiloci6n, de requiiikn..
especifico del proyecto que c.onli_ OeKripciones y otribulos detoIlodos de los requililos.

::~~:~..~m:_:':"'~Ed.

prooISO del ~.

1mingenierio de 10

herramientos one Per 10

requi~105

de mocIeIos gr61ko5 (por UMlI que mue51ron los o~ de informoci6n,

OnYOOJrMartt Pro, desarroIlodo per OmniV.w Iwww.omni-viskl.com), ccn~ uno base de datos de los requililos, ewblece reIociooes 8I'Itre ~Ios, y perrnile a los uworios onaliror 10 reIoci6n enln! los requisilos y los colendarQ/anlo5.
RotionolRequilitePro, de~1odo po!" Rarionol Softwore
( _ rational.com), permite a los uwarios cborrollor uno bose de datos de los requisim, represenla los ,eb:iona entre estos Yb. organize, priorizc y ro5trea.

~:::-;;::~j tomportomiento de un !illemo. E$Ios boWl poI'CI bdos las oIn;Is octividodM
"~mi_I".

representatNa.

Sy$lenu Guide, Inc::. ha preporodo ~ lim herramienhJs pora 10 6W w puede enconlfor . . ::::~:;:::::

a .xWudu de requisito!. !Ie ~ en .I CClpI1uIo B

la,cal.LIas que MI ~ 0 c:ontinuociOn se ., Ia gtM6n de r.quililos.

'_.~ild.c;omJGui\d$iIe/Robs/tWooI5.

RTM, Oe.orroIkxIo par Integrtrled o,ipwore (www.chipwore.com). ISS uno herromionlc poro 10 descripci6n y roweob;lOdod 0. ,*!ui,ito. q ..... tomb;", soporIa ciartos o~ del tontrol del cambio y

...... de~. pruoba..

Se o.b. hoc. nokJr que muchas 10,." de 10 geUi6n de r.quilitos WI puedeo rea/izor c.on uno simple hoia de mIcuIo 0 un lidema peqvei'io poro eI monejo de basos dedato.

d.orroIIodo per cybemetic Inteligera: GMBH ......... eo~rm.com), c.on~ un diccionorio/glosario

En un escenario ideal, los clientes y los ingenieros de software trabajan juntos en el mismo equipo_7 En tales casos, la ingenieria de requisitos se trata 5610 de guiar con versacianes significallvas con colegas que son miembros bien canocidos del equipo Sin embargo, en la reaHdad a menudo es bastante diferentc. Los clientes pueden estar en una eiudad 0 pals diferente, pueden tener ;)(')10 uno idea vaga de 10 que se requiere, ta1 vez tengan opinianes connictivas ace rca del sistema que se construirn, quiza SU cOIlocimiento tecnlco sea limltado y tengan un tlempo limitado para interactuar con eJ ingeniero de requisitos. Ninguna de cstas situaciom:::; es deseable, pera son muycomunes, yet equipo de software can frecuencia se ve obli gada a trabajar demro de las restricciones que Impone esta situacl0n En las seccianes siguientes se examinan los pasos requeridos para inidar Ja ingeniena de requisitos; es decir, para comenzar un proyecto de forma que se mantenga en mavimiento hada una soluci6n exitosa

Las ~nam!t!nta5 rJl(!OCionadas aqui son una muestra denim dt! t!51a calegoria En la mayoria dt! los casos los nombres estan reglStrados por sus respectlVOS cksanoUadort!S 7 ESle enfoque se recoml(!nda pan! lodes los proyectos Y eo; una parte !nt~al de La filosofia para el desanollo igil &, software

164

PARTE DOS

~ DE LA INGENlllIiA 00. SOFtWARE

7.3.1 Identificacion de los interesados

Sommerville y Sawyer ISOM971 definen a los interesados como "tOOos aquellos se benefician en una forma directa 0 indirecta del sistema que esta en desarrollo Va se ha identificado a los sospechosos usuales: gerentes de operaciones de negc. cios, gerentes de producto, genie de mercadotecnia, ciientes internos y extertlO( usuarios finales, consullores, ingenieros de producto, ingenieros de software. inge-

I..kl inl6fesodo es (oolquiera qJe JKIIli<ipa!Jo1 fmoo (jrec:tu ell eI sisteIoo

..,.. a descrrallor uobtiene benelicios de este.

IJ.)e se

nieros de soporte y mantenimiento y alros. cada interesado liene una visi6n diferente del sistema, obliene beneficios diferentes cuando este se desarrolla de manera
exitosa, y esta abierto a diferentes riesgos si el esfuerzo de desarrollo llegara a fal1M En el inicio el ingeniero de requisitos puede crear una lisla de personas que COl' tribuiran durante la obtend6n de requisitos (secd6n 7.4). La lista inidal crecera COl' forme se eSlablezca contaclo con los inleresados. ya que a cada uno de ellos se It preguntara: ~ iCOn quifn mas piensa que deberia hablar?"

1.3.2 Reconoctmtento de mUltiples puntos de vista

Debido a que existen muchos clientes diferentes. los requisitos del sistema se expk>Tarim desde diversos puntos de vista. Por ejemplo, el grupo de mercadotecnia eSUI interesado en fundones y caracteristicas que estimulen al mercado potencial, q..r hagan que el nuevo sistema sea fadl de vender. Los gerentes de negocios estan interesados en un grupo de caracteristicas que se puedan conslruir sin rebasar un presupuesto y que estfn Hstas para lIegar a nkhos de mercado definidos. Los usuarios finales pueden desear caracteristicas con las que esten familiarizados y sean facites de aprender y utilizar. Los ingenieros de software quiza esten interesados en fW1dones que den el soporte de la infraestructura y caracteristicas mas accesibles al mercado. los ingenieros de soporte se pueden enfocar en la facilidad de manterumiento del software.
11m . . . 15IIIos en Il1O WitaciDn y pregUnteles ."e jpo . . . . . . apiIicIII5 dRnntts-

-w...

w.m. quinn. fs ".........

Cada uno de estos componentes (y otros) propordonarim infonnaci6n al proceso de la ingenieria de requisitos. COnforme se recopila infonnaci6n desde multiples puntos de vista, los requisitos que surjan pueden ser inconsistentes 0 entrar en conflklo con alglin otro. EI trabajo del ingeniero de requisitos es categorizar lada la informaci6n de los interesados (incluidos los requisitos inconsistentes y conflktiv~ en una forma que permita a quienes tomen la decisiones elegir un conjunto de requisitos para eI sistema que sean consistentes de manera inlema.

7.3.3 Trabajo con respecto a la colaborac1on

En los capitulos previos se ha mendon ado que los clientes (y otros inleresados) deberian colaborar entre si (evitando peleas insignificantes) y con los profesionales

cAPiTuLo 7

I~ DE REQIJISIl'ai

165

de la ingenieria del sotlware si se desea obtener un sistema exitoso. Pero, l.como se logra esta eolaboraci6n? El trabajo del ingeniero de requisitos es identificar areas en comun (es decir, los requisitos en los que todos los interesados estim de acuerdo) y areas de eonnieto 0 inconsistencia (esto es, los requisitos solicitados por un interesado que entran en eonnicto con las necesidades de otro) . Esta es, por supuesto, la ultima categoria que presenta un desafio.

Ut1JJzaclon de los ""puntos de pnoridad" 1kIo forma de ~ los conflidos entre (desde su puntro de vistro) 01 osignone uno 0 m6s punlcs de prioridod. los puntros osignados no $e poeden revtilizar. Uno vez que 10$ punkn de prioridod del interesodo se hon ogoIodo, dicho penono no puede realizer ninguno olro occiOn 50bre los requisilos. los puntos IotaIes que osignen
o coda requisitro todos los interesodos indicon 10 importoncio generoI de coda requisilo.

La colaboraci6n no significa, necesariamente, que los requisitos se definan por consenso. En muchos casos, los interesados colaboran al proporcionar Sll visi6n de los requisilos, pero un fuerte "campe6n de proyecto" (por ejemplo, un gerenle de nego-

cios a un tecnico importante) puede tomar la decisi6n final acerca de cuales requisitos se aceptan .

7.3.4 Formulacion de las prtmeras preguntas

En este capitulo se ha destacado que las preguntas fonnuladas al inicio del proyecto deben ser "libres de contexto" [GAU89J. El primer conjunto de preguntas libres de contexto se enfoca en el eliente y Olras interesados, metas generales y en lOS Oenefieios. Por ejemplo, el ingeniero de requisitos podria preguntar: iQuien esta detr<is de la solicitud de este trabajo? .:.QuU~n usara la soluci6n? l.Cual sera el beneficia eeon6mico de una soluci6n exitosa? l.Existe otra fuenle para la soluci6n requerida? Estas preguntas ayudan a identifiear a lodos los partieipantes que tendrlan inte-

res en el sotlware que sera conslruido. Ademas, estas preguntas identifiean el beneficio medible de una implementaci6n exitosa y las altemativas posibles para personalizar el desarrollo del software.

--"'l

1M
La

siguiente serie de preguntas permite que el equipo de software co,np,er"

meior c::1 prOblema y deja Que eJ cliente exprese sus percepciones acerca de una cion:

Lboles nil

.........
II proWe.a?

las prtglln,., ",ay_ a

iC6mo podrla caracterizarse un buen resultado generado por una soluci6n exitosa?

iCuales problemas deberia atacar esta soluci6n? ;.Podria usted describir 0 mostrar el ambieote de negocios en e l que se
utilizara la soluci6n?
iLos aspectos especiaJes del desempei'lo 0 las restricciones afectaran la form

,.... pr. . . .

en que se busque la soluci6n?

La serie final de preguntas se enfoca en la erectividad de la actividad de comun

ca.ci6n en SI misma. Gause y Weinberg IGAU89j las lIaman las

"metapreguntas~

propanen la slguieme lista abreviada:

;.Es usted la persona adecuada para contestar esta pregunla? iSUS respuestas

son "oficiales"?
iMis preguntas son relevantes para su problema? iEslOY haciendo demasiadas pregunlaS? iAlguien mas puede proporcionar informacion adicional? iDeberia preguntarle alguna otra cosa'

, eique no pr'!lllm IS III JoIfO .... ..,.,.-

::....

Eslas preguntas (y otras) ayudaran a "'romper el hielo" y a inidar la conversaci6r esencia[ para la obtenci6n exitosa. Pero un formata de reuni6n de pregunta y respuesta no es un enfoque que haya sido exilose de manera contundente. De hecho la sesi6n de preguntas y respuestas se debe usar s6lo para el primer encuentro, , despues se debe reemplazar por un formato de obtenci6n de requisitos que combine elementos de reso[uci6n de problemas, negociaci6n y especificaci6n En la sec ci6n 7.4 se presenta un enfoque de este tipo

7.4

OltgCIQ. pi 1181"110$
El (armata de pregunta y respuesta descrilo en la secci6n 7.3.4 es util en la etapa ini dal, pero no es un enfoque que haya sida exitoso de manera decisiva para una obtencion de requisitos mas detallada; de hecho, la sesi6n de preguntas y respues las se debe usar s6[0 para el primer encuentro y despues se debe reemplazar por un forma ta de obtenci6n de requisitos que combine elementos de la resoluci6n, elaboracion. ncgociaci6n y especificaci6n del problema. En la siguiente secci6n se pre senta un enfoque de este tipo.

cAPinn.o 1

INGtNIERIA DE REQI1lSJTOS

167

7.4.1 Recop1laden conJunta de requisitos

CUando se desea estimular un esfuerzo conjunto y orientado al equipo de recopilaci6n de requisitos. un equipo de participantes y desarroltadores trabajan juntos para identificar el problema, propaner elementos de soluci6n, negociar diferentes enroques y espedficar un conjunto preliminar de requisitos para la soluci6n (ZAH90].'

Se han propuestos muchos y diferentes enfoques para la recopilaci6n conjunta de

requisitos. cada uno utiliza un escenario muy diferente, perc todos aplican alguna

variaci6n de las siguientes directrices Mslcas:

Las reuniones las dirige alguno de los asistentes, ya sea un ingeniero de

sonware 0 un cliente (junto con OITOS participantes interesadosj.

........ -........
i
,

Se establecen reglas para \a preparaci6n y la participaci6n.

se sugiere una agenda que sea tan fonnal como para cubnr lodos los puntas
importantes, pero tan informal como para estimutar el fluio de ideas Un moderador (puede ser un cliente. un desarrollador a un agente external controla la reuni6n.

Me . .

'

se utiliza un "mecanismo de delinici6n

un foro virtual) .

(pueden ser hojas de tTabaja,

graficos. hojas adheribles. un tablero electrOnico, un mensajero electr6nico a

La meta es identificar el problema, proponer elementos de soluci6n, negociar

diferentes enfoques y espedlicar un conjunlo de requisitos de solud6n preliminares en una atm6sf"era que conduzca aI cumphmiento de la meta Para entender mejor el flujo de los eventos (confonne estos ocurren), se presenta un escenario breve que describe la secuencia de eventos que conducen a la reuni6n para la recopilaci6n de requisitos y que ocurren durante la reuni6n y despues de esta.

~ 1I.ho ........ -rwiI rHI esfueno del

,,do-" a Ia im.,lememaci6n ni a las prueIIas,'"

..... Odir '" II "

' " Y 'III

a a.sInIi"."

--

Durante Ja fase de inido (secci6n 7.3). las preguntas y respuestas basicas establecen el ambito del problema y la percepci6n global de una soluci6n. Fuera de estas reuniones inidales, los partidpantes escriben una "solicitud de produclo" de una a dos paginas. Se tijan un lugar, una hora y una fecha para la reuni6n y se selecciona un moderador. Los miembros del equipo de software y otras organizadones intere-

8 A esle enfoque se Ie llama algunas veces teatica de espea:rlCild6n factlltada de Ia aplicaci6 n (FAST. por sus Slglas en inglb)

..

PARTE DOS

I'RAC'ocA DE LA!NGENnlllA. rn SCf'TWARE

sadas son invitados a asistir. La solicttud de producto se distribuye a lod05 los asis tentes antes de la fecha de reuni6n. Mientras revisa la solicitud de producto en los dlas previos a la reuni6n, se pide a
_ _ (JAIl,

cada asistente hacer una lista de objelos que son parte del ambiente que rodea al sis-

porlUS ~as .. tIad

-' 111.-..
........... _ 1.,1 t_
~. ISla 1ioiaI_

......... _do

tema, alros objetos que este producirA, y objelos que uliJiza para realizar sus fun ciones. Ademas, se Ie pide a cada asistente que elabore una lisla de los servlclos (procesos 0 funciones) que manipulan 0 interacluan con los objetos. Por ultimo. tamblen se preparan Iistas de las restricciones (por ejemplo, cosio, tamana. reglas del negocio) y de los critenos de rendimiento (pOT ejemplo, velocidad, exactitud) . Sc: infonna a los asistentes que no se espera que las listas sean exhaustivas, sino que reflejen la percepci6n que cada persona liene del sistema . Como un ejemplo,' considerese el fragmento de un documento previo a la reuni6n, escrito par una persona de mercadotecnia involucrada en el proyecto de HogarSeguro. Esta persona escribe la siguiente narraci6n acerca de la funci6n de seguridad en el hagar que sera parte de HogarSeguro_
Nuesl:ra investigaci6n indica que eI mercado para los Sistemas de administrad6n del ho-gar esta creciendo a una tasa de 40 por denio anual La primera funci6n de Hoga~uro que saquemos al mercado deberia seT la funoon de seguridad en el hagar La mayolia de la gente esta familiarizada con los ~sistemas de alanna-, por 10 que dicha funci6n selia facil de vender La funci6n de quridad en el hagar proteger1a contra 0 reconoceria una variedad de -situaciones- indeseables como una entrada ilegal, fuego, inundaciones. niveles de mon6xido de carbona y otras. Utillzara nuestros sensores inalambricos para detectar cada sltuad6n, el usuario podra programarla y llamara poT telefono automaticamente a una olicina de monitoreo cuanda deleae alguna situad6n

51 "" SISIMWI 0 (1Wkto seni6 D

tooehos USluios Sf

dobo ....
..... ,..moId.
~ los ,.". sa o/:JtitrwJ de 4fIG

/IlU6SIIlI mrxltSMllr11M:! de /os USlOios. Si

s6Ia IBl de /as

IlIIIlils dm td:Is

1m..,..." nesgo de ffCiruo IS

"""

En realidad, atros podrian contribuir a este relato durante la reuni6n para la recopilaci6n de requisitos, y mucha mas infonnad6n estaria disponible. Pero aun con infonnaci6n adicional, la ambigOedad podria estar presente, es probable que exis~ tieran omisiones y podrian ocurrir errores. Por ahora, la -descripci6n funeional" anterior sera. sufidente. EI equipo de recopilaci6n de requisitos 10 componen representantes de los departamentos de mercadotecnia. de ingenieria de hardware y software y de manufactura. Se utilizara un moderador extemo. cada persona desarrolla las Iistas previa mente descritas. Los objetos descritos para HogarStguro podrian induir el panel de control. los detectores de humo, los sensores en puertas y ventanas, los detectores de movimiento. una alanna, un evento (cuando algun .sensor se active) , una pantalla. una PC, numeros telef6nieos, una

9 El ejemplo de Hogo~!Jro (con extensiones y vanaciones) 5e utihza para ilustrar metodos importantes de Ia in~nielia del sonware en muchos de los capitulos que siguen. COmo ejercicio, selia uti! realizar una reuni6n para la recopilaci6n de requisltos propia y desarrollar una serie de hSt3S para

..

cAPiTuLo 7

!NGENIERlA DE I!EQl1lSITOS

'69

Hamada telef6nica yotros_ La lista de servicios podria incluir la configuracion del sistema, la colocad6n de la alanna, el monilota) de sensores, la marcacion telef6nica, la programaci6n del panel de control y la JtXlUro de pantalla (observese que los servicios actCtan sobre los objetos). De una manera similar, cada asistenle elaborara listas de restricciones (por ejemplo, el sistema debe reconocer cuando los sensores no esten en funcionamiento, debe ser amigable para el usuario, debe tener una interfaz directa con la linea telef6nical y criterios de rendimiento (por ejemplo, el evento de un sensor debe ser reconocido en un segundo 0 menos; se debe imp[ementar un esquema para la prioridad de los eventos) .

-.....,
CUando se inicia la reun16n para la recopilaci6n de documentos, el primer t6pico que se trata es la nesesidad y la justificaci6n para el nuevo producto, lodos deben estar de acuerdo en que la necesidad del producto se justifica. Una vez establecido el acuerdo, cada partidpante presenta sus listas para examinarlas. Las lislas pueden fijarse en las paredes del sa16n usando hojas grandes de papel, pegarse en los muros mediante hojas adhesivas 0 escribirse en un pizarr6n . De manera altemativa. las listas pueden haber side colocadas en un boletln electronico. en un siUo Web interno. o situadas dentro de un ambienle de foro de discusi6n (chat room) para revisarlas antes de la reuni6n. En forma ideal. cada asunto en la lisla debe permitir manipularse por separado para que las listas se puedan combinar, los asuntos puedan borrarse y se les puedan reaJizar adiciones. En esta etapa la critica y el debate estan estrictamente prohibidos. Despues de que las listas individuales sobre el area de un t6pico se hayan presentado. el grupo crea una \isla combinada. Dicha !ista elimina los asunlos redundantes. incorpora ideas nuevas surgidas durante el debate. pero no borra nada. Despues de haberse creado las lislas combinadas para todas las areas de los distinlos 1 6picos. el moderador coordina el debate La 1ista combinada se reduce, se incrementa 0 replantea para renejar de manera apropiada e[ producto/sistema que se desarrollara. EI objetivo es desarrol1ar una lisla consensada en el area de cada t6pico (objetos, servicios. restricciones y rendimiento). Despues dichas listas se inte gran para 1a acci6n posterior. Cuando se completan las listas consesadas. el equipo se divide en subequipos menores; cada uno trabaJa para desarrolJar miniespecificodones para uno 0 mas asuntos de cada una de las listas. IO Cada miniespecificaci6n es una explicaci6n concisa de la palabra 0 frase contenida en 1a !ista Por ejemplo, la miniespecificaci6n para el objeto Panel de control de HogarSeguro podria ser:

10 En lugar de crear miniespecificaclones, muchos ~ulp05 de soI\ware eHgen desarroHar escenarlos del usuario lIamados casos de uso. $los se oonskkran con detalle en la secc)6n 7.5.

170

El Panel de control es una unidad empotrada en la pared con un lamallo aproximado de 9 x 5 pulgadas. EI panel de control Ijene conexi6n inalambrica con los sensores y una PC. La Lnteraccl6n con eJ usuario ocurre por media de un tablero de 12 tedas. Una panlalla LCD de 2 x 2 pulgadas proporciona Ia retroalimcntaci6n del usuario. EI software provee

sugerendas e Imagenes interactivas y funciones sunilares_

Despues, cada subequipo presenta sus miniespecificadones a tcx10s los asi.st,'nu.> para comentarlas. se realizan las adiciones, anulaciones y elaboraciones postenc res. En algunos casos, el desarrollo de las miniespecificaciones descubrira nue requisitos de objetos, servicios, restricciones y rendimiento que se agregaran a
listas originales. Durante los debates el equipo encontrarti algun asunto que
pueda resolverse durante 1a reuni6n. Se mantendrti una Usta de asuntos pendien para que despues se pueda acluar sobre estas ideas. Oespues de completar las miniespecificaciones, cada asistente hace una lista criterios de validaci6n para el producto/sistema y la presenta at equipa. Enlances crea una lista cansensada de criterios de validaci6n. Por ultimo, uno 0 mas part pantes (0 agentes extemos) redben el encargo de escribir las especificaciones c pletas mediante eJ usa de todas los asuntos tratados en la reuni6n .

......... II I....... AI
~;nco. ~.

IfIiIIfIIbro del ecppo de

. ~ del equipo de
del equipo d. software; cW ecppo de toItwore; Ires
~

no~..,Iror" Jamia: m~ 0 hao. oIgo_

II '
"..

..... d

ad

_,..10 ""'''" do ~ ~. hog<r

.. r J

.i.
5

fa"

~)'

II

"'' '.._ode.

I'e$f)OI"Im1idod .-.cae en IIOIOin)I.

...... /Juy ""'"

~~~':~~:~i;=
,-.......,.

. _ ' .... _obI ... de

,., II. . . . . . . . . pbarNn ~ 611a.1o l,da odIIaI de ol:t,etos)'

..." ,

MercaJ,IscNa: Perc CMI aM... , . . . . . con.:tMdod por~. t6Io Si c_ ....... que C\IIlIquier inIrwo ..... Ed: Es m6s f6ci1 deciflo ~ . . . . '/..
~O$OJntoonoro_

o.de nueslfa ......... _""" ........... 10 I...cion

...

_.....
hog<r I

AnotoImo. . . . _

... ......
.....

. . . . "... ....oc..o ~ los usuarios quwion todo

.. P... ,
'

:A.III.~acce:.ibleporlmDrneP.

debe reoIi:zorse Y oontinuwtIOI.. 1Ooog. .............._do 10 _

anoIoci6n ~,l

....

Do _10 " ' - do ~ ~ 01 hog<r. I"'"

0'= ....... luncionoIidod y 105 objetos

,.

n c al...:llcSi corredo ..

M,Jo... SieNo~oUnhay_.,..,. coo,ideror oqul

(a grupo u!iI'zo!os ~.c.5 ............. , expondir los d.taII.s de 10 funci6n.. ., , _ II

_r.

,,'

"!flo ~ 0Qn9J o&euno$

cAPiTtn.o 7
7.4.2

1NGEN1ERlA. DE REQtnSlTOS

171

DespUegue de 10 funclan de caUdad

EI despliegue de fa fund6n de calidad (QFD, por sus siglas en ingles) es una tecnica que traduce las necesidades del cliente en requisitos tecnicos para el software EI QFD ~se concentra en aumentar la satisfacci6n del cHente desde el praceso de la ingenierla del software (ZUL921.~ Para lograr 10 anterior, el QFD resalta una comprensi6n de 10 que es valioso para el cliente y despues despliega estos valores durante el proceso de ingenieJia EI QFD identifica tres tipos de requisitos [ZUL92]: Requisltos nonnales. Renejan los objetivos y metas establecidos para un producto 0 sistema durante las reuniones con el cHenle. Si estos requisitos estan presenles, el cliente estara satisfecho. Algunos ejemplos de requisitos normales podrian ser los tipos de graficos en pantalla, las funciones especfficas del sistema, y los niveles de rendimiento solicitados. Requisitos esperados. .stan implicitos en el producto 0 sistema y pueden parecer tan obvios, aunque son fundamentales, que el cliente no los establece de manera expllcita. So ausencia causarta una insatisfacci6n significativa. Algunos ejemplos de requisltos esperados son la facilidad de la interacci6n humano/milquina, correcci6n y confiabilidad operacional general y facilidad en la instalad6n del software. Requlsitos estimuJantes. Reflejan las caracterlsticas que van mas alia de las expectativas del clienle y que prueban ser muy satisfactorias cuando estan presentes. Por ejemplo, un software procesador de palabras se solicita con caracteristicas estandar. EI producto entregado contiene varias capacidades de configuraci6n de pagina que son bastante satisfactorias e inesperadas. En la actualidad, el QFD abarca 1a totalidad del proceso de ingenieria [PAR96] , Sin embargo, muchas conceplos del QFD son aplicables a 1a actividad de obtenci6n de requisitos. En los parrafos siguientes se presenla una visi6n general de dichos conceptos (adaptadOS para el software de computadoral .

. . . . . . . . . . . 111 ' . .... ' . . . . 111 . . . . . , ......

En las reuniones con el clienle, la fimci6n de despliegue se aplica para determinar el valor de cada funci6n que se requiere para el sistema. EI despliegue de 10 in!ormad6n identifica los datos de los objetos y eventos que debe consumir y producir el sistema. Los datos eslan ligados a las fundones. Por ultimo, el despliegue de tareos examina el comportamiento del sistema 0 producto dentro del contexto de su entomo, EI analisis de valor se realiza para determinar la prioridad relatlva de los requisitos determinadas durante cada uno de los tres despliegues. El QFD utiliza entrevistas y observaci6n del cliente, sondeos y exploraci6n de los datos hist6ricos (por ejemplo. los reportes de problemas) como datos crudos para la actividad de recopilad6n de requisitos. Despues, estos datos se traducen en una

72

PARTE DOS

PrU\cncA [)[ LA INGDIIDllA DEl. SOfiWARE

tabla de requisitos -Hamada la tabla de la \.-UZ del dJente- que se revisa con el clienk: Una variedad de diagramas. matrices y metodos de evaluaci6n se utiJilan para obtentt los requisitos esperados y tratar de conseguir los requisitos estimulantes [BOS91 J.

7.4 .3 Escenarios del usuarlo

Conforme se recopilan los requisitos se comienza a materializar una visi6n general de las funciones y caracteristicas del sistema. Sin embargo, resulta difkil continuar con actividades de ingenierta del software mas tecnicas mientras el equipo de software no entienda la manera en que las distintas c1ases de usuarios finales aplicaran estas funciones y caracteristicas Para lograrlo, los desarrolladores y usuarios pueden crear un canjunlo de escenarios que identifican una cadena de usa para el sistema que se va a construir. Los escenarios, lIamados con frecuencia casos de USl. VAC92], proporcionan una descripci6n de c6mo se usara el sistema. Los casos de

usa se examinan con un mayor detalle e n la secci6n 7.5.

DatzrroIJo de un escenario de uso prellmlnar

I FH _ io.: Uncuolo de

MaIl.,IIII., ,.......1"

pimIra ~ porn Ie
. . . . lamr. rn..mbro del equipo de lariat, ~ del equipo eM
eM~;

10 tuios dirrIe cOma ID .... ,

'*sona.

11

....

coso qu. necniIoricJ

~ . . -..,Hpo de

; Ires I.W\repraentontede wt-o..udur_

Introo:Lciria V .......
~~y.

o 10 u.cionalidod de par Internet. M. eI acceso 0 10

if1bmaci6n, vtnod, pero.1IaIira. en 10 forma en "'" eI UII.IIIMO

Mall.

IIbr~~:::;;:~~::~~

,do """""'" Vmod: No hoy pobla,o.

diciendo, enIr'OIia en.! id.nJi~C(I(:i6n de vworio y dot
.Jamie;

...,.......
Moll 11.,1111.,

Ii

aIwickt

Uf'I

par de fcnnas,

Io.~ Drinoa ly opri:I 0 uno persot'IO de

ols,~

F-O no OmO$ 0

una nato d.I '-"'0 Y10

Esloy segum IP ___ aIraL

' - - _ Wii : I

"Mii __ 'au_

bueno, M!o ana y tvviero que dejOr a

Hurrm.

10._.
todos la, ~ianIII. ScJ.I .... funci6n de MgUridacI WI .I
requi, que ~

173

10 penono de "...codoe.olia CDIIMo hcJbb,do, 00IJg Ioma lea naQ co.. 4 _ ... DIll-. /1Ob$ Ionnon 10 bos. paro priINr laO . . . inlonnol. 0. moneru oII.maIiva, lit II puIIo W. pecMdo 0 10 pencno ct. "...............
(MieoHros
escenor1o,

1*'0"''' haria -., . . . ...........

_.tu lee

7.4.4 Prcxtuctos de trabajo de 1a obtencton

Los productos de trabaja producidos como consecuencia de la obtenci6n de requisi-

los vanara de acuerdo con el tamana del sistema 0 producto que se vaya a conslruir
La mayoria de los sistemas incluye los siguientes productos de trabaja:

Un enunciado de necesidad y factibilidad. Un enunciado limitado del ambito del sistema 0 produClo.

Una lisla de clientes, usuarios y alros interesados que participaron en la

obtenci6n de requisites Una descripci6n del ambiente tecnico del sistema, Una ]isla de requisitos (de manera preferente organizados por funci6n) y las

restricciones de dominic aplicables a cada uno

Un conjunto de escenarios de usa que proporcionen un discemimiento de la utiHzaci6n del sistema 0 producto en diferentes condiciones de operaci6n. cualesquiera protOlipos desarrollados para definir de mejor forma los requisitos. cada uno de estos productos de trabajo los revisa tod" la gente que ha participudo en la obtencl6n de requisitos.

En un libra que analiza la manera de escribir casos de uso encaces, Alistair Cockburn [COCO I I menciona que "un case de uso captura un contrato ... (que] describe el comportamiento del sistema en diferentes condiciones mientras este responde a la petici6n de uno de sus usuaries". En esencia, un

case de usc cuenta una

historia estili-

zada de la manera en que un usuario final (el cual desempena uno de varies papeles posibles) interactua con el sistema en un conjunl o especifico de circunstancias.
La historia puede ser un texto narrative, un esquema de lareas 0 interaccianes, una

descripci6n basada en una plantilla 0 una representaci6n por media de diagramas. Sin importar su fanna, un caso de usa muestra el software 0 sistema desde el punto de vista del usuario final. EI primer paso al escribir un caso de uso consiste en definlr e\ conjunto de res" que estaran involucrados en la hisloria Los
" aClQ -

actores son las diferentes personas

174

PARTE DOS PRAcncA DE 1-' INGENIll4A DEl. SOf'TWAR

dispositivos) que utilizan el sistema 0 prooucto dentro del contexte de la funcKr y el comportamiento que se describirti. LoS actores representan los papeJes que joe(0

gan las personas (0 dispositivos) conforme el sistema opera. Definido de una ma~

fa mas formal, un actor es algun elemento que se comunica con el sistema 0 pre. ducto y que es extemo al sistema en sf mismo. cada actor tiene una 0 mas rnetas. cuando utiliza el sistema Es importante senalar que un actor y un usuario final no son necesariamente mismo. Un usuario lipico puede desempenar varios papeJes al Usaf un sistenv.. mientras que un actor representa una clase de e ntidad extema (can frecuencia, peTI"I
no siempre, una persona) que desempena 5610 un papel en el contexte del caso kuso. COmo un ejemplo, considerese aI operador de una m.i.quina (un usuario) que interactua con la computadora de control para una celula de manufactura que con tiene varios robots y maquinas de control numerico. Despues de la revisi6n cuidadosa de los requisitos, el software para la computadora de control requiere cuatrr diferentc5 modos (acto res) para su interacciOn; modo de programaci6n, modo dt prueba, modo de monitoreo y modo de resoluci6n de problemas. Por 10 tanto, sc pueden definir cuatro actores; el programador, el que realiza las pruebas, el qut" monltorea y el que resuelve los problemas. En algunos casas el operador de Ia maquina puede desempenar todos estos papeles. En otras situaciones. son personas diferentes las que pueden desempenar el papel de cada actor. Como la obtenci6n de requisitos es una actividad evolutiva, no todos los actores se identlfican durante la primera iterad6n. Durante esta es poslble identificar los actores primarios UAC921. mientras que los actores secundarios se identifican conforme se aprende mas acerca del sistema. Los actores primarios interactuan para lograr 1a funci6n requeri da del sistema y obtienen el beneficio que se espera de este Ellos lTabajan de manera directa y frecuente con el software. Los actores secundarios dan soporte a1 sistema de manera que los adores primarios puedan hacer su trabajo. Va identificados los actores pueden desarrollarse los casas de uso. Jacobson UAC92J sugiere varias pregunlas l l que se deberlan contestar mediante un caso de

,1M ..

USO .

rna.. (lUI.
1M

_.sha pwatlesa-

iQuien(es) es(son) el(los) actor(es) primario{s)? iCU.1les son las metas del actor? iCU.1les son las condiciones previas que deben existir antes de comenzar la historia? iCuales son las tareas 0 funciones principales que realiza el actor? iCuales excepdones podrian considerarse mientras se describe la historia? icuales son las variadones posibles en la interacci6n del actor?
II laS preguntas de Jacobson se han exlendido para propomonar una viSI6n mas completa del conterudo del caso de usc

tficn?

CAPiTuLo 1

INGENIRlA DE ~UISllOS

115

iCuill es la informaci6n del sistema que el actor adquirira, producira 0 cambiara?

iEI actor tendra que informar al sistema acerca de cambios en el medio

ambiente extemo? iCutd es la informaci6n que el actor desea del sistema? iEI actor quiere ser informado acerca de cambios inesperados? Como se recordara, los requisitos basicos de HogarSeguro definen tres actores: el propietario de la casa (un usuario). un administrador de la configuraci6n (probablemenle la misma persona que el propietario, pero en una funci6n diferenIe), los sensores (dispositivos agregados al sistema), y el subsistema de monitoreo (la estaci6n central que monitorea la funci6n de seguridad en el hagar donde esta instalado HogarSeguro). Para los prop6sitos de este ejemplo s610 se considera al actor propietario. tste interactUa con la funci6n de seguridad en el hogar en diferentes formas mediante el uso el panel de control de la aiarma 0 una PC Ingresa una contrasefta para permitir todas las demas interacciones. Indaga ace rca del estatus de una zona de seguridad. Indaga acerca del estatus de un sensor. Presiona el bot6n de panico en caso de emergencia. Acliva/desaetiva el sistema de seguridad. Si se eonsidera la situaei6n en \a eual el propietario utiliza el panel de control, el caso de uso basieo para la activaci6n del sistema se presenta de la siguiente manera:"

HogarSeguro
a~~

VI

nl

verificar

",",,0
octivoda

solido en ooso inslcnle desvioci6n no 11510

o o

et\Cendido

12 N6tese que este

caso de uso difiere de Ia situaci6n en Ia cual se e ntra en el sistema a trav~s de Intemet En este caso, la interaccion se lleva a cabo par medio del paned de control, el acceso es diferente que cuando se utillza una PC.

176

PARTE DOS PW.CT1CA IE LA lNGNlRiA oo.!iOFYWARE

El propietario observa eI panel de control de HogarSeguro (figura 7_2) para detenninar 51 el sistema est:. lisle para enlTaL Si el sistema no esta lisle se despliega un mensaje de

no lisla sobre la pantalla LCD. y el propietario debe cerrar en forma flsica puertas y ventanas para que el mensaje desaparezca (Un mensaje de no liSle Implica que un sensor

se encuentra ablerto; es electr. que una puerta 0 ventana esta abierta.,

2 EI propietarlo uliliza el tedado para introduclr una contrasena de cuatro digitos. La (ontrasefia se compara con Ia clave almacenada en el sistema. Si la contrasefia es incorrecta, el panel de control emilira un sonido y se reiniciarti para recibir otTa entrada, Si I,
contrasei\a es correcta, el panel de control esperara la siguiente acci6n.

EI propietario selecdona e introduce en aJ50 0 S(Jlido (vease la ligula 7.2) para aclivar eI sistema En casa activa 5610 los sensores de'l perlmetro (los sensores para la detecci6n de' movimiento interno se desactivan) SaHda activa todos los sensores, Cuando se realiza la acllvaci6n, el propielano puede observar una luz roja de alarma

EI caso de uso basico presenta una historia de alto nivel que describe la interacd6n entre el actor y el sistema. En muchas ocasiones, los casos de uso tienen una mayor elaboraci6n para pro-pordonar mas detalles acerca de la interacci6n Por ejemplo, Cockburn (COCOI ) sugiere la siguiente plantilla para las descripciones detalladas de los casos de uso

...... _50
t.""",,",",
CIIIIS dr USII Sf
- " , SlTIClI-

caso de usa:

fnJdo de moro/Off:O

AClor primarlo: Meta en el contexte:

Propielario de la casa. Esla blecer eJ sIStema para monilo~ar los sensores cuando el propletario salsa de la cas<! 0 permanezca de'ntro ella
El Sistema ha sido prosramado para una contrase-

.... """"'-

""""...,.
fJI Sf trJtSiJnn

,..,IIa/llOSf'IlW

_.""de.

COndiciones previas: Actlvador: Escenario:

na y reconocer diferentes sensoTes. el sistema, es decir, encender las funciones de ala rma.
~iniciar"

El propielario decide

I PropietarlOc observa el panel de control.

2. Propietario introduce la contrasefia

3. Propietario; selecdona
~e n casa~

0 -salida-

4. Propietario: observa la luz roja de alarma para indicar que

HOSOrS<guro esta en ope-

raciOn. Excepdones:
El panel de control no est4 llslo: el propletano verifica tados los senso~s para determinar cuates estan ablertos; los cierra

2 La conlrasei'la es incorrecta (el panel de control emite un sonido); eJ propietario introduce de nuevo la contrasena correcta 3. La contrasei'ia no es reconocida, debe conlaclarse eI subsislema de monitoreo y respuesta para teprogramar la contrasei'la 4 Se selecciona CfI casa el panel de control emile un solUdo doole y se endende la luz de tn ca5l1, se acUvan los sensores del penmetro.

cAPiTuLo 7

INGEHIERlA DE IlEQUISITOS

177

5. 5e selecciona salida el panel de control emite un sonido triple y se endende la tuz de salida; se acUvan tados los sensores Priorldad:
DisponJble desde: Frecuenda de uso:
Esencial, debe implementarse.

Et primer incremento. Muchas veces al dla

A traves de la Inlerfaz del panel de control.

canaI bacia el actor:

Actores secundarios:
~es

Tecnicos de soporte, sensores.

hada. los actores secunduios:

Tecnico de sopone linea telef"6nica 5ensores Interfaces alambricas e inalambTicas

AsunlOS pendientcs:

.i.Deberia haber una forma de actJvar ei515tema sin el U50 de una contrasei'ia 0 con una clave abreViada' 2 . .i.EI panel de control deberia desplegar otros mensajes de lexto' 3 . .i.De cuanto tiempo dispone eI propielario para inlroducir la contrasei'la desde el momenta en que presiona la primera tecla' 4. .i.Existe alguna fonna de desactivar el sistema antes de que bte se active en realidad 7

Los casos de usa para las otras interacciones del propietario se desarrollarian de una manera similar Es importante sefialar que cada caso de uso debe revisarse con cuidado. Si algun elemento de la interacci6n es ambiguo, existe la posibilidad de que una revisi6n del caso de usa descubra el problema

~~~~~~~~: ~~M~;r,Q~~:-~~~'~"P="::"~~_~: .... ..........

......"..; que escribimos.,,,,,,

;,

r:==........... --_. . ._. . .

10--.'0<"""
.-m<W _ _ .t1a

........ *181 .a..,mmo de al.o

_1_
decir,

an _

Malinda" Si.
~
y utilid: II cucdro

de

adores; at

que no. uno

--

Doug: .Eto !.gal lM' MI tis: I r. lo "'eo'dod I'D (IS CCfI'IUniror 10 itJo. maa6... Yo ~ que ~ UI'ID petICInO

..... 7.31

d;."...".. puodo ""'"'""'""'. un poco los cmos. No cr.o ~.tD ' . . . . . . plobiemo

178

PARTE DOS I'RACOCA DE LA!NGINIIldA DEl. SOFTWARE

VInod: 0. ocuerOO, enIrorK.e$lienemOs norratios de uno de 105 6Yo1os. iNec:esiJamCl$ daorraIar I'ICIfI'Ofiym mcls detalb:ios con bose en pIcni'" He IeIOo oterCQ de .lim. Mu i, .lIan Probobiemente. pero esc) puede esperar hoskJ q.M hayamc CXII'Isidemdo otros fuociooes. de
COS05 de too para coda

Persona de rnermll,r.",* ~. viendo este diogrcmo, y de rtIJ*lIe me" cuInIO . .

fit"'"

homo. oIOd.do oIgo

Moderodor: tOe verdad 6G1u6.10 que . . . . . . .
(La reuni6n continUo)

-Soguro

""""amo

c<DOde~

de

para io Iuncl6n de

el hogar de

-~

_0.
Desarrollo de casas de uso Objetivo: Ayvdo eo eI desarrollo de cosos de uso 01 propon:;ionor pIontillo, que s6Io nquieren elllenado de ~k en bIonco, pore OS! crear WSO$ de usc eficaces. La moyorio de los fvncionolidodes poro 105 COS05 de uso estran induioos en un conjunlo de func~ m6! amp/ia pare 1 0 ingenierio de requisilos.

La vo~ mayorio de los herromienk:ls poro eI mocIeIodo del onCihis, bowdcs en UML, proporcionon ~

grofico y en /IexIo pare eI desarrollo y modeIacIo de

case de uso.

Herramientas representativas U

dear Requirement Woricbench, desorrollodo pof liveSpecs

Softwore (www.live~$. oom), proporciono soporte oulomalizodo pora Ie c;recxiOn Y evolooci60 de (0$0$ de UloO, asf como una variedod de oIms funciones pore

Objects by Design, una !vente pore herromienlos de UMl Iwww.objectsbydesign.oom/ klols/umltooidryCompony .htmlJ proporciono vinculos completm para conocer herromientas de ~!1!1 ripo.
En U~~.oqJ (www.u$eCo!.e$.org) Sf! puede encoo trar uno voriedod de pIontillas para de!.Orro!lor C050S de uso, CHi como una bo$e de oolos para soponarlos.

10 ingenierio de requisilos.

13 U.s herramientas mencionadas aqui son una muestra de esta categoria E.n la mayorla de 105 casas los oomb res estan regi Slrados par sus respeCl ivos desarrolladores

cAPiTuLo 7

INGENIRLo. DE REQUIStTOS

179

EI objetivo del modele de analisis es describir los dominios requeridos de infonnaci6n. funcionamiento y comportamiento para un sistema basado en computadoras. EI modelo cambia en fonna dinamica conforme los ingenieros de software aprenden mas acerca del sistema que se va a construir y los interesados entienden mejor 10 que necesitan. Por esta razbn el modelo de analisis es una representadbn de los 0 que se espera que este cambie. requisitos en un momento determinado. pOT 1 ConfOT me el modelo de amllisis evoluciona. ciertos elementos se volveran relativa mente estables. por 10 que proporcionaran una base salida para las tareas de disefio que siguen. Sin embargo. otTOS elementos del modelo pueden seT mas volatiles. 10 que indicara que el cliente alm no entiende por completo los requisitos para el sistema. El modelo de analisis y los metodos utilizados para construirlo se describen can detalle en el capitulo 8. En las secciones siguientes se presenta una breve visi6n general.

7.6,1 Elementos del mod.elo de anCdisis

Existen muchas maneras de buscar los requisitos para un sistema basado en computadora. Algunas personas involucradas con el software dicen que 10 mejor es seleccionar un modo de represen taci6n (por ejemplo, el caso de uso) y aplica rlo sin tamar en cuenta tooos los mooos restantes. Dtros profesionales creen que resulta valioso utilizar varios mooos de representaci6n para mostrar el modela de analisis Las diferentes formas de representaci6n obligan al equipo de software a considerar los requisitos desde distintos puntas de vista, un enfoque que tiene mayores probabilidades de descubrir omisiones. i nconsistencias y ambiguedades. Los elementos especificos del modelo de analisis los determina eI metoda de modelado que se utilice (capitulo 8)_Sin embargo. existe un conjunto de elementos genericos comun a la mayoria de los modelos de amllisis: Elementos basados en escenarios. El sistema se describe, desde el punta de
djagra m a~

vista del usuario, por medio de un enfoque basado en escenarios Par ejemplo. los casos de uso basicos y sus correspondientes de caso de U50 (figura 7.3)

...... Il00.,
t.wkJtspsOrlea

s.,re ts 1m 00en0 . . iwOOcror alos

,. ..;o,ts frrmas de

evolucionan para con vertirse en casos de usa mas elaborados basados en plamiJlas. Los elementos del modelo de analisis basados en escenarios can frecuencia son los primeros que se desarrollan durante la elaboraCIOn del mOdelo_ Por tal motlvo. sirven como una entra da para la creaci6n de olros elementos de modeJado. Un enfoque alga diferente dentm del modelado basado en escenarios muestra las actividades 0 funciones que han sido definidas como parte de la tarea de obtenci6n de requisitos. Estas funciones existen dentro de un contexto de procesamiento_ 1::sto es, la secuencia de acti vidades (tambien se pueden utilizar los terminos fundones u operaciones) que describe el procesamiento dentTQ de un contexto limitado se define como parte del modele de analisis. Como la mayoria de los elementos del mode 10 de analisis (y Ol TOS modelos de la ingenieria de 5Oftware) , las actividades (funcio

cD trIO !pi! ekixn

. . Sf utiIotd M

......

aI5IIS tit l6(I ~ ~lcfoonaM

180

PARTE DOS

PIU.cncA DE LA ~ DEl.!IOf'TWAR

nes) se pueden representar en muchas grados diferentes de abstracci6n. Los mode-

los en esta categorla pueden definirse de manera iterativa. cada iteraci6n proporciona detalles adlclonales del procesamiemo. Como un ejempJo, en la figura 7.4 se presenta un dlagrama de actividad en UML para Ja obtenci6n de requisitos. 14 Se muestran Ires niveles de elaboraci6n.

--_de
!
do _ _

pan""

docWnon"".

Obtener requis,los

!
"""'"'"'" dale para do el
,"""".

.
5en1OO"
nombre/id
area

~cod6n
~rll

corocterist,cas

.""'''''''''' octivor{ I J
rec.onTI,II'Qr{

14 EI diagrama de acllvldad cs bastantc parecido al diagrama de nujo un dlagrama graflCo para reprc-

sentar las secucnctas y l6f!ica del nujo de control tcapiluk> II).

181

Elementos basados en clases.

cada escenario de usa implica un conjunto de

"objetos" que se manipula mientras un actor interactua con el sistema. Estos objelos se clasifican en clases: una colecci6n de clases con atributos similares y comportamientos en comun. Por ejemplo, se puede Usaf un diagrama de clase para mostrar

una cJase de sensor para la funci6n de seguridad de HogarSeguro (figura 7.5). Ohservese que eJ diagrama lisla los alrihutos de los sensores (POT ejemp[o, nombNIld,
tipo) Y las operaciones lpor ejemplo, identificar( ), habiJjtar( )1 que pueden aplicarse

para modificar dichos atributos_ Ademas de los diagramas de clase, olros elementos

del modelado del anillisis muestran 1a forma en que las clases colaboran con uno y otro y las relaciones e interacciones entre las clases. La anterior se examina con mayor detalle en el capitulo 8.
Elementos de comportamiento. El comportamiento de un sistema basado en computadora puede tener un profundo efecto sobre el diseno que se elija, asi como en el enfoque de implementaci6n que se apJique. Por 10 tanto, eJ modele de analisis debe proporcionar elementos de modelado que muestren el comportamiento. El diagrama de estado (capitulo 8) es un metoda para representar el comportamiento de un sistema al mostrar sus estados y los eventos que ocasionan que dicho sistema camhie de estado. Un estado es cualquier forma de comportamiento observable. Ademas, el diagrama de estado indica las acciones (por ejemplo. la activaci6n del proceso) que se taman como consecuencia de un evento particular. Para ilustrar un diogramo de estado, considerese el estado de lectura de comandos de una fotocopiadora de oficina. En la IIgura 7.6 se presenta el diagrama de esta do correspondiente en UML Un rectangulo redondeado representa un estado EI rec tangulo se divide en tres areas; I) el nombre del estado (por ejemplo. l..ectura de comandos). 2) las vanobles de e;tado que mdican la manera en que el estado se

'-'uno

"'~.D'
Mensa!e desplegodo ...
-introducir cmd"

"-

Nombre del estodo

ESlOk" del SIAeflKJ ... -Usto- .....

i' Voriobles de .slOdo

Oilploy stoh.ll ... steady cdatus cihplegodo .. estoble

Enlrodo/wi;uwnos liw Acci6n: peelir 10 entrada del lISuorio en eI ponel AcciOn, t--Io ...in;>do &.I
usuorio Acci6n: inlWprelor 10 entrodo
~\lwono

,a,
HOGARSEGURO

ModeItHIo pteltminar del comportamJento

. . .,1'tDrio: L/rIo sokt d.

:Nt b

; : : : G....'" ~ ....... pan> ~...,;Iocion do

......,u.Iomieo Lozot, mOembro del equipo 0.

"""'- v....d _ . -.... dol """"" do -'oro dol ... ", do ......... Doue MiIIIr, mierN:Iro d.I equipo de software; Ires

"""'-Ed ........

.... ..... de MM.1 ...... eh .......,4..._

_.OI.l'IWu.~c_"io; repreMnll:ri!l de . . .1iIrto cW proGucto; y un mod.,,;xio(,

un

"lee. e.mos caIaJ."

~.

......
Ma J

esklm 1I'IOI'!;loreondo Io.~."""""

IXIn'IOI'Ido5 del propie6orio d.1a ca:a Qq'. ,

1.r. 'Ifi, N pudtt '-*'0

a punIO de terminar de hcmIor

~ de MlgUfICb::l en eI hogor de IWo OIIIIIS de ho:-'o, t\"III gWorio dlscutir

Jamw. Torrben IlIVisorO Ia PC poRI doo...,;_ .......

alg~

enlroda desde ohi, pot ~ . . _ _

., a.portca,,;'110 de Ia luncion .... .41. Ed 11tJlia:Yonoentiendoloque

. . . . . . . _~tlo

bosodo ... Internet 0 inIronnocion .. co..5.....dln. y ....., Si. do ho<ho. ~~doI_. alodo pot d.r.cho propio.
Doug: Me J*lsorlo un pot "... .
..,diogrt:-ode~

........" Es cuondo Ie dos aI pmducto un "Iietnpo

___ Ii .. w ..... b tnaI

~quI 'I'CII'I""~:'::'.=:~2~ ,I

'
., 1

t" No ...odu" .... ~ expIic:odes, [Et 11' . . . . . . .pica gI equipo de rec.opiloci6n de

,.

t_

CICIIapoi

bosicos del modeIodo del

=P

Madn"'lFl Si . ,..........., .......".l1li d..pu6. do ~ ........

taw:i:nlD.J

manifiesta a si mismo en el mundo exterior, y 3) las aclivldades de eswdo que i

can 1a forma en que se ingresa a1 estado mientras se permanece en el mismo.

(~/)

y las acciones (do: ) invoca

Elementos orientados aJ flujo. Cuando la informad6n nuye a traves de un tema basado en computadora, esta se transforma El sistema aeepta la entrada una variedad de form as, aptiea funciones para transformarla y produce una sa tamblen en formas diferentes. La entrada puede ser una senal de control que traIlS"' mite un transductor, una serie de numeros que teclea un operador humano, paquete de informaci6n transmitido a traves de una liga de red, 0 un volumin archivo de datos obtenido de un almaeenamiento secunda rio. La transformac puede induir una sola comparaci6n l6gica, un algoritmo numerico complejo 0 enfoque de interferencia de reglas perteneciente a un sistema experto. La sal puede encender una sola luz de LED 0 produeir un reporte de 200 paginas. En erec to, es posible crear un modelo de nujo para eualquier sistema basado en camp" tadora, sin irnportar su tamano 0 complejidad. En el capitulo 8 se presenta una expo sici6n mas detallada del mode\ado del nujo.

cAPiroLo 7

INGENIERfA DE IlEQUISITOS

183

7.6.2 Patrones de cmCdisis

Cualquiera que lleve a cabo ingenieria de requisitos en mas de unos cuantos proyectos de software comienza a darse cuenta que ciertas cosas suceden de manera recurrente en lodos los proyectos dentro de un dominio de aplicaci6n espedfico_ 15 Estos pueden denominarse patrones de anofisis [FOW971 y representan alga (par ejemplo, una dase, una funci6n 0 un comportamiento) dentro del dominio de aplicaci6n que puede reutiiizarse al modelar muchas aplicaciones_ Geyer-Shultz y Hahsler IGEYO I ] sugieren dos beneficios que pueden asociarse con el uso de patrones de analisis:
Primero, los patrones de am\lisis aceleran el desarrollo de moclelos de anaJisis abstractos que capturan los requisitos principales del problema concreto al proporcionar modelos reutilizables del analisis. los cuales incluyen ejemplos, asi como una descripci6n de las ventajas y limitaciones Segundo, los patrones de analisis facilitan la transformaci6n del modele de analisis en un modelo de disefio al sugerir patrones de disefio y soluciones confiables para problemas comunes

Los patrones de analisis se integran al modele respectivo mediante una referenda al nombre del patr6n. Estos lambien se encuentran almacenados en un dep6sito para que los ingenieros de requisitos puedan utilizar los servicios de busqueda yasi encontrarlos y reutilizarlos. La infonnaci6n acerca de un patr6n de antllisis se presenta en una plantilla esttlndar que liene la siguiente fonna (GEY01 1;'6
Nombre del patron: un descriptor que captura la esencia del patron EI descnptor se utiliza dentro del modele de analisis cuando se hace alguna referencia al patr6n Intend6n; describe aquello que el patr6n pretende lograr 0 representar 0 el problema que ataca denlro del contexte de un dominio de aplicad6n Motlvacl6n; un escenario que iluslra la forma en que el patron se puede ulillzar para atacar el problema_
Fuer-zas y contexto; una descripci6n de los aspectos extemos (fuerzas externas) capaces de arectar la manera en que se utiliza el patron. asl como de los asuntos externos que serim resueltos cuando se aplique el patron. Los aspectos cxtcmos pueden incluir cuestiones relacionadas con los negodos. restricciones tecnicas extemas. y asunlos relacionados con las personas

SOlud6n; una descripcion de la fonna en que se aplica el patr6n para resolver el problema, poniendo especial atenci6n en los aspectos estructurales y de comportamiento. COnsecuencias; se enfoca en 10 que sucede cuando se aplica el patron yen los cambios que se producen durante su aplicaci6n 15 En algunas situaciones las cosas se repiten sin importar el dominio de aplkaci6n Por ejemplo, las caraclensticas y funciones de las interfases del usuario son comunes. independienlemente del dominio de aplicaci6n que se considere 16 En 1a bibliografla se ha propuesto una variedad de plantllIasde patron lOS lectores lnteresados puc den consultar IfOW971, [BUS961 YIGAM'J5I, entre muchas OIras fuenles

.
Oi5efio: examina la manera en que el patrOn de analws se puede iosrar por media de
patrones de disefio conocidos
Usos conocldos: ejemplos de usos en sistemas reales.

Patrone5 reladonados: uno 0 mas patrones de an:msis que esttm relacionados con

el patron en cuesti6n, porque el patr6n de analisis II por 10 general se utiliza junlocon e1

patron en estUdlO, 2) es similar en el sentido eslructural a dicho patron, 3) es una variaci6n del mismo.

En el capitulo 8 se presentan ejemplos de patrones de anti:lisis, as! como olros ana-

\isis de este t6pico,

Patrones
los potrones 58 puec:Ien ver en co:li OJCJiquier

octividod de 10 vida diana Considerense las peliculos de occiOn y CJYeflluros ~ IYIOnwo mOs et.pOO1ico 10. peJicukn poIiciocos de occiOn Y oventvros con matK:es de ocwnedio--. Se puec:Ien definir
potroneJporoel~, ~,

pon8f"

~ o6mico, 0 puede U5CnI!I en I,Wl popel m6s moIivoIo pon;! trobot. ~ 0 i~ penonoIes en eI comino

do .. ,aiw

dO~. So ho ~oo """""

Paro un ej~ olga m6s l8cnico con:lidel"ese un teI6fono c8uIor. Los siguienta potrones 50rl oI:!vm: ~
~, Va?\o4ensojes enlfe m~ otm5.

CriminolcmComzt y muchos mOl for efenllIo, eI Cqli~ Mtoede lJQleftJ noriabIe mas vieio, U1CI oorbato (el h6roe no), ~grikl en k.mo es~iendo eI

Coda

uno de MIo!i potrones puede describirse una vez y despu6l reutilirorse en III ~ paro cvolquier telelono celulor.

En un contexte ideal de la ingenieria de requlsitos, las tareas de inicio, obtenci6n elaboraci6n determinan los requisitos con el suficiente detalle como para emprender los pasos subsecuentes de la ingenieria del software. Desgraciadamente, esto sucede muy rara vez. En realidad, el cliente y el desarrollador entran en un procesc. de negoCJoci6n, en el cual se Ie debe pedir al cliente un balance de la funcionalidad el rendimiento y otras caracteristicas del sistema 0 producto frente al costa y el tiem

po de colocaci6n en el mercado. EI objetivo de esta negociacl6n es desarrollar

UfI

plan de proyecto que satisfaga las necesidades del ciiente al mismo tiempo que refleja las restricciones del mundo real (por ejempl0, tiempo, gente, presupuesto) a las que esta sometido el equipo de software.

las mejores negociaciones son aquellas que buscan un resultado del tipo "ganargana('Y Esto es, el cliente gana al oblener el sistema 0 produclo que salisface 1a
17 Se han escritotku:na.sde libr05sobre las aplIludespan Ia negoOad6n /pOre,emplo, [lLWOOJ. [FAR971 100N961) Esta es uniI de las compeu-naas mas LrIlpOIUntes que un angeruero 0 gerente de software ;0ven (0 no tan;c-n) puecIe apm1def se ra:omienda leer at menas uno de Io5libros mencionados

18.
mayo ria de sus necesidades, y et equipo de software gana at trabajar con presupuestos y IImites de tiempo realistas y alcanzables. Bohem (ooE98J define un conjunto de actividades de negociaci6n en el inieia de cada iteraci6n del proceso del software. En lugaf de la actividad sencilla de comuni caci6n con el cliente, se definen las siguientes actividades: I . Identificaci6n de los inleresados clave en el sistema 0 subsistema. 2. Determinaci6n de las "condiciones ganadoras" de los interesados

3. Negociad6n de las condiciones ganadoras de los interesados para reconciliarlas en canjunto de condiciones del tipo ganar-ganar para todos los Involucrados (incluido el equipo de software)
La conclusi6n exitosa de estos pasos iniciales asegura un resu[tado del tipo ganar-

ganar, eJ cual se convierte en el criterio clave para continuar con las actividades subsecuentes de la ingenieria del software.

E1 arte de Ja negoc1adan

EI ~izoje del orie de 10 negocioci6n efectr..c lIS uno octividod que ~rve a IftMk de ticnica 'I penonol. La con~i6n de 10,
diredrioes puede ~ muy vgjioso:

'eno,. que no (1$ uno compel"u,io. Pore

~. o~!ados

deben -mm;.mo de ~ ganado 0 Iogrado olga. l.o$ ~ por1e$ Mdr6n que lleeer a un acverdo. DI'ser'kr uno estroIegio. Oecidir que M 10 que Mil d.seorio Iogror; que lIS 10 que 10 otrc porte quiefe okanzor. y qv6 lIS 10 que Mil va 0 hacer p::wa qtJe ambo, COKlS weedon. &cuchor- de tnanctr"O aaivoo. No ~ debe penSOI" eo ~ uno respuesto mienfrcn Ie oIrCI porte est6

Iener.

hoblondo. Es rMICe$Orlo flCUChor. h po5ible que se obtengo un oonocimienlo que ayudor6 a negociar de mejor monero 10 po~d6n propia. 4. fnlixone en los in/ete$es de 10 oIro pone. Si se quieren eitor los conRidos no se debe klmOr 1m
posici6n inRe"ubl..

5. No dtjor que ~ vveIva persono/. Enfocarse en eI probIcmo que debe::IoCI" reweho. 6 . s... uwmi"'O. c.-.do ........ ailuao;iono do eskJncomienkl no se debe trener miedo de f*UOr fuero de los c6n0nes.
7 Estar /,$10 para podor U.... _:r. q ..... he. lLegodo '" un ocuerdo. no lIS necetorio ~r: se debe poctcr

dicho ~io Y -suir od.Ion",

., ""'*' ". """ IteflOCIod6n

1111 _ _

Oficino de tiso ..... 10

de

Doug: En realidad~. bu.IOI eiementoos a 10.....".. ~ baIaant.

Uto (aonriendo): Slcbo.... ""diinn . . ...... YqJI! no M I.ftO odMcbd rruy ~ . . ...... .... 1 ........ \lk:nico 10 pr6Iumo ~ que \III vn.. Mira. lila. JO'"
que pod..- ............

ErwioW'"

~Me_do_Ia_.

,............,Io_ ...... ~ .. ""

po;"._ .................. ..

lundonolidodoo ..... 10 Iun06n

do . . . . . . . ...

.
n'Il.I)'

PARTE DOS

PRACTCA DE LA INGNlDIL\ DEL SOfTWARE

para los ftrctICIl de los que esIO habIondo III gerenoo. Es

prot' )'010 W, perc yo he estodo hoc,endo un ....... ...".;do do 10",..,..,... y

u..: Drebemcn teneno para e$(J!echo, Doug. tDe cu61 funcioflolidod MtQs hablando? DeuF Me porea! que podemos KIC(Ir lode Ia fvnci6n d. ....idod en '" hagar paro Ia f.ed,o limi le, perc " " 10' Cf'A' nIIn:Jior el 0CCM0 po!'" Irnemet hosla Ia
LIM: Doug. III oa:mo par I...... es 10 que de a ~ 10 coIidod de ' na.oedoso. Vamos 0 CDIIIII'Vir toda nuestro CCJ!'IlXIoo de ,....oodotea ,io alNd.cb d. toIkI, ,Debemo, ~
.,...: Entiendo IU situoci6n, de.....dod EI problema e! qu. pare dartre acceso a Inlemd necesiloremo$ tener un

podcwnot hocer con los t'KUn05 que ___ ___

encontror uno

sillo Web~ .. MIgl.IfQ. )'O~,~ funcionomienlo Para e50 _ I'IIIOt$ilg Iiempo,. . . . Tombi. lendr."..,. que COr'IRnHr- funcicwi( t' , odicionolM en 10 prill'llWO entrwga .. no

eNG,,"

..............

liMa (frunciMMlo .. qAo): Yo '4O.jJII'O'" Iormo de hocerIo. Es. crucial ,... . h.r.cione, de wguridod ~ II hagar y para ' -. .

"","",- . . . -.
~

hoskI lo, ~ enQgos. esIariI d.~_

"" """ ""'""'- .......

_.'

LiKl YDoug porecerl eWr en ~ caIti6n ...... oUno~ ~negocioruno~o . . p: " . . . .....""'i6n, .,...don .,.,..... "" .... En ........ un mediodor, tcu61 sMa uno ~ ap!Qpiodol

AI crear Cilda elemento del modelo de analisis, este se examina para conocer su s;stencia, sus omisiones y amhigiiedades. A los requisitos que representa el mode: e1 d icnlc les da jerarquia y sc agrupan en paquetes de requisitos que se imple tan como incrementos de software y se Ie entregan Una revisi6n del modelo de lisis se enfoca en las siguientes preguntas:

(u"cIa
pr~as

st

GCada requisito es consistente con e[ objetivo general del sistema/product, Grodos los requisitos han side especlficados con el grado apropiado de abstraccioo? Esto es, <.algunos requisltos proporcionan un grado de detaJle lecnico que sea inapropiado en esta etapa? GEl reqUisito es necesario en realidad 0 representa una caraclerislica agregada irrelevante para el objetivo del sistema? Gcada requisito esta limitado y no es ambiguo? <.Cada reqUisito l iene una atribuci6n? Esto es, Gexiste una Fuente (por 10 general, espedfica, individual) determinada para cada requisito? tAlgunos requisitos entran en conniclo can otros? <.cada requlsito es alcanzable en el ambiente h~cnico que recibira al sisterr""~ prooucto? (.Cada requisito se puede probar una vez que este haya sido implementado?

rlviSCII Ills r sites. , aHNeS

Ht.e.

INKtrM?

iEI modelo de requisitos refleja de manera apropiada la informaci6n, la funci6n y eI comportamiente del sistema que sera construido?
GEl modele de requisitos se ha sometido a "partici6n~ para que exponga en forma progresiva informacion mas delaJlada acerca del sistema?

187

iSe han usado palrones de requisitos para simplificar el modele de requisitos?

,Todos los patrones se han validado de manera apropiada? ,Todos los patrones son consistentes con los requlsltos del cliente?

tstas y atras 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 s6lida para el diseno.

Antes de que el diseiio y \a canstrucci6n de un sistema basado en compuladora pue-

dan comenzar, es necesario enlender los requisitos Esto se logra realizando una sene de tareas de ingenierla de requisitos, 1a cual se lIeva a cabo durante las actividades de comunicad6n con el c1iente y modelado que han side definidas para el proceso gene-rico del software. LDs miembros del equipo de software realizan siele fun ciones distintas dentro de la ingenierla de requisitos: inicio, obtcnci6n, elaboraci6n, negociaci6n, especificaci6n, validaci6n y gesti6n_ AI inicio del proyecto el desarrollador y el ciienle (asi como otros interesadosj establecen los requisitos basicos del problema, definen las restricciones predomi nantes del proyecto y espedfican las caracteristicas y funciones mas importantes que deben estar presentes en el sistema para que este alcance sus objetivos. Esta informaci6n es expandida y refinada durante la obtenci6n, una actividad para la recopilaci6n de requisitos que emplea reuniones que encabeza un moderador facili tadas, el QFD y el desarrollo de escenarios de uso_
La elaboraci6n posterior expande los requisitos hacia un modele de antilisis;

es

decir, una colecci6n de elementos del modelo basados en escenarios, en actividades

y en cJases, de comportamiento y orientados a[ flujo_ En la creaci6n de estos ele

mentos se puede utilizar una variedad de notaciones de modelado. EI modele puede referirse a patrones de analisis, caracteristicas del dominio del problema que son TeCUrrentes a traves de djferentes aplicaciones. Cuando se identifican los requisitos y se crea el modele de analisis, el equipo de software, el cJienle y otTOS interesados en el proyecto negocian la prioridad, disponibilidad y costo relativo de cada requisito. El objetivo de esta negociaci6n es desa rrollar un plan de proyecto realisla_ Ademas, cada requisito y el modelo de analisis como un todo se validan conlrastandolos con las necesidades del cJiente para ase gurar que se construira e] sistema carrecto.

(BOE98] Boehm, B. y A Egye<l, ~SOnware ReqUIrements Negotiation Some Lessons Learned", en Proc. InU. Con! software Engincenng. AeM/ IEEE, 1998. pp. 503-506, (BOS91l8ossert, J L, QualIty Function ~t A PractJtJonffs Approach, ASQC Press, 1991 (8U5%1 Buschmann, F, d al. f'altem()rimtaJ software An:Iutecture, A ~em Pallem , Wiley,

1996

ICOC01] COCkburn, A., Writing EjJecM Use-Ci=s, Addison-wesley, 2OCH. ICRl92] Christel, M. G. Y K. C. Kang, H issues in Requirements Elicitalion H , en software Engineenre Institute, CMU/SEI-92-TR-12 7, septiembre de 1992. [OON96] Donaldson, M. C. Y M Donaldson, NegotialJng for Dummies, lOG Books worldwide 1996 [FAR97J Farber, D. c., COmmon sense NegodOtion; The Aft of Winning Gracefully, Bay Press, 1997 [FOW97] Fowler, M ,AnO~ Pal/ems: Reusable Ob]f!Ct Models, Addison-Wesley, 1977. ]GAM951 Gamma, E. et 01., Design Patterns; Elements Of Reusable Object-Oriented Software. Addison-wesley, 1995. [GAU89] Gause, D. C. Y G. M Weinberg, Exploring ReqUirements; Quality Before Design, Dor.id House, 1989. [GEYO li Geyer-SChultz, A y M, Hahsier, software Engineering with Ana/y.iis Patterns, Techni Repon 01/2001, Instltut mr Informationsverarbeitung und-winschaft, Wirschaftsuniversl . Wien, noviembre de 2001, oblenido de http://wwwaiwu-wien.ac.atl-hahSler/research/vir lib_wooonglOOl/virlib/. UAC92] Jacobson, 1 , ObJetcOnenled SOftware Engineering, Addison-wesley, 1992. [lWOO] lewicKi, R., D Saunders y J- Minton, Essentials Of Negotiation, McGraw-Hill, 2002. [PAR96] Pardee, W., 10 Satisfy and Delight Your Costumer, Dorset House, 1996. [SOM97] SOmerville, I. y P. sawyer, ~UlremenlS Engmeering, Wiley, 1997. [THA97] Thayer. R- H. Y M Dorfman, software ReqUirements Engineering, 2a. ed., IEEE Computer Society Press. 1997 [YOUOI] Young, R, EjJective ReqUirements Practices, Addison-wesley, 2001. (ZAH90) Zahniser, R- A., HBuilding SOftware in GroupsH, en ~an ProgrammeT, vol.3. nums ... 8, Julio-agosto de 1990. [ZUL92] Zultner. R., "Qua[ity Function Deployment for SOftware, satisfying COStumers", American Programmer, febrero de 1992, pp. 28-41.

7.1. ,Por que varios desarrolladores de software no prestan mucha atenci6n a la ingenierfa requisitos? .:5e lIegan a dar Clrcunstancias en las que se puede omitir? 7.2 . .:Que implica el Nanalisis de ci6n inicio'
factibilidad~

cuando se examina dentro del contexto de la fun

7.3. A usted se Ie ha dado la responsabiUdad de oblener requisitos de un cHente que dice est.demasiado ocupado para reunirse con usted . .:Que debe hacer? 7.4. Exponer algunos de los problemas que pueden surgir cuando los requisitos deben obtenerse de Ires 0 cuatro clienles diferentes. 7.5 . .:Por que se dice que eI modelo de analisis representa una foto instantanea de un sistelNl en el tiempo' 7.6. Suponga que ha convencido al cliente (usted es un excelente vendedor) de cada dema que ha hecho como desarrollador oi.E.50 10 convierte en un negociador experto? ,Por que? 7.7. Desarrollar al menos tres "preguntas de contexto libre adidonales que pueda hacerle algtin interesado durante la fase de inicio.
N

7.8. A traves de este capllulo se ha hecho referencia al Ncliente" Describa al "c1iente" para desarrolladores de sistemas de informaci6n, para constructores de productos basados en comi ladora, para conslructores de sistemas. Debe tenerse precauci6n: pueden existir mas clientes este problema de 10 que se imagina. 7.9. Desarrolle un "paquete que faclli te la recopilaci6n de requisitos. El equipo debe incluir conjunto de directrices para realizar una reuni6n de recopilaci6n de requisitos y una serie dt: materiales que puedan utilizarse para facilitar la creaci6n de listas y otros dispositivos que puedan ayudar en la definici6n de requlsitos.
N

CAPfrtn.o 1 INGi:NJERlA DE RQUISITOS

,.9

7. 10. fJ profesor hara grupos de cuatro 0 onco estudiantes. La mitad del grupo representara el papel del departamento de mercadotecnia, y la otra milad, el de ingenieria del software. La que se pretendera es definir los requisltos para la funci6n de seguridad de HogarStguro, descrila en este capitulo. Realizar una reuni6n de recoplLacibn de requisitos mienlTas se ulilizan las direc~ trkes presentadas en este capitulo 7, 11 . Desarrolle un caso de uso para una de las siguientes aClividades;
aJ Hacer un retiro en cajero automatko b) Ulilizar su talJeta de credilO para una comida en un restaurante,
C) d)

COmprar la despensa con una cuenta de cobro en linea. Buscar libros (sobre un tema especHico) a lTaves de una librerfa en Ilnea e) Una actiVidad que defina su Instructor
GQu~

7 . 12 .

representan las wexcepciones'" en los casos de uso'

7. 13. Explicar con brevedad cada uno de los elementos de un moclelo de analisis [ndicar con qut contribuye cada elemenlO al modelo, c6mo es que cada moclelo es unico y qut informad6n general presenta cada moclf'lo 7. 14. Describir con argumentos propios un patron de analisis. 7. 15. Con la plantilla presentada en Ia secd6n 7.6.2, sugenr uno 0 mas palrones para una caci6n que aplique el instructor
apli~

7 . 16...Qut significa 8a nar~gana .... en el contexto de la negociaci6n durante la aclividad de ingenierfa de requisllos' 7 . 17 . ,Qut se cree que suceda cuanda la valldaci6n de requisitos descubre un error? ,Quitn es el indicado para corregir el error'

Debido a que es pnmordial para la cread6n exitosa de cualquier sistema complcte bMlldo en computadora, la ingenierfa de reqUlSltos se expone en una gran cantidad de hbros. Hull y sus colegas (ReqUIrements Engineering, Springer~verlag, 2002), Bray (An Introduction to Requirements Eng~ng, Addison wesley, 2(02), Mow (~Ulrements Engmeenng, Addison~Wesley, 2001), Cilb (RequiremenLS EnBs~ng, Addi50n-W~Ie)'. 2000), G~ ..ham (RcqWrl:'men~ EnsmCCr1tl5 arid Rapid ~t. Addison~wesley, 1999) y Sommerville y Kotonya (Requi~ts &!gint'fflng' Proc~ and Rchniqut!S. Wiley, 1998) son sOlo algunos libros dedicados a cslC lemu. Dan Berry {http://seuwalerloo,caJ-dbeny/bibhlml)hapublicadounaampiiavariedad de escrilOS acerca de t6picos relacionados con 13 ingemeria de requisllos Lauesen ~re Rrquuemmts.- Slyks and TecIJnJquei. A(khson~wesley, 20021 pre~nta una amplia muestra de notaciones y mer.odos para el analisis de requisitos. Wcigers (SOftware Requirefl1ef!LS, Microsofi Press, 1999) y Leffingwell y sus colegas (MaflO8lng sojtware Requirements II unljit:d Approach, Addison-wesley, 2000) presentan una colecci6n util de las mejores praClicas de requisilos y sugicren gulas pragmalicas para casl todo5 lOS aspectos del proceso de la ingeniena de requisitos Robertson y Robertson Vofastenng the ReqUIrements Process. Addison wesley, ] 9991 presentan un e5ludio de caso muy detallado que ayuda a explicar toclos los aspectos del analisis de requisitos y el modelo de analisis de software. Kovitz (PracbcaJ Software ReqUIrements: II Manual o/COntent and Styie, Manning Publications, 1998) explica paso a paso un enfoque para el anali~ sis de requisitos y una guia de Wilo para aquellos que deben desarrollar especificaciones de requisitos Jackson ~re Rrquifmlt!llLS Ana>Ls and Specification A U:x1con of Practices, Pnnapks and F're]ucb:s, Addison~Wesley, 1995) presenla una vtsi6n sugerente del lema de la A ala Z (de manera literal) PIoesc:h V\SS01!Ons. SCenarios and ProtOl)'pC5, Springer~verlag, 2003) explica tecnicas avanzadas para desarrol1ar requi5il~ de 3Qnware

190

PARTE DOS

PRACTICA DE LA DiENnl!lA 00. SOt"TWARE

Windk y Abreo (5o.fhw'R' Rafwn:nJtnts USIng eM Unified Process, Pr~ntice-Hall, 2002) exponen 101 lngeJ\icJia de requtsltos denim del contexte del proceso unlficado y la notaci6n del UML Alexander y St~n (Writing &tt~ Reqwrm1mrs, Addl50n-wesl~. 2002) p~ntan un breve COO)unlO de dlrectJices para escribir requisllos daros, represenlarlos como escenanos y revisal' el resultado final

EI modelado de casas de uso es a menudo el conductor de la creaci6n de lodos los delTlis aspectos del modeJo de analisis. Bittner y Spence (U.se-Case Mock/ins. Addison-wesley, 20011' examman el lema de manera amplia, asi como Cockburn ICOCO]), Armour y Miller (t\dvancft) Use-Case Moddmg SOjh\I(JTe 5)':Slems, AddlSOfl-Wesley, 2000), Kulak y sus colegas (Use Cases. ReqUIrements III COmof. Addison-Wesley, 2000). y seh.nelder y Winters (llpplyrng Use cases
Addison-wesley, ]9'}8). En Intemet se puede disponer de una amplia variedad de fuentes de informaci6n sobre ana !isis e ingenierla de requiSllos En el slUe web de SEPA, http://_ .mhhe.com/ pressman, se puede cncontrar una lisla aclualizada de referencla.s en la red mundial que son relevanto para el amtlislS Y la ingenieria de requiSllos

CAPirVLO

MODELADO DEL ANALISIS

n el ambito ttcnko. la ingenieria de software comienza con una serie de tareas de modelado que conducen a una especificad6n de reqwsHos y a una representad6n completa del diseno del software que se construira El moddo de ana/isis. que en realidad es una serie de modelos. es la primera repre~ sentacion tecnica de un sistema .
... 196

...21'

En un libro sobre m~odos de modelado del anal isis, Tom DeMarco (OEM79J describe el proceso de la siguiente manera:

AI obscrvar 10$ problemas y (alias reconocidas de Ia f~ de analisiS es necesario agregarle los siguientes ob,eIiVOS:
Los productos del anaJisiS

deben tener una elevada faclhdad de mantem-

miento. Esto se aplica en parucular al documento final fespecificaci6n de reo qulSit05 de softwarel

.1G2

lAs problemas de gran tarnatio deben trataJse con un metodo efectivo de partici6n La espitkaci6n del bpo de las r.oveIa5 vktorianas ya no ~irve

.. .225 .. .191

Deben utJbzarse graticas ruanda ~a posible .

se debe dif~nciar entre cOllSXieradones I6sicas !eSoencialesl y fisicas Ide imP'ememaci6nl .
Como mirumo se necesila

...2"
.. .lIS

Alga que ayude a l\acer una p.artiri6n de los reqUlSilOS y a ctoe...me-nlaJ'ia antes de la especdkaci6n

211

.....1"

de las imerfGSe5. tlerranuemH nuevas para deSCrtblr la IOgIca y Ii tacna. alga me)Or que un
texto narrativo.

Algunos medias para eI 5eguimiento y evaluaci6n

Aunque DeMarco escribi6 acerca de los atributos del modeJado del anillisis hace mas de un cuarto de siglo, sus contribuclones Sf: siguen apJicando en la notacl6n y los metodos modernos de modelado del and lis is.

iLiNW6t. 10 intagriclad y kJ <X:IIUistencio . ... 'I .. ~, Un ingeniero de 50ftware (algu' ~ Iamodo onolistal COf\struye eI modeIo

.,CIf'b* c:cnc:U:e a uno reonsi6n para Iogror Ia

,' . . ~ abl.nidos. del cliente.

que ............ rool de entender y, otin mOs

, . ... _ inn, aria....'

. . . I)>>

Pera volidcr len. cW software as nec:esorio exominarlos ......... _ de ..... d,r....,,,,. 8 modo-

,.,

'92

cton.. EI

_lao

"""" .. ..,..... ..IN

EI ana/isis de reqUisltos genera la especificaci6n de caracteristicas ope",ci'ln"'el' do software; indica la interfaz del software con alros elementos del sistema, y estab ce las reslricciones que debe tener el software. EI antllisis de requisitos permite
eJ ingeniero de software (a veces lIamado en este contexte analista 0 modeJador') extienda sobre requerimientos basicos establecidos durante tareas anteriores a

ingenieria de requisitos y construya modelos que representen escenarios del usu.a.

rio, actividades funcionales, dases de problemas y sus relaciones, el comportamien to de las c1ases y el sistema y, a medida que se transforma, eillujo de datos. El analisis de requisitos Ie proporciona al diseftador de software una representa ci6n de informacl6n, fund6n y comportamiento que puede trasladar a disenos arqui tect6nicos, de interfaz y en el nivel de componentes. Por ultimo, el modele de ana!isis y la especificaci6n de requisites ofrecen al desarroJlador y al cliente los medios para evaluar la calidad una vez construido el software . Por medio del modelado del analisis el ingeniero de software se centra primero en el que, no en el c6mo. ,Que objetes manipula el sistema, que [unciones debe desempenar el sistema, que comportamientes muestra el Sistema, que interfaces .se definen y que restricciones se aplican?' En capitulos anteriores se establed6 que en esta etapa tal vez no [uera posible reali zar una especificaci6n completa de requisitos. QuizA el desarrollador no esle'

.~

1I .....

C&VE
~_y

0lIl0iIi<'" ~

........

-.

~ IfCJpOlciooa

I.Il metio po1Il111UJ

III cmibh..., ve:z rpII

I Es necesario mencionar que conrorme los chentes se welven mas refinados en el sentido tecnol6giro exiSte una tendenda I\aCla La espedficacl6n tanto del cOmo como del q~. Sin embargo, el en roque primario debe permanecer en el que.

,.3

...

DHcripciion

segura de que enfoque especifico realizara la funciOn y sl se desempeftara de manefa apropiada. Estas reaUdades favorecen un enfoque iterativo para eJ anal isis y el

modelado de requisitos. EI analista debe rnodelar 10 que se conoce y utilizar ese

modelo como base para diseiiar un incremento de software,2

8.1.1 FIlosofia y objetivos generales

EI modele de amllisis debe cumplir tres objetivos primarios: I) describir 10 que requiere el cliente, 2) establecer una base para la creaci6n de un diseno de software, y 3) definir un canjunto de requisitos que puedan validarse una vez construido el software. EI modele de analisis lIena el vaclo entre una descripci6n al nivel de sistema (capitulo 6) -que detalla la funcionalidad general del sistema, la cual se JagTa al aplicar software. hardware, datos, humanos-- y atros elementos del sistema y del diseflo de software (capitulo 9) -que delallan la arquitectura de aplicaci6n del software, la inlerfaz con eJ usuario y la cstructura en el nlvel de componcntc5-. Est... relaci6n se iluslra en la figura 8. t .

Es importante punlualizar que algunos elementos del modelo de analisis estan presentes (en un grado mtls alto de abstracci6n) en la descripci6n del sistema, y que esas tareas de ingenierla de requisitos en realidad comienzan como parte de la ingeniena de sistemas. Ademt.s, lodos los elementos del modelo de anaiisis son Identificables de manera directa en las partes del modelo del diseflo. No siempre es posi bie una divisi6n clara de tareas de anillisis y diseflo entre estas dos importantes actividades del modelado. De modo invariable, como parte del analisis se realiza alg(ln disei'io y algUn analisis se efectua durante el di.seno.
2
De manera alternativa, el equipo de software puede eleglr la creao6n de un prototipo (capitulo 3)

en un esli.Jerzo encaminado a entender me;or los requlsltos para el Slsl:ema

.94
8.1.2 Reglas pr6ct1cas de an6:llsis
Arlow y Neustadt [ARL02[ sugieren varias reglas pr.kticas que deben seguirse para crear el modele de an.llisis:

El modele debe centrarse en los rtXjuisitos visibles dentro del problema 0 dominic de negocio. J gmdo de abstrocd6n debe ~r O/fO de forma reiativo. MNo se debe

perder tiempo en detalles~ IARL02) que tratan de explicar c6mo funcionara el sistema.
cada d~ro del modelo de ana/isis debe agregarse a un acuerdo genmll de /os requisitos de sofl'Nare y propordonar una visi6n intcma del dominic de informa-

dOn, funci6n y compoI1ilITliento del sistema

Debe relrasarse 10 considerod6n de la infraestructura y OLraS modeJos no juncionales hasta el diseflo. Por ejempio, es posible que se requiera una base de

datos, pero las clases necesarias para implementaria, las fundones que se requieren para acceder a ella y el comportamiento que se exhibira cuando se
utilice debe considerarse s610 despues de que se haya completado el analisis de dominio del problema.

Se debe mmirruzar d acopJamiento ck tado d sislema. Es importante representar las relaciones entre clases y funciones. Sin embargo. si el nivel de "interconexi6n~ es extremadamente alto se deben hacer esfuerzos para reducirlo.

Se debe tener /a Sl!guridad de que e/ modelo de anaJisis proporciona valor a Codos los mteresados. Cada circunscripc.i6n tiene su propio usa del modelo. Par ejemplo, los interesados relacionados can los negocios deben utilizar el modele para validar los requisitos; los disenadores, como base para el diseno; la gente de aseguramiento de la calidad, como ayuda para planear pruebas de
aceptaci6n.

El modelo debe manlCflerst! lall simple como.sea {XJSIbJe. No se deben agregar diagramas adicionales cuando estos no ofrezcan informacion nueva. No se deben utilizar formas de nola cion nuevas cuando basta con una simple lisla

8.1.3 An6llsis del domlnlo

AI examinar la ingenieria de requisitos (capitulo 7) se estableci6 que los patrones de analisis a menudo ocurren de nuevo en muchas aplicaciones dentro de un dominio de negocio especlfico. Si estos palrones se definen y se clasifican por categoria de una manera que permitan al ingeniero 0 al analista de software reconocerlos y reu tilizar]os, la creaci6n del modele de aniliisis se acelera. Un factor de mayor importancia es que la probabilidad de aplicar patrones de diseno reutilizables y componentes ejecutables de software aumenta en forma sustancial. Esto ofrece tiempo al mercado y reduce los costos del desarrollo.

'9'
Entrada Y salida para . 1 an61is1s del domin1o.

literature Iknica
Taxonomies de dOM

Sendees 0 los dienles

-.

. . cIominio 1--"""-'-='''::''--''''-_-1
languajes de dominio

Modele, funcionales

ModeIo de (m6Ii$is del dominic

,Pero, en primer lugar, c6mo se reconocen los patrones de an,Uisis? iQuienes los definen, los asignan a una categorfa y los preparan para aplicarlos en proyectos subsecuentes? Las respuestas a estas preguntas residen en el anal,Sls del dominio.
Firesmith [FI R93] describe el anAlisis del dominic de la siguiente manera:
El 3naiisis del dominio de software es La identiflcaci6n, el analisis y la especificad6n de requisitos comunes de un dominio especIflCo de aplicaci6n para, de manera lipica. reutilizaria en multiples proyectos dentro de ese dominio de aplicaci6n rEI analisis del dominic orientado a obJetos eslia identificad6n, el antliisis y \a especificaci6n de capaddades comunes reuti1izables denlfO de un dominio espedfico de aplicaci6n. en terminos de objetos. clases. subensamblajes y marcos de trabajo

EI Hdominio de aplicaci6n especlfico" puede vari ar desde aeronautica hasla servicios bancarios. desde videojuegos en multimedia hasta software aplicado en instrumental medico. La meta del amUisis 0 de dominic es directa: encontrar 0 crear aquellas clases de analisis 0 funciones y caraderisticas comunes que se aplican ampliamente para que puedan reutilizarse. J

................... ,...,...
En derta fonna. el papet de un analista de dominio es similar al de un maestro forjador de herramientas en un ambiente de manufactura pesada EI trabajo de este ultimo es disefiar y fabricar instrumentos que puedan ser usados por mucha gente que realiza trabajos similares. EI papel del analista de dominio4 es descubrir y definir
3 Una visi6n complementaria del anahsis del domlnio involucra el modelado del dominio de fonna que los ingenieros de .sol\ware yotros interesados puedan aprender mas de el no todas las clases del domlnlO resultan nc:cesanarnente en el desarrollo de cla5e!; reutiliubles"[LETOJI 4 No debe suponer.;e que 51 se cuenta con Ia coIaborao6n de un anallSla. del dominio. un in~nl :rode software no Ilene pot que cornprender el domlnio de apbcaci6n Todos \os mlembms de un eqoipo de software deben tener algun eonocimiento del domlmo 1m et cualse coIocara el software

PARTE DOS I'RAC'ncA Of: 1.A!NGDml!fA 00. SOFlWARE

patrones de ani1lisis reutillzables, clases de an<1lisis e informad6n relacionada que

pueda usar mucha gente en aplicaciones parecidas. La figura 8.2 IARA89) ilustra entradas y salidas clave para el proceso de analisas de dominio. Las fuentes de conocimiento del dominic se examinan en un intento par
identificar objelos que pueden seT reutilizados a
t rav~

del dominio.

Una visi6n del modelado del analisis, lIamado ondJisis estructurodo, considera que 105 datos y el proceso que transfonnan los datos son entidades separadas. lDS objetOl de datos se mooelan en una forma que define sus atributos y relaciones. Los proce 50S que manipulan los objetos de los datos se mcxlelan de tal manera que muestrar'l c6mo transforman los datos, mientras los objetos de datos fluyen por el sistema Un segundo enfoque del modelado del analisis, Hamado ana/isis orientado a objelos, se centra en la definici6n de c1ases y en la manera en que estas colaboran entre'

elias para efectuar los requisitos del c1iente. EI UML Y el proceso unificado 3) estan orientados a objetos en forma predominante.

(capit~

BI_m_, ... do,.................. ....,Ioio, ...... , .... (a_~ ....... U. .t..ID, II Yiejo _ dt 10 consncdOl. sma-. _ ..........
5' ...:

'Ill" _...

..-

Aunque el modele de analisis propuesto en este capitulo combina caracteristicas de ambos enfoques, es comun que los equipos de software elijan uno y excluyar todas las representaciones del otro. El cuestionamiento no es cual es el mejor, inc" que combinaci6n de representaciones Ie proporcionara a los interesados el mep modele de requisitos de software y el puente mas efectivo para el diseno de software EI modelado del analisis conduce a la derivaci6n de cada uno de los elementos dt. modelado mostrados en la figura 8.3. No obstante, el contenido especlfico de cadi elemento (por ejempio, los diagramas con que se construyen el elemento y el mode1 0) 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. S6lo St' deben utilizar aquellos elementos que agreguen valor al mOOelo.

..... ....was de tal fwma que r. . . . 0 enfatK~ riIr1a5 c.-odIrisIicas oitim de WI . . . . -' . . . .
.... .. ~ enfa$i5 atfos IIIp8dOS del sislemo.

-t" ......

~ rnodIIos? iPol-'" lID ClII5tninIo5 II sishIIO '1)'1? LA r. . . . IS . . , . . . .

w_

197

o...g.-do ........... ......o.

_CO:

__ _ ........
,-60_._
C_60 .... diow0....- .........

..........

...

o.ow- cIo Iujo do coMe!

~do~

Doorn- do IIuto do 0 -

.ModeIo de on6li$ls

.......

a..-

... ....,

D.og_do~

EI modelado del antilisis a menudo comienza con el mode/ado de datos. EI ingeniero o analisla de software define todos los objelos de datos que se procesan dentro del sistema y las reiaciones entre los objetos de datos, ademtis de otra inforrnaci6n per-

tinente para las relaciones.

8 .3. 1 Ob)elos de datos
Un objeto de datos es una representaci6n de cas! cualquier informaci6n compuesta

que el software debe enlender. lnJormoci6n compuesta se reliere a algo que liene
muchas propiedades 0 atributos diferentes. Por 10 tanto, uanchura~ (un valor indivi-

dual) no seria un objeto de datos valido, pero las dimensiones (Ia incorporad6n de
altura, anchura y profundidad) podrian definirse como un obJeto_ Un objeto de datos puede ser una entidad extema (pOT ejempJo, cua!quier cosa que produzca consuma inrormaci6nl. una cosa (por ejemplo. un reporte 0 un desplieguel. un suceso (como una lIamada teief6nica) 0 un evento (como una aJarma). un papel (por ejempio, un vendedor) , una unidad organizacionaJ (como un departamento de conta durla), un Jugar (como un aimacen) , 0 una estructura (como un archivo). Por ejempl0, una persona 0 un auto pueden verse como un objeto de datos en el sentido de que cualquiera de ellos puede definirse en terminos de un conjunto de alributos La descripci6n del objeto de datos incorpora el objeto y lodos sus atribulos. Un objeto de datos encapsula 5610 datos no existe alguna referencia dentro de un objeto de datos a las operaciones actlien sobre los datos .~ Por 10 tanto, ei objeto de datos puede representarse como una tabla, tal como se muestra en la figura 84 lOs encabezados de la tabla renejan los atnbutos del objeto. En este caso, un auto se define en terminos de rnerc., 1nOdeIo. nUmero de __ , tipo de canooeriII, ooIor Y propiet
rio. El contenido de la tabla representa ejemplos espedficos del objeto de datos. Por

ejempl0, un Chevy Corvette es una muestra del objeto de datos auto_

5
Esta distmci6n 5eJHlIC' orie:ntado a objeto:s
)os

objdos de datos y las clases u obtelos definJdos como parle del en{oque

II
Representact6n tabulard. obJetos de
datco.

Insloncia

Blanco Azul

Ul Blf

.~

8 .3 ,2

Ahihutos

C~VE

1.05 atrbJIos cWin.J a

lI'I objelo de dmos,

'"""""'"

(lioocrblmi y, WI
~ flIICK, 10:,"

.....

ffliereOO:l 0 altO

Los a lribu/O$ definen las propiedades de un objeto de datos y taman una de las tres caractetisticas diferentes. Se pueden utilizar para I) nombrar una ocurrencia dd. objeto de datos, 2) describir la ocurrenda 0 3) hacer referenda a otra ocurrenda eP Olra tabla. Ademas, se debe definir uno 0 mas atributos como un identificador; e5 ded r, el atributo identificador se convierte en una ~clave~ cuando se desea encontr.Jr una ocurrenda del objeto de datos. En algunos casas, los valores para el 005) iden tificador(es) son unicos, aunque esto no es un requisito. En referencia al objeto datos auto, un identificador razonable podtia ser el numero de serie. EI conjunto de atributos apropiado para un objeto de datos se detennina mediar te la comprensi6n del contexto del problema. Los atributos para auto SiNen btc2' para una aplicaci6n que utilice el Departamento de vehiculos de motor, pero esu. atributos serian inutiles para una companla automotriz que necesite un softw para el control de fabricaci6n. En este ultimo caso, los atributos para auto tal incluirian tambh~n nUmeto dII ..., flJo dII 08ft'0CeI"iI Y color, pero ademas tendrian adidonarse muchos mas atributos (como 06diao int.,;o" tipo dII tNn de manejo, ~ dar dII paquet. de Ijue.e. tipo dIIlran$rniei6n) para hacer de auto un objeto signiticatm en el contexto de control de fabricaci6n

Objete< de date< y clases 00, <SOO 10 mlsmo? Cuondo te deboIe /Xef"CQ de los objeIos de torrOi6n iO(X)l poi CI los cperocioneI que mcnipulcn los datos. es cornUn que wrjo uno Pf89Unta: tvn dcnos implicados por d~ otributol. Adcm6s, 10 objeto de datos IS Ie miuno que uno dose orientodo 0 definiciOn de cIos.es implico uno infroestrudvro compIeio obietm'lc rupueW es no" que es parte del enloque de 10 irogenierio de software orientodo CI oq..o.,. las dCI5e5 se comunicon entre ~ 0 Un objeto de dlJlOl deftne un ~Io compueslo de los dolos; csio C$, if"lCOfPO'"O uno coIeOO6n de elemenlos de trovft de men~; puoden orgcniwr$I en jOfqUkn;
doto$ individuoles (arril;,vtro,.J y do un nombre 0 10 roIecd6n de elementos (el nomJy. del oOieto de doto!.l. Uno dote 00 ~ otribuIos de los dcnos. petO
propotcionon corocterlilicol

heredoda$ para objelol que

son uno in~ia pam uno dow.

'99

ponono
do .....

1-----I ClvtomCM1

at Una c;onexiOn bO~c;o entre obittlos

8.3.3 Relactones
conectados entre sl de muchas maneras diferentes. Por ejemplo, des objetos de datos, persona y auto , pueden representarse can la simple notaci6n ilustrada en la figura 8.Sa. Se establece una conexi6n enlre persona y auto porque los objetos se reiacionan entre 51 <.Perc, cuales son las relaciones? La
Los objetos de datos

estan

respuesta se delermina entendiendo eJ papel de las personas (propietarios, en este casal y de los autos dentro del contexto del software que se conslruira. Se puede
definir un conjunto de parejas ob;eto/~laci6n que deli nan las relaciones relevantes.

Por ejemplo:

Una persona post:t un auto .

Una persona estd asegumda para condue;r un auto

Las reiaciones postX y est4 asegurada pam condudr definen las conexiones relevan

tes entre persona y auto. En la tigura 8.Sb se ilustran estas parejas objeto/relaciOn
de manera gratica Las Oechas de la ligura B_sb ofn::cen informacion importLlnlC acerca de la direccionalidad de la relad6n y a menudo reducen la ambigiiedad 0 las malas interpretacioncs.

8.3.4 Cardinalldad y moda1idad

Los elementos del modelado de datos ---objetos de datos, atributos y relaciones ofrecen la base para entender el dominio de Infonnaci6n de un problema Sin embargo, tambien es necesario comprender informaci6n adicional relacionada con estos elementos basicos_ Hasta esle punto se ha delinido un conjunto de objetos y se han representado las

parejas objeto/relaci6n que los limitan. Pero un simple par que establece que objetoX se reladona con objetoY no proporciona suficiente informaciOn para los pr0p6sitos de la ingen~r1a del software. Se debe entender cuantas ocurrencias del objetoX estan relacionadas con cuantas ocurrencias del objetoY. Esio conduce al concepto del mcx:lelado de datos lIamado cardinalldad EI modele de datos debe ser capaz de representar el numero de ocurrencias de los objetos en una relaciOn dada . TIllmann lTIL931 define la cardinalidad de un par objetotrelaci6n de la siguiente manera: HCardinalidad es la especificacion del nume-

200

,co.."
sitlHKiOR II II

ro de ocurrencias de un lobjeto] que puede reladonarse con eJ numero de ocurr

eias de Olro [objelal" Por ejemplo, un objeto puede relacionarse 5610 con ol ro

malltja Ina

obte-

",Mit, ..
&talos ISto , .
<ioHdo".1a
onrttllda"

to (una relad6n I; I); un objeto puede reiacionarse con muchas objetos (una relae' I :N); un numero de ocurrencias de un objeto puede relacionarse con algDn
numero de ocurrencias de otro objelo (una relaci6n M:N).' La cardinalidad lambdefine "eJ numero maximo de objetos que puede participar en una relaci6n" [TIL931 Sin embargo, no indica si un objelo particular de datos debe participar 0 no en relaci6n. E! modele de datos agrega modalidad al par objeto/relaci6n para especit car esta informaci6n.

..d.solTlS oItjelOS de Hlos?

DJagramas de enUdad-relad6n to poreja obieto-reIoci6n as Ie piedra anguIor

del modeIo de doloa. E~kI~ porejos puedon repreWllarse de monera grOfil medionJ<e eI diogrorno de enliclod...Iocion IDER)? EI DER 10 propno origirdmente Peter Chen [CHE77) poro eI diMi\o de ~slemos de bases relacionoles, y despues oIros 10 hon ompliodo. Con eI DEll
se identifico un conjunb de componenles primclriQ$: ~ de dotos, otributos, r.Iociones e indicooLe5 de WInos hpos EI prop6sib primordiol del DER M representor obietos d. datos. y lUi reIociones.

rlIJIresenIon JXlf' l'Mdio de un ted6ngu&o eriquetodo. Los reIociones se represerom mediGnle uno linea etiquetada que conecb objem. En <JIguncJI voriocione, del DER 10 lineo de conW6n contiene un rombo que ,516 eliquetodo con 10 reIoci6n. los conea:iones .wre objetos de dotos y reIociones 58 estobIecen medionle uno YCIIiedod de simbalos espec:io1e5 que indicon w cordinolidod y

modoIidod.
Poro mCrs informoci6n ~ eI nWJdelodo de dotos y eI diogromcl de entidod-reloci6n elledor inlet'Modo puede

Yo HI ho hocho unCI ;nlrod.,cci6n de 10 nokJci6n n.odimentorio poro eI DER. 1m ~ de ~ se

"",,",,,,, [THAOOJ
que

La modalidad de una relaci6n es de 0 si no hay una necesidad explicita para

ocurra la relaci6n 0 la relaci6n es opcional. La modalidad es I si una ocurrencia de la relaci6n es obligatoria .

.... _ _ I. vtfdad, milatJas que eI promo 15 relatiYa . 1a IiaiaL~

...... _y.
. , . ... III

sidImD. iia"**, cIt .....

SIt .... maf1aWt, ~ _oninrioI 1 _ _ _ .. Ii l nilisis cW ptiKISD .

""' ...... ,... ... '*'" Ia ....... _ . . .

--

Mooe/ado de datos
coroderislicos y reIociones. blul herromienlo, -que I t
uti~ zon 5CIbte todo poro ~ opIicociones de bases de dotos y orros ptO)'edOS de Ji~$ de inl7onnoci6n-

Obj_tivo: los h,rromienlus poro eI modeIodo de dcno, piopoiCOIOl1 01 ingeniero de soItwore 10 copociooo de representor objetos de doIo5, 'IUS

6 For ejemplo, un liD puede I~r muchos sobnnos y un sobrino puede teneT' muchos tias 7 Aunque eiDER toclavla se usa en algunas ap!Jcaoones para el dISeno de bases de datos. en la ac tualidad Ja ootacl6n en UML es \.i mas utilizada para el dlsei\o de datos

cAPfroLo 8

MOOEU.DO OU .... NALlSIS

201

un medio ouIomoriwdo para creor

enlidod'~od6n , diecionorios

OoxI./o,,;g...... de.o.,.,iodo po< 00xI. s,-.

( _.orode.com!. rnodeIo procesos de negocios, enridodes de datos y n!Iociones que se transiormor. en disef'\o$ 0 partir de los cuales se generan aplicodones CXlITIpIeta, y bases de dolol.
~Scope,

de objeloS de

las herromitll'1tos etl eW cotegorfo pefmiten datos y ws reIociones. En .i notoci6n del DER.; en otros

modeIon ~ reIociones por medio de otros

....,

Adem6s permiten

10 0'ICi6n de un rnodeIo

de datos 01 ~r un esquemo de base de datos

repre.entativa.

desormllado po!" M.adrone Systems ! _.mocIronel)'SMrru.comj, M uno hen-omiento para eI rnocIeIodo de dolos de boio cosio que do soporte 0 10 representoci6n grnfico de datos .

~_....~...

ModeISpbere, de$CrroIlodo po!" Magno SoIu~ons GMBH !_. rnogno~ulions.com), do soporte a uno voriedod de hetrcmienlas de rnocIeIodo reIocionol.
YisibieAno/yst, de$(lrrollodo po!" Visible Sy~s !www.visible.com).do 5OpOI'18 0 uno voriedod de funciones de mocIeIodo del onalisil, inc\uioo eI modeIodo de dolo,.

propios y elementos .do, desorroIIodo po!" Embaroxlero SoHwore ~n:odero.com!. brindo qxwtre 01 modeIodo
~reIoci6n.

Cualquier estudio sobre el amMisis orientado a objetos deberia comenzar definiendo el termino orienlado a objetos. tQue es un punta de vista arientada a objetos? t Por que un metooa se cOnsidera orientado a objetos? lQue es un objeto? Cuando la 00 obtuvo una amplia variedad de adeptos durante las decadas de 19BO y 1990, existleron muchas opiniones diferentes (por ejemplo, [BER93). \TAY90J, ISTR88J, IBOO86] acerca de las respuestas correctas a estas preguntas. En la actualidad ha surgido una visi6n coherente de la 00. EI objetivo del analisis orientado a objetos (AOO) es definir todas las clases lademas de las relaciones y el comportamiento asociado can elias) relevantes para el problema y que deben resolverse. Esto se lagra Ilevando a cabo algunas tareas: I . Deben camunicarse los requisitos basicas del usuario entre eJ clienLe y el ingeniero de software. 2. Deben identificarse las clases (es decir. se definen los aLributos y melOOOS). 3 . Se define una jerarqu[a de clases. 4 . Deben representarse las reladones de objeto a objeto (conexiones entre objetos). 5 . Debe modelarse el comportamienLo del objeto, 6 . Las tareas I a 5 se vuelven a apJicar de manera iterativa hasta que el modelo este completo.

8 laS herramientas mencionadas aqui son una muestra de est.J ca.tegona En la mayona de los casas los nombres estim registrados poT sus respealvos desarrol~

202

En lugar de examinar un problema mediante un modele mas convencional tipo entrada-procesamiento-salida (nujo de informad6n) 0 un modele derivado forma exclusiva de las estructuras jerarquicas de informacl6n, el AOO construye modelo orientado a las clases que se basa en la comprensl6n de los conceptos 00

Conceptos orlentados a obJetos

los conc;epros orienlodos 0 objetos (CX es!6n bien e~bleddos en III mundo de Ia ingenieria del $Oftwore. A c:onlinuoci6n se presenlon los deKripciones obreviodos de c;onc;epIo$ 00 que se eowentron c:on frec;venc;io duronte eI modeIocIo del on6lisis. En eI oopitulo lOse presenklO otros objelos 00 que estOn olineodos de monera m6s cercena 01 diseilo de $Oftwore. Atributos: uno ooIeo:i6n de volores de las datos que de!ICriben uno dose. Close: enc;opsulo los dalos y los obSlrocdones de procedimiento reque;ri<b poro deKribir eI c:ontenido y eI comportomienlo de alguno entidod del mundo real. Dic:ho de otro monera, uno dose es uno desaipci6n generolizodo (por ejemplo, uno pIonlillo, un poIT6n 0 un plano de trobojo) que deKribe uno cdecci6n de objekIs
~milore5.

Objetos: instoncios de uno dose MpeCifico. los oe;... heredon ~ otribulos y operoci~ de uno dose. 0per0ciQne,; tombi., tlomoOos mModos y serviciot.. proporcionon 10 representoci6n de uno de los comporlamienlos de uno ,lose. SubcIose: uno espedotiwd6n de lo wpei"dose. I.b, subclose puede heredor tonto los otribulo5 c;omo los operociones de uno wperdose. Superdose: tombi... llomado uno dose bOsko, genernliUJci6n de un c:onjunlo de doses que estr6n relodonodos c:on ella.

Aunque el exito de un sistema 0 producto basado en computadora se muchas formas, la satisfacci6n del usuario encabeza la !ista. Si los iin"en.....', software entienden la manera en que los usuarios finales (y otros acto res) interactuar con el sistema , el equipo de software sera mas capaz de caracter forma apropiada los requisites y construir modelos significativos de analiss fio. Por 10 tanto, el modelado del analisis con UML comienza con la creaci6n cit narios en la forma de cases de use, diagramas de actividad y diagramas de

B.S. 1 Escrttura de casos de uso

Un caso de usc captura las interacdones que ocurren entre los productores sumidores de informaci6n y del sistema en sf mismo. En esta secci6n se forma en que se desarroUan los casos de usc como una parte de la ac:tM modelado del anallsis.9 El concepto de un case de use (capitulo 7) es relativamente fadl de ent cribe un escenario de use especifico en un lenguaje directo desde el pun.,""

Los casas de uso son una parte part!cu!armente importante del modelado de! anoilisls

terfaSC'S con el usuario. EI analisis de la interfaz se trata con detalle en el capitulo 12

cAPfnn.o 8

MOOl.AOO

on ANALlsIs

203

de un actor definido.IO Pero c6mo puede saberse I) .i,sobre que escribir? 2), .i,cuanto escribir acerca de ello? 3), .i,que tan detallada debe ser la descripcI6n?, y 4) .i,c6mo organizar la descriIXi6n? Estas son las preguntas que deben contestarse para que los casas de uso tengan un valor como herramienta para el modelado del analisis.

-.-1... ", ..1:

1III_ J_ ....... lRlayudajllndemirlorpJt exislt . . . siIIIIIIl....lyll .......

....

<.Sobre que escribir? Las primeras dos tareas de la ingenieria de requisitosII -inido y obtenci6n- proporclonan la inronnad6n necesaria para comenzar a escribir casas de uso. Las reuniones para la recopilaci6n de requisi tos, despliegue de la run ci6n de calidad (QFD) y otros mecanismos para la ingenieria de requisitos se utili zan para identificar a los interesados. definir el ambito del problema. especificar las metas operativas globales, esquematizar todos los requisitos runcionales conocldos y describir las cosas (objetos) que manipulara el sistema. El desarrollo de una serie de casos de uso se comienza haciendo una !ista de las runciones 0 actividades que rea!iza un actor especfnco. Estas pueden obtenerse de una Usta de runciones requeridas del sistema por media de canversacianes can las c1ientes 0 usuarios finale s, 0 mediante una evaluaci6n de los diagramas de actividad (secci6n 8.5.2) desarrollados como parte del modelado de! analisis.

II ill 1M \huala d.

Ja_.

i<lu*> ' - .. papol ..' ......"1

MIiII.cIIh:
vigiloncia ItS 10 coso mienlrol tI

10 Un actor no es una persona espec[fica, sinoel papel que de5l!mpena una persona (odisposi tivo) den110 de un contexto especlflco. Un actor "llama al SIStema para entregar uno de sus 5I!rvicios"

ICOCOll
11 Estas tareas de la ingenier1a de requisitos 51! examlNn con detalle en el capitulo 7

PARTE DOS PRAcn::A D LA INGI'NIIlIlA DEL sonwAR!

. . . telo6-"dilCOi

""' .....

~y

~Iico-

....... ~.. haydol

~pnm.a

pIono Ia cma. dolo. "'PC' do bIoq..- 01

~d.un

.,.....

"""
quiero destaar.

...,.ada pen .. 10 Fvnci6n

CaIno aIobMcitnino
~_do~,mo

~E~'M'MO'

" ;

.... 1 0 . _ 1una6n do ....Iancio .... 10._

a..o ...... oc:ceIO 0 10 lvnciOn de

...... let PC 0 d.lnfIIrMt. Sienlo .to uti> ftII6s frwc........

.a inlluitiwl; dicit;

"""""' ................

La funci6n de vigilancia en el hagar de HogarSeguro que se examina en el recua

dro identifiea las siguientes fundones (una lista abreviada) que reaUza el actor ide!tificado como propietarlo de la casa:

Tener acceso a la camara de vigilancla via Internet.

Selecclonar 1a camara que desea ver.
Solicitar vistas en miniatura de todas las camaras.

Desplegar vistas de la camara en una ventana de una PC.

Controlar la visi6n

panoramica y de acercamiento en una camara especifica

Registrar en forma selectiva la salida de camara.

Repetir la salida de camara.

Conforme se reallzan las conversaciones posteriores con el interesado (qua

desempena el papel de un propietario), el equipo de recopilaci6n de requisitos deg. rrolla casos de uso para cada una de las funciones mencionadas. En general, casas de uso se escriben primero en un estilo narrativo Informal. 5i se requier. mayor formalidad se rescrib e el mismo caso de uso utilizando un formato estrucbl rad o similar al propuesto en el capitulo 7 y reproducido en esta secci6n como recuadro. Con fines ilustrativos, considerese la funci6n H acceso a camara de vigilancia-despliegue de vistas de camara {ACV-DVC)". El interesado que desempena el papel d5 propietario podrfa escribir el siguiente relato:

CAPiTuLo 8

MODELAOO DEL ANAusIs

205

Caso de uso: Acceso a dmant de vigllanda-despliegue de vistas de cAmara

(ACV-DVC)

Actor: propietario
5i me encuentro en un lugar lejano pue<lo usar una PC con un software de navegaci6n apropiado para entrar at siUo web de los proouctos HogarSeguro.lngreso mi clave de usuario y dos niveles de contrasenas y, despues de que estoy validado, tengo acceso a toda la funcionalidad de mi sistema HogarSeguro instalado. Para tener acceso a la vista de una camara especlfica selecciono "vigilancia" de los botones despJegados para las funciones mas importantes. Despues escojo "seJeccionar una camara" y se despJiega un plano de planta de Ja casa. Entonces selecciono la camara en la que estoy interesado. En forma altema, puedo ver simulttineamente una !ista con vistas en miniatura de tooas las camaras a! seJeccionar "todas las camaras" como mi opci6n de visualizaci6n, Una vez que he seJeccionado una camara, seJecciono "vista" y una vista de un cuadro por segundo aparece en una ventana, a Ja cual identifica la camara clave. 5i quiero cambiar de camara, elijo "seleccionar una camara" y Ja ventana de visi6n original desaparece y se despliega de nuevo el plano de planta de la casa,

Una variaci6n del caso de uso relatado presenta la interacci6n como una secuencia ordenada de las acciones del usuario. Cada acci6n se representa como un enunciado declarativo, Despues de visitar la funci6n ACV-DVC, se puede escribir:
Caso de uso: Acceso a dunara de vigUancla-despllegue de vistas de cAmara

(ACV-DVC)

Actor: propietarlo
1. El propietario entra en el sitio web de HogarSeguro,

2. EJ propietario introduce su clave de usuario,

3. EJ propietario introduce dos contrasefias (cada una de aJ menos ocho caracteres).

4. El sistema despliega todos los botones de las funciones mas importantes.

5, El propietario selecciona "vigilancia" de los botones de funciones mas importantes.

6, EI propietario elige "seleccionar una camara".

7, 1 sistema despliega el plano de planta de la casa.

8. EI propietario selecciona un icono de camara del plano de planta.

9. El propietario selecciona el bot6n "vista".

10. El sistema despliega una ventana de visi6n, identificado pOT la clave de la camara. 11. El sistema muestra salida de video dentro de la ventana de visi6n con una veloci-

dad de un marco por segundo. Es importante destacar que esta presentaci6n secuencial no considera algunas jnte-

racciones altemativas (la narrativa tiene un flujo mas libre y representa unas cuantas alternativas). Los casos de uso de este tipo se relieren algunas veces como escenarios primarios [SCH981.

-,.~-'

"'_"1150"'"

II58I"st en

mudJOS pl"0(es05 [de softwart1 Nuestro Ivvorito IS un pntISO'" . . lInIhty

Gori_, __

PARTE DOS

PRACOCA DE LA INGf.NIERlA DEL SOFTWARE

Por supuesto, para una camprensi6n completa de la runci6n que se pretende cribir es esencial una descripci6n de las interacciones altemativas. Par 10 tanto, paso en el escenario primario se evalua reaHzando las siguientes preguntas [S<:If' 'I

......" ......
I.C
M

o- st

i.El acto puede ejecutar otra acci6n en este punto? lEs posible que el actor encuentre alguna condici6n de error en este es asi, i.cual podrla ser?

PU,"","

~trM1iv.I "

.dil lIIietItr.s

dHarr.Ha III elst de IS.1

i.Es posible que el actor encuentre aJgUn otro comportamiento provocado aJgun evento ruera de su control? Si es asi, i.cual podria ser? EI resultado de las respuestas a estas preguntas es la creaci6n de un conjunto escenarios secundarios que son parte del caso de usa original. pero que rellre.se'...... comportamlentos alternativos. Por ejemplo, considerense los pasos 6 y 7 en el escenario primario pre,s.""ta~, IIneas atras: . 6 EI propletario elige Hseleccionar una camara H
7, EI sistema despliega el plano de planta de la casa.
;.El actor puede ejecuwr olIo acci6n en este punto? La respuesta es:

cia al relato de flujo libre, el aclor puede elegir ver las vistas en miniatura de t las camaras de manera simultanea. Par ende, un escenario secundario podrla "Ver las vistas en miniatura de todas las camaras".

iEs posib/e que el actor encuenlIe alguna condici6n de error en este punta? Cua un sistema basado en computadora esta en runcionamiento puede ocurrir cuai cantidad de condiciones de error. En este contexto se consideran s6lo las candic:iC" nes de error que pueden ocurrir como resultado directo de las acciones descritas los pasas 6 0 7. De nuevo, Ja respuesta a la pregunta es: "51". Puede ser que nunc::l se haya canfigurada un plano de pianla can iconos de las camaras. Por 10 tanto, elegir "seleccionar una camara" se produce una condici6n de error: H no existe plano de planta configurado para esta casa".12 Esta condici6n de error se convie~
en un escenario secundario. ;.E.s posible que eI OCCor encuenlre a/gun alTo comportamiento en estc punto? De nuevo, la respuesta a la pregunta es: "51", Cuando se realizan los pasos 6 y 7 el sistema puede encontrar una condici6n de alanna. Esto podria resullar en que el sistema desplegara una notificaci6n especial de alanna (tipo, ubicaci6n, acci6n del sistema) y Ie proporcione al actor una serie de opciones relacionadas con la naturaleza de la alarma. Como este escenario secundario puede ocurrir para casi todas las interacciones, no se convertira en una parte del caso de uso para el ACV- OVC. En

12 En este caso, otro actor, eI a dministrador dei l is tema, tendria que configurar el plano de plant. lnstalar e inictallzar (es decir, asignar una ID a cada equipo) para todas las camaras, asl como~ lizar pruebas para estar segura de que cada una de elias es accesible por medio del sistema y a Ira vb del plano de planla

CAPiTuLo 8

MOD1.AOO DEL ANAusIS

207

vez de eso, se desarrollara un caso de usc por separado -"eondici6n de alarma encontrada"-, el eual estara referenciado a otros casos de usc, segun se requiera. En relaci6n con las plantillas fo rmales para los casos de uso que se muestran en el recuadro, los escenarios secundarios se representan como excepciones a la secuencia basica descrita respecto al ACV- DVC.

_ _ de c.uo de uso para la vigthmda

c.ode \nO: Ac:ceso 0 10 c6mon:I '" rigiIcw.cio~ de vistos ......... {ACV-OVCI,

11 EI $istemodespliega 1osaidr:s . . . . . venlono de viwoliMcl6n 0 un cvocIro ~ ExcepcioneJ;

1. La 10 0

,~::~;1 , : ,M ,\it

... """"' "" """';00 o dt

Ir<Ms
InWnet.

... 10 saIi60 de IoJ c6m0ros (... "" a 10 largo de Jo ctl50

<emo1a

Ie" cOM'oMi'laa 101\ if\ICOi . . . . . . ... rec.onocen; 'leo. eI c:mo de uso: ~'" conif"oM!iicl$-,

,... _ .. B _ _ ...... """""""" po< comP-to;,. deben obtener 10 Y

2. La hmciOO de vigi&!mcla 1'IO...a ~ es!e si$lema, 0'[ que eI aisierno ~ de efI'OI' apropiodo;....,.1tI nO d. va

tll'lliillnlil'
...,

.........
wiIam 0

~ apropiodos poro los

10 fvnci6n de vigiIancicf . 3. EI propietario seIo<xiono "Vttr vi1b., I'fIiniaIufo

..(OOfigurof

EI propieIario decide echMe un

W anti mieofras

pora todm 105 lItO: visten en mi"iotvw poro todm Ie. c6mana"

c6moro'" ,. . .

(010.

encuriQ

~
,

=::: "oLR'

..
W

fu.ro de eIIo.

4. No 8$t6 disponible un plano de pIonIo 0 .... ftIt) . . he co"figurodo, od que eI stPemo ~. memoje de 1IfI'"Q( opropiodo; vr60M eI COlO cit UIO "configurar plano de 10 COlO" ,
S. Se encueotra una conditiOn de oKxma; ..... til ctlSO de uso; ~(ondki6rl de aIorma~.

wob do "",",,,,,, 10 de l.IW(Ifio

.. pi api,lt:

io ineroduce dol cootraHlOOs (codo uno

Prioridod:

Prioridod moder-ado, qIM'.

.::::::=::: """""""',
~ . . icIINllilic:ada con

......... adto CUiodeifi). II ...... _pIiIgo todm 1m OOtones de los ~...- ... irnportgn.....

implem. ...... d ~.Ie.

fundOl'le$ b6$k:o$.
Disponible en: Frecueocio de usa:

Elle:liIf" inc1lll!lelOO.
Poco fr&evente.

",";",",~' dolo. bo<ooeo

S,.........io "'-ccioI1O ".oger uno c6moro". B_ dooP.... 01"..,., dolo~, Ii 1M..... io ..6.a:tOIlO eI icono de uno c6moro del "..,., .. pIonio S,...,io lIiKciono.boton .... .ista...

Conal hacia eI odof; A troves de on broww baMtdo en PC y conexi6n de Internet at sitio

wobdoHoga_, Adores -=undoric: Adminimodor del siWma,

c6maras. Canales hocio \c:l$ odore5 secvndorio!;:

a ...... "'liNgo uno...mma de visoolizoci6n

!a 10 de 10 cdmaro.

1. Adminillrodor del siuema: sislema bosodo." PC.

2. COmoros: c::onKtividad

inol6mhm:o

208

PARTE DOS i'RACTICA DE LA lNGENIERfA 00. SOI'TWAR

le

IB'.

."..antno . . pra.g. Q)Nro.l ~ no I I'" I .... CQpaCiWcI pot parte de 105 . . 1.: iD cu..,...:uof -. .............. S ingt'lno no oubizodo
. . . . . ~ :........ , . ...... 10 una invoiiOn . . S . . . . . . . priYoc:idod.

3. dadool_dob 'lo~cW,"::::::~

do_
video a
o~ho

4.

is. d.,o.. oIot6 uno

~

En muchos casos no es necesario crear una representad6n grtlfica de un esceNo rio de uso. Sin embargo, la representaci6n diagramatica puede facilitar la comprt'WI si6n, en particular cuando el escenario es complejo. Como se mencion6 en eJ

cap.

tulo 7, el UML proporciona una capacidad para hacer diagram as de casos de uso pre Iiminar para el producto HogarSeguro. Cada caso de usa se representa mediante

6valo. En esta secci6n 0010 se ha examinado en detalle el caso de uso para eJ Ac\

eve.
8.5.2 Desarrollo de un dJagrama de acUvidad
El diagrama de actividad en UML (que se trat6 en forma breve en los capitu[os 6 y'" complementa el casa de uso al proporcionar una representad6n grafica del flup de intt racci6n dentro de un escenario espedfico. De manera similar al diagrama de flup un diagrama de actividad utiliza rectangulos redondeados para indicar una funcitJ'l espedfica del sistema. flechas para representar el flujo a lraves del sistema, rombol: de decisi6n para mostrar una ramificaci6n por decisi6n (cada flecha que sale ~ rombo se etiquetaj, y lineas horizontales s6lidas para indicar que ocurren acti vida des paralelas.

OIagroma

HogorSegufO

-.
casodeuso

peUm1nar de

p""n'

Aceeso a 10 cOmara de vigilooci<lJl_-fC."""'"

via Ifllerne!

....me

Propieklria

~\

Corofiguror
r6melrO$

de! $isle

HogorSeguro

dela
~~

cAPiTuLo 8

MODEl.ADO DEL ANAusIs

209

Introdocir contrasefla II 10 del usuario

Conlrasenas/IO validas Seleccionar uno iOn irnparloote

Conlrosanas/IO no validas Opei,;,n para rei resc Restan intentes de entrada

Tambien sa pueden sale<:cionar olros funcionllS

""""50"1-","""""".(...-,"'vi Hancia

Vistas lin miniaturo cionor uno comora MpeCifica.istlu en miniatura

Seleccionar una camara IIspecifica Seieccionor un icona de c6mara

Solir de esia funci6n

Vllr olra camara

En la figura 8,7 se muestra un diagrama de actividad para la funci6n de ACV DVC. Se debe resaltar que el diagrama de aetividad agrega detalles adicionales que no se meneionan de manera direeta (pero si implicita) en el easo de uso. Por ejemplo, un usuario puede intentar ingresar la IDusuario y la contrasena s610 un numero limitado de veees. Esto se representa mediante un rombo de deeisi6n debajo de

opci6n para reingreso.

8.5.3 Diagramas de carril
EI diagrama de earril de UML es una variaci6n util del diagrama de actividad. ya que permite al modelador la representaci6n del flujo de actividades descritas por el caso de usa y, al mismo tiempo. indicar que actor (si hay multiples aetores involucrados en una funci6n especifiea) 0 clase de analisis tiene la responsabilidad de la acci6n descrita mediante un rectangulo de aetividad. Las responsabilidades se representan

210

PARTE DOS

PRACTICA DE LA INGENIERIA DEL OClFTWAII

Dlagrama de can1l para 10 tunc:l6n de Acceso a 1a cCunarQ de vig1lanC1a-despUegue It. vistas de cclmara.

PropiMario

Camara

Interiot

Introducir coolro5efio 10 de! usuorio

(:;~;X"Q0"'"~'\________---t~C~OO::':O~::':O~'/~ID~'~61~id~O~.-t----------->'f~
Se
ciOt1or uno

ontroHliios/ID
rIO

v6lioos

Tombien HI>:;;;;:;;;;;:;:;;;;;;;;;;;:.;'
seleccionorc/____L __' "

funci6tl imporlonle

"""',
arras

funciones ' -_ _,

Selecc:fonor vigiloncia
_ _"
No reslon
in!enll:

de entrada

Vislas en
miniaturo
IOI'IOf

Selec:cionor uno

comara ':If>8Cifico

uno dimoro

especifico-vistos
en mlnlaturo

Seleccionor un keno de c6maro

Generar salida de video Visto de solido de cornaro en uno vantono.IP ueloda

Opci6n
fXlro alTa visla

Solir d.
esto funci6n Ver olro

comaro

~<?f>.

C~VE

Ill ........ _ .. 1JMl

.... '*_."

--.s._
.taDlISym

_~"'do

--

como segmentos paralelos que dividen eJ diagrama en forma vertical, como los carriles de una alberca. Existen Ires clases de analisis - Propietario, Interfaz y camara- con responsabilidades directas 0 Indirectas en el contexte del diagrama de actividad representado en la ligura 8.7. Respecto de la ligura 8.8, el diagrama de actividad se reorgani za de forma que las actividades asociadas con una clase de analisis particular pertenezcan al cam! correspondiente a dicha clase. Por ejemplo, la clase Interfaz representa la interfaz con el usuario de acuerdo con la visi6n del propietario. E1 diagrama de actividad considera dos opciones que son responsabilidad de la interfaz: opci6n para el rein-

cAPiroLo 8

MODELAOO DEL ANAusIs

2ll

greso y opci6n para oua vista. Eslas ot>ciones y las decisiones asociadas con elias per-

tenecen al carrH de Interiaz. Sin embargo, las flechas conducen desde ese earril de regreso al carril de propietarlo, donde ocurren las acciones del propietario.

EI modelado de datos orientado al flujo es una de las notaciones de analisis utilizadas con mayor amplitud en la aclualidad. 13 Aunque el diagrama de jlujo de datos (OFO) y los diagramas y la informaci6n relacionados no son una parte formal de UML, pueden utilizarse para complemenl ar los diagramas en UML y proporcionar un conocimiento adicional de los requisitos y el fluio del sistema. E1 OFO tiene una visi6n del sistema del tipo entrada-proceso-salida. Esto es, los objetos de datos l1uyen 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 circulos (tambien llamadas burbujas). EI OFO se presenla en una forma jerarquica. Esto es, eJ primer modelo de flujo de datos (algunas veces llamado un DFD de nivel 0 0 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 nive! subsiguiente.

"S ~ de los diagramos de f1ujo de datos as proporcionar un puente semilntko enlr.1os IlSUGrios ylos '-roladorts de sisttrnos.

8.6.1

Creacian de un modelo de flujo de datos

El diagrama de flujo de datos permite que e! ingeniero de software desarrolle modelos del dominio de informaci6n y del dominio funcional al mismo tiempo. A medida que el OFO se refina hacia grados mayores de detalle, el analista desempena una descomposid6n fundonal impHcita del sistema. Al mismo tiempo, el refinamiento del OFO resulta en un correspondiente refinamiento de datos mientras se mueve hacia los procesos que incorporan la aplicad6n Unas pocas directrices simples permiten obtener una ayuda invaluable durante la creaci6n de un diagrama de flujo de datos: I) el nivel 0 del 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 refinaci6n debe comenzar por el aislamiento de procesos, obietos de datos y almacenamientos de datos candidatos a ser representados en e! siguiente nivei; 4) todas las flechas y burbujas se deben rotular con nombres significativos; 5) se debe mantener la continuidad del fluio de infor-

13 El modelo de flujo de datos es una actividad de modelado esencial en el aniiJisis es rrucrurado.

212

DFDaln1vel de contexto
_ ala

seguridad de HogarSeguro.

_de

,.... '" """'"

ComonOC)I YdoIot

Oe~I.gue

o.~

del uworio

de inforMOCi6n

"" ....... '"

""'M

npo
de oIormo

_
...

""~N

EIIQIuI
doI_~

TOI'oOI ~ nu~ _leI6n.ko

........ ""'"

"_<10111;0
do_debt _wi"",
Ia .made ysaIiOO en 111_ dabaIl. kIs
YdGIl11ll11 riwI

~~VE

..... "'" 101. OID."",..m ..

IIi5am "" 10 droOO

-.

maci6n al cambiar de nivel a nivel;l~ y 6) la refinaci6n de las burbujas debe hacer.;e una por una. Existe una tendenda natural a complicar de mcis el diagrama de flujo de datos. Esto ocurre cuando el analista intenta mostrar muchos detalles demasia-do pronto 0 representar aspectos de procedimiento del software en lugar de e~ mentos del flujo de informaci6n. EI uso del OFO y de la notaci6n relacionada se iluslra de nuevo considerando la funci6n de seguridad en el hogar de HogarSeguro. En la figura 8.9 se muestra un OFD al nivel de conlexto para la funci6n de seguridad. Las entidades extemas primarias (cajas) producen informaci6n para el uso del sistema y consumen informaci6n que este genera. Las flechas rotuiadas representan objelos de datos 0 jerarquias de objelOS de datos. Por ejemplo, comandos y datos del usuarlo abarcan todos los comandos de configuraci6n, lodos los comandos de activaci6n/desactivaci6n, todas expandir un las interacciones y lodos los datos que se ingresan para calificar comando. EI OFO de nivel 0 ahora se expande a un modele de flujo de datos de nivel 1. iPero c6mo se logra esto? Un enfoque simple, pero efectivQ, es realizar un "amilisis gramaticai" [ABB83J sobre la narrativa que describe la burbuja al nivel de contexta. Esta es, se alsian lodos los sustantivos y verbos en la narrariva de procesamiento de HogarSeguro l5 oblenida durante la primera reuni6n para la recopilaci6n de requisitos. Can prap6sitos i1ustrativos, cansiderese el siguiente texto narrativa de procesamienlo can la primera aparici6n de lodos los sustantivos subrayados y Ja primera aparici6n de lodos los verbos en ilalicas. 16

14 Esto es, los objetos de datos que fluyen hacia el sistema 0 cualquier transformacion en alglin nivel, deben ser los mismos objetos de datos (0 sus partes constituyentes) que fiuyen hacia la transformad6n en un mvel mas refinado I S Una narrativa del procesamiento es similar en estno al caso de uso, poero algo diferente en Pr0p6sito. La narraliva del procesamiento proporciona una dc:scripct6n general de la funcien que sera desalTollada. No es un escenario escrito desde el punto de vista de alguno de los actores. 16 Debe noLarse que se omiten los susta ntivos 0 vemos que son sinooimos 0 que no tienen una ingerencia directa en el proceso de modelacien Tambitn se debe notar que, ruando se considere el modelado basado en clases de la seecien 8.7, se usara un amilisis gramaticai similar

C APiTuLo 8

MODELAOO DEL ANAuSIS

213

La (undOn de sCiuridad de H~arSciuropmrrite al propjetarjo configumrel sjstema de se~

cuando i!:ste se instala, moni/orear lodos los sensores que se conectan al sistema de seguridad y que inleroctuan con el propielario a travi!:s de l.rlkrnet, una .I::'C 0 un paru:l de control.

Durante la jnstalacjOn, la PC de HogarSeguro se utiliza para programar y configurar el A cada sensor se Ie asigna un tlWrua:Q Y.tiIKt, se programa una contrasefia ma.cilia. para habilitar 0 deshabiJitar el sistema, y algunos oUmeros telefOnjcos ingresan para marcarse cuando se presenta un eyento en los sensores.
~.

Cuando se ra:onoce un evento en los sensores, el software solicita una alarma aydible que el propietario especifica durante las actividades de configuraci6n del sistema, el software marca el numero telef6nico de un servjcio de monjtoreo, proporciona informaci6n acerca de la ubicaci6n. reporta la naturaleza del evento que se ha detectado. EI numero telef6nico se remarca cada 20 segundos hasta que se obtiene una conexi6n telef6nica. EI propietario ra:ibe informaciOn de seiyridad a traves de un panel de control, la PC a un buscador que en forma colectiva se denomina una.in.lerfaz. La interfaz despliega men:. sajes de o.pciOn e informaciOn del estatus del sistema en el panel de control, la PC 0 la ventana del buscador. La interacciOn del propietario asume la siguiente forma .. En relaci6n con el analisis gramatica! comienza a surgir un patr6n. 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 0 de control (f1echas), 0 almacenamientos de datos (!ineas dobles) . Despues debe observarse que los sustantivos y verbos se puedan asociar de distintas formas

Comandos y dotos d,,1 usuorio ...

Configwor sistema
_~-...._ _~,,-..:Configufaci6n

SOliCltUd~ ' ___ ~=~~~~~::::~::~ Con iguraci60 de in rmaciOn confieurf'~

de aotos

" .....~. .,Iniciar Controser'i detener

Configuroci60 de datos

de 10 va ido Configurocibn de dotos

Mo"~I

InformaciOn

del
~.. I--o~c---~ EstoNs del sensor

A1arma

SoenKif

TIpo de olorma
10lI05

del numero

telef6nico

lIneo telefOnieo

2.4

PARTE DOS

i'RACTlCA DE LA INGENIERiA 00. SOFTWARE

OFD de mvel 2 que reUna 81

_de
monlto<oo de sensores.
InformaciOn de configuroci6n
Do~,

de$pliegue

Formato para eI

lnlormoci6n del senSO!'

Tr
alormc
Numero

de configuration

telef6nico
IO,lipo de sen$Or

TonO$ de

numeral

IeleF6nieos

f:..wo. .
51 debe IllnIr /0 ,..m.I~ .. .., /0 IIllflQriwI de {XOC,.
.scmisnID IP8 SIt iJlWIl ootzrx es1fJ esaitIJ con tI mismo ~

entre 51. Por ejemplo, a cada sensor se Ie asigna un numero y un tipo; por 10 tanto. el nCimero y el tipo son atributos del ohjelo de datos sensor. Enlances, al realizar un

anillisis gramatical sobre la narrativa de procesamiento para una burbuja en cualquieT nivel del DFD, se puede generar mucha informaci6n uti! acerca de c6mo proceder con la reflnaci6n para el siguiente nivel. En la figura 8. 10 se presenta un OFD de nivel I para el cual se ha utilizado esla informaci6n. EI proceso at nivel de can texto mostrado en la figura 8.9 se ha expandido a seis procesos obtenidos de un exa~ men del analisis gramatical. De manera similar, el flujo de lnformaci6n entre los procesos en el nlvel 1 ha side obtenido del analisis. Ademas, se mantiene la continuidad del flujo de informaci6n entre los niveles 0 y 1.

... . "'...

Los procesos representados en el OFD de nivel I se retinan despues hacia niveles mas bajos. Por ejemplo, es posible retinar el proceso monitorear sensores hacia un DFD de nivel 2 como se muestra en la tigura 8.1 1. De nuevo, debe sef\alarse que st mantiene la continuidad del flujo de informaci6n entre los niveles. La refinaci6n de los DFD continua hasta que cada burbuja realiza una sola fun ci6n; es decir, hasta que el proceso que representa la burbuja desempene una funci6n
que podria implementarse can facilidad como un componente de programa. En d capitulo 9 se examina un concepto. lIamada cohesi6n, con el cual se evalua la simplicidad de una funci6n dada. Por ahora, se busca retinar los OFO hasta que cada burbuja tenga "un solo significado".

8.6.2 Creacton de Wl modelo de control del Oujo

En muchos tipos de aplicaciones el modelo de datos y el diagrama de flujo de datos son todo 10 que se necesita para obtener una visi6n significativa de los requisitos del

cAPiTuLo 8

MOOELADO DEl. ANAus!s

215

software. Sin embargo, como ya se ha mencionado, existe una c1ase muy grande de aplicaciones que esttm guiadas por eventos en lugar de datos, que producen informaci6n de control en lugar de reportes 0 despliegues, y que procesan informaci6n con un especial interes por el tiempo y el rendimienlo. Oichas aplicaciones requieren aplicar el modelado de control del flujo, ademas del modelado del flujo de datos. Va se ha mencionado que un evenlo 0 elemenlo de control se implementa como un valor booleano (por ejemplo, verdadero 0 falso, encendido 0 apagado, 1 0 0) 0 una !isla discreta de condiciones (vado, saturado, lIeno). En la selecci6n de los eventos que son candidatos potenciales se sugieren las siguientes directrices: Hacer una lisla de todos los sensores que el software "lee". Ustar todas las condiciones de interrupci6n. Uslar lodos los "interruptores" que maneja un operador. Uslar tcxl.as las condiciones de datos.

De acuerdo con el analisis de sustantlvos y verbos aplicado a la narrativa de procesamiento, revisar todos los "elementos de control" como posibilidades de entradas y salidas del control de flujo.
oescribir el comportamiento de un sistema mediante la idenlificaci6n de sus estados; determinar el grado en el que se alcanza cada eSlado, y definir las transiciones entre los estados. Enfocarse en posibles omisiones -un error muy comun al especificar el control-; por ejemplo, se puede preguntar: "iexiste alguna olra manera de alcanzar este estado 0 salir de el?".

8.6,3 Espec1ficacion de control

La espedjicadon de control (EC) represenla el comportamiento del sistema (en el nlvel desde el cual esta referido) de dos maneras diferentes. l1 La EC contiene un diagrama de estado que es una especificaciOn secuencial del comportamiento. Tambien puede contener una tabla de activaci6n del programa: una especificaci6n combinaloria del comportamiento.
En la figura 8.12 se mueslra un diagrama de estado preliminar ' 8 para el modelo de control del flujo en el nivel I para HogarSeguro. EI diagrama indica c6mo responde el sistema a diferentes eventos conforme este atraviesa los cuatro estados definidos en este nivel. Al revisar el diagrama de estado. un ingeniero de software puede determinar el comportamlento del sistema y, aun mas importante, puede encontrar si existen "hoyos~ en eJ comportamiento especificado.
11 oespub, en este mismo capItulo, se pre:senta notaci6n adicional para el modelado del comportamiento 18 La notad6n para el dlagrama de estado se: muestra aquI de COflforrnldad con la notad6n del UM!.. En el analisis estruaurado se: cuenta con un d~ de ~ de estado", pew el forrnato del UML es superior en contenldo y ~ de mformaci6n

"6

PARTE DOS

PRAcnCA DE LA INGENlERlA DEL 50FTWARE

-- Inltoo/para,

D1agrama de estado para 1a tunct6n de sequrldad de HogarSeguro.

fnlJOl'/>ndar E_........... "iliac*><>'

E,*or/iroir:io< .. .p~ ..... l
.... IC~ .. _

.w_o

,,
&-ar/onio;ior ~"''''
G " d I.dQ/looo' j

R_nldc

""*"'00

e..../iIIOeb"o..p~

n" 'inoe!Ioo'

i,I-U~'

~t_

.. ";08

",......... 2

Ennr/O\iciQr dHpIlego ......... 2

"!'lor ""- 'If*'"' E ....... ~ ....~llIoo(_ .......

f_t"'t<:ior.,p .... ..t_ ......

Hoctor:

....

_dIago~

f~ "1O(O'

01

~"'2

_.... ,1.1.

___
d'

""-

~-

&,.0,./_ _ _ ' _ ' E"ffor/Wc"'~ ' ...... I..,.....!o

bJro</in'CIOt ~2 ,.
Hoc::.._y~

.........

n.".t_dHpI~"""
G~

/fodad._. .

..,ocic,r...,porimcb

fmoorf\NciGr e - fnfrOl/"'ld... 18

.,11_- " deooch="""'

!1

_. . . ..
= ""
",.1

for/_doo 8 t.... doop:oodor ..... _

D 'I':..pdo

E_I_~

" ' -............_'fConIrOlorSi _

ttoc.r~",,_~

_.............

'--Y~ . """"'. ""11" ", '

U
Por ejemplo. el diagrama de estado (figura 8.12) indica que las transiciones desdt el estado desocupodo pueden ocurrir si el sistema se reinicia, activa 0 apaga. Si el sis--

tema se activa (es decir, se enciende el sistema de aianna) ocurfe una transicD

hacia el estado MoniloreoEstalusSislema, los mensajes que se despliegan cambian como se mueslra, y se solicita el proceso SislemaControiyMoniloreo. Con el estado Moniloreo Strolus Sistema ocurren dos Iransiciones: I) al desactivar eJ sistema se presenta una Iransid6n de regreso al estado desocupado; 2) cuando se dispara un sensor ocurre una transid6n hada el estado Acci6nEnAlanna. Durante la revisi6n se consideran todas las transidones y el contenido de todos los estados.

1jIiI...... "'..Jl'rlJo de d'01

La ......

]I' 1

cAPiTuLo 8

MODELAIX> DEL ANAusis

217

lei: .De .,...dodt

-~,,,...,pn-"'-'''''''''''' dean6lisi~~,y"'_I0 ...

Vinod: Bueno,"
quo

.." __ . ".;,. ...... _1_ ..... """" """' """'"". ""'!

-.10 ' - .... do.., .
(Doug -.I gerentI! de if9lllierio cIoI , ...

_dol

cvbttvlo.)

~~~~,~,:::;~::".j
Jamie (con uI.a; Yo oc........ 2 ...
...... "'", _ .. M .......

poOI1o

mocho tiempo para hcac:-'ca.

1~~i'vriow'~dMn . . . . .

oonrionl

La EC describe el comportamiento del sistema, pero no brinda informad6n acerca del trabajo interior de los procesos que activa. La notaci6n de modelado que proporciona esta infonnaci6n se estudia en la secci6n 8.6.4.

8.6.4 Especificaci6n de proceso

La espedjiruci6n de proceso (EP) se utiliza para describir todos los prcx:esos del modelo de flujo que aparecen en el nivel final de refinaci6n. EI contenido de la especificaci6n de proceso puede incluir texto narrativo, una descripci6n en lenguaje de disei'lo de programas (LOP) 19 del algoritmo del proceso, ecuaciones matematicas, tablas, diagramas 0 graticas. Al proporcionar una EP para acompai'lar cada burbuja en el modelo de flujo, el ingeniero de software crea una "miniespecificad6n" que puede selVir como guia para el diseno del componente del software que implemen-

-::::.::~eI

tara el proceso. Para ilustrar el uso de la EP, considerese la transfonnaci6n procesamienlO de contraseiia representada en el modele de flujo para HogarSeguro (figura 8. I 0). La EP para esta funci6n podria tomar la fonna:
EP: procesamiento de conuasefta (en eI panel de control). La transformaci6n

pro-

cesamietlto de contrasdla valida la contrasei'la en el panel de control para la funci6n de se19 EJ lenguaje de disei'oo de programas (tDl') mezda 1a SlntaxlS del lenguaje de programaci6n con la narrativa en texto para proporcionar detalles del disei'io del procedlmiento. EllDP se estudia en el

capitulo II

PARTE DOS
gurldad de

PRAcnc.... DE I-' 1NGENlERlA. DEL SOFTWAAE

HogarSegUro.

El procesamiento de contrasena recibe una contrasei'la de cuatro

dlgitos a partir de \a funci6n de

interocd6n con eI usuano.

La contrasefta se compara pri -

mere con la contrasei'la maestra almacenada en el sistema 5i la contrasei'la maestra coincide IMensaje de 10 valida _ verdadero] se pasa a la funcl6n de mensaje y despliegue del
eslOIUS. 5i la contrasei'la maestra no coincide, se comparan los cuatro dlgitos con una ta-

bla de contrasei'las secundarias (eslaS se pueden asignar a invitados 0 trabajadores que necesitan entrar en \a casa cuan do el propietario no este). 5i la contrasena coincide con alguna entrada dentro de la tabla Imensaje de Id valida _ verdadero]. se pasa a Ja funci6n de mensajey desplieguc del

esfatus. 5i no existe alguna coincidencia Imensaje de ld valida

_ falso), se pasa a la funci6n de mensaje y despJiegue del estatus.

Si en esta etapa se desean tener detalles algoritmicos adicionales, se podria inc1uir tamblen una representaci6n en lenguaje de diseno de programas como parte de la EP. Sin embargo, muchos proresionales del software creen que 1a versi6n en LDP ~ puede posponer hasta que comience el diseiio de componentes.

Ancil1sls estructurado
Herromientas rep.-.sentativos20
AxiamSys, desorrollodo por STG, Inc. (WWW.$fgcOHl.com). proporciono un poqueto camplell) de herromientos poro eI on6lisis de 10 eslrudura que irICluye extensiones de Horl!ey-Pirbhoi paro eI modeIodo de sinmos en liempo reoL
A-1ocA&D, WinA&D, de$Orrollocb par Excel Software (www.excelsoftwore.cam), proporcionan un coniunlo de henamienlos simples y borolos pora eI on6lisis y eI di5ei\o en m6quincn Moe y Windows.

Objetivo: l.eu helTllmientos del onillisis estrudurado oyvdon 0 un ingeniero de software o crear modeIes de dalos, modeIes de fluto y modeIcn de camp::lrtamienlo de una monera que permila 10 veri~cad6n de Ia continuidod y Ie consislencia, asi como su f6cil ecliciOn y e.xtensiOn. los modelos creodos ulilitondo ~s helTllmieotas brindon 01iogeniero de software uno visiOn de 10 rtlpf"esefltoci6n del 0061isis y oyvdon 0 eliminor errores ontes de que eslas HI propoguen en eI disefio 0 , oun peor, en Ia misma implementociOn. Mec:anico: Los herramienlos de eslo cotegorio utitizon un ~dicciooorio de dalo$" como Ie boHl de datos centrol poro 10 descripci6n de todos los objetos de dalas. Uno vez que las entrodos del diccionorio estOn delinidas, pueden creorse diogromos de entidodreIociOn y HI pueden desarrollor los jerorqulos de objet<. los corocteristicos de diogromoci6n del Ruio de datos permilefl creor f6cilmenle esle modeIo gr6rico y lambien proporciono coroclel'"is~cos poro 10 creociOn de especj~cocjones de controllEC) y especil1cociones de procew IEPJ. los helTORlientos de CWl6Iisis ~ ayudon 01 ingeniero de software en 10 creaci6n de modelos de compartomiento que usan los diogromos de eModo como noloci6n operotive.

MeIaCASE Workbench, desorrollodo par MeiocOHl

Consulting (WWW.meIocoHl.com) es una metoherramienlo utilizodo poro delinir un metoda de on6lisis 0 diseilo (induido en on6lisis es/nldurodoJ: sus conceplos, reglas, notociones y generodores. System Arcni/ecl, desorrollodo par Popkin Softwore (www.popkin.com). proporciooo un omplio ronga de herromienlos de on6lisis y diseno, induye herromienlas pora el modeIodo de datos YeI o06lisis estrvcturodo.

20 la5 helTamientas mencionadas aqul representan una muestra de esta categor!a. En la mayoria de 105 casos \os nombres est.in reglstrados por sus respectivos desarrolladores

cAPiTuLo 8

MODElAOO DEL ANAusrs

219

iQut se debe hacer para desarrollar los elementos basados en clases de un modelo de analisis: clases y objetos, atributos, operaciones, paquetes. modelos eRe y dia gramas de colaboraci6n? Las secdones siguientes presentan una serie de directrices infonnales que ayudanln a identificarlos y representarlos,

8.7.1 Ident111caci6n de c1ases de an6:lisis

AI observar el interior de una habitaci6n se vera que existe un canjunto de objetos fisicos que pueden idenlHicarse. clasilicarse y definirse con facilidad (en terminos de atributos y operaciones). Pera cuando se "observa~ el espacio del problema de una aplicaci6n de software, quiza las clases (y los objetos) sean mas difkiles de comprender.

"S proWema reo!mente difkd IS dtsc:ubrir (00185 son 1m objel05 cOI'rectos [doses] en primer Iugor!

Se puede iniciar la identificaci6n de clases al examinar el enunciado del problema 0 (de acuerdo con la l enninologia aplicada previamenle en este capitulo) al rea lizar un "analisis gramalical" sobre las narrativas desarrolladas para el sislema que se va a conslruir 0 de los casos de uso. Las clases se delenninan al subrayar cada sustantivo e inlroduciendolas en una simple tabla, Los sin6nimos deben anotarse_ Si la clase se requiere para implementar una soluci6n, entonces es parte del espacio de soluci6n; por otro lado. si una clase s610 se necesita para describir una soluci6n es parte del espacio del problema. ,Que se debe buscar despues de que todos los sustantivos han sido aisiados? Las clases se manifiestan en una de las siguientes formas:

_ .......

1M .....

Entidades exfemas (por ejemplo, otros sistemas, disposilivos, personas) que producen 0 consumen informaci6n que usara un sistema basado en compuladora. Cosas (por ejempJo, reportes, despliegues, letras. seriaiesj que son parle del dominio de la informaci6n para el problema. Sucesos 0 eventos (por ejemplo, una transferencia de propiedad 0 la consecuci6n de una serie de movimientos de robot) que ocurren dentro del contexto de la operaci6n del sistema. Popeles (por ejemplo, gerente. ingeniero, personal de ventas) que desemperian personas que inleracluan con el sistema Unidades organizacionaJes (por ejemplo, diviSl6n, grupo, equipo) relevanles para alguna apJicaci6n. Sitios (por ejempio. el piso de manufaclura 0 el puerto de cargal que establecen el contexto del problema y Ja funca6n global del sistema

 Estructuras (por ejemp[o, sensores, veh!culos de cuatro ruedas 0 computadora9

que definen una clase de objetos 0 clases de objetos relacionadas. Esta categorizaei6n es una de las muehas que se han propuesto en la bibliograna Por ejemplo, si los desarroJladores del software para un sistema de observaci medica definen un objeto con e[ nombre de lmagenlnvertida 0 Inversi6ndelmagen,. podrian estar eometiendo un error sutil. La Imagen obtenida del software podrtl. por supuesto, ser una c1ase (es una cosa integrante del dominio de la informaci6n
La inversi6n de la imagen es una operaci6n que se apliea a la c1ase. Probablemente: la inversi6n( ) se definiria como una operaci6n para la c1ase Imagen, pero no se esta-

bleceria como una c\ase diferente para connotar ~ inversi6n de imagen

Como esta-

bleee cashman ICAS891 : H EI objetivo de la orientaci6n haeia los objetos es encapsular, pero aun as! mantener separados, los datos y las operaeiones sobre los datos.. Para ilustrar la forma en que [as dases de antilisis pueden definirse durante las primeras etapas del mode!ado, se utiliza de nuevo la funci6n de seguridad de HogarSeguro. En la secci6n 8.6.1 se realiz6 un "antilisis gramatical" sobre la narrativa del pracesamienlo2l para la funci6n de seguridad. Al extraer los sustanlivos se puede proponer una serie de ciases potenciales:

Close potential
p<opletorio

CIo,ificoc:ian general
popel 0

eolldod exlefno

entldad eKtefno

rxmel de

contr~

e ntidod e)(terno

in ~loci6n

~i~lemo lolkls si.slemo numero, tipo

conlro~ JTIOEI!>IrO

de .5eglJododl

mimero IeIef6nico
e-.<enlo

del
de

se!1S01

ocurr9flC1O

ola,mo ooxlible
~icio

enhdod eKlefno IJnidod orgonizociorlol 0 E!f1 tidad e)(temo

monilOfeo

La !isla podria extenderse hasta que todos los sustantivos en [a narrativa del pracesamiento hayan side eonsiderados. Obstrvese que cada entrada en la [isla ha sido

21 Ora categorizaciOn imponante ~la cual define entidad, frontera y clases de con trolador~ se examina en la secci6n 8.7 4 22 Es importante notar que esta tecnica debe usarse tambien para todos los casos de uso desa rroH ados como parte de la actlvidad para la recopilaci6n de requisltos (obtenci6n). Esto es, los casos de uso pueden analizarse gramaticalmente para e)(traer clases de an;ilisis potenciales.

cAPiTuLo 8

MODll..ADO on ANAusIs

Ilamada como un objeto potencial. cada uno de ellos debe considerarse a fondo antes de tomar una decisi6n final.

...

Coad y Yourdon [COA911 sugieren seis caracteristicas de selecci6n que se deben usar cuando un analista considera cada clase potencial para incluirlas en el modelo de analisis:
l.

Infonnad6n referida. La clase potencial sera uti! durante el analisis s610 si la infonnaci6n ace rca de ella debe recordarse para que el sistema pueda funcionar.
identificables que puedan cambiar el valor de sus atributos de alguna manera .

2. 5ervidos requeridos. La clase potencial debe tener un conjunto de operaciones

,""'1

IIICI

3. Atributos multiples. Durante el analisis de requisitos el enfoque debe estar en la infonnaci6n "importante"; una clase can un solo atributo puede, de hecho, ser uti! durante el diseiio, pera probablemente es mejor representarla como un atributo de otra clase durante la actividad de anaiisis. 4. Ar.ributos comunes. Es posible definir un conjunto de atributas para la clase potencial, y estos atributos pueden aplicarse en todas las instancias de la c1ase.
5. Operaciones comunes. Es posible definir un conjunto de operacianes para la clase potencial, y estas operaciones pueden aplicarse en todas las instancias de la clase.

6 . Requisitos esenciales. Las entidades externas que aparecen en el espacio del problema, y que producen a consumen informaci6n esencial para la aperaci6n de cualquier soluci6n para el sistema. se definiran casi siempre como clases en el modele de requisitos.
Considerarla una clase legitima para incluirla en el modele de requisitos requiere que una clase potencial satisfaga todas (0 casi todas) estas caracteristlcas. La decisi6n de incluir clases potenciales en el modelo de analisis es alga subjetiva, y una eva luaci6n posterior puede ocasionar que se descarte a reinstale una clase . Sin embargo, el primer paso del modelado basado en clases es la definiciOn de clases, y se deben tomar decislones (incluso subjetivas) _Con esto en mente, se aplican las caracleristicas de selecci6n a la [isla de clases potenciales de HogarSeguro:

Cia potencial
propoelOrio

Numet'O de caracteri.tica que aplica

rechozodo 1 Y 2 kJlan ounque ophco 6

ocepbdo Iodos apIocoo
OC8!.' L Iodas opIocoo
I

"""'" pone! de control

222

PARTE DOS

PRAcncA D IA 1NGENlEl!!A DEL SOf"tWARE

,~horodo

,f\,\lobciOn

sistema 101 ,05 lur.ciOO de segurldodl

numero, ('po
000110$000

oceploch IOdos ophcon rechozado lallo 3, a~ibulos dd sensor

maestro

rechazodo folia 3
rechozoda:

nUmero telef6nico

10110 3

del $erl$Of olormo audible

evenlO

ocepIOdo. todos oplican

oceplOdo apli<:on 2, 3, 4, 5, 6
recholodo 1 y 2 lollon ounqlle aplice 6

5e debe senalar que I) la lisla anterior no esta completa (se tendrian que agregar ses adicionales para tenninar el modelo) ; 2) algunas de las clases potenciales recl zadas se convertiran en atributos para las clases aceptadas (por ejemplo, roe.tipo son atributos de sensor, y conlresefia maestra y nUm&I"O felef6nloo se pueden co'",,tir en atributos de sistema) ; 3) la existencia de enunciados diferentes del p",b~..~ podria ocasionar decisiones dislintas de "aceptaci6n 0 rechazo" (por ejemp\o, SI propietario l uviera una con trasei'ia diferente 0 si pudiera identificarse por su voz clase Propietario satisfarla las caracterlsticas I y 2 Y esta habria side aceptadal

8.7.2 Espec1ficacion de abibutos

Los atributos describen una clase que ha side seleccionada para inclui rla en

&,

modelo de analisis. En esencia, los atributos son los que definen la clase, 10 cual rifica que significa la clase en el contexto del espacio del problema, En el desarrollo de un conjunto de atributos
sign ifi cativ~

c.a

"~ C&VE

para una clase de anal.

sis un ingeniero de software puede estudiar de nuevo un caso de uso y selecciONlli aquellas "cosas" que "pertenecen" de manera razonable a la clase. Ademas. se debt conlestar la siguiente pregunta para cada clase: ,Cuales elementos de datos (com puestos 0 elementales) definen esta c1ase en el contexte del problema? Esto se i luslra considerando la clase sistema definida para HogaTSeguro. Se ha mencionado que el propietario puede configurar la funcion de seguridad para reflejar la infonnacion del sensor, infonnacion de la respuesta de alanna, infonnaci6n de la activaci6n/desactivaci6n, informaci6n de la identificaci6n, y asl sucesivamente Estos elementos de datos compuestos se pueden representar de la siguiente manera
infO!"mllOi6n de identlfioloi6n .. ID del 8l8t_

.. ....

los atributos SCtl eI

COI\lOOto de objetos de

00105 cpJe de~flEn par ~ .". clenlro del conIexto del

del I1Umero telefOnioo + .t.ru,

de/am_
Informeci6n de .. reapUMt. de IIhIrma = tMmpo"
aibl"

mr.o + I1Umwo tNfOnioo

+ nUmero d, interJtOll ptrmi-

inforrn.ci6n de I. lICfill.ol6nl~ ., oon~ ...-tra

+ oontl1Hlen.

Iltnporlll

Algunos de los datos a la derecha del signo de igual podrian refinarse hasta un nivel elemental. pero para los prop6sitos de este capitulo constituyen una !ista razonable de atributos para la clase sistema (parte sombreada de la Iigura 8. 13)

CAPiTuLo 8

MODElAOO DEL ANAusis

223

Los sensores son parte del sistema global de HogorScguro, yaun asl no estan enlistados como elementos de datos 0 como atributos en la figura 8.13. Ya se ha definido sensor como una clase, y varios objetos de sensor se asociarim con la clase sistema. En general, se evita la definici6n de un elemento como un atributo si mas de uno de los elementos se asociara con la clase.

8.7.3 Def1nlcj6n de operac10n0s

Las operaciones definen el comportamiento de un objeto. Aunque existen muchos tipos distintos de operaciones, estas se pueden dividir, por 10 general, en tres grandes categorias: I) operaciones que manipulan los datos de alguna manera (por ejemplo, al agregar, borrar, reformatear, seleccionar), 2) operaciones que realizan un c6mputo, 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 0 asociaciones (5eCci6n 8.7.5). Por 10 tanto, una operaci6n debe tener "conocimiento" de la naturaleza de los atributos y asociaciones de la clase. Como una primera iteraci6n en la obtenci6n de un conjunto de operaciones para una clase de analisis, el analista puede estudiar otra vez la narrativa de un procesamiento (0 caso de uso) y seleccionar aquellas operaciones que pertenezcan de manera razonable a la clase. Esto se logra estudiando de nuevo el analisis gramatical y aislando los verbos. Algunos de estos verbos seran opeiones legitimas y podran conectarse con facilidad a una clase especlfica. Por ejemplo, en la narrativa del procesamiento presentada parrafos atras en este capitulo, se observa que "al sensor se Ie asigna un numero y un tipo" 0 "se programa una contrasena maestra para habiJitar y deshabilitar el sistema". Estas frases indican algunos hechos:

Sistema
fD Ii"-a v.rificoci6nNUmero Telef6nko
~"'uislMno
liempoi,,*OiO

N~IJ6nico
eo.~ ConIfcuel'.aN;iipOi 01

N,,"-adeHl... iIos Pfogromar( I desplegor( I reinicior( I bllscorll modilicor( I llamorl I

224

Que una operaci6n de asignar( J es relevante para la clase sensor. Que una operaci6n de programor( ) esta encapsuJada por la clase sistema.

Que habililar( ) y deshabilitar( ) son operaciones que se apllcan a Ja clase

sistema.
En una investigaci6n posterior tal vez la operaci6n programar( ) sea dividida

serie de suboperaciones mas espedficas que se requieren para configurar el

Por ejemplo, programar( ) implica Ja especificaci6n de numeros telef6nicos, la guraci6n de caracteristicas del sistema (como a\ crear la tabla de sensores, aJ

ducir las caracterislicas de Ja alarmaJ y la introducci6n de contrasena(s). Sin go, por ahora programar( ) se especifica como una sola operaci6n.
HOGARSEGURO

.......... Cubicu!o de Ed, 01

"'--

do _

.......... p.... ... '~ .....i~

Ed.. miembros del equipo

......

"" ...... do .m.,o, ,.., Nolo .....

woIoo M _ pored Moe unos

;~~i~
.._

_do~IIao

~ylo:;~::~~!::==== Po,.. como I i

atribuIoo_

'd'SI, I o . _ . . . . . . . .

do ~ plano ~-~ do pia"", Ho

.... a P1Dnta. AqlJ f esl6
8.IA.)

ITlOIIimiento y eI OC*~ una 10, pero VInodo - len oIfm Id, IIomooo _ _ . _ . . ..

"::l=;:"~1

propOsitos cW despIi.gue.

....... "" i~S"i-~~'~~I"~_~~""E"""~~-~ q"""

'1~ io&c:6moros;
".,

Jamie: T.... ...., pcwa

IJamooIao

. . . . "4IIOCiaciones.. Lot.

Ic.. osociocionet
~

."'"

c_

SoeglJrOldeque

lei: No esIo)I

seguro" c6mo t.-Ia

""'.'1III1IIii

No - QffOI" 10. Le$ mo5trari.

CAPiTuLo 8

MODELAOO DEL ANAusIS

225

PlanodePlanta
"po
~ Dimensionese~1emcn

...

delerminorTipo( ) potidonorf'lonoc!ePlOf,to( i e~!or( ) c.ambior color( )

Se ubica dentro de

I
"

E_ porte de
Pa..d
WmenWontipar.,d

CComa...

it'

~~~
Acerc"m'ento

ubic.=
~

VisiOn
~FncrTipo! ) eoblorOimenll,,"lu( )

t'te<m~Un{ )

a~:t9,~1

Se u!<l por"
c.on.trui,

r-":III'c.om;.nfoj )

tipo Coordenodo&inicio Coordenodcufincl Sigu1lll'>te$egmenlO

,~

...... ........ ..

Se U!<l po,a con_truir I

_lano

Se u!<l pom ... construir

V...-

tfpo
C~rc:i"
Coordenodos~nol

"po

C~ink;io

SiguienteVentoroa delerminorlipol i dibujor

CoordenCKbfincl Si9'Ji... tePuerto d.terminorllpo{ ) dibujOf

d_m,r>Qfnpo( J dibujar

8.7.4 Modelado de Clase-Responsab1lidad-Colaborador (CRC)

El modelado de
dase~Responsabilidad-Colaborador

(CRC) [WlR901 proporciona un

medio simple para identificar y organizar las clases relevantes para los requisitos del sistema 0 producto. Ambler [AMB9SI describe el modelado CRC de la siguiente forma:
Un modelo CRC en reaUdad es una colecci6n de larjelas Indice eslandar que representan c1ases. las tarjetas se dividen en tres secciones. A 10 largo del borde superior de la tarjeta se escribe el nombre de la c1ase. En el cuerpo de la tarjeta se lislan las responsabilidades de la c1ase a la izquierda y los colaboradores a Ia derecha

En realidad, el modele CRC puede utilizar tarjetas indice reales 0 virtuales. El objetivo es desarrollar una representaci6n organizada de las clases. Las responsabilidades

PARTE DOS PRAcn:A DE 1J.!NGDIIERiA. DEL SOFTWARE

son los atributos y las operaciones relevantes para la c1ase. Dicho de manera simple, una responsabilidad es Hcualquier cosa que la clase sabe 0 hace" lAM Los colaboradores son aquellas dases que se requieren para que una clase reciba infonnaci6n necesaria para completar una responsabilldad. En general, una colabo raci6n implica ya sea una solicitud de infonnacl6n 0 la so!icitud de a\guna accl6n.

aI inKio,

to
En la figura 8.15 se i1ustra una tarjeta indice CRC simple para la clase Planodeplanta. La !ista de responsabilidades que se muestra en la tarjeta CRC es preliminal" y esta sUjeta a adiciones 0 modificaciones. Las clases Pared y aHnara se anotar enseguida de la responsabilJdad que requerira su colaboraci6n. elases. Las directrices basicas para identificar clases y objetos ya se han presentado en este mismo capitulo. La taxonomla de los tipos de clases que se present6 ell la secci6n 8.7. 1 se puede extender considerando las siguientes categorias:

doses de enlidad. tamblen lIamadas clases de modelo 0 negocios. se extraen de manera directa del enunciado del problema (por ejemplo, Planodeplanta y Sensor). De manera tipica, estas clases representan clases que se almace naran en una base de datos y que persisten durante la aplicaci6n (a menos que se borren de manera especlfica) . Closes deJrontera. Se ulilizan para crear la interfaz (por ejemplo, pantallas interactivas a reportes impresos) que el usuario ve y con la cua! interactua ruanda se utiliza el software. Las clases de entidad contienen infonnaci6n

Ck."

~
M" o Ia

,I pla~ d, pla"1o Mo"'io 10 po.k'60 del E~ola ,I .Ia~ de .10"10 PO'O " E~ola ~ pla~ de plo"1o PO'O "

Po,""
, d, 10"

c APinn.o 8

MODELAOO DEL

mAUSIS

221

importante para los usuarios. pero no se despliegan a si mismas. Las clases de frontera estan disenadas con ia responsabiiidad de manejar ia forma en que los objetos de entidad se presentan a los usuarios. Por ejemplo. una clase de frontera llamada Vetttanadecamara tendria la responsabilidad de desplegar la salida de una camara de vigilancia para el sistema HogarSeguro . Las clases de contra/ador manejan una "unidad de trabajo" jUML03] desde el inido hasta el final. Esto es, las clases de controlador se pueden disenar para manejar 1) la creaci6n 0 actualizaci6n de los objetos de entidad; 2) la inmediatez de objetos de frontera conforme estos obtienen informaci6n de objetos de entidad; 3) la comunicaci6n compleia entre conjuntos de obietos; y 4) la validaci6n de datos comunicados entre los obietos 0 entre el usuario y la apJicaci6n. En general, las clases de controlador no se consideran sino hasta que ha comenzado el diseno.

[i.:~""'''' ciIsIIbne de marIIrlI cienlifka en tres Irandes coIegorias: los .. lit

I i 'Ills ... sa piIrden."

rur.w.., lis ...

ResponsabiUdades. En las secciones 8.7.2 y 8.7.3 se han presentado las directrices basicas para identificar responsabilidades (atributos y operaciones). Wirfs-Brock y sus colegas [W1R90J sugieren cinco directrices para determinar las responsabilida des de las clases: 1. La intellgencia del sistema se debe distrlbuir entre las clases para abordar de mejor manera las necesidades del problema. cada aplicaci6n abarca un derto grado de inteligencia; esto es, 10 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 cJases "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 cJases, 10 que dificulta los eambios, y b) tiende a requerir mas clases, y por ende, un mejor esfuerzo de desarrollo. Si la inteligencia del sistema se distribuye con mayor amplitud entre las clases de una aplicaci6n. cada obieto sabe y haee s610 unas cuantas cosas (las cuales, por 10 general, son bien enfocadas) . y la cohesi6n 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 inteiigencia del sistema esta bien distribuida las responsabilidades anotadas en cada tarjeta Indice del modele CRC deben evaluarse y asi comprobar si alguna cJase liene una !isla de responsabilidades

--

PARTE DOS

PRJ.cncA DE LA INGlNlIl!IA DEl. SOFtWARE

demasiado larga. Esto indica una concentrad6n de inteligenda.2J Ademas, las responsabilidades para cada ciase deben mostrar el mismo grado de abstraccD 2. cada responsabUidad debe estableeerse tan genera) como sea posIble. Esta directriz implica que las responsabilidades generales (tanto atribulos como operaciones) deben estar en la parte alia de la jerarqula de la c1a.se (debido a que son genericas son apllcables en todas las subclases). 3 . La informad6n y el comportamlento relaclonado con ella deben est . dentro de la misma clase. Con esto se logra eJ principio 00 Ilamado encJlPtsulaci6n. Los dalos y los procesos que manipulan los datos deben empaquetarse como una unidad cohesiva. 4 . La informacion relatlva a una cosa debe locallzarse con una sola clase, no distribuirse entre muchas de ellas. Una sola ciase debe tomar la responsabiJidad de almacenar y manipular un tipo especlfico de infonnaci6n. En general, esta responsabilidad no se puede compartir entre varias cla ses. Si la infonnaci6n se distribuye, el soRware se vuelve mas dificil de mantener y mas desafiante de probar. 5. Las responsabUidades pueden eompartirse entre elases reladonadas cuando esto es apropiado. Exislen muchos casos en los que una variedad de objetos relacionados deben mostrar el mismo comportamlento al mismo Hempo. Como un ejemplo, considerese un videojuego que debe desplegar las siguienles clases: Jugador, CuerpoJugador, BrazosJugador, PiemasJugador, CabezaJugador. Cada una de estas clases tiene sus propios atributos (por ejemplo, poaIci6n, orientMli6n, ooIor, veIocided) Y todos deben actualizarse y desplegarse cuando el usuario manipula un joystick. Por 10 tanto, las responsabilidades aClualizor( ) y desplegarr ) deben compartirlas cada uno de los objelOS mencionados. El Jugador sabe cuando algo ha cambiado y se requiere actualizor( J. Colabora con los alros objelos para lograr una nueva posici6n u orientaci6n. pero cada objeto conlrola su propio despliegue. Colaboraciones. Las clases cumplen sus responsabitidades en una de dos fonnas I) una cJase puede ulilizar sus propias operaciones para manipular sus propios atributos. y con ello cumplir con una responsabilidad particular, 0 2) una clase puede colaborar con otras clases. Wirfs-Brock y sus colegas [WIR901 definen las colaboraciones de la siguienle manera:
Las colaboraciones represenlan las solicitudes que un cHenle haec a un servidor con el lin de cumplir una responsabilidad Una colaboraci6n es la materializaci6n del contrato entre el cliente y el servidor.. se dice que un objelo colabora con olm objeto si, para cumplir con una responsabilidad, necesita enviar algunos mensajes al otro objeto. Una 23 En tales casas puede ser necesario dividir las clases en multiples clases 0 subsislemas rompletO$ para dlslribulT la intehgencta de manera mfls erlCaz

cAPiTuLo 8

MODELADO DEL ANAUSIS

229

colaboraci6n sencil!a fluye en una direcci6n, 10 que representa una solicitud del cliente al servidor. Desde el punto de vista del ciiente, cada una de sus colaboraciones esta asociada con una responsabilidad particular que ha implementado el servidor.

Las colaboraciones identifican las relaciones entre dases. Cuando un conjunto de clases colabora para lagrar algtin requisito, este puede organizarse en un subsisterna (un aspecto de diseno). Las colaboraciones se identifican al detenninar si una clase puede cumpJir cada responsabilidad por si misma. 5i no es as[, entonces se requiere de la interacci6n con otra dase y, por ende, una colaboraci6n. Como un ejernplo, considerese la funci6n de seguridad de HogarSeguro. Como parte del procedimiento de activaci6n, el objeto PaneldeControl debe detenninar si algun sensor esta abierto. Se define una responsabilidad llamada determinar-csta tus-sensor( ). 5i los sensores estim abiertos, PaneldeControl debe establecer un atributo de estatus como "no listo". La informaci6n de los sensores se obtiene de cada objeto sensor. Por 10 tanto, la responsabiJidad detenninar-estatus-control( ) trabaja en colaboraci6n con sensor. Para ayudarse en la identificaci6n de los colaboradores, el analista puede examinar tres relaciones genericas diferentes entre las dases [WIR90J: I) la relacion e5parte-de, 2) la relaci6n tiene-conocimiento-de, y 3) la relaci6n depende de. Cada una de las tres relaciones genericas se considera con brevedad en los siguientes parrafos. Todas las clases que son parte de una clase agregada se conectan a esta a trojlves de una relaci6n del tipo es-parre-de. Considerense las clases definidas para el videojuego ya mencionado, la clase cuerpoJugador es-parre-de ]ugador, al igual que , BrazosJugador, PiernasJugador y cabezaJugador. En UML estas relaciones se representan como la agregaci6n mostrada en la figura 8.16. Cuando una clase debe obtener informaci6n de otra clase se establece la relaci6n tiene-conocimiento-de. La responsabilidad detenninar-estatus-sensor( ) mencionada antes ejemplifica una relaci6n del ripo tiene-conocimiento-de. La relad6n depende-de implica que dos clases tienen una dependencia que no se logra mediante las relaciones tiene-conocimiento-de 0 es-parre-de. Por ejemplo, cabezaJugador siempre debe estar conectada a CuerpoJugador (a menos que el videojuego sea violento en particular). Aun asi, cada objeto puede existir sin el conocimiento directo del otro. Un atributo del objeto cabezaJugador lIamado posicion central esta detenninado desde la posici6n central de CuerpoJugador. Esta informaci6n se obtiene a traves 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 Indice del modelo CRC enseguida de la responsabilidad que ha producido la colaboraci6n. Por 10 tanto, la tarjeta indice contiene una lista de responsabilidades y las colaboraciones correspondientes que permiten que las responsabilidades puedan cumplirse (figura 8.15).

230

-Unackae

.......
I I

COD1puesta.

Cuando se ha desarrollado un modele eRe completo, los representantes del cI tes y la ingenierla del software pueden revisar el modele utilizando el siguiente eni' que (AMB95):

I . Todos los participantes en la revisi6n (del modelo CRq reciben un subconjunto de las tarjetas indice del modelo eRe. Las tarjetas que colaboran se deben separar (es dedr, ningun revisor debe tener dos que co\aboren).

2. Todos los escenartos de case de usa (y los diagramas de caso de USQ corres-.
pondientes) deben organizarse en categorfas. 3. Ellider de 1a revisi6n lee el case de usa en (anna deliberada. Cuando eilider Ilega a una clase nombrada pasa una

senal a 1a persona que Hene la tatjeta

indice de clase correspondiente. Por ejemplo, un case de usa para Hoga&-

gum conliene la siguiente narrativa:

El propietarioobserva el panel de control de Hoga!Seguro para delerminar si el sistema estti listo para la entrada. Si no 10 estti, el propietario podra cerrar nsicameme vema nas y puertas para que se presente el indicador de listo. [Un indicador de no-listo implica que un sensor estti abierto; es declr, que esa puerta 0 ventana estti abierta.l

Cuanda elMer de la revisi6n Ilega a "panel de control", en la narrativa del caso de usa, la sei\al se pasa a la persona que posee la carta indice del Paneldecontrol. La (rase "implica que un sensor esta abierto" requiere que la ta~eta Indice contenga una responsabilidad que validara esta implicaci6n (10 cual sc lagra mediante la responsabilidad de~jnar-estalUs-sensor( )). Enseguida de la responsabiJidad escrita en la tarjeta esta el colaborador sensor. Entonces, Ia sefial se pasa a la clase sensor. 4. Cuanda se pasa la sefial. la persona que posee la tarjeta de clase debe describir las responsabilidades anotadas en ella. El grupo determina si una (0 mas) de las responsabilidades satisface el requisita del caso de usa.

CAPiTuLo 8

MODl.AOO DEL ANAusis

231

5. Si las responsabilidades y las colaboraciones anotadas en las tarjetas Indice no satisfacen el caso de uso, se hacen las modificaciones necesarias a la tarjeta. Esto puede incluir la definici6n de clases nuevas (y corresponden a las tarjetas de indice de CRC) 0 la espedficad6n de responsabilidades 0 colaboradones nuevas revisadas sobre las tarjetas existentes. Esta forma de operaci6n continua hasta que se termina can el caso de uso. Cuando se han revisado todos los casos de usa se continua can el modelado del analisis.

in.......

10
una CClItrCIMIi'kJ .... lt

II

Vlnod

:n:~"~inaI6r:"~I.. ;J;_:;","'''''

digomolque monera, utraje adminitlrcxi6n

oIkn ~ ojompIo.
lei: 00 ",,*,",..

In....,............... 'I
~.

NdS...

son. los oII'ibutol y coIabonxionel son los

y aire poro

Vinod: Crwo ~ no .........cat: Ed: Tal ... UI"t poco. pI"Ocontin6ct.

".,.,.,

plano do

............

................. zliul' .
Po...Iopcicw_: "';;;.;::.:::~:: penn"" aI usuario .-00.101'

112

... '1,la".1 mQDIO que eI objeto de vigilancio, pero . . . . . *01 di~_

. . D.l Oiapocitiwo: ;lIbmoci6n w:Cre iconos que .,--Iblluces. apkoci00e5, a.naros, etcetero.
. . ds+DitposiIivo: loirnulaciOn de una apli(OCi6n 0 . . . . . CIOnIrOI d. un diapotitiYO; pennife eI control.

~~Siluoci6r1

enlr(l~nta

"-I ........ .....

....,.1IIt ...... .....

lei: E"1onces cuando Ie invoc:a Ia .....uci6ib

0.1 adl ,

...
, t

".".",..CDnttoIO, ~1roI(J,
...",.fltSilucxi6n(/, ~rSiIuoc;6nIJ,

M~Io{I.... """"""_" ......

vigilancio. Espero ~gUfCl 8.IA)

. . .PlcwlCOlOWflbrlolJ ..J.cciOlaorlconoDispo$ilivo(), It, b, 1I:cdJ .. ad "boO, -.frur PotteIDfspmilivo(J,.

~
0

Vino&h E:coctam.....

. . ,

at ' , 1'.,5 G 101

25 upr
......

modoIo
ohl, (I
UOCI

Cl'.' .... r
.... IIFllSd.nM(doseJ
... ,. . . . .d.lMI. ldose)

(I$I~"'.

d6

.............. .10 __... _ _

Vlnocl: 51.

"

_1601"'-1

~~

8.7.5 Asociaciones y dependenc1as

En muchos casos, dos clases de anaIisis se reladonan entre 51 de alguna manera, parecida a la forma en que se relaclonan dos objetos de datos (secci6n 8.3.3). En UML estas
relaciones se llaman asociadones. Vease de nuevo Ja figura 8.14; la dase PlanodePlantil se define al identiftcar un conjunto de asociaciones entre PlanodePlanta y otras dos cia-

C&VE
UIIO asociodOO defile IRI reIaciXIllRlle Om.......... define amlm de lIlQ dmo ...

........,"" de 00se.
amnlm 0Irn

ses, camara y Pared. La clase Pared se asocia con tres clases que permiten que st: construya una pared, Segmentodepared. Ventana y Puerta. En algunos casos, una asociad6n se puede definir en forma mas extensa a1 inm car multiplicidad (el termino cardinalidad ya se us6 antes en este capitulo). En referenda a la figura 8. 14, un objeto de Pared se construye con uno 0 mas objetos Ik SegmentosdePared. Ademas, el objeto Pared puede contener 0 0 mas objetos de Ventana y 0 0 mas objetos de Puerta. Estas restricciones de multipliddad se iiustran en 1a figura 8.17, donde "uno 0 mas" se representa mediante 1.. - y "0 0 mas" pol" medio 0 .. - . En UML el asterisco indica una frontera superior ilimitada en el rango.JiI En muchos cases exisle una relaci6n clienle-servidor entre dos dases de analisis En tales cases, una clase de cHenle depende de alguna manera de la clase de servidor y se eslablece una relad6n independencia. Las dependencias se definen mediante un eSlereotipo. Un estereoupo es un "mecanismo de extensibiHdad" [ARL..02J den-

24 Otras relaclonesde muillplicidad -una a una, una a muchas. muchas a mochas, una a un rango especifico con timites Inferior y superior. y otras- se pueden indicar como parte de una asociaci6n

cAPiTuLo 8

MODELADO DEL ANAusis

233

Po....

1
Sa utilize pare
conslruir

-I

,
o.

- Sa

utiliza para construir

Sa utiliza para
construir

I O.

Segme"toPared

V.mana

Pue""

.............
_~na

Camara
occe$O (contraseiio)

tro del UML que permite a un ingeniero de software definir un elemento de modelado especial cuya semtmtica define el cliente. En UML los estereotipos se representan dentro de comillas angulares (por ejemplo, estereotipo). Como una ilustraci6n de una dependencia simple dentro del sistema de vigilancia de HogarSeguro, un objeto de Camara (en este caso, la clase de servidor) proporciona una imagen de video 0 un objeto de Ventanadeoespliegue (en este caso, la del cliente). La relaci6n entre estos dos objetos no es una asociaci6n simple, aun asi existe una asc:xiaci6n de dependencia. En un caso de uso escrito para la vigilancia (que no se muestra), el modelador aprende que se debe proporcionar una contrasei'ia especial para ver ubicaciones especificas de camara. Una forma de lograr esto es que camara pida una contrasei'ia y despues de penniso a VentanadeD espliegue 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 camara esta controlado mediante una contrasena especial.

8.7.6 Paquetes de anCdisis

Una parte importante del modelado del analisis es la categorizacion. Esto es, los diferentes elementos del modelo de analisis (por ejemplo, casos de usa, clases de

PARTE DOS

PRAcncA. DE LA INGEN1IRlA. DEL SOFIWARt

Paquet...

~~!i!i!i!i!!l[.~ .... Nomb.. del paquet.

.'4..

.""""' " ........

.p....!

+Poisoje

+Edifteio +EI.ctoViwo! +EsceflQ

~~VE ............. ..... do....,

1kI ~ $I utizo

analisis) se dasifican de una manera que los empaquete como una aglrup'aci6n, -'-mada un paquete de ami/isis-, a la cual se Ie asigna un nombre representativo. Para ilustrar la utilizaci6n de paquetes de analisis considerese el videojuego se present6 parrafos atnis. Al desarrollar eJ modelo de analisis para el videojuego obtiene un gran mimero de dases. Algunas se enfocan en el ambiente del juego; ejemplo, las escenas visuales que el usuario ve mientras se desarrolla el j1Jelr! Clases como ArOOI, palsaje, camino, pared, PUente, Edifldo, EfectoVls podrian estar dentro de esta categorfa. Otras se enfocan en los personajes denlro juego al describir sus caracterlslicas tisicas, acciones y reslricciones. Se podrian del nir dases como Jugador (Ia cual se describl6 can anterioridad), Protagonista. Antagonista y Papelesdesoporte. Ademas, otras describen las reglas del juego c6mo navega el jugador a traves del ambiente. Aqui son candidatas dases com ReglasDeMovimiento y RestrlcdonesEnAcd6n. PUeden existir muchas otnlI categorias. Estas dases pueden representarse como los paquetes de analisis que muestran en la figura 8.19. EI signa de mas que precede al nombre de la dase de analisis en cada paquet.: indica que las dases tienen vlsibilidad publica y que, por 10 tanto, son accesibles desde otros paquetes. Aunque no se muestran en esta figura, hay otros slmbolos que pueden preceder a un elemento dentro de un paquete. Un signa de men05 indica que WI elemento esta oculto de todos [os otros paquetes, y un slmbolo " indica que un elementa es accesible s610 a las dases contenidas dentro de un paquete dado.

""""""'.

Los diagramas de dase, las tarjetas Indice CRC y otras modelos orientados a las da-

ses tratados en la secci6n 8.7 representan elementos estaticos del modele de anali

CAPiTuLo 8

MODELAIX) DEL ANAusis

235

sis. Ahora es tiempo de hacer una transici6n al comportamiento dinamico del sistema 0 producto. Para lograrlo el comportamiento del sistema debe presentarse como una funci6n de los elementos espedficos y el tiempo. El modelo de comportamiento indica la forma en que eJ software respondera a los evenlos a estimulos extemos. En la cread6n del modelo el analista debe realizar los siguientes pasos:
I . Evaluar todos los casos de usa para entender por completo la secuencia de

interacci6n dentro del sistema.

2 . Identificar los eventos que conducen la secuencia de interacci6n y entender la

forma en que estos eventos se relacionan con las clases especlficas.

3. Crear una secuencia para cada casa de usa.

4 . Construir un diagrama de estado para el sistema.

5. Revisar el modele de comportamiento para verificar su exactitud y consisten-

cia. Cada uno de estes pasos se expone en las secciones siguientes.

8.B.1 Ident11lcacl6n de eventos con e1 caso de uso

Como se mencion6 en la secci6n 8.5, el casa de usa representa una secuencia de actividades que implica a los actores y al sistema. En general. siempre que el sistema y un actor intercambian informacl6n ocurre un evento. 5i se recuerda la expJicaci6n anterior acerca del modelado del comportamiento en la secci6n 8.6.3, sera importante puntualizar que el evento no es la informaci6n que se ha intercambiado, sino el hecho de que la informaci6n haya sido intercambiada. Los puntos del intercambio de informaci6n se obtienen examinando un caso de usa, A manera de ilustraci6n, se reconsiderara el casa de usa para una pequena parte de la funci6n de seguridad de HogarSeguro.
EI propietado utiliza el teclado para jntrodudr una contrasefia de cuatro d[iitQs. La run:: traseOa se compara can la cQntrasefia yAlida almacenada en el sistema Si la contrasefia es incorrecta. el panel de control emjtirA un sonido por una sola vez y se reiniciarA para esperar otra entrada. Si la contrasefia es cOlTecta, el panel de control esperartl la acci6n posterior.

Las partes subrayadas del escenario del caso de usa indican eventos. 5e debe identificar a un autor para cada evento; la informaci6n intercambiada se debe anotar. y cualquier condici6n 0 restricci6n debe registrarse. Como ejemplo de un evento Upico, considerese la frase subrayada del casa de uso "el propietario utiliza el teclado para introducir una contrasefia de cuatro digitos". En el contexto del modele de analisis, el objeto, propietario ,lS transmite un evento al
25 En este ejemplo se asume que cada usuado fpropietaIiot que interactUa con HogarSeguro tiene una contrasena de identificaci6n y que. por 10 tanto, es un obJeIo IegitUTIO.

2J6

PARTE DOS

PRAcnCA DE!J\. INGENlDl!A DEl. $OF"I'WAR

objelo PaneldeControl EI evento podria lIamarse inuoducd6n de conrrasdllc. informaci6n transrerida son los cuatro dlgitos que constiluyen la contrasena . esta no es una parte esencial del modelo de comportamienlo. Es importante que algunos eventos lienen un impacto explicito sobre el flu}o de control del <:as(, usc, mienlras que alTOS no tienen impacto directo sabre el flujo de control. plo, eJ evento introducci6n de contrasena no cambia de manera expllcita el nUl" control del caso de usc, pero los resultados del evento comparaci6n de ~ (derivado de Ja interacci6n "la contrasei'ia se campara con Ja contrasena almacenada en el sistema") tendra un impacto expllcito sobre \a informaci6n flujo de control del software de HogarSeguro. Una vez que se han identiflcado todos los eventos, estos se ubican con los tos involucrados. Los objelos pueden ser responsables de generar eventos ,"'" .101~ plo, Propletario genera el evento de introducci6n de contrasefia) 0 de eventos que han ocurrido en cualquier sitio (por ejemplo. PaneldeControl TeaJIII ce el resultado binario del evenlo comparaci6n de contrasei'la) .

Po",...

C"""'...

"":0''''''.

8.8.2 Representaciones de estado

En el contexto del modelado del comportamiento se pueden considerar dos dW"". tes caracterizaciones de los estados: I) el estado de cada clase conforme el realiza su funci6n, y 2) el estado del sistema como se observa desde el exterior forme el sistema realiza su funci6n ,26 El estado de una clase implica caracteristicas tanto pasivas como activas (CHA

,i."""

~~

C&VE

""""
~

"". . . . 00

.......

_w """",,"",,"

EI sistenlIliene

..

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 aplicaci6n de videoj estudiada con anterioridad) incluiria los alributos de poeici6n y ori....aoI6n del Jugador asl como otras caracl eristicas relevanles para el juego (por ejemplo, un atributo Indique la exirieocia d. deQ808 maaicoa). El esrado activo de un objeto indica el esta actual del objeto cuando este esta sujeto a una transformacl6n 0 a un procesam' to continuos. La clase Jugador podria teneT los siguientes estados activ05: en t1JOI'& mienro, ell descanso, herido, en curaci6n, atrapado, perdido, etcetera. Debe ocurrir evento (algunas veces lIamado un disparador) para obligar a un objeto a hacer transici6n de un eslado activo a otro. En los parrafos siguientes se explican dos diferentes representaciones del C OD:'" portamiento. La primera indica la forma en que una clase individual cambia sus esta do con base en eventos externos. y la segunda muestra el comportamiento del soft ware como una funci6n del tiempo. Diagramas de estado para clases de anAlisls. Un componente de un mod del comportamiento es un diagrama de estado en UML que representa los estados activos para cada clase y los eventos (disparadores) que ocasionan cambios en~
26 Los diagramas de estado presen!ados en la secci6n 8.6.3 muestnm el estado del Sistema. La exposid6n en esta Sl:ccl6n se enfocarli al estado de cada clase dentro del modelo de analisis.

eI erterior; tm

dase Iiene estodos ~

amdo eI sisfBmll !dm SUS Ioociooes.

cAPiTuLo 8

MODELAOO DEL ANAUS!S

237

Tempori:wdor ~ TiempoCerrodo

Temoorizodor

>

TiemPOCerrodo

Controsei'io .. incorrecta y numeroDeIntento5 < IntenlosmO/limos

C.....do

Golpe

de "'''

"""'"'

L
Contrcsena inlroducidc

CompanKiOn

numeroDeIntent05 > Intentosmc/limos

r-

Ha<:er: volidor Conlro sei'io

Contrasei'io ... correcta

s.tecciOn

Aclivoci6n e/litaso

estos estados activos. En la figura 8.20 se ilustra un diagrama de estado para la clase PaneldeControl en la funci6n de seguridad de HogarSeguro. Cada flecha en la figura 8.20 representa una transici6n desde un estado activo de una clase hasta otm. Las etiquetas mostradas para cada flecha representan el evento que dispara la transici6n. Aunque el modelo de estado activo proporciona un discemimiento activo de la "historia de vida" de una clase, es posible especificar informaci6n adicional para proporcionar mayor profundidad en la comprensi6n del comportamiento de una clase. Ademils de especificar el evento que ocasiona la transici6n. el anaJista puede especificar una guardia y una accion [CHA93j. Una guardia es una condidon booleana que debe satisfacerse para que ocurra la transicion. Por ejemplo, Ja guardia para la transici6n desde eJ estado de "lectura" aJ estado de "comparaci6n" de la figura 8.20 se puede deterrninar al examinar el caso de uso:
ai (introducci6n d. oonfraser'ia = 4 dlgbl, eotono.c compel'Sr con oontras&Oa almacenada

En general, la guardia para una transid6n por 10 regular depende del valor de uno 0 mas atributos de un objeto. En otras palabras, la guardia depende del estado pasivo del objeto. Una acd6n sucede de manera concurrente con la transiei6n del estado 0 como 0 general implica una 0 mas operaciones (responsabiliconsecuencia de este. y por 1 dades) del objeto. Por ejemplo, una aed6n conectada con el evento contrasefia introducida (figura 8.20) es una operaci6n Hamada VolidarContrasefia( ) que da aceeso a

231

sec:uenc1a (paIdal) para la tuncI6n de segurtdad. de HogarSeguro,

1 ,,-~ I

1-<10-.. I

,,.odoc,do

e f;.:o- n 1,.1

ClmM'"

r~)
,
c.m.Io
I I

Solicitud de bUsquedo
Resultado

,
I
I

, ,
Solidtud de octivoci6n
I I I

numerOelntenlos InMnlosmOKimos

:>

Conlfo$8lio - CQl"recIo
:> ~

.1..
I I I I I I I I

Tem~~ Tiern wr

Aclivoci6n exiloKl
I

(-)
i

AodivociOn exilo.o

un objelo de contrasefta y realiza una comparaci6n digilo por dfgilo para validar 1a conlrasel'la inlroducida. Diagramas de secuenda. EI segundo tipo de representaci6n de comportamien-10, lIamado un diagrama de secuencia en UML, indica c6mo los evenlos causan Iransiciones de objele a objelo. Una vez que se han identificado los eventos al examinar un casa de uso, eJ modelador crea un diagrama de secuencia: una represenlaci6n de c6mo los eventos causan un flujo de un evento a otro como una funci6n del tiempo. En esencia. el diagrama de secuencia es una versi6n abrevlada del casa de usa Representa clases clave y evenlos que causan que el comportamiento fluya de clase a clase. En la figura 8.21 se ilustra un diagrama de secuencia parcial de la funci6n de seguridad de HogarSeguro. cada flecha representa un evento (derivade de un caso de usa) e indica c6mo el evento canaliza el comportamienlo entre los objetos de HogarSeguro. EI tiempo se mide de manera vertical (hacia abajo), y los rect~ngulos verticales delgados representan el tiempo invertido en procesar una actividad. Los estados se pueden mostrar a 10 largo de una linea de tiempo vertical. EI primer evento, sistema lisla, se deriva del ambiente extemo y canaliza el com portamiento a un objeto de propietarlo. EI propietario introduce una contrasena. Se pasa un evento de soJici/ud de bUsqueda al sistema, el cual busca la contrasena en una base de datos simple y regresa un resuJ/ado (encontrodo 0 no enconlrado) al PanekSecontrol (ahora en el estado de compamd6n). Una contrasena valida resul-

c APiTuLo

MODELADO DEL

ANAusrs

239

ta en un evento contrasefia=correcta para et Sistema, et cual activa los sensores con un evento de soJicitud de activaci6n. Por ultimo, el control se pasa de regreso al propietario con el evento activaci6n 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 can un conjunto de eventos de entrada y eventos de salida (de un objeto). Esta informaci6n es util en la creaci6n de un disefio eticaz para el sistema que sera construido.

MOOelado del an6:U.sIs generalJzado en UMI.

Obfetivo: Las helTClmienk;n poro III modeIodo del on6lisis proporcionan Ia copocidod de modeIos basodos en escenarios, modeIos ... doses y modeIos de comportamienlo mediante Las herromienlas en asia cotegorfa $OpOI1on de diagromas en UML requeridos pora oootisis (eslas herramienlas III modelodo del disena). Adem6s de Ia las herromienlas en asia cotegorio de Ia consislencia YIa correcc::i6n dlOQronlOS en UMl; 2) proporcionan vinculas .....-.0 y Ia generoci6n de c6digo; 3) conm-uyen
ArgoUML, una herramienla de fuente obierta (orgouml.tigris.org).

ControJ Cenier, desarrollodo pili" Together-Soft

(www.togethersah.com).
Enlerprise Architect, desorrollodo por Spont Systems

(www.sporxsystems.com.au).

Object Technology worM:.ench (OTW}, desarrollodo por OTVV Software {www.otwwftwore.coml.

Puwer Designer, desorToUado por Sybase (www.sybase.com).

Rational Rose, desarrollodo por Rolional Corporation (www.rotional.com).

Syslem Archilect, desarrollodo por Popkin Softwore (www.popkin.com).
UML Studio, desarrollodo por Pragsoh Corporotfon (www.pragsoh.com).

~:~i::: modelos oyvcIc!n 0 Ia oominislroci6n y en UMl reqoeridos poro

representativas2 7
rongtl comp!eto UMl requeridos pora III modeIodo del

" '_ _la.

" : ; : : : :herra: mienlos wportan un

Visio, desorrollodo

pili"

Microsoft (www.microsoh.com).

Visual UML, desorrollodo por Vi$UOI Object N\odelen (www.visualuml.com).

El objetivo del modelado del analisis es crear una variedad de representaciones que muestran los requisitos del software para la informaci6n. la funci6n y el comportamiento. Esto se logra aplicando dos diferentes tilosoflas de modelado (pero potencialmente complementarias): el analisis estructurado y el analisis orientado a objetos. E1 analisis estructurado considera al software como un transformador de infor-

27 Las herTamientas mencionadas aqu[ 50n una muestra de esliI categoria En la mayorla de los ca50S los nombres estan regislrados por sus respectivos desanoIladores

PARTE DOS

PRAcncA DE L.\ INGDIlERIA DEL SOFTWARE

mad6n . Este ayuda al ingeniero de software a identificar los objetos de datos. reladones y la manera en la cua! eslos objelos de datos se transfonnan mientras yen a Iraves de las funciones de procesamiento del software. EI analisis orienlad' objelos examina un dominio de problema definido como un conjunlo de casas usc en un esfuerzo por extraer c1ases que definen el problema. cada clase conjunlo de atributos y operadones. Las clases estan relacionadas entre sl en variedad de fonnas diferentes y se moldean mediante la aplicaci6n de diagramas UML. EI modelo de analisis 10 componen cuatro elementos de modelado: basados en escenarios, modelos de fluio, modelos basados en clases y modelos comportamiento. Los modelos basados en escenarios mueslran los requisitos del software desdc punto de vista del usuario. EI caso de uso -una descripci6n narrativa 0 basada una plantilla de una inleracci6n entre un actor y el software- es el elemento mario del modelado. EI caso de usa, derivado durante la obtend6n de <equis.... define los casas clave para una fund6n 0 interacd6n especlfica. EI grado de lidad y detaHe del case de usa varia, pero el resultado final proporciona la necesaria a las otras actividades de modelado del analisis. Los escenarios la pueden describirse por medio de un diagrama de actividad: una representaci6n fica del tipo de un diagrama de flujo que muestra el flujo del procesamiento de un escenario especffico. Los diagramas de carril ilustran la forma en que el de procesamiento incumbe a varios actores 0 dases. Los modelos de flujo se enfocan en el fluio de objetos de datos confonne las ciones de procesamienlo los transfonnan. Los modelos de fluio, que se derivan analisis estructurado, utilizan el diagrama de fluio de datos; esta es una nolaCKln modelado que muestra la manera en que una entrada se transforma en una conforme los objetos de datos se mueven a traves del sistema. Cada funci6n del ware que Iransforma datos se describe mediante una espedficad6n del proce51.1 narrativa. Ademas del flujo de datos, este elemento de modelado tambien mu..... el flujo de control (una representaci6n que Ilustra la fonna en que los eventos tan el comportamiento del sistema). EI modelado basado en clases utiliza informacion derivada de elementos modelado orientado al flujo y basado en escenarios para extraer dases c""didol", atributos y operaciones de las narrativas basadas en texlo. Se establecen los c rios para la definici6n de una dase. La la~eta Indice clase-responsabilidad-col rador puede usarse en la definicion de relaciones entre las dases. Ademas, se p aplicar una variedad de notaciones de modelado en UML para definir jerarq reladones, asociaciones, agregaciones y dependencias entre las clases. Los pa tes de analisis se utilizan para categorizar y agrupar c!ases de manera que sean manejables para los sistemas grandes. Los primeros tres elementos del modelado del analisis proporcionan una vjg, estatica del sanware. Los modelos de comportamiento muestran un desemper dinamico. EI modele de comportamiento utiliza la entrada de elementos basados

tie,,,,,, ..

m<""_,

en"".

CAPinn.o 8

MODELADO DEL ANAusIS

24 1

escenarios, orientados al flujo y basados en clases para representar los estados de las clases de analisis y del sistema como un todo. Esto se logra identificando los estados, definiendo los eventos que ocasionan que una clase (0 sistema) tenga una transici6n de un estado a otro, e identificando las acciones que suceden cuando se realiza Ja transici6n. En el modelado del comportamiento se utiliza la notaci6n en UML de los diagramas de estado y los diagramas de secuencia.

[ABB831 Abbott, R., "Program Design by Informal English Descriptions", en CACM, vol. 26, num. 11, noviembre de 1983, pp. 892-894. [AMB951 Amble r, S.. "Using Use-Cases", en software Development, julio de 1995, pp. 53-6] [ARA891 Arango, G. y R. Prieto-Diaz, "Domain Analysis: Concepts and Research Directions", en Domain Analysis: AcqUisition of Reusable information for SOftware Construction, (Arango, G. y R. Prieto-Diaz, eds.J,IEEE Computer Society Press, 1989. [ARL02J Arlow, J. e 1. Neustadt, UML and the unified Process, Addison-Wesley, 2002. [BER931 Berard, E. V., ESsays on Objetc-Oriented software Engineering, Addison-Wesley, 1993. [800861 Booch, G., "Object-Oriented Development", en TEE Trans. software Engineen'ng, vol. SE12, num. 2, febrero de ]986, pp. 2] ]ff. [BUD%J 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. ]4, num. 6, octubre de 1989, p. 67. [CHA931 de Champeaux, D., D. Lea y P. Faure, Object-Oriented system Development, Addisonwesley, 1993. [CHE77] Chen, P., Th e EntiO!-Reiationship Approach to Logical Database Design, QED ]nfonnation Systems, 1977. [COA9I] Coad, P. y E. Yourdon, Object-Oriented Analysis, 2a. ed., Prentice-Hall, 1991. [COCOll Cockbum, A., Writing Effective Use Cases, Addison-Wesley, 2001 [DAv'931 Davis, A., software Requirements: Objects, Functions and States, Prentice-Hall, 1993. [DEM79] DeMarco, T., Structured Analysis and system specification, Prentice-Hall, 1979 [F1R93] Firesmith, D. G., Object-Oriented Requirements Analysis and Logical Design, Wiley, 1993. [LET03] Lethbridge, T., comunicaci6n personal sobre el analisis del dominio. mayo de 2003. [OMG03] Object Management Group, OMG Unified Modeling Language Specification, versi6n 1.5, marzo de 2003, disponible en http://www.rational.com/uml/resources/documentation/. [SCH021 Schmuller, J., 7lXlch YOurseljUML in 24 Hours, 2a. ed., SAMS Publishing 2002. [SCH981 Schneider, G. y J. Winters, Applying Use Cases, Addison-Wesley, 1998. [STR88] Slroustrup. B., "What is Object-Oriented Programming?", en ]EEE SOftware, vol. 5, nUm. 3, mayo de 1988, pp. 10-20. [TAY90] Taylor, D. A., Object-Oriented Technology: A Managers Guide, Addison-wesley, ]990. [THAOOJ Thalheim, B., Entity Relationship Modeling, Springer-Verlag, 2000. [TIL931 Tillmann, G., A Practical Guide /0 Logical Data Modeling, McGraw-Hill, 1993. [UML03] The UML Cafe, "Customers Don't Print Themselves", disponible en http://www theumlcafe.com/aOO79.htm, mayo de 2003. [W1R90] wirfs~Brock, R., B. wilkerson y L Weiner, Designing Object-Oriented software, PrenticeHall,I990.

8 . 1. ~Es posible comenzar a codificar inmediatamente despues de haber creado el modelo de analisis? Explicar la respuesta y despues justirlCM los puntas en contra.

PARTE DOS

PRAcncA D LA INGDlIERIA InOOFTWAIIE

8.2. Un analisis practico es aquel en el cual el modelo "debe enfocarse en los requisitos que son visibles dentro de los domlnlos del problema 0 del negocio" . ..CUales tipos de requisitos 110 son visibles en estos dominios' Dar algunos ejemplos. 8.3 ...Culd es ei pr0p6sito del anaiisis del dominio' ..C6mo se relaciona con el concepto de los patrones de requlsitos? 8.4. En unas cuantas lIneas, tratese de describir las diferencias primordiales entre el amlliSlS estructuraclo y ei anal isis orientado a objetos. 8.5 ... Es posible desarrollar un modelo de anal isis elicaz sin desarrollar los cua tro elemento$ que se muestran en la ligura S.3? Explicar la respuesta. 8.6. sup6ngase que han pedido construir uno de los siguientes sistemas.
a) Un registro de cursos basado en red para una universidad. b) Un sistema procesador de Ordenes basado en Internet para una tienda de computadoras d} El sofiware que reemplace un Roiodex

c) Un sistema simple de factu raciOn para un negocio pequei'lo. y que se encuentre denlro de un teItrono inalambrico. e) Un Iibro de cocina automatico que estt construido dentro de un homo eltctrico 0 de microondas.

SeIecci6nese el sistema que se considere interesante y descrfbanse sus objelos de datos, relaciones y atributos. 8.7. Oibujar un modelo al nlvel de contexto (OFO de nivel 0) para uno de los cinco sistemas que se !istan en el problema 8.6. Escribir una narratlva de! procesamlento para e\ sistema al nivel de contexto. 8.8. Utilizar el DFD a\ nivel de contexte desarrollado en el problema 8.7 para dibujar los diagTamas de nup de los niveles I y 2. Para comenzar, utilicese un "analisis gramatkal" en Ia narrativa del procesamien to al nivel de contexto. Recuerdese espedficar todo el nuido de informaci6n mientras rotula todas las flechas que se encuentran entre las burbujas. Osense nombres significativos para cada tran sformaci6n . 8.9. Desarr611ense especilicaciones de control (EQ y especilicaciones de proceso (EP) para eI sistema que seleccion6 en e\ problema 8.6. Trlilese de que el modele sea 1 0 mlls completo posible. 8.10. El departamento de obras pub!icas de una ciudad grande ha decidido desarrollar un sistema de rastreo y reparaci6n de baches basado en la Web (SRRB) . Se incluye la siguiente descripci6n:
Los c\udadanos pueden entrar a1 sitio Web y reportar la ubicaci6n y severidad de los baches Cuando estos se reportan entran a un sistema de reparaci6n del departamento de obras publicas", donde se leg asigna un numero de idenIiOcac\6n, junto con la direcci6n de Ia caUe, eJlamano (en una escala de 0 a 10), Ja ubicaci6n (en Ja orilla de la calle, en medio. etcetera), el distrito (determinado por la direcciOn de \a ca11e), y la urgencla de la reparaciOn (determinada por eilamano del bache) . Los datos de la orden de trabajo estlin as0ciadas con cada bache e incluyen la ubicad6n y el tamai'lO del bache. numero de identilicaci6n de \a reparaci6n. cantldad de personal necesario, horas aplicadas a la reparaci6n estado del bache (trabajo en progreso, reparado, reparado en forma temporal. no repara do), cantldad de material de relleno utitizado, y costa de Ja reparaci6n (calculo de las horas aplicadas, numero de personas, material y equipo utilizados). Por ultimo, se crea un archi vo de dai'los para registrar informaci6n sabre averias reportadas debido a los baches, el cual incluye nombre del ciudadano, direcci6n. nlimero telef6nico, tipo de dano, precio del dano en d6lares. EI SRRB es un sistema basado en la Web; todas las peUciones se hacen en forma interactiva

Con base en una notaci6n de analisis estructurada, desarrolle un modelo de analisis para el SRRB.

CAPiTuLo 8 MODELADO DEL ANAusrs 8.11. Describir los terminos orientados a objetos encapsulad6n y herenda.

243

8.12. Escrtbir un caso de usa basado en una plantilla para el sistema de gesti6n para el hogar
HogarSeguro, descrtto de manera informal en un re<:uadro ubicado enseguida de la secci6n

8.7.4.

8.13. Dibujar un diagrama de caso de uso en UML para el sistema 5RRB presentado en el problema 8. 10. Tendn'm que hacerse vartos supuestos sobre la manera en que el usuarto interactlia con este sistema. 8.14. Desarrollar un modelo de c1ase para el sistema SRRB presentado en el problema 8.10. 8.15. Desarrollar un conjunto completo de tarjetas Indice del modelo CRC para el sistema SRRB presentado en el problema 8.10. 8.16. Encabezar una revisi6n de las tarjetas [ndice de CRC con sus colegas. iCuAntas c1ases adidonales, responsabilidades y colaboradores fueron agregados como consecuenda de la revisi6n?
8. t 7. Descrtbir la diferenda entre una asociad6n y una dependencia para una c1ase de anAlisis.

8.18. ,Que es un paquete de anAlisis y c6mo debe utilizarse? 8. t 9. ,De que manera difiere un diagrama de estado para clases de anAHsis de los diagramas de estado presentados para el sistema completo?

se han publicado docenas de libros sobre am\lisis estructurado. En la mayorla se trata el tema de una manera adecuada, pero s6lo en unos cuantos se presenta un trabajo en verdad excelente. DeMarco y Plauger (Structured Ana!Ysis and ~tem SpecijiaJtion, Pearson, 1985) es un clAsica que sigue siendo una buena introducci6n a la notaci6n basi ca. Los libros de Kendal y Kendal (~femS Ana~is and Design, Sa, ed., Prentice-Hall, 2002) y Hoffer et al. (Modem ~fems Ana.[ysisand Design, Addison-wesley, 3a. ed., 2001) son referencias vaHosas, El Hbro de Yourdon (Modem Structured Ana[ysis, Yourdon-Press, 1989) sobre el tema se conserva entre las publicaciones mas completas a la fecha. Allen (Data Modeling for E'VeJyOne, Wrox Press, 2002), Simpson y Witt (Data Modeling Essentials, 2a. ed., COriolis Group. 2OCXJ), Reingruber y Gregory (Data Modeling Handbook. Wiley, 1995) presentan guras detaUadas para crear modelos de datos relacionados con la calidad industrtaL Un interesante libro de Hay (Data Modeling Patterns, Dorset House, 1995) presenta patrones de modelos de datos tlpicos 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 analisis orientado a objetos. Los libros de Bittner y Spence (Use Cose Modeling, Addison-Wesley, 2002), COCkbum (COCOI], Armour y Miller (Advanced Usecase Modeling; software ~tems, Addison-wesley, 2OCXJ] y Rosemberg y SCot (Use-Case Driven Object Modeling with UML: A Practical Approach, Addison-wesley, 1999) proporcionan una guia valiosa en la creaci6n y uso de este importante mecanismo de representaci6n y logro de requerimientos. Arlow y Neustadt han escrito apreciables analisis del UML [ARL021. SChmuller [SCH021. Fowler y SCott (UML Distilled, 2a. ed., Addison-wesley, 1999), Booch Ysus colegas (The UML User Guide, Addison-Wesley, 1998) y Rumbaugh y sus colegas (The unified Modeling Language ~/erence Manual, Addison-wesley, 1998). Los metodos de analisis y disei'io que apoyan el proceso unificado los explica Lannan (,Applying UML and Patterns; An lntroduction to Objed-Drknted AnatvsLs and Design and the unified process, 2a. ed., Prentice-Hal!, 2(01), Dennis y sus co~as (S)'sfem Ana!;'sis and Design: An Object-Oriented Approach with UML, Wiley, 2001), Y Rosenberg Y SCott (Use-case Driven Object Modeling with UML, Addison-wesley, 1999), Balcer y Mellor (Ejcecutable UML' A Foundation/or

...
Modd Driven Ndlilture, Addison-wesley, 20(2) exponen la semtm tica general del UML, los modelos que se pueden crear, y una fonna de considerar el UML como un lengua/e ejecutable Starr (EXecutable UMl.; How to Build Class Models, Prentice-Hail, 2001) o rrece una gula util y sugerencias detalladas para crear c1ases de disei'io y am\1isis efectivos. En Internet se dispone de una gran variedad de ruen tes de inronnad6n sobre el modelado del analisis. En el sitio SEPA se puede encontrar una lisla actualizada de referencias de Ja red que son notables para el modelado del ana-lisis:

http://www.mhhe.com/pressman.

CAPiTULO

INGENIERiA DEL DISENO

.. 253

,"' .259 ...259

.262

254 256 ....2S4

a ingenierta del disei'io abarca un conjunto de principios, conceptos y prac ticas que conducen al desarrollo de un sistema 0 producto de alta caUdad. los principios del disei'io (explicados en el capftulo 5) establecen una filosofia primordial que guian al disei'iador en el trabajo que desempei'ia. Es necesa rio comprender los conceptos del disei'io antes de que se apliquen las mecanicas de la practica del disei'io, y la practica del diseiio mismo conduce a la creaci6n de varias representaciones del software, eJ eual sirve como gufa para 1a actividad de construcci6n que sigue. La ingenieria del diseno no es una (rase comun dentro del contexto de la ingenleria del software. Sin embargo, deberta serlo. El disefio es una actividad primordial de la ingenierta. A prindpios de la decada de 1990, Mitch Kapor, el creador de Lotus 1-2-3, present6 un "manitiesto sobre el dlsei'lo de software" en Dr. Dobbs!oumal. Ah! afinna: .i.Que es el disei\o? Es ellugar en ckJnde una persona se puede parar con un pie en dos mundos -<:1 mundo de la tecnologia y et de la gente y los prop6sitos humanos-e intenta unirlos_ EI crftico de arquite<:tura romana Vitruvtus aport6 18 nocJ6n de que las construc~ ciones bien dlselladas eran aqueUas que mostraban finneza, comodidad y placer Lc> mismo debe decirse del huen software. FirmeuJ' el programa no debe tener n{ngun error que inhiba su fu,nd6n, Comodidad: un programa debe cumpllr con los pr0p6si. lOS para los que fue crtado_ Placer,la expetiencia de usar el programa debe ser agra~ dable_ Aqul se presentan los pri.ncipios de una teona de disefio para software.

iii ...., 1.0$ ingenienn de software de diseiio. iii . . . . . .nlet EI diseflo permile 01 ,,",1'0 .10 soItwore modeIor eI sislemo 0 proa oonstrvir. EUe modeIo puede reIoci6n con so calidod y mejororde reohar pruebo$

':r:~

::u:",,:;do:;1os Ioreos

.$ eI Iaa>lKlad deI_.
disefio
CiOtll,)()j lonotento

sa won involucrasitia en at que

iio

f""I'O'dono
compotlel'lfes

.... de daIo.. ""

p3I'O

leo ........' EI di_ f""'8"10 eI p';me<o. debe ",_:101610 arquitedura del sistema a proo.p.-, rnodeIm los interfaces que _

do d _ Ionno..

implementor

.. software con los usuarios finales,

245

PARTE DOS JW.c:ocA DE LA INGNIERlA. DEL SOFTWARE

La meta de la ingenierla del disei'to es producir un modelo de "~;:t:~~~:::~ muestre flnneza, comodldad y placer. Para lograrlo, un disenador debe la diversificacl6n y despues la convergencia. Belady (BE1..811 establece que H ficaci6n es la adquisici6n de un repertorio de altemativas, la materia prima del

i'to: componentes, soluciones de componentes y conocimiento, todo contenido catalogos, libros de texto y en la mente", Una vez que se ha integrado este cmljul.. de infonnaci6n, el disenador debe elegir y tomar elementos del repertorlo que plan los requisitos definidos por la ingenierla de requisitos (capitulo 7) y el de analisis (capitulo 8). Cuando esto ocurre, se consideran y se rechazan las nativas, y ellngeniero de disei'to converge en "una configuraci6n particular de ponentes y, por 10 tanto, en la creacl6n del producto final " [BELBlj . La diversificaci6n y la convergencia demandan intuici6n y juicio. Estas ,",.\i(Iad.. estan basadas en la experiencia de construir entidades simi lares, un conjunto principios que gulan c6mo evoluciona el modelo, un conjunto de criterios que miten juzgar la calidad, y un proceso de iteraci6n que conduce a una del disei'to final.

"f"e,se,",,'"

La ingenierla del diseno para el software de computadora esta en un ca.nblio c... tinuo, en la medida en que evolucionan mejores metodos, me;ores analisis y comprensi6n mas amplia. Aun en la actualidad. la mayorla de las disei'to de software carecen de profundidad. flexibilidad y naturaleza 0 general se asocian con disciplinas de disei'to de ingenierla mas que por 1 Sin embargo. existen metodos para el diseno de software, se dispone de

para la caUdad del disei'to, y es posible aplicar notaci6n de disefio. En este se exploraran los conceptos y principios fundamentales aplicables a todO el de software. los elementos del modele del diseno y el impacto de los patrones el proceso de diseno. En los capilulos 10, 11 Y 12 se examina una variedad de dos de disefio de software mlentras se aplican al disei'to arquitect6nlco. de 'nteBIl y en el nivel de componentes,

ca,"tu'"

cAPiTuLo 9

INGENIER!A DEL DWO

247

El disefio del software se encuentra en el nucleo U:cnico de la respectiva ingenieria y se apliea de manera independiente al modele de software que se utilice. Una vez que se analizan y especifican los requisitos, el diseno del software es la ultima acci6n de la ingenierla eOlTespondiente dentro de la actividad del modelado, la eua] establece una plataforma para la construcci6n (generaci6n de c6digo y pruebas).

cada uno de los elementos del modele de analisis (capitulo 8) proporciona la informaci6n neeesaria para crear los cuatro modelos de diseno que se requieren para una especificaci6n completa de diseno. En la figura 9.1 se ilustra el flujo de infonnaci6n durante el diseno 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 disei'io. Mediante la notaei6n de diseno y de los metodos de diseno que se exponen en capltulos posteriores, la tarea de diseno produce un disei'io de datos-elase, un disei'io arquitect6nico, un diseno de interfaz y un diseno de componentes. El diseno de datos-clase transforma los modelos de analisis y clases (capitulo 8) en las clases de diseno y las estructuras de datos que se requieren para implemen-

Transformac16n del modelo de an61lsis en un modelo de d1sei\o.

Dili.no .., . 1 nivef

de componenhtli
Diagramos de ftujo de datos Narrotivas de pracesomieola

,.-'=
'uquetes de ana!isis

Oiogramos de

fl:Y '~ O "'~'~OO~"~ ' ~~~~t~:::~~~

Modele, CRC Oiogromos de

Modelo de disei'io

tar el software. Las clases y relaciones que definen las tarjetas [ndice CRC y el contenido detallado de datos que muestran los atributos de clase y otras notaciones proporcionan la base para la actividad de diseno de datos. Una parte del diseno de clases puede ocurrir en conjunto con el diseno de la arquitectura del software. E1 diseno de cJase mas detallado se realiza a medida que se disena cada componente del software. EI diselio arquitect6nico define la relaci6n entre los elementos estructurales mas importantes del software, los estilos arquitect6nicos y patrones de diselio que pueden usarse para satisfacer los requisitos definidos por el sistema, y las restrlcciones que afectan la manera en que se pueden implementar los patrones arquitect6nicos (SHA96j . La representaci6n del diseno arquitect6nico --el marco de trabajo de un sistema basado en computadora- puede derivarse de la especificaci6n del sistema. del modelo de analisis y de la interacci6n de los subsistemas definidos dentro del modele de analisis. EI diseno de la interfaz describe la forma en que el software se comunica con los sistemas que interactuan con ei y can los humanos que los utili zan. Una interfaz implica un fluio de informacibn (por ejemplo, datos 0 control) y un tipo de comportamiento espedfico. Por 10 tanto, los escenarios de uso y los modelos de comportamiento proporcionan mucha de la Informaci6n que se requiere en el diseno de la interfaz. EI diseno al nivel de componentes lransforma los elementos estructurales de la arquitectura del software en una descrlpci6n procedimental de los componentes de este. La informaci6n obtenida de los modelos basados en clases, los modelos de flujo y los modelos de comportamiento sirven como base para el diseno de componentes

.............. tOftSfn.irun distiiodtsoftwor . Uno forma ts hoc.to"" . . . . . z' d .., ...... ,10 .... _ " ' ....... ....._ _ _ .0 _ _ . _. .

,...

t&.II._

Durante el diseno se toman decisiones que al final incidiran en el exilo de la construcci6n del software, as! como en, con el mismo grado de importancia, la facilldad con que el software puede manlenerse. Pero, .i.por que es tan importante el diseno' La importancia del disefio del software puede describirse can una sola palabra. cal/dad. EI disefio es la etapa en la que se fomentara la calidad en la ingenierla del software. El diseno proporciona las representaciones del software susceptibJes de evaluar respecto de la calidad. EI diseno es la unica forma en que, de manera exacla, un requisito del cliente se puede convertir en un sistema 0 producto de software terminado. EI diseno del software sirve como fundamento para todas las actividades subsecuentes de la ingenlerla del sollware y del soporte de este. Sin diselio se com: el riesgo de construir un sistema inestable, el cual faHara cuando se realicen cambios pequef'tos; que sera diflcil de probar; cuya caUdad no podra evaluarse sino hasta

cAPiTuLo 9

INGENIER!A DEL DISENO

etapas tardias del proceso del software, cuando queda poco tiempo y ya se ha gastado mucho dinero en el.

El disefio 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 visi6n hollstica del software. Es decir, el disefio se representa en un grado alto de abstracci6n, el cual puede rastrearse de manera directa hasta conseguir el objetivo especlfico del sistema y requisitos mas detallados de comportamiento, funcionales y de datos. A medida en que ocurren las iteraciones del disefio, un refinamiento subsiguiente conduce a representaciones del disei'to a grados mucho mas bajos de abstracci6n. Estos grados aun se pueden rastrear hasta los requisitos, pero la conexi6n es mas sutil. A traves del proceso del disei'to, la calidad en evoluci6n de este se evah1a con una serie de revisiones tecnicas formales 0 con revisiones de disei'to explicadas en el capitulo 26. McGlaughlin [MCG91] sugiere tres caracterlsticas que sirven como gula en la evaluaci6n de un buen disefio: El disefio debe implementar todos los requisitos expllcitos contenidos en el modelo de analisis, y debe ajustarse a todos los requisitos impllcitos que desea el cliente. El disefio debe ser una gula legible y comprensible para quienes generan c6digo y quienes realizan pruebas y, en consecuencia, dan soporte aJ software. El disefio debe proporcionar una imagen completa del software -dando direcci6n a los dominios de datos, funcionales y de comportamiento- desde una perspectiva de implementaci6n. cada una de estas caracteristicas es en realidad una meta del proceso de disefio. Pero, ;.c6mo se a\canza cada una de ellas?

fvncione IS una CD5CI; diseiiar

Directrices de caUdad. Can el fin de evaluar la calidad de una representaci6n de disefio se deben establecer los criterios tecnicos para un buen disefio. En secciones posteriores de este capitulo se expondran los conceptas de disefio que tambien siryen como criterios de calidad del software. Por ahara se presentan las siguientes directrices: I. Un disefio debe presentar una estructura arquitect6nica que oj se haya creado mediante patrones de disei'to reconocibles, b) la integren componentes que

PARTE DOS

RlACr1CA. a;: LA INGINIilllA. OEL SOFTWARE

, (1iI1ts SOl
las (GrOderistkDS 1Ie ..1 ... 1iHiD1

exhiban buenas caracterlsticas de diseno (estas se explican mas adelante este capitulo)' y c) pueda implementarse de manera evo!uliva, I para que de esla forma facilile la implemenlaci6n y las pruebas.

2. Un disefio debe ser modular, esto es, el software debera dividirse de man
l6gica en elementos osubsislemas.
3. Un disefio debe contener distintas represenlaciones de los datos, la arquitec

tura, las interfaces y los componentes.

4. Un disefio debe conducir a estructuras de datos que sean apropiadas para

dases que habran de imp!ementarse y que procedan de patrones de datos conocibles.
5 . Un diseilo debe conduclr a componentes que presenten caracterlsticas func::l,

nales independientes.

6. Un disefio debe conducir a inlerfases que reduzcan la complejidad de las co-nexiones entre los componentes y el ambiente externo.

7. Un diseilo debe obtenerse por media de un metodo repetible que se base eninformaci6n obtenida durante el analisis de requisitos del software.
8, Un disefio debe representarse por medio de una notaci6n que comunique cit

manera eficaz su significado. Estas directrices de diseilo no se logran por casualidad. EI proceso de diseiio del ware fomenta el buen diseilo aplicando principios fundamentales de diseno, metodologia sistematica y una re1lisi6n cuidadosa.

Evaluact6n de la caUdad del diseiio: 1a revtsl6n tknica lormaJ

EI diMli\o es importante porque permite que un equipo de ~ftwor. evolVe 10 cclidod1 del soft....c- Ollie! de implementorlo; es decir, en un momento en eI que los errores, omisiOl'lfls 0 inconsistencios $Ofl f6elles de corregir y no resulton corOl. Pero tcOmo ~ evolw 10 colidad durante eI diseiio' EI software no HI pvede comprobor porque no &JUsle un software ejecutable 01 cvoI opicone

pruebos. aOve debe hocene~

Durante eI diMli\o, 10 colidad HI eOIw 01 reoliZ(X' uno wrie de revisional Iknicos formales (RTF). Los RTf HI Iraton con detaIl. ... eI copitulo 26,3 pero rewlto...o!ioso

hocer un rewmen de 10 kknico en este punlo. Uno RTF. uno reuni6n que dirigen miembros del ~ipo de aoftwcn. Par 10 genertli porticipon dos, Ires 0 cuotro penonos, cIepende del6mbijo de 10 informoci6n de diseiio que HI revl$(lrQ. Coda persona desempeilo un popel: eI/leW de I"fNisi6n ploneo 10 reuni6n, .slob/eee Ia ogendo y despu6l reoli:tO 10 reuni6n; eI reIo#rx klmo notas pora que node _ oIvide; eI procIuc/w esla persona cuyo praducto de trabqD (par ejempIo. eI disei\o de un componenle del software)_ rl!lViso. Antes de 10 reuni6n, coda per$OOO en eI equipo de revili6n recibe uno copia del producto de Irabojo del
)

I Para sistemas mas pequenos algunas veres eJ disel\o puede desarrollarse en rorma lineal. 2 Los ractores de calidad tratados en el capitulo 15 pueden ayudar al equipo de revisi6n mientras evalua la calidad. 3 En este punlo se podrla cOIlSiderar la revlsl6n de]a secd6n 264. Las RTF son una parte critica proceso de disetlo y un mecanlsmo Importante para lograr Ja caUdad del diseflo

cAPiTuLo 9
.

INGENlERlA DEL DISENO

251

'r . ~ ,;do que 10 lea en oosca de errores, o ombigOedodes. Cuondo 10 reuni6n comienro, es detector todoslos problemo$ del produdo POl'll que e$\os pvedon C0fT89ir5e onte$ de que C ........... ,toci6n. L.o RTF liene uno dUl'Ilci6n tipica

de eolre 90 minulos y Oos hol'lls. AI conduir 10 RTF, el

equipo de revisi6n determino si se requieren acdones posleriores por parte del productor onles de que el prodocto de trobojo del di!.ei'lo pvedo oproborse como porte del mcxktlo de diseiio final.

Atributos de caUdad. Hewlett-Packard [GRAS7] desarroli6 un conjunto de atributos de calidad; entre ellos estan la funcionalidad, la facilidad de uso, la contiabilidad, el desempei'io y la soportabilidad. Estos atributos de calidad representan un objetivo para todo el disefto de software:

La fundonalidad se estima al evaluar el conjunto de caracteristicas y capacidades del programa. la generalidad de las funciones que se entregan y la seguridad del sistema en su totalidad.
LaJadJidad de uso se valora al considerar los factores humanos (capitulo 12), la estetica, consistencia y documentaci6n generales.

La conjiabiJidad se evalua al medir la frecuencia y severidad de las fallas, la

precisi6n de los resultados de salida, la media del momento de fallas (MMF). la habilidad para recuperarse de las falias y la previsibilidad del programa. EI desempeno se mide con la velocidad de procesamiento, tiempo de respuesta, consumo de recursos, rendimiento y eticacia.

L.o soportabilidad combina la habilidad de extender el programa (extensibiJidad), la adaptabilidad y la serviciabilidad -estos tres atributos representan un concepto mas comun,jadJidad de mantenimiento- ademas, resistencia a pruebas, compatibilidad, configurabilidad (habilidad para organizar y controlar elementos de la configuraci6n de software) (capitulo 27), la facilidad can que puede instalarse el sistema, y la facilidad can que se pueden localizar los problemas.
No todos los atributos de la calidad del software tienen el mismo peso cuando se desarrolla el disefto del software. Tal vez una aplicaci6n tenga un especial interes en la seguridad. Es posible que otra demande desempef'lo can un enfoque particular en la velocidad de procesamiento. Una tercera puede centrarse en la contiabilidad. Sin importar el peso, es importante puntualizar que estos atributos de caUdad deben considerarse al comienzo del disefio. no despues de que el disefio este completo y haya comenzado la construcci6n.

.,

PARTE DOS PRAcnc..t. DE LA INGENlERlA DEl. SOfiWARI

CONJUNTO DE TAREAS

Con/unto de tareas genencas para 61

1. Examiner eI modelo del dominio de 10 inlormoci6n y diwmar las Iltrucluras de dolos Ilpropiodos para los objetos de datos Y
sus otribulos 2. PO( medio del modeIo de on6lisis, seleccionar un e!tilo arquiled6nico IpatnSn) que sea apropiodo para eI software. 3. Dividir eI mOOeIo de oo6l;sis en wb~PemcI$ de diseOO y ubioor estos sub:listemos denlJ'o de Ia
arquileclvro.
A.$eguror~
IV

cUs6no
Evoluor y seleccionor patrones de di$8i'\o paro
ckl$e de diseOO 0 un lubsistema.
\oW'G

ReviSQr las dases de diseoo y modificor\as 5egUn. requiero.

DiMi"Jar CUCllqui interfaz requel'ido con sistemcao diSfX>SitiYO$ e;demo$. 6. DiMli\ar Ia intret10z del U5uorio. Reviwf los rewltoclc del on6Iisis de tor.os. E'I*=ificor 10 SVeOtio de oo:i6n con bose en
S.
elCenorios dellISOOrio.

de que coda wbsisMmo., ~ivCJ en

fvndonomienlo.

Crear un modeIo de comportamienlo de 10 in _ _ Definir los objetos de Ie intrerfaz. y mecani~ d.

Di5ei'oor las interfaces del $ubsislema. Ubicor doses 0 fvnciones de aOO lisis para coda subsisiemc:l.
4. Crear un conjunlo de do,.,s de di5elio 0 componenles.

"",1<01.
ReYi$(lr eI dileoo de 10 interfaz y modi~carlo seg... le requiero. 7. Conducir el diMilo 01 nivel de c:ornponentes. E'f)8Cincor todos los algol'ilmo$ a un grodo de

Troducir coda desaipci6n de los clo5e$ de o06lisis en

obwrocci6n reIativomen. baja.

Refiner Ie interf'uz de codo component.. o.finir esh'uduros de datos 01 nivel : : : : : : . ReviKlf coda componente Y corregir t descubieMc. DesarrollOf un rnodeIo de despliegue.

uno dose de diseno. Verificor coda dose de diseno conlro los uileriQ$ de diseOO; considerar los aspectos de 10 herencio. De~nir metodos y mensoies osociodos con coda dose de di5eiio.

a.

A lraves de la historia de Ja ingenierfa del software ha evoludonado un conjLln"'~" conceptos fundamentales de diseno de software. Aunque el grado de interes en concepto ha varfada can los anos, han pasado la prueba del tiempo. Cada uno ce al ingeniera de software un fundamento sobre el cual pueden apllcarse m.!to..... de disei'i.a mas elaborados. M. A. Jackson UAC75j dijo una vez: "El comienza de la sabiduria para [un niero de software] es reconocer la diferencia entre hacer que un programe y conseguir que 10 haga del modo correcto". Los canceptos fundamentales del flo de software ofrecen el marco de trabaja necesario para hacer las cosas "del correcto".

[UI"''''''.

9.3.1 Abstracc10n
muchosgrados de absrracci6n . En un alto grado de abstracci6n una soluci6n se bJece en terminos generales con el lenguaje del enlorno del problema. En los ;...... de menor abstracci6n se proporciona una descripci6n mas detaHada de la soluc'

Cuando se considera una soluci6n modular a cualquier problema se pueden .,,,,,,, ...1

cAPiTuLo 9

INGENIERiA DEL DlSENO

'53

En la medida en que cambian los diferentes grados de abstracci6n se trabaja para crear abstracciones procedimentales y de datos. Una abslracci6n procedimental se refiere a una secuencia de instrucciones que tiene una funci6n espedfica y Iimitada. El nombre de abstracci6n procedimental implica estas funciones, pero se omiten detaHes especificos. Un ejemplo de abstracci6n procedimental seria la palabra abrir para una puerta . Abrir implica una larga secuencia de pasos procedimentales (por ejemplo, caminar a la puerta, alcanzar la manija, darle vueita a la manija y empujar la puerta, hacerse a un lado para abrir paso a la puerta que se abre, etc.}.4 Una abstracd6n de datos es una colecci6n nombrada de datos que describe un objeto de datos. En el contexto de abstracci6n procedimental. abrir se puede definir como una abstracci6n de datos Hamada puerta. Como cualquier objeto de datos, la abstracci6n de datos para puerta abarcarfa una serie de atributos que la describan (por ejemplo, puerie, tipo. direoci6n de aperture. macanismo da aperture, peso, dimenalonea) . Se puede decir que la abstracci6n procedimental abrir emplearla la informaci6n contenida en los alributos de la abstracci6n de datos puerta.

9.3.2 Arqullectura
La

arquitectura del software alude a "Ia estructura general del software y las formas

en que la estructura proporciona una integridad conceptual para un sistema" [SHA95a]. En su forma mas simple, la arquitectura es la estructura u organizaci6n de los componentes del programa (m6dulos), la manera en que estos componentes interactuan, y la estructura de datos que utilizan los componentes. En un sentido mas amplio, sin embargo, los componentes pueden generalizarse para representar elementos importantes del sistema y sus interacciones.

"Une arquiteduru de software es eI produtto dellroboio de desarroRo que ofrete &1 mayor rendimienlo de 10 """'" ron respedo 0 Ia (aIidod, elliempo y eI (oslo.

tel less " ..

Una de las metas del diseno de software es derivar una representaci6n arquitect6nica de un sistema. Esta representaci6n sirve como el marco de trabajo a partir del cual se conducen actividades de disefio mas detalladas. Un conjunto de patrones

Sin embargo, debe notarse que un conjunto de operaciones puede reemplazarse con olro, siempre que la funci6n implicada por la abstracci6n de proccdimienlo sea la misma PDr 10 tanto, los pasos requeridos para implementar abrir podr1an camNr en forma sustancial si la puerta fuera automa tica y estuviera unida a un sensor.

PARTE DOS PRAcncA DE U INGENIElIlA DO. SOFTWAR

arquitect6nicos permite que un ingeniero de sonware reutil ice conceptos en el de disefio.

'" dol do;m ..

fX1I sf saki. Si fS(}
posD,

EI disef'io arquitect6nico puede representarse al Usaf uno 0 mas de muchos mock los diferentes lGAR95J. Los modeJos estructurales representan la arquitectura una colecci6n organizada de componentes del programa. Los

kl~sucedo

. _do -"""'''
1/ ffSto d6I
~de~sa

modelos del m"",,,.,,

trabajo incrementan el grado de abstracci6n del discno al intentar identificar rna

de tTabaja repetibles del diseno arquitect6nico que se encuentran en tipos de aplica cianes similares. Los modeJos dinamicos abordan los aspectos conductuales ~ arquitectura del programa, al indicar c6mo puede cambiar 1a configurad6n de la ~ tura 0 el sistema, como funci6n de los eventos extemos. LDs moddos del proceso
centran en el diseno del proceso tecnico 0 de negocios que el sistema debe nero Por ultimo, los mode/osji.mdona/es pueden utilizarse para representar 1a;er. quia funcional de un sistema. El diseno arquitect6nlco se expone en el capitulo 10

""""" tfsMo. ,"""'"

StItCO"
IIDII!IIII

inoefti'lj III IrafIX de

UfIdlu.

9.3.3 Patrones
Brad Appleton define un patr6n de discflo de la siguiente manera: "Un patrOn es semilla de conocimienlo, la cual tiene un nombre y transporta la esenda de una dOn probada a un problema recurrente dentro de derto contexte en medio de . reses en competencia" [APP98) . Dicho de olro modo, un patrOn de diseno desa... una estructura de diseno que resuelve un problema de diseno particular den",o.~ un contexto especifico y en medio de "fuerzas" que pueden tener un impacto en manera en que se aplica y utiliza el patr6n .
IXLrre una y otra 1111 til nuestro

La finalidad de cada patrOn de diseno es propordonar una descripciOn q"" Ie po'. mita al disenador determinar 1) si el patrOn es aplicable al trabajo actual, 2) 51

patron se puede reutilizar (por ende, ahorrar tiempo del diseno), y 3) si el puede servir como gula para desarrollar un patrOn similar, pero diferente en a 1a funcionalidad 0 estructura. Los patrones de diseno se exponen con mayor lie en la secci6n 9.5.

9.3.4

Modulartdad

Los patrones de arquitectura y diseno de software materializan la modularidad. decir, el software se divide en componentes con nombres independientes y que, ~::: ble abordar en forma individual. Estos componentes Ilamados m6dulos se ir para satisfacer los requisitos del problema.

Se ha establecido que la "modularidad es el atributo particular del software

permite que un programa sea manejable de manera intelectual" [MYE7S]. EI
sol\W~

re monolitico (es decir, un programa grande compuesto por un m6dulo sencilio)

C APiTuLo 9

INGENIER!A DEL DISENO

255

puede entenderlo con facilidad un ingeniero de software. EI numero de TUtas de conlrol, la amplitud de las referencias, el numero de variables y la complejidad general imposibililaria comprenderlo. Este punto se ilustra con el siguiente argumento, basado en observaciones de soJuci6n de problemas humanos. Considerense dos problemas, PI Y P2' Si la complejidad observada para PI es mayor que la de Pl se deduce que el esfuerzo requerido para resolver PI es mayor que el esfuerzo necesario para resolver Pl. Como un caso general, este resultado es obvio en el sentido intuitivo; la resoluci6n de un problema dificil toma mas tiempo. Tambien se deduce que la complejidad observada de dos problemas, cuando estan combinados, con frecuencia es mayor que la suma de las complejidades observadas cuando cada una de elias se toma por separado: esto conduce a una estrategia de "divide y venceras" (es mas facil resolver un problema complejo cuando este se divide en piezas mas manejables). Esto tiene implicaciones importantes can 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 reducira en forma sensible . Por desgracia, hay otras fuerzas que entran en juego, 10 que ocasiona que esta conclusi6n sea (tristemente) invalida. En relaci6n can la figura 9.2, el esfuerzo (costO) para desarrollar un solo m6dulo de software decrece confonne se incremenla el numero de m6dulos. Si se tiene el mismo conjunto de requisitos, mas m6d.ulos significan un tamano individual menor. Sin embargo, a medida que crece el numero de m6dulos, el esfuerzo (costo) asociado con la integraci6n de los m6dulos tambien crece. Estas caracteristicas conducen tamblen a la curva total del costo 0 e[ esfuerzo que se muestra en la figura. Existe un numero M de m6dulos que resultaria en un costa de desarrollo mlnimo, aunque hasta el momento no se tiene la sofisticaci6n necesaria para predecir M con seguridad. Las curvas que se muestran en la figura 9.2 proporcionan una guia util cuando se considera la modularidad . Esta debe aplicarse, pero se debe teneT cuidado de per-

I CosiO lolel del software

I

'eoslo por . mtegrar

, ......

Regi6n de cOllo

"'r--,'"
I I

",,""

,,'

-----p..q----Numero de m6dulos

Costo/ mOdulo

256

PARTE DOS

PRAcnCA DE LA ~ 00. SCFTWARE

manecer en la vecindad de M. Debe evitarse la modularidad excesiva 0 insuficiente. pero ic6mo puede conocerse 1a vedndad de M? tan modular debe hacerse eI software? las respuestas a estas preguntas requieren comprender atros conceptos de disefto que se considerartm despues, en este misrno capitulo. Un diseno y el programa resultante se modularizan de manera que el desarrollo se pueda planear con mayor facilidad; se puedan definir y entregar inerementos del software; los cambios puedan ajustarse con mayor faciJidad; las pruebas y la elinunaci6n de errores se pueda conducir con mas eficiencia. y el mantenimiento se pueda conducir sin efectos laterales de consideraci6n .

,Que

9.3.5 Ocultacl6n de 1n1ormacion

El concepto de modularidad conduce a todos los disenadores de software a formularse una pregunta fundamental: i.c6mo puede descomponerse una soluci6n de software para obtener el mejor conjunto de m6dulos? El principia de ocu/radon de inf ormaciOn [PAR72] sugiere que los m6dulos "se caracterizan por las decisiones de diseno que (cada uno) oculta a los otros~. En otras palabras, los m6dulos deben espedlicarse y disenarse de manera que la informaci6n (procedimienlo y dalos) que esu. dentro del m6dulo sea inaccesible para otros m6dulos que no necesiten esa informaci6n . La ocultaci6n implica que se puede conseguir una modularidad efectiva al defiru.un conjunto de m6dulos independientes que se comuniquen entre sf y que intercambien 5610 la informaci6n necesaria para lograr la funci6n del software. La abstracci6n ayuda a delinir las entidades de procedimiento (0 informaci6n) que conforman el software. La ocultaci6n define y fortalece las restricciones de acceso para loi detalles de procedimiento denlro de un m6dulo y para cualquier estructura de datm: local que ulilice el m6dulo IROS75). EI uso de la ocultaci6n de informaci6n, como un criterio de diseno para sistemas modulares, proporciona los mayores beneficios cuando se requieren modificaciones durante la realizaci6n de las pruebas y, despues, en el curso de mantenimiento del software. Como la mayorfa de los datos y procedimientos esta oculta de las otras partes del software, exisle una probabilidad menor de introducir errores inadvertidc al realizar las modificaciones y propagarlos a otros lugares denlro del software.

. "" C~VE
~
...... do. _""do

rioonocibn es reseMN .. dodos do .. esIn.O.IIls de 00I0s r cit lets ~1MlIien1Os cit prOCd1en1D detros de lIlII i1ter1oz
del....,.EI
{onoci1ienIo de los . . no debe tSIOr alctlJKt de IDs I.ISI.Dios del rOOdIAo,

9.3.6 Independencla fWlclonal

EI concepto de independencia fundonaJ es \a suma direcla de la modularidad y de 105 conceptos de abstracci6n y ocultaci6n de informaci6n. En referencias obligadas sabre eJ di.seno de software, Wirth [WlR7 JI y Pamas [PAR721 aJuden a las tecnicas de re6namiento que mejoran la independencia de los m6dulos. Trabajos posteriores de Stevens, Myers y Constantine [STE74] consolidaron el concepto. La independencia funcional se consigue a\ desarrollar m6dulos con una fun cit:.l' -delerminante~ y una Haversi6n" a Ja inleracci6n excesiva cen otros m6dulos. Dici"D de etra manera, se desea disenar el software de tal manera que cada m6dulo aborde una subfunci6n especlfica de los requisites y tenga una sola interfaz cuando se

cAPinrr.o 9

INGENIEIUA DEL DISENO

257

observe desde otras partes de la estructura del programa, Es justo preguntarse por que es importante la independenda. El soflware con una modularidad efectiva, es dedr, con m6dulos independientes, es mas facil de desarrollar porque la fund6n se puede fraccionar y las interfaces se simplifican (considerense las ramificadones cuando el desarrollo se realiza en equipO). Los m6dulos independienles son mas faeiles de mantener (y probar) porque se limitan los efectos seeundarios que onginan las modifieaciones al disefio 0 al c6digo, se reduce la propagaci6n de errores, y es posible emplear m6dulos reulilizables. En resumen, la independencia funcional es una clave para el buen disefio, y el diseno es la clave para lograr la calidad del software. La independencia se evalua aplicando dos criterios cualitativos: eohesi6n y aeoplamiento. La eohesi6n es una medida de la fuerza funcional relativa de un m6dulo. EI acoplamiento es una medida de la interdependencia relativa entre los m6dulos. La cohesi6n es una exlensi6n natural del concepto de ocultaci6n de informad6n descrito en la secci6n 9.3.5. Un m6dulo cohesivo realiza una sola tarea, para 10 que requiere muy poca interacci6n con otros componentes en otras partes del programa. Dicho de manera sendlla, un m6dulo cohesivo debe (idealmente) hacer s610 una cosa. EI acoplamiento es una medida de la interconexi6n entre los m6dulos de una estructura de software. EI acoplamiento depende de la complejidad de la interfaz entre los m6dulos, el punto donde se realiza una entrada 0 referenda a un m6dulo, y los datos que pasan a traves de la interfaz. En el disefio de software se intenta conseguir el acoplamiento mas bajo posible. Una conectividad sencilla entre los m6dulos da como resultado un software mas facil de entender y menos propenso a experimentar el "efecto ola" [STE74J, el eual se presenta cuando surgen problemas en un lugar y despues se propagan a traves del sistema.

9.3.7 Refinamiento
El refinamiento paso a paso es una estrategia de disefio descendente que propuso inidalmente Niklaus Wirth [W1R71J. EI desarrollo de un programa se realiza al refinar de manera sucesiva los niveles de detalle procedimentales. Una jerarquia se desarrolla al descomponer el enunciado macrosc6pico de una fund6n (una abstracci6n procedimental) paso a paso hasta alcanzar las oradones dellenguaje de programaci6n. En realidad, el refinamiento es un proceso de eJaboraci6n. Se inicia con el enundado de una funci6n (0 una descripci6n de datos) que se define con un alto grado de abstracci6n. Esto es, el enunciado describe los datos 0 la funci6n de manera conceptual, pero no proporciona infonnaci6n acerca de los trabajos internos de la funci6n 0 de la estructura intema de los datos. EI refinamiento hace que el disefiador trabaje sobre eJ enunciado original y que proporcione mas y mas detalles confonne se realiza cada refinamiento sucesivo (elaboraci6n) . La abstracci6n y el refinamiento son conceptos complementarios. La abstracci6n Ie pennite a un disenador especificar procedimientos y datos sin considerar detalles

258

PARTE DOS

PAA.CI'lCA DE!J\.!NGmII'lllA. DEl. S(lnWARE

de grado menor. EI refinamiento ayuda al disetiador a revelar los detalles de menor mientras se realiza el disei\o. Ambos conceptos auxilian al disenador er creaci6n de un modele de disefio completo a medida que evoJudona la actividad disef\o.

9.3.8 Refabricaci6n
Una actividad importante de diseno que sugieren muchos metodos agiles 104) es la re/abriCfld6n, tecnica de reorganizaci6n que simplifica el disei'lo (0 de un componente sin cambiar su funci6n 0 comportamiento. Fowler IFOW99J ne 1a refabricaci6n de la siguiente manera: "La refabricaci6n es el proceso de biaT un sistema de software de tal forma que no se altere el comportamiento no de su c6digo [diseflo] y aun as[ se mejore su estructura interna." Cuando un software se re fabrica el diseflo existente se examina en busca redundancias, elementos de disef\o inutiles, algoritmos innecesarios 0 , ' r "ulnd.", ... estructuras de datos inapropiadas 0 construidas de manera incorrecta. 0 c~~: otra falla de diseno que se pueda corregir para lograr un mejor disei'io. Por c una primera iteraci6n de diseno podrla producir un componente que muestra p! cohesi6n (realiza tres fundones que tienen muy pocas reladones entre sf). E1 nador puede decidir que el componente debe refabricarse en tres componentes tintos, cada uno de ellos con una elevada cohesi6n. El resultado sera un """". mas fadl de integrar, probar y mantener.

C._

lie tIIM:IIo

~'.l::=:.'"' c..a;"Io do V<n<>d,

.......
Sh.1dra: Yo no .....

.......

cAPiTuLo 9

INGENIERiA DEl. 0!SEN0

259

....... 1roIo.
una COlO, ,...;I;mo-

'!roc S. \IIiIiza en ...,......

lIo\iil'i!

esc dilO . . 51.

._ .
..... do
INIIIIo .... 0 refinor

Iohoooo .......
~'''''''''Si

""'~ _
~

............. _doodo_
9.3,9 Clases de d1seiio
En el capitulo 8 se mendon6 que el modelo de analisis define un conjunto completo de clases de ana lis is. cada una de eslas clases describe alglin elemento del dominio del problema, con enfoque en los aspectos del problema visibles para el usuario o el cliente. EI grado de abstracci6n de una c!ase de analisis es relativamente alto. Conforme evoluciona el modelo de diseiio, el equlpo de software debe definir un conjunto de clases de diseno que I) refine las clases de analisis al proporcionar detalles del diseiio que permitiran la implementacl6n de las clases, Y 2) produzca un conjunto nuevo de clases de diseiio que implementen una infraestructura de software para soportar la salud6n del negodo. Se sugieren dnco diferentes tipos de c!ases de diseflo, cada uno representa una capa distinta de la arquitectura de diseiio [AMBOI I
Las clases de interfaz con cI usuario definen taclas las abstracciones necesarias

para la Interacci6n humano-computadora (IHq. En muchos casas, la IHC ocurre dentro del contexte de una meldfora (por ejempla, un libra de verificaci6n, un formata de orden, una maquina de fax) y las clases de diseiia para la interfaz pueden ser representaciones visuales de los elementos de la metMora. Las closes del dominio de negocios a menudo son refinamientos de las c!ases de antllisis definidas antes. Las clases identifican los atributos y servidos (melaclos) necesarios para implementar algUn elemento del dominio de negocios. Las closes de proceso implementan abstracciones del negocio en un nivel mas bajo, las cuales se requieren para maneJar por completo las clases del dominio de negocios. Las clases persislenles representan almacenamientos de datos (por ejemplo, una base de datos) que persistiran mas alla de la ejecuci6n del software.

 Las c/aS(:$ de sistema implementan las funciones de gesti6n y control del software que permiten que el sistema opere y se comunique dentro de su entomo de computaci6n y con el mundo exterior. A medida que evoluciona el mooelo de diseno, el equipo de software debe des.. liar un conjunlo completo de atributos y operaciones para cada clase de discto grado de abstracci6n se reduce conforme cada clase de anillisis se transform. una representaci6n del disefio. Esta es, las c1ases de aniliisis representan obte' servicios asociados que se aplican a estoS) usando la jerga del domi nic de negt" Las clases de disefio presentan un mayor detalle tecnica, pues son una guia implementaci6n Arlow y Neustadl [ARL..02] sugieren revisar cada clase de diseflo para a~:~:~ la misma este "bien formada" Ellos definen cuatrc caracteristicas de una disei\o bien formada: Comp1eta y sufidente. Una clase de diseno debe ser la encapsulaci6n ta de tooos los atributos y metooos que se pueden esperar, en forma razonabk base en una inlerpretaci6n reconocible del nombre de la clase). que existan clase. Por ejempla, Ja clase escena definida para el software de edici6n de esta completa 561 0 si contiene lodos los atributos y melodos que pueden a de manera razonable con la creaci6n de una escena de video. La suficiencia ra que la c1ase de diseno contenga 5610 aquellos metodos que sean suficiente5 lograr el objetivo, ni mas ni menos. PrimJtivismo. Los mttodos asociadas con una clase de diserio deben e en el cumplimienta de un servicio para la clase. Una vez que el servicio ty implementada can un mttodo, la c1ase no debe proporcionar atra forma de mentar la misma cosa. Por ejemplo, la clase vtdeocllp del software de edl video podrian tener atributos punfo..inici81 y punto-llna1 para indicar los puntos ~ y fin del clip (n6tese que el video brute cargado en el sistema puede ser mas que el clip que se usa). Los metodos CSlabiecerPuntolnicial( ) y establecerPUntoFinat porcionan los unicos medios para configurar los puntos de inicio y fin del clip. Cohesion alta. Una clase de disei\o cohesiva tiene un canjunta de responsdades pequeno y enfocada, y aplica atributos y metodos de manera senciUa implementar dichas responsabilidades. Por eJemplo, la clase VideocHp del re para la edici6n de video podria conlener un conjunto de metodos para ediI. videoclip. Mientras cada metodo se enfoque 5610 en atributos asociadas can eI clip se mantendra la cohesi6n Acoplamiento baJo. Denlro del modela de dlsena es necesario que las c~'"":t; diseno colaboren con alguna atra. Sin embargo, la calaboraci6n se debe mar en un minima aceptable. Si un modele de disei\o tiene un acoplamiento alto las clases de disena calaboran can lodas las otras clases de disenol, el sisteMI. dificil de implementar, prcbar y mantener a traves del tiempo. En general, las

,Qd.,

fonnoda-?

.....

... daUN

cAPiTuLo 9

lNGENtERlA DEL DISENO

2.'

de disena dentra de un subsistema deben tener s610 un conocimienta limitada de las clases en atros subsistemas. Esta restricd6n, llamada la L()' de Demeter [UEOJ]. sugiere que un metoda s6la debe enviar mensajes a metodos de clases vecinas. 5

PlanodaPianta
lipo

la 1

dimensiol\es exl&fiores agregarC6mora( ) agregorPored{ ) ogregorVenlono( ) borrarSegmerlto[ ) dibuiar{ )

CO""""

"po ;d
Compocievision Angulodebvsqueda Configuroci6nocercamiento

.............
Coordenodoinicio Coordenadofin oblenefTipo{ ) dibl.t"or{)

<.;. '

I
Segmentodepored

I
Vontana

000

RejlnadOn de una dase de onaJisis en una close de dJseJto

If ....... 10' Cubtculo de Ed,

diseilo.

Vinod y Ed. ~ del equipo de

Ed: Enlonces trec::verdos\a dose PI_ad,PIon'., ,.,. Se utilil:O coma una porte de ku funciones de vigib1cia adminisl!"oci6n del hogor.
Vinod (ofirmando con Ia cabna): 5i, me porec:e recordar que 10 IJKlmos como porte de I\tleslfos crnaIilis de CRC para 10 odministroci6n del hogor.

do. PkInocIePkmta {*5e el eI ~cIe 10 $lltciOn 8.7.4 y 10 figura L lAll y ~ ha reI1nodo para eI modelo de di5ei\o.1

Ed: to hicilTlO$ De CVCIlquier m<:mera, 10 esloy re~nondo para eI di$GiiQ Quiero mosltar c6Ino implementoremos

5 Una fonna menos formal de enunciar Ia Leyde Demeter es: amigos; no oon extrailos

~Cada

unidad debe hablar 5610 con sus

262

da.. .. " -

(Ed 10_. __.1.".

_Yo""""
Iuroe:iOll0l6.

EI mode/o de diseno puede verse en dos dimensiones diferentes, como se ilustra m la figura 9.4. La dimension del proceso indica la evoluci6n del modelo de diseno COP forme se ejecutan las tareas de disei'io como una parte del proceso del software LI dimensi6n de abstrocd6n representa eJ grado de detalle a medida que cada elemta

&,

~~

C&VE
EI modeIo de tiseOO Iiene cootro elementos

to del modele de analisis se transforma en un equivalente del diseflo y despues .!iii::: retina de una manera iterativ3. En la figura , la linea punteada indica la frontera enbe: los modelos de analisis y disei'io. En algunos casos se distingue con cJaridad entre bI: modelos de anal isis y disei'io; en otros, e l modelo de analisis se combina con el disrflo y la distinci6n resulta menos obvia.
Los elementos del modele del diseiio ulilizan muchos de los diagramas en U aplicados en el modelo de ana!isis. La diferencia es que estos diagramas estan rt' nados y elaborados como parte del diseno; se proporciona un mayor detalle para implementaci6n especlfica y se resaltan la estructura y el estilo arquitect6nicos, kI5 componentes que residen dentro de la arquitectura y l as interfaces entre los componentes y con el mundo exterior .

in!Jortantes: ~105,
nr~9(1IIll,
~!ese

i1terluz.

... ,.... D'QIIit g II diseiio IS IIIJU'SIIio I) eviJDbIa esIin basant n.a ... II ........... II ..... 11 . . . . IS IIIIIDI Rio Y MI su ilexisJendD.

......

Sin embargo, es importante mencionar que los elementos del modele anotados JI 10 largo del eje horizontal no siempre se desarrollan de una manera secuencial. E:;. la mayoria de los casos, el diseno arquitect6nico preliminar establece la plataforrra y 10 siguen el diseno de interfaz y el diseno al nivel de componentes. los cuales hasta que el diseno ha side desarrollado por completo.
JI

menudo se realizan en paralelo. EI modelo de despliegue con frecuencia se retrasl

C APiTULO 9

lNGENIEillA DEL DlSENO

263

Dimensiones d el modelo de diselio.

:................ 1

""" I

<I.

E~!<>I"ln .....1

inlo<k>z

0.

com,........,...

Dimension del proceso

9.4.1

Elementos del diseno de datos

Al igua\ que atras actividades de la ingenieria del software, el diseilo de datos (algunas veces llamado arquitectura de datos) crea un modelo de datos 0 informaci6n que se representa con un alto grado de abstracci6n (la visi6n de los datos del cliente/usuario). Despues, este modelo de datos se retina en representaciones que de manera progresiva tienen una implementaci6n especifica y que pueden procesarse mediante el sistema basado en computadora. En muchas aplicaciones de software la arquitectura de los datos tendra una profunda influencia sobre Ja arquitectura del softwa-

re que los debe procesar.

La estructura de los datos siempre ha sido una parte importante del disei'io del

software. AI nivel de los componentes del sistema, las estructuras del diseno de datos y los algoritmos con que se manipulan son esenciales para la creaci6n de aplicaciones de alta caJidad. AI nivel de aplicaci6n. la traducci6n de un modelo de datos (obtenido como una base de la ingenieria de requisitos) a una base de datos es esencial para alcanzar los objetivos de negocio de un sistema. Al nivel de negocios, la colecci6n de informad6n almacenada en bases de datos dispersas y reorganizadas en una "conjunci6n de datos" pennite Ja explotaci6n de datos 0 el descubrimiento de un conocimiento que puede tener un impacto sobre el exito del mismo negocio. En

PARTE DOS

PR.i.CnCA DE LA ItGNlIlIiA IEL!CIF!'WARE

cada caso, el diseno de datos juega un papel importante. El diseno de datos se expi-

&!'

u:",

ca con mayor detalle en el capitulo 10.

C&VE
EI modeIo

9.4.2 Elementos del d1seiio arquitect6nJco

E! disefio arquitect6nico para el software es el equivalente al plano de planta de una casa. Este plano muestra la configuraci6n general de las habitaciones, su tamano forma y las relaciones entre elias, y las puertas y ventanas que penniten el mO'!" miento hacia y desde los cuartos. EI plano de planta proporciona una visi6n glob& de la casa. Los elementos del diseno arquitect6nico dan una visi6n general del d

.... ....... dO_

dos YpaIIOMS ~

OIcp.itect6rtO S4I dO_~

~-Y"

ware.

El modelo arquite<:t6nico (SHA96) se obtiene a partir de tres fuentes: I) la infCl' maci6n acerca del dominic de aplicaci6n para el software que se va a construir _ los elementos del modelo de analisis especifico, tales como diagramas de nUJo datos 0 clases de analisis, sus relaciones y colaboraciones para el problema q~ Uene a la mano, y 3) la disponibilidad de patrones (secci6n 9.5) y estilos arquiteru.. nicos (capitulo 10).

9.4.3 Elementos de disefio de interfm

El discfjo de interjaz para software es el equivalente a un conjunto de dibujos deta \lados (y especificaciones) para puertas, ventanas y utilidades extemas de una C<lSl. Estos dibujos representan el tamano y forma de las puertas y ventanas. la manera er que operan, la manera en que las conexiones de las utilidades (como agua, energ.... eiectrica, gas, teiefono) lIegan a la casa y se distribuyen entre las habitaciones representadas en el plano de planta Estes dibujos indican d6nde esta localizado el ti bre de la puerta, si hay un intercomunicador que anuncie la presencia de un visitar te y c6mo esta instalado el sistema de seguridad En esencia, los dibujos (yespecmcaciones) detallados para las puertas, ventanas y utilidades extemas indican c6mnuyen las casas y la informaci6n desde y hacia la casa y dentro de las habitacioncs que son parte del plano de planta. Los elementos del diseiio de interfaz para soft ware muestran c6mo fluye la infonnaci6n hacia a fuera del sistema y c6mo este est. comunicado entre los componentes definidos como parte de la arquitectura

tEl 1Mb e:'Jb II'ItIs fII,.inO:t ton II . . _ "" II ... En M, est6 (QI.mmo I) ~ tllIIII" pIIIIJII 51 ;
((WI

~ kl fPJe Wwe_ to ""'" IS 1IIIRlIIIIt,1o'" es WII}IO.'

,...a.I

Existen lres elementos importantes del disei'lo de interfaz: I) la interfaz con d usuario (IU); 2) interfaces externas a olros sistemas, artefactos, redes u otros pro ductores 0 consumidores de informaci6n; y 3) interfaces intemas entre varios com

C APiTuLo 9

!NGENIERIA DEL D!SENO

265

ponentes de diseri.o. Estos elementos de diseno de interfaz penniten al software comunicarse de manera externa y penniten la comunicaci6n y colaboraci6n intema entre los componentes que pueblan la arquitectura del software. El diseno de la IU es una acci6n primordial de la ingenieria de software, y se considera con detalle en el capitulo 12. EI diseno de una IU incorpora elementos esteticos (par ejemplo, distribuci6n, color, graficas, mecanismos de interacci6n). elementos ergon6micos (por ejemplo, informaci6n y ubicaci6n de la distribuci6n, metaforas, navegacion de la IU), y elementos tecnicos (como patrones de la IU, componentes reutilizables). En general. la IU es un subsistema unico dentro de la arquitectura de aplicaci6n general. EI disefio de las interfases extemas requiere informacion definitiva acerca de la entidad hacia donde se manda a recibe la infonnaciOn. En todos los casos, esta informaci6n debe recopilarse durante la ingenieria de requisitos (capitulo 7) y verificarse una vez que comience el diseno de la interfaz. 6 EI diseiio de interfases externas debe incorporar revision de errores y (cuando sea necesario) caracteristicas apropiadas de seguridad. El diseno de las interfaces intemas esta cercanamente alineado can el diseno aJ nivel de los componentes (capItulo II). Las realizaciones del diseno de clases de analisis representan todas las operaciones y esquemas de mensajes requeridos para permitir la comunicaci6n y colaboraci6n entre las operaciones de vadas clases. Cada

TelefonoMovii PDAlnalombrico

,
PoneldeControl

"

"

ponlllllolCD il"ldkodoreslED corocter!sticosTeclodo

bocino

, , , , , ,, ,, ,,, , ,

V. Teclodo
-, ,
,

, ;,f,.

,r,oI6mb,',"
lnterFoz Teclodo eerGolpede1edo( ) decodificorTeclo( 1

IeerGolpedeTeclo( I decodi~corTeclo( ) desplegorEslolu5( )

iuzLfD5j)

enviorMensojeControl( )

:-

No resulta poco comun que las caracterishcas de 1a mterfaz camblen con el tiempo. Por 10 tanto. un diser'tador debe asegurar que Ia. especificaci6n parilia mterfaz se manlenga actualizada

PARTE DOS PIlAcncA DE LA INGlNIDdA DEl. SOf'TWAJI

mensaje debe ser disenado para ajustarse a la transferencia de informaci6n de reqw. sitos y los requerimientos funcionales especificos de la operaci6n que ha sido solidtada. En algunos casas, una interfaz se modela de una manera muy parecida a UI'LI clase. El UML define una inlaj'az de la slguiente manera [OMGO\): "Una interfaz es un determinante de las operaciones lPublicasl visibles de manera externa de una clase, componente u otro c1asificador (incluidos los subsistemas) sin especificaciOr de estructura interna". Oicho de un modo mas simple, una interfaz es un conjuntC" de operaciones que describe parte del comportamiento de una c1ase y propord~ acceso a esas operadones. Por ejemplo, la fund6n de seguridad de HogarSeguro emplea un panel de cont que pennite al propietario de la casa controlar ciertos aspectos de la funci6n de seguridad. En una versi6n avanzada del sistema, las fundones del panel de contro. pueden implementarse via PDA inalambrico 0 telefono m6vil. La clase Paneldecontrol (ligura 9.5) proporciona el comportamiento asociack. con un teclado y, por 10 tanto, debe implementar operaciones de 1t:efleclaPresionada y decodificotTeda( ). Si estas operaciones se suministraran a atra clase (en este caso a PDAlnalAmbrtco y TelefonoM6vU), resulta inuUl delinir una interfaz como la que se muestra en la ligura. La interfaz llamada Teclado se muestra como un este reotipo de interfaz 0 como un arculo pequeno y etiquetado que se conecla .. la cJase con una linea. La interfaz se define sin atributos y con el conjunto de ope:. raciones necesarias para lograr el comportamiento de un teclado .

... _ ...... a.lllils pInDIIIIS amIo IrU de cDia aIgooo,ht. s'Is ............
'. .. . . . . . . . . . . . . . . r

I' 'iiM'lslantvs.

......

La linea punteada can un triangulo abierto en su extremo (figura 9 .5) indica que la clase PaneldeControl propordona operaciones de Teclado como parte de su comportamiento. En UML esto se caracteriza como una rmljzaci6n. Esto es, parte del comportamiento de PaneldeControl se implementara al realizar las operaciones de Teclado. Estas operaciones se proporcionaran a otras clases que entren a la interfaz.

9.4.4 Elementos de disefio al nivel de componentes

EI diseno al nivel de componentes para el software equlvale a un conjunto de dibujos detallados (y especilicadonesj para cada cuarto en una casa. Estos dibujos mues-lran el alambrado y la instalaci6n sanitaria dentro de cada cuarto, la ubicaci6n de los receptaculos electricos e interruptores, lIaves, lavabos, tinas, desagOes y armarios Tambltn describen los pisos que se usaran, los moldes que se aplicaran, y cualqu~ olTO detalle asociado can el cuarto. El disei'lo al nivel de componentes para software describe por completo el detalle interno de cada componente del software. Pa~

CAPinn.o 9

INGENIERlA DEL 0ISN0

267

MonIIISemor

----G

lograrlo el diseiio al nivel de componentes define estructuras de datos para todos los objetos de datos locales, asl como detalle algorftmico para todo e\ procesamiento que ocurre dentro de un componente y una interfaz que permite el acceso a todas las operaciones de los componentes (comportamientos).

Dentro del contexto de la ingenieria 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 lIamado ManejoSensoT (parte de la funci6n de seguridad de HogarSeguro). EI componente esta conectado a una clase lIamada sensor, la cual esta asignada a este mediante una flecha punteada EI componente ManeJoSensor realiza todas las funciones asociadas can los sensores de HogarScguro, entre las que se encuentran su monitoreo y configuraci6n. En el capitulo 11 se presenta una explicaci6n mas a fonda acerca de los diagramas de componente. Los detalles de diseno de un componente se pueden modeJar a muchos grados distintos de abstracci6n. En la representaci6n del procesamiento l6gico se puede utilizar un diagrama de activldad. EI flujo detallado de procedimiento para un componente puede representarse, ya sea mediante un pseudoc6digo (una representaci6n del lipo de lenguaje de programaci6n que se describe en el capitulo II), a de algun formato diagramatico (por ejemplo, un diagrama de aclividad 0 un diagrama de flujO).

9.4.5 Elementos de d1seiio a1 rovel del despUegue

Los elementos de disefto al nivel del despliegue indican c6mo se ubicaran la funcio naJidad y 105 subsistemas dentro del entomo computacional fisico que soportara al software. Por ejemplo, los elementos del producto HogarSeguro estan configurados para operar dentro de tres entomos de computad6n primarios: una PC domestica, el panel de control de HogarSeguro y un servidor ubicado en CPI corp. (10 que proporciona acceso al sistema a traves de Internet) Durante el diseno se desarrolla un diagrama de despliegue en UML y despues se retina, como se muestra en la figura 9 7 En est.a se muestran tres ambientes computacionales (en reaJidad, deberfa haber mas, si se incluyen sensores, camaras y otres). Se indican los subsislemas (funcionalidad) que se alojan dentro de cada ele-

PARTE DOS

PRAcnc:A. DE LA ~ DIl.!iOFTWAJE

-.
DIaguana de deopIJegue
onUMLpma

.............
/

....W.

_(III

-e-op-~ I
1/

/
~-

u u rexMmO ~ _:

...

f"~1
fAd"'in,1Iroc

f'-~

I
/

Comunicoci6n

'C~VE

.............

.... """"
.douiJo ..

lm <iog<oom ~ do!oiogoo"""""

mento de computo. Por ejemplo, la computadora personal aleja subsistemas qu:; implementan seguridad, vigilanda. administraci6n del hogar y caracteristicas cit. comunicaci6n. Ademas, se ha disei'iado un subsistema de acceso extemo para contT olar lodos los inlentos de acceso al sistema HogarSeguro desde una fuente exter

--"' . ........ _do.

...,.,do
t: ..

doa\JIo..... ~

na. cada subsistema sena elaborado para indicar los componenles que implemen~ EI diagrama mostrado en la figura 9.7 esta en/arma de descriptor. Esto signiflCll que el diagrama de despliegue muestra el enloma computacional. pero no indica de
manera explicita detalles de configuraci6n Por ejemplo. no se identilica 1a "compuladora personal~. Podria seTuna "Wintel" PC 0 una Macintosh, una estaci6n de tR bajo Sun a una Unux-box. Estes detalles se proporcionan cuando el diagrama de despliegue se revisa en forma de ;nslOnda durante etapas posteriores del diselio 0 cuanda camienza la canslrucd6n. Se identifica cada instancia del despliegue (UM configuraci6n de hardware can un nambre especifica).

IlespJ6s se otizo 1II krmoto de itstlIril Y

...... , _ _ .. _ ,...... c.....Io ...'''''~ ....., ......... "" _ _ ""

............ 1IIIDIU5 II treIIaio pIIrtCI rrm,.,-,.. rr.yor parte.w .... , .......... .,,,...rnin SIt obsena COl _ hdidai.-

1'IIisIIo,... ........

CAPInn.o 9

INGENIERiA DEl DISENo

'69

Los mejores disenadores 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 soluci6n. A traves del proceso de

disefio, un ingeniero de software debe buscar tada oportunidad para reutilizar patrones de diseno existentes (cuando cumplen las necesidades de un diseno) en vez de crear nuevos.

9.5.1 Desctlpc\6n de un patrOn de dJseno

Las disciplinas maduras de la ingenieria utilizan miles de patrones de diseno Por ejemplo, un ingeniero mecanico utiliza un eje de dos pasos como un patrOn de diseno clave. Los atributos (di.ametros del eje, dimensiones del orificio de las Ilaves, etcetera) y [as operadones (por ejemplo, la rotad6n del giro y la conexi6n del giro) son inherentes al patr6n . Un ingeniero electrico utillza un circuito integrado (un patr6n de disefio en extrema complejo) para resolver un etemento especlfico de un problema nuevo. Los patrones de diseno pueden describirse empteando la plantilla IMAJ03J que se muestra en el recuadro ~Plantilla del patr6n de diseno~.

Plantilla del patr6n de

cUseno
Porticipanles: describe las responsobilidodM de len doses que se requieren para implemenlar eI patron.

Nombre del po/r6n: describe Ia esencio del polr6n en un nombre coria, pera expr8sivo.

_...,do.."ibo,. p""" y ~ q... ha<o. ...._""""',"'"~~,. lisla 105 sin6nimos pore eI

CaIabarocianes: describe c6mo coIaboran 105 participontes

para llevar 0 cobo ws responsabilidodes.
Consecuencias: c!eKribe leu "liJerzos de disei\o" que olectoo 01 patf6n y 105 intercombios poIencioles que deben COflsiderorse cuondo WI implemenlo eI potr6n. Pofrones reIociooodos: polrones de disei'!o reIocionodos mediante ref.entnc:ios cruzodos.

Una descripci6n del patr6n de diseno puede considerar tambien un conjunto de fuerzas de diseno. Las Juerzas de disef!o describen requisites no funcionales (por ejemplo, facilidad de mantenimiento, portabilidad) asociados con el software en el que se aplicar.a eJ patr6n. Ademas, las fuerzas definen las limitaciones que restringen la manera en que se implementara el diseflo. En esenda, las fuerzas de diseiio describen el ambiente y las condiciones que deben existir para que el patr6n del disefio sea aplicable. Las caracterfsticas del patron (ciases, responsabilidades y colaboraciones) indican los atributos ajustables del diset\o para permitir que el patr6n se ajuste a una variedad de problemas IGAM95J . Estos aUibutos representan caracteristicas del diseiio que pueden buscarse (por eJemplo. a lraves de una base de datos)

210

para que sea factible encontrar un patron apropJado. Por ultimo, la gula
diseno.

asoc:i.J;",.

con el uso de un patron de disei\o indica las ramificaciones de las dedsiones

LDs nambres de los palrones de diseno deben elegirse con cuidado. Uno de problemas tecnicos clave en la reutilizad6n de software es 1a [alta de habilidad

--

encontrar patrones reutilizables existentes, a pesar de que existen cientos 0 miles

patrones. La bUsqueda del patron ~correcto" tiene un apoyo inmenso si se aa' con un nambre slgnificativo del patr6n.

9.5.2 Ut1l1zac16n de patrones en el disefto

Los patrones de diseno pueden usarse durante eJ diseno del software . Una vez

se ha desarrollado el modele de analisis (capitulo 8), el diseftador puede exa

una representaci6n detallada del problema que debe resolver y las restricciones impone el problema. La descripd6n del problema se examina en varios grados abstracci6n para detenninar si es flexible para uno 0 mas de los siguientes tipos de pat:'

nes de diseno.

,aui tipos
de patrones

Patrones arqultect6nlcos. Estos patrones definen la estructura general del ware, indican las relaciones entre los subsistemas y los componentes del soft y definen las reg las para especificar las relaciones entre los elementos ( paquetes, componentes. subsistemas) de la arquitectura. Patrones de diseiio. Estos patrones se aplican a un elemento espedfico diseno como un agregado de componentes para resolver alg(ln problema de d relaciones entre los componentes 0 los mecanismos para efectuar la comunicaa. de componente a componente. ldiomas. A veces lIamados patrones de c6digo, estos patrones especificos de guaje por 10 general implementan un elemento algoritmico 0 un componente protocolo de interfaz espedfico 0 un mecanismo de comunicaci6n entre los c nenles. cada uno de los tipos de patrones difiere en el grado de abstracci6n can el esta representado y con el grado en el que proporciona una guia directa para la vidad de construcci6n (en este casc, codificaci6n) del proceso de software.

9.5.3 Marcos de trabajo

En algunos casas es necesario proporcionar una infraeslructura esque[etica espe fica de implementad6n. Ilamada marco de trabajo, para el trabajo de diseflo. Esto el disenador puede seleccionar una "miniarquileclUra reutilizabJe que ofrezca el

cAPiTuLo 9

INGENIERiA DEl. DlSENO

271

en

portamiento y la estructura generica para una familia de abstracciones de software. junto con un contexto .. que especifique su colaboraci6n y uso dentro de un dominio dado" [APP98j. Un marco de trabajo no es un patr6n arquitect6nico. sino un esqueleto con una colecci6n de "puntos de conexi6n" (tambien llamados ganchos y ranuras) que Ie permiten adaptarse a un dominio de un problema especlfico. Los puntos de conexi6n permiten al disenador integrar clases a funcionalidad especificas del problema dentro del esqueleto. En un contexto orientado al objeto. un marco de trabajo es una colecci6n de clases que cooperan. En esencia. el disenador de un marco de trabajo argumentara que una miniarquitectura reutilizable se puede aplicar a todo el software que se desarrollara dentro de un dominio limitado de aplicaci6n. Para que sean mas efectivos, los marcos de trabajo se aplican sin cambios. se pueden agregar elementos de diseno adicionales. pero s610 a traves de los puntos de conexi6n que permiten que el disefiador desarrolle el esqueleto del marco de trabajo.

La ingenieria de disefio comienza cuando la primera iteraci6n de la ingenieria de

requisitos llega a su fin. La finalidad del disefio de software es aplicar un conjunto de principios, conceptos y practicas que conducen al desarrollo de un sistema 0 producto de alta calidad. La meta del disefio es crear un modelo de software que imp lemente todos los requisitos del c1iente de manera correcta y complazca a aquellos que 10 usen. Los ingenieros de disefio deben examinar por media de muchas alternativas de disefio y converger en la soluci6n que mejor cumpla las necesidades de los interesados en el proyecto. EI proceso de diseno avanza de una visi6n general de software a una visi6n mas estrecha que define el detalle requerido para implementar un sistema. EI proceso comienza con un enfoque en la arquitectura. Se definen los subsistemas; se establecen mecanismos de comunicaci6n entre los subsistemas; se identifican los componentes; y se desarrolla una descripci6n detallada de cada componente. Ademas, se disefian las interfases internas. externas y del usuario. Los conceptos de disefio han evolucionado en la primera mitad del siglo de trabajo de la ingenieria 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 metodos de diseno que se apliquen. a los lenguajes de programaci6n que utilicen. El modelo de disefio abarca cuatro elementos diferentes. En la medida en que se desarrolla cada uno de estos elementos evoluciona una visi6n mas completa del disefio. El elemento arquitect6nico utiliza informaci6n derivada del dominic de aplicaci6n. el modelo de analisis y catalagos disponibles para patrones y estilos que deriven una representaci6n estructural completa del software, sus sistemas y com-

272

PARTE DOS

PRAcncA DE LA INGINIIlIlA OIl. SOfTWARE

ponentes, Los elementos de diseno de interfaz modelan interfaces intemas y e~ nas y la interfaz del usuario. Los elementos al nivel de componentes definen cad. uno de los m6dulos (componentes) que pueblan la arquitectura. Por ultimo, los eItmentos de diseno al nivel de despliegue asignan la arquitectura, sus componentes las interfases a la configurad6n fisica que albergara el software. El diseno basado en patrones es una tecnica que reutiliza elementos de dist:i' que han probado ser exitosos en el pasado. cada patr6n arquitect6nico, patron diseno 0 idioma se cataJoga, se documenta par completo y se considera cuidada5amente cuando se evalua para incluirlo en una apJicad6n espedfica. Los marcos trabajo, una extensi6n de los patrones, ofrecen un esqueleto arquitect6nico paR diseno de subsistemas completos dentro de un dominio de aplicaci6n especifica.

[AMBOI] Ambler,S., The Obj! Pnrner, cambridge Univ. Press, 2a. ed., 200 I. IAPP98] Appleton, B., ~Pattems and SOnware: Essential Concepts and Terminology", obtenerse en http://wwwenteract.com/-bradapp/docs/pattems-intro.html. [ARL021 Aflow, J. e I. Neusdadt, UML and the Urufied Process, Addison-Wesley, 2002. [BELaI] Belady, L, pr610g0 de ~ Design: Mdhods and Techniques (L J. Peters, autorJ. don Press, 1981. [FOWOO] Fowler, M. et 01., Rejactoring Improving /he Design of Existing Code, Addison-W
2000.

[GAM951 Gamma, E. et ai, Design Patterns, Addison-Wesley, 1995. [GAR951 Garlan, O. y M. Shaw, ~An tntroduction to SOfiware Architecture~, en Advana5" software EnglntrrJng and Knowledge En8m~, vol. I {Y. Ambliola y G. Tortora, eds,} SCientific Publishing COmpany, 1995. [GRA871 Grady, R. B. Y D. L casswell, software Metrics: Establishing a Company-Wide ~ Prentice-Hall, 1987. UAC751 Jackson, M. A., Prinaples of Program Design, Academic Press, 1975. [UE031 Ueberherr, K., ~Demeter Aspect-Oriented Programming~, mayo de 2003, disponLbk http://www.ccs.neu.edu/homellieberlLaD.hlm!. [MAIOll Maioriello, J., "What Are DesIgn Patterns and Do I Need Them?", developer.com, disponible en httpJlwww.developer.cOmldesign/article.php/1474561. [MCG911 McGlaughlin, R., NSOme Notes on Program DeSign-, en SOftware Engineering NOlJ!:S , 16, mim. 4, octubre de 1991, pp 53-54. [MYE781 Myers, G" composJle5ttuctured Design, Van Nostrand, 1978. [OMG01 J Object Management Group, OMG Unifkd Modeling Language Specification, versi6n sepliembre de 2001. [PAR721 Pamas, D. L, NOn Criteria to be used in Decomposing Systems into Modules~, CAL. vol. 14, mim. I, abril de 1972, pp. 221-227. [ROS7Sl Ross, D, J Goodenough y C Irvine, ~SOnware Engineering: Process, Principles Goals~, en IEEE Computer, vol. 8, num. 5, mayo de 1975 [SCH021 SChmuller.L Teach YourseIjUML. SAMS Publishing, 2002. [SHA961 Shaw, M. y D. Garlan. Software Architecture, Prentice-Hall, 1996. [STA02J ~Metaphor'" en The Slanford HO LL!ammg Space, 2002, http://hcLstanford.edulb::.i... concepts/melaphor.hlml. rSTE74l Stevens, W" G. Myersy L Constantine, ~Structu red Design", en IBM ~lemsJOUma.13. num. 2, 1974, pp. 115-139 [WIR711 Wirth, N., "Program Development by stepwise Refinemenl en O\CM, vol. 14, num 1971, pp. 221-227
H ,

cAPiTuLo 9

1NGNIR1A D1 0ISEN0

273

9. 1. ,Se disei'ia un software cuando se "escribe w un programa? no de software sea diferente a la generacl6n de c6cligo?

~Que

es 10 que hace que el dise-

9.1 . Si un disei'lo de software no es un programa (de hecho no 10 es), ,entonces. qut es?

9.3. ,C6mo se evalua la calidad de un disei'lo de software? 9 .4. Examinar el conjunto de tareas presentadas para un diseno. dentro del conjunto de tareas? ,C6mo se lagra esto?
~Cuando

se evalua la caUdad

9.5. Dar ejemplos de tres abstracciones de datos y abstracciones procedimentales que puedan utilizarse para manipularlas 9.6 . Describir con argumentos propios Ja arquitectura de software. 9 .7. Sugenr un patr6n de diset'\o relacionado con una calegoria de cosas colidianas (por ejempia, productos electronicos, autom6viles, aparatos). Documentar el patr6n con ayuda de )a plantilla que se presenta en la secci6n 9.5. 9 .S. ,Ex!ste alg(m caso en el que los problemas compleJos requieran de menos esfuerzo para resolverse? ,C6mo afectaria ese caso el argumento para la modularidad'

9 .9. se debe implementar un diseno modular como software monolltico? ,C6mo se puede lograr esto' ,E1 desempei'lo es la unica justificad6n para la implementaci6n del software monoIItico? 9 . 10. Explicar la relaci6n entre el concepto de QCultaci6n de informaci6n como un atributo de modularidad efectiva y el concepto de independenda del m6dulo. 9 . 11 . ,Como se relacionan los conceptos de acoplamiento y portabilidad del software' Dar
ejemplos que apoyen la explicaci6n

9 . 12. Aplicar un -enfoque de refinamiento paso a paso para desarrollar tres grados diferemes
de abstracd6n procedlmental para uno 0 mas de los siguientes programas a) Desarrollar una maquina que expida cheques que, al dar una cantidad numerica en d6Jares, imprima la canti dad en paJabras que por 10 general se requiere en un cheque; b) resolver de manera iterativa la ralz de una ecuaci6n trascendental; c) desarrollar una tarea simple que planee algoritmos para un sistema operativo

9 . 13 . Realizar una pequef'la investigaci6n sabre programaci6n extrema y escribir un texlO breve acerca de la refabricad6n para un proceso de desarrollo de software agiL 9. 14 . Visitar un dep6sito de patrones de disef'lo (en Ja web) y navegue por unos minutos a Iravts de los patrones Elegir uno y presentarlo ame los compaf'leros de clase

Donald Norman ha escrito dos libros (The Design of EVeryday Things, Doubleday, 1990, y The Psychology oJ E'veJytf<ry Things. HarperCollins, 1938) que se han convertido en clasicos en la blbliograna sabre disei'lo y -debe- leerlos cualquiera que disef'le cualquier cosa que usen los humanos. Adams (COncqJlual BIockbUSlmg, Ja cd , Addison-Wesley, 1986) ha escrito un libro que es una lectura esencial para los disenadores que qUleran ampliar su manera de pensar. Por ultimo, un texto clasico de Polya (How 10 SOlve II, Pnnceton university Press, 2a. ed., 1988) proporciona un proceso de resoluci6n de problemas genbico que puede ayudar a los disenadores de software al enfrentarse con problemas compkJos Dentro de la misma tradici6n, Winograd et aJ I&m8m8 Design to SOftware, Addison-wesley, 1996) analiza los disenos de software que funcionan . los que no funcionan y por qut. Un libro fascinante editado por Wixon y Ramsey (Fidd Methods Casebook for SOfhvare Design, Wiley,

.,4
1996) sugiere metodos de investigaci6n de campo (muy pareddos a los que utilizan los aJ'lO'no p610g0s) para entender c6mo los usuatios finales hacen el trabajo que hacen, y despues ot'na. una gula para di.senar eJ software que satisfaga sus necesidades. Beyer y Holtzblatt (Con/e:xa. Design: A ~-Cen~ Approach to ~ DesIgns, Academic Press, 1997) ofrecen <*a vislbn del disei'lo de software que integra aI diente-usuario en cada aspecto del proce50 disel\o de software McConnell (COde Compk:fe, Microsoft Press, 1993) presenta una excelente exposici6n de aspectos practicos de disei\ar software para computadora de alta ca!idad. Robertson (SmpIrProgram Design, 33. ed., Kboyd Y Fraser PUblishing. 1999) ofrece una uti! explicaci6n introda. toria del disei\o de software para quienes comienzan $U estudio ace rca del tema. Fowler y . . colegas (Refactoring: Improving the Design Of Existing Code, Addison-Wesley, 1999) exponen tee n[cas para el mejoramiento incremental de los diseftos de software. En 1a decada pasada se han escrito muchos libros sobre disei\05 basados en patrones ~ ingenieros de software. Gamma y sus coIegas 1G.AM95) han escrito ellibro fundamental satr el tema Otros libros de Douglass (Rml-Tfme Design Alllt!tnS, Addison-Wesley, 2002), M eua. (DesIgn Pttttt!tnS AppOed, Wtox Pr5s, 2002), Marinescu y Roman WB Design A:Jrtems, WIro 2001) siluan patrones de disei\o en ambientes de aplicad6n y lenguajes especificos. A~ los Jibros clasicos del arquitecto Christopher Alexander (Noles on the .synthesis o{Form , Harva university Press, 1964. y A Pattern Language: R7Wns, Buildings, Conslruction, OXford Universl' Press, 1977) debe I~rlos el disel\ador de software que pretenda comprender a fondo los pm. nes de disefio. En Internet se dispone de una amplia variedad de fuer1tes de informacl6n sabre inge~ de disei\o, Una lista actualizada de referencias en Ia red mundial relevantes para el diseflo soft.ware y Ja ingenieria de: diseno puede encontrarse en eI siUo web de SEPA: http://www.mhhe.comlpressman.

,...' .
DISENO ARQUITECTONICO

10

..2.. 276

I diseno se ha descrito como un proceso de varios pasos en el cual las re~ presentaciones de la estructura de los datos y el programa, las caracter1s ticas de la informaci6n y el detalle procedimental se sintetizan a partir de los requisitos, Esta descripci6n la amplia Freeman IFRE80]

ID!iset\o es una lIctividad relacionada con la toma de decisiones, a menudo de naturaleza estnIctural Comparte con Ia programacl6n una preocupad6n relacionada con abstraer la reprcsenladon de la informa,;6n y las secutncias del procesamienlo, perc el grado de deta1!es es muy diferente en los extremos, E! disefio construye representaciones cohetentes y bien planeadas de los programas, que se concenlran en las ;nterrelaciones entre las partes al n\veJ m6s elevado y las operaciones 16glcas en los
niveles inferiores

Como se Indic6 en el capitulo 9, el diseno esta orientado a la infonnaci6n. Los metodos de dise"o del software se derivan de Is considerad6n de cada uno de los tres dominios del ami.lisis del modelo_ Los dominiOS de la informaci6n, la fun~ ci6n y el comportamiento sirven como suia para el disei\o del software

En este capitulo se presentaran los metodos requeridos para crear "represen~

. 211 ..296

y bien planeadas" de las capas de los datos y la arquitectura del modelo de diseno. EI objetivo es proporcionar un enfoque sistematico del
taciones coherentes diseno arquitect6nico: los pianos prelimlnares que se utilizan .

294

1m demoodos durante Ia ingenieria

.,. caW ..

eI an6I $tl de 10, requlSilo$ del soFtware.

del sistema y

bnpartante? Nadie tratorio de consln.llr una CO$O lin un plano, averdod~ Tom poco !pUOrio a IrOZQr pIonos bosquejondo 10 diaIribuci6n de Ia Fonlaneria. NecesilQrio un po' narama generoilio propio 00$(1) antes de preo'

"l:::~PO<~:'~cI.toIIes. Eso es 10 que hClC8 el di"

_",!]CI

IN,...-t El disei\o arqoitect6ni01 do..... de los daroo y luogo de una 0 mas representa "' arquiIect6nico del siseemIos 0 patronM arquitec
d.riwrr fa:etirucfut"o que se requ.5it04 del dian,.. En
275

00 prcpomono uno vista gef1e que .. obtengo 10 que se deseo.

.,6

PARTE DOS PRAcncA DE LA INGENlD4A. DEl. SCl'TWAJIE

._10 . .

En su notable libra sabre el tema, Shaw y Garlan [SHA961 analizan la arquit

del software de la siguiente manera:

Desde la primera vez que un programa se dIVidi6 en mOdulos, los sistemas de sonw~

han tenido arqUltecturas, y los programadores han sido responsables de las interacciones entre los mOduIos y las propiedades globales del ensamblaje. Hisl6ricamente, las arquttecturas han estado impllcitas (como accklentes de implementad6n 0 sistemas heredados
del pasado). Los buenos desarrolladores de software han adoptado con frecuencia unoo

varios patrones arquitect6nicos como estrategia para Ia organiz.ad6n del sistema, pero loa
emplean de manera infonnal y no tienen medias para hacerlos expUcitos en el sIstema resultante.

Hoy, la arquitectura del software efectiva y su representaci6n y diseno expllcitos

han welto temas dominantes en la ingenieria del software.

, .. _

"tI., 7 ........1.

en."ZflmBIS\IImarco~~ .. lItsde w_y ...... t-al"

10. 1.1

,Que as la arquitectma?

--

Cuando se analiza la arquitectura de un edifido vienen a la mente muchos am diferentes. En el aspecto mas simple se considera la forma general de la estru fisica . Pero, en reaUdad, la arquitectura es mucho mas, es la manera en que los versos componentes de un edificio se integra n para formar un todo cohesionade. la manera en que el edificio se amolda a su ambiente y se combina con otros cios vecinos. Es el grade en el cual el edifioo cumple con el propOsito establedd. en que satisface las necesidades de su propie tarlo. Es la percepci6n estetica de la tructura -el impacto visual del edificio- y la manera en que las texturas, los res y los materiales se combinan para crear la fachada exte ma y el Mentomo vi te del Interior. Son pequefi os detalles: el diseno de la i1uminaci6n, el tipe de piso colocaci6n de las casas que cuelgan de las paredes, la Usta es casi interminable nalmente, se trata de un a rte.
H

cAPiTuLo 10

cesEiIo~

Tn

iPero que pasa con la arquitI!CturQ dd software? Bass, Clement y Kazman IBAS03) definen este termino elusivo de la siguiente manera:
La arquitectura del software de un programa 0 sistema de c6mpulo es la estructura 0 las estructuras del sIstema, que inc1uyen los componentes de! software, las propiedades viSibles externamente de esos componentes y las relaciones entre ellos,

ta arquitectura no es el software operative. En cambia, es una representaci6n que permite que un ingenlero del software: I) analice la efectividad del diseno para cumplir con los requlsitos establecidos, 2) considere opciones arquitect6nicas en una etapa en que aun resuita reiativamente facB haeer cambios al diseno, y 3) reduzca los riesgos asoclados con la construcci6n del software.

.....,Esta definici6n destaca el papel de los

~componentes

del software" en cuaJquier

representaci6n arquitect6nica. En el contexto del diseno arquitect6nico. un componente de software es algo tan simple como un m6dulo del programa 0 una clase orientada a objetos, pero lambien se extiende para incluir bases de datos y middfewaIl! que pennita configurar una red de clientes y servidores. En este libro, el diseno de la arquitectura del software considera dos niveles de la piramide del diseno (figura 9.1): el diseiio de datos y el diseiio arquitect6nico. En el contexto del analisis anterior, eJ diseiio de los datos pennite representar eJ componente de datos de Ja arquitectura en sistemas convencionaJes y definiciones de clase (atributos y operaciones de encapsulamiento) de los sistemas orientados a obje-

tos. El disef'io arquitect6nico se concentra en la representaci6n de la eslructura de

los componentes del software, sus propiedades e interacciones.

10.1.2 I,Por que es tmportcmte 1a arqultectwa?

En un libro dedicado a la arquitectura del software, Bass y sus colegas [BASOJ] identitican tres razones clave por las cuales la arquitectura del software es importante:

~VE

Las representaciones de la arquitectura del softwa re permiten la comunlcaci6n entre todas las partes (participantes) interesadas en el desarrollo de un sistema de c6mputo.
La arquitectura destaca las decisiones iniciales re\acionadas con el diseiio que

tendran un impaclo profundo en lode el trabajo de \a ingenierla del software que Ie sigue y, 10 que tambien resulta importante, en el exilo tinal del sistema como entidad operacional.
La arquitectura "constituye un modelo relativamente pequeno e intelectual-

mente comprensible de c6mo esta estructurado el sistema y c6mo trabajan juntos sus co mpon ente s~ [BASOl]

270

EI modele de disefio arquitect6nico y los patrones arqultect6nicos que contie~ transferibles. Es dedr. 105 estilos y patrones arquitect6nicos (secci6n 10.3.1) se apliar al diseno de otros sistemas y representan un conjunto de abstracdones que pe
a los ingenieros de soltware describir la arquitectura de maneras predecihles.

La acd6n de dtsefio de datos traduce los objetos de datos definidos como

parte

modele de antllisis (capitulo 8) en estructuras globales al nivel de componentes software y, cuando es necesario, una arquitectura de base de datos al nivel de
caci6n. En algunas situaciones debe diseiiarse y construirse una base de datos

cificamente para un nuevo sistema. Sin embargo, en otras, se emplean una 0

bases de datos existentes.

10.2.1 otsefio de datos al nivel arquitect6n1co

HOy los negocios grandes y pequenos esttm inundados de datos. No resulta

poco

mun que incluso un negocio de tamaJio moderado tenga docenas de bases de

que sirven a muchas aplicaclones que abarcan cientos de gigabytes de datos. EJ to consiste en exlraer informaci6n util de este entomo de datos, sabre todo
cuag

la informaci6n deseada bene funcionalidad cruzada (por ejemplo, informaci6n s610 se obtiene si los datos especificos de mercadotecnia estan relaclonados ~ nera cruzada con los datos de ingenierla del producto) .

...... 1 '

Para resolver este desarto la comunidad de empresas de la tecnologfa de la inC! ci6n (TIl ha desarrollado la tecnica de minetia de datos, tambien denominada descu.. miento ck conodmientD en bases de datos ([)cBD), que recorre bases de datos existen.... con el fin de extraer informad6n aproplada en eJ ambito de los negocios. Sin em la existenda de multiples bases de datos, SUS diferentes estructuras. el grado de dea. lie que contienen y muchos otros fadores hacen que la minerla de datos resulte denlro de un entomo existente de base de datos. Una salud6n altema. denominada macen de datos agrega una capa adicional a la arquitectura de datos. Un almacen de datos es un entomo de datos independiente que no esta direal: mente integrado en las aplicadones cotidianas, pero que abarca todos los datos lizados en un negocio [MAT96J . En cierto senlido, un almacen de datos es una 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 mas dejar el analisis detallado del diseno de estructuras de datos, de datos y almacenes de datos a los libros dedicados a estos temas (por ejernpll

....

......

IDATOOOJ. (PRE98J . IKIM98J). El lector interesado debe leer la secci6n Otras/eel

y Juentes de infonnaci6n de este capitulo como referenda adicional

279

Minera y almacenam1ento de datos Objetivo: tas herramientas de lo minerio de oyvdan en la identi~cod6n de relaciones entre

inlegroci6n, la consulto, el informe, el anlisis y ..1 onIisi, de datos-.

::~~~do~~~';::boo~ dolos. un objeto datos espedfic:o o un las de herramientas pera el

de 0011 ayudon en el diseo de modelos un almacn de dotos.
herramientas tienen diver:lOs mec:niccs. paol, las herromientos de minerfo aceptan conjuntos dotos como entroda y permiten que el usuario CZIfI5I.IIIe pcl'Cl Irotor de comprender mejor las
E$k;1$

SPSS, desarrollado por SPSS, lne. (w-.~.com), propotciona uno amplia variedod de funciones esIodrslicas que pennilen el onli$is de conjunlo$ grondes

do

doto..

Almacenamiento d. dare,.:

lndusIry Won!house Studio, desarrolloda por Sybase

(_.sybase.com), proporciono uno in~ de alrnoc:M de datos empaquetodo que M$irve como trampoIn paro inkior el di5eo de un oImoc::n de datos.
M

,.;,.." do

;
:.

~~~:tre elementos de datos. en Lasel di~ de diversos dmocenamienlo empleodas

v(rw;u!os con

la entidad u otras opciones de

~:::;:::: representativas 1
de dato.:

IFW Business Inlelligerw::e Svile, de$CIrrolloda por ModeIware (www.modeIworepl.com). es un conjunto de modelos, herramientas de soHwore y diseos de base de dotas qUfl Mproporcionan un camino rpido al almacn de dalas y al diseo y la implementoci6n de centras de acopia de datos M .
Uno lista extenso de herramientas y recUf"$OS de minera y almacenamiento de datas se encontrar en el Data Warehousing Information Center (www.dwinfocenter.orgl.

Ob",,. desalT'Olloda por Business Objed's, SA "-w.busineObjects.com), es un conjunto de lWromienlos de di$E!llo de dolos que apoya -lo

10.2.2 Diseo de datos al nivel de componentes

El diseno de datos al nivel de componentes se concentra en la representacin de estructuras de datos a las que se tiene acceso en fonna directa mediante uno o ms componentes de software. Wasserman fWASBO] 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 [WAS8011 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

,1

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 diseno del software.

2 . Deben identijiwrse todas las estructuras de dalosy las operaciones que se realizarn. El diseno 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. 5k) representan una muestra de esta categora En casi todos los caS05 los nombres son maKoilS ~ de sus respectivos desarrolladores.

280

PARTE DOS

PRCTtCA DE LA !NGENlDIiA tu 9OF'1'WARE

3 . Debe establecerse un mecanismo para la definicin del contenido de roda objeto de datos y usarlo paro definir los datos y las operaciones que se les aplican. Los
diagramas de clase (capitulo 8) definen los elementos de datos (atributos) contenidos dentro de una clase y el procesamiento (operaciones) que se apli-

ca a esos elementos de daloS.

4. Los decisiones del diseo aJ nivd de datos deben posponerse hasta una de las timas etapas del proceso de diseno. Un proceso de refinacin paso a paso es aplicable al diseo de datos. Es decir, la organizacin general de los datos

w..

puede definirse durante el anlisis de los requisitos. refinarse durante el trabajo de diseo de datos y especificarse de manera detallada durante el diseo al nivel de componentes.

5. La representacin de una estructuro de datos slo debe conocerse para los mM los que deben usor directamente los datos que contiene tal estructura. El concepto de ocultacin de la informacin y el concepto relacionado del acoplamiera.. (capitulo 9) proporcionan conocimientos importantes sobre la calidad de un diseo de software. 6 . Debe desaTTO/Ja~ una biblioteca de estructuras de datos tiles y tambin las operaciones que pueden aplicrseJes. Esto se logra con una biblioteca de clasa 7. Un diseo de software y un lenguaje de progromadn deben dar soporte a la esxx:[Jicadn y la realizacin de Jos tipos de datos abslmctos. La implementad6t de una sofisticada estructura de datos llega a volverse excesivamente dificil no existen medios para la especificacin directa de la estructura en el lenguaje de programacin elegido para la implementacin.
Estos principios fonnan una base para un enfoque de diseo de datos, al nivel componentes, que se integre a las actividades de anlisis y diseno.

Cuando un constructor estadounidense usa la frase ~colonal con una sala al cen (centre hall colonial) para describir una casa, la mayora de quienes estn famili;s 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 c mecanismo descriptivo para diferenciar la casa de otros estilos (por ejemplo, mam. en A, rancho elevado, cape COd). Pero algo ms importante es que el estilo arquittc tnico tambin es una plantilla para la construccin. Resulta necesario proporci~ mayores detalles de la casa. Se deben especificar sus dimensiones finales, agrep caractersticas personalizadas, detenninar los materiales de construccin, pero estilo ("colonial con sala al centro") es el que gula el trabajo del constructor.

.. ..ma hay l1li patrII D. , dt arqudIn.

cAP'n1LO 10 DISEO ~

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 conju nto 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 disenador, mediante el anlisis de las propiedades conocidas de las partes que lo integran (BAS03j, comprender las propiedades generales de un sistema. Un estilo arquitectnico es una transformacin impuesta al diseno 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 reingeni erla (captulo 31), la imposicin de un estilo arquitectnico desembocar en cambios funda mentales en la estructura del software, incluida una reasignacin de la funcionalidad de los componentes [805001. Un

parron 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 re gla sobre la arquitectura, pues describe la manera en que el sofiware manejar algn aspecto de su funci onalidad al nivel de la infraestructura (por ejemplo, concurrencia) [80500]; 3) los patrones arquitectnicos tienden a abarcar aspectos especificas 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 expondrn estilos y patrones arquitectnicos de uso comn en el software.

10.3.1 Una breve taxonoma de esWos arquitectnicos

Aunque se han creado millones de sistemas de cmputo en los ltimos 50 aos. la gran mayorla puede clasificarse (consltense [SHA961. [BUS96l. [BAS03J) 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 componen-

tes 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.1 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 i nde~ pendientemente de cualquier cambio hecho a los datos o a las acciones de otro software cliente. Una variacin de este enfoque transforma el depsito en un "pizarrn" que envia nolificaciones al software cliente cuando cambian los datos de inters para el cliente.

I
.vqultectwa centtadaen

SoIowo~

SoI!wao.
dienllt

_oo.

d_
~

SoI!wao. eli....

eli....

~\
/

-do...

1/ _.
.......
~

SoI!wao.

"""'"

I
~

\
~

el.,.

clie!1ie

d.....

Una arquitectura centrada en datos promueve la copaddad de integradn (BAS(.., Esto significa que es posible cambiar componentes existentes y agregar nuevos ponentes cliente a la arquitectura sin preocuparse por otros clientes (ya que los
ponentes diente operan en forma independiente) . Adems, es posible pasar datos
l re clientes empleando el mecanismo del pizarrn (es decir, el componente pizat"" sirve para coordinar la transferencia de infonnaci6n entre dientes). Los comp<:II'U

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 componertes para el clculo o la manipulacin. Una estructura de tuberas y filtros ([gura I tiene un conjunto de componentes, denominados filtros. conectados por luber1as transmiten datos de un componente al siguiente. cada filtro funciona sin tonw

Arquitectura de tluJo de datoo.

Filtro

filtro

filtro

c AP'roLO l a

DISEO ARQlJrTEC"fNl

283

cuenta si los componentes tienen Oujo 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.
ampliamente patrones y estilos de cao.'

-....

Si el flujo de datos degenera en una sola linea de transformaciones se denomina

procesamiento por lotes 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 retorno. Este estilo arquitectnico permite que un di-

seador de software (arquitecto del sistema) obtenga una estructura de programa que resulta relativamente fcil modificar y cambiar de tamao. En esta categoria hay dos subestilos IBAS03J:

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 /Jamada de procedimiento remoto. Los componentes de una arquitectura de programa principal/subprograma se distribuyen entre varias computadoras de una red.

s...bpfogroma de aphcocin

Subprograma de aplicacin

Suhpn>g~

do

op."."'"

Subprograma

o. aplicocifl

Arquitectura o rientada a objetos. Los componentes de un sistema encap5l.Wl' los datos y las operaciones que deben aplicarse para manipular los datos. La ceanicacin y coordinacin entre componentes se consigue mediante el paso de me~ Arquitectura estratificada. En la figura 10.4 se ilustra la estructura bsica de arquitectura estratificada. Hay varias capas definidas; cada una de ellas realiza raciones que se acercan progresivamente al conjunto de instrucciones de la m na. En la capa externa los componentes sirven a las operadones de interfaz de rio. En la capa interna los componentes sirven como inteaz con el sistema opCIP tivo. Las capas intennedias proporcionan servicios de utileria y de software de cadones. Estos estilos arquitectnicos slo son un pequeo subconjunto de los que ~ ne el diseador de software.} Una vez que la ingeniera de requisitos define las racteristicas y restricciones del sistema que habr de construirse, podrn elegtlY estilo arquitectnico o la combinacin de estilos que mejor combinen con las can.. teristicas y restricciones. En muchos casos ser apropiado ms de un estilo y podr disearse y evaluarse distintas opciones. Por ejemplo, en muchas aplicaciones base de datos se combina un estilo por capas (apropiado para casi todos los mas) con una arquitectura centrada en datos

10.3.2 Patrones arquitectnicos

Si el constructor decide construir una casa colonial con sala al centro slo aplicar un estilo arquitectnico. Los detalles del estilo (por ejemplo, numero de

2 COnsilltese [BOSOOI. (HOFOOI . IBAS031 . [SHA971. [BUS961 y (SHA96l para contar con un an tallado de los estIlos y patrones arquitectnicos

Elecdn de un estilo arqwtectnico

11 escenorio: C~1o de Jamie, el espacio
Jame.: Sueno, eso no es cierta. Hay jerorquku de dose ... pienso en lo j8forqufo logtegaciOOJ que hicimos poro el obela PIonoCaaa [figuro 9.3). Una orquiNclv ro orientoda a obletos es uoo combioocin de ftQ e$k1JdlJro y lo, interconexiones (yo sob.n. coIaboracio' f"Ie$) en,", 10$da_ lo lTIOSIroremo$ 01 describir por completo 105 atribulos y los operaciones. 105 mensolM que $e in!ercombion y lo estructuro de los da-.

:~':~ el modelado del disei'lo. Jomie y Ed, integrantes delllqUipo de

software HogorSegoro.

......~"""" ...... "oodoIoodo b

. )'O

sabes, do_o,elaciones y ese

Id: v'7f o dedicor uoo horo a

uno orqui.

'-'90 ~, paro viwoli.tOr lo ql.l8 es lo

orientoda o objetos. Conozco la orquit8du ~:~~Y:'l1Itomo, \100 tipo de ..-arquJa de proce' , pero orientada o ob/flb' . . no s, me

iectlJro

de IIomada y retomo, luego regr~ aqvl y pensar en la orquileduro orientada o objetos. Jomie: Doug no Iefldr problema Ctln es.Q. ~I dijo que
~

...._

""""'"......1' Amorlo, ,oh'

m,

tOfUideror arquitecturos ClernI:u Par cierto, no hoy ninguno rozn poro no combinor ombos orquitlKlu

lo ~ quiero decir es que no logro visualizar .......m '"", 0610 01 d _ do do-lIoIoodo ~

Id: Buena, en 8$0 estoy.

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:~ Por ejemplo, cada casa (y todo estilo arquitectnico para casas) emplea un patrn cocina, el cual define la necesidad de colocar las articulas bsicos de cocina, un fregadero, alacenas y, posiblemente.

3 Podra argumentarsc que la arq1.utectura de Hoga~uro debe considerarse en un nivel ms elevado que la arquitectura indicada. HogarSeguro tiene diversos subsistemas (funcionalidad de fllonitoreo de la casa, el sitio de monitoreo de la compaia y el subsistema que se ejecuta en la pe del propietario). Dentro de IQl!i subsistemas prevale<;en los procesos concurrentes (por ejemplo, el monitoreo de sensoreS) y el manejo de eventos_ A este nivel, algunas decisiones arquitectnicas se toman durante la ingeniena del sistema y el producto (capitulo 6), pero el diSeo arquite<;tnlco dentro de la ingeniena del software muy bien tendria que con5lderat estos aspectos 4 Esto indica que tendr un!! 53la central y un pasillo. que las habitaciones estarn colocadas a la izquierda y la derecha de la sala, que la casa tendr dos 10 mas) piSos. que los dormitOriOS estarn en la planta alta, etc Estas ~reglas~ se imponen una vez que se ha tomado la decisin de usar el estilo colonial con sala al centro 5 Es importante observar que no hay un acuerdo uruversaJ sobre la terminologa Algunas personas (por ejemplo, [BU5961l usan los trminos estilos y patronescomo Sinmmos, mientras que otros ha cen la sutil distincin sugerida en esta se<cin

PARTE DOS

PRCTIC.A DE LA ~ DEl.

SCFTWARE

reglas para ubicar cosas reladonadas con el nujo de trabajo en la habitacin. Adems, el patrn podrfa especificar la necesidad de cubiertas y acabados, iluminacirl

interruptores de pared o una isla central, pisos, etc. Obviamente, hay ms de un elseo de cocina, pero todo diseo se concebir dentro del contexto de la "solucin

que sugiere el patrn cocina.

Como ya se indic, los patrones arquitectnicos para el software definen un el'foque especifico para el manejo de alguna caracterfstica de comportamiento del 55 tema. Bosch IBOSOO] define varios patrones arquitectnicos. En los siguientes plD-

fos se presentan ejemplos representativos. COncurrend a. Muchas aplicaciones deben manejar varias tareas de manera tal

C&VE
11m_dO
sofrwme Iient
orqUllct6oicos ""

simulen paralelismo (es decir, esto ocurre cada vez que un solo procesador rnaJ"ICJ-varias tareas "paralelas" o componentes). Una aplicacin tiene varias maneras manejar la concurrencia, y cada una se presenta mediante un patrn arquitect6ruu diferente. Por ejemplo, un enfoque consiste en usar un patrn de manejo de pl"OCl sos del sistema operativo que ofrece caracteristicas integradas del sistema oper1L va 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 cona. rrencia. Otro mtodo seria definir un calendarizador de tareas al nivel de aplicadcr Un patrn calendarizador de tareas contiene un conjunto de objetos activos, y uno de ellos incluye una operacin tiC( ) [BOSOOJ. El calendarizador invoca per10cl 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 ~ cin tiC( ) para el siguiente objeto concurrente. Persistencia. Los datos persisten si sobreviven despus de la ejecucin del procr so que los cre. Los datos persistentes se almacenan en una base de datos o un chivo; en un momento posterior, otros procesos tienen la opcin de leerlos o rnod. ficarlos. En los entornos orientados a objetos la idea de un objeto persistente exta> 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 almac para su aplicacin y recuperacin posterior. En general, se emplean dos patrones .. quitectnicos para lograr la persistencia: 1) un patrn de sistema de adminisl1"l1Ca&. de base de dOlOS que aplica las capacidades de almacenamiento y recuperaci n de sistema de administracin de base de dalos a la arquitectura de la aplicacin . o un patrn de x:rsislenda al nivel de la aplicad6n que construye caracteristicas de pet sistencia en la arquitectura de sta (por ejemplo, el software de procesamiento palabras que maneja su propia estructura de documento).

clierden fImI!S (MIO kl CCOOIrtneil, m

_JO

Distribudn . El problema de la distribucin dirige la manera en que se comu entre si los sistemas, o los componentes de stos, en un entorno distribuido
problema incluye dos elementos: 1) la manera en que las entidades se conectan tre si, y 2) la naturaleza de la comunicacin. El patrn arquitectnico ms comn

c APTULO 1O ~ AlIQUITD::'t'OCO

287

tablecido para dirigir el problema de la distribucin es el de corredor. Un corredor ac ta como "intermediarioN entre el componente cliente y un componente servidor E.I cliente envla un mensaje al corredor (que contiene toda la informaci6n apropiada para que se realice la comunicacin), el cual completa la conexin. CORBA (capitulo JO) 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 Organ1zac16n 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 arquitect6nico. Las siguientes preguntas [BAS03] proporcionan una visin especifica del estilo arquitectnico que se ha derivado. COntrol. Cmo se maneja el control dentro de la arquitectura? Existe una jerarqula de control distintiva y, si es as!, cul es la funci6n de los componentes dentro de esta jerarqula de control? C6mo transfieren los campos el control dentro del sistema? C6mo se comparte el control entre los componentes? Cul es la topologla del control (es decir, cul es la forma geomtrica que asume el control)? Est sincronizado el controlo 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 pizarr6n o almacn) y. de ser as!, cul es su papel? C6mo interactan [os 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 e[ 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 soRware y tambin la naturaleza de la interaccin. Esta infonnad6n suele adquirirse del modelo de anlisis y toda la dems infonnacin reunida durante la ingenierla de requisitos. Una vez que se ha modelado el contexto y que se han descrito todas [as interfaces exter-

nas del software, el diseador espedfica la estructura del sistema al definir y re

los componentes del software que implementan la arquitectura. Este proceso p~ de manera iterativa hasta que se obtiene una estructura arquitectnica completa.
. . . . . ...",. 1m erom, ,*0 111

lu,.iledo sOlo poed. . . o su c'-" .. ,... . . .

-UopIWIIjt
10.4.1

Representacin del sistema en el contexto

C~VE

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 rep ~ lar el flujo de la nfoonacin dentro y fuera del sistema, la nfonnacin del U5Uanl.t el procesamiento relevante de soporte. Al nivel de dise"o arquitectnico, un arQIoo teclo del sofiware aplica un diseo de contexto arquitectnico (DCA) para modd.

~o

D"''''''

-~ en fJl8 el dtwme

"'$15' .... 05

W8Iocta too m enliOOdes elfemlls a

la manera en que el software Interactuar con las entidades ubicadas ms all de limites. La estructura genrica de los diagramas de contexto arquitectnico se tran en la figura 10.5. Si se toma como rererencia la figura, los sistemas que interactuan con el si.ste. de deslino (el sistema para el que se est desarrollando un diseo arquitectniCO! representan asl:
SIstemas superordinados: los que emplean el sistema de destino como parte

inef~.

algn esquema de procesamiento de nivel ms elevado.

SIstemas subordinados: los que utiliza el sistema de destino y que proporcio-

"fr. s?

nan Jos datos o el procesamiento necesarios para completar la runcionalidill del sistema de destino.

""""ama
contezln

de

"'qulloctnJoo
(adaptado de

(BOSOOD.

U~.

Pares

o.,-de.do

cAPTULO 10

ooEO ARQurm::r6m:::o

289

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

me-

diante una interfaz (los pequeos rectngulos sombreados). Para ilustrar la utilizacin del DCA considrese de nuevo la funcin de seguridad casera del producto HogarScguro. El controlador general y el sistema de Internet del prcxl.ucto HogarScguro 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 tendrian 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 importanUsima 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

HogO<Segu<o

Si5lema basado en lntemef

Uro

funcibn de vigiklncia

Propietario

Uro

PARTE DOS

PRCnCA DE LA JNGnm:IA DIl. SOFTWARE

arquetipos, que representan elementos estables de la arquitectura pero que puedl:r

dar paso a instancias de muchas maneras diferentes, con base en el comportamiel to del sistema. En muchos casos, los arquetipos se derivan al examinar las clases de anlisis eje. finidas como parte del modelo de anlisis. Si se contina el anlisis de la funcin seguridad casera de HogarSt!guro se definirlan los siguientes arquetipos: Nodo. Representa una coleccin cohesiva de elementos de entrada y salida en la fundn de seguridad casera. Por ejemplo, un nodo eslarfa integrado po-

1) varios sensores y 2) varios indkadores de alarma (salida).

Detector. Una abstraccin que abarca todo el equipo de sensores que alimenta informacin en el sistema de destino.

lndJcador. Una abstraccin que representa todos los mecanismos (por eJemplo, sirena de alarma, luces parpadeantes, timbre) para indicar que est ocu-rriendo una condicin de alarma. Controlador. Una abstraccin que describe el mecanismo que permite el. mado o desarmado de un nodo. Si los controladores residen en una red t la capacidad de comunicarse entre si. cada uno de estos arquetipos se describe con la notacin UML, como se muestra la figura 10.7. Recurdese que los arquetipos forman la base de la arquitectura pero son abstnr.. ciones que deben refinarse an ms a medida que avanza el diseo arquitect6nio; Por ejemplo, Detector podria 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 est del sistema empieza a emerger. Pero cmo se eli~n estos componentes? Para

re.

_de H_
[BOSOOD.

Relacloneo UML paro loo

arquetipos d e la funcin . .

(adaptado de

I
I
DI
I

t ..

c.ornunico con

c APTULO 10

DISE:O ~

291

ponder, el diseador de la arquitectura empieza con las clases descritas como parte del modelo de anlisis,' 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 aplicadn. 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.

1a15lnld\n de 111 mtwna de softwan propaniona la .aIovia l1li que lIIIet, fIIIIIiooI y muwe ti ~.Iht ...... MIl ..... ,... el lila l1li 11 muOn ele !ocios los mmponemes nemorios ele 111 si>fenIo de softwn.

1.-

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 comunicad6n externa: coordina la comunicacin de la funcin 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 sobre ellas. cada uno de estos componentes de nivel superior tendrla que elaborarse iterativamente y luego posicionarse dentro de la arquitectura general de HogarSeguro. Para cada uno se definirlan 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 especificarlan hasta la realizacin del diseo en el nivel de componentes (capitulo 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 ob;etosl. es posible derivar los componentes del modelo de nujo de datos. En la seccin 10.6 se anab:urt este enfoque

292

Eshuctuta general. de la arquitectura de HogarSeguto con componentes de nivel

Diredof

Hogo.Seguro

.. .. '. ...
'

..

adquiere las transacciones provenientes de los componentes que procesan la ~ grjiru de usuario de HogarSeguro y la interfaz de Inlernet. El componente director de garSeguro maneja esta informacin y selecciona la funcin de producto apropiada este caso, seguridad). El componente procesamiento de xme1 de control interacta el propietario para annar o desarmar la funcin de seguridad. El componente marJCII de detector agrupa los sensores para detectar una condicin de alanna, y el comp<XlCa
te procesamiento de alarma produce una salida cuando se detecta la alarma.

10.4.4 Descrtpc:1n de la creacin de instancias del sistema

El diseo arquitectnico que se ha modelado hasta este punto a todavla es de un

vel relalivamente alto. Se ha representado el contexto del Sistema; se han defi

los arquetipos que indican las abstracciones importantes dentro del dominio del
blema; es evidente la estructura general del sistema; y se han identificado los cipales componentes del software, Sin embargo, an se necesita mayor refinallllCl' to (recurdese que todo el diseo es iterativo). Esto se logra desarrollando una instanda de la arquitectura. Es decir, la arquilc:: tura se aplica a un problema espefico con el propsito de demostrar que la estna.. tura y los componentes son apropiados. En la figura 10.9 se ilustra una instancia de la arquitectura HogarSeguro para el tema de seguridad. Los componentes que muestra la figura 10.8 se refinan an para mostrar detalles adicionales. Por ejemplo, el componente manejo de detector i racta con el componente de infraestruchtra caJendarizador que implementa el agrup. miento ~concurrente" de cada objeto sensor del sistema de seguridad. Una elaboraot. similar se realiza para cada uno de los componentes representados en la figura 10.&

CAPTULO 10

l:lISEO ~

Instancia de 10 tund6n de seguridad can elc:Iborac1OO. de componentes.

Director HogarSeguro

,,
Monejode
comunicacIn

,, ,,

-,,

.-.o
,,
Interlaz de Internet

Procesamiento de alarma

Alarmo

Ob.tivo: 1.,0" henomienta, de diseo arquilecl6nko modelan lo e~/n.Icturo generol del

al reprlI$ef1k:1r nterf.:5e$, dependencia"
~

(www.synths.com}.es uno henornienlo especializodo paro el diseo '110 con$hvccin de arquileduro especificas ele componentes

W".

ObjectiF, desorrolloda por micraTOOL GmbH

{www.mir:rotool.com}, es una herromienta de di~ UMl que lIeYCI a arquiteclvra$ {por ejemplo, CoIdfusion, J2EE, Fusebox) sensibles a la ingeniera de saftware baKJda en componentes {coplvlo 30).

e inleroc;c;iones de los componentes.

Ro6onoI Role, d.nondlada por Rational

Iwwwrorionol.com), esuno herramienlo de diseo

basada .... lJML que soporta toc:b los aspectos del

diil!o arquiIed6nko

Las herramientas expuestas slo representan UI'III muestrA de esta categora En casi todos los ca50S los nombres son marcas registradas por sus rnpeclIVOI desarrolladores

En el mejor de los casos, el diseo produce varias opciones arquitectnicas que evalan para detenninar cul es la ms apropiada respecto al problema que haba. de resolverse. En las siguientes secciones se analizaran diseos arquitectnicos al ternos.

10.5.1 Un m todo de anlisis de compensacin para la arquitectwa

El Instituto de Ingenieria del SOltware (SEI, por sus siglas en ingls) ha desarrolladr;. un mtodo de anlisis de compensacin para la arquiteccura (MACA) [KAZ98] que define un proceso de evaluacin iterativo para las arquitecturas del software . Las 9guientes actividades de anlisis del diseo se realizan iterativamente:
1. Recopilar escenarios. Se desarrolla un conjunto de casos de uso (capitulos 7 y
8) para representar el sistema desde el punto de vista del usuario.

2 . lkdudr reqUIsitos. restricdones y descripdn de entornos. Esta informacin se

requiere como parte de la ingeniera de requisitos y se usa para asegurarse dt que se atiendan todas las preocupaciones de los participantes.
3. Describir Jos estilos/patrones arquitect6nicos que se han elegido para dirigir los escenarios y requisitos. 4. EValuar los alnbutos de calidad al considcar cada atributn de manero 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 reutilizadn e int~ perabilidad.
5. Identificar la sensibilidad de Jos atributos de calidad respecfO de varios atributos arquitect6nicos para un estilo arquitectnico especfico. Esto se logra haciendo

pequeos cambios en la arquitectura y detenninando la sensibilidad al cam ~ bio de un atributo 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 alternas (desarrolladas en el paso 3) emp/eondo el al'kl lisis de sensibilidad aplicado en el paso 5. El $EI describe este enfoque de la si

guiente manera IKAZ98] :

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 CISlO~
que son sensibles varios atributos. Por ejemplo, el desempeo de una arquitectura cliente-servidor ser1a muy sensible al numero de servidores (el desempeo aumentar, dentro de cierto ran8Q, al aumentar el numero de servidores) Por tanto, el nmero de seTVldores 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 deta!!e,

y luego

aplicar de nueva cuenta los pasos de MACAs

~~;;~tIe;."'~tII"fUI,ecru",
diMl'to

""
do!

mquiteduros Y

do<;',oImo ......... en el conIIIldo cW CICIIO ' " ....

de,o~ ..... Iuon.

"~=2::;=!
..... _"'- . . 1Ioo'_...... 4~
orquillldllico no _ dndo, _a.no, .... _~::::~

moo pora hcar el .......

y..., ..

...... No .. 1o _

'" . _.......,ooiIIII

00'"
. . . . Iamado y f1IIomo, Y

..........

_ N o, .. _ _ " ' . _.........,

....... , ... hdoIooodo do '" de cc.nbio, o no'

VJnod: S. Lo que porticipcrlllll y
Yo KJbes.

-....""

cosos. Construimos

TombNn d.toiloAomo. coIidod que

lo orquillld\.lro del soltwcn. Jamie: Y los ~ Q le. ". ...

_ '-'o.

usoylos~_elque ....... .....

8_. . _. . . ._.

El mtodo de anliSIs de la arquitectura del sojtIwrr MAA$) es una alternativa a MACA y vale la pena que los lectores interesados en el anlisis arqultect6rtico lo exammen Un articulo sobre MAAS se descarga de http://www.sei.cmu edu/publicationsl.1rttdeslsaam- metho--propert -sas htm

10.5.2 Complejidad arqultectnlca

Una tcnica til para evaluar la complejidad general de una arquitectura delennm. da consiste en considerar las dependencias entre componentes dentro de la 31'q101 lectura. Estas dependencias las orienta la inrormacin, el Hujo de control, o ambil:. dentro del sistema. Zhao rZHA98J sugiere tres

tipos de dependencias:

DeperldencIOS rompartJdas que representan reladones de dependencia entre consumidores que usan el mismo recurso o los productores que producen para los mIsmos consu
midores. Por ejemplo, supbnganse dos componentes u y v que se refieren a los mismos datos globales. Entonces existe una relacin de dependencia compartida entre u y v,

DqJendenoas de flujO que representan las relaciones de dependencia entre productores . consumidores de recursos. Por eJemplo, para dos componentes u y v, si u debe compiletarse antes de que el control pase a v (prerrequisltol o SI u se comunica con v medianacparmetros. entonces existe una relacin de dependencia de flujo entre u y v.
fkpendmcias restringidas que representan restricciones al flujo relativo de control entre' un conjunto de actividades Por ejemplo, si dos componentes u y v no pueden ejecutarx
al mismo tiempo (exclusin mutua), entonces existe una reladn de dependencia restrIn-

gida entre u y v.

Las dependencias compartidas y de flujo que seala Zhao son similares al concq"
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 arqultectnlca

El arquitecto de una casa tiene un conjunto de herramientas estandarizadas y de tacin que pennite representar el diseo de una manera poco ambigua y fci comprender. Aunque el arquitecto del software puede dibujar con notacin UML necesitan otras formas de diagramaci6n, y unas cuantas herramientas relacionada. para aplicar un enfoque ms formal a la especificacin de un diseo arquitect6ra. El lenguaje de descripcin arqwtectnica (IDA) proporciona una semntica y sintaxis para describir una arquitectura del software. Hofmann y sus colegas [HOR" sugieren que un IDA debe proporcionar al diseador la capacidad de separar ponentes arquitectnicos, de integrar componentes individuales en bloques tect6nicos mayores y de representar interfaces (mecanismos de conexin) componentes. Una vez que se hayan establecido las tcnicas descriptivas, ba en el lenguaje para diseo arquitectnico, es ms probable que se establezcan mtodos de evaluacin efectivos para la arquitectura a medida que el diseo ev ciona.

CAPiTuLo 10 DISENo ARQUITECTNICO

291

Lenguajes de descripcin arquitectnica

El siguiente resumen de yorios LOA imporlontes lo prepor Rickord lond [LAN02] y se : : : : : el permiso del outor. Debe observorse que cinco LOA se han de50rrollodo con fines de : .......oci<~ Y no son produdos comerciales. ....-::~ ;:::.:,::~~;~~[lUC95] construye a lo nocin de parcides orde!,adas. ...(.." 1__."u,~,. ,.kl_LI";C~1 [SHA96] define mquilec1\ras de software desde el punto de vista de alM-acciones tiles poro los diseodores . Wrighl[www.cs.anu.edu/-able/wright/I [All97[ formalizo los estilos arquitectnicos empleondo predicodos, lo que permite comprobar la esttico para determinar la consistencia y elgrodo en que se ha completado una arquitectvra . Acme [www.cs.cmu.edu/-acme/l[GAROO]esun LOA de segunda generacin .

UML [www.uml.org/) incluye muchos de los artefaclos necesarios poro descripciones arquitectnicos; no es ton completo como otros LOA.

..... t_. o.,m".KI,I~bl.I,.~pll [GAR9.4] atiende

.. pmbIema 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 prclica 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 //amaday 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 [MYE781 y Yourdon y Constantin [YQU79]. 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 fonna lgica para "la realidad

externa". Por ejemplo, los datos escritos en un teclado, [os 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

transforman los datos externos en una forma interna. Estas rutas se identiflcan a" mo flujo de entrada. En el ncleo del software ocurre una transicin. Los datos cr trantes se pasan por un centro de transfonnad6n y empiezan a moverse por rutas ahora los llevan "fuera" del software. Al desplazamiento de los datos por estas rum. se le denomina flujo de salida. El flujo general de datos ocurre de manera secue y sigue una o unas cuantas rutas "en lnea recta'" Cuando un segmento de un grama de flujo de datos muestra estas caracterfsticas est presente el flujo de lmIIf

formacin.

10.6.2

Flujo de trcmsacc1n

Al flujo de informacin suele caracterizarlo un solo elemento de datos, llamado l1tIt' sacdn, que dispara otro flujo de datos por una de muchas rutas. Cuando un d ma de flujo de datos (OFO) asume la forma mostrada en la figura 10.10 est pr el flujo de transaccin. Al flujo de transaccin Jo caracterizan los datos que se desplazan por un ca entrante que convierte la informacin proveniente del exterior en una transa t5ta se evala y, con base en su valor, se inicia el flujo por una de muchas ruta! acd6n. Al elemento que concentra y distribuye el flujo de informacin, del que nan muchas rutas de accin, se le denomina centro de uansacdn. Debe observarse que, dentro del DFO de un sistema grande, tienen que estar sentes los flujos de transformacin y transaccin. Por ejemplo, en una transaca. orientada a flujo, el flujo de informacin por un camino de accin puede tener racterfsticas del flujo de transformacin ..

"'-----TronlolXCi6n
transaccin

----9 Una correlacJ6n obvia para este upo de flUjO de infonnaci6n es la arqUItectura de flujo de datOl cnta en la seccin 103 I Sin embargo, hay muchos casos en que esta arquitectura tal vez no mejor elecCin para un sistema compleio Entre los ejemplos se incluyen sistemas que ex tarn cambIOS sustanciales con el tiempo o sistemas en Jos cuales el procesamiento asociado el flujo de datos no necesariamente resulta secuencial.

cAPiTuLo 10

r:tSDro ARQl/tTEC'tONx:

10.6.3 Correlaci6n de transformaciones

La correlacin de transformaciones es un conjunto de pasos de dise'o que permite

que un DFD con caracterlsticas de flujo de transformacin se correlacione con un estilo arquitectnico especifico. Ilustrar este enfoque requiere considerar de nuevo la funcin de seguridad HogarSeguro. IO 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 disef\o:

Paso l . 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 extemos de los datos que fluyen al interior y hacia fuera de la funcin. En la figura 10. 11 se describe un modelo de nivelO; en la 10. 12 se muestra un flujo de datos refinado para la funcin de seguridad.

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 DFO de nivel 2 para supervisar St!l1SOre5 (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 (capitulo 9) . Es decir, el proceso impllcito en una transformacin realiza una funcin nica y distintiva que puede implementarse como un componente del software HogarSeguro. Por tanto, el OFD de la figura 10.14 contiene suficiente detalle para un "primer corte" en el diseo arquitectnico del subsistema supervisar sensores, y se sigue adelante sin mayor refinamiento.

COfTlc;mdos y datos de u~uorio

informaci6n de
despliegue Tipo de alormo

de panel de

"""' ","'",

Estotus de
sensores

Tonos de nmero

telefnico

10 Slo se considera una parte de la funcin de seguridad de HagaJSquro que usa el panel de conlrol. No se tendrn en cuenla otras caractenstlcas expu.est.aS al pnOpio de este libro y en esle capUulo.

300

...........

DFD de nivel 1 xua la fundn de

_.
/

/ y-~

_ _ , ......., ~ d ". conngl.lfoci6n

In

Dooo.

I I I
I

in

con i urocin

USUOfl O

\ \
\

Conlrastttio

Inicio detencin

",
'.... ...

onIrosei'iah Mo;;;'~ ;;;i .'ID).. ;;ao.f--~f,::r.:'\--' I? " """-m"~ ,;,, ,,,, -ll-'S
oo~~~in
/ dedespliegve

PrC)Ce5Or

I r----;;:)~~
Sensores

- ----------Estolus

Mon.loreor .,.-

de Mnsores

F= do_=!'O"'~==~"""'5 lelel::ca
Tipo de alarmo
TOOQl de

nb~~ --~

numero _mnieo

DFD t nivel 2
que refina la

transformac16n
mon/to>-"", sensores. Tipo

';;;;;===="'~"",b;a,ci6n
configuracin

In

mocin

de con' Ufocin ID, tipo,

de alormo
Dolos

E...ai..or
contn:I

de alarmo
Nmero

....._ " "relel6nico

lD, tipo

de $81lsores

Eslolus

de senwres

Tono5 de numero
lelelnico

Paso 3 . Detennnar si el OFD tiene caracterisdcas de flujo de transr.

dn o de transacdn. En general, siempre es posible representar el flujo de . macin dentro de un sistema como una transformacin. Sin embargo, cuando st

cuentra una caracterislica obvia de transaccin (figura 10. 101, se recomienda correlacin de diseo diferente. En este paso el diseador sele<:dona las ca

CAPTULo 10

DISEO AAQurro::i'NlCO

301

DFD de nivel 3 para monitOlear sensores con Imites de Dujo.

Informocin de configuracin l Dotos de configuracin

/1\

ID,tipo, "-<m ubicacin con formato de~iegue

Informacin de $en~res

ID, configuracin de $enseres

Tipo de alarmo

C6digo de listo de condicin de nmeros alormo, ID de $en~re$, informacin de calendario

Nmero telefnico Tono listo paro nmero telefnico Ge-n.eror I~s poro

Iooo
Tonos de nmero telefnico

ticas de flujo global (de todo el software) con base en la naturaleza prevaleciente del DFD. Adems, se aislan las regiones locales del flujo de transformacin o transaccin. Estos subJ1ujos se aprovechan para refinar la arquitectura del programa derivado de una caracterstica global descrita antes. Por ahora, la atencin se centrar slo en el fluj o de datos del subsistema monitorear sensores descrto 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 caracterlstica general de transformacin para el flujo de la informacin.

Paso 4, Aislar el centro de transfonnadn al espedficar 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 lo largo del camino de flujo generalmente tendr poco impacto en la estructura final del programa.

302

PARTE DOS

PRCTICA DE LA

JNGnmlA DIl.1Of'TWAIIE

Los limites de flujo en este ejemplo se ilustran como curvas sombreadas que rren verticalmente por el flujo de la figura 10.14. Las transformaciones (bu~ que constituyen el centro de transformacin caen dentro de los dos limites sombrCI:

dos que corren de aniba abajo en la figura. Podrla respaldarse el argumento de

es posible reajustar un limite (por ejemplo. podrla proponerse un Hmlle de fluJO

entrada que separe ker smson!S Yadquirir inJormad6n de respuesta). En este paso de sea debe: resaltarse la seleccin de limites razonables, no la larga iteracin sottt
posicin de los limites.

..........Nos.dD'"
IIItS1tl'fIIP1. Tti'N SflllneclSllillSlfiit.ce, dos om6s ctIfIIto-

Paso S. Realizar una "factorlzadn de primer niveln La arquitectura del grama que se ha derivado a partir de los resultados de la correladn lleva a una tribuci6n descendente del control. La foctorizodn genera una estructura de p
ma en que los componentes descendentes se encargan de la toma de decisionel los componentes de bajo nivel realizan ms trabajo de entrada. clculo y salida. componentes de nivel intennedio se encargan de parte del control y realizan dades moderadas de trabajo. Al encontrar el flujo de transformacin se correlaciona un DFD con una e:stnxJI.r ra especifica (una arquitectura de llamada y retomo) que proporciona control pan procesamiento de la informacin de entrada, de transformacin y de salida. En 11 gura 10.15 se muestra esta faclorizacin de primer nivel para el subsistema ~ 50r sensores. Un controlador principal (llamado supe1Vi5Or director de sensores)

..... ""
1nIrsI.

~too

,h/"Jo di ""'"', con bas"tJ kJ a:mI.;.i>d dO .....

~1mO.(0II!"

Si t SIJido
l5lt 1&

cmU! b

. , fMse!

CAPiTuLo 10

DISEO ARQtmECTN!CO

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 condidones de alarma, supelVisa 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 contro/adorde 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 Hmitarse al mnimo posible para realizar las funciones de control y aun mantener buenas caractersticas de independencia funcional. Paso 6 . Realice una "factorizadn de segundo nivel". La factorizacin de segundo nivel se logra al correlacionar las transformaciones individuales (burbujas) de una DFO 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 luego 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 OFO 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 disef'o 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 OFO se correlaciona con un mdulo que est subordinado al controlador de transformacin. En la figura 10.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, delx! escribirse una breve explica-

PARTE DOS

PRAcn:A DE LA tNGDmlIlA. DEl. SOFTWARE

""..
nivel para supeIVtsa1

FactoriJac16n

""""'.

fv\onitroreor
du".ctoJ

de

-~.

COO"

de entrodo de Ioen5OfEl$

cM condic'Of"!e$ de oJormo

Co"~1OOOf

C01lIr~

do """~

de IOlida

I~~~ do .10
1M<
~

_~ir.

Establee..

/"-.....

condiciooes

de olarmo

l~~
teWnico

-,~~

_______ 1
,,",-o,

seal de
o~~

~ red telefnico

c~~or
ueneror ""I~ poro r.neo

,,",-o, despliegue

CAProLo 10 DISEo ARQtrm:C!NlCO

30.

cin de su procesamiento (adaptado de la especificacin creada durante el modelado del anlisis).

Paso 7 _ Refinar la arquitectura de primera iteradn empleando disef\o heurstico 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 eva luar o refinar a voluntad. en un nivel global u holstico. En realidad, tendr dificultad para "ver el bosque entre los rboles".

Rejinomiento de una arquitectura de primera jteradn

, ...... con el

11 NOnario: Cubculo de .lamia, modelado del diseo.

Ed: Miro, aqu eoo lo orquileclvro qve he obtenido. (Ed muestro o Jomia lo ~9uro 10.17, que eUa estudia por

.::::;:::.: y :

Ed, infegfal1les del equipo de in........ """",s.gvro.

unos momentos.)
Jamie: E!J muy bien, pero creo qve pod~$ hocer aIguOO$ CO!oO$ poro ~mpliJicorkl Y maiororla. Ed: tCmo tulest Jamie: Bueno, por qu U$O$ el componente controlo-

~:::::.. ::",,:,.p.tu::,~,,"~~d~i_:~~de primero ilerod6n

~

. Se detiene poro pe-

or ele .-.In:dJ ele ~

NI ..... . - - un teNOr poro la corrwb:in. ...... En ~ no. El c:ontrolodor no hoc. 1'I'II.d!o,

..... eIitIffto5lfa1eja1!do un tolo comino de Rujo para ............... PocNmos eliminar el controIodor Jin
' I I . . a ...............

... Somptolia.an ......

Jamie: As .. Y l'I'Iier*ot hoc:.Ia ......... ... bo...wJ cJ. Nducir Iol CIII1Ipa . . . . . . . . . . . ' $ S... ,

de o:nro4 .. MmpIe. Pad.not .............. ......

Id (l.

_'*"'-S_ ............. ....

. . ,.,... wMr CDn ~, l1ar6 el cambio y, .

Iomodo,.... .........

. . . . Ull.CSb. 'a . ' " ' ' - condicicw_ de ob-mo y .. eel ... ...:..o~, En ...Iidod el COIrtrdodor

.lrr ' wwa:i6it . . . . . . . . no .. ~, ylape-

_ .................
e
Ioo"~

,,-", """"'" """""'" ,..~

. . .........t1 jD. . . . . . IIIID . . .

que CfW$ que pod.ta ' - '

(I.o\uesIra o..IarN.lo figura 10.18.'

.--

"-"ir. Es un inicio

de""..,...

Producir

10.6.4 Correlacin de transacciones

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 correspondientes racteristicas de flujo se analizaron en la seccin 10.6.2. En esta seccin se c rarn los pasos de diseno empleados para correlacionar el !lujo de transaccir una arquitectura de software. La correlacin de transacciones se ilustrar si se considera el subsistema leraccin 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 el 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 V .... . . un l1ujo de informacin adicional por una de tres rutas de accin. Un solo ele...' "

CAPTULo 10 DISEO ARQum::ctONtco

307

de datos, tipo de comando, hace que el flujo de datos se expanda hacia fuera del concentrador. Por tanto, la caracterstica general dell1ujo de datos est orientada a la transaccin. Debe obselVarse 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 estalUS. Los pasos del diseo 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 OFO con la estructura del software. Paso 1. Revisar el modelo fundamental del sistema. Paso 2. Revisar y refinar los diagramas de flujo de datos para el software. Paso 3. Determinar si el DFD tiene caracterlsticas de flujo de transformacin o de transaccin. Los pasos 1, 2 Y 3 son idnticos a los correspondientes en la correlacin de transformaciones. El OFO que se muestra en la figura 10.19 tiene una caracterstica de flujo de transformacin clsico. Sin embargo, el flujo por las rutas de accin que emanan de la burbuja invocar procesamiento de comandos parece contar con caractersticas de flujo de transformacin. Por tanto, deben determinarse limites de flujo para ambos tipos. Paso 4. Identificar el centro de transaccin y las caracteristicas de flujo en cada una de las rutas de accin. La ubicacin del centro de transaccin se desprende directamente del OFO. 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. 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 caracteristica 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 limites. Paso 5. Correlacionar el DFD con una estructura 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-

Dro de n1vel 2 para el subsistema de interac:d60 CXlIl el usuario.

0010$ de configuracin

"~Io

cin subordinados. cada camino de flujo de accin del OFD se correlaciona con estructura que corresponde a sus caractensticas de flujo especificas. Este ilustra esquemticamente en la figura 10.20. Si se toma en cuenta el flujo de datos del subsistema de interaccin con el rio, la factorizadn de primer nivel para el paso 5 se muestra en la figura 10.21 burbujas leer comandos dd usuario y activar/desactivar sistema se correlacionar rectamente con la arquitectura sin necesidad de mdulos de control inmediatc centro de transaccin , invocar comando de procesamienfO, se correlaciona di mente con el mdulo despachador del mismo nombre. Se crean controladores la configuracin del sistema y el procesamiento de la contrasea, como figura 10.21 .

procese.

se ilustra es

Paso 6 . Factorlzar y refinar la estructura de transacdn y la de cada no de acdn. cada camino de accin del OFD tiene sus propias caracterlslk.al flujo de informad6n. Ya se ha observado que es posible encontrar los flujos de trans.
macin nor. 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

o transaccin.

La "subestructura ~ relacionada con el camino de accilx'

desarrolla empleando los pasos de diseo analizados en esta seccin y en la

cAPTULO 10 rlSE."O ARQUTTEC1Or.oco

J09

Director de
~ '" II$\/Ori
interaccin

dooo<."""
tra caractersticas de transformacin clsicas. Se ingresa una contrasena (flujo en trante) y se transmite a un centro de transformacin donde se compara contra las contrasenas 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

Activar/

.......

Paso 7. Refinar la arquitectura de primera iteracin e mpleando diseo h eu ristico para mejorar la calidad del software. Este paso para la correlacin de transacciones es Idntico al de transformadones En ambos enfoques de diseno. cri-

310

PARTE DOS

PRAcncA DE LA!NGDmR!A DEL!a'rW....

Arquitectura de primera Iteract6n para

"'""'" do

con el UlUCIrio

-.-.

el subsistema
de lnteracd6n

con el usuario.

--'" d o_

...

"'P" ~ '''lID

0._.0'"
""'-1

d.I.......,

/ ... ------....

fto~

-c-..,
""'"'" do

.. -

-- ...
I

..

.~

la

...

~.

,-

~------dIoJOlida _"'0-'0 o. ""'"'" I ........

/

~o"'r_i\o

C_.....
confl'OMlioc

_ ... 0..no el..olicb

terios como independencia del mdulo, factibilidad (eficacia de la implementac::i(wl la prueba) y facilidad de mantenimiento deben ponderarse cuidadosamente e se propongan modificaciones estructurales.

10.6.5 Refinamiento del diseo arquitectnico

--

Cualquier anlisis del refinamiento del diseo debe prologarse con el siguiente mentaro: recuerde que un "'diseo ptimo" que no funciona tiene un mrito cu nable. El diseador de software debe preocuparse por desarrollar una represem. cin del software que cumpla con todos los requisitos funcionales y de desemptlli as como la aceptacin del mrito basado en las medidas y la heurlstica del disetr Debe 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 ver ros beneficios que se obtienen de desarrollar una representacin de la arquit del sonware.

Es importante indicar que a menudo la simplicidad estructural refleja eleganOi

eficiencia. El objetivo del refinamiento del diseo debe ser el uso del menor ntl

de componentes que permitan una integradn efectiva de los mdulos y de la

311

tructura de datos menos compleja que sirva adecuadamente para los requisitos de

informacin.

la arquitectura del software proporciona un concepto holistico del sistema que ha br de construirse. Describe [a estructura y la organizacin de los componentes del software, sus propiedades y la conexin entre ellos. Entre los componentes del ware se incluyen los mdulos del programa y las diversas representaciones de datos

son

que ste manipula. Por tanto, el diseno de datos es una parte integral de la derivacin de la arquitectura del software. La arquitectura destaca las decisiones iniciales del diseno y proporciona un mecanismo para considerar los beneficios de estructufas 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 categorfa 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 especificas de la arquitectura para ~probar- el diseo en un contexto real. Como un simple ejemplo de diseo arquitectnico, el mtodo de correlacin a ma pea 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

[AH083] Aho, A. V,

J HopCrOn y 1. Ullmann, DaID Structures and Algorilhms, Addjson-W~ 1983. (All.97] A1len R., ~A Formal Approach to SOftware Archttecture", tesis de doctorado, camegie McIIIt University, NUmerode reporte tcnico: CMU<S-97- 44, 1997 (BAROO Barroca, l.. y P Hall (eds.), Software .vchitecturt!." Advances and Applications, Spnrp verlag. 2000 [BASQJ] Bass, L , P Clements y R. Kazman, Software Archifecture in Praccice. 2a ed .. Add Wesley, 2003 [BOSOO] Bosch, J., Desi8n i Use of Software 'ChICtures, Addison-Wesley, 2000. [BUS96 Buschmann, F_. Pottml-Oriented Sojtwan: Ndutture. Wiley, 1996. [OA100] Date, e J, Anlntroduction lO Datllbase S)'Sfe'mS. 7a. ed., Addison-Wesley, 2000_ [OIKOO] Oikel. D.. D. Kane y J. Wlson, SOftwrJre Ardlltecrure: Organizational Pnnciples and lems, PrenliceHaIl, 2000. [FRESO] ~man. p. "The Conlext oC Design", en Software Design TI:!chniques, 3a ed. (P F Y A Wasserman, eds.), IEEE Compuler Society Press, 1980, pp 2-4. {GAR94 Garlan D., R. AJlen y J. Ockerbloom, "Exploitin8 Slyle in Architectural Design En ments", en Proceedings ofS/GSOFr '94 symposlum on /he Foundarions ofSojhYare ETpnng.I994 , GAROO] Garlan D., R. T. Monroe y 0_ Wile, ~Acme: Architectural Description ofCom~ sed Systems~, en Foundations ofComponent-8ased Systems, G. T. L.eavens y M SI (eds.), cambridge university Prcss, 2000 [HOFOO] Hofmeister, C. R. Nord y D. SOni, Applied SOftware Archileclure, Addison -wesley. [HOFOlj Hofmann: C. et al , ~Approaches lo SOftware ArchlltUre", se descarga de http
seer.nj.ntt..com/84015.htm1. [KAZ98 Kazman, R. el al., The Archiux:turalTtadeoff AnoJysis Mefhod, Sottware Engl lnstitute," CMU/SEl-98- TR-OOS, julio de 1998. [KIM98] Kimball, R., L Reeves, M. Ross y w. Thomthwaite, The Dara Warehouse Ufecyck Idl: Expert Melltodsfor DesignJll8, ~/opin8, and Deploying Data Warehouses, wiley. [LAN02] Land R, A BrtefSUrvey of SOftware Archltecture, repone tcnico, Departamento de nieria de Cmputo, Universidad MaJardalen, 5tJecia, febrero de 2002. (LUC95] Luckham D. C. et al. , -Specillcation and Analysis ofSystem Archi tecture Using bp en IEEE Ttansacdons on Software Engin:nng, ejemplar "Special Issue o n SOftware luce", 1995. {MAT96] Mauison, R, Dora warehousing: Slrategie:s. Thnologles. and Thchniques, McG,.... MYE78] Myers, G., Composlte Slructun'd DesIgn, Van Nostrand, 1978. [PRE98] Preiss, B. R, Da/a 5truc/ures and AJaonlltms l-Villt ObJe:t-Oriented [)(!Sign Po C_. wiley, 1998 [SHA96] Shaw, M. y D Garlan, ~R' lIIdlilecture, Prentice-Hall, 1996. [SHA97] Shaw, M. y P. Clemen ts, -A field Guide 10 Boxology: Preliminary Classificatlon chitectural Slyles for SOnware Systems-, en Proc. COMPSM:, Washington, OC, agosto de [WAS80J Wasserman, A , "Principies ofSystematic Data Design and lmplementation-, I'!II ware Design Techniques (P. fTeeman y A Wasserman, eds.l, la. ed.,IEEE Computer Press, 1980, pp. 287-293 [YOU19 Yourdon, E. y L Constantine, ~ Design, Prentice-Hall. 1979. IZHA98] Zhao,L "On Assessing!he ComplexityofSoftware Architectures~, en Proc. In/J An:hitture Htlrkshop, ACM, Orlando, FL. 1996, pp. 163-161.

,....

10 .1 . Em pleando la arquitectura de una casa o un edificio como metafora, realizar dones con la arquitectura del sofiware. En qu~ son similares las disciplinas de la arq dsica y la del software? En qu se di ferencian?

CAPTULO 10

DISEO ARQI.IITEC'l'Mco

313

10.2. Escribir un articulo 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 selecdonar. 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 secdn \0.3.\ son de naturaleza jerrquica, otros no. Elaborar una lista de cada tipo. Cmo se implementarlan los estilos arquitectnicos que no son jerrquicos? 10.6. Los trminos estilo arquitect6nico, patrn arquitect6nico 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.1. 10.9. Algunos diseadores sostienen que todos los nujos 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 nujo orientado a la transaccin se trata como transformacin. Utilizar un nujo de ejemplo para !lustrar puntos importantes. 10. 10. Si no se ha hecho, completar el problema 8.10. Emplear los mtodos de diseo descritos en este capitulo 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 nujo de transformacin. Definir los limites del nujo y correlacionar el diagrama de flujo de datos con la arquitectura del software empleando la tcnica descrita en la seccin 10.6.3. 10.12. Empleando un diagrama de flujo de datos y una descripcin del procesamiento, describir un sistema de cmputo que tenga distintas caractersticas de nujo de transaccin . Defina los limites 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 (PaUems ofEnlerprist! Application Archileclure, Addison-wesley, 2003). Clements y sus colegas (DocumenUg software Architecture: Vewand Beyond, Addison-wesley, 2002), Schmidt y sus colegas (Palfern-OrientlXl software Architectures, dos volmenes, Wiley, 2000), Bosch [BOSOO, Dikel y sus colegas [DIKOOI , Hofmeister y sus colegas [HOFOO] Bass, Clements y Kazman [BAS03]. Shaw y Garlan [SHA%] y Buschmann el al. [BUS%] proporcionan un anlisis a fondo del tema. Un trabajo previo de Garlan (An Inlroduction lo software Architeclure, SOftware Engineering lnstitute, CMU/SEI-94-TR-021.1994) Tiene una excelente introduccin. Clements y Northrop (Software Product Unes: Practices and Pattnns, Addison-wesley, 200 1) trata el diseo de arquitecturas que dan soporte a lineas de productos de sofware. Clements y sus colegas (EVa/uatin8 Software Architectures, Addison-wesley 2(02) considera los temas asociados con la evaluacin de alternativas de arquitectura y la seleccin de la mejor arquitectura para un problema de dominio dado.

31.

PARTE

DOS

PRCTICA DEUI. !NGEN1ERIAIELSOFTWARE

Libros especificas sobre implementadn de arquitectura tratan el diseo arquitectnico dcII tea de un ambiente de desarrollo o tecnologa especiales. walInau y sus colegas {Building ~ from Commerdal COmpollents, Addison-wesley. 2(01) presentan mtodos para construir artp lecturas basadas en componentes. Ptitchard (COM and CORBA 5idc-by-Side, Addison-W~
[999), Mowbray (CORBA Des/gll Prlttems, Wiley, 1997) y Mark. el al. (Objelel Managerl'X'l

Architecture Guide, Wi/ey. 1996) provee tineaminttos de diseo detallados para la estructura soporte CORBA, Shanley (Prolected Motie SoJhW1re Itn:hitecture, Addison-Wesley ! 9%) proporoa na asesorfa sobre diseo arquitectnico para cualquier sistema operativo basado en tiempo n2 para Pe, sistemas operativos multiproposito o drM!f'S. La investigacin actua l sobre arquitectura de software se documenta anualmente en Proceedings of the Intemational WoItshop en Software Arc:hilecture, patrocinados por la ACM otras organizaciones de computacin, y \os Proceedlngs of /he Jntemational ConJerence SOftware Engineering Barroca y Hall [BAROO presentan un tU estudio de investigacin reciedr: El modelado de datos es un requisito para un buen diseo en esta materia. Los libros Teory (Dalabase ModeJ.ing and DesJgn, Academic Press, 1998); Schmidt (Data Mode/ing InJormaaon ProJessiorwls, Prenlice-HaU, 1998); Bobak (Dala Modefing and Design Jor ~ Archita::tures, Arte<:h House, 1997); Silverstone, Graziano e Inmon (The Dala Mode/ R~ Book, Wiley, 1997); Date {DATOO], y Reingruber y Gregal)' (The Data Modding Handbook. A ~ Proctice Approach 10 Building Qua!Jty DaIO Modds, Wiley, 1994) contiene presentaciones deUII.. das sobre notacin de modelado de datos, heuristic y aspectos del diseo de bases de datos. diseo de almacenes de datos se ha vuelto ms importante en los ultimos aos. Los libros Humphreys, Hawk.ins y Dy (Data Warehousing; Architecture and ImplemenlGUon, Prentice1999); Kimball et al. [KIM98] e Inmon [INM95] 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 ingenieria de re. Tratamientos ms rigurosos del tema se hallan en Feijs V' FormaJization oJ Dcsign M PrenticeHall, 1993) Witl et al. (Software Architecture and Design Prindples, Thomson Publ 1994) Y Budgen (Software Design, Addisson-Wesley, 1994). Presentadones completas de diseo orientado al flujo de datos pueden encontrarse en (MYE78). Yourdon y COnstanline [YOU79J, y Page-Jones [17le PracticaJ Guide lo Slructured Design, 2a. ed. Prentice Hall, 1998). Estos libros estn dedicados slo al diseo se in extensos anlisis del flujo de datos. Una amplia variedad de fuentes de informacin sobre el diseo arquitectnico estn nibles en Internet. Una lista actualizada de referendas en la World Wlde Web que son re tes para el diseo arquitectnico puede encontrarse en e l sitio Web de SEPA, http: //www. mhhe.COmlpressman.

CAPiTULO

DISEO AL NIVEL DE COMPONENTES

11
com~

_ .... ".
....327

l diseo al nivel de componentes se presenta despus de que se ha

pletado la primera iteracin del diseo arquitectnico. En esta etapa ya se

han establecido los datos generales y la estructura del programa. El objeti

vo 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 pro grama 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

.:117
....321
..325

etapas posteriores del proceso de software En una famosa conferencia, Edsgar Dijkslra, una de las personas que ms ha contribuido a nuestra comprensln del diseo de software, afirm [0IJ721:
Al parecer, la diferenda entre el software y muchos otros productos es que en stos, como regla ge~raL mayor calidad representa precio ms elevado. Quienes desean software realmente confiable descubrirn que deben encontrar un medio para evitar la mayor parte de los errores desde el pnoclpio y, como resullado, el proceso de programacion se volver mucho ms e.::on6mico Jos buenos programadores. no deben desperdiciar <;u tiempo depurando; deben evitar los errores desde el principio

325
.....340

....3H
, .331

Aunque estas palabras fueron pronunciadas hace muchos aftas, an son vlidas. Cuando el modelo de diseo

.....lla

se traduce en cdigo (uente deben seguirse

....343

una serie de principios de diseno que no slo realicen la traduccin, sino que "eviten la introduccin de errores desde el principio~

.324

_ _ .Jn

Es posible representar el diseo al nivel de componentes empleando un lenguaje de programacin En esencia, el programa se crea con el modelo de diseo arquitectnico como guia. Un enfoque alterno consiste en representar el diseo al nivel de componentes empleando alguna representacin intermedia (por
ejemplo, grfica, tabular o basada en texto) que go fuente. Independientemente del mecanismo con que definidos deben adecuarse que ayuden

se traduzca fcilmente en cdise represente el diseo

definidas,

al nivel de componentes, las estructuras de datos, las interfaces y los algoritmos

a diversas [[neas generales de diseo bien

a evitar

errores a medida que evoluciona el diseo procedimentaL

En este capitulo se examinaran esas lineas generales y los mtodos disponibles para segulrlas.

Qu ? Un conjunto c~ de
componentes

ne durante el diMf\o orquilednico, pero las estr\lcturos de deJo

de software se defi

Inlemas y el procesamiento de detol1es de cada componente no se reprewltan en un grado de obsltactln par.cldo al cdigo. El di~o 01 nj.....1 de ~tes define las eslnJcturos de da
315

"6

PARTE DOS

PRCTICA. DE LA D.>ENlERlA Dfl. SOFTWARE

De manera general, un componente es un bloque de construccin modular para

sortware de cmputo. De manera ms formal, la especificacin unificada de lengm je de modelado de OMG (OMGO 1) define un componente como "una parte moo

desplegable y reemplazable de un sistema que encapsula implementacin y exporo

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 arquitedl. ra del software, deben comunicarse y colaborar con otros componentes y con dades (como otros sistemas, dispositivos, personas) que existen fuera de los li del software.

,._....""_.

""""" -..
~

El verdadero significado del trmino "componente" variar dependiendo del pwo lO de vista del ingeniero de software que 10 usa. En la siguiente seccin se revisar; 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 JIU. NIVEL DE c::caa>amms

317

11.1.1

Concepto orientado a objetos

En el contexto de la ingenierfa del software orientada a objetos, un componente contiene un conjunto de clases que colaboran entre sI. I 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 dIseno, tambIn deben definirse todas las Interfaces (mensajes) que penniten 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 ingenierla de los requisitos se deriva una clase de anlisis denominada Trabajo lmprenta. 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 TrabaJolmprenta como un componente de la arquitectura de software y se representa empleando la notacin abreviada de UMLque se muestra en la parte central derecha de la figura . Observe que Trabajolmprenta tiene dos interfaces, calcular7tabajo, que proporciona la capacidad de cotizar el trabajo, e iniciaI7tabajo, que pasa el trabajo a la planta de produccin. Estas 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 infonnacin 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 ciase como el componente Trabajolmprenta. Tomando como referencia la parte in ferior derecha de la figura 11.1, 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 cal culaI7tabajo e iniciaI7tabajo llevan impllcitas la comunicacin y colaboracin con otros componentes (que no se muestran aquiJ. Por ejemplo, la operacin calcularCosfoPagina( ) (parte de la interfaz ca/cular1tabajo) colaboraria con un componente TablaPredos que contiene la infonnacin de precios de los trabajos. La operacin verijicarPrioridad( ) (parte de la interfaz iniciar7tabajo) colaboraria con el componente ColaTrabaJo s 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 podria contener una sola clase

31.
operacin e interfaz. Deben especificarse las estructuras de datos apropiadas cada atributo. Adems, tambin se disefta el detalle algoritmico que se requiere

ra implementar la lgica de procesamiento asociada con cada operacin. Esta vidad de diseno procedimental se analizar ms adelante, en este mismo cap'
Por ltimo, se disean los mecanismos necesarios para implementar la interfaz. EII caso del software orientado a objetos, esto abarca la descripcin de todos los mens. jes que se requieren para realizar la comunkacin entre objetos dentro del sistema.

a.. _ _
Elabo<ad6n do un
T.* o o

j."

componenle de diseo.

==x:
?~
~

....... +",,.,

~T~,

-...-,._" I I1I

~~ -.......
.....Idqo

==
...,. . ,"""'*'
<C~~

"CI_..o

-,,-.

a... ................. ~
101 .. 1, ....

/'

~l"""loo>ID

,, ,

?<W~~
::;;:..J
1

-..0..0........ ,

_ .... """obIIl

_T~I

--

........ _ ..........,-,
,
--",
.w-"i<ItIdcIdIl

-S

=:r ........
" " M<ff=-

, """""'""" ,

~T"""baI(l
~lrabaol

------

..;

11 ,1.2 El concepto convencional

En el contexto de la ingenierfa del software convencional, un componente es un mento funcional de un programa que incorpora la lgica del procesamiento, las tructuras internas de los datos necesarios para implementar dicha lgica, y una terfaz que permita la invocacin del componente y el paso de los datos. Un e nente convencional, tambin denominado mdulo, reside dentro de la arquit

cAPTULO 11

CISINo AL NIVEl. DE ~

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 fun cin 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 transfonnacin (burbuja) representada en los niveles inferiores del diagrama de flujo de datos (capitulo 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 hacia la parte inferior de la jerarquia. Para lograr una modularidad efectiva, se aplican conceptos de diseo como la independencia funcional (capitulo 9) a medida que se elaboran los componentes .

....' ,'

$1.~"unVslemlmrnple.que""" ha .......... , . .........

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 derivarla durante el modelado del anlisis. Se supondr que stos se correlacionan (seccin 10.6) dentro de la arquitectura que se muestra en la figura 11.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 Trabajolmprenta 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 explicita. Es decir, se representa cada objeto de datos o de control que fluye por la interfaz. El algoritmo que pennite que el mdulo realice su funcin est diseado con el enfoque de refinamiento paso a paso analizado en el capitulo 9. El comportamiento del mdulo suele representarse con un diagrama de estado. Para ilustrar este proceso considrese el mdulo CoJcuJarCostoPagina. 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: nmef'o de p'Aioaa en el dooumento, nmero total de documentos que a8 ~. .. por una o ambas 08l11a, DOlor

""Mit.

320

PARTE DOS

PRJ.cncA DE LA ~ DEL 10FTWAIIE

o b6anoo \1

nearo \1 temao. Estos datos se pasan a ColculatCostoPagina mediante la

teaz del mdulo. ste usa los datos y determina un costo por pgina que se baso. en el tamao y la complejidad del traba}o (una funcin de todos los datos pasados mdulo con la interfaz) . El costo por pgina es inversamente proporcional al taDll o del trabajo y directamente proporcional a su complejidad .

G<6&ade _ _a
. . un ..... moCUlv.ncIonal.

Sistemo de
adminislracin de trabajo

,,

,,

o.

leer dato! d. "ahojo imptesi6n

Seleox_ Iofvnci6n d. molleja de Irobojo

Enviar Irabojo

o producd6n

En la figura 11 .3 se representa el diseo al nivel de componentes empleancknotacin UML modificada. El mdulo ColcularCoslOPagina tiene acceso a los invocar al mdulo OblenerDatosTrobojo, que permite el paso de todos los datos vantes al componente. y una interfaz de base de datos, accesarBDCoslos, 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 CalcularCoslOPagn. ra proporcionar el detalle del algoritmo y la interfase (figura 11.3) . El detalle goritmo se representa empleando el texto de seudocdigo que se muestra en 11 ra con un diagrama de actividad de UML Las interfaces se representan como leccin de objetos o elementos de dalos de entrada y salida. la elaboracin sea continua hasta que se proporcione detalle suficiente para guiar la constNr..... del componente

321

ColculorCodoPogino

CO$toPogino
enlro: nu.......oDocu_101. entro Iodc- 1, 2 entro color. 1,2, J, 4 enlro: IamooPogioo .. A, S,

_"1m

nu .......oPog;nos

MJI.: costo el. p6gina

entro toIItOi'toTrobojo

e, o
e, D
II;ImoQ de Iroboio (TTI ..
numerotaginas .. nYlTleroOoc;umenlos;

entro color.. 1, 2, J, 4
entro IamooPogina .. A. 8,

10": CBP

so": Sf

obtemwOotosTroboo (numeroPagioo$, nUfl'MlfoOocUlWrlkls, lodo color, IomooPogino, costoPogino) ~O'k(lomooTroboio. color, IamaoPogino, CSP, Sf) colculorCostoPogiflO( ) ____________ _

buKor oo,to base de pgino

ocxewrSOCO$k colorf; bU$Cor Ioctor de lamo\o 1FT) .> acce$OrBDC05kls (11. color, tamao) foclof ele eompleidod d. "abajo (FCT) .. 1 + UIodo,,1) * cooolodo + costoPag.no .. CSP fCT

err,

(cePl-"

fn

11.1.3 Un concepto relacionado con el proceso

En los conceptos orientado a objetos y convencional del diseo al nivel de compo-

nentes 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 ingenierla 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 ingenierla del software basada en componentes se analizar de manera muy detallada en el capItulo JO.

322

PARTE DOS

PRCTICA DE LA lNGENIEli!A DIl. SOFTWAIIE

Middleware e ingenlea de software basada en componentes

Q+.tG CORSA (http://www.corbo.org/l.

Uno de los elementos clave que IIe.oa al xito o el fT0c050 de lo ingeniera del software basado en c~1es es lo di'f'Ol'libilidod de middewore. w es una coleccin de componentes de iflfroeshvct\lro que permiten que los componentes del dominio del probIemo MI comuniquen con otros en uno red o 0en1Yo de un ~_ me complejo. Quienes ~ U$(II" ingenieria del ~ boKldo en COIIIPOIIetIies o med'1do que CM:JIUO el procmo de ~re cvenlon con tres Undores c.ornpetido.-m:

MkrmoIt CCM jhllp:!/_.m~. com/com/lech/complvl.a~l

Sun..bYo6eons {http://IO'''O.wn.com/producb/eJb/l. los onMriotes sitien wfl, po-esenkIn uno amplio voriedod
. .

de 1uIorioIes., ~, hermmienlos y I'8CUIW$ ~ sobr. estos importrJnte$ e$lndol"e$ de midcl\eo...oore, En,j capitulo 30 MI encontrar ln$ inkwmocin ocerca de la ingenierio del ~ basada en cornp:lI*'Ites.

Como ya se ha observado, el diseo al nivel de componentes se basa en I~:::::~

desarrollada como parte del modelo de anlisis (captulo 8) y representada parte del modelo arquitectnico (capitulo 10). CUando se elige un mtodo de nierfa de software basado en componentes, el diseo al nivel de stos se CCXJt:ZSl en la elaboracin de las clases de anlisis (clases especificas del dominio del ma), y la definicin y la afinacin de las clases de infraestructura . La descripdx' tallada de los atributos, las operaciones y las interfaces empleados por estas representa el detalle de diseo requerido como precursor de la actividad de truccin

11.2.1

Prindptos bsicos de diseo

Hay cuatro principios bsicos de diseo aplicables al diseo al nivel de com tes y se han adoptado ampliamente cuando se aplica ingenierla de software <lnl' 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 darlos cuando ocurren cambios. Estos principios pueden usarse para guiar al ador a medida que desarrolla un componente de software.

El prindpio abierto-cerrado (PAC). 1E/ componeme de] un mdulo abierto para extensin, pero cerrado para mocJificadn w (MAROO) . Esta

d~

contradiccin, pero representa una de las caractersticas ms importantes dl.. buen diseo al nivel de componentes. Para expresarlo de manera simple, el dist. dar debe especificar el componente de manera que permita extenderlo (dentrf' dominio funcional que atiende) sin necesidad de modificaciones internas al componente (al nivel de cdigo o lgica). Para ello, el diseador crea ah"fi.a:...'~ que sirven como memoria intermedia entre la funcionalidad que tal vez habr. tenderse y la propia clase de diseo.

323

inrrem:,p>
Soo~

inhobiUlor( 1

leer!) habilitor( )

.------~,-~-----,I
I I ,

probar( )

L;>.

, ,

~----_----r-----------r----------r----------' I , , ,

,-~_"""" __ "_ "" _ / .... I

_ Ventonas

Soo . .

H,~ 1~~~_,m,~m I Soo~~ 1 I Soo~02 1

Por ejemplo, suponga que la funcin de seguridad HogarSeguro usa la clase De-

tector 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-sLno (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-sLno 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

Vinod: Et. poro lo gente que dijo 5UI n...........

parlomenlo5

Ikrmo 01 telfono IuIor del dueo. Shokiro: No brom.s. Vinod: Et. en wlo. Ooug quiere saber cuOnIo f...,a nos Iomor 091 egarIo o lo funcin de seguridad Shokiro (pensando por un "..,... .): No""," cho miro (le '"'-"""'O a Vinod lo figuro 11 ....( lWmCII oidodo los dos. cM MfttOf'e5 reales Ira5Ia inWfaz .... 501". Siemp. Ycvonda '-"gamos especilkaoClII" . . sen5Ol" de perro6... 0W9 en un tris. 1.0 f'Iioo que .....

o condominios o <DIOS muy ~ S .... rro empiezo o ladrar. El YeCino se enoja y .. cpa. Con MM seosor, si el perro ladro dvronI. fn5 di "" miftuIIt. PIX decir oleo. el detono uno alanno...-;al.-

"$Of

32.

PARTE DOS

PRC"OCA DE LA

lt<GMDIiA DEl. XlI'TWAlIIE

!~~~~::~:: . .
_

do

no hoy II'IU-

ho.

~No~~~~~~: r o _ t i .. loqa DI

5tt ....

Prindpio de sustitud6n de Uskov (PSL). wvebe tenerse la opcin de sustic. subclases con sus clases principales. ~ [MAROOj Este principio del diseo. que ori
mente propuso Barbara Uslcov [US88l, sugiere que un componente que use una se principal debe seguir runcionando apropiadamente si, en cambio, se pasa al ponente una clase derivada. El PSL exige que cualquier clase derivada de una

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 cipa] y una condicin posterior que debe ser cierta despus de que el componente una clase principal. Cuando un diseador crea clases derlvadas, tambin deben tarse a las condiciones previas y posteriores.

Principio de inversi n de la dependencia (PI O) . "'I kpenda de las abstrae

no de las concreciones." (MAROOJ Como hemos visto en el anlisis del PACo las tracciones son el lugar donde un diseo se puede extender sin grandes complica... nes. CUanto ms dependa un componente de otros componentes concretos (en gar de abstractos, como la interfaz), ms dificil ser extenderlos.

"",-...

Si se xflriltJe dt ". sdio r SI fKJSD !he. b'II8tI/e rJ aIdpo,

isll es 1I"ame-

Principio de segregad n d e la inteaz (PSI). "'Es mejor tener muchas intetf.'J..

especficas del diente que una interfaz de propsito general. "' ,MAROO Hay muchos 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 e~ zada para servir a cada categoria importante del cliente. Slo las operaciones irJ1l. tantes para una categoria especial de clientes deben especificarse en la interfaz ra esos clientes. Si varios clientes necesitan las mismas operaciones, deben espa.. ficarse en cada una de las interfaces especializadas. Por ejemplo, piense en la clase PlanoCasa que se usa en sa slo se emplea durante las actividades de configuracin

()" 1m. kJ Que

_""'''"0.

se

HogarSeguro

para

ciones de seguridad y vigilancia. En el caso de las funciones de seguridad, P~

y utiliza

las opera

colocorOlspOSltivo( J, mostrorDispositNO( J, agruparDispositivo( ) y e/lminarDispasitIpara colocar, mostrar, agrupar y eliminar sensores del plano. La funcin de vigi de

HogarSeguro

usa las cuatro operaciones indicadas para seguridad, pero

5k)

quiere operaciones espaciales para manejar las cmaras: mostrorPV( ) y mostrarl

CAPTULo 11

DISEO AL NIVEL DE C'OMJ'CMNTt:S

325

positivo( J. Por tanto, el PSI sugiere que los comIx>nentes de cliente de las dos funciones de HogarSeguro tengan interfaces especializadas y definidas para ellas. La interfaz de seguridad slo abarcarla las operaciones colocarDisposWvo( J, mostrarDispositivo( J, agruparDispositivo( J y e]iminarDispositivo( J. La interfaz de vigilancia incorporarla las cuatro operaciones anteriores, adems de mostrarPV( ) y mostrarlDDisposirivo( ). Aunque los principios de diseo al nivel de componentes proporcionan una gula til, los propios componentes no existen en el vado. En muchos casos, los componentes o las clases individuales se organizan en subsistemas o paquetes. Es razona ble preguntar, cmo debe presentarse esta actividad de empaquetamiento? Exactamente, cmo deben organizarse los componentes a medida que avanza el diseo? Martin (MAROO 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. N[MAROO] Cuando las clases o componentes se disean para reutilizarlos, hay un contrato expHcito 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, 10 aconsejable seria agrupar las clases reutilizables en paquetes que pueden manejarse y controlarse a medida que evolucionan nuevas versiones.

Principio del cierre comn (PCC). NLas dases que cambian junlaS deben pennanecer juntas," [MAROO] Las clases deben empaquetarse de manera que sean un todo coherente. Es decir, cuando las clases se empaquetan como parte de un diseo, deben atender la misma rea de funciones o comportamientos. Cuando alguna caracteristica 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 dases que no se reutilizan juntas

no deben agruparse juntas. ~ 1MAROOj 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

vel de componentes. Estas lineas generales se aplican a componentes, sus intert. ces y las caractersticas de dependencia y herencias que impactan el diseo rest.CWst dtbt IOMIII' 111 cHIta cltOlMlo se ...... Ios co.poHItts?
tanteo Ambler IAMB02j sugiere las siguientes lineas generales:

Componentes. Deben definirse convenciones de asignacin de nombres

componentes especificados como parte del modelo arquitectnico, y luego refi

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 lo leen, sin importar sus

tecedentes tcnicos. Por otra parte. los componentes de infraestructura o las

elaboradas al nivel de componentes deben tener un nombre que refleje el sig do especfico de la implementacin. Si se habr de manejar una lista vincula~ mo parte de la implementacin de PlanoCasa, la operadn manejarUsta( )

res.

apropiada, aunque una persona sin conocimientos tcnicos podrla malinterpretJl' Tambin vale la pena usar estereotipos para ayudar a identificar la natura)ez:; los componentes al nivel de diseo detallado . Por ejemplo, infraetttructuN usarse para identirlcar un componente de infraestructura; bu Bdedaloo:> podrfa se para identificar una base de datos que sirve a una o ms clases del diseno

o.

do el sistema; t.bI se usarla para identificar una tabla dentro de una base de

tos.
Interfaces. Las inteaces proporcionan informacin importante acerca de .. municacin y la colaboracin (adems de ayudar a lograr el PAq. Sin embargo representacin libre de las i nterfaces tiende a complicar los diagramas del nente. Ambler IAMB021 recomienda que 1) cuando los diagramas se vuelvaJ'! complejos se use la representacin de linea y circulo para una inteaz, en lugar

Coha<I6nde

capa.

Panel de COfIwoI

Es Improbable que una persona de marcadotecnla o de la organizacin del cliente (un trpo

tecedentes ttcnicos) eltamine el detalle de la infonnacin de diseo

CAPTULo 11

DISENo AL NIVEL DE c:oMi'ClNlNmi

enfoque ms formal del recuadro UML y la flecha con lnea de guiones; 2) por razones 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 capitulo 9 se describi la cohesin como la "funcin nica" de un componente. En el contexto de! 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 si y con la clase del propio componente. Lethbridge y Laganire [LErO I1 definen varios tipos diferentes de cohesin (que aparecen en la lista ordenados segn su grado de cohesin):J 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 Bamada 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 comunicadn. 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, mas [cil ser implementar, probar y mante ner el componente.

32.

PARTE DOS

PRCTICA DE LA lNGEN!EIA. 00. SOFfWARE

Procedimental. Las componentes o las operaciones estn agrupados de mane

fa 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 estad.
especifico, como una operacin que se realiza al principio o todas las operaciCD15

realizadas cuando se detecta un error.

Utilitaria. se han agrupado componentes. clases u operaciones que existen de. tro de la misma categoria, pero que no tienen otra relacin. Por ejemplo, una llamada Estadistica muestra cohesin utilitaria si contiene todos los atributos y operaciones necesarios para calcular seis medidas estadsticas simples. Estos grados de cohesin son menos deseables y deben evitarse cuando exisl:cl otras opciones de diseo. Sin embargo, es importante tomar en cuenta que a veas. los temas pragmticos de diseo e implementacin obligan al diseador a optar por grados inferiores de cohesin,

Id,

,~:::::::,......._

delOJi',..,. de CInart:I rptdo nllfisin' reoIicIod quiWo tu opihobIondo J

pora c-

___.... _ --.J' No, ......""" ..

que $1 una

bueno deo.

Ed {frunciendo" c.Ao}: queas openxioI_ puec&.. o:MaI" . . . .0IIII-.

aPcr'" .,.......
.

Jarnir. El poblMoo de ~ ___ . .

~6n. Tu sab., !endria IKIO solo funcin.

Ieodr ms de cierllineos
;~

Ed

(un

poco :.:n~:.:'~n:.~.:~~;;:~~:::.;

..

Jomie: Y qu po5Orio si /IleIQ.dot.:liOio decide CICI'Ir biar la manefO en que ~ ti

campo'"

Ed: S;~ me meto ... ksOf*QciII . . . . . . . . maro( Jy oIoboro ~ m6duIo.

==::.~_~~om-

.knniIt: iY qu: peno con los el.dos

Ed: iA qu te~'

oaIaI._'

CAPiTULO 11

DISl:O AL

NIVEL DE COMPONENTES

329

EcI: t Oe modo que estl tn _"'Idl Jomie; T _ el di~w

grote de _ ...""'. "" _ _....

""""",do do"'_
ty,

'-'n.
EcI (,...._radal. ,... ""
lnO$

ir

11.2.4 Acoplamiento
En exposiciones precedentes de! 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 interdepen dientes, el acoplamiento aumenta. Un objetivo importante en el diseo al nivel de componentes consiste en mantener el acoplamiento lo ms bajo posible. El acoplamiento de clase se manifiesta de varias maneras. Lethbridge y Laganire [LETOl ] definen las siguientes categoras de acoplamiento:

Acoplamiento del contenido. Ocurre cuando un componente "modifica subrepticiamente datos internos de otro" [LETOl]. Esto viola la ocultacin de la informacin. que es un concepto bsico del diseo.

Acoplamiento comn. Ocurre cuando varios componentes usan una variable

gl obal. 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 opera-

cin

B( )

y pasa una marca de control a B. La marca de control "dirige" entonces el

fluj o 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 omite, se presentar un error.

Acoplamiento de estampa. Ocurre cuando CiaseS se declara como tipo para un argumento de una operacin de ClaseA. Debido a que CiaseS ahora es parte de la definicin de ClaseA. la modificacin del sistema se vuelve ms compleja.

3JO

Acoplamiento de datos. Ocurre cuando las operaciones pasan cadenas Iarp

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 m nimiento son ms dificiles.

Acopiamiento de llamada a rutina. Ocurre cuando una operacin invcxa

otra. Este grado de acoplamiento es comn y, a menudo, muy necesario. Sin ernI:IaF

go, aumenta la conectividad de un sistema

Acoplamiento de uso de tipo. Ocurre cuando el componente A usa un tipo datos definido en el componente B (por ejemplo. esto ocurre cada vez que "una
declara una variable de instancia o una local como si tuviera otra clase para su (LElO I ]). Si cambia la definicin del tipo, tambin deben cambiar todos los comnentes que usan la definicin.

Acoplamiento de inclusin o importadn. Ocurre cuando el componenlt' importa o incluye un paquete o el contenido del componente B .
Acoplamiento externo. Ocurre cuando un componente se comunica o col.iJltl. ra con componentes de infraestructura (como las funciones del sistema de opca cin, la capacidad de la base de datos, las funciones de comunicacin). Aunqut: tipo de acoplamiento es necesario, debe limitarse a un pequeo nmero de c nente o clases dentro de un sistema. El software debe comunicarse interna y externamente. Por tanto, el acoplamien fun damental. Sin embargo, el disei'iador debe trabajar para reducir el acoplal1UC'" cada vez que sea posible y comprender las ramificaciones de un acoplamiento vado cuando no pueda evitarse .

....._Ieo .., .,

en GCdn
dei equ;po
g ... . (~::~~t:::~::==~~ r_ .... ........

PTT _ _ ~o.Shokiro.
~qu. trabajon en

VInocI: tGu".. . . . . . 00.... Shakira: 8i.rl, de

no crear uno cpaaci6n M da~l ...
~.

cac:Ia

...."....,
paco 'IiIIfOI' 11'10 me poteci la NChoci, pero CfJ8 JeIia

'*""

Lluauo ..... lP.O. . . . . .

for.oI cOfUpOi . . . LluaII'I'.UI'T

Vinod (peIlllolh.): ten lugar

ContNI o teo a.Il

botocion 0C\IrT0 "-o de \,1ft

......... c:1o.o ... I0000

""'"

cAPnJLO

II

DISEO AL NMt DE ~

331

- : ; : : - y... bueno, ~ pen1ft cosos.

. . COlO, . .

meor-

........ No ........... ~ _ ....iIIi mocin potqUe ti cambia. SIw*it& No par-. flNYlIlMc ...

.... nlOcit, a ....

_8

inc!i<:a que no M~.

_0.__.

Al principio de este capitulo se obselV 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
11.1.1.

Paso 2.

Identificar todas las clases de diseo que corresponden al domi-

nio 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.
"::~::;:/IO

..,

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 disefio 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 com

ponentes 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 SlSlema

332

i
D!agnDnade

coIabcrncI6n

Trobojof'roduccicwI
1: CXJn$truirTrobojo "":'..,_....::-_. 2: remitirTrobojo

con envio M
memajeo.

1"'~,oOn

#'
/'

~"'_oOn

OrdeIlTrobojo

.-" -"'---.
CdoTrobojo

En la figura 11 .6 se ilustra un diagrama simple de colaboracin para el sistetNI

impresin analizado antes. Tres objetos, TrabajoProducdon, OnlenTrabajo ColaTrabajo, colaboran para preparar el envio de un trabajo de impresin al
de produccin. Los mensajes se pasan entre objetos como lo ilustran las flechas la figura. Durante el modelado del anlisis los mensajes se especifican como
muestra en la figura . Sin embargo, a medida que avanza el diseo, cada mensaJC! elabora al expandir su sintaxis de la siguiente manera IBEN02].
[oorddn~) 1cptMi6 . . . ~ (wIof

deweIto): =

oornI:If'9 MI menuj. (.... de lraumenfoeJ

donde una

[oondoi6n~]

est escrita en lenguaje de restriccin de objeto loa.

por sus siglas en ingls) y especifica cualquier conjunto de condiciones que debL

cumplirse antes de enviar el mensaje; upt"'6" de ~ es un valor entero (u

indicador de orden, como 3.1.2) que indica el orden secuencial en que se envia mensaje; (vab devueKo) es el nombre de la infonnadn que devuelve la operacin vocada por el mensaje; nombre di! menu;e identifica la operacin que se invoca y fa de ~) es la lista de los atributos que se pasan a la operacin.

Paso 3b. Identificar las inteaces apropiadas para cada componente. Ell
contexto del diseo al nivel de componentes, una inteaz UML es un "grupo de raciones externamente visibles (es decir, pblicas) . La interfase no contiene estn.. tura interna; no tiene atributos ni asociaciones... ~ (BEB021 . Definida de manera formal, una interfaz es el equivalente a una clase abstracta que proporci ona 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 abstracta (la interfaz) debe tener cohesin; es decir, debe mostrar procesamier' que se concentra en una funcin o subfuncin limitada. Tomando como referencia la figura 11 .1, podrfa argumentarse que la interfaz datTtabajo no muestra suficiente cohesin. En realidad, realiza tres subfunciones

ElOCL se anallU brevemente en la seccin 11 4 Y~n el capitulo 28_

CAPTULO 11

DISEo AL

NIVEL DE COMPONEHTIS

333

Refactorizad6n de det1n1clones de Interfases y clases para Impr1m1rTrabajo.

uftt.tIG.r. micJQrTrobo

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 ree xaminar las clases del diseo y definir una nueva clase OrdenTrabajo que se ocuparla de todas las actividades asociadas con la elaboracin de una orden de trabajo. La operacin construrOrdenTI"abajo( ) se vuelve una parte de esa clase. De igual manera, se podrla definir una clase FflaTrabaJo que incorporara la operacin revisarPrioridad( ). Una clase TrabaJoProducdon abarcarla toda la informacin asociada con un trabajo de produccin que se pasar a la planta de produccin. La interfaz iniciarTrabajo tomarla 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, OtdenTrabajo 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-axpresio :::: valor-inicial {propiedad cadena} donde nombre es nombre del atrbuto y tIpo-expreai6n es el tipo de datos; valor-iniciel es el valor que toma el atributo cuando se crea un objeto y P"Opiedad cadel18 define una propiedad o caracterlstica 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-pesoPopel se define de la siguiente manera: Tipo-pe80papel: atrin& :::: NA"{oontlene 1 di. 4 wIor.: A. 8, e o O}

334

que define TTpo-~ como una variable de cadena variable inidalizada con el ya. lar A y que toma uno de cuatro valores del conjunto IA,B,C,DI. Si un atributo aparece varias veces en varias clases de diseo, y tiene una estruc tura relativamente compleja, es mejor crear una clase separada para acomodar atributo.

Paso 3-D. Describir de manera detallada el flujo de procesamiento

d~

de cada operacin. Esto se logra empleando un seudocdigo basado en un bo guaje de programacin (seccin 11 .5.5) o el diagrama de actividad UML cada

ponente de software se elabora mediante varias interacciones que aplican el

cepto de refinamiento paso a paso (capitulo 9). La primera iteracin define cada operacin como parte de la clase de diseo ~

cada caso, la operacin debe estar caracterizada de manera que asegure una
sin elevada; es decir, la operacin debe realizar una sola funcin o sustitucin finida . La siguiente iteracin hace poco ms que expandir el nombre de la ope Por ejemplo, la operacin ru1cularCoslOPapel( ) observada en la figura 11 . 1 se ~ dirla de la siguiente manera:

Esto indica que ru/cularCostoPa~ ) requiere los atributos pellO, tamao Y oob entrada y devuelve un valor numrico (en realidad un valor en pesos) como

Si el algoritmo requerido para implementar rulcuJarCostoPapel( ) es simpk' comprende ampliamente, tal vez sea innecesario elaborar diseo adicional El
lJJ ...... selml

m a(mD lIIiemros"
SI

".Iist/Io dti """"" . ...,. ...,,,.-,,,

niero de software responsable de la codificacin proporcionar el detalle "'%5.< para implementar la operacin. Sin embargo, si el algoritmo es ms compleJO creta, se requiere mayor elaboracin de diseo en esta etapa. En la figura I describe un diagrama de actividad UML para calcularCostoPapeJ( ). Cuando sr plean diagramas de actividad para especificacin de diseo al nivel de co""",~ tes, suelen representarse en un nivel de abstraccin un poco ms elevado que digo fuente. Ms adelante. en este mismo capitulo, se analizar un mtodo .... -,,' el uso de seudocdigo para especificar el diseo.
Paso 4 . Describir fuentes de datos persistentes (bases de datos

Hoy lRl matlIlfIJ ds

~" lS1D miett, lIi!mo rtSIJtrrIo?

'"... """'*'

y ...._ ..

e identiftcar las clases necesarias para manejarlas. Las bases de datos y chivos suelen trascender la descripcin del diseo de un componente indi casi todos los casos estos almacenes de datos persistentes suelen especifi cialmente como parte del diseo arquitectnico. Sin embargo, a medida q~ la elaboracin del diseo, a veces resulta til proporcionar detalles adicionaSes estructura y organizacin de estas fuentes de datos persistentes.

CAPITuLo 11

DISEO AL NIVEl. DE COMPONIlrnS

335

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 disefo 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 infonnad6n 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 calcuJarCostoPapeJ( ).

validar enl1ada de atributos

Tamao .. B

co~toPopeIPorf>agil"\O
co~toBo$6PorP

..

ioo*1.2

Tomoo ..

coMoPapelPorPogioo .. costoBo~ePori'o ioo'1.4

Tomao .. D

cO$tof'apeIParPogina ..
ca~lofkuePorPo

no'1.6

El cotor

e~

e$tndar

e~

costoBasePorPagina* 1.14 ~~~~~~'~"'~P~O~"~PO<~Piog~;;"O~-2;~

Et color personolizada, /-~~~~--~

Devuelve
IcostoPo
IPorP

ino)

336

cin entre estados (impulsados por los eventos) se represen tan 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 r deadas) a otro ocurre como consecuencia de un evento que toma esta forma
~ev.nto

(lieta-per&mefftM:) loondidon-au.dill l expresion de aooioo

donde roombr.-.....-.ro identifica el evento; .....

piII.,..11"08 incorpora datos a

con el evento; OOI'odioI6I' ....~ est. escrita en lenguaje de restriccin de objeto y especifica una condicin que debe cumplirse antes de que pueda ocurrir el t o , y e.xpr-esion de acdon define una accin antes de que ocurra cuando t~ 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 lida. En casi todos los casos, estas acciones corresponden a operaciones re para la clase que se est modelando. El indicador hacer/proporciona un mecanismo ra indicar las actividades que ocurren mientras se encuentra en el estado, y d cador incJwr/ proporciona un medio para elaborar el comportamiento al ms detalle en la grfica de estado dentro de la definicin de un estado.
Fragmento de diagrama ele estado para la c:laM
~Implenta.

T
.~I ,~I
,

.,.".,

, ,,

,,

..........".......u.-~

_""

~l
I

,,

,,

CO.lDrra baoAcepIodo

tel d,ente

1""'-' irmoflectronico

['-1
el citen.. fil
,abafOlmpo-lHIOII

~ ,

,tI

~ 1~$Io$

CAP'ruLO 11

DISEo AL NIVEL DE ~

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 Trabajolmprenta 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 remitirTrabajo. 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 10 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 especificas y que se indica la ubicacin de los paquetes de componentes dentro de este entorno. Paso 7_ Factorlzar todas las representaciones del diseo a l nivel 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 mcxlelo 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 .

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 algun elemento del modelo de diseo. Es posible. por supuesto, describir restricciones en un lenguaje natural, pero este mtodo lleva invariablemente a la inconsistenLa

331

PARTE DOS

PRC"OCA DE 1.0\ lNI:DmIIiA DEL SOFTW.AB

cia y la ambigedad. Por tanto, lo apropiado parece un lenguaje ms fonnal, que '"

me en cuenta la leona de conjuntos y los lenguajes rannales de especificacin

ptulo 28), pero que tenga una cantidad menor de sintaxis matemtica que un
guaje de programadn.

(Q~

El lenguaje de resmcdn de obJdOS (OCw complementa al UML al permitir que

ingeniero de software use gramtica y sintaxis formales para construir instrucciorxs

& ,

.~

C~VE
~

sin ambigedades relacionadas con varios elementos del modelo de disef'lo l.P ejemplo, clases y objetos, eventos, mensajes. interfaces) . En el OCL las instrucciCln5 se construyen en cuatro partes 1) un contexto que define la situacin limitada el

que es vlida la instruccin; 2) una propiedad que representan algunas caraderi5io

cas del contexto (por ejemplo, si el contexto es una clase, una propiedad seria atnbuto); 3) una operodn (aritmtica, OTientada a conjuntos) que manipula o ca una propiedad, y 4) palabras clave (como if, theo, eIu, . nd, or, not, m plIee) con se especifican expresiones condicionales_ Como ejemplo simple de una expresin OCL, considrese la condicin guardia locada en el evento costoTtabajoAceptado que causa una transicin entre los estadI.. ca1cularCostOTrabajo y fonnaJTrabajo dentro del diagrama de grfica de e:sliII.. para la clase Trabajolmprenta (figura 11.9). En el diagrama, la condicin guard. se expresa en lenguaje natural y especifica que la autorizacin slo se presentan: el cliente est autorizado para aprobar el costo del trabajo. En el OCL, la expre5k tomaria la fonna

El OCl npoIOOr1:I gnt rOOboo YS'J\IlXi!; for. moles peno desoiIi los

el.",,,,, ..., el
nivel de componentes.

donde un atributo booleano, autoridadAutorizeci6n, de la clase CUente (en realidad instancia especifica de la clase) debe tener el valor si para satisfacer la canda guardia Cuando se crea el modelo de diseo suele haber instancias (consulte la seca 11.2.1) en que deben satisfacerse las condiciones previas y posteriores antes completar alguna opcin especificada en el diseo. El OCL proporciona una hern' mienta poderosa para especificar condiciones previas y posteriores de manera mal Como ejemplo, piense en una extensin al sistema de la imprenta (analizad. lo largo de este capitulo) en que el cliente proporciona un lmite de costo super" para el traba}o de impresin y una fecha de entrega limIte, al mismo tiempo que especifican olras caracteristicas del trabajo Si el costo y la entrega estimada den esos limites, el trabajo no se entregar y debe nolincarse al cliente. En el 01...un conjunto de condiciones previas y posteriores se especificarla de la siguiente nera:
oontext Trllbajolmprenta::vaIidate{lmite9uperiorCo8to : In...." reqEovioCIieot. :
Intew)
pHI: Imit~

> O

339

and I'8qEr'lvIoClieota > O

artd tiane.8utOf'lzacionTrabajo :: "no" post: If tIeM.OO8toTotalTrabejo < - limite9uperiorCoeto and ti_JeohaEnvio < .. reqErwioCIienta

......

tiene.avforizaclonTrabajo

= "ar

Esta declaracin OCL define una invariante (condiciones que deben existir antes [prel

'"'"

y despus [poat] de algn comportamiento). Al principio. la condicin previa establece que el cliente debe especificar el costo limite y la fecha de entrega, y que la autorizacin debe estar en "no" Despus de determinar los costos y la fecha de envo, se apli ca la condicin posterior. Tambin debe tomarse en cuenta que la expresin fiene.lMJtorizaoiooTrabejo :: "si" no est asignando el valor "si"; en cambio, est declarando que auforiHOiooTrabajo debe tener el valor "si" en el momento en que termine la operacin . Una descripcin completa del OCL est ms all del alcance de este libra. s Los lectores interesados deben consultar [WAR98J y IOMGOI J para conocer detalles adi cionales

UMI./ OCL Objetivo: e...lle !,IIl(I omplio YOriedod de herromienlos UMl poro oyudor 01diW'iaclor en

Hernlmientos representativos'
ArgoUMl, distribuido por Tigreu.OI'g Ihttp:// orgouml ti gris.org/I. da sapor1e o UMl y 0Cl completo, e inclu-

los eIropo$ del diW\o. Algunas de eWs herromienlas _"""~" _ al <XL

"";'"',a, Las herromienlos de esto cotegorro penniten a ~ crear todos los diagn;lInos de UMl nece$(!O poro conslnJir un modelo de diseo completo. lo ms le es que muchas herramienlos proporcionan uno y uno semntico slidos, verilloxin Ymonejo de de versin y combios (coplulo 27). Cuando se procapacidad de OCL, las herromienlos penniten .1 diiei\odor cree expresiones OCL y, en olgunos coIca compile para voriOllipos de evoluocin y

ye YOOos herramientas de oyudo paro el diseo, que yon ms ali de la generoci6n de diagramas UMl y e,:_<XL

Dresdtm OCL too/kif, de$(! rrollodo por Fronk Finger en la univenidod Tecnolgica de Dresden Ihttp://dresdenod-SOIHUIro..ge.oet/l, es un juega de herramientas basada en un compilador OCL que abarco yoriOl

mdulos que onolizon, fe'o'i$(!n ellipo y normalizan las

restricciones

0Cl.

OCL porser, desorrollodo por IBM Ihttp://www3.ibm.cam-

/ software/od/librory/ slandors/OCL-downlood. hlmlJ, esl escrita en Java y est. di~ible graluitomente PO' ra la comunidad orientoda o abek con el fin de que se estnnule el U$O de OCL con modeI~ UML

5 Sin embargo, en el capitulo 29 se presentar1 una apo5ICion ms amplia del OCL (presentada en el contexto de los m~todos fonnales) 6 laS herramientas mencionadas aqu ~lan UNI muestra de tsta calegorla En casi l odos los casos los nombres de las mismas son marcas repstradas de sus respect1VOS desan olladores

PARTE DOS

PRC11CA O[ lA

lM3tNID!fA DEL SIOFlWAIIE

.....,
~~.."

Los fundamentos del diseo al nivel de componen les para componentes ConvenQla nales de software' se integraron a principios de la dcada de 1960 y adquirieron lidez con el trabajo de Edsgar Oijkstra y sus colegas ([BOH66), 1011651. IDIJ76)). A nales de esos aos, Oijkstra y otros propusieron el uso de un conjunto de constnlo.. ciones lgicas restringidas, a partir de las cuales se pudiera fonnar cualquier proga. ma Las construcciones destacaban el ~mantenim iento del dominio funcional'" decir, cada construccin tenia una estructura lgica predecible, a la que se ingrtSll ba en la parte superior y se abandonaba en la inferior, lo que pennitla al lector guir con mayor facilidad el flujo del procedimiento. Las construcciones son secuencia, condicin y repeticin. ~ncia implemet'" los pasos de procesamiento esenciales en la especificacin de cualquier algon Condicin proporciona las funciones para el procesamiento seleccionado con en algn evento lgico, y repetidn permite los bucles. Estas tres construcciones fundamentales para la programadn estructurada, que es una importante ttcnic:a diseo al nivel de componentes. Las construcciones estructuradas se propusieron para restringir el diseo prtJCI. dimental del software a un nUmero pequeo de operaciones. la complejidad de mtricas (capitulo 15) indica que el uso de las construcciones estructuradas r la complejidad del programa y, por tanto, mejora las opciones de lectura, prucbl mantenimiento. El uso de un nmero limitado de construcciones lgicas ta contribuye a un proceso de comprensin humana que los psiclogos llaman mentad6n. Para comprender este proceso, pinsese en la manera en que est lqicI 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 estructur das son grupos lgicos que le permiten a un lector reconocer elementos prc::x: mentaJes de un mdulo, en lugar de leer el diseo o cdigo lnea por linea. La prensin se mejora cuando hay patrones lgicos fcilmente reconocibles.

C&VE
le ropnoo(:wl es ln.IlIOOo 1$I.l10 faj(O

de c5seOO cpJII res

..... I\;c~, ..

""II!S: SICI8I,

gG a 111$ cCII"6IrI.IaD-

am-

11.5.1

Notacin grfica del diseo

Ya se ha analizado el diagrama de actividad UML en este capitulo y en los capi 7 Y s, El diagrama de actividad permite a un diseador representar secuencia did6n y repetidn (todos elementos de la programadn estructurada) y es el cendiente de una representacin de diseo grfico anterior (an usado ampliame:r te) llamado diagmma de flujo. Un diagrama de flujo, como uno de actividad, es muy simple grficamente diamante representa una condidn lgica, y las flechas muestran el flujo de c
7 Un componente de software convencional implementa un elemento de procesamiento que uniI funcin O subfunci6n en el dominio del problema, o alguna capacidad en el dominio de It fr.Ie5tnIctura. A. menudo denominados mdulos. procedlfJuen/(lS o subruanas, los componentes vencionales no encapsulan datos de la misma manera que los componentes onentados a oo,c.

cAPTULO II

OOEo Al NIVEL DE ~

341

Condici6n

, - - ' - - , . Sigui... ~

"''''l~" m,~
Sftuencia

Repetir 100110 (r&ptoOt until)

Seleccin

Repeticin

En la figura 11.10 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-siJlo, 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 siJ1o. 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 reperir 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 selecdonar-caso) que muestra la figura es en realidad una extensin de si-entonces-siJ1o. 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 I es obviamente el enfoque ideal, pero la 2 puede acomodarse sin infringir el espritu de la programacin estructurada.

,.2
11 .5.2 Notact6n tabular del diseo
En muchas aplicaciones de software tal vez se requiera un mdulo para evaluar
combinacin compleja de condiciones y seleccionar las acciones apropiadas das en esas condiciones. las tablas de dedsin (HUR831 proporcionan una notac. que traduce acciones y condiciones (descritas en una narrativa de procesamie . una forma tabular Es dificil malinterpretar una tabla, y hasta puede usarse como Irada legible para una mquina a un algoritmo orientado a tablas. Una tabla de decisin se divide en cuatro cuadrantes. El de la esquina superior

o. umt tnl ftlbko

(cq.tlro

de tIec.isiOO aOki:llll com;Hto ~ (Crdti:JMS r oones S! eocwnlfm r:IMtm

dem(~re.

quierda contiene una lista de todas las condiciones. El cuadrante de la esquina il:r' izquierda contiene una lista de todas las acciones posibles, basada en combira. nes de condiciones. Los cuadrantes de la derecha forman una matriz que combinaciones de condicin y las acciones correspondientes que ocurrirn para W\a binacin espedfica. Por tanto, cada columna de la matriz puede interpretarse una regla de procesamiento. Los siguientes pasos se aplican para desarrollar un.
bla de decisin. l. Presentar una lista de todas las acciones que puedan asociarse con un prr dimiento (o mdulo) especifico. 2 . Presentar una lista de todas las condiciones (O decisiones tomadas) dUfilll ejecucin de un procedimiento. 3. Asociar conjuntos especficos con acciones especficas. eliminando c ciones especificas de condiciones; como opcin. desarrllese cada posau... pennutacin de las condiciones. 4 . Definir reglas al indicar cules acciones ocurren para un conjunto de ciones Para ilustrar el uso de una tabla de decisin, pinsese en el siguiente extracL. 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 otO llpos se asignan segun la canlldad de negocios que el cliente realiza con la imprftLI un penodo de 12 meses). Un cliente regular recibe predos de Impresin y fechas de ga normales_ Un cliente de plata obtiene un descuento de 8 por ciento sobre todas la tlzaciones y se coloca adelante de los clientes regulares en la cola de impresin Un de oro obtiene una reduccin dell S por dento sobre los precios cotizados y se coloca lante de los clientes regulares y de plata en la cola de trabajo. Es posible apliQr __ cuento especial de x porcentaje adicional a los otros descuentos a la c~ cualquier cliente, a discrecin de la administracin

En la figura 11.11 se ilustra una representacin de una tabla de declsKwl nada con el anterior caso de uso informal. cada una de las seis reglas ,nctic. ;""... las seis condiciones viables. Como regla general, la tabla de decisin se usa. de nera efectiva para complementar otras notaciones de diseo procedimenta.

c APTULO 11 ~ Al. NIVEL DEc:a.uamms

343

Condiciones CliMIe regular

CIoente

Reglo. 3

V(T) V(T)

ploto
f

VIT) V Ir) VITJ

f

Cliente oro Cliente e'f*:iol Acciones Sin descuento Aplicar 8 por <:iento de descuento Aplicar 15 por ciento de descuento Aplicar JI por~toe de descuento odiciooo!

V(T) V(T) V Ir) f VITJ

"
1"""',......1 "

...,.
,......-

11.5.3 Lengua1e de diseo de programas

El lenguaje de diseo de programas (POl, por sus siglas en ingls) , tambin denomi nado lenguaje comn estructurado o seudoctxJigo, es "un lenguaje rudimentario porque utiliza el vocabulario de un idioma (como el ingls) y la sintaxis general de otro (es declr, un lenguaje estructurado de programacin)" [CAI751. En este captulo, POl se usa como referencia genrica para un lenguaje de diseo. A primera vista, POL parecerla un lenguaje de programacin. La diferencia entre POl y un lenguaje de programacin real radica en el uso de texlO narrativo (como el ingls) incrustado directamente dentro de [as instrucciones en POL Dado el uso de texto narrativo incrustado directamente en una estructura sintctica, no es posible compilar POL. Sin embargo, algunas herramientas pueden traducirlo en un "esque leto" de lenguaje de programacin, en una representacin grnca de diseo, o en ambas (por ejemplo, un diagrama de flujO). Estas herramientas tambin producen mapas de anidamiento, un ndice de operacin de diseo, tablas de referencia cru zada y otra informacin diversa. Un lenguaje de diseo de programas puede ser una simple transposicin de un lenguaje como Ada, C o Java. La sintaxis bsica de POl debe incluir construcciones para definicin de componentes, descripci6n de interfaces, declaracin de datos, es tructuracin de bloques y construcciones de condiciones, de repeticin y de entra da/salida. Debe tomarse en cuenta que POl puede extenderse para incluir palabras clave para multitareas, procesamiento concurrente (o ambas opciones], manejo de interrupciones, sincronizacin de interprocesos y muchas otras caractersticas. El di seo de la aplicacin para la que se est usando POL debe dictar la forma final del lenguaje de diseo. El formato y la semntica de algunas de estas construcciones de POl se presentan en el ejemplo siguiente. Para ilustrar el uso de POL, consideramos un diseo procedimental para la funcin de .seguridad HogarSeguro analizada en ca pltulos anteriores. El sistema supervisa las alarmas para detectar fuego, humo, robo,

PARTE DOS

PRAcncA DE LA ~ DEL:aTWARE

agua y temperatura (por ejemplo, rompimiento del horno cuando el propietario esto. ausente en el invierno) , produce un timbre de alarma y llama a un sistema de mon tores, generando un mensaje de voz sintetizado. En el POL siguiente ilustramos a;, gunas de las construcciones importantes anotadas en secciones anteriores. Recuerde que POL no es un lenguaje de programacin. El diseador puede adaptarlo como se requiera sin preocuparse por errores de sintaxis. Sin embargo, el dlSl:o del software de supervisin tendrla que revisarse (se observa algn problema'" y refinarse antes de que pueda escribirse el cdigo. El siguiente POL' proporcaa una elaboracin del diseo procedimental para una versin anterior de un compt" nente de manejo de alarmas.
E1 obj.nw ct. oootrol periir

... """""""'.

_mone_ .t.
ct.
~

oompooente Jl'\Wlej... 108 Int~ Y lea entredee del per1III loe 8M8ONII por el ~ Y lIOtt.r en cuelquier oondioI6n de nrme . .

Mt.blecer veIorn por defecto p.. Mteius9lllf_ lvalot devuelto), todoe loe toe ti. defOl lniDieIzer todoe 108 ~ del 8IIrterrMI WNink:iIIr todo el t..rdwwe
_lnt~llpo)

ea.-

al ipo '" M proberMentonces inYocer

.wm. fijer WI M encendidoM

WI

al !po "" M .a...m.Apegedo" .-.tono. Invocat at...m. fijar

"apeaaOO"

por defecto ipc: = rintunO ....tllbleoer todo ~ ....t~ heoet F*8 todoe 101 MflIIOMI8 inYocer ~ prooecII,lieI,to ..,... VIIIorgeeI
al veIor9Ii'MII > limite
[~)

.,tono. t.Wono.menuje "" ......je ft\poAllNfne)

fij .. t..braAlerme WI "enoenddo" pete .t.m.Tiempogeaundoe fij ... Mteful aillf8lnli = "oondoi6nAIerme"
perempieza

............

prooedimiento alarma con "encendido", alarrnaTMJfl'IP0gegundoe invocer procedmiento telfono Jlj ... WlIipoAIarmI, nrneroTelfooo

..........

ti_1'iO omitir

t ....... t-peN
twmhe Jl'\WleJoAl-rme

8 El nivel de detalle que representa el POL:se define localmente Algunas personas prefieren UN cripcin orientada al lenguaje ms natural, mientras que otras prefieren algo ms parecido a
digo.

CAPTULO II

DISEO AL NIVIl. DE C(:NP(lNlNTIS

345

Obswese que el diseador del componente de manejo de alanna ha usado las construcciones psNltnpiezs._. parterrnioa que especifica un bloque paralelo. Todas las tareas especificadas en el bloque parampieza se ejecutan en paralelo. En este caso, no se toman en cuenta los detalles de implementacin .

Lenguaje de dL5eo de progJCzmas

Obje&to: Aunque lo inmensa mayora de los software que usa PDL a seudocuna versin que r.e adapto del lenguaje de de empleor para lo implementoPDL En algunos COsal, los Mrramienlos oplicon inveno 01 cdigo fuente {una triste rllCllidod en algunos programes no tienen absolutodocumentacin). Otros permiten al diseacon uno ayudo automatizado.
"~m;..". representativas
aeoc:i6n de diseos con el uso de una versin definido

doPOL
DocGen, distribuido por Software Improvment Grovp {http://www.saftware-improvers.com/DocGen.html. es uno herramienta de ingenierfo inversa que genero documentacin parecida a PDl a partir de cdigo

Ada y C.
PowerPDl., desarrollado por Iconix (http://www.iaJniY.sw. com/SpecSheets/powerf'Dl.htmll, le permite a un diseoodor creor PDL basado en di~s y luego traducir el seudocdigo O formas que puedon generar otras representaciones de di~.

JI " desarrollada poi" Caine, Farber y Gordon :// www.cfg.com/pdI81/1pd.html).dasoportea la

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 setia: Cul notacin es realmente mejor, dados los atributos indicados lineas 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 caractetisticas. 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
H

las herramientas expuestas aqui el autor no \as respalda; slo representan una muestra de las herramientas incluidas en esta categona. En casi todos kI5 casos. los nombres de las herramientas son marcas registradas de sus respectivos desarrolladores

PARTE DOS

PRCTICA CE: LA JNGDmlIlA. DEL!lCl'TWARE

grfica de los diagramas de actividad y los de flujo proporciona una perspectiva

bre el flujo de control que muchos disefiadores prefieren. El contenido tabular preo so de las tablas de decisin es una herramienta excelente para aplicaciones orientl 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 a sis final. la eleccin de una herramienta de diseo eSlar relacionada de manera Ir. estrecha con factores humanos que con atributos tcnicos.

La accin de diseo al nivel de componentes abarca una secuencia de tareas qur

ducen lentamente el grado de abstraccin con que se representa el software El sea 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. 11 depende de la naturaleza del software que habr de desarrollarse. El concepto tado a objetos se enfoca en la elaboracin de clases de diseno que provienen del problema como del dominio de la infraestructura. El concepto convenciora fina tres tipos principales de componentes o mdulos: de control. de domuv.. problema y de infraestructura. En ambos casos se aplican principios bsicos dr: 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 en ponentes de software reutilizables y en patrones de diseo que son elementos te de la ingenieria de software basada en componentes. El diseo al nivel de componentes orientado a objetos se basa en clases principios y conceptos importantes gulan al diseador a medida que se elabonr clases. Principios como el principio abierto-cerrado y el de inversin de la d cia. adems de conceptos como acoplamiento y cohesin, gulan al ingenierodr: ware en la construccin de componentes de software susceptibles de probars.. plementarse y mantenerse Para realizar diseo al nivel de componentes e. contexto, las clases se elaboran al especificar detalles de los mensajes. identifi teaces apropiadas, elaborar atributos y definir estructuras de datos para im tarlos, describir el Oujo de procesamiento dentro de cada operacin y represt!l comportamiento en un nivel de clase o componente. En todo caso, la iteracil'r seo es una actividad esencial. El diseo al nivel de componentes convencional requiere la representacin tructuras de datos, inteaces y algoritmos para un mdulo de programa con el Ue suficiente para servir como gua en la generacin de cdigo fuente en len programacin. Para lograr esto, el diseador usa una de varias notaciones de o que representan detalles al nivel de componentes en formatos grficos, o de texto.

tat.

347
La

programacin estructurada es una filosofia de diseo procedimental que res-

tringe 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.

[AMB021 Ambler, S" "UML Component Diagramming Guidelines", disponible en http://www.mo-

delingstyle.info/.2oo2
[BEN02) Benneu, S., S. McRobb y R Fanner, Obj/-Oriented Analysis and Des1gn. 2a, ed . MeGraw-HilJ, 2002 [BOH661 Bohm, C. y G. Jacopini. -F1ow Diagrams, 1\.Iring Machines and Languages w i th Only Two Formalion Rules", en CACM, vol 9, nm, 5. mayo de 1966. pp 366-37 1 [CAI75[ caine, S y K, Gordon , "PDL-A Tool ror sonware Design-, en Proc, Nalional Compuler conferenc~, AFlPS Press, 1975, pp. 271-276 [DI)65[ Dijkstra, E., "Programming Considered as a Human Activity", en Prrx 19651F1P Congress, North-HoHand Publishing Ca, 1965. [DU72[ Dijkstra, E., -rh~ Humble Programmer", 1972 ACM TUnng Award Lecture, CACM, vol 15, num lO, octubre de 1972, pp. 859-866. IDIJ76 Dijkstra , E., "Structured Programming", en SOjtwar~ Engl1leering, Concepts and 7h:hntques O Buxton ~t al., eds 1, Van Nostrand-Reinhold, 1976 [HUR83] Hurley, R. B., ~ision "RIbles in sojtware Engintxring, Van Nostrand-Reinhold. 1983 {LETOI] Lethbrldge, T y R. Laganiere. ObjfOn~nled SOftware Engineering' Praclica/ SOftware lkvelopmenl uslng UML and Java, McGraw-lliIl, 2001 [US88] Uskov, B. , "Data Abstraction and Hierarchy", en SIGPlAN NOUces, vol 23, nm. S, mayo de 1988. [MARoo] Mantn, R., ~Ikslgn PrincipIes and Design Patlems", descargado de hllp:/ /www.object mentor com, 2000 OMGOIj OMG UntJied Modding SpedJication, Object Management Group, version lA , septiem bre de 2001 [WAR98] Warmer, J. y A Klepp, Ob/ectConstroint Language: PredseModeling wlth UML, AddisonWesley, 1998,

I 1. 1. El trmino componente suele ser diflcll de dennir Primero proporcinese una denniCln genrica y luego definiciones ms explicitas para software orientado a objetos y convencional Por ultImo, elijanse tres lenguajes de programacin con los que se est familiarizado e ilustre se 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 orien tado a objetos' 11 .3 . Descrlbase el paradigma onentadoa obtetos mediante argumentos

propios Por qu es impor-

tante crear abstracciones que sirvan como inteaz entre componentes'

11 .4. Describase el DIP mediante argumentos propios. Qu pasar1a 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 cohe sin elevada, cul seria' 1 1.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 aeo plamiento elevado, cul seria'

PARTE DOS

PRAcTIcA DE LA lNGnmSIlA. DEL!IClfTWAa

11 .7. Es razonable dec Lr que los componentes del dominio del problema nunca deben trar acoplamiento externo' Si se est de acuerdo. cules tipos de componente mostrarlan tipo de acoplamiento' 11 .8 . Investlguese y desarrllese una lista de categonas tlpicas para los componentes de fraestructura 11 .9. ,Qu es una condicin guardia y cundo se usa? 11 . 10. ,Cul es el papel de las interfaces en un disefio al nivel de componentes basado clases' 1 1.11 . Los trminos all'ibulas pblicos y privOdos suelen usarse en trabajo de diseo alru..." 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) a-. grama de actividad para una de las operaciones dentro de la clase; 4) un diagrama de de estado detallado para una de las clases de HogarSeguro que se han analizado en anterores. 11 . 14. Es lo mismo refinamiento por pasos que faclorizadn? Si no. cules son sus cias' 1 1. 15. Investguese un poco y describanse ues o cuatro construcciones OCl u operadora: no se hayan analizado en la secd6n 11.4. 11 . 16. Selecci6nese una pequea parte de un programa existente (de unas 50 a 751~ cdigo). Aislense las construcciones de programaci6n estructurada dibujando cajas de ellas en el cdigo fuente ,El extracto del programa tiene construcciones que violan solla de programacin estructurada' De ser as!. redisese el cdigo para que se amoldlt construcciones de programacin estructurada De lo contrario. qu nota en los recuadftest dibujando'

los pTincipios de diseo. los conceptos, las lineas generales y las tcnicas para clases .

ponentes orientados a objetos se revisan en muchos libros sobre mgeniera de sonwa~ lisis y diseo orientados a objetos Entre las muchas fuentes de informacin se el1C1EJ!ll Bennelt y sus colegas lBEN02, Larman CApplying UML and PtJll~$. Prentlce-HalJ, 2001 rldge y Laganiere [L.ETOII y Nicola y sus colegas (Slreamlined Objecl Modellng. Parlcm and Impkmmtotlon, Prenti~- Hall , 2(01), SChach tObjeCl-OrierliM and dassical ~ neering, 2001 ), Dennis y sus ~~;;;~~~~A~oa~,~",,~~~; signo An quinta Ob)ect edicin, OrientedMcCraw-Hill. Approach wilh UMl, Wiley, 20011, Prinaples aOO PractJce. Addison-wesley, 2(00), Richter (Deslgrung ems Wllh UML, Macmillan. 1999), Stevens y PooIey (UsllJ8 UML Sojhwre Enginemng }15 and ComponenlS, edicin revisada. Addison-wesiey, 1999) y Riel (Objecl-Orienfcu I/eunstics, Addison-wesley, 1996). El concepto de dLseo por contrato es un til paradigma de dLseo. libros de Mltc KLm (DeSIgn ~ Contraa ~ EXample. Addison-wesley. 2001) y Jezequel y sus colegas Paltems 000 Con/nJcts, Addison-wesley. 1999) analizan este tema en forma detallada (DesIgn PrIftems java l\trlbook. AddJson-Wesley. 2002) y Shalloway y Trott (Of'sign plamed A Nav Petspt!t:trve 0fJ ObJeaQnented Design. Addlson-wesley. 2001) toman ert el Impacto de los palrones en el diseo de componentes de sonware, La iteracin de esencial para la creacin de diseos de alta calidad. Fowler (Refaclonng Improving !he ofEXISIJng COde, Addison-wesley, 1999) proporciona una gula til que puede aplicarse da que evoluciona el diseo. El uabajo de Unger. MLlis y WiU (.SUucrtutd Progrommmg-Theory 000 Proc~. Wesley, 1979) sigue siendo un tratado definitivo sobre el tema El texto contiene un adems de explicaciones detalladas de las rnmificaciones de la programacin "'",,_3iI

"""'dI!<

CAPITtn.o 11

DISlO AL NJVEL rE a::Ni'ONENTES

349

Otros libros que se concentran en los temas de diseo procedimental para sistemas tradicionales son los de RObertson (Simple Program fJeslgn, tercera edicin, Course Technology, 2000), FarreU (A Guide ro Programmmg Logic and Design, Course TecllOotogy, 19991. Bentley CProgrom ming Palrls. 2a. edicin, Addison-Wesley, i999) y Dahl (Structured Programming, Academic Press, 1997). Relalivamente, pocos libros recientes se han dedicado en exclusiva al disefto al nivel de componentes. En general. los libros de lenguaje de programadn atienden el disefto procedimental con algn detalle, pero siempre en el contexto del lenguaje que se introduce en el libro Hay disponibles cientos de titulos Una amplia variedad de fuentes de in(onnacin sobre diseo al nivel de componentes se encuentra en Internet. Una lista actualizada de referencias en World Wlde Web que resultan relevantes para el diseo al nive! de componentes se encuentra en el slUo Web de SEPA' http://www.mhhe.cOmlpl"essman.

CAPTULO

12
CONCEPTOS CLAVE

DISEO DE LA INTERFAZ DE USUARIO

.........

11. . . . . . .

.375

...... . .3$6

.......... ..... _.364 ..........

l plano de una casa (su diseo arquitect6nico) no estarfa completo sin representacin de puertas. ventanas y conexiones de agua, electricidad y rono (sm mencionar la televisin por cable) Las "'puertas. ventanas f nexiones" del software de computacin integran el diseo de la interfaz usuano. El diseo de la interfaz se concentra en tres reas: 1) el diseo de inle

r.to ........363

entre componentes de software; 2) el diseno de interfases entre el soft otros productores y consumidores de informacin que no son humanos les
cir. otras entidades externas), y 3) el diseno de la interfaz entre un ser h (es decir, el usuario) y la computadora. Este capitulo se concentrar excl mente en la tercera calegoria de diseo de lo interjaz: la del usuario . En el prlogo de su libro clsico acerca del diseno de interfaces de Ben Shneiderman (SHN901 afirma
La frustracin y ansiedad son parte de la vida diaria de muchos usuarios de 51st de informacin computarizados. lUchan por aprender ellenguale de comand~

.........

fedIWod;' ISO. 355

..,Ra ...... .313

lit.".....
1. . . . . . . . . .

.316

IIt.mI ..... .354

-'IsiI dt ..354
tIMb.......355

sistemas de selecdn de menus que

presuntamente deben ayudarles a realizar sub-

..,... .317

. . .... .361
petT..s .....311
~M . . . .351

,.... ..

. . . . . . . . .3$6

baJO. Algunas pcrsonasse encuentran con casos tan serios de choque de com ra. terror terminal o neuross de red. que eviian el empleo de siStemas de cmput:"

Los problemas que refiere Shneiderman son reales. Es derto que las ces graficas de usuario. las ventanas. los iconos y las selecciones hechios ,:;;;;.~,
ratn han eliminado gran parte de los ms terribles problemas '~I~~~~:::~ las inleases. Pero aun en un mundo de ventanas~. todo mundo ha

o. .., El diseo de la nterfoz de

uwario croo un medIO de comunico cin efecti'lO entre un 5ef humano y uno computadora Siguiendo un con junto de principiru de diseo de interfaces, el diseador ldentfica Ioi obletos y los acciones de lo interfaz y luego crea un foro mato de paf1tollo que forma le base de un proIolipo de interfaz de usuario Quin lo hace? Un ingeniero de soft......ore dseo la interfaz de U$UClrlo 01 opltCOr un ptoa!SO iterativo basado fJfl principtos de diseo amplio""",lo oceptodoo Por qu importonte' Si el v)() del software e$ ~il. si levo 01 'lJsuorio o cometer errares os'

frustro sus esfuerzO$ por alconzor ws ~...,,"

no le gustor. sin imporlor su copacidad

fvncione$ que ofrezco. Lo interfaz liene que

correcto porque moldeo lo percepcin del no acerco del software.

e...... ton ..,. paso. , El diseo de lo inierll: u!oUCIrio empieza con la identificacin requl51Os de $te. lo tareo y el ombiet*
...ex identificados los toreas del usuario, se

y anal UJI"I los escenarios de ste poro deIini conunto de objetos y acciones paro la
Este constituye \a base poro lo creacin Ot rJ"IOtoi de pontcllo que representan el disek &CO y la ubicoci6n de los iconos. la defin ,

...

...., d e _ '" panlolla Ia..pec;

C APTULo 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 (arman 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 disei'iador a la interfaz pretenden simplificar el modo de interaccin Para quienes? En muchos ca-

PARTE DOS

PRC"J1CA DE LA ~ 0E1. sc::I'T'WAJiIE

sos, el diseador introduce limitaciones y restricciones para simplificar la implerratacin de la interfaz. As, tal vez se tenga como resultado una interfaz fcil de ~ truir, pero cuyo uso resulta frustrante. Mandel [MAN971 define varios principios de diseo que permiten al usuario mil' tener el control: Definir los modos de interacdn de forma que el usuario no realice aco. nes innecesarias o indeseables. Un modo de interaccin es el estado actua. la inteaz. Por ejemplo, si se elige corrector ortogrfico en un men de un proas. dor de palabras, el software pasa a un modo corrector ortogrfico. No hay ni razn para obligar al usuario a que permanezca en este modo si desea editar el too Debe darse al usuario la opcin de entrar y salir de l sin esfuerzo. Proporcionar- una intencdn flexible. Debido a que diferentes usuarios distintas preferencias de interaccin, deben ofrecerse las opciones correspon<tier' Por ejemplo, tal vez el software le permita al usuario interactuar mediante miento del ratn , un lpiz digitalizador o comandos seleccionados con el teca... mediante reconocimiento de voz. Pero no todas las acciones son adecuadas pata dos los mecanismos de interaccin. Por ejemplo, imagine la dificultad de utililJl'" mandos seleccionados con el teclado (o entrada de voz) para dibujar una compleja. Incluir las opciones de intelTUlllpir y deshacer- la interaccin del .._ . Aunque se encuentre en medio de una secuencia de acciones, un usuario debe con la opcin de interrumpir la secuencia para hacer otra cosa (sin perder el que haya hecho) . Tambin debe contar con la opcin de "deshacer" cualquier Depurar la interaccin a medida que aumentan los grados de desl:r"ea 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 fa interaccin. Oculte al usuario ocasional los elementos t~cnicos internos. La interfJ.. be llevar al usuario al mundo virtual de la aplicacin; no es necesario que COf"I el sistema operativo, las funciones de administracin de archivos u otros secrdl la tecnologia 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 soflwJll aplicacin) . Disear interaccin directa con los objetos que aparecen en la pan ~ usuario siente que tiene el control cuando manipula los objetos necesarios paa. lizar una tarea de manera parecida a como lo hara con un objeto material Por plo, una interfaz de aplicacin que permita al usuario "alargar" un objeto su tamao) es una implementacin de manipulacin directa.

CAPTULo 1 2

DISEO DE LA Itm:RFAZ DE USUAlOCl

353

"SiImpn he deseado que mi (omputodora seo lan fd de nmejof tomo mi telefooo. Mi _ .. ea si t6ma lISIlf mi !tIfooo:

w ha yudlo,.w.t

12.1 .2 Reducir la carga en la memorta 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 este. 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. Mandel [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-I 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 fonnato visual de la inteaz 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 pennite que el usuario dependa de pistas visuales que comprende bien, en lugar de memorizar una misteriosa secuencia de interacciones.

Desglosar la infonnaci6n 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).

PARTE DOS PRC'OCA DE LA lNG'oENIIlIiA. DIl.SOFTWARE

HOGARSEGURO

la . . . na; cubculo de Vinod,

~

de USUOrlo

_m1 _ vw.od,.bM, in~ del equipo de

Vinod: Eso !lO. lo importroIlIe ... laI Ji Ia. ..... Jomie: Oh, pod.mos proposcioiOM _ . . . . cmaras en opeIoci6I, y ara . . . . _ , WL
V;........ .
U!lO

*""

.......... ,.ro.-.~.

la

_ ~

_'4!xtdo. ...... t-n.._ J.II Pw\sor es bueno_

.......... .....ao ....do., lo interIoz de lo funcin

"lbl'

,..;bIo. ... _

.......... . . .

dfna

~ oo~

Jamia: tmy bien, plopoI~Ia . . . Ia . . . Vinod: Eso est6 ifIIlIot. Por lo

. . . . 0.0 . . podImos simplificar un poco los

Jc.n.. I~
Vinoct: Af-

....... au.no. ~ pasorio si eiirnincJmos por completo

....... lo CICJdI Es,~. pero requiere muc:hol En Iugor de eso. ~ol t $ 1a . . 4. :iIq.IaClllDfaqdeseo ..... yluego t i 14 .t!II.I vidIo. uno -*'"':1 de video.

...................

"""""" '""" ........... .... ..... un _. l_"Pwoolilt

"** ,.......-

gu".1 plano, te> nof

..Iamie; CuI ~ . . a.tJU*llklo

II1II._.-'..
.......... _Oobo....,..

_!,.'_et
IOCII_ ka

V. .....:r.bo"...a"........

Jamir. No Vinod: Uh. .. q&.-

111M. W

......... furw:ioI.do y d6ndt se eno.oenIrOfl'

.. ... iC6mo NCDdcw.l propietario CUflt-n

"""(Iiit _ .

fuflCiones oh cxlivo! en las productoe... . . . . no'" ifltere!o cuI M ms f6ciI de CXIftIlrW.

Jam;' ' .... pl.....): Nvt

_."'"

1 ' ~ . 01 d..oiIo. dobe

bMn. toI v..- ..... un

prototipo de ambos

Vinod: Bt..!o ideo.. luego dep . . . que 11 dienII

decido.

12.1.3 Lograr que la interfaz sea consistente

La interfaz debe adquirir y presentar la informacin de manera consistente . Esto

p(ca que 1) toda la informacin visual est organizada de acuerdo con un e de diseo que se mantenga en todas las presentaciones de pantalla; 2) los mear mas de entrada se restrinjan a un conjunto limitado que se utilice de manera lente en toda la aplicacin, y 3) los mecanismos para ir de una tarea a otra se hr definido e implementado de manera consistente. Mandel[MAN971 define un c to de principios de diseno que ayudan a construir una interfaz consistente:

Las qw fitnen ti mismo ~D, . . .

Pennitir que el usuario incluya la tarea actual en un contexto que tenp gn significado. Muchas interfaces implementan capas complejas de interac...... nes con docenas de imgenes en pantalla. Es importante proporcionar indicaGi.o (pOr ejemplo, ttulos de ventana, iconos grficos, cdigos de color consistentes

cAPTULO

12

DISENO DE LA INTD!fAZ DE USUARIO

355

permitan al usuario conocer el contexto del trabajo que realiza Adems, el usuario debe tener la capacidad de detenninar de dnde viene y cules son sus opciones pa ra la transicin a una nueva tarea. Mantener la consistencia en toda una familia de apUcaciones. Un conju nto 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 r-azones lnexcusables. Una ve7 que una secuencia interactiva se ha convertido en un estndar de Jacto (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) crearla confusin. Los principios del diseo de interfases expuestos aqu y en secciones anteriores proporcionan una gula para un ingeniero de software. En la siguiente seccin se examinar el proceso de diseo de la interfaz.

Fac1lldad de uso En un brillonte ensayo sobre lo facildad de

uso, larry Conuonline [CON95} plontea una ""..."" que Ii_ uno fuerte re/ocin con el tema: MtAl de cuentos, que quief"ef\ los U$uorios' Re~ os: realmente quieren son buenos :~:::;~:~':~: . Todos los sislemos de softwore, de5de los operolivos y ~ leng\lOjes hoslll lo enlrodo de y los oplic:.ociones de opero o lo tomo de decisiones, do herramientas. Los uwori05 finales esperon de 105 ~_ _"~, que conslrvirrlOl poro ellos lo mivno que espetorrlOl de los herromienlol que USOrrlOl listemos fciles de op.-eoder y que les ayuden o troboo. Quieren softwore que na los detengo, '...... o confundo, que na les IIeYe o comelel" en"OI"eS o lIiIicuIte lo lefminocin del trobojo-. Con.sl'Ontine orgumenlo que lo focmdocl de vso na se de mec::onismos de inlerocci6n estticos o modernos, Iflleligencio integrodo en lo inlerfaz. En combic. cvondo lo orquih!Jduro de lo inlerfoz corresponde o ....cesicIodM de los personas que lo usor6n. ..kIo definicin formol de focilidod de uso es elU1ivo. =-",",y $Us coIegos (DON99) lo definen de lo siguiente MFocilidad de uso es una medido de lo monero en un lislemo de cmputo... focililll el oprendizoje; ..do o qui_ o::wenden o recordor lo que hon ido; reduce lo posibilidod de errores; les pet"mite ser i -I~.... Ylos dejo sotisfechos con el ,istemo-.

Lo nico monero de detenninar si existre M focilidod de dentro de un lislemo en conslruccin consi"" en usoM realizor uno evoluocin o una pruebo de uso. Obst-.oese o los usuorios interoctvondo con el sstena y respndonse los siguientes preguntos [CON95]:
Es posible usor el sistemo sin ayudo ni enseonzo
conti n uo~

ilos regios de interaccin ayudon o un usuorio conocedor o trobojor con efciencio~ iLos mecanismos de interoccin se vuelven ms flexibles o medido que los usuorios adquieren m6s conocimientos'

tE! si$femQ se ha odecvodo 01entomo fsico y sociol en que hobrn de usorse'

El uworio esI ollonlo del estado del sistemo' tEI uworio $Obe dnde se encuentro en codo mome!1to~ Lo inlerloz esl eslruclvrodo de monero lgico y conlislentrei

iLm. meconivnos de interaccin, iconos y procedimientos son consistentes en todo lo imerfod

tLo inlenxci6n onlicipo
l!fTOI"e5

correginos'

y ayudo 01 uworio o

lo intertoz Ioieto los enores que se cometen~

ilo interoccin es simple2

356

Si 58 responde afirmotivomenle o codo uno de ~Ios pregunten, es probable que 1tI ho)'O okonzodo lo Iocilidod

de U50. E"tre Ioi nvmet"OSO$ beneIkios men~ derivoc\c.s de Uf1 )islierro con foclidoc! de uso 58 enwenlrOn ([)()N99):
ITICI)"OI"

CQilpetiliOlO, me;ot'lI$ reseas en le medios, mejores 18CCi , . . .docio Ifi de boca en boca, cosIoJ de soporte reducickt5, mayor productividod del uwario ~nol, ~ coNos de copoc:itocin Y documentocin, oOem6s de
menos

probobilidocles de que ~ uworiO$ in$OIi$~

niYel de vento$ y $(Iti~i6n del usuario, ventaja

enloblen demondoL

El proceso general para analizar y disear una interfaz de usuario empieza con creacin de diferentes modelos de funcin del sistema (como se percibe desde el CI terior) . Luego se delinean las tareas orientadas al ser humano y el equipo que se re-

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 pi' ra crear prototipos e implantar finalmente el modelo de diseno, y los usuarios fm.

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 m diferentes. Un ingeniero humano (o el ingeniero del software) establece un modo.
dd usuario; el ingeniero del software crea un modelo del diseno; el usuario finaJ

sarrolla una imagen mental que suele denominarse modelo mental del usuario o f1'l' cepci6n del SIstema, y quienes implementan el sistema crean un modelo de la imp. mentacin. Por desgracia, es posible que estos modelos difieran signiflcativamer entre sI. El papel del diseador de la interfaz es reconciliar estas direrenclas y del var una representacin consistente de la interfaz.
15 tlIIISisteIft.

HasIo !IIUSIAl/'O
(JI9on1e ~g
(l((fSOS

El modelo del usuario establece el perfil de los usuarios finales del sistema construir una interfaz de usuario efectiva, "todo diseo debe empezar por la prensin de quines son los usuarios de destino, incluidos sus perfiles de edad
XO , habilidades flsicas, educacin, antecedentes culturales o tnicos, motivacOr objetivos y personalidad" (SCH90. Adems, es posible distribuir a los usuarios en siguientes categorfas:

LWIOnS; hasm kis USOOtios

~asycm

--

amir_lo suelen _ _ 1IIDuil

Principiantes No tienen conocimientos de la sintaxisL del sistema

y cuentan

Hoy .. -

...

escasos conocimientos1 de la semntica de la aplicacin o del uso de la computa ra en general.

I En este contexto, conOCimiento de Sllllaxis alude a los mecanismos de interaccin requeridm usar la interfaz de manera efectiva 2 COtloanuenlode semntico alude al senlido in~rente de la aplicacin luna comprensin de dones que se realizan. elsLgflHcado de entrada y salida, y las melas y los objetivos del siSlml

CAPTULo 12

DISEO DE LA INTERFAZ DE USUARIO

357

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 "s(ndrome del usuario avanzado" (es decir, individuos que buscan combinaciones de teclas y mtodos abreviados para interactuarl Un modelo del diseno 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.! 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 determinarla 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.

1P)tste CIfeOO6fI o lo que hwo los USIIOI"GS, no a lo que dicen."

El modelo de la implementacin combina la manifestacin externa del sistema de cmputo (1a 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 exactltud la informacin sintctica y semntica de la interfaz. lOs modelos descritos en esta seccin son "abstracciones de lo que el usuario est haciendo o 10 que piensa que est haciendo o lo que alguien ms piensa que deberla estar haciendo cuando usa el sistema interactivo". [MON841. 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 Asf no es como deben ser las cosas. En muchos casos. el dlSd\o de la interfaz es tan imiX'nante como el diseo arquitectnico y el nivel de componen tes

358

PARTE DOS

l'RC't1CA. DE LAINGENlEl4A DEL SOFTWARE

12.2.2

El proceso

El proceso de an~lisis y diseo de las interfaces de usuario es iterativo y se represet

la con un modelo espiral parecido al que se analiz en el capitulo 3. Tomando referencia la figura 12.1, se observar que el proceso de anlisis y diseo de la IllIef
faz de usuario abarca cuatro actividades distintas de marco de trabajo [MAN97) l . Anlisis y modelado de usuarios. tareas y enlomos.

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 a

nal de los requisitos y el diseo resultante. En casi todos los casos, la actividad 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 interaa.. rn con el sistema. Se registrarn el grado de habilidad, la comprensin del y la disposicin general ante el nuevo sistema, y se definirn diferentes catep de usuarios.

Una vez definidos los requisitos generales se realiza un anlisis ms detalladL las tareas. Se identifican, describen y elaboran las tareas que el usuario realiza

--

El _do _do'" lnter1cn dII

U5UOrlo.

Volidoci6n

An61~s

del uworio,

de lo

inte~

lo toreo y el entorno

Implemenlocin

~--....._..... Oiwti\o de lo interfaz

CAPTULo 12

DISEO DE LA IN'TI:RFAZ DE USUARIO

35.

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 estiln las siguientes: Dnde se localizar fsicamente 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 defne 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.

Un principio clave de todos los modelos de procesos de ingenier1a del software reza: es mejor comprender el problema antes de tratar de diseiiar una solucin. En el ca 4 Resulta razonable argumentar que esta seccin debi colocanoe en el capitulo 8. porque a!Ji se estudia el
an~\isis

de requisitos. se ha incluido aqu porqut': el anlisis y el diseno de la interfaz estn

ntimamente relacionados, y porque ellmte entre ambos es muy difuso

PARTE DOS

PRCTICA DE LA

lNGDIIDIfA DEL 9:lFTWARE

so del diseo de la interfaz de usuario. comprender el problema significa comJ'lU' 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 hactt trabajo; 3) el contenido que se presenta como parte de la interfaz, y 4) el entamo que se realizarn estas tareas. En las secciones siguientes se examinar cada uno estos elementos del anlisis de la interfaz con el fin de establecer una base para el diseno de las tareas que siguen.

12.3. 1 Anlisis del usuario

Ya se ha indicado que cada usuario tiene una imagen mental del software (o pen:r! cin del sistema) que podrla ser diferente de la imagen mental de otros. Adems probable que la imagen mental del usuario sea muy diferente del modelo del disIS que tiene el ingeniero. El diseador slo lograrla que coincidan la imagen me el modelo del diseo si trabaja para comprender a los propios usuarios, ademas la manera en que ellos usarn el sistema. Es posible usar infonnacin de una variedad de fuentes disponible para lograr esto: Entrevistas con el usuario. Es el enfoque ms directo. Representantes del po de software se entrevistan con usuarios finales para comprender mejor sus sidades, motivaciones, cultura de trabajo y gran cantidad de temas adicionales. to se logra mediante reuniones personales o con grupos de enfoque. Informacin de ventas. El personal de ventas se reune con clientes y de manera regular y obtiene infonnacin que ayudar al equipo de software a ficar a los usuarios en categorlas y a comprender mejor sus necesidades. Informacin de mercadotecnia. El anlisis de mercado es invaluable en la nici6n de los segmentos del mercado, al tiempo que proporciona una comprerlSllJla la manera en que cada segmento usarla el software de manera sutilmente di( 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 disgma caracteristicas que generan dudas y las que resultan fciles de usar. El siguiente grupo de preguntas (adaptado de IHAC98] ayudar al diseador 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 expr 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?

Cmo s lo

que los lSuarios quieren de la interfaz?

f"COMSIJO"
san "'", """'" ~1I1riJh0ll .m U5lIri:Is "*.

....... ......
""'" ... do

petO d /rur.;a ClIr

"""'/10fuerte .. .....

--do'"

oro'

"

C&VE

Cmo oxenderoos sobre kl deroo;wdo V los (oroctOOstic:os de los usooriosfim?

cAPTULO

12

DISENO DE LA [NttRf'AZ DE USUARIO

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 agruparlan 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 especificas? Cules tareas y subtareas se realizarn mientras el usuario trabaja? Cules objetos especlficos del dominio del problema manipular el usuario mientras se realiza el trabajo? En qu secuencia se presentan tareas del trabajo (el nujo 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 especifica 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 pequef'a 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 especificas del diseo. Cuando se les pregunta: "cmo decide

36'
el lugar en que colocar un mueble en una habitacin?", un disenador de nten.:escribe el siguiente caso de uso informal:
Empiezo hacendo un borrador del plano de la habitacin. las dimensiones y la POSlCJ(8

de las ventanas y puenas. Me preocupo por la manera en que entra la luz , por la vista qu..
se tiene a travs de las ventanas {si es hermosa, me gustarla llamar la atencin hacia elY: por el espacio que las paredes no tapan, por el flujo del movimiento en la habitacin. Lue-

go observo la lista de muebles que mi cliente y yo hemos elegido (mesas, sillas, sillones vitnnas) y la lISta de accesorlos lamparas. alfombras, cuadros. esculturas, plantas, peque fIas piezas), y tambitn observo mis notas sobre la manera en que mi cliente desea que litdistribuyan Luego dibuJO cada elemento de miS lislas empleando una plantilla que se hI
dibUjado a escala con el plano. Etiqueto cada elemento y uso lpiz porque siempre mUl,"VD cosas. Considero vanas opciones de ubicacin y decido cul es la que me gusta cliente una idea del aspecto que tendr
m"..

Luego dIbujo una representacin (Una imagen tridImensional) del ruano, para dar a

Este caso de uso proporciona una descripci6n elemental de una tarea de traba, portante para el sistema de diseo asistido por computadora. A partir de l, el niero de sonware extraer tareas y objetos, adems del flujo general de la inllJ< cin Adems, tambin es posible concebir otras caracteristicas del sistema agradaran al diseador de interiores. Por ejemplo, podrian tomarse fotograllas tales del panorama de cada ventana. AsI, cuando se haga una representaci6n dt;imagen de la habitaci6n se mostrara la vista real en cada ventana.

HOGARSEGURO

0U0t de uso paro el djselJo de lnterfQus de usaarIo

. . ..;;;.~:;;... o~ .. d,...., do b """""-

.. ".!'MI: GAliculo de VnxI,

i~

YInOd; E$O d bien. & \.nO o. te. p* e 'ea """"""'_ do b ' - do la U- do

~

1M
.. _

I _ Vinod y~,
......II'm

del equipo ele

..;g.lr;.ncig, P.n:I .....,1(& . . . _ _ '"lar ..........

....._IuCW ~o. HoggrStIguro.

...... fui a

. . . . 0 . . . 0 Ion aJIO de UIO pato

a mi o:rixto de mtIO'~io e hice la ~ de vigilmcia.

. . . . eo.dt:- prio de visto de qu;n~

...... 0.1 prcpieDrio de kJ caso,;de quin ms~ . . . ~ . . . . ~ 0.1 odrnini$lradcwt"f~ io~ ese papel, Iandr un

Jomie (h-ritocIa): r_ razn . (Jomie ~ o buKOr o lo f*lC'IO de .. _~oicl Regreso unos horas mM Iorde,' Jo....: Twe werte. Encanfr a nuestro CII:II*'dD mecodokio,;oy rr~ junto5.1 COIOd.I oommisJrador BOsico"*e. ~

del odminislrudor d.l5oi....

.......... _ _ _ _ a 'odmini"""""

;~""'" D"""', d_" piona do b = ,

. . . . hicelueque"*codoI.a.io~ro p . ao . . . . . *unvideo.

. _.

hobiI",~

tbn .. muestro a vonod.l CDXJ d. Il1O iMoormoI.1

~~~~:~~~::ro::::~~::~~:-'
~. Cuondo~"Ii"-a~_D

Ca.o de "'M ""... nMII:CIuiefolocClpclI:i.d. tonJiguror o edilor. fomDo cW.n..na -' cuakpwr

furo6n de OOmirustrocin. Me f"9UI*J:~";::::!~

uno nwvo QOO~9uroc:iil Respondo

cAPTULO

12

DISENO DE LA INTERfAZOE USUARJ:)

363

en ona cuadriculo, Hobr g~gs~~~d.dibujo ~ me permi. Y que

ftlnlanas

poerlas

me

, Solamen. estiro los ic01'101 poro qoe

clmenlin~. El siWrna despIegor kH ,... O ft'IIIIn:Il ~ sMeciooor elli$lemo TIIIgo lo opcin de _c;onor sensores y

o eIin.inot los que yo ai$len, editor el plano de io cotO Y los ~ de c;maros y Mn!lOl'eS, En todos los COIOI. MpeJO que el sis""" -..ga consi.tencia y me oyucho a no corneter errores

bibtldKa y de ubiconol en el P'ono

codo una, pero el ,i!.lema
Tongo~

...... Iot pormcItro$ de ~ y . . . . . MIft$ .,.des, Si Mlecc:iono edilcK,

,_.. ,-.....,.. o

Vinod (delpWl de ..... el guin}l M.ry bt.n Tal vez hoyo olgunos ~ de diseo 6ts O algunas componentes reutilizoble. que podcwra UIOI' efI lea inlBrfoces 9r61i~ de utUPrio tomados el. algn programo de d$Olao. To CIpIIC'IO lo Jmido 11 "'" si 101 O$OmQ$, podemos implementar porte de lo iIWrfaz cW odministrodor. o cosi lodo ella,

1m cmoros, agregar nl.le'OS

Elaboracin de la tarea. En el capitulo 9, se analiz la elaboradn paso a pa so (tambin denominada descomposicin juncional o refinamiento paso a paSO) como mecanismo para refinar las tareas de procesamiento requeridas para que el softwa re realice alguna fundn deseada. El anlisis de la tarea para el diseo de la inter faz emplea un enfoque elaborativo para apoyar la comprensin de las actividades humanas a las que debe adecuarse la interfaz de usuario. El anlisis de la tarea se aplica de dos maneras. Como ya 10 hemos indicado, un sistema interactivo, computacional, suele usarse para reemplazar una actividad ma nual o semiautomtica. Con el fin de comprender las tareas indispensables para al canzar el objetivo de la actividad, un ingeniero humanoS debe comprender las tareas que las personas realizan actualmente (al usar un mtodo manual) y luego relado narlas 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 hu mano 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 compafa de soft

:=::.~!

n III'J , ....'.. no

ware pretende construir un sistema de diseo asistido por computadora explfcitamen te para diseadores de interiores. Al observar cmo trabaja uno de ellos, el ingeniero nota que el diseo de interiores abarca varias actividades importantes: distribucin del mobiliario (tome en cuenta el caso de uso que ya analizamos), seleccin de telas y ma teriales. seleccin de tapices para paredes y cortinas para ventanas, presentacin (pa ra el cliente). presupuesto y compras. cada una de estas importantes 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 doescntas en esta sein. Lo Ideal es que esta persona tenga capacitacin en IngenieN humana y en ~ de interfaces de usuario

364

PARTE DOS

PRCT1CA DE lA

lNGDml!lA 00. SOFTWARE

el caso de uso, la distribucin del mobiliario se refinarla de las siguientes tareas; 1 bujar un plano de la casa tomando como base las dimensiones de la habitacin _

ubicar las ventanas y puertas en los lugares adecuados; 3al usar las plantillas muebles para dibujar contornos a escala en el plano; 3b) usar las plantillas de 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 vista

dimensinal en perspectiva para el c1iente_ Un enfoque similar se usarla 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 reallzarn al 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 representaria poca interaccin directa del usuario.' El modelo del diseo d..: interfaz debe acomodar cada una de esas tareas para que sea consistente con d deJo del usuario (el perfil de un diseador de interiores ~tipicoj y la percepciP sistema {lo que el diseftador de interiores espera de un sistema automatizado] Elaboradn del objeto. En lugar de concentrarse en las tareas que un debe realizar, el ingeniero de software examina el caso de uso y otra informadc. tenida del usuario y obtiene los objetos fisicos que usa el diseador de interiores tos objetos pueden ordenarse en clases. Los atributos de cada clase y una cin de las acciones aplicadas a cada objeto proporcionan al diseador una lts:l operaciones Por ejemplo, la plantilla de muebles se traduce en una clase I_ _~ Mueble con atributos que podrlan incluir tamao, fon-na, ubicaci6n Y otras. El dar de interiores seleccionarla el objeto de la clase Mueble, lo mt:1lleria a una pos en el plano (otro objeto en el contexto), dibujarla el contorno de los muebles, d.:.. tareas sdecdonar; mover y dibuj<U son operaciones El modelo del anlisis dt terfaz de usuario no proporcionarla una implementacin para cada una ~ operaciones. Sin embargo, a medida que se elabore el diseo se definirlan los Hes de cada operacin.

tcON_.

.....

d!I.Sf/fJflti.1ID debe lISIrSe romo II!

...."'" ""'"
inle. 1.0 VOl del
111 rwn.tr . . . .

...........
lIlIti: di "

ti

ma.

An:llisis del Oujo 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 dd. trabajo. Esta tcnica permite que un ingeniero de software comprenda cmo SI!" liza un proceso de trabajo cuando se involucran varias personas (ji papeles). en una compaia que pretende automatizar el proceso de prescribir y enviar camentos que se venden con receta. Todo el proceso7 girar alrededor de UN
6 Sl.n embargo. tal vez l5te no sea el caso Es probable que el disel\ador de interiores quien car la perspectLva del dibujo. el tamao o el uso del color y otra informacin. El caso de donado con las representaciones de dibujos en perspectiva proporcionarla la inform~
7
Este. ejemplo

necCSlta atender en CSla tarea. se ha Miaptado de [HAC<J8j

C APTULo 12

DISEO DE LA INTmFAZ 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 linea 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 jerarqula 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 Especificar fecha 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.

PARTE DOS

PRCOCA

DE L\ lNGENlEAIA DEI. SOFTWARE

D1agrama ele llnea de flotad6n p:na la tund6n de resurtido de recetas.

Paciente

Fannacutico

Mdico

SoIicilcl que MI rewrto uno receto

No

re.slan

So

Rev;$(! .l j~lorio potO resurtido u otro opcin

Se....alo
medicocin olterno

Recibe notincoci6n
de que no hoy .ltislellCio$

Recibe fecho/horo
poro """""'

Ninguno

Recibe $OIcilud de ir 01 mdico

CAPTULO 12

DISEO DE LA INTIIlFAZ DE USUAmO

367

~ , "!s ~ "'" ""'lo< lo lomoIog;o ,1 """" .. .ligo. , Ot, oIopl 10 "",",lo.' ' lorr;' ~
12.3.3 Anlisis del contenido de la pantalla

Las tareas del usuario idenlificadas en la seccin anterior llevan a la presentacin de diferentes tipos de contenido. En el caso de aplicaciones modemas. 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 falografia 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:

.....0;" ~

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 [HAC981 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 alrededor,las caractersticas 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 difcil o frustrante.

PARTE DOS

PRCJ1CA DE: LA ~ DEl. SCFfWARE

En algunas aplicaciones la interfaz de usuario para un sistema de cmputo se ca en un ~Iugar amigable para el usuario" (por ejemplo, iluminacin apropiada, na altura de la pantalla, fcil acceso al teclado), ~ro en otros (como el piso de fbrica o la cabina de un avin), la iluminacin es deficiente, el ruido es importaPI un teclado o un ratn no son una opcin, la colocacin del monitor es menos ideal. Al disenador de la interfaz lo limitarn faclores que atentan contra la faci

de uso. Adems de los factores del entorno fisico, la cultura del lugar de trabajo la incide. La interaccin del sistema se medir de alguna manera (por ejemplo.

po por transaccin o exactitud de esta)? Dos o ms personas tendrn que ca tir informacin antes de que se proporcione una entrada? Cmo se dar sopor"" los usuarios del sistema' Es necesario responder stas y muchas otras pregunta ladonadas antes de iniciar el diseo de la interfaz.

Una vez finalizado el anlisis de la interfaz, se han identificado con detalle todL tareas (objetos o acciones) que requiere el usuario final, y comenzar la activldJl. diseno de la interfaz. Esta etapa, como todo el diseo de la ingeniera del softes un proceso iterativo. Cada paso del diseo de la interfaz se da varias veces cada uno de ellos se elabora y refina informacin desarrollada en los pasos
res. Aunque se han propuesto muchos modelos diferentes para el diseo de la

faz de usuario (por ejemplo, INOR86J, INIEOOIl , todos sugieren alguna comb de los siguientes pasos: 1, Con base en la infonnacin desarrollada durante el anlisis de la info (seccin 123), definir los objetos y las acciones de la interfaz (operac' 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 final 4. Indicar cmo interpreta el usuario el estado del sistema a partir de la i proporcionada mediante la interfaz. En algunos casos, el disei'lador de la interfaz puede empezar con borradores da estado de la interfaz (es decir, el aspecto de la interfaz en distintas circu y luego trabaJar hada atrs para definir objetos, acciones y otra informacin tante para el diseo Independientemente de la secuencia de las tareas del ste debe 1) seguir siempre las reglas de oro analizadas en la seccin 12.1. 2 lar la manera en que se implementar la interfaz, y 3) tomar en cuenta el (por ejemplo, la tecnologla de despliegue, el sistema operativo, las herram desarrollo) en que habr de usarse.

cAPTULO

12

DISEO DE LA !N1ERFAZ DE USUARIO

369

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 aislan los nombres (objetos) y los verbos (acciones) para crear una Usta 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 aplicacn 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 envo 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 pantalla. 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 pre liminar. Quiero tener acceso a mi sistema HogarSeguro desde cualquier lugar remoto vla Internet. Empleando software de navegador que opera en mi notebook (mientras estoy trabajando o viajando) puedo detenninar el estado del sistema de alarmas, armar o desannar 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 contraseia. Estos elementos definen los niveles de acceso (por ejemplo, no lodos los usuarios pueden reconfigurar el sistema ni proporcionar seguridad). Una vez validado, puedo revisar el estatus del sistema y cambiarlo al annar o desannar HogarSeguro. Puedo reconfigurar el sistema al desplegar un plano de la casa. ver cada uno de los sensores de

370

PARTE DOS

PRAcocA DI: lA ING&IIERIA ca.!IOFTWARE

.seguridad, desplegar cada zona configurada actualmente y modificar zonas de acuerdo.

con las necesidades. Puedo ver el nlenor de la casa con las cmaras de video colocadas

de manera estratgica. Puedo hacer acen:amicntos y desplazamientos con las cmaras

para proporcionar dLferentes vistas del interior

Con base en este caso de uso se identifican las tareas del propietario. los
los elementos siguientes-

ob~

tiene acceso al sistema HogarScguro

ingresa un ID y una contrasef\a para acceso remoto

rt:VJS(l

el estatus del sistema

anna o desanna el sistema HogarSeguro

despliega el plano de la casa y las ubicadones de los sensores despliega zonas en el plano de la casa
cambio zonas en el plano de la casa

despliega ubicadones de las dmaras de video O el plano de la casa

selecciona visualmente una cAmara de video
Vt"

imgenes de video

desplazo 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 a 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 video (una ventana que contiene el despliegue de video). Se crea un boceto preliminar del ronnato de la pantalla para el monitomro deo (figura 12.3).' La imagen de video se solicita seleccionando un icono de cin de las camaras de video, e, localizado en el plano de la casa despleg ventana de monitoreo. En este caso se arrastra la ubicacin de una camara en la sala, SA, y se coloca sobre el icono de cmara de video ubicado en la

irn.aa-

tcOflSlJO" ....,.."
""'-lO<

outomc~lodas WI

8fI el rJesoooIo do_do 1Mnato, 111 oc:mim!s

perior izquierda de la pantalla. Aparecer la ventana de imagen de video, desr' do video de flujo continuo proveniente de la cmara ubicada en la sala (SA ' troles deslizables de acercamiento y desplazamiento se emplean para CClr' ampliacin y la direccin de la imagen del video. Para seleccionar una visL. cmara, el usuario simplemente arrastra y coloca un icono de ubicacin de

...

bIomrpl2

,.1M:I1S'Prr

8 Considrese que esto difiere de la Implemenlacin de estas caracteristicas ."",.,,".... . . . . Esto podra considerarse un borrador del primer diseo y representa una opcin dJgIWI
~~~

CAPTULO 12

DISEO DE LA INTERf'AZ DE USUARIO

371

Acce$o ConF iguror Sis!emo

HogarSeguro
C:::::::~~=:D:l

Primer PjJo
S s.n-p<.JMIO/~ [) OW1rX ti. ~ /royo moTx/oJ e U6ic0ciM ti. ~ ti. ~

I 111111 6:rp.._ '

11111111 D

diferente en el icono de la cmara emplazado en la esquina superior izquierda de la pantalla. El boceto del formato que se muestra tendria que complementarse con una ex pansi6n 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 ca da tarea de propietario anotada en el escenario del usuario.

12.4.2 Patrones de diseo de la interfaz de usuario

Las interfaces grficas de usuario sofisticadas se han vuelto tan comunes que ha 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 IDUV02j , [BORO I ], WELOI r y [TlOO21 para conocer ms informadn .

J72

Patrones de Jnterfaz de usuano En las ultimas dcadas se han propueW cien los de patrones de interfaz de uwono. rtdwell
nOO2j y Van W.lie [WROll proporcionon Ioxonomios' de los patrones de diseo de nIefku: de uworio que se hon Of9OI"IiwOO en 1O cotegorlas. En ate recvodro MI pre~Ion patrones de ejemplo de codo uno de Was colegoIios,

Descripcin breve: PrcpoR:iona uno ruto completo de ~, cuando al usuario eu6lrobojondo CDl I n )

"'"""'" do"";~

o,...,..... do dMP_

Interfaz de UllJOr1a c:ompleta. PropoIciouo kneos

Ncrvegocin. AJVdo 01 usuario en el m:orrido de _ ns jerrquicos, pgino! Web y ponIollo de despliegue __ leroctivo. PcItrn: .didn en ellvgor Descripcin breve: Proporciono lo copocidod de.l
ci6n ~mpIe de lexIos poro ciertos tipos de conlenido _ ellugor en que se despliego.

generoles de diseo paro l&)inJctvra y novegocin de oIto

n~ ,

PatrOn: j~ eJe oho nivel Descripcin breve: Ploporciono un menU de olio nr..eI. O menudo ocopIado o un logotipo o lInO imagen de identificocin que permite lo novegocin directo o woIquiero de los principales fvncione:t, del $i~.

Bsqueda. Permita bsquedas de conlrenido ~ mediante lo inlormocin mantenido en un !oitio web 0 _

lrenido en oImocenm pers~1IIn de dolo! que esIn_ ilbIM poro una opIiaxin inlerodivo.

D.ao d. pagina. Atiende lo Of'9OOizocin genero! de los p6ginos {poro silioJ Webl o di,tin\o$ despliegues de
pomaRo (poro oplic0ci0ne:5 irer0diY05). Patrn: pilo eJe corlcu Descripcin breve: Proporciona el 05pIKkl de uno pilo de conos con pe$too$; poro 5elec;cionar40s Sol hcx:e die en codo uno de ellas, que reprmIIo ~ espeo1icos o cotegorim de canterudo

Patrn: bonquedo simple Descripcin breve: Preporcioroo lo copocidod de ' cor, en un iltio web o una fven,- de dota! per!I
un elemento WnpIe de dotol Oacrita por uno codoIfo~ .

fte.nentos de pgina Implementa elemenlo$

CO$

de un plgina web o pantalla de de~egue

uno Ioreo complejo, proporcionando guas poro

Patrn: O$iPenIe Descripcin breve: u..o 01 usuario poso o peno !XI"

fonnularios y entrada. Tomo en evenla d~ 1cnic05 de diWw; paro tOmpIetor enIrodos al nivel de formularios.. Patr6n: llene los espoc:im; .., blanco DelCripcin breve: Permite el ingreso de dom olfonurnricDs en un ~cuodro de 1eJdo-.
Tabla.. PrClpOlc::iouo gufo de di*", para lo cttJOCi6n Y monipulocin de todo tipo de dol\ tabulares. Patrn: labia qve perm;1e su onIenocin DeKripdn breve: Despliego uno largo liw de regis' tros que :111 ordenon 01 ~ un meconi$ll'lO interruptor poro cualquier etiqueto de lo columna. Manipulacin directo d. dotos. Atiende lo edicin, modificoci6n y Ironsformoci6n de dotol. migas de por!

pIetor lo 101110 medionll!! una WIrie de ventonas

Comerdo .a.mnico Especb de sitios we
potronM implementan elementos recurrentes de .......~

de comercia electrnico. Patrn: corriIo de compros Descripcin breve: Proporciono uno liw de ___ seIeccionodos en uno compro. Vorios Patrones que no caben fcilmente en lo.
MI

rim onlt!riotes. En ~ cosos, estos patrones ..._ _

del domin,o u ocurren poro do5e$ especo1iCO! de Patrn: nc/icoor de programo Descripcin breve: Proporciono uno ndio:Jci6,o greso cuondo se flI reoIiuJndo uno ..,..... .......

12.4.3 Temas de diseo

A medida que evoluciona el diseo de una interfaz casi siempre surgen cualJIII comunes: tiempo de respuesta del sistema, fundones de ayuda para el USlaI'I nejo de informacin de error y rotulado de comandos. Por desgracia. m
9 Ef1 {Tl002 Y IWELOI se encontrarn descripciones de patrones completos Ounto con otros patrones)

CAPTULO 12

DISEo DE LA. INTERFAZ DIE USlJAlIIO

373

nadores no prestan atencin a estos temas hasta una etapa relativamente tardla del proceso de diseno (en ocasiones el pnmer 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 melar abordar cada uno como elemento de diseo y tomarlo en cuenta al principio del diseno de software, cuando los cambios son fciles y el costo es bajo.

nempo de r espuesta. 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 teela Return o hacer elic con el ratn) hasta que el software responde con la salida o la accin deseada. El tiempo de respuesta del sistema tiene dos caractersticas importantes: duracin y variabmdad. Si la respuesta del sistema se demora mucho, la frustra cin 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 varia 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, lal 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 linea que permiten al usuario obtener una respuesta a sus preguntas o resolver un problema sin dejar la inteaz. Deben atenderse varios temas de diseo (RUB881 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? Enlre 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.

37.

Cmo se represenlar la ayuda? Las opciones son una ventana separada ,

una referencia a un documento impreso (menos que ideal) o una sugerencia

de una o dos lineas que aparece en un lugar fijo de la pantalla.

Cmo regresar el usuario a la interaccin normal? Entre las opciones se m c1uyen un botn de regreso desplegado en la pantalla. una tecla de funcin ouna secuencia de control Cmo se estructurar la informacin de ayuda? Las opciones son una estJ\L tura "plana" en que se tiene acceso a toda la in formacin con el teclado, ~ Jerarqua en capas de informacin que proporciona detalles crecientes a medida que el usuario la recorre, o el uso de hipertexto.

Manejo de errores.
noticias~

Los mensajes de error y los avisos de precaucin son

que se entregan a los usuarios de sistemas interactivos cuando algo salt

En el peor de los casos, los mensajes de error y los avisos de precaucin ofrecetl' fOllTlacin intil O que puede malinlerpretarse y que slo sirve para aumentar la traci6n del usuario Algunos usuarios de computadora han encontrado un error fOllTla

-z.a aplicodn XXX se ha visto forzada a cerrarse porque se ha encontrado un

del tipo Ion". En alglin lugar debe existir una explicaci6n del error 1023; de lo
rio, por qu habrian asignado los diseiiadores ese identificador ? Sin embair' mensaje de error no proporciona una indicacin real de lo que estu vo mal ni de de buscar la infOllTlaci6n adicional. Un mensa}e de error presentado de esta no hace nada por aliviar la ansiedad del usuario ni ayuda a corregir el problema

,. iIIIrfa aIII el irinr. 'r.. mmp me error 'f

....."

.wanll,

em. waIq.ier nIInn priIIo. 11 ...

En general , todo mensaje de error o aviso de precaucin que produzca ma interactivo debe tener las siguientes caracterlsticas:

UI'

,CM
cDracteristic:as debe fuer un

El mensaje debe describir el problema en un lenguaje que el usuario enI El mensaje debe proporcionar consejos constructivos sobre la manera cuperarse del error. El mensaje debe indicar cualquier consecuencia negativa del error lpe< ....... la pos1bilidad de que se corrompan los archivos de datOS) para que el asegure que no han ocurrido (o para que los corrija si ya ocurrieron). El mensaje debe acompaflase de una pista visual o auditiva. Es decir. nerarse un bip juniO con el despliegue del mensaje, o ste debe parpadl;:. momentneamente o desplegarse en un color que se reconozca f ci como
~color

-kM" IHnsoft Oe error?

de error"

El mensaje no debe contener juicios. Es decir, la redacci6n nunca debr al usuario

c APTULO

12

DISENO DE LA INmIFAZ DIE USUASllO

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. Rotulaci n de mens y comandos. El comando de texto escrito fue alguna vez el modo ms com n de interaccin entre los usuarios y el software del sistema y se usaba en aplicaciones de todo tipo. Hay el uso de interfaces orientadas a ventanas, con opcin de sei'lalar y elegir, ha reducido la dependencia de los comandos escritos, pero muchos usuarios avanzados an prefieren este lipa de interaccin Varios lemas 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 funcln o palabras escritas por el usuario Qu tan dificil 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 [a interfaz? Los submens son consistentes con la funcin indicada en un elemento principal del men? Como se indic al principio de este capitulo, 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 errares. Accesibllldad de la aplicacin. A medida que las aplicaciones de computadora se vuelven ubicuas, tos ingenieros de software 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 fisicos_ Diversas lneas generales de accesibilidad (por ejemplo, [W3C03)), muchas diseadas para aplicaciones web, pero a menudo aplicables a cualquier sonware, proporcionan sugerencias detalladas para el diseo de interfaces que alcanzan diferentes grados de accesibilidad. Otros (como [APP03]. MIC03!) proporcionan lineas generales especificas para "tecnologla asistencial" que atiende las necesidades de quienes tienen discapacidades visuales, auditivas, de movilidad , del habla o de aprendizaje.

37.

lntemadonallz.acin. Los ingenieros de software y sus administradores subesti man invariablemente el esfuerzo y las habIlidades necesarias para crear interfases de usuario que atiendan las necesidades de usuarios de otras localidades o que ha blan diferentes idiomas. Con demasiada frecuencia. las interfases se disenan para

una localidad y un idioma y luego se espera que funcionen en otros paises. El relo para los diseos de nleases es crear software "globalizado"; las interfaces de usua
rio deben disearse para contener un ncleo genrico de funciones que se entreguen a todos los usuarios. caracteristicas adicionales de localidad permiten a la interfaz

personalizarse para un mercado especifico.

Los ingenieros de software cuentan con varias pautas para la internacionalizacin (como [IBM03J). Estas pautas atienden amplios problemas de diseo (como las diferencias en formato de pantalla en varios mercados) y temas discretos de imp~ mentaci6n (por ejemplo, diferentes alfabetos pueden crear rotulaci6n y requisitos de espacio especiales). El estndar Unicode (UN J 03]) se ha desarrollado para alender el desalentador desafio de manejar docenas de idiomas naturales con cientos de carac teres y simbolos.

Desanollo de interfases de usuario

CI

lIiiiiiiiI Objetivo. EW5 het-romientrcu le penniten un ingeniero de softwore creor uno in~lIioxIo

Hen-omienta, de rep...,entoctn IO

terfuz grfiOl de uworio ero opIeo..do ~Ie e5IXI$O

wftwore personoIi:tOdo. Los henumienlos prorMilimbles Y caMerlll!llo creocin de uno interfo:t en uno ~ entre opcic:InrM predefinidcn que w ensamblon mediante la herromienb.
pOIc::ia1Oll oa:eiCI CI cornpo!MIMes

~m:lIio de

Mocromedio AvIhotwore, desarroilodo por HIoctomedio lne. (www.rnocromedio.com/softwore/l.whadiseodo poro lo creocin de interbes y enlomo5 de oprendi.zoje eledrnico. EmPeo coroc;lrelsticos .ofisticodo:n
decon~.

Mecnico. los interfoses de usuorio modernos ~ln constnJioos con un conjunto de componentes reutilizobl~ ocopIodos con olglJOO$ componenle$ penonoIi~ desom:lIiodos poro proporcionor funciones especioIi:todeu. Cosi lodos las herromiento$ de desarrollo de interfoses de uworio permiten que el ingeniero de software cree uno in~z empleando opc~ de ~arraslror y coIoc.or"; es decir, el desarrollador Miecciono en.... opciones predefinidos (por ejempla, consln.odores de formulorios, meconiwnos de inleroccin, copocidod de prncesomienb de COI.IOIO:n) Y coloco esas opciones en el CCIO"IlerIido de la intenoz que ha-

Motif Common Deslft:lp Environmenl, de:r.orrollodo por The

Open Group (www.O$f.org/lech/desktop/cde/l. ~ uno imwfoz grfko de usuorio integrado poro sistemos abiertos de computrxin de escritorio. Enlrego uno in!lerfoz grfico simple, estndor, poro lo om,mi$. Ifocin de dolos, orchivos y opIcor;ione$.
~/"'-1lvikW. .... rroIlado "'" s,bo~
(www. rybose/producn/n~sl. es un

br6 de crearse.

conjunto mvy completo de herramientas CASE, que induyw1 muchos opciones poro el diseo y lo con!.tn.occin de inleffoses gr6flcos de usuoOo.

10 Las herramientas expuestas aquf slo representan una muestra de esta catesorla. En casi todos casos los nombres de las mismas son marcas regJstradas de sus respectivos desarrolladores

CAPTULo 12

DISENO DE LA INTERFAZ DE USUARIO

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 fonna mostrada en la figura 12.4. Despus de completado el diseo se crea un prototipo de primer nivel. A continuacin. el usuario evala este prototipoll 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 infamacin que proporciona el usuario. y as se crea un prototipo de segundo nivel. El cieJo de la evaluacin contina hasta que ya sean innecesarias ms modificaciones al diseo de la interfaz.

Diseo preliminar

'\

Con$JTlJir interfaz prototipo # 1

Construir

interfaz

(
Se realizon modficaciornn 01 dluao

ptOtoIipo 'n

El tJ5\Jorio evol(a la interfaz

estudia Oiuano de Interfaz lo evoluoci6n completa

"--

Eldi~

11 Es importante notar que los expertos en disei'los ergon6momico y de interfaz tambin pueden diri -

gir revisiones de la interfaz. Dichas funciones se llaman evaluaciones heursticas o ensayos cogni tivos _

'"
El enfoque de creacin de prototipos resulta eficaz, pero es posible evaluar la ca lidad de una inteaz de usuario antes de construir un prototipo? Si se descubren posibles problemas y se corrigen en las primeras etapas, se reducir el numero de bucles en el ciclo de evaluacin y se acortar el tiempo de desarrollo. Si se ha cread&.. un mcx1elo de diseo de la Interfaz, es posible aplicar varios criterios de evaluaciQrl (MOR8I) en las primeras revisiones del dIseo: 1. La longitud y complejidad de la especificacin escrita del sistema y su interfaz indican la cantidad de aprendizaje necesario para los usuarios del sistema 2 . El numero especificado de tareas del usuario y el promedio de acciones por larea 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 inteaz y el grado de aceptacin del usuario. Una vez construido el primer prototipo, el diseador puede recopilar diversos daL cualitativos y cuantitativos que ayudarn a evaluar la inteaz. Para recopilar los ca tos cualitativos se pueden distribuir cuestionarios entre los usuarios del protOllJ'" con preguntas que arrojan: 1) respuesta simple si/ no, 2) respuesta numrica, 3) res puesta con escala de valoracin (subjetiva) , 4) escala de Ukert (por ejemplo, c pletamente de acuerdo, un poco de acuerdo), 5) respuesta con porcentajes (sub va) o 6) respuesta abierta Si se desean datos cuantitativos, puede aplicarse una forma de anlisis de esb. dio del tiempo. Se observa a los usuarios durante la interaccin y se usan los da (como el numero de tareas completadas correctamente en un periodo estndar, fre cuencia y secuencia de acciones, tiemJX) que pasa ~mirando" la pantalla, numerr tipo de errores, tiemJX) de recuperacin de errores, tiempo dedicado al uso de la a da y canUdad de referencias de ayuda por periodo estndar) como gua para la mt dificacin de la interfaz. Un anlisis completo de los mtodos de evaluacin de la interfaz de usuario te' basa el alcance de este libro. se puede consultar ms informacin en [LEA MAN97) Y [HAC98)

12 ,6

RIIPNIN
Es posible afirmar que la inteaz de usuario es el elemento ms importante de sistema o producto de cmputo. Si la inteaz est mal diseada la capacidad usuario se ver muy reducida para aprovechar las ventajas de una aplicacin efecto, una inteaz dbil puede llevar al fracaso una aplicacin bien diseada y una implementacin slida

CAPiTuLo 12

DISENO DE LA IN'l1:RFAZ DE USVARIO

379

Tres principios importantes guian el disefio de una interfaz de usuario efectiva: I) dar el control al usuario, 21 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 desarrol1ar un proceso de diseno organizado. EI diseno de la interfaz de usuario comienza con una serie de tareas de analisis. Entre estas se encuentra identificaci6n del usuario, tarea y analisis y modificaci6n de la tarea y el entomo. EI analisis del usuario define los perfiles de varios usuarios finales y aplica informacion recopilada de diferentes fuentes de negocios y tecnicas. EI analisis de tareas define las tareas y acciones de! usuario empleando un enfoque elaborativo u orientado a objetos, aplicando casos de uso, elaboraci6n de tareas y objelos, analisis de flujo de trabajo y represenlaciones jerarquicas de tareas para comprender plenamente la interacci6n ser humano-compuladora. EI amllisis 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 objelos y acciones de la interfaz . Eslo proporciona la base para la creaci6n de! fonnato de pantalla, que represenla el diseno grafica y !a ubicaci6n de los icones, la definici6n de un texto descriptiva en panta!la, la especificaci6n de las ventanas y la asignaci6n de Utulos a estas, ademas de la especificaci6n de los elementos primarios y secundarios del menu. Mientras se retina el modela de diseno, deben tomarse en cuenla l emas relacionados con el diseno, como tiempo de respuesta, eslructura de comandas y accianes, manejo de errores y funciones de ayuda. El usuaria dispone de varlas herramientas de implementaci6n para construir un pratotipo que el mismo puede evaluar.

[APP03] Apple COmputer, Pooplewith Special Needs, 2003, disponible en http://www.apple.com! disability/. [BAR01) Borchers. J., A Ftluem Approach 10 Interaction Design, wiley 2001. [CQN9S! Constantine, L "What 00 Users WanP Engineering Usability in Software, en ~Vindows 7elh }oUma1, diciembre de 1995, disponible en htlp:l!wwwfoTUse.com. lDON99] Donahue, G., S weinschenck y J Nowicki, "usability is Good Business', Compuware Corp., julio de 1999, disponible en http://www.compuware.com. [DUY021 vanDuyne, D.. ). Landay y J. Hong, The deSign Of Sites, Addison-Wesley, 2002 [HAC98] Hackos, J. y J. Redish, User and Task AnalYsis for Interface Design, Wiley, 1998. [!BM03! 16M, OvetviewofSoftware Globalization, 2003, disponible en http://oss.software.ibm.com /icu!userguide/ I 18n.html. [LEA88] Lea, M .. "Eva I ualing User Interfaces Designs~ , en User Interface DeSignfor computer ~tems, Halstead Press (Wiley), 1988 [MAN97! Mandel, T., The Elements of User tnt~ace DesIgn, Wiley, 1997 (MIC031 Microsoft Accesability Technology for Everyone, 2003, disponible en httJ /www.microsoft.com/enable/. IMON84] Monk, A. (ed), Fundamentals a/Human Computer Interaction, Academic Press, 1984. [MOR81! Moran, T. P., ''The Command Language Grammar A Representation for the User Interface of Interactive Computer Systems", en InCl. Journal o{Man-Machlne Studies. vol. 15, pr 3-50. (N1EOOI Nielsen, 1, Designing Web US(1bility. New Riders Publishing, 2000. INOR861 Norman. D. A., "Cognitive Engineering~, en UsnC~tered systems Design, Lawrence Earlbaum Associates, 1986.

380
IRUB88j Rubin, T., U!btn~eDesignjxComputer~, Haldstead Press (Wiley). 1988 [SHN90j Shneiderman, B., Deslgrufl8 the ~ IntJ:rface. Addison-wesley, 3a. ed. 1990.

[T1D99] Tidwell, 1-. Common Ground A Pattern Language for He! Design", disponible rfI http://wwwmitedu/@jhdwelllinteraaion.,.pattems.hlmi. mayo de 1999. [Tl002] Tidwell, J . "IU Patterns and Techniques". dlspombJe en http://time,trippercom/UlP'iterns/index hlml, mayo de 2002. IUN103] Unicode inc ., The Unicode Home Page. 2003, disponible en http://www.unicode org, IW3COJI World Wide Web Consonium, Web COtI~1 Accesablh{y Guidelines, 2003, disponibJe http://www. w3.orgITRll00JlWord-WCAGlD-200J0624/. [WELDI] vanwelle M . "Interaction Design Patterns"', dlsponible en http://wwwweliecom /
terns/ , 200 I

PROILIM.' X rpHIOI A COMSlP"I,

12.1. Describir Ja meJor Y la peoT interfaz con que se haya lrabajado alguna vez y cntiqUC'IIR
en relaci6n con los conceptos presentados ~n 12.3. Dcsarrollar dos principi os de disefio del usuari08
esl~

capllulo.
8d~n ~I

12.2. Desarrollar dos pnncipios de disefio adiciona1es qu~

adicional~$

control al usuario"

que "reduzcan la carga en la memcw<

~Iogr~n

12.4. Desarrollar dos pnnclplOs d~ diseno adicionates qu~

una interfaz conSiSlenk

12.5. se ha pedido desarrotlar un sistema de banco ~n c.asa para Web; desarrottar los model del usuano. del dlSdio y mental y la Implementaci6n 12.6. Reahzar un anahslS detallado de tareas para el sistema del problema 12 ,5, Ulihz.at enfoque eiaboratlvo u orientado a objetos 12.7. Agregar por 10 menos CincO preguntas adicionales a la lista desarrollada para el ane. de contenido de Ia secci6n 12.3.5

12.8. Siguiendo con el problema 12.6, delinir objelos y acciones de interfaz para la aphcacuJ ldentific.ar cada tipo de objetos
12.9. Desarrollar un conjunla de formatos de pantalla con una definici6n de elementos pales y secundanos del menu para eI sistema del problema 12.5

prm....

12.10. Desarrollar un canjunlo de formalos de pantalla con una definici6n de los elemenl pnneipales y secundaJios del menU para eI sistema~. Es po:sible aplicar un enfoque rente del que se muestra para el formato de pantalLa en La figura 15.3. 12. 11 . Descnhlr un enfoque proplO de las funaones de ayuda del usuario para el analLSb tareas que se hayan realizado como parte del problema 12.5 12.12. Proporcionar algunos ejemplos que iluslren por qu~ debe tomarse en cuenta la v.. hilidad del tiempo d~ respuesta 12.13. Desarrol1ar un enfoque que integre automaticamente los mensajes de error y funci6n de ayuda para el usuario. Es door, que el sistema reconozca automaticamente el de error y proporcione una ventana de ayuda con sugerencias para corregirlo. Realizar un dI.flo de sonware razonablemente completo que tome en cuema las estructuras de datos y los goritmos apropiados 12.14. Desarrollar un cuestionario de evaluaci6n de interfaces que conlenga 20 pregu gentricas aphcabJes a la mayor parte de las interfaces. I'fdase que 10 companeros de completen el clJesHonario para un sistema InleractJ.vo que tados usen Resumir los resultadr. infonnar de elias a su c1ase.

OIRAS LECTPR'S X [UENIES DE INFQRMACI6N

Aunque su \ibro no se relaciona espedlicamente con interfaces ser humano-computadora, cho de 10 que Donald Nonnan (The DesIgn afEVeryday ThIngs. edici6n reimpresa , Currencyl

CAPiTuLo 12

OISENO Of: LA INTlJ!FAZ Of: USUAaK)

la '

bleday. 1990) tiene que decir 500re ta psicologia de un diseiio efectivo se aplicara a las interfaces de usuario_ Es una lectura recomendada para cualquier persona que tome con seriedad el disefio de interfaces de alta caUdad Las interfaces grMlcas del usuario son ubicuas en el mundo mOOemo de la computaci6n Va sea empleada por un caJero automatico. un telerono m6vil, una PDA, un sitio web 0 una aplicaci6n de negocios, la interfaz de usuario proporciona una ventana al software. Por ella, abundan los libros sabre eJ dise~o de interfaces. TOOos los siguientes libros tratan sobre facilldad de uso, conceptos de interfaz de usuario, principios y u~cnlcas de diseM, adelJ1as de que conllenen muchos ejemplos utiles Galitz (Tik! <;sentiai Guide 10 User Inlerface Design, Wiley, 2002), Cooper tAbout Face 2.0: The Essentials oj User Interface lksign, lOG Books, 2003), Beyer y Holtzblatt (ConlexluallXslgn A Costumer Centered Approach 10 SYSfems Design. Morgan-Kaurmann, 2002), Raskin (The Human Interface, Addison-wesley. 2000). Constantine y Lockwood (So)hvore for Use. ACM Press. 1999) y Mayhew (The Usability ngi~ring Uftcyck. Morgan-Kaufmaon, 19991 Johnson (GUI Bloopers Don'ts and Do's jar so)hvore ~/oper.i and web De;igners, Morgan Kaufmann, 2000) proporciona una guia titil para quienes aprenden mejor al exammar cant raejemplos Un libra que se disfruta, de Cooper (The Inmates..-\r"e Running the Asylum. Sams Publishing, 1999), analiza por que los productos de alta tecnologla nos atraen y la manera de disel'lar unos que no 10 hagan EI analisis y mOOeJado de tareas son actividades fundamentales del disefio de interfaces. Hackos y Redish IHAC98] han escrito un libro dedicado a estos temas y proporcionan un metodo detaJlado para cancentrarse en el analisis de tareas. wood (User Inlerface Design Bridgmg the Gap from User Requi~ents to Design, eRC Press, 1997) aborda la aclividad de analisis para interfaces y la translcl6n a las tareas de diseiio. La actividad de evaluaci6n se concentra en la racilidad de uso. Los libros de Rubin (Handbook ojusablllty "R!sllrlg; How 10 f'fan, Deslgn. and Conduct EjJective Tests, Wiley, 1994) y Nielsen (Usability Inspection Methods, Wiley, 1994) abordan el lema can gran detal1e. En un libro unico, que podria parecer muy interesante a los disefiadores de producta. MUrphy (Front Panel. Designing SOJf-w<1rr: jor Embedded user Interfaces, R&D Books, (998) ofrece una SUla detal1ada para el disefia de interfaces deslinadas a sistemas incrustados y abOrda los peligros de scguridad mherentes a los contro!es, el manejo de maquinaria pesada y las interfaces para sistemas medicos a de Iransporte. El diseno de la Interfaz para productos incruslados tamblen se estudia en el Iibro de Garrett (Advanced {nSlrumenration and Computer (/o Design Real Time ~Iem Compuler Inlet/ace Engineering, IEEE. 1994) En Internet se encuenlra una amplia variedad de Fuentes de inrormaci6n sobre el disefia de la interfaz de usuario Una lista actuaJizada de rererencias en la World Wide Web relevantes pa ra el disefio de la interfaz de usuario se encuentra en el silio Web SEPA http://www.mhhe.com / pressman.

CAPiTULO

13
CONCEPTOS

ESTRATEGIAS DE PRUEBA DEL SOFTWARE

na estrategia de prueha del software integra los metodos de disei'lo caso de pruebas del software en una serie bien planeada de pasos que desemhocara en la eficaz conslrucci6n de software. La eslrategia propc"' dona un mapa que describe los pasos que se daran como parte de la pruebii indica cuando se planean y cuando se dan estos pasos, ademas de cuanto es-

........
CLAVE
~

fiaallQci6I lI9

...........
.stnllegia

. 409

lit prtfta ....401

tOII'ttIIdoIItII ,3&6

fuerzo. tiempo y recursos consumiran. Por tanto, cualquier estrategia de prueh. debe incorporar la planeaci6n de pruebas, e\ disei'lO de caso de pruebas, la eJo. cuci6n de pruebas y la recolecci6n y evaluaci6n de los datos resultantes.
Una estralegia de prueba del software debe ser 10 suficienlemente flex como para prom over un enfoque personalizado. AI mismo tiempo, debe ser adecuadamente rigido como para promover una planeaci6n razonable y seguimiento administrativo del avance del proyecto. Shooman (SHOS31 analir. estos temas: En muchas seJltldos. la prueba es un proceso aut6nomo, y el numero de tipos diferentes de pruebas varia tanto como los diferentes enfoques de desarrollo. Durante muchos ailes, 1a (mica defensa comra los errores de programaci6n fueron el disefio culdadoso y la inleligenda natural del programador. Ahora estamos en la era en q~ las tecnicas modemas de diseilo [y las revisiones de las tecnkas fonnalesl nos estan ayudando a reducir el mlmero de errores iniciales inherentes al c6digo. De manera similar, diferenles metodos de prueba estan empezando a apilarse en varios met()(iQ" y filosofJas distinlos. Estos "enfoques y filosofias" confonnan 10 que se denomina estrategia. Er capitulo 14 se presentara la tecnologia de prueba del software. Ese capitulo concentrara en la estrategia de la prueba del software.

........ ......
.~Ias

ttlJllt.

.....02

GIP ........ .316

... '-0 ......399

,...

illtgr1Ki611 .394

....... .......

..

rf9l"'.. .391

........

1IIiIW ...... 392

vaIidociiMI 404

s1sl.1111 406 ,,_, alhal MIfI 40S V.,V .l&4

.........

Laue . ? EI $Oftware $e pruabo para descubrir rores cometidos sin done cuenla 01 reoiizor !oU diseno y construcciOn. iPero c6mo $e rea izon los pruebo$~ iDebe desarrollorse un plon formal poro los pruebos? iDebe probarse eI programo como un lode 0 s610 deben opIicorse pruebas a uno parte pequeiio 2 iDeben voIver o reolizarse los pruebas ejecutodos a mediclo que :Ie agregon nuevas componente! a un sistemo

ticipoci6n del diente~ ~$IO$ Ymuchas otros preguntos se responderon cuondo desarrolle uno esImlegio

de pruebo del ",!two",.

LQu. . 10 hoc.? EI jefe de proyecto, los ingenieros de software 0 las especiolistos en pruebo:s son quienei desorrollon 10 estralegio para 10

pruebo del ",!two",. c.Por que e. importante? Con frecuendo,

de gran kimono? iCucindo debe pedir$8 10 par-

pruebo reqoier-e uno mayor contided del esfver. zo dec!icodo 01 proyecto que cuolquier olro acti vidod de ingenierio del software. Si se realize

383

....... 100 ....... dobon ~ y <ON>_ . ,..... odo ... P""'"'" IIamodo dopu""i6n.

01 ........ ""'-- .10 povobco 01 de""''-~;:. '" uno eoio'aiogia _ , ".. 100 palO< ...,..

~ao.1oo povobco ~ eI onfoque q...

_........u_

.taISJdct., Uno Especi

Ia Especi idauela 1e.wJ

"";sar

.............
Ioo_do do povobco

que habnln

dol
.. coda

La prueba es un con)unto de actividades que se planean con anticipaci6n y se reali -

zan de manera sistematica. Por tanto, se debe definit una plantilla para las pruebas del software (un canjunto de pasas en que se puedan induit tecnicas y metodos
espedficos del diseno de casos de prueba) , Se han propuesto varias estrategias de prueba del software en distintos libros; todas proporcionan a1 desarrollador del software una piantilla para pruebas y todas tienen las siguientes caracterlsticas genericas Para realizar pruebas efectivas un equipo de software debe erectuar revisiones lecnicas formales y efectivas (capitulo 26). Esto eliminara muchas errores antes de que empieee la prueba.
La prueba eomienza al nive! de eomponentes y trabaja "hacia fuera ", hacia la

integraci6n de todo el sistema de e6mputo. Diferentes tecnicas de prueba son apropiadas en diferentes momentos.
La prueba la dirige el desarroJlador del software y (en el easo de proyeetos

grandes) un grupo independiente de pruebas

La prueba y \a depuraci6n son aetividades diferentes, pero la segunda debe

incluirse en eualquier estralegia de prueba Una estrategia para la prueba del software debe incluir pruebas de bajo nivel (neee sarias para eonfirmar Ja eorrecta implementaci6n de un pequeno segmento de e6di go fuente) y de alto nivel (que validen las principales funciones del sistema a partir

de los requisitos del dientel. Una estrategia debe servir como gula para el p nal y fijar un conjunto de gulas para el Jere de proyecto. Debido a que los pasoI la estrategia de prueba son simult.i.neos, cuando empieza a aumentar la presi6l' las rechas limite debe tenerse la opci6n de medir los avances y busear que los blemas aparezcan 10 antes posible.

13.1.1 VerWcacton y validadon

La prueba del software es un elemento de un lema mas amplio que suele deP narse verificaci6n y validaci6n (VyV). Verificadon es el conjunlo de actividades aseguran que el software implemente COrrectamente una runci6n esped. Validad6n es un conjunlo diferente de actividades que aseguran que el soft" construido corresponde con los requisitos del cliente. I Boehm [BOE811 10 estat de otra manera:

Verificaci6n: "(Estamos construyendo el producto correctamente?" Validacl6n: ~ (Stamos construyendo el producto correcto?"
La definlci6n de VyV abarca muchas de las actividades incluidas en el asegu

, . SM tIIO~!etl

. ...., .. .....
_
~,..,.,.

NostdebM rener desa.WIos ri cMSidn tpI ,bs

to de la calidad del software y se analiza de manera detallada en el capitulo ~ La verificaci6n y la vaJidaci6n abarcan una amplia Usia de actividades de ramienlo de 1a calidad del software: revisiones tecnicas fonnaies, auditorias de dad y de configuraci6n, moniloreo del desempeno, simulaci6n, factibilidad, In' de la documentaci6n y la base de datos, analisis de algoritmos, pruebas de de",,': 110, de (acilidad de uso, calificaci6n y de instalacl6n [WAL891. Aunque las aCl;""..... de prueba Ilenen un papel demasiado importante en VyV, lambien se n muchas olras actividades.

.... los

_a'''_dfI

..... mlo ... _

......... .....".___ ............. _ . - . .

~--.

._dfI
sdtwot.

soirwrn. 1M /a SM. o.bI {XX"'" ,..aaI cviOOdo M 10 C!tiId r dtOOi6n de ImUS

las pruebas son el ultimo basti6n para la evaluaci6n de la caUdad y, de mas pragmalica, el descubrimiento de errores. Pero las pruebas no deben c rarse como una ~red de seguridad". Como suele decirse: "No es posible probar Ia

mo.'"

",1rJdD"~de

dad. 51 no esta ahf antes de que empiece la prueba. no estara cuando se Ie La calidad se incorpora al software en lodo el proceso de ingenieria. La apliC&. apropiada de metodos y herramientas. las revislones lecnicas (onnales y efect.

I Debe indka~ que hay una fuerte divergenda de OPIni6n acerca de los tipos de prueba que tuyen una "Validaci6n- AJgunas personas creen que toda prueba es una verificacl6n, y que: II daci6n se realiza cuando eI usuario revisa yaprueba los requisitos, y mas delante, cuando el esla en condiciones de operar otras personas consideran que la prueba de la unidad y la ci6n (secciOnes 13.3.1 y 13.3.2) constiluyen la verillcaci6n y que las pruebas de alto nlvell lias mas adt:1ante en este capItulo) son 1a valldacl6n

CAPiTuLo 13 ESmATEGlAS DE PRIJEIlA m. 50FTWARE

38.

junto con una administraci6n y una medici6n s6lidas aportan la calidad, que se confirma durante las pruebas. Miller [M!L77] re!aciona la prueba del software con el aseguramiento de la calidad al afirmar: "10 que motiva la prueba de los programas es la confirmaci6n de la caUdad del software con metodos que se puedan aplicar de manera econ6mica y efectiva en sistemas grandes y pequenos".

13.1.2 Orgcm1zac1on para las pruebas del software

En cualquier proyecto de software se presenta un confliclo de intereses cuando comienzan las pruebas. Ahara se pide a las personas que han construido el software que 10 prueben. En sl, esto parece inofensivo; despues de todo, ,quien conace mejor un programa que la persona que 10 desarro1l6? Por desgracia, a esos mismos desarrolladores les interesa mucho demostrar que el programa esta libre de errores, que funciona de acuerdo con los requisitos del cliente y que se completara a tiempo y sin rebasar el presupuesto. Cada uno de estos intereses mina las bondades de la prueba.

"8 upIii~i~ i~~ peligro owpadona/ cit 10 prograrnociOn; Ia pru~, eI trotarniento.

''I

Desde un punto de vista psicol6gico, el analisis y el diseno del software ijunto can la codificaci6n) son tareas constructivas. EI ingeniero del software analiza, modela y luego crea un programa de computadora, junto con su documentaci6n. Como cualquier constructor, el ingeniero del software se sentira orgulloso del edificio que acaba de construir y mirara con recelo a cualquiera que pretenda echarlo abajo. Cuando comienza la prueba hay un intento sutil, pero definitivo, de "romper" 10 que ha construido el ingeniero del software. AI ponerse en los zapatos del constructor la prueba parecera (psicoI6gicamente) destructiva. De modo que el constructor actuara con cuidado, disenando y ejecutando pruebas que demostraran el buen funcionamiento del programa en lugar de descubrir errores. Por desgracia, los errores segui ran presentes. Y si el ingeniero del software no los encuentra, jel cliente sf 10 han!!! De las consideraciones precedentes suelen inferirse err6neamente varias maias interpretaciones: I) que el responsable del desarrollo no deberia participar en el proceso de prueba, 2) que el software debe ponerse a salvo de extra nos que 10 prueben sin misericordia, y.3) que quienes aplican las pruebas s610 deben participar en el proyecto cuando vayan a darse los primeros pasos de esas pruebas. Todas estas afirmaciones son incorrectas. EI desarrollador del software siempre sera e\ responsable de probar las unidades individuales (componentes) del programa y asegurar que cada una realice la funci6n o muestre el comportamiento para el que se di.seM. En muchos casos, el desarroHador tambien aplica la prueba de integraci6n (un paso que lieva a la construcci6n, y la prueba, de toda la arquitectura del software) . 5610 despues de que la arquitectura del software este completa participara un grupo independiente de prueba.

fr.M_.
51 III UlSllIII GlP dMfIOdelQ)
1PI~~511

386

EI papel de un grupo mdt:pendiClle de pruetJO (GIP) consisl e en eliminar los blemas propios de deJar que el constructor pruebe 10 que

-,,-..

el mismo

ha constrww.

La prueba independiente elimina el canmeta de intereses que, de otra manera ,

ria presente. Despues de todo, al personal del GIP se Ie paga para que encu errores.
Sin embargo, el ingeniero del software no debe simplemente entregar el p rna a1 GIP y alejarse. EI desarrollador y el GIP deben trabajar unidos en todo el

fUlID de ~ ,..0.
Nq>b''''''~ dtbe IIDfIr 118 dISI1tM

yecto de software para asegurar la realizaci6n de pruebas exhaustivas. Mi

estas se realizan, eJ desarrollador debe estar disponible para corregl r los errores

se descubran.

[ ::w"~"""""""~""'''~_''''~'''''''''do'''''~=-~
EI GIP es parte del equipo del proyecto de desarrollo del software, ya que par'" pa en el analisis y diseno y ademas sigue partkipando (al planear y especificar cedimientos de prueba) en todos los pasos de un proyecto grande. 5in embargco muchos casos el GIP informa a la organizad6n de aseguramiento de caUdad deJ ware, por 10 que obtiene un grado de independencia que seria imposible si parte de la organizaci6n encargada de la ingenieria del software.

13.1.3. Estrateg1a de prueba para arquitecturas convenc1onales del software

Seria factible considerar que el proceso de ingenieria del software es equiparabl la espiral que se ilustra en la figura 13. 1. AI principio, la ingenieria del sistema ne el papel del software y lIeva al analisis de los requisitos de este, donde se blecen el dominio de informaci6n, la funci6n, el comportamiento, el desempem restricdones y los criterios de validaci6n del software. Al desplazarse hacia el rior de la espiral se lIega al disefio y, por ultimo, a la codificaci6n . EI desarr software de computadora requiere recorrer la espiral hacia dentro, a 1 0 largo de linea bien definida que disminuye el grado de abstracci6n tras cada vuelta.
i.CtiI" III

Tambien es posible ver una estral egia para la prueba del software en el con de la espiral (figura 13. \) . La prueba de unidad comienza en el vertice de la e se concentra en cada unidad (componente) del software, tal como se implemen el clx1igo fuente. La prueba avanza al desplazarse hacia fuera, a 1 0 largo de ]a ral, hasta lIegar a la proeba de integmd6n. donde se atiende e[ diseno y la co ci6n de la arquitectura del software. 5i se recorre etra vuelta hada fuera en la ral, se encuentra la proeba de valldaci6n. donde se validan los requisitos establ como parte del analisis de requisitos del software, comparandolos con el so que se ha construido Por ultimo, .se nega a la proeba del sistema, donde se p como un todo el software y otros elementos del sistema. El software de com ra se prueba recorriendo la espiral hada fuera, por una linea bien definida, de mar'I que en cada vuelta se ensancha el aJcance de la prueba.

........., .......

tstrolegil

1'..,81 pen 10

38'
Si

se considera el proceso desde un punto de vista procedimental, en reaUdad la

prueba dentro del contexto de la ingenieria del software consiste en una serie de
cualro pasos que se implementan de manera secuencial. E50S pasos se muestran en

la figura 13.2. Al principia. la prueba se concentra en cada componente individual,

asegurando que funciona de manera apTopiada como unidad (por ella se Ie denomina prueba de unidad). La prueba de unidad emplea en forma recurrente las teenicas de prueba que recorren caminos especlficos en una estructura de conlrol del com-

ponente, 10 que asegura una cobertura completa y una detecci6n maxima de errores. Enseguida deben ensamblarse 0 integrarse los componentes para (annaT el
paquete de software completo. La prueba de integraci6n atiende todos [os aspectos asociados con el doble problema de verificad6n y construcci6n del programa. Las tecnicas de disei'io de casos de prueba que se concenlran en entradas y salidas son

ruebo del

!i~lema

Prueba de unidod

Disefio Requiiitos Ingenlerio e mlemo

Requbito!

DiHlno

Pruebos de alto nivel

Prvebo de inlegrodOn

"Direccionde 10 pruebo

Codi go

/r

TI"::::,,,n

n n

mas dominantes durante la integrad6n. aunque podrian usarse tecnicas que rec.
rren rutas especificas del programa para asegurar la cobertura de los princi

earninos de control . Despues de que se ha integrado (construido) e\ software se ca un conjunto de pruebas de alto nivei Se deben evaluar los criterios de validaci
establecidos durante el anAlisis de requisitos. La prueba de validaci6n propo un aseguramiento final de que el software cumple con todos los requisitos nales, de comportamiento y desempeno. El ultimo paso de 1a prueba de alto nivel queda fuera de los Umites de 1a inge. ria del software, pera deniro de un contexto mas amplio de la ingenieria de los temas de c6mputo. EI software, una vez vaJidado. debe combinarse con otl'05 mentos del sistema (por ejemplo, hardware, personas, bases de datos). La pruei

ru.nc..

sistema verifica que todos los elementos encajen apropiadamente y que se Iogft" funci6n y el desempeno generales del sistema.

13.1.4 strategia de prueba del software para arquitecturas

orientadas a obJetos

(~,m

C~VE ... ., ......

La prueba de sistemas orientados a objetos planlea un conjunlo diferente de al ingeniero del software. La definici6n de prueba debe ampliarse para incluir cas de descubrimiento de errores (por ejemplo, revisiones tecnicas formales) aplican para analizar y disenar modelos. El grado al que se han completado y La sistencia de las representaciones orientadas a objetos deben evaluarse a medidl
se construyen. La prueba de unida<! pierde parte de su significado, y las est de integracion cambian de manera importante. En resumen, las estrategias y las ticas de prueba (capitulo 14) deben ser responsables de las caracteristicas unkB. software orientado a objetos. La estrategia general para el software orientado a objetos Ilene una filosona tica a la que se aplica a las arquitecturas convencionales, pero presenta dife en el enfoque. Se empieza ~probando 10 pequer\o~ y se trabaja hacia el exterior bando 10 grande- Sin embargo. la atend6n cambia ruando la prueba es pequei' un m6dulo individual (el concepto convencional) a una clase que abarca atri operaciones y que, ademas, requiere comunicaci6n y colaboraci6n. A medida

UlIIltodas D~
em;ielOO In' 10 ' '''''''.50 emoorgo,!IIl cosi todas los tDSOi, eI elemeGlo

""',...., .....
es LIllI OM 0 III
~" de duse5 qJe colobcm! Mire si.

HOGARSEGURO

I'ftpdnIc/i>n para la prueba

. . I I EI _ Oficino

de Doug
Doug: Me ~ """ no].....,. ~I' " " ' - . hobIo< de ... . . - .

........... CII:IftMUa -' di-'o 01 nn..l d.

II 'I . . . ,....,.., 10 contINcci6n de (ier1Ql

.\

.....

..

.............. _.Ed,ShoIo~.

1_ Oaug MiIIr,

jefe de i"9"lreOo del

. . . . .'. "kicW~de~.

_dol

"'........

VIIMCI:

r_ raz6n, pMI . . . . . . . . . . . . . . . . . oloieodo:A. Y odem05 '-,.....-..... ..

....idod. ' - - hodoo _ ... . . -

CAPiTuLo 13

I'S!RATEG!AS DE PllUEBA DEI.. SOF'IWARE

389

Jam..: Yo he 8$Iodo hacienda 10 mismo.

Vinod: Y he klmodo eI popel de tn~ de modo que coda vez que uno de los muchachoI me pate un componenle, 10 integrare y ~ una.no de pruobcn de regre5i60 en eI progRlMO porcio/rnenIe

;doa

do <Ii""", pruoba. do codtficor cualquiero de los no C!$ !o que hemos trotodo orchivo de prvebos que IKI6 compIeto eI c6dig(! de

integroda. He ask:Ido ~ pam diMIIor un con junlo de ~ gprcpiodo pmo c:gcfa Ivnci6n dell
sistema. Doug ,_ V .....~
las pruebosl

,eon """'" _ _

.. ~ no eafamolusondo, en $I, kI ~ que ..,.10 lKIO bueno de ~ ontM de COIls/nlir el _ do kIdo 10 infonnod60 que

Vlnod: Toda$ \0$ dfCl$ . ho$/o que $0 ~ biM eI sislemo. 0 $eO, heslo que /0$ inc.-.menkls d. taItwor-. CfJe pIoneomos enlregor" queden i"lIgIodos.

Doug: lMuchochal, von adebtte de "'" Vinod (~: I.a onticipoci6n 10 toGo en. negocio del ~ftwo,.., jft.

integran clases dentro de una arquitectura orientada a objetos, se ejecuta una serie de pruebas de regresi6n para descubrir errores debidos a la comunicaci6n y colaboraci6n entre clases (componentes) y a los efectos colaterales que origina la adici6n de nuevas clases (componentes). Por ultimo, se prueba el sistema como un todo para asegurarse de que se descubran errores en los requisitos.

13.1.5 Crttertos para completar la prueba

Cada vez que se analizan las pruebas del software surge una pregunta clasica: icuim do hemos terminado las pruebas (c6mo sabemos que hemos probado 10 suficiente)? La lamentable es que no hay una respuesta definitiva, sino que hay algunas respuestas pragmaticas y algunos intentos iniciaies de sentar una gufa empfrica. 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, 0 ambos, ejecutan un programa de computadora, este se esta probando. Este hecho incuestionable subraya la importancia de otras actividades del aseguramiento de la calidad del software. Otra respuesta (un poco clnica, pero carrecta) es: "la prueba se lermina cuando se agota el tiempo 0 el dinero". Aunque algunos usaran esta respuesta como argumento, un ingeniero del software necesita criterios mas ngurosos para determinar que las pruebas han sido sufidentes. Musa y Ackerman IMUS89] sugieren una respuesta basada en criterios estadisticos: "No, no podemos eslar completamente seguros de que el software nunca faHara, pero de acuerdo con un modele estadistico te6ricamente s61ido 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

CPU Jibres de fallas en un entomo definido de forma probabilistica es por 10 rneD' de 0.995." Ernpleando el modelado estadistico y 1a teona de la confiabilidad del ware, pueden desarrollarse modelos de fallas del software (descubiertas durante

prueba) como una funci6n del tiempo de ejecuci6n (por ejemplo, con
[MU589], [SIN99] 0 [tEEOl)) .

Al recopilar rnetricas durante la prueba del software y usar modelos existentes

Ja confiabilidad del software, es posible desarrollar directrices signiftcativas para

ponder la pregunta: lCuando hemos terrninado la prueba? Lo indisculible es que falta mucha trabaja antes de que puedan establecerse reglas cuantitativas pan!
prueba, pero los enfoques empiricos existentes son considerablemente mejores la simple intuidan.

Mas adelante, en este mismo capitulo, se explorara una estrategia sistematica prueba del software. Pera hasta la mejor estrategia fallara si no atiende una serk: aspectos predominantes. Tom Gilb IGIL9S) argumenta que deben atenderse los tes tern as, si se desea irnplementar con exito una estrategia de prueba del SOfiwaR

,Clilles
diredfkH
lIt'lal a I IMI

Espcciftcor los requisitos del producto de monera cuantijicoble mucho antes de empiecen las proebas. Aunque el objetivo primordial de la prueba es encontrar

estrotegia de pnoobo dol

sohwar. q..
t. aga Ixllo?

res, una buena estrategia de prueba tambien evalua otras caracteristicas de Ia dad, como las opciones de lIevaria a Olra plataforma, ademas de la facilidad de tenimiento y uso (capitulo \5). Esto debe especificarse de manera tal que "",.,. medirlo para que los resultados de la prueba no resulten ambiguos.
Establecer explicitomente los objetivos de la prueba. Los abjetivos especificos

prueba se deben establecer en terminos cuantificables. Por ejemplo, dentro del de prueba deben establecerse la efectividad y la cobertura de la prueba, el media de falla, el costo de encanlrar y corregir defeclos, la densidad 0 la de las fallas restantes, y las horas de trabaja por prueba de regresi6n [GIL9S!

[,ecuo,.,_

Con;prender cwiles son los usuarios del software y desarro/Jar un perfil para categoria de usuario. Los casos de uso que describan el escenario de i,,te,eacci6n'_

cada clase de usuario reducen el esfuerza general de prueba, ya que concen prueba en la utilizaci6n real del producta.
Desarrollor un plan de prueba que destoque Ja "prueba de cicio rapido~. Gilb

recomienda que un equipo de ingenieria del software "aprenda a probar en rapidos (296 del esfuerzo del prayectollos incrementos en el mejoramiento de 1a cionalidad, la calidad, a ambas, de manera que sean utiles para el cliente y dan probar en el campo". La retroalimentaci6n que generan estas pruebas de rapido se utiliza para controlar los grados de calidad y las eo'Te';pcmdi'te'; "'.... gias de prueba.

39'
Conslruir un software HrobustoW diseflado pora proborsc a sf mismo. EI software debe disenarse de manera tal que use tecnicas antierror (secd6n 13.3.1). Es decir, el SOn~ ware debe tener la capacidad de diagnosticar ciertas clases de errores. Ademtls, eJ diseno debe incluir pruebas automatizadas y de regresi6n.

Usaf revisiones lecnicas Jormales y eJectivas como filtro previa a 10 prueba Las rev!
siones tl:cnicas formales (capitulo 26) llegan a seT tan efectivas como las pruebas
para descubrir errores. Por tanto, las revislones reducen la cantidad de es(uerzo de prueba que se requiere para producir software de alta caUdad.

Rea/izar revlSJones lecnicas fonnales pora eva/uar 10 estrotegia de prueba y los pro-

pios cosos de proeba.

Las revisiones tecnieas formales posibilitan descubrir mconsis-

tendas, omisiones y errores evidentes en el enfoque de la prueba. Esto ahorra tiempo y lambien mejora la caUdad del produclo.

Desarrollor un enJoque de mejom continuo para el proceso de prueba.

Es necesario

medir la eSlralegia de prueba. Las medidas reunldas durante la prueba deben usarse como parte de un enfoque estadistico de control del proceso para la prueba del software .

.."... UniaInent.1os requilitos del U5Uorio filal ts tomO Insptaionat 00 ..000 :miderando iJflkOfI'ItCQ " IrIIIajo: realrodo p eI Wfiodor de iPteriar85, 0 costa de 10'1 dmieatos, los 't'igm y to plomtfio. ..... hb..

En la prueba del software es posible aplicar muchas eSl ralegias. En un extremo, un equipo de software podrla esperar hasta que el sistem a este totalmente construido y luego aplkar pruebas al sistema general esperando encontrar errores Este enfoque, aunque atractivo, simplemente no funciona. Arrojara un software plagado de errores. molesto para el dienle y usuario final En el otro extremo, un ingeniero de software podrla aplicar pruebas diariamente, sin imporlar la parte del sistema que se construya. Este enfoque. aunque menos alractivo para muchos, es muy efectivo. Par desgracia, la mayorla de los desarrolladores de software dudan en usarlo. ,Que 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 disenadas para facilitar la integraci6n de las unidades, y culmma con pruebas que realizan sobre el sistema construido. En las siguientes se<:ciones se expone cada una de estas clases de prueba.

392

PARTE DOS

~ DE LA

INGf:NlER!A De. SOFTWARE

13.3.1

Prueba de Wlidad

de unidad se con centra en el esfuerza de verificaci6n de la unidad rI\OI$ pequena del diseiio del sonware: el componente 0 m6dulo de software. Tomando
La prueba

como gula la descripci6n del disei'lo al nivel de componentes, se prueban importaltles caminos de control para descubrir errores denlro de los limites del m6dulo E! a!cance restringido que se ha deterrninado para las proebas de unidad limita la Telativa complejidad de las pruebas y los errores que estas descubren. Las pruebas de lim-

dad se concentran en la 16gica del procesamienta interne y en las estructuras de datDI denlro de los limites de un componente. Este tipo de prueba se puede aplicar ~
paraJeJo a varios componentes.

Consideraclones sobre la prueba de unidad. En la figura 13.3 se ilustran

manera esquematica las pruebas que se aplican como parte de la prueba de unidad. u. interfaz del m6dulo se prueba para asegurar que la infonnaci6n fluye apropiadameNt; 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 mantienen la irKgridad durante tados los pasos de la ejecuci6n de un algoritmo. Se recorren tados caminos independientes (caminos de base) en tada la estructura para asegurar todas las instrucciones de un m6dulo se hayan ejecutado por 10 menos una vez SiE prueban las condiciones limite para asegurar que el m6dulo opera ban todos los caminos de manejo de errores.
apropiada ~

en los limites establecidos para restringir el procesamiento. Y, par ultimo, se prur

Es necesario probar el flujo de datos en la interfaz del m6dulo antes de iniciir

_ftlfran

cualquier o tra prueba. Si los datos no entran ni salen apropiadamente, todas demas pruebas resullaran inutHes. Ademas, durante la prueba de unidad deben rea! rrerse las estructuras de datos locales y evaluarse (si es posible) eJ impacto I sobre los datos globaJes. Durante \a prueba de unidad, una tarea esencial es la prueba selectiva de las ru tas ejecuci6n. Se deben diseflar casas de prueba para descubrir errores debidos a Cel. incorrectos, comparaciones erroneas 0 flujos de control inapropiados. Entre los em::

tomuftmHte

ct.rHt,1a pAtH
0. .nidad?

Prueba d e unldad.

"""'"
_ _

E ............ do doIoo IocoIoo

~1INt

i"d.p."di _ de......." do....,..,

CAPInn.o 13

1SrnA!EG!AS DE PRUE8Ir.. 00. SOFTWARE

393

res mas eomunes en los calculos se encuentran los siguientes: I} aplicaci6n incorrecta 0 mal entendida de !a precedencia aritmetica, 2) operaciones de modo mezdadas, 3) inicializaci6n ineorrecta, 4) falta de precision, y 5) representaci6n simb6lica incorrecta de una expresion. La eomparacion y elflujo de control estan estrechamente acoplados entre Sl (es decir, eillujo cambia con frecuencia despues de una comparaci6n). Los casos de prueba deben descubrir errores como: 1) comparaciones entre diferentes tipos de datos, 2) operadores l6gieos 0 preeedencia de estos aplicados incorrectamente, 3) expectativa de igualdad cuando los errores de precision hacen que sea poco probable, 4) comparaci6n incorreeta de variables, 5) terminacion inapropiada 0 inexistente de budes, 6) falla en la salida euando se encuentra una iteraci6n divergente, y 7) variables de bude modificadas de manera inapropiada. La prueba de limites es una de las tareas mas importantes de la prueba de unidad. Con frecuencia, el software falla en sus limites. Es decir, a menudo los errores ocurren cuando se procesa el enesimo elemente de una matriz de n dimensiones, cuando se evoca la i-esima repetici6n de un bude con i pasas, cuando se encuentra el valor maximo 0 mlnimo permisible. Es muy probable descubrir errores en los casas de prueba que se ejercen sabre la estructura de datos, el flujo de control y los valores de datos ubicados apenas abajo de los maximos 0 minimos, sobre estos y apenas arriba de ellos. Un buen diseno impone que se prevean las condiciones de error y que se configuren rutas de manejo de errores para modificar la ruta 0 tenninar limpiamente el procesamiento cuando ocurra un error. Yourdon [yOU75jllama a este enfoque antieffOf. Por desgracia, existe la tendencia a incorporar el manejo de errores en el software y, can ello, a no probarlo nunea. Una historia real servira como ejemplo:
Un sistema de disefio asistido por computadora se desarro\l6 bajo contrato . En un modulo de procesamlento de transacCiones, un bromista practico puso el siguiente mensaje de manejo de errores desputs de una serie de pruebas condicionales que inllocaban lIarias ramas del flujo de control; iERROR! NO HAY FORMA DE QUE PUEDA LLEGAR HASTA AQUI. iE~te "mensaje de error" 10 descubri6 un cliente durante la capacitaci6n del usuario!

Entre los posibles errores que deben probarse cuando se ellalue el manejo de errores se encuentran los siguientes: \) la descripcion de! error es ininteligible, 2) el error indicado no corresponde al encontrado, 3) la condici6n de error causa 1a intervenci6n del sistema operativo antes de que se dispare el manejo de errores, 4) el procesamiento de la condici6n de excepd6n es ineorreeto, 5) la descripcion del error no proporciona informaci6n 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 codificad6n. El diseno de las pruebas de unidad puede realizarse antes de que empieee la codificaci6n (un enfoque agil que suele preferirse) a despues de que se ha generado el c6digo fuente. Una revisi6n de la infonnaci6n del

PARTE DOS

PRJ.cncA O LA ItGN!D!lA. DEl. SOF!WARE

Entornode prueba de unldad.

"-'-* ....

..... R_. __.....E .............. 1ocoIoo

l.-~_

,..., """".

"""' afticos ykls

"" """".

""........ ..,...,do_
t;W 110 Sf fM6m kls
",

reooos fKIO hoc.

fntoo:es dsben _.

{~III*,

ys6ldsos_

.......
t;W

disefio propordona una gula para establecer casos de prueba que prababl descubriran errores en cada una de las categarlas analizadas. cada caso de debe relacianarse can un canjunto de resultados esperados. Debido a que un componente no es un programa independiente, para cada ba de unidad se debe desarrollar sallware controJodor; de resguardo, a de tipos. En la ligura 13.4 se ilustra el entomo para la prueba de unidad. En casi las aplicacianes. un cantralador no es mAs que un "programa principal" que los datos del caso de prueba, pasa estos datos al componente (que habra de se) e imprime los resultados importantes. Los resguordos sirven para reemp. m6dulos subordinados al componente que habra de probarse (a \Iamados par Un resguardo 0 "subprograma simulado" usa la interfaz del m6dula subor realiza una minima manipulaci6n de datos, proporciona verificaci6n de la en devuelve el control al m6dulo de prueba. Control adores y resguardos representan una sobrecarga de trabajo. Es resulla necesario escribir ambos lipos de software (Sin que suela aplicarse WI 1'10 formal), pero no se entregan con el producto.de software final 5i se les ne en un nivel simple, la sabrecarga real es relativamente pequena Por d no es posible aplicar adecuadamente una prueba de unidad a muchos compen.. can un "Simple" software de sobrecarga. En muchos casas es posible po~ prueba completa hasta el paso de prueba de integraci6n (donde tambien se controladores a resguardos) La prueba de unidad se simplifica cuando se disena un componente c cohesion elevada. Cuando 5610 se atiende una funci6n de un componente. el ro de casos de prueba se reduce y es mas fadl predecir y corregir los errores

13.3.2 Prueba de integracion

Un ne6fito en el mundo del software podrla plantear una pregunta aparent iegitima, una vez que se haya aplicado una prueba de unidad a l odos los "5i todo funci ona bien individualmente, ipor que dudan que funcione cu

3 .'
une?H EI problema, por supuesto, (onsiste en "unit' (crear la interfaz). En una interfaz es posible perder datos, un m6dulo podrfa teneT un efecto adverso e inadvertido sobre otro, la combinaci6n de subfunciones tal vez no produzca la funci6n principal deseada, la impreclsi6n aceplable en elementos individuales podria ampliarse hasta grados inaceptables y las estructuras globales de datos podrian presentar problemas . Es triste, pero la lisla sigue y sigue.
La prucba de integraci6n

es una tecnica sistematica para construir la arquitectu-

fa 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 aplic6 una prueba de unidad y construir una estruClura de programa que determine
el diseno A menudo se tiende a intentar una integraci6n que no sea incremental , es decir, a construir el programa mediante un enfoque de "big bang". Se combinan todos los componentes por antidpado. se prueba todo el programa como un todo. jY se produce el caos! Se encuentra una gran cantidad de errores. La correcci6n es difkiJ, porque resulta complicado aislar las causas debido a la extensi6n del programa completo. Una vez corregidos esos errores, aparecen otros nuevos y el proceso continua en un cicio que parece interminable.
La inlegroci6n incremental es la antitesis del enfoque del "big bang" EI programa

se construye y prueba en pequenos incrementos, en los cuales resulta mas facil aislar y corregir los errores, es mas probable que se prueben por completo las interfaces y se vuelve factible la aplicaci6n de un enfoque de prueba sistematica. En los siguientes parrafos se expondritn varias eSlrategias diferentes de integraci6n incremental. Integrad6n descendente.

La prueba de inlcgraci6n descendence es un enfoque incremental para la construcci6n de la arquitectura del software. Los m6dulos se
trol principal (programa principal) . Los m6dulos subordinados al m6dulo de control principal se incorporan en ia estructura de una de dos maneras: primero-en -profun didad 0 primero-en-anchura. Tomando como referencia la figura 13.5, 10 integraci6n primero -en proJundidad

integran al descender por la jerarquia de control. empezando con el m6dulo de con-

integra todos los m6dulos de una ruta de cOntrol principal de la estructura del programa. La selecci6n de una ruta principal es un poco arbitraria y depende de las caracteristicas especificas de la aplicaci6n_ Por ejemplo, Sl se elige el camino de la izquierda, se integrarfan primero los m6dulos M,. Ml Y Ms. A conlinuaci6n, se integraria Ma 0 (si es necesario para el adecuado funcionamiento de M1 ) M~ Enseguida se construyen las rutas de control central y a 1a derecha La integraci6n pnmero-cn
anchuro incorpora lodos los componentes directamente subordi nados en cada nivel,

desplazandose horizonlaimente por la estructura En el caso de ia figura, se integrarian primero los componentes M l , M} Y M. Y les seguirian M~, M 6, etc. EI proceso de integraci6n se realiza en una serie de cinco pasos

396

PARTE DOS

PRAcnc:A DE LA INGmIERfA DEL SOFTWARE

I
Int&gIac16n

M,

clescendente.

..,
/
M,

--- -- -M3

--

_"::I..- _ _ ..,

~
M,

[-~-l

I I I

Me

,(lilieS SOlI

I. El m6dulo de control principal se utiliza como controlador de prueba, y se

los pam de Ja iltegrodOl descendenl.?

sustituyen los resguardos en tod05 los componentes directamente subordiM

dos al m6dulo de control principal.
2. Dependiendo del enroque de integraci6n seleccionado (es dec!r, primero--enprorundidad
0

primero-en-anchura) se van reemplazando los resguardos sa-

bordinados, uno por uno, con los componentes reales. 3. Se aplican pruebas cada que se integra un nuevo m6<lulo.

4. Al completar cada conjunto de pruebas. se reemplaza otro resguardo con d m6dulo real.
5. Se aplica la prueba de regresi6n (que se analiza mas ade[ante, en esta misml secci6n) para asegurarse de que no se han introducido nuevos errores.

EI procesQ continua a partir del paso 2 hasta la construcci6n total de la estruc:tml del programa. La estrategia de integraci6n descendente verlfica los principales puntos de trol a decisi6n al principia del proceso de prueba. En una estructura de prog bien elaborada , la toma de decisiones ocurre en los niveles superiores de la jera y, par tanto, se encuentran primero. Si existen problemas de control importan&a resulta esencial reconocerlos desde el principio. Si se selecciona la integraci6n mero-en-profundidad, es posible implementar y demostrar una funci6n completa software. Por ejemplo, imaginese una estructura de transacci6n clasica (capitulo en que una serie compleja de entradas interactivas se solicila, adquiere y valida medio de una ruta de entrada. Tal vez ese camino este integrado en forma desccs dente. Todo el procesamiento de entrada {para el envto de las siguientes transaca.

CAPiTULO 13 ~DEPRlJEBA.DEl.SOFTWAJIE

397

nes) podria demostrarse antes de que alros elementos de la estructura se hayan integrade. La demostraci6n temprana de Ja capacidad funcional genera confianza en el desarrollador y en el cliente.
La

estrategia descendente no parece muy complicada, perc en Ja practica llegan

. . . . . .'.. 'lIal

Ia Int. -

a surgir problemas de logistica. EI mas comun se presenta cuando se requiere procesamiento en los niveJes inferiores de la jerarquia para probar de manera adecuada los niveles superiores. Al principia de la prueba descendente se reemplazan los m6dulos de bajo nivel con resguardos; por tanto, no nuiran datos importantes hacia \a parte superior de Ja estructura del programa. Quien aplica la prueba cuenta con tres opciones: 1) retrasar muchas de las pruebas hasta que los resguardos sean reemplazados can los m6dulos reales, 2) desarrollar resguardos que realicen funciones limitadas que simulen los m6dulos reales, a 3) integrar el software de la parte inferior de la jerarqu[a hacia arriba. EI primer enfoque (retrasar las pruebas hasta no reemplazar los resguardos can los m6dulos reales) hace perder cierto control sobre la correspondencia entre pruebas especificas y Ja incorporaci6n de m6dulos espedficos. Can esto se dificulta determinar la causa de los errores y se tiende a vioiar la naturaleza altamente restringida del enfoque descendente. Es posible trabajar con el segundo enfoque, pero puede Ilevar a un aumento importante de la sobrecarga de trabajo, a medida que los resguardos se vuelvan mas y mas complejos. EI tercer enfoque, denominado prueba ascendente, se expondra en la siguiente secci6n. Integracl6n ascendente. La prueba de integraci6n ascendente, como su nombre 10 indica, empieza la construcci6n y la prueba can m6dulos at6micos (es decir, componentes de los niveles mas bajos de la estructura del programa). Oebido a que los componentes se integran de abajo hacia arriba, siempre esta disponible el procesamiento requerido para los componentes subordinados a un determinado nivel y se elimina la necesidad de resguardos. Una estrategia de integraci6n ascendente se impJementa mediante los siguientes pasos: I. Se combinan los m6dulos de bajo nivel en grupos (tamblen llamados construcciones) que realicen una subfunci6n especifica 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 casas de prueba. 3. Se prueba el grupo. 4 . Se eliminan los controladores y se combinan los gTUpOS ascendiendo par la estructura del programa.
La integraci6n sigue el patr6n ilustrado en la figura 13.6. Los componentes se

S.."

C&VE
-.dante eSmioo ill

_do

-'" ' ' '""''

combinan para formar los grupos 1. 2 Y 3. cada uno de elias se prueba empleando un controlador (mostrado como un recuadro con guiones). Los componentes de los gTUpoS 1 Y 2 estan subordinados a Mo. Los controladores C1 y C2 se eliminan y los gTUpes interaccionan directamente con Mo. De iguaJ manera, se elimina el controlador

PARTE DOS

PRAc"nc/.. DE LA INGllGERiA. OIL D'TWAllii

!
Intagmcl6n
ascenclente.

Grupo 3

Grupo I

CJ del grupo 3 antes de la integraci6n con el m6dulo M b M. Y Mb se integrartm mente con el m6dulo Me. y as! sucesivamente. A medida que la integraci6n asdende se reduce la neeesidad de controladores prueha separados En realidad, si los dos niveles superiores de la estructura del

grama se integran de manera descendente. se reducira de manera irnportantt mimero de controladores y se simplificara enormemente la integraci6n de sru~ Prueba de regresi6n. cada vez que se agrega un nuevo m6dulo como partt'

fu.,..,do tIf1esiIJtt IS 00iJ esimr*.U .,[tm

una prueba de integraci6n, el software cambia. Se establecen nuevas rutas de de datos. ocurren nuevas entradas y salidas y se invoca una nueva l6gica de co
Estos cambios lIegan a causar problemas can fundones que antes funcionaban En el contexte de una estrategia de prueba de integraci6n, la aplicaci6n de una prl ba de regresi6n consiste en ejecutar nuevamente el mismo subconjunto de pruet. que ya se ha aplicado para asegurarse de que los cambios no han propagado tos colaterales indeseables. En un contexto mas amplio, Sl las pruebas (de cualquier tipo) tienen exito resultado es el descubrimiento de errores, y estos deben corregirse. Cada vez qu.. software se corrige tambien cambia algtln aspecto de la configuraci6n del so (el programa, su documentaciOn 0 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 0 errores adicionales.
La prueba de regresi6n se aplica manualmente, al ejecutar de nueva cuenLi

aio_"._

.~reporo

. .1WIIIItS).

"'""-_roWdo.

"""'" ,..1m do f8IItsi6n adJ WI Ill' 5I1rIgo III

iIJl9InIrId! Imm

subconjunto de todos los casas de prueba 0 al emplear herramientas aulomaticas

399

captura, reproducci6n, 0 ambas. las hmtlmrentas de caplUra, reproduccion. 0 de ambos tipos, permiten al ingeniero del software capturar casas de prucba y resultados para reproducirlos y compararlos despues, EI canjunlo de pruebas de regresi6n

(el subconjunto de pruebas que se aplkaran) contlene tres c1ases diferentes de ca50s
de prueba: Una muestra representativa de pruebas que ejercertm todas las fundones del software. Pruebas adicionales que se concentran en las funciones del software que probablemente el cambia afectaria. Pruebas que se concentran en los componentes de! software que han cambiado. A medida que avanza la prueba de integraci6n, la cantidad de pruebas de regresi6n llega a vol verse muy grande . Por tanto, el canjunlo de pruebas de regresi6n debe diseftarse para que 561 0 incluya las que atienden una 0 mas clases de errores en cada una de las fundones prindpales del programa. Resulta poco practico e inefidente repelir cada prueba para todas las fundones del programa despues de que se ha presentado un cambia. Prueba de humo. La prueba de humo es un enfoque de prueba de integrad6n que suele utilizarse mientras se desarrollan produclos de software. Esta disenado como mecanismo para marcar el ritmo en proyectos en los cuales el tiempo es cr!tico. 10 que permite que el equipo de software evalue su proyecto con frecuenda . En esen cia. el enfoque de 1a prueba de humo abarca las siguientes actividades: I.

Los componentes de software traduddos a c6digo se integran en una "construcd6n", la cual induye todos los archivos de datos, las librerias, los m6dulos reutilizables y los componentes de ingenierfa que se requi eren para implementar una 0 mas funciones del produdo_
Se disena una seri e de pruebas para exponer errores que impediran que la construcci6n rea lice apropiadamente su funci6n. El objetivo es descubrir errores "paralizantes" que tengan la mayor probabilidad de retrasar el proyecto de software.

2.

3.

La construcci6n se integra con otras (onstrucciones. y diariamente se apllca

una prueba de humo a todo el producto (en su fonna actual). EI enfoque de la integraci6n puede ser descendente 0 ascendente.
La aplicad6n diaria de una prueba a todo el producto sorprendera a algunos lecto-

res. Sin embargo. las pruebas frecuentes dan a los jeres de proyeclo y participantes una evaluaci6n realista del avance de las pruebas de integraci6n McConnell [MC096] describe as! la prueba de humo:

400
La prueba

de humo debe e,eratar todo elSlStema de principia a lin No debe ser exha __
~

tiva, pero debe tener \a capaCldad de expener problemas lmportanles. La proeba de hwro

debe seT tan completa que si la construcci6n la aprueba, puede suponerse que esta
suficienlemente estable como para probarla de manera mas completa.

La prueba de humo proporeiona varios beneficios cuanda se aplica en proyectL.... ingenieria del sofiware complejos y que dependen en fonna critica del tiempo

Se minimizo eI riesgo en Ja integrad6n Debido a que las pruebas de humo

aplican diariamente, desde el principia se descubren las incompatibilida

atros errores paraUzantes, por 10 que se reduce la probabilidad de que tlO'" un fUerte impacto en el calendano cuando se descubran errores.

Sc meJOm 10 caUdad del producto final Como el enroque estA orientado a

construcci6n (integraci6n), es probable que la prueba de humo descubra errores funciona les, arquitect6nicos y al nivel de componentes. 5i eslos errores se corrigen desde el principio, se obtendra una mayor calidad en producto.

Se simplijican el dlagn6stico y /a rorrecdOn de errores. Como todos los ero

de prueba de integraci6n, es probable que los errores no descubiertos ell prueba de humo esten asociados con ~ nuevos i ncremenlos de software software que se acaba de anadir a la conslrucci6n es una posible caUSOl error reeien descubierto) .

EI progreso es mas fad/ de eva/uar cada dla que pasa se integra mas
y se demuestra que funciona. Eslo mejora la moral del equipo y brinda Jefes de proyecto una buena indicaci6n de que se estan logrando avant.;

.... 11 (CMIIIruaiOI .... a . 5i ft.a III CClfamn iMllIf"IJ'IdO. Si '" IiInt anziJn, II !Koyedo It5Ii .n.
Opciones estrategicas. Ha habido mucha discusi6n (por ejemplo, (BEl

..

las ventajas y desventajas relativas de las pruebas de integraci6n ascen~ cendente En general, las ventajas de una estrategia lienden a convertirse en tajas para la etra. La principal desventaja del enfoque descendente es la n resguardos y las dUicullades de las pruebas asociadas. Los problemas relae... con los resguardos se compensarian con la ventaja de probar las princlpa1es nes de control en las primeras eta pas. La principal desventaja de la inL ascendente es que ~el programa, como una entidad. no existe hasta que se dido el ultimo m6dulo ~ (MYE79). Esta desvenlaJa la atenua la mayor rac"'~,1!111 disei'iar casas de prueba y la falta de resguard os
La seJecci6n de una estrategia de integraci6n depende de las caracte

-. _ ..... -._-

0; I, i !iNA'

__ :"'e.

software y, en ocasiones, del calendario del proyecto. En general. la meior un enfoque combinado (a veces denominado prueba sandwich) que usa prut:.

401

cendentes para los niveles superiores de la estructura del programa, junto con prue
bas ascendentes para los niveles subordinados.
1ft

tritico

A medida que se realiza la prueba de integraci6n, el responsable debe identificar m6dulos criticos. Un m6dulo critieo tiene una 0 mas de las siguienles caracleristicasI) atiende varias requisitos del software, 2) tiene un alto grade de control (se encuentra en un [ugaf relativamente alto de la estructura del programal, 3) es complejo a propenso a errores, 0 4) Uene requisitos de desempeno bien deftnidos. Los m6dulos criticos deben probarse 10 antes posible. Ademas, las pruebas de regresi6n se deben concenlrar en el funcionamiento de los m6dulos criticos.

Documentacl6n de la prueba de integrad6n. Un plan general para la Integraci6n del software y una descripci6n de pruebas especificas se documenlan en la

Espedflcaci6n de la prueba.

Esle documento que contiene un plan de prueba, un pro-

cedimiento de prueba, es un producto de trabajo del proceso de software y se vuelve parte de la configuraci6n del software. El plan de prueba describe la estrategia general de integraci6n La prueba se divide en fases y construcciones que atienden caracteristicas especificas del funcionamiento y el comportamiento del software. Por ejemplo, la prueba de integraci6n para un sistema de disei'\o asistido par computadora se dividiria en las siguientes fases de prueba: Interacci6n del usuario (seiecci6n de comandos, creaci6n de dibujos, representaci6n del despliegue, procesamiento de errores y representad6n) . Manipulaci6n y analisis de datos (creaci6n de simbolos, asignaci6n de dimensiones, rotaci6n, cakulo de propiedades fislcas). Procesamiento y generaci6n de despliegue (despliegues bi y tridimensionales, imagenes y grfiricas). Administracl6n de base de datos (acceso, actualizaci6n, integridad , desempei'\o) cada una de estas fases y subfases (denotadas entre parentesis) delinean una amplia categoria funcional dentro de! software y suelen relaclonarse con un dominic especifico dentro de la arquitectura del software. Por tanto, las construcciones del pro grama (grupos de m6dulos) se crean para que correspondan con cada rase Los siguientes criterios y las pruebas correspondientes se aplican para todas las fases de prueba

Inlegrldad de la inleljaz. Las interfaces intemas y externas se prueban a medida

que cada m6dulo (0 grupo) se incorpora en la eslructura.

Validez Juncional. Se realizan las pruebas disefladas para descubrir errores fundonales.

Conlenido de la informad6n. Se aplican las pruebas disefladas para descubrir errores asociadas can estructuras de datos locales 0 globales.

Desempeno. Se realizan las pruebas diseliadas para verificar los IImites de descw
peno establecidos durante el diseno del software. Un calendario para la integraci6n, el desarrollo de software de sobrecarga y temas relacionados tamblen se analizan como parte del plan de prueba. Se det nan las fechas de inicio y termino para cada fase y se definen las '"ventanas de ponibilidad" para los m6dulos de prueba de unidad. Una breve descripcion del ware de sobrecarga (resguardos y controladores) se concentra en las caracleri.sll... que requieren esfuerzos espedales. Por ultimo. se describen el entorno y los r 50S de la prueba. Configuraciones poco comunes de hardware, simuladores ex y herramientas espedaJes de prueba son algunos de los muchos temas que ta podrian analizarse. A continuaci6n se describe el procedimiento detallado de prueba que se r para completar el plan respectivo. Tambien se detalla el orden de integraci6n pruebas correspondientes en cada paso de inlegradon. Ademas, se incluyen lisla de lodos los casos de prueba (anotados para referencia posterior) y los dos esperados. Una historia de resultados, problemas 0 peculiaridades de las pruebas r registra en el lnJonne de prueba que puede adjuntarse a la Espedficad6n de pr 5i se desea, la informaci6n contenida en esta secci6n sera vital durante el mar' miento del software. Tambien se presentan referencias y apendices apropiados Como lodos los demas elementos de una configuraci6n de software, el fI de 1a especificaci6n de prueba puede amoldarse a las necesidades locales dt organizaci6n de ingenieria del software. 5in embargo, es importante observar una estrategia de integraci6n (conlenida en el plan de prueba) y los detalles de ba (descritos en el procedimiento de prueba) son ingredienles esenciales y aparecer.
"f11111jor ~
II1II " . lit 15

.,,1IIll*Ih m6s

IfTOI"I5 .

!ino . . .

El objetivo de prcbar, para definirlo de manera simple, es encontrar la mayor dad de errores aplicando una cantidad manejable de esfuerzo en un periodo ta, Aunque este objetivo fundamental sigue sm cambie para el software orien objetos, la naturaleza de este software cambia la estrategia y la tactica de las bas (capitulo 14).

13.4.1 Prueha de unidad en el contexto orientado a objetos

Al pensar en el software orientado a objetos cambia el concepto de un' encapsulaci6n orienta la definici6n de clases Esto significa que cada clase e cia de una clase (objeIO) empaquela alribut05 (datOS) y las operaciones (fu que manipulan estos datos Una clase encapsulada suele ser el eje de las p~

403

unidad. Sin embargo, las unidades de prueba mas pequenas son las operaciones
dentro de la clase Debido a que una clase puede contener varias operaciones diferentes y a que una operaci6n detenninada puede existir como parte de varias clases diferentes, deben cambiar las t,ikticas aplicadas para la prueba de unidad No es poslble probar una sola operaci6n de manera aislada (el concepto convendonal de prueba de unidad) sino como parte de una clase. Para ilustrarlo, considerese una jerarqula de clase en que se define una operaci6n X para la superclase y que heredan varias subclases. cada una de estas usa la operaci6n X, perc se apliea den lro del contexte de los alributos prtvados y las operaciones que se han definido para la subclase. Dado que el contexto en que se emplea la operaci6n X varia en fonnas suliles, es necesario probar 1a operaci6n en el contexto de cada una de las subclases. Esto signHica que si se prueba la operaci6n X de manera independiente (el enfoque de la prueba de unidad convencional) se pocIn1 usar de manera deficiente en el contexto orienlado a objetes. La prueba de clase para el software orientado a objelos es el equivalenle a la prueba de unidad para el software cenvenciona1. A diferencia de esta, que tiende a concentrarse en el detalle algoritmico de un m6dulo y en los dalos que fluyen por la interfaz del m6dulo, la prueba de dase para el software orientado a objelos se orienta mediante las operaciones que encapsula la clase y en el comportamiento de estado de Ja clase.

13.4.2 Prueba de tntegracion en el contexto ortentado a objetos

Debido a que el software orientado a objetos no tiene una estrategia obvia de control jerarquico, lienen poco significado las estrategias de integraci6n descendente y ascendente tradicionales (secci6n 13.3.2). Ademas, integrar las operaciones una por una en una dase (el enfoque convendonal de la integraci6n incremental) suele resuitar imposible debido a las "interacciones directas e indirectas de los componenles que integran la clase" [BER93! Hay dos estrateglas diferentes para la prueba de integraci6n de los sistemas orientados a objetos IBIN94] . La primera, la prueba basada en subprocesos, integra el conjunto de clases requerido para responder a una entrada 0 un evento del sistema Cada subproceso se integra y prueba indivIdual mente. La prueba de regresi6n se aplica para asegurar que no se presenten efeclos colaterales. EI segundo enfoque de integraci6n, la prueba basada en el USO , empieza la construcci6n del sistema con la prueba de esas clases (llamadas clases independientes) que usan muy pocas clases de servidor (0 ninguna) . oespues de que se prueban las cJases independientes, se prueba la siguiente capa de cJases, Ilamadas doses dependienres, que usan las dases independientes_ Esta secuencia de capas de prueba de clases dependientes continua hasta que se construye todo el sistema_ El uso de controladores y resguardos tambi~n cambia wando se aplican prucbas de integraci6n a los sistemas orientados a ob}etos Con los controladores se prueban operaciones al nivel mas bajo y gTUpos completos de cJases Un controlador tambien

PARTE DOS J>RAcn::.t. DE LA INGINIERlA OIl.!a'TWAJIE

se utiliza para reemplazar la interfaz de usuario, de modo que puedan aplicarse pruebas de funcionalidad del sistema antes de la implementad6n de la interfaz resguardos se usan en situadones en que la colaborad6n entre clases es necesal" pero en las cuales aun no se han implementado por completo una 0 mas de las ses que colaboran. La prueba d~ gropo es un paso en la prueba de integraci6n del software ori do a objetos. Aqui, un grupo de clases que colaboran entre sl (determinadas par examen del CRC y el modelo objeto-relaci6n) se ejercita al disenar cases de p que tratan de descubrir errores en las colaboraciones.

13,5 P'P'IA$ pI

DLlDAC,6M

"C~VE c.ro,,",,"_ swebo.

~strotude desobi 1IIOI8S, ~

....-.. ..
IIJ505 de

11110

an ei rweI de los

r~ (0 los COSQS

...,

Las proebas de validaci6n empiezan tras la culminaci6n de la prueba de integrao cuando se han ejercitado los componentes individuates, se ha terminado de e blar el software como paquete y se han descubierto y corregido los errores de faz. En el nivel de validaci6n 0 sistema desaparece la distinci6n entre software vencional y orientado a objetos. La prueba se concentra en las aceiones visibles el usuario y en la salida del sistema que este puede reconcx:er. La vaJidad6n se define de mochas rormas, pero una definici6n simple (a vutgar) es que se aJcanza cuando el software funciona de tal manera que satisfaa. expectativas razonables del cliente. En este punto, un desarrollador de software rimentado protestaria: ..iQue 0 quien decide 10 que es una expectativa razonablC"" Las expectativas razonables se definen en la Especificaci6n de requisitos del war~ (un documento que describe los atributos del software visibles para el usu.. La especificaci6n contiene una secci6n denominada Crirerios de vaJidaci6n. La maci6n contenida en esa secci6n integra la base del enfoque de la prueba de dad6n.

imledcJhlnenle

e'liclantes JXIO ei
tISllIIiI fid).

13.5.1

Criterios de la prueba de valldac16n

La validaci6n del software se logra mediante una serle de pruebas que dem que se cumple con los requisitos. Un plan de prueba delinea la clase de pruebal se aplicaran, y un procedimiento de prueba define los casas de prueba especL Tanto el plan como el procedimiento se disenan para asegurar que se sa todos los requisitos funcionales, que se alcanzan todas las caracteristicas de portamiento, que se comple con todos los requisitos de desempefto, que la mentaci6n es correcta y que se cumple tambien con todos los requisitos de ! de uso y otros requisitos espedficados (pOr ejemplo, portabilidad. compati recuperaci6n de errores, facilidad de mantenimiento). Despues de que se ha dirigido cada caso de prueba de vaJidaci6n, existira dos condiciones posibles: I) la caracterlstica de funcionamiento 0 desempeno pie con la especificad6n y se Ie acepta, 0 2) se descubre una desviaci6n de la cificad6n y se crea una lista de deficiencias. La desviaci6n 0 el error descubl

405

esta etapa de un proyecto rara vez se corrige antes de 1a fecha de enlrega A menudo es necesario negociar con el cliente un metodo para resolver las deflciencias_

13.5.2 Revision de la contiguract6n

La revision de /a conjiguracion es un elemente importante del proceso de validaci6n;

su objetivo es asegurar que todos los elementos de la configuraci6n del software se hayan desarrollado apropiadamente, esten catatogados y tengan e\ detalle suficiente para rerorzar 1a rase de soporte del cicio de vida del software. La revisiOn de la configuraciOn. a veces denominada auditoria, se analizara con mas detalle en el

capitulo 27.

13.5.3 Pruebas a11a y beta

En Ja practica es imposible que un desarrollador de software prevea c6mo utilizara el usuario realmente el programa. Es posible que se malinterpreten las instrucciones
de uso, que se utilicen con regularidad extraf'ias 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 aceptaci6n que penniten al cliente vatidar todos los requisitos. El usuario final conduce, no los ingenieros del software, las pruebas de aceptaci6n, las cuales van desde una "prueba de manejo" informal hasta una serie de pruebas planeadas yejecutadas de manera sistematica. En realidad, la prueba de aceptaci6n lIega a durar semanas 0 meses, por 10 que es posible descubrir errores acumulativos que degradan el sistema .

..... _
, ':"

y II tImKi6n Slfiubvia pDfl olgaienl."

.............. boto ydo '''''''''oIoio<.. """"" ..

.-M.....""..
LI.,....

Si el software se desarrol1a como un producto que usaran muchos clientes. no es practico realizar pruebas de aceptaci6n formales para cada uno. La mayorfa de los constructores de productos de software emplean procesos lIamados prueba alJa y prueba beta para descubrir errores que 5610 el usuario final podria detectar Los usuarios finales son quienes aplican la prueba alJa en el lugar de trabajo del desarrollador. El software se utiliza en un entomo natural mientras el desarrollador "mira sobre el hombro~ de los usuarios tipicos y registra los errores y los problemas de uso. Las pruebas aIra se realizan en un entomo controlado. Las pruebas beta se apliean en ellugar de trabaJo de los usuarios finales. A diferencia de la prueba alfa, por 10 general el desarrollador no esta. Por tanto, la prueba beta es una aplicaci6n "en vivo" del software en un entomo que no controla el desarrollador. EI usuario final registra lodos los problemas (reales 0 imaginarios) que

...
encuentra durante Ja prueba y los infonna de manera regular a l desarrollador resultado de los problemas informados durante las pruebas beta. los ingenieros
software 10 modifican y luego preparan la Iiberaci6n del produc to de software

toda la base de clientes_

HOGARSEGURO

Preparadlm ptUa validadon

Doug: $i, " realidod he ~ . . ~_ .... a un contJoIi5la que _ayudecon Ia .tdlciM.- ....
dineroenel~...,_. ynoldarto . . . . . . . . . .

_do

...........

..... 8pimw ~ esIoftIli5lO para YOIidoci6n

~

_dol . . . . "",.,m
Liw

, .-. &.... _

Doug Miler, j.M d. ingenierio de dw.:n. vtnOd,.Iamie, Ed y Shabo, inlegrontts del

HogmS.go.~

..."
Vtnocl: Creo que 10 t.nemos todo bajo coWoI
Doug: Esloy MgUI'O de MO, pero un ~ iodependiente de prueba I'lOl clarO un purIo de ilia
outooorno

sobre eI toftw-.

'IIM* fa CDn'IIdo. lD inlIgroti6n YO bien. EskIn'Io$

_E_;.-do ........... Ooug

......... pruIbca de hu.r.o a diane, WICOntrondo . . . . trnnI. J*tI ncda que no .. pueda monefor

" ' ' ' ' - ahooa Iodo ~ bOon .....~unpDDD_lo~

. . . . . . . . . . . . . . . . .IQ

__ para" cr..r.o.
. . Lo.....,)'O-

tocb 1o.CC1SC15 de V$O

pruebol, AUn no

t. ............. do"',I."d.,....,.. ""'" tocI.loI CCIIO& d. UIO de ~ que tOy ~$(Ible

. . . . Yo b'I'Oen, F*O Iand.wnos que oduar juntos pen .. " . . . de CKepb:d6n Y to,,**, pam los . . . - . . y boa. ,..dad<

"-

,. penICII, no Mngo ~ para cuidar a nocM que 1ro9n (I hoc. IraDajo. Doug: to M, 10 Mo, Pwo iii unGl'lnIixajoa ......," ~isilos Y(;0_ de """. "" ........" ..d., .,MI...
Vinod: fodcMo
~
pienSO

que 10 _ _, tod..... ,_

Doug: Yo Ie oi, Vinod, f*O me vay (I . . . ._

eI encu.ntro

adeIonte, esto mi~ temonO

~

con.

, . . .

IIP_.... cW

que ,..!roe. YtnOCI: Mut bien. 101 ... oiigInt un poco Ia a.gra.

En el inicio de este libro se deslac6 el hecho de que el software sOlo es un to de un sistema de c6mputo mas grande. Al final, el software se incorpora elementos del sistema (como hardware. personas. informaci6nl. y se realizl, serie de pruebas de integraci6n del sistema y de validaci6n. Estas pruebas est.ar alia del alcance del proceso del software y no las realizan unicamente los ros del software. Sin embargo. los pasos dados durante el diseiio y la prueba del ware mejoraran en gran medida la probabilidad de tener exito en la integraa. software en el sistema mayor.

407

Un problema clasico de la prueba del SIStema es ~sena lar con el dedo" Eslo ocurre
cuando se descubre un error y el desarrollador de cada elemento del sistema culpa a los demas. En lugar de caer en este absurdo, el mgeniero del software debe anticiparse a posibles problemas con la interfaz y I) disenar rutas de manejo de errores que prueben toda 1a informaci6n proveniente de alros elementos del sistema, 2) aplicar una serie de pruebas que simuien datos incorrecl os u otros posibles errores en la interfaz del software, 3) registrar los resultados de las pruebas como "evidenda" en el caso de que se Ie culpe,

y 4)

participar en la planeaci6n

y el diseno de pruebas del sistema

para asegurar que el software se ha probado adecuadamente. En realidad, 1a prueba del sistema abarca una serie de pruebas diferentes euyo prop6sito principal es ejercitar profunda mente el sistema de c6mputo. Aunque cada prueba tiene un prop6sito diferente, todas trabajan para veri ficar que se hayan inte grado adecuadamenle todos los elementos del sistema y que realizan las funciones apropiadas. En las siguientes secciones se examinaran los tipos de pruebas del sistema [BEI84) que valen la pena para sistemas basados en software.

13.6 .1 Prueba d e recuperadon

Muchos sistemas de c6mputo deben recuperarse de fallas y reanudar el procesamiento en un tiempo determinado. En algunos casas, un sistem a debe ser tolerante con las fallas; es decir, las fallas de procesamiento no deben lIevar a la caida del sistema, en general. En olros casos, una falla del sistema debe corregirse dentro de un periodo especlfico a se sufrira un fuerte dano econ6m ico.

La prueba de recupemci6n es una prueba del sislema que obllga al software a

fallar de varias maneras y a verificar que la recuperaci6n se realice apropiadamenteo Si la recuperaci6n es automatica (la realiza el propio sistema) debe evaluarse que sean correctos la reinicializaci6n, tos mecan ismos de respaldo del sistema, la recu peraci6n de datos y el nuevo arranque. Si la recuperaci6n requiere intervenci6n humana, se debe evaluar el tiempo media de reparaci6n (fMR) para determinar si se encuentra dentro de limites aceptables.

13.6.2

Prueba de seguridad

Cualquier sistema de c6mputo que maneje informaci6n confidencial 0 que desenca dene acciones que danen (0 beneficien) inapropiadamente a los individuos es un blanco para irrupciones impropias a iJegales. La irrupci6n abarca un amplio rango de actividades: hackers que lratan de enlrar en los sistemas por juego, empleados disgustados que lratan de irrumpir como forma de venganza, e i ndividuos deshonestos que buscan ganancias personales iHcitas. La prueba de seguridad comprueba que los mecanismos de protecci6n integrados en e[ sistema realmente 10 prolejan 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 tambien a los perpetrados por los flancos 0 la retaguardia".

408

PARTE DOS

PRAcnCA DE LA INGNIRlA. DEL SOFTWARE

Durante Ja prueba de seguridad, quien la aplica desempefLa el papel del individaD

que desea entrar en eJ sistema. iTodo se vale! Debe tratar de obtener contrase~ por cualquier media extema; podria atacar el sistema con software personalizadco disenado para burlar cualquier defensa que se haya construido; podria saturar el515
lema, negando asi eI servicio a atros; pcx1ria producir errores intencionales en eJ sisk

rna para tTatar de tener acceso durante la recuperaci6n: podria revisar datos sin pr"" tecd6n , con 1a idea de encontrar la clave de acceso at sistema.
Si se dan el tiempo y los recursos suficientes, una buena prueba de seguridad tefminara por irrumpir en el sistema. EI papel del disenador del sistema es que el a::Q de 1a irrupci6n sea mayor que el valor de Ja infonnaci6n que habra de obtene~

13.6.3 Prueba de resistencia

Los pasos de prueba analizados antes, en este mismo capitulo, !levan a una e ci6n completa de las funciones y el desempefio normales del programa. Las p de resistencia esttm disenadas para confrontar los programas con situaciones an males. En esencia, la persona que realiza la prueba de resistencia se pregu "iHasta d6nde puedo !levar esto antes de que falle?" La proeba de resistenda ejecuta un sistema de tal manera que requiera una dad, una frecuencia 0 un volumen anormal de recursos. Por ejemplo: \) se dpruebas especiales que generen diez interrupciones por segundo, ruando la promedio es de una 0 dos; 2) se aumenta la frecuencia de entrada de datos en magnitud que permita determinar c6mo responderan las funciones de entrada. ejecutan casos de prueba que requieran el maximo de memoria u otros recursos se disefian casas de prueba que causen problemas de administraci6n de me 5) se crean casos de prueba que produzcan busquedas excesivas de datos en eJ En esencia, la persona que aplica la prueba tratara de sobrecargar el programa

"5i ISIO IrQIdo de tnCOIdmr venIodaros emwes del sislema y no ho SI:IIIIlIido SlJ softwa-e " .. rt5isteOOa, entonI:es isle as eI momento de ~,,(.

una...w.o ,..

Una variante de la prueba de resistencia es una tl~cnica denominada prueta sensibilidad. En algunas situaciones (Ia mas comun de elias ocurre con los mas matemalicos), un rango muy pequeno de datos contendidos dentro de los tes de los datos vaHdos para un programa puede causar procesamiento ex incluso err6neo, 0 una fuerte degradaci6n del desempeno. Las pruebas de se dad tratan de descubrir combinaciones de datos dentro de las c1ases de entrada das que causen inestabilidad 0 procesamiento inapropiado.

. . .-

13.6.4 Prueba de desempeiio

En sistemas en tiempo real e incrustados es inaceptable el software que prop"" na Ja funci6n requerida pero que no cumple los requisitos de desempefio. La de desempeno esta disenada para probar el desempefio del software en tie

ejecuci6n dentro del contexto de un sistema integrado. La prueba de desempeno se aplica en todos los pasos del proceso de Ia prueba. Incluso al nivel de la unidad, el desempefto de un m6dulo individual debe evaluarse mientras se realizan las pruebas. 5in embargo, no es sino hasta que se encuentran totalmente integrados todos los elementos del sistema que es posible asegurar el verdadero desempeno del sistema. Con frecuencia las pruebas de desempefto se vinculan can pruebas de resistencia y suelen requerir instrumentaci6n de software y hardware. Es decir, a menudo resulta necesario medir con exactitud la utilizaci6n de recursos (por ejempl0, los ciclos de procesador). Mediante instrumentaci6n extema pueden vigilarse de manera regular los intervalos de ejecuci6n, los eventos que se registran (como las interrupcionesj y los estados de muestra del equipo. 5i se instrumenta un Sistema, la persona que aplica \a prueha descubrira situaciones que lleven a la degradaci6n y posibles fallas del sistema.

Planeac16n yadminLstraci6n
depru6bas
Objelivo: Estos herromieotos oyudon 01 .....' do ~re a pioneer 10 estrotegio de pruebo que de elegirse y a monejor eI proceso de pruebo a . . . ., ~~ :Ie oplito.
"","' ,., Los herromientos de esto categorio otienden j:i6c:I'Ieoci6n y eI olmocenomieoto de Ia pruebo, Ia yel control, eI seguimiento de los , Ia integroci6n, eI rostreo de errores y Ia de inb-mes. Los jefes de proyedo las usan las herromienlos de pIoneoci6n. opliton las pruebos uson Mlos herromientos paro oc;rividodes de prvebo y controlor eI Rujo de a medido que (JV(lnzo el proceso de pruebo.

Herramientas repre se ntalivos 2 OTF (Ob;ect TMting Framework), desarrollodo por MCG Software Inc. (WWW..mcgsoft.com). proporciono un morco conceptual paro 10 ooministroci6n de conjunloS de pn.Jebos paro objetos Smollloik .
QADi~,

desarroHocIo por Compuwore Corp . (WWW'.compuwore.oom/qocenter),proporcionounsoio punta de control para ooministror todos las loses del proceso de prvebo.

TestWorb, desarrollodo por Software Reoseorcn Inc. (WWW..soH.com/Products/inde.x;. hlml), contiene un conjunta plenomente integrodo de herromientas de pruebo, induidos algunos que sirven paro eI monejo y Ia generoci6n de inb-mes de los pruebos.

La prueba del software es un proceso que puede planearse y especificarse sistematicamente. Se disefta el caso de prueba, se define una estrategia y se evaluan los resultados frente a las expectativas prescritas. La depuraci6n ocurre como consecuencia de una prueba reaJizada can exito. Es

decir, cuando un caso de prueba descubre un error, la depuraci6n es la acci6n que 10 elimina. Aunque la depuraci6n puede y debe ser un proceso ordenado, sigue sien do un arte. Un ingeniero del software, al evaluar los resultados de una prueba, suele

2 Las herramientas expuestas aqul 5610 representan una muestra de esta categoria . En casi lodes los caS05 los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.

410

enfrentarse con una indicaci6n "sintoma:tica" de un problema de software. Es dea. tal vez la manifeslaci6n extema del error y su causa inlema no tienen una rela obvia. La depuraci6n es el proceso mental que caneela un slntoma con una caUSil

"&I..uo_pmmos III pr. . . . . ~,.a1UlSD -rresa, que . . .6fad ~ II prop-. ................ b ..escn ___ ID ....... baado lilllOll1el'h DIXIt., qot .. ' o.ta .. . . .., a gastar p i par1e dt mi 'lido, 0 par1i" de est momenta, .. lIKontrar los MOriS de 1M ,opIos pr. . . .. MIIIKkt wa.ts, II ~.,. ud6w .. , ....

.s*.

13.7.1 El proceso de depwac10n

La depuraci6n no es una prueba, perc siempre ocurre como consecuencia de

Si se toma como referenCla la figura 13.7. el proceso de depuraci6n comienza CO"' ejecuci6n de un caso de prueba. Se evaluan los resultados y se encuentra una de correspondencia entre el desempeno esperado y el real. En muchos casos datos que no corresponden son sinloma de una causa que aun no aparece. La raci6n trata de relacionar el sintoma con la causa, 10 que conduce a corregir el
La depuraci6n siempre arrOja dos resultados: 1) se encuenlra y se corrige 13

o 2) no se localiza la causa En este ultimo caso, la persona encargada de la d ci6n debe sospechar la causa, diseiiar uno 0 mas casos de prueba que ayuden a validar esa sospecha y avanzar hacia la correcci6n del error de manera iteratlQ

E1 proceso de clepwac:ien.

Co~

d. pruobo

Pioobo, de regre$i6n

"-

Correccio"u!l~ COU5Q5 _ _

identificodos

....._ _ _J

AI hacer esta afirmaci6n se torna f'l COOCf'p(O mas amplio posible de La prueba. jNo s6Io d

llador prueba elsoftware anles de La 1ibf'raci6n, SU'lO qui!: el cliente, el usuano, 0 ambos. p software atda vel: que 10 usan!

CAPInn.O 13 ESmATEGlAS DE PRUEBA DEL SClFTWAR

411

iPor que es tan dificiJ Ja depuraci6n? Con toda probabilidad, la respuesta se rela ciona mas con la psicologia humana (consulte la siguiente secci6n) que con la tecnologia del software. Sin embargo, ciertas caracteristicas de los errores ofrecen algunas pistas: I. EI sintoma y la causa pueden estar separados geogrMicamente. Es decir, aquel aparece en una parte del programa mientras esta se ubica en un sitio distante. Los componentes con un fuerte acoplamiento (capitulo It) exacerban esta situaci6n. 2. Es posible que el s[ntoma desaparezca (temporatmcnte) al corregir otro error.

3. Es probable que el sintoma no 10 cause algun error (como en el caso de inexactitudes al redondear cifras).

4. EI sintoma podrla deberse a un error humane dificil de localizar.

5. EI sintoma podrla deberse a problemas de tiempo y no de procesamiento.

6. Tal vez sea difIcil reproducir con exactitud las condiciones de entrada (por
ejemplo, una aplicaci6n en tiempo real en que no esta definido el orden de entrada).

1 . El sintoma podrla presentarse intermitentemente. sto suele ser comun en

sistemas empotrados que acoplan el hardware y el software de manera inextricable.

8. Probablemente el sintoma se debe a causas distribuidas entre varias tareas

que se ejecutan en diferentes procesadores [CHE90]. Durante la depuraci6n se encuentran errores que van de medianamente molestos (como un formato de salida incorrecto) a catastr6ficos (por ejemplo, el sistema Falla y causa serios dafios econ6micos 0 fisicos) . A medida que aumentan las consecuencias de un error, tambien se incrementa la presi6n para encontrar la causa. A menudo, debido a la presi6n, un desarrollador del software introduce dos errores mas al tratar de corregir uno.

, . . sobtnque depurar es dos veers mils difid que esaibir eI Pfograma. Por tanio, si a~Kct tado su inteliplKio paro ewibirlo, ((0010 espera siquim depurorlo?"

Irian KlrlIigHn

13.7.2 Consideraciones psicolOgtcas

Por desgracia, hay evidencia de que las destrezas para Ja depuracion son innatas en eJ ser humano. Ciertas personas son buenas para ella; otras no. Aunque la evidencia experimental sobre la depuracion esta abierta a muchas interpretaciones, se han reportado grandes variaciones en la habilidad para la depuraci6n en programadores con educaci6n y experiencia similares.

4'2
Al comentar los aspectos humanos de la depuraci6n, Shneiderman (SHNSOI
La depurad6n es una de las panes mas frustrantes de la programad6n Incluye elemel'l

tos de ~uci6n de problemas 0 de retas mentales, junto con el molesto reconoc.m!lel& de que se ha cometldo un error. La creoente ansieda<l yescasa 'IOJuntad de aceptar 1a em lencia de errores aumenlan la dlficullad de Ia laTea. Por fonuna. se presenta un gran via y la lensi6n decreet cuando eJ error linaimente. se comge

Aunque sea dificiJ "aprender" a depurar. se propenen varios enroques para eI blema. Se examinaran en la siguiente secci6n.

HOGARSEGURO

DepuradOn
La ......: Cubkulo de Ed

b cr;dkocion y 10 pnM:x! de unidod

Shakira ( .1 __ .. C1.'."" A_,

~..-.

Ed: Si pero.

lacon ....a.n: It I ' h. C _nela .e a Ia entroclo cW

".MID..... '*

Eel: E5 compIicodo. yod.nos .......

duronte, ;euOnIo~. cil'\CO horta. No "'Ot 0 .""" .... to.

,.1 "

''tWo):H.y.. ~~olohorodel

_"

do_

Shakira: Perd6nome. tcu6I., .. poOl.lllo' (Ed Ie expIico eI p",bleulQ a ShoLra, que 10 ........""'1 30 MgUndos sin ~ I Shakira(...... i . . . . . . . . w .... _ _ _
JU roam.): Miru. Ivsto 0Cf'II,

' _ I t mal. ~ 1M 10 CfIe paso' ad (. . . . . . . . con fuena): He eslodo trobajOnda ~ ... cW.p> error porque 10 descubn a len 9:30 de Ia mm\cmI. Y tor'1lm 2:45 y oUr! no tango IKICI pisIa

10 "OriabIe

.wbIet:etCondicioAAJormo. tNo deb.ria panerM""falso'" antes de ~ il"llCie III budef

''''Pemeque~de~ en no cWcor m(ft de uno horo a depurar cmas po.. nuestro cuemc.. En eM COSO, tandriomos que buKDt'" oyucIa, to no2

lEd .. queda vieI"Ida 10 p:rokJIIo $in~," indincI ~io deIorua y empieUl 0 goIpear $!,I cabezo gen~I""'1e CXlrlIro aI .nania. Sftobo, ahoro SOI'Ii . . .
ampliamel"lle, ~!.wanta

y sole.)

13.7,3 Estrategias de depuracton

Sin importar el enfoque que se adopte, la depuraci6n tiene un objetivo prim encontrar y corregir la causa de un error del software. El ohjetivo se logra c nando 1a evaluaci6n sistematica, 13 intuici6n y la suerte. Bradley (BRASS] descr asi el enfoque de la depuraci6n:
La depuraci6n es una aplicaci6n simple y dUe1:ta del metodo clentifico desarrollado ila(...

2 500 ai'los La esencia de la depuracl6n consiste en ubicar la ruente del problema causal mediante partici6n binaria, mane}3ndo hip6tesis de lrabajo que predigan nUe valores que habr.ID de examll\arse. Tomemos un ejemplo sencillo, sm relaci6n alguna con el software: en mi casa no fw ciona una lampara. Si no fundona nada en la casa, Ja causa debe scr un fusible fundidc una falla en eI summlSlro de energla eleclrica Miro alrededor para ver si hay luz en el ~

CAPiTuLo 13

ESTRAn:G!AS DE PRUEl1.A 00. SOFTWARE

413

cindario. Conecto la lampara bajo sospe1:ha en un enchufe que funcione y un aparato en buen estado en el enchufe bajo sospecha Y asi se siguen altemando hip6tesis y pruebas.

En general, se han propuesto tres estrategias de depuraci6n [MYE79J: 1) fuerza bruta, 2) seguimiento hacia atras y 3) eliminaci6n de la causa.

'11 primer paso para (orregir un programa ItS hot. "" fate reptlidamente (enel ejemplo m6s" simple posib/tl:" T. Doff
TActicas de depuraci6n. La categorla de depuraci6n por laJuerza bruta tal vez sea el metoda mas comun y menos eficiente para aislar la causa de un error del soft ~ ware. Los metodos de depuraci6n par la fuerza bruta se aplican cuando todo 10 demas falla. Al aplicar una filosofia de "dejemos que la computadora encuentre el error", se hacen descargas de memoria, se invocan senales en tiempo de ejecuci6n y se carga el programa can instrucciones de salida. En algun lugar del pantano de infonnaci6n que se produce se espera encontrar una pista que pueda conducir a la causa de un error. Aunque la gran cantidad de informaci6n producida conduzca finalmente al exilO, 10 mas frecuente es que haga desperdiciar tiempo y esfuerzo. El rastreo hacia arras es un enfoque de depuraci6n muy comun, que se utiliza con exilo en pequenos programas. Empezando en el sitio donde se ha descubierto un sinloma, se recorre hacia atras el c6digo fuente (manualmente) hasta hallar el sitio de la causa. Por desgracia, a medida que aumenta el numero de l!neas del c6digo, la cantidad de caminos hacia atras se vuelve tan grande que resulta inmanejable. EI tercer enfoque para la depuraci6n (eliminaci6n decausas) 10 determina la induc~ ci6n 0 deducci6n e introduce el concepto de partici6n binaria. Los datos relacionados con el error se organizan para aislar las causas posibles. 5e elabora una "hip6tesis de la causa" y se aprovechan los datos ya mencionados para probar 0 desechar la hip6tesis. Como opci6n, se elabora una lista de todas las causas posibles y se apli can pruebas para eliminar cada una de elIas. 5i las pruebas iniciales indican que determinada hip6tesis de causa es prometedora, se refinan los datos para tratar de aislar el error. Depuraci6n automatizada. cada uno de los enfoques de depuraci6n anteriores complementan las herramientas de depuracion que proporcionan sapotte semiauto ~ malizado al ingeniero de software mientras se intentan estrategias de depuracion. Hailpern y 5anthanam (HAI02J resumen el estado de eslas herramientas cuando indican: .... se han propuesto muchos nuevos enfoques y se dispone de muchos entornos de depuraci6n comerciales. Los entornos de desarrollo integrado (ED!) pro~ porcionan una manera de capturar algunos de los errores par defecto espccificos del lenguaje (por ejemplo, caracteres faltantes de fin ~ de~ instruccion, variables indefini ~ das, etc.) sin requerir compilaci6n." Un area que ha atrapado la imaginaci6n de la industria es la visualizaci6n de las construcciones de programaci6n necesarias como medio de amilisis de programas IBAE971_ se cuenla can una amplia variedad de compiladores de depuraci6n, ayudas dinamicas para la depuraci6n ("trazadores"). generadores automaticos de casos de prueha y herramientas de correlaci6n de refe ~

414

f!'IIII Depuracion tivo: E$f(1$ IiiiiiiiII Obie oyvdo

ciepvroci6n manualmenle.
~ctnica: ~

helTOf1lienlo$ proporcionon aulomatizoda (I qvi~ deben depurar

WOdeti5tic05 de depuraci6n oyvdon oj diognQ*l:l

los erTOI'el .1C00.lrodos.

~ d..onoIodo po< ......... """"""
1-~.cxmI~,popoocioolO_

probIemos de ~re. El objetivo IS proportionar conoc::imienlo dificil de obten si w afmnto eI proce50 de

Iodas las ............ de dap.oci6n IOfl ~ficos tW Ienguoje de P"'YUI ......i6I. Y dill entcmo.
Hen-omtenta, rep~senlativclIJ:

.,5

I ,.......... _ ........... islicm m6s i ............... ~cb qx:riIiI Q C/C++, .b.oa,.~, ~ ___

_".,.., """'~ ~ lNX......n, ""

I>d.. _

~,~~,fORTRANy~

Jprobo TI".o,L.,~, dooorroliodo po< smoko (www.sitroko.com). ayvdo en 10 evoIuoc:i6n de

problemos de subprocesos: bIoqveos, detenciones y condiciones de carrero que represenlon serioI peligros pore eI des.empei'lo en aplicaciones de.lOYO C++ Test, desarrollodo por Para~ (www.parosoft.coml. IS uno herramiel'lkl de prveba de unidod que soporto un omplio rongo de pruebos en c6digo C Y C++. \.os

&gCoIodo< flo, d..onoIodo po< No.bitt SoItw.n Cap i_.nabit.o:m/l. i.ipIe. ..... IrICIIx. de Ota. ""'""""'" "" oyudo ~ """" do ....... _ aror1II .wportadoo y otro5 sclicitudM de man~
odm;"....." do R..;o dolrobojo do """,",","-

GNATS, uno opIic:oci6n freeware

Iwww.gnu.org/softwore/gncmll.esunconjunlo. henomienkls para regiKl'or informes de error

rendas cruzadas. Sin embargo, las herramientas no son un sustitulo de la ci6n cuidadosa basada en un modele de diseno completo y un c6digo fu ente El factor humane. NingUn anillisis de los enfoques y las herramientas de ci6n estaria completo si n mencionar un poderoso aliado: jlos demas! Un pur vista fresco, despejado de horas de frustraci6n, puede hacer maravillas,5 Una 0 demas faile, pida ayuda rna final para 1a depuraci6n seria: "iCuando todo 1 "

13,7.4

Correcc1On del error

CUando se encuentra un error debe corregirse. Pero como ya se ha indi corregir un error pueden introducirse otms y, por 1 0 tanto, causar mas dar.: soludonar el problema. Van Vleck IVAN891 sugiere tres preguntas simples que ria plantearse todo ingeniero del software antes de hacer la "correcci6n" que ne la causa del error~

(tondo ,...riJII .....r...,

,qui prtgllllias debo ......1

I . .i.lA causa del error se repile en oim parte del programa? En muehas situa un error se produce en un programa debido a un patr6n err6neo de l6gial podria repetirse en cualquier lugar. La considerad6n explicita del patr6n gieo puede llevar al descubrimiento de otras errores.

4 5

Las herramientas expuestas aqu! repre5('ntan una muesua de esta categorta. En casi tados

50S los IlOmbres de las mLsmas son marcas registradas de sus respectivos desarroJladores EI concepto de programaa6n por pares {recomendada como parte del modelo de proceso ell'

gromociOn exlrmW anaHzado en el capitulo 4) proporciona un mecanismo para la depuraci6n

tra5 se disei'ia y codlnca el soIl.ware

CAPiTuLo 13

ESffiA'iEQASDEPllUEllA.IlELSttlWARE

415

2. dCwlJ es eJ usiguiente error" que podria introducirse con Ja correcci6n que

esta a

punto de realizarse? Antes de la correcci6n se debe evaluar el cOOigo [uente (0

mejor aun, el diselio) para evaluar el acoplamiento entre las estructuras 16gicas y de datos. 5i la correcci6n se realiza en una secci6n del programa con un acoplamiento elevado, debe tenerse mucho cuidado cuando se haga cualquier cambio. 3. dQut debi6 hacerse para evitar este error desde eJ principio? Esta pregunta es el primer paso hacia el establecimiento de un enfoque estadistico de aseguramiento de la calidad del software (capitulo 26). 51 se corrlge el proceso junto con el producto, se eliminara eJ error del programa actual y de todos los programas futuros.

La prueba ocupa eJ mayor porcentaje del esfuerzo tecnico en el proceso del software. Apenas se empiezan a comprender las sutiJezas de la planeaci6n, la ejecuci6n y el control sistematicos de las pruebas. EJ objetivo de la prueba del software es descubrir errores; se cumple planeando y ejecutando una serie de pasos (pruebas de unidad, integraci6n, validaci6n y sistema). Las pruebas de unidad e integraci6n se concentran en la verificaci6n funcional de cada componente y en la incorporaci6n de componentes en la arquitectura del software. La prueba de vaEdaci6n demuestra el cumplimiento con los requisites 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 comp!eta mediante una serie de tecnicas sistematicas de prueba que ayudan a diseliar los casas de prueba. Cada paso de prueba ensancha el grado de abstracci6n con que se considera el software. A diferencia de 1a prueba (una actividad sistematica y planeada), la depuraci6n debe considerarse un arte. La actividad de depuraci6n empieza con la indicaci6n sintomatica de un problema y debe rastrear la causa del error. Entre los muchos recursos disponibles durante la depuraci6n, el mas valioso es el consejo de otros integrantes del equipo de ingenieria del software.
La necesidad de crear software de la mayor caUdad exige un enfoque de prueba

mas sistematico. Para citar a Dunn y Ullman [DUN82]:

1.0 indispensable es una estrategia general que abarque el espacio de prueba estrategico

con una metodologia tan deHberada como 1 0 era el desarrollo sistematico en que se basaban el analisis, el diseno y la codificatiOn.

En este capitulo se ha examinado el espacio de prueba estrategico, 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.

4.6

iSAE97J Baecker, R.. C DIGiano y A Marcus, SORware Visuahzation of Debuggn'l' commun/catlon5ojcheM:M, vol. 40, nlim. 4. abril de 1997 yotrosensayos en Ia misma ISEI84] Beizer, S, Software System TestIll8 and Quality Assuronce, Van Nostrand-Reinhold iBER93) Berard, E., ~ OIl ObjeCt-onentt:d SojtvIIOre Engineering. vol. I, Addison-wesley iBIN941 Binder. R., "Testing Object--Qriented Systems A Status Report". en American vol 7. num 4. abnl de 1994 , ruta critica, pp. 23-28. IBOEBII Boehm, B . SOjlwaref'J"rglnemng Economics, Prentice-Hall, 1981, p. 37. IBRA851 Bradley, J-H_, "The science and Art of Debugging-, en Computetworld. 19 de 1985, pp 35-38 ICHE901 Cheung. W H.J P Black y E. Manning, -A Framework for Distributed DebuggmC" IEEE SojtvIIOre, enero de 1990, pp 106-115 [OUN82] Dunn, R. y R Ullman, Quality A.ssunlr'IajorCOlnPUfer' 5ojtware, McGraw-Hili, 1982. r IGIL95] Gilb, T, "What We Fail To Do In Our Current en Testing Culture"", en ~nB 11 Newsletler (edici6n en linea, un@soR.com), SoRware Research, Inc. , enero df: {HAI02 ] Hailpem, B. y P. Santhanam, -software Debugging, Testing and Veritication-, en Systems Journal. vol. 41, num 1,2002, disponible en http://www.research.ibm.COml journal/sj/411/hailpem.html. \IEEOI]5ojtware Rdlabillry EngIMering. 12th Intemotional Symposium, IEEE, 2001 {MC096] McConnell. S., ~Bc:st Practices: Dally Build and Smoke Test", en IEEE 5ofiwo". num.4,juliode 1996,pp 143144. IMll77J Miller, E., ""The Philosophy of Testing", en Program Testlng Techniques. IEEE Society Press, 1977, pp 1-3 IMUS891 Musa,1. D. Y A. F Ackerman, "'Quantirylng SOltware Validation When to Stop--r; enlEEE.SOjtwa~,mayode 1989,pp 19-27_ {MYE79] Myers, G, TheM of5ojtware Tesbng. Wiley, 1979, ISH083] Shooman, M L, SojtwareEnglflet:nng, McGraw Hill, 1983 {SHNSO] Shneiderman, B. SOftware PsychoIcgy, Winthrop Publishers. 1980, p. 28. ]SIN99] Singpurwal1a, N. y S Wilson, Statistical Methods in Softvvare Engineering: Relia Risk, Springer-Verlag, 1999. IVAN891 Van Vleck. T. "Three QuestiOns About Each Bug You find-, en "CM SOftware Noles.voI.14,num5.)uliode 1989,pp_62-63 \WAl89] Walia nee, DRy R. U Fujii, soRware verification and Validation, An OverY IEEE 5ojtware, mayo de 1989. 1(H 7. {yOU75J Yourdon, E.. TtchnKfuei ofPrugmm srructure and DeSIgn, Prentice-Hall, 1975

I'rosn._

""""..-;t

w-

13 .1 . COn palabras propias, descrfbase la direrencia entre verifieaci6n y validaci6n. , metodos de disei\o de casos de prueba y estrategias de prueba? 13.2 . Elab6rese una Usta de algunos problemas que pudieran estar asociados con la de un grupo independiente de prueba inlegran las mismas personas que el g~ aseguramiento de la cahdad del soRware"

,La

13.3. ,Siempre es poslble desarrollar una eslrategia para probar soRware que seeuencia de pasos de prueba descrita en la seeci6n 13_1.3? ,Cuales son las complieadones que podrian surglr para sistemas incrustados" 13.4. ,Por qu~ es dlficil aplicar pruebas de umdad a un m6dulo altamente ae 13.5. El concepto de -antierror" (se<:ci6n 13.3. I) es una manera extremadamente efectJ, proporcionar depuraci6n integrada cuando se descubre un error'
a} b)

c}

Desarrollar un eonjunto de directrices antierror Analizar las ventajas de usar esta t~cnica Analizar las desventajas de usar esta tnica

417
13.6. i.C6mo afecta la calendarizaci6n la prueba de intesraci6n'

13.1.

La

prueha de unidad es posible (0 incluso deseable) en todas las circunstancias"

Proporcionar ejemplos que Justifiquen la respuesta

13.8 . ..Quitn debe aplicar la prueba de validaci6n: el desarrollador 0 el usuario del sofiware' Justifiquese la rcspuesta. 13.9. Desarrollar una estratcgia de prucba completa para el sistema HogarSeguro analizado en todo el libro. Oocumentese en una E.spt:cljicaci6n de prueba. 13.10. Como proyecto de clase, desarrollar una Gu/a de depuraci6n para instalarla Deben proporcionarse cansejos orientados al1enguaje y al sistema ique se hayan aprendido en la escuela de la vidal Empezar con una descripci6n esquematica de los lemas que revlsari!ln los

companeros de clase y el proresor

Casi lodos los libros sobre la prucba del software analizan estrategias junto con metodos para el disei'lo de casos de prueba. Todos los siguientes libros analizan los principlos, los concept os, las estrategias y los metodos de prueba: Crai g y Kaskiel (~Iematic software Testing, Artech House, 2002), Tamres (Jntroducing SOftware Testing, Addison-Wesley, 2002). Whittaker IHow 7b Break software, Addison-wesley, 2002), Jorgensen (software Testing: A Crajtman'SApproach, eRC Press, 2002), Splaine y sus cOlegas (The web Teslsng Hand/xJok, Software Quality Engineering Publishing, 2001), Patton (SOftware Testing, sams Publishing, 2000), Kaner y sus colegas (TestlTl8 COmputer software, segunda edici6n, Wiley, 1999), Black (ManagIng the Testing Process, Microsoft Press, 1999) y Perry (Sutvnllns /he TOp Ten Challenges Of software Tesling.' A PeopIeOriented Approoch, Dorset House, 1997) tambien atienden las estralegias de prueba del software_ Para los lectores interesados en metodos de desarrollo agil de software, Crispin y House [TeSttns Extreme Progrommil18, Addison-Wesley, 2002) y Beck (Rsl Driven Dt:veiopmenl By Example, Addison-Wesley, 2002) presentan estralegias y tacticas de prueba para Programaci6n Extrema, Kamer y sus colegas (Lessons Learned in Software Testing, Wiley, 2001) presentan una colecci6n de mas de 300 wlecciones" pragm<iticas (directrices) que toda persona dedlcada a la prueba de software debe aprender. Watkins (Testing rr. An Off the Shelf Testing Process, Cambridge university Press, 2001) establece un marco conceptual de prueba efectivo para todos los tipos de software desarrollado y adquirido, Lewis (Software 1l!SIing and Continuous Qualll)! Improvment, CRC Press. 2000) y Koomen y sus colegas (n'sl Process Improvmenl, Addison-wesley, 1999) analizan estrategias para la mejora continua del proceso de prueba Sykes y McGregor (Pmclical Guide to Rsttng Object OnentJ!d Software, Addison-wesley, 2001), Bashir y Goel (n'sting ObjeCt-Oriented Software, Springer-Verlag, 2000), Binder, Tesl1ns ObjectOnenled ~tems. Mdison-Wesley, 1999), Kung y sus colegas (Testtng Object Onenred Software, lEE Computer SOCiety Press, (998) y Marick (The craft ofsoftware Testing, Prenlice Hall, 1997) presentan estrategias y metodos para prueba de sistemas orientados a objetos. Directrices para la depuracl6n se encuentran cn libros de Agans (Debugging The Nine Indispensable RUlesfor Finding EVen The Most Elusive Hardware and Software PrOblems, AMAeON, 2002), Tells y Hsieh (The SCience of Debugging. The COreo!is Group, 2001), Robbins (Debugging Applications, Microsoft Press, 2000) y Dunn I,SO{twore Defect Removal, McGraw-Hill. 1984). Rosenberg (HOW Debuggers ~, Wiley, 1996) atiende la lecnoIogia de las herramientas de depurad6n. vounessi (ObjeCt-OnentJ!d Defoct Mana,generlt cfSoftware, Prentice-Hail, 2002) presenta ttcnicas para administrar los defectos que se encuentran en sistemas orientados a objetos. Beizer [BEI84J presenta una inleresanle ~onomia de los errores" que puede lIevar a metodos efeClivos para la planeaci6n de pruebas. Ball ~ Embedded MKroprocessor S)'Stem5. Newnes Publishing, (998) atiende Ia naluraleza especial deJ software inaustado de microprocesador En Internet se encuentra una amplia variedad de fuenles de infonnaci6n sobre estrategias de prueba del software. Una lisla aClualizada de refe~1'ICi.as en la World Wide Web que resu\tan relevanles para las estrategias de prueba del software se encuentran en el sitio Web SEPA: http://www.mhhe.com / pressman.

CAPiTULO

14

TECNICAS DE PRUEBA DEL SOFTWARE

,.........
CLAVE

CONCEPTOS

An .. ..437

ddo.6tk 426

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 10 "correcto~ en el software y entonces diseiie dillciles casos de prueba para perla". Beizer IBEI90J describe bien esta situaci6n cuando afinna
Es un

prutIta . ..419

mito que si reafmenle fueramos buenos para programar no tendrlamos ~

...... ...,.......4,.
""' .....473

,.;om"

purar errores. Si tan SOlo pudicramos coocenlramos, SI lodes usaran progra estruclurada, diseflo descendc:nte 0 lablas de decisi6n, 5i los programas se escdIr ran en SQUISH, si tuvitramos las balas plateadas correctas. entonc~ no habrta res. t.se es el milo_ Hay errores, dice el rrulo, porque somos malos en 10 que "". .'" y si somas malos en eso, debemos sentimos (ulpables Por tanto, el diseiio de bas Yde casos de prueha es una admisiOn de Ia falla, que Instila una buena dasis culpa Yel tedkl de probar 5610 es un castlgo par nuesl.ros errores icastigo per

,.,r_1 ..... ........

4S6

........

MI II
nc..II .. .444

"Par ser seres humanos~ "CUlpables ck que~ ,Dc no a1canzar una perfecci6n
iPor no distinguir entre 10 que ottO progJiunador piensa y 10 que dlce~ ,PIa' usar Ia telepaUa~ "POr no resolver las problemas de las comunicaciones huma~ han estado presentes_ durante cuarenta sigJos~
... Las pruebas deben provocar culpa~ .:.Las pruebas son realmente destr1"':":'''; La respuesta es ino! En este capitulo se analizaran tecnicas para el diseno de casos de pn"::.~ software. Este tipo de diseno se concentra en un conjunto de trategias de prueba analizadas en el capitulo 13.
t~cni cas
na~

fills ..... .40

1M . . . . . .02

.a+- ......423 -c:+ ....433

nlnKlwl

c.trel .. 430

"..... "

creaci6n de casos de prueba que cumplan con obJetivos generales y con

dut .....441

........

,... . . . .423 "teIOS . .441

jetiYo es disenor uno serle de CQIO& de FJf'Mba que tengon uno 0/$0 probobiJidad dt .......... CH errores, 2pero ~ AqJi e! donci.t -*on eft..., ''''0'''''''' do dol ........ E*D_ proporcionon directrices sistemotic:as para ~

mayc< _dad do "'""'" ",Ie> do ""'""""" 01 cI;onoo

s--cdo eI c6nec:esono probor " dtwco-e pam de.Mri, Iy """'9'110

LOW .., Uno vel:

digo fuente, os

pooa.Jo So ob-

,_10 _,
..... pnoeba..

boo do d;_ que I) ~ 10 log.. no y !CD jnterfuses de todo componenle <W wen 'I 2) comprueben los domini05 de - - dido del FMcgtama para descubrir erTOf8$ k.nQ6n, comportomiento YdesempeiioOu<onto kn elope. ,in,~"",'" proceso, un ingeniero de software rtIOlizo
Ie. pruebas._ Sin embwgo, a medida que
m . . proce5O 5e trOn incorporondo ~'""=-

""*'"

411

CAPInrr.o 14

TtcNICAS DE PRUEllA DEl. SOf'TWARE

419

En el capitulo 5 se analizaron los objetivos y principlos fundamentales de las pruebas. Se recordara que el objetivo de las pruebas es encontrar errores y que una buena prueba es la que tiene una alta probabiHdad de encontrar un error. Por tanto, cuando un ingeniero de software disei'ie e implemente un sistema 0 un producto de c6mputo, debe tenet en mente la facilidad de prueba. Al mismo tiempo, las propias pruebas deben mostrar un conjunto de caracteristicas para alcanzar el objetivo de encontrar la mayor cantidad de errores con un minima de esfuerzo.

~ pr~o ho!:e allIO bien; pero to! 'i!I sea 10 que no querert10i que hota

Fadlldad de prueba. James Bach l proporciona la siguiente definici6n: "La facilidad

de prueba del software indica simplemente si es fadl 0 no probar [un programa de computadoraJ ." las siguientes caracteristicas propician la creaci6n de software que tenga facilidad de prueba.
1 Los parrafos siguientes se usan con permlso de James Bach 4copynght. 1994) Y se han adaptado del
material que originalmente apareci6 pubhcado en el grupo de nolidas comp.software-eng

PARTE DOS

PR.i.CnCA DE IA INGNIERlA tu D'TWARIi

(Drocttristi<as 6e Ia fociUcNI ... prlltba?

...

,CHiH
~.

Operatividad. ~Cuanto mejor fundone, con mayor efkiencia podra probarst un sistema esta disenado e implementado con la calidad en mente, seran relat.
mente escasos los eITores que bloquearan la ejecuci6n de las pruebas, 10 que pertira el

avance de ~stas sin correcciones oi reinicios.

Observabllidad . "La que se ve es 10 que se prueba." Las entradas proporc.iar das como parte de la prueba producen salidas distintas. Los estados y las variatl del sistema son visihles y pueden consuitarse durante la ejecuci6n. La salida rrecta se idenlifica facilmente. Los errores internos se detectan y reportan en f< automatica. EI c6digo fuente es accesible.

COntrolabUldad. Cuanto mejor se conlro{e el software, mejor se automa

y mejoraran las pruebas. EI ingeniero de pruebas cootrola directamente los estau

las variables de software y hardware Las pruebas pueden seT convenienlemenk pecificadas, aulomatizadas y reproducidas. capaddad para descomponer. AI controlar el alcance de la prueba, se ran los problemas mas rApidamente y se aplicarAn las pruebas nueva mente COf! yor inteligencia. EI sistema de software se construye a partir de m6dulos i dientes que tambien se prueban independientemente Simpllddad. ~CUanto menos haya que probar, mAs rapido se hara " EI P"'!!..... debe mostrar SlmpllCidodfundonal (pOr e;emplo, el conjunto de caracteristicas minima necesano para satisfacer los requisLtOS), 5JmpUcJdad es./rucrura/ Ita arqttura aparece en m6dulos para limitar la propagaci6n de fallas) y simplicidad tk go (se adapta un estandar de codificad6n para fadlitar la inspecci6n y el m miento.)

Estabilldad. "Cuantos menos camblos haya. menores alteradones habr.1L prueba." Los cambios al software son poco frecuentes. se controlan cuando y no invalidan las pruebas existentes EI sonware se recupera bien de las fal Fadlidad de co mprensi6 n . ~Cuanta mayor informaci6n se tenga, con ~ teligenda se aplicara la prueba.~ Se comprenden bien el diseiio de la arquil las dependenclas entre componentes intern os, extemos y compartidos. Se t ceso inslantaneo a la documentaci6n tecnica, esta bien organizada, es espcc.... detallada y exacta. los cambios a1 diseno se comunican a quienes aplican las bas. Un ingeniero usarA los atributos que sugiere Bach para desarrollar una confi de software (es decir, programas. datos y documentos) que sea sensible a la

.t.s lImnS _ mils OIIIIIINS. II softwcn, linn _ MIIIrIK IImoIogias.

.. ~, ~

caracterlstlcas d e l a prueba. iY que hay con las propias pruebas? Kaner. Nguyen (KAN93] sugieren los siguientes alributos para una buena prueba

CAPiTuLo 14

'T't!cNicAs DE PRUEBA. DEL SCFtWAI!E

421

I. Una buena prueba liene una eJevada probabiJidad de encontrar un error. Akan-

zar este objetivo requiere que la persona que aplica la prueba comprenda el software y trate de desarrollar una imagen mental de la manera en que puede fallar. La idea! es probar los tipos de fallas. Por ejemplo, un tipo de falla posible en una interfaz grafica de usuario es la incapaddad de reconocer la posid6n correeta del rat6n; por tanto, se disenarla un conjunto de pruebas para probarlo tratando de evidendar un error en el reconocimiento de su posid6n .
2. Una buena prueba no es redundante. EI tiempo y los recursos deslinados a las

pruebas son limitados. No hay raz6n para realizar una prueba que tenga el mismo prop6sito que otra. cada prueba debe tener un prop6sito diferente (aunque las diferencias sean sutiles).
3. Una buena prueba debe ser "/a mejor de su clase" [KAN93]. En un grupo de

pruebas con un objetivo similar y recursos limitados podrfa optarse par la ejecud6n de un solo subconjunto de elias. En este caso, debe usarse la prueba que lenga la mayor probabilidad de descubrir un tipo completo de errores.
4. Una buena prueba no debe ser ni muy simple ni demasiado complejo. Aunque a veces es posible combinar una serie de pruebas en un caso de prueba, los po-

sible efeetos eolaterales asociadas can este enfoque podrian enmascarar errares. En general, cada prueba debe ejecutarse por separado.

DUeJJo de ptVcbds unJcas

Vlnod: Est6 bien, 1*0 no veo COlO., . . . . . los enlrodas 123.4 y 6789. Son ~ ... prwban 10 mi$ll"lO, &0

mucno

no'

Ed: Bueno, son vaiores dilwrentes.

Vinod: Es cierto, pero si 123.. no dNcubr. 11ft trrOr en otros palobros ... 10 operociOn ~ detecta que 10 conlroHi'io no es v6Uda, aN q. no ... probobIe que 6789 nos m~ o/go "'--0.

~:::::!:::,

:.::::

Ed: Yo se 10 que quieres deck

Vinod: No eskly trotondo de $01" punfibo... do . . tenemos Iiempo limitodo poro las pvebos, modo.,. es buena ideo ejecvtor pruebos que tengan uno afta probobilidod de enconlror rIOI!IVOS erI'QAJ$. Ed: No hay probIemo. Penl(lre un poco _ en eskt.

123A y 6789 po' reccnocimiento de COI'ItroMlMS

14.2 PRp A$ AI ",1t IIlgl. X GA,Ii ILAMGA

Hay una de dos maneras de probar cualquier producto construido lY casi eua cosa) I) si se conoce la fund6n espedfica para la que se diseM el producto, se can pruebas, que demuestren que cada funci6n es plenamente operacional, mi se buscan los errores de cada funci6n; 2) si se conoce el funcionamiento inteTn('!l producto, se aplican pruebas para asegurarse de que "todas las piezas encaJan decir, que las operaciones internas se realizan de acuerdo con las especificac y que se han probado lodos los componentes internos de manera adecuada AI mer enfoque de prueba se Ie denomina prueba de caja negra; al segundo, prueta caja blanca. l Las pruebas de caja negra son las que se aplican a la interfaz del software prueba de este tipo examina algun aspecl o funcional de un sistema que liene relaci6n con la estruclura 1 6gica inlerna del software. La prueba de caja blanGI software se basa en un examen cercano al detalle procedimental . Se prueban ~ tas l6gicas del software y la colaboraci6n entre componentes, al proporcionar de prueba que ejerciten conjuntos especificos de condiciones, buc1es 0 ambos

~~

-.....
(~(o

C~VE

los~de{tjl

-slID hay .... regIu pll"G dis.io- (oses lit pruebn: _(D\" Iodas las funOones, pero no diseiior "1OSioIIas tma'

1m. "" ,..."

_ ..... dO

T_'_

""" _u, necesoriD 1JlI kIs ...,..,dO

........
..

proglOmo esl8n

A primera vista, pareceria que toda prueba de caja blanca complel a \levaN programa 100 por clenlo correcto. Todo 10 que se necesita hacer es identificar los caminos 16gicos. desarrollar casos de prueba para ejercitarlos y evaluar dos; es decir, generar casas de prueba para comprobar exhaustivamente la 16gi.. programa. Por desgracla, la prueba exhaustiva presenta ciertos problemas de lica (consultese el anAlisis del reeuadro) Sin embargo. la prueba de caja bla

Prueba exhaustiva
giro porque flO exi5te) parc op/itor uno pruebo YO EI procesodor desorrollo vn coso de pruebo, 10 y eYaiUti los rewllodo$ en un milisegundo. Si trobcJtahoro1o diorios, 365 dias 01oi'Io, necesilorio 3 170 ~ ra probor eI programo. &to cav$Orlo, indudoblen.desmtre en ca~ Iodos los calendarios de desorrolo Pot ionia, M rozanobMi osegvl'Of" que I'e$VIta i....... op!icor Uflo prveba exhouiliYo en ~$lemas grondel"
~~.

Considerese un programo de cien linoos en lengl.lClje C. Despum de algvno dedorod6n b6sica de dotos, eI p!"OgromQ contiene dos budes onidodos que se eiecvton de 1 020 veces coda W)O, 10 que depende de 10 mndici6n especificoclo en 10 entroda. Dentro del bude inlema se requieren cuatro constn.0c:ci0ne5 ~...,.t0nce5. si_flO (if-"-'-e#w J. lEI pragramo tendra alrededor de 10" pasibles !"VIos de ejec:uci6n1 Poner eite numero en perspedivo requiere wponer que he desorrcHodo un procesodot- de prueba m6gico (.rnQ.

2 Los ternunos prudxJ .fundonal Yprueba tStrUCltUIJda sueJen usarse en lugar de prueba d<~'oiI
y de caja blanca, resperuvamente

cAPiTuLo

14 ID::NlCAS DE PIIUIlIA DEL SCFTWAIIE

423

debe desecharse nunca como impractica. Es posible seleccionar y comprobar un numero limitado de rutas 16gicas irnportantes; ademas de probar la validez de las principales estructuras de datos.

La prueha de caja blanca, en ocasiones llamada prueba de caja de cristal, es un metoda de diseno que usa la estructura de control descrita como parte del diseno al nivel de componentes para derivar los casas de prueba. Al emplear los metodos de prueba de caja blanca, el ingeniero del software podra derivar casos de prueba que 1) garanticen que todos las rutas independientes dentro del m6dulo se han ejercitado por 10 menos una vez, 2) ejerciten los lados verdadero y falso de todas las deci-

siones 16gicas, 3) ejecuten todos los budes en sus Ifmites y dentro de sus limites operacionales, y 4) ejerciten estructuras de datos internos para asegurar su vaJidez.

"Los tfTores pIllulan en los riKones y se oc:umulon en Io$limiles."

La prueba de /0 rula bOsica es una tecnica de prueba de caja blanca que propuso ini-

cialmente Tom Mccabe [MCC76j. EI metodo de la ruta Msica permite que el disenador de casos de prueba obtenga una medida de complejidad 16gica de un diseno procedimental y que use esta medida como gula para definir un conjunto Msico de TUtas de ejecuci6n. Los casos de prueha derivados para ejercitar el conjunto basico deben garantizar que se ejecuta cada instrucci6n del programa por 10 menos una vez duran~ te la prueba.

14.4.1

Notaclon de grCdlca de f1uJo

Antes de tratar el metodo de la ruta Msica, debe presentarse una notaci6n simple para la representaci6n del flujo de control, lIamado grdJica deJlujo (0 grdJica del programa).3 La grafica de flujo describe un flujo de control16gico empleando la notaci6n ilustrada en la figura 14.1. Cada construcci6n estructurada (capitulo 11) tiene su simbolo correspondiente en la grafica de flujo. EI uso de una grafica de flujo se ilustra considerando la representaci6n del disefio procedimental de la figura 14.2a. Aqui se describe la estruclura de control del programa mediante un diagrama de flujo. En la figura 14.2b se correiaciona (a mapea) el diagrama de flujo con su gratica de flujo correspondiente (suponiendo que no existen condiciones compuestas en los diamantes de decisi6n del diagrama de flujo). To3 En realidad, el metodo de la ruta Msica se aplica san eI uso ~ las gr.ificas de nujo_ Sin embargo, sirven como notaci6n litil para comprender el nujo de control e Ilustrar el enfoque

"4
mando como referenda la ligura 14.2b. cada circulo. lIamado nodo de grdfica de,. jo. represenla una 0 mas instrucciones procedimentales. Una secuencia de recu... dros de praceso y un diamante de decisi6n se correlaciona con un solo nodo. Las chas en la gratica de flujo, lIamadas arislos 0 enlaces. representan el flujo de contJlr' y son analogos a las flechas de los diagramas de flujo. Una arista debe terminar un nodo, aunque el nodo no represente ninguna instrucci6n procedimental ejemplo, vease el slmbolo en la grafica de flujo para la conslrncci6n if-then~~ de figura 14 . 1) . Las areas que limitan aristas y nodos se denominan regiones. C se cuentan las regiones se incJuyen las areas ubicadas fuera de la grafica.~

Notacl6nde
grcl!1ca de fiujo. Secuencio

lal conslruccionm

eslrudurodas en formo

de grofico de Rujo:
Hoste

Segun_MO

s;

Mienlros

Oonde cado cirevlo reprewnkl una 0 min in5lnJa:i6nen LOP ~n romificociones 0 de c6digo Fuente

ex)

Diagrama de nul<> y b) gr6ttca de nul<>.

~"

01

..

Un anAlisis mas detallado de las graflcas y su apllCad6n se presenlara en Ia 5eCci6n 14 6 1

CAPiTuLo 14

'!'OCNlcAs DE PRUEBA DEL SOFTWARE

Cuando se encuentran condiciones compuestas en un disefi.o procedimenta!. 1a generaci6n de una grMica de flujo se vuelve ligeramente mas complicada. Una condici6n compuesta ocurre cuando hay uno 0 mas operadores booleanos (OR, AND, NAND, NOR) en una instrucci6n condicional. Tamanda como referencla la figura 14.3, el segmento en LOP se traduce a la grafica de flujo mostrada. Observese que se crea un nodo separado para cada una de las condiciones a y b en la instrucci6n IF a OR b. Cada nodo que contiene una condici6n es un nodo predicado y se caracteriza porque de el emanan dos 0 mas aristas.

14.4.2 Rutas lndependientes del programa

Una ruta independiente es cualquier ruta del programa que ingresa por 10 menos un nuevo conjunto de instrucciones de procesamiento 0 una nueva condici6n. Cuando se explica desde el punto de vista de una grcHica de flujo, una ruta independiente debe recorrer por 10 menos una arista que no se haya recorrido antes. Por ejemplo, a continuaci6n se presenta un conjunto de rutas independientes en la gralica de flujo de la ligura 14.2b: ruta I: I-II ruta 2: \ -2-3-4-5- 10-\ - 11 ruta 3: \-2-3-6-8-9-10-1-11 ruta 4: 1-2-3-6-7-9- 10- \ - 11 Observese que cada nuevo camino ingresa una nueva arista. El camino 1-2-3-4-5- 10- 1-2-3-6-8-9- \ 0-\ - \\ no se considera una ruta independiente porque se trata simplemente de una combinaci6n de rutas ya especificadas y no recorre ninguna arista nueva. Los caminos 1,2,3 Y 4 constituyen un canjunto Msico para la gralica de tlujo de la ligura 14.2b. Es decir, si se disenan pruebas para forzar la ejecuci6n de esas rutas

IFoORb
then procedimiento x else procedimiento y

ENDIF

..6

PARTE DOS

PRAcncA [)[ I-' INGNJERlA DEL 90FTWARE

flOHSUO.
""""'"*"
acbndtJrolSlIlII

tun canjunto basicO). se habran ejecutado los lados verdadero y falso de cada trucci6n del programa. Debe observarse que un conjunto basico no es linico . En rca lidad, es posible derivar varios conjunlos bAslcos di(erentes de un diseno proced. mental determinado.

rrM Iriro ~ rISIirrI

uri fXXO rxedeci

(0iIIM fII1OIJS..

,C6mo se sabe cuantas rutas buscar? EI dllculo de la complejidad cic/omatico

porciona 1a respuesta. La complejidad ciclomatica es una metrica de software

"".-do Se ...... "" ,.",.,do,.... """" .. _do

_o'Il6c.tJos Iieni!I'I

...

proporciona una medida cuantitativa de la compJejidad l6gica de un prog Cuando se emptea en el contexte del m~todo de prueba de la ruta basica , el
calculado mediante 1a compJejidad ciclomatica define el numero de rutas indepcr dientes en el canJunta bAsico de un programa, y proporciona un limite supenor ra el niimero de pruebas que deben aplicarse para asegurar que todas las instrucn.. nes se hayan ejecutado por 10 menos una vez.
La complejidad ciclomatica se basa en la teona grafica y se calcula de una de

<"'.". ,.,.00.

maneras:

LCiHno Sf cak.1a Ia (OIIIpIe;docI 000

lItGtka?

I. El numero de regiones corresponde a la complejidad ciclomatica. 2 . La complejidad ciclomatica, V(G), de una grafica de nujo, G, se define COfTW
V(G) -E-N+2

donde E es el numero de aristas. y N, el numero de nodos de la grafica de

jo
~~

~~

3 . La complejidad ciclomatica, V(G), de una grafica de flujo. G, tambien se como

V(G) : p + I

C&VE

.... _<10
plI'IhllJ ~ coda

l.a(~

cidonirIKa ~
rimIro III(I5IIiJ de msos dt prueIm IJII1I

donde Pes el numero de nodos predicado inc\uidos en la grafica de nujo G Tomando como referencia una vez mas la grafica de nujo de la figura 14.2b complejidad ciclomatica se calcula empleando cada uno de los algoritmos que acaban de indicar I . La grafica de flujo tiene cuatro regiones.
2 . V(G) '" II aristas - 9 nodos

-""'"
IIlII 111.

1ISfru(00n ..

o;orutodo ,., - -

+2 - 4
= 4

3 . V(G) .. 3 nodos predicado

+I

HOGARSEGURO

utlllzad6n de 10 complcjldod ddomaticD

Lacon............ :
7

-= v.nod Y snok'IlJ, inlegron_ del equipo

Shokifo: Mira. S. que ~ opIiaJr prua. de-

.......ia del taftwore HogorSeguro que trobal0 en ... 60. du prueba5 para Ia fund6n de seguridad.

un.docl 0 los ~ de Ia fu~nci6I~:"~: :~:~

pero hay demo$l~, y ~ II::mo5 '" operociCJne$ que debet, ejerci~, no M . . to! vu

CAPiTuLo 14 TtcN!CAS DI-: I'RUEJIA DEl. SOFTWARE

427

10. . . ...an m6l propIn_ Q ertQf. U Y o6fno cakuIo V ct. Gt .,.... & fPAI'J 16cil. .Aqui un Iibro qt.III deKrib.
10ft

10 YIGI para operaci6n d.ntro cI. coda COII"KIMntI,. __ cu6l. ..... ao.
io5~ m6t~

..... '-10.

'**

1"" ....... .....- .... 10 ..... ,.........

blanco,. ..

10ft

'M. I .JI.., ,
J lot m6t ......_
Q

.-""""W'''' .........
IiIm:Id"

a-

I '.........

........

Ch ...." 'I.D):Nwybien, no pcnIClIIdiffcil. to pmbcri. lal~ c;DI kl V(GJ m65 ~ $e"" . . . .Ididaka.,.." kn pnJebas 0. c:ojo bbnco. ..... S6Io~quenohay QCliCldlol.lM <OfI'If" . . . . In UI'lO YfG) boja oUn puede .... propenlO Q

a : ...

V.G.

~tOCl"4

Nducir" n6fIwoda awnpor. . . quiI ~

(I

, .... ,." bien. Pero pot lQ 1'MI1O$.-o me ~

pruebo de cajo bkwm.

La mas notable es que el valor de V(G) proporciona ellimite superior del numero de rutas independientes que forman el conjunto basico; por implicaci6n, ofrece un limite superior del numero de pruebas que debe disei'iarse y ejecutarse para garantizar la cobertura de todas las instrucciones del programa.

14.4.3 Derivacton de casos de prueoo

El metoda de prueba de la ruta basica se aplica a un disei'io procedimental 0 al c6digo fuente. En esta secci6n se presentara la prueba de la ruta basica como una serie de pasos. Se empleara el procedlmiento promedio (descrito en POL en la figura 14.4) como ejemplo para ilustrar cada paso en el metoda de disei'io de casos de prueba. Observese que promedio, aun en el caso de un algoritmo extremadamente simple, contiene condiciones compuestas y bucles. LDs siguientes pasos se aplican para derivar el conjunto basico: I. utilizando el diseno 0 el cOdigo como base se dibuja fa grafica de flu jo correspondiente. En la creaci6n de una grMica de flujo se emplean los slmbolos y las reglas de conslrucci6n presentadas en la secci6n 14.4.1. To mando como referencia el POL para obtener promedio en la figura 14.4, se crea una grMica de flujo numerando esas inslrucciones en POL, que se correlacionaran 0 mapearan en los nodos correspondientes de la grafica de flujo. En la figura 14.5 se muestra la grafica de flujo resultante. 2. Determinese la complejidad ciclomitica de la graflca de Oujo resuJtante. La complejidad ciclomatica, V(C), se determina at aplicar el algoritmo descrito en la secci6n 14.4.2. Debe indicarse que podria determinarse V(G} sin desarrollar una gratica de flujo, si se cuentan todas las instrucciones condicio-

42.
PROC(OIMIOOQ ~,

PDLeen nodoo IdenUf1cados.

-_po ........................ 100._ ....... ............... .

~ - W ........ _ . . . .
llfTlRFAClE
~""""", . . . - . . . - .

.......--

lahL..&do:

IfII'OIFACf ACCll'nI ...... - . _

M'I'....-..., ....................,

TYPf " ' {I:IOO} IlilICAiM

-.-. _.ICAUA:

-=

nales en eJ POL (para el procedimiento promedio, las condiciones com cuentan como dos) y se suma I a1 resultado. gura 14.5.
V(G) =

6 regiones V(G):oo 17 aristas - 13 nados + 2 - 6

V{G) - 5 nod05 predicado

+ 1- 6

3 . Determinese un conJunto basico de rutas linea1mente independlt_ . EI valor de V(G) indica el numero de rutas lInealmente independientes de
estructura de control del programa .

espera especificar seis caminos:

ruta I : 12!()...1 (.13

ruta 2: 1-2-10-12-13
ruta 3: 1-2-3-\0-1 H3
ruta 4: 1-2-3-4-5-8-9-2-...

ruta 5: 1-2-3-4-5-6-8-9-2-... ruta 6: 12-3-4-5-6-7-8-9-2-

cAPiTuLo

14

rtcN!CAS DE PRUEIIA til. SOfTWARE

429

Los puntos suspensivos ( .. J 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 nados predicado como apoyo para derivar los casas de prueba. En este caso, los nados 2, 3, 5, 6 Y 10 son nados predicado. 4. Preparense los casos de prueba que forzaran la ejecud6n de cada ru ~ ta en el conjunto hAsko. Es necesario seleccionar los datos de manera tal que se establezcan apropiadamente las condiciones de los nados predicado, a medida que se prueba cada ruta. Cada caso de prueba se ejecuta y compara con los resultados esperados. Una vez completados lados los casos, la perso~ na que aplica la prueba puede estar segura de que todas las instrucciones del 0 menos una vez . programa se han ejecutado por 1 Es importante observar que es imposible probar algunas rutas independientes (como la ruta I en nuestro ejemplo) por separado. Es decir. en el flujo normal del programa no puede obtenerse la combinaci6n de los datos requeridos para recorrer la ruta. En tales casos, estas rutas se ejercitan como parte de olra prueba del camino.

234

2
d 3
4

5 _";;"11...1
Gr6fica de RIJ;o
.Malriz de gr6fico

430

14.4.4 Mabices de gr6:ficas

El procedimiento para derivar la grMica de flujo e inc\uso determinar un conjunto rutas basicas es sensible a la mecanizad6n. Una estructura de datos denomi matriz de grofica resulta muy util para desarrollar una herramienta de software ayude en la prueba de la TUla basica.
Una matriz de grafica es una matriz cuadrada cuyo tamana (es decir. el mimcr de filas y columnas) es igua\ al numero de nados en la grafica de flujo. Cada f11l columna corresponde a un node identificado, y las entradas de la matriz correspal' den a las conexiones (una arista) entre nodos. En la figura 14.6 se muestra un ~ plo simple de una grarica de flujo y su matriz de grafica correspondiente [8E19OI Tomando como rererencia la figura, cada nodo en la grafica estti. identificado numeros, mientras que cada arista se identifica con letras. Una conexi6n entre nodos se indica creando una entrada de letra en la matriz. Por ejemplo, el nodo.l conecta al node 4 con la arista b. Hasta este punto, la matriz de grafica no es mas que una representaci6n de una grafica de flujo. Sin embargo, al agregar un peso de enlace a cada una de entradas, la matriz de grafica se convierte en una herramienta poderosa para luar la estructura de control del programa durante la prueba. El peso de enlace porciona informacion adicional acerca del nujo de control. En su forma mas el peso de enlace es I (existe una conexi6nj 0 0 (no existe una conexi6n) . Pem ~ pesos de enlace tambien se Ie asignan otras propiedades, mas interesantes:
La probabilidad de que se ejecute un enlace (arista).

,Otte es Ina
mcrtriz de grilfka y (omo St utiende para I$arla tllia prutba?

Elliempo 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 [8E1 901 proporciona un tratamiento completo de algoritmos mate adicionales que son aplicables a una matriz de grafica. E1 empleo de estas permite automatizar parcial 0 totalmente el ancUisis requerido para diseftar prueba.

La tecnica de prueba de la ruta basica descrita en la secci6n 14.4 es una de

tecnicas para la prueba de estructuras de control. Aunque la prueba de la ruta ca es simple y efectiva, no es suficiente por Sl misma . En esla secci6n se a~""... ". brevemente variaciones sobre la prueba de estructuras de control. Estas ensap 1a cobertura de las pruebas y mejoran la calidad de la prueba de caja blanca

14.5.1

Prueba de condlcton

La prueba de condid6n fTA189J es un metoda de disei'io de casas de prueba que ejer-

cita las condiciones 16gicas contenidas en un m6dulo del programa . Una condici6n simple es una variable booleana 0 una expresi6n relacional, tal vez precedida con un operador NOT (""). Una expresi6n reladonal toma la forma
E I <operador relacional>

E1

donde EI Y 2 son expresiones aritmeticas y <operador relacional> es uno de los siguientes: <, S , =, *" (desigual), > 0:2:. Una condici6n compuesta la integran dos 0 mas condiciones simples, operadores booieanos y parentesis. Se supone que entre los operadores booleanos permitidos en una condici6n compuesta se incluyen OR (I), AND (&) Y NOT (....). Una condid6n sin expresiones reiacionales se considera una expresi6n booleana. Por tanto, los posibles tipos de elementos en una condici6n incluyen un operador booleano, una variable booleana, un par de parentesis (que encierran una condici6n booleana simple 0 compuesta). un operador relacional 0 una expresi6n aritmetica. Si una condici6n es incorrecta, entonces por 10 menos un componente de la candici6n es incorrecto. Por tanto, entre los tipos de errores en una condid6n se inclu yen los presentes en el operador booieano (operadores booleanos incorrectos/faltantes/adidonales). en la variable booleana, en los parentesis booleanos, en los operadores reladonales y en la expresi6n aritmetica. EI metodo de prueba de condid6n se concenlra en la prueba de cada condidon del programa para asegurar que no contiene errores.

14.5.2 Prueba del tlujo de datos

El metoda de prueba del J1ujo de datos selecciona rutas de prueba en un programa de acuerdo con las ubicaciones de las definidones y los usos de las variables en el programa. El enfoque de prueba del flujo de datos se ilustra suponiendo que a cada instrucci6n de un programa se Ie asigna un numero de instrucci6n, y que ninguna funci6n modifica sus parametros 0 variables globales. En el caso de una instrucci6n con
! como numero de instrucci6n,

DEF(I) "" V'" I instrucci6n 1 contiene una definici6n de X} USO(l) '" V'" I instrucci6n 1 conliene un uso de X} Si la instrucci6n 1 es una instrucci6n if (51) 0 loop (bucle), su conjunto DEF esta vacio y su conjunto USO se basa en la condici6n de la instrucci6n I. Se dice que la definici6n de la variable X en la instrucd6n 1 esta viva en la instrucci6n /' si existe una ruta de la instrucci6n 1 a la /" que no contiene olTa definici6n de x. Una cadena definici6n usa (DU) de la variable X es de la forma IX, I, 11, donde I e
I' son numeros de instrucci6n, X esta en DEF(I) y USO(l"l. Y la definici6n de X en la

instrucci6n 1 esta viva en la 1'.

432

PARTE DOS

PRACOCA DE LA

~ 00.

SOFtWARE

Una estrategia simple de prueba de flujo de datos consiste en solicitar que

""""' ~ ,.,'",kllIjo
oorosseustrfJde
mtJnero exlffiSo

No 65 ooi5trJ

...

cadena DU sea cubierta par \0 menos una vez. Esta estrategia se denomina estnk
gia de prueba DU. Se ha mostrado que esta no garantiza la cobertura de todas las
mas de un programa. Sin embargo. s610 en raras situaciones no se garantiza que

rama este cubierta par una prueba DU, como en las construcciones if-then-elst entonces-sLno) en que la parte then no tiene definici6n de alguna variable y la

a.mdo 58 (XIJIJIxJ II)

sistllll1lJ ,ande.

te else no existe. En esta situaci6n, la rama else de la instrucci6n ifno esta n riamente cubierta por la prueba DU. Se han estudiado y comparado varias
gias de prueba de flujo de datos (por ejempio, {FRASS), (NTA88], [FRA93J) . A los

s.;, """",, ....

aienlada GIII mo IJ(1 fJreas de soItwrn .. "","*,
USOO8 de I.RI /OOfIIIIf1

tores interesados se les recomienda que consideren consultar esas referencas bliogrilficas.

-"',

-14.5.3 Prueba de bucles

Los buc!es son la piedra de toque para la gran mayona de los algoritmos im tados en software. Y aun asi, a menudo se les presta poca atenci6n mientras 2 lizan pruebas de software. La prueba de bucfes es una tecnica de prueba de caja blanca que se concentla c!usivamente en la validez de la construcci6n de buc!es. Es posible definir C\IabII ferentes clases de bucles [8EI9O): bucles simples, concatenados. anidados y tructurados (figura 14.7).

Clasesde bucles.

Budel anidodal Bodes simples Bucles concatenadO$

'~Ie.

no eslruclurodos

CAPiTuLo 14 rtoncAs DE PR\JEBA DEL SCFTWARI:

Bucles simples. EI siguiente conjunto de pruebas se aplica a budes simples, don de n es el numero maximo de pasos que pemute el bude. 1. Omitir por completo el bude. 2. 5610 un paso par el bude. 3 . Dos pasos par el bucle. 4. m pasos por el bude, donde m < n. 5. n - I , n,n+lpasosporelbude Dudes anldados. 5i se fuese a extender el enfoque de prueba de los bucles sim ~ pies a los anidados, el numero de pruebas posibles creceria geometricamente a medida que aumente el nivel de anidamiento. Esto generaria un numero poco practico de pruebas. Beizer ISEI90] sugiere un enfoque que ayudara a reducir el numero de pruebas: 1. Inidar en el bude mas interno. Asignar a tados los budes los valores mlnimos. 2. Aplicar pruebas de bude simple al mas intemo mientras se mantienen los extemos en los valores minimos del parametro de iteraci6n (como el contador de budes) . Agregar otras pruebas para los valores fuera de rango a exduidos 3 . nabajar hacia fuera, conduciendo pruebas para el siguiente bude. pero manteniendo lados los demas budes extemos en valores minimos y otros bucles anidados en valores "tipicos". 4. Segui r mientras no se hayan probado tados los budes. Budes concatenados. Los budes concatenados se prueban empleando el enfoque definido para los budes simples, si cada uno de los budes es independiente. Sin embargo. si dos bucles estan concatenados y el contador del bude I se emplea como valor inicial para el bude 2, entonces los budes no son independientes. Cuando los budes no 10 son, entonces se recomienda el enfoque aplicado a los budes anidados. BUcies no estructurados. Siempre que sea posible, esta clase de budes debe di seftarse nuevamente para reflejar el usa de las construcciones de programad6n estructurada (capitulo I I ).

Las pruebas de COla negro, tambien denommadas, pruebas de comportamiento, se concentran en los requisitos fundonales del software. Es decir, permiten al ingeniero de software derivar conjuntos de condiciones de entrada que ejercitaran por completo tados los requisitos funcionales de un programa. La prueba de caja negra no es una opci6n frente a las tecnicas de caja blanca Es, en cambio, un enfoque complementario que tiene probabilidades de descubrir una clase diferente errores de los que se descubrirlan can los metados de caJa blanca

PARTE DOS PRAc:n::A ot: 1.0'. n>DIIElIIA DEl. SOFTWARE

Las pruebas de caja negra tratan de encontrar errores en las sigulentes categt"

rias: 1) funciones incorrectas 0 raltantes, 2) errores de interfaz, 3) errores en estru.. turas de datos 0 en acceso a bases de datos extemas, 4) errores de comportamato 0 desempeno, y 5) errores de inicializaci6n y tennina. A direrencia de las pruebas de caja blanca, que se realizan al inki a del proceso prueba, las de caja negra tienden a aplicarse durante las ultimas etapas de la pnk ba (cansultese el capitulo 13). Debido a que estas desatienden a prop6sito la estn... tura de contrOl, la atenci6n se concentra en el dominic de la informaci6n. Las bas esttm disefiadas para responder las siguientes preguntas: iC6mo se prueba la validez runcional'

Pftgftfas

r. spoIIIIH las pr.tOas de c ap.

Mgra?

iC6mo se prueban el comportamiento y el desempeno del sistema? icuales clasts de entrada seran buenos casas de prueba? iEI sistema es partkularmente sensible a ciertos valores de entrada? iC6mo se aislan los Ifmites de una clase de dalos? icuales tasas de datos y cual volumen tolera el sistema? iQue erecto tienen combinaciones espedficas de datos sobre la operactor sistema? AI aplicar ttenicas de caja negra se deriva un conjunto de casos de prueba Q\k tisracen los siguientes criterios IMYE79J 1) casas de prueba que reducen , m una cuenta mayor que uno, el numero de casas de prueba adicionales que debcr seiiarse para alcanzar una prueba razonable, y 2) casas de prueba que indican acerca de la presencia 0 ausencia de clases de errores, en lugar de un error a5L do 5610 con la prueba especlfica a la mano.

'to'

"

14.6.1 Metodos gr6:ficos de prueba

EI primer paso en la prueba de caja negra es comprender los objetos~ modelad el software y la relaci6n entre ellos Una vez que se ha logrado, el sigUlente consiste en definir la sene de pruebas que verifican que "lodos los obJetos t relaci6n esperada entre si" 18EI951. Explkado de otra manera, la prueba de re empieza al crear una grafica de objetos importantes y sus relaciones y lueg< una serie de pruebas que cubran la grafica de tal manera que se ejercite cada to y relaci6n y que se descubran los errores. Para dar estos pasas, el ingeniero de software empieza creando

C&VE

I.hI ~Q 19jXesenIO

..... .......
do,.... ..

los ~ entre los cqetos de dotos Vlos de progl[lmc, 10 ~ permite o.Mr CIISOS
mociIdos CIIl esIm

una graJit:-

colecci6n de nodos que representan obJetos, enlaces que representan la relaOr: tre objetos, pesos de nodo que describen las propiedades de un nodo (como til' de datos 0 un comportamiento de estado especifico) y pesos de enlace que desc. algunas caracteristicas de un enlace.
5
En este caso ellO'mino "obJelos" se considera en el OOIltell.to rrns ampllo posible Abarca ...""'. . . .

lOS, componenles (mOdulos) tradicionaJes Y elementos onentados a objetos del software de

435

Obiaro 1---,:: f"51oc:::;.~d~;'~ E<!o",_-j

, I

(peso

en

e)

Enlace no dirigido

Per.o del nodo

Objelo
Enloce~

(valor) parolelo5

#3
o}
~
La .HIlecci6n del merlu genera ~~~~~~~~~~l Archivcl (tiempo de generoc::i6n < 1.0 sea)

" - '" Es repreUintodo como

Permite ia edition de

"~-,,,
Alributos:

Documento
b}

."'"

Contiene Dimension iniciol: valor preferencios predeterminodos Color de fondo: blanco Color de lexto: color 0
preferencios

En \a figura 14.8a se muestra una representaci6n simb61ica de una grafica. Los nodos se representan como circulos conectados poT enlaces que toman un numero
diferente de fonnas. Un enlace directo (representado por una flecha) indica que una relaci6n se mueve en una sola direcci6n. Un enlace bidirecciona/, tambien denomi-

nado enlace simetrlco, indica que la relaci6n se apliea en ambas direcciones. Los enlaces parale/os se emplean cuando se establece un numero diferente de relaciones entre los nodos de la gratica. COmo ejemplo simple, considerese una parte de la grafica para una aplicaci6n de procesamiento de palabras (figura 14.8b) donde
Objelo # 1 '" nuevoArchivo (menu selecci6n) Objelo #2 '" ventanaDocumento Objero #3 '" textoDocumento

Si se toma como referencia la figura, una selecci6n del menu en nuevoArchivo genera una ventana de documento. EI peso del nodo de ventanaDocumento proporciona una !ista de los atributos de la ventana que se esperaban cuando esta se genero. EI peso del enlace indica que la ventana debe generarse en menos de 1.0 segundos. Un enlace indirecto establece una relaci6n simetrica entre la selecci6n del menu nuevoArchivo y textoDocumento, y los enlaces paralelos indican las relaciones entre ventanaDocumento y textoDocumento. En rea!idad, tendria que generarse una grafica mucho mas detallada como precursora del diseno de casos de prueba. EI ingeniero de software deriva entonces los casas de prueba al recorrer la

grafica y cubrir cada una de las reladones mostradas. Eslos casas de prueba se seflarim en un intento de encontrar errores en cualquiera de las reladones.
Beizer fBEI95J describe varios metodos de prueba de comportamiento que graficas:

Modelado del fluJo de transacci6n. Los nodos representan pasos de alguna tr.sacci6n (por ejemplo, los pasos requeridos para hacer una reservaci6n en una aeI'I linea empleando un servicio en linea) y los enlaces representan la conexi6n I 1a creaci6n de

entre los pasos. EI diagrama de flu;o de datos (capitulo 8) se utiliza para ayudar graficas de este tipo.
Modelado de estado finito . Los nodos representan los diferentes estados que
usuario observa en el sofiware (POT ejemplo, cada una de las "pantallas" que a cen cuando un empleado lorna un pedido por teiefonO) y los enlaces representan transidones que ocurren para ir de un estado a otro. EI diagrama de estado tca 10 8) ayuda a crear graficas de este tlpo. Modelado del nuJo de datos. Los nados son objetos de datos, y los enlaces las transformaciones que ocurren para traducir un objeto de datos en otro, Por plo. el nado impuesto retenido por RCA (JRF) se calcula a partir de salario _ to (SN) empleando la relad6n IRF = 0 .62 x SN . Modelado reladonado con eI tiempo. Los nados son objetos de programa , ~ enlaces son las conexiones secuenciales entre esas objetos. Con los pesos de c:r:" ce se especifican los tiempos de ejecud6n requeridos mientras el programa se cuta. Un analisis detallado de cada uno de estos ra tener una cobertura eompleta.
m~tados

graficos de prueba se en

tra mas alia del alcance de este libro. Ellector interesado debe consultar IBEI951

14.6.2 Particton equivalente

La partici6n equNOJente es un metodo de prueba de caja negra que divide el nio de entrada de un programa en clases de datos a partir de las cuales pueden rivarse casas de prueba. Un caso de prueba ideal de manejo simple descubre clase de errores (por ejemplo, procesamiento incorrecto de todos los datos de

f" COHWO"
1m etrD:mts ,. ell" I1rrID .roo (trIOOO:zI .. II1II eI!JlII rai:JtMr. _ _ dol

teres) que, de otra manera, requeriria la ejecuci6n de muchas casas antes de (f\II observe el error general. La partieian equivalente se esfuerza por definir un cast/. prueba que descubra ciertas clases de errores, redueiendo asl el numero total dI:sos de prueba que deben desarrollarse . EI diseno de casos de prueba para partici6n equivalente se basa en una e cian de las clases de equivalencia para una condid6n de entrada. Con el uso de eoneeptos introducidos en 1a secci6n anterior, si es posible enlazar un conjun objetos mediante relaeiones sim~tricas. transitivas y reOexivas, entonces exisle clase de equivalencia \8EI95\. Una c\ase de equivalencia representa un eonjunIC estados validos y no validos para las condiciones de entrada. Por 10 general.

_ ..... ...
,.".,.""d_.

Ardl, dO.,... MSf It pIllS/un kz

_ _ .fief.

437
condici6n de entrada es un valor numerico especifico, un rango de valores, un conjunto de valores relacionados a una condid6n booleana. Las c1ases de equivalencia se definen de acuerdo con las siguientes directrices: 1. 5i una condici6n de entrada especifica un rango, se definen una (lase de equivalencia valida y dos no validas.
2. 5i una condici6n de entrada requiere un valor especifico, se definen una clase

de equivalencia valida y dos no validas.

3 . 5i una condici6n de entrada especifica un miembro de un conjunto, se definen una clase de equivalencia valida y otra no valida .

4 . 5i una condici6n de entrada es booleana, se definen una c1ase de equivalencia valida y olra no valida. Al aplicar .estas directrices para la derivaci6n de dases de equivalencia, se desarrollaran y ejecutafiln los casos de prueba para cada objeto de los dalos del dominio de entrada. Los casas de prueba se seleccionan de modo que el mayor numero de atributos de c1ase de equivaJencia se ejercila una vez.

14.6.3 An6:llsis de valores limite

Es mayor el numero de errores que se presenta en los limites del dominio de entrada que en el "centro"; par ello se ha desarrallado el ana/isis de valores limite {AVLJ como tecnica de prueba. EI AVL lleva a una selecci6n de casas que prueba los valores llmite. El analisis de valores limite es una tecnica de disefio de casas de prueba que com plementa la partici6n equivalente. En lugar de seleccionar cualquier elemento de una c1ase de equivaJencia, el AVL lleva a la selecci6n de casos de prueba en las "aristas" de la c1ase. En lugar de concentrase excJusivamente en las condiciones de entrada, el AVL tambien deriva casas de prueba del dominio de salida IMYE79j. Las directrices para el AVL son muy similares a las proporcionadas para la parti d6n equivalente:
I . 5i una condici6n de entrada especifica un rango limitado par los valares a y b, los casas de prueba deben disefiarse can esos valores, ademas de los que se encuentran apenas arriba y abajo de elias. 2. 5i una candici6n de entrada especifica diversos valores, deben desarrollarse casos de prueba que ejerciten los numeros maximo y minima. Tambien se prueban los valares ubicados apenas arriba y abajo de estos maximos y minimos. 3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ejemplo, sup6ngase que una tabla que compara presi6n y temperatura se requiere como salida de un programa de analisis de ingenieria Los casos de prueba deben diseftarse para crear un informe de salida que produzca el numero maximo (y minima) permisible para las entradas de la tabla

L CiNno puedo alOr .os de pmba M ?

438

PARTE DOS

PRACl1CA DE LA INQNIER!A

on sa'fWARE

4. 5i la estructura inlema de datos del programa tiene limites prescritos (por ejemplo, una matriz que liene un limite definido de cien entradas) debe <liseftarse un caso de prueba para ejercitar los limites de la estructura de datos-La mayoria de los ingenieros de software realizan intuitivamente eJ AVL, hasta

to grado. Al aplicar estas directrices, la prueha de Iimites estara mas completa tanto, tendrA una mayor probabilidad de detectar errores.

-8 ..... AriIIII 5~ III ~r delNdo G .... sinpIe clefeclo terror) del softwIn .. w r. . . . t:Dllla _ . . . tie I I I _ de puntD IIottnte III 6411i5 en UII entero de l' bits.. BcoheN y ws tu*o . . . . . . . . , . , . . . . SCM) IIIIanes de dOlores. U .. pruebo (ompieta del sisIerna huIiera . . . . . tllmf,,.. .... . . par nm.s tie presupuesto.

14.6.4 Prueha de tabla ortogonal

Hay muchas aplicaciones en las cuales el dominio de entrada es reiativamente tado. Es decir, e\ numero de parametros es pequeno y los valores que cada
Ira puede tomar estan c\aramente limitados. Cuando estos numeros son muy nos (por ejemplo, Ires parametros de entrada toman Ires valores discretos cada es posible considerar cada pennutaci6n de entrada y probar exhaustivamente ti cesamiento del dominio de entrada. Sin embargo, a medida que crece el nu valores de entrada. junto con el numero de valores discretos para cada elemcs prueba exhaustiva se vuelve poco prcktica 0 imposible. La prueba de tabla orrogonaJ se aplica en problemas en los cuaJes el do entrada es relativamente pequeno, pero demasiado grande para una prueba tiva. El metodo de prueba de tabla ortogonal resulta ulil sobre todo para e errores asociados con lasJaJJas de region (una categoria de error asociada con fectos de la 16gica en un componente de software). ilustrar la diferencia entre la prueba de tabla ortogonal y los enfoques mas cion ales de "un elemento de entrada a la vez" requiere imaginar un sistema elementos de entrada, X, Yy Z. cada uno de estos elementos tiene Ires vall""... ,~ cretos asociados. Hay 33 = 27 casos de prueba posibles. Phadke [PHA97] s concepto geometrico, que se ilustra en la ligura 14.9, para los posibles prueba asociados can X, Y Y Z. Si toma como referencia la figura, s6lo un el<_111 de entrada podria variar a un mismo Hempo en la secuencia que sigue cada entrada. Esteda como resultado un cobertura relativamente limitada dell dc'm;ruo, ~ ... Irada (que representa el cuba de la izquierda de la figural. Cuando se presenta una prueba de tabla ortogonal se crea una tabla ort de casas de prueba, \a cua! tiene una "propiedad de equilibria" [PHA97]. Es casos de prueba (represenlados con puntos azules en la figural estAn "uniforn" te disperses por lodo el dominio de la prueba", como se ilustra en el cuba de la de 1a figura 14.9. La cobertura de proeba en el dominio de entrada es mas co''1'. ...

.,
oro'
..00.

C&VE

[, """" hill ortogoooI permile disei'G (IISOS de

,,",000lJOI)Ortion<rllo mliximo ooberturo de jXlJebo (00 II1I1.imero rozoooble de cosos de

439

I
x~

x_

Un .Ie,.,.nto eM entroda a Ia v.2.

Tabla ortosIonal L9

Para ilustrar el usa de [a tabla ortogonal L9. considerese [a fund6n enviar de una aplicaci6n de fax. Se pasan cuatro parametros, PI, P2, P3 Y P4 a la funci6n enviar.

cada uno toma tres valores discretos. Por ejemplo, PI lorna los valores:
PI .. 1, enviarlo ahara
PI PI
:0

2, enviarlo en una hora 3, enviarlo a medianoche

P2, P3 Y P4 tam bien podrlan tomar los valores I , 2 Y 3, representando atras runciones de enviar. 5i se eligiera una estrategia de prueba "un elemento de entrada a \a vez", se especificarian las siguientes secuencias de prueba (PI, P2, P3, P4): (I , I , I, 1), (2, I, I ,
I), (3, I , I , I ). ( I , 2, I , I) . (1, 3, 1. 1), ( I , I, 2, 1). ( I , I , 3, I ). ( I , I, I. 2) Y (1, I. J, 3).

Phadke [PHA97] evalua estos casas de prueba al afinnar:

Estos casos de prueba 56[0 son utiles cuando se estfl segura de que [os parametros de prueba no interactuan. Detectaran fallas de 16gica donde un solo valor de parametro hace que eJ software funcione mal se trata dejalJas de moda/idad simple Este metodo no detecta fallas de J6gica que provoquen un mal funcionamienlocuando dos 0 mas para metros loman ciertos valores slmu[taneamente; es decir, no detecta interacciones. Por tanto. SU capaci dad para detectar fallas esta limitada

Dado el numero relativamente pequei\o de parametros de entrada y valores discretos es posible aplicar una prueba exhaustiva. EI numero de pruebas requeridas es 3 4 '" 8 1 (grande. pero manejable) Se encontrarlan todas las fallas asociadas con permutaci6n de elementos de datos, pero el esfuerzo requerido es relalivamente alto. El enfoque de prueba de tabla ortogonal permite proporcionar buena cobertura de prueba con un numero considerabJemente menor de casos de prueba que la estrategla exhaustiva. En la figura 14.10 se mueslra una tabla ortogonal L9 para la fun d6n enviar de fax. A continuaci6n se presenta la evaluaci6n de Phadke [PHA97] acerca de las pruebas aplicadas con la tabla ortogonal:

440

Tabla ortogcnaI L9.

do .......
P, I I I I

Cooo

P... a....-o. de prwbo

P, I P, I P, I

3
I

3
2

3 3
I

2 2 2

3
I

3
I

2 2

3 3 3

3
I

8
9

3
I

Oetecta Y aisla todas las rallas de modalldad simple. Una falla de modalidad

pie es un problema consistente con cualquier nivel de cualquier parametro simple PI: c)C1l1plo, si todos los casas de prueba del factor PI .. I causan una condici6n de emJf trata de una falla de modalidad simple. En eSle ejemplo, las pruebas 1,2 Y 3 (figura 14 mostran\n errores. AI anallzar la informad6n acerca de cual~ pruebas mueslran ern:K!l se identifican cuales vaJores de par.1metros causan Ia falla En esle ejemplo. al notal' las pruebas 1,2 Y3 causan enores, se aisla lei procesamiento l6gico asociado con ~ 10 ahora WI 1)1 como la fuenle del error. Este alslamlento de la falla es importanttp.H

ra cortegJ.rla
Detecta todas las raBu de modalidad doble. 51 existe un problema co",,"""

cuando se presentan niveles especlflcos de dos parametros al mi5mo tiempo, se Ie dea

mina rQlla de modahckld dobk.. Per supucslo, se trata de una indicaci6n de incom

dad de un par de valores 0 de inleracdones dai\inas entre dos parametros de

p~

Fallas muJtlmodaJes. Las tablas ortogonales (del tipo mostrado) 5610 aseguran 11: teccl6n de fanas de modalidad simple y doble. Sin embargo. estas pruebas tambi!n tan muchas (alias multmlOdales
Un analisis detallado de las pruebas de tabla ortogonal se encontrara en 1f'HAj..

DJseiio de casos de prueba

Obietivo: Ayudor 01eqlJipo de softwore a desorrollor un coniunlo completo de COSOI de
pas dilerenles de herromienk15 de pn..oebo e$t6tic:o _ .. herromienlol de pruebo bosodos en t6digo, Iengua,. prurebo especiolizodol y herromienlos de prueba en requisiloi. Los herromienlas de pruebo bosodos .. digo ocepkln t6digo fuente como entrada y rJli _ _ nos oncilisil que llevon a 10 generoci6n de COSOi de

pruebo de cojo blanca y negro.

Mllconic:a: EWI herromientol toW! en Om ompIim cdr goriIa: prwbo, eWticol Ydincimicos. Se empIeon IrM n

CAPiTuLo 14

TtcMCAS DE PRUE8A [ u SOFTWARE

441

los lengU(ljes de prvebo especiolizodos (como

10 Ioglstico para su ejecvciOn. los herramienros ,.- '_...... bosodos en requisitos oislon requisilos Ispod~ uworio y $ugieron cosos de pruebo (0 closes de Ijerciror6n los requi~tos. los herramientos de pn.Jebo interodUon con un programa de eie10 cobertum del comino, probondo los relocionados con el valor de variables espedotro monera eI Rujo de Ijocuci6n
representativas Test, desorrdloda por McCabe & Associates f-w.mccobe.com), implemenlo diverses tecnico$ de pruebo de 10 rulo derivodos de una evaluaciOn de 10 oompIejidad cidom6tico y de oIra$ metricos de software.

de soflwore escribo esqve describen coda coso de :::~:,~~:~~'~n,iingeniero

Ponoroma, desorrollodo par In!emotional Soflwore Auto mation, Inc. (www.softworeoutomotion.com). oborco un iuego complelo de herromienlas para de$OlTOlior software orientodo 0 objelol, incluidos herromientas que ayudon a di~r COSO$ de proeba y plonear pruebos.

Te5M'orb, desorroIbdo por Software Research Inc. (WW'W.

soft.com/Products), es un juego completo de herramiende prueba que oyudon 01 disena de cosos de pruebo para soIiware desarrollodo en (/C++ y .IaYo Y proporcionon soporte 0 pruebas de regresi6n.
los oulomatizodas

TNec Test Generation System, de$Orrallodo par T-VEC Technologils (www.t-vec.com). IS un coniunto de herra' mienlos que do ~te 0 pruebos de unidod, integra ci6M y validoci6n 01 oyudor en eI disei'to de C050S de pruebo empleondo informaciOn contenido en uno e'P8' ci~cociOn de requisilas orientodo 0 objetos.

La arquitectura del software orientado a objetos genera una serie de subsistemas se-

parados en capas que encapsulan las clases que colaboran entre si. Cada uno de estos elementos del sistema (subsistemas y dases) realiza funciones que ayudan a eumpEr con los requisitos del sistema. Es necesario probar un sistema orientado a objetos en diferentes niveles para descubrir errores que podrian ocurrir a medida que las clases colaboran entre sf y los subsistemas se comunican entre las capas de la arquitectura. En el aspecto estrategico, Ja prueba orientada a objetos es similar a la de los sistemas convencionales, pero es diferenle en el aspeeto tactico. Debido a que los modelos de ana1isis y diseno orientados a objetos tienen una estructura y un contenido similares al programa orientado a objetos resultante, la "prueba" podria empezar con la revisi6n de estos modelos. Una vez que se ha generado el e6digo, la prueba orientada a objetos real empieza por 10 "pequeno", con una serie de pruebas disenadas para ejercitar las operaciones de clase y examinar si existen errores a medida que una clase eolabora con otra. Cuando las clases se integran para fonnar un subsistema, se apllca la prueba basada en el uso, junto eon los enfoques basados en fallas, para ejercitar plenamente las clases que colaboran entre si. POT ultimo, se emp1ean los easos de usa para descubrir errores al nivel de validaci6n del software. El diseno convencional de casos de prueba 10 determina el concepto entrada-proceso-salida del software 0 el detalle algoritmico de m6dulos individuales. La prueba

6 Las herramientas expuestas aqui 0010 representan una muestra de esta categoria. En casi lodns los casos los nombres de las mismas son marcas regi5tradas de sus respe<:tivos desarrolladores.

ortentada a objetos se cancentra en el diseno de secuendas apropiadas de ope para ejercitar los estados de una dase. ! Oi lIRa t:rulenlltoIK

II HNA'

""" ....

em.1IIIa.b YIt"

_ _ O~llI

14.1.1 Implicactones del concepto ortentado a objetos en al dJseno de casos de prueba

A medida que la clase evoludona mediante los modelos de analisis y diseno se \ ve un destine para el diseno de casas de prueba. Oebido a que los atributos y las radones estan encapsulados, las operaciones de prueba fuera de la clase sue\eJ1 improdudivas. Aunque el encapsuJamiento es un concepto de diseno esend&. orientaci6n a objetos, representa un obstacuJo menor cuando se prueba, como dica Binder [BIN94] : "La prueba debe informar sobre el estado concreto y a de un objeto Sin embargo, el encapsulamiento lIega a dificultar la adquisidtr esta informaci6n. A menos que se proporcionen operaciones integradas para tar los valores de los atrtbutos de clase, sera dificil obtener una instanttmea ck:i tada de un objeto.
H

La herencia tambi~n plantea desafios adicionales para el disenador de

prueba. Va se ha observado que cada nuevo contexto de usa requiere una nueva ba, aunque se haya alcanzado la reutilizaci6n Ademas, la herenda multiple plica la prueba mas alia de aumentar el numero de contextos que requlens prueba [BIN94] . SI las subcJases que se convierten en instancias a partir de perc\ase se usan dentro del mismo dominio del problema, es posible usar el to de casas de prueba derivado de la superclase cuando se prueba la subcla:sc. embargo, si tsta se empJea en un contexte completamente nuevo, los casos de ba de la superclase no seran aplicables y sera necesario disefiar de pruebas

14.1.2 ApllcabWdad de metodos convenctonales de d1seiio de depruaba

Los m~todos de prueba de caja blanca descritos en secciones anteriores puedcr carse a las operaciones definidas para una clase. Las t~cnicas de flujo de
prueba de la ruta bAsica 0 de bucle ayudan a asegurar que se han probado instrucciones de una operaci6n . Sin embargo, la estructura concisa de mucn. raciones de clase hace que algunos argumenten que el esfuerzo aplicado a II ba de caja blanca podrta redirigirse mejer para probar un nivel de clase Los m~todos de prueba de caja negra son tan apropiados para los sistemas tados a objetos como los sistemas que se desarrollan can metodos conve de ingenieria de software. Como ya se indic6 en este mismo capitulo, los "". , . usa praporcionan informaci6n uti! para el diseiio de pruebas de caja negra das en el estado IAMB95J .

Un concepto de orientaci6n a objet.os que debe usarse con extremo cWdado.

cAPiTuLo 14 1tcNtc.As D PRUE8A DEl. SOFTWARE

14.7.3 Prueba basada en fallas8

443

E! objetivo de la prueba basada en fallas dentro del sistema orientado a objetos es disefiar pruebas que tengan una alta probabilidad de descubrir posibles fallas. Debido a que el producto 0 sistema debe cumplir con los requisitos del ciiente, 1a planeaci6n preliminar requerida para realizar la prueba basada en fallas empieza con el modelo de! ana.lisis. La persona que aplica la prueba busca fallas posibles (es decir, aspectos de la impJementaci6n del sistema que generen defectos). Detenninar si existen estas fallas requiere disefi.ar casos de prueba que revisen el disefi.o 0 el c6digo. Por supuesto, la efectividad de estas tecnicas depende de la manera en que las personas que aplican las pruebas adviertan una (alia posible . 5i las fallas reales en un sistema orientado a objelos se consideran poco posibles, entonces este metodo en realidad no es mejor que cualquier tecnica de prueba al azar. Sin embargo, si los modelos de analisis y disefi.o arrojan luz sobre 10 que tal vez este mal, entonces la prueba basada en fallas encontrartl una cantidad importante de errores con gastos relalivamenle minimos de esfuerzo. La prueba de integraci6n (cuando se aplica en un contexto orientado a objetos) busca fallas en llamadas a operaci6n 0 en conexiones entre mensajes. Tl"es tipos de fallas se encuentran en este contexto: resultado inesperado, operaci6n incorreclal mensaje empleado, invocaci6n incorrecta. Para determinar las fallas a medida que se invocan las funciones (operaciones), debe examinarse el comportamiento de la operaci6n. La prueba de integraci6n se aplica a los alributos y a las operaciones. Los "comportamientos" de un objelo los definen los valores que se asignan a sus atributos. La prueba debe ejercitar los atributos para detenninar si ocurren valores apropiados para distintos tipos de comportamiento de objeto. Es importante observar que las prueba de integraci6n tratan de encontrar errores en el objeto ciiente, no en el servidor. Explicado en terminos convencionales, el eje de la prueba de integraci6n es detenninar si existen errores en el c6digo que llama, no en el c6digo llamado. La Hamada a la operaci6n se usa como una pista, una manera de encontrar los requisitos de prueba que ejercitan el c6digo que llama.

"Sf st quitre 'f espera que un ptOtrDma funciane, 10 mirs probable es Clue Sf yea un Pf09I"UITICI fundDoondD (y que se pctSIII pDf alto las folios): (ell K ..... ,01.

tk la secci6n 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 c.:omponente. testlng Esta adaptaCKln se incluye con el penniso de! autor Para conocer mayor infonnaci6n sobn: estos temas ronsu!tese IMAR94 1. Debe observars.e que las tecnicas analizadas de las ~cclones 14 7 3 a 14 16 son aplicables al software convencional

...
14.7.4 Casos de prue ba y jerCD'quia de close
La herencia no obvia la necesidad de una prueba completa de Lodas las clases de"

vadas. En realidad, lIega a complicar el proceso de prueba. Imaginese la siguientr tuaci6n. Una clase Base conliene las operaciones heredado( ) y redejinido( ). Una

se D erivado define redeflnido( ) para que sirva en un contexte local. Hay pocas

.,
!IlII

das de que debe probarse Derivedo::redefInIdo( ) porque representa un nuevo dism

un nuevo c6digo. Pero ,debe probarse de nuevo OerivMJo::heredado{ )? Si Derivado::her.o.do( ) llama a redejinidO( ) y eJ comportamiento redefinido(

~~

...... ..... ""

C&VE
.."

mse de Ime, DIll

sa tendni que JloOOf

...

cambiado, es posible que Derivado::t..dado( I maneje err6neamente el nuevo portamiento. Por tanto, se necesitan nuevas pruebas aunque no hayan cambi

disefio ni el c6digo. Sin embargo, es importante observar que s610 es posible zar un subconjunto de todas las pruebas de Oarivado::hwedado{ J, Si parte del disd'
el c6digo de hcredodo( ) no depende de redcfinido( ) (es decir, no 10 llama a digo en la clase derivada. Baae::redefinkjoU y o.iwdo::redefinido son aperaciones distintas con diferentes cificaciones e implementaciones. cada una tendria un canjunto de requiSlttw prueba derivados de la especificaci6n y la implementaci6n . Esos requisitos de ba revisan (alias posibles: (alias de integraci6n, de condici6n, de IImites, etc. Sin barga. es probable que las operaciones sean simi lares; sus canjuntos de requade prueba

et

IOIosm...,

ningUn c6diga que la lIame indirectamente), es innecesario probar de nuevo ese

_~oIo.

.se superpondran. Mientras me}or sea el diselio orientado a objetos

yor sera la superposici6n. Es necesario derivar nuevas pruebas exclusivamente los requisitos de Derivado::recktflOido( ) que no se satisfagan con las pruebas de

" ..........(1.
En resumen, las pruebas de Bese::redefUdo{ ) se aplican a abjetos de la clase
~.

Las entradas de prueha son apropiadas para las clases de base y derivadas

ro los resultados esperados podrian diferir en la clase derivada.

14 .7.5 Prue babasada e n escenarios

La prueba basada en fallas soslaya dos tipos importantes de errore5: I) especi.. ciones incorrectas y 2) interacciones entre subsistemas. Cuando ocurren errortS ciados con especificaciones incorrectas, el producto no hace 1 0 que el cliente

.,

reo Podrla hacer 10 incorrecto, u omitir funcionalidad importante. En cualquier se merma la calidad (el cumplimiento de los requisitos). lDS errores asociadas las interacciones entre subsistemas ocurren cuando el comportamiento de un sistema crea circunstancias (como eventos 0 flujo de datos) que causan 1a ~ olro subsistema.
La

~~

.. ..... -.....La prueba iII5IIOO !Ill I5CIIIIios desobi6

C&VE

prueba basada en escenarios se concentra en 10 que hace el

usuario. no d

ducto. EsIO significa que se deben capturar las tareas (mediante casos de uso) usuario tiene que realizar y luego aplicarlas, junto can sus variantes, como p Los escenarios descubren los errores de interacci6n. Pero esto se logra si 101 sos de prueba son mas complejos y realistas que las pruebas basadas en fallas

..... ClII.

pruebas basadas en escenarios tienden a eJercitar varios subsistemas en una sola prueba (los usuarios no se limilan al uso de un subsistema a la vez). Como ejemplo, conslderese el diseiio de pruebas basadas en escenarios para un editor de texto mediante la revisi6n de los slguienles casos de uso infonnales:
Case de uso: Corregir d borrador final.
Antecedentes: Es comun que se imprima el borrador "final". se lea y se dcscubran algunos errores molestos y confusos en la imagen en pantalla Este caso de uso describe la secuencia de eventos que se presenta ruando ocurre esto.
I.

Se imprime tode eI documento.

2. Se recorre el documente. cambiando ciertas paginas

3. A medida que se hacen cambios, se imprime pagina por pagina.

4. A veces se imprime una serie de paginas.

Este escenario describe dos casas: una prueba y necesidades especlficas del usuario. Las necesidades del usuario son obvias: I) un metoda para imprimir paglnas individuales, y 2) un metodo para imprtmir un rango de paginas. A medida que se aplica la prueba, debe probarse la edici6n despues de imprtmir (ya la inversa). La persona que apliea la prueba espera descubrir que la funci6n de impresi6n causa errores en la funci6n de edici6n; es decir, que las dos funciones del software no tienen la independencia apropiada.

caso de uso: Imprimir una nueva cop/a.

Antecedentes: Alguien pide al usuario una nueva copia del documento. Debe imprlmirse.

Se abre el documento.
2 Se lmprime. 3. Se cierra el documento.

Una vez mas, el enfoque de la prueba es relativamente obvio, con la excepci6n de que este documento no aparece de la nada. Se cre6 en una tarea inicial. iAqueJla tarea afecla a esta? En muchos editares modemos, los documentos recuerdan c6mo se imprimieron por ultima vez. Como opci6n predeterminada, se imprimen de la misma manera la siguiente ocasi6n. Despues del escenario correglfel borradorfinal, can s610 seleccionaT "Imprimir" en el menu y hacer elie en el bot6n Imprimir del cuadra de dialogo se imprimira de nuevo la ultima versi6n corregida. De modo que, de acuerdo can el editor, el escenario correcl o debe tener este aspecto:
Case de usc: Impnmir una nueva cop/a
I. Se abre el documento. 2. se selecciona "lmprimir" en el menu

...
3
4. se revisa 5i esta

Impnnuendo un rango de pagmas. 51 es asi. se hace elie para

miT todo eJ documento,

se hace elie en eJ bot6n Imprimir

5. Se derra el documenlo
Perc este escenario indica un posible error de especificaci6n. EI editor no hace lc-

e! usuario espera razonablemente que haga Los clienles con frecuencia ami revisi6n indicada en el paso 3, Se sentimn molestos cando vayan a la impresc.
encuentren una pagina cuando querian 100. Los clientes malestos seriaiartm e..de especificaci6n

Un disenador de casos de prueha podria pasar por alto esta dependencia ..

naT Ja prueba, pero es probable que el problema surja durante la prueba. EI

sable de esta tendrla entonces que enfrentarse a la probable respuesta: Hias;i

pone que debla fun cionar!"

14.7.6

Estructuras de superficie y de fondo en pruebas

Estrocturo de superjicie es la estructura observable extemamente de un P"'I!'I=-

oro.~

'~

orientado a objetos. Es decir, la estructura que resulta inmediatamente obvia usuario final. En lugar de realizar funciones, se Ie dan objetos detenninados ~ rio de muchos sistemas orientados a objetos para que los manipule. Pero ra que sea la interfaz, las pruebas aun se basan en tareas de usuario. La cap estas tareas requiere comprensi6n, observaci6n y comunicaci6n con usuari<v sentativos (y con todos los usuarios que no 10 son que valga la pena tamar en Seguramente habra algunas diferencias en los detalles. Por ejemplo, en ... rna convencional con una interfaz orientada a comandos, el usuario podria dos los comandos como lista de verificaci6n de una prueba Si no existen de prueba para ejercitar un comanda, es probable que la prueba soslaye al reas del usuario (0 que la interfaz tenga comandos inutiles). En una interfa... tada a objetos el responsable de la prueba jXXIrfa emplear todos los ob)etl una lista de verificaci6n de una prueba. Las mejores pruebas se derivan cuando eJ disei'lador observa el sistema manera nueva 0 poco convencional. Por ejemplo, si el sistema a el prodUO una interfaz basada en comandos, las pruebas mas completas se derivartm ser'iador del caso de prueba pretende que las operaciones sean independientL. objetos. Deben plantearse preguntas como: ~ tEl usuario deseara usar esta ope (que 5610 se aplica al objeto esdtner) mlentras lrabaja con la impresora?"' . portar cual sea el estilo de la interfaz, el diseflo de casas de prueba que eter_ estructura de superficie debe usar obJetos y opera clones como pistas que a tareas omitidas La estructura a fonda representa los detalles tecnicos intemos de un prr" orientado a objelos Es decir, la estructura que se comprende al e",mina" .1 ..... el c6digo, 0 ambos. La prueba de estructura de fondo esta diser'iada para eJer,pendencias, comportamientos y mecanismos de comunicaci6n que se han

C&VE
""",,do
estrud\ltl de ~

~""'o.""",, de cqo rl8!1O. 1.0 de

eslnKlI.\'Q de fondo es simiklr 0 kl de c* bIooco.

44'
cida como parte del modelo de diselio (capitulos 9-12) para el software orientado a objetos. Los modelos de amllisis y diseilo son la base de 1a prueba de estructura de fonda.
Por ejemplo, el diagrama de colaboraci6n UML 0 el modele de despJiegue describe
las colaboraciones entre objetos y subsistemas que tal vez no sean visibles extemamente. El disenador de casos de prueba pregunta entonces: .i,hemos capturado (como prueba) algunas tareas que ejercitan ta colaboraci6n indicada en el diagrama de

colaboraci6n? Si no es as!, ipor que?

........... 1Ds.-rom Ii los mrmtr1a en aime.:

En el capitulo 13 se ind1c6 que Ja prueba del software empieza por 10 "pequeno" y lentamente avanza hacia 10 "grande". se prueba en el pequeno entorna de una sola clase y los metodos que estan encapsulados en [a clase. La prueba aleatoria y la partici6n son metodos que se emplean para ejercitar una clase durante una prueba
orientada a objelos

IKIR94J.

14.8.1

Prueba aleatoria para closes orientadas a objetos

Para ilustrar brevemente estos metodos, imaginese una aplicaci6n bancaria en que una clase Cuenta tiene las siguientes operaciones; aMT(), configumT( ), deposiWT( ), re-

Uml(). saldal( ), sumar(). IimiteCredito() y cerrar() [KIR94J. 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 despues de que se han completado todas las operadones) relacionadas con la naturaleza del problema. Aun con estas restricci ones, hay muchas permutas en las operaciones. El hislorial de comportamiento mlnimo de una instancia de Cuenta incluye las siguientes operaciones:

Eslo representa la secuenda de prueba minima para Cuenta. Sin embargo. podna presenlarse una amplia variedad de comportamientos distintos dentro de esta secuencia.

Es posible generar at azar varias secuencias diferentes de operaciones. Por ejemplo: Caso de prueba r ,: abriroonfiaurerdepoeii.dtpoIffllll'uldatsumar .... fitar08IT8t caso de prueba r2: IbMr' confiaurar ' dapoaitar' rati'I" dapolita, ' aalda, UmltaCr.dl-

to

retira,

0IIT8I'

Estas y otras pruebas de orden aleatorlo se aplican para ejercitar diferenles historiales de instancias de cJase.

...

PARTE DOS

PRAciK::A DE LA INGENlERfA Dl!l SOfTWARE

HOGARSEGURO

a. _

1._

CubiaAo de Sftokiro

........... "' ... ~ .. He .................... . .

&.alll _Jcnie'lShakim. ~d.IpJipo .~ . . ~ Hagar5Igwo que est6n trobojaodo .... do..- do ....... porn ~ ~""'"
~

okI>ooodo

IMuestro 0 Jamie ro. siguienIM.., I

*2: M1tIww'probIr'

dll)

(lMrr....... .

#3;tJ-1"
I

#4: . . . . . . .1111 . . . ' . . . . . . ' . . .1 ., r'. tit _. L .CIbk> algunos pruebm para 10 da- ..... -.: oe;orr. .. Ii CIIIftItII." lit iaIInd6n. , ..... (Iguro 11 A1 )'Q - . . 10 que permi/e oc-

Ia.ca II
c.IO a

tacb Ie. aLj.b d. ......, pcro 10 Mw:i6n de .... I' I fPIIa Iaw...iauda ccn .lot

rTe

eI hisloriol

,_a
onl8s
SOl"

devso~'2

. . . . (lor.;. . . .)!: CIaro, .. 1o que Ie permitll ogre. . . . . . . . 0. . . .1'0'

de que !Ie IJICthot . , menlO" de wror, .~

n cabo IIIino 0. ~ troanfII'O. Mr'MI una in-

Yluego If<*:I d.1ewIo. tHo.

. . . . . . euc*oopeAlCiol_ '-1L ocfMJr1J, d.sodfvor{) '1,..-.0. ........ CJII8 un . . . . *9' 10 pos;bllidod de

be J
Shakiro: En ~ no. En N.I _ _ do to que real...- ~ H \'01" h.nciono COITIO cW.io. Si .. p _ _ -.0

..... r..,...~.-t~ITlOI'IIri:). a
JIasA ......... COiitpOibl . . 1ID
IIww

........ _.Una_.......,.poodo ..... , ....

_ . . . . . pootaIGdo uno c:ondicioo de abmo. O' .......... UID......ur..,.,.de prwbo que
. . . . . a ............ MCWncia.1
. . . . . . . . ., . . . . ,. . . . . ' t

......

...... Eso fUnclOlicri. lpero '*- que probor m6s

"..bao11 """"" do ~L ........_ _ ~ de.m)r, $i nolo"... . . . . . _ _ error en 10 operoci6n detadiwor. Jo __ E,,,,,,",,, SOlo _ _'P' .. _ ..... bot. ---. que op&ig:n. a codo Iipo . . . . . . >do _ ...... poodo _ . ._ .........."" d,endo del tipo de MAIOI'. Shcddn:t: No .. ~ h..1f plan

14.8.2 Prueba de partici6n al nivel de close

La prueba de partici6n reduce el numero de casos de prueba requeridos para

tar la c1ase de manera muy paredda a la partid6n equivalente (secd6n 146..:el software convencional. La entrada y la salida se ordenan en categorlas y SiC nan casos de prueba para ejerdtar cada ca tegorla iC6mo se derivan las de partici6n'

,C_

..........
pOIeba IStim

.do

La partki6n basada en eI estado ordena en categorlas las operaciones de

partir de su capacidad para cambiar el estado de la c\ase, Si se piensa una en la clase Cuenta, las operaciones de estado induyen depositor( ) y retirarr tras que las que no son de estado incluyen saldar( ), sumar( ) y limi(<!Cret/J pruebas est~n disenadas de manera que ejercitan por separado las operac' cambian de estado y las que no 10 hacen. Por tanto,

IiYtC4I dIM?

caw de prueba PI:

abrir~depo&it8tdepoeit.,.tirerretftrcemw

caso de prueba p~ abrir~depoeitarIIUJI'WlirniteCNOrioretiNr ~

"9
El caso de prueba PI cambia de estado. mientras que el caso de prueba Pl ejercita
operaciones que no cambian de estado (aparte de las que se encuentran en Ja se~ cuencia de prueba minima) .
La partici6n basada en atributos e rdena en ca tegorias las operaciones de c\ase ba-

sadas en los atributos que utilizan. En el casa de la clase Cuenta, los atributos sel

der y limiteCredito se emplean para definir particiones. Las operaciones se dividen en

tres particiones:

1)

operaciones que usan IimiieCredito, 2) operaciones que modifican

IlmlteCredito, y 3) operaciones que no usan ni modifican limiteCredito. Entonces se dise-

nan secuencias de prueba para cada partici6n.

La

partici6n basada en categoTias ordena en categorlas las operaciones de clase

con base en Ja funci6n generica que cada una realiza. Por ejemplo, las operaciones de la clase Cuenta se organizan en operaciones de inicializaci6n [abrir( ), configuraT( )], operaciones computacionaies [depositar( ), retirar( )), consuitas [sa/dar( ), sumar( ), limiteCredito( )] y de terminaci6n [cerrar( )]

EI diseno de casas de prueba se vuelve mas complicado cuando empieza la integraci6n del sistema orientado a objetos. En esta etapa debe empezar la prueba de colaboraci6n entre clases. Para ilustrar la "generaci6n de casos de prueba de interclase" [KIR94], se expande el ejemplo del sistema bancario presentado en la secci6n 14.8 para que incluya las clases y colaboraciones indicadas en la figura 14.11. La direcci6n de las flechas en la figura indica la direcci6n de los mensajes. Y las etiquetas individuales indican las operaciones que se invocan como consecuencia de la colaboraci6n indicada por los mensajes. Como en la prueba de clases individua les, la prueba de colaboraci6n entre clases se I!eva a cabo al aplicar metodos aleatorios y de partici6n, ademas de pruebas basadas en el escenario y de comportamiento.

14.9.1 Prueba de clases mUltiples

Kirani y Tsai [KIR94] sugieren la siguiente secuencia de pasos para generar varios casas de prueba aleatorios de clases multiples: I. En cada clase cliente use la lista de operaciones de clase para generar una serie de secuencias de pruebas aleatorias. Las operaciones enviartm mensajes a otras clases del selVidor. 2. En cada mensaje generado, determlnese la clase colaboradora y la operaci6n correspondiente en el objeto selVidor. 3. En cada operaci6n del objeto servidor (invocada por los mensajes enviados desde el objeto cliente) determlnense los mensajes que transmite. 4. En cada uno de los mensajes. determinese el siguiente nivel de operaciones invocadas e incorp6relos en la secuencia de prueba.

450

Dlag>amad8

d e c",,", _oW><>

,d.po~lor

farjetaln--ooo
retirOf

~ficorCuento

-ma.t'oIitica
Kllieilorfl:etiro ioIicilorOej:xilo inJ.::.Cuow.to

_.

_cadOn

bancaria (adaptoclo de

~~;o ~

"""'"' do

(KIR94D.

.- ..................
.... incol'fslatus
~lDepolilo

15IoIIJsCuetlio lerminor

C""", A.-.....

obrirCuenlO deposiloln~~ cerrorC..,.,,1o

......

I
I

ouk>rilOtTOllelo desovtorizor

ImprimirEiIodoCuenia IMdnlolorjelo ob"I*"Mon!oEMct;\/O

.....
retifor

limiMCredilo
hpoCuenlo

I I
C.",.

dotpcnilor cenol

C_

Ivol~1
a

Como ejemplo IKIR94J, considerese una secuenda de operaciones para Banco relacionada con una cJase cajeroAutom atico (figura 14.11):

verif"108I'Cuenfl o ...ritl(l8rH IP (1~'rPoImo. d ofudRetlro I I toIIcit.,o.poaito I"'_"~

"""'lor
Un case de prueba aleatoria para la clase Banco seria:
caso de prtH:ba rJ .. ~ ' ....nficerNIP soIoif...o.po.ito

COnsiderar a los colaboradores que partidpan en la proeba requiere tamar m

La los mensajes asociados con cada una de las operaciones indicadas en eI

prueba r.l _ Banco debe coIaborar con infovaUdadon para ejerutar virijica

vcrijicarNJP( ). Banco debe colaborar con Cuenta para e}ecutar soJidtarDeposlro.o tanto, se tiene un nuevo caso de prueba que ejercila estas colaboraciones:

Coso de prueba r4 = ~ (~t.lnfuVRIidecIonI wrfficarNlPBanoo [validwNlPlnfcwalldllOionl oeoIkitarDepoeito [depoeitareuent.)

EI enfoque para la prueba de partid6n de clases multiples es similar at empleado para la de clases individuales. Como se analiz6 en Ia secci6n 14.8.2 mete a partici6n una sola clase. Sin embargo. se expande la secuencia de para inc\uir las operaciones invocadas mediante mensajes a las c\ases que ran. Un enfoque altemo lleva a cabo la particiOn de las pruebas con base CI terfaces de una clase delerminada. 5i se lorna como referenda Ja flgura 14 I se Banco redbe mensajes de las clases cajeroAutomatico y cajero. Por metodos denlro de Banco se prueban al particionarlas entre las que s,,,,,,:n ..... roAutom atico y a cajero. La partidOn basada en el estado (secciOn 14 8.2 para reflnar aun mas las particiones.

cAPiTuLo 14

1EcNlCAS DE PRUEBA DEl. SOFTWAR'I:

45'

14.9.2 Pruebas derivadas de modelos de comportamiento

En el capitulo 8 se analiz6 el usa del diagrama de estado como modelo para representar el comportamiento dinamico de una clase. EI diagrama de estado de una clase ayuda a derivar una secuencia de pruebas que revisa el comportamiento dinami co de la clase (y las clases que colaboran con ella). En la figura 14.12 [KIR94] se muestra un diagrama de estado para la clase Cuenta que ya se analiz6. 5i se observa, las transiciones in[dales recorren los estados vadar 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 cuentaMueT1a, respectivamente. Las pruebas que se disefien deben cubrir todos los estados [KIR94] . Es decir, las secuencias de operaci6n deben lograr que la clase Cuenta haga una transici6n a todos los estados pennisibles:
abrif 0COIlfigurCuenla 0depor:ilaf(inicial) 0relifar(finalJ 0cetTar

Debe notarse que esta secuencia es identica a Ja secuencia de la prueba minima tratada en la secci6n 14.9.1. La secuencia de la prueba adicional se agrega a la sucesi6n minima,

Caso de prueha 5,: Caso de prueha 5.. :

abrir 0configufarCuenta 0depositaftinicialJ 0dapositaf 0saldar 0ac rediter 0retlrar( final) 0cetTat abrir 0configutatCuenta 0depos iter(iniciel) 0depos itar 0retirer 0ln(oCusnta l'8nraf{final) 0cetTer

Es posible derivar atm mas casas de prueba para asegurar que todos los comporta-

mientos de la clase se hayan ejercitado adecuadamente. En situaciones en que el comportamiento de la clase da como resultado la colaboraci6n can una 0 mas clases, se utili zan varios diagramas de estado para registrar el flujo del comportamiento del sistema.

1---::__::-_-1 configurar
Abrir , -_ _J configuror Cuento

,-C _',~_"'_'
depo$itor [iniciol) depo$itor

soldor Credito infoCuenlo

h"aboiando Cuento

retirar

retiror [finol) Cuento

C~,

m_

...2

EI mooelo de estado puede recorrerse de una manera ~ primero-en -and'lml [MGR94). En este contexto, primero-en-anchura indica que un caso de prueba ejerCila una transici6n. Cuando debe probarse una nueva transici6n 5610 se u transiciones probadas previa mente.

Imaginese que el objeto l'arjetaCredlto es parle del sistema bancario. EI inidal de T'arjetaCredito es mdefinido (es dec!r, no se ha proporcionado un n ro de larjeta de erediIO). T'ras leer la tarjeta durante una venta, el objeto lorna ,... lado ckJinido; es decir, se definen los atributos numero, ...jet. y fechI ~ to con los identificadores especificos del banco. La tarjeta de credito es rr:r
cuando se Ie envia para autorizaci6n. y es aprobada cuando se recibe la au ci6n. La transieion de TarjetaCredito de un estado a otro se prueba derivando 50S de prueba que causen la transici6n. Un metodo primero-en-anchura para esIr de prueba no ejercitarla remitida antes de indefinida 0 definida. En este caso. usalYi sicianes que no se han probado y, por tanto. violarla el criterio primero-en-anchla

Los metodos de prueba analizados en secck>nes anteriores suelen aplicarse eI dos los entomos. las arquitecturas y las aplkaciones, pero en ocasiones se cionan directrices y enfoques unicos para las pruebas. En esta secci6n se a las directrices para prueba de los entomos, las arquitecturas y las aplicadoncs cializadas que suelen encontrar los ingenieros de software.

f'rONKlOS.

14.10.1
Las

Pruebas de interfaces gr6:ficas de usuario

dt,..

Us.s. IRI rsIrotIgiD

siniu"

,.,.,., (S.,,'"

~odl!'

." ..",.In". ........

14.8) fDOlfWD

Interfaces grdficas de usuario (GUI, por sus siglas en Ingles) plantean d teresantes a los ingenieros de software. Debido a los componentes reutili zabies porcionados como parte de los entomos de desarrollo de la GUI, la creaci6n de terfaz de usuario consume menos tiempo y es mas precisa (capitulo 12) , ?em ~ rna tiempo ha crecldo la complejidad de las GUI, 10 que dificulta mas el di
ejecuci6n de casas de prueba . Debido a que muchas GUI modemas tienen un aspecto y un modo de u~" res. es posible derivar una serie de pruebas eslandar. Las graficas de m estado finito se usan para derivar una serie de pruebas que ejerciten obje",. ficas de datos y programas que resultan relevanles para la GUI. Debido al gran numero de pennutaciones asociadas can las operaciones GUI, la prueba debe reducirse empleando herramientas automatizadas. En mas aflos ha apareddo en el mercado una amplia serie de herramientas de

,"'"=

.---,...
i

bltI . . . . . 'IM

-9
t

de GUI. Para un mayor analisis al respecto consulte el capitulo 12.

/111."'.
Ii _

14.10.2 Prueba de arquitecturas cUente/ servidor

La arquitectura cliente /servidor representa un importante

prueban el software. La naturaleza distribuida de los entamos cliente /se

cAPiTuLo 14

rtr..:N1CAS DE PRUEBA [l. s:n'WAIZE

453

aspectos de desempefio reladonados can el proceso de transacd6n, la posible presencia de varias plataformas de hardware diferentes, la complejidad de la comunicaci6n en red, la necesidad de servir a varios clientes desde una base de datos centralizada (0, en algunos casos, distribuida) y los requisitos de coordinaci6n impues~ tos al servidor se combinan para que la prueba de las arquilecturas de software cliente/servidor resulle considerablemente mas diflcil que la prueba de aplicaciones independientes. En realidad, estudios recientes de la industria indican un aumento importanle en el tiempo y costo de la prueba cuando se desarrollan entornos clien~ te/servidor.

1n aI lema de los pruebas exisle una buena dosis de sim ilitud entre los 5istet1H15 traditiooDl y diente/servidoI:: kdoy-En general, la prueba del software c1iente/servidor se presenta en tres niveles diferenles: 1) aplicaciones de ciiente individuales se prueban en una madalidad "des~ conectada"; la operaci6n 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 explkita; 3) se prueba tada la arqui ~ tectura c1iente/servidor, inc1uida la operaci6n y el desempeflo 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 funclonalidad de la aplicaci6n. La funcionalidad de las aplica~ dones de clienle se prueba empleando los metodos analizados en este capltu~ 10. En esencia, la aplicaci6n se prueba de manera independiente. Pruebas de servidor. Se prueban las funciones de coordinaci6n y manejo de datos del servidor. Tambien se considera el desempeflo 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 clienle para asegurar que los dalos se almacenan, actualizan y recuperan apropiadamente. Tambien se prueba la funci6n de archivado. Pruebas de transacci6n. 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 detenninar si es correcto el procesamiento y en aspectos del desempeflo (pOT ejemplo, tiempos de procesamiento de las transacciones y volumen de estas). Pruebas de comunicaciones d e r ed. COn estas pruebas se verifica que la comunicaci6n entre los nodos de la red ocurre de manera correcta y que el paso de mensajes, las transacciones y el trafico de la red relacionado se realiza sin errores. Tambien es posible realizar pruebas de seguridad de la red como parte de estas pruebas.

4..
Para completar estos enfoques de prueha, Musa (MUS93] recomienda el desam::AI de perfiles operacionales derivados de escenarios de usa de cliente / servidor. 9 Un pttfil operacional indica la manera en que diferentes tipos de usuarios interoperan em el sistema cliente/ servidor. Es dedr, los perfiles proporcionan un "patr6n de uso aplicabJe al disei'io y ejecuci6n de las pruebas.

14.10.3 Prueba de la docwnentac1on y las tunc10nes de ayuda

El tennino proeba del software evoca imagenes de grandes cantidades de casas prueba preparados para ejercilar los programas de c6mputo y los datos que ma~

Ian. Si se recuerda Ja definici6n de software presentada en eJ primer capitulo de lS te libra, es importante observar que la prueba tambien debe extenderse al tercer ~ mento de la configuraci6n del software: la documentaci6n.
Los errores en la documentaci6n son tan devastadores para la aceptaci6n del grama como los errores en los datos 0 el c6digo fuente. Nada es mas fruslrante seguir una guia de usuario 0 una funci6n de ayuda en linea con tada pukritud y tener resultados 0 comportamiento que no coinciden con los descritos en la dQa. mentaci6n. Por esc la prueba de la documentaci6n debe ser una parte signifi de cualquier plan de prueba del software.
La prueba de la documentaci6n se aborda en dos fases. E.n la primera, revisiOl"

inspecci6n (capitulo 26), se examina la claridad editorial del documento. E.n la gunda fase, prueba en vivo, se emplea la documentaci6n junto con el programa

~
que
I.e

INFORMACION

Prueba de docwnentadon

tEl di~ del documenlo (formoto, tipo de tetro,..grios, im6genes,) es opropiodo poro oomprencler '1_

Los sigvienles pregunlas deben respondene dUlllnle 10 pnJeba de documenlaci6n, de fun ti6n de oyvdo, oombos: ala documentoci6n describe coo exoctitud 10 mIlne!ll en

milor riJpidomenle 10 inb-moci6n~

tTodos

reolizo woo modoIidod de

U$O~

iEs exoctCllo destripci6n de todo seo:vencio de inlerocciones~

io1. men$Oies de error del ~re que wd. pliegon poro eI vSUClrio 6!J6n descrilos coo mas en eI documenlo~ tLas occiones que <:!eben ernpreror $e como COfl$eO.leOCio de un men$Oie de error esD
romentre delineodos'
$e

21m ejemplos $01"1 exodos' ala Iemlinologro, los desaipc:iones de menu y los respuestCI5 del sislema $01"1 coosistentes coo eI progromo recM
tEs reolmenle f6cillocolizor uno guio dentro de 10 docvmentociOn'

Si

U$On

los Yinculos de hipertextro, 2$01"1 exodos J

compIetos~

Si $e U$O eI hipertexlo, tel di~ de 10 novegac::D_ opropiodo pam 10 informoci6n requeridol

La uniro IT1CIf"IeIll vioble de responder 0 eslos preg!.da hocet- que un lertero (por ejemplo, olgunos USUClrlos cionoclc) pruebe 10 dcxvmento<::i6n en eI toniexlo cW del progromo. Se hobron de indicor todos los di~

tEl U$O de 10 documenlcJci6n focililCllo detection y res0lutiOn de errores'? tEl contenido y eI rndite del documenlo $01"1 exodos y
cornpIetosl

tios y clefinioe los Oreas debiles 0 ombigUCIs del

10 poro uno posible reescriluro.

9 Debe obsoI';rvarse que \os perfiles operaa onaJes pueden aplicarse para probar todos los tipos
quitecturas del sisl:ema, no s610 La clienteJservidor.

455

14.10,4 Prueha de sistemas de ttempo real

La naturaleza asincr6nica, dependiente del tiempo, de muchas aplicaciones en tiempo real agrega un elemento nuevo cy dificil en potencial a la mezcla de pruebas: el tiempo. El disenador del caso de prueba no s610 debe considerar los casas de prueba convencionales, sino tamblen el manejo de eventos (es decir, el procesamiento de interrupciones), la temporizaci6n 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 esta en un estado produciran un procesamiento apropiado, mientras que los mismos datos proporcionados cuando el sistema este en un estado diferente provocaran 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 capias (en el estado copia!') . Si estas mismas interrupciones del operador se ingresan cuando el equipo se encuentra en el estado alasco, se perdera la pantalla de visualizaci6n del c6digo de diagn6stico (indicando la ubicaci6n del atasco) , 10 que representa un error. Ademas, la intima relaci6n entre el software en tiempo real y su entorno de hardware llegan a causar problemas en la prueba. Las pruebas del soft.ware deben considerar el impacto de las fal!as de! hardware en el procesamiento del software. Resulta extremadamente diflcil simular estas fallas de manera realista. Los metodos exhaustivos de disefio de casos de prueba para sistemas en tiempo real slguen evolucionando. Sin embargo, es posible proponer una estrategia de cuatro pasos:

flllna

I,

oIs

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 disefian y ejecutan pruebas convencionales para cada tarea. (Cada tarea se ejecuta de manera independiente durante estas pruebas.) La prueba de tareas descubre errores de l6gica y funcionamiento, pero no de tiempo ni de comportamiento.

Prueba de comportamiento, Can el emp\eo de modelos del sistema creados can herramientas automatizadas es posible simular el comportamiento de un sistema en tiempo real y examinarlo como una consecuencia de eventos extemos. Estas actividades de analisis sirven como base para el diseno 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 asincr6nicas de las cuales se sabe que se comunican entre sl, empleando diferentes tasas de datos y cargas de procesamiento para determinar si ocurriran errores de sincronizaci6n intertareas. Ademas, se pruehan las tareas que se comunican por media de la cola de mensajes 0 el almacen de datos para descubrir errores en el tamano de estas areas de almacenamiento de datos.

 Prueba del sistem a . EI software y el hardware esttlO integrados, de rnoc:l; que se aplica un rango completo de pruebas del sistema (capitulo 13) pan lar de descubrir errores en la interfaz software/hardware. casi todos los mas en tiempo real procesan interrupciones. Por tanto, resulta esencialla prueba del manejo de estos eventos booleanos. Por medio del diagrama estado y la especificad6n de control (capitulo 8), el responsable de la prudl desarrolla una !isla de todas las interrupc:iones posibles y el procesami~ que ocurre como consecuenda de las interrupclones. Entonces se diseflalo pruebas para evaluar las siguientes caractensticas del sistema.

-,5e han asignado y manejado apropiadamente las propiedades de in

d6n?

-i5e ha mane)ado correctamente el procesamlento de cada interrupciOr

-iEI desempei'io de cada procedimiento de manejo de interrupciones ejemplo, el tiempo de procesamiento) cumple con los requisitOS? -,Un elevado volumen de interrupciones que Ilega en momentos cntia. problemas en la fund6n 0 el desempeflo? Ademas. deben probarse areas de datos globales que se emplean para traP informacibn como parte de un procesamiento de interrupciones. con el fin de luar la posibilidad de generaci6n de efectos colaterales.

_!iF d)
~G_.

-a_lllllII*I.

70~.~

En capltulos anteriores se analiz6 el usa de patrones como mecanismo para bir los bloques de construcd6n del software 0 situaciones de ingeniena del d Estos bloques de construcci6n 0 situadones se repiten a medida que se co diferentes aplicaciones 0 que se realizan diferentes proyectos. Como sus coo.....' tes en el ancilisis y el diseno. los patrones de prueba describen bloques de cion a siluacianes frecuentes y que los responsables de probar el software reutilizar al afrantar la prueba de algun sistema nuevo 0 revisado. Los patrones de prueba no sblo proporcionan a los ingenieros del soflwarr directriz util ruanda empiezan las activldades de prueba. lambien proporci()Nlf benefidos adicionales descritos por Marick (MAR021:
I. Proporcionan una termmologla a los encargados de 1a resoluci6n de los prob ~H ey. ,sabes"'. debemos usar un Objeto Nulo_~ 2. Concentran la atend6n en las fuerzas que se encuentran detras del problema Eso nute a los dise.ftadores Ide casos de pruebal comprender me.tOr cuando se apia soluci6n, y por que 3. Estlmulan el razonamlento ileralivo. cada soluci6n crea un nuevo contexto para ver nuevos problemas.

&,

~~

C~VE

1m,.".., ~ .... oyucm a lX1 eqUpo de

-..

~fI'IIju
. . . . . O(~

.... ~ . . y

... mfu.zas ""

......... ....

cAPfnrLo

14

rtcNICAS DE PRUEBA IE. SClFJWARE

457

Aunque estos beneficios sean Hleves~, no deben perderse de vista. Buena parte de la prueba del software, incluso durante las wtimas decadas, ha sido una actividad ad hex. Si los patrones de prueba ayudan a un equipo de software a comunicarse de manera mas efectiva, a comprender las fuerzas motivadoras que llevan a un enfoque espedfico de prueba y a considerar el diseno de los casos de prueba como una actividad en evoluci6n, se habra logrado mucho. Los patrones de prueba se describen de manera muy parecida a los de analisis y diseiio (capitulos 7 y 9). Se han propuesto docenas de patrones de prueba (par ejemplo, [B1N99J, [MAR02]). Los siguientes tres patrones (presentados en [anna resumida). proporcionan ejemplos representativos:
Nombre del patr6n: testigo par

Resumen: PatrOn orientado a procesos. testigo par describe una tecnica an.:\loga a la programaciOn par (capItulo 4), en la cual dos responsables de una pruebas trabajan de manera conjunta para disefiar y ejecutar una serie de pruebas aplicables a actiyidades de prueba

de unidad. integraci6n

Yalidaci6n.

Nombre del patr6n: interl'az de prueba separada

Resumen: En sistemas orientados a objetos es necesario probar cada clase, incluidas las "clases intemas" (es decir. las clases que no exponen ninguna interfaz fuera del cornponente que las utiliza). EI patr6n interl'az de prueba separada describe la manera de crear una interfaz de prueba que permita describir pruebas especlncas en clases que s610 son visibles intemamente para un componente" [LANa II.
N

Nombre del patr6n: prueba de escenario

Resumen: Una yez que se ha aplicado una prueba de unidad 0 de integraci6n es necesario detenninar si el software se comporlara de manera lal que satisfaga al usuario. EI patr6n prueba de escenario describe una lecnica para ejercitar el software desde el punto de vista del usuario. Una falla en este niyel indica que el software no satisface los requisitos de un usuario visible [KANO![.

Un analisis completo de los patrones de prueba esta mas aila del alcance de este li bro. El lector interesado debe consultar [B!N991 y [MAR021 para conocer mayor in fonnaci6n sabre este importante tema .

14,12

IIIPMSN
El objetivo principal del diseno de casas 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 categorias diferentes de tecnicas de diseno de casas de prueba (apJicables a sistemas convendonales y orientados a objetos): las pruebas de caja negra y de caja blanca . Las pruebas de caja blanca se concentran en la eslructura de control del prograrna. Los casos de prueba se derivan para asegurar que todas las instrucciones del 0 menos una vez durante la prueba, y que todas las con programa se ejecuten por 1 diciones 16gicas se ejerciten. La prueba de la ruta basica, una tecnica de caja blan-

...
ca, aprovecha las grcUicas del programa (0 matrices de graficas) para derivar un
junto de pruebas Iinealmente independientes que aseguren una cobertura. La ba de condici6n y de Oujo de datos ejercitan a(m mas la l6gica del programa prueba de bucie complementa atras tecnicas de caja blanca al proporcionar un cedirniento para ejercitar bucies con grados diversos de complejidad. Las pruebas de caja negra estim disei\adas para validar requisitos funcionales importar el funcionamiento intema de un programa. Estas tecnicas de pru cancentran en el dominic de 1a informad6n del software. derivando casos de

ba mediante partici6n de los dominios de entrada y salida de un programa en tal que proporcione cobertura completa. La partid6n equivalente divide el dolde entrada en clases de datos que probablemente ejercitaran una funci6n esped..
del software. El analisis de valores limite prueba la capacidad del programa pafil nejar datos en los IImites de aceptabilidad. La prueba de tabla ortogonal propat"" na un metodo eficiente y sistematico de probar sistemas con numeros pequeflol parametros de entrada. Aunque el objetivo general de la prueba orientada a objetos (encontrar el ro maximo de errores can una cantidad minima de esfuerzo) es identico aJ prueba del software convendonal , la tactica para 1a prueba orientada a ob)dDI fieren un poco. EI concepto de prueba se ensancha para incluir la revisi6n del dele de am\lisis y diseno. Ademas, el eje de la proeba se desplaza del com procedimental lei m6dulo) hacia la clase. E1 diseno de pruebas para una clase diversos metodos: prueba basada en fallas, aleatoria y de partici6n. cada uno los metodos ejercita las operaciones encapsuladas por la clase. Las secue prueba estan disenadas para asegurar que se ejerciten operaciones relevankS examina el estado de 1a clase, representado por los valores de sus atributos, ~ terminar si existen errores. La prueba de integrad6n se realiza mediante una estrategia basada en el Ie tipo de prueba construye el sistema en capas, empezando con las clases usan clase de servidor. Los metodos de diselio de cases de prueba deel;~:::: I tambien pueden emplear pruebas aleatorias y de partlc\6n. Ademas, se u bas basadas en el escenario y derivadas de modelos de compartamiento para una clase y sus colaboradores. Una secuencia de prueba da seguimiento al las operaciones entre las colaboraciones de cJases. Los melodos de prueba especializados abarcan una amplia serie de ope software y areas de aplicad6n. La prueba para interfaces graficas de usualio. quitecturas cliente/ servidor, de la documentaci6n y funciones de ayuda y ck mas en tiempo real requieren directrices y b~cnicas especializadas. Los desarrolladores de software con experiencia suelen decir: " La pruebil termina, s61 0 se transfiere del ingeniero del software al c1iente. cada vez usa el programa, esla realizando una prueba ~. Al aplicar el disefto de casas ck ba, el ingeniero de software Jogra pruebas mas completas y, por tanto, O esa".,,. corrige el mayor numero de errores antes de que empiecen las "pruebas Oel CI...."

..9

[AMB95] Ambler, So. "using Use cases en sojlware Development. julio de 1995, pp . 53-6\. [BEI90] Beizer, S., software Tesling Techniques, segunda edici6n, Van Nostrand-Reinhold, 1990. [BEI95] Beizer, B., Black-&Jx Testing. wiley, 1995. [BIN94J Binder, R. V., "Testing Object-0riented Systems: A Status Report", en American Programmer; vol. 7, num. 4, abnl de 1994, pp. 23-28. [BIN99] Binder, R., Testing Object-Oriented 5}:stems: Models, Patterns, and Tools, Addison-Wesley,
H ,

1999
[DEU79J Deutsch, M .. "Verification and Validation", en Software Engineering (R. Jensen y C. To nies, eds.). Prentice-Hall, 1979. pp. 329-408. [FRASS] Frankl. P. G. Y E, J. Weyuker, "An Applicable Family of Data Flow Testing Criteria", en IEEE Trans. Software Engineering, vol. SE-14, num.IO, octubre de 1988, pp. 1483-1498.

[FRA93] Frankl, P. G. Y S. Weiss, "An Experimental Comparison o f the Effectiveness of Branch Testing and Data Flow", en IEEE Trans. Softvvare Engineering, vol. 5-19, num.8, agosto de 1993, pp.770-787. [KAN93] Kaner, C,]. Falky H. Q. Nguyen, Testing Computer Sojh-vare, segunda edici6n, Van Nostrand-Reinhold, 1993. [KANOI] Kaner, C, "Pattern, SCenario Testing" (borrador). 2001. disponible en http://www.testing.com/test-patterns/patterns/pattern-scenario-testing-kaner.html. [K1R941 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. [L4..NOl] Lange, M., "[I's Testing Time! Patterns for Testing SOftware", junio de 2001, disponible para descarga en http://www.testing.com/test-patterns/patterns/index.html. {UN941 Lindland, O. I. et al., "understanding Quality in Conceptual Modeling", en IEEE Soj?ware, vol. 11, num. 4, julio de 1994, pp. 42-49. [MAR94] Marick, B., The craft ofSoj?ware Testing, Prentke-Hall, 1994 . [MAR02] Marick, B., "SOftware Testing Patterns", 2002, http://www.testing.com/tcst-patterns/ index.html. [MCC76] McCabe, T., "A Software Complexity Measure", en IEEE Trans. Softvvare Engineering, vol SE-2, diciembre de 1976, pp. 308-320. [MGR94] McGregor, J. D. Y T. D. Korson, "Integrated Object-Oriented Testing and Development Processes". CA.CM, vol. 37, mlm. 9, septiembre de 1994, pp. 59-77. [MUS93] Musa, J., HOperational Profiles in Software Reliability Engineering", en IEEE Software, marzo de 1993, pp. 14-32. [MYE79J Myers, G., TheM ofSoj?ware Testing, Wiley, 1979. ]NTA88] Ntafos, S. C, "A Comparison of Some Structural Testing Strategies", en IEEE 7I"ans. So}!ware Engineering, vol. SE-14, num.6, junio de 1988, pp. 868-874 [PHA89] Phadke, M.S., Quality Engineering Using Robust Design. Prentice-Hal!, 1989. [PHA97J Phadke, M.S., "Planning Efficient Software Tests'". Crosstalk. vol. 10. num. 10, octubrc de 1997. pp. II-IS. rrA!89] Tai. K. C., "What to Do Beyond Branch Testing",ACM Software Engineering Notes, vol. 14, num. 2, abril de 1989, pp. 58-61.

14.1 . Myers {MYE79] apliea el siguiente pr08rama como autoevaluaci6n de la eapacidad propia para especifiear pruebas adecuadas: un programa lee tres valores enteros. Los tres va lores se interpretan como si representaran las longitudes de los lados de un tritmgulo. El programa imprime un mensaje que indica si el triangu10 es escaieno, is6sceles 0 equilatero. Desarr6lJese un conjunto de casos de prueba que se eonsidere que prueben adccuadamente este programa. 14.2 . Disefiar e implementar el programa (COIl manqo de errores cuando sea apropiado) especificado en el problema 14.1. Derivar una grMica de nu)O para eJ programa y aplicar la prueba de la ruta basica para desarrolJar casos de prueba que garanlieen que se han probado todas las instrueciones del programa. Ejecutar los casos y mostrar los resultados.

analizaron

14.3 . ,AI lector I~ es poslbl~ pensar en alguna prueba adiciOnal de ~n la secci6n 14.7?

caract~rtsticas

que

fI[I'

14 .4 . Seleccionar un compon~nt~ d~ software que el lecter haya dLSefiado ~ implememadc.. Di2i'1ar un conjunto de casos de proeba qu ~ ~u r~n que todas las instruc se hayan eJecutado con la prueba de la ruta baska
cient~ment~.

14.5. Especificar. dtsenar ~ implementar una herrami~n ta de software qu~ calcuJe la co dad ciclomatica para ~1 1~nguaj~ de programad6n que ~ ~lija Aplicar la matriz de grafica mo estructura operauva d~ datos en e\ dlSeOO, 14.6 . !Lase Belzer IBEl95] y determinese la manera ~n qu~ ~I programa qu~ 2 desafTtllooo. el problema 14.5 puede extenderse para acomodar varies pesos de enlace. Extiendase la mienta para procesar probabilldades de ~jeruci6n 0 ti~mpos d~ procesamiento d~ ~nlaces 14.7. Disei\e2 una henam)enta automatizada que Tonozca bucles y los rias, como 2 indLca en Ja secci6n 14.5.3,
ord~n~

en

14.8. Extiendase la h~rramienta descrita en e l probl~ma 14 7 para generar casos de pruet. ra cada cat~gorla d~ bucl~. una vez encontrada Sera necesario desarrollar ~sta funci6n nera interactLva con el ~ncargado de Ja prueba 14.9. Ofrezca~ po!' 10 m~nos tres ejemplos ~n que la prueba de caja negra darla la de qu~ Htodo est.1 bi~nH, mientras que las pruebas de ca}a blanca descubrirlan un elTOf por 1 0 menos tres ejemplos en que suceda \0 contrario la prueba de caja blanca daria Ia si6n de que 'lode estj bi~nH, mientras que las pruebas de caja negra descubririan un em-' 14. 10. prueba exhausuva (en casode que 2a posibl~ ~n programas muy pequ~~ tiza que eI programa es totalmente correao" 14 . 1 I . En palabras proptas, describase por que la cla2 es la menor unidad razonable prueba dentro d~ un sist~ma onentado a obj~tos 14. 12. (Por que 2 tie~n que volver a probar subclases qu~ crean inslancias a part. clase exist~nte si esta ya se ha probado por compl~IO" ,Es poslble usar los cases de pn&. senados para la clase ~xlsl~m~? 14. 13. Apllqu~nse pruebas aleatorias y de: partitiOn a Ires clases definidas en el dlseflO tema Hoga~uro_ Proc:!uzcanse casas de prueba QU~ indiquen las secuendas de ope se invocaran 14. 14 . Apllquensc pruebas de clase multiple y pruebense derivados del modelo de: ca.... . mienlo para el diseno HogtIrSeguro 14.15. Prutbese un manual de usuario (0 una fund6n de ayudaJ de una aplicad6n ...' .,_.. con frc:<:uencia. Encuentrese por 10 menos un error en la documentad6n.

i",,,,,,=

,La

Enlre docenas de libros que presentan melodos de disc:i\o de cases de prueba 2 Craig Y KaskiellS)'SlemallC Software Testing, Artech House, 2002j, Tamres Testing, Addison-wesley, 2002), Whittak~r (HoW to Break SOftware. Addison-Wesley. ge~n (software ~ng A. OUjtman$ Approtxh, CRC Press. 2002), Splaine y sus IVeb Te5ling Handbook, Software Quality Engineering Publishmg, 2(01). Pallon (~ sams Publishing. 20(0). Kaner y sus colegas rre5l1f18 Computer Software. segunda tdic. ley, I IJ'J9) Ademlls. Hutcheson ~re TestJng Methods and Metric"s; The M05llm McGraw-Hill, 1997) y Martelt. (The Craft of Software Tl::Sbng. Sub$ySem Jesting Ind~ Based and Ob}IOrienlJ!d ksUng. Prentice-Hall, 1995) presenlan tratamientos de m Irategias de prueba Myers IMYE79] sigu~ siendo un t~xlO clasico, que analiza las tecnkas de caja negtil detalle. Beizer IBE I90J proporciona una amplia cobenura de las Itcnicas de caja b

461

duce un nivel de rigor matemalico que a menudo se emite en Olros tralamientos de pruebas. Su

ultimo libro [BE195] presenta un tratamienlo Cond50 de mttodos imponantes. Perry (EJf~tive Methods for software R!stin,g, Wiley-QED, 1995) Y Friedman y Voas (software Assessment." Reliability, Safety, 7e:s/abillly, Wiley. 1995) presentan buenas Introducciones a las estrategias y tacticas de prueba. Mosley (The Handbook of MIS ApplicolJOn Software 1l!sting. Prentice-Hall, 1993) analiza temas de prueba para sistemas de informaci6n grandes, y Marks (TOling very Big Systems, McGraw-Hill, 1992) analiza los aspectos especiales que deben tornarse en cuenla cuando se prueban sistemas de programacl6n importantes. Sykes y MCGregor WrnctkaJ Guide for Testing Object Orienred Software, Addison - wesley, 2001), Bashir y Gael (Testing Object-Oriented Software, Springer-Verlag. 2000), Binder ('n5ling
Object-Oriented S}'stems. Addison-wesley, 1999), Kung y sus colegas (Testing Object-Orienfed 5ojtware, IEEE Computer Society Press. 1998), Marick rrk Croft of 50jtwure Testing, PrenticeHall, 1997) y Siegel y Muller (Object-Ofien/ed SOftwore n=sti1l8' A HierarchicQI Approach, Wiley, 1996) presentan estrategias y mttodos para probar sistemas orienlados a obJelos La prueba del sonware es una actividad que ocupa muchos recufSOS. Por elio, muchas organizaciones automatizan partes del proceso de prueba Ubros de Dustin, Rashka y Poston ~uto maled 50jtwure Testing' Introduction, Management, and Performance, Addison -Wesley, 1999), Graham y sus colegas (Software Test Automation, Addison -wesley, 1999), y Poston (,Automating Specification-Based software Testing, IEEE COmputer Society, 1996) analizan herramientas, estrategias y metodos para pruebas automatizadas. Varios libros consideran los metodos y las estrateglas de prueba en areas de aplicaci6n especializadas. Gardiner rn:sting Sa/ety-Related sojtware A Practical Handbook, Springer-Verlag. 1999) ha editado un libro que aborda la prueba de sistemas de seguridad critica. Mosley (ClicrlV &rver sojtwure Testing on tM Desk Top and the web, Prentice-Hall, 1999) analiza el proceso de prueba para dienles, servidores y componentes de red. Rubin (Handbook ojUSlJbility Testing, Wiley, 1994) ha escrito una gura util para quienes deben ejercitar interfaces humanas Binder IBIN991 describe cast 70 patrones de prueba que cubren metodos de prueba, clases/ grupos. subsistemas, componentes reutilizables. marcos conceptuales y sistemas, ademas de aulomatizaci6n de pruebas y prueha de base de datos especializada. Una lisla de estos palrones se enconlrara en www.rbsc.com/pagesrrestpattemUst.htm Una amplia varledad de fuentes de informad6n sobre los mt':todos de djse~o de casos de prueba esta disponlble en Intemet. Una lisla actuatizada de referendas en la World Wide Web que lienen relevancia para las tt':cnicas de prueba se encuenlra en el silio Web SEPA http://www.mhhe.com /pressrnan.

CAPiTULO

15
CONCEPTOS
C LAVE
~

METRICAS DEL PRODUCTO PARA EL SOFTWARE

.... .....,
.MNI ....464

.......

. 464

a medici6n es un elemento clave en cualquier proceso de ingenierla. medldas se emplean para comprender mejor los atributos de los m

que se crean y evaluar la calidad de los proouctos de la ingenierla 0 de

sistemas que se construyen. Pero a diferencia de otras disciplinas de 1a in ria. la del software no se basa en las leyes cuantitativas bAsicas de la fisica

"

medidas directas. como el voltaJe, la masa. la velocidad 0 la temperatura no

comunes en el mundo del sofiware. Debido a que las medidas y metricas software suelen ser indirectas estAn expuestas a1debate. Fenton [FEN911 este lema cuando afinna:
La medici6n es el pnxeso medmnte el cual S(' aslgnan m.imeros a simboJos a los

........ .. ...471

'*""to ... .411

prlltcipiol 469

IItIidos 461
lie ticIto

.... .....

...491

...... . ..496 . . . . . . .474

......

..... ....,...

. . . ...419
1O~1fl ...411

butos de entidades reales para defimrlas de acuerdo can regJas daramente eslab das. En las ciencias lIsicas, Ia medicina y. mas rtCientemente, las ciencias ""'-"=. ahara podemos me<:lir atnllillos que se consideraban impostbles de medir Par puesto. estas medkiones no henen d rnismo refinamiento que casi todas las de cienoas flSicas. pero exislen IY muchas decistones imponantes se loman con en eUas\. Sentimos que Ja ooligad6n de tratar de "medlr 10 inmedible" para nuestra cQmprenst6n de enlidades partlCUlares es lan lmportante en la ingemen. sofiware como en cualqulCr etta diSCiplina. Pero algunos miembros de la comunidad de software slguen argumentando el software -es inmedible", 0 que deben posponerse los intentos de medu1c ta que se comprenda mejor el propio software y los atributos que deben se para descrtbirlo Esto es un error.

....... ... .49.

OP ...410

"'-iii. ... ,414

taue .., Por JV noturotem, 10 ingenieria es uno diKipIina cuontitohV(I. lc ingenterOS uson nUmeroi at'
mo ClJX'YO para eI d.wOO y Ia ewoIuoci6n del producto que construirOn.
Hoslo hoce pcxo, los ingenierO$ de ultwore conlaban con escosas guios cuontiIotiYm en SU frobaja, pero eso estD ccmbiondo los trWtricos del producto los ayudan a conocer mejor iii diMilo y 10 construcciOn del dtware que eIobomn. A dlferencio de Io.s metricos del proceso y eI proyet'"" to que se aplicon aI proyedo fa 01 proc.eso) co

mo un

todo, 105 metricos del produdo se

Iran en atributos especificos de los prodvctca trabojo de 10 ingenterio del software y sa Ian Q rnedido que se realizon los toreos lon6Iisis diw.o, codificoci6n y pruebo). ,QuIOn 10 ' - 7 ID> de ",ft,,,,,,,,_ 100 _ dol producto """" opoyo ccmtNir so&wor. de mayor colidod . . - . . . . . . . . . - . . ' 5;omp<e . dr6n . , . a cdkJlivol en Ie creociCr softwcn E ".abIema es que no basta eYOluoci6n cuolitotiva. Un ingeniero de

'ngen_'

'*"_'.

...

cAPiTuLo

15

MErnICAS DEL PRODUCTO PARA El. SOFfWARE

463

en diEn

010 modib

Aunque las metricas del producto para el software de computadora no suelen ser absolutas, proporcionan una manera sistematica de evaluar la calidad a partir de un conjunto de reglas definidas can claridad. Tambien proporcionan al ingeniero de software informaci6n inmediata y en el sitio; no posterior al hecho. Esto perrnite al ingeniero descubrir y corregir problemas potenciales antes de que se conviertan en defectos catastr6ficos. En este capItulo se analiza ran las mediciones can que se evah1a la calidad del producto mientras se disena 0 construye. Estas medidas de atributos internos del producto proporcionan al ingeniero de software una indicaci6n en tiempo real de la eficacia de los modelos de analisis, disefio y c6digo; tambien aportan indicativos de la efectividad de los casas de prueba y la calidad general del software que habra de construirse.

Hasta los desarrolladores de software exhaustos estim de acuerdo en que es importante crear software de alta caUdad. Pero, .i.c6mo se define la calidad? En el sentido mas amplio, calidad del software es el cumplimiento de los requisitos de jUncionalidad y desempefJO explfcitamente establecidos, de los estandares de desarrollo explicitamenIe documentados y de las caracteristicas impliciws que se esperan de todo sojhvare desarrollado profesionalmente. Es indudable que esta definici6n podria modificarse a extenderse

y debatirse interrninablemente. En cuanto a los objetivos de este libro, la definici6n sirve para destacar tres puntas importantes:

...

PARTE DOS

PRAcricA DE LA INGNIEIlL\ IEL SOF'TWARli

1. Los requisitos del software son la base de las medidas de calidad. La (alta
concordancia con estos requisitos es una (alta de calidad. I
2. Los estandares especificados definen un conjunto de crilerios de desaITOit" que gulan la ingenieria del software. Si no se siguen los criterios. el resu sera, casi seguramente, la falta de caUdad. 3. A menudo se soslaya un canjunlo de requisi tos implicitos (poT ejemplo, eI. seo de aicanzar la facilidad de usa). Si el software cumple con sus requ' explicitos pero no con los implicitos, la caUdad del software estara en duck
La calidad del software es una compleja combinaci6n de factores que

variaran

diferentes aplicaciones y los distintos clientes que las solicitan. En las siguientes ciones se identifican los (adores que afectan la ca[idad del software y se desc:J! las actividades humanas que deben desarrollarse para a1canzarla.

15. 1.1

Faclores de calidad de McCall

~

Los factores que afectan la calidad del software se dividen en dos gran des

los que se miden directamente (por ejemplo, defectos descubiertos durante la _ ba), y 2) los que salo se miden indirectamente (por ejemplo, facilidad de uso mantenimiento). En cada caso debe presentarse una medici6n. Se debe com software (programa, datos, documentos) con alglin conjunto de datos y obtencr algun indicio sobre la calidad. Mccall, Richards y Walters [MeC77] propusieron una clasificaci6n util de k tores que afectan la calidad del software. Estos factores, que se muestran en Ia ra 15.1, se concentran en tres aspectos importantes de un producto de software. caracteristicas operativas, su capacidad para experimentar cambios y su ca para adaptarse a nuevas entomos. Si se taman como referencia los factores indicados en la figura 15.1, McCaJ.. colegas proporcionan las siguientes descripciones:

Factm9S de la cal1dad del software de McCall.

focilidod de montenimienlo Fie)(ibiiidod Foci]idod de prueoo

PorIobi!idad Focilidad de reuti]izocian

Inleraperabilidod

REVISI6N DEL PRODUCTO

TRANSICION DEL PRODUCTO

COfTeo::i6n Coofiabilidad

focilidod de usa Integridad

Efidencia

Es importante indicarquc' La calidad se eJdiende a lascaracteristicas tecnicasde los modelos. lisis y diseno, as! como a la realizad6n del c6digo fuente de estos. Modelos de alta calida

sentido t#:cnico) darim lugar a software de alta cahdad, desde el punto de vista del cliente

CAPiTuLo 15

MtrRICAS DEL PROOOCTO PARA El. SOfTWARE

465

COITocci6n. El grado en que el programa cumple con su espedficad6n y satisface los ob-

jetivos que propuso el cliente.

COnftabilidad. El grado en que se esperaria qlK: un programa desempene su func:i6n con la

precisi6n requerida. [Debe observarse que se han propuesto otras definiciones de confiabilidad mas cornpletas (consultese el capitulo 26)].
Eftdencia. La cantidad de c6digo y de recursos de c6mputo necesarios para que un progra-

rna reaJice su funci6n.

Inlegridad. El grado de control sobre el acceso al software 0 los datos por parte de las per-

sonas no autorizadas.
Facilidad de uso. EI esfuerzo necesario para aprender, operar y preparar los datos de en-

trada de un programa e interpretar la salida.

Facilidad de manlenimiento. El esfuerzo necesario para localizar y corregir un error en un

programa. (Una definid6n muy limitada.)

Flexibilidad. El esfuerzo necesario para modificar un programa en operaci6n. Facilidad de prueoo. El es(uerzo que demanda probar un programa can el fin de asegurar

que realiza su funci6n.

Porlobilidad. El esfuerzo necesario para transferir el programa de un enlomo de hardwa-

re 0 software a otTO.
FadJidad de reutilizaci6n. EI grado en que un programa (0 partes de el) puede reutilizarse

en otras aplicadones (en relaci6n con el empaquetamiento y el alcance de las funciones que reaJiza el programa).
Interopembilidad. El esfuerzo necesario para acoplar un sistema con otTO.

I ,.
~~

lilt

producto is una hmOOn del lien qlll han III mundo.

Es difidl. Y en algunos casos imposible, desarrollar medidas directas2 de estos factores de [a calidad. En realidad, muchas de las metricas que definen McCall et al. s610 se miden subjetivamente. Es comun que las metricas adquieran la forma de una lista de comprobaci6n que se emplea para "asignar una graduaci6n" a atributos especificos del software [CAV78].

15.1.2 Factores de caUdad del est6:ndar ISO 9126

El esltmdar ISO 9126 se desarroll6 como un intento par identificar los alributos de calidad para el software de computadora. EI estandar identifica seis atributos clave de la calidad:

2 Una m~ida dirtXta indica que s610 es posible conlar un valor que proporciona una indicacion directa del atributo que se examina. Por ejempJo, eI '"lalnai\o'" de un programa se mide directamente aJ contar eJ numero de lineas de c6digo

...
FundonaJidad. EI grade en que el software satisface las necesidades que i
los siguientes subatributos: idoneidad. exactitud, interoperabilidad, cumplimi seguridad.

Confiabilidod. La cantidad de tiempo en que el sotl:ware estA disponible para 10 segun los siguientes subatributos: madurez, tolerancia a fallas y facilidad de ret.
peraci6n. Fadlidad de usa. La (acilidad con que se usa el software de acuerdo con guientes subatributos: fadlidad de comprensi6n. fadlidad de aprendizaje y opeI'J.i lidad.

Efidcncia. El grade en que el software emplea en forma 6ptima los recursos sistema, como 10 indican los siguientes subatributos: comportamienlo en el t comportamiento de los recursos.

Fac;Jidad de mantenimiento. La facilidad con que se repara e! software de a

con los siguientes subatributos: facil idad de ana lis Is, facilidad de cambia, esta

y facilidad de prueba .
PoT1obiJidad. La facilidad can que se lIeva el software de un entomo a otro

los siguientes subatributos: adaptabiJidad, facilidad para instalarse, cumpli faciJidad para reemplazarse. A1 igual que otros factores de calidad del software analizados en el capitulo 9 5ecci6n 15. 1.1 , los factores ISO 9 126 no necesariamente se prestan a la medi . recta. Sin embargo, proporcionan una base valiosa para las medidas indirectas J lisla de verificaci6n excelente para evaluar la calidad de un sistema.

15.1.3 La transtc16n a

Wl

concepto cuanUtaUvo

En las secciones anteriores se analiz6 un conjunto de factores cualitativos "medid6n" de la caUdad del software. EI esfuerzo por desarrollar medidas p de la calidad del software en ocasiones se frustra por la naturaleza subjeUva activtdad. cavano y Mccall ICAV78j analizan esta siluaci6n:
La delenninaci6n de la caUdad es un ractor clave en todas las actividades diarias (CO sos de cata de vinos, compelendas deportlvas leoma la gimnaSia\. concwsos de tal etc.). En estas situaciones 13 calidad se juzga de Ia manera mas basica y directa C~ rando ob}etos que se encuenlran juntos en condiciones identicas y con conceptos pred.: terminados EI VInO se juzga de acuerdo con su claridad, color, bouquet. sabor, elc embargo. este tlpo de juicios es muy subjetivo; para que tenga alg(.Ln valor debe haccII un experto
La subjetividad y la especializad6n tambien se aplican para determinar la calldad software. Se necesila una definid6n mas predsa de \a calidad del software para resoio

CAPiTuLo 15

MtrnJCAS DEL PRODUClO PARA D. SOFTWARl:

467

este problema, ademas de un medio para derivar medidas cuanlitalivas, a partir de la caUdad del software, para realizar un anaJisis objelivo __

En las secciones siguientes se examina un conjunto de metricas que se aplican en la evaluaci6n cuantitativa de la calidad del software. En todos los casos las metricas representan medidas indirectas; es decir, nunca se mide reaimente la calidad, sino algona manifestaci6n de esta. EI factor que complica las casas es la relaci6n precisa entre la variable que se mide y la calidad del software .

.... _IG!IIIIIid6et de 10 temperoturo IIfI1pieza COlI lin dedo indica., . ycia lugar a esoias, "-'eM_IllS y.... aft S. . tsi SIu/e COlI Ia mocIurez en]a m edidOn del software.

lei.

-.......

Como se indic6 en la introducd6n de este capitulo, la medid6n asigna numeros 0 simbolos a atributos de entidades reales. Esto requiere un modelo de medid6n que abarque un conjunto consistente de reglas. Aunque la teo ria de la medid6n (por ejempio, [KYBS4)) y su apJicad6n al software de computadora (por ejemplo, [DEMSI], [BRI96], [ZU597J) son temas que rebasan el alcance de este libro, vale la pena establecer un marco conceptual y un conjunto de principios basicos para la medid6n de metricas para el producto de software.

15.2.1 Med1das, metricas e Indicadores

Aunque medida, medici6n y metrica son terminos que suelen utilizarse de manera intercambiable, es importante observar las sutiles diferencias entre ellos. En el contexto de la ingenieria de! software una medida proporciona una indicaci6n cuantitativa de la extensi6n, la cantidad, la dimensi6n, la capaddad 0 el tamano de algun atributo de un producto 0 proceso, Medici6n es el acto de detel1T1inar una medida. El Glosario de estcindares del IEEE [lEE93[ define metrica como una "medida cuantitativa del grado en que un sistema, componente 0 proceso posee un atributo detel1T1inado". Cuando se ha recopilado un solo tipo de datos (por ejemplo, el numero de errores descubiertos denlro de un solo componente de! software) se ha establecido una medida, La medici6n ocurre como resultado de !a recopilaci6n de uno 0 mas puntas de datos (por ejemplo, se investigan varias revisiones de componentes y proebas de unidad para reunir medidas del numero de errores encontrados en cada uno) . Una metrica de software reiadona de alguna manera las medidas individuales (por ejemplo, el numero promedio de errores encontrados en cada revisi6n 0 prueba de unidad). Un ingeniero de software recopila medidas y desarrolla metricas para obtener los indicadores. Un indicador es una metrica 0 una combinaci6n de metricas que proporcianan conocimientos acerca del proceso del software, un proyecto de software o ei propio producto. Un indicador proporciona conocimientos que permiten al jere

...

PARTE DOS

PRAcncA [ LA INGENIElIfA DEL SOf'TWARE

de proyecto 0 los ingenieros de software ajustar el proceso, el proyecto 0 el p to para que las casas mejoren.

15.2.2 E1 reta de las metrlcas del producto

En las ultimas lres decadas, muchas investigadores han tratado de desarrollar sola metrica que proporcione una medida completa de la complejidad del s,oftt. Fenton [FEN941 caracteriza esta investigaci6n como una btlsqueda del "santo imposible". Aunque se han propuesto docenas de medidas de complejidad [ cada una tiene un concepto diferente de la complejidad y de los atributos de un rna que Ilevan a la complejidad. Por anaiogia, considerese una metrica para ev

autom6vil atractivo. Algunos observadores destacarian el disefio de la caIToceM lamanan en cuenta caracteristicas mecanic.as y otros mas podrian considerar d
el desempeno, Ja economia de combustible 0 1a capacidad de reciclarlo cuando to sea inservible. Como cualquiera de estas caraderisticas estaria en desven~ otras, resulta diflcil derivar un solo valor de "atractivo". El mismo pr<)blenlaoo". con el software de computadora . Pero existe la necesidad de medir y controlar la complejidad del software dificil derivar un solo valor de esta metrica de calidad, debe tenerse la posib desarrollar medidas de diferentes atributos internos del programa (por ejempIQ dularldad efectiva, independenda fundonal y otros atrlbutos analizadoss ~:~:~= al 12). Estas medidas y las metricas derivadas de elias se utilizan como ir dependientes de la calidad de los modelos de analisis y diseflo. Pero aqul ~ gen problemas. Fenton [FEN94) observa esto cuando afinna: "EI peligro de encontrar medidas que caradericen tantos atributos diferentes es que ;.,1e"taIL.... te las medidas tienen que satisfacer objetivos que entran en conflicto entre si. opone a la leona de que cada medici6n debe ser representativa." Aunque Ia ...... ci6n de Fenton es correcta, muchas personas argumentan que Ja medici6n del realizada durante las primeras etapas del proceso del software proporciona ~ genieros un mecanismo consistente y objetivo para evaluar la caUdad. Sin embargo, vale la pena preguntarse sabre la validez de las metricas ducto. Es decir, ;,que tanto concuerdan las metricas del producto, la conli largo plaza y la calidad de un sistema de c6mputo? Fenton [FEN91 J aborda quietud de Ja siguiente manera: A pesar de las conexiones intuitivas entre la estructura intema de los productos cr ware [metricas del producto] y los atributos de su producto y su proceso exlemos, ar lidad se han realizado muy pocos intentoscientificos porestablecerreiaciones Esto es asl por varias razones: la que se a la con mas frecuencia I tico realizar experimentos relevantes.

_ _ _ ...... .......
... "". ..,.......
./8_/.

.!

....

-.

c APiTuLo

15

MmcAS DEL PIIODlICIO PARA .Q. SOFTWARE

..9

cada uno de los "relos" indicados aqui debe tomarse con cautela. pero no hay ra z6n para restarle ml!ritos a las metricas t&nicas 3 La medici6n es esencial si se desea atcanzar la caUdad.

15.2.3 Prtnctpios de medicion

Antes de introduclr una serie de metricas del producto que 1) ayuden a evaluar los modelos de analisls y diseno, 2) ofrezcan una indicaci6n de la complejidad de los disenos procedimentales y el c6digo fuente, y 3) fadliten et diseflo de pruebas mas efectivas, es importante comprender los principios basicos de la medici6n Roche [ROC94] sugiere un proceso de medici6n al que caraclerizan cinco aClividades:

Fonnu/ad6n. La derivaci6n de medidas y melricas aprapiadas para la representaci6n del sofiware que se considera.

Recolecci6n. El mecanisme can que se acumulan los datos necesarios para

derivar las metricas formuladas.

Analisis. EI calculo de las metricas y la aplicaci6n de herramientas matematicas. tnterpretad6n. La evaluaci6n de las metricas en un esfuerzo por conocer mejor la calidad de la representaci6n.

RelrOalimcntaci6n. Recomendaciones derivadas de [a interpretaci6n de las melricas del produclo transmitidas al equipo del sofiware. Las metricas del software 5610 seran utiles si estan caracterizadas de manera efectiva y se validan para probar su valOT. Los siguienles principios [LET03] son representativos de muchas olros que podrian proponerse para caracterizar y vaHdar las metricas:

Una metrica debe tener propiedodes matcmaticas deseab/es. Es decir, el valor de la

metrica debe estar en un rango significativo (por ejemplo, de cera a uno, donde cero realmente significa ausencia, uno indica el valor maximo y 0.5 representa el "punto media"). Ademas, una metrica que pretende estar en una escala racional no debe contar can componentes que 5610 se miden en una escala ordinal

Cuando una metrica representa una caracteristica de software que aumenca wando se presentan rasgos positivos 0 que disminuye 01 enconlrar rasgos indeseables, el valor de 10 metrica debe aumentar a disminuir en el mismo senUdo. Coda melrica debe validarse empiricamente en una amplia variedad de COlltextos antes de publicarse 0 aplicorse en 10 loma de decisiones. Una me-trica debe medir el factor de interes, independientemente de olras factores. Debe "crecer" para aplicarse en sistemas grandes y funcionar en diversos lenguajes de pragramaci6n y dominios de sistemas_
3 Aunque \a crillea de ~lricasespecirlCaS es comun en Ia blbhograf1a. muchasde esas crilicas seconcentran en aspectos esotericos y pierden de V1Sla eI pnnclpal ob]etivo de las melricas en \a realidad ayudar al Ingenlero de software a eslablecer una
mMIefiI

sistematica y objetiva de com>eer a fondo

su Irabaja y, como resullado, mejorar la calidad del producto

470

PARTE DOS

PRAc:nc:A [ LA tNGDmlIlA DEL!IOFTWARE

Aunque 1a formulaci6n, caracterizaci6n y vaJidaci6n son Criticas, la recopilaci6n analisis son las actividades que dirigen el proceso de medici6n. Roche [ROC941

giere las siguientes directrices para estas actividades: I) siempre que sea posible
ben automatizarse la recopilaci6n de datos y su analisis; 2) deben aplicarse t

estadlstlcas validas para establecer reladones entre los atributos internos del
ducto y las caracteristicas de calidad extemas (por ejemplo, si el grade de c dad de la arquitectura se correlaciona con el numero de defectos informados aplicarl a en producci6n), y 3) para cada metrica deben establecerse directrices . comendaciones para la interpretaci6n.

15.2.4 MedJ.ctOn del software orientado a objetivos

Basili y Weiss IBAS84} desarrollaron el paradigma objefivo/preguntalmetnca como una tecnica para identilicar mttricas significativas apJicables en cualqta:l" Ie del proceso del software. El OPM destaca la necesidad de I ) establecer un \IV de medici6n expllcito que sea especlfico para la actividad del proceso 0 las teristicas del prodUCIO que se esta evaluando, 2) definir un conjunto de preguna.. deben responderse con el fin de alcanzar el objeto, y 3) identificar melIicas
muladas que ayuden a responder esas preguntas. Es posible emplear una plantilJa de definid6n de objetivos [BAS94) para da objetivo de medici6n. La plantilla lorna esla forma:
AnaHzar lei nombre de la actividad 0 el atributo que se mediraj con el prop6sito" objetivo general del analisi:;4\ en reIad6n con lei aspecto de la actividad 0 atn se en consideraJ desde eI punto de vista de (la gente que tiene interes en la mecI en el contexto de lei entomo en que tiene Jugar]a medid6nl

COmo ejemplo, considerese una plantilla de definici6n del objelivo panl

Seguro,
Ana.lb:ar la arquitectura del software HO(JCltSqJuro con eJ propOsito de evaluar Iol

p<mentes arquitecl6nicos en relad6n con la capaddad para lograr que HogarSegw' mas extensible de5de eI punta de vista de los ingenieros de software que r trabajo en eI contexte de ]a me)ora del producto en los siguientes tres alios.
Una vez definido expllcilamente el objelivo de la medici6n, se desarrob junto de pregunlas. Las respuestas a estas ayudan al equipo de softwilrt otros participantes) a determinar sl se ha alcanzado el objetivo de m""''''''' las preguntas que se responden estan las siguientes:
P,:

,los componentes arquitect6nicos estan caracterizados de m~

aparecen por separado la funci6n y los datos relacionados?

Van solingen y 8eJ"Bhout 1501..99) sugieren que el objetivo es casi siempre comprendl!!" mejorar" Ia ad.Jvidad del proceso 0 e1 atributo del producto.

P1:

lLa complejidad de cada componente se encuentra dentro de los IImites que facilitaran su modificad6n yextensi6n?
emplean~

cada una de estas preguntas debe responderse de manera cuantitativa,

do una 0 mas medidas y metricas. Por ejemplo, una metrica que proporclona una In dicaci6n de la cohesi6n (capitulo 9) de un componente arquitect6nico serla uti! para responder P" La complejidad ciclomatica y las metricas analizadas en la secci6n 15.4, 1 0 15.4.2 proporcionarlan conocimientos a fondo para p}. En realidad, tal vez haya diversos objetivos de medici6n con preguntas y metricas
reladonadas. En cualquier caso, las metricas elegidas (0 derivadas) deben cumplir con los principios de medici6n analizados en 1a secci6n 15.2.3 y los atribulos de medici6n analizados en la secci6n 15.2.5. Si se desea obtener mayor informacl6n sobre OPM, ellector interesado debe consultar [SHE98J 0 [SOL99J.

15.2.5 Los ab1butos de las metrtcas efect1vas del software

Se han propuesto cientos de metricas para el software de computadora. pero no todas proporcionan soporte practico para el ingeniero de software. Algunas exigen mediciones demasiado complejas; otras son Ian esol ericas que pacos profesionales podrian comprenderlas. y otras mas violan las nociones intuitivas Msicas de 1 0 que es eJ software de alta calidad. Ejiogu [EJ191J define un conjunlo de atributos que toda metrica efectiva del software debe abarcar. La metrica derivada y las medidas que lIevan a ella deben ser:

SimpJesyruJcu/ab/es. Debe seT relativamente facil aprender a derivar la metrica,

y su calculo no debe exigir cantidades anormales de tiempo 0 esfuerzo.

Empirica e intuitivamente persuasWas. La metrica debe satisfacer las nociones

intuitivas del ingeniero ace rca del atributo del producto que se esta conslruyendo.

Consistentes y objetivas. La metrica siempre debe arrojar resultados que no

permitan ambigOedad alguna.

Consistentes en el uso de unidades y dimensiones. E1 calculo matematico de la

dlsrll!lllilllJ lIMo dti twtkIo si

_....
__ ,Idd

metrica debe emplear medidas que no lleven a combinaciones extrai'ias de unidades.

lndependientes del Jenguaje de progmmaci6n. Las metricas deben basarse en el

modelo de analisis a diseiio, a en la estructura del propio programa .
Meamismos cJcctivos pam la retroafimentaci6n dcafla calidad. Es decir, la me-

trica debe llevar a un producto final de la mas alia calidad. Aunque casi todas las metricas de software satisfacen estos atributos, algunas metricas de uso comun no cumplen can una a dos de elias. Un ejemplo es el punto de funci6n (el cual se estudia en la secci6n 15.3. II. que es una medida de la entrega de "funcionalidad" por parte del software. Se puede argumentarS que el atributo consis-

-.~ IiIarsf docns de

.... ..,..,..,.
"" /0 tMlrica Sf

..ws", IS iroba-

472

lente y objdivo falla porque tal vez un tercero, que sea independiente, no Jogre dem el mismo valor del punto de fund6n que un cOlega que utilice la misma (nfonn
acerca del software. iDebemos rechazar entonces la medida de punto de funci6n'

respuesta es ipor supuesto que no! El punto de fund6n propordona conocimi

utiles y, par tanto, valores distintos, aunque no satisfaga algUn atributo a Ia perfecd..

15.2.6 Panorama de las mebicas del producto

Aunque se ha propuesto una amplia variedad de taxonomlas metricas, el si esquema atiende las areas mas importantes de las metricas:

Ml:tricas para el modelo de amilisis. Estas metricas atienden varios aspectOl5 modele de anaJisis e induyen:
Fundonalidad entregada: propordona una medida indirecta de la funcio

que se empaqueta con el sonware.

Tomai'io del sistema: mide el tamana general del sistema, deflnido desde eJ de vista de \a informaci6n disponible como parte del modelo de analisis.

caUdad de fa espt:dficoci6n: proporciona una indicad6n de la especifiddad

grado en que se ha complelado 1a espedficad6n de los requisitos. Metrlcas para el modelo de diseiio. Estas metricas cuantifican 1 05 atrib diseno de manera tal que Ie permil en al ingeniero de software evaluar la ca diset\o. La metrica incluye:

Metricas arquitect6rucas: proporcionan un indicio de la caUdad del diseflo arq... ," t6nico. Metncas aJ !livef de componen/.e: miden la complejidad de los compone software y otras caracteristicas que impactan la calidad. Memcas dedisdio de 10 inlerjaz: se concentran principalmente en \a facilidad MClncas espedallzodas en diseno orientado a objet.os: miden caracteristicas ses, ademas de las correspondientes a comunicaci6n y colaboraci6n.
Metricas para el c6d.igo fuente. Estas metricas miden el c6digo fuente y para evaluar su complejidad, ademas de la facilidad con que se mantiene . .- ... entre otras caracteristicas:

Metricas de Halstead: controversiales pero fascinantes, estas metricas nan medidas (micas de un programa de c6mputo. Mctricas de complejidad: miden la complejidad l6gica del c6digo fuente se consideran metricas de disei'io aJ nivel de componentes). Metricas de Jongirud~ proporcionan un indicio del tamano del software.
5 Podrla usan;e un oontraargumento igualmente Vlgoroso [sa es Ia Nllurakza de " ' __
software

cAPiTuLo

15

MtrRiCAS DEL PROOOCro PARA II. SOfTWARE

.73

Metricas para pruebas. Estas melncas ayudan a disenar casos de prueba efectivos

y a evaluar la eficacia de las pruebas

Merricas de coberturo de inslrucciones y ramas l1eva al diseno de casos de prueba

que praporcionan cobertura del programa.

Metricas re1acionadas con los defeclOS: se caocentran en encontrar defectos y no

en las propias pruebas.

Efectividad de 10 prueoo: proporcianan un indicia en tiempo real de la efectividad de las pruebas aplicadas.
Merricos en el proceso: metricas relacionadas can el proceso que se determinan a medida que se aplican las pruebas.

En muchas casos las metricas de un modela pueden aplicarse en actividades posteriores de la ingenierfa del sofiware. Por ejempla, las metricas de diseno se utilizan para estimar el esfuerzo requerido para generar c6digo fuente. Ademas, las metricas de diseno se apravechan para planear pruebas y el disei'lo de casas de prueba.

de ingenierio del
~ m61ricos
'IIagO. ~
JU UIO d.p.derio

dol

dijo
pcll1l

de 1'IO$01ro$.
".,..

............... do'"""'io

roo tMemot liempo

Jamie. EIIanIo5 contra 111105,

Ylnod: No, """'-0 iY Ii nos ohonan ~ Jamie: 6COmo' Vinod: Evitondo 'eIrobator. Si uno (I flYitor un p'obAao,1Q imjJOill'" (I fnduao uno moderodo, y ftC) nos evito ..,abajca uno paN cW r.istemo, ohorroren'lOl tiempo. to d Ed: Es po$ible, wpongo, pero inDl gao...... cpt olgung m6ttico del produdo no5 ~ a ......... \It p'obiemo Vinod: ,V IV megorontims que no 10 hanW Jamie; Bueno, ~qut; _s poponieucio' Vinocl: Creo que ~ ~ unotCllllJl'llllt memcos de di.no, to! YOZ orientodas (I do..)' opIicorkJs como pcII1e de nuestro proc:.o ... t.tIi6n

fIIiIric:o,..'"

pcll"O

lock los COI'I'IpOi".que dwol......... Ed: No atr:Jy muy farndioriudo con lea,.....

. Es COlO de tiempo. y)'O

nor.aIu.ca()i'~

01 ieI

dodos (I obtetos

Ysnod: Vert (I dedicor un poco de Ii..,.,o G,.wI. . . . , a hac. aiguncft ,ecOI," oduc:ionel.. ~. GO . . . (Ed y ..Iomoe 0IientwI tin rnucho~)

.,.
Aunque exislen en la bibliografia relativamente pocas metricas de analisis y

espeo

ficaci6n. es posible adaptar metricas que se utilizan en 1a estimaci6n de proyect05 aplicarlas en este contexto. Estas metricas examinan el modelo de analisis con 1a

tenci6n de predecir el "tamano" del sistema resuitanle. EI tamana es. en ocas

(pero no siempre), un indicador de la complejidad del diseno y casi siempre un indicador de un mayor esfuerzo de codificaci6n. integraci6n y prueba.

15.3.1 Metricas basadas en 1 a fund6n

La metrica de punto de funci6n (PF), propuesta inicialmente por Albretch IALB ~

usa de manera efectiva como medio para medif la funcionalidad que entrega un lema .' Empleando datos hist6r1cos, el PF se usa para \) estimar el costo 0 el zo requerido para diseiiar, codificar y probar.el software; 2) predecir el numero errores que se encontrartm durante la prueba, y 3) pronosticar el numero de c nentes, de Iineas de c6digo proyectadas, 0 ambas, en el sistema impiementado

Los puntos de fund6n se derivan empleando una relad6n empirica ba.sadI.

medidas contables (directasj del dominio de la informad6n del software y las luaciones de la complejidad de este. Los valores del dominic de la infonnaci6n finen de la siguiente manera 1 N1imero de entradas extemas (EE) . cada entrada extema se origina usuario 0 es transmitida desde otra aplicad6n y propordona distintos datos on..... dos a la aplicaci6n 0 informaci6n de control. Las entradas suelen emplearse tualizar archivos 16gicos intemos (AU). Las entradas deben distinguirse de 1m sultas, que se cuentan por separado. Numero de salidas extemas (SE). cada salida extema se deriva en el de la aplicaci6n y proporciona informaci6n al usuario. En este contexto, tema alude a informes, pantallas, mensajes de error, etc. Los elementos de ""._. dividuales dentro de un informe no se cuentan por separado. Nlimero de consuJtas extemas (eE) . Una consu/to extema se define entrada en linea que lleva a la generaci6n de alguna respuesta inmediata pedel software, en la fonna de salida en linea (a menudo recuperada de un Nlimero de archivos l 6gicos intemos (AU) . cada archive I6gico inttn'l agrupamiento 100ico de datos que reside dentro de los Iimites de las apli que se mantiene mediante entradas extemas.

6
7

Desde que Albrecht dio a conoccr su tTabajo original. sc han d,n"." ticulos sabre PF. En [IEPOlI se cncontfiua una bibliografla muy valiOsa.
tan

=ri",

lit"",,. ~"''1'1

En realidad, \a definid6n de los valores del domlnlO de Ia tnformacl6n Y Ia ma" . :;~,;:~~ .

son un poco mas complcjas EI lector intcresado dcbcr consultar (JFPO 1\ p; tal'"

CAPInn.O 15

MtmICAS DEL PRODUCTO PARA EL SOfTWARE

475

Valor del dominio de informaciOn

EntrodO$ externO$ lEE) Solido$ extern05lSE) COn$ulto5 externOI ICE) Ardivos de lOgico interne (AU) ArchiV05 de interfaz externo (AlE) Totol de conteos

C_ _

Factor de ponderacion Simple Promedia Complejo

x x x

r::J r::J r::J r::J r=l

,
3 7 5

,
5

6 7 6
15
10

,
10

x x

r::J r::J r::J r::J r::J

Cl

Numero de archivos de interfaz extemos (AlE) . Cada archiva de interfaz exlema es un agrupamiento 16gico de datos externo a la aplicaci6n pero que proporciona datos que podrian usarse en esta.
Una vez que se han recolectado los datos. se completa la tabla de la ligura \5.2 y se asocia un valor de complejidad con cada conteo. Las organizaciones que usan metodos de punto de funci6n desarrollan criterios para determinar si una entrada determinada es simple. promedio 0 compleja. No obstante, la determinaci6n de la complejidad es un poco subjetiva. Para calcular los puntos de funci6n (PF) se usa la siguiente relaci6n:

PF

= conteo total

x [0.65 + 0.0 I x

r (F.)]

(15.1)

donde conteo total es la suma de todas las entradas de PF obtenidas de la figura 15.2. Fi (i = I a 14) sonfaetares de ajuste de valor basados en las respuestas a las siguientes preguntas [LON02): 1. .i.EI sistema requiere respaldo y reeuperaci6n eonfiables? 2 . .i.Se requieren comunieaeiones de datos espeeializadas para transferir informaei6n a la aplicaci6n, u obtenerla de ella? 3 . .i.Hay funciones distribuidas de procesamiento? 4 . .i.E] desempei'io es crilieo? 5 . .i.EI sistema se ejeeutara en un entomo existente que tiene un uso pesado de operaciones? 6 . .i.EI sistema requiere entrada de datos en linea? 7. .i.La entrada de datos en linea requiere que la transacei6n de entrada se construya en varias pantallas u operaeiones? 8. .i.Los AU se aetualizan en linea? 9. .i.Las entradas. las salidas. los archivos 0 las consultas son complejos? 10. .i.Es complejo eJ procesamiento interno' 11 . .i.EI c<'>digo disei'iado sera reutilizable'

.,.
12 .i.Se induyen la conversi6n e instaJaci6n en el disefio? 13. ,Esta disefiado el sistema para instaiaciones multiples en diferentes orgalUD ciones? 14. (,La aplicaci6n
est~

diseftada para facilitar el cambia y para Que el usuario Ie.

use faciimente?
cada una de estas preguntas se responde empleando una escala que va de 0 (no

portante

aplicable) a 5 (absolutamente esencial) . Los valores conslantes de

ecuaci6n (15.\) y los (adores de peso que se aptican a los CQnleos del dominiode k
fonnad6n se determinan empiricamente.

Para jlustrar el empleo de la metrica del PF en este contexte se ide6 la represea' dbn simple del modelo de analisis, que se muestra en la figura 15.3. Ahl se rep ta un diagrama de flujo de datos (capitulo 8) denlro del software HogarS!guro. La d6n maneja \a inleracci6n con el usuario aceptando una contrasena de este para tivar 0 desactivar el Sistema, y permite consultas sobre el estado de las zonas de guridad y varios sensores de seguridad. La runci6n despliega una serie de me~ envia seflales de control apropiadas a varios componentes del sistema de segurdI..

se evahla el diagrama de flujo de datos para determinar un conjunto de mc...._

clave del dominio de infonnaci6n que se requieren para calcular la metrica del to de funci6n. En la figura se muestran tres entradas extemas (contrasefia, de panico y activar/ desactivar) junto con dos consultas extemas (conswta zona y consu1ta de sensor) . Se muestra un AU (archivo de configuracl6ft sistema). Tamblen estan presenles dos salidas de usuarios (mensajes y es del sensor) y cualro AlE (sensor de prueba, conflguracilm de zona, acttva desactivar y alerta de alarma). En la figura 15,4 se muestran estos datos. con la complejidad apropiada. EI conteo tOlal que se muestra en la figura 15.4 debe ajustarse empleando la don ( 15. 1): PF '" conleo lotal x 10.65 + 0.0 I x I. (F,JI

Modelo de OuJo de datos para

SenSOfes

el software
Hog<uSeguro.

Controseno Conwho de zona

Conlroseiio, sensores ...

Alena
de olormo

Sub.btllmo
monilQfIO

Dotos de configurocibn dellistemo

y rMpUes/o

Conteo
Enlfodos
eXMlrn05

Foetor de ponderacion Simple Promedio Complejo

(EE)

6 7

Solidos .xlerno! [SEJ ConSt/llas externos (CEI Archivos d. l6gico interne (ALII Archives d. inlerfoz e;.:;lerno (AlE)

CD CD OJ C!l

x x x x

r:Il

5 4
1O 7

(7)
~

OJ

6
15
1O

OJ
c:z:::l
O!l

Totol de

COl'lteos

Q[l

donde contea total es la suma de todas las entradas de PF obtenidas de la figura 15,4, y F, Ii - I a 14) son factores de ajuste de valor. Para los objetivos de este ejemplo, sup6ngase que r (F)) es 46 (un producto moderadamente complejo). Por tanto: PF - 50 x 10.65 + (0.0 I x 46)1 - 56 Con base en el valor proyectado del PF derivado del modelo de analisis, el equi-

po del proyecto puede estimar el tamai'io implementado general de la funci6n de interacci6n del usuario de HogarSeguro. Sup6ngase que los datos del pasado indican que un PF se traduce a 60 J[neas de c6digo (se va a usar un lenguaje orientado a objelOS) y que se producen 12 PF por cada persona-mes de esfuerzo. Estos datos hist6ricos proporcionan al jefe del proyecto informad6n importante que sirve para la planeaci6n y que se basa en el modelo de analisis mas que en estimados prelimina res. Sup6ngase, ademas, que los proyectos anteriores han encontrado un promedio de tres errores por punta de funci6n durante las revisiones del analisis y el diseno, y de cuatro errores par punta de funci6n durante las pruebas de unidad e integraci6n, Estos datos ayudaran a los ingenieras de sofiware a evaluar el grado en el que han completado sus actividades de revisi6n y prueba. Uemura y sus colegas IUEM99J sugieren que los puntas de funci6n lambien pueden calcularse a partir de diagramas UMl de clase y secuencia (capitulos 8 y 10) EI lector interesado debe consultar [UEM99J para conacer mas detalles.

-& """ ............... do roil .... mi... ............. doi>omo> , ...."'" ~ """,,,,"" (Oft las ml!ritasrMIdoooI ... y t..y_

',.-1Inmos

15,3.2 Mebicas para 10 calldad de 10 especificaci6n

Davis y sus colegas [DAV93) propanen una !ista de caracteristicas con las cuales puede evaluarse la calidad del modelo de ana!isis y la correspondiente especilicaci6n

.7.

PARTE DOS

de requisitos: especificidad (falta de ambigiiedad), grado de avancc, cona::ci6n, Jaaltdad de comprenSJon, facilidad de verijicaci6n . consistenaa intema y exlcma, foclbt.1tltt

PR.\cnc..\ DE lA INGDmJiIA I n saIWARE

para alcanzar los objetNos, COndsiOn, Jodlklad para doric scguimiento. fadlidad , . . modijicQrsc, precisiOn y Jac/Mad de reutHizociOn Ademtls. los autores IDAV931 obser
van que las especificaciones de alta calidad deben estar almacenadas electr6r\iQ.-

mente, ser ejecutables 0 por 1 0 menos interpretables, estar anotadas por importallCJio
relativa, ser estables, tener indicada la versi6n, estar organizadas, incluir referenc:il!l

~
~

cruzadas y especificarse con el grado de detalle correcto. Aunque, al parecer. muchas de estas caracterfsticas tienen una naturaieza

(OlO(tertshros cit III

~~VE .....
~y.",

a.a.

tativa, Davis el oj IDAV931 sugieren que cada una puede representarse empl
una 0 mas metricas. Por ejemplo, sup6ngase que hay nr requisitos en una especI. caci6n, de modo que

especlico06n as pcdJIe obi,. 1.1'1 conociniento QJQIltitoliYo de 10

do """'.

n,= nj+ nrf

donde flJ es el numero de requisitos funcionales y ntf el de no funcionales (como desempefto). Para determinar la especificidad (falla de ambigiiedad) de los requisitos, Dans

al. sugieren una metrica basada en la cons;stencia de la interpretaci6n de los r

res de cada requisito:

donde n"" es el numero de requisitos que todos los revtsores interpretaron de Ia rna manera . Cuanto mas cercano este el valor de Qat, menor sera la ambi,... ...." de la especificaci6n. El ci6n
Q~ =

grade de avance de n,/ln, x nJ

los requisitos funcionales se determina al ca\Cular Ia

donde nues el numero de requisitos de fund6n unk:.a; nt, el nfunero de entradas (

los) definidos 0 implkitos en la especiflcad6n, y n .. el numero de estados e!1pecl6c",,"s

La relaci6n Q1 mide el porcentaje de funciones necesarias que se han espedfiC:alZ

ra un sistema. Sin embargo, no se atienden requisitos que no son funcionales corporarlos a una metrica general del grado de avance, se debe considerar el validaci6n de los requisitos:
QJ = n~/["(

+ "no1

donde

"ces el numero de requisitos que se han validado como correctos, y n

requisitos que aun no se validan .

,.., 10 .. SIlO ~, V10 que 110 10 sea. weMlo meRWfQbIt.

cAPiTuLo 15

MtrRICAs DEL PROOUCrO PARA EI. IOf'TWARE

.7.

Selia inconcebible que el dlseno de un nuevo avi6n. un nuevo chip de computadora o un nuevo edificio de oficinas se realizara sin defimr las medidas del disenO, Sin detenninar las metricas de diversos aspectos de la calidad del disefto y sin usarlas pa ra guiar la manera en que evoluciona el diseno, Sin embargo. a menudo eJ dJseno de sistemas de software cornplejos suele avanzar casi sin medicien. La ironIa es que se dispone de metricas de diseno para el software. pero la gran mayoria de los desarro\Iadores siguen ignorando su existencia. Las metricas de diselio para el software de computadora, como todas las dem~s metricas del software. no son perfectas. Sigue abierto el debate sabre su eficacia y la manera en que deben aplicarse. Muches expertos argumentan que se necesita mas experimentaci6n antes de emplear las mediciones en el disei\o. Sin embargo, un disei'lo sin medici6n es inaceptable.

15.4.1 Metricas del diseno arqultecton1co

Las metricas de diselio arquitect6nico se concentran en las caracteristicas de Ja arquitectura del programa (capitulo 10). y se destacan la estructura arquilecl6nica y la efectividad de m6dules 0 componentes denlro de la arquitectura. Estas metricas son de "caja negra~, en el sentido de que no requieren ningUn conocimienlo del funcionamiento interno de un componente de software en particular. Card y Glass ICAR90J definen Ires medidas de la complejidad del disei'lo del software: estructural, de datos y del sistema. En el caso de las arquitecturas jerarquicas (por ejemplo, las arquitecturas de 11amada y retorno), la compJejidad estructural de un m6dulo j se define de la siguiente manera:
S{i) - f lOUl {i)

(15.2)

dondeJCJll\(i) es la dependencia hacia fuera' del m6dulo i. La compfejidad de datos propordona una indicaci6n de la comp[ejidad de la inlerfaze intema de un m6du[o ; y se define como:
D(i) - v(i)/Vo<n(i)

+ 1J

(15.3)

donde v(i) es el numero de variables de entrada y salida que se pasan al m6dulo i 0 se reciben de este. Por ultimo, compJejidad del sistema se define como la suma de las complejidades estrnctural y de datos, especificada como:
CV) 5(1)
8

+ Oil)

(15.4)

Dependcl"ICia haaajiJo"rJ se define como el numero de m6duJos inmediatamente subordlnados al

m6duJo i; es decir, el numero de m6duJos invocados directamente por i. La contralia, dependentia hada denlro, sena una variableftt que indique eI nlimero de m6dulos que invocan direclamente al m6duloi.

PARTE DOS

PRACTICA DE LA INGl':HlER!A DEl. SOFTWARI!

A medida que aumentan estos valores, la complejidad arquitect6nica general del tema lambien 10 haee. Esto lIeva a una mayor probabiJidad de que aumenten los fuerzos de integraei6n y prueha Fenton [FEN91 J sugiere varias metricas simples de morfologia (es decir. de f, que permilen la comparad6n entre diferentes arquitecturas de programas emp do un conjunlo de dimensiones directas. Si se toma como referenda la arquit de lIamada y retorno de la figura 15.5. se definirim las siguientes metricas: lamaii.o=n

+a

donde n es el numero de nodos y a, el de areos. En el caso de la arqultectura trada en la figura 15.5, tamano - 17 + 18 = 35 profundidad - 4, el camino mas largo desde el node raiz (superior) a un hoja. anchura ". 6, numero maximo de nooos en cualquier Rivel de la arquitcclUQ. relaci6n arco-a-nodo. r ,., a/ n, que mide la densidad de las conexiones y proporciona una simple indicaci6n dQ, acoplamiento de la arquitectura. En el caso de la arquitectura mostrada en la fi~

r - 18117 '" 1.06. EI COmando de Sistemas de 1a Fuerza Aerea de Estados Unidos IUSA87j ha d~ rrollado varios indleadores de la ealidad del software que se basan en las caracteris15.5,

tieas de diseno que pueden medirse en un programa de computadora. Empleandc. conceptos similares a los propuestos en el IEEE Std. 982.1- 1988 IlEE941. la FuerD Ai~rea estadounidense emplea informaci6n oblenida del disefio de datos y arquitec16nico para derivar un indice de calidad de la estruclura de disei\o (ICED) que va df o a I . EI ctilculo del ICED requiere determinar los siguientes valores ICHA89] .
51 ,. el numero l otal de m6dulos definidos en la arquitectura del programa

M etricas de

Node

modologia.

Profundidod

j r-"'-~~
~.~------------------- ~~ --------------------~.

C APiTuLo 15

MmlCAS DEL PRODUCTO PARA EL SOFTWARE

481

52 "" el numero de m6dulos cuya funci6n correcta depende de la fuente de entrada de datos a que produce datos que se usaran en otro lugar (en general, los m6dulos de control , entre otros, no se contarian como parte de 52) 53 = el numero de m6dulos cuya funci6n correcla depende de! procesamiento anterior 54 "" el numero de elementos de base de datos (incluye objetos de datos y 10dos los atributos que definen objetos) 5s = el numero total de elementos unicos de base de datos 56 = el numero de segmentos de base de datos (registros diferentes u objetos individuales) 57 = el numero de m6dulas can una sola entrada y salida (con excepci6n del procesamiento, no se considera una salida multiple) Una vez que se han detenninado los valores del 5 1al57 para un programa de computadora, es posible calcular los siguientes valores intermedios:
Escructura del programa; 0 1, donde 0 1 se define como sigue: si el disei'io arquitec-

t6nico se desarro1l6 empleando un metodo distinto (por ejemplo, disei'io orientado al flujo de datos u objetos). entonces 0 1 = I; de 10 contrario, 0 1 = o.
Independencia del m6dulo; O2
'"

1 - (52 /5d

M6dulos no dependientes del procesamiento anterior: 0 3 = 1 - (53 /5 1) Tamano de la base de datos; 0 4 = 1 - {5s/54) Oivisi6n en compartimientos de la base de datos; 0 5 = 1 - (56 /5 4 ) Caracteristica de entrada/salida del m6dulo:
D6

= 1 - (5715 1)

Una vez detenninados los valores intermedios, se calcula el ICED de la siguiente manera: ICED

=IwP;

{lS.S)

donde j .. 1 a 6, Wj es el peso relativo de la importancia de cada uno de los valores Wi '" 1 (si todo D j tiene pesos iguales, entonces Wj = 0.167). intermedios, Y se determina el valor de [CEO para los disefios anteriores y se compara con un disefio que esta en desarrollo. Si el [CEO es significativamente menor que el promedio, 10 indicado es realizar trabajo de diseno y revisi6n adicionales. De iguaJ manera, si se van a realizar cambios importantes en un disei'io existente, podra calcularse el efec-

to de esos cambios sobre el ICED.

_ _ _ _ .... ' ....... 10.. _ _1.

............... Ia medkiOn 15 un demo. U. dmio nemario, porqut Ia mayoria de los SIRS . . . . . . .

15.4.2 Meb1cas para 91 d1sefto onentado a objetos

Gran parte del disei'io orientado a objetos es subjetivo {un disei'iador experimentado "sabe" c6mo caracterizar un sistema orientado a objetos para que implemente efec-

482

tivamente los requisitos del c1iente) . Pero, a medida que aumenta el tamana y complejidad del modelo de diseno orientado a objet05, un concepto mas objetivo las caracteristicas del diseno benefidarfa al disenador experimentado (que obtend::i.

conocimientos adicionalesJ y al prindpiante (que obtendria una indicaci6n de la c;a.

lidad que de atta manera no estarfa disponiblej.

En un tratamiento detallado de las metricas del soRware para sistemas orieru

dos a ohjelos, Whitmire {WH197J describe nueve caracteristicas distintivas y mellSio rabIes de un diseno orientado a objetos: Yamano. EI tamano se define a partir de cuatro conceptos: pob\aci6n, volumcl

(arlKferistl CIS ",.dea nttdirSI (uando $I IValila In diSliio orienlado a objetos?

longitud y funcionalidad. PobJacion se mide al tamar un contee estatico de enticl.alk! orientada a objetos como clases u operaciones. L:ls medidas de volumen son idenii cas a las de la poblaci6n, pero se recopilan dinamicamente (en un momenta dele minado) . La longitud es una medida de una cadena de elementos de disefio interm nectados (por ejemplo, la profundidad de un arboi de herencia es una medida de lewgitud) . Las metricas de juncionalidad proporcionan una indicaci6n indlrecta del
entregado al cliente en una apUcaci6n orientada a objetos. COmplejidad. Como el tamano, hay muchos conceptos diferentes de la compie-jidad del software [ZUS97) . Whitmire considera la complejidad desde el punto de va ta de las caracteristicas estruclurales, al examinar la manera en que se interrelaci; nan las clases de un disefto orientado a objetos. Acoplamiento. Las conexiones fisicas entre los elementos de un disefto orielllOl do a obietos (por ejemplo, el numero de colaboraciones entre clases tado a objetos. Suficienda. Whitmire define suficiencia como "el grado en que una abstracciar posee las caracteristicas que se Ie piden, 0 el grado en que un componente de dise-fto posee caracteristicas en su abslracci6n, desde el punto de vista de la aplicacD actual". Expresado de otra manera , se pregunta: icuaies propiedades debe tener C$ta abstracci6n (clase) para que sea ulil? [WHI97J . En esencia, un componente de tfj. sefto (por eiemplo, una ciase) es suficiente si retleja plenamente todas las propie<a des del objeto de dominio de la aplicaci6n que se esta modelando (es decir, que .. abstracci6n, 0 ciase, posee las caracteristicas que debe tenerI.
0

el de mens.

jes pasados entre objetos) representan el acoplamiento dentro de un sistema o~

:~._"''''''''''''''''''doI-''''_''''' __ :I ':';~ '~: ~_~ f .111:t~.

f

Grado de avance. La unica diferencia entre el grado de avance y la suficienca es "e\ coniunto de caracteristicas contra las que comparamos el componente de abstracci6n 0 diseftoHIWHI97J. La suficiencia compara la abstracci6n desde el punto de' vista de la aplicaci6n actual. El grado de avance considera varios puntos de vista

cAPiTuLo

15

MrntCAS DEL PROOOCTO PARA D. SOf'1'WAJU:

48'

planteando la pregunta: ;.CUales propiedades se requieren para representar plena~ mente el objeto del dominio del problema? oebido a que los criterios para el grado de avance conslderan diferentes puntas de vista, indican indirectamente el grado en que puede reutnlzarse el componente de abstracci6n 0 diseno. Cohesion. Como su contraparte en el software convencional, un componente orientado a objetos debe disenarse de manera que todas las operaciones trabajen en combinaci6n para alcanzar un solo prop6sito, bien definido_ El grado de cohesi6n de una cJase se detellTlina al examinar el grado en que "el conjunto de propiedades que posee es parte del dominio del problema 0 el diseno" fWH197J. Primitivismo. Una caracteristica similar a la simplicidad, el grado de primitivis~ rno (aplicado a operaciones y clases) es el grado en que una operaci6n es at6mica (es decir, la operaci6n no puede canstruirse a partir de una secuencia de otras operacianes contenidas dentro de una c1ase). Una clase que muestra un alto grado de primitivismo s610 encapsula operacianes primitivas. Similltud. Esta medida indica el grado en que dos a mas c1ases son sirnilares en cuanto a su estructura, funci6n, comportamiento a prop6sito. Volatilldad. Como ya se ha visto en este libro, los cambios de disef\o ocurren cuando los requisitos se rnodifican 0 cuando las modificaciones se presentan en otra 0 que produce una adaptaci6n obligatoria del componente parte de una aplicaci6n, 1 del disena en cuesti6n. La valatilidad de un componente de diseno orientado a oov jetos mlde la probabilidad de que ocurra un cambia. En realidad, las metricas del producla para sistemas orientados a objetos no wlo se aplican al modelo de diseflo, sino tamblen al de analisis. En las seccianes que siguen se exploraran las metricas que proporcianan una indicaci6n de la caUdad al nivel de clase orientada a objetas y al nivel de operaci6n.

15.4.3 Meb1cas orientadas a closes: la colecc1on de mebicas de CK

La c1ase es la unidad fundamental de un sistema orientado a objelos_ Por tanto. las

medidas y melricas de una clase individual, la jerarquia de clase y las colaboraciones de clase seran invaluables para un ingeniero de software que debe valorar 1a ca lidad del diseflo. En capftulos anteriores se vio que la clase encapsula aperadanes (procesamiento) y atributos (datos). La c1ase suele ser el "predecesor" de las subcla ses (a veces denominadas descendientes) que heredan sus atributos y operacianes. Con frecuencia, la c1ase colabora con otras clases_ Cada una de estas caracteristicas se utiliza como base de la medici6n.9
v v

Chidamber y Kemerer (CHI94] propusieron uno de los conjunlos de melricas de

software orientado a objetos al que se hace referencia con mayor frecuen cia. A me9 Debe observarsc que aun se debate en Ia bibllografla tecniCa la validez de algunas de las melricas analizadas en este caprtulo_ Quienes derM'!nden 11 teot1a de Ia medici6n. exigen un grade de formalismo que algunas metricas orientadas a objetos no propon::ionan Sin embargo. es razenable deter minar que las metrlcas indicadas propordonan conoomientos 1.ihJes para el ingenlero de software

...
~

~~

nudo denominadas colecci6n de metricas de CK, los autores proponen seis rnetricB de diseno basado en clases para sistemas orientados a objetos. 10

C&VE
EI rimero de metoOOs

ysu (omplejiOOd esItr1

O:redcmenle

conelo(ionodos con eI
esfuerzor~
portI

Metodos ponderados poT d ase (MPC). Suponga que n rnelodos de complejidilll! cj, cJ, ... ,cn esta.n definidos por la clase C. La metrica de complejidad especifica se elija (pOT ejemplo, la complejidad ciclomatica) debe nonnalizarse con eJ fin de que complejidad nominal de un metoda tome un valor de 1.0. MPC = Ie;
para i = 1 a n. EI numero de metodos y su complejidad son indicadores raz onablts de \a cantidad de esfuerzo requerido para implementar y probar una clase. Adern& cuanto mayor sea el numero de metodos, mas complejo sera el arbot de herena;. (todas las subclases heredan los metodos de sus predecesores) . Por ultimo, confar

proIw lRI dose.

,. ......
LDheiWB511!1l

me crece el numero de metodos de una c\ase detenninada, es probable que se vud va mas y mas especlfica de la aplicacion, 10 que Iimita sus posibiJidades de reutil.iza. cion. Por todas las razones mencionadas, MPC debe mantenerse 10 mas bajo que SeI posible . Aunque parezca relativamente simple desarrollar un conteo del numero de me. dos en la ciase, en realidad el problema es mas complejo de 10 que parece. Debe desarrollarse un enfoque de contea consistente para los metodos [CHU95}. Arbol d e profundidad de la heren d a (APH) . Esta metrica es Hla longitud miDI rna desde el nodo hasta la raiz del arbol" [CHI94}. Si toma como referenda la figwa 15.6. el valor de APH para la jerarquia de c1ase mostrada es 4. A rnedida que c:n::a la APH. es probable que las clases de nivel inferior heredaran muchos metodos es.

,..".,
{OOSl1f

""""""'. rxaIJemos '"'* Ikse

si se

siJ 0Adl00. III APH y obm mfuns pcwa obfetlef In!' kttJo de " ,.,.;.;mI do Os _ d o ....

Jerarquia de una cl"",.

I
"

I
10 Chidamber y Kemerer usan el termino mttodosen J ugal de operodones. La forma en que emplean

lermino se reneja en esta secci6n

48.
to se presta a posibles difkultades cuando se trata de predecir el comportamiento de una clase. Una jerarqu[a de clase profunda (su APH es mayor) lambien se presta a una

mayor complejidad de disef\o. Por ellado positiv~, valores grandes de APH indican que se podrian reutillzar muchos metodos.
Niimero de descendlentes (NDD). Un descendiente es una $ubclase que se
en~

cuentra inmediatamente subordinada a olra en la jerarquia de clases. Si se lorna co

mo referenda ta ligura 15.6, la c1ase C1 liene tres descendientes (las subclases Cll , en y C: 1 3) A medida que crece el numero de descendientes, se incrementa la reutiIizaci6n. pero podrla dilulrse la abstracci6n que representa la clase predecesora sl al&uno de los descendientes no es un miembro apropiado de la clase predecesora. A medida que aumenla el NOD, tambien 10 hace la cantidad de pruebas (requeridas para ejercitar cada descendiente en su contexte operacional). Acoplamiento entre clases de objetos (AECO). El modelo de conjunta de res-

puesta de una clase (CRe), expuesto en el capitulo 8, se emplea para detenninar el valor de AECO. En esencia, AECO es el numero de colaboraciones enlistadas, para una clase, en su tarjeta de Indice eRe. (( A medida que AECO aumenta, es probable que disminuya la racilidad de reutilizaci6n de una clase. Valores elevados de AECO lambien 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 mas bajo que sea razonable. Esto es consistente con la directriz general para reducir el acoplamiento en el software convencional. Respuesta para una clase (RPC). El canjunlo de respuesta para una clase es un

"conjunto de metodos que liene la posibilidad de ejecutarse como respuesta a un mensaje que recibe un objeto de esa clase" [CHI94j. La RPC es el numero de metodos en el conjunto de respuesta . A medida que la RPC aumenta, el esfuerzo requerido para probar tambien 10 hace, debido a que crece la secuencia de prueba (capitulo 14). Tambien se desprende que, a medida que la RPC aumenta, se incrementa la complejidad del diseno general de la clase. Falta de cohesion en me-todos (FCM). Cada metoda dentro de una cJase, C, tie-

ne acceso a uno 0 mas atributos (tambien denominados variables de inscancia). La FCM es el numero de metodos que acceden a uno 0 mas de los mismos atributos. 12 5i ningun metodo accede a los mismos atributos, entonces FCM '"' O. Para ilustrar el caso donde FCM <I- 0, imaginese una cJase de seis metodos. Cuatro de elias lienen u no 0 mas atributos en comun (es decir, acceden a alributos comunes) Por tanto, FCM = 4. 5i la FCM es alta, los metodos pueden acoplarse entre sl mediante atribu tos. Sto aumenta la complejidad del diseno de c1ase. Aunque hay casas en que re -

II Si las tarjetas de fndfce CRC se desarrollan manu.Jlmente. el grado de avance y la conslstencia deben evaluarse antes de determinar el AECO de
IJ\MleB

conftabk

12 La definici6n formal es un poco mas complqa ConiuItese ICHI941 para conacer mas detalles

...

PARTE DOS

PRAcncA DE lJ\.

~ DIl. SOFTWARE

suJta justificable un valor elevado para la FCM. 1..0 deseable es mantener alta Ja cohesi6n; es decir, conservar baja la FCM .lJ

tie mell1cds de CK

Vinod; St,

CIS!

10 aeo ..

...,..-..

probw. 5epO!odcn JornirI: IC- que: 10

Iiempo' Vinoch A Ie largo, $I.

15.4.4 Mebicas orientadas a objetos: 10 colecc1on de metrtcas para el

diseno orientado a objetos
Harrison, Counsell y Nithi [HAR98] propanen un conjunto de metricas para diseflo orientado a objelos que proporcionan indicadores cuantitativQs para las caractelis-

ticas del disefio orientado a objetos. A continuaci6n se presente una pequena muestra de estas metricas:

13 La metrica FCM proporciona conocimientos utiles en algunas situaciones, pero puede malinterpno tarse en otras. POT ejemplo, mantener el acoplamiento encapsulado denlro de una clase aument. cohesi6n del sistema como un todo. Por tanto, por 10 menos en un sentido importante, un FCM elevado en realidad sugiere que una clase puede tener una mayor cohesioo, no una menor.

48'
Metodo del factor de herend a (MFH). EI grado en que la arquitectura de clases de un sistema orientado a objetos usa la herencia para metodos (operacionesj y alri ~ bulos se define como

donde la sumatoria se presenta desde i - I hasta Te. Te se define como e[ ntimero tc-

tai de dases en la arquitectura; C, es una clase dentro de 1a arquitectura y

Ma(q -= Md(C j )

+ MdC,)

donde
Ma(C,)

-=

el numero de metodos que pueden invocarse en asociad6n con C,

M,fC,j = el mimero de metodos declarados en la clase C'O

MtC1J = eJ numero de metodos heredados (y no redefinidos) en C,. EI valor de MFH (el atributo de factor de herencia, AFH, se define de manera am11ogal es un indicativa del impacto de la herencia en el software orientado a objeles

"8..aIM .. softwn orientacIo a _

flCl'D evaluar su caUdadse estti voIviendo todo flt m6s ~ t .. ~ ponIgmo [....... ",",oJ'" go"'"'" "",Orldod.'

Factor de acoplamlento (FA).

AI principio de esle capitulo se indic6 que el aco-

plamiento es una indicaci6n de las conexi ones entre elementos de un diseno orientado a objetos. EI conjunto de metricas del disef\o orientado a objelos define el acoplamiento de la siguiente manera:
FA -

Ii Lj e5_c1iente

(C~ 9/(T/ - T, )

donde las sumatorias van desde i = I hasta T, y desdeJ .., 1 hasta T,. La fund6n

es_diente "" I, si Y 561 0 si existe una relaci6n entre la clase cliente, en Y la clase servidor, C5 , Y C. "" 0, en cua!quier otro case Aunque muchos factores afectan la complejidad, la facilidad de comprensi6n y el mantenimiento de! software, resulta razonable concluir que, a medida que aumenta el valor de FA,
tambi~n

c.: '"

aumentara la compleJidad del software orienlado a objeles

Y, como consecuencia, es posible que resulten afectadas la fadlidad de comprensi6n Y mantenimiento, junto con la posibilidad de reutilizaci6n Harrison Y sus cOlegas [HAR98] presenta:t una ana.!isis detal!ado de MFH y FA, junto con otras metricas, y examinan su validez para emplearlos en la evaluaci6n de la calidad del disei'io.

...

PARTE DOS PAACrICA D U INGENlERiA. Ofl. SOFTWARE

15.4.5 Metricas orientadas a oblatos propuestas por Lorenz y Kid.d

En su libra sabre metricas orientadas a objetos. Lorenz y Kidd [LOR94J dividen las

metricas basadas en dases en cuatro amplias categorias. cada una con un disei'io al nivel de componentes: tamafto, herencia, valores internos y vaiores externos. Las metricas arientadas at tamano aplicadas a una clase de disefio orientado a objetos se concentran en el contee de atributos y operaciones de una clase individual, asi como en valores promedio para el sistema orientado a objetos como un todo. Las metricas basadas en la herencia se concentran en Ja manera en que las operaciones
,se reutilizan en la jerarquia de dases. Las metricas para los valores internos buscan cohesi6n y aspectos orienlados al c6digo, y las metricas de valores extemos examinan el acoplamienlo y la reutilizaci6n. A continuaci6n se presenla una muestra de las metricas propuestas por Lorenz y Kidd:

fl.o .....
"""'" do _ ,
IXIOno66n

Tamafio de la clase (Te). siguientes medidas:

El tamano general de una clase se determina con las

Dl.xanm fa f8Visi6n del

EI numero tolal de operaciones (de instancia heredada y privada) que esttm encapsuladas dentro de la clase. EI numero de atributos (de instancia heredada y privada) que esttm encapsulados por la clase.
La metrica MPC que propusieron Chidamber y Kemerer (secci6n 15.4.3) lamb

/as tG/iB1rJs rill indice

(R[ fXOIKKdooorfm

"""""de.,
...,~

"",._do.
das6. 5156 800J111)tro ooadas6 (MOO m:merO groode d9
,~,

"""""'
6fl

rIvid"riJ.

es una medida ponderada de tamano de clase. Como ya se indic6. los valores grandes de TC indican que tal vez una clase tenga demasiada responsabilidad. Esto reo ducira la posibilidad de reutilizaci6n de la clase y complicara la implementaci6n y prueba. En general, debe darsele mas peso a las operaciones y los atributos hereda. dos a publicos para determinar el tamano de la clase [LOR94j . Las operaciones y atributos privados permiten la especializaci6n y estan mas focalizados en el disenc, Tambien deben calcularse los promedios para el numero de atributos y operacioncs de clase. Cuanto menores sean los valores promedio para el TC. mas probable que las clases dentro del sistema puedan reutilizarse ampliamente. Ntimero de operaciones aftadJdas por una subclase (NOAl. las subclases especializan al agregar operaciones y atributos. A medida que el valor de NOA menta, la subclase se aparta de la abstracci6n implicita en la superclase. En gene a medida que la profundidad de la jerarqula de clase aumenta (APH se vuelve .,.". yor), debe caer el valor de NOA en los niveles inferiores de la jerarquia.

15.4.6 Metrlcas de disefto al nlvel de componentes

las metricas de disei'io al nlvel de componentes del software convencional se centran en las caracteristicas internas de un componente de software e incluyen didas de cohesi6n, acoplamiento y complejidad del m6dulo. Estas medidas ayudan un ingeniero de software a juzgar la caJidad de un disefio al nivel de componen

CAPiTuLo 15

Mtm!CAS DEL PROOOCTO PARA EL SOFTWARE

...

Las metricas presentadas en esta secd6n son de "caja de crista!", en el sentido de que requieren conocimiento del funcionamiento interne del m6dulo que se esta. considerando. Las metricas de disena al nive! de componentes se aplican una vez que se ha desarrollado el diseno procedimental. Como opci6n, pueden demorarse hasta que eI c6digo fuente este disponible. Metricas de cohesi6n. Sieman y Ott [SIE94J definen una colecci6n de metricas

que proporcionan una indicaci6n del grada de cohesi6n (capitulo 9) de un m6dulo. Las melricas se definen a partir de cinco conceptos y medidas:
Porci6n de datos. Definido simplemente, una poreion de datos es un recorrido

hacia atnis por un m6dulo; busca valores de datos que afectan el estado del m6du10 cuando comienza el recorrido. Debe indicarse que es posible deftnir las porciones del programa (que se concentran en instrucciones y condiciones) y las porciones de datos,
Muestras de datos. Las variables deftnidas para un m6dula se definen como

muestras de datos para el m6dulo.

Seflales de uni6n. Este con junto de muestras de datos cae en una 0 mas porcio-

nes de datos.
Seflales de supcruni6n. Estas muestras de datos son comunes a todas las porcio-

nes de datos de un m6dulo.

capaddad de uni6n. La capacidad de uni6n relativa de una senal de uni6n es di-

rectamente proporcional al numero de porciones de datos que une. Bieman y Ott desarrollan metricas para cohesi6n fundonal jiJerte, cohesi6n Jundonal
debil y adhesividad (que se relaciona can el grado en que las senales de uni6n integran

las porciones de datos). Estas metricas se interpretan de la siguiente manera [BIE94]: Todas estas metricas de cohesi6n abarcan valores de 0 a 1. Tienen un valor de 0 cuando un procedimiento cuenta con mas de una salida y no muestra atributo alguno de cohesi6n indicado por una metrica particular. Un procedimiento sin senales de superuni6n (es decir, sin muestras comunes a todas las porciones de datos), tiene 0 cohesi6n funcional fuerte (no hay muestras de datos que contribuyan a todas las saJidas), Un procedimiento sin senaJes de uni6n (es dedr, sin muestras comunes a mas de una porci6n de datos, en procedimientos con mas de una porci6n de datOS) muestra 0 cohesi6n funcional debi! y 0 adhesividad (no hay muestras de datos que contribuyan a mas de una salida). La cohesi6n funcional fuerte y la adhesividad se encuentran cuando las metricas de Bieman y Olt taman un valor maximo de I . MHricas de acoplamiento. El acoplamiento del m6dulo proporciona una indica-

ci6n de la "conectividad" de un m6dulo con otros m6dulos, con datos globales yean el entoma exterior. En el capItulo 9 se analiz6 el acoplamiento desde el punta de vista cuaHtativo.

490

Dhama [DHA95] ha propuesto una metrica para el acoplamiento del m6dulo que abarca el acoplamiento de Oujo de dalos y de control, el global y el de entomo. I...as medidas necesarias para calcular el acoplamienlo del m6dulo se definen a partir eX cada uno de los tres tipos de acoplamiento indicados antes. En el caso del acopa. miento de flujo de datos y de control,
d~

- numero de parametros de datos de entrada

numero de parametros de datos de salida numero de parametros de control de salida

ce = numero de parametros de control de entrada dJ C s

..

..

En el caso del acoplamiento global:

gd = numero de variables globales usadas como datos

ge '" ntlmero de variables globales usadas como control

En el caso del acoplamiento de enlomo: w '" numero de m6dulos l1amados (dependencia hada [uera) r .. numero de m6dulos que Ilaman al m6dulo en cuesti6n (dependencia dentrol COn estas medidas se define un indicador de acoplamiento del m6dulo, guiente manera:
m~ =

rna, de ]a

k/M

donde k es una constanle de proporcionaJidad y

M=~+~x~+~+~X~+~+kx~+w+r

Los valores de k, a, bye deben derivarse emp[ricamente. A medida que el valor de rnaaumenta, disminuye el acoplamiento general del dulo. Para lagrar que la metrica de acoplamiento suba a medida que aumenta el do de acoplamiento, se defi ne una metrlca de acoplamienlo revisada

donde el grado de acoplamiento aumenta a medida que 10 hacen las medidas ecuaci6n (15.6).
M ~trlcas de compleJldad. Es posible calcular diversas metricas del sofl:~ para delerminar la complejidad del flujo de control del programa. Muchas de se basan en la grafica de flujo. Como se anaHz6 en el capitulo 14. una grafiCi. una representaci6n compuesta de nodos y enlaces (tambien deno,mil1a<joS.. ,jSIJ~ Cuando los enlaces (aristas) estan dirigidos. la grafi ca de fl:ujo es una gratica

gida.

'9'
Mccabe y Watson [MCC94) identifJCaJl varios usos importantes para las metricas de complejidad:
Las metricas de complejidad se utilizan para predecir 1a informaci6n crttica acerea de la confiabilidad y 1a fadlidad de mantenimiento de sistemas de software a partir del analisls automatico del c6digo fuenle [0 la infonnaci6n del disei'io proccdimental]. Las melriclJS de

complejidad lambic!:n ofrecen retroalimenlacl6n durante e1 proyeclo de software para ayudar a controlar [la actlvldad del disei'iOj. Durante las pruehas y eI mantenimlenlO, ofrecen una informaci6n detatlada accrca de los m6dulos de software para ayudar a detectar areas de posible Inestabilidad.

La metrica de complejidad cuyo usa es el mas extendido (y debatido) para el software de computadora es la complejidad ciclomatica, originalmente desarrollada por Thomas McCabe [MCC761. [MCC89J, y que se analiz6 con todo detalle en el capitulo 14, Zuse ({ZUS90]. rZUS971J presenta un am\lisis encic1opedico de no menos de 18 categorias diferentes de las metricas de complejidad del software. El autor presenta las definiciones basicas de metricas en cada categoria (por ejemplo, hay distintas variaciones de 1a metrica de complejidad cic1omatica) y luego analiza y critica cada una. El trabajo de Zuse es el mas completo pubJicado a la fecha.

15.4.7 Metrlcas orientadas a la operacion

Oebido a que la ciase es la unidad dominante en los sistemas orientados a objetos, se han propuesto pocas metricas para operaciones que residen dentro de la clase. Churcher y Shepperd {CHU9S] analizan esto cuando afirman: "Los resultados de estudios recientes indican que los metodos tienden a ser pequeftos en cuanto al numero de instrucciones y a complejidad 16gica [W1L9.3]. 10 que sugiere que la estructura de conectividad de un sistema es mas importante que el contenido de los m6dulos individuales". Sin embargo, se apreciaran mejor las cosas si se examinan las consull as promedio de metodos (operaciones) Tres metricas simples, propuestas por Lorenz y Kidd rLOR941, resultan apropiadas: Tamano promed1o de operad6n (TOpn>m). Aunque las lineas de c6digo po-

dMan usarse como indicador del tamano de operaci6n. la medida de Hneas de c6digo adolece de una serle de problemas analizados en el capitulo 22. Par ella, el numero de mensajes que envla la operaci6n proporciona una opci6n al tamano de operaci6n. A medida que aumenta el nUmero de mensajes enviados por una sola operaci6n. es probable que las responsabilidades no se hayan asignado bien dentro de la clase. Complejldad de la operacl6n (CO). La complejidad de una operaci6n se caku1a empleando cualquier metrica de compleJidad propuesta para el software convencional [ZUS90]. Oebido a que las operaciones deben Iimitarse a una responsabilidad especifica, el disenador debe esforzarse por mantener la CO 10 mas baja posible .

4.,

PARTE DOS

PS1J.Cl'ICA DE 1-" ~ DEL SOFTWARE

NUmero promedlo de parimetros de la operadon (NPOpoom"

Mientras

IN'

yor sea el numero de parametros de la operaci6n, mas compleja sera la colabora entre los objelos. En general, el NPOpn:on debe mantenerse 10 mas bajo posible.

15.4.8 Meb1cas de diseno de la intedm de usuarlo Aunque hay obras lmportantes que tratan el diseno de interfaces ser humano/maq
(capitulo 12), se ha pubJicado relativamente poca infonnaci6n sobre metricas que pre!' porcionen conocimientos profundos sobre la calidad y la facilidad de uso de la intert&..

Sears ISEA93) sugiere que \0 apropiado dd formata (AF) es una metrica de diseiio liosa para interfaces ser humano/maquina. Una GUI cornun aplica entidades de fI
to (iconos grafices, texto. menus.

ventanas, etc.) para ayudar al usuario a completar entid;"

in'

reas. Para realizar una tarea detenninada can una CUI, el usuario debe pasar de entidad de presentaci6n a la siguiente. La poslci6n absoiuta y reialiva de cada entidad de fonnato a la siguiente conlribuirtm a detenninar 10 apropiado de la de presentaci6n, la frecuenda con que se emplea y el "cosi o" de la transici6n de

- ...................
... 10 _

.ter'-

.. ,..., del c&seiII 0. inMrfoo.s de uwario si .m.1o ,. __

Kokoi Y sus colegas [KOK95] definen una melrica de cohesion para las de la interfaz de usuario que mide la conexi6n relativa entre el contenido de

D.""'....

""',..._,

/os mitricos de Ifs8Ilo de 10 ilfeffaz

pantalla y el de otra. 5i los datos (0 el contenido adidonal) presentados en una lalla pertenecen a un solo objeto importante de datos {como se defini6 de'ntn"~ modelo de analisisl. la cohesi6n de la interfaz para esa pantalla sera alta. 51 se senlan muchos tipos diferentes de datos a contenidos y esos datos se relacionan diferentes objetos de datos, 1a cohesi6n de la interfaz de usuario sera baja. Los tores proporcionan modelos empl ricos para la cohesi6n IKOK95J. Ademas, las medidas directas de la inleracci6n con la interfaz de USlJ.,ios< .acentran en la medici6n del tiempo requerido para alcanzar un escenario 0 un ,.,. rad6n espedficos, elliempo requerido para recuperarse de una condid6n

""......... _. .
lIS necmlo I1Sf(/lt

son odoodas, petO

~ aios USOOIios

" . yde !pi .tsros SIt siootMI c&noOOs

con /os iltIJrocdonls

de ...~

"""'""

los conteos de operadones 0 tareas especfficas requeridas para alcanzar un caso USO, el numero de objetos de datos 0 contenido presentados en una pantalla, I sidad y el tamai'io del texto y muchos otros. Sin embargo, estas medidas directas estar organizadas para crear metricas de interfaz de usuario que tengan un si cado y que lIeven a mejorar la calidad, la facilidad de usa, 0 ambos elementos interfaz de usuario.

Es importante observar que la selecci6n de un diselio de inlerfaz grafica de"""

rio puede detenninarse a partir de metricas como AF 0 la cohesi6n de pantalla interfaz de usuario, pero eJ arbitro final debe ser la entrada del usuario b.,,.da prototipos de interfaz grafica de usuario. Nielsen y levy [NIE94J reportan que - se ne una probabilidad razonablemente grande de exilo si se elige entre las i ' ,lIe,1" 4

cAPiTuLo 15

MtnllCAS DEl. PROCOCTO PARA D. SOFTWARE

493

IdiseriosJ basadas exclusivamente en las opiniones de los usuarios. EI desemperio promedio de las tareas de los usuarios y su satisfacci6n subjetiva con una inlerfaz grafica de usuario tienen una elevada correlacl6n"

La teoria de Halstead de la "ciencia del software" rHAL77J propuso las primeras "leyes" analiticas para el software de computadora. 14 Halstead asign6 leyes cuantitativas al desarrollo de este software empleando un conjunto de medidas primitivas que se derivan despues de que se ha generado el c6digo. 0 se estiman una vez que el diserio esle completo. Las medidas son:
nl

el numero de operadores distintos que aparecen en un programa . n l ... eJ numero de operandos dislintos que aparecen en un pragrama.
-

NI - el numero total de veces que aparece el operador. N2 - el numero total de veces que aparece el operando.
Halstead aplica estas medidas primitivas para desarrollar expresiones relacionadas con la longitud global del programa. el volumen minimo posible para un algoritmo. el volumen real (numero de bits requeridos para espedficar un programa). el nivel del programa (una medida de la complejidad del software). el nivel del lenguaje (una constante para un lenguaje detenninado) y otras caracterisUcas como esfuerzo de desarrollo, tiempo de desarrollo y hasta el numero proyectado de fallas en el software. Halstead demuestra que la longitud N se puede estimar asi:

N - n, logl n, + n.llCl&2 nJ
y que el volumen de programa
V '" N

se puede definlr como:

1082 (nl + n 2)

Se debe observar que V variara de acuerdo can ellenguaje de programaci6n y que re presenta el volumen de infonnaci6n (en bits) necesario para especificar un programa.

En teoria, debe existir un volumen minima para un algoritmo determinado. Halstead define una relaci6n de volumen. l . como la relaci6n entre el volumen de la for ma mas compacta de un programa y el volumen real del programa. En realidad, l siempre debe ser menor que I . Desde el punto de vista de las medidas primitivas, [a relaci6n de volumen se expresa como
14 Debe observarse que las "Ieyes" de Halstead hall gcnc'rado gran controversia, y muchos creen que la leoTia tiene falias Sin embargo, se ha reahzado Ia venlicaci6n experimental de lenguajes de programacl6n sele<cionados (POT ejemplo. IfL89JI

-'

'8_" '................,.......

[p"' ..... 010 do ........1.,., ....... 10 ......

--

...

PARTE DOS

PRAcncA DE LA INGN!llIlA DL SOfTWARE

L = Un]

x n21N2

E1 trabajo de Halstead es sensible a la verificaci6n experimentaL y se ha realiza

do una gran cantidad de investigaci6n sobre la ciencia del software. Para obtener
mas informaci6n. consultense 12U59O], IFEN91J Y [2U597].

Aunque se ha escrito mucho sobre las metricas del software para pruebas (por ejem-

propuestas se concentran en el proceso !k prueha, no en las caracteristicas tecnicas de Jas propias pruebas. En general. quienes aplican las pruebas deben depender de las metricas de anaJisis, disefio Y c6digo como guia para el disefi.o y la ejecuci6n de los casos de prueba. Las metricas basadas en 1a funci6n (secci6n \5.3.1) se aplican para predecir el esfuerzo general de la prueba. Es posible recopilar varias caracteristicas al nivel del proyecto (como el esfuerzo y el tiempo para las pruebas, los errores descubiertos, et
plo, [HET93J), casi todas las metricas numero de casas de prueba producidos) de proyectos anteriores y correlacionarlas con el m.imero de puntos de funci6n que produce un equipo de proyecto. Este equipo tiene la opci6n posterior de proyectar "valores esperados" de estas caracteristicas para el proyecto actual. Las metricas del disei'io arquitect6nico proporcionan infonnaci6n sabre la factJi. dad
0

",
1Jo1
1)

la dificultad asociada con la prueba de integraci6n (capItulo 13) y 1a necesidad

C~VE
los que Ireton de

de contar con software especializado en pruebas (por ejemplo, resguardos y con troladores) . La complejidad ciciomAtica (una metrica de diseflo al nivel de componen tes) cae en el eje de las pruebas de camino Msico, un metodo de diseflo de casas de: prueba presentado en el capitulo 14. Ademas, la complejidad dc\omatica se emplea para determinar los m6dulos que seran candidatos a pruebas de unidad mas extensas. Los m6dulos con elevada complejidad cic\omatica son mas propensos a error que [os que tienen una menor complejidad. Por ella, la persona responsable de 11prueba debe realizar un esfuerzo superior al promedio para descubrir errores en estos m6dulos antes de integrarlos en un sistema.

los ~fri(os de p-uebo

se ~ eIl~

IIIf4IIios (DtegoOOs:

proo eI rIiim&ro

ploOOije de piueOOs

que se requie(eI1 a wOOs niveIes de

""1),, ..
se tOlKenlTOn en 10
cobertua~ . . .
~ooc~nfe

15.6.1 Metricas de Halstead apl1cad.as a las pruebas

Tambien es posible estimar el esfuerzo que requieren las pruebas mediante metricas derivadas de las medidas de Halstead (secci6n 15.5) . Si se aplican las definiciones volumen, V, y el nivel de un programa, NP, el esfuerzo de Halstead, e, se calculara as!:
NP", \/[(n I /2)

determilodo.

(N2 1n 2lJ

e '" VINP
ria con la siguiente relaci6n: porcentaje de esfuerzo de prueba (k) "" e(k)/Ie(J)

(1 5.

EJ porcentaje del esfuerzo general de prueba que se debe asignar a un k se esti ~

( 15.1ll

donde k) se calcula para el m6dulo k empJeando las ecuaciones (15.7), y donde

C APInn.o 15

MtrRICAS DEL PRODUCtO PAllA El. SOFTWARE:

495

sumatoria en el denominador de la ecuaci6n (15.8) es la suma del esfuerzo de Halstead en todos los m6dulos del sistema.
15.6.2 Metricas para pruebas orientadas a objetos

Las metricas del disefi.o orientado a objetos expuestas en la secd6n 15.4 proporcionan una indicaci6n de la calidad del disei'io. Tambien proporcionan una indicaci6n general de la cantidad de esfuerzo necesario en la prueba para ejercitar un sistema orientado a obietos. Binder [BIN941 sugiere una amplia serie de metricas de disefio que tienen una influenda directa sabre la "facilidad de prueba" de un sistema orientado a objetos. Las metricas toman en cuenta aspectos de encapsulamiento y herencia. A continuaci6n se presenta una mueslra: Falta de cohesi6n en metodos (FCM).15 Mientras mayor sea el valor de FCM, deben probarse mas estados para asegurar que los metodos no generen efedos colalerales. Porcentaje publico y protegido (PYP). Esta metrica indica el porcentaje de atributos de clase que san publicos 0 estan protegidos. Valores elevados de PYP aumentan la probabilidad de efectos colaterales enlre clases porque los atributos publicos o protegidos conllevan una alta probabilidad de acoplamienlo (capitulo 9).16 Deben disefi.arse pruebas para asegurar el descubrimiento de estos efectos colaterales. Integrantes de a cceso publico a datos (APD). Esta metrica indica el numero de clases (0 metodos) al que tienen acceso otras atributos de clase, 10 que es una violaci6n del encapsutamiento. valores elevados de APD conllevan la posibilidad de efectos colaterales entre clases. Deben disefiarse pruebas para asegurar el descubrimiento de estes efectos colaterales. Nlirn.ero de clases raiz (NCR). Esta metrica es un conteo de las distintas jerarquias de clase descritas en el modele de disefto. Deben desarrollarse conjuntos de prueba para cada clase raiz y para la jerarquia de clases correspondiente. A medida que aumenle el NCR, tambien aumentara el esfuerzo de la prueba. Dependencia hacia dentro (FIN) . Cuando se aplica en el contexte orientado a obietos, la dependencia hacia dentro para la ierarquia de herencia es un indicadoT de herencia multiple. FIN> 1 indica que una clase hereda sus atributos y operaciones a partir de una clase raiz. Debe evitarse que FIN> 1 a tada costa . Nfunero de descendientes (NDD) y arbol de profundidad de herencia (APH).'1 Como se analiz6 en el capitulo 14, es necesario volveT a probar los metodos de la superclase de cada subclase.

IS COnsultese la secci6n 15.4.3 para conocer una descripci6n de FCM. 16 Algunas personas promueven diseilos en que runguoo de los atributos es publico 0 privado; es decir. PYP ,. 0 Esto indica que todos los atributos deben accederse en otras clases por medio de metodos. L7 Consultese la secci6n 15.4.3 para conocer una descnpd6n de NOD y APH.

496

PARTE DOS

PRAcnCA DE LA lNGENJIRiA DL SOFTWARE

15.'

Mlx,lCAI PAlA XL MAMtl.INII.TO Tadas las metricas del software presentadas en este capitulo se aplican tambien desarrollo de nuevo software y al mantenimiento del existente. Sin embargo, se haD propuesta metricas disenadas expHcitamente para actividades de mantenimiento. EI IEEE Std. 982.1-1988 (IEE941 sugiere un Indice de madurez del software (IMSr que proporciona una indicaci6n de la estabilidad de un producto de software (basa da en los cambios que ocurren can cada versi6n del producto). Se determina la g. guiente infonnaci6n:
Mr = eJ numero de mOdulos en la versi6n actual

Fe

= el numero de m6dulos cambiados en la versi6n actual

Fa = e\ numero de m6dulos aftadidos a la versi6n actual

FJ = el numera de m6dulos de la version anterior que se eliminaron en la actual

EI indice de madurez del software se calcula de la siguiente manera: IMS = [My- (Fa + Fe + Fd )]1 Mr A medida que ellMS se acerca a 1.0, el producto empieza a estabilizarse. EIIMS tambien se aplica como metrica para la planeaci6n de aclividades de mantenimiento dd software. EI tiempo media para praducir una versi6n de un producto de software puede carrelacionarse con eiIMS, y pueden desarrol!arse modelos empiricos para d. esfuerza de mantenimiento.

~ Metricas del p r oduc to

~ Objetivo: Ayudor 0 los ingenieros de softwore en eI de5Crrolio de metricos

significotivos que evo\OOn los productos deltrobojo generodos durante eI modelodo de oOOlisis y di~no, 10 ganeraci6n de c6digo !vente y 10 pruebo.

Mecanica: Los herramienlcs de esta cotegorio oborcon uno omplio serie de metricos y ~ implernentan como oplicociones independientes 0 (con mayor frecuencio) como fvncionolidod que e;.;iste dentro de los herromienlcs paro ooolisis y di~no, codificoci60 0 pruebo. En 10 mayor parte de los cosos, 10 herromienta de metrico onoliro uno repre~ntaci60 del software (por ejemplo, un modelo UMl o el c6digo fuentel y de5Crrollo uno 0 mas metricos. Herramientas representativGs l'
Krolcolcu Metrics, descrrolloda par Power Software (www. powersoftwore.com/products) , colculo metricos

de compJejidod, Halsteod y otros relacionodas paro C/C++ y JavtI. Metric$4C, desarrollodo por +1 Softwore Er.gineering (www.plus-one.com/Mretric~C-foct_sheet.hlml). cokulo vorios rniltricos orquilect6nicos, de di!.eOO y orientodos a c6digo, adem6s de olras orientodos 0 proyeclo. Rational Rore, de5CrroHodo por Rotionol Corporation (www.ro~onol.com). es un conjunlo de herromientm completos poro eI modelodo UMl que incorporo vorios corocleristicos de on6lisis de metricos. RSM, de5Crroliodo por M-Squored Technologies (msquoredtechnologies.com/ m2rsm/index.hlml), cokulo uno omplio voriedod de rniltricos orientodos 0 con~guraci6n para C, C++ y Java. Underslond, de5Crroliodo par Scientific Toolworb, Inc. (www.scitools.com). colculo los metricos orientoclos 0 c6digo paro diverses lenguojes de progromoci60.

18 Las herramientas expuestas representan una muestra de esta categorla. En cdsi lodos los casos lea nombres de tas mismas son marcas registradas de sus respecUvos desarrotladores.

cAPiTuLo 15

MtnIICAS DEL PROO!JCTO PARA El. SOF1WARt

497

Las metricas del software proporcionan una manera cuantitativa de evaluar la calidad de los atributos internos de un producto, 10 que permite que un ingeniero de software evalue la calidad antes de construirlo. Las metricas proporcionan los conocimientos necesarios para crear modelos efectivos de analisis y diseiio, un c6digo s6lido y pruebas exhaustivas. Para que resulte util en la realidad, una melrica del software debe ser simple y calculable, persuasiva, consistente y objetiva. Debe seT independiente del lenguaje de programaci6n y proporcionar retroalimentaci6n efectiva al ingeniero del software. Las metricas para el modele de analisis se concentran en la funci6n, los datos y el comportamiento (1os tres componentes del modelo de analisis). Las metricas para el disefio consideran los aspectos del disefio de la arquitectura, al nivel de componenles y de la interfaz. Las metricas del disefio de la arquitectura consideran los aspectos estructurales del modelo de disefio. Las metricas de diseiio al nivel de componentes indican [a calidad del m6dulo al estab[ecer medidas indirectas para la cohesi6n, el acoplamiento y la complejidad. Las metricas de diseiio de la interfaz de usuario proporcionan un indicio de la facilidad con que se usa la interfaz grMka del usuario. Las metricas para los sistemas orientados a objetos se concentran en la medici6n que puede aplicarse a las caraclensticas de clase y disefio (localizaci6n, encapsulamiento, ocultamiento de infonnaci6n, herencia y tecnicas de abstracci6n de objetos) que convierten a la clase en unica. Halstead proporciona un conjunto interesante de metricas al nivel de c6digo fuenteo Empleando el numero de operadores y operandos presentes en el c6digo, se desarrolla una variedad de metricas para evaluar la calidad del programa. Pocas metricas del producto se han propuesto para emplearlas directamente en las pruebas del software y en el mantenimiento. Sin embargo, muchas otras metricas del producto pueden aplicarse para guiar el proceso de prueba y como mecanismo para evaluar la facilidad de mantenimiento de un programa de computo. Una amplia variedad de metricas orientadas a objelos se ha propuesto para evaluar la facilidad de prueba de un sistema orientado a objelos.
REFEIENelAS
[ALB79] Albrecht, A. J., "Measuring Application Development Productivity", en Proc. IBM Application Development Symposium, Monterey, CA, octubre de 1979, pp. 83-92. [ALB83] Albrecht, A. J. y J E. Gaffney, ~Sonware Function, Source Unes of Code and Development Effort Prediction: A Software SCience Validation", en IEEE Trans. software Engineering, noviembre de 1983, pp, 639-648. IBAS84] Basili, v. R. Y D. M. Weiss, "A Methodology for Collecting valid SOftware Engineering Data", en IEEE Trans, Software Englrlcenng, vol SE-l0, 1984, pp. 728-738. [BER951 Berard, E" "Metrics for Object-Qrienled Software Engineering", publicaci6n de Internet en comp,software-eng, 28 de enero, 1995 [B1E94l Bieman, J. M. Y L M. Ott, "Measuring Func:tional Cohe9on" en IEEE Trans, SOftware En gineering, vol. SE-20, num. 8, agosto de 1m, pp 308-320

PARTE DOS

1'RAct1CA DE LA ItQNln!lA DEL SOFTWARE

[BIN94] Binder, R V" ~Object-oriented SOftware Tesllng , en CACM, vo\. 37, nlim. 9, septiem de 1994, p. 29 [BRI%J Briand, L C., 5. Morasca y V. R Basili, "Property-Based SOftware Engineering Me~ ment", en IEEE 7tarlS. SOftware Engineering, vol. 5-22. num, J, enero de 1996, pp. 68-85 [CAR90] Card, O. N. Y R L. Glass, Measuring Software Design Quality, Prentice-Hall, 1990. [CAV78] Cavano, J. P. Y J. A. McCall, "'A Framework for the Measurement of SOftware Quallt}", Prrx. ACM software Quality Assurance workshop, novlembre de 1978, pp. 133-139. (CHA89] Charette, R N., SOftware Engineering Risk Ana!Ysis and Managemet1/, McGraw-Hili/Inter text, 1989. (CHI94] Chidamber, S. Rye F. Kemerer, "A Metrics Suite for Object-Oriented Design~, en 1m 1taru. software Engm~ng, vol SE-20, num, 6. junio de 1994, pp. 476-493. [CH1981 Chidamber, S R , D. P Darcy y C. F Kemerer, ~Management Use of Metrics for Objta Oriented SOftware: An Exploratory Analysis, en IEEE 7tems. Software Engin~ng, vol, SEnum 8, agosto de 1998, pp. 629-639. [CHU95] Churcher, N. I. Y M J. Shepperd, -roward a Conceptual Framework for Object-Orien Metrics , en ACM SOftware Engineering N~es, vol. 20, num, 2, abril de 1995, pp. 69-76 [CUR80] Curtis, W., "Management and Experimentation in SOftware Engineering", en Proc. fUE. vol. 68, num, 9, septiembre de 1980. [DAV93] Davis, A, et ai, "Identifying and Measuring Quality in a SOftware Requirements Spec lication", en Prrx. First Inti. sojtware Metrics Symposium, IEEE, Baltimore, MD, mayo de I pp. 141 - 152. [DEM81] DeMilio, R. A Y R. J. Upton, "Software Project Forecasting", en software Metrics IA Perils, F G. Saywardy M. Shaw. eds.), MIT Press, 1981, pp. 77-89. [DEM82j DeMarco, T.. Controlling Software Projects, Yourdon Press, \982. [DHA95] Dhama, H.. "Quantitative Models or COhesion and Coupling in SOftware", en}OUmDI systems alld Software, vol. 29, nUrn. 4, abril de 1995. [EJ1911 Ejiogu, L, SoftIvare Engineering with Formal Metrics, QED Publishing, 1991 [FEL89] Felican, L y G. lalateu, "Validating Halstead's Theory for Pascal Programs", en I 1tans. software Engineering, vol. SE-IS, num. 2, dlc\embre de 1989, pp. 1630-1632 [FEN91] Fenton, N ,software Metrics, Chapman and Hall, 1991 . [FEN94] Fenton, N., "SOftware Measurement: A Necessary SCientific Basis", en IEEE 1tans, Sc: wore Engmeenng. vol. SE-20, num. 3, maTZO de 1994, pp. 199-206. [GRA87] Grady, R. e. y D. L. Caswell, Software Metrics; Eslab/ishing a Company Wide ~ Prentice-Hall, 1987. [HAL711 Halstead, M., Elements a/software SCience, North-Holland. t971 [HAR981 Harrison, R., S. ). Counsell y R V. Nlthl, ~An Evaluation of the MOOD set of ~ Oriented SOftware Metrics", en IEEE ltans. SOftware Engint!t!flng, vol. 5E-24, num 6, JUruo 1998, pp. 491 -496. IHET93] Hetzel, B., Maklng Software Measurement WOrk, QED Publishing, 1993. [lEE93] IEEE Standard G/ossory ofSoft\vare Engm~ng Termmology, IEEE, 1993. [IEE94] Software Engineering Standards, edici6n 1994, IEEE, 1994. [IFPCI] Function Point COtInting Practices Manual, versl6n 4 1 I, International Function Users Group, 2001, d!sponible en http://www.ifpug,org/publicationS/manualhtm, (IFP03] Function Point Bibliography/Reference Ubrary, International Function Point U Group, 2003. disponible en httpJlwww.ifpug.org/aboutlbibliography.htm. IKOK95[ Kokol, P, \. Rozman y v. venuti, "User Interface Metrics",ACM SlGPLAN Notices, vol nUm. 4. abril de 1995, puede descargarse de httpll portal.acmorg/. [KYB84J Kyburg, H. E., Theory and Measurement, cambridge university Press, 1984. [LT031 Lethbridge, T , comunicaci6n pnvada sobre metricas de software, junio de 2003 [LON02] Longstreet, D" " FUndamental of Function Point Analysis", Longstreet c onsulting. 2002, dispomble en httpJ/www.ifpug.com/ fpafund.htrn. ILOR94] Lorenz, M y J Kidd, Objecl-Oriented Software Metrics, Prentice-Hall, 1994. [MCC76] McCabe, T. J.,"A SOftware Complexity Measure", en IEEE 1taru, Software Enginemll vol. SE-2, dlcicmbre de 1976, pp. 308-320. [MCC77] McCall, )., p, Richards y G. Walters, "Factors In SOftware Quality", tres voKlmenes, AD-A049 -014, 015, 055, novicmbre de 1977.

CAPiTuLo 15

MmlCAS

DEL PROOUCTO PARA El.. SOfiWARE

499

[MCC89] McCabe, T. j. Yc. W. Butler, Design Complexity Measurement and Testing", en 0\C1rl, vol. 32, nUm. 12, diciembre de 1989, pp. 1415-1425. [MCC94] McCabe. T. J. Y A. H. Watson, Software en CompleXity", en crosstalk. vol. 7, num. 12, diciembre de 1994, pp. 5-9. [NIE94] Nielsen, J. y J. Levy. "Measuring Usability: Preference vs. Performance", en O\CM, vol. 37, num, 4, abril de 1994. pp. 65-75. [ROC94] Roche, J. M., "SOftware Metrics and Measurement Principles", en Software Engineering NOleS, ACM, vol. 19, num. 1, enero de 1994, pp. 76-85. [SEA93] Sears, A., "layout Appropriateness: A Metric for Evaluating User Interface widget layout", en IEEE 7hIns. Software Engineering, vol. SE-19, num. 7, julio de 1993, pp. 707-719. [SHE98] Sheppard, M., Goa!. Question. Metric, 1998, disponible en http://dec.boumemouth.ac.ukl ESERG/mshepperd/SEMGQM .hlm] [SOL99] Van SOlingen, RyE. Berghout, The Goal/Question/Metric Method, McGraw-Hm, 1999. [UEM99] Uemura, T., S, Kusumoto y K. Inoue, "A FUnction Point Measurement Tool for UML Design Specifications", en Proc. O/Sixth Intemational Symposium on SOftware Metrics, IEEE, noviembre de 1999, pp. 62-69, [USA87j Management Quali~ Insight, AFCSP 800-14 (U.s. Air Force), 20 de enero de 1987. [WHI97] Whitmire, S., Object-Oriented Design Measurement, Wiley, 1997. [WIL93] Wilde, N. y R Huitt. "Maintaining Object-Oriented SOftware", en rEEE software, enero de 1993, pp. 75-80. [ZUS90J Zuse, H., Software Complexity: Measures and Methods, DeGruyter, 1990. [ZUS97) Zuse, H., A Framework o/Software Measurement, DeGruyter, 1997.

15.1. la teoria de la medici6n es un tema avanzado que tiene una fuerte influencia sobre las metricas del software. Utilizando [ZUS97j. [FEN91J, [KYB84J u otras fuentes, escribir un breve ensayo que delinee los principales principios de \a teorla de la medici6n. Proyecto individual: desarroHar una presentaci6n sobre el tema y presentarla ante \a clase. 15.2. Los factores de calidad de McCall se desarrollaron durante la decada de 1970. Casi todos los aspectos de la computaci6n han cambiado drasticamente desde que se desarrollaron; sin embargo, los faclores de Mccall siguen aplicandose al software modemo. iPodtia Ilegarse a algunas conclusiones a partir de esle hecho? 15.3. ,Por qu~ no se puede desarrollar una sola metrica que 10 abarque todo para la complejidad 0 la caJidad de un programa? 15.4. Tratese de desarrollar una medida 0 una m~trica tomada de la vida real que viole los alributos de las metricas efectivas del software que se definieron en la secci6n 15.2.5 15.5. Un sistema tiene 12 entradas exlemas, 24 salidas extemas, campos para 30 consultas extemas diferentes, maneja cuatro archivos 16gicos extemos y tiene interfaces con seis sistemas heredados diferentes (6 AlE). Todos estos datos tienen una complejidad promedio, y el sistema general es relativamente simple. Calculese el punto de funci6n para el sistema, 15.6. EI software para el Sistema X liene 24 requisitos funcionales individuales y 14 no funcionales. iCual es la especificidad de los requisilOS? iEn que grado se ha completado? 15.1. Un importante sistema de infonnaci6n liene I J 40 m6dulos; 96 m6dulos realizan funciones de control y coordinaci6n, y 490 dependen de un procesamiento anterior. El sistema procesa alrededor de 220 objelos de datos, cada uno con un promedio de tres atributos. Hay J 40 elementos unicos de la base de datos y 90 segmentos diferenles de esta. Por ultimo, 600 m6dulos lienen puntos unicos de entrada y salida. calcUlese ellCED del sistema, 15.8. Una clase, X, liene 12 operaciones. se ha calcuJado la comp1ejidad ciclomatica para todas las operaciones del sistema orientado a objelos, y el valor promedio de la complejidad del m6dulo es de 4. Para la clase X, la complejidad ck la operaci6n 1 ala 12 es 5, 4, 3, 3, 6, B, 2, 2, 5,5,4 Y 4, respectivamente. Calculense los metodos ponderados por clase.

500

PARTE DOS i'RACTICA DE LA INGINlERIA. ru SOFrWARE

15.9. Desarr6l1ese una herramienta de software que calcule la complejidad dclomatica de m6dulo de lenguaje de programad6n. Elljase ellenguaje que se desee. 15.10. Desarrolle una pequefia herramienla de software que rea lice un analisis de Haist sobre c6digo fuente en ellenguaje de programaci6n que se desee. 15. 11. Un sistema heredado tiene 940 m6dulos. La ultima versi6n requiri6 que 90 de esaI m6dulos cambiaran. Ademas, se agregaron 40 nuevos m6dulos y se eHminaron 12 de esos mOo dulos. Calculese el Indice de madurez del software para el sistema.

Hay un numero sorprendentemente grande de libros dedicados a las metricas del software, que la mayor parte de ellos se concentra en las mctricas del proceso y el proyecto, por 10 excluyen las mctricas del producto. Kan (Metrics and Models in Software Quality Enginnng, dison-Wesley, segunda edki6n, 2002), Fenton y pfleeger (So..f/"ure Metrics; A Rjgourous and tIcal Approach, Brook.s<ole Publishing, 1998) y Zuse IZUS97] han escrilo IralamienlOS C tos de las mctricas del producto. Libros de Card y Glass ICAR90}, zuse [ZUS90[, Fenton [FEN91[, Ejiogu [EJl91], Moellery lish (Software Melrics, Chapman y Hall, 1993) y Hetzel [HET93] atienden las metricas del prodll.. to con algun detane, Oman y pfleeger I,Applyig Software Metrics, IEEE Computer Society 1997) han editado una antologla de artlculos importantes sobre las melricas del software. mas, vale la pena examlnar los siguientes Hbros: COnte, S. D., H. E. Dunsmore y V. Y. Shen, 50jlware Engirk!'ering Metrics and Models, min-cummings, 1984 Grady, R. B., Praccica/5o.fhwre MetricsJor Project ManagctrH!tlt and Process Im~t, lice-Hall, 1992 . Sheppard, M., Software Ensirrring Metrics, McGraw-Hill, 1992. Denvir, Herman y Whitty presentan la teorfa de la medld6n del so~wa,~e~e~"~""~at)~~~ editada de artlculos (PrOceedings of the In~mationol BCS-FACS workshop: suremenl, springer-verlag, 1992). Shepperd (Foundations of Software Hail, 1996) lambien aliende con cierto dela1ie la leorfa de la medici6n. EI estado vestigaci6n se presenta en los Proceedings of the Symposium on Software Melric:s (IEEE, dos anualmente) . Un resumen muy complete de docenas de metricas de software utiles se presenta en En general, un anallsls de cada metrica se ha reducklo a los ~primitivos~ (las medidas) ies necesarios para caicular la metrica y las reiadones apropiadas para realizar el calculo apendice proporciona un anaJisis y muchas referencias. Whitmire IWHI97] presenla el tralamiento mas completo y matematicamenle soliSlicada las mclricas orientadas a objetos que se haya publicado a la fecha . Lorenz y Kidd ILOR94] dersen-SeUers (Objcct-Orierlred Metrics: MNSU1l5 ofCOmp/exlty, Prentice-Hail, 1996) unico libro adicionai dedlcado a las metricas orientadas a obJetos. Hutcheson (So..fhwre Fundamentals: Methods and Metrics, Wiley, 2(03) presenla una gula uti! para la aplicaci()R uso de metricas para la prueba del software. Una amplia varledad de fuentes de informaci6n sabre metricas del soft.w;:a:;",,:"'~~;~::: disponible en Internet. Una lista actualizada de refe rencias en la World wide \-\ ra las metricas de! software se encontrara en el sitlo Web de SEPA: http:/t_,mhhe.comlpressman.

ApUCACION DE LA INGENIERiA WEB

n esta parte de Il1genJerIa del sojIwate, un enjbque pnictico. se aprenderAn los pIindpIos. conceptos y mttodos con que se crean apIicadones Web de alta calldad. Las siguientes preguntas se abordan en los capItuIos postel1ores:
;.Las aplk:adones Web (WebApps) tlpos de software?

son dlferentes de otros

.Que es \a Ingen\erIa Web Y que elementos de la practica de la InsenJella del software puede adoptar?

los elementos de un proceso de insenierla Web? .C6mo se formula yplanea un proyecto de Ingenleria Web? .C6mo se anaUzan y modelan los requlsitos de las WebApps? .Que conceptos y principios gulan la pr~ctica en el disefio de las WebApps? .C6mo se dIrigen \a arqullectura. la Interfase y el diseilo de navegacl6n de las WebApps? .Que tknlcas de construcci6n se pueden aplicar para implementar eI modelo del diseilo?

.~ son

.Que oonceptos. prindpios y metodos de prueba son aplicabios a \a Ingen\erIa Web?

Una vez respondidas estas pnegunlas se estar~ mejor preparado para realizar \a Ingenieria de aplicaciones Web de alta calidad.

50.

CAPitULO

16
CONCEPTOS

INGENIERiA WEB

...... ....... "'"

CLAVE

......... .511
... ; 101 .SOI

L
pido

a World Wide Web y la Internet que la alimentan son, posiblemente, los d4 sarrollos mas importantes en la historia de la computaci6n, Estas tecnol

8ias han lIevada a todos (can cientas de mitlones que eventualmen seguiran) a la era de la informatica; ademas, se han convertido en parte integl"l Para quienes pueden recardar un Mundo sin la Web, el crecimiento ca de la tecnolog[a tiene su arigen en atra era los primeros dias del sotlware .

mas

de la vida diaria en la primera decada del siglo XXI.

............ 0501
promo ... 507
_ell de traNI_ dtI ,,"110 ..509

una epoca de poca disciplina pero enonne entusiasmo y creatividad. Eran tiem pos en que los programadores a menudo ingresaban a sistemas en cooJunta. a ces para bien, a veces para mal. La actitud prevaleciente parecla ser: "hazlo

",","
~

y entra

en el campo; nQSOtros 10 Iimpiaremos (y mejor entiende que es

U

"tckllt .....51%

1Iaim . ..m
W ......

.......

que realmenle se necesita construir) conforme avancemos Hrme mi posici6n en relaci6n con la ingenieria Web.

<.Suena familiar?

En una mesa redonda virtual pubJicada en iEEE Software (PRE98J, mant

lItTi.tes 504
ClI...,., 506

Me parece que cualquier produClO 0 sistema lmportante yale Ia pena una ingeniena Antes de comenzar a construirla es mejor que entlenda el problema. disei'le una soluci6n factible, la implemente en una forma s6lida y la ponga a prueba ampliamente Tal yez tamblen tenga que controlar los camb\os conforme el trabajo avance y dispo. ner de algun mecanismo para asegurar la ca1ldad del resultado final. Muchos desarrolladores de Web no esttm de acuerdo con esLO; etlos piensan que su mundo realmente es diferente y que los enfoques convendonales de ingenierla del softwal'C simplemente no se aplican.

ofl'ecen un complejo arreglo de con' tenido y funcionalidod a una ompIia pob!o<;&, d. """";.. h.... ... ingenieria web (lWeb) es eI prtUSO con eI <p sa croon webApp.s de aha Ilidod. La fWeb no es un doo perfecto de 10 ingenMwfo c:W toEtwv-

que ditciplinodo para eI desarrollo de on sisle' ma batodo en to computodorn. , _ Ie _ , "" y k de.o. i'dadotet del contenido que no es tecnica creon las WtbApp. &POT ...... Imp....- , Conlonne 10. W.... ~ Ie imegron coda ez m6~ en las .strate--re, pero lorna prestodc muc:ho. ~ 'I gias de negoclOi para pequeiias y gra~ principios fundamentales d. ella. Ademo. " 8iYIpiWSCJ$ (pol' efempIo, en eI comercio electroni proceso lWeb acentUo octividodn lr6cnicas Y eo), creal en impartancia 10 necesidad de cons' administrativo$ similares. Exis\en sutilel diferen

,Qui 1 los sistemas yoplicocion" based", en W.b IW....""'I

ciat en

kJ monero coma se dirigen dichas activi

dodes., 1*0 eI metodo prirnon:fial dido un enfo.

'ngen_ W'"

CAPITuLo 16

lNGENIERlA WIJ!

503

tn.tfr sistemas Por tonto, .. I'IIOIItCIio en <uonto 01 doocw.uRo

too
que 9I'_icIO c:,.ae gias, t6c:ticm '1 m6todot ceso fw.b comienm pocbIemo quo ..

pIoneo

diseIIo fa """""YO ............... r "OI! cializacb osociodot con entrego Q 10. UIUCW'ioI
$itos Y ..

01.,...,-

...... 10 he En oc:osfones es diffc~

"""'"'" linaleo eje<u.
dol ooIowoo. do los mcdoIos 1Wob, .. global. dol ........, 1 0 '" do...."" y ko -"<lad.

"""".

"*- .

Esto conduce a una pregunta clave: ;.sc pueden aplicar principlos, conceptos y metodos de 10 ingenieria del software 01 desarrollo Web? Es posible aprovechar muchos de ellos, pero su aplicaci6n puede requerir un giro un tanto diferente. lPero que ocurre si persiste un enfoque sin disciplina respecto al desarrollo Web? En ausencia de un ptoceso disciplinado dirigido a desarrollar sistemas basados en Web, existe una creciente preocupaci6n de que se enfrenten serios problemas en su desarrollo, despJiegue y mantenimiento exitosos. En esencia, la infraestructura de aplicaci6n que se esta creando en la actualidad puede conducir a una "Web enmaranada" conforme se adentra mas este nuevo sig1o. Esta frase entrafia un cumul0 de aplicaciones basadas en web mal desarroHadas y que tienen muy altas probabiJidades de fracaso. Peor aun, conforme los sistemas basados en Web crecen con mayor complejidad, una falla en uno puede propagar y propagaril amplios problemas por media de muchos. Cuando esto ocurra, la confianza en toda la Internet sera sacudida. Peor aun, podria conducir a una regulaci6n gubernamental innecesaria y mal concebida, 10 que provocara un dano irreparable a estas tecnologlas unicas. Para evitar una Web enmarafiada y lograr mayor exilo en el desarrollo y la aplicacion de sistemas basados en web complejos y a gran escala, exisle una apremiante necesidad de enfoques disciplinados y nuevas metodos y herramientas con que desarrollar, desplegar y evaluar los sistemas y aplicaciones basados en Web. Tales enfoques y tecnicas deben considerar las caracterislicas especiales de los nuevos medias, los ambienles y escenarios operativos, y la multiplicidad de perfiles de usuario que colocan desaflos adicionales al desarrollo de aplicaciones basadas en Web. La ingenierfa Web (Iweb) apJica "s6lidos principios cientificos, de ingenierfa y de administraci6n, y enfoques disciplinados y sistemilticos para el desarrollo, despliegue y mantenimiento exitosos de sistemas y aplicaciones basados en Web de alta caJidad" [MUR99].

504

PARTE TRES

AP1.1CAC16N DE LA INGENIERiA WEB

En los primeros dias de la World Wide Web (circa 1990 a 1995) los "sltios Web" con-

sistian en poco mas de un conjunto de archivos de hipertexto ligados que presentaban informaci6n mediante texto y grarkos limitados. Conforme e\ tiempo pas6, d
HTML aument6 al desarrollar herramientas (pof ejemplo, XML, Java) que permilieron a los ingenieros Web ofrecer capacidades de ctliculo junto con informaci6n. Nacieron los sistemas y aplicaciones l basados en Web (se les referira de manera colee-

tiva como WebApps). En la actualidad, las webApps han evolucionado en sofisticadas herramientas de computaci6n que no s6ta proporcionan funci6n por si mismas al usuario final. sino que tambien se han integrado con bases de datos corporativas y aplicaciones de negocios.

-. :',-:..-:-,. en "'''' ~ f

'teCIftIOS

tierta ....-. de estabiUloci6n, 10 Web se habra mmdIo. ""-

.~.

... ....
::

-I
17

Existe poco debate en cuanto a que las webApps son diferentes a las mudar otras categorlas de software infonnatico analizadas en el capitulo 1. Powell resu las diferencias principales cuando establece que los sistemas basados en Web "invo lucran una mezcla entre publicaci6n impresa y desarrollo de software, entre maliceting e informatica, entre comunicaciones internas y relaciones externas, y entre_ te y tecnologla" IPOW98j. En la gran mayoria de las webApps se encuentran loss. guientes atributos.

f"CONWO"
50,.......".,,"

lntensidad de red. Una WebApp reside en una red y debe satisfacer las neceg. dades de una variada comunidad de clientes. Una WebApp puede residir en la Intt. net /y, en consecuencia, permitir una comunicaci6n mundial abierta). AiternatiYiI mente, una aplicaci6n puede colocarse en una Intranet (10 que implementa la cOOll nicaci6n en una organizaci6n) 0 en una Extranet (comunicaci6n inter-red). Concurrenda. Un gran numero de usuarios puede teneT acceso a la webApp mismo tiempo. En muchos casos, los patrones de uso entre los usuarios finales riaran enormemente. carga imprededble. EI numero de usuarios de la WebApp puede variar en denes de magnitud de dia con dia. Ellunes pueden mostrarse 100 usuarios; el tes pueden usar el sistema 10 000.
En el contexto de este capitulo, el termino "aplicaci6n Web" (WebApp) abarca todo, desde

,,,.,,,,,,. '"
",""",
1oxM,

Cf.Jfl1Rlap;c1KiOO

tro6ciotd dsnlro d6
domikl5 de stwrxe rmtrxJas til II cO(i/rJo

istrJ de atributos. Si1

,,... """"'... '"

W~ casi siem/Xe

pie pAgina Web que puede ayudar al consumidor a caicular el pago de arrendamiento de un m6vil. hasta un amplio Silio Web que proporcione servicios de viaje completos para genk' negocios y vacacionistas. Dentro de esta categona se incluyen los silios Web completos, la nalidad especializada dentro de los sitios Web y las aplicaciones de procesamiento de '" que residen en la Internet 0 en una Intranet 0 ExtraneI.

,fm""'"

CAPmn.o 16

INGENIERiA WIB

505

Desempeiio. Si un usuario de WebApp debe esperar demasiado (para ingresar, para procesamiento en ellado del servidor, para formateo y despJiegue en ellado del cliente) puede decidir irse a cualquier etra parte. Disponlbilldad. 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 "24/7/365". Los usuarios en Australia 0 Asia pueden demandar acceso durante momentos cuando las tradlclonalesaplicadones de sonware domestico en Norteamerica pueden estar fuera de linea por mantenimiento. Gobemada por los datos. La funci6n primordial de muchas webApps es usar hipermedia para presentar contenido de texlO. gralicos. audio y video al usuario fi nal. Ademas. por 10 general, las WebApps se utili zan para tener aceeso a informad6n que existe en bases de datos que originalmente no eran parte integral del ambiente basado en Web (por ejemplo, comercio electr6nico 0 aplicaciones financie ras). Sensibilldad aJ contenldo. La caUdad y naturaleza estelica del contenido sigue siendo un impartante determinante de la calidad de una WebApp. Evolud6n continua. A diferencia del sonware de aplicaci6n convencional, que evoluciona a 10 largo de una serie de planeadas Iiberaciones espaciadas cronol6gicamente, las aplicaciones web evolucionan de manera continua. No es raro que algunas WebApps (especificamente. su contenido) se actualicen sobre una agenda minuto a minuto. 0 que el contenido sea caJculado de manera independiente para cada solicitud. Algunos argumentan que la evoluci6n continua de las webApps hace que el trabajo realizado sobre elias sea analogo a la jardineria. Lowe [LOW99[ comenta esto cuando escribe:
La insenierfa Irala de adopta r un enfoque consiSlenle y cienllfico. suavizado por un can

texto practico espedflro. para el desarrollo ycomisionado de slslemas 0 aplicaciones. Con frecuenda, el desarrollo de silios Web se relaciona mucho con ta creaci6n de una infraestructura (sembrar el Jardin) y luego con ~cultivar'" la informad6n que crece y relona dentra de esle jardin. A )0 largo del Uempo. el jardln (eS decir. el silio Web) continuara evoludonando. camblando y creciendo. Una buena arquitectura inicial debe permltir que este crecimiento OCUrTa en una fonna controlada y consislente ..

EI cuidado continuo y la alimentaci6n permiten que un siUo Web crezea (en robustez e impartancia). Pero. a diferencia del jardin, las aplicadones Web deben satisfacer IY adaptarse a) las necesidades de alguien mas que el jardinero. Inmediatez. Aunque la inmedia~ -Ja apremiante necesidad de paner software en el mercado rapidamente- es una caracteristica de muchos dominios de aplicaci6n, las webApps con frecuencia muestran un tiempo para comercializar que puede ser cuesti6n de unos cuantos dlas 0 semanas 1 Los ingenieros web deben aplicar
2 COn las herTamientas modemas se pueden productr etaboradas ptlginas Web en cuesU6n de unas cuantas horas.

506

PARTE TRES APlJcACJ6N DE IA lNGENlER!A WEB

melodos de planeaci6n, analisis, diseno, implementaci6n y puesta a prueba que han side adaptados a los apretados tiempos requeridos para el desarrollo de webApps segurldad. Puesto que las WebApps esta.n disponibles mediante eJ acceso a la red , es dillcil, si no imposibJe. limitar la pobJaci6n de usuarios finales que pueden

te-

net acceso a la aplicaci6n. Con la finalidad de proleger eJ contenido confidencial y

ofrecer modos seguros de transmisi6n de datos, se deben implementar fuertes medidas de seguridad a 10 largo de la infraestructura que sustenta una WebApp y denlro de la aplicaci6n misma . Estetica. Una parte innegable de la apariencia de una WebApp es su presentaci6n y la disposicl6n de sus elementos. Cuando una aplicaci6n se disena para comer cializar 0 vender prcxluctos 0 ideas, la estetica puede tener tanto que ver con el exi to como el diseno te:cnico. Estos atributos generales se aplican a todas las WebApps, pero con diferentes gra dos de influencia. i Pero que hay de las webApps por elias mismas? iQue problemas abordan? En d trabajo IWeb es usual encontrar las siguientes categorlas de aplicaciones IDAR99J

"ON afttgo-rias lie w.bApps It _lntTo .. tI trDbajo IWeb?

Informarivo;
ces simples.

se proporciona contenido de 5610 lectura con navegaci6n y enla-

Descarga: un usuario descarga informaci6n del servidor apropiado. Personalizable: el usuario personaliza el contenido segun sus necesidades especificas.

Inceracci6n: 1a comunicaci6n entre una comunidad de usuarios OCllrre por medio de cuartos de charla, tableros de anuncios 0 mensajeria instantanea.

Enuada del usuario: 1a entrada con base en

formu larios es el principal meca(por ejemplo, realiza por

nismo para las necesidades de comunicaci6n.

Orientada a transacciones: el usuario hace una solicitud

un pedidO) que ejecuta la webApp.

Orientada a seIYicios: la aplicaci6n proporciona un servicio al usuario;

ejemplo, 1 0 asesora en la determinaci6n del pago de una hipoteca.

Porcal: la aplicaci6n canaliza a! usuario hacia otro contenido 0 servicios Web

fuera del dominio del portal de la aplicaci6n.

Acceso a una base de datos:

trae informaci6n.

el usuario consulta una gran base de datos y exde grandes bases de da-

Almacen de datos: el usuario consulta una colecci6n

tos y extrae informaci6n.

Los atributos comentados en esta secci6n, y las categorias de aplicaci6n destaca das lineas arriba, representan importantes hechos de vida para los ingenieros web
La clave es vivir dentro de las restricciones que imponen dichos atributos y aun a.si

producir una webApp exitosa.

cAPiTuLo

16

!NGINIER!A WEB

S07

EI desarrollo de sistemas y aplicaciones basados en web incorpora modelos de proceso especializados, metodos de ingenierfa del software adaptados a las caracteristicas del desarrollo de WebApps y un conjunto de importantes tecnologlas habilitadoras. Los procesos, metodos y tecnologias (herramientas) proporcionan un enfoque en estratos de la lWeb que es conceptualmente identico a los estratos de la ingenieria del software descritos en la figura 2.1.

,. . . . . Web traIa (O!I enfoques disOplinados y ~Iemilticos para el desarrollo, despIiegue y1MIIfIIiI . . . _ _ ,........,...." '" Wol.'

16.2,1

Proceso

Los modelos de procesos IWeb (que se tratan con detalle en la secci6n \6.3) adoptan la filosofia del desarrollo agi! (capitulo 4). El desarrollo agil enfatiza un enfoque de desarrollo riguroso que incorpora rapidos ciclos de desarrollo. Aoyama [AOY98j describe la motivaci6n para el enfoque agil en la siguiente forma:
Internet cambi6 la prioridad principal del desarrollo de software de que a cudndo. El reducido tiempo para el mercado se ha converticlo en el 1!mite competitiv~ por el que luchan las compaftias lideres. En consecuencia, reducir el cicIo de desarro1!o es ahora una de las misiones mas importantes de la ingenieria del software.

Aun cuando r<ipidos ciclos de tiempo dominan la reflexi6n acerca del desarrollo, es importante reconocer que el problema todavia debe analizarse, debe desarrollarse un disefi.o, la implementaci6n 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 I) adopte el cambia, 2) aliente la creatividad y la independencia del equipo de desarrollo y fortalezca la inleracci6n can los accionistas de la WebApp, 3) construya sistemas que utilicen pequefi.os equipos de desarrollo, y 4) subraye el desarrollo evolulivo 0 incremental mediante el uso de cortos ciclos de desarrollo [MCDOI j.

16.2.2

Metodos

EJ panorama de los metodos de lWeb abarca un conjunto de labores tecnicas que permiten al ingeniero Web comprender, caracterizar y luego construi r una WebApp de alta calidad. Los metodos de lWeb (que se tratan con detalle en los capitulos 18 al 20) se pueden categorizar de 1a siguiente manera: Metodos de comunicaci6n: definen el enfoque con que se facilita la comunicaci6n entre ingenieros Web y los demas participantes de la webApp (por ejemplo, usuarios finales, clientes de negocios, expertos en problemas de dominio, disenadores de contenido, lideres de equipo, gestoTes de proyectO), Las tecnicas de comunicaci6n son partkulannente importantes durante la recole<ci6n de requisitos y siempre que sea evaluado un incremento en 1a webApp.

...
ft".NSU
{s inpottmlB nofIJr
rpllTJKhas mitOOus (Web Sf hrrI oOOptOOo

PARTE TRES
M ~todos

API.L\C1ON DE LA INGOmJliA. WEB

de anMisis de requisitos : proporcionan una base para comprender el contenido que entregara una WebApp, la funci6n que proporcionara aJ usuario IInal

y los modes de interacd6n que cada clase de usuario requerira mientras ocum

1a navegaci6n por media de 1a WebApp.

_-...
9trJpos frxmarivas.

tilrlm6l1le de SlK CCtI/fopDIffSde" rIfriJ dtI SDhware. Otros IISrdn en sus

de disefio: abarcan una sene de tecnicas de disei'io que abordan contenido. 1a aplicaci6n y la arquitectura de infonnaci6n, asl como el diseiio de in
M ~ tod os

terfase y la estructura de navegaci6n de la WebApp.

....... do_

de prueba: incorporan revisiones tecnicas formales - tanto del conte-nido y el modelo de diseno como de una amplia variedad de tecnicas de prueba qu.. abordan connictos al nivel de componente y arquitect6nicos-, pruebas de la na~
M ~todos

corirJnne Sf supienrt merxes edtqJes.

gaci6n, pruebas de racilidad de usa, pruebas de seguridad y pruebas de configuraci Es lmportante sei'ialar que, aunque los metodos IWeb adoptan muchos d e los m mas conceptos y principlos subyacentes a los metodos de ingenieJia del
sonw~

descritos en la parte 2 de este libro, los mecanismos de amilisis, diseno y prueba ell ben adaptarse para acomodar las caracterlsticas especiales de las WebApps. Ademas de los metodos tecnicos que se han subrayado, es esencial una sene actividades sombrilla (con metodos asociados) para la ingenieria Web exitosa.

tsu.

incluye tecnicas de gesti6n de proyecto (por ejemplo, estimaci6n. calendarizaci anal isis de riesgo). tecnicas de gesti6n de configuraci6n de soflware y de revisi6n

"Ii, i )'RA'
So_

--

16.2.3 Herramienlas y tecnologia

A 10 largo de la decada pasada ha evolucionado un amplio conjunlo de herramier-las y tecnologla con forme las webApps se han welto mas complejas y extendid..z:. Oichas tecnologias abarcan un amplio conjunto de descripci6n de contenido y 1mguajes de modelad6n (por ejemplo. HTML. VRML, XML), lenguajes de programac' (par ejemplo. Java), recursos de desarrollo basados en componentes (por ejemp CORBA, COM, ActiveX, .NEn, navegadores, herramientas multimedia, herramien de autoria de sitio, herramientas de conectividad de bases de datos, herramientas seguridad, servidores y utilidades de servldor, y herramientas de administraci6n analisis de sitio. Un tratamiento completo de las herramientas y tecnologla para la lngenierla W esta mas alia del ambito de este libra. El lector interesado puede vlsitar uno a de los siguientes sitios Web: Web Developers Virtual Encyclopedia (www.wdlv.com

"'-"" w_. ""-I .........

If! .. tWlnloptr. ( 011 y..

webDeveloper (www.webdeve!opeLcom).[)(:veloperShed(www.devshed.com), Wi knowhow.ne/ (www.webknowhow.net) a WebReference (www.webrererence.com)

16.3

EL PROCESO pE IHGEHIERiA WEB

Los alributos de los sistemas y aplicaciones basados en Web tienen una prorunda In. fluencia sobre el proceso de [Web que se ellja. En el capitulo 3 se hizo notar que ingeniero de software elige un modelo de proceso basado en los atributos del salt

cAPfTuLo 16

INGOOllItA. wt:II

...

ware que habra de desarrollarse. Esta premisa tambien es cierta para un ingeniero Web. Si la inmediatez y Ja evaluci6n continua son atributos principaJes de una WebApp. un equipo de ingenieria Web debe elegir un modelo de proceso agil (capitulo 4) que produzca liberaciones de WebApp a un ritmo vertiginoso. Por otra parte, si una WebApp sera desarrallada durante un largo periooa (por ejemplo. una gran aplicaci6n de co mercia electr6nico) puede elegirse un modele de proceso incremental (capitula 3)

' EI dtsortolo Web e5 III ~1I\tI ... III igum CJlllIa m ayoria cia los adoIescenle5, quiere str or:eptodo tlIII'IO un ..Ito mnfIWmt idenlo oItjont cia sus padres. Si qujere okanzlIf tocIo su POtencial. 6tbt Jomor grm manias INa.
IllS cIeI

mas operinelmdo moodo cIeI dtsonolo de sohwur...

.....-...

La inlensa naturaleza de las aplicaciones de la red en este dominio sugiere una diversa pobJaci6n de usuarios (que. par 10 tanIo, reaiizan demandas especiales acer ca de respuesta y modelada de requisitOS) y una arquitectura de aplicaci6n que pue de ser altamente especializada (que en consecuencia realiza demandas aeerca del disena). Puesto que can frecuencia las WebApps son conductoras de eontenido, can

enfasis en la estetica, es probable que se proyecten actividades de desarrollo para lelas dentro del proceso rWeb e involucren un equipo de personal tanto tecnico co mo lego (par ejemplo, publieistas, disenadores granCOS).

16.3.1 Definicion del marco de trabajo

Cualquiera de los modelos de proceso agil (por ejemplo, Programaci6n Extrema , De sarrollo de Software Adaptativo. SCRUM) presentados en el capitulo 4 se pueden aplicar de manera exitosa como un proceso lWeb. EI marco de tTabajo del proceso que se presenta aqul es una amalgama de los principios e ideas tralados en dicho capitulo. La efeclividad de cualquier proceso de ingenieria depende de su adaptabilidad Eslo es, la organizaci6n del equipo de proyecto, los modos de comunicaeion entre miembros del equipo, las actividades de ingenieria y las tareas que deben realizar se, la informaci6n que se recolecle y cree, y los metodos empleados para produeir un produclo de alta caUdad 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 lWeb se debe reconocer que:

I . Las WebApps con frecuencia se entregan de manera incremental Esto es, las actividades del marco de trabajo ocurriran de manera repetida con forme cada Incremento se someta a ingenieria y se entregue.

2 . Los cambios ocurrirdnfrecuente~nte Estos cambios pueden ocurrir como re o

sullado de la evaluaci6n de un incremento enuegado a como consecueneia de cambiar las condiciones de los negooos

510

PARTE TRES

APUCACION DE LA INGEmERiA WEB

3. Los plazos son cortos. Esto aminora Ja creaci6n y revisi6n de voluminosa documentaci6n de ingenieria, pero no excluye la simple realidad de que el anal..

sis entico, eJ diseno y la prueba deben registrarse en alguna forma.

Ademas, se deben apJicar los principlos definidos como parte del "Manifiesto para desarrollo de software agi!" (capitulo 4). Sin embargo, los principlos no son los diez. mandamientos. A veces es razonable adoptar eJ espiritu de dichos principios sin

que:

.~~VE
~
[I modelo de poxeso

sea necesario atenerse a Ja letra del manifiesto. Con estos conflictos en mente se aborda el proceso de lweb dentro del procesc generico de marco de trabajo presentado en el capitulo 2.
Comunicaci6n con el cliente. Dentro del proceso [Web la comunicaci6n can cliente se caracteriza por media de dos grandes tareas: el analisis del negocio Y formulaci6n. El ancilisis del negocio define el contexto empresaria!~organizativo pan. la WebApp. Ademas, se identifican los participantes, se predicen los potenciaks cambios en el ambiente 0 los requisitos del negocio, Y se define la integraci6n enb( la WebApp Y otras aplicaciones de negocios, bases de datos y funciones. La JOma.

generil:c Ontroducido
en eI (opitlAo 2) es

""'~" ingooieoo Web.

laci6n es una actividad de recopilaci6n de requisitos que involucra a todos los IW'I cipantes. El intento es describir el problema que la WebApp habra de resolver (j con los requisitos basicos para la WebApp) con el aprovechamiento de la mejor fonnaci6n disponible. Ademas, se intenta identificar areas de incertidumbre y c:It:. de ocurrirtm cambios potenciales.
Pianeaci6n. Se crea el plan del proyecto para el incremento de la WebApp. plan consiste de una definici6n de tareas y un calendario de plazos respecto al rioda (usualmente medido en semanas) proyectado para el desarrollo del incrernel to de la WebApp. Modelado. Las labores convendonales de analisis y disefia de ingenieria software se adaptan al desarrollo de la WebApp, se mezclan y luego se funden en actividad de modelado IWeb (capllulos 18 Y 19). El inlento es desarrollar analisis pidos" y modelos de disefio que definan requisitos y al mismo tiempo una WebApp que los satisfara. Construcci6n. Las herramientas y la tecnologia IWeb se aplican para c~~;::~ WebApp que se ha modelado. Una vez que se construye el incremento de se dirige una serie de pruebas rapidas para asegurar que se descubran los el disefio (es dedr: contenido, arquitectura, interfase, navegad6n). Pruebas adi nales abordan otras caracterfsticas webApp. Despliegue, La webApp se configura para su ambiente operativo, se entrep los usuarios finales y luego comienza un periodo de evaluaci6n. La ,etro,din,e,.., d6n acerca de la evaluaci6n se presenta al equipo de IWeb y el incremento se 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 [6.1

'"1"e,;e,,,,,

wo",.."

'II

INFORMACION

IngenJena Web: preguntas b6:s1cas

La ingenierio de cuolqu'" produdo illYOlucro HIli

~:::~no odvier1en inmedialomenle quienM

~

sustonciol. las IXlroc;terbticos de los WebApps a lot ingenieros wJ:J g responder uno diY'el'$ldad

corecen de

aQue opcionM de medios oudiovisuole1 tienen m6s imvideo 10 III audio) I" uno opciOn efectivo' tCv6ndo se deben elegir YOrlcU opciones de medios oudioviwolMi'
poctof tlos gr6ficos son m6s efectivos que ellexloa iEI

1marco de trobojo. Las pregunlas e,tmtegil'1IIocionodos con los necesidodes del negocio y los del prodvcto, s.e tra10n dUfonle 10 fonnuloc:i6n . fA9U"lcu oterco de los requiiik, reIocionoda, con (Dl'Oderl$ticos y runclones, deben COOWWoIlol durante an6Ii~s de modeIodo. los p!'e9Unkls ~ificos de disebne, relocionodos con Ia orquitecluro de 10 WebApp, coraderbricos de 10 interfaz y los conRidos de r'ICJY89O.. consideran conkwme muciono eI modeIo de di-'0, Finolmenle, un conjllllio de conRidos humanos, Wociollodos con Ia fo.mo eo 10 que vn uwario reolmenle .-rodVo con Ia WebApp, 58 obordon en forma continuo. Su5CW11Nei1'\$henk (WEK)2] ~ un conjunlo de pregunqIM M deben c:onsideror cadorme pi"y8$CIi'l II a"I6Iisis y eI ~ /lqio M anoia lIIl ~ wIxonjunIo (~I; iCu6n imporionle M Ie. pagino de inicio (home poge) de un sitio W~ tDebe conlenftr informoci6n Util 0 uno simple lislo de enIotes que conduuon 01 uwono a meyores detolle5 en niveles inlttrioresi' Cu6! In Ia plantil10 de p6gino mOs efectNa (pol'" ejempia, men\! arribo, 0 Ia derecho, (I Ia iutuierdo) y 6$lo V'CIfiar6 segVn eI tipo de WebApp que sa de50rroIlor6

tCu6nlo trobojo 58 puede e~r que reolice un usucrio euondo buKO informoci6n' aCuantos dies de~ ha
ter

10 genie'

tCv6n imporlOnlM

k)I'1 los ouxiliores de ne;rvoegoci6n cuonOO los WebApps :I0I'l complejos~

,Cu6n compIejos pueden $CII" los entrodos de formulorio onlM de que M weIvon irritanles para eI uworiof iC6mo M pueden expedir las entrodos de formulariof
tCu6n importontes son las copoddades de bUsquedoi ,Que pon;enlOje de uworios navego Yque porcentaie U50 bUsquedas especlficos~ eCuan importante es estrucIvror coda p6gino en uno forma que supongo un enloee desde oIguno Nente extemoi

,La WebApp MI diseii0r6 en uno forma que MICI oronibIe 0 quienft IengOn discapocidodes liskos 0 de olgUn
-,;pol

No exisa.n ~ obsoIutos 0 pregunlOs como ~s, e induso<Nmguno> cI.b.I ~rse conforme oyooce Ia !Web. En mcapiIuIos 1701 20 se consideror6n r.$fIUMtas

...........

512

PARTE TRES

APUCAct6N DE LA lNGENlER!A WEB

16.3.2 Refinamiento del marco de trabajo

Va se ha advertido que eJ modelo del proceso IWeb debe ser adaptable. E5tO es, la definici6n de las tareas de ingenierla requeridas para reflnar cada actividad del marco de trabajo se dejan a discrecionaJ juicio del equipo de ingenierla Web. En algunos casos, una actividad del marco de trabajo se dirige de manera informal; en atras, se

definira una serle de distintas tareas y las dirigiran miembros del equipo. En todo caso, el equipo es responsable de producir un incremento webApp de alta calidad den-

tro del periodo acordado. Es importante destacar que las tareas asociadas con las actividades del marco de
trabajo IWeb pueden modificarse, eliminarse 0 extenderse con base en las caracteris-

ticas del problema, e\ producto, el proyecto y la gente en el equipo de ingenierfa Web

........... lICIiOtros que creen que los mejores prOdkas poro II desImIIo de ............, - . ,. .. ' I Ish Yluego existlll'l algunos de nosotros que [rl!lll1 que las mejDre5 pr6dima. II ..........., II18S 110 10 SOlI poru eI mundo real, muchosllrm.

11_ ....

iTodo desarrollador de webApp utilizara el marco de trabajo y el conjunto de tareas del proceso [Web definido en la secci6n 16.3? Probablemente no. En ocasiones. 105 equipos de ingenieria Web estan sometidos a enonne presi6n respecto del tiempo trataran de tamar atajos (incJuso si estos son imprudentes e implican mas esfuel'2l:!' de desarrollo, en lugar de menos). Pero se debe aplicar un conjunto fundamentaJ cr mejores practicas -adoptado de las practicas de ingenieria del software tratadas 10 largo de la Parte 2 de este libro--- si se han de construir WebApps can calidad industrial.
I. Tomar tiempo para entender las necesidades del negocio y los objefivos del producto, induso si los detalles de 10 webApp son vagos. Muchos desarrolladores

6SlidllljlJll
tm

........ ....m,
cmJOO kIs f1fJ(~
pnlftl W~. 5i
.,esosi..~

_doI_

de WebApps creen err6neamente que los requisitos vagos (que son bastante comunes) los liberan de la necesidad de asegurarse de que el sistema que estan a punta de sameter a ingenierfa tenga un prop6sito empresariallegltimo_ EI resuitado final es (tambien can frecuencia) un buen trabaja tecnico que c duce a la construcci6n del sistema equivocado por las razones equivocadas para el publico equivocado. Si los accionistas no pueden enunciar una necesr dad empresarial para la WebApp. debe procederse can extrema precauci6n. 9 los accionistas luchan por identificar un conjunto de objetivos darns para el producto (WebApp). no debe procederse mientras elias no conduyan.
2. Describir c6mo interactuQnin los usuarios can la WebApp aplicando un enJoquebasado en escenarios. Se debe convencer a los accionistas para desarrollar ca-

.""".sthn

sas de usa (tratados a 10 largo de la Parte 2 de este libra) para reflejar c6mo los diversos actores interactuaran con la webApp. Entonces se pueden apro-

CAPiTuLo 16

INGENIERlA. WEB

513

vechar dichos escenarios I ) para la planeaci6n y el raslreo del proyecto, 2) para guiar e\ analisis y el modelado del diseno, y 3) como una entrada importante para el diseno de pruebas.
3. Desarrollar un plan del p~to, incJuso si es mtO' breve. EI 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 dosificaci6n del programa debe ser exacta; es decir, en muchas instancias el proyecto debe planearse y raslrearse diariamenle.
4, Utilizaralgun tiempo para modelar 10 que se construira. Por [0 general, el analisis total y los modelos de disefio no se desarrollan durante la ingenierla Web.

Sin embargo, la cJase UML y los diagramas de secuencia, junto con otra notaci6n UML seleccionada (par ejemplo, diagramas de estado), pueden proporcionar una visi6n invaluable.
5. Revisar la consistenda y caUdad de los mode/os. Las revisiones teenicas forma -

les (capitulo 26) se deben dirigir a 10 [argo del proyecto IWeb. El tiempo empleado en las revisiones paga importantes dividendos porque usualmente elimina reeiaboraciones y resulta en una webApp que exhibe alta caUdad, 10 que aumenta la satisfacci6n del cliente.
6, Utilizar herramientas y tecnologia que pennilan construir eJ sistema con tantos componenres reurilizabJes como sea posible. Un amplio conjunto de herramien-

las WebApp estan a disposici6n virtualmente para cada aspecto de la construcci6n WebApp. Muchas de dichas herramientas permiten que un ingeniero Web construya porciones signifieativas de ia aplicaci6n empleando componentes reutilizables.
7 . No apoyarse en usuarios anteriores para depurar fa WebApp; distiiense prueoos amplias y ejecutense antes de liberar eJsistema. Los usuarios de una WebApp

can freeuencia Ie dan una oportunidad. Si falla en su ejeeuci6n se mueven a cualquiera otra parte: nunea regresan. Por esta raz6n, el "pruebe primero, despues despliegue" debe ser un sistema primordial, incluso si los plazos se deben prolongar.

Critenos de ca1idad/ dJrectrtces para WebApps

Lo lWeb se e5fverzc en 10 producci6n de -.bApps de 0[10 oolidod. Pero, en esle cootexlo, aque es
y que directrice5 e$t6n di$pOllible5 poro Iogrorlo' orticvlo ocen;o de oseguromienlo de 10 oolidod en $i"'W.b, Ouibeldey-Cirkel [QUKlI] wgiere un omplio - 10 de recursos en linea que obordon e5\o$ conRiclos:
til

W3C: guto cIe esJib poro hipertexlo en linea www.w3.org/Provider/Sty\e lo Gvio ~ poro eI di~ Web www_ _ .(Otn.(I4)/ Wf!ibzone/dMign/guide.o$p P6ginas w.b ~ ApeskJn
www.~ .c:om/index.hlml

514

PARTE TRES

APllCACl6N DE LA INGEN!ERiA WEB

Recursos ocerco de esti/o web www.westegg.com/unmainlained/bodpoges Herramiento de eva/ooci6tl web de Gartner www.gartner.com/ebusiness/websile-ings IBM Corp: directrices Web www-3.ibm.com/ibm/eosy/eou_ext.nsf/Pubiish/572 Focilidad de UK' en Ia world Wide Web ijhcs.open.ac.!.Ik Inlerfoz Sal6tl de /0 Vergiienzo www.iarchitect.com/mshame.htm 1 arle y el zen de /0$ $ili05 web www.tk-systems.com/webtips.shtml Diseiia para Ia web: estudios empfricos www.microsoft.com/!.lsobilily/webconf.htm !.Iseit.com de Nielsen www.useil.com

calidad de experiencia
www.qualityofexperience.org Creoci6tl de $ili05 web o5esinoJ www.killer1ites.com/core.html Todas las cosos en Ia web www.ponlos.org/atw

Nl.Ie'IO diseiSa Web de SUN

www.wn.com/9801\3/sunonnet Tognauini, Bl1JCe: homepoge www.asktog.com

Webmonkey
hotwired.lycos.coml webmonkeyI desi9n/~tw-desi9n Las meiore5 5ilio$ web del mundo www.worIdbestwebsiles.com Yale University: guia de Mlila web de Yale info.med. yole.edul coiml manual

Es posible argumentar que el impacto de los sistemas y aplicaciones basados en W es el suceso mas significativo en la historia de la computaci6n. Conforme la importancia de las WebApps crece ha comenzado a evolucionar un enfoque IWeb discip& nado (adaptado de los principios, conceptos, procesos y metodos de la ingenierla lid software) . Las webApps son diferentes de otras categorlas de software informatico; son ena nentemente de red, las gobiernan los datos y se encuentran en evoluci6n continUl. La inmediatez que dirige su desarrollo, la necesidad apremiante de seguridad en operaci6n y la demanda de estetica, asl como la entrega de contenido funcional, ~ factores diferenciales adicionales. AI igual que otros tipos de software, las webApp5 pueden valorarse mediante una diversidad de criterios de calidad que incluyen faG lidad de uso, funcionalidad, confiabilidad, eficiencia, capacidad de mantenimienw seguridad, disponibilidad, escalabilidad y tiempo para comercializaci6n. La JWeb se describe en tres estratos: proceso, metodos y herramientas/tecnoiogia. El proceso JWeb adopta el enfoque de desarrollo agil que subraya un punto df: vista de ingenieria "magro", riguroso, que conduce a la entrega incremental del . tema que sera construido. EI proceso generico del marco de trabajo -comunicaci6n planeaci6n, modelado, construcci6n y despliegue- es aplicable a la [Web. Dic actividades del marco de trabajo se retinan en un conjunto de tareas IWeb que adaptan a las necesidades de cada proyecto. A tOOos los proyectos IWeb se les aplica un conjunto de actividades sombrilla similar al aplicado durante el trabajo de ingenierla del software: SQA, SCM, gesti6n del proyecto.

c APfTuto 16

INGENIRIA. WEB

515

[AOY98J Aoyama, M., ~Web-Based Agile Software Development", en IEEE Computer, noviembrediciembre, 1998, pp 56-65 [DAR99] Dart,S., Contalnlng the Web Crisis using Configuration Management", en Proc. flrsf ICSE workshop on Web Engineering, ACM , Los Angeles, mayo de 1999, (The Proceedings olllle FirsJ.ICSE WOrkshop on Web Engineenng se publican en linea en http,llfistservmacarthur uws.e<lu.au/sanlicse99-WebEIICSE99-WebE-Proc/default.htm) [FOWOI] Fowler, M. y J Highsmith, "The Agile Manifesto", en Software Development Magazme. agosto de 2001, http.llwww.sdmagazine.com/documentsls.. 844/sdmOt08a/OI03a.htm [MeDO IJ McDonald, A. y R. Weiland, Agile Web Engineering (AWE) Process, Department of Com puler SCience, University of Glasgow, Technical Report TR-2oo1-98, 2()() I , se puerle descargar desde http://wwwdcs.gla.ac.ukl-andreW/TR-2oo1-98.pdf [MUR99] Murugesan, 5., webE Home Page, http://flStserv.macarthur.uws,e<lu,au/santwebEHome, juho de 1999 [NOR99] Norton, K" ~Applying Cross Functional Evolutionary Methodologies to Web Development", en Proc. First ICSE Workshop on Web Engineenng, ACM, Los Angeles, mayo de 1999 [POW981 Powell, T. A., WdJ Site Engineering, Prentlce-Hall, 1998. [PRE98) Pressman, R 5 (moderadorl. "can Internet-Based Applications Be Engineered?", IEEE Software, septiembre de 1998, pp. 104-110. [QUI01] Quibeldey-cirkel, K., "Checklist for Web Slle Quality Assurance", en Quall~ week Euro pe, 2001, se puede descargar desde wwwlbilh -darmstadtde/- quibeldey/Projekte/QWE2()() I/Paper_Quibeldey_Cirkel.pdf. 1WEI021 Weinschenk, 5, Psychology and the Web Designing for People", 2002, http://wwwweinschenk.com/leam/facts.asp.

16. 1 ,Exlsten otros atributos genericos que diferenden a las WebApps de las aplicaciones de software mas convendonales? Intentese mencionar dos 0 tres. 16.2 ,C6mo juzga elle<:tor la "caUdad" de un silio Web? Hagase una IiSla, en orden descendente de priori dad, de 10 atrlbutos de caJidad que conslderen los mas Importantes. 16.3 Realizar un poco de investigaci6n y escribir un artfculo de dos a tres paginas que resuma una de las tecnologfas anotadas en la secci6n 16.2.3 16 . Empleando un sitlo Web real como ejemplo, ilustrar las diferentes manifestaciones del contenido" de la WebApp 16.5 Revisar los procesos de ingenierla del software descritos en los capltulos 3 y 4. ,Existc(n) algun{os) otre(s) proceso(s) -<listinlo(s) al modelo de proceso agil- que pueda(n) seT apHcable(s) a la ingenleria Web? 51 la respuesta es afinnativa. lndicar cual(es) proceso(s) y por que 16.6 Revisar la exposici6n del "Manifiesto para desal'TOllo de software agil" presentado en el capitulo 4. ,Cual de los 12 principios funcionaria bien para un proyecto de dos ai'ios (que involucra a docenas de personas) que constnura un gran SIstema de comercio electr6nico para una companla aulomotriz? ,Cual de los 12 principiOs funcionaria bien para un proyecto de dos meses que construira un sitio informativo para una pequel'ia ruma de bienes ralces? 16.7 Elaborar una lista de "rlesgos" que sertan probables durante el desarrollo de una nueva aplicaci6n de comercio electr6nico que se dlSCM para vender telefonos celulares y servicios directa mente por medio de la Web.

516

PARTE TRES

APUCNXlN DE LA INGENlERlA WEB

En aflos recientes se han publicado dentos de lihros que analizan uno 0 mas lemas de in8en~ ria Web, aunque reJativamente pocos abordan 1 0005 los aspectos de la [Web. Sarukkai (Fou"", (ions oj Web Technology. Kluwar Academic Publishers, 2002) presenta una valiosa compilacK. de tecnologias que se requieren para la [Web. Murugusan y Deshpande (Web Engin~ring' Mil

naging Diversity and COmplexjty ofweb Daldopment. Springer-verlag, 2001) han edltado una m..
lecci6n de (ltiles ar\!culos a(erca de lWeb. Las aelas de oonferencias intemacionales acerca de ingenieria Web y de ingenieria de sistemas de Inrormacl6n Web las publica anualmente eJ lEa Computer SOCiety Press.

Flor (web Business Enginring. Addison-wesley, 2000) analiza el anaJisis de negoclos y

preocupaciones relacionadas que permiten al ingeniero Web comprender mejor Jas necesidacb de los dientes. Bean (Engineenng Global E~rce SItes, Morgan Kaufman, 2(03) presenta cIreetrices para el desarrollo de webApps gJobales. Lowe y Hall (H)'pem1edia and /he Web; An It gineering Approoch, Wiley, 1999) Y Powell [POW981 ofrec~n una cobertura razonablement~ COlDpleta. Umar (,Application Reo-engineering: BUilding Web-Based A[)plicatiollS and Dealing with t...egat:r ~fems, Pr~ntic~ Hall . 1997) aborda uno de los mas diflciles conflictos en la [W~b : la relngeNr' ria de los sistemas heredados para hacerlos compatibles con los sistemas basados en Web. lEa Std. 2001 - 1999 define praclicas basicas de [Web. Erl [ntemet hay disponlble una gran variedad de fuentes de informaciOn aeerca de ingera. rfa Web. En el sitio Web de SEPA se puede encontrar una !isla actua!izada de referendas en World Wide Web que son relevantes para la ingenieria Web: htlp:II_ .mhhe.comJpressman.

CAPITULO

FORMULACION Y PLANEACION PARA INGENIERiA WEB

17

.52l

.i3O

.520

....536
..539

.. .530

.. J19

urante la tempestuosa decada de 1990, el boom de la Internet gener6 mas arrogancia que cualquier otro evento en la historia de las computadoras, Los desarrolladores de WebApps en dentos de j6venes compafilas puntocom argumentaban que habla surgido un nuevo paradigma para el desalTollo de software, que las viejas reglas ya no se aplicarian mas. que elliempo para el mercado dominaba todas las demas preocupaciones. Se neron de la noci6n de que la fonnulaci6n y la planeaci6n cuidadosas debfan ocurrir antes de que comenzara la construccion. ;'Y quien podia rebatirlos? EJ dinero estaba en todas partes, los j6venes de 24 ai'los se volvieron multimillonarios (al menos en el papel); tal vel las cosas realmente hablan cambiado. Y entonces el 5uelo se vino abajo, Conforme comenzaba el siglo XXI empez6 a ser dolorosamente evidenle que un enfoque de "construye!o y ellos vendrnn" simplemente no funcionaba. que \a formulaci6n del problema es esenciaJ para garantizar que una webApp en ver dad es necesaria, y que la planeaci6n vale el esfuerzo, aun cuando el calendario de desarrollo sea apretado. COnstantine y Lockwood (CON02) advierten esta siluaci6n cuando escriben:
A pesar de las dedaraciones radicales de que la Web representa un nuevo paradigma

--'"
..... J24

poT reglas nuevas, los desarroHadores profeslonales se estan dando cuenta de que las lecciones acerca del desarrollo de software, aprendidas en los d!as prevlos
definido allntemet, todavla

se aplican. Las paginas Web son interfaces de usuariO, Ia progra

maci6n HTML es programad6n, y las aplicaciones desplegadas en el navesador son sistemas de software que pueden beneflciarse de los principios basic05 de la ingenle-

ria del software

Entre los principios fundamentales de la ingenieria de software destaca el de comprender el problema anles ck comenzor a resolverio, y eslDI seguro ck que la solucl6n concebJda es aqudJa q~ la gen~ realmente quiere. Esla es 1a base de la formulaci6n, la primera gran actividad en la ingenieria Web. Otro principio fundamental de la Ingenierta de software es: planear el trabajo antes de comenzar a real/zario, Este es el enfoque que subyace a la planeaci6n de proyectos.

j,Qu6 .... COI _

cit PO< uno pcwto. _

eta a eIi_r,

.......... ... .....

....w.:.d .. conozco que se

~

nece!ito

hexer

0 ..... " -

toda I .... cnmocIa porno ..... do quo _ ..... ba,O PO<" _ pcwto. hoy un doooo . . . . de comenzar a COMtruir inckno

y'" .... anIIl_"

son inopropi~ y po!" ello las cia. pr O$ octMdodes del marco de trobajo ... . . . . ...-.0 Web deskxan Ia formulaci6n y ..... O. La iormuIociOn voIoro Ia necesi .,....... de 10 WebApp, las corodefisti gIoboJes que deseon los usuoriO$

r.n"",_

518

PARTE TRES

APUCAC!6N DE LA!NGENID1lA WEB

ma.y._01 .......
prayecto.

~i6n~ ~ aboo~""~"~;~=
paRI ...

bIMw un

,GuiinIo_'Las

,- .......
Iugao- que
"" mapa.

nistludunn y los nkos; todos ~.

on

_con

1a'9" on

pto.-i6n

'C...... _
ci6n

equip<> do

"",...mdoo"",ala negocio. qui

........

17_1

Ep'MVLAC,OM
La fonnulad6n

pi

IIITIMY

IAIApOl

IB W'I

de sistemas y aplicaciones basados en Web representa una secuencia de acciones de ingenieria Web que comienza con la identificaci6n de las necesidades del negocio, se mueve hacia una descripci6n de los objetivos de la WebApp define grandes caracteristicas y funciones y realiza la recopilaci6n de requisitos q~ conducen a! desarrollo de un modelo de anal isis. La fonnulaci6n permite que los clientes y e[ equipo de ingenieria web establezcan un conjunto comun de metas y objetivos para la construcci6n de la webApp. Tamblen identifica e\ ambito del esfuerzo de desarrollo y proporciona un media para determinar un resuitado exitoso. El analisis - una actividad tecnica que es una continuaci6n de la formulaci6nidentifica los requisitos funcionales, de comportamiento y de datos para la WebApp Antes de considerar la formulaci6n con mas detalle, es razonable preguntar d6nde termina la formulaci6n y d6nde comienza el analisis de requisitos. No existe una respuesta sencilla para esta pregunta. La formulaci6n se enfoca sobre el "gran cuadra": en las necesidades y objetivos del negocio y en la informaci6n relacionada. Sin embargo, virtualmente es imposible mantener este grado de abstracci6n. Los c1ientes y los ingenieras Web quieren definir el contenido requerido, discutir la fun -

11 _ _

Im-'

~'

. -' ........f ,

C&VE

..........

y~-

...
cionalidad especfflca, enumerar caracterfsticas especlficas

e identilicar la forma en

que los usuarios finales interactuaran con la WebApp. ,Esta es fonnulaci6n 0 recopilad6n de requlsilOS? Ambos es la respuesta .

17.1.1 Preguntas de formulacion

Powell [POW98] sugiere un conjunto de preguntas que deben fonnularse y responderse al comienzo de la elapa de fonnulaci6n;
,Cual es la principal molivaci6n (necesirlades del negocio) para \a WebApp?

,Cuates son los objetivas que debe satisfacer la WebApp?

i..Quien usarA la WebApp?

La respuesta a cada una de estas simples preguntas debe establecerse tan sucinta-

mente como sea posible. Por ejemplo, sup6ngase que el fabricante de HogarSf:guro l ha decidido establecer un sitio web de comercio electr6nico para vender sus productos direclamente a los consumidores. Un enunciado que describa la motivaci6n para la webApp puede ser:
HogarSegurolnccom permilira a los consumidores configurar y comprar lados los com ponenles requerldos para instalar un sislema de adminiSIraci6n en su hagar 0 empresa

Es importante advertir que en este enunciado no se proporcionan detalles. El objetivo aqui es acotar la intenci6n global de la WebApp y colocarla en un contexte empresariallegltirno. oespues de platicar con varios clientes se establece una respuesta a la segunda pregunta:
HogarSegurolnc.com nos pennitira vender directamente a los consumidores, 10 que eli minara los costos de inlermediaci6n y mejorara los mflrgenes de ulilidad. Tambien nos permitira aumentar las ventas en un proyectado 25 por clento sobre las ventas anuales actuales y penelrar en regiones geograficas donde en la aCluaJidad no lenemos puntos de venia.

Finalmente, la companla define la demogralla para la WebApp: HLos usuarios proyectados de HogarSegurolnc.com son los propietarios de viviendas y los duefios de pequenos negocios." Las respuestas establecidas Ilneas arriba implican melas especificas para el siUo Web de HogarSegurolnc.com. En general. se identifican dos categonas de metas IGNA991:

Metas inJormacivas: indican una intenci6n de proporcionar conlenido informaci6n especificos al usuario final Metns aplicables: indican la habilidad para realizar alguna tarea dentro de la webApp.
1 EI producto HogarSeguro ya se us6 como qempk). kI

tarvo de las partes 1 y 2 de este libra

.20

PARTE TRES

DE LA INGENlERlA. WEB

En el contexto de la webApp HogarSegurolnc.com. una meta informativa puede ser El sitia proporcionan\ a los usuarios especincackmes de produclo detalladas, que inclulran descripciones tecnicas, instrucciones de instalacl6n e infonnaci6n de predos. El examen de las respuestas a las preguntas planteadas puede conducir al establed-

miento de una meta aplicable:

HogarSegurolnc.com consultara al usuario acerca de la instalaci6n les decir: casa, oficina, espacio de venIa aJ menudeo) que sera prolegida y realizara recomendaciones personalizadas acerca del producto y Ia configuraci6n que.se utilizan1.

Una vez identificadas todas las metas informativas y aplicables, se desarrolla un per-

fil de usuario. E1 perfil de usuario captura "caracteristicas relevantes relaclonadas

con los usuaries potenciaies, que incluye sus antecedentes, escolaridad, preferencias e incluso mas" IGNA99I. En el caso de HogarSeguTolnc.com, un perfil de usuarto identificaria las caracterlsticas de un comprador tlpico de sistemas de seguridad (esta informaci6n la suministrarla el departamento de mercadotecnia).

Una vez que se han desarrollado las melas y perfiles de usuario. la actividad de formulaci6n se enfoca sobre una afirmaci6n del ambito para la webApp. En muchos casos, las metas ya desarrolladas se integran en la afirmaci6n del ambito. Ademas. es uti], no obstante, indicar el grado de integraci6n esperado de la webApp. Esto es. con frecuencia es necesario integrar los sistemas de informaci6n existenles (par ejemplo, una aplicaci6n existenle de base de datos) con un planteamiento basado en Web. Los lemas de conectividad se consideran en esta etapa.

17.1.2 RocopUac16n de requ1s1tos para WebApps

Los metodos para 1a recopiJad6n de requisitos se trataron en el capitulo 7. Aunque esta actividad puede abreviarse para la ingenierla Web, los objetivos globaJes de Ia recopilaci6n de requisitos propuestos para la ingenieria de software permanecen inaUerados. Adaplados para las WebApp, dichos objetivos se convierten en; Identificar requisitos de contenido. Identificar requisitos funcionales.

. ,...,... ... ..... .........

LCW,...

Defin!r escenarios de interacci6n para diferentes ciases de usuaries. Los siguientes pasos de la recopilaci6n de requisites se dirigen para lograr eslos objetiv05: 1. Pedir a los cJientes que definan las categorlas de usuario y describan cada ca tegoria . 2 . Comunicarse can los ciientes para delinir los requisitos basicos de la WebApp.

.. ~?

CAPiTuLo 17 I'ORM\Jl.ACt6N y ~ PARA INGENlERlA WEB

521

3. Analizar la informaci6n reeopilada y utillzar la informad6n para realizar un seguimiento con los clientes. 4. Definlr casos de uso (capitulo 8) que describan escenarios de interaed6n para eada clase de usuario. Definici6n de l as catego rias de usuarlo. Se puede argumentar que la complejidad de la WebApp es direetamente propordonaJ al numero de categorlas de usuario para el sistema. La definiei6n de una categorla de usuario requiere formular un eonjunto de preguntas fundamentales:
~Q.NjJ es d

ob)Ctivo global del usuario cuando usa fa WCMpp?' Pm ejemplo, un usuario del slUo de comerdo electr6nleo de HogarSegUrolnC.com puede estar interesado en recopilar informad6n aeerca de productos de administrad6n del hagar. Otro usuario tal vez desee eomparar preclos. Un tercer usuario qui ere comprar el producto HogarSeguro. cada uno representa una clase 0 calegoria diferente de usuario; cada uno tendra diferentes necesidades y navegara a traves

de la webApp de manera diferente. Un cuarto usuario ya posee HogarSeguro y

busca soporte ttenieo 0 quiere comprar sensores 0 aecesorios adicionales.

~cuales

son /os antecedentes y 10 pericia del usuario en reladon con el contcnido

y la Juncionalidad de la WebApp? 51 un usuario tlene un antecedente ttenico y

una pericia significativa el contenido 0 la funcionalidad elementales ofreceran poco beneficio. De manera altemativa, un ne6fito demanda contenldo y funcionalidad elementales y estaria confundido si se perdiese.

~C6mo

lIegard e/ usuario a la webApp? tEl arriba ocurrira a traves de un enlace desde otro sltio Web (probablemente hacia contenido 0 funcionalidad dentro de la WebApp). 0 lIegara en una forma mas controlada?

~Que

caracrerislicas genericas de 10 WebApps Ie guston 0 disgUSlan al usuario?' Diferentes tipos de usuarios pueden tener distintos y predecibles gustos y aversiones. Vale la pena el intento de determinar si los tienen 0 no. En muchas situaciones la respuesta se puede averiguar preguntandoles cuales son sus WebApps favorita y menes favorita.

Al aprovechar las respuestas a estas preguntas se debe definir el mas peque~o conjunto razonable de c1ases de usuario. Conforme se avanza en la recopilacl6n de requisites. cada diferente clase de usuario debe encuestarse para obtener datos.

l\1li""" ., Nt""".".-..,.,.
&"d . .

522

PARTE TRES

AI'I.JCACION [)[ LA INGEN1ll!lA WEB

...... i

"um_.fI,.
.podudo

.... _

8' Iieria cWlOItwor. Hogar5egfJro; mOs ......... ~io_

DeuflIa..,..so ha decidido que cons/nlyomos un C8mIfOo MKtronito pcwo.......der HogarSegvro. _ iG-. Doug' No _ _ """" pam " ' - . ........ ~ .. ....dos con eI troboro cIe :IOftwore . . . . lo ... 10 .... ~ eI desorrollocon UI'CI CICIiA.,-o lIIpKiaIizodo en 10 consllVeci6n de ~tios ., c:xn.do-.a6..i..... EJIOlI'lOS dir6n que 10 tendrim IitIo y COfritndo en tnWIO$ de un mes .. ~

Vlnod (om-........ '3~ oQ....._,

......ona ...... cI.a.. tal ....!OJ

guiar 01 uworio CI

tra*dII-proc.mct.

ponona!lm06n" ~ ownto del c::omercio Mdronico

"""':

Peuona" n.u ........... "

ohcer un nu.r.o 800 para dispve$lol a ...aIizor

COIIIfIOI." ,.....;Ii1lClbl.t.

va... Mo, BMn .. ~ par que estoy oqult

fonno minima, los

hf'MftCI de

mere",,,,,, ftI e.,.

cxtMdod.

:::
3 ..

Vinos: Nwy bien,

haYcw_1f

..... Par. lDciIiear let COIOi: qvieren que !'\Os - - . - - . 1 0 ..oop1exiOn de requislios para el IiIiIL 0..0 que .......IIIS con los diYerJo, dientes
panlCIOI'........ ~ leO WI
,.....~

cOmo Ies guiltorio del produdo como \Ifl(I p"" 11 . . , . . . ~ IS$O par un 1TIO!MriIo. Tengo __ ~ ptegunflll fvodomentoI.,.

."

".... .......... J=Doug .. nome~$ d~ . ......,.apeb:loo.derietrp>yew...

Vmod (_ a Ia Oiiisl& que queriol ;Vier 0

1*'-_. __.....
Ie. .,..,.;0. 0

pnx_. jAlgun ~Ioquo ...,.aaIf

. . . . . . . . . 11 )1:

I"~ II com.niOo b6sico, Ie funci6n; 1O ........ ~ltousual. ...... ..,r"o)l: Ed6 bierI. Los llomore y para rnaftono, J*O no me Iocililo, 10

....... .

YiMwI. .... f ,

SOlo dole un dio de litmpo. _0Jn IoIIipos de ,,*cocbecnio y

tu

' .. sona ....... EcnIo ~QuWaIo" pro<:elO po~ a pate, con ~ .............

_ "'alp

.... _~ ""_" ...... 10. ~I"'" ""'"""

....

re$flOOder preguntos 0. requisitol b6Iicot. . . . _ tipo 0. tOlOS. Coda Ilona, Y 105 dabs delXlC6a vwano';' ...............
desplego~,

paIO_"

movene 01 po~ ii~ _

. . . . . Me d.dan ocerca de 10,. objeti'l'01 y

tl . . . . . . . Ios usuarios.

"'. . ..-.1
7

-""'"

Vinod: ,Has CXInIpt'Obado . , con ___ reprfteflkJtivos2

hf'lOftCI de "*"cp'

IVMod 1Ii . . . con Ires penonas de mel"codotecnio

lea_ HI No, , . . ...... ytnod: Uno toSO mOs. ac6mo .cu...., ....... ..
un uworiaf

Persone

de e.... lroboionOo en uno tOmp:lI\o pvCIicilario . . . . . .

merE "..... '1,

'. . . . . . . _cad.taenla '1: Comodije, p wuonoteacapozdepenonalizar

. . . . . . . .

correa dirigido a

. . . . . . . . . ~. TU~.

flCog

- . . , . . . . . . eot*oI, carocleristils Yfuociorles, ~cwnIa de rnotwioles w generodo . . . 10 cotizoci6rt y Iuego cornpmf

www.Hogors.gurolnc.comenonunciotds ......... objetios, onvndot . . . . . . . tonlenido que opor",*, en 50s fI\OIDN& ds W....... y lral vu indlnOaigUl'lOl spoh de 6ft

radio,.;..

VInOd: La que quoem decir . .. Ie. uauariot ........

eMon

a ~ de 10 p6gin0 .....

.... 1OftCI

de

.21

~ .. ,iiOl que

eI

guwria

merc".'._ .......1Ifj

coso, no un *"ico, ti tnMs del proceso palO a

VInod, """ ~.

troboiOl".

penonoliUlr los si-..os en Ifnto.

CAPiTULO 11 I'ORMtIl.ACI6N y Pl.ANEACXJN PARA JNGDm:R!A WEB

523

comunicad6n can los clientes y usuarios fmales. La mayorfa de las WebApps

tiene una amplia poblaci6n de usuarios finales. Aunque la creaci6n de categorias 0 clases de usuario hace que una evaluaci6n de [as requisitos de usuario sea mas manejab[e, no es recomendable emplear informaci6n recopilada s610 de una 0 dos personas como!a base para !a formu!aci6n 0 e! amilisis. Se deben considerar mas personas (y mas opiniones y puntos de vista) . La comunicaci6n se puede !ograr aprovechando uno 0 mas de los mecanismos siguientes [FUC02a]: Grupo muestral tradicional. Un moderador entrenado se reune con un pequeno (usualmente menos de 10 personas) grupo representativo de usuarios finales (0 participantes internos que los representan). EI prop6sito es discutir la WebApp que se desarrollara y, fuera de la discusi6n, comprender mejor los requisitos del sistema. Grupo muestral electr6nico. Un debate electr6nico mcxlerado dirigido con un grupo de usuarios finales y participantes representativos. El numero de participantes puede ser mayor. Puesto que todos los usuarios pueden participar al mismo tiempo, es posible recopilar mas informaci6n en un periodo mas corto. Dado que todo el debate se basa en texto es automatico un registro contemporaneo.
Entrevistas iterativas. Una serie de entrevistas breves, dirigida a usuarios repre -

sentativos y en la que se solicitan respuestas a preguntas especificas acerca de la WebApp, se dirige a traves del sitio Web a mediante correa electr6nico. Las respuestas se analizan y aprovechan para afinar la enlrevista siguiente.
En1revistas de explorad6n. Encuesta basada en Web

y ligada a una 0 mas

webApps can usuarios similares a los que usaran la WebApp que se desarronara. Los usuarios se enlazan a la entrevista y responden una serie de preguntas (usualmente reciben alguna recompensa por participar).

Construcci6n de escenarios. A usuarios seleccionados se les pide crear casas de usa informales que describan interacciones especificas con la WebApp.
Anfillsis

de la infonnaci6n recopUada. Conforme se recopHa infonnaci6n se categoriza en cJase de usuario y tipo de transacci6n, y luego se valera segun su relevancia. EI objetivo es desarrollar listas de objetos de contenido, operaciones que se aplican a los objetos de contenido dentm de una transacci6n de usuario especifica, funciones (por ejemplo, infonnativa , computacional, 16gica 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 comunicaci6n. Fuccella y Pizzo[ato [FUC02b] sugieren un metodo simple (de baja tecnologia:

low- tech) para comprender c6mo se deben organizar el contenido y la funcionalidad.

Se crea un paquete de "cartas" para los objel OS de contenido, las operaciones aplicadas a los objetos de contenido, la funciones WebA.pp y olms requisitos no funcio-

524

PARTE TRES

APllCA06N DE I.A INGENIERiA WEB

nales. Se barajan las cartas y luego se distribuyen a las personas representativas de cada categorla de usuario. Se pide a los usuarios que ordenan las cartas en grupos que reflejan c6mo les gustarla que se organizara eJ contenido y la fundonalidad denlro de la webApp. Luego se soiicita a los usuarios que describan cada agrupamiento y las razones por las que son importantes para ellos. Una vez que cada usuario
realiza este ejercicio, eJ equipo de ingenierla Web busca agrupamientos camunes entre diferentes clases de usuarios y olros agrupamientos que sean unicos para UIWI clase de usuario especifica. El equipo IWeb desarro!la una lista de etiquetas que se usaran para apuntar ~ informaci6n dentro de cada uno de los agrupamientos derivados con el usa de los paque. tes de cartas. Entonces, a los diferentes usuarios representativos se les dan klI paquetes de cartas y se les pide ubicar el contenido y la fundonalidad a cada una de las etiquetas. Aqu! el pr6posito es detenninar cuando las etiquetas (enlaces dentn" de la WebApp real) implican de manera adecuada el accesa al contenido y las fundones que los usuarios esperan encontrar detras de la etiqueta. Este pasa se aplo de manera iterativa hasta que se alcanza el consensa.

fn kJ Prxte 2 dB fI5IrJ ixa SI! IratmJn (00 dstrJle .bs cosos de

,,010 de cosos de tISIl "" bgos, iI<lM

_...

oo.,oo,.,odw

t/SIl.)mpJ mOOios

lIIC/ IIOUo66tt iIkxmd

benefido. (onvenzo 0 hs IlStO'ios potG I1Je esaIxxt casos de 1M.

Desarrollo de casas de uso. Los casas de usol describen c6mo interactuara COl' la webApp una categoria de usuario especlfica (llamada acton para lograr acd6n especlfica. La acd6n puede ser tan simple como adquirir contenido definida o tan compleja como que el usuario realice un analisis detallado de registros selec donados que se mantienen en una base de datos en linea. Los casas de usa descn ben la interacci6n desde el punta de vista del usuario. Aunque desarrollarlos y analizarlos toma tiempo, los casas de uso \) ayudan desarrollador a entender c6mo perdben los usuarios su interacci6n con la WebApp 2) propordonan el detalle necesario para crear un modelo de analisis efectivo; ayudan a dividir en compartimientos el trabajo de Web; y 4) ofrecen una gufa imtxtante para quienes deben probar la WebApp.

La comWlicac1an con eJ cJlente (An6:l1sJsjFormuJac16n)

1. klentiffquense 0 /as dienles del negocio. tExadomenle quien es el -dien\e" de Ia WebApp~ iQue personos de negocios pueden funcionor como expertos y usuarios finales reprtI$(In h:ltivos? aQuien porlicipora como miembro octivo del equipo?

2. FonnU/ese eI conlex/o del negocio. !C6mo encojo 10 WebApp en una estrategia de negocios mO$ ompl~
3.

Delinonse los meltrs y objelivas clave del negocio para 10 WebApp. ~C6mo $(I medira el 6xilo de Ia
WebApp, tanto en terminos cuolilolivos como
cuontitativos~

2 En los capltulos 7 y 8 ~

pre~nt.aron

can delalle las I~cnicas para desarrollar los casos de uso.

525

dose

Que o./inonsa leu metas informoliVOJ Y apliaJb~. a de tonlenido 5e proporcionor6 a los uworios

6.

RfJcopilense requisifioS. aQue !areas dell,l$uorio sa

U50 de Ia WebApp? eGue contenido 5e deKlrrollor6~ !Oue mel6fora de interocci6n se usor6? eave funciones compulocionales proporcionar6 Ia WebApp? tC6mo

Iogror6n median", el

Moles? aOue funciorle$/Ioreas 5e Iograr6n cuondo sa use Ia WebApp? IcIentiliquese eI probIerno. eave problema espec:fRco
~IaWebApp~

58 con~guror6

Ie WebApp para su urilizoci6n en red? tOue esquema de novegoci60 sa desea?

17.1 .3 EI puente hacia 91 modelado de ancllls1s

Como ya se ha seoaJado en este capitulo, las actividades que conducen a un equipo
de ingenieria Web de la formulaci6n al modelado de anaJisis representa un continuo.

En esencia, el grado de abstracd6n considerado durante las primeras etapas de \a

formulaci6n es la estrategia del negocio. Sin embargo, conforme la formulaci6n se

Jleva a cabo, se analizan los detalles tacticos y se abordan los requisitos especificos
de Ja WebApp. Finaimente, estos requisitos se modelan (con la utilizaci6n de casos de uso y notaci6n UML). Los conceptos y principios tratados para e\ analisis de requisitos de software (capltulos 7 y 8) se aplican sin revisi6n para la actividad de analisis de ingenieria Web. Durante el analisis se elabora el ambito deflnido durante la actividad de formulaci6n para crear un modele de analisls completo para la WebApp. En la lWeb se realizan cuatro tipos diferentes de analisis: del contenido, de ia interacci6n, de la funci6n y de la conflguraci6n. En el capItulo 18 se exponen las tareas y tecnicas de modelado asociadas con cada uno de estos anaiisis.

........

Dada la inmediatez de las webApps es razonable preguntar: . . en realidad se necesi ta gastar tiempo en la planeaci6n y administraci6n de un esfuerzo WebApp? iNo s610 se deberla dejar evoiucionar naturaimente a la WebApp, con poca 0 ninguna gesti6n explicita? Mas de un desarrollador Web optaria por poca 0 ninguna gesti6n, ipero eso no hace que esten en 10 correcto!
La figura 17.1 presenta un cuadro adaptado de Kulik y samuelson [KULOOJ que indica c6mo los "proyectos electr6nicos" (e~ projects , su termino para los proyectos WebApp) se comparan con los proyectos de software tradicionales. AI consultar la figura, los proyectos de software tradicionales y los grandes proyectos electr6nicos tienen similitudes sustanciales. Dado que la gesti6n del proyecto se indica para los

proyectos tradicionales, pareceria razonable argumentar que tambien estarfa indicada para los gran des proyectos electr6nicos. Los pequenos proyectos electr6nicos tienen caracteristicas especiales que los diferencian de los proyectos tradicionales. Sin embargo, incluso en el caso de los pequenos proyectos electr6nicos, la planea-

.,.

PARTE TRES

APUCAa6N DE LA INGNIERtA WEB

OOerendas entre proyectos trac:Hdonales y electrlmicos (8-proJects> {adaptcx\o de KULOO~

CJn.tdM ..,oy __

........ .-.....
l.opiloci6n
DurocilNo del

,,., ..... trodlciDnal.. ,....u.AN .......... . .""..Ii

eo.

....." . . 'tlll

RigurolO

Umilodo
rnodek,
meIIS

Riguros<l
~jOonlU

l~ifIcac'--

PYuebo

"Io~

.. "" 11.T""-........
pi''''''
8

MfIIClkoeion

~obusla'

PQf1O(OOTlO dllCripoivo
Medlado en dial, IeITIOIIQI 00 _

Robu,lO: mod.Ioa UMl,

Medida ...

Enfooodo.n ~ bIoncos 0. col,

Exp!ic:iIo
_I 0

Eniocado tobr. eonh'oI do ......

.."'"

Medida ... "'"''''''

~romienk> 0.10

............. a.. .,....,...w..

letf'ocl&imontact6n

O"IiOn ........

''''''
mOs
00

~300"" ...

col del iOhwore como "d.taibe en .I c~1o 26

ExpIlcikl
0.0012_

m6,

cOtto

o m61 corkl
Riguros<l

'roc," eM Iibofoc.on

RigurOlO

Expedikl
So .......
(MIiom6Iicamente

~k."r.:=.

,.....~

R~."""&O

S. obi..... kink! de
de 10

inter0a;!6n con III uwcmo

por medio de ooIic;i!vd 0. ..orooIirnonloci6n

mo""ro~lic:<Jeomo

ci6n se debe realizar, se deben considerar los riesgos, se debe establecer un progrl rna y se deben definir conlroles de modo que eviten la confusi6n, la frustraci6n y fracaso.

Un equipo de ingenieria Web exitoso mezcla una amplia variedad de talentos deben Irabajar como equipo en un ambiente de proyecto con alta presi6n. Los zos son cortos, los cambios son inexorables y la tecnologia continua cambiando. creaci6n de un equipo que se consolide (vease el capitulo 21) no es asunto sen

.,. II...., DdIIII. aIimmdo poi' II Web y tentroda .11 red, lIIIO nec:esila . . ,..,. cit .........:

s....." . . . ...
17.3.1
Los

actores

La creaci6n de una aplicaci6n Web exitosa demanda un amplio abanico de haIDlli'-des. Tilley y Huang [TIL99] abordan este tema cuando afirman: "Existen tantos ) i rentes aspectos del software de aplicaci6n la la Web] que se ha dado el del renacentista, aquel que se siente c6modO trahajando en varias disciplinas Aunque los autores estan en 10 correcto, los "renacentistas" son ,.l,alll,",neol1 pocos, y dadas las demandas asociadas con los grandes proyectos de desarrollo

WebApps, el conjunto de diversas habilidades requeridas puede ser mejor dlstrill do entre un equipo de ingenieria Web. Los equipos de ingenieria Web se pueden organizar, en gran medida, en la forma que los equlpos de software tradicionales (capitulo 21). Sin embargo, los

527
res y sus papeles usualmente son bastante diferenles. Entre las muchas habilidades que

se deben distribuir entre los miembros del equipo IWeb se encuentran:

ingenie-

rfa del sonware basada en componentes. realizaci6n de redes, disefio arquitect6n i-

co y de navegaci6n, lenguajes/estAndares de Internet, disef\o de inlerrase humana, disefio graftco, disposid6n del contenido y pruebas de las WebApps.
Los siguientes papelesl se deben distribuir entre los miembros del equipo Iweb:

DesarroUadores/ proveedores de contenido. Dado que el contenido controla inherenlemente las WebApps, una funci6n del equipo IWeb se debe enfocar en la

generaci6n 0 recopilaci6n del contenido. Recuerdese que e\ contenido abarca un

amplio abanico de objcles de datos, por ello los desarroltadores/proveedores de contenido pueden provenir de diversos ambitos (no de software). Editores de web. EI variado contenido que generan los respectivos desarrol1a dores/proveedores se debe organizar para induirlo en la WebApp. Ademas, alguien debe actuar como conexi6n entre el equipo tecnico que disena la WebApp y los desa rrolladores/proveedores de contenido sin conocimientos tecnicos. Este papel 1 0 satisface el editor de Web, quien debe entender tanto el con tenido como la tecnolo gia de la WebApp. Ingenlero Web. EI ingeniero Web se involucra en un amplio rango de activida des durante el desarrollo de una webApp, que incluyen la obtenci6n de requisitos, el modelado de ana.lisis, el disefto arquitect6nico, de navegaci6n y de interfase, la implementad6n de la webApp y las pruebas. EI ingeniero Web tambien debe tener una s6lida comprensi6n de las tecnologlas de componentes, de las arquitecturas cliente/servidor, de HTML/XML y de tecnologias de bases de datos, y un conoci miento practico de los conceptos multimedia, de las plataformas hardware/software, de Ja seguridad de redes y de cuestiones de apoyo a slUos Web. Expertos en dominios empresariaJes. Un experto en dominio empresarial debe ser capaz de responder lodas las preguntas reladonadas con melas, objetivos y requisit os empresariaies reladonados can la webApp EspeclaUsta 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 evolu donan continua mente, el especialista de soporte es responsable de las correcciones, adaptadones y mejoras al sitio, que incluyen actualizaciones de contenido, imp Ie mentaci6n de nuevos pracedimientos y formas, y cambios al patr6n de navegaci6n Administrador. usualmente lIamado "web master". esta persona liene la res ponsabilidad de la operaci6n diana de la WebApp. 10 que incluye: desarrollo e imple mentad6n de poHticas para la operaci6n de la webApp, establedmiento de procedi mientos de soporte y retroalimentad6n. Iffiplementad6n de seguridad y derechos de acceso. medici6n y ana.lisis de trafico del Sltio Web. coordinad6n de los pracedi mientos de control de cambios (capitulo 27) y coordinaci6n con el especialista de
3 Estos papeles se han adaplado de Hansen y sus coIcps IHAN'J91

528

soporte. EI administrador tambien puede estar involucrado en las actividades tecnicas que realizan los ingenieros Web y los especialistas de soporte.

fr........
Esm corocrtrfsticas SDI! USIOas ., /os ~ de cOObotrJ.

17.3.2 Construcc1on del equipo

En el capitulo 21 se trataran con derla delalle los lineamientos para la construcci6n exitosa de los equipos de ingenieria del sonware. Pero. ;.estos lineamientos se aptican en el apretujado mundo de los proyectos WebApp? La respuesta es sl. Haee algun Hempo. en su exita de libreria acerca de la industria de la computaci6n, Tracy Kidder IKIDOO] cuenta la historia del heroico intento de una campa "de computad6n poT construir una computadora para enfrentar el reta de un nu producto que fabric6 un competidor mas grande.4 La historia es una metaJora del eqwpo de trabajo, del liderazgo y del aplastante estres que todos los tecn61ogos encuen tran euando los proyectos criticos no avanzan tan suave mente como se plane6. Un resumen del libro de Kidder dificilmente Ie haee justicia, pero los siguientcs puntos clave [PICO 1[ Henen particular relevancia cuando una organizaci6n constn/. ye un equipo de ingenieria Web:

""'--'" ............ .....

~('"""
4}. .41isntra5 " . ~,,~,-

"'..-do -.
~

fXoOOzcD .

se debe establecer un conjunto de directrices de equJpo. Dichas diredIJ ees abarcan 10 que se espera de eada persona, c6mo se Iidiara con los problemas que mecanismos existen para mejorar la efectividad del equipo conrorme avanza proyecto.
El Uderazgo (uerte es una obligad6n. EI Uder del equipo debe guiar mem. te el ejemplo y el contacto. Debe mostrar un grado de entusiasmo que impulse a otros miembros del equipo "a endosarse" psicol6gicamente al trabajo que enfren El respeto hada los talentos indivtduaJes es crudal. Nadie es bueno todo. Los mejores equipos utilizan las fortalezas individuales. Los mejores IId,~ equipo permiten que los individuos tengan libertad para seguir una buena idea cada mJembro del equipo se debe comprometer. El protagonista Drind'" en ellibro de Kidder Ie llama a esto "endoso".

Es fAdI comenzar, 10 diftdl es mantener el impetu. Los mejores equipos dejan que un problema "insuperable" los detenga. Los miembros del equipo <Ie:..... llan una soluci6n "10 suficientemente buena" y proceden, con la esperanza de (mpetu del progreso pueda eondueirlos a una soluci6n todavia mejor en ellargo pI.J'..

Una vez realizada la formulaci6n y que se han idenlificado los requisitos la WebApp, 1a empresa debe elegir una de dos opciones de ingenierfa Web WebApp es subcontrorada (outsourced): la ingenierla Web la realiza un tercer
4 EI libro de Kidder. The SOul of (1 New Machine. origlnalmente publicado en 1981. ies una lectunI tamenle recomendable para cualquiera que intente realizar una carrera en la compulaci6n quienes ya la Ilenen!

529

dor con experiencia, talento y recursos con los cuales no cuente la empresa; 0 2) la WebApp la desarrollan en casa ingenieros Web que sean empleados de la empresa . Una tercera opci6n (hacer algun trabajo de ingenieria web en casa y subcontratar
otro trabajo) tambien es una posibilidad.

0lIl ,torto. La 'lido en un proytdo de softwort que tOfTe po/Irtmtflle; as salm, pobrl, peligroso, awl Y tell . . . . . . . . vez IS 10 sufKientemtnte (DI1a. StfYtI.c
El trabaja que debe realizarse sigue siendo el mismo sin importar si una webApp es subcontratada, desarrollada en casa 0 distribuida entre un proveedor extemo y el
equipo de casa. No obstante, sl cambian los requisites de comunicaci6n, la distribu-

'CoM ......

n.n.. Hob!." ..... "', Io.;do bo~ 1m ",1m do 1m p<06 ....... pain, .......

ci6n de actividades tecnicas, el grado de interacci6n entre clientes y desarrolladores, y una diversidad de atros conflictos crucialmente importantes. La figura 17.2 ilustra. respecto a las WebApps, la diferenda organizaeional entre subeontratad6n y desarrollo en casa. Este (figura 17.2a) integra direetamente todos los miembros del equipo de ingenieria web (el dreulo punteado impliea integraci6n) . La eomunicad6n se estableee mediante los eaminos de la organizad6n. En euanto ala subcontrataci6n (figura 17.2b), es impractico y desaeonsejable que cada elementa de casa (por ejemplo, desarrolladores de contenido, acdonistas, ingenieros Web internos) tenga eomunicad6n directa con el subcontratista sin que exista algun elemento de conexi6n para coordinar y eontrolar la comunicad6n. En las secdones que siguen se examinaran con mas detalle las planeadones para la subeontratad6n y el desarrollo en casa.

Adm iniwodof

,
\

'-_/'

a/ o.sarroHo en ca...

530

PARTE TRES

APUCAct6N DE LA lNGENlER!A WEB

tc".N"'."
Nase~fPI,

17.4.1 Planeacion de WebApp: subconb'atacion

Un porcentaje sustanciai de las webApps se subcontrata con proveedores que (supuestamente) se especializan en eJ desarrollo de sistemas y aplicaciones basados en Web ,s En tales casas, un negocio (ei cliente) pide un precia fijo para desarrollar la webApp de uno 0 mas proveedores, evalua los precios competitivos y luego elige un proveedor para efectuar el trabajo. Pero, ique busca la organizaci6n contratante?
;.C6mo se determina la competencia de un proveedor de WebApps? ,C6mo se sabe si una cotizaci6n es razonable? ,Que grado de planeaci6n, programa de trabajo y valoraci6n de riesgo se pueden esperar conforme una organizad6n (y su subcontratista) se embarca en un esfuerzo por desarrollar una gran WebApp?

puesto que 58 Ita mootrotrJdo OOCJ

WeMw, mlesporISIr

fiIidodes son minimas. De hedIo,

8S jXOOobIe f1JfI 56

rBqIJieron m6s, 110

meoos,~y

gesrilln.

.......1IIJIfImII$ lie Fortune sao han descubierto cd software coma un madeIa lie senicio bwm: Ii ' I), ....
_ Is JI MIIiIIIos sinMns intema 0 extemamente,

Estas preguntas no siempre son ftldles de contestar, pero vale la pena considerar algunos lineamientos, Inido del proyecto. Si la subcontrataci6n se elegirtl como la estrategia para desarrollar la WebApp, la organizaci6n debe realizar una serie de tareas antes de buscar una empresa subcontratista que haga el trabajo:
I . Realizar, intemamente, muchas de las /abares de ana/isis tratadas en /a secci6n

..-

17, 1,3 (Y en e/ capitulo 18), Se identifica el publico para la WebApp; se hace una lisla can los accionistas internos interesados en la WebApp; se definen y revisan las metas globales para la WebApp; se especifican la informaci6n y servicios que habra de proporcionar la webApp; se destacan los sitios web competidores; y se identifican las "medidas" cualitativas y cuantitativas de una WebApp exitosa, Esta informacion debera documentarse en una especificaci6n de producto que se entregara al subcontratista,
2 . Desarro/lar intemamente un diseiio aproximado de /a WebApp, Obviamente, un

tc".N"'."

"""" "",.'"
C(J(/1(l

argumenhJll que wei

riseIio aptoxinodo"
es mrteCeSOJio. Veose

"mero orertu" que eI proveWor suixon/rofis1lJ (XJede mOOifiror y mejoroI. AJ /II611OS estd romunkondo SUS ideas OCefCO de aque It debe patfK9f ei
WlO

desarrollador Web experto creara un disefto completo, pero es posible ahorrar tiempo y costa sl la visi6n y el sentido general de la WebApp se identifican para la empresa subcontratista (esto siempre puede modificarse durante las etapas preliminares del proyecto), El disefto debe induir una indicaci6n del tipo y volumen de contenido que se presentara en la webApp y los tipos de procesamiento interactivo (par ejemplo, formatos. entrada de pedidos) que se llevaran a cabo, Esta informaci6n debera agregarse a la especificaci6n del producto,

-"",.

Aunque es dificil eneontrar datos industriales confiables, puede afirmarse que este porcentaJe 5 considerablemente mayor que el que se obse!'va en el tTabajo de software convencional. En el cap tulo 23 se ofrece una cxposici6n adicional acerca de la subcontrataci6n_

531

3. Efaborar un programa aproximado que inc/uya no sO/a los jechas finales de en-

trego, sino tambienfechas clave. Las fechas clave se deben actjuntar a las versiones de entrega (incrementos) de la WebApp conforme esta evolucione .

4. Crear una lista de responsabilidades para 10 organizaci6n interno y el subcontraOSlO.

En esencia, esta tarea aborda que informaci6n, contactos y otTOS recursas se requieren de ambas organizaciones.

5 . Identificar e/ grado de supeIVisi6n e inleracd6n de 10 018anizaci6n contratante con eJ suOContTatista. Esto debe inc1uir e[ nambre del contacto del vendedor y Ja identificaci6n de las responsabilidades y autoridad del contacto, la definici6n de los puntas de revisi6n de calidad conforme avance el desarrollo, y las responsabiJidades del subcontratista en relaci6n con la comunicaci6n entre las organizaciones.
Toda la informaci6n generada durante estos pasos debera organizarse en una solicitud de presupuesto que se entrega las empresas candidatas. 6

......,",,?

varlas

selecci6n entre los subcontratistas candidatos. En los ultimos af'ios han surgido miles de compaf'tias de "disef'to Web" dedicadas a ayudar a las empresas que desean establecer una presencia Web 0 aventurarse en el comercio electr6nico. Muchas se han vuelto adictas al proceso de IWeb, pero muchas otras son poco mas que hackers (intrusos informaticos). Con la finalidad de elegiT desarrolladores Web candidatos, el contratante debe realizar algunas diligencias obligadas: I) entrevistar a los clientes antiguos para determinar el profesionalismo del vendedor Web, asi como su habilidad para cumplir con compromisos de plazas 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, despues, asegurarse de que esta persona tenga la obligaci6n contractual de estar involucrada en su proyecto); y 3) examinar cuidadosamente ejemplos del trabajo del subcontratista que sean similares en apariencia y sentido (y area de negocios) a la WebApp que sera contratada . lncluso antes de que se ofrezca una solicitud de presupuesto, una entrevista personal puede ofrecer un discernimiento sustancial de la "conexi6n" entre el contratante y el subcontratista.

Valoraci6n de la validez de las cotizadones y la confiabilidad de las estimaciones. Puesto que existen rela tivamente pocos datos hist6ricos y que el ambito de las webApps es fluido en forma notoria, la estimaci6n es inherentemente ries6 Si el tTabajo de desarrollo de la WebApp 10 dirigiri un g:rupo mterno, ilO cambia nada! El proyecto

.se inida de la misma manera.

PARTE TRES

APUCACI6N DE LA INGmIElllA WJJI

gosa . Por esta raron. algunos proveedores incorporaran margenes de seguridad sus-

tanciales en cotizaciones para un proyecto. Esto es comprensible y apropiado. u,

pregunta no es sl se ha obtenido la mejor soluci6n pot la inversi6n. Mas bien, las pre-

guntas deben set:

tLa cotizaci6n de la webApp ofrece un rendimiento sobre J a i nversi6n, direao o indirecto, que justifique el proyecto?
i..La empresa emisora de la cotizaci6n tiene el profesionalismo y la expe-

riencia que se requieren?

Si las respuestas a estas preguntas son afirmativas la cotizaci6n es justa.

Comprensi6n del grado de gesti6n del proyecto que puede esperar 0 Tealzar. La formalidad asociada con las Jabores de gesti6n del proyecto (que reallzan proveedor y la organlzacl6n cantratante) es directamente proporcional at tamahc casto y complejidad de la WebApp. Respecto a proyectos complejos y grandes necesario elaborar un programa del proyecto que defina las tareas del trabajo, puntos de comprobaci6n, el aseguramiento de la calidad del software, los produ

de trabajo de ingenieria, los puntos de revisi6n del c1iente y los hitos importantes proveedor y el contratante tendrtm que valorar el riesgo conjuntamente y elabora planes para mitigar, monitorear y manejar los riesgos considerados importantcs. Los mecanismos para asegurar la caUdad y el control de cambios se deberan deft explicitamente por escrito. Se deberan establecer metodos para la comunica efectiva entre el contratante y el proveedor. Evaluad6n del programa del proyecto. Dado que los programas de desarrol. de webApps abarcan un periado relativamente carta (por 10 general menos de ados meses para que se entregue el incremento), el programa para el desa debe tener una dosificaci6n muy precisa. Es decir: las lareas de trabaja y los . menores se deben programar en un cronograma diario. Esta dosificaci6n pr pennite. tanto a la organizaci6n canlratante como al subcontratista. reconocer hoja suelta de la agenda antes de que amenace la fecha de finalizaci6n. Gesti6n del ambito. Como es enormemente probable que el ambito cambiara fOITTle avance el proyecto de la WebApp, el modelo de proceso IWeb es adaptablt incremental. Esto permite que el equipo de desarrollo del subcontratista "conge Ie' ambito para un incremento. de modo que se pueda crear una \iberaci6n operativa la webApp. EI siguiente incremento puede abordar cambios en el ambito que sugerido una revisi6n del incremento precedente. pero una vez que comience segundo incremento el ambito nuevamente se ~con ge l a" de manera temporal. enfoque permite que el equipo de \a WebApp trabaje sin tener que acomodar corriente continua de cambios, pera al mismo tiempo reconoce la evoluci6n c nua caracterlstica de la mayoria de las WebApps . Los lineamientos sugeridos [[neas atn'ts no intentan ser un recetario a prueba tontos para l a producci6n a tiempo de webApps de bajo casto. Sin embargo. ayuda'

~~VE h._0101

....... '"

6nOIo 51 (oogelo eI
~IfJIIYVYOo

...

,,_ .. ......
iIaeInno.lDs

CIdias 51 demmoo

533

ran tanto a la organizaci6n contratante como al subcontratista a inidar el trabaja de manera flexible con un minima de malas interpretaciones.

.._.aI. . . . _ ..""""_.
equipo de , "-on Wood.. 01 .. .....10. comettio electr6nko
ingeniriJ~

. .que . . as E .... Sobe cNCioI

dip .. e/edr6nko moftona en Ia maftana..

que I8nio que po!*'

~abap~.~odo~~"~E~~;5'
...,.00.

...... ....,b." _.

Cf'Jiero enl,u'''...m .... 1u CIIIfIIiirID......

,,",izor .., eI

5harom No hoy poohl.na, '* .......... irwolucroc:b. a ~~

Todo comunica06n .....Iro
como Viood.

......

ooIondorio .."...0,.
Iitio.

........
01 hobojo . 01
"a,il

Iogros, los pob&.mca....... aeo que eso 81 10 t;tdeQ1IIdo ' Sharonl EdO bt.n.

""*'

)'0 cilI.

,..

Doug(................ ..mtorio Y ...

-....
coollaclai 0 WI

ogondo """",""",st-en (Iuego OIl.

Mm~ .
~

(DI05.

kxde Ie 10 lIMo per OCII'NO r' ' ....

.....

... ~

...... CIom

17.4.2 Planeacion de WebApp: lngenleria Web en casa

Conforme las WebApps se vuelven m~ extensas y estrategicas para los negocios. muchas compai'llas han optado por controlar el desarrollo en casa. No sorprende que 1a IWeb en casa se gestione de manera un poco diferente a un esfuerzo de $ubcontrataci6n.

--

534

PARTE TRES

APUCAOON DE LA!NGENIERIA WEB

La gesti6n de proyectos IWeb pequeiios y de tamana moderado les decir:

de 3-5 meses de duraci6n) requiere un enfoque agil que quite el enfasis en la ge

del proyecto pero no elimine la necesidad de planear. Todavla se aplican los prino piDS basicos de gesti6n de proyectos (capitulo 21), pero el enfoque global es
parco y menos formal. Sin embargo, conforme crece eJ tamafio del proytdt WebApp, la gesti6n del proyecto de ingenierfa Web se vuelve mas y mas wmo I. gesti6n de proyectos de ingenierfa del software (Parte 4 de este libro). Los

siguientes se recomiendan para proyectos IWeb pequei\os y de tamana moderado

f:ONJIJO.
fs irIJpcxtoo1s
f9COOOCsr t:pB

los

fX1SD5 f1flOizados 811 95/11 seam 56

pooden leoilOf dameIlte. En rWIg(Jn

(asolo~

Entender e) ambito, las dimenslones de cambia y las restrlcdones del yecto. Ningun proyecto, sin importar euan apretada sea la restricci6n del tielf1JO puede comenzar mientras el equipo del proyecto no entienda que debe construir. recopilaci6n de requisitos y la comunieaci6n con el cliente son preeursores e",ne;" les para la planeaci6n efectiva de la webApp.
Definir una estrategta de proyecto incremental. Va se ha senalado que WebApps evolucionan con el tiempo. 5i la evoluci6n es descontrolada y ca6tica. probabiJidad de un resultado exitoso es pequena. 5in embargo, si el equipo estab'.~ ce una estrategia de proyecto que defina incrementos (Hberaciones) de webApp proporcionen contenido util y funcionalidad a los usuarios finales, el eslheJczo "" ingenierla puede enfocarse con mayor facilidad. Reallzar anMisis de rlesgo. En el capitulo 25 se presenta una exposici6n lIada del analisis de riesgo para proyectos tradicionales de ingenieria del software Todas las labares de gesti6n de riesgo se realizan para proyectos lWeb, pero su que se abrevia. Los riesgos que entranan el programa y la tecnologla dominan la p~::.~~:: de la mayorla de los equipos de ingenierla Web. Entre las muchas preguntas nadas con el riesgo que el equipo debe formular y responder estan: ;.Los incremen WebApp planeados pueden entregarse en los plazos definidos? ;.Estos incTeOno_ proporcionaran valor subsecuente para los usuarios finales mientras se realiu ingenierla de incrementos adicionales? ;.C6mo impactan las fechas de entrega solicitudes de cambios? ;.EI equipo comprende los metodos, tecnologlas y mientas de ingenieria Web requeridos? ;.La tecnoiogia disponible es adecuada trabajo? ;.Los cambios probables requieren la introducci6n de nueva tecnologla? Desarrollar una estimad6n rapida. El eje de la estimaci6n para la mayoria los proyectos de ingenierla Web 10 representan los conflictos macrosc6picos, que los microsc6picos. El equipo IWeb valora si los incrementos WebAP)IP;;;~;':: pueden desarrollarse con los recursos disponibles de acuerdo con las TI de! programa definido. Esto se logra considerando el contenido y la funci6n deca"

"'Y". rId>I.

/Web para proyfICtos de 85m tnroofto toma nx!s del 5pIX denio del rdueuo d4JI

Aquellos lectores que no esten familiarizados con lit terminolog!a y las pr<kticas basicas de ti6n de riesgos deberan consultar en este momento el capftulo 25.

535

incremento como un todo. Normalmente no se realizan rompimientos "microsc6pl COS", funcionales 0 de trabaja, del incremento que sean seguidos por el calculo de estimaciones puntuales de multiples datos (vease el capitulo 23).

Elegir un conJunto de tareas (descripci6n del proceso) . Empleando un marco de trabaja del proceso (capitulo 16) se elige un canjunlo de tareas de ingenierla web
que sean adecuadas para las caracteristicas del problema , el producto, el proyecto y 1a gente en el equipo de ingenieria Web. Recon6zcase la posibilidad de adaptar el

canjunlo de tareas para que encaje en el desarrollo de cada incremento.

Establecer un programa. EJ programa de un proyecto IWeb tiene una dosiflcaci6n reiativamente precisa respecto de las tareas que se realizartm en el corto plazo, y luego una mucha mas nexible durante peri odos posterlores (cuando vayan a entre garse los incrementos adiclonales) . Esto es, las tareas de ingenierfa Web se distribu yen a 10 largo de la linea de tiempo del proyecto para el incremento que se desarro l1ara. La distribuci6n de tareas para subsecuentes incrementos WebApp se demora hasta la entrega del incremento programado. Definlr mecanismos de rastreo del proyecto. En un ambiente de desarrollo agil, la entrega de un incremento operativo de software can frecuencia es la medlda primarla del progreso, Pero mucho antes de que el software liberable este disponi ble, el ingeniero Web enfrenlara inevitablemente la pregunta: ,d6nde estamos? En el trabajo convencional de ingenieri a del software el progreso se mide determinanda que objetivos se han lograda (por ejemplo, la revisi6n exitosa de un producto de tra baja). Respecta a proyectos de ingenierla Web pequenos y de tamana moderado, los objetivos pueden estar menos definldos, y las actividades formales de aseguramien to de la calidad pueden perder fuerza. En consecuencia, es pasible derlvar una res puesta 51 se entrevista al equipo de ingenierfa Web para determinar que actividades del marco de trabaja se han completado. No obstante. este enfoque puede ser poco fiable. Otro enfoque es determinar cuantos casos de uso se han implementado y cuantos (para un incremento dado) permanecen sin implementarse. Esto proporcio na una indicaci6n aproximada del grado relativo en que se ha completado el incre mento del proyecto.

Establecer un enfoque de gesti6n del cambia. La gesti6n del cambia se facili ta mediante 1a estrategla de desarrollo incremental que se recamend6 para las webApps. Puesto que el tiempo de desarrollo para un incremento es corto, can fre cuencia es posible demorar la introducd6n de un cambio hasta el siguiente incre mento, con la consiguiente reducci6n de los efectos de demora asociados con los cambios que se deben implemenlar ~al vuelo~ En el capitulo 27 se presenta la ges li6n de la configuracl6n y el contenido para Las WebAWS

536

Gest16n de proyectos !Web

gelli6n de proyectro graluito, en lineo y bo~ en Web, que puode usar 0)r1 W navegodor web,

Obj_tivo: Auxiliar aI eqtJipo de ingenieria web en Ie p/anead6n, gesti6n, control y ro~reo de proyeclos de ingeniena web.

Mec6nic::a: Las herramientos de gesri6n de proyedos Ie permilen a un equipo rweb e~ un conjunlo de Iorem de troboio, o"gnor esFuen:o y especifioor responsobilidod a coda tarea, estoblecer cIepeodencia de Ioreas, dennir un progromo y rostreor y controlor kls octividodes del proyedo. Mucha, hemlmienlos en eW categorio WOn boKJdos lin web.

0url'r0jec1, Oe$o!lrrollado por Our Project (www.OtRprOject.coml. '" uno suite de hem:lmienlas de gesti6n de proyec:to que: son aplicables a 10 lWeb Ya 100".",.- de -.~.

ProjNeI, desarrolloclo po!" Rolional Concepts, Inc.

(www.rotionok:oncepls.com). "implemenla una oficino

Herramiento. ,..presentcmvo.'
Bu3ine Engine, desorrollodo por Bu~neu Engine
(www.businenengine.coml. ItS una suite de herromienlos boKJdos en web que ohcen Ioc:ilidodes de gedi6n para proyedo5 compIetos de rweb y

de proyecto virtual (vPO, virtual project office) pora coIoboroci6fl y CO!I'IUnicocioo" SIortWright (_.~9hl.com/projedl.hlm) ho Oesorrollodo uno de los recur~ men oomplelos de 10
Web para herromiet1las It informod6n, I'CmIa para lWeb como port! gesti6n de proyecIos de toftwore
~.

dtwore c;onvenc:iono!es. /momwoti, desorrollodo por i1'eomworkcom

(W'WW.iteomwork.com),
MI

proyedo$ de

uno oplicoci6n de eqvipo de

b necesorio oIervor que mucOOs de los herromienlos de gesti6n de proyectro cOOYeOCioooI (Porte .. de liSle 'ibro) Irombien se pueden opn:wechor de monero efectivo en los
~rweb.

Los ingenieros Web desarrollan sistemas complejos y, al igual que otros tecn61 0p que realizan esta tarea, deben usar mediciones para mejorar el proceso de ingenieria Web y el producto. En el capitulo 15 se analizaron los uses estrategicos y Lictia para la medici6n de software en un contexto de ingenieria del software. Dichos USOI
tambit~n

se aplican en la ingenieria Web. En resumen, Ja medici6n de software ofrece una base para mejorar el proceso de

En gntd, elllineto cit mdJas /Web !pi

II dsbIl

... .........
l"IJPOIoold d
!,W II consfni'lj.

""""'*"

"'_
rscOllh. ~ su f1d>t/.

software, 10 que aumenta la precisi6n de las estimaciones del proyecto, incremeru. el rastreo del proyecto y mejora la calidad del software. La medici6n de ingenieriol Web, si se caracteriza de manera adecuada, podria lagrar todos estos beneficios tambien mejorar la facilidad de uso, el desempeno de la webApp y la satisfacci6n de. usuario. En el contexto de la ingenieria Web, las mediciones tienen tres metas principala 1) proporcionar un indicador de la calidad de la webApp desde el punto de vista tnico, 2) proporcionar una base para la estimad6n del esfuerzo, y 3) proporcionar um indicaci6n del exito de la webApp desde el punto de vista empresarial.

8 Las herramientas expuestas 5610 representan una muestra de esta categorla. En cas! lados los ca50S los nombres de Las mlsmas son marcas registradas de sus respectivos desarroUadores.

537

En esta secci6n se resume un conjunto de mediciones de esfuerzo comun y complejidad 9 para las webApps. Este canjunto puede destinarse aJ desarrollo de una base de datos hist6rica para Ja estimaci6n del esfuerzo. Ademas, la medici6n de la
complejidad puede conducir a final de cuentas a una incapacidad para valorar cuantitativamente uno 0 mas atributos tecnicos de las wehApps discutidos en el capitulo 16.

17.5.1

Mediciones para estuerzo de ingenieria Web

los ingenieros web dedican esfuerza humane al realizar una diversidad de tareas de
trabaja conforme evoluciona una WebApp. Mendes y sus colegas [MENOI] sugieren

algunas posibles medidas de esfuerzo para WebApps. Algunas de (0 todas) elias podria registrarlas un equipo de ingenieria Web y luego aprovecharse en una base de datos hlst6rica con fines de estimaci6n (capitulo 23).

Aplicaciim de las #areas de autoria y diuiio

Medida sugerida
e$fuer.w

Descripcion
hempo f.Xlro estructuror Ie WebApp y/o Ie orquitecruro deflYOOO tiempo poro intefYinculor p6ginm y 0$1 constflJir 10 e5hoctura de 1m

de e~lrvc:ruroci6n ~fver.ro de inlervinculoci6n

pIoneoci6n

WebApp
C0r\51rucc;oo e5fverzo

de inlerfoz de in~foz
p-uebo de vioculm

hempo en que !>e tiempa en que tiempa en que tiempa en que

!Ie !Ie

pIof\eO 10 inlerfoz de Ie WebApp

implemenla 10 interfoz de Ie WebApp
p-uebon prueb:m

de

lodes 10$ vinculm en 10 WebApp Iodos 1m mediO$ oudiovisooles en Ia

asluerzo de pwebo de 10$ mec!ios oooiovisuole5 esfverzo Iotol

!Ie

Web<lpp

de

esfvetza de e$tTocturoci6n + esluefzo de inlervinculoci6n + pkmeoci6n inlerfose + conwocci6n de in~fO!>e + esfvetzo de pruebo de vifICLI" 1m + esfuerzo de pruebo de 1m medios aooiovisuoles

Estu.no d. outoria
Medido sug.rido
esfuerzo de laxlO esfver.ro de vinculoci6n de p6gina esfverzo de estTocluroc;oo de p:'>gina
~OOfZo

DescripciOn
hempa en que sa aeo
0

reuti lize lexto en uno p:lgirlO

tiernpa erl que sa aeon vinculo5 en 10 p6g ine tiempo en que sa estructuro 10 p:'>gifIQ esfverzo de Iexto + eWeuo estTvc:tvroci6n de p6g1OO

de p6gina I0I01

de vincu!oc;oo

de p6gino + e~uerzo

de

Es importanle nOlar que las mediciones lWeb todavia e5l.in en su infancia

538

PARTE TRES

APUCAa6N DE LA INGNlERlA WEB

Autorio d. meJios audiovi.ual

Medida 5ugerida
duerzo

DescripciOn
tiempo en que se creon 0 reutilizo n orc hivos ti empo en

de

medic oooioviwol

de

medics oudiov iwoill

esruerzo de d ig itol izoc i6n medi05 oud iovi5lKl le~

de
q...e se digitolizon medias oud ioviwoles

dverzo I0I01de medias

oud iovisooles
esfuerzo de media audiovisool + esfuerzo rnedlOS oudkwlwdes

de d igitolizociOO de

AI/toria de programo.

Modida lugenda
esfuello de progromoci60
e~zo

Desc:ripc:ion
tiempo en que se creon HTMl, jovo 0 implementocior.es relocionodo

de

de reutilizocK>!1

liempo p::n o reutilizor/modilicor 10 programoci6!1 existoote

17.5.2 Med1cl6n del valor de negoc1os

Es interesante advertir que la gente de negocios ha llegado considerablemente an que la ingenieria Web al desarrollo, la recopilaci6n y el empleo de la medici6n las webApps {por ejemplo, [STE02], {NOBOIJl . Al entender la demografia de usuarios finales y sus patrones de usa, una compania u organizaci6n puede d~ rrollar la entrada inmediata para mas contenido webApp significativo, ventas esfuerzos de mercadotecnia mas efectivos, y mejorar la rentabilidad de los neg Los mecanismos requeridos con que se recopilan datos valiosos para la err.po... usualmente los implementa el equipo de ingenieria Web, pero evaluarlos y las a nes resuitantes las realizan otros participantes. Por ejemplo, sup6ngase la pas dad de determinar el numero de vistas de la pagina para cada visitante Unico. base en la medici6n recopilada, los visitantes que llegan desde el motor de bu da X promedian nueve vistas de pagina, mientras que los visitantes desde el portal. s610 dos. Estos promedios los puede emplear el departamento de mercadotea para ubicar un anuncio pubJicitario (banner') donde promueva presupuestos (la p cidad en el motor de busqueda X propordona mayor exposici6n, con base en medid6n recolectada, que la publicidad en el portal Y).

Mediciones Web Objetivo: Valoror Ia forma en 10 que se utilize una WebApp, los categorios de U5UCriOS Y Ie foc.ilidod de U50 de 10 WebApp. Meconico: La groll mayorfo de los helTCmienkl$ de

medicioo Web capture 10 informoci6n de U$O uno vez ~ 10 WebApp esl6 en linea. Dichcs herromienlcs proporcionan uno omplie voriedod de datos ,~, ". ad. S(! valora que elementos de Ia WebApp se utilizen mCs, c6mo se utilizon y quien los utilizo.

53

..._,-"......presentotiVO. 10

~::~;~:~::::~~:::d~i~a::mx~b:.~~:~ de on6lilis
ard.ivos de occeso (log) que muestro eI ..-porkImieolo del visitante 01 silio web directomente p6ginas de esle.

OIoro el8xito de los w~ de comercio electr6nico. Web MttIrics resIDed, dMorroUoda par NIST
Izing.rw::il.ni",QO/WebToois/L es una suile de

, desorroUaoo par Coremetrics _.Coremelrics.com), es represenlotivo de muchas iemos que rec:opilon ~ con len c;uo~ se

herromientas boK!dos en web que voloren 10 Iocilidad de usa de uno WebApp. WebTntnds, desarrollodo par netfQ (WW'W.NeIlQ.com), recopilo un omplio rongo de dotos de usa perc w.bApp. de todo, los. tipot..

Una revisi6n completa de la recopilaci6n y el empleo de las mediciones con valor en los negoc.ios (que incluya el debate actual acerca de la privacidad personal) esta mas alia del ambito de este libra. El lector Interesado debera examinar [INA02J,
[EIS02), [PAT02! 0 [RlGOI].

En ocasiones, la mejer rorma de aprender romo hacer alga correctamente jes exa minar c6mo no hacerlo! Durante la decada pasada. muchas webApps fracasaron porque I ) un descuido del proyecto y el cambio en los principios de gesti6n (de cual quier manera infonnales) result6 en un equipo de ingenierla Web que "rebot6 en las paredes"; 2) un enfoque ad hoc para eJ desarrollo de la webApp fa1l6 y no produjo un sistema operable: 3) un enfoque desdenoso hacia la recopilaci6n y analisis de requi sitos fracas6 en producir un sistema que satisfaciera las necesidades del usuario; 4) un enfoque incompetente para el diseno fracas6 al intentar producir un desarrollo de la webApp que fuese utilizable, funcional, extensible (sustentable) y verilicable; 5) un enfoque equivocado para las pruebas fracas6 para producir un sistema que funcio nase antes de su introducci6n. Con estas situaciones en mente, tal vez valga la pena considerar un conJunto de las "peores practicas" en la ingenierla Web, adopladas de un articulo de Tom Bragg [BRAOOj. 5i su proyecto electr6nico muestra cualquiera de elias, es necesaria una acci6n correctiva inmediata.

Peor practlca
/a WebApp

# I : Se tiene una gran idea, as! que se puede comenzar a construir ahora, No es necesario preocuparse en considerar si la webApp esta jus-

tilicada por el negocio, si los usuaries realmenle quemln usarta, si se comprenden los requisites del negocto. EI liempo es corto, tiene que comenzarse. Realidad: T6mense unas cuantas horas 0 dias y elab6rese un caso de negocios para la webApp. Asegurese de que la idea Ia apoyan qUlenes la financiarim y quienes la usaran.
10 Las herramientas expuestas el autor no las respakSa 6io repr~ ntan una muestra de las herra mientas incluidas en esta categorta. En CilSI todI:J5 II CU05o, \05 nombres de las herramle ntas son marcas registradas de sus respectivos desarroll.dort'S

Peor prAcUca ' 2 : Las cosas cambiardn conslantemenle, asi que no Uene case trotar de comprender los reqwsitos de la WebApp. Nunca se escriba algo (perdida de tiem-

PO). El apoyo debe basarse exclusivamente en la palabra oral. Realldad: Es derto que los requisitos de la webApp evoludonan conforme CCIrf-tinllan las actividades de ingenieria Web. Tambilm es mas rapido y simple obte informacion de manera verbal. Sin embargo, un enfoque desclefioso respecto de recopilaci6n y el analisis de requisitos es un catalizador para mas cambia (innecesario) todavla . Peor practlca 11 3 : Los desarrolladores cl!Ya experiencia dominance ~ re/adona

eJ desarrollo de software tradidonal pueden desarrollor WebApps inmediatamente. No

requiere un nuevo enfrenamiento. Despues de todo, el software es software,

,0

no?

Realidad: Las webApps son diferentes. Se debe aplicar de manera experta amplia abanico de metodos, tecnologlas y herramientas. E1 entrenamiento y 1a expeo riencia can elias es esencial. 11 Peor prActica ' 4: Burocrariza~. Insista en modelos de proceso pesados, har.rios, muchas e innecesarias reuniones Nde progreso" y en IIderes de proyecto nunca han gestionado un proyecto WebApp. Realldad: Aliente un proceso agil que resalte la competenda y la creatividad un equipo de ingenierla Web experimentado. Luego salga de su camino y perml trabajar. Si se deben recopilar datos relacionados can el prayecto (por razones ) les 0 el calculo de 1a medid6n) , el ingreso/recopilaci6n de datos debe ser tan no tructiva y simple como sea posible. Pear practica Its : ~Pruebas? ~Por que mo/esta~? Se Ie dara a unos cuantos rios finales y se dejara que ellos digan que funciona y que no. Realidad: Con el tiempo, los usuarios finales 51 realizan "pruebas" exhaustt pero estan tan enojados por la falta de confiabilidad y el pobre desempeno que dejan mucho antes de que los problemas sean corregidos (nunca regresan) . En los capitulos que siguen se considerartlO los metodos de ingenieria ayudaran a evitar estes errores.

w"b .,'"

La formulaci6n, una actividad de comunicaci6n con el clienle, define el problema resolvera una WebApp. Se identifican las necesidades del negocio, la melas y obje i del proyecto, las categorias de usuario final, las funciones y caracteristicas yel grado de interoperabilidad con otras aplicaciones, Mientras mas informaci6n lIada y tecnica se adquiera, la formulaci6n se convierte en analisis de requisites
II Muchos grandes proyectos [Web requieren integraci6n con aplicaciones y bases de datos COnI cionales. En tales cases, los individuos s610 con experiencia convencional pueden y deben sa volucrados.

cAPinn.o

17

FORMULACI6N Y

~ PARAINGENIERiA WEB

541
organiza~

El equipo IWeb 10 integra un grupo de miembros tecnicos y no tecnicos

dos en una forma que les brinda considerable autonomia y flexibilidad. Durante la ingenieria Web se requiere gesti6n del proyecto, pero las tareas correspondientes estan abreviadas y son considerablemente menos formales que las aplicadas en los proyectos convencionales de ingenieria del software. Muchos proyectos WebApp se subcontratan, pero existe una tendencia creciente hacia el desarrollo de WebApps en casa. La gesti6n del proyecto para cada enfoque difiere tanto en estrategia como en tacticas. Las mediciones de \a ingenierla Web estan en desarrollo, pero tienen eJ potencial para ofrecer una indicaci6n de la calidad de 1a WebApp, proporcionar una base para 1a estimaci6n del esfuerzo y permitir vislumbrar el exito de la webApp desde el punto de vista de los negocios.

IBRAOOI Bragg, T., "Worst Practices for e-Business Projects: We Have Met the Enemy and He Is Us!", Cutter rr Journal, voL 13, num. 4, abril de 2000, pp. 35-39. [CONOl] Constantine, L y L Lockwood, "User-Centered Engineering for Web Applications", en lEff Software, vol. 19, nUrn. 2, marzo-abril de 2002, pp. 42-50. [ElS02] Eisenberg, B., "How to Interpret Web Metrics", en ClickZ Todqy, marzo de 2002, disponible en http://www.dickz.com/sales/traffic/article.php/992351. IFUC02a] Fuccella, L 1. Pizzolato y J. Franks, "Finding Out What Users Want from your Web Site", IBM developerworks, 2002, http://www-l06.ibm.com/developerworks/libraryImoderator-guide/requirements.html. IFUC02bJ Fuccella, J. y J. Pizzolato, "Giving People What They Want: How to Involve Users in Site Design", IBM developerworlcs, 2002, http://www-l06.ibm.com/developerworks/ library/design-by-feedback/expectations.html. jGNA99] Gnado, C. y F. LarcheT, "A User-Centered Methodology for Complex and Customizable Web Applications Engineering", en Proc. First IC5E Workshop in Web Engineering, ACM, Los Angeles, mayo de 1999. [HAN99[ Hansen, S., Y. Deshpande y S. Murugesan, "A Skills Hierarchy for Web Information System Development", en Proc. First /CSE workshop on Web Engineering, ACM, Los Angeles, mayo de 1999. [INA02]lnan, H. y M. Kean, Measuring the Success of Your Web Site, Longman Publishing, 2002. IKIDOO) Kidder, T., The Soul of a New Machine, Back Bay Books (edici6n 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.htm!. {LOW9B] Lowe, D. y W. Hall (eds.)' Hypertext and the Web-An Engineering Approach, Wiley, 199B. {MEND\] Mendes, E., N. Mosley y S. COunsell, "Estimating DeSign and Authoring Effort", en IEEE Multimedia, enero-marzo de 2001, pp. SO-57. [NOM1] Nobles, R. y K. Grady, Web Site Ana~ and Reporting, Premier Press, 2001. [PAT02! Patton, S., "Web Metrics That Matter", en CIO, 15 de noviembre de 2002, disponible en http://www.computerworld.com/developmen ttopics/websitemgmtl story I O,IOB01,76002,oo.htm!. {PICO!] Pickering, c., "Building an Effective E-Profect Team", en E-Project Management AdviSOry Service, Cutter Consortium, vol. 2, nurn. 1, 2001, hllp:llwww.cutter.coml consortium. jPOW98] Powell, TA, Web Site Engineering, ~ntia: Hall, 1998

PARTE TRES

APLICAClOO DE LA INGENIRtA WEB

[RIGOI] Riggins, F. y S. Mitra, "A Framewor1c. for Developing E-Business Metrics Through funcOOnaJity Interaction", enero de 2001, se puede descargar de http://digitalenterprise org/metlics/metrics.html. ISTE02] Sterne, J., web Metrics: Proven Methods for Measuring Web Site Success, Wiley.. 2002. [TlL99] Tilley, S. y S. Huang, "On the Emergence of the Renaissance Software Engineer"' Proc, ISlICSE Workshop on Web Engineering, ACM, Los Angeles, mayo de 1999.

PROBLIMAS X PUMtOS A CQNIIPIRU

17 .1. ~En que ditiere la fonnulaci6n de la recopilaci6n de requisitos? ,En que ditiere la foll1'Wlacion del analisis de requisitos y del modelado de analisis?

17.2. En la seccion 17.1. 1 se encuentran tres preguntas fundamentales acerca de la fonnulacion. ~Existen algunas otras preguntas que se considere posibles de plantear en este punto" es as!. "cuales son y par que deberian hacerse?
17.3. En el contexte de la recopilacion de requisitos, (que es una "categoria de usuario"? Densik ejemplos de tres categorias de usuario para un vendedor de libros en linea. 17.4. Considerese el sitio de comercio electronico de HogarSeguro tratado en este capl ,Que mecanismo de comunicacion con el usuario podria usarse para obtener requisitos del tema y por que?

17.5. Con palabras propias, exponga como se "analiza" la informacion recopilada durante comunicad6n con el cliente y cllal es el resultado de esta actividad,
17.6. ,Que beneficios se pueden derivar de requerir el desarrollo de casas de uso como de la actividad de recopilaci6n de requisitoS?

I 7.7. Revisese la tabla presentada en la figura 17. 1. Agreguense Ires hileras mas que ulteriorrnerll=" distinguiran los proyectos tradicionales de los electr6nkos. 17.S, Con palabras propias, describa el papel del editor Web. 17.9. Revisense las caracteTisticas de los equipos de desarrollo agi! analizados en el capitulo adviene que una organizaci6n en equipo agil es apropiada para la (Web? ,Ellector realu.. algun cambio a 1a organizaci6n para el desarrollo de la WebApp?
~se

17.10. Describanse cinco riesgos asociados con la suocontrataci6n del desarrollo de WebApp" 17.11. Descrlbanse cinco riesgos asociados con el desarrollo en casa de las webApps. 17.12. Considerense las mediciones para el esfuerzo de ingenieTia Web tra tadas en la secc:.L

17.5.1 . Intentese desarrollar cinco 0 mas mediciones adicionales para una 0 mas categorias 17.13. La facilidad de navegadon a traves de un sitio Web es un indicadorimportante de la de la WebApp. Desarr6!lense dos 0 tres medici ones con las cualcs pudicra indicarse la facilidad navegacion. 17.14. Aprovechando una de las referencias sugeridas en la secci6n 17 .5.2, comente c6mo pueden aprovechar [as mediciones con valor en los negocios para apoyar la toma de decis pragmatica en cstos.

Los metodos para la formulaci6n de WcbApps y la recopilaci6n de requisitos se pueden adapl' de amilisis de mclodos similares para el software de aplicaci6n convencionaL Las olras I ras fccomendadas en los capitulos 7 y 8 contienen mucha informaci6n uti! para el inge Web.

543
FloT (Ieb Business Engmeermg, Addison-Wesley, 2(00) aborda el analis!s de negocios y las pre<x:upaciones reladonadas que permiten a1 mgeruero Web comprender melor las necesidades del c1iente. La racilidad de uso de la webApp es un concepto que subyace a mutha de la informaci6n definida como parte de la formulaciOn y la recopilaci6n de requisitos. Krug y Black (Don'/ Make me Think A Common sense Approach to Web UsabllifY, Que Publishing, 2000) con liene muchas directrices y ejemplos que pueden ayudar al ingeniero Web a traduclr los requisi lOS del usuario en una WebApp efectiva. La gestiOn de proyecto para los proye<:t05 [Web parte de muchos de los mlsmos princlplos y conceptos aplicables en proyectos de sonware convenctonal Sin embargo, agilidad es un lema
walla~ (Extreme Progrommmgfor web Pro~fS. Addison-wesley, 2003) describe c6mo se puede aprovechar el d~sarrollo agil para la IWeb y contiene analisis util~s d~ connictos de gesti6n d~ proyectos Sh~l rord y Remillard (Real Web Project Management, Addison-W~sl~y, 2003), O'COnnell (Haw to Run success.jill ProJ'Xts in Web 71me, Arthec House, 2000), Fr~idlein (Web Project Managemt!nt, Morgan Kaufman, 2000) y Gilbert (90 Da}5 /0 launch Internet ProJOCIS on 71me and on Budget, Wiley, 2000) tratan una amplia variedad de t~mas de g~sli6n de proyectos para IW~b Whit~head (Leading a SoJhmre Development 1hJm, Addison-Wesley, 2(01) presenta muchos lineamienlos utiles que pueden adaptar los equipos de ingenicria Web. Las tecnicas para usar mediciones Web en la lorna de decisiones empr~sariales se presen tan en libros como los de Sterne {STE02], Inan [INA02J, Nobles [NOB011 y Menasce y Almeida (Capacity Planning/or Web 5eNices: Metrics, Models and Methods, Prentice-Hall, 200 I) . L1s "peores practicas son consid~radas por Ferry y Ferry (77 SUre Fire Ways to KiJl a Software Project, iUniverse.com, 2000) En Internet esta disponibl~ una amplia variedad d~ fuentes de infonnaci6n acerca d~ fonnulad6n y planeaci6n para ingenlerla Web Una lista aclualizada de referencias en la world wide Web, relevante para la fonnulaci6n y la planead6n, se encuentra en el sitio Web de SEPA

http://_

.mhhe.com/ pressman.

CAPiTULO

18
CONCEPTOS
CLAVE

MODELADO DE ANALISIS PARA APLICACIONE S WEB

-~-

lit IItI'Itga<\OII .561 dlrelad" .560

primera vista, exisle una aparente contradicci6n cuando se considera modelado de antilisis denlro del con texte de la mgenierla Web. DesptJ/ de todo, se h a nol ad o (capitulo 16) que las WebApps tienen una in1ll'

diatez y una volalilidad contra ria al modelado detallado, ya sea en la etapa analisis 0 en la del disef'\o. Y 51se realiza algun tipo de modelado, 1 a fi losofia

iIW ....os .557 AIM .. . ..560

(un modelo de proceso adecuado para muchos proyectos de ingenierfa Web) giere que el modelado del analisis se minimice en favor del model ado de di . limitados. Franklin (FRA02] advierte esta situaci6n y escribe:

(aSO' dlno . .541

......

10 ....... ..546 ___

. . . .aciN 559

......
...... ......

. . . . . ....54.5

...... .CMt.......

.5S1

lOS s!lios web, por 10 general. son complejos y enonnemenle dinamicos Requieren fases de desarrollo cortas con la finalidad de tener lisla ('I produ<:to y cjecutarlo rapL damenle. Con frecuencia.los desarrol1adores van dlrttlOhacia la (ase de codJlkack sin comprender que esltin tratando de construir 0 c6mo quieren construirlo_ La cadlficaci6n respeclO del servidor con frecuencia se hace ad hoc, las tablas de bases de datos se agregan con forme se necesitan y la arquiteclura evoluciona en una fonna ~ veces no intenclonal. Pero a1guna ingenierla de sonware modelada y disciplinada 10grara que el proceso de desarrollo de sofiware sea mucho mas suave y a5egurara qLIf el sistema Web sea mAs sustenlable en lo futuro_

.-..

__. . - . 3M

fwdMII .. .sS7
w.t.... .....552

tEs posible tenerio en las dos (ormas? tSe puede haeer "alguna ingenierla software modelada y dlsciplinada" y todavia asl trabajar efectiva mente en mundo donde reinan la lnmediatez y la volatilidad? La respuesta es un calif do sl.

Laue ? EI on6lisis de uno potencial aplicoci6n Web 58 enfoco en Ires preguntaJ importontes: 11 eqtJe informoci6n 0 contenido $e p!'e5entor6 0 maoipulor6?; 21 ~ funciones realizorO el uSUClrio finol~; y 3) tque comportcmientos exhibir610 WebApp conforme presenle conleoido y reolice fvnciones? las respueslos 58 representan como porte de un modelo de analisis que aborea uno divenidod de representociooes UML ..Ou_ to hoce? los ingenieros Web, los desarroIlodores de contenido que no $00 tecnicos y los dienle$ porticipan eo 10 creoci6n del modelo de on6li5is.

..PM

que importante? A 10 largo de esII

$e

libra

ha resokodo 10 nec.esidad de compren-

der el problema antes de comenzor 0 resolverlo.

EI modelado de an6lisis es imporfronte no ~ permito que un equipo de ingenierio Web desorrolle un modelo concreto de reqoisik W~ (los caso~ cambian mvy frecuentemenle coma poro que eslo sea uno expec:totivo r8OIi51o), sina que, m65 bien, permite que un ingeniero Wf!.define aspectos fundomenk:lles del problemc:: elem.-ltos cuyo cambia no es probab'e (en fvtvro cercona). 1 di~ y 10 coo5trvcci6n Ie faciliton cvando 50 comprenden eI contenido, funci6n yel comportomiento fundomentales_

...

cAPiTuLo 18

).(()DELADQ OE ANAiJsIs PARA AJ'UCACIONES WB

545

IOn

onIooo WI 100 _ _ 1""cIao....... dol

inlllrac:ci6n. funa6n con_:oon. conIIInido, EI on6I de """"""" _mIka 100
Y
io_ac:ci6rI d.aib.

1M ....... EJ rnodeIoc de ardi-

cuencia. EI Gn6Ii.., de Ia mnftguroci6n identifico .I amb"tlhl operatioIo en .I cuol mid. 10

WobApp.

ycoIcobooucioneo de """""""'. EI_o,

bs ........ b6aicos ......., Ia Ivnci6n y Ia mnftgurociOn. doI_, Ia - " ' " y 100 , _ " ' - _ _ ...... 10110 dol "'" """"". S
Ioolvndonoo de
. . . . COl ...........' 101 produdc. ot.nidoe. del ~ cL dB c:mIiti! c:W... rtrVi1ar para

,Cu6I .... de an6Ii.i.

integron un conjunlo de diogramas y ...-0. UMl que describen .a eon...,ido, Ia in..

r:

0 ducto

.b.anhlat fl mocWodo

usucwio y Ia .....,.. de proc:8ICIIftieIdo que ocurre como CIOI'tI8""

co.;giIa. OOI .."b ycbles c:onsiseencio.

Un equipo de Ingenlerfa Web debe emprender el modelado de analisis cuando se cumplen la mayoria 0 todas las condiciones siguientes:
La webApp que se construira es grande 0 compleja,

El numero de clientes es grande. EI numero de ingenieros Web y otros colaboradores es grande. Las metas y los objetivos (determinados durante la formulaci6n) para la WebbApp afectaran la linea de referenda del negocio. EI exito de la webApp tendra una fuerte conexi6n con el del negoclo. 51 estas condiciones no estan presentes, 10 que Ie resta importancia al modelado de analisis, aprovechar la informaci6n obtenida durante la formulaci6n y la recopilaci6n de requisitos (capitu lo 17) siTVe como base para la cread6n de un modelo de disei'o para la WebApp. En tales circunstancias, tal vez se obtenga un modelado de analisis limitado, pero que terminara inc1uido en el disei'o.

El GmiJisis de requislloS para las webApps abarca Ires grandes tareas: (ormulaci6n, recopilaci6n de requisi tos,) y modelado de analisis. Durante la formulaci6n se identifican la motivacl6n (metas) y los ob}etivos basicos para la WebApp, y lambien se definen las categorlas de usuarios. Cuando comienza la recopilaci6n de requisitos se intensifica la comunicaci6n entre el equipo de ingenierfa Web y los accionislas (por ejemplo, clienles, usuarios finales). Los requisitos de conlenido y funcionales se enlislan y se desarrollan los escenarios de interacci6n (casos de usa) escritos desde el punta de vista del usuario final . La intenci6n es establecer una comprensi6n basica de por que se construi ra la WebApp, quien la usara y que problema) resalvera a sus usuarios.
1 En el capItulo 11 se ahordan con delalle Ja fonrwloloOrl Y Ja recopllaci6n de requislles

...

PARTE TRES

A.PIJCA06N

[)

U lNGlNIERiA WEB

'Los prilqlios de ingenieria !Kecco cit pIoneor antes de d6n Ikno!bgko previo; hlmbiM sobr.vivirOn a esta lraMi<iOn,"
WItts 11

,I.,

18.1.1

La jerarquia de usuario

Las categorias de usuarios finales que interactuartm con la WebApp se identifi como parte de las tareas de fonnulaci6n y de recopilaci6n de requisitos. En la ma~

ria de los casas, las categorfas de usuario son relativamente limitadas y no necesa
tan una representaci6n UML. Sin embargo, cuando creee el numero de categorlas usuario, a veces es aconsejable desalTollar una jerorquia de usuarlos, como se mues

tra en la figura 18.1, La ligura muestra a los usuarios del sitio de comercio electr

frONIU0S.
Es ~ idee (oos'
1M tI'kf /ffWtPo de
USLQIO.

O#flllltl

visi6n iIsImIMeo de

co de HogarSegurolnc.com tratada en los capitulos 16 y 17. Las categorias de usuario (can frecuencia l1amados aclores) que se muestran la figura 18,1 indican la funcionalidad que ofrecera la WebApp; ademas, sei'ialan necesidad de que se desarrollen casos de uso para cada usuario final (actor) an do en la jerarquia. En la misma figura, el usuarlo de HogarSeguroInc.com en parte superior de la jerarqula representa la clase (categoria) de usuario mas gen y se refina niveles abajo. Un visitante es un usuario que visita el sitio pero no se gistra. Tales usuarios usualmente buscan informaci6n general, comparan compras de alguna otra forma estan interesados en contenido 0 funcionalldad "gratuitos" usuario registrado dedica tiempo para ofrecer informaci6n y se Ie considera contacto (junto can otros datos demograficos que solicitan las entradas de los f( mularios) . Las subcategorlas para los usuarios registrados incluyen:

" pa/JIodM do "" rills YIIW1 morro de

Slim riJonkDJ m

~qtJfiJYll" ~ Q tJSIfllS I1lB

_do"'" .....

-.
Jerarquia de usuariooparo

roInc.com.

Usuorio de HogorSegurolnc.com

I
~
Vi$itonle

~
Uworio regislTodo

~
Personal

de 5efVicio
01 cHenle

Clien" existente

cAPiTuLo 18

MOOELADO DE ANJ.usis PARA. APUCACJONES WE!

.,

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 electr6nico) Cliente existente: un usuario que ya posee componentes de HogarSeguro y usa la webApp para 1) comprar componentes adicionales; 2) adqulrlr lnformaci6n de saporte tecnico; a 3) contactar con el saporte al c!iente. Los miembros del personal de servido al cUente san usuarios especiales que tambien pueden interactuar con el contenido y 1a funcionalidad de HogarSegu rolne.eom eonforme asisten a los dientes que han establecido contacto con el saporte al diente de HogorSeguro.

18.1.2 Desarrollo de casas de usa

Franklin [FRA011 se reliere a los casas de usa como "haces de funcionalidad". Esta descripci6n captura la esencia de esta Importante teenica de modelado de analisis.2 Los casas de usa se desarrollan para cada categoria de usuario descrita en la jerarquia de usuario. En el contexto de \a ingenieria Web, el casa de usa en sl mismo es relativamente informal : un parrafo narrativo que describe una interacci6n especiliea entre un usuario y la WebApp.J

~~

~""""'1Of < .ncl.y.o~

<,~~

""" ..... ~

~~!!t..p!"~_~'2"

----,

___ ~ __ .J

, , , , ,
I

CI;..... ~...., ..:::r

t -c.:::~~ iI :::::: :r-;.:;., ,--=~ ii

, ,

~---~---

-------- -~-- ,

, ,
2
3

'f,

,---------------------

Ilt~~

U.s tecnioCas para deS3TTo Uar casas de ~!oC ;,maIil....on '011 cklan~ en ,aplt u lo~ dlllcn orc!> de C!>IC
libra
(v~a n se

los capltulos 7 y 8)

Aunque es posible desarrollar descripciOIl6 mas rorma~de casas de U50, la necesidad de aglhdad

para la IWeb con frecuend a excluye este enfoque

...
La ligura 18.2 representa un diagrama UML de caso de usa para la categorla de usuario cHenle nuevo (ligura 18.1). cada 6valo en el diagrama representa un caso de usa que describe una interacci6n espedfica entre el cllente nuevo y 1a WebApp Por ejemplo, la primera interacci6n se describe con el caso de usa pec/ir acceso (~ in) a HogarSegurOlnc.com. No se requerirla mas de un solo parrafo para describir esta interacci6n comUn. La funcionalidad de las grandes webApp cy los casos de uso reievantes para ella. se anotan adentro de recuadros con lineas punteadas en la figura 18.2. TClles recur dros se canacen como Npaquetes" en UML y representan funcionalidad espedfica Se

advierten dos paquetes: personalizoci6n y comerdo e/ectr6nico.

Como ejemplo, considerese el paquete personafizaci6n de casos de usc, Un nlJe' va cliente debe describir el ambiente domestico en el cual se instalara HogarSegurr'" Para Jograrlo, cUente nuevo inicia los casos de uso describir plano de 10 coso, ~ donor componentes HogarSeguro y guardar configuraci6n. Considerense los siguimtes casos de usc preliminares escritos desde eJ punto de vista de un cUente nuevo
Caso de usa: descnbir plano de /a coso

f"_III

La WebApp fonnulara algunas preguntas generales acerca del ambienle en el cual se pia-

-, ..
w./lIo>, , 0/

nea instalar HogorSegUro nlimero de habitadones y su tamano. tipo de habitaci6n, nlimero de pisos. numero de puertas exteriores y ven tanas. La WebApp
permitir~

(tJivrmf 01(f "

construir un

plano de la casa aproximado al conjuntar formas delineadas de las habilaciones para 01da pisa. EI usuario ser~ capaz de nombrar al plano de la casa y guardarlo para una referenda futura (vease caso de usa: guardar con!lgurod6n).
Caso de U50: seieccionar componenles HogorSeguro

1i!iU(lSO, /os casas de

-~ ~ ...... "'"
~.monetI1

."""""' ,.,., """"''"' ""

-,..,.".,
., """" 8.5 del
""'" 8.

!ISO (Xeiminores

Enlonces la WebApp control. sensares.

recomenda r~

componenles de producto (por ejemplo: paneles

c~maras)

y otras caracteristicas (por ejempl0. funcionalidad basada ef'

IIIIis {1fCIII(I d

PC implementada en sofiware) para cada habitaci6n y la entrada exterior. Si el usuario solicita opciones. la WebApp las proporcionarti si existen, EI usuario obtendr~ informacKll' descriptiva y de precios para cada componente de producto La webApp crear~ y mostnr~

una factura de materiales confonne se seleccionen varios componentes. EI usuant

tambien podr~ nombrar la factura de materiales y guardarla para referenda futura (veastcasa de usa: guardar configuraci6nj.
Caso de uso: guardar configuraci6n
La webApp pennilir~ guardar los datos de personalizaci6n de moo~ que el usuario puedia

regresar desputs.

Podr~

guardar el plano de la casa y la factura de materiales Ilogo~

to que eligi6 para tl, Lograr esto requiere que el usuario proporcione un identiticador un

co para el plano de la casa y la factura de materiales, Tambien proporcionarti un. contrasena (password) de configurad6n especial que debe validarse antes de que pu~ tener accesa a la inrormad6n guardada.

CAPiTULO

METRICAS DE PROCESO Y PROYECTO

22

....77

a medicl6n pennite obtener una visi6n del proceso y el proyecto pues propordona un mecanismo para lograr una evaluacl6n objetiva, Lord Kelvin dijo una vez:

cuando puede mechr aquello de 10 que est! hablando y expresar}o en numeros sabe

...6n

.661

algo aeer,a de eUo, pero wando no puede medir, cuando no puede expresarlo en numeros, su conodmiento es escaso, deficiente: puede seT el comienl'o del conoclmlento, perc, en sus pensamlentos. apenas est! avanzado al ambito de la ciencia

.670

La comunidad de 1a ingenieria del software ha tomado en serio las palabras de lord Kelvin iMas no sin frustrac!6n y algo mas que un poco de controversial La medici6n se aplica al proceso de software con la finalidad de mejorarlo de manera continua La medici6n se utiliza a 10 largo de un proyecto de software como apoyo en la estimad6n, eJ control de caUdad, la valoracl6n de la productividad y el control del proyecto. Finalmente, la medicl6n la aplican los ingenieros de software como auxiliar en la evaluaci6n de la caUdad de los productos de trabajo y para apoyar la lorna de decisiones tActica confonne avanza un proyecto

......
666
. .674

(capitulo 15) En su gula ace rca de la medici6n de software, Park, Goethert y Florae [PAR96] apunlan las razones por las que se mide: I) para caracrenzor en un esfuerzo per comprender acerca 'de los procesos, productos, recursos y entomos. y para estableeer hneas base para comparaciones con evaluaciones futuras~ ; 2) para a'oluor"detenninando el estado can respecto a los planes"; 3) para predlXlf me-. diante "la comprensi6n de relaciones entre procesos y produetos y construir mo-

. . . . . . . . . . . ., los gestores de software onoli zan y eYOivan los m6tricos del software_ Con hecuenoo, los ingenieros de software ~opilon las

" . . . . . . importante? Si no ~ reoli:ron medlClOnet eI iUlcio s6Io w boso en evoluoci6n IUbjeIiya La medici6n permi\el de~to<:or los tend.nciaI yo sean buenas 0 molos) y hocer meio .aimDciOllft. y con el tiempo 50 puede Iogror

.......

.... dodera mejOfio, ..Co 61 ..... los pasos? 50 comienzo definien

unto
mdado

de medidos del proceso

".." ... .. , .. .. " ,.... 1 que

rn8d!das pol' 10 general se nonnoaupenodo metnc:as Ofientados allomoiio

puedan rec:opilarse con foci-

...

PARTE CUATRO

GES'l!6N DE PIIOYEClOS DE SOf"TW..o.m::

delos de dichas relaciones"; y 4) para mejorar a\ Hidentificar barricadas, causas rail: ineficiencias y otras oportunidades para mejorar \a calidad del producto y el deserr-

peno del proceso" .

La medici6n es una herramienta de gestoria. Si se lIeva a cabo adecuadam
proporciona visi6n al gestor del proyecto. Y, como resultado, apoya al gestor del p"" yecto y al equipo de software a tomar decisiones que conduciran a un proyecto
t05O.

.....,
"~ C&VE
1m mea del
prou5olilrllWliqloOo

Las mttricas del proceso se recopilan en el curso de todos los proyectos y durante lair
gos periodos. Su objetivo es proporcionar un canjunto de indicadores de proceso conduzcan a la mejora de los procesos de software de largo plaza. las merricas

proyecto

permiten que un gestor de proyecto de software I) valore el estado de

H

proyeclo en curso; 2) rastree los riesgas polenciales; 3) descubra las areas problell': antes de que se vuelvan Hcriticas , 4) ajuste el flujo de trabajo 0 las tareas, y 5) hie la habilidad del equipo del proyecto para conlrolar la calidad de los productos trabajo del software. Las medidas que recopila un equipo de proyecto y las que convierte en met . para emplearlas durante un proyecto tambien se pueden transmitir a quienes lie la responsabilidad de mejorar el proceso de software. Por esta raz6n, muchas de mismas metricas se usan tanto en el dominio del proceso como en el del proyed'

Do>,."..10
00jetiw lIS meloltul IlOC8S0 an 51. (on
~1IO.I!fKII, 1M m6!rir:as

doI.-

conllbJyeiJ m

desorrolo de m6tricas del proceso.

22.1.1 M atricas del proce so y m a jora del proceso de software

La (mica forma radonal de mejorar cualquier proceso es medir sus atributos esped
ficas, desarrollar un conjunto de metricas significativas can base en dichos aIr! y luego empiear las metricas para ofrecer indicadores que conducirtm a una estratL. gia de mejora. Pero antes de estudiar las metricas de software y su impacto en la me jora del proceso de software es importanle destacar que el proceso s610 es uno varias H factares controlables en la mejora de la caUdad del software y el desempeii-' organizacional H IPAU94]. En la figura 22.1 eJ proceso se asienla en el centro de un Iriangulo que con Ires factores con una profunda influenda en Ja calidad del software y el desempei\'f organizacional. La destreza y la motivaci6n del personal [BOE8 11 se muestran c

CAPITuLo 22

MrnuCAS DE PROCISO Y PIIOYfCTO

66'

Producto

Corocterf$tiCQ$ del cliente

_.10
Entorno de desarrollo

Condiciones del negocio

Personal

Tecnologia

el factor individual mas influyente en la caUdad y el desempeno. La complejidad del producto puede tener un impacto sustancial sobre la caJidad y el desempeno del equipo. La tecnologia (es decir, los metodos y herramientas de la ingenieria del software) que reside en el proceso tambien tiene un impacto. Ademas, el triangulo de proceso existe dentro de un drculo de condiciones ambientales que incluyen el entomo de desarrollo (por ejemplo, herramientas CASE), condiciones del negocio (por ejemplo, fechas limite, reglas comercia[es) y caracteristicas del cliente (por ejemplo, facilidad de comunicaci6n y colaboraci6n).
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce

un conjunto de metricas basadas en [os 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 planificaci6n consumido, concordancia con la planificaci6n y otras medidas. Tambien se deducen metricas de proceso al medir las caracterfsticas de tareas especificas de ingenieria del software. Por ejemplo, se mide el esfuerzo y el tiempo utilizados al realizar las actividades genericas de la ingenierfa del software descritas en el capitulo 2.

Grady [GRA92] argumenta que existen usos "privados y publicos" para diferentes tipos de datos de proceso. Como es natural que los ingenieros de software especiales sean sensibles al uso de las met:ricas recopiladas sobre una base particular, di-

...
IItr. 'HIS prlvatlos y

PARTE CUATRO GESnN DE ~ DE!lCJf'TW'ARE

chos datos deben ser privados para el individuo y funci onar como un indicador sOlo para

el. Los ejemplos de memcas privadas induyen Indices de defecto por individuo

indices de defeclo por componente de software y erfOTes encontrados durante el de-

pilWicOJ d.la, Mitrieas de

Hhwa,,?

sarrollo.
La filosofia de ~datos de proceso privados" se ajusta bien al enfoque de proceso per

sanal del software (capitulo 2) que propone Humphrey rHUM95] . Humphrey reconoct

que la mejora en el proceso de software puede y debe comenzar en el nlvel individua.

Los datos de proceso privados pueden funcionar como un importante promotor par.I que et tT abaja individual del ingeniero de software mejore. Algunas metricas de praceso son privadas para el equipo del proyecto de software, perc publlcas para lodos los miembros del equipo. Los ejemplos incluyen defeetos que reportan las grandes fundones de sonware (las cuales desarrollaron variol profeslonales), errores detectados durante las revisiones tecnicas formales y lineas de c6digo 0 puntos de funci6n por m6dulo 0 fund6n.' Dichos datos los revisa d equipo para descubrir indicadores que mejoren su desempeno. Las metri cas publicas por 10 general asim ilan in formad 6n que originalmente era privada para los individuos y equipos. Los indices de defecto al nivel del proyectu (que no se atribuyen por ningun motivo a un individuol, esfuerzo, planificaci6n y datos reladonados se recopilan y evaluan con la finalid ad de descubrir indicadores QUI: pueden mejorar eJ desempeno del proceso organizadonal. Las metricas del proceso de sonware ofrecen beneficios significativos conforrtk una organizad6n trabaja en mejorar su grad o global de madurez del proceso. Sa> embargo, como todas las metricas. estas pueden emplearse mal y crear mas probkmas de los que soludonan. Grady {GRA92] sugiere un "conjunto de reglas de eUquea para las metricas de son ware", adecuado tanto para gestores como para profesiona les confonne instituyen un programa de metricas del proceso: Aplique sentido comun y sensibilidad organizativa cuando interprete datos metricos. Ofrezca retroalimentad6n regular a los individuos y equipos que recopilan medidas y metricas. No utilice las metricas para evaluar a los individuos. Trabaje can los profesionales y equipos para establecer metas c1aras y las ~ tri cas que se emptearan para conseguirlas. Nunca use metricas para amenazar a los individuos 0 equipos. Los datos melricos que indican una area problema no deben considerarse "negat ivos~. Dichos datos s61 0 son un indicador de la mejora del proceso. No se obsesione con una sola metrica y excluya otras metricas importantes.

,.........
It

d.btn aplkar

fl(opiIaI . .trices

tit Rftwor.?

I lAS met:ricas de lineas de cOdigo y punto de funci6n se estudian en las secciones 22.1.1 y 22.2.2

c APiTuLo 22

MtiRrcAS D PROCESO Y PSIOff.ClO

667

Conforme una organizaci6n se sienle mas c6moda con la recopilaci6n y el empleo de las metricas de procesa, la deducci6n de indicadores simples da la paula para un enfoque mas riguroso lIamado meJOffl estodislica del proceso de software (MEPS). En esencia, el MEPS aplica el anAlisis de falla de software para recopilar informaci6n acerca de lodos los errores y defectos1 que se encuentran al desarrollar y utilizar una aplicaci6n, sistema 0 producto.

22.1 .2 Meb1cas del proyecto

A diferencia de las metricas del proceso de software que se ulilizan con prop6sitos estrategicos, las metricas del proyecto de software son tActicas. Es decir, un gerente de proyecto y un equipo de software emplean las metricas del proyecto y los indicadores que se deducen de elias para adaptar el f1ujo de trabajo del proyecto y las actividades teenicas. La primera aplicaci6n de las metricas del proyecto en la mayona de los proyectos de software ocurre durante la estimaci6n. Las metricas recopiladas de los proyectos previos se aprovechan como base desde la cual se reali zan 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 planificaci6n del proyecto). EI gestor del proyeclo emplea dichos datos para supervisar y controlar el progreso. Mientras comienza el trabajo tecnicO, las Olras metricas del proyecto comienzan a tener significado. Se miden los indices de producci6n representados en terminos de modelos creados, horas de revisi6n, puntos de funci6n y lineas fuente entregadas. AdemAs, se les da seguimiento a los errores descubiertos durante cada tarea de ingenierla del software. Conforme el software evoluciona desde los requisitos hasta el diseno, se recopilan melricas tecnicas para valorar la calidad del diseno y mejorar los indicadores que influiran en e\ enfoque que se adopte para la generaci6n y prueba del c6digo. La finalidad de las metricas del proyecto es doble. Primero. se empiean para minimizar 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 sabre una base actual y. cuando es necesario. modificar el enfoque tecnico para mejorar la caUdad. Conforme la caUdad mejora los defectos se min imizan , y mientras esto sucede tambien se reduce fa cantidad de reelaboraci6n requerida durante el proyecto. Esto conduce a una reducci6n en el costo global del proyecto.

En este !ibro, un error se define como algun fallo en un producto de trabajo de ingenier!a del soft ware que se descubre antes de que et software se entregue al usuario final Un ck:fecro es un fallo que se descubre desputs de Ia entrega at usuano ftn&I se ~ advertir que otros no haeen esta dislinciOn En el capitulo 26 se presenta un mayor ~

...

PARTE CUATRO GESTI6N DE PROYB::TOS DE!a1WAR2

H.,I , . .
_

"'Ite.... Doue Miller ...... cW 41q1Jipo de inge

......... ~yVmodR~yJo.

=~

b,"'_._.

.......... La oficino de Doug cit inicior eI prOf'IdO de

diendo_
loy

...... -.. '" '_Ian.. ~I0"""

Jamie: P.ro tiompo

NUnieron un conil,lllio de

fIIro _ ........ t.ndrOn ~ def;nir W$

Jc.nie: No, pero._ _ j<M ....................It deben llI\Ifli,. en 1'10 . . . . c:fntcDo

ITIOt WI

10 cat;docI

dad ...

__ c_ ",,". "' .., loti.......

es 'liiOCeIICIiio.

~_:",~.~~",,~~:a.~~:~
.\eO

c;idod.

. . _. . . .
algunos han.
morio tiempo

~.::===

Ja_(_~_

. ."""'_

po pride ... gunes definirernQ5

En el capitulo 15 se indic6 que \a medici6n de software se clasifica en dos cat~ rias: I) medidas direclas del proceso de software (por ejemplo, casto y esfuerzo api. cados) y del producto (por ejemplo, lineas de c6digo ILDq producidas, rapidez cit:: ejecuci6n y defectos reportados a 10 largo de cierto periodo establecido) y 2) mat. das indirectas del producto que incluyen funcionalidad, calidad, complejidad, eficien. cia, confiabilidad, facilidad de mantenimiento y muchas atras "ha bilidades~ tratadib en el capitulo 15.

C APITuLo 22

Mf;m!CAS DE PROCESO Y PROYECTO

66.

Las metricas del proyecto se consolidan con el fin de crear metricas del proceso que sean publicas para la organizaci6n de software como un todo. Pero, tc6mo combina una organizaci6n las metricas provenientes de diferentes individuos a proyectos? Can fines ilustrativos, considerese 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 cambinan para desarrollar medidas de equipo. El equipo A encontr6 342 errores durante el proceso del software previo allanzamiento. El equipo B encontr6 184 errores. Si todas las demas cosas se mantienen iguales, lque equipo es mas eficiente al descubrir errores a 10 largo del proceso? Puesto que no se canocen ni el tamano ni la complejidad de los proyectos, no se puede responder esta pregunta. Sin embargo, si las mediciones se normalizan, es posible crear metricas de software que posibililen la comparaci6n a promedios organizacionales mas amplios. De esta forma, las metricas orientadas tanto al tamano como a la funci6n estan nonnalizadas.

22.2.1 Metrtcas orientadas al tamaiio

Las metricas del software orientadas al tamano preceden de la normalizaci6n de las medidas de calidad 0 productividad considerando el tamano del software que se ha producido. Si una organizaci6n de software mantiene registros simples es factible crear una tabla de medidas orientadas al tamano, 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 anos 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 lineas de c6digo se desarrollaron con 24 personas-mes de esfuerzo a un costa de 168 000 dolares. Se debe notar que el esfuerzo y eJ costa registrados en la tabla representan todas las actividades de ingenieria del software (analisis, diseno, c6digo y pruebaJ, no s610 codificaci6n. Informaci6n adicional del proyecto alfa indica que se desarrollaron 365 paginas de documentacian, se registraron 134 errores antes de que el software fuese liberado y se encontraron 29 defectos despues de la liberaci6n al cliente denlro del primer ana de operaci6n. Tres personas trabajaron en el desarrollo del software para el proyecto alfa EI desarrollo de metricas que se asimilen can metricas similares procedentes de otros proyectos requiere elegir lineas de c6djgo como valor de normalizacian. A partir de los datos rudimentarios de la tabla se desarrolla un conjunto de metricas simples orientadas al tamano para cada proyecto: errores por KLDC (miles de lineas de c6digo), defectos par KLDC, costa por KLOC, paginas de documentacian par KLOC. Ademas, se pueden ca1cular otras metricas interesantes: errores por persona-mes, KLOC par persona-mes, costa por pagina de documentaci6n.

670

PARTE CUATRO GEST10N DE PIIO'YlrfOS DE SOFTWARE

MiIrl=
orlentadas a1

.....,...

,
IDe
12 100 27200 20200

tamaiio.

... .....

gommo

2A 62 3

-. -- .
,

.
3 5 6

.... "
'68

....

DIll It ..

345 1 22.

, 050

321 256

'3<1

,. ...

.......
~

"~.f>.

C&VE

-........
""""",",,,
'

....... "" ..........

las m.!\ri(os orienlO6Js

IKImI cit su .".jdez y

Las metricas orientadas a1 (amana no se aceptan universalmente como la meJOl' forma de medir el proceso del software UON861 . La mayor parte de la controvers&.; gira en tome aJ uso de IIneasde c6digo como medida clave. Los partidariosde la me dida LDC afirman que estas son un "artefacto" de todos los proyectos de desarr de software que pueden faciimente contarse, que muchas modelos de estlmaci6n dL software existenles usan LDC 0 KLDC como entrada clave, y que ya existe un grar cuerpo de bibliografia y datos pubJicados para LOC. Por atra parte, los detractores argumentan que las medidas LDC dependen dellenguaje de programaci6n, que, ruando se considera la productividad, castigan los programas bien disenados, pero mo... cortos, que no pueden amoldar con facilidad lenguajes que no provienen del proceso y cuyo empleo en la estimaci6n requiere un nivel de detalle que serla difkil de k.. grar les decir. el planificador debe estimar que las LlJC se produciran mucho antes de que el analisis y el diseno se hayan completado).

22.2.2 Mebicas orientodas 0 10 func16n

Las metricas de software orientadas a la funci6n emplean como un valor de nOIlJalizaci6n una medida de la funcionalidad que entrega la aplicaci6n. La metrica orientada a la funci6n utilizada can mayor amplitud es el punta dejunci6n (PF). El caleu10 del punto de funci6n se basa c!n caracterlsticas del dominio de informaci6n y Ia complejidad del software. La medmica del calculo del PF se trat6 en el capitulo 1S EI punto de funci6n. al igual que la medida LlJC, es controversial_ Los partidanc. afirman que el PF es independiente dellenguaje de programaci6n. caracteristica que 10 hace ideal para aplicaciones que utilizan lenguajes convencionales y no procedimentales. y que se basa en datos que es mas probable que se conozcan tempranc. en la evoluci6n de un proyecto, 10 que hace al PF mas atractivo como enfoque de es-

Vcase la secci6n 15.3.1 para una detallada e)(poslcl6n del calrulo de PF

cAPiTuLo 22

MtnuCAS DE ~ Y PROhL'tO

671

timad6n, Los detractores afirman que el metodo requiere derta "preslidigitaci6n" en cuanto a que el calculo se basa en datos subjetivos mas que objetivos, que el conteo del dominio de informaci6n (y otras dimensiones) puede ser dificil de recopilar despues del hecho, y que el PF no tiene significado fisico directo: es s6lo un nUmero.

22.2.3 ReconclliaciOn de las meb'1cas LDC y PF

La Telad6n entre IIneas de c6digo y puntos de funci6n depende del lenguaje de programad6n en que se implementan el software y la caJidad del diseno. Varios estudios han intentado reladonar las medidas de PF y LOC. Por ejemplo Albrecth y Gaffney [ALB83]:
La tesis de este trabajo es que la cantidad de funci6n que se ofrecera por medio de la apli caci6n (programa) se puede estimar a partir de pormenorizar los grandes componentes' de datos que se emplearan 0 proporcionaran. Mas alin, esta estimaci6n de la funci6n debe estar correlacionada tanto con la cantidad de ux: que se desarrollara como con el esfuerzo de desarrollo necesario,

La tabla 5 siguiente [QSM02] ofrece estimaciones burdas del numero promedio de li-

neas de c6digo que se requieren para construir un punta de funci6n en varios lenguajes de programad6n: Una revisi6n de estos datos indica que una LDC de C++ proporciona aproximadamente 2.4 veces la "fundonalidad" (en promedio) de una LDC de C. Mas atm. una LDC de Smalltalk propordona al menos cuatro veces la fundonalidad de una LDC de un lenguaje de programad6n convendonal como Ada, COBOL a C. La utilizaci6n de la informaci6n contenida en la tabla permite "tamar como contrafuego" UON98] el soft ware existente para estimar eJ numero de puntos de funcian, una vez que se conoz ca el numero total de enunciados dellenguaje de programaci6n. se ha encontrado que las metricas basadas en puntos de funci6n y LDC son indicadoras relativamente precisos del esfuerzo y el costa del desarrollo de software. Sin embargo. emplear LDC y PF en la estimad6n (capitulo 23) requiere establecer una linea de referenda hist6rica de informaci6n. En contexto del proceso y las metricas del proyecto. la preocupaci6n principal la generan la productividad y la calidad: medidas de [a "salida" de desarrollo de sol1ware como funci6n del esfuerzo y el tiempo aplicados y medidas de la "aptitud para el uso" de los produclos de tTabajo obtenidos Respecto a prop6sitos de mejora del proceso y planeaci6n del proyecto, el interes es hist6rico .;.Cu.:il fue la productividad

4 Es importanle notar que "pormenorizar los grandes componcnles" se puede lnterpretar en "arias form as. Los ingenieros de software que trabafan I"Il un enlomo de desarrollo orientado a objclos usan eI nilmem de clases u objelos comoel tam.II\odr mrlrica dominante. Una organizaci6n de man lenimienlo puede considerar ellamanodrl pmyt"C\On"l temllnos de! numem de pedidos de cambio~ de ingenieria (capitulo 27). Una organizaoOn $ISlemaS de mformacion quiza "ea el nilmcro de procesos comerciales quc afecla una aplicadOn 5 Utilizado con permiso de Quantitative Soft'ol.'ate ~ Iwww.qsmcoml.copyright2002

.72

PARTE CUATRO GiSrI6N DE AIOYB:'TOS DE sonwARf:

de desarrollo del software en los proyectos pasados? iCual Cue 1a calidad del software que se produjo? teoma se pueden extrapolar a1 presente la productividad y 1a calidad pasadas? ,Como puede ayudar a mejorar el proceso y planificar nuevas proyectos
con mayor precisi6n?

Lenguaj_ de programociOn
PromMlio
Acceu

lDC pot' punto de IunciOn

Ado
APS

""P6Q
Ensambloda
C C++
Clipper

35 154 86 62 337 162

66

PMcIaaftO 38
83
315

1010
15 104 20 32 91 33 29
27

Allo

47 205 184
127

38
77

COBOl Cool Gen/IEF

Culprit

38
51

100 53 39 77 31 34 42 35 52 31 31 53 63 123
22 27 BI

14
10

6'14 704 178 70 400

180

1l6o.. W
Easylne..." 1

'"",,,7

''''''' FORTRAN
',"",0
Idool IEf /CooiGen
Inkllml)<,

52 33 46 43

25

31 32
25

41 63
56

32
66

J<wo JovoScfipt

38 42 63
58

JCl JSP
10'" Nooe>
NIonhs

91 59
21
71

34 10 24 77 42 26 15
22

35 203 180 57 75
ISO
25

2SO

Mo""",
Naturol

"'ode
Perl
Pl/I

PeopieSoh

118 60 30 33 60 7B
32

16
22

52

35 32 67
31

4 30
22 II

245 141 217 40 263 105 155 49 55 110 158

POYo'efbuilder

.00
RPG II/III

SAS
Smollrolk SGl!
VBSaipl36 Visual BaSIC

67 61 40 26 40 34 47

49 41 19 37
27

24 33 10 7
SO

42

16

CAPInn.o 22

MtmlCAS DE l'ROCISO Y JiiM)rOCIO

6"

22.2.4 Metrlcas orientadas a objetos

las metricas de proyectos de software convencionales fLOC 0 PF) se aplican en la estimaci6n de proyectos de software orientados a objetos. Sin embargo. estas metricas no proporcionan suficiente granularidad para [a planificaci6n y los ajustes de esfuerzo que se requieren conforme se itera a 10 largo de un praceso evolutivo 0 incremental. LDrenz y Kidd rLOR94J sugieren el siguienle conjunlo de metricas para proyectos 00: Numero de guiones de escenarlo. Un gui6n de escenario (analogo a los casos de uso estudiados a traves de las partes 2 y 3 de este libro) es una secuencia detalIada de pasos que describen la interacci6n entre el usuario y la aplicaci6n. EI numero de guiones de escenario estA directamente correlacionada can el tamano de la aplicaci6n yean el numero de casos de prueba que se deben desarrollar para ejercitar el sistema una vez que se construya. N(unero de clases clave. las clases clave son los "componentes enormemente independientes" ILOR94J definidos con antelaci6n en el analisis orientado a objetos (capitulo 8) .6 PUesto que las clases dave son centrales respecta del dominio del problema, su numera indica la cantidad de esfuerzo necesario para desarrollar el software. Tambien indican la potencial cantidad de reutilizaci6n que se aplicara durante el desarrollo del sistema. N6mero de c1ases de apoyo. las clases de apayo son necesarias en la implemenlaci6n del sistema, pero no estan inmediatamente relacionadas con el dominio del problema . Los ejemplos pueden ser las clases IU, los accesos a bases de datos y las clases de manipulaci6n y las de ca1culo. Ademas, las dases de apoyo se pueden desarrollar para cada una de las dases clave. E1 numero de clases de apoyo es un indicio de la cantidad de esfuerzo indispensable para desarrollar el software. asl como un indicio de la potencial cantidad de reutili zaci6n que se aplicara durante el desarrollo del sistema. N(unero promedio de clases de apoy o por clase clave . En general, las dases clave se conacen en etapas iniciales del proyeCIO. las dases de apoyo se definen a 10 largo del curso de este. 5i se conociese el numero promedio de clases de apoya por clase clave respecto de un dominio de problema dado, la estimaci6n (con base en el numero total de clases) se simplificaria mucha. Lorenz y Kidd sugieren que las aplicaciones can una GUI tienen entre dos y tres veces el numero de clases de apoyo que las clases clave. Las aplicaciones sin GUI tienen entre una y dos veces el numera de clases de apoyo que las clases clave N6mero de subsistemas. Un subsistcmo es un agregada de clases que apoyan una funci6n visible para el usuario final de un sistema Una vez identificadas los sub-

6 En la parte 2 de este !ibro a las clases clave se Irs rdInO como cIclses

*"

amiJisjs

.,.

PARTE CUATRO GESTl6N DE PROYECTC6 DEU'TWARE

sistemas es mas fad] extender una planificaci6n razQnable en la eual se haya hecJy

la partici6n del tTabaja entre el equipo del proyecto. La utilizaci6n eficiente en un entoma de lngenieria de software orientada a obtelos requiere recopilar me-Incas similares a las anotadas IIneas arriba, junto con medidas del proyecto tales como esfuerzo gastado, errores y defectos descubiertos modelos 0 paginas de documentaci6n producidos. Conform e la base de datos c (despues de comp!etados varios proyectos), las relaciones entre medidas orienta
a ohjeles y medidas de proyecto proporcionaran metricas que auxiHen en la estinv. ci6n del proyecto.

22.2.5 Metricas ortentadas a casos de uso

Parecerfa razonable aplicar el caso de uso? como una medida de normalizaci6n milar a la LDC a PF. Como el PF, el caso de uso se define en etapas tempranas proceso de software, 10 que permile emplearlo en la estimad6n antes de iniciar las ac Uvidades significativas de modelado y construcd6n. Los casas de usa describen menos indirectamente) fundones y caracterislicas visibles al usuario que son requa... las basicos para un sislema. El caso de usa es independiente del lenguaje de progn. maci6n. Ademas, el numero de casas de usa es direelamente proporeional al tarnaL de la apliead6n en LDC, asi como al numero de casas de prueba que tendran que senarse para ejerdlar complelamente la aplicaci6n. Puesto que los casos de uso pueden crearse can gradas de abstracci6n amp! _ mente direrentes, no exisle lamano estandar para ellos. Sin una medida estandar aplicaci6n como medida de normalizad6n (par ejemplo, esfuerzo empleado por so de uso) es sospeehosa. Aunque varias investigadores (por ejemplo, ISMI99]) inlenlada obtener metricas de caso de uso, todavia queda mucho tTabaja por haa..

22.2.6 Meuicas de proyectos de lngenieria Web

El objetivo de lodos los proyeelos de ingenierfa Web (parte 3 de este libro) es cor trui T una aplieaei6n Web (WebApp) que propocione una combinaci6n de conte y funeionalidad al usuario final. Las medidas y metricas que se emplean en las PI' yeetos de ingenierla de software Iradicionales son dil1ciles de Iradueir direetamer a la WebApp. Incluso. una organizaci6n de ingenierla Web debe desarrollar una se de datos que Ie permila valorar su productividad y calidad intemas a 10 largo varias proyeclos. Entre las medidas que se pueden reeopilar estan: Numero de paginas Web estAticas. Las pilginas Web de contenido estatico decir. el usuario I1nal no eonlro1a el eontenido desplegado en la pagina) son [as eomunes de lodas las caracterlsticas WebApp. Eslas paginas representan una c plejidad relativa baja y por 10 general requieren menos esfuerzo al construirlas

Los

casas de usa se estudJan iI traves de las partes 2 y 3 de este libro.

cAPiTuLo 22

MtrRiCAS DE PIIOCESO Y PROYIC1O

las paginas dinamlcas. Esla medida propordona un indicio del lamano global de la apJieaci6n y eJ esfuerzo que se requiere para desarrollarla. Numero de pagtnas web dinamIcas. Las paginas Web de eontenido dlnamico (es dedr, las acdones del usuario final generan eontenido personalizado que se despliega en la pagina) son eseneiales en todas las aplleadones de camerda electr6nlco. motores de b\lsqueda, aplieadanes finanderas y muchas atras categarias de WebApp. Eslas paginas representan una mayor complejidad relativa y requieren mas esfuerzo al construirlas que las paginas estaticas. Esta medida proporciana un indicia del tamano global de la aplicaci6n y el esfuerza requerido para desarrollarla. Nfunero de vinculO$ lntemos de pagina. Los vlneulos inlemos de pagina son punteros que ofrecen un hipervinculo hacia alguna otra pagina Web dentro de la WebApp. Esta medida proporclona un indicia del grado de acaplamienta arquitect6nica denlro de la WebApp. Conforme aumenta el numero de vlnculas de la pagina. tambien 1 0 hace el esfuerza empleada en e! disena y construcci6n de la navegaci6n . N6mero de objetos de datos persistentes. Una webApp puede tener aeee50 a uno a mas abjetos de datos persistentes (por ejemplo. una base de datos a archivo de datos). Conforme el numero de objetos de datos persistentes erece, tambien 10 haee la eomplejidad de la webApp y el esfuerzo para implemenlarla aumenta proporcionalmente. Numero de sistemas extemos en interfaz. Con freeuencia las WebApps deben haeer interfaz con aplieaeiones comerciales "de euarto trasero". Conforme crece el requisito para haeer Interfaz, la complejidad del sistema y el esfuerzo de desarrollo tambien aumentan. Nfunero de objetos de contenido estatico. Los objetos de cantenido estatieo abarcan infarmaei6n estatiea basada en texlo, grafiea, video, animad6n y audio que se ineorporan denlro de la webApp. En una pagina Web sencilla pueden apareeer multiples objetos de eontenido eslatico. Niunero de objetos de contenido dinamlco. Los objelos de contenido dinamico se generan con base en las aeciones del usuarlo final y abarcan infarmaci6n generada intemamente basada en texto, grafica, video, animad6n y audio que se incorporan denlro de la WebApp. En una pagina Web sencilla pueden aparecer multiples abjetos de eantenido dinamico. Nfunero de (undones ejecutables. Una funcl6n ejecutable (por ejemplo. un gui6n 0 apple!) ofreee eierto servicio eomputaclonal al usuario final. Conforme aumenta el numero de funcianes ejecutables, tambien aumenlan los esfuerzos de modelado y eonstrueci6n. cada una de estas medidas se puede detenninar en una etapa relativamente temprana del prcx:eso de ingenieria Web. Por ejempla, es posible definir una melr'ica que reOeJe el grado de personalizaci6n de usuario final que se requiere para la WebApp y correlacianarla can el esfuerza

.7.
empleado en el proyecto de [Web 0 los errores descubiertos conforme se llevan a cabo revisiones y pruebas. Para lograr esto, se define

Nsp - numero de pagi nas Web estaticas N dp - numero de paginas Web dinamicas
Entonces, Indice de personalizaci6n, C '"' NrJpi(Ndp + NspJ

El valor de C varia de 0 a 1. Confonne C creee, el nivel de personaJizaci6n de la WebApp se vuelve un conflicto tecnico significativo. Es posible calcular y correlacionar metricas similares de aplicaciones web coo medidas del proyecta, tales como el esfuerzo empleado, los errores y defectos descubiertos y los modelos 0 paginas de documentaci6n producidos. Conforme la base: de datos crece jdespues de que varios proyectos se han completado). las relaciones entre las medidas WebApp y las medidas del proyecto proporclonaran indicadores que auxllien en la eslimaci6n del proyecto.

MetJ1cas del proyecto Y II proceso

ci6n, evolvociOn y reporte de medidos Y metri-

IIIiiiiiiII Objetivo: Ayudor en Ia definiciOn, recopilacas de software.

MecGnk a : Code herrom.,10 YOrio en cuonlo 0 w oplicoci6n, pero Iodos ohcen meconi$ll1OS para reoopilar y eYOIuor dotos que condv:tCOll 01 c;6kvlo de metrico$ de
ooftwo~.

PSIYllnsight, deKlrroilodo por Practical Soflwore and ~. tems Meowremenl (www.psmsc.com). ouxilio en Ia creoci6n y wbsiguienle on6li:lis de una bose de doIos de medici6n del proyedo.
SUM boI set, clMorroIIado pew QSM (www.<pm.comJ, proporciono un completo c;onjuntro de mlrIricos Yheno-

mienlos de estimaci6n.

Herramientas representotivas'
Functiofl Point WORKBENCH, de50rroUodo par Chariwotek 1WW'W.choriwotek.com.ou), ofrece uno omplio YCr riedod de metricas orienlodos 0 PF.

SPR tool $f)t, de50 rrollodo por Soltwore Productivily Re{WW'W.:!pI".com), ofreee uno colecci6n detollodo de herromienlos orientodo$ 0 PF.

$eOre.

Me/ricCen/e(, desan-oIloda par Dimibutive Software

T~a,

jwww.distribvtive.com). soporto recopilociOn outomati' zodo de dolo$, on61ilis, formoteo de gr6ficos, genero' ci6n de reportes y alros toreos de medici6n .

de5Ol"l'O!1odo par Predicate logic, Inc. { _ predicole.com), as uno wile de hemJmienkl$ paro gastionor reoopiloci60 de metricO$ y reportrM.

La meta primordial de la ingenierla del software es producir un Sistema. aplicaci

o producto de alta calidad dentro de un marco temporal que satisfaga una necesidal.

8 Las herramientas anotadas aqul son una muestra de esta categona En la mayoria de 105 casos nombres de las mismas son marcas registradas par sus respectivos desarrolladores.

cAPiTuLo 22

MtnncAs DE PIIOCISOT ...."OCtO

671

del mercado. Ellogro de esta meta requiere que los ingenieros de software apliquen metodos eficaces acoplados con herramientas modemas dentro del contexto de un proceso de software maduro. Ademas. un buen ingeniero de software (y los buenos gestores de ingenierla del software) debe medir si se lograra la alta calidad. Las metricas privadas reunidas JX>r los ingenieros de software individuales se asimilan con los resultados ofrecidos en el ambito del proyecto. Aunque se pueden reunir muchas medidas de calidad. el impulso primario en el ambito del proyecto es medir los errores y defectos. Las metricas derivadas de estas medidas proporcionan un indicio de la efectividad de la garantia de la caJidad del software y de las actividades de conlrol tanto de los individuos como del grupa. Las metricas como los errores en el producto de trabajo (por ejemplo. requisitos o diseno) por punlo de funci6n. errores descubiertos por hora de revtsi6n. y los errores descubiertos por hora de prueba ofrecen una visi6n de la eficacla de cada una de las actlvidades implicadas en la metrica. Los datos de error tambien se pueden emplear en el calculo de la eficacia en la efiminaci6n de defectos (EED) para cada actividad del marco de trabajo del proceso. La EED se estudia en la secci6n 22.3.2.

22.3.1 Medlclan de la calIdad

Aunque existen muchas medidas de la calidad del software.' la correcci6n. la facili dad de mantenimiento, la integridad y la faclHdad de uso ofrecen indicadores utiles para el equipo del proyecto. Gilb [GIL88[ sugiere definiciones y mediciones para cada una de elias. CorrecciOn. Un programa debe operar correctamente a proporcionara poco valor para sus usuarios. La correcci6n es el grado en que eJ software desempena la fun ci6n para la que fue creado. La medida mas comun para la correcci6n es defectos por KLDC, donde un defecto se define como una falta comprobada de concordancia con los requisitos. Cuando se considera la caUdad global de un producto de software, los defectos son los problemas que reporta un usuario del programa despues de que este se liber6 para el uso general. Para los prop6sitos de la evaluaci6n de la calidad, los defectos se cuentan sobre un periodo estandar. usualmente un ana. Fadlldad de mantenlmlento. EI mantenimiento del software justifica mas esfuerzos que cualquier olra actividad de la ingenierla del software. La facilidad de mantenimiento es la sencillez can la que un programa puede corregirse si se encuentra un error, adaptarse si su entomo cambia, a mejorar si el cliente desea un camblo en los requisitos. No existe forma de medir directamenle la facilidad de man tenimiento; en consecuencla, se deben emplear medidas indirectas. Una simple medida orientada al tiempa es el tiempo 1TI(;dio de cambia (TMC), el tiempo que toma anaJizar el cambia solicitado. disenar una modificaci6n apropiada, implementar el

9 En el capitulo 15 sc prescntb una discusU"l**aJlada de los factores que influycn en la calidad del software y las metricas que sc pucdcn usar ~ ........ " c.aIidad del software

.7.

PARTE CUATRO GEST16N DE PROYECTOS DE SOF'TW"AAl:

cambia. probarlo y distribuir el cambia a lodos los usuarios. En promedio. los programas susceptibles de mantenimiento tendrtm un TMC bajo (para tipes de cambios equivalentes) que los programas que no 10 son.

Integrldad. La inlegridad del software se ha vuelte cada vez mas importante en

la edad de los ciberterroristas y hackers. Esle atributo mide la habilidad de un sistema para resistir ataques (tanto accidentales como Intencionales) a su seguridad. Los

alaques se pueden realizar en los Ires componentes del software: programas, datos
y documentos.
La medici6n de la integridad requiere definir dos atributos adicionales: amenaza

y seguridad. Amenaza es 1a probabiJidad (que puede estimarse 0 deducirse de evidencia empirical de que un ataque de un tipe especifico ocurrira dentro de un tiempo dado.

Seguridad es la probabiHdad (que puede estimarse a deducirse de evidencia

empirical de que se repela el ataque de un tipo especlfico. Entonces, la integridad de un sistema

se puede definir como:

x
( I - seguridad))

integridad - I - (amenaza

Par ejemplo, si la amenaza (Ia probabilidad de que un ataque ocurrira) es 0.25 ~ la seguridad (Ia posibiJidad de repeler un ataquel es 0.95, la integridad del sistema cs

0.99 (muy elevadaj. 5i, par otTa parte, la probabiJidad de amenaza es 0.50 y la postbilidad de repeler un ataque es s6lo 0.25, la integridad del sistema es 0.63 (inaceptablemente baja).

Facllldad de uso. Can frecuencia, un programa que no es fadl de usar esta con
denado al fracaso, inctuso si las funciones que realiza son valiosas. La faciJidad cit uso es un intento por cuantificar la senciJIez de la aplicaci6n al utilizarla y se puedt medir en terminos de las caracteristicas presentadas en el capitulo 12.

Los cuatro factores apenas descritos 561 0 representan una muestra de los que St
han propuesto como medidas para la caUdad del software. EI capitulo 15 consideTil este t6pico can mayor detalle.

22.3.2 Eftcacta en la el1m1nacton de defectos

Una metrica de caUdad que ofrece beneficios tanto en el ambito del proyecto COI1'lO en el del proceso es la

ejicacia en 10 eliminocl6n de dejectos (EED). En esencla, la Em

es una medida de 1a habilidad de filtrar las actividades de la garantia de cualidad ~ de control conforme se aplica a traves de todas las actividades del marco de traha del praceso. Cuando se considera un proyecto como un todo, la EEO siguiente: EED = E/( + OJ donde E es el numero de errores encontrados antes de entregar el software at usuario final, y D es el numero de defectos encontrados despues de la entrega.

se

define de la manera

cAPiTuLo 22

MtrRICAS O JICMXISO Y PDO.1C10

..,.

EI valor ideal de la EED es 1. Esto es: no se encuentra defecto alguno en el software. En reaJidad, D sera mayor que 0, pero el valor de EED todavla puede acercarse a 1. Conforme E aumenta (para un valor dado de DJ, el valor global de EED comienza a acercarse a I. De hecho, conforme E aumenta, es probable que el valor final de D disminuya (1os errores se mtran antes de que se conviertan en defectos). Si se utiliza como una metrica 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 tecnicas para encontrar tantos errores como sea posible antes de la entrega.
La EED tambien se puede aplicar en el proyecto para valorar 1a habilidad de un

equipo de encontrar errores antes de que pasen a la siguiente actividad del marco de trabajo 0 a 1a siguiente tarea en la ingeniena del software. Por ejemplo, la tarea de ana!isis de requisitos produce un modele de analisis que se revisa para encontrar y corregir errores. Aquellos errores que no se encuentran durante la revisi6n del mode10 de analisis pasan al disef\o (donde pueden 0 no encontrarse). Cuando se aplica en este contexto la EED se redefine como

EED, - E,I(E, + E, 1)
donde E/ es el numero de errores encontrado durante la actividad i de ingenieria de software y E/ , I es el numero de errores encontrado durante la actividad i + 1 de ingenieria del software que se puede seguir para Ilegar a errores que no fueron descubiertos en la actividad i de lngenieria del software. Un objetivo de caUdad para un equipo de software (0 un ingeniero de software individual) es lograr una EED/ que se acerque a I . Esto es: los errores deben filtrarse antes de que pasen a la siguiente actividad .

I0I0<.'' ' '.. "" un enfoq.e de m~_

CIpDI'M'Iidr:Id de ap.Jd.

_,01 ........

IN!

~- ... ~ -I

...orw. nI:aaio

kOi . . . . , . . . . .

010 ...... coda polO

...

PARTE CUATRO GESTION DE I'ROYECTI:X) DE SOFTWARE

.... .......
y, por desgr""'~ muchas tienen poco deseo de comenzar. Como se ha selialado en este capitulao problema es cultural. El intenlo de recopilar medidas donde nadie 10 ha hecho en eI
La mayorla de los desarrolladores de software todavla no miden

sado con frecuencia genera resistencia. "tPor que tenemos que hacer esto?~ P"'II''' ta un gestor de proyecto acosado. "No Ie veo el caso~, se queja un profesional
exceso de trabajo. En esta secci6n se consideran algunos argumentos para las metricas de sot...... y se presenta un enfoque para instituir un programa de recopilaci6n de metricas una organizaci6n de ingenierla del software. Perc antes de comenzar, ww;em, a .... siderar (GRAS7) algunas palabras de cordura de Grady y caswell:

Algunas de las cosas que describimos aqul sonaran bastante sencillas. En rcalidad, sio
embargo, eJ establecimien]o de un programa de metricas de software exitoso en el ambt to de la companla es un trabajo duro. Cuando decimos que se debe esperar al menos tre:s aflos antes de que esten disponibles tendencias organizacionales amplias, se obtiene ill guna idea del ambito de tal esfuerzo.

Vale la pena prestar atenci6n a la advertencia que sugleren estos autores, pero beneficios de la medici6n son tan convincentes que el trabajo duro vale la pena..

22.4.1 Argumentos para las meb1cas del software

,Por que es importante medir el proceso de ingenierla del software y el pccxlUd8
(software) que elabora? La respuesta es relativamente obvia. 5i no se mide, no ell te una forma real de determinar si se esta mejorando. Y si no se mejora, se esta per dido. Al cuestionar y evaluar la productivldad y las medidas de calidad, un equipo software (y su gesti6n) puede establecer metas significativas para mejorar el proc& so del software. En el capItulo I se apunt6 que el software es un tema comercial

cAPiTuLo 22

MtTluCAS O PIkX:ISO y J)'LIO

61'

trategico para muchas companlas. Si el proceso con el eual se desarrolla puede me jorarse, se praducira un impaeto directo en 10 sustancial. Pero para establecer obtrtivos de mejora es preciso eomprender el estado actual del desarrollo de software Por 10 tanto. la medici6n se emplea para establecer una linea base de proceso a partir de la cual se evaluan las mejoras.

...... """, '"'..,..,,' .... _M

' ' '. . .1las cosos mtdionte los n6meros tfllIIIKhos aspect05 de nueslTas ms ... Estos nirnIeros /l1li . . . . . . ~_.'

.........,...,pc..

Los rigores cotidianos del trabajo del proyecto de software dejan poco tiempo

ra ejercitar el pensamiento estrategko. Los gestores de proyectos de software " preocupados con temas mas concretos (aunque igualmente importantes): des.arr>[Jar estimaciones de proyecto significativas. producir sistemas de alta caUdad, tene;el producto en circulaci6n a tiempo. Si se emplea 1a medici6n para establecer una nea base del proyecto, cada uno de dichos temas se welve mas manejable. Va 5l' lui mencionado que la linea base sirve como fundamento para la estimaci6n Adicionr. mente, la recopilaci6n de metricas de caUdad permite que una organizaci6n -SIn nke su proceso de software para remover las causas "poco vitales" de los defectos que lienen el mayor impacto sobre el desarrollo del software. IO
N

22.4.2 Establecim1ento de una linea base

Con el establecimienlo de una linea base de metricas se obllenen beneficios en ambitos del proceso, del proyecto y del produclo (l ecnico) . Jncluso la informadO. que se recopila no necesita ser fundamentalmente diferente. Las mismas melricas pueden servir a muchos maestros. La linea base de metricas consiste de datos ~ pilados en proyectos previos de desarrollo de software y pueden ser tan simples cmo la tabla presentada en la figura 22.2 0 tan complejos como una base de datos detallada que conHene docenas de medidas de proyectos y las metrkas derivadas de estos. Para ser un auxiliar elicaz en el proceso de mejora 0 de cosio y esfuerzo, los datos de la linea base deben tener los siguientes atrlbutos: I) los datos deben ser razona blemente precisos: se deben evitar las Hconjeturas" ace rca de los proyeclos pasados 2) los datos deben recopilarse para tanlos proyectos como sea posible; 3) las med).das deben ser consistentes, por ejemplo: una linea de c6digo debe interpretarse consistentemenle a Iraves de tados los proyectos para los que se recopilan los datos; 4) las aplicaciones deben ser similares al trabajo que se estimara: tiene poco sentido emplear una linea base en un trabajo de sistemas de informaci6n en bloque para estimar una aplicaci6n anidada en tiempo real.
En et capItulo 26 se tralan con detalke eu.1deas. fonnal:1udas en un enfoque denominado ganrn do estadisooJ de aI/iliad tid softwr.1rr

10

.,
_de
recopUaciOn

PARTE CUATRO GEST!6N D PROYKiOS DE sonw~

demetr1cas de software.

~~

22.4.3 RecopUacton. c6Iculo y evaluacion de metricas

En la figura 22.3 se ilustra eJ proceso con el que se establece una linea base de me. tricas. De manera ideal, los datos necesarios para hacerlo se han recopilado confor~ me se avanza. Por desgracia, esto rata vez es el caso. En consecuencia, la recopilad6n de datos requiere una investigaci6n hist6rica de los proyectos previos para reconstruir los datos requeridos. Una vez que se han recopilado las medidas (incuestionablemente el paso mas dilkil) es posible calcular las metricas. Oependiendo de
la amplitud de las medidas recopiladas. las metricas pueden abarcar una amplia garna de metricas orientadas a la aplicaci6n (por ejemplo, LDC, PF, orientada a objetos webApp). as] como olras orientadas a la calidad y al proyecto. Finalmente, las metricas deben evaiuarse y aplicarse durante la estimaci6n del trabajo tecnico, el control del proyecto y la mejora del proceso. La evaluaci6n de las metricas se centra en las razones subyacentes de los resultados obtenidos y produce un conjunto de indicadores que gu[an el proyecto 0 proceso.

C&VE
los detos de mAItioos
~", oo._

Ie<:opirse de 1RI 1F1 rooestro r8!W8SfIl1DlMl

softwme1l'8Yios.

.""""

tc'.N"'."
5i se esJIj (0016II"

La gran mayoria de las organizaciones de desarrollo de software tiene menos de 20

zoodo Grecopi/rll 00Ius d6 metriros,

_ mool>

", ..... m
"'""'" do _

"""~ Sim

empleados. Es irracional, yen la mayorla de los casos irreal. esperar que tales organizaciones desarrollaran programas detallados de metricas de software. Sin embargo, es razonable sugerir que las organizaciones de software de todos los tamanos miden y luego emplean las metricas resultantes para ayudar a mejorar sus procesos de software locales y la caUdad y la puntualidad de los productos que elaboran . Un enfoque de sentido comun respecto de la implementaci6n de cualquier actividad relacionada con el proceso de software es mantenerlo simple, personalizarlo paril satisfacer las necesidades locales y asegurarse de que agrega valor. En los parrafos

cAPiTuLo 22 MtnocAs DE PROCeSIO T I'8OtEcro

que siguen se examina c6ma estes Jineamientas se relacianan can las metricas
H

pa-

ra pequenos negodos. 11 "Mantenerla simple es una directriz que funciona razonablemenle bien en mu chas actividades. Pero, tc6mo se deduce un canjunto "simple" de metricas de soft ware que aun as! proporcione valor, y c6mo se garantiza que dichas metricas sim pies satisfaran las necesidades de una organizaci6n de software particular? Un buen comienzo cansisle en enfocarse no sobre las mediciones sino mas bien sobre los resultados. Al grupo de software se Ie entrevista para definir un abjetivo sencillo que requieTe mejora. Par ejempla, "reducir el tlempo para evaluar e implementar ios cambios solicitados". Una organizaci6n pequena puede seleccionar el siguiente 0 Injunto de medidas que se recapilan can facilidad: Tiempo (haras a d!as) transcurrid a desde el momento en que se hizo una soticilud hasta que la evaluaci6n esta completa, l,;""". Esfuerza (persona-horas) para realizar 1a evaluaci6n, T~ Tiempo (hOTaS 0 dias) transcurrida desde que se completa la evaluaci6n hasta la asignaci6n del pedida de cambio al personal, l,....,~ Esfuerzo (persona-horas) requerido para hacer el cambio, T ,rnt>o Tiempo requerida (haras a dlas) para hacer el cambia, t,<lml>t<' Errores descubiertos durante el trabaja para hacer eI cambia, f,am"'" Defectos descubiertos despues de que el cambio es liberado a la base de clienles, D,amblo . Una vez que se han recapilado dichas medidas para varios cambios solicitadoa es posible calcular el tiempa transcurrida tOlal promedio desde que el cambia se solicit6 hasta la implementaci6n del cambia y el porcentaje del tiempo transcurrido sorhido por la cola de espera inicia\. la evaluaci6n y la asignaci6n y la implementaci6n del cambio. De igual modo, es posible detenninar el porcenlaJe del esfuerza que requleren la evaluaci6n y la implementaci6n Estas metricas se evaluan en el contodDJ de los datos de caUdad, ~=~ y D, ... ~ Los porcentajes proporcionan conocimiefll;:; detallada de d6nde se vuelve lento el proceso de solicitud de cambia y conduce a pa50S de mejara del proceso para reducir la" T&JJ. t/"\ul, T'lmfoto. 0 EC<lm/>icl. Ademas. la efica.. cia en la de eliminaci6n de defectos se puede calcular como
EED - E<<lmtr/(Ewmbk

+ Dc,," J

EED se compara con eJ tiempo transcumdo y el esfuerzo total para detenninar el im pacto de las actividades de aseguram~nlo de la calidad en el tiempo y el esfuerzo requeridos para realizar un cambia.

II Esta exposiciem

es Igualmenle relevante par.l1Ds ~ ck software que han adopt ado un

so de desarrollo de software .igil (capit""41

...
...........
WWW,e! _ _

PAll:TE CUATRO

GESllON DE PIlOvterCti DE SOFlWAR

El Software Engineering Institute (SEI) ha elaborado una gula detallada [PAR961 para establecer un programa de metricas de software "dirigido por metas". La gula su-

giere los siguientes pasos:

I. ldentificar los objetivos de la empresa.

2.
3.
4.

Identificar 10 que se quiere conocer 0 aprender.

Identificar los subobjetivos .
Identificar las entidades y atributos relacionados con los objetivos secundarios

5.

Fonnalizar los objetivos de la medlci6n.

6. 7.
8. 9. 10.

Idenlificar preguntas cuantificables y los indicadores relacionados que se em-

pleanin como apoyo para lograr los objetivos de sus mediciones.

Identificar los elementos de datos que se recopilaran para construir los indicadores que ayuctaran a responder las pregunlas. Definir las medidas que se emplearan y hacer que estas definidones sean operativas. Identificar las acciones que se tamarim para implementar las medidas. Preparar un plan para impiemenlar las medidas.

.....,

Una exposici6n detallada de estos pasos mejor se deja para ellibro del SE.I. Sin embargo, bien vale la pena dar un breve vistazo a los puntos clave. Pueslo que las fundones comerdales de apoyo del software diferendan los sistemas 0 productos basados en compuladora. 0 actuan como un producto en sl mismo. las metas definidas para las empresas casi siempre pueden seguirse hacia abajo has-

~"*" C&VE
lcs melricas de sdrMre c,Je sa debwI eslllr basoOOs an k1smelos de ll&gO(ios VIknitas (jilt sa des!on klgnr.

ta metas espedficas al nivel de la ingenieria del software. Por ejemplo, considerese

una compania que fabrica avanzados sistemas de seguridad para el hogar que liene contenido de software sustandal. Al trabajar como equipo. la ingenieria del software y los gestores del negocio pueden confecdonar una lisla de metas priorizadas del negocio: I. 2. 3. 4. 5. Mejorar la satisfacd6n de los clienles con los produclos. Hacer que los productos sean mas fadles de usar. Reducir elliempo que loma poner un produclo en eI mercado. Simplificar el soporle para los productos. Mejorar \a obtenci6n global de utilidades.

La organizad6n de software examina cada meta de negocios y pregunla: c:Que acti~

vidades se geslionan 0 ejecutan y que se quiere mejorar de dichas aclividades? Para responder estas preguntas el SEI recomienda la creaci6n de una "\ista entidad-pregunta" en la que se anolen lodas las cosas (enlidades) dentro del proceso de softwa-

CAPiTuLo 22 MtmICAS Dt PROCESO YPIlOY1CI'O

68.

re que se gestionan 0 en las que influye la organizad6n de software. Los ejemplos de entidades incluyen recursos de desarrollo, productos de trabajo, c6digo fuente, casos de prueba, solicitudes de cambia, tareas de ingenierfa del software y pJanificadones. Para cada entidad en la tista el personal de software desarrolla un conjunlo de preguntas que evaluan caracteristicas cuantitativas de la entidad (por ejemplo, tamafio, costo, tiempo de desarrollo) . las preguntas que se derivan de la creaci6n de una !ista entidad-pregunta conducen a la derivaci6n de un conjunto de subobjetivos que se relacionan directamente con las entidades creadas y las actividades realizadas como parte del proceso del software. Considerese la cuarta meta: "Simplificar el soporte para los productos". Para esta meta se puede derivar la siguiente lista de preguntas [PAR96j:

,La solicitud de cambio del cliente contiene la informaci6n requerida para

evaluar adecuadamente el cambio y luego implementarlo en una forma oportuna? ,Cuan grande es el registro de petici6n de cambio?

,E! tiempo de respuesta para fijar los bugs es aceptable con base en las necesidades del cliente?

,5e sigue el proceso de control de cambios (capitulo 27)?

,Los cambios de alta prioridad se implementan en forma oportuna? Con base en estas preguntas la organizaci6n de software puede deducir el siguiente subobjetivo: mejorar el desempefw del proceso de gesti6n de cambia. Se identifican las entidades y los atributos del proceso de software relevantes respecto del subobjetiYO, y se delinean las metas de medici6n asociadas con ambos elementos.

El SEI [PAR96] proporciona una guia detallada para los pasos 6 al !O de su enfoque de medici6n orientado a objetivos. En esencia, se ap!ica un proceso de retinamiento paso a paso en el que los objetivos se retinan en preguntas que posteriormente se refinan en entidades y atributos que entonces se retinan en metricas.

Establec1mJento de un programa de m etricas

EI Software Prodl.lCtivity CIll1~ [www.lfK.oo) sugierl un III1foque de ocho pasos pare

de :IOftware y que se puede empleor como al enloque del SEI descrita en Ia secci6n 22.6. ""~'.~ 58 resume a cantinuoci6n. Entender el proceso de software existente. 51 definen las octividodes del marca de Irobojo (capitulo 2). 51 describe Ia informaciOn de entrada para coda
actividad.

~~:;'~n progroma de metricos dentro de uno

Se definen las Ioreas awciadas can cada octividod. Se oooIan las fvn<ianes de aseguremiento de Ia ooIidod. 51 hoc:e uno lisla can las productos de Iroboia

pn>dOOdo>. 2. o.IirW los ob;etivos que se Iogror6n mediante el ~I-"o de un progrema de melricas. q.mpIos: mejox' Ia precisi6n de la el~maci6n, ~ '" coIidad del producta.

...

PARTE CUATRO GCm6N DE PROYECT05 DE sonwARE

3. ldenlificor las metricas requeridos para !ograr los objetivos. Se definen kn preguntos que deben responder$e; por ejemplo, tw6nlo5 em;lI"es encontrodos en uno octiYidod de morco de trobojo pueden seguil'1e hoslo 10 octividod del morco de trobojo Crear medidos y metri(Qs que ~r6n rec;opilados y cokulodas.
.4.

tQue meconismos de volidoci6n se aplicon port! gon:mtizof que los 00105 seon correclos~

6. Adquirir herromienkn oOecuoocn pora apoyor 10 recopiloci6n yevoluoci6n.

7.

".....don'"

Estoblecef- una bose de datos de metrical. Se establece Ia complejidod reIotiva de 10 base 0.

dolo .
58 expIoro eI empleo de herromienlos relocionodas (por ejemplo, un ol~ SCM, copihJlo 27}. Se IMlIvon los product05 de bose de ~
existenlm.
8.

ldentificor ku medidos y metrical que MlrOn recopilodos y cokulodos.

olobiecer un proce1O de recopiloci6n de

medidos

re$fXll1diendo las ~guienles Pfl'9untos: ~Cu61 es Ia !vente de las medkionesf ~Las herromientos Ml pueden empleor en reoopikx:i6n de los dotos?

Dennir meconismos de realimet1loci6n odecuodos

tOui." requiere informoci6n de ~lficos en

10

marcha'
tC6mo se enlregar6 Ia informaciOn' tCuOI M eI formoto de 10 informoci6nf Uno descripci6n considerablemente m6s detoIlodo de ... oc:h<n po$O$ 5e puede descargor de
http://_.$pc.co! re5OI.Irces/ metrics/.

tOuien eJ relpOOKJbIe de Ia recopiloci6n de doio.! iCoondo HI recopilon y regiMron los dotm, tCOmo HI oImocenon los datos?

22,7

RESYMEN
Las mediciones permiten que los gestores y profesionales mejoren el proceso software; auxilien en la planificaci6n, seguimiento y control de un proyecto de sot ware; y evaluen l a calldad del producto (software) que se produce. Las medidas atributos espedficos del proceso, proyecto y producto se utilizan para calcular Ill'... tricas de software. Dichas metricas se pueden analizar para ofrecer indicadores gulen las acciones de gesti6n y tecnica. Las metricas del proceso permiten que una organizaci6n adopte una visi6n eSlJ7' tegica al propordonar lnformad6n detallada de la eficada de un proceso de softwre oLas metricas de proyecto son tacticas; permilen que un gestor de proyecto actav le el nujo de trabajo del preyeao y un enfoque tecnico realista en terminos de Bernpt. Las metricas orientadas tanto al tamano como a la funci6n se aplican a 10 larg de loda la industria. Las metricas orientadas al tamano emplean la linea de c6d como un factor de normalizaci6n para otras medidas como persona-mes 0 defect EI punto de funci6n se deduce de las medidas del dominio de la informaci6n y de lin' valoraci6n subjetiva de la complejidad del problema. Ademas, se pueden utHizar melricas orientadas a objelos y las metricas de aplicaci6n Web. Las metricas de calidad del software, como las melricas de productividad, se ef'I focan sabre e[ proceso, el preyecto y el producto. AI desarrollar y analizar una II

cAPiTuLo 22

MtrR!cAS DE PROCESO Y PROYECTO

68'

base de metricas para la calidad, una organizaci6n puede corregir aquellas areas del proceso de software que causan defectos de software. La medici6n resulta en cambios eulturales. La recopilaci6n de datos, el ealculo y el analisis de metricas son los tres pasos que predso implementar para comenzar un programa de metricas. En general, un enfoque orientado a objetivos ayuda a que una organizad6n se enfoque en las melricas correetas para su negocio. Al crear una linea base de metrieas -una base de datos que contiene medidones de proceso y produeto--- 10s ingenieros de software y sus gestores pueden eomprender mejor el trabajo que haeen y el produeto que elaboran

1AL8831 Albrecht, A J Y 1. E, Gaffney, "SOftware function, Source Unes of Code and Develop' ment Effort Prediction. A Software Science Validation", cn IEEE ThIns. SOftware Engmeering, noviembre de 1983, pp. 639-648, [WESI1 Boehm, B., SOftware Engineering Economics, Prentice-Hail, 1981. [GRA871 Grady, R B, Y D. L. Caswell, software Metrics: Brablishing a Company \tl'de Program, Prentice-Han, 1987 IGRA92] Grady, R. G., Praclica/sojtware MettlcsJor ProjeCt Managemem and Process Improvement. Prentice-Hall, 1992 IGI1.881 Gilb, T., Prinaples oJSOftware Project Managemenl, Addison-wesley, 1988. {HET93] Hetzel. W, Maldng SOftware Measurement Work, QED Publish[ng Group. 1993 [HUM95[ Humphrey, W., A Discipline Jor Software Engineering, Addison-wesley, 1995, [IEE93] IEEE software Engineering SlandanJs, Standard 610.12-1990, pp, 47-48 [lON86] Jones, C, Programming Productivity, McGraW-Hill, 1986, [lON911 Jones, C, Applied SOftware Measurement, McGraW-Hill, 1991. [lON981 Jones, C., Estimating Software Costs, McGraw-Hill, 1998. [LOR94] Lorenz, M . y J, Kidd, Object-Oriented Software Memes, Prentice-Hall. 1994 [PAR961 Parte, R. E, W. B. Goethert y w. A. Florae, Goal Driven SOftware Measurement A Guide book, CMU/SEI96-BH-002, Software Engineering Institute, carnegie Mellon University, agosto de 1996. [PAU94] Paulish, D. y A. carleton, "Case Studies of Software Process Improvement Measure ment en Computer, vol 27, num. 9, septiembre de 1994. pp 50-57, [QSM02] "QSM FUnction Point Language Gearing Factors-. Versi6n 2.0, Quantitative Software Management, 2002, hUpJlwww.qsm.com/FPGearing.html [RAG95] Ragland, e, "Measure, MeJrie or Indicator What's the Dirrerence?~, en Crosstalk. vol 8. num. 3, marzo de 1995, pp 29-30. ISMI99] Smith, J., "The Estimation of Effort Based on Use-Cases~, un artkulo de Rational Corporation, 1999, se puede descargar de hUpJIWWW,ratlonalcom/products/rup/whltepa
H

pers.jsp.

22.1. Describir con palabras proplaS la diferenoa entre

m~tricas

del proceso y del proyecto

22.2. ,Por qu~ algunas m~tricas de software det:Im conservarse "privadas~? Ofrecer elemplos de tres metricas que deban ser pnvadas C>fi"eur e,emplos de tres metricas que deban ser publi-

"" 22.3 . ,Que es una medida indirecta yporqut' taks medJdas son comunes en eltrabaJo de metricas del software? 22.4 , Grady sugiere un conjunto de regtas de ebqUeU pMillas m~tricas de software iEllector puede agregar tres reglas mas a las menc:icnadas rn III secOOn 22.1 l '

...

PARTl: CUATRO GSi10N DE PROYf.CTOS D SOFTWARE 22.5 EI equipo A encontr6 342 eITores durante el proceso de ingenierla del software previa a

Ja HberaciOn. El equipo B encontr6 184 errores. ,Que medidas adicionales tendrlan que realizar

los proyectos Ay B para detennlnar euai de los equ\pos elimin6 los errores de manera mas eti ciente? ,Que metticas pocIrian proponerse para ayudar a reaiizar \a detennlnaci6n? ,Que datos
hist6ricos pueden ser (niles?

22.6. Presentar un argumento contra las lineas de c6digo como medida para la produclividad

de software. iEi caso se sostiene cuando se consideran docenas 0 dentO$ de proyeclOS?

22.7. calcular el valor de punta de fund6n para un proyecto con las siguienles caracterfsticas de dominic de informaci6n:

Numero de entradas extemas: 32

Numero Numero Numero Numero de salidas extemas: 60 de consultas extemas 24 de archiv05 l6gicos intemos; 8 de archivos de interfaz exlemos: 2

Suponer que lodos los valores de ajuste de complejldad son promedlos. Utilizar el algorilmO anotado en e! capitulo 15. 22.8. Emplear la tabla presentada en la secci6n 22.2.3 para elaborar un argumento conlra II utilizaci6n del lenguaje ensamblador basado en la funcionalidad entregada poT enunciado dt cOdigo. Vease de nuevo la tabla y comentar por que c++ presentarfa una mejor altemativa que C. 22.9. El software utilizado para controlar una fotocopiadora requiere 32 000 1.DC de C y 4 201" lIneas de Small talk. Estimar el numero de puntos de funci6n para el software dentm de ]a copiadora. 22,10, Un equipo de ingenlerla Web ha construido una webApp de comercio electr6nico QUI: contiene 145 ptlginas indivtduales. De estas ptlginas 65 son dim\mlcas: esto es, se generan manera intema con base en la entrada del usuarlo final. LCu:'1 es ellndice de personalizaoblr para esta aplicad6n' 22. 11 . Una webApp y su enlomo de sopone no han sido completamen te rerorzados 0 es del 30 par ataques Los ingenieros Web estiman que la probabilidad de repeler un ataque 561 ciento. El sistema no contiene informaci6n sensible 0 controversial, as! que la probabilidad amenaza es de 25 por ciento. LCu:'1 es la integridad de la WebApp? 22.12. En la conclusi6n de un proyecto que utiliz6 el Proceso Unificado (Capitulo 3) se deteI" min6 que 30 errores se enconlraron durante la rase de elaboraci6n, y 12 errores hal1ados dur. te la rase de construcci6n podlan seguirse hasta errores que no fueron descubienos en la de elaboraci6n. LCu:.1es la EED para estas dos rases? 22,13, Un equipo de software entrega un incremento de software a los usuarios finales. descubren oc:ho defectos durante eJ primer mes de uso. Antes de la entrega, eJ equipo de ware encontr6 242 errores durante las revisiones tecnicas formales y todas las tareas de p ba lCu:'1 es la 0 global para el proyecto?

r...

La mejora del proceso de sonware (MPS) ha recibldo una cantidad signiflcativa de atenci6n rante las des d&adas pasadas. Dado que la medici6n y las metricas de software son clave mejorar exitosamente el proceso de software, muchos libres acerca de Ja MPS tambien tratan metricas. Las fuentes valiosas de informaci6n acerca de las metricas de procesos lncluyen
Burr, A. y M. Owen, Statistical MethodsforSOftware Quality, International Thomson Pu hlng, 1996. El Emam, K. y N. MadhaV)i (eds.), Elements afSoftware Process A.sses.sment and fmp~ IEEE computer SOCiety, 1999.

cAPiTuLo 22

MtnucAs M PRCX:D:l T IIiIOhCIO

689

Florae, W. A, Y A. D, carleton, M~ the SOftware Process: SUUistica/ Process Control Jor software Process ImpfOV'l!ment, Addison-Wesley, 1999. Gannus, D. y D, Herron, Measunng the surements, Prentice-Hall, 1996

sojlware Process: A Practical Guide to Functional Mea-

Humphrey, W.,lntroducDon to 1M 1h1m 50jtware Process, Addison-wesley/Longman, 2000 Kan, S H., Metrics and Models m 50jtware Quality Enginemng. Addison-wesley, 1995 McGany y sus colegas (Pmctkll/ SOjlware Measuremenl. Addison-wesley. 2(01) presentan conseJos a pro(undidad para valorar el proceso de software, Haug y sus colegas (SOftware Process lmprovement; Metrics. Measurement and Process Modeling, Springer-verlag, 2(01) han editado una colecci6n de artlculos valiosos. Florae y Carlton (Measuring the 5()ftware Process, Addisonwesley, 1999) y Fenton y pfleeger !Software MetriCS: A Rigorous and Practical Approach, revisado, Brooks/Cole Publishers, 1998) tratan e6mo se pueden emplear las metrieas de software para proporclonar los indicadores necesarios para mejorar el proceso de sotlware Putnam y Myers (Five Core: Metrics, Dorset House, 2003) estudian una base de datos de mas de 6 000 proyectos de software para demostrar cOmo cinco metricas centrales -tiempo, esfuerZO, tamano, confiabilidad y produetividad de proceso- se pueden emplear para controlaT los proyectos de software, Maxwell [,Applied Statistics Jor SOftware Man~rs, Prenllce-Hall, 2003) presenta tecnicas para anaHzar datos del proyecto de sotlware. Munson (software Engineering Measurement, Auerbach, 2(03) estudia un amplio abanico de temas de medlci6n de ingenierfa del software Jones (Software Assessments, Eknchmarks and Besl Practices, Addison-wesley, 2000) describe tanto medidas cuantitati'o'as como factores cualitati'o'OS que ayudan a una organizacl6n a 'o'aloraTsus procesos y practicas de software. Gannus y Herron (FunctiOll Pomt AlIab' sis: Measurement Practices for Succes.sji.J1 Software Projts, Addison-wesley, 2000) examinan las metricas de proceso con enfasls en e\ analisis de los puntos de funci6n. Lorenze y Kidd [LOR94) Y DeChampeax (Object-Oriented Development Process and Memes, Prentice-Hall, 1996) consideran el proceso 00 y describen un conjunto de metricas para 'o'alorarlo. Whitmire (Object-Orientt!d Design Measurement, Wiley, 1997) y Henderson-Sellers (Object Orlenleel Metrics: Measures ojComplexity, Prentice-Hall, 1995) se enfocan en las metricas tecnicas para el trabajo 00, perc lambien eonsideran medidas y metricas que se pueden aplicar en el ambito del proceso y del producto. se ha publicado relati'o'amente poco acerca de \as metricas para el trabajo de ingenierla Web Sin embargo, stem (web Metrics: Provet1 Methods for Measuring Web Site SUccess, Wiley. 2(02), Inan y Kean (Measuring the SUccess oJYour Website, Longman, 2(02) y Nobles y Grady (Web Site AnalYsis and Reporting, Premier Press, 2001) abordan las metricas Web desde una perspeeti'o'a de negoclos y de marke ting. Lo mas reciente en la In'o'estigaci6n en eJ area de metricas 10 resume ellEEE (Symposium on 50jtware Melrics, publicado anualmente), En Internet esta disponible una amplia variedad de fuentes de in(onnaci6n acerca de las metricas de proceso y proyecto. Una \ista actualizada de referendas en la World Wide Web se encuentra en el sitio Web SEPA' http://www.mhhe.com/ pressman.

CAPiTULO

23
CONCEPTOS
CLAVE

ESTIMACION PARA PROYECTOS DE SOFTWARE

inIbito .......693
(OIIfIIejitkJcl 103 fllillladOn

...... ......

a gest!6n del proyecto de software comlenza con un conjunto de activida des que en grupo se denominan planificad6n del proyecto. Antes de que d proyecto comience el gestor del proyecto y el equipo de software deben e5" timar ellrabajo que habra de realizarse, los recursos que se requeriran y el tiempc: que transcurrira desde el principio hasta eJ final. Una vez que se completen esta.. actividades, el equipo de software debe establecer un plan del proyecto que dl.
tina las tareas y fechas clave de l.a ingenierla del software. que identifique quier

IIlDC ...100

IlaSOlla .. Pf 702
JIr1K*SOI 704

Ul51n'" llSO

.70S

es responsable de dirigir cada tarea y especifique las dependendas entre tarea!o que pueden ser determinantes en el progreso . En una excelente guia para "sobrevivir el proyecto de software", Steve McConnel {MCC981 presenta una visiOn del mundo real de la pJanificaci6n del proyecto:
Muchos trabajadores tcknicos preferiran realizar cI trabajo tecnico en lugarde pasat el tiempo en la pJanHicaci6n. Muchos gestores tecnkos no tienen suficiente entrenamiento en 1a gesti6n t&:nica para scntirse seguros de que su planificaci6n mejorara el resultado de un proyecto. Puesto que ninguna parte quiere hacer la planificaci6n, con fre<:uencia no se realiza. Pero las (alias para planificar es uno de los maYOTes errores que un proyecto pueda cometeT ... se necesita la planificaci6n eflcaz para resolver los problemas corriente arriba Itemprano en el proyectOj a bajo ~o, mas que corriente abajo {tarde en eJ proyecto1 a alto costo. EI proyecto promedio gasta 80 por dento de su tiempo en Tee laboraci6n: conigiendo errores que se cometieron en etapas tempranas del proyecto

fadiIIWacI 693
pro)"dO 692

_do

COIK.,",I 69'

rondliadO.

loa

.....

_ _ . .. .. .694

del softwcn ..691

cAPfTuLo

23

ES'TtMAct6N PAllA 1'IIO'I .... C6 DE 5Of'TWAlZE

Sin

quo

01 ""'-

....

McConell argumenta que cualquier proyecto puede encontrar el tiempo para planilicar (y adaptar el plan a 10 largo del proyecto) simplemente tomando un pequeno porcentaje del tiempo que se habrla gastado en la reelaborad6n que ocurre debido a que no se planific6.

La planificaci6n requiere que los gestores tecnicos y los miembros del equipo de software establezcan un compromiso inicial, aun cuando sea probable que este "compromise" pruebe estar equivocado. Siempre que se realizan estimaciones se atisba al futuro y se acepta automaticamente algtin grado de incertidumbre Para d lar a Frederick Brooks IBR075):
[Nluestras tecnicas de estimacl6n estan pobremente desarroUadas. Mas seriamente, reflejan una suposicl6n no expresada que es bastante incierta, es decir, que todo ira bien Puesto que no estamos seguros de nuestras estimaciones, con frecuencia los gestOTes de sonware carecen de la cortes testarudez para hacer que la gente espere un huen producto.

Aunque la estimad6n es tanto un arte como una denda, esta importante actividad no necesita reaJizarse en una forma improvisada. Existen tecnicas titiles para la estimad6n de tiempo y esfuerzo. Las metricas del proceso y del proyecto ofrecen la perspectiva hist6rica y la energla para la generad6n de estimadones cuantitativas. La experienda (de tada la gente involucrada) puede auxiliar enormemente con forme se desarrollan y revisan las estimaciones Puesto que la estimaci6n caleca los cimientos para las demas actividades de planificaci6n del proyecto, y esta propordona la ruta para la ingenierla del software exitosa, se estaria mal aconsejado si se embarcara sin ella.

,...:o.""""'._' ......................... ___ ~ .... _ ..... ~.

.

..-

PARTE CUATRO GES'OON D PRClYfx:TC6 DE SOf"lWAAE

La estimaci6n de recursos, costa y programa de tTabaja para una tarea de ingenieria de software requiere experiencia, acceso a buena informad6n hist6rica (metricas) y el valor para comprometerse con predicciones cuantitativas cuando la informaci6n cualitativa es todo 10 que existe. La estimaci6n implica riesgo inherente, 1 y este conduce a la incertidumbre. La disponibilidad de informaci6n hist6rica tiene una fuerte influencia en el riesgo de 1a estimaci6n. Al mirar en retrospectiva, se pueden emular las casas que funcionaron y mejorar las areas donde surgieron problemas. Cuando hay disponibles

amplias metricas de software (capitulo 22) de proyectos previos, las estimaciones se

haeen con mayor seguridad, los programas de trabajo se pueden establecer para evi~ tar dificullades pasadas y el riesgo global se reduce .
... _ .... 010 . . _ _.. fi ....... ""',"'" ""~,,..._ .... ~_ . . . -

..... y

t.smr ".XlIdiIUd cuando sOlo IS pow.Ie II1II aproxinod6n .111 .....

. ,11111
EI riesgo de la estimaci6n se mide por el grado de incertidumbre en las estima~ dones cuantitalivas establecidas para recursos, costos y programa de trabajo. Si eI ambito del proyecto se comprende en forma deficiente 0 los requisitos del proyedo estan sujetos a eventuales cambios, la incertidumbre y el ri esgo de la estimad6n se incrementan peligrosamente. EI planificador y, en forma mas importante, el clienk deben reeonocer que la variabilidad en [os requisitos del sof'tware significa inestabllidad en costa y programa de trabajo. Sin embargo, un gestor de proyecto no debe obsesionarse con las estimaciones Los modemos enfoques de ingenieria del software (por ejemplo, modelos de proceso incremental) asumen una visi6n iterativa del desarrollo. En tales enfoques es posible, aunque no siempre aceptable politicamente. reexaminar las estimadones (cuando se conozea mas informad6n) y modificarlas cuando el cliente cambia los requlsitos.

f[.N"'

......"" me;x
COOOlCa,

-".

estitod.

..... '"

f~

EI objetivo de la planificaci6n del proyecto de sof'tware es proporcionar un marco de tTabajo que permita al gestor estimar razonablemente recursos, casto y progra~ de trabajo. Ademas, las estimaciones deben intentar definir los escenarios de mejor ., peor caso de modo que los resultados del proyecto se puedan acotar. Aunque existe un grado inherente de incertidumbre. el equipo de sof'tware se embarca en un plar establecido como consecuencia de las tareas de planificad6n. Por 10 tanto, el plan sr debe adaptar y aclualizar confonne avance eJ proyecto. En las secciones siguientes .se estudiara cada una de las actividades asociadas con la planificaci6n del proyecto de sof'tware.
I

rmIotrrIt IMW

En el capitulo 25 se presentan ti!:cnicas sistematicas para el analisis del riesgo.

693

~
"
o

Conjunto de tareas para 1a pJanlI1caci6n deJ proyecto

1. htoblecer el6mbilo del proyecto 2. Determlnor 10 foctiblhdod

CON JUNTO DE TAREAS

3 Analizar los riesgos (capitula 25). . . .... Definlr los ~rSOl requeridos . o Detemlloor los IlICUIlO$ hlomOnOS r8qlHlridos. b. Definir los recunos de software r.urilizobles. e.. IOentincor los IlIClInOI del enlomo. blimor CO$Io y eJverzo.
DMcompooer eI

b. DeKlrrolior do, 0 m6s eshmoclOl'les empleando Iomono, pur1tos de fvncioo, Ion~os de prOCIl50 0 (0$0$ de usc. c. Reconcilior los estilOOClones De50rroIlor un pion del proyecto (capitulo 24), O. E~ un conjunlo de Ioreas signi~ootiyo. b. Dehnir uno red de !oreos. c. thor herromienlos de pIonificoci6n pon;! ~rroIor un cronogromo.

probIemo.

d.

Definir meconiWlO$

de $CI9Uimienlo del

prog!"omo de tnJbojo.

EI ambito del software describe las funciones y caraclerislicas que se entregaran a los usuarios finales, los datos que son entrada y salida, el "contenido" que se presenla a los usuarios como consecuencia de emplear el software, as! como el desempeno, las restricciones, las interfases y la confiabilidad que acotan el sistema. EI ambito se defi ne al usar una de Jas dos tecnicas siguienles: I. Despues de una comunicaci6n con lodos los participantes se desarrolla una descripcl6n narrativa del ambito del software. 2. Los usuarios finales desarrollan un conjunto de casos de uso. J Las funciones descritas en el enunciado del ambito (0 dentro de los casos de uso) se evaluan y en algunos casos se refinan para proporcionar mas detalles antes de comenzar la estimaci6n. Puesto que las eslimaciones de costa y programa de Irabajo estin funcionalmenle orientadas, can frecuencia es uti! cierto grado de descomposici6n. Las consideraciones del desempeno abarcan los requisitos de procesamiento

y tiempo de respuesta. Las reslricciones idenlifican los lImites colocados en el software por el hardware extemo, la memoria disponible U otros sistemas exislentes. Una vez identificado el ambito (can la participaci6n del cliente) es razonable preguntar: ,es posible construir software para satisfacer este ambito? ,El proyecto es factible? Con mucha frecuencia los ingenieros de software soslayan estas preguntas (0 gestores 0 c\ientes impacientes los presionan para hacerlo), s610 para verse enredados en un proyecto condenado al fracaso. Putnam y Myers rplJT97aJ abordan este conniclo cuando escriben:

Los casas de U50 se discutierOfl con detalle en las partes 2 y 3 de este libro. Un ca50 de U50 es una

dcscripci6n basada en escenarlo de la interacci6n del usuario con el 5Oftware. desde el punto de vista del usuario.

6. .

PARTE CUATRO GEST!ONOEPROYB::tai DESOFTWARE

wfooiJldo!doI
(Xoyedo as inpof. 1OOle, ptfO IIIU <OOSt de/OCi/ln df k1s

IN]o tcxl.o 1 0 Imaginable es factible, incluso ni en software, tan evanescente como puede pare<:er a los extrai'ios. Por el contrario, la factibilidad del software liene cuairo dimensiones s61idas: TecnoJogia: ,el proyecto es tecnicamente facllble? ,Esta denIm del terrene de
la disdplina? ,1.os defectos se pueden reducir a tal grade que se emparejen con las neee-

sidade5 de la apllcaci6n? Finanzas, ..es financieramente factible?

,Se puede complelar el

desarrollo a un costo que la organizaci6n de software, su c1iente 0 el mercado puedan en-

nesiOOdrs del
negodo as induso

frenlar? Tkmpo, iel proyeclo lIegar.:'t al mercado antes y veneer.:'! a la competenda? ReCUTSaS:

"'-"
lIO!ie~e.

m6s iIfJoitmte. No as /xIeoo coostnM III sistema 0JXO(iKIIl de

ila organizaci6n tiene los recursos necesarios para triunfar?

Putnam y Myers sugieren. acertadamente, que eJ ambito no es suficiente. Una que el ambito se comprende, el equipo de software y otros deben trabajar para deter minar si se puede hacer dentro de las dimensiones anotadas lineas arriba.

Esta

una parte crucial, aunque con frecuencia ignorada, del proceso de estimaci6n .

La segunda tarea de la planificaci6n es la estimaci6n de los recursos necesarios par!' completar el esfuerzo de desarrollo del software. La figura 23.1 muestra las lreI' grandes categorfas de los recursos de ingenieda del software: personal, componer tes de software reutilizables y eJ entomo de desarrollo (hardware y herramientas software). cada recurso se especifica con cuatro earacteristicas: descrtpci6n dt.. recurso; un informe de disponibilidad; cuando se requerira el recurso; tiempo durante el eual el recurso se aplicara. Las ultimas dos caracteristicas se pueden veT COO'l"

RecutJos del

JXOYOC1o.

Numero

Herromiento de $Oftwore

Hobilidode i'>_-",

P"""""I
Ubicocioo

'-.0

Recurso5

__..,f~~r--Ado ,od

Componentes

ors

p.pefiencio
completo

omponenles de eXpefieocio pa rciol

cAPiTuLo 23

ESTlMACI6N PARA PQOYI!C'T05 DE SOFTWARE

69.

una ventana de

ti~mpo.

La disponibilidad del recurso para una ventana especffica

debe establecerse 10 mas pronto posible.

23.4.1 Recursos humanos

EI planificador comienza evaluando el ambito del software y seleccionando las habJlidades requeridas para completar el desarrollo. Se especifican tanto la poslci6n organizacional (por ejemplo, gestor, ingeniero de software ejecutivo) como 1a especialidad (par ejemplo, lelecomunicaciones, base de datos, cliente/servidor). En proyectos relativamente pequenos (unos pocos persona-meses) un solo individuo puede realizar toclas las tareas de ingenieJia del software y consullar con especialislas conforme se requiera. En proyeclos mayores el equipo de software puede estar geograficamente disperso en varios siUos. Aqui se especifica la ubicaci6n de cada recurso humano. El nilmero de personas que requiere un proyeclo de software s610 se delermina despues de que se ha hecho una estimaci6n del esfuerzo de desarro!1o (por ejemplo, personas-mes). Las lecnicas para estimar el esfuerzo se ttalaran mas adelante en este capitulo.

23.4.2 Recwsos de software reutwzables

La ingenieria del software basada en componentes (capilulo 30) enfatiza la reulili -

zaci6n; es decir, la creaci6n y reutilizaci6n de bloques de construcci6n de software [HOO9IJ. Tales bloques, usualmente Uamados componentes, deben calaJogarse para consultarlos con facilidad, estandarizarse para facilitar SU aplicaci6n y validarse para integrarlos facilmente. Bennatan [BEN921 sugiere cuatro categorias de recursos de software que deben considerarse conforme avanza la planificaci6n:

Componenfes ya desorrollados. EI software existente se puede adquirir de un lercero 0 se desarroll6 intemamenle para un proyecto previo. Los CCYO (componenles comerciales ya desarrollados) se compran de un tercero, estan Jislos para emplearlos en el proyecto actual y han side ampliamente validados.

Componl.'!ntcs experimentados. Especificaciones, disenos, c6digo 0 datos de prueba existenles que se desarrollaron para proyectos previos son similares al software qlle se construira para el proyecto actual. Los miembros del equipo de software actual ya lienen experiencia en el area de aplicaci6n que representan dichos componentes En
consecuencia. las moclificaciones que requieran los componentes experimentados seran relativamente de bajo riesgo.

COmponenccs de experienda parcial. Espedficaclones, disenos, c6digo 0 datos de

prueba existentes que se desarrollaron para proyectos previos estan reladonados con el software que se construira para el proyecto actual pero requeriran modificaciones sustanciales. Los miembros del eqwpo de: software actual s610 tienen experiencia limitada en el area de aplicad6n que representan dichos componentes. Por

...

PARTE CUATRO GESTI6N De PROYB::TOS DE SCWTWARE

10 tanto, las modificaciones que requieren los componentes de experiencia pardA tienen un grado considerable de riesgo.

Componenccs nuevos. EI equipo de software debe (onstruir los componentes

software especlficamente para las necesidades del proyecto actual.

lr6nicamente, con frecuencia los componentes de software reutilizables son desp~ ciados durante la planificaci6n, s610 para convertirse en una preocupaci6n impor tante durante la rase de desarrollo del proceso de software. Es mejor especifiar cuanto antes los requisitos de recursos de software. De esta forma se puede lIevar. cabo la evaluaci6n tecnica de las altemativas y puede ocurrir la adquisici6n oportW"ll

23.4.3 Recursos del entorno

El entomo que soporta un proyecto de software. con frecuencia denominado entom

de ingenieria del software (EIS). incorpora hardware y software. El hardware propor

dona una plataforma que soparta las herramientas (software) con que se prodUCCII los productas de trabaja basados en una buena practica de la ingenieria del soft~ re. l PUesto que la mayor parte de las organizadanes de software tienen multiples constituyentes que requieren acceso al EIS, el planificador de proyecto debe prescrr bir la ventana de tiempo requerida por el hard ware y el software. y verificar que recursos estaran disponibles. CUando un sistema basado en computadora (que incorpora hardware y softwan: especializadosj se sometera a ingenieria, el equipo de software quiza requiera acceso a elementos de hardware que estan desarrollando olros equipos de ingenier\i. Par ejemplo, el software de un contador numerlco (CN) utilizado en un tipo cit maquinas-herramienta tal vez requiera una maquina-herramienta espedfica (par ejemplo, un CN de tomo) como parte del paso de prueba de validaci6n; un proyeck. de software para plantilla de pagina avanzada quiza necesite una impresora de calidad en algun punto durante el desarrollo. EI planificador del proyecto de sonw. re debe especificar cada elemento de hardware.

El software es el elemento mas caro de virtual mente todos los sistemas basados computadora. En sistemas complejos, personalizados, un gran error en la estirr.. ci6n del costa puede hacer la diferenda entre beneficio y perdida. Rebasar el c puede seT desastroso para el desarrollador.

-& _ ......,baldn Y(GqilteiKia aeaenla, \a habiliclod pIID em........... mKioI pIID mudiD5 yupos de n.-

alii...,. jniiiIt.........

...-

Otro hardware -cl entorno objetivo- es la computadora en la que el software se ejecutarA cua haya side liberado al usuario final.

cAPiTuLo 23

ESllMACtON PARA PIIO'tICIOI DESOf'TWARE

La estimaci6n del costa y el esfuerzo nunea sera. una ciencia exacta. 4 Demasiadas "anables -humanas, tecnicas, ambientales, polltkas- pueden afectar el costa nnal del software y el esfuerzo aplicado a desarrollarlo. Sin embargo, la estimaci6n del proyecto de soflware se puede Iransfonnar de una practica oscura en una serie de pasos sistematkos que proporcionan estimaciones can riesga aceptable. Para lograr esbmaciones confiables de costa y esfuerzo se tienen "arias opciones: I. Demorar la estimaci6n hasta mas tarde en eJ proyecto (obviamente, jse puede lograr 100 por dento de estimaciones precisas despues de que el proyecto este tenninado ' ) 2. Basar las estimadones en proyectos similares que ya hayan side completados 3. Emplear tecnicas de descomposid6n relativamente simples para generar estimaciones de costa y esfuerzo del proyecto. 4. Utilizar uno 0 ma.s modelos emplricos en la estimad6n de costa y esfuerzo. Desgraciadamenle, la primera opci6n, aunque atracliva, no es practica. Las estimaciones de costas se tienen que proporcianar "por adelanlado". No obstante, se debe reconacer que, mientras mas se espere mas se conacera, y mientras mas se conozca menos probable es que se cometan series errores en las estimaciones. La segunda apci6n puede funcionar razonablemente bien si el proyecto en curso es muy similar a los previos y a otras influencias del proyecto (por ejemplo, el equipo de software, el cliente, las condiciones del mercado, el E1S, las fechas limite) son aproximadamente equivalentes. Por desgracia, la experiencia no siempre ha sido un buen indicador de los resultados futuras. Las opciones restantes son enfoques "jables para la estimaci6n del proyeCIO de software. Idealmente, las tecnicas mencionadas para ,ada opci6n deben aplicarse juntas, cada una empleada como una marca de verificaci6n para la otra. Las tecnicas de descomposid6n asumen un enfoque de "divide y venceras" respecto de la estimaci6n del proyecto de software. AI descomponer un proyecta en funcianes principales y actividades de ingenierfa del software relacianadas, las estimaciones de costo y esfuerzo se pueden realizar en fanna escalanada. Los modelos de estimad6n empirica son uUles para complementar las l ecnicas de descomposici6n y afrecet un enfoque de estimaci6n potencialmente "alloso por su propio derecho. Estos modelos se estudian en la seccl6n 23.7. cada una de las opciones viables de estimaci6n de costa del software sera tan buena como 10 sean los datos hist6ricos en que se basa la estimaci6n. Si no existen datos hist6ricos, la estimaci6n del costa se basara en un fundamento muy lambaleanle. En el capitulo 22 se examinan las caracterfsticas de algunas de las metricas de sofiware que proporcionan la base para los datos hlst6ricos de estimaci6n.
" 8ennalan [BEN03l reporta que oW porc:imto* Io&desiIJrcIirdore de software conllnuan luchando con las esttmaclones y que el lamal'lodd SOIIwane 1 d -..podc desarrollo son muy dltTciles de estimar con predsi6n.

698

PARTE CUATRO GSTI6N IX PROY!CTC6 t:E SOFI'WARE

La estimaci6n del proyecto de software es una forma de resolver problemas; en La

mayoria de los casas, el problema que debe resolverse (es decir, el desarrollo de una

estimaci6n de costo y esfuerzo para un proyecto de software) es muy complejo como

para considerarlo una sola pieza. Por esta raz6n se descompone el problema, recaracterizandolo como un conjunto de problemas mas pequef'ios (y, esperanzadoramente, mas manejable). En el capItulo 21 se examine e\ enfoque de descomposici6n desde dos diferentes puntos de vista: descomposlci6n del problema y descomposici6n del proceso. U: estimaci6n emplea una 0 ambas farmas de partid6n. Perc antes de que pueda rea Ilzarse una estimaci6n, el planificador del proyeeto debe entender el ambito del soft ware que se construira y generar una estimaci6n de su "tamano".

23.6.1
".,

Tamaiio del software

'~

La precisi6n de la estimaci6n de un proyecto de software se manifi esta en varios fae

C&VE
a"lImtIa" del

"'*" .............
cOl'lSlnitl
1& II1IMI chdu,

.. w

LOC. 0 l,Il(I rmtcltl.

tares: I) el grado con el cual el pJanificador ha estimado adecuadamente eJ tamafiL del producto que se censtruira; 2) la habitidad para traduelr la estlmaci6n del lamano en esfuerzo humane, programa de Irabajo y dinero (una funcl6n de la disponihl lidad de las metricas de software conflab!es a partir de proyectos previos); 3) el grade. en eJ cual el plan del proyecto refleja las habilidades del equipo de software; y 4: II estabilldad de los requisitos del producto y el entomo que soporta el esfuerzo ingenierfa del software. En esta secci6n se considera el problema del lamano del software. PUeslo que estimaci6n de un proyecto s610 es tan buena como la eslimacion del tamano dellr.lbajo para realizarlo, el tamana representa el primer gran desafIo del plani tieadot del proyecto. En el contexto de la planiflcaci6n del proyecto, tamanD se retiere a resultado cuantificable del proyecto de software. 5i se asume un enfoque directo. tamana se puede medir en [[neas de c6digo (LOC). 51 se elige un enfoque indlrectu eJ tamano se representa como puntos de funcl6n (PF). PUtnam y Myers [PUT92] sugieren cuatro diferentes en foques al problema tamana:

"

Tamano de "168ica difusa~.

'1IIIIIito

d.1

sohwar. qUI 51 plaNa COISt...ir?

La apllcacion de esle enfoque requiere que el pia.. ficador identifique el tipo de aplicacion, establezca su magnitud en una escaL.. cua litativa y luego refine Ja magnitud dentro del rango original.

Tamano de punta de junci6n. EI planiticador desarrolla estimaciones de las

caracterlsticas del dominio de la informacl6n tratadas en el capItulo IS.

Tamano de componenles estandar. EI software se com pone de varios "com~

nentes estandar", los cuales son diferentes y generieos de una area particu&ar de la aplicacl6n. Por ejemp!o, los componentes estandar de un sistema de informaci6n son subsistemas, m6dulos, pantallas. reportes, programas inter-

17&
iJnser y Trammell (HCleanroom Software Ensineering Reference Model H . SEI TechrucaJ Report CMU/SEI-96-TR-022. 1996) han definido un conjunto de 14 procesos de sala limpia y 20 productos de trabajo que fonnan la base para la SEI CMM de la ingeniena de software de sa1a limpia (CMU/SEI-96-TR-023). Michael Deck de Cleanroom Software Ensineering (www.cleansoll..com) ha preparado una bibliografia acerca de temas de sala limpia. MUchas estan disponibles en Connato descargable La verificaci6n del diseno mediante la prueha de las cOlTecciones se encuentra en el centro del enfoque de sala limpia, Los Jibros de Stavely (lbWard uro-Defect sojh.vare, Addison-wesley. 1998), Baber (Error Fm! sojhvare, Wiley, 1991) Y Schulmeycr (zero Defect software, McGraw-Hili. 1990) abordan la prucba de cOITccci6n en fonna muy detal1ada En Internet hay disponible una amplia variedad de fuentes de infonnaci6n acerca de la inge:nlena del software de sala limpia Una liSla actualizada de rererencias en la world Wide web se puede encontrar en el sitio Web SEPA:

http;//www.mhhe.com/pressman.

CAPITULO

INGENIERiA DEL SOFTWARE BASADA EN COMPONENTES

CONCEPTOS

30

............... sal
CLAVE

caIfiadh

E
ria

duIfkodh . -892
DIC .836

-..

4. rwtfbodOft .194

_rio
..... ......

del cIo.NnIo sa3 tsK ..819

......... .890
......... .105

n el contexto de la ingenierla del software la reutilizaci6n es una idea tanto antigua como nueva. Los programadores han reutilizado Ideas, abstracciones y procesos desde los primeros dlas de la computad6n, pero el enfoque original para la reutilizaci6n era especifico. En la actualidad, los complejos sistemas de alta calidad basados en computadoras se deben construir en un tiempo muy cotto y demanda un enfoque mas organizado de la reutilizaci6n La /ngcmcrfa del software basada en componentes ([SOC) es un proceso que concede particular importancia al diseno y la construcci6n de sistemas basados en computadoras que utilizan "componentesn de software reutilizables. Clements ICLE95] describe asf la ISOC:
ISOCI esta cambiando la forma en quese desarrollan los grandes SIStemas de software_1La ISBC} encama la filosofia de dcomprar, no constru\f" de \a eual son partidarios Fred Brooks y otros. En la misma forma como las pnmeras subrutlnas liberaron aJ programador de pensar acerca de los detalles, Ila ISBq cambi6 eI mteres de programar software por el de componcr sislemasde software. La implementad6n ha dado paso a la lntegraci6n comoccntro del enfoque En $US cimientos esta la suposlC10n de que existe suficiente base comun entre muchas grandes sistemas de software para Justlficar el desarrollo de componentes reutillzables para explotarla y saUsfacerla

'"'"' ..... .II!

.. "~ .897

......." .... 1

Pero surgen varias preguntas. (.Es posible construir sistemas complejos mediante el ensamblado de componentes de software reutilizables provenientes de un cataJogo? <.Esto se puede Jagrar en una forma eficaz tanto en costo como en tiempo? <.E5 posible establecer incentivos adecuados que alienten a los ingenieros de software a reutilizar en vez de reinventar? ,Los gestores tienen buena disposici6n para incurrir en el gasto adicional asociado con la creaci6n de componentes de software reutilizables? <.La blblloteca de componentes es necesaria para lograr que la reutilizaci6n se cree en una forma que sea accesible a qulenes la necesitan? componentes que existen pueden enconlrarlos quienes los necesilen?

,Los

xiones son

8"

110

PARTE CINCO 1lMAS A,VANV.J:JCS D.J INGmIERfA CIl. SOFTWARE

Incluso en la aclualidad, los ingenieros de software luchan con estas y otras preguntas ace rca de la reutilizaci6n de componentes de software. En este capitulo se abordan algunas de las respuestas.

1iI1SIK ........ au .... , _

...

--

En la superficie, la ISBC parece bastante similar a la ingenierla del software orienta-

da a objelos convencionaL El proceso comienza ruanda un equipo de software establece requisitos para el sistema que se construira mediante tecnicas convenclonales de investigaci6n de requisitos (cap[tulo 7), Se establece un disefio arquitect6nico (capitulo 10). pero en lugar de dirigirse inmediatamente hacla tareas de diseno

mas detalladas, eJ equipo examina los requisitos para determinar que subconjunto esta directamente dispuesto para la composici6n, y no para la construcci6n. Es decir, el equipo plantea las siguientes preguntas para cada requisito del sistema:

831

aHay componentes comerdales de linea (COL) disponibles para implementar

los requisitos?
.i.Hay disponibles componentes reutilizables desarrollados inlernamente para

implementar los requisitos?

,Las interfases para los componentes disponibles son compatibles dentro de la arquitectura del sistema que se construira? El equipo tal vez intente modificar 0 eliminar aquellos requisitos del sistema que no sea posible implementar con COL 0 de desarrollo proplol 5i el requisito no puede cambiarse 0 eliminarse se aplican los metodos de insenlerla del software en la
construcci6n de aquellos nuevos componentes que deben desarrollarse para satisfa-

eer los requisitos. Pero para los requisitos que se abordan con los componentes disponibles comienza un conjunto diferente de actividades de ingenierla del software: cualificaci6n, adaptaci6n, composici6n y actualizaci6n. Cada una de estas actividades de lSBC se exam ina con mayor detalle en la secci6n 30.4. En la primera parte de esta secci6n se ha utilizado repetidamente el termino com-

ponente,

aunque falta una descripci6n definiliva del lermino. Brown y Wallnau

[BR0961 sugieren las siguientes posibilidades:

Componente: parte importanle, casi independiente y reemplazable de un sistema que satisface una funci6n clara en el contexto de una arquitectura bIen definida.

Componente del software en ejecuci6n: paquele dina:mico de uni6n de uno 0

ma:s programas gestionados como unidad y a los cuales se tiene acceso por medio de inlerfases documentadas que se pueden descubrir en 1a ejecuci6n.

Componente de software: unidad de composici6n que s610 tiene dependencias

de contexto explfcilaS y especificadas en forma contractual.

Componenle de negodo: la implementaci6n de software de un concepto 0 procesc de negocio

"aut6nomo~.

Adema:s de estas descripciones, los componentes de software tambien se pueden caracterizar can base en sus aplicaciones en el proceso de [SBC. Adema:s de los componentes COL, el proceso de ISBC produce:

COmponentes cualtficados: evaluados por ingenieros de software para garantizar que no s610 la funcionalidad, sino el desempeno, la flabilidad, la faciHdad de usa y olros factores de calidad (capitulo 26) concuerdan con los requisitos del sistema a producto que se construira:

La impikacI6n es que Ia OfJIanizad6n IIJU$la los requ~t05 de su negocio 0 producto de modo que la implementaci6n basada en componmll'Sse ton5ip SIll que sea necesarta la Ingenier1a de personallzad6n Este enroque reduce los C05lOS, ~ d bempO en que el producto l1ega al mercado, pero no siempre es posible

"2

PARTE C INCO '!EMAS AVANZA.JX, EN INGENIrniA DEl. SOFTWARE

componentes adaprados: adaptados para modificar (acci6n tambien Hamada en-mascarar 0 envolver) {BR096] caracteristicas que no se requieren 0 indeseables.

Componentes actualiwdos: sustituyen el software existente conforme estan

disponibles las nuevas versiones de los componentes.

El

proceso de (SBC

se caracteriza de tal forma que no 5610 identifica los componen-

tes candidatos sino que tambien cualifica la interfaz de cada componente, adapta los componentes para eliminar las equivocaciones arquitect6nicas, ensambla los componentes en un estiio arquitect6nico seieccionado y actualiza los componentes confonne los requisites del sistema cambian [BR096]. El modelo de proceso para la
ingenierla del software basada en componentes destaca las pistas paralelas en las cuales la ingenieria del dominio (secci6n 30.3) se lIeva a cabo concurrentemente con el desarrollo basado en componentes. La figura 30.1 ilustra un modelo de proceso tipico que expJ[citamente acopla la ISBC ICHR95j. La ingenieria del dominio crea un modelo del dominio de aplicaci6n que se utiliza como base para analizar los requisitos del usuario en el flujo de ingeniena del software. Una arquitectura generica de software proporciona la entrada para el diseflo de la aplicaci6n. Finalmente, despues de que los componentes reutiIizables se han comprado, seleccionado de bibliotecas existentes 0 construido (co-

PJOCI"O que
apoya 10 lSBC.

i _1 0 ..

lngtnieria d.I dor!tinio Anali. i. del daminio

Desorrollo arquitecl6nico de software

f-

e componente~ i - revtilirobles

"'' ' '"' '

~-An6Ii,i,

L Modo" ~L ,
feloominio

Modo" e5troctural

Dep6tila de artefocla,/ componenles reunlizable,

.......
r--i de compooenles
Calificocibn Actualirod6n

~arquitect6nico

~ companente

Adoploci6n de componente. Composicibn de componenles

=G",,',oc-.;)
del software

L.J..~~VLf 'NOi>o.

..3

rna parte de la ingenierla del dominic), estan disponibles para los ingenieros de software durante el desarrollo basado en componentes. Los pasos de andJisis y diseno arqulttXt6nico definidos como parte del desarrollo basado en componentes (figura 30.1) se pueden implementar en el contexte de un paradigma de diseno abstracto (ADP, por sus siglas en inglesJ [DOG031. Un ADP implica que el modele global del software -representado como datos, funciones y comportamiento (contro!)- se puede descomponer jerarquicamente. Conronne la descomposici6n comienza. el sistema se representa como una colecci6n de marcos de Irabaja arquitect6nico, cada uno compuesto de uno 0 mas patrones de diseno (capItulo 10) . Un refinamiento mayor identifica los componentes necesarios para crear cada palr6n de diseJi.o. En un contexte ideal. todos los componentes se adquirirlan a partir de un dep6sito (aplicando acUvidades de calificaci6n, adapraci6n y composici6n de componenfcs). Cuando se requieren componentes espedalizados se aplica la in genieria de componenles.

La finalidad de la ingmieria 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 aplicad6n particular. La meta global es establecer mecanismos que les permitan a los i ngenieros de software compartir dichos componentes -para reutilizarlos- durante el trabajo en sistemas nuevos y existenles. La ingenieria del dominio incluye Ires gran des actividades: analisis, conslrucd6n y diseminad6n .

....... tW .... tnIfa delllUWltror los IIIpICIos UIIlIlIIIS enbIa w.nas ]lin . . . . . ",. 4 .. _ ........... 1IIUd.s Vshmas, y,an idenlifimr hm1ias de
. . . . . . . . . . tII' ".

f"FIIICI5". ,....,.._11

....II

8 fXOC8SO d"nlM estIlidl.,1SIo s. citJn sun/ocr"n los I*< iii """"', Ii

se puede argumentar que ~la reutilizaci6n desaparecera, no por eliminaci6n. sino por integraci6n en la estructura de la practica de la ingenierla del software [TRA95] .
H

ccmpooenres 181Jrizu_dt_
(1)( .........

Como la reulilizaci6n cada vez tiene mayor auge algunos creen que la ingenieria del dominio adquirira tanta importanda como la ingenierla del software durante la decada siguiente.

.;..,;0,
CD,

decanetdo~

"*""'"

30.3,1 E1 proceso de an6:lisis del dominic

EI enfoque global para el analisis del dominio usualmenle se caracteriza en el contexto de la ingenierla del software onentada a objetos. Los pasos en el proceso se definen como: I. Definir el dominic que se lnvestJgari . 2. categorizar los elementos extraidos del dommio.

tPclri:rlls iii IV"

Ir1mt1IiztxiJn de

",",dt_ doI_,

1m ;uti del trIIi6Sis

-,.,..",

1M

PARTE CINCO

TO.oIAS AVANl.A!X:6 EN 1NGN1ERlA DEL SOFTWARE

,Ote
component.s Identifi<odol durante ,I onOhsis del dominio sera ,ondidatos para Ia r.utillzadon7

3. Recopilar una mueslra representativa de las aplicaciones en el dominio. 4. Analizar cada aplicaci6n en la muestra y definir las clases de anaiisis.

5. Desarrollar un modele de amilisis para las clases.

Es importante advertir que eJ analisis del dominic es aplicable a cualquier paradig--

rna de ingenierla del software, y que se puede aplicar al desarrollo convencional y aJ

orientado a objeles. Aunque los pasos citados ofrecen un modele uti! para eJ analisis del dominic, no brindan una gula para decidir cuttles componentes de software son candidatos a Ia reutilizaci6n. Hutchinson y Hindley [HUT88j sugieren el siguiente conjunto de pre-

guntas pr.kticas como una guia para identificar los componentes de software reutiIizables: c:En las implementaciones futuras se requiere la funcionalidad del componente? c:Cuim comun es la fund6n del componente dentro del dominio? c:Existe dupliddad de la fund6n del componente dentro del dominio? c:EI componente depende del hardware? 5i es asl, c:el hardware permanece invariable entre las implementaciones 0 las especificaciones del hardware pueden trasladarse hacia otro componente? GEl diseno esta 10 suficientemente optimizado para la siguiente implementaci6n?
i5e pueden establecer parametros respecto de un componente no reutilizable

de modo que se vuelva reutilizable? ,!.El componeme es reutilizable en muchas implementaciones s610 con cambios menores? iEs factible la reutilizad6n por medio de la modificaci6n? ,;.Un componente no reutilizable se puede descomponer para producir componentes reutilizables? C:Cuan valida es la descomposici6n de un componente para la reutilizaci6n? Para informaci6n adicional acerca del analisis del dominio vease [ATKOl]. [HElOl] y [PRI93J.

30.3.2 F\1nciones de caracterizacien

A veces es dificil determinar si un componente potencialmente reutilizable es de hecho aplicab!e en una situaci6n particular. Esta determinaci6n requiere definir un conjunto de caractetisticas de! dominio que comparta todo el software dentro de un dominio. Una caractetistlca del dominio define algun atributo generico de todos los productos que existen dentro de eJ. Por ejemplo. las caractetisticas genericas podtian induir la importancia de la seguridad y fiabilidad, el1enguaje de programaci6n, la concurrencia en el procesamiento y muchas otras.

88.
Un canjunto de caracteristicas de dominio de un componente reutilizable se puede representar como IDp). donde cada elemento, DIN. en el (anjunto representa una caracterlstica especlfica del dominic. EI valor asignado a Dpi representa una escala ordinal que indica 1a relevancia de la caracteristica para el componente p. Una escaJa tipica IBAS941 podrfa seT 1: No es relevante si la reutilizacl6n es apropiada. 2 : Relevante s610 en circunstanclas inusuales.

3: Relevante : el componente se modifica para usarl0, a pesar de las diferencias.

4: Claramente relevante, y si el nuevo software no tiene esta caracteristica, la reutilizacl6n sera ineficiente pero tal vez sea p05ible.
5: Claramente relevante, y sl eJ nuevo software no tiene esta caracleristica , la reutilizad6n sera ineficiente y la reutilizaci6n sin dicha caracteristica no se comienda. Cuando dentro del dominio de aplicaci6n se conslruira nuevo software, w, se deriva para el un conjunto de caracteristlcas del dominio. Enlonces se comparan DJII y D... para detenninar si el componenle existente p se reutiliza con eficacia en la aphcad6n w. Aunque el software que se construira claramente existe dentro de un dominio de aplicaci6n, los componentes reutilizables en el se deben analizar para determinar su aplicabilidad. En algunos casos (con suerte, un numero Iimltado)' "reinventar la rueda" tal vez sea la mejor elecci6n en cuanto a COSIO.
re~

30.3.3 Modelado

~ctura1

Y punt"" de

~ctura

Cuando se aplica el analisis del dominio el analista busca los patrones repetitivos en las aplicaciones que residen dentro de un dominio. EI modelado estructural es un enfoque de ingenieria del dominio basada en patrones que funciona bajo la premisa de que cualquier dominio de aplicad6n liene patrones repelitivos (de fund6n, datos y comportamiento) que lienen un potencial de reutilizad6n. Cada dominio de aplicaci6n se caracteriza mediante un modelo estructural (por ejemplo, los sistemas avi6nicos de las aeronaves difleren enonnemente en especificaciones, pero todo el software modemo en este dominio Ilene el mismo modelo estructural) . Por 1 0 tanto, el modelo estructural es un estilo arquitect6nico (capitulo 10) que puede y debe reutilizarse mediante las aplicadones dentro del dominio. McMahon (MCM95! describe un punto de estructura como "una estructura dislinta denlro de un modele estructural- Los puntas de estructura tienen Ires caracterislicas distintas:

,IWH_

............
_1

,... H

fnIctw. YeMIts

1. Un punto de estructura es una abstracci6n que debe tener un numero Iimitado de instandas. Ademas, Ia abstracci6n debe recurrir a traves de las aplicadones en el dominio. De otro modo no se justifica el costa de verificar, documentar y diseminar el punta de estructura

...
~

PARTE CINCO 1'lMAS AVANZAOCIS EN INGENIER!A DEL SOFTWARE

2. Las reglas que rigen el uso del punto de estructura deben comprenderse con facilidad. Ademas, la interfaz para el punto de estructura debe ser relativa-

mente simple.
3 . EI punto de estructura debe implementar la ocultaci6n de infonnaci6n al aislar toda la complejidad dentro del rnisrno punto de estructura. Esto reduce la complejidad percibida del sistema globaJes canjunlo. Como un ejemplo de puntas de estructura como patrones arquitect6nicos de un sistema, considerese eJ dominic de software de sistemas de alarma. Este dominic puede abarcar sistemas tan simples como HogatScguro (descritos en capitulos anterioresj o tan complejos como el sistema de alarma para un proceso industrial. Sin embar-

~'%>.

C&VE
Un p!.IlIO de estrucIIIU
IS G'IlIklgo 0 11111111611
de~!pIse~

de &rKontHlI repetidct(00 III

menlll en duma espe6

.iooes

fico.

se encuentra un conjunto de patrones estructurales predecibles interjaz que Ie pennite al usuario interactuar con el sistema; un mecanismo de establecimiento de limites que Ie permite al usuario establecer limites a los parametros que se mediran; un mecanismo de gestion de sensores que se comunica con todos los sensores de supervisi6n; un mecanismo de respuesla que reacciona a la entrada
go, en cada caso una proporcionada por el sistema de gesti6n de sensores, y un mecanismo de control que Ie pennite al usuario controlar la fanna en la que se realiza la supervisi6n. cada uno de estos puntos de estructura minios de aplicaci6n (STA94[ ;

se integra en una arquitectura de dominio.

Es posible definir puntos de estructura genericas que trasciendan diferentes do.

Aplicacion frontal (Clientc): la GUI que incluye todos los menus, paneles y entradas y ordena las funciones de edici6n.

Bases de datos: el dep6sito para todos los objetos relevantes respecto del dominio de la apJicaci6n.

MOlor de calculo: los modelas numericos y no numericos que manipulan datos.

Funcion de generod6n de infonnes: la funci6n que produce salidas de cualquier

tipo.

Editor de aplicaciones: el mecanismo para personalizar la aplicaci6n respecto a

las necesidades de usuarios especlficos.

Los puntos de estructura se han sugerido como una alternativa a las IIneas de c6digo y puntas de funci6n para la estimaci6n del costo del software (MCM95). En la secci6n 30.6.2 se presenta una breve descripci6n del empleo de los puntas de estructura en la cotizaci6n.

El

desarrollo basado en componentes IDBC) es una actividad de [SBC que ocurre en

paralelo con la ingenieria del dominio. AI aplicar los metodos de diseiio de analisis y arquitect6nico ya tratados en este libra, el equipo de software retina un estilo ar-

887

quitect6nico apropiado para el modelo de

construirA.2

an~lisis

creado para Ja aplicaci6n que se

Una vez que la arquitectura ~ ha establecido, deben agregarsele componentes que I) esten disponibles en bihliotecas de reutilizaci6n 2) sean disei'lados para satisfacer las necesidades personales del cliente. Por lanlo, el nujo de tareas para el desarrollo basado en componentes tiene dos trayectorias paralelas (figura 30 I ). CUanda

los componentes reutilizables esttm disponibles para su potencial integraci6n en la arquitectura lienen que cualificarse y adaptarse. Cuando se requieren nuevos comp<mentes es preciso disenarlos. Entonces los componentes resultantes se "componen~ (integran) en la plantilla arquitect6nica y se prueban en forma minudosa.

30.4.1 Callficacl6n, adaptac16n y composlci6n de componentes

Como ya se ha visto, la ingenierfa del dominic proporciona la biblioteca de componentes reutHizables indispensables para la ingenierla de! software basada en componentes. Algunos de estos componentes se desarrollan especialmente para el dominic, otros pueden extraerse de aplicadones existentes e incluso otros pueden adquirirse de terceras partes. Desgraciadamente, la existenda de componentes reutilizables no garantiza que puedan lntegrarse con facilidad 0 eficada en la arquitectura elegida para una nueva aplicaci6n. Por esta raz6n se aplica una sucesi6n de actividades de desarrollo basada en componentes cuando se propane el uso de un componente.

_"'_f.1a ,aIf'ICCtdO. lit

(I

.. ,.....

...,....III?

canncacl6n de componentes. Esta actividad garantiza que el componente candidato realizartl la funci6n requerida, "encajartl" adecuadamente en el estilo arquitect6nico que especHica el sistema y mostrartl las caracterfsticas de caUdad (por ejemplo, desempeno, fiabilidad, facilidad de uso) que requiere la aplieaci6n. La descripci6n de 1a interfaz suministra informaci6n uti! aeerca de la operaci6n y la utilizaci6n de un componente de software, pero no proporciona toda la informaei6n que se requiere para determinar si un componente propuesto puede, en la prtictiea, reutiJizarse con eficacia en una aplicaci6n nueva. Entre los muchos factores eonsiderados durante la cualificaci6n de componentes estan [BR096J : interfaz de programaci6n de la aplicaci6n (IPA); herramientas de desarrollo e integrad6n que requiere el componente; requisitos de tiempo de ejecuci6n, que incluyen uso de recurses (por ejemplo, memoria 0 almacenamiento), Uempos 0 velocidad y protocolo de red; requisitos de servicio, que incluyen interfases de sistema operativo y apoyo de otros eomponentes; caracteristicas de seguridad, que incluyen controles de acceso y protocolos de autenUcaci6n; suposidones de diseno anidado, que inc1uyen el empleo de algoritmos numericos 0 no numericos especlficos; y manejo de excepciones.

2 Se debe senalar que en el estilo ~-.mOlWX)t:on frKuencia ;nnuye el modelo estructural generico creado durante ]a Ingenietia dd doano fw.e iii fiIKura JO II

au

PARTE CINCO nMAS AVANIJ>.I:a EN INGIlNlERlA DEl SOF1WARE

cada uno de estos factores es relativamente sencillo de evaluar cuando se p~ nen componenles reuUlizables que se han desarrol1ado especialmente para la apltcacion. Sin embargo, es mucha mas dificil determinar 1a operatividad inl ema de los CDL 0 de componentes de provenientes de terceros porque la (mica informaci6n dis-ponible tal vez sea la misma especificaci6n de 1a interfaz.

Adaptad6n de componentes. En un contexto ideal, la ingenieria del domiruo

crearla una biblioteca de componentes que podrfan integrarse filcilmenle en una arquitectura de aplicaci6n. La implicaci6n de la "integraci6n fad!" es que \) se han im-

plementado metodos consistentes de gesti6n de recursos para todos los componentes

en la biblioteca, 2) existen actividades comunes como la gesti6n de datos para tados los eomponentes, y 3) se han implementado interfases dentro de la arquitectura y con el enlomo extemo en una forma consistente.

flo.SIlo"
Adem:I:s de Om si
es~elrosto
de~",,*,

En realidad, incJuso despues de que un componente se ha cualificado para emplearlo dentro de una arquitectura de apJicad6n, es posible que haya conOictos en una 0 mas de las areas indicadas. Estos conflictos usualmente se evitan utilizando una tecnica de adaptaci6n llamada encubrimienlo de componeme [BR096j. Cuando Wl equipo de software tiene pleno acceso al disefio interne y el c6digo de un compo-nente (con frecuencia no es el case cuanda se utili zan componentes COL) se apliea el

de""-_ ..... *'1m< *' M>

" ds:sfm;IIo Sf fJJf" ,." 1IJIll'M till tMm.

reuflizOO6n,

,,~

-,."..., ....,'"

encubrimiemo de caja blanca. AI igual que su conlraparte en la prueba de software

(capitulo 14), el encubrimiento de caja blanca examina los detalles de procesamiento intemo del eomponente y haee modificadones en el c6digo para eliminar euaJquier c:onflicto, EI cncubrimienfo de caja gIis se aplica cuando la biblioteca de componentes proporciona un lenguaje de extens16n de eomponente 0 lPA que permite eliminar 0 enmascarar los conflictos. EI encubrimiento de caja negra requiere la introducci6n de pre y posprocesamiento en la interfaz del componente para eliminar o enmascarar los conflict os. El equipo de software debe delerminar si e1 esfuerzo requerido para encubrir adecuadamente un eomponente esta justificado 0 si, en 1ugar de ello, debe disenarse un componente personalizado (designado para eliminar los connictos encontrados). composlcl6n de componentes.
La tarea de composici6n de componente en-

...

sambla componentes cualificados, adaptados y diseflados con el fin de agregarselos a la arquilectura establecida para una aplicad6n. Esto se logra estableciendo una infraestructura que una los componentes en un sistema operativo. La infraestructwa (usual mente una biblioteca de componentes especiaJizados) proporciona un mode1 0 para coordinar los eomponentes y los servicios espedficos que permiten que los componentes se coordinen mutua mente y realicen tareas comunes. Entre los muchos mecanismos que existen para crear una infraestructura eficaz hay un conjunto de cuatro "ingredienles arquitect6nicos" IADL95) que debe estar presente para lograr la composici6n de componentes: Modelo de intercambio de datos. Respecto de los componentes reutili zables se deben definir mecanismos que permitan que los usuarios y aplicaciones inlerae-

889

~,.....Io

tuen y transfieran datos (por ejemplo, arrastrar y saltar, cartar y pegar) . Los mecanismos de intercambio de datos no s610 penniten la transferenda de datos humano-soflware y componente-componente, sino tambien Ja transferencia entre recursos del sistema (por ejemplo, arrastrar un archivo a un ieono de impresora para imprimirlo) .

dill."., , .., ....

gr. " (..,.sl-

Automatlzad6n. Se deben implementar varias herramientas, macros y guiones para facilitar la interacci6n entre componentes reulilizables.

Almacenamiento estructurado. los datos heterogeneos (por ejemplo, datos

graficos, Voz, video, texto y datos numericos) que contiene un "documento <:om-

puesto deben estar organizados y orrecer acceso como una sola estruclura de datos y no como una colecci6n de archivos separados. "Los datos estructurados conservan
U

un Indlce descriptivo de estructuras anidadas por las cuales las apticaciones pueden navegar libremente para ubicar, crear 0 editar contenidos de datos individuales segun ordene el usuario final" [ADL95j.

Modelo de objeto subyacente. EI modele de objeto asegura que los componenles desarrollados en diferentes lenguajes de programaci6n y que residen en diferentes plataformas pueden ser interoperables. Es declr, los objelos deben ser capaces de comunlcarse a traves de una red. Esto se lagra si el modele de objeto define un est.i.ndar para la interoperabilidad de los componentes. Puesto que el impacto potencial de la reutilizaci6n y la ISse sobre la industria del software es enarme, varias grandes companias y consorcios industriales han prapuesto esttmdares para el software de camponentes: OMG/CORBA. EI Grupo de Gesti6n de Objetos (OMG, por sus siglas en ingles) ha publicado una arquitectura cornun de distribuci6n de objetos (CORBA: por sus siglas en Ingles). Un distribuidorde objetos (ORB, por sus siglas en ingles) proporciona una diversidad de servicios que permiten que los componentes reutilizables (objetos) se comuniquen can otros componentes, sin importar su ubicaci6n dentro de un siste-

ma.
COM de Microsoft. Microsoft ha desarrollado un modelo de objetos para componentes (COM, por sus siglas en ingles) que ofrece una especificaci6n para utilizar componentes producidos por varias empresas dentro de una sola aplicaci6n que carra baja el sistema operati vo Windows. EI COM incJuye dos elementos: interfaces COM (implementadas como objetes COM) y un conjunto de mecanlsmos que regisIra y pasa mensajes entre interfaces COM. COmponentes Sun JavaBeans. El sistema de camponentes JavaBeans es una infraestructura de ISBC portalil e independiente de la plataforma que uliliza y desarroJla empleando el lenguaje de programad6n Java. EI sistema de componentes JavaBeans incJuye un conjunto de herramientas, lIamado Kit de Desarrollo Bean (SDK,

Bean Development Kif) , que permite a los desarrolladores I ) analizar c6mo funcionan los Beans existentes (componentes), 2) personalizar su comportamiento y apariencia. 3) establecer mecanismos para coon:hnac:i6n y comunicaci6n, 4) desarrollar

090

PARTE CINCO

TEMAS AVA1llJ\fJCX> DI ~

co. SOFTWARf:

Beans personalizados para usarlos en una aplicaci6n especlflca, y 5) probar y eva-

... 10--_ _I .,.....,1MsI

a.. .... .
batslll...l t ....

luar el comportamiento Bean . ,CuAI de estos esttmdares dominartl 1a industria? En este momento no existe una respuesta sencilla . Aunque muchos desarrolladores han adoptado uno de los estandares, tal vez las grandes organizaciones de software quieran optar por uno de los tres estandares. segun las categorias de aplicaci6n y las plataformas que eHjan .

Arqultectura comlin de dtsb1budon de objetos los si$lemos d"'te-sefVidor:le implementon 10 que WI ocomodon los peticiones de objelo5 0 10 Iorgo del emplenado c.omponenles (objekn) de IIOftwore ~~ dienle-servidor. que deben ser capoces de interoctuar unos con oIros dell PUMIo que los peticiooes de objetol 0 troves de 10 red Iro de una solo m6quino (diente 0 ~dor) 0 0 troves de ocurnlfl eo liempo de eiecuci6n, se debe esloblecer un me10 red. Un dislribuich- eM obiefos (ORB) es micklJewore conismo para olmocenor 10 dMcripci6n de objeto de modo (5Ohware penooolizodol que permite que un objeto resique 10 inlormoci6n periinente ocerca del objelo y w ubico den", en un diente _Ie un lTI(Ir1K1je a un metoda que e$l6 ci6n esten di~ibles cuondo MI nec!Hile. EI ~Io de
encopsulodo en un objelo residente en un servidor. En esencio, eI ORB inlemiplCl eI lTI(Ir1$Oje 'I rnorlejo los octividodIH de cc:lrmInicoci6n y coordinoci6n ~as poro encontrar eI objeto al cool foe dirigido eI lTI(Ir1$Oje, invoc:o w m6/odo, po$O los dolos aPfClPiocm a l objeto y tro nsfiere \0$ doIos rewltontres de vuello 01 objelro que gener6 primero eI mensoje. CClQQA. COM V ..1c""oQ.oru i~lon unolilosofla de clislribWdor de ob;eIm. En !Hie rocuocIro CORBA Ie IIKItO poro ilush"or eI middl.wore ORB. En Ie figura JO.Z se Ilusrro Ie esrrvcturo bOsica de una u'<!"'t.<;.tu, .. CORBA. Cuaodo CORBA .. impl......10 en un sistema diente-servidor, los objetos servidores ambos Ie definen ulilizondo un lengoo;' de descripci6n de interfose (101., interface dewiption /onguogel. un lengooje de declorociones que permi'" que un ingeniero de KIftwofe defino objetos, otribulos, metodos y los mensajes que Ie requien poro invocanos. Poro que un objeto resident. en eI dienle ocornode uno petici6n poro un metoda resiclente en eI MI(vidor $a crC!(ln stubs (odoplodores) deilDL en el elien" y eI los stubs proporcionon 10 compuerkl 0 troves de

interfoz lagro eslo. cuondo uno apicoci6n en eI dianle debe ill'lOClJr un metoda ubicodo denim de un objelo en CUCllqu~ porte del sisiemCl, CORBA utilizg inY'IXClCi6n din6mico poro 1) obleroer inlormoci6n periinenll!l ocer<:a del m411odo deseado a pornr del dep6silo de interfaz, 2) creor uno eMruduro de dolos con por6metro! que posor6n 01 obieto, 3) cteClr uno pelici6n pora eI objelo, y .4) invocor 10 perici6n. Entonces 10 perici6n poso al nUdeo del ORB -uno pone del sislemCl operntivo de 10 red Mj)eCI'fico de 10 implementoci6n que gesliono los peticiones- YMI cumple 10 peticiOn. lei petici6n poSCI a trclYfIs del nUdeo Y 10 proceSCI el MIl" vidor. En eI sitia de esle un odoptodor de objelo oImoceno inlormoci6n de 10 close y eI objeto en un dep6silo de interfez resident. en eI servidor, ClCepkI y QlHtiono los petitioroes que IIegon del dieme y reoIiw uno divenidod de CItros Nnciones de QlHriOn de objet05. En eI servic:Io.- srubs dellDl similores a los definidos en 10 m6quino diente se utilizon como 10 inloeffaz por~ 10 impiementoci6n del objelo reol r.. siden" en eI sino del servidof".

30.4 .2 lngenleria de componentes

Como ya se indic6 en este capitulo, el proceso de lSBC alienta el uso de componentes de software existentes. Sin embargo, hay ocasiones en que los componentes deben disef'iarse. Es decir. se deben desarroilar nuevas componentes de software e integrarse can los COL ya existentes y con los componentes de desarrollo propio . PlIesto que los nuevos componentes se integran a la biblioteca propia de componentes reutilizables, deben diseliarse para su reutilizaci6n.

'91

Arquilactura
CORBA """"".

No hay nada magico en la creaci6n de componentes de software reutilizables. Los conceptos de diseno tales como abstracci6n. ocultaci6n. independencia funcional. refinamiento y programaci6n estructurada. junto con metodos orientados a objeto, pruebas de SQA y metodos de verifi caci6n de correccl6n, todos contribuyen a la creaci6n de componentes de software reutilizables.l En esta secci6n no se volveran a tratar estos temas. Mas bien, se consideraran los temas especlficos de la reutili za~ d6n que complementan las practicas s6lidas de ingenierla del software.

30.4.3 Anld1sts Y dlseiio para 1a reulll1zad6n

El modele de analisis se analiza para determinar aquellos elementos del modele que apuntan hacla los componentes reutilizables existentes. El problema es extraer informacJ6n a partir del modele de requisitos en una forma que conduzca a la "concordancia de especificaciones 5i la concordancia de especificaciones produce componentes que se ajustan con las necesidades de la aplicaci6n actual, el disef\ador puede extraer dichos componentes de una biblioteca (dep6sito) de reutilizaci6n y aplicarlos en el diseno de nuevos sistemas. 5i no encuentra componentes de dlseno, ellngeniero de software debe aplicar metodos de diseno convencional u 00 para crearJos. En este punto -cuan do el disenador comienza a crear un nuevo componente- se debe considerar eJ diseno JX1m Ja reutiHzoci6n (DPR). Como ya se indic6, el DPR requiere que el ingeniero de software aplique s6lidos conceptos y principios de disei\o de software (capitulo 9). Pero tambien se deben
H

3 Par.l aprcnder mas acerc.a de estos mncepI05 'fII!lwt5e las parteS 2 Y5 de este libro.

a..

PARTE CINCO

TEMAS A.VANVJX:1S. EN INGENlEldA DEI. SOFlWARE

f"-JIJO.
811ff1 .... '" .,. /'oofe tiftl cwnOO los crxnpooentes deben BStrJr eo ilf9ffaz a ~
fBgIOOos (00 sistemas

considerar la caracteristicas del dominic de la aplicaci6n. Binder IBIN93j sugiere varios lemas clave~ que forman una base para el diseno destinado a 1a reutilizaci6n .

Datos estandar . se debe investigar el dominic de la aplicaci6n e identificar las

estructuras de datos globales (por ejemplo, estructuras de archivos 0 una base de datos completa) . Entonces se pueden caracterizar lodos los componentes de diseno para aprovechar dichas estructuras de datos cstandar.

herhdos aCOO WtIi! iIJerfuJ sa .,.

mos~(LfO(Jto

Pro tocolos de interfaz estandar. Se deben establecer tres niveles de protoco10 de interfaz: 1a naturaleza de las interfaces inlramodulares, el disei\o de interfaces tecnicas (no humanas) externas y la interfaz hombre-maquina . Plantillas de programa. EI modelo de eslruclura (secci6n 30.3.3) sirve como una planlilla paTa el diseno arquitect6nico de un programa nuevo. Una vez establecidas las interfases, los datos estandar y las plantBlas de programa, e\ disei'iador tiene un marco de tTabajo en el que puede crear el diseno. Los nuevos componentes que se ajusten a este marco de tTabajo tienen una mayor probabilidad de que se Jes reutilice posteriormente.

~ y,roJOCDlos

Considerese una biblioleca universitaria. Cientos de miles de libras, publicaciones perilxJicas y otras fuentes de informaci6n estan disponibJes para utilizartos. Pero el ingreso a dichas fuentes requiere desarrol1ar un sistema de c!asificaci6n. Para navegar por este gran volumen de infonnaci6n, los blbllotecarias han definido un sistema de clasificaci6n que incluye el c6digo de clasificaci6n de la Biblioteca del Congreso (en los Estado5 UnJdo5 de America). palabras clave, nambres de autor y otras entradas de indice . Todo esto pennite que el usuario encuenlre rapida y fticilmenle la fuente requerida . Ahara, cansiderese un gran depOsito de camponentes. Cientos de miles de com ponentes de sofiware reutilizable se hallan en el. Pero, ,i,c6mo encuentra un ingeniero de software el componente que necesita? Para responder esta pregunta surge otra: ,c6mo se describen los componentes de software en lerminos clasificables y sin ambigOedades? Estas son preguntas diftciles y todavla no se ha desarro1!ado una respuesta definitiva. En esta secci6n se exploran las tendencias actuaies que penniliran a los futuros ingenieros de software navegar entre las bibliolecas de reutilizaci6n.

30.5.1 Oescripcton de los componentes reutwzables

Un componente de software reutilizables se describe en muchas formas, pero una descripci6n ideal incluye 10 que Tracz rrRA901 ha llamado el modeJo JC: concepto, contenido y contexto.

En general, se deben realizar preparativos para el DPR como parte de)a ingenieria del dominio (secd6n .30.3)

,.3
El conceplo de un componente de software es Nuna descripci6n de 10 que haee el componente~ [WHI9S). La interfaz con el componenle esta completamente descrlta y Ja semantica -representada dentro del contexto de las precondiciones y las poscondiciones-, identificada. EI concepto debe comunicar la intenci6n del componente. EI comen/do de un componente describe c6mo se construye el concepto. En esencia, el contenido es informaci6n QCulla para los usuarios habituales y que 5610 necesilan conocerla quienes quieran modificar 0 probar eJ componente. El contexto situa un componente de software reutilizable en su dominio de aplica-

biHdad. Es decir, al especificar las caracteristicas conceptuales, operativas y de

implementaci6n el contexto pennite que un ingeniero de software encuentre el componente apropiado para satisfacer los requisitos de la aplicad6n. Para que sean utiles en la practica, concepto, contenido y contexto se deben 1radudr en un esquema de especificaci6n concreto. Se han escrito docenas de ensayos y artlcu[os ace rca de [os esquemas de clasilicaci6n para componentes de software reutillzables (por ejemplo, [LUC01] y [WHI95] contienen bibliografias extensas) Los metodos propuestos se pueden clasificar en tres grandes areas: metodos de biblioteconomia y de ciencias de [a comunicaci6n, metodos de inteligencia artificial y sistemas de hipertexto. La gran mayorla del trabaja realizado hasta la fecha sugiere el empleo de metodas de bibliateconomia para la clasificad6n de componentes.
La figura 30.3 presenta una taxonamia de los metodos de indexaci6n en la biblio-

vocabularios contro/ados de indexad6n limitan los terminos 0 sintaxis con que se ciasifica un objelo (componente) Los YOCIJbu/arios de indexad6n no contro/ados no ponen restricdones en la naturaleza de la descripci6n. La mayoria de los
tecanomla. Los esquemas de clasificad6n para los componentes de software se incluye en lres categorias. Clasiflcaci6n enumerada. Los componentes se describen mediante una estructura jerarquica en la cual se definen las clases y los niveles variables de subclases de los componentes de software. La estructura jerarquica de un esquema de c[asificad6n enumerada facilita comprenderlo y utilizarlo. Sin embargo. antes de conslruir una jerarqula se debe llevar a cabo la ingenierla del dominio de modo que haya sufidente conocimiento de las entradas adecuadas en la jerarqula. Clasiflcaci6n por facetas. Se analiza una area del dominio y se identifica un conjunlo de caracterlsticas descriptivas basicas. Estas caracterlslicas, lIamadas face-

ras, entonces se clasifican segtin su importanda y se coneclan con un componente.

Una faceta describe la funci6n que el componente realiza, los datos que se manipulan, el contexte en el que se aplican
0

cualquiera o tTa caracleristica EI conjunlo de

facetas que describe un camponente se denomina

descriptor de facelas . En

general.

la descripci6n par facetas se limita a no mas de siete u acho facetas. Clasiflcad6n de valo res y atributos. Un conJunto de atributos se define para todos los componentes en cierta area de] domink> Enseguida se asignan valares a dichos atributos en una forma muy similar a 1a c1asificaci6n por facetas De hecho.

...
Taxonomia de los m&todos de lndeXacl6n
[FRA94].

PARTE C INCO

'lEMAS AV~

EN INGENIERiA DEL SOt"lWARE

Indexoci6n de vocabularies

Controlado

Oss<:ontrolodo

Par elenas

Polobro doV1l

Terminos extrofdos dellexlo

Terminal no

Enumerodo

Por meatas

extroidos del lexlo

Con sinloxis

Sin sintaxis

demoteria Okcionario - - - - - '

la clasificaci6n de valores y atributos es similar a 1a clasificaci6n por facet as, con las siguientes excepciones: 1) no se limita el numero de atributos que se pueden utilizar, 2) no se asignan prioridades a los atributos, y 3) no se utiliza la funci6n diccionario. Can base en un estudio empfrico de cada una de estas tecnicas de clasificaci6n,

frakes y Pole [FRA94] indican que no existe una tecnica claramente "mejor" y que
"ningun metoda se desempei'i6 mas que moderadamente en Ja eficacia de busqueda ... " Pareceria que todavia falta reallza mas trabajo en eJ desarrollo de esquemas de clasificaci6n eficaces para bibliotecas de reutilizaci6n.

30.5.2 Elentorno de reut1l1zaclon

La reutilizaci6n de componentes de software debe apoyarla un entomo que incluya

los siguientes elementos: Una base de datos de componentes capaz de almacenar componentes de software, asi como Ja informaci6n de clasificaci6n necesaria para recuperarlos. Un sistema de gesti6n de bibliotecas que ofrezca acceso a la base de datos. Un sistema de recuperaci6n de componentes de software (por ejempio, un dislribuidor de objelOS) que pennita que una ap][caci6n clienle recupere componentes y servicios del servidor de la biblioteca. Herramientas de [sse que apoyen la integraci6n de los componentes reutilizados en un nuevo diseiio a implementaci6n. Cada una de estas funciones interactua con 0 estA incorporada en los confines de una biblioteca de reutilizaci6n.

.95
La biblioteca de reutilizad6n es un elemento de un dep6sito de soflware mayor (cap[tulo 27) y proporciona medios para el almacenamiento de componentes de soft~

ware y una amplia gama de productos de trabaja reutilizables (por ejemplo, esped~ ficaciones, disefios, patrones, marcos de trabaja, fragmenlos de c6<ligo, casos de prueba, gulas de usuario). La biblioteca contiene una base de datos y las herramien~ tas necesarias para consultarla y recuperar componentes de ella. Un esquema de clasificaci6n de componentes (secci6n 30.5.1) sirve como base para consultar la bi-

blioleca.
Las consultas usualmente se caracterizan mediante e[ elemento contexto del mo-

dele 3C ya descrito en esta secci6n. 5i una consulta inicial resulta e n una exlensa !isla de componentes candidatos, la consulta se retina para reducirla Entonces se extrae la informaci6n de concepto y contenido (despues de hallar los componentes candidatos) para auxiliar al desarrol!ador en la selecci6n del componenle apropiado Una descripci6n detallada de la eSlructura de las bibliotecas de reutilizaci6n y de las herramientas que las gestionan es mejor dejarsela a las fuentes especializadas en la materia. El lector interesado obtendra mayor informaci6n consultando IFISOOJ y IUN95! .

...

IS8(wpullil_

.....II~
cW ... _I.

Desarrollo basado en componentes

Componenl Monoger, dosorrollodo par Fkrshline (www.fIg~line.com), -.s uno opIioxia... que pCIloibililo, pro~ 1 mide 10 reutilizoci6n de tomponenles de

Objetivo: Auxilior efl eI modelodo. diseno, revi,ia.... integroci6n de 105 componenle$ de soft.. wore como parte de un sistemo 1nO)"CII".

Mec:anica: La mec6niol de ~ herromienlos yoriQ. En generoJ, los herramient!;J$ de DB( ouxilion en uno 0 mas de los sigulentes capac:idades. lI$pIIcificocia... 1 modeIodo de 10 arquiteduro del sofrwgre; ne;Milj)lXi6n 1 wlecxi6n de len cornponentes de softwore disponibles; integroci6n de cornponentes.

.....

~.

Sektct Componenl Fodoty, desorrollodo per Select Busi

ness Solutions (www.seIecti.com/produds), e! un conjunlo inlegrodo de prcxIuclo$ poro eI diseno de softwore, feIIisi6n de diseiio, eewa... de servicios 1 componenle!, gMti6n de requisilo$ 1 generoci6n de c6digo SoItware Through PiduresACD, dislri~idc por Aonix Iwww.oonix.coml, permit'll eI modelodo integrolempIeondo UML para 10 orquitectur<:J que rige eI modele OMG; un enfoq\ifl para 10 ISBC abierla e ir.dependienIe de 10 empreso

Herromienta. rep,..entattva. 1
CamponenlSoorce Iwww.companenISCIUrce.comlproperciooo un amplia .erie de componentes 11 herramiefllos) de soltwore COl apoyado en muchos esl6ndores de componenles diferentes.

30_6

ESgNON'A p i LA

ISIC

La ingenierfa del software basada en componentes tiene un atractivo intuitivo. En

teoria, debe proporcionar a una organizaciOn de software ventajas en cuanto a cali-

5 Us h.erramienlas expuestas SOia le,.~ UNllftUeSUiI de esta catcgatia En la mayoria de los casos los nambres de las mismas 5011 naan:.as ' ......... por ~ ~IVOS dcsarrolJadorcs

...

PARTE CINCO

m.v.s AVAHl.ADC6 EN INGENlERIA DEL DTWARE

dad y oportunidad. 10 que debe traducirse en ahorros. Perc, iexisten datos reales que

--.

apoyen esta intuici6n?

La respuesta a esta pregunta primero requiere entender 10 que en reaUdad se puede

Iri:IS !DO lloec y10\;

CD. Sf p.IIdt . . . .

~- ....

reutilizar en un contexte de ingenierla del software y luego cuales son en realidad los costos asociadas con la reutilizaci6n. Como consecuencia, sera posible desarroliar un analisis costo~be n efido para la reutilizaci6n de componenles .

30.6.1

Impacto soble la caUdad, la productividad V el costo

Existen numerosas evidencias, a partir de estudios de case industriales (por ejemplo,

[Au.o2J, [HEN95J, IMCM95J), que indican la posibilidad de derivar sllstanciales beneficios de negocios a partir de la reulilizaci6n vigerosa del software. Mejoran la caUdad del producto, la productividad de desarrollo y el costo global.

caUdad. En un entomo ideal, un componente de software que se desarrolle para reulilizaci6n se verificarla como correClO (vease el capitulo 29) y no contendrla defectos. En realidad, la verificaci6n 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 reutilizad6n los defectos se encuentran y eliminan, Y, como resultado, mejora la caUdad del componente. Con el liempo el componente queda virtualmente Ubre de defectos. En un estudio realizado en Hewlett-Packard. Um [LIM94) report6 que la tasa de defectos para el c6digo reutilizada es de 0.9 defectas par KLDC. mientras que la tasa para software desarrollada recientemenle es de 4.1 defectos por KLDC. En una aplicaci6n campuesta de 68 por denIO de cMigo reutilizado la tasa de defecto fue de 2.0 defectos por KLOC, es decir; un 51 por denio de mejora respecto de 1a tasa esperada SI Ja aplicad6n hubiese sido desarrollada sin reutilizaci6n. Henry y Faller IHEN951 reporta un 35 par cienta de mejora en la caUdad. Aunque los reportes anecd6ticos abarcan un espectro razonablemente amplia de porcentajes de mejara en la calidad, es justo afinnar que la reu tilizaci6n ofrece un beneficio importante en cuanto a la caUdad y fiabiHdad para el software enlregado. Productividad. Cuando los componentes reutilizables se aplican a 10 largo del proceso de software, se dedica menDs tiempo a la creaci6n de planes, modeios, documentas. c6diga y datos que se requieren para crear un sistema fiab le. Por 1 0 tanta, se entrega al cJiente el mismo nivel de funcionalidad can menos esfuerzo, la que mejora la productividad. Aunque los reportes de mejara porcentual en la productividad son notablemente diffciles de interpretar,6 parece que la reutilizad6n del 30 al 50 por ciento puede resultar en mejoras en la productividad en e[ rango del 25-40 por ciento.

6 Mochas circunstancias atenuantes {pOT ejemplo, dominio de aplicaci6n, compleJidad del problema, estructura y tamano del equipo. duraci6n del proyecto. tecnologia aplicadal tienen un profundo impacto sobre la productividad del equipo del proyecto

.97

Costo. Los ahorros en el costa neto por la reutilizaci6n se estiman aJ prayectar el casto de! proye<:to si este [uese desarrollado desde cera. Co. y Juego se resta la suma

--"<0,..,
"" .,Iroddn.

1 rostIJ dI desaroIat III ~" retIfi. zriM (OR frewetIdo IS fIlUY(r IIJe &J dI desmoIcr til Compo-

de los costas asociados can la reutilizaci6n, C" y el casto real del software en eJ momenta de la entrega, Ceo EI factor Co se puede determinar al apJicar una 0 mas de las tecnicas de eslimaci6n estudladas en el capitulo 23, Los costos asodados con la reutilizad6n, Cr, incluyen [CHR95J: analisis y modelado del dominio, desarrollo de arquitectura del domlnlo, aumento en la documentaci6n para facilitar la reutilizaci6n, sopone y mejora de los componentes de reutilizaci6n, regalias y licencias para camponentes adquiridos extemamente, creaci6n 0 adquisici6n y operaci6n de un dep6sito de reutilizaci6n, yen trenamiento del personal en diseno y construcci6n para reutilizaci6n. Aunque los costas asociados con el analisls del domlnio (seccl6n 30.3) y la operaci6n de un dep6sito de reutilizaci6n pueden ser sustanciales, muchos de los otros costos indicados aqul abordan los conflictos que forman parte de una buena practica de ingenierla de software, ya sea que la reutilizaci6n sea 0 no una prioridad.

-.-.

./m6""

rest de qIJt If! (1/ fultt

nesdJd ffSj)1!l dti

COftlXXJ8fI/e ~

bit. Atp as donde Sf

30.6.2 An6llsis de costo empleando puntos de estructura

En la secci6n 30.3.3 se defini6 un punta de estructura como un patr6n arquitect6nico recurrente en la totalidad de un dominlo de aplicaci6n particular. Un diseiiador de software (0 ingeniero de sistemas) puede desarrollar una arquitectura para una nueva aplicaci6n, sistema a producto al definir una arquitectura del dominio y !uego dotarla can punlos de estructura. ~IOS son 0 componentes reutilizables individuales 0 paquetes de componentes reutilizables. Aunque los puntos de estructura sean reutilizables, sus eostas de eualificaci6n. adaptaci6n, inlegraci6n y mantenimiento no son insignificantes. Antes de proceder a la reulilizaci6n el gestor del prayeeto debe comprender los costos asociadas con la uti!izaci6n de los puntas de estructura. Dado que lodas los puntas de estructura (y los componentes reutilizables en general) tienen una historia. es pasible recopilar datos de costos de cada uno. En un contexto ideal los costos de calil1caci6n, adaptaci6n, integraci6n y mantenimiento asociados con cada componente en una bibliate<:a de reutilizaci6n se mantienen para eada caso de utilizaci6n. Entonces se pueden analizar dichos datos para desarroliar los coslos proye<:tados respecto del siguiente caso de reutilizaci6n. Como ejemplo, considerese una nueva aplicaei6n, x, que requiere 60 por ciento de c6digo nuevo y la reulilizaci6n de Ires puntas de estructura: PEl, PE2 Y PE". Cada uno de estos componentes reutilizables se ha ulilizado en muchas otras aplicaciones, y estan disponibles los costos promedlO para cualificaci6n , adaptaei6n, inlegraci6n y mantenimiento. La estimaci6n del esfuerzo necesano para entregar X requiere determinar 10 siguiente: esfuerzo global - Enueoo + donde

E... ...

E.... ...

E...

...

PARTE CINCO

TDMS AVJ>.NZMX:15 EN INGNlERiA IEL ~AR

EnIriO '"

esfuerza requerido para diseiiar y construir nuevos componentes de

software (deterrninados empleando las tecnicas descrilas en el capitulo 23)

E<alif
= esfuerzo requerido para caHficar PEl, PEl Y PE)
..

EadaPI EiMt

esfuerzo requerido para adaplar PEl, PEl Y PE,)

= esfuerzo requerido para integrar

PEj, PEl Y PEl

EI esfuerzo requerldo para cualificar, adaptar e integrar PE], PEl Y PE,) se determina a\ tomar el promedio de los datos hist6ricos recopilados para la cualificaci6n, adaptaci6n e integraci6n de los componentes reutilizables en atras aplicaciones.

3Q 7

RI$UM'N

La ingenieria del software basada en componentes ofrece beneficios inherentes en

la caJidad del software. la produclividad del desarrollador y el coslo global del sistema. Sin embargo, falta superar muchas abstaculos antes de que el modela de proceso de ISBC se utilice ampliamente en la industria. Ademas de los componentes del software, un ingeniero de software puede adquirir una amplia gama de artefactos reutili zables. Entre estos se encuentran representadones tecnicas del software (por ejemplo, especilicaclones, modelos arquitect6nicos, disei\OS), documentos, patrones, marcos de trabajo, datos de prueba e i ncluso tareas relacionadas con el proceso (por ejemplo, inspecciones tecnicas). EI proceso de IS6C incluye dos subprocesos concurrentes: la ingenieria del dominio y el desarrollo basado en componentes. La finalidad de Ja ingenierla del dominic es identificar, construir, cataJogar y diseminar un conJunlo de componentes de software en un dominio de aplicad6n especifico. Entonces el desarrollo basado en componenles califica, adapta e integra dichos componen tes para emplearlos en un nuevo sistema . Ademas. el desarrollo basado en componentes disefla los componentes nuevos que se basan en los requisitos personalizados de un sistema nuevo. Las tecnicas de analisis y diseno para componentes reulilizables se basan en los mismos principios y conceptos que forman parte de una buena pr,ktica de ingenieria del software. Los componentes reutilizables deben disenarse en un entomo que establezca estructuras de datos esttmdar, prolocolos de interfaz y arquitecturas de programa para cada dominio de la aplicaci6n.
La ingenieria del software basada en componentes utiliza un modele de inteream-

bio de datos, herramientas. almacenamiento estructurado y un modelo de objeto subyaeente para construir las aplicaciones. EI modele de objelo generalmente concuerda con uno 0 mas estandares de componentes (por ejemplo, OMG/ CORBA) que definen la fonna en que una aplieaci6n puede acceder a los objetos reutilizables. Los esquemas de clasificaci6n pennilen que un desarrollador encuentre y recupere componentes reu tilizables y se ajuste a un modelo que identifica conceplo, contenida y contexto. La clasificaci6n enumerada, la clasificaci6n por facetas y la clasificaci6n de valores y atribulos son representativas de muchas esquemas de dasilicaci6n de componentes.

.99
La economla de la reutilizaci6n del software se aborda mediante una sola pregun-

ta: ies ereclivo en costo el construir menos y reutilizar mas? En general, 1a respuesta
es si, perc un pJaniticador de proyectos de software debe considerar los costas importantes asociadas con Ja calificaci6n. adaptaci6n e integraci6n de los componen-

les reutiHzables.

IADL95) Adler, R. M., HEmerging Standards for Component SOltware en CompUler, vol 28, num
H ,

3, mane de 1995, pp 68-77 [Al102J Allen, P ., eSD Survey: The Stale of the Practice-, en The CUller Edge, marzo de 2002, disponible en http://www.culter.com/researchl2002ledge020305.html [ATKOI] Atkinson, c., et al .. component-Based Product Une Engineering with UML, Addison-Wesley, 2001 [BAS94] Basili, V R., L C. Briand y W. M. Thomas, HDomatn Analysis for the Reuse of Software Development Experiences~, Proc. Of /he 19th Annual Software Engineering Workshop, NASA/GSFC, Greenbelt, MD, diciembre de 1994, [BIN93] Binder, R., "DeSIgn for Reuse is for Real", en American Programmer, vol. 6, num 8, ag05to de 1993, pp 30-37. [BR096] Brown, A W.. Y K C. Wallnau, "Engineering of Component-Based Systems", en ComponentBoW Software Engineenng, IEEE Computer Society Press, 1996, pp. 7-15 ICHR951 Christensen, S. R., Software Reuse Initiatives at lockheed", en CrossTalk, vol 8, num, 5, mayo de 1995, pp. 26-31. ICLE95] dements, p, C, From Subroutines to Subsystems: Component-Based Software Development", en Amencon Programmer, vol. 8, num. II, noviembre de 1995. 1[)(Xj()3] Dogru, A, y M. Tanik, "A Process Model for Component-Oriented Software Engineering", en IEEE Software, voL 20, mim, 2, marzo-abriI2003, pp. 34-41. IFlSOO] Fischer, 8 ., Specification-Based Browsing of Software Component Ubraries , en). Automated Software Engineering, vo\. 7, num. 2, 2000, pp. 179-200, disponible en http://ase.arc.nasa.gov/people/flscher/papers/ase-OO.htm1. [FRA94] Frakes, W. B., yT P. Pole. "An Empirical Study of Representation Methods for Reusable Software Components", en IEEE Trans. Software Engineering, vol. SE-20, num 8, ag05to de 1994, pp. 617-630. IHElO I ] Heineman, G" y W Coundll (cds.). Component-Bastxl Software Engineenng, Addisonwesley, 2001 {HEN951 Henl)', E,. y B Faller, "large SCale Industrial Reuse to Reduce COSt and cycle Time", en IEEE SOftware, septiemhre de 1995, pp 47-53 [HlJf881 Hutchinson, J W, Y P. G. Hindley, "A Preliminal)' Study of Large Scale Software Reuse", en Software Engineering}Oumal, vol. 3. num. 5. 1988, pp. 208-212. IUA93] Uao, H., y wang, F., "Software Reuse Based on a Large Object-Oriented Ubrary", en ACM Software Engineenng NOles, vol. 18, nWn. I, enero de 1993, pp. 74-80. [UM94] Urn, W C., "EtTects of Reuse on Quality, Productivity, and Economics, en IEEE Softwa re, septiembre de t994 , pp 23--30 ]UN95] Unthicum, O. S" "Component Development la Special Feature)", Application DeYdopmenf n-ends, junio de 1995, pp, 57-78 [WCO I ] deLucena, Jr , V" "Facet-Based Classirlcation SCheme for Industrial SOftware Components", 2001, se puede desc.argar de. NtpJlresearch.microsoft com/users/cszypers/eventsIWCOP200 l /weena pdf ]MCM951 McMahon, P. E., "Panem-Based Architecture, Bridging Software Reuse and Cost Managemenl~, en CrosstDlk, vol 8. mim 3. maTZO de 1995, pp 10-16. [0RF96] Orfali, R., O. Harkey y J Edwards, The Essenool Distributed Objects SUrvival Guide, Wiley, 1996. [PRl93] Prielo-Dlaz, R., "Issues and ~i.ences U'I SOIlware Reuse- , en American Programmer, vol. 6, num. 8, agosto de 1994. pp 67-68

900

PARTE CINCO

TEMAS AVANZAJXJS EN

INGIN!ERtA DEL SOFTWARE

lPOL94] Pollak, W. y M, Rissman, NStructural Models and Patterned Architectures", en OJmpult!r. vol. 27, num. 8, agosto de 1994, pp.67-68. [STA94] Staringer, W., "Constructing Applications from Reusable COmponents", en IEEE Softwa re, septiembre de 1994, pp. 61 -68. [TRA90] Tracz, w., "Where Does Reuse Start?", Prrx;, Realities of Reuse workshop, Syracuse Uruversity CASE Center. enero de 1990. rrRA951 Tracz, W., "Third International Conference on SOftware Reuse-Summary", en ACM Scftware Engineen'ng Notes, vol. 20, num. 2, abril de 1995, pp. 21 -22. [WHI95] Whittle. B., "Models and Languages for Component Description and Reuse", en ACIrI Software Engineering NOles, vol. 20, num. 2, abril de 1995, pp. 76-89. [YOU98] Yourdon, E. (ed.). "Distributed Objects", en Cutter IT journal, vol. I I, num, 12, diciembre de 1998.

3 0.1 . Uno de los obstaculos clave para la reutiJizaci6n consiste en hacer que los desarrolJadores de software consideren la reutiJizaci6n de componentes existentes en lugar de reinventar unos nuevos (despues de todo, iconstruir cosas es divertido!) . sugerir de tres a cuatro fonnas diferentes en que una organizaci6n de software puede ofrecer incentivos para que los ingenieros de software empleen la reutilizaci6n. ,Que tecnologras deben existir para apoyar el esfuerzo de la reutilizaci6n? 30.2. Aunque los componentes de software son los "artefactos" reutilizables mas obvios, se pueden reutilizar muchos otros productos de tTabajo producidos como parte de la ingenieria del software. Considerar los planes de proyecto y las estimaciones de costo. ,C6mo se pueden reutilizar y cual es el beneficio de hacerlo? 30.3. Investiguese un poco ace rca de la ingenierla del dominio y detallese el modele de proceso esbozado en la figura 30.1. Identiflquense las tareas que se requieren para el analisis del dominio y el desarroHo arqui ted6nico del software. 30.4 . ,En que son semejantes las funciones de caracterizaci6n para dominios de aplicaci6n y los esqucmas de c1asificad6n de componentes? .. En que se diferencian? 30.1!i. Cc,...rrollar un conjunto de caracterlsticas de dominio para sistemas de informaci6n que sean relevantes respecto al procesamiento de datos de estudiantes de una universidad. 30.6. Desarrollar un conjunto de caracteristicas de dominio que sean relevantes para un software de procesamlento de textos y pubJicaci6n. 30.7. DesarroUar un modelo estructural simple para un dominio de ap hcaci6n que asigne individualmente el instructor 0 uno can el cual se este familiarizado, 30.8.
~Que

es un punto de estruclura?

30.9. Adqui rir infonnaci6n acerca del mas reciente estandar CORBA, COM 0 JavaBeans y elaborar un ensayo de tres a cinco paginas que aborde sus prindpales atributos, Obtener infonnaci6n acerca de una herramienta de distribuci6n de solicitudes de objetos e ilustrar c6mo la herramienta se ajusta al estandar, 30.10. Desarrollar una clasificaci6n enumerada para un dominio de aplicaci6n que asigne el instructor 0 uno con el que se este familiarizado. 30.tt. Desarrollar un esquema de clasificaci6n por facetas para un dominio de aplicaci6n que asigne el instructor 0 uno con el que se este familiarizado . 30.12. Investlguese en la bibliografia para obtener datos recientes de calidad y productividad que apoyen el uso de la [SBC, Presentense los datos a \a clase,

901

En anos recientes se han pubticado muchas libros acerca del desarrollo basado en componenles y \a reutilizaci6n de wos. Heineman y COuncil! [HEIOlj, Brown (Li1rge Scale Componenf-Based Devdopmtnl, Prentice-Hall, 2(00), Allen (Rmiizi1l8 e-Business with components, Addison-Wesley, 2000), Herzum y Sims (BUSiness COmponenf Factory, Wiley, 1999) y Allen, Frost y Yourdon (COmponent-Based D&dopmentfor n/erptlSie Systems: Applying the Select Perspective, cambridge Uni-

versity Press, 1998) cubren todos los aspectos importantes del proceso de ISOC. ApPerly y sus
colega5 (5etvKe- and component-Based Dt:velopment. Addison-wesley, 2(03). Atkinson IATKO ]] y Cheesman y Daniels (UML Components, Addison-Wesley, 2000) examinan la ISec poniendo espedal cuidado en UML Leach (SOftware Reu~: Methods, Modds, and Costs, McGraw-Hill, 1997) proporciona un ana-

lIsls detallado de los confliclos de costo asociadas con 1a [SOC y la reutilizaci6n Poulin (M'MSUring Sojlware Reuse. Prindples, Practic~, and Economic Models, Addison-Wesley, 1996) sugieren
algunos metodos cuantitativos para valorar los beneficios de la reutilizaci6n de software. En ai'ios recientes se han publicado docenas de libros que describen los est<\ndares basados en componentes de la industria. En eUos se abordan las funciones internas de los est<\ndares mismos, pero tambien consideran muchos t6picos importantes de Ja ISBC. A continuaci6n se presenta una muestra de los tres eslandares estudiados en este capitulo:

CORM
Bolton, F., Pure CORaA., Sams Publishing, 200 I Doss, G. M., CORaA. Networking With}OVa, Wordware Publishing, 1999. Hoque, R., CORlM for Reol Progrommers, Academic Press/Morgan Kaufmann, 1999. Siegel, J., CORaA fundamentals and ProgrammIng, Wiley, 1999. Slama, D., J. Garbis Y P. Russell, Enterprise CORBA, Prentice-Hall, 1999.

COM
Box, D., K. Brown, T Ewald yc. Seils, Effective COM' 50 ~ to Improve \1:lurCOM-and MTSBased !oppficauons, Addison-wesley, 1999 Gordon, A., The COM and COM+ Programming PrImer, Prentice-Hall, 2000 Kirtland, M" DesJgrnng COmpo1lMf-&Ism Applications, Microsoft Press, 1999, Tapadiya, P., COM+ Programming, Prentice-Hall, 2000, Muchas organizaciones aplican una combinaci6n de est3.ndares de componenles. lOs libros de Geraghty y sus colegas (COM-CORBA InteroperobJIl/y, Prentice-Hall, 1999), Pritchard (COM and CORM Side by Side: !trchitectures, Slrategies, and Implementations, Addison-wesley, 1999), y Rosen y sus cole gas (/megrallng CORBAy COM Applications, WHey, 1999) consideran los confllctos asociados can el uso tanto de CORBA como de COM como la base para el desarrollo basado en componentes.

javQlJeans
Asbury,S., y S. R. Weiner, Developmg}OVa Enterprise Applications, Wiley, 1999, Anderson, G., y P. Anderson, En~rise }aVabeons Component Architecture, Prentice-Hall, 2002. Monson-Haefel, R., Ent~ }avr1beans, tercera edici6n, O'Reilly & Associates, 2001. Roman, E" et 01., Ma.sleru18 En~ }avr1beans, 2a ed., Wiley, 2001 En Internet hay disponible una amplia vanedad de fuentes de Informacl6n acerca de la ingenieria del software basada en componentes.. Una bsta actuaUzada de referenclas en la worid Wide Web se puede encontrar en eJ sioo Web SPA. http://www.mhhe.comlpresstnan.

CAPiTULO

31
.......
.,...,iI
CONCEPTOS C LAV E

REINGENIERiA

...~
~IfwlI1

909

n un relevante articulo pubJicado en 1a HaNarri Business Review, Michael Hammer IHAM901 sent61as bases para una revoluci6n en eJ pensamlento administrativo acerca de los procesos de negocios y la computaci6n:

,/1 .........929
00 . ........921 MOIIOIIIia 923

Es eI momento de dejar de paVimentar los senderos para vacas. En Jugar de incrustar procesos anlicuados en silicio y software. debemos eliminarlos y comenzar de nuevo. Debemos $OmeleT a Mreingenieria" nuestros negocios: usar el poder de las modernas lecnologias de la informaci6n para redlsenar radicalmente nuestros pr!>cesos de negocios con la finalidad de alcanzar mejoras radicales en su desempeno.

......... "td4I .......

iImf........912

...........906

pron... "', 903

nil.llli. II 908
,...lnKtWDd6ft 91 /)

_ ..
,..eK." ..
,MS'rvdlra

918

Cualquitr companla opera de acuerdo con una gran cantidad de reglas desarticuIadas_. La reingenleria lucha por separarse de las viejas reglas acerca de c6mo or ganizar y dirigir nuestros negocios_ AI igual que todas las revoluciones, eillamado a las armas de Hammer gener6 cambios positivos y negativas Durante el decenio de 1990, algunas companias aplicaron un esfuerzo legltimo en la realizacl6n de reingenierfa, y los resultados las condujeron a mejorar su campetitividad_ Otras se apoyaron exc1usivamente en el redimensionamlento y la subcontratad6n (en lugar de la reingenieria) para mejorar sus l\neas base; por 10 tanto, can frecuenda resultaran organizaciones con poco pOlenclal para un crecimlento futuro [DEM95J. Durante esta primera decada del siglo XXl, la promoci6n exagerada de 1a reinsenierla ha decaldo, pero e1 proceso en sl continua en compal'ilas grandes y pequenas. Los nexos entre 13 reingenierta de negodos e ingenierta del software

.. ikfo, .....4117

se encuentran en una revisi6n de sistema .

,Que _1 Considere cw&qu. to IecnolOgico que Ie haya twvtdD

WliIidad

QSI ccrno una rneioJ focilidod de A eIO sele lama reingenierio.

uliliza ~ PIrO 'il::.1b~:.:':1L:t.:fn 6mbiIo de los orgonizocie> est6 YOIiendo obaoIeIo Se, :~:,::~" '~ . ..... um Ia IIewn 0 cabo elp8Ciolisios mocha frecuencio, su l4IpOiod6n IOIIIa n 1con fncuencio eompoiiif consulb 0tI que usted quisiera. Yyo no 'T lline ..., 0.1 softwarw 10 reingeoierio 10

Usted 10

..

""'" 1oa>oIog;o. tGlui """" 51 ..

hc.dwore, ro YCOI1lpIOIa un rnodeIo nal'WVG. .... pononaIimdo, <kilo qxi6n tal

pububleo.....

dot - .
en 1XI munclo en

dispon bIe. Na:esiba ~

..

<On """ """"

IuncloooIdod,

las derronckAocerco de los runy Ia Ioaoologla dot 10 ;,r..mo. ..on combbdo a un rilmO poo;6n en 10..

"""""INa

CAPiTuLo 31

RllNGENlERiA

903

,~-

... idoo_
praom

0.10011-

cio, y a.I

. . . 10 he

cumpIon - tWingtnilrio
rico,

"-"'pnId>
t6c:nico! fof de db ..,;
""""'" do

1rIrimiwIIo.
~

do.

;"IJ'I'iOrio

........

. . . _.. , 10 opIKoprue-

C&VE
III RPfI (011 frecuenoo

._dO _dO
....,m"'.
1!IOIlIririen1o.

,...."".." -~ soItMn, _1IOs

Usuaimente el software es Ja realizaci6n de las reglas del negocio que Hammer describe. Conforme ,ambien dichas reglas, el software tambien debe hacerlo. En la aClualidad, las grandes compai'iias lienen decenas de miles de programas de compuladora que apoyan a las viejas reglas del negocio. A medida que los administradores trabajen en la modificaci6n de las reglas y logren mayores efectividad y competitividad, el software debe mantener el rilma. En algunos casos, esto implica la creaci6n de mayores y nuevas sistemas basados en computadora. 1 Perc, en muchas alros, significa la modificaci6n 0 reconstrucci6n de las aplicaciones existentes. En este capitulo se examina la reingenieria en rorma descendente, comenzando can un breve panorama de la reingenieria de procesos de negocio y despues se abordan con mayor detalle las actividades tecnicas que se llevan a cabo al realizar la reingenieria del software.

sdtwuIe IIObojo pm!

scitwtn mtenll (CII III mejIJ . , . 1 de _ldIoIdo

La reingenierla de procesos de negocio (RPN) rebasa el ambito de las tecnologias de

la informaci6n y de la ingenierla del software. Entre las muchas definiciones (la mayorla un tanto abstractaj sugeridas para la RPN destaca una publicada en la revista Fortune [STE93j : uLa Msqueda e implementacl6n de un cambia radical en el proceso de negocios para lagrar resultados de vanguardi a u , Pero, ic6mo se lIeva a cabo la busqueda y c6mo se logra la implementacl6n? Mas importante aun. ,c6mo se puede garantizar que el ~cambio radical" sugerido conducira a "resultados de vanguardia" en lugar de caos organizadonal'
1 La exp\osl6n de aplicaciones y ~ baYdo5 en WdJ estudiados en la parte 3 de este libro es un indic\o de esta tendenCia.

PARTE CINCO

TDMS AVJ>.NUUX:li>EN lNGENtERiAoo.SOFTWARE

'"&Ifr.tar .I mai'iona (QIl1a idea de tnlfIIeor los mitoclos de II)'If es 'IisuaIizor Ia .,. OIIIID . . , . . . . .
31.1.1

_ ..

Procesos de negoc1os
H

Un proceso de negocio es "un conjunto de tareas l6gicamente relaclonadas que se ejecutan para lograr un resultado de negocios especifico IDAV90I. Dentro del proceso de negocio, la gente, el equipo, los recursos materiales y los procedimientos del negocio se combinan para producir un resultado especifico. Los ejemp[os de procesos de negocios incluyen el diseno de un nuevo producto, la compra de servicios y suministros, la contrataci6n de un nuevo empleado y el pago a proveedores. cada uno demanda un conjunto de tareas y tambien emplea diversos recursos dentro del negocio. cada proceso de negocio tiene un cliente definido: una persona grupe que recibe el resultado (por ejemplo, una idea, un informe, un diseno, un producto). Ademas, los procesos de negocios traspasan las fronteras de la organizaci6n. Esto requiere que diferentes grupos de organlzaciones partlcipen en las "tareas l6gicamente relacionadas" que definen el proceso. En el capItulo 6 se indic6 que todo sistema es en realidad una jerarquia de sub-

(OOIO~de

-.,W""","
,.,.",..,

.....",,....,.

" ""'" de""_SO

de ....... .,

""""MI 1M .owtltr ..,..

sistemas. Un negocio no es la excepci6n. cada sistema de negocio (tambien Ilamado una funci6n negocio) esta compuesto de unoo mas procesos de negoclo, ya cada proceso de negocio 10 define un conjunta de subprocesos.
La RPN se puede aplicar en cualquier nivel de la jerarqula, pero conforme se amplia su ambito (es decir, conforme uno se mueve hacia aniba en la jerarqula) las ties-

naes. 5i BSIr1 no flo ...., w""'"

gas asociadas con ello crecen sustancialmente. Por esta raz6n, la mayorfa de las

roo, Iilljp.

esruerzos de \a RPN se enfoca en procesos individuales a subprocesos .

I,,,.?
31 .1.2 Un moclelo de RPN

Como la mayotia de las actividades de ingenieria, la reingenierfa de procesos de negocio es iterativa. Las metas del negocio y los procesos can que se logran se deben adaptar a un entoma de negocios cambiante. Por esta raz6n no existe principio ni fin para la RPN: se trata de un proceso evolutivo. En la figura 31. 1 se muestra un modele de reingenieria de procesos de negocio. El modelo define seis activida-

des.
Definid6n del negocio. Las metas del negocio se identifican denle el contexto de cuatro controladores clave: reducci6n de costo, reducci6n de tiempos, mejora de la calidad y desarrollo y fortalecimiento del personal. Es posible definir las metas al nivel del negocio a respecto de un componente especifico del negocio. Identiflcad6n del proceso. se identifican los procesos cruciales para lograr las metas precisadas en la definicl6n del negocio. Luego podrfa clasificarse de acuerdo

...
con su importancia, necesidad de cambia 0 en cualquier atTa forma que sea ade-

cuada para la actividad de reingenieria. EvaJuadon del proceso. EI proceso exlstente se analiza y mide exhaustivamente. Se identifican las tareas del ptoceso; se anotan los costos y el tiempo que consumen las tareas del proceso; y se afslan los problemas de calidad y desempef'lo.

Espedflcacion y diseiio del proceso. Con base en la retroalimentaci6n obtenida durante las primeras tres actividades de la RPN, se preparan casos de uso (capi-

tulo 7) para cada proceso que sera rediseliado. En del conlexto de 1a RPN los casos
de usc identifican un escenario que enlrega cierto resultado a un cliente. Con eJ cas de

usa como la especificaci6n del proceso se disef'ia un nuevo conjunto de lareas para

el proceso.

Elaborad6n de prototipos. Un proceso de negocio redisenado debe conver

tirse en prototipo antes de que sea integrado por completo en el negacio. Esta actio vidad "prueba" el praceso de modo que puedan lIevarse a cabo refinamientos. Reflnamjento y particularlzaci6n. Can base en la retroalimentaci6n del prototipo, el praceso de negocio se retina y luego se particulariza dentro de un sistema de negacio. En ocasiones, estas actividades de RPN se ulilizan junto con las herramientas de antllisis de flujo de Irabajo. La finalidad de estas herramientas es elaborar un mode 10 de flujo de trabajo practico, esfuerzo encaminado a analizar mejor los procesos existentes. Ademas, para implementar las primeras cuatro actividades descritas en el modelo de praceso se pueden aplicar las tecnicas de modelado usualmente aso ciadas can las activldades de ingenieria de pracesos de negacio (capitulo 6).

,
Modelo de RPM.
Dtfinici6n del

-"'

/'
Eloboroci6n de

R"'nom,enlo e inllanl;,ociOn (penonalizociOn)

~
Idenlificoci6n

".-""

do"......

\
ElpKificoa6n
ydlMilode
~~

)
&oIuocio.. de
I""'.~

906

PARTE CINCO 1DdAS AVA.Nl.A.DCS DlINGINIIlllA OEL SOfTWARE

IIiiiiiiiiiIt Obje';yo: EI objetivo de los herromienlos de

10 RPN
e$

~ Relngenteria de procesos de negocto (RPN)

opoyor eI on6lisi, y 10 eYOluoci6n de negocio pi$lenle$ Y 10 ~f;coci6n Y eI

los pnx:tI$O$ de diseiio de \,II'lOs m.-os.

e-Worlc, deKlrroilodo por ,o\o\elasb'm (www.meklstorm.comJ,opoyo 10 QMti6n de procMO$ de negoclo$ en proce$O$ monuole5 y ovtomotiwdos.
keTooJs, ~rmllodos po<'" Blue Ice (www.blueice.cOlll).es UOCI coIeo:i6n de pIonlillos de RPN para Microsoft Office y ~ Project.

Mecanica: Lo meo::6nic;o de los herromienll;l$ VClrio. En generol, los herromienlos de Ie RPN permiten que un analiw de negocios modele len ~ de negoc::io existenles en un esfuerzo destinodo 1;1 IYOluar las ineficiencios del Auia de trabajo 0 problemas fundonaiM. Uoo vel que Ml ideotificon los problemas eJ(i~tM las
herromielllos pennilen que los onoliWs eIoboren

.s,:-Dev, ~Iodo per NimbleStor Group

Iwww.nimbleslor.com). es uno de mud'lOs herromienlos que penniten que una Of'gOniloci6n modele RujO$ de trobajo de ~ len esle coso, Ruja de trobajo de

prototipos 0 simulen procesos de negocio He rramientas rep re.entativa. 2

reYj~.

TIl workflow tools, deKirTOllodas por .MeIuSoltware

(www.melcsoftwore.comL incorporo un conjunlo de herromienlos pora modeIodo, limuloci6n y colendorizoci6n del Ru;o de trobojo.
Uno lislo (jlil de v(nculos a herromientas de RPN
enconlror en http://www.donaldWI

&dend, dMorTOllodo pol' ImagineThat, Inc:. (www.imoginethotinc.com). (IS uno herromienla de simuloci6n para eI modeIodo de procesos lIXidentes Y 10 eJq)lonxi6!'l de unos nuevos. Extend proporciono
uno extenso oopocidod si. . . enloncM- que pennile

puede

que un OI"IOlj~ de negocim~~~

de pXe50.

firesmith.com/Components/Produceo/Toob/BulineuProce nRMngi-'ing TooI5.htmI.

EI escenario es tan comun ; una aplicaci6n ha cubierto las necesidades de negocios de una compai'Ha durante 10 0 15 ai'los. Durante ese lapso se ha corregido, adaptado y mejorado muchas veces. EI personal enrrent6 este trabajo can las mejores intenciones, pero las buenas practicas de ingenieria del software siempre fueron soslayadas (debido a la pres[6n de otros asuntos importantes) . Ahara la aplicaci6n es inestable. Todavfa runciona pero, cada vez que se intenta un cambia, ocurren efeclos colaterales, inesperados y serios. Y la aplicaci6n todavla tiene que evolucionar. ,Que hacer? El software al cual no se Ie puede dar mantenimiento no es un problema nuevo. De hecho, la importancia cada vez mayor que se Ie concede a la reingenieria del sollware la han impulsado los problemas en el mantenimiento del software que han ido creciendo durante mas de 40 anos.

L.A5 herramientas expuestas eJ autor no las respalda; sOlo representan una muestra de las herra-

mientas inclu idas en esta categorla En la mayoria de los casos, los nombres de las henamientas son marcas registradas por sus respectivos desarrolladores

cAPiTuLo 31

RlNG&llEIllA.

907

31.2. 1 Manten1mlento del software

Durante las tres decadas pasadas el mantenimiento del software se caracteriz6 [CAN72J como un Miceberg". Se esperaba que 10 inmedialamenle visible fuese todo 1 0 que habia. pero se sabia que bajo la superficie se encontraba una enorme masa de problemas y costas potenciales. A principios del decenio de 1970, el manlenimiento del iceberg era suficientemente grande como para hundir un portaaviones. En la actualidad. if,kilmente podrfa hundir a toda la marina! EI manlenimiento del software existente expl!ca casi cl 60 por cicnlo del esfuerzo que emplea una organizaci6n de desarrollo, y el porcentaje continua elevandose conforme se produce mas software [HAN93J. Los lectores con escasos conocimien105 sobre el tema podrlan preguntarse por que se requiere tanto mantenimiento y por que se dedica tanto esfuerzo. Osborne y Chikofsky [05B9O] ofrecen una respuesta parcial:
Gran parte del software del que dependemos en la actualidad tiene en promedio de 10 a

15 anos de antigiledad. Aun cuando dichos programas se crearon empleando las mejores I.Y la mayorfa no 10 eran!, se Clearon cuando el tamano de los programas y el espacio de almacenamiento eran las princitecnkas de diseno y codificad6n conocidas en Ja epoca pales preocupaciones Enlonces emigraron hacia nuevas plalaformas, se ajustaron para adecuarlos a los camblos en las maquinas y a la tecnologfa de los sistemas operallvos y aumentaron para salisfacer las necesidades de nuevos usuarios; todo se hizo sin conslderaT 10 suficiente La arquiteclura global EI resullado es estrucluras mal disenadas, codi ficaci6n deficilente, 100lca inadecuada y escasa documentaci6n de los sistemas de 50nware por los que ahara se nos llama para manlenerlos en operaci6n.

Otra raz6n respecto del problema del mantenimiento del software es la movilidad del personal. Es probable que el equipo (o persona) de software que realiz6 el trabajo original ya no este. Pear atm, las generadones subsecuentes de personal han modificado el sistema y 10 han daftado. En la actualidad, tal vez no haya nadie que tenga algun conocimiento directo del sistema heredado. Como se indic6 en el capitulo 27, la naturaleza ubicua del cambio subyace en lodo el trabajo de software. EI cambio es inevitable cuando se construyen sistemas basados en computadora; en consecuenda, se deben desarrollar mecanismos para eva luar, conlrolar y efectuar modificaciones
,. ......... _ . : :10

_los progrlllDClS , III (::mpr1lllSibilidad de los

pt._

son (_ _ .......

Despues de leer los parrafos anteriores un leclor podrfa protestar: "Pero yo no paso el 60 por dento de mi tiempo componiendo errores en los programas que desarrol lo". Desde luega, el mantemmJento del software es mucho mas que "componer errores" Es posible defirur eI manterumiento descr:biendo cuatro actividades [5WA761 que se realizan despuesde que Wl programa es liberado para su utilizad6n

--

PARTE CINCO

ltMAS AV~ EN ING'oENlER!A Ol. SOfTWARE

~~

C&VE
8 monlerWnierlro del scirwoIe IlWye (Il00
IlCIMOOdes: OOITe(OOO de error, adaptadoo,

-,_.
.......

El mantenimiento del software se define identificando cuatro actividades diferentes: mantenimiento correctiv~, mantenimiento adaptativo, mejora 0 mantenimiento de perfeccionamiento y mantenimiento preventivo 0 reingenieria. 5610 cerea del 20 por ciento del trabaja de mantenimienta se emplea en "(ompaner errores". El restante 80 por cienla se dedica a adaptar los sistemas existentes a los camblos en su entorno extemo, realizar las mejoras que solicitan los usuarios y redisenar una aplicaci6n para usarla en 10 futuro. Al considerar que el manlenimiento incluye todas estas actividades es relativamente sendllo abservar por que absorbe tanto esfuerzo.

31.2.2 Un modelo de procesos d e reingen1eria del software

La reingenieria requiere tiempo, cuesta cantidades signincativas de dinero yabsor-

be recursos que de olro modo se ocuparian en problemas inmediatos. Por todas estas razones la reingenieria no se logra en unos cuantos meses, ni siquiera en unos cuantos aflos. La reingenieria de los sistemas de informaci6n es una actividad que absorbeni recursos de la tecnologia de la informaci6n durante muchos anos. Por tanto, toda organizaci6n necesita una estrategia pragmatica respecto de la reingenleria del software. EI modelo de proceso de reingeniena incJuye una estrategia operativa. EI modelo se tratara mas adelante en esta secci6n, pero prlmero se presentaran algunos principios basicos.
La reingenieria es una actlvidad de reconstrucci6n, y la reingenieria de los siste-

mas de informaci6n se comprende mejor si se considera una actividad analoga : la recon5trucci6n de una casa. Considerese la sigulente situaci6n. EI lector compra una casa en otro estado. En realidad nunea ha visto la propiedad, peru Ja adquiriO cn un prccio sorprendentemente baja, can la advertencia de que lal ve2 Icnga que reconslruirse por completo. GC6mo se procedena? Antes de que se pueda iniciar la reconstrucci6n seria razonable inspeccionar la casa Determinar si es necesario reconstruirla requiere que el lector (0 un inspector profesional) elabore una !isla de criterios de modo que la inspecci6n resulte sistematica. Antes de lirar y reconstruir toda la casa se debe tener la certeza que la estructura es debi!. 5i la casa es estructuralmente s61ida tal vez sea posible "remodelarla" sin reconstruirla (a un costo mucho mas bajo y en mucho menos tiempo). Antes de iniciar la reconstrucci6n se debe tener la certeza de que se entiende c6mo se construy61a original. Eche un vistazo detTaS de las paredes. Entienda el alambrado, la plomerla y los componentes estructurales. Incluso sl se liran lodos a la basura, la cornprensi6n que se adquiera sera utH cuando comience la construcci6n. 5i se cornienza a reconslruir s610 se utilizaran los materiales mas rnodernos y de larga duraci6n. Esto puede costar un poco mas ahora, pero ayudara a evitar un mantenimiento costoso y \ardado mas ade!ante.

 Si se decide reconstruir es preciso disciplinarse en cuanlo a ello. Utilicense practicas que redundarcin en alta calidad, hoy y manana. Aunque estos principios se enfacan en la reconstrucci6n de una casa, tambien se ap!ican igualmente bien a la reingenieria de sistemas y aplicaciones basadas en computadoras. La implementaci6n de estos principios requiere apticar un modelo de proceso de reingenieria del software que define seis actividades, como se muestra en la figura 31.2. En algunos casos dichas adividades ocurren en una secuencia tineal, pero este no siempre es el caso. Por ejemplo, tal vez la ingenierfa inversa (comprender el funcionamiento interno de un programa) tenga que acurrir antes de que comience la reestrucluraci6n de documentos. El paradigma de reingenieria que se muestra en la figura es un modelo cfclico. Eslo significa que cada una de las actividades presentadas como pane del paradigma pueden volver a visitarse. En algun cicio parUcular el proceso quiza termine despues de cualquiera de dichas actividades. Analisis de inventarios. las organizaciones de software deberlan tener un inventaria de todas sus aplicaciones. E1 inventario tal vez no sea mas que un modelo en una hoja de calcula que contenga informaci6n que proporcione una descripci6n detallada (por ejemplo, tamano, edad, importancia para el negocio) de las aplicacianes activas. Al ordenar esta infarmaci6n -de acuerdo can la importancia para el negocio, antigOedad, facilidad actual de mantenimiento y otros criterios localmente imponantes- aparecen los candidatos para reingenieria. Entonces se pueden asignar los recursos a las apJicaciones candidatas para el trabaja de reingenierla .

Modelode
_<lola reingenIeria del
sottwaJ8.

Ingoenierio

AnOlisis de

ovonzoda

del (6<li9O

Inverso

910

PARTE CINCO

m,{AS

AVA.NV.!XS EN INGENIE2A DEL SCFlWARE

Es

importante sefialar que el inventario debera visitarse con regularidad. El estado

--" ~ wIi soorelido D

,OCesD de reirlge-

.do_._ """,",o'lIClIJIlS 6S(flSeOO,

SltI/iMfJorios

de las aplicaciones (por ejemplo, importancia respecto del negocio) puede cambiar en funci6n del tiempo y, como resultado, cambiaran las prioridades para la reingenieria.

;.ude (oosider(if fa

Reestructuraci6n de documentos. La documenlaci6n dehll es Ja marca de muchos sistemas heredados. <.Pero que se haee ace rca de ello?
nes?

,cuales son las opcio-

Ii600 01 20 {XX cienfrl

del soItwrxs rpe ...... 80", Cidnlo de los

I. Crear documentaci6n consume muchfsimo tiempo. Si el sistema funciona vivira con 10 que se tenga. En algunos casos esle es el enfoque corre<:to. No es posible recrear documentaci6n para cientos de programas de computadora . Si un programa es relativamente estatico esta Ilegando al final de su vida util, por 1 0 que es improbable que experimente un cambia significativa, idejela seT! 2 . La documentaci6n debe actualizarse, pero se tienen rocursos /imirados. se utili zara un enfoque de "documenlar cuanda se toque Tal vez sea innecesaria valver a documentar por campleto la aplicaci6n. En cambia, se documentan campletamente aquelJas porcianes del sistema que en la actualidad experi men tan cam bios. Can eJ tiempa evalucianara una calecci6n de documentaci6n util y relevante.
H

,"_SIlOs.
u.._ ...
doamIntocidn (0010
MCBSi/e porn

1I1m..,nm.

entelKJet " soItwrn,

3 . El sistema es crucial para eI negocio y debe voMr a documenrarse por comp/eto. Induso en este caso un enfoque inteligente es recortar la documentaci6n a un minima esenciai.
cada una de cSlas apcioncs cs viable. Una organizad6n de software debe elegir la mas apro piada para cada caso. Ingenieria inversa. El termino ingenieria inversa tiene sus arigenes en el mundo del hardware . Una compafHa desensambla un producto de hardware de un competidor can la flnaHdad de comprender sus "secretos" de diseno y fabricaci6n. Tales secretos podrlan comprenderse facilmente sl se obtuviesen las especificaciones de disena y fabricaci6n del competidar. Pero dichas documentos estilO patentados y na esttm dispanibles para la campania que realiza la ingenieda inversa. En esencia. la ingenierla inversa exitosa obtiene una a mas especificaciones de diseno y fabricaci6n para un producto cuando se examinan especimenes reales del proclucta. La ingenieria inversa para el software es bastante similar. Sin embargo, en ambos casas el programa objcto de la ingcnieria inversa no es el de un competidor. sino el trabaja de la prapia campania (con frecuencia elaborado muchos anos atras). Los "secretos" que se comprendan seran oscuros. pues nunca se desarroll6 una espedficad 6n Por la tanto, la ingenieria inversa del software es el proceso de analizar un programa can la finalidad de crear una representaci6n del programa en un mayor grada de abstracci6n que el c6digo fuente . La ingenieria inversa es un proceso de recuperacl6n de diseno. Las herramientas de la ingenieria inversa obtienen infor-

cAPiTuLo 31

I!lNGEMERlA

911

mad6n del diseno de datos, arquitect6nico y de procedimientos a partir de un programa exislente. Reestructuracl6n de c6digo. EI tipo mas comun de reingenieria (en rea lidad , en este caso el empleo del tennino reingenieria es cuestionable) es la reestruclurad6n de c6digo.J Algunos sistemas heredados lienen una arqultectura de programa rela tlvamente s6lida, pero los m6dulos indlviduales se codificaron en una fonna que dificulta comprenderlos, probarlos y mantenerlos. En tales casos se puede reeslructurar el c6dlgo denlro de los m6dulos sospechosos. Uevar a cabo esta actividad requiere analizar el e6digo fuente empleando una herramienta de reestructuraci6n. Se indican las violaciones de las estructuras de programaci6n estructurada y entonces el c6digo se reestructura (esto se puede haeer automaticamentej . EI c6digo reestructurado resultante se revisa y prueba para garantizar que no se han introducido anormalidades. La documentaci6n del c6digo interno se actualiza. Reestructuracl6n de datos. Un programa con una arquitectura de datos debil sera difIcii de adaptar y mejorar. De hecha, en muchas aplicaciones la arquitectura de datos esta mas relacionada con la viabilidad a largo plaza de un programa que el c6digo fuente. A diferencia de la reestructuraci6n de c6digo, que ocurre en un grado relativamente bajo de abstracd6n, la reestructuraci6n de datos es una actividad de reingenleria a gran escala . En la mayoria de los casos, la reestructuraci6n de datos comienza con una actividad de ingenieria inversa. La arquiteCiura de datos actual se analiza can minuciosidad y se definen los modelos de datos necesarios (capitulo 9). se identifican los objetos de datos y los atributos, y despues se revisa la calidad de las estructuras de datos existentes. Cuando la eslructura de datos es debil (por ejemplo, actualmente se implementan archivos pIanos, cuando un enfoque relacional simplificaria enonnemente el procesamiento), los datos se someten a reingenieria . PUesto que la arquitectura de datos tiene una fuerte inlluencia sobre la arquiteclura del programa y los algoritmos que [0 pueblan, los camblos a los datos invariablemente resultaran en cambios arquitect6nieos 0 al nlvel de c6digo. Ingenlerla directa. En un mundo ideal, las aplicaclones se reeonstruirlan empleando un "motor de reingenleria" automatizado. El programa antiguo serfa insertado en el motor, analizado, reestructurado y luego regenerado en una fonna que exhiblese los mejores aspectos de la calidad del software. A carta plazo es improbable que tal "molor" aparezca, pero las empresas han introducido herramlentas que mejoran un limitado subconjunto ~ diehas capaddades que aborden dominios de aplicaci6n especificos (por ejemplo, las aplicadones que se implementan mediante
J

La reestructurad6n de c6digo tIenr . . . . de II dementos de "refactorizad6n", un concepto de redisef'lo introduddo en el capttulo .. Y1RDdo en 0IraS parteS de esle libro

PARTE CINCO

n:MAS AVANZ.AIXX:. EN INGENIERiA DEL SOFTWARE

un sistema de base de datos especifico). Mas importante, dichas herramientas de reingenieria se estan volviendo cada vez mas sofisticadas.
La ingenieria directa, tambien Hamada renovaci6n 0 reclamaci6n [CHI901, no s610 recupera la informaci6n de diseno a partir del software existente, tambien utiiiza esta informaci6n para alterar 0 reconstituir el sistema existente con la finalidad de mejorar su calidad globa\. En la mayoria de los casos el software sometido a reingenieria vuelve a implementar la funci6n del sistema existente y tambien aflade nuevas funciones 0 mejora eJ desempeno global.

La ingenieria inversa invoca una imagen de "ranura magica". En la ranura se inserta

una !ista Fuente sin documentar y diseflado casualmente, y del otro extrema sale una descripcion (y tada la documentacion) completa del disef\a para el programa de computadora. Oesdichadamente, la ranura magica no existe. La ingenierla inversa puede obtener informaci6n de diseno a partir del c6digo fuente, pero el grado de abstraccion, Ja campletud de la documentaci6n, el grado en el que las herramientas y un analista humana trabajan en canjunta, y Ja direccionalidad del proceso son enormemente variables.
El grade de abstracd6n de un proceso de ingenieria inversa y las herramientas uti-

lizadas para efectuarlo se refieren a la sofisticaci6n de la informaci6n del diseno que es posible obtener del c6digo fuente. ldealmente, el grada de abstracci6n debe ser tan alto como sea posible. Esto es, el proceso de ingenieria inversa debe ser capaz de derivar representaciones de disefi.o de procedimiento (un grado de abstraccion ba;o), informaci6n de estructura de programa y datos (un grado de abstracci6n un poco mas elevado), modelos de objeto, modelos de flujo de datos 0 control (un grado de abstraccion reJativamenle alto) y clases UML, diagramas de estado y despliegue (un grado alto de abstracci6n). conforme ei grado de abstracci6n aumenta, el ingeniero de software obtiene informaci6n que Ie permitira comprender con mas facilidad el programa.
La completud de un proceso de ingenieria inversa se refiere al grado de detalle que

se ofrece en un grado de abstracci6n. En la mayoria de los casos, la integridad disminuye confarme el grada de abstracci6n aumenta. Par ejemplo, dada una \ista del c6d.igo fuente, es relativamente sencilla desarrollar una representaci6n completa del disefla del procedimiento. Tambien se pueden derivar representaciones sencillas de diseflo, pero es mucho mas dificil desarrollar un conjunto completo de diagramas o madelos UML.
La campletud mejora en proporci6n directa con ia cantidad de analisis que efec-

tlia quien realiza !a ingenieria inversa. La interactividad se refiere a! grado en e! que el ser humano esta "integrado" con las herramientas automatizadas para crear un proceso de ingenieria inversa efectivo . En la mayoJia de los casas, conforme aumenla ei grado de abstracci6n la interaclividad debe aumentar 0 la completud sufrira.

cAPirot.o 31

R!lNGNlRlA

913

"'0<000<1&

In......,_

lngonleria

".do .....

Si la direccionalidad del proceso de ingenieria inversa es unidirecdonal. toja Ja

informaci6n extraida del c6digo fuente se afrece al ingeniero de software que el 'tonces puede usarla durante cualquier actividad de mantenimiento. Si la direccionalidad

es bidireccionai, la infonnaci6n alimenla a una herramienta de reingenieria que inlenta reestruclurar 0 regenerar el programa antiguo. En la figura 31.3 se representa el praceso de ingenieria inversa Antes de que comiencen las actividades de ingenieria inversa, el c6digo fuente no estructurado
rsucio") se reestructura (secci6n 31.4.1) de modo que 561 0 contenga las estructuras

de programaci6n estructurada.~ Esto fadlita la lectura del c6digo fuenle y afrece la

base para las subsecuentes actividades de ingenierla inversa. EI n(ldeo de la ingenierla inversa es una actividad llamada exlracci6n de abstrac-

dones.

EI ingeniero debe evaluar el programa antiguo y, a partir del c6digo Fuente

(con frecuencia sin documentar), desarrollar una especiflcad6n significaliva del procesamiento que realiza, la interfaz del usuario que se aplica y las estructuras de datos del programa 0 las bases de datos que se utiHzan.

31 .3.1 Ingen1eria inversa para comprender los datos

La ingenierfa inversa de datos ocum en diferenles grados de abstracci6n y can Frecuencla es la prim era larea de reingenieria AI nivel del programa, las estructuras de datos internos del programa usualmenle deben someterse a reingenierla inversa

4 El c6dlgo 5e reestructura empleando un -*:It ~tmKi6n, una herramienla que reesJ.ruclura c6dlgo fuente

91.

PARTE CINCO 1t:MAS AVANZADOS EN INGENlrnlA DEL SOl'TWARE

como parte de un esfuerzo global de reingenierta. En eJ nivel del sistema las estructuras globales de datos (por ejemplo, archivos, bases de datos) con frecuencia se sameten a reingenierla para ajustarlos con los nuevas paradigmas de gesti6n de bases de datos (por ejemplo, el movimiento desde los archivos pianos hacia los sistemas de bases de datos relacionales U orientados a objetos) . La ingenieria inversa

de las actuales estructuras globales de datos establece el escenario para la introducd6n de una nueva base de datos que abarque todD el sistema.

los compromisos
apalentemenfe ~ nmcanf8s etI /as estnxturos de ooIDs
~{onducKo

Estructuras d e datos intemos. Las tecnicas de ingenieria inversa para datos internos del programa se enfoca en la definici6n de clases de objetos. Esto se logra al examinar el c6digo del programa con el prop6sito de agrupar las variables de programa relacionadas. En muchos casos, la organizaci6n de los datos dentro del c6digo identifica tipos abstractos de datos. Por ejemplo, eslructuras de registro, archivos, listas y otras estructuras de datos con frecuencia ofrecen una indicaci6n inicial de las clases.

""""'" 1'".>601
aio5 fufrxas.

mente rotastr6ficos en

(oosidete como
"""" eI pro/Jooo Y2K.

Estructura de bases de d atos. Sin importar su organizaci6n l6gica yestructura fisica, una base de datos permite la definici6n de objetos de datos y apoya algun metoda para establecer relaciones entre los objelos. En consecuencia, la reingenieria de un esquema de base de datos en otro requiere comprender los objelos existentes y sus relaciones. Los siguientes pasos [PRE94] se pueden utilizar para definir el modelo de datos existente como un precursor para la reingenieria de un nuevo modele de base de datos: I) construcci6n de un modelo inicial de objeto, 2) determinaci6n de los candidatos clave, 3) retinar las c1ases tentativas, 4) definici6n de generalizaciones y 5) descubrimiento de asociaciones (empleo de tecnicas ana10gas al enfoque CRC) . Una vez que se conoce la informaciOn definida en los pasos precedentes, se aplica una sene de transfonnaciones [PRE94] para correlacionar la estructura antigua de la base de datos con una nueva estructura de base de datos.

31.3.2 Ingenieria inversa para comprender el procesamlento

La

ingenieria inversa para comprender el procesamiento comienza con un intento por comprender y luego extraer abstracciones de procedimientos representadas por el c6digo fuente. Para comprender las abstracciones de procedimientos el c6digo se analiza en grados variables de abstracciOn : sistema, programa, componentes, patrOn y planteamiento. La funcionalidad global de todo el sistema de aplicaci6n se debe comprender antes de que ocurra un trabajo de ingenieria inversa mas detaJlado. Esto establece un contexte para un mayor analisis y ofrece poca visi6n de los conflictos de interoperabilidad enlre las aplicaciones dentro del sistema. cada uno de los programas que conforman el sistema de la aplicaci6n representa una abstracci6n funcional en un mayor grado de detalle. Se crea un diagrama de bloques que representa la interacci6n entre dichas abstracciones funcionales. cada componente realiza alguna

subfunci6n y representa una abstraccl6n de procedJmlento definida. Para cada componente se desarrolla una narrativa de procesamiento. En algunas situaciones ya existen especificaciones del sistema, el programa y los componentes. Cuando este es el caso, las especificaciones se revisan para verificar si concuerdan con eJ cOdlgo
existente.~

It ...............

...... _ . . .....

'1 ~ asi COIIIO

~_do

. _.

.m. IllIG par Ia mo. OidIa pasi6II . . . . . . . . . .....

Las casas se complican mas cuando se considera e\ c6digo denlro de un componente. El ingeniero busca las secciones de c6digo que representen patrones de procedimiento genericos. Casi en cada componente una secci6n del cMigo pre para los datos para el pracesamiento (dentro del m6dulo), una secci6n dlferente de c6digo realiza el pracesamiento y otra secci6n del c6digo prepara los resultados del pracesamiento para exportarlos desde el componenle_Dentro de cada una de estas sec ciones se pueden encontrar pequenos patrones; por ejemplo. la validaci6n de los datos y fa verificaci6n de enlaces con frecuencia ocurre dentro de la secd6n de e6digo que prepara los datos para el pracesamiento. En sistemas grandes la ingenierfa inversa. por 10 general, se logra utiJizando un enfoque semiautomalizado. Las herramientas automatizadas se utilizan para ayudar al ingeniero de software a comprender la semantica del c6digo exislente. Enlonces la salida de este proceso pasa a la reestructuraci6n y a las herramientas de ingenieria avanzada para completa r el praceso de reingenierla.

--

31.3.3 Ingenieria inversa de interfaces de usuarto

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 mas comunes de actividad de reingenierla. Pero antes de que una interfaz de usuario se pueda reconstruir debera realizarse una actividad de ingenieria inversa. Entender por completo una interfaz de usuario existente requiere especificar la estruclura y el comportamiento de la interfaz. Merlo y sus colegas (MER93J sugieren tres preguntas basicas que se deben responder con forme comienza la ingenieria inversa de la IGU: ,Cuales son las acciones basicas (por ejemplo, presiones de tecla 0 elics de rat6n) que debe procesar la interfaz?

5 COn frecuenoa, las especlrlCllCioncsetall&S en las pnmeras etapas en la hislona de Vida de un pro-

grama n\lnca se actuallzan Conlorme II:. cambIos 5e reabzan. el c6dlgo ya no cOIlcuerda m;b con
las especiflcaciones.

.,,
,co..
ItfII.ndtr los nndon.s de Ina
IIleriDI .. ISH-

PARTE CINCO

1l:MAS

AVANU>.D05 EN INGENIERiA CU SOFTWARE

.::Cuttl es la descripci6n compacta de las respuestas de comportamiento del sistema a estas acciones?

i..Que se entiende por "reemplazo" 0, mas exactamente, que concepto de equi~

valencia de interfaces es relevante en este caso?
La notaci6n de modelado de comportamiento (capitulo 8) puede ofrecer un media

rio existlflt.?

para desarrollar respuestas a las primeras dos pregunlas. Gran parte de 1a infonna-

ci6n necesaria para crear un modelo de comportamienlo se puede obtener observanda la manifestaci6n extema de la interfaz existente. Pera la informaci6n adicional necesaria para crear el modelo de comportamiento se debe extraeT del cMigc.

Es importante senalar que una GUI de reemptazo tal vez no rel1eje exaclamente
la interfaz antigua (de hecho, quiza sea radicalmente diferente). Con frecuenda vale la pena desarrollar nuevas melMoras de inleracci6n. Por ejemplo, una GUI anligua solicila que un usuario proporcione un faclor de escala (que varia desde I hasta 10) para encoger

a ampliar una imagen grafica. Una GUl sometida a reingenierla puede

ulilizar una barra de deslizamiento y un rat6n para realizar la misma funci6n.

f!!!!!IIIIIIlngenJerfa inversa
~ Objet;vo: Ayudar 0 los iogenierOl de software o ccmprender Ie esIruduro de di$eOO intemo de los progromos compIejos.
Meconico: En Ie moyorio de 10, COSO$, 10$ herromiento$ de insemeric inveoo oceplon Wdigo fuenle como entrodo YpJOdUCefl una dlversidod de representociones de di5elio
...Irudu,,,,l. procedimionto. doloa y ....... portamionto. software C y C++ complejo 0 heredoclo" 01 SOtI'\etel'" 0 inge nierio inveno 'I documenlor til Wdigo fuente.

UncJer,tond, desorrollodo

pol'" Scientific TooIworks, Inc. {www.scitools.com}. onolito gromoticolmenle Ado, Fortron, C, C++ y JC1'I(l "poro reolizor ingenierlo inversa, do.:.vmenlor out0m6ticorneme, cokular metriCOI de Wdigo y ouxiliono 0 oomp,endet-, ~r y monlener eI c6digo fuente- .

Herramientas representativQs
lmogi.., 40, deoorrolloda par lmogix {www.imogiu;om), N oyvdo a 10. desorralladores de soltwore 0 oomprender

Uno exlenso liw

de herrcmientos de ingenieria inverso se puede encontror em http;//scgwiki.iom.unibe.ch;8080/

SCG/370.

La reestruClurad6n de software modifica el c6digo Fuente 0 los datos con la final i ~

dad de adecuarlos para futuros cam bios. En general. la reestructuraci6n no

modifi~

ca la arquitectura global del programa. Tiende a enfocarse sobre los delalles de disefio de los m6dulos individuales y en las eSlructuras de datos locales definidos denlro de los m6dulos. 5i el tTabajo de reestrucluraci6n se extiende mas alla de las fronteras
6 l2s h.erramienlas expuestas el aulor no las respalda; s610 represenlan una muestra de las herramientas ir.c:luidas en esta categoria. En la mayoria de los casos, los nombres de las herramientas son marcas registradas por sus re5pe(:livos desarrolladores.

cAPiTuLo 31

RElNGEN!RlA

9"

del m6dulo y abarca la arquitectura del software, la reestructuraci6n se convierte en ingenierfa avanzada (secci6n 31.5) ,
La reestructurad6n ocurre cuando la arquitectura basica de una aplicaci6n es

s6lida, aun cuando el interior tecnico necesite trabajarse. Se inida cuando grandes partes del software son fundonales y 5610 un subconjunto de los componentes y datos necesltan una modificad6n extensa .1

31 .4.1 Reesbuctwac16n del c6d1go

La reestructuraci6n del c6digo se realiza para generar un diseno que produzca la

ALn;uI reestroc/lt

.,..,,",,""'" _.k

*' _dol,,,,,,

""""' " """'" k""'"

coo.b~a

~,Ml"'es

.-.

_1

l>Inm>"w.."
sda CI.8Ida StIllStnJe/WI.bs 00tas y

misma runcl6n que el programa original. pero con mayor calidad. En general, las tec~ nicas de reestructuraci6n de cMigo (por ejemplo, tecnicas de simplificaci6n 16gica de Wamier {WAR74]) modelan la 16gica del programa utilizando algebra booleana y luego aplican una serie de reglas de transrormaci6n que praducen J6gica reestructu ~ rada. EI abjetivo es tomar el "taz6n de espagueU" de cMiga y derivar un diseno de procedimiento que concuerde can la tilosofla de la programaci6n estructurada (capj ~ tulo I I). Tambien se han propuesto atras tecnicas de reestructuraci6n para utillzarlas con las herramientas de reingenierla. Un diagrama de intercambio de recursos correla~ dona cada m6dulo de programa y los recursos (tipas de datos, procedimientos y variables) que se intercambian entre ellos y otros m6dulos. Mediante la cread6n de representaciones del flujo de recursos se puede reestructurar la arquitectura del pro~ grama para lograr minimos acoplamientos entre m6dulos.

31.4.2 Reesbuctwaclon de los datos

Antes de comenzar la reestructuraci6n de datos se debe llevar a cabo una actividad de ingenierfa inversa denominada anMsis del ctxligo fuente. Primero se evaluan todos los enunclados del lenguaje de programaci6n que contengan deliniciones de datos, descripciones de archivos, 1 10 y descripciones de interfaz. La finalidad es exlraer elementos y objetos de datos para obtener informaci6n acerca del flujo de datos y comprender las estructuras de datos existentes que se han implementado. Esta actividad a veces se denomina analiSJs de datos {RIC89]. Una vez completado el amUisis de datos comienza el rediseiio de datos. En su forma mas simple, un paso de esli1ndanzaci6n de registro de datos clarilica las deli~ niciones de datos para lograr consistencia entre los nombres de elementos de datos o formatos de registro flsicos dentro de una estructura de datos existente 0 farmato de archivo. otra rorma de rediseno, denominada racionaJizad6n del nombre de los dalos asegura que todas las convenciones de nombramiento de los datos concuer~ dan con el estandar local y que 105 pseud6nimos se eliminan como flujo de datos a traves del sistema.

veces es dHfcU distinguir entre ~ ecten5CII Y volver a desarroJtar

Ambos son rein

genierla

PARTE C INCO

n:MAS AVANl./>.OO6 EN INGI'NIERL\ DEl. SOfTWAR2

Cuando la reestructuraci6n rebasa la estandarizaci6n y la nacionalizaci6n se rea lizan modificaciones flsicas a las estructuras de datos existentes para lograr que el disei'io de los datos sea mas erectivo. Esto puede slgnificar una traducci6n de un farmato de archivQ a otro 0, en algunos casos, la traducci6n desde un Upo de base de

datos a olro.

~ Reestructuraclon de software

IIiiiiiiII Obierivo: EI obierivo de Io~ herromienlos de

reMlruduroci6n es Ironsfonnor eI antiguo ~

para

uno diver$ic!od de copocidodes de ~i6n COBOL, C/CH, Jovo, fORTRAN 90 y VHOL

poi'"

WIlre de computodoro carenle de es.truduro en lenguajes de progromoci6n y estructuras de diseno modemos. Mec:onico: En generol, eI codigo fuente w irlQre50 y trollsforma en un mejor progromo estrvcturodo. En algunos 00$0$, 10 trcmslormoci6n 0CLI!1l! dentro del mi~ lenguaje de progromoci6n. En oIros 00505, un lenguaie de programoci6n ontiguo sa IranJorma en un Ienguoje m6s moderno.

FORESYS, desorrolloda

Simulog (www.limulog.h"!.

onolizo y Ironsformo progromos e5Critos en FORTRAN,

Function Encopwlotion Tool, desorrolloda en 10 WOytlfJ State University

(www.(s.woyne.edu/~vip/RefoctoringTools/).reloctofi

zo en C++ los OfltigUO$ progrornos en C.

Herromienta, rept'esentativos'

OMS SoItwore Reengineering 1oo/I(i" desorrollodo por

Semantic Delign Iwww.semc:lesignu:lOm). proporciono

plusFORT, deKJl'TOiIodo por Polyhedron (www.poIyhedron. com), es un conjunto de herromiento~ de FORTRAN que tiene copoc~ poro reeslTvduror en FORTRAN rnoderno 0 C e~ndor 105 progrornos en FORTRAN deficientemenie diseilodc,

Un programa con flujo de control-el equivalente gralico de un taz6n de espagueti, con "m6dulos" que tienen 2 000 enunciados de langitud, con pocas lineas significativas de comentaTios en los 290 000 enunciados fuente y ninguna olra documentaci6n, se debe modificar para Que se ajuste a los cambiantes requerimientos de los usuari os Se tienen las siguientes opciones:

, Qu' opdonn ulll.n

1. Se puede tTabajar modificaci6n tras modificaci6n, luchando con el diseno im pEcita y el c6digo fuente para implementar los cambios necesarios. 2. Se puede intentar comprender eJ extenso fundanamienta interna del programa can el prop6slto de realizar modilicadanes de manera mas eliciente . 3 . Se puede redisenar, recodificar y probar aquellas porciones del software que requieran modilicaci6n mediante la aplicaci6n de un enfoque de ingenierla del software en lodos los segmentos revisados.

(Hndo Sf .nfr.nto lin progromo dtRdent.ment. MseiiOH . ..",,...tode?

Las herramlentas expueslas 5610 represenlan una mues\ra de esta categorla En la mayorla de los casos los nombres de las mismas son mareas registradas por sus respectivos desarrolladores

CAPiTuLo 31

RElNGENlDl1A

...

4.

se puede redisei'iar, recodificar y probar eJ programa completamente empJeando herramientas de reingenieria como auxiliares para comprender el diseiio actual.

No existe una opci6n Individual ~correcta" Las circunstancias pueden dictar la pomera opci6n, incluso si las otras son mas deseables. En lugar de esperar hasta que se reciba la solicitud de mantenimiento, la organ;zaci6n de desarrol\o 0 soporte utiliza los resultados del analisis de Invcntario5 para seleccionar un programa que I) se empleara durante un numero detenninado de arios, 2) actualmente se utilice can exito, y 3) es probable que experimentara grandes modificaciones a mejoras en el futuro cercano Entonces se aplican las opciones 2,3 a 4 Este enfoque de mantenimiento prevcncivo 10 introdujo Miller [MILSII con el nombre de retrofit estructurodo. Este concepto se define como "la apHcaci6n de las metadologias de hoy a los sistemas del ayer para apoyar los requisitos del manana" A primera vista, la sugerencia de que se desarrolle de nuevo un gran programa cuando ya existe una versi6n operaliva puede parecer bastante extravagante. Antes de emilir un juicio, considerense los puntos siguienles: I. El costo de mantener una linea de c6digo fuente tal vez oscile entre 20 y 40 veces el cosIo de su desarrollo inicial
ID~MnIIl' G/a inpieza

plXm

--IIlIIItf sus mctk"as

,..,_yo

dttntd. Puede pemDf en " . dt tr11MIIS

f1I(fS. PIJfG ''IfJf1fooi.

2. EI redisei'io de la arquiteclura de software {estructura de programa 0 datos) empleando conceptos modernos de diserio puede facilitar enonnemente el mantenimiento futuro 3. Puesto que ya existe un prototipo del software, el desarrollo de la productividad debe ser mucho mayor que el promedio. 4. EI usuario ahora liene experiencia con el software. En consecuencia, los nuevos requisitos y la direcci6n del cambio pueden afirmarse con mayor facilidad

,.., """"" ddo,

5. Las herramienlas automatizadas para reingeniena facilitaran algunas partes del trabajo.
6. Antes de tenninar el mantenimiento preventivo existira una configuraci6n completa del software (documentos, programas y datos). Cuando una organizaci6n de desarrollo de software vende software como producto. el mantenimiento preventivo se considera como "nuevas liberaclones" de un programa. Un gran desarrollador de software local (por ejemplo, un grupo de desarrollo de software para sistemas de negocios destinadas a una gran compai'ila can sumidora de produCIOS) puede teneT 500-2 000 programas de producci6n dentro de
EI termino retrofit (literal mente retroajiJSlel recile mochas denommaciones en espanol, entre las

que deslacan remodelaoo. modemlZldon. retrocambto. reajuste. mo(lirlcaci6n relroacliva. Para no

generar contusiOn con otrosconcep.:., dmouunKiones Slmilares. pero no relacionados. utihzare el terminoor1ginal. que por Iodrmas.es ,eco_:1dcuknlrodd medlO (NT)

PARTE ClNCO

TEMAS AVJ>.NUJX;6 EN R<lGENIERIA Dtl. SOFTWARE

su dominio de responsabilidad. Dkhos programas pueden c1asificarse segun su importancia y luego revisarlos como candidatos para mantenimiento preventivo. El proceso de ingenieria avanzada aplica los principios, conceptos y metodos de la ingenieria del software para recrear una aplicaci6n existente. En la mayarfa de los ca50S, \a ingenieria directa no simplemente erea el equivalente modemo de un pro

grama antiguo. Mas bien, los nuevas requisitos de usuario y leenoiogla se integran
en el tTabaja de reingenieria. El programa que se desarrolla de nuevo ampHa las

capacidades de la aplicad6n anterior.

31 .5.1 Ingenieria directa para arquitecturas cUente/ servtdor

Durante las decadas pasadas muchas aplicaciones para computadora central se han semetido a reingenieria para adaptarlas a arquitecturas cliente/servidor (incluse WebApps). En esencia, los recursos de c6mputo cenlralizados (que incluyen senware) se distribuyen entre muchas plataformas cHente. Aunque se pueden disenar varios entomos distribuidos diferentes, 1a aplicaci6n tipica de computadora central que se semele a reingenieria en una arquitectura cliente/servidor tiene las siguientes caracteristicas:
La funcionalidad de la apJicaci6n migra hacia cada computadora cliente.

En los silios c1iente se implementan nuevas interfases IGU. Las funciones de base de datos se asignan al servidor.
La funcionalidad espedalizada (POT ejemplo, analisis intense de c6mputo)

puede pennanecer en el siUo servidor. Tanto en los sitios c1iente como servidor se deben establecer nuevos requlsitos de comunicaciones, seguridad, archivado y control. Es importante senalar que la migraci6n desde la computadora central hacia el c6mputo diente/servidor Tequiere reingenieria tanto de negocio como de software. Ademas,

flsu
fn dgLrm 0lSDS, b migroci6n hodrJ iJ

:se debe establecer una infraestructura de red de empresa" UAY94) . La reingenieria para aplicaciones cliente/servidor comienza con un amplio ana-

arquiret/llto cknteSfrVidtJt fit) debe

~(omoftlit.

lisis del entomo de negocios que incluye la computadora central existente. Se pueden identificar tres capas de abstracci6n. 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 (deflnidas mediante un proceso de negocio existente 0 sometido a reingenieria). Las aplicaciones cliente o[recen la fundonalidad deseada para la comunidad de usuarios. Las fundones del sistema de gesti6n de bases de datos existente y la arquitectufa de datos de la base de datos existente deben someterse a ingenierla inversa como precursores del rediseno de la capa de base de datos. En algunos casos se crea un nuevo modelo de datos (capitulo 8). En cada caso la base de datos cliente/servidor se somete a reingenieria para garanti zar que las transacciones se ejecutan en [anna

""*",, IIIIO COIRO III OOI!W tJS!rJemJ dt

_ . 1 . ....

.... IiaJdtI-.

nietfo iIf1!Sl1 d

""*' """"'"" **""""" -'"

. " MIG m;UfBr.

cAPiTuLo 31

RlNGENlERiA

.21

consistente, que todas las actualizaciones las realizan s610 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, contralos 0 comunicaciones relacionados con dicha empresa), que las consultas se pueden ajustar eficientemente y que se ha establecido una capacidad completa de archivado.
La capo de reg/as de negocios representa el software que reside tanto en el dien te como en el servidor. [Ste software realiza tareas de control y coordinad6n para garantizar que las transacciones y consultas entre la aplicaci6n clienle y la base de

datos se ajustan al proceso de negocios establecido.

La capo de aplicaciones cliente implementa funciones de negocios que requieren grupos espedficos de usuarios finales En muchas instancias, una aplicaci6n de computadora central se segmenta en varlas aplicaclones de escritono mas pequerias y sometidas a reingenierla. La comunicaci6n entre las aplicaciones de escritono (cuando es necesario) se contrela mediante la capa de reglas de negocios.

Un estudio completo del diseno y la reingenieria del software clienlef servidor es materia de Iibros especializados. El lector interesado debe consultar [VAN02J,
[COUOOI Y IORF99I.

31 .5.2 Ingen1eria directa para arquitecturas ortentadas a ob}etos

La ingenieria del software orienlado a objetos se ha convertido en la alternativa en

cuanto al paradigma de desarrollo para muchas organizaciones de software. Pera, Nue hay acerca de las aplicaciones existentes que se desarrollaron empleando metodos convencionaJes? En algunos casas la respuesta es dejar tales aplicaciones "como estan~. En olros, las aplicaciones viejas deben someterse a reingenieria de modo que se integren con facilidad en grandes sistemas orientados a objelos.
La reingenieria del software convendonal en una implementaci6n orientada a

objetos utiliza muchas de las mismas tecnicas estudiadas en la parte 2 de este libra. Primero, el software existente se somete a ingenieria inversa de modo que sea posi ble crear modelos de datos, funcionales y de comportamiento apropiados. Si el sistema de reingenieria amplia la funcionalidad 0 el comportamiento de la aplicaci6n original, se crean casas de usa (capftulos 7 y 8). Luego los modelos de datos creados durante la ingenieria inversa se utilizan junto con el modelado CRC (capitulo 8) para establecer la base con que se definil-an las dases. Enseguida se definen las jerarqufas de dases, los modelos de relaci6n de objetos, los modelos de comportamiento de objelos y los subsistemas y entonces comienza el disef'io orientado a objetos. Conforme la ingenierla directa orientada a objetos progresa desde el analisis hasta el diseno se puede invocar un modele de proceso ISOC (capitulo 30). Si la apli caci6n antigua se encuentra en un dominio que ya ocupan muchas aplicaciones orientadas a objelos, es probable que haya una buena biblioteca de componentes y que se pueda utilizar durante 1a ingenieria directa

PARTE CINCO

TThlA$ AVANlJ\.IXX; N 1NGENIRlA DEL SOfTWARE

En aquellas clases que daban construirse desde el principia tal vez sea posible reutilizar algoritmos y estructuras de datos de la aplicad6n convencional exislente. Sin embargo, quiza sea precise disenarlos de nuevo para ajuslarlos a la arquitectura orient ada a objetos.

31.5.3 lngenieria directa de interfaces de usuarto

Conforme las aplicaciones migran de 1a computadora central hacia el escritorio, los usuarios ya no desean tolerar las interfaces de usuario misleriosas basadas en ca racteres. De hecho, una porci6n significativa del tTabaja empleado en la transici6n de la computadora cen tral a la computaci6n cliente-servidor se puede dedicar a la reingenieria de las interfaces de usuario de la aplicaci6n clienle. Merlo y sus colegas [MER95J sugieren el siguiente modelo para la reingenieria de interfaces de usuario:

f:.NW
illA pos4S ssp poro SMJef8f a
r9k/geMiJI.tlO rJlWfru III umio?

Sf_

I. Comprender 10 interJaz original y los datos que ~ trasladan entre ella y eJ resto de la aplicaci6n La finalidad es entender c6mo otros elementos de un programa

interactuan con el c6digo existente que implementa la interfa z. Si se desarrollanl una nueva GUI, los datos que fluyan enlre esta 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 comporramiento implfcito en la illlerJaz existente en una serie de abstracciones que tengan sentido en e/ contexto de uno GU!. Aunque el modo de
imcraccion pucdc ser radicalmente diferente, el comportamiento de negocios que muestran los usuarios de las interfases vieja y nueva (cuando se Ie considera en lerminos de un escenario de utilizaci6n) debe pennanecer igua!. Una interfaz redisei'iada debera permitir que un usuario muestre el comporta miento de negocios apropiado. Por ejemplo, cuando se cansulta una base de datos la vieja interfa z puede requerir una larga serie de comandos basados en

I HI II Whit'

-......,-, O;>s~.

lkullcn.oal dlllllls de 300 p(IgI:a IDItO de

texlO para especificar la consulta. La GUI sometida a reingenieria puede diri gir la consulta a una pequeria secuenda de elecdones con el rat6n, pero el prop6sito y el conlenido de la consulla permanecen intactos.

, _.... ..... """" ,...........

fAMOOS EWI) Ie

3. IntroduC/r meJoras que hagan mas ejiciente el modo de interacci6n. Las fallas ergon6micas de la interfaz existente se estudian y carTigen en el disefio de la nueva GUI.

4. Construir e integrar la nueva GU!. La existencia de bibliotecas de c1ases y herramientas automatizadas puede reduclr significativamente el trabajo requerido para construir la GUI. Sin embargo, la integraci6n con el software de la aplicad6n existente puede requerir mas liempo. Debe tenerse cuidado de garantizar que la GU! no propagara efectos colaterales adversos en el resta de la aplicaci6n .
, . . pagar poco d' .. oahara, D puede pagat mumo dinero mils odeIame:

"'-"'1/

,.....'.....1

Allultdo d. toller lIII(ilnko qM . . . . . ofntt

CAPmn.o 31

IWNGENDJI:fA

923

En un mundo perfecto, cualquier programa al que no se Ie pudiera dar manteni miento seria retirado inmediatamente, y serla sustituido por apHcaciones de mayor caUdad con reingenieria desarrollada empleando modemas praclicas de ingenieria del software. Sin embargo, se vive en un mundo de recursos limitados La reingenielia demanda recursos que pueden utilizarse para olros prop6sitos del negocio. En consecuencia, antes de que una organizaci6n intente someter a reingenieria una aplicaci6n existente, debe realizar un analisis costo-beneficio. Sneed ISNE95] ha propuesto un modelo de analisis costo-beneficlo para la reingenieria. Se definen nueve parametros:
PI - costa de mantenimiento anual actual para una aplicaci6n

costa de operaci6n anual actual para una aplicaci6n P3 - valor de negocios anual actual de una aplicaci6n P4 - costa de mantenimienta anual predicho despues de la reingenierfa Ps - costa de operaci6n anual predicho despues de la reingenieria P6 - valor de negocias anual predicho despues de la reingenlerfa P7 - costa estimado de la reingenierfa
P2
-

Pa - fecha estimada de la reingenieria P9 - factor de riesgo de la reingenieria (P9 - 1.0 es el valor nominal) L - vida esperada del sistema El costo asociado con el mantenimiento continuo de una apllcaci6n candidata (es decir, slla reingenieria no se realiza) se puede definlr como
(3 1- 1)

LoS costas asociados can la reingenieria se definen empleando la siguiente relaci6n:

(31 -2)

Con la utilizaci6n de los costos presenlados en las ecuaciones (31-1) y (31 -2) el beneficio global de la reingenierla se puede calcular como costa beneficia C""ng - C manl

(3\-3)

EI analisis costa-beneficia presentado en las ecuaciones se puede reallzar para todas las aplicaclones de alta prioridad identificadas durante el anaJisis de invenlario (secci6n 31.2.2) . Aquellas aplicaciones que muestren el mayor costo-beneficio podran destlnarse a la reingenieria, mienlras el trabajo con otras se puede posponer hasta que haya recursos disponibles.

La reingenieria se presenta en dos diferentes grades de abstraccl6n. En el ambito del negocio, la reingenierla se centra en el proceso de negocies can eJ pr0p6sito de efec-

...

PARTE CINCO

TEMAS AVANU.DCt3 EN ~ DEL SOFTWARE

tuar los cambios para mejorar la competitividad en alguna area del negocio. En el ambito del software, la reingenierla examina los sistemas y apHcaciones de infor mad6n con la finalidad de reeslructurarlos 0 reconstruirlos de modo que muestren

mayor caUdad.
La reingenieria de procesos de negocio (RPN) define metas del negocio, identifica

y evalua los procesos de negocios existentes (en el contexte de metas definidas). especifica y disefi.a procesos revisados, y elabora prototipos, los retina y particulariza dentro de un negocio. La RPN tiene un objetivo que va mas aHa del software. Su resullado con frecuencia es la definici6n de las fafmas en las cuales las tecnologlas de la infonnaci6n pueden apoyar mejor a los negocios.
La reingenieria de software comprende una serie de actividades que induyen

antdisis de inventario, reestructuraci6n de documentos, ingenierla inversa, reestruc lurad6n de programas y datos, e ingenieria dire<:ta. La finalidad de estas actividades es crear versiones de programas exislenles que sean de mayor caUdad y tengan mayor facilidad de manlenimiento (programas que seran viables ya muy avanzado e\ siglo XXI). EI analisis de inventarios permite que una organizaci6n evalue cada ap\icaci6n sistemalicamente, con la rinalidad de determinar cuales son candidalas a la relnge nierla La reestructuraci6n de documentos crea un marco de trabajo de documentaci6n que f. necesario para brindar apoyo a largo plazo a una aplicaci6n. La ingenieria I ~ es e\ proceso de analizar un programa can e\ prop6silo de oblener informa !..Iun de disei'io de datos, arqultect6nico y de procedimiento. Finalmenle, la ingenie ria directa reconslruye un programa empleando modemas practlcas de ingenierta del software y la informaci6n aprendida durante la ingenierla inversa. Et costo-beneficio de \a reingenierla se determina cuantitalivamenle. El cosiO del stattl quo. esto es, el costa asociado can el soporte y el mantenimiento actuates de una apticaci6n existente, se compara con los costas proyectados de la reingenieria y la reducci6n 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 reingenieria representa una estrategia de negocios efecti va en cuanto at costa.

ICAN721 canning, R , "The Maintenance 'Iceberil'~, en EDPAnalyzer, vol 10, num. 10, octubre de 1972. ICAS88] '"Case Tools for Reverse Engineering", en CASE Oullook, CASE Consulting Group, vol 2, num. 2,1988, pp. i-15. [CHI90[ Chikofsky, E. J Y J H Cross, II, "Reverse Engineering and Design Recovery; A Taxonomy", en IEEE Software. enero de 1990, pp. 13-17. [COVOQ[ Coulouris. G" J. Dollimore y T. Kindberg, Distributed ~Iems: Concepts and Design, 3a ed., Addison-Wesley, 2000. [DAV901 Davenport, T H. Y j. E. Young, NThe New Industrial Engineering; Information Technology and Business Process RedesignN, en Sloan management Review, verano de 1990, WII-27.

925
[DEM95J DeMarco, T., "Lean and M ean~, en IEEE Software, noviembre de 1995, pp 101- 102. [HAM901 Hammer, M ., ~ Reengineer Work: Don't Automate, Obliterate", en Harvard Business Review, julio-agosto de 1990, pp. 104-1 12 IHAN931 Manna, M ., "Maintenance Burden Begging for a Remedy", en l)(Jtamation, abril de 1993. pp. 53-63. UAY941 Jaychandra, Y. Re-engineering the Nerworked Enterprise, McGraw-Hili, 1994. 1MER931 Merlo, E. et aI, " Reverse Engineering of user Interfaces", Proc. workmg conference on Reverse Engineenng, IEEE, Baltimore, mayo de 1993, pp. 171 - 178 [MER951 Merlo, E et aI., "Reengineering User Interfaces", en IEEE Software, enero de 1995, pp 64-73, [M1LSI ] Miller. J-. en Techniques of Program and ~Iem Maintenance, (G. Parik h. ed) Winthrop Publishers, 198 1 [ORF991 Orfali, R., 0 Harkey y J. Edwards, ClienLlServer Suvival GUIde, 3a. ed, Wiley, 1999. [OSB901 Osborne, W. M Y E. J. Chikofsky, "Fitting Pieces to the Maintenance Puzzle", en IEEE Soj/'Nare, enero de 1990, pp. 10-11 [PRE9~J Premerlani, W. J. y M. R. Blaha, "An Approach for Re verse Engineering of Relational Oatabases~, en CACM, vol. 37, num. 5, mayo de 1994, pp 42-49, IRlC89[ Ricketts. J. A., J, C. DelMonaco y M. W. Weeks, "Data Reengineering for Application Systems", Proc. Con! Software Maimenance- 1989, IEEE, 1989, pp 174-179, [SNE95] Sneed, H., "Planning the Reengineering of Legacy Systems", en IEEE Software, enero de 1995, pp. 24-25. [5TE93J Stewart, T. A., "Reengineering: The Hot New Managing Tool", en Fortune, 23 de agosto de 1993, pp. 41-48 (S WA 76[ Swanson, E. B., '"The Dimensions of Maintenance", Proc, Sond Inti Conf SOftware Enginring, IEEE, octubre de 1976, pp 492-497. [VAN02] Van Steen , M y A . Tanenbaum, Distributed systems PrInCIples and Paradigms, Prentice-hall, 2002. [WAR74] Wamier, J. D., Logical Conslruclion of Programs, Van Nostrand-Reinhold, 1974

31.1. COnsiderar cualquier empleo realizado en los wtimos cinco allos. Describir el proceso de negocio en el que se particip6. Emplear el modelo de RPN descrito en la seccl6n 31.1.3 para recomendar cambios aI proceso con la finalidad de hacerIo mAs eficiente. 31.2. Investigar un poco ace rca de la eficacia de la reingenieria de procesos del negocio, Presenlar argumenlos en favor yen contra de este enfoque. 31.3. EI instructor seleccionara uno de los programas que todos en la clase han desarrollado durante este curso. Intercambie su programa en forma aleatoria con alguien mas en la clase. No explique u ofTezca un "paseo" par el programa. Ahora, Implemente una mejora (que haya espedficado el instructor) en el programa que ha recibldo,
a) Realice todas las tareas de ingenieria del sofiware, incluso una breve prueba manual

(mas no con el autor del programal. b) Conserve un cuidadoso seguimiento de todos los errores encontrados durante las pruebas c) Describa sus experiencias en clase 31.4. Explorar la !isla de verificaci6n del anAlisis de inventario presentado en el sitio web SEP e intentar el desarrollo de un sistema cuantitalivo de calirlCacioo de sofiware que pudiese aplicarse a programas existentes con la finalidad de elegir programas candidatos para rein gen ieria. EI sistema debe rebasar el anAlisis presenlado en Ia secd6n 31 .6 3 1.5. sugerir opciones a 1a documentaOOn por escrito 0 electr6nica convencional que pudiesen servlT como base para Ia reestructwad6n de documentos. (Sugerencla' piensese en las nuevas tecnologias descriptivas que se p(Klieran usar para com unicar el prop6silo del sofiware)

PARTE CINCO

TEMAS AV~ fN INGENlERlA 00. SOF1WAR

31.6. Algunas personas creen que la tecnologla de inteligencia artIficial aumenlan\ el grado de abslracci6n del proceso de ingenieria inversa. Realizar alga de invesligaci6n acerca de esta materia (es dccir, el uso de IA en la ingenieria inversa) y escribir un breve ensayo que contenga una opini6n acerca de este punlo 31.7. ,"Por que la completud es diflcil de lograr conforme aumenta el grado de abstracd6n' 31.S. ,"Par que debe aumentar la interactividad si la completud aumenta? 31.9. Con base en la informaci6n oblenida via Internet, presente a su c\ase las caracterlsticas de Ires herramienlas de ingenieria inversa 31.10. Existe una sutll direrencia entre reestructuraci6n e ingenierla directa ,"Cual es?

31.1 I . Investigue Ja bibliografla 0 fuen les de Internet para encontrar uno 0 mas escritos que borden estudios de case de reingenieria de compu tadora central a cliente-servidor. Presenle un resumen. 31.12. ,"C6mo delerminaria de P~ a PI en el modelo costo-benef1cio presentado en la secci6n 31.6'

Al igual que muchos temas apasionanles en la comunidad de negocios, las exageraciones que rodeaban la reingenierla de procesos de negocio han dado paso a una visi6n mas pragmatica de la materia. Hammer y champy (Rttngirnxring the CorporotKm, HarperBusiness, edici6n revi sada, 2001) precipit6 el interes lemprano con el exilo de venlas de su libra. Mas tarde, tiammer
(~
,~-

Rng1neering How the ProcessaJ-C~I~ organization 15 Changing Our WOrk and Our

lJves, HarperColhns. 1997) refin6 su visi6n al enfocarse sobre los lemas centrados en eI proLos libros de Smith y Fingar (Business Process Management (BPM); The Third Wave, MeghanKiffer Press, 2003). Jacka y Keller (Business Process Mapping: Improving Customer Satisfaction, Wiley, 2(01), Sharp YMcDennott (worJst1ow ModeJill8, Anech )Iouse, 2001), Andersen (Business Process Improvement TOolbox, American Society for Quality, 1999) Y Harrington et al (Business Process Improvem ent workbook, McGraw-Hill, 1997) presentan estudios de caso y directrices delalladas para la RP~ Feldmann (The Practical Gvide to Business Process Reeingineering Using lDEFO, Dorset House, 1<)9{I) onoli>;o U~ notaei6n de modelado que auxilia en la RPN Ber.(.tiss (SOjtware MelJlCdsjor Business Reenginemng, Springer, 1996) y Spurr ef 01 ISq'hwreAsslslnncefor BusinesS ~neeri1l8, Wiley, 1994) examinan herramientas y tecnicas que fad litan la RPN. secord y sus colegas (Modemizing Ugacy 5)5tems, Addison-wesley, 2(03) , Ulrich (Ugacy systems: Tmfls/omJaI/on 5(r(l1C81e$. Prentice-Hall, 2002), Valenti f,Succ~1 Software Reengmeering, [RM Press, 2002) y Rada (Reengineering software; How /0 Reuse Progrommill8 to &.uld new, Stale-ofthe~Art SOftware, Fitzroy Dearborn Publishers, J 999) se enfocan en las estrategias y praclicas para la reingenlerla en un contexte tecnico. Miller (Reengineering Ugao/ SOftware 5)5lems, Digital Press, 1998) ~ofrece un marco de trabajo para mantener las aplicaciones de los sistemas sincronizadas con las estrategias del negocio y los camblos tecnol6gicos". Umar IAPplication (Re}Engineeri1l8; Buildill8 Web-Based Applications and Deallns with Lcgades, Prentice-Hail, J 997) ofrece lineamientos valiosos para las OTganizaciones que quieren transfonnar los sistemas heredados en un en tomo basado en Web. Cook (BuildiIl8 nterp~ Information Architectures: Remginem1l8 Information S}'SIems, Prentice-Hall, 1996) analiza el puente entre 1a RPN Y La teenologia de la infonnaci6n. Aiken (D01a Reverse Engineering, McGraW-Hill, 1996) esludia c6mo recuperar, reorganizar y reutilizar datos de la organizaci6n. Arnold (Sojtware Rt%nglneering. IEEE COmputer SOCiety Press, 1993) ha reunido una excelente anlologia de los primerosensayos que Irataban acerca de las tecnologias de ]a reingenieria del soRware. Una amplia variedad de fuentes de infonnaci6n acetca de reingenierla de sofiware esta disponible en [nlemel. Una IiSla actualizada de teferencias en la World Wide Web se puede enconIrar en el sitio web SEPA:

http://www.mhhe.com/ pressman.

CAPiTULO

CAMINO POR RECORRER

CON C EPT OS
CLAVE

EL

32

-. ... c...w.. ....m

~I. .934

n [os 3 1 capitulos precedentes se exploro un proceso para [a ingenierla del

software. Se presenlaron tanlo procedimientos de gesU6n como metodos tccnicos, principios basicos y tecnicas especializ.adas, actividades o rienta-

atos ..... .. ,933

.....,

itIaI .... . . . .936

iiW..ttw_ .921
..... 1WClidiwI 933

...

das a las personas y tareas adecuadas para automatizarlas, notaci6n de papel y lapiz y herramientas de software. Se argument6 que la medici6n, la disciplina y una vigilancia estricta sabre la caUdad generaran un software que satisfaga las necesidades de los clientes, que sea fiable, que tenga facilidad de mantenlmiento, que sea mejer, Sin embargo, nunea se ha promelido que la ingenierta del soft-

ware sea una panacea.

Conforme se continue el viaje en el nuevo siglo, las tecnologlas de software
Y sistemas seguiran siendo un desaflo para los pro(esionilles del software y las compai'tlas que construyan sistemas basados en computadoras. Aunque escribi6 estas palabras can una vision del siglo xx, Max Hopper jHOP90] describi6 con precisi6n el estada actual del asunto: Puesla que los cambios en Ia tecnologla de la infonnacion se esUln volviendo tan ra pidos e lmplacables, y las consecuenciasde caer ante ellos son irreversibles, las com" panlas dominaran la tecnologia 0 moriran, P1ense en ello como en un molino de tecnotogla. Las compaf\las tendran que COTTer ca<la vez mas rapido para pennanecer en su lugar

,.--s ., ...930
,..... .931

.........

l..-..m ..936

,Quiprtd.cir

r&nCisfOs ~ trioIes no ,. rwatln

~=r:~~;E~Y:~ p.diccionet' iPor de que anoli5taS un por:::: ....... ::

recorrer 8116 exciton"", nue'YO$ tecnoIogku tfJ* nunca 10 lVeron 10 pelQr de

public:itoriosj, y con freo..eneio 10 hlCnologios m6s modNtas

F".dc.

'C.......... IN JMIIOI' No existe una form u~r

fX""-"

del pUblKo lee hor6scopos~ tabet quf vendrll para ester

aI camino que sa recorrer6 , Se nwdionle Ie recopilod6n de

modincoron 10 direcciOn y
principal. En conYCUenClO

que.

hooerio

~";;noc:i6n 6ti1- y .1 exomen de osociaciones obeener ccnocimiento y, a partir de

III orgol'lIzod6n pora proporcionar

,QuiOn 10 ......, lrodo 01.........

dec;r el futuro SinO que Io!. ronAid que comprender ccSmo eI so&wcny soft.Nore combiar6n en Sol afioI por

_l1li1081,

IJ'or que c:onl.olUbc:M guos reyes

9ro~ corporocionel

1~:'P~.:S~I:w:s;"~'~:~~~~5~~ ~:~~_:~s:_:-:mente? edeci eI cam iDe no ., un one Pr no una r cieocio.

Ie raro cuando una predicci6n
927

r probables hechos que pntd;gon los coso, en cierto tiernpo futuro. eI procIucto obtenldo? Uno visi6n cero:Il'IO que podna 0 no ser COI'Tecto. _ _ _ de que 10 he

_<0

PARTE CINCO

TI:MAS AV~ EN

MGNIERlA on SOI"lWARE

Los cambios en la tecnologla de ingenieria de software son de hecho "r<ipidos e implacables", mientras que, al mismo tiempo, el progreso, por 10 general, es bastante lento. Pero cuando se toma la decisi6n de adoptar un nuevo metodo (0 una nueva herramienta), de llevar a cabo el entrenamiento necesario para comprender su aplicaci6n y de introducir la tecnologia en la cultura de desarrollo del software, algo mas nuevo (e incluse mejer) ha IJegado, y el proceso comienza de nuevo. En este capitulo se examinan tendencias hacia el futuro. La linalidad no es explorar todas las areas de investigaci6n que resulten prometedoras. Tampoco es mirar en una "bola de cristal" y pronosticar el futuro. Mas bien, se explora el ambito del cambio y la forma en la que este afectara el proceso de ingenieria del software en los anos por venir.

32.1

LA IMPOIDM'IA nIL $O[tDRI. SEGgNDA PARTE

La importancia del software de computadora se puede establecer en muchas fonnas.

En e! capitulo I el software se caracteriz6 como un diferenciador. La funci6n que proporciona el software diferencia productos, sistemas y servicios, y ofrece una ventaja competitiva en el mercado. Perc el software es mas que un diferenciador. Los programas, documentos y datos que constituyen el software ayudan a generar el producto mas importante que cualquier individuo, negocio 0 gobiemo pueda adquirir: informa-

cion. Pressman y Herron [PRE91] describen aJ software en la fonna siguiente:

El software de computadora es una de 5610 unas cuantas tecnologias clave que tendran 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 tecnologia, un metodo de captura de experiendas valiosas para que las utilicen otros. un media para diferenciar los productos de una compania de los de sus competidores, y una ventana al conocimiento colectivo de una corporaci6n. El software es un pivote para casi cualquier aspecto de los negocios Pero, en muchas ronnas, el software tambien es una tecnologia oculta. Se encuentra software (usualmente sin darse cuenta de ello) cuando se viaja al trabajo, Sf realiza alguna compra al menudeo, se detiene en el banco, se hace una Hamada telef6nica. se visita al medico 0 se realiza alguna de las dentes de actividades cotidianas que reflejan la vida moderna.
La omnipresencia del software conduce a una conclusi6n simple: siempre que una tecnologia tenga un amplio impacto (un impacto que pueda salvar vidas 0

ponerlas en peligro, construir negocios 0 destruirlos, informar a los llderes de gobiernos 0 mal infonnarlos) debe manejarsele con cuidado.

CAPiTuLo 32 L CAMINO POR RECORRII

...-

,~

...

.'

'"

Los cambios en Ja informatica durante los pasados 50 anos han sido dirigidos par avances en las ciencias basicas; ftslca, quimica, ciencia de materiales e ingenieria Esta tendencia continuara durante el primer cuarto del siglo XXI. EI impacto de las nuevas tecnologias es profunda: en las comunicaciones, la energia, el cuidado de la salud, la transportaci6n , el entretenimiento, la economia, III industria manufacture ra y la guerra, por mencionar s610 unas cuantas_

(hoy YOrIo$ de~) identificor los 20 )ec;nQ\ogkls m6s prometedoros del mon(JIlo". Las ietnoIogias regislrodos

TecnoJogias a observm, Las tecnologias para miIar. tos edilores de PC Mogoz:ine [PCM03] ~ poro supervisor 10 presencia de armas preparan un numera anuol de "Tecnologias del biol6gicas 0 qulmioos. futuro que "'buscal 0 ~ de ~ ~ MfXXQ de chat Pantolk.. OLIo. Un OlEO (diodo emilOf de luz
org6nioo) "utilizo una moIecula disenodon::J con bose de carbona que emile luz cvanda una corrienlll! ebica paso a troves de ella. Junlll! muchas de est(]) moIecuios y oOtendr6 una panlallo muy deIgoda de o~ oolidod; no requiere lvenle de luz Ira~ que pro'I'OOO perdidas de ~ia" [PCM03). EI resullodo: panlallos ultrodelgodas que !oil pveden enrollor 0 dobiar, ~ sabre uno wperficie curvo odaptorw de alguno oIro forma 0 un entomo especifico.

obarcon tOOa una omplia garno, deKie eI cuidada de 10 solud hostel Ia guerro. Sin emborgo, f l inlet'esonte oo-vor que eI softwore y Ia ingenieria del softwore Iienen un significatiyo popel que jugar eTI tOOas, yo sea como imP'lISOfes de Ia tecnoIogfa 0 como una porte integral de ellos. las siguienles ~Ion una _Ira de los IecnoIoglos registrodas: Nanotubos de (amono. Con una fino estn.lctlJro porecida 01 Qrofilo, los nanolvbos de carbona pueden funcionor como alombres, pam IYonsmitir seOaIes desde un punlo 0 oIro, Y como lTonsislrore$, usondo combios de ~I poro olmoc:eoor infomwxi6n. EI usa de eslos di$pOsiliYOs porece prornetedor en .1 desarrollo de disptitiVO$ electr6nicos mOs pequeOOs, m6s r6pidos, de menor energia y menos costoIOs (par ejemplo, micropnxesodores, memorias, pantallosl. Bio n.o..... los sefl50reS microelectr6nicos, ~ 0 implontobles, yo se utilizan ompliamenle en 10 deleo:i6n, deKM ogenles qufmi(O$ en eI aire que w respiro hosla niveles de songre 81'1 pocienhH cardiocos. confonne fltoI'sensores!oll vvetvon m6s sofidicados, padr6n imp~nlar!oll en pacienleS medicos para supervisor uno yoriedad de condiciones relacionadas con 10 solud, 0 incorporarlos 0 105 uniformes de los.

Reticula d. computo. Esta tecno!agia (disponible en 10 actvalidodl crea una red que apravec:ho los miles de millones de dcbs de CPU no utilizodos de coda m6quina en 10 red y permi. que w complelen lareos de c6mputo excesivomenNi complejos sin conlar con una supet'COlT1P'1iodoro. V6aw un ejemplo pr6<:tico que oborco A 5 millones de computodoros en

http://setiothome.berbIey.edu!.
MOquinal cognitival. EI sonla grial en ~ campo de 10 rob6tico as desorrollor m6quinos que esten comcienles de w entomo, que puedon recabor pisla5, ~ a situociones siempre oombiantes e inIIn:Jduor con penonas de fI"IOdo no!urol" [PCM03]. lm mOquinos cognilivos todavia est6n en los primeras ~ de desarrollo, pero eI potencial (si !oil lagra

a9n:J ....z:) as WIOI'lI'Ie

9JO

PARTE CINCO

TDotAS AVAN'ZAJ:Jai EN INGENlERlA DL 9OFTWAII

!Ol"ilih d1

A largo plaza, los avances revolucionarios en la informatica bien pueden dirigirlos las ciencias sociales: psicologia humana, sociologla, filosofia, antropologfa y atras. El periOOo de gestaci6n de las tecnologfas informatlcas 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 antropoJ6gica- de usuarios, que son ramificaciones de las redes de pares a pares). La influencia de las ciencias sociales quiza ayude a moldear la direcci6n de la investigaci6n en informatica en las ciencias basicas. Por ejemplo, el diseno de las futuras computadoras tal vez 10 guie mas el conocimiento de la psicologia cerebral que el de la microelectr6nica convencional. A carta plaza, los cambios que inddirim en 1a ingenierla del software durante la siguiente decada redbiran la influencia de cuatro fuentes simultaneas: I) las perso. nas que realicen el trabajo, 2) e\ proceso que apliquen, 3) la naturaleza de la infor maci6n y 4) la tecnologla informatica subyacente. En las secciones que siguen se examinan con mas detalle cada uno de estos componentes: personas, proceso, informaci6n y tecnologla.

E1 software que requieren los sistemas de alta tecnologia se vuelve mas complejo cada ano, y el tamano de los programas resultantes aumenta propordonalmente. El rapido credmiento en el tamano del programa "promedio" presentarfa pacos problemas Sl no fuese por un hecho simple: conforme aumenta el tamano del prograrna, tambien debe aumentar eJ nOmero de personas que deben trabajar en el.

La experiencia Indica que conforme aumenta el numero de personas de un equipo de proyt:cto de SOnW~lfC:: , tal vez la productividad global del grupo disminuya. Una

forma para resolver este problema consiste en crear equipos de ingenierla del software, y en consecuencia dividir al personal en grupos de trabajo individuales. Sin embargo, conforme crece el numero de equipos de trabajo de ingenierla del software, 1a eomuniead6n entre ellos se vuelve tan dlflcil y tardada como la comunlcaci6n entre los individuos. Peor atm, la eomunicad6n (entre individuos 0 equipos) tiende a ser inefleiente; es decir, se pasa demasiado tiempo transfiriendo muy poco eontenido de informad6n, y con mucha frecuencia la informaci6n importante "cae entre las grietas".

11

'IFISN

"*"" delluturo 10 ogolacloro desorienlocilll que inducimos amDos."" periodo demasiodo (orto..
IS lemibn y

til

los indiriduos 01 mjeiIrIos 0

Si la comunidad de la ingenieria del software tiene que tratar con efleacia el dilema de la comunicaci6n, el camino que reeorreran los ingenieros de software debe induir eambios radicales en la forma en que los [ndividuos y los equipos se comunican entre si. EI correa eleetr6nico, los sitios Web y las eonferencias de videa centra-

--

cAPfnn.o 32

EL CAMINO POR RECadCJI

9"

lizadas ahara son mecanismos camunes para conectar a un gran numera de personas a una red de inrormaci6n. La importancla de estas herramientas en el contexta del trabaja de ingenierfa del software no se debe sobrevaluar. Con un correa electr6nico efidente 0 un sistema de mensajerfa instantanea, el problema que encuentre un ingeniero de software en la ciudad de Nueva York puede resolverse can la ayuda de un col ega en Tokio. En realldad, las sesiones de conversaci6n Ichatl sobre un lema particular y los grupos de noticias especlalizados se vuelven dep6sitos de conocimiento que permiten que el saber colectivo de un gran grupo de tecnicos sea aplicado para solucionar un problema tecnico 0 un conflicto de gesli6n EI video personaliza la comunicaci6n. En el meior de los casos, permlte que los colegas en diferenles ubicadones (0 en diferentes canlinentes) se "reunan" can cier ta regularidad. Ademas, el video lambien afrece otro beneficia: se puede usar como dep6sito de conocimiento acerca del software y para entrenar a los reeien Ilegados a un proyecto.

,. ..... dsIiaI-" IIlIe kl temoIoQio digitalIS ocIotJturia como WIG I1UM . . . . . 0 !olio 10
.. Jo t..-, Y...Ja (on pII!iOn, SlDdtlla, MmeridocI Y0te,1o."

..... 'rio ...

La evoluct6n de los agenles inteUgentes Iamblen camblara los patrones laiYJrales

Mds" r I!XIs "00 (XOflr.oolins o!SIOO

de un ingeniero de software al extender sustancialmente las capacidades lie las herramienlas de software. Los agentes inteligenles mejorartm la habilidad del ingeniero al eomprobar varias veees los productos de trabajo de ingenierla empleando conocimiento especlfico del dominio, realizando lareas adminislrativas, llevando a cabo una investigaci6n dirigida y coordinando la camunicaci6n entre las personas. Finalmente, la adquisici6n de conocimiento esta cambianda en forma radical. En Internet, un ingeniero de software puede suscribirse a grupos de noticias que se enfoquen en areas de tecnalogia que Ie interesen directamente. Una pregunta enviada a un grupo de nolicias precipita las respuestas de olras partes interesadas alrededor del mundo. La world Wide Web ofrece a un ingeniero de software la mas grande biblioteca del mundo de trabajos e informes de investigaci6n, manuales, comenlarios y rererencias acerca de la ingenierfa del software. Si la historla es un indicio, es acertado decir que las personas no cambiaran. Sin embargo, las formas en las que se camunican. el entorno en el que trabajan , la manera en la que adquieren conodmienlo, los m!loclos y herramientas que usan, la disdplina que aplican y, por 10 tanto, la cultura general del desarrollo del software cambiaran en rormas significalivas e inc1uso prorundas.

-.,..1> ..

... DC_
til "

"'""'" Omlti tew.JsiriJ oc1ID

~

-~
frAwo.
fslos

-....... ."""*'10 .......

M

-.."", i "."

..

estf 601 PtOOoblemtntf flO. ffIO

dO-.6gl,

-~irUosiflO~

Es razonable caraclerizar las primeras dos ctecadas de la practica de la ingenierfa del software como la era del "pensaJllimto lineal- Fomenlada por el modele c1asico del cicio vital, la ingenieria del software se ~0c6 como una actividad lineal en la que

PARTE CINCO

'I1:MAS AVANZ.ATX:1!> IN INGlN1llllA OEL S()f1WARE

se podrlan aplicar una serie de pasos secuenciales con la finalldad de resolver problemas complejos. Sin embargo, los enfoques lineales acerca del desarrollo de software corren contra la fonna en la que la mayorla de los sistemas realmente se construye. En realidad, los sistemas complejos evolucionan iterativamente, induso en forma incremental. Por esta raz6n, un gran segmento de la comunidad de ingenieria del software se desplaza hacia modelos incrementales agiles para el desarrollo del software. Los modelos de proceso incremental agH reconocen que la incertidumbre domina la mayorta de los proyectos, que los plazos de entrega con frecuencia son imposibJes de cumplir y cortos, y que la iteracion proporciona la habilidad de dar una soluci6n parcial, induso cuando un producto completo no es realizable dentro del tiempo asignado. Los modelos evolutivos subrayan la necesidad de productos de trabajo incrementales, analisis de riesgo, planeaci6n y luego revision del plan, y retroalimentaci6n con el cliente. En muchos casos el equipo de software aplica un "manifiesto .lSi!" (capitulo 4) que subraya "los individuos e interacciones sobre los procesos y herramientas; el software operativ~ sabre la documentaci6n detallada; la colaboraci6n del cliente sobre la negociaci6n de conlratos; y la respuesta al cambio sobre el seguimiento de un plan" IBECOlj.

" .., rr... moIiana IS hexer un buen

laS tecnologlas de obJetos, junto con la ingenierla del software basada en componenles (capitulo 30) , son una consecuencia natural de la tendencia hacia los mcxlelos de procesos incrementales y evolutivos. Ambos tendran un profundo impacto sobrc In productividad del desarrollo de software y 1a calidad del producto. La reutilizaci6n de camponentes afrece beneficios inmediatos y convincentes. Cuando la reutilizaci6n se une con las herramientas CASE para los prototipos de una aplicaci6n, los incrementos del programa se pueden construir mucho mas rapidamente que mediante los enfoques convencionales. La elaboraci6n de prototipos involucra al cliente can el proceso. En consecuencia, es probable que los clientes y usuarios se involucren mucho mas en el desarrollo del software. Esto, a su vez, puede conducir a una mayor satisfacci6n del usuario final y en general a mejorar la caUdad del software. EI rapido credmiento en las lecnologlas de red y multimedia (por ejemplo, el aumento exponencial en las WebApps durante las pasadas d~cadas) estti cambiando tanto al proceso de ingenieria del software como a sus participantes. De nuevo, se esta ante un paradigma incremental agil que destaca la inmediatez, la seguridad y la est~tica, as! como preocupaci6n por la ingenierla de software mas convencional. Los modemos equipos de software (por ejemplo, un equlpo de ingenierla Web) can frecuencia mezclan tecnicos con especialistas de contenido (por ejemplo, artistas, mUsicos, videogrMos) para construir una fuente de infonnaci6n destinada a una

CAPiTuLo 3:i1

EL CAMINO POR ROCORRR

933

comunidad de usuarios grande e impredecibJe, El software que se ha desarrollado con base en estas tecnologias ha generado radicales cambios econ6micos y culturales, Aunque los conceptos y principios basicos tratados en este libro son aplicables, el proceso de ingenieria del software se debe adaptar.

A \0 largo de la historia de \a informatica ha ocurrido una lransid6n suUl en la teT minologia con que se describe el trabaja de desarrollo del software realizado para la comunidad de negocios, Hace cuarenta atlas, el lermino proccsamiento de datos era la frase operativa para describir la utilizaci6n de las camputadoras en un contexto de negocios. En la actualidad, el procesamienlo de datos ha dado paso a atra Frase -teeno/agfo de 10 inJormoci6n- que significa 10 misma pero presenta un sutil cambia en el enfoque. La importancia radica no 5610 en procesar grandes cantidades de dalos, sino en obtener Informaci6n slgnificativa de dichos datos. Obviamente, esta fue siempre la finalidad, pero el cambia en la terminologia ref1eja un cambio mucho mas importante en la filosofTa de la gesti6n. Cuando en la actualidad se abordan las aplicaciones de software las palabras

datos e informaci6n aparecen repetidamente.

La palabra conocimienlO se encuentra en algunas aplicaciones de inteligencia artificial, perc su utilizaci6n es relativamente escasa, Virtualmente nadie se re fi ere a la sobiduria en el contexto de las apllca-

ciones de software. Los dalos son informaci6n en bruto: calecciones de hechos que deben procesarse para que sean significativos. La informaci6n se deri va al asociar los hechos en un

_de
i

"in1onnac:16n-,
Informaci6n: asocialividad denlra d. un cool8)(1o

Cooocimienlo:
asocialividad denlra de multiples cool8)(1os

I>

Sabiduria: creoci6n de principios

generclizodos coo
bose en el conocimiento procedenl8 de fuenles diferenles

PARTE CINCO

TEMAS AVANUJXJS EN INGINlIJl!A DEL SOFTWARE

contexto dado. EI conocimiento asocia la informaci6n obtenida en un contexte con otra informaci6n obtenida en un contexto diferente. Finalmente, !a sabiduria se pre~ senta cuando los principios generalizados se derivan de conocimientos dispares. Cada una de estas cuatro visiones de la "informaci6n" se representa esquematicamente en la figura 32.1. A la fecha, la gran mayor!a del software se ha construido para procesar datos 0 informaci6n. lOs ingenieros de software ahora estan igualmente preocupados con los sistemas que procesan el conocimiento. I 1 conocimiento es bidimensional. La informaci6n recopilada acerca de una diversidad de temas relacionados e inconexos se relaciona para formar un cuerpo de hechos que se llamara conocimiento. La clave es la habilidad personal para asociar la informaci6n proveniente de diversas fuentes, que tal vez no tengan alguna conexi6n evidente, y combinarla en una forma que ofrezca algun beneficio distinto.

-..a d:Iiduria as eI poder que pefmile ub Hzcr eI (onocimienl0 pam eI benefido de nosotros 1IIismos, ........

_L_

Para ilustrar la progresi6n desde datos hasta conocimiento, considerense los datos censales que indican que los nacimienlos en 1996 en Estados Unidos fueron 4.9 millones. Este numero representa un valor de datos. Al relacionar esta pieza de datos con las tasas de nacimiento para los 40 atlas precedentes, se puede derivar una litH pieza de informaci6n: los cada vez mas viejos baby boomers de 1a decada de 1950 y de principios de la de 1960 haclan un ultimo esfuerzo para tener hijos antes del final de su vida reproductiva, Ademas, los gen-Xers {miemhros de la generad6n Xl comenzaban su vida reproductiva. Los datos censales entonces pueden vincular5e con otra5 pieza5 de informaci6n aparentemente no relacionada. Par ejemplo, el numero actual de profesores de escuela elemental que se retiraran durante la siguiente decada, el numero de estudiantes universitarios que se graduaran en educaci6n primaria y secundaria, la presi6n sobre los politicos para mantener bajos los impuestos y, por 10 tanto, limitar los aumentos salariales a los profesores. Todos estos elementos de informaci6n se pueden combinar para formular una representacion del conocimiento: existira una presi6n significativa sobre el sistema educativo en Eslados Unidos en la primera decada del siglo XXI, y esta presion conlinuara durante una decada . Con la utilizacion de este conocimiento puede surgir una oportunidad de negocio. Quiza haya significativas oportunidades para desarroliar nuevos modos de aprendizaje que sean mas eficaces y menos costosos que los enfoques actuaJes.

El n'lpido crecirniento de las tecnologias de extracci6n y alrnacenarniento de datos refleja esta tendencia creciente.

cAPiTuLo 32

0. CAMINO fOR IlF( <:WRfR

.35

El camino que recorrera el software conduce a sistemas que procesan el conocimienlo. Se han eslado procesando datos empleando computadoras durante 50 alios y extrayendo informaci6n durante mas de Ires decadas. Uno de los desafios mas significativos que enfrenta la comunidad de ingenierla del software es construir sistemas que den el pr6xirno paso a 10 largo del espectro: sistemas que extraigan conocimiento a partir de los datos e informaci6n en una forma practica y beneficiosa

La genie que construye y utiliza software, eI proceso de ingenietia del software que

se aplica y la informaci6n que se produce resultan afectados por los avances en el hardware y la tecnologla del software. Hist6ricamente, el hardware ha servido como el impulsor tecnol6gico en la computaci6n. Una nueva tecnologia 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 fuluras de ta te<:nologla de hardware avancen por dos trayectorias paralelas. A \0 largo de una trayectoria las tecnologfas de hardware continuaran evolucionando con rapidez. Ante la mayor capacidad que ofrecen las arquitecturas de hardware tradicionales, las demandas a los ingenieros de software continuaran creciendo. Pero los cambios verdaderos en la lecnologia de hardware podrlan producirse en otra direcci6n. EI desarrollo de arquitecturas de hardware no tradicionales (por ejemplo, nanolubos de carbono, microprocesadores EUL, maquinas cognilivas, reticulas de c6mpUIO) podrlan provocar cambios radicales en el tipo de software que se construira y cambios fundamenlales en el enfoque hacia la ingenieria del software. Dado que estos enfoques no tradicionales se estan madurando, es dificil determinar cual tendra un impacto significativ~ e Incluso es mas difTcil predecir c6mo cambiara el mundo del software para adaptarse a elias. Las tendencias futuras de la ingenierla del software las impulsan las lecnologfas de software. La reutilizaci6n y la ingenierla 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. Quiza haya empresas que construyan dispositivos discretos (componentes de software reutihzables), otras empresas que conslruyan componentes de sistemas (pOr ejemplo, un conjunto de herramientas para la interacci6n hombre-maquina) e integradores de sistemas que ofrezcan soluciones (productos y sistemas construidos de forma personalizada) para el usuario final. La ingenieria del software cambiara, de eso se puede estar seguro. Pero, sin importar cuan radlcales sean los cambios, se puede eslar seguro de que la calidad nunca perdera su importancia . y de que el analisis y el diseno erectivos y las pruebas competentes siempre tendr.in un lugaf en el desarrollo de los sistemas basadas en computadoras.

PARTE cnoICO

TtMAS

AVANZADOS E:N INGEN1ERIA 00. 5OF'TWARE

INFORMACI6N

Tendendas tecnol6gicas
P. Cripwell Auodoles (www.jpcripwell.coml, uno firmo de consulloria espociolizoda en gesH6n del conoc::imienta II ingenierfo de Ia infonnaci6n, onalizo cil'\C() impulKnS iecnoI6giC05 que inRuir6n en las direcciones de Ia tecnoIogia en las ooos por venir. odvertencios; y debe inform6rseles 0 los outom6viles individuales (si est6n equipodos con sen~es digitales 0 comunicoci6n inal6mbrico). Pora Iogrorlo se debe Iomor una voriedod de c\ecisiooes, con bose en los datos odquiridos a partir del sistema de supefVisi6n (iusi6n de datos).
Tecnoiogia de empuje. En onos posodos surgiO un problema 'I se desorroll6 tec;noIogio para resoIerIo. Puesto que eI problema era evider"e para muc:has personal, eI mercodo poro 10 nueva hIcnoIogio eslobo bien definida. En 10 octuolidod, olgunos tecnoIogfas f!YOiucionon como soIuciones que bu.con problemas. Un mercodo debe empujorse para reconocer que necesita 10 nueYO tecnoIogfo (par ejemple, telMonas m6vi~s, PDA). Conforme los personas reconacen 10 necesidod, 10 tecnoIogfo se oceIero, mejoro y con frecuencio se ITonsfotmo conforme f!YOiuciona 10 combinoci6n de tecnoIogias.

CombinaciOn d. tecnologkn. Coando dos impartantes tecnoIogias se lunden, eI impodo del resultodo con hcvencio M mayor que Ia wmo del impodO de codo una por seporodo. POI' ejempla, 10 tecnoIogio de los soteIilM GPS {si~s de posicionomienta gIoball junlo con 10 copocidod de c6mputo 0 bordo y los IecnoIogfos de pontollas LCD han permiHdo conslnlir sofisricodos si$lemas de locoliUICi6n en los outom6viles. Los tecnologfos con frecueocio evoIudonon a rutas seporodos, pero 01 impo<:l0 en los nogocios 0 social significoHvo s6Io ocurre cuondo olguien los CQITlbina para resolver un problema.
$(I adquieran, rn6s dolO5 $(I roeICe$ilor6n . .....as impartanle oUn, mienlras m6s datos)ll odquieron, m6s dificil es extroer infonnoci6n Uti1. 0. heI;ho, con frecuencio $I necesito odquirir todcM'o rn6s Oems para ocmprender qui! datos son importonles;

FUliOn d. datos. Mienlras m6s dotos

qut!i datos

iOI'I

reHr.onles paro uno necesidod 0 Nerne

particular, y qLM datos se deben empIeor para Ie Ioma de J.c.o-.. ~... H.I.,...,bIema deta fu,iOn de datos. 1. P.
Cripwell uHlizo como ejempio un sis'-'o ovonzodo de
~,iOn de tr.!Jic:o ~Iidico Sen~1l digilales de ropidez len eI caminol y cOmoros digilales detectan un

Red Y (Gluolidod. En esIe conlexto, reel implico cone.x.iones entre penonas a entre personcs e informoci6n. Conforme crec.1o red, 10 probobilidod de sinergio entre dos ~ de red (par ejemplo, personas, fuentes de informoci6nJ tombien Crectl. Una conexi6n fortuilo (cowoJ) puede conducir a uno inlpiroci6n y a nuevo tecnoIogfo 0 aplicod6n.
Sobr.cargo d. inforln(lciOn. Un omptio oc6ona de informoci6n e$16 (I disposici6n de wolquiero con uno cone.x.iOn de Internet. EI probIemo, desde lvega, es encoolfor 10 informoci6n corredtJ, determinor MI volidez y luogo traduc:irlo en uno opIicoci6n pr6ctico en un 6rnbilo de negocios 0 per.anol.

occld..." ... La _' idad del occ;o.....le _ deb. det.n.'nor (to trcJyft de los c6morosl). Con bose en Ia 5oIMridod, eI si$lemo de supervlsi6n debe conlodor 0 10 po/ido, kn bomberos 0 ombuloncios; ellr6fico se debe reelirigir; los medias de comunicoci6n (radial deben difundir

La ingenierfa del software ha evolucionado en una profesi6n respetada en el ambi to mundial. COmo profesionales, los ingenieros de software deben regirse por un c6digo de ttiea que guie el trabajo que realizan y los productos que producen . Una fuerza de trabajo conjunto ACM/IEEE-CS ha producido un C6digo de elicay praclica proJesional para los ingenieros de software (versi6n 5.1). EI c6digo (ACM98] afinna:
Los ingenieros de software se deben comprometer a 51 mismos a convertir el analisis, la espedficad6n, el diseno, el desarrollo, la prueba y el mantenimiento del software en una profesi6n beneficiosa y respetada. En concordancia con SU compromiso con la salud, la

CAPiTuLo 32

El.

CAMINO POR IIiCORRDI

937

seguridad y el bieneslar del pUblico, los ingenieros de software deben adherirse a los siguientes acho Principies; I POBUCO. Los ingenieros de software deben actuar consistenteme nte con el interes del publico. 2. CUENTES Y EMP1..EAOORES. Los ingenieres de software deben actuar en una forma que beneficie \os intereses de sus clientes y empleadores y sea consistente con el interes publico. 3. PRODUcrO. Los ingenieros de software deben garanlizaT que sus productos y modllicaciones relacionadas satisfacen los mayores estandares profesionales posfbles. 4 JUICIO. Los ingenieros de software deben mantener la integridad y la independe ncia en su juicio profcsional. 5. GESTION. Los gestores y Uderes de la ingenierla del software deben suscribir y promover un enfoque etico de la gesti6n del desarrollo y el mantenimiento del software . 6. PROFES10N. Los ingenieros de software deben promover la integridad y la buena repulaci6n de la profesi6n en una fonna conslstente con el interes publico. 7. COLGAS. Los ingenieros de software deben ser justos con sus colegas y apoyarlos. 8. COMPROMISQ PE~NAL Los ingenieros de software deben participar en un aprendiza}e permanente en relaci6n con la practica de su profesi6n y promover un e nfoque etico para su pracUca

Aunque cada uno de estos acho principios es igualmente importante, aparece un tema mas relevante: un ingeniero de software debe trabajar en pro del interes publico. En el ambito personal, un ingeniero de software debe atenerse a las siguientes reglas: Nunca robar datos para beneficio personal. Nunca distribuir 0 vender infonnaci6n patentada que haya obtenido como parte de su trabaja en un proyecto de software. Nunca destruir 0 modificar maiiciosamente los programas, archivos 0 datos de otra persona. Nunca violar la privacidad de un individuo, grupo u organizaci6n. Nunca alaear un sistema por deporte

beneficio.

Nunca crear 0 difundir un virus 0 gusano de computadora. Nunca usar la tecnologla de computaci6n para facilitar la discriminaci6n 0 el hosUgamiento. Durante la decada pasada, ciertos miembros de la industria del software han cabildeado por una legislaci6n protectora que ISEE031 :
I . Permita a las compaflias liberar el software sin revelar los defectos conacidos.

2. Exentar a los desarroUadores de responsabilidad penal por cualesquiera danos que resulten debido a dM:hos defectos conocidos.

PARTE CINCO

TDotAS

AVANlJUJOS N lNGENIERiA Dfl.. SOFTWARE

3. Restringir a otros la revelaci6n de defectos sin permiso del desarrollador original.

4. Pennitir la incorporaci6n de software de "autoayuda" dentro de un producto que pueda desactivar (vIa comandos remolos) la operaci6n del producto.
5. Exentar a los desarrol1adores de software con "autoayuda" de los danos en caso de que el software 10 desactive una tercera persona.
AI igual que con cualquier legislad6n, el debate con frecuencia se centra en conflictos poHticos, no tecnol6gicos. Sin embargo, mucha gente (incluSQ este autor) considera que la legislaci6n protectora, si se propone de manera inadecuada, entra en conmcta con el c6digo de etica de la ingenierla del software al exentar indirectamente a los ingenieros de software de su responsabilidad para producir software de alia calidad.

32.8

UN COMINIARJO fiNAL

Ya han pasado 25 aflos desde que se escribi6 la primera edici6n de este libro. Todavia 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 indus so todavla menos realmente comprendla . Recuerdo las cartas de rechazo de los edi tores, quienes argumentaban (gentil, pero finnememe) que nunca habria un mercado para un Iibro acerca de ~ ingenierfa del software Afortunadamente, McGraw-Hill
H

elccidiO elarle una oportunlelael/ y eJ resto, como dicen, es historia.

Durante los pasados 25 alios, este libra ha cambiada sustancialmente: en akan ce, en tamana, en eslilo y en cantenido. AI igual que la ingenieria del software, ha crecida y (espero) madurado con los al'\os. Un enfoque de ingenieria para el desarrollo del software de computadora es ahora sabiduria convencional. Aunque eJ debate continua acerca del "paradigma carrecto", la importancia de la agilidad, el grado de automatizaci6n y los melodos mas efecti vos, las principios subyacentes de la ingenierfa del software ahara son aceptados a 10 largo de la industria ,Por que, entonces, se ha vista su amplia aceptaci6n s610 recientemente? La respuesta, creo, se encuentra en la dificultad de la transici6n tecnol6gica y el cambio cultural que la acompana . Aun cuando la mayoria de las personas aprecian la necesidad de una disciplina de ingenieria para eJ software, se lucha contra la iner cia de la practica pasada y se enfrentan nuevos dominics de aplicaci6n (y los desarroJladores que trabajan en ellos), que parecen !istos a repetir los errores del pasado.

En realldad, el cr6dito corresponde a Peter Freeman y Eric Munson, quienes convencieron a McGrawHill de que valla la pena intentarlo.

CAPiTuLo 32

EL CAMINO POR RICORREII

939

Para facilitar la transid6n se necesitan muchas cosas: un proceso de software

agH, adaptable y sensible; metodos mas efectivos; herramientas mas poderosas; mejor aceptaci6n de los profesionales y apoyo de los gestores; y no pequenas dosis
de educad6n y "publicidad". La ingenierla del software no ha tenido et beneficia de la publicidad masiva, pero, confonne pasa el tiempo, el concepto se vende a sl mismo. De alguna manera, este libra es un "anuncio publidtarlo" para la tecnologla Ellector lal vez no este de acuerdo con lodos los enfoques descritos en este libra. Algunas de las tecnicas y opiniones son controvertidas; otras debertm ajustarse para trabajar bien en diferentes entornos de desarrollo de software. Sin embargo, mi 51ncera esperanza es que Ingenjerlo del software. Un enJoque prdclico haya delineado los problemas que se enfrentan, demostrado la fuerza de los conceptos de la ingenierla del software y ofrecida un marco de trabaja de los metodos y herramientas. Confonne se avanza en el slglo XXI, el software se ha convertido en el producto mas importante y en una industria primordial en el escenario mundial. Su impacto e importancia han transitado un largo camino. E inc1uso, una nueva generaci6n de desarrolladores de software debe enfrentar muchos de los mismos desafios que enfrentaron las primeras generaciones. Espero que las personas que enfrenten el reto - ingenieros de software- tendran la sabidurfa de desarrollar sistemas que mejoren la condici6n humana.

IACM981 ACM/IEEE-CS Joint Task Force, sojtware Engineenng Code of Ethics and Professkmol Practice, 1998, disponible en http://www.acm.org/serving/se/code.htm. tBEC011 Beck, K. et ai" "Manifesto for Agile Software Development", http://wwwagilemanifes-

to.orgl.
tBOl91] Bollinger, T y C. McGowen, "A Critical Look at software capability Evaluations en IEEE Software, julio de 1991, pp. 25-41. [Gll96l Gilb, T., "What is Level Six''', IEEE software, enero de 1996. pp, 97-98,103 [HOP90j Hopper, M. D., -Rattling SABRE, New Ways to Compete on InformationN, en HalVClrd BuSiness Rev/eIN, mayo-junio de 1990, [PAU931 Paulk, M, et 01., Capability Maturity MOOdfor SOjtware, SOftware Engineering Institute, camegie Mellon University, 1993, [PCM03J "Technologies to Watch", en PC Magazi~, julio de 2003, disponible en http: //wwwpc mag.com/article210,4149, 1130591 ,00,asp [PRE911 Pressman, R. S. Y S R. Herron, software Shock, Dorset House, 1991. [SEE03j The SOftware Engineering Elhics Research Institute, "UOTA updates", 2003, disponible en htlp://seeri.etsu.edu/default.htm
H ,

32. 1. Obtener una copia de las principales revistas de negocios y notlcias de eSla semana (por ejemplo. Newsl.veek, Time, Business \\tek)- Elaborar una !iSla de cada elemento del articulo 0 noticia que se pueda utiHzar para llustrar la importancia del software_ 32.2 . Uno de los dominios mas rei\idos de Ia aplicad6n del software son los sistemas y aplicaciones basados en Web. Estudiar c6mo la gente, Ia comunicaci6n y el proceso lienen que evolucionar para adaptarse a\ desarrollo de las WebApps de "siguiente generaci6n"

...

PARTE CINCO

nMAS AVANZAJ::;I:Y; EN lNGE:NIERlA DEL SOFtWARE

32.3. Escribir una breve descripci6n del cnloma de desarroilo de un ingeniero de software ideal hada el 2010. Descrihir los elementos del cnloma (hardware. software y tecnologlas de comunicaci6n) y su impacto sobre la cali dad y el tiempo en que lIega al mercado.

32.4. Revisar el esludio de los modelos de proceso incrementales agHes en el capitulo 4, Realizar una investigaci6n y recopilar artkuJos recientes acerca de la materia. Resumir las fortalezas y debilidades de los paradigmas agiles con base en las experiencias subrayadas en los articulos. 32.5. Intcntese desarrollar un ejemplo que comience con la recopilaci6n de datos en brulo Y
llevese a cabo la adquisici6n de informaci6n, 1uega de conocimiento y, por ultimo, de sabiduria.

32.6. Proportionar ejemplos especificos que iJustren uno de los ochos principios eli cos de la ingenierla del software mencionados en la secci6n 32.7.

Los libros que estudian las tendencias futuras del software y la computaci6n abarcan una amplia variedad de temas tecnicos, cientificos, econ6micos, poHlicos y sociales. Sterling (1bmoITow Now, Random House, 2oo2) recuerda que el progreso real rara vez es ordenado y eficiente. Teich (Technology and /he Future, Wadworth, 2oo2) presenta reflexivos ensayos acerca del impacto social de la tecnolog!a y c6mo la cultura cambiante da forma a la tecnologia, Naisbilt, Philips y Naisbitt (High TeclVHigh 1buch, Nicholas Brealey, 2ool) senalan que muchas personas se han "intoxicado" con la alta tecnologla y que la "gran ironia de la era de la alta tecnologla es que la humanidad se ha esclavizado a los disposilivos que se supone brindarian libertad". ley (The Future Factor, McGraw-Hill, 2000) analiza cinco fuerzas que daran fonna al destino humano durante este siglo. Canton (Technofutures, Hay House, 1999) estudia c6mo la tecnologfa transfonnara los negocios en el siglo xx!. Robertson (The New Renaissance: Computer.; and the Next Level of Civilization, Oxford University Press, 1998) argumenla que la revoluci6n en la computaci6n puede ser el avance individual mas significativo en la historia de la civilizaci6n, BrodericK (Spike, Forge, 2001) analiza el impacto de las lecnologlas emergentes. Dertrouzos y Gates (Wha( Will be: How au: New World ofInformation Will Change Our Uves, Harper-Business, 1998) ofrecen un estudio detallado de algunas de las direcciones que pueden tamar las tecnolagias de la informaci6n en las primeras decadas de este siglo. Bamatt (Valueware' Technology, Humanity and Organization, Praeger Publishing, 1999) presenta un intrigante estudio de una "economia de ideas" y como el valor econ6mico se creara conforme evolucionen los cibernegocios. El de Negroponte (Being Digital, Alfred A. Knopf. 1995) fue un exilo de ventas a mediados del decenio de 1990 y continua ofreciendo una interesante visi6n de la computaci6n y de su impacto global Kroker y Kroker (Digital Delirium, New World Perspectives, 1997) han editado una controvertida colecci6n de ensayos, poemas y humor que examinan el impacto de las tecnologias digitales sobre las personas y la sociedad. Brin {The Transparent SOCiety: Will Technology Force Us /0 Choose Between Pn'va9' and Freedom?, Perseus Books, 1999} vuelven a revisar el continuo debate asociado con la inevitable perdida de privacidad personal que acompana al crecimiento de las tecnologias de la informaci6n. Shenk (Data Smog: Surviving the Information Glut, HarperColJins, 1998) estudia los problemas asociados con una "sociedad infestada de informaci6n" que se sofoca por el volumen de infonnaci6n que produce el software. Brockman (The Next FijIy Yeats, Vintage Books, 2002) y Miller y sus colegas (21st Century Technologies: Promises and Perils Ofa Dynamic Future, Brookings Institution Press, 1999) han editado una colecci6n de articulos y ensayos acerca del impacto de la tecnologla sobre las estructuras sociales, empresariales y econ6micas. Para aquelJos interesados en los temas tecnicos, Luryi, Xu y Zaslavsky (Future Trends in Microelectronics, Wiley, 1999) han edilado una colecci6n de articulos acerca de las probables direcciones para el hardware de computadora, con enfasis en las nanotecnoiogias. Hayzelden y Bigham (sojlware Agents for Future Communication systems, springer-verlag, 1999) han editado una colecci6n que analiza las tendencias en ei desarrollo de agentes de software inteligentes.

cAPiTuLo 32

EL CAMINO POll RECORlUlI

941

Conforme el software se vuelve cada vez mas parte de la fabricaci6n de virtualmente todas las facelas de la vida moderna, la "cibertlica" ha evolucionado como un lema importanle de eSludio. lDs Jibros de Spinello (~thics: Morality and Law In cyberspace, Jones & Bartlett Publishers, 2002), Halbert e IngulU (Cyberelhk:s, Soulh-Western College Publishers, 2001) Y Baird Y sus colegas (CyberethlCS; SOCia/ and Mora/Issues In the Computer Age, Prometheus Books, 2000) consideran el tema en detane_ EI gobierno estadounidense ha publicado un voluminoso TeporIe en CD-ROM (JIst Century Guide /0 cybercrime, Progressive Management, 20(3) que considera todos los aspectos del crimen computacional. conninos de propledad imelectuaJ y eI Centro de ProtecciOn a la Infraestructura Nacional (NIPC, por sus siglas en ingles) Kurzweil (The Age of SpJ/itual Machines, ~ Computers Exceed Iluman Intelligence, vikmg/Penguin Books, 1999) argumenla que, dentro de 20 anos, la tecnologla de hardware tendra la capacidad de modelar por completo el cerebra humano_ BoTsmann (lioklins on In RM/ilyThe Nature ojlnjormafion allheTIlm oJrheMilknium, University o(Chicago Press, 1999) ha escri to una interesante historia de la informaciOn, y rastrea su papel en III transformacion de la cultura Devlin (lrIjoSense: ruming Injormation InlO Knowledge, W tl Freeman & CO., 1m) intenta darle senUdo al constante flujo de informaciOn que bombardca a la pobillcion diariamente Gleick (Faster' The Acceleration Of Just About EVerylhlng, Pantheon Books, 2000) estudia Ja tasa siempre en aceleraci6n del cambio tecnol6gico y su Impaclo sabre todos los aspectos de la vida moderna )onscher (The Evolution of Wired Uje: From the Alphabet to /he Sou/-Catcher Chip-HOW Injoffllation 1hnologies Change Our World, Wiley, 2000) argumcnta que cI pensamiento y la interacci6n humanas trascienden la importancia de la tecno)ogia En Internet hay disponible una amplia variedad de fuentes de informaci6n accrca de las direcciones futuras en las tecno)ogias relacionadas con el software y la ingemeria de software Una Iista aCluaJizada de referencias en la World Wide Web se pucde encontrar en eI SltlO Web SEPA

http://www.mhhe.com/ pressman.

 INDICE ANALiTICO

ABC MPi, 37

Abstracci6n, 252 Accesibmdad,375

Aceiones, 25 Acoplamienlo, 260, 482 nlveles de, 329 medici6n, 487. 489 Actividades, 24 Actividades de sombriJla, 24, 28 Actividades del marco de trabaja, 24,26 genericas, 26 Actores, 173,206

Agilidad, 79. Vease tambien Proceso agil

definici6n de, 79

factores humanos, 82 principlos de la, 80

Almacenamiento de datos, 278

Ambiente de trabaja. 368 Ambito,112 Ambito del software, 651, 693 Umites, 693
Analisis, 192 Veose tambien

Analisis de los requisitos orientado a objeles. 201 patrones, 183 (vatse tombien
Patrones)

reglas por experiencia, 194 Analisis de inventario, 909

AnAlisis de peligros, 762
AnAlisis de requisitos, 192. Vta5e tombten AnAlisis

aplicaciones basadas en web, 587 de datos, 140 descripci6n de la, 276 imponanda de la, 277 MVC, 589 Arquitectura de aplicaci6n, 8-9 Arquitectura de datos, 140 Arquitet:tura del agente para solicitud de objeto, 890 Arquitectura del contenido, 586 estructuras, 586 Aseguramiento de la calidad, 770 actividades, 773 estadlstico, 78.3 historia, 772 plan, 791 Aseguramiento de la calidad del software (SQA). Vease AsegUramiento de Ia calidad Asociaciones, 232 Atributos, 222 Atributos de los datos, 198 Audiloria de configuraci6n, 8\3 aplicaciones basadas en Web,823 Auditorias, 806. Vtase tambi&J AlJditoria de coofiguraci6n Autentificaci6n, 6.31 Autoridad del control del camblo (ACC},810 Autorizaci6n, 62
Base de datos del proyet:to, 800. VeaSt' tambihl Dep6sito

objetivos del, 193

ingeniena Web, 545 AnAlisis de tareas, 361 Analisis del arbol de decisi6n,

717 Analisis del domlnlo, 194 Analisis del flujo de tTabajo, 364 Analisis del usuario, metodos I?ara el, 361 AnaliS1S del valor de frontera, 437,624 Analisis del valor ganado (AVG), 742 Analisis gramatico, 212 Analisis Relaci6n-Navegaci6n (ARN),589 Aplicaclones basadas en Web. vtase webApps Arbol de datos, 552 Arbol de requisitos de la calidad, WebApps, 568 Arquetipas, 289 Arquitectura, 253 analisis de sensibilidad, 294

cala de tiempo, 740 Ca endarizaci6n, 724, 727, 736 conceptos, 725 principios, 728 seguimiento, 739 varianza, 743 Calidad contexto de la [sac, 896 costo de la, 770 definici6n de, 46.3, 769 detenninantes, 66S diret:trices para la Iweb, 513 factores, 464 factores del ISO 9126, 465 medici6n, 676 medidas de la. 677 Calidad de la concordancia, 769 Calidad del disei\o, 769 Calidad del software. Vazse calidad Calificaci6n de componentes. 887

Cambio, 6, 7, 114 ambito del, 929 impacto sobre el software, 6 ongen del, 797 caos,48 Capital del software, 22 CaractensUca, definiciOn de, 95 Cardinahdad, 199,232 Casos de prueba caracterfsticas de los, 420 derivaci6n, 427 Categorlas de usuario, definici6n de las, 521 Centro de transacci6n, .306 CertiOcaci6n, 874 Clase agre~ada compuesta, 230 multlplicidad, 232 Clase-responsabilidad-colaborador,225. Vease tambitn Modelado CRC Clases de analisis aplicaciones basadas en Web, 554 atributos, 221 caracteristicas de las, 221 identiflcaci6n de las, 219 operaciones, 223 tipas de, 219, 226-227 Clases de controlador, 227 Clases de diseno, 259 caracterislicas de las, 260 tipas de, 259 Clases de entidad, 226 Clases de frontera , 226 Clientes, III COCOMO II, 710 Codificad6n, 631 CodificacJ6n, principios, 123 C6digo fuente a nlvel de programa, 493 medici6n, 493 volumen, 493 Cohesl6n, 260, 483 medici6n para la, 489 niveles de, 326 ColaboracJ6n, 8.3, 110 definld6n de eRC, 228 Complejidad, 482, 490 medlci6n, 491 Complejidad ciclomatica, 426 Componentes adaptaci6n de, 888 basados en clases, 321 clasificaci6n de, 893 composid6n de, 888 convencionales, 317, 340
943

definiciOn de, 315, 889

descripci6n de, 892 eJemplo de diseflo de, 321 ingenieria de, 890 nuevos, 696 reutilizables, 695 visiOn 00, 316 Comprobaci6n de correcci6n, 867, 868 Comprobaciones subordinadas,

869
ComputaciOn ubicua, 10

Correcci6n, 677 comprobaci6n de la, 868 condiciones, 869 verificaci6n de la, 867, 868 Cortafuegos, 631 Costo, varianza, 744 Costas de falla, 771 Costos de prevenci6n, 770 Costos de valoraci6n, 770 Cristal, 95 Curva de la baiiera, 5 Curva Putnam-Raleigh -Norden,

Diagramas de aclividad, 148, 180, 208, 340 Diagramas de re laci6n de entidad,200 Oiagramas de secuencia, 238 aplicaciones basadas en la Web, 554, 555 Diseno, 245, 275, 314, 350 a nivel de componente, 314,

593
apJicaciones basadas en la Web,566 ar'1uitect6nico, 275, 585 atnbutos de calidad, 25 1 comprobaci6n de la correcci6n del, 868 conjunto de tareas, 122, 252 directriz de calidad, 249 esletico, 582 hipermedia, 595 ingenieria del software de sa la limpia, 867 interfaces con el usuarlo, 350 interfaces para aplicaciones basadas en Web, 573 medici6n, 479 proceso, 250 verificaci6n, 867 Oiseno al nivel de componentes, 3 14 aplicaciones basadas en Web,

comunicad6n, 26, 11 0
conjunlo de lareas, 112

730
Curvas de fa lia, 7 Decisi6n de hacer la compra, 717 Defectos, 775 Dependencias, 232 Dep6sito, 801 caracteristicas del, 804 contenido, 804 Depuraci6n, 408 consideraciones psicol6gicas,

del cliente, 523

insenierfa Web, 510, 523 pnnclpios de la, I 10 Concurrencia, 286 CandidOn posterior, 834 Condici6n previa, 833 ConfiguraclOn del software, 797 Conjunto de base, 424, 425 Conjunto de cambios, 809

conjunto de (areas
comunicad6n, 112 comunicaci6n con el cJiente,

410
estrategias, 411 proceso de, 409 tacticas, 412 Desarrollo basado en componentes (OBe) , 63, 886 Desarrollo conducido por la caracterislica (DCq, 95 Desarrollo del software adaptativo (DSA). S9 Desarrollo orientado a aspectos,

conslruccion, 124
definiciOn del , 27

52'

despliegue, J 28
disei'lo, 122

modelacl6n del analisis, 118

planeacibn, I I {, planeaci6n del proyecto, 693
prucbD.S, 125- 126

593
directrices, 326 pasos, 331 principios basicos, 322 Diseiio arquitect6nico, 275, 287 aplicaclones basadas en la Web,585 complejidad del, 296 diagrama del nujo de datos,

65
Descomposlci6n del problema,

pruebas de aplicaciones basa das en la Web, 61 1 refinamiento del, 737 selecclOn. 732 Conocimiento,934 Consecuencias imprevistas, I Consejo Airlie, 658 Construcd6n, 26, 399 conjunto de tareas, 124 ingenlerla Web, 510 practica, 122 Construcci6n basada en componentes, 8 Construcciones estructuradas, 340 Control de calidad, 770 Control de la variaci6n, 768 Control de la versi6n, 805, 808 aplicaciones basadas en la Web,822 Control del cambio, 810 f1uja de trabaja, 811 tipos de, 811 COntrolador vista del modele (MVC), 589 Controladores, 394

652
Descomposici6n funcional, 362 oesgaste, 5, 6 Despllegue, 26 principios, 126 conjunto de tareas, 128 lngenierla Web, 5 10 oespliegue de la funci6n de cali dad (QFD), 171 Delerioro, 6 Diagrama de caso de uso, ISO oiagrama de clase, 148, 223 Diagrama de contexto, 212 Diagrama de contexto de \a arquitectura (DCA), 288 Diagrama de contexto del sistema, 145 Diagrama de despliegue, 148 Oiagrama de estado, 181 , 2 16, 237,555 utilizaci6 n de pruebas, 450 Diagrama de flujo , 340, 341 Diagrama de flujo de datos (DFD), 212, 299 Diagrama de flujo del sistema (DFS), 146

297
evaluaci6n del, 294 refinamiento del, 290, 310 Diseno de datos, 26 a nivel arquitect6nico, 278 a nivel de componente, 279 Oiseiio de interfaz, 350 analisis del, 358 aplicaciones basadas en la Web,573 nujo de trabajo, 368, 580 patrones para el, 371, 372 principios del, 351, 574 proceso del, 358 Oisei'io de Ia interfaz con el usuario, 350 analisis de tareas, 361 analisis del nujo de trabajo, 364 aspectos del, 372 evaluaci6n del, 377 medici6n, 492 principios del, 352

...
proceso, 358 pasos, 368 reglas de oro, 351 Diseno de navegaci6n, 590 Diseiio del contenido, 584 Diseno esletko, 572, 582 aplkaclones basadas en Web, Especiflcaci6n de ca}a negra, 865 Especificaci6n de caJa transparente, 866 Especificaci6n de la estructura de caja.864 Especificaci6n del control (EQ, Factores de calidad de McCall,

463
Factores humanos, 82 FactorizaciOn, primer nlvel, 302 Fiabilidad, 465, 786 medidas de, 787 Filtros, 283 Flujo de transformaci6n, 297 Formas de navegaci6n (FdN) , 591 Fonnato de condiciOn-transmisi6n-consecuencia (eTC),

582
aspectos de configuraci6n, 582 Disei'io grcUico. Vaz5e Diseiio estetico Disponibilidad, apHcadones basadas en Web, 569 Distribuci6n, 286 Distribuci6n del esfuerzo, 732 Dominio semantico, 844 ECS,803 EcuadOn del software, 712, 131 Eficacia en la remocl6n de defec lOS (EED), 678 Eficiencia, 466 ElaboraciOn, 159,652 ElaboraciOn de objetos, 364 ElaboraciOn de tareas, 363 objetos, 364 tareas,363 Elementos de configuracl6n del software (ECS), 800 Elementos de diseno arquitect6nko, 264 componentes, 266 dalos, 263 despliegue, 267 interfaz, 264 Elementos del sistema, 134 Encubrimiento de componentes, 888 Ensayo, 774. Vaz5e tambien Revisiones Entrega incremental, 81 Envoltura, 888 Equipo de medici6n, MDOO, 485 Equipos agHes, 82, 649 coordinad6n, 650 cuajados, 83, 90, 647 ingenierfa Web, 526 organizaclOn prop la, 83 programador en Jefe, 64 7 tipos de, 646 Equipos agiles, 649 Equipos de software, Vease Equlpos Errores, 775 correcci6n de, 414 costa relativo, 771 Escalabilidad, WebApps, 569 Escenarios del usualio, 172 Especilicaci6n, 160 Especificaci6n constructiva, 837 Espedficacl6n de caja de estado,

215
EspecificaciOn del proceso (EPl,

217
EspedflcaciOn fonnal, 842 Espectro de la infonnaciOn, 933 Estado, 833 Estereotipo, 232 Estilos arquitecl6nicos, 280 centrada en datos, 281-282 eslratificada, 284 flujo de datos, 281 llamada y retorno, 263 orientada a obl'etos. 284 taxonomia de os, 281 EstimadOn, 690, 696 apUcadones basadas en Web,

759
FormulaciOn, 510, 517 de preguntas, 519 recopirad6n de requisitos, 520 Fuente ablerta, 10 Funcionalidad, 465 funciones de ayuda, 373 Funciones de caracterlzaclOn,

884
Fundamentos, 741 puntos de fijaci6n, 59 GCS. 797,815 elementos de la, 799 escenario, 798 estandares, 824 estratos del proceso, 807 funclones, 805 gestiOn del cambio, 820 gestiOn del contenido, 817 Identificaci6n, 8Q7 ingenierla Web, medici6n, 598 medici6n del valor de nego clos, 538 modelo de analisls, 580 objetos de configuraciOn, 817 jerarqula del usuario, 546 proceso, 806 pruebas de desempeno, 631 pruebas de navegaci6n, 625 pruebas de segurldad, 680 tip?s de, 506 GestJ6n de la calidad, 767. vtose lambien Aseguramienlo de la calidad GestiOn de Ja configuraci6n del software. Vease GCS Gesti6n de la conflguraciOn, 829. Vease lambitn SCM GestiOn de requisitos, 161 GestiOn del cambio, 796, Vease tambien GCS aplicaciones basadas en Web, 815 GestiOn del contenldo, 817 Gesti6n del proyecto, 640 aspectos de la, 643 practicas criticas, 658 GestiOn del proyecto de software. Vease GestiOn de proyecto GestiOn del rjesgo, 747

715
basada en PF, 702 basada en LOC, 700 basada en el problema, 699 basada en el proceso, 704 descomposici6n, 698 desarrollo agil, 714 estlmaciOn, 713 modelos, 710 modelos empiricos, 709 observaciones, 691 proyectos 00,713 tecnicas automatlzadas, 709 USO-(:aSOS, 705 EslimaciOn del proyecto. Vmse Estimaci6n Estimaciones ingenierla web, 534 reconciliaciOn, 708 Estructura de analisis de trabajo (EAl),737 Estructura de superficie, 445 Estructura profunda, 445 Etica,936 c6di~ de, 936 conSlderaciones personales, 937 EvaluaciOn del riesgo, 752, 757 Eventos. 215, 235 Evoluci6n del software, 12 leyes de la, 13 EvoluciOn. V&Jse Evoluci6n del software Exposid6n al nesgo, 757 calculo de la, 757 Extracci6n de datos, 278 Facilidad de manterumienlO, 466,

677
Factibilidad, 693

866

...
Grafica de flujo, 423, 425 Grafica de la estructura, 320 Grafica de linea de tlempo. 737 Graficaci6n de la transaccl6n, 306 Graficaci6n de la transformaci6n,

gestl6n del riesgo, 763 fngenieria de los requisllos,

163
ingenieria inversa, 916 inlermedias, 321 LDA,297 medici6n de aplicaciones basadas en Web, 599 medici6n del producto, 495 medici6n del proceso y el proyecto, 676 metodos formales, 852 mineria de datos, 279 modelado de datos, 200 modelado del analisis en UML,239 modelado del proceso, 43 modelado del sistema, 151 PDL, 344 planeaci6n de pruebas, 408 pruebas de aphcaciones basadas en Web, 633 reestructuraci6n, 918 RPN, 905, 906 simulaci6n del sistema, 139,

299
Graficaci6n del flujo de datos,

298
Grafieo de estado, 336
Granularidad, I 14 Grupo independiente de prueba (Glp),386 GUI,451 facilidad de usc, 620 jerarqula de clase, 444 mediciones para, 494 metodos 00, 441 modelaci6n del flujo de datos,

USN,592 usa-casos, 175,205,369, 549 HogarSeguro (cuadros al margen), 17,57,62, Ill, 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 informaci6n del riesgo, 757,762 Idiomas, 270 IMCM,29 adopci6n de la, 32 modelo continuo, 30 metas,32 modelo por etapas, 32 niveles de capacidad, 30 pnkticas, 31 Impurezas, 775 Incremento, vtase Incrementos del soRware Incrementos de soRware, 51,81 Independencia funcional, 256 Indicadores, 466 Indice de caUdad de la estructura del diseno (ICED), 480 Informaci6n, representaci6n de \a,933 Informe de cambios, 810 Infraestructura, tecnologla, 141 lngenierfa de requisitos, 155 tareas de la, 157 Ingenieria de software de sala lim,p:ia, 64, 850 certificac16n, 874 diferenciaci6n de caracteristi c35,862 diseno,867 especilicaci6n funcional, 86J estrategia, 860 pruebas, 872 Ingenierfa del diseno, 245 Ingenierla del dominio, 883 Ingenieria del proceso de negocios (IPN), 903 jerarqula, 141 Ingeniena del producto, 142 Ingenieria del sistema jerarqula, 136 visi6n mundlal, 136 lngenieria del software definici6n de la, 23 de sala lImpia, 858 estratos, 24 etica, 936 futuro de la, 927

436
modelado del flujo de transacci6n, 436 modelaci6n del est ado finite,

435
modelos de comportamiento,
451 navegaci6n, 610

140
soporte de la GeS, 814 UMUOCL,339 Herramientas del software, Herramientas Historias del usuario, 85
Ho~arseguro

opciones, 400 partici6n, 447 particiones de equivalencia,

436

Vease

patrones, 455
prlnClpiOS, 114 proceso para apiicaciones ruta basica, 423 servicios de ayuda, 454 sistemas en tiempo real. 455 lecnlcas, 418 Herramientas, 24 almacenamiento de datos,
antllisis estructurado, 218 basadas en Web, 599 calendarizaci6n, 737 casas de usa, 78 DBC,895 depuraci6n, 413 desarrollo de la interfaz con el usuario, 376 desarrollo agi!, 98-99 disefto de casas de prueba,

art>ol de datos, 552

carta Indice eRC, 226

ba:xl.da.s en Web, ~

clases de analisis, 220, 554

clases de disefio, 261
configuraci6n de pantalla, 371 DCA,289 dlagrama de ACTIVIDAD, 209,

558

".
439

diagrama diagrama dlagrama diagrama

de de de de

carriles, 210 dase, 181, 225 despliegue, 268 estado, 216, 237,

555
diagrama de flujo de datos, 212,213,300 diagrama de secuencia, 238, 554 diagrama usa-caso, 178, 208 diseno de componeme, 344 EP, 217 esquema conceptual. 597 eslructura arquitect6nica, 292, 306,310 estructura de la funci6n de seguridad,292 modelo eRC, 231 narrativa de procesamiento, 212 objetos del contenido, 584 relaciones de clase, 290

estimaci6n, 716 gesti6n de la calidad, 791 gesti6n del cambio, 822 gestl6n del contenido, 819 gesti6n del proceso, 66 gesti6n del proyecto, 659 eesb6n del proyecto de ingerueria Web, 536

94'
pnktica, 104. Wase lambien

Practica

principios. 107 Ingenierfa del software asistida por computadora. Wase Herramientas

Ingenierla del software basada en componentes, 879, 880. Vease IOmbitrJ ISBC lngenierla directa, 911, 918 cliente/servidor, 920
Interfaces con el usuario, 922
sistemas 00, 921

Ingenierla inversa, 910, 912 datos, 913-914

interfaces con el usuario, 915

procesamiento.914-915 Ingenierta Web (IWeb). 502

acUvidades del marco de tracaracterlstlcas del equipo, 527 casas de USO, 547 construcci6n del equlpo, 528 desarrollo en casa, 533
directrices de calidad, 513

ingenierfa inversa, 915 mecanismos de control, 579 modelo de anAlisis, 356 patrones,372 prototipo, 557, 580 pruebas, 616 Intermedio (middleware), 322 Intemadonalizaci6n, 375 Invariante de datos, 834 ISAC. v&zse Herramientas ISOC, 879 anAlisis del costo, 897 economla de la, 895 proceso, 882 ISO 9000, 790 ISO 9001: 2000, 38, 790 esquema del, 790 Itinerario de! proyecto. Vease Calendarizaci6n Jerarqula del conlenido, 552 Jerarqulas de usuario, 546 Lenguaje de diseno de programa. Vease LOP Lenguaje de especificacl6n Z,

Mantenimiento, 7, 12,907 medici6n del, 496 Mantenlmlenlo del software, 7, 12, 907. Vease lamb;&! Manlenimiento Marcos de (rabaJa, 270 Matrices grAficas, 430 MDHOO, 595 dlsei'\o abstracto de interfaz,

597
disei'lo conceptual, 5'75 dlset\o de navegaci6n, 596 MDSD,91 reingeniena, 908 Medicl6n (metricas), 467 acoplamiento, 487 anfllisis de, 474 a nivel de componentes, 488 apllcactones basadas en Web, 536, 598, 674 argumentos para la, 680 atributos de la, 471 basada en la funci6n, 474 caJidad,677 calldad de la especificaci6n, 477 c6digo fuente, 492 cohesi6n, 489 complejidad,491 definlcl6n, 467 diseno, 479 disei'io arquilect6nico, 479 establecimienlo, 684 etiqueta, 666 interfaz can el usuario, 492 linea de base, 681 mantenimiento, 496 orientada a la clase, 486 orientada at tamano, 669 orientada a objetos, 481, 495,

b'jo.509

disei'\o a nlvel de componente,

593

849
ejemplo, 849 notaci6n, 850 Lenguaje de restricci6n de objelos (IRQ), 338, 845 condiciones previas/posteriores, 337 ejemplo de, 847 invariante, 338 notaci6n, 846 visi6n general, 845 Lenguajes de descripci6n arquitect6nica (LOA), 296 Lenguajes de especificaci6n formal,844 Ley de Demeter, 261 Ley de Flit, 576 Uder del equipo, 644 Unea de base, 800 definici6n de, 800 medici6n, 681 Usta de problemas, 169 Usta de verificaci6n calidad del diseiio de webApps,570 validaci6n de requisitos, 161,
186

diseno arquitect6nico, 585 disei'lo de Interfaz, 573 diseno de navegacl6n, 590 diselio del oontenido, 584
estimaci6n, 715 formulad6n. 517 (veast !am-

bien Formulacl6n)
GCS,815 herramientas, 508

las peores practicas, 539

las mejores prtictlcas, 512 metodos, 507 medid6n, 536 medici6n del diseno, 598 modelado del anAlisls, 544 planeaci6n, 525 preguntas bAsicas, 51 I proceso, 507, 508, 51 I pruebas, 604, 607, 612 subcontratacl6n, 530 Ingenierla Web, piramide de diseno, 572 Inicio, 157 Inmediatez,505 Inspecciones, 774. Vease lambicn Revisiones Integrldad, 678 Intereses generales, 65 Inlerfaz con el usuario, 349, Vease lambicn Inlerfaz anAlisls, 359 carga de memoria, 353 consislencia, 354 contenido del despliegue, 367 control del usuario, 351

673
orientada a la operaci6n, 491 oraanizaciones pequeflas, 682 pnvada,666 proceso, 663, 682 productividad, 699 proyecto, 462, 472, 667 pruebas, 494 publica, 666 retos, 468 ti~ de, 471 Medlci6n de Halstead, 493 Medici6n de la productividad,

Usta de verificaci6n de elementos de riess?, 750 Usta de veriflCao6n para la validaci6n de requisitos, 161 Manejo del error, 374 Maniliesto, desarrollo de software agil. 77 Manifiesto tigil, 77

699
Medicl6n de linea de c6digo (LDC),669 Medici6n del software Vense Medici6n Mediclones CK, 482 Medidas, 467 dlrectas, 668 indireclas, 668

...
MEIEP, 37 Me}oramiento del proceso del software (MPS), 664

estadistico, 667
Melt, 92 principios, 93 reuniones, 94 MeIMora,577 Metoda de analisis del cambia de

apJicaciones basadas en Web, 550 elementos del, 179, 197 relaci6n con el diseFio, 247 Modelo de comportamiento, 235 Modelo de desarrollo concurren-

graiica,340 tabul ar, 342 Nueva econom[a, 10 Objeto de los datos, 197 Objetos de configuraci6n, 802 aplicaciones basadas en web,

te,60
Modelo de espiral, 58 problemas con el, 59 Modelo de interacci6n, 554 Modelo de la cascada, 50 problemas can el, 51 Modelo del contenido, 551 Modelo del diseFio, 247 dimensiones del, 263 relaci6n con el analisis, 247 Modelo ORA, 53 retrocesos, 54 Modelo funcional, 557 Modelos de proceso agil,81 cascada, 50 Cristal,95 OAR,53 DAS, 89 !XC, 95 determinados por el riesgo, 58 desarrollo concurrente, 60 diferencias, 28-29 especializado.63 espi ral, 58 estados de bloqueo, 51 evolutivo, 54 incremental, 52 ISec, 882
RPN,904

817
Objetos de contenido, 551, 584 Obtenci6n, 158, 652 Obtenci6n de requisitos, 166 Ocultamienlo de infonnaci6n,

arquitectura (MACA). 294 Metodos,24 Metodos formales, 64, 830

conceptos, 830, 833

definici6n de, 830

256
OMG/CORBA, 889 Operaciones, 223, 833 identificacl6n, 223 Operadores de conjunlo, 838 Operadores IbRicos, 840 Orden del camoio, 8 10 Ors-anizaci6n propia, 83-84 Onentado a obJetos conceptos, 201 estimaci6n, 713 seguimiento del proyecto, 741 Paquetes, 234 Paquetes de analisis, 234 paradigma OPM, 469 Partici6n,652 de equivalencia, 435, 623 Patrones, 108, 119, 124 analisis de, 163 arquitect6nicos, 280, 281,284 disei'1o, 254 diseno de hipermedia, 594 dep6sitos de hipermedia, 595 interfaz con el usuario, 371 plantilla de I?atrones para el analiSls, 183 plantilla para los, 37 proceso, 36 pruebas, 455 Patrones arquitect6nicos, 280 refinamiento de los, 287 tipos de, 586 Patrones de diseiio, 254. VCosc tambitn Patrones descripci6n de los, 269 plantilJas, 269 uso de, 270 Patrones del proceso, 34 ejemplo de, 36 PE. VCase Programaci6n Extrema
(PE)

directrices de los, 852

preliminares matemAticas, 837

Miniespecificaciones, 169
Mitigaci6n del riesgo, 760 Milos, 14-15 de la gesti6n, 13-14

del cliente, 15 del desarrollador, 16 Mooalidad, 200 ModeJado, 26

ingeniena Web, 5 10

Modelado agH. 97
principiosdel . 97-98,121
Modelado eRe, 225, 226

en Pc. 86 Modelado de datos, 197

Modelado de
Hatle'y~ P1rbhai,

144

MMelado del anallSls, 159, 191 1;1":1\Ido cn (;la.:iCS, 181 , ZJ? basado en e:scenariOS, 179,

conjumo de tareas. 118

comenido, 551
enfoques. 196
ingenieria Web, 544 interacci6n, 554 orienladoal flujo, 182,211 principios, 117 Modelado del diseno, principios,
del comportamiento. 181. 234

202

Programaci6n Extrema, 84 prescriptivo, 49

prototipos,55 sala limpia, 859 Modelos evolutivos, 54-55 Modelos incrementales, 52 Mooelos iterativos, 55 Modelos prescriptivos, 49. vtase lambien Modelos de proceso faJlas de los, 78 Modo de bombero, 747 Modularidad,254 Monltoreo del nesgo, 760 MS,107 Multiplicidad, 232 Navegaci6n, 559, 572 analisis de la, 559, 56 1 preguntas, 560 semlmtica, 591, 626 sintaxis, 590, 592, 625 Negociaci6n, 112, 160, 184 Nooos de navegaci6n, 59l Notacibn del diseno basada en texlo, 242 comparaci6n de la, 345

119
Modelado del flujo de control,
215

Modelado del sistema, 137, 144 factoTes restrictivos, t 38-139 UML, t47 Modelado estructural, 88S Modelo clasico del cicio de vida, 50 Modelo CRC colaboraciones, 228 construcci6n, 225 res{X?nsabilidades, 227 revlsi6n de directrices, 233 JrolOdeio de amplificaci6n del defecto, 776 Modelo ~ anAlisis

Persistencia, 286 Personal, 641, 930 aspectos de gesti6n, 641 relaci6n con el esfuerz o, 729 usuarios, 643 PERT ICPM, 736 Peso del vinculo, 429, 433 Plan de SQA, 791

...
Planeaci6n, 26, 6S5
Planeaci6n de pruebas, 381, 608

Planeaci6n del cicio adaptativo

(PCA) , 90

Planeaci6n del proyecto, 692

Plan RSGR, 761 , 763

Plantilla modelo del sistema, 145

Portabilidad, 465 Practica (ingenierla del software). 103-132

Preguntas, libres de con texto, 55

Primitivismo, 260, 482

Principia abierto-cerrado (PAC),

322 Principia de cerra dura cornun

(PCC),325 Principia de equivalencia de la

reutilizaci6n (PER), 325

Principia de invers16n de 1a
dependencia (PSI), 324

Principia de Pareto, 125

Principia de reutiliz.aci6n cornun (PRC).325 Principia de segregaci6n de inter-

fase (PSI), 324 Principia de sustituci6n de LJSKOV

(PSLJ.324 Principia WHH, 11 5, 657

Principios, I 13, 655

analisis, 117

codificaci6n, 123

camunicaci6n, I 10
conjunto de tareas, 116 despliegue, 126 diseno, 119-120

ingenieria del software, 107 IWeb, 5 11 , 525 mcxlelado agn, 121 pianeaci6n, t 13 pruebas, 124 Proceso, 24 aspectos de la gesti6n del proyecto, 653 aspectos de $esti6n, 642 descomposicl6n, 654 direcciones fuluras, 931 evaluaci6n,37 marco de ttabaJa, 24 medici6n,663 relaci6n can el prcxlucto, 43 Proceso agi!, 81 politica del, 8] Proceso del software en equipo (PSE) actividades del marco de tra bajo,41 abjetivos, 40 escritos, 41 Proceso del software personal IPSPl,39 Proceso unificado (PUt, 67 rases, 68

historia del, 67 prcxluclos del trabaJo, 7 1 Procesos de negocios, 904 Prcxlucto, 651 aspectos de gesU6n, 642 del trabaja, 173 relaci6n con el proceso, 43 Prcxlucto esenclal, 52 Programaci6n estructurada. 340 Programaci6n extrema (PE), 84 actividades del marco de trabajo,85 ccxlificaci6n,87 diseflo, 86 planeaci6n, 85 pruebas, 88 Programaci6n par, 87 Protolipos, 55 problemas con los, 57 Proyectos diferencias, 526 estimaci6n, 690 medici6n 00, 673 medici6n para, 667 problemas, 656 seguimiento, 739 tipos de, 733 Proyectos de software. vtasc Prayectos Prudencia, 934 Prueba beta, 405 Prucba de caja negra, 422, 433 Prueba de ruta Mstca, 423 ejempto de, 428 Prueba de unidad, 88 Pruebas aleatorias, 48 a nivel de componente, 610,

623
aplicaciones basadas en Web,

604
arquitecturas convencionales,

386
arquitecturas 00. 388 basadas en el uso, 403 basadas en escenarios, 444 basadas en fallas, 443 basadas en grtificas, 434 basadas en (a clase, 447 basadas en ligas, 403 base de datos, 613 caracteristicas genericas, 383 canjunlo de tareas, 125 conlenido, 610, 612 cliente/servidor. 452 criterio de complelitud, 389 de c1ase multiple, 419 de uso estadisUco, 873 documentaci6n, 454 especializadas, 452 estrategias, 3&3, 390 estrategias 00.402

estructura de control, 430 estructura profunda, 446 estructura de superficies, 446 exhaustivas, 422 Ingenieria del software de sala Iimpia ,872 interfaces, 610, 616, 6 17, 619 limites, 437 tabla ortagonal, 438 Pruebas a la configuraci6n aplicaciones basadas en web, 6 11.628 del lade del cliente, 629 del1ado del selVidor, 628 Pruebas a la unidad, 388, 392 ambiente para las, 394 consideraciones de las, 392 prOCedimicntos para las, 393 Pruebas a las bases de datos, 6 13 Pruebas at Oujo de datos, 431 Pruebas at sistema, 388, 406 Prucbas alfa, 405 Pruebas de aceplaci6n , 88 Pruebas de agrupamlento, 404 Pruebas de buc\e, 131 Pruebas de caja blanca, 423 Pruehas de carga, 633 Pruebas de compatlblIIdad, 622 Pruebas de condici6n. 431 Pruebas de desempeno, 408, 631 Pruebas de humo, 399 Pruebas de integrad6n, 388, 394 Pruehas del contenido, 612 Pruebas de tabla ortogonat, 438 ascendentes, 398 documentaci6n ,400 descendente, 396 estudlo, 395 humo, 395 Pruebas de navegaci6n, 625 Pruebas de recuperaci6n, 407 Pruebas de regresi6n, 398 Pruebas de ruta, 624 Pruehas de software. Vease Pruebas Pruebas de tensi6n, 408, 633 Pruebas de validadOn, 388, 404 criterios, 404 principios, 123 Pruebas estadlsticas de uso, 873 PSE,40 PSp, 39 Puntos de fijaciOn , 59 Puntos de runciOn, 474 , 670 c6mputo de, 476 lenguajes de programaciOn,

672
reconciliaci6n, 671 Puntos de la estructura, 885 analisis del costo, 897 caracterlsticas de los, 885-886 Puntos de obJeto, 711

PUntos de prtoridad, 165

Puntos vitales, 784-785

Recopilaci6n de requisitos
colaborativa, 167 (Vease tam bien Obtenci6n) directrices, 167 equipo, 168 Recopilacl6n de requisitos,

webApps. 520 Recursos ambientales, 6% Recursos del proyecto, 694

Recursos humanos, 695 Red de actividad, 735 Red de tareas, 735 Reeslructurad6n de c6digo, 9 17

Riesgo, 114 componentes, 753 estrategias, 747 formato erc, 759 definici6n de, 748 controladores,753 identificaci6n, 750 impacto, 754, 757 planeaci6n, 759 proyecci6n, 754 refinamiento del. 759 tipos de, 748 Rotulaci6n, menus y comandos.

Soluci6n de problemas, 106 SOluci6n pica, 86 Soporte, 126 SPICE,37 Sprint, 94 Subcontrataci6n, 718 ingenierla Web, 530 Sucesiones, 841 suficiencia, 482 Susceptibilidad a las pruebas, caracteristicas de la, 420 Tabla de decisi6n, 342 labia de recursos, 739 Tabla de Mesgo, 754 Tablas de rastreabilidad, 162 Tamano, 482 Tamano, proyectos de software,

374
Ruta cri tica, 736 Rutas de acci6n, 306 Rutas independientes, 424 Salvaguarda del sofiware, 762,

de datos, 917
Reestructuraci6n de c6digo, 91 I Reestructuraci6n de datos, 911 Reestructuraci6n de documentos,

698
Tecnologia del proceso, 42 Tecnologlas, futuro, 929, 935 Tiempo de respuesta, 373 Tiempo en el mercado, aplicaciones basadas en Web, 569 Tiempo media de reparad6n n-MDR), 787 Tiempo medio entre fa11as n-MDF), 787 Toxicidad del equipo, 648 Ttansacci6n, 298 1\IOOs, 282

788
5eguimiento de conflictos, 808 5eguimiento de la dependencia,

910
Refabricaci6n, 87, 258 Refinamiento, 257

805
5egulmlento de requisitos, 805 Seguimiento del proyecto, [Web,

Refinamiento paso a paso, 257

Reg:la 40-20-40, 732

Remgenierta, 906
economla de la, 923

535
Seguridad,407,506 aplicaclones basadas en la Web,569 pruebas de, 407, 630 Servicios otorgados, 807 Sigma seis, 785 Slml1arldad,482 Simulaci6n del sistema, 139 Sistema definici6n de, 134 elemento macro, 135 Sistema de versiones concurrentes (5VC), 809 Sistemas basados en componentes, 880 Sitios Web, bien diseflados, 58J Software aplicaciones heredadas, II caracteristicas del, 5 definici6n de, 4 mitos acerca del, 14 papel evolutivo del, 2 preguntas fundamentales, 4-5 referencias hist6ricas, 4 Software de ingenieria y dentifico,9 SOfiware de Inteligencia Artificial. 9- 10 Software de linea de producto, 9 Software de sistema, 8 Software heredado, I I calidad del, 12 Software, categorias de aplicaci6n, 8-9 Software empotrado, 9 Solicitud de cambio, 810

modelo del proceso, 908

Reingenierla del proceso de

negoclos (RPN), 903

Reportes de estado, 814 RequlslIos de los aspectos. 65

modefo del proceso, 904 Rt:!aclones del contenido. 554

Requisitos, validaci6n de los, 186 Rc s8ua rdos, 394 Responsabilidades, definici6n de

e Re, 227 Retraso,93 Reutilizabilidad, 64 Reu tili zaci6n, 8, 109,269,325.

analisis y disei'io, 891 medio ambiente, 894 Revisi6n de la configuraci6n, 405 Revisiones. Vea.se tombien Revlsiones tecnicas formales (RTF) basadas en muestra, 781 conservaci6 n del registro, 779 directrices, 780 Junta de reuni6n, 778 reporte genera), 779 reportes, 779 ~viSlones basadas en muestra,

...

781
Jtevis,K)nes del software, 774, V~ tambien Revisiones ~nes tecnicas fonnales (RTF), 250, 577, 774. Vtase IaI7IbIen Revisiones

UML diagrama de actividad, 148, 180209, 335 diagrama de carriles, 209, 366 diagrama de casa de usa, ISO, 178, 547 diagrama de colaOOraci6n, 332 diagrama de clase, 150, 180 diagrama de despliegue, 148, 268 diagrama de eslado, 181 , 216, 247 diagrama de modelaci6n del sistema, 148 diagramas de secuenc\a, 238 elabara ci6n del componente, 318 estereotipo, 233 grafica de estado, 336 OCL, 337, 845 paqueles, 234 representaciones de interfaz, 265,333 Unidad semantica de navegaci6n (USN) , 592, 626 Uso, casas de, 360 analisis de tareas, 36 1 aplicaciones basadas en la Web, 524, 547, 554

desarrollo del, 173 escritura, 202 identificaci6n de eventos, 235 medici6n, 674 preguntas acerca del, 17417S

usuarios finales, III Validaci6n, 161, 384 Velocidad del proyecto, 86 vertficaci6n, 384 vlnculos de navegaci6n, 591 Volatilidad, 483 WebApPS, 9, 504 atnbutos de las, 504

Usuario, 26, 643 idenlilicaci6n del, 173 puntos de vista multiples, 173

INDICE DE SIGLAS MAS COMUNES EN INGENIERiA DEL SOFTWARE

Sig1as espafiollingles
Termino equivalente en espaifal
ABC M PI (apreciaCi6n basada en el eMU para el mcjoramiento del proceso interno) 37 Ace (aulorklad del control del cambio) 810 ..-.op (paradigma de dlseno abstracto) 883 AECO (acoplamiento entre clases de obJctos) 485 AG2 0 (analisis geometrico bidimensional) 70 I AG 3 D (anaHsis geometrico tridimensional) 701

Termino equwalente en mgles

CMM (based appraisal for internal procces improvement eSA 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 (external interface files) IUs (intemallogical files) OODA (object-oriented domain analysis) PAD (public access to data members) orr (depth of the lnherttance tree) RNA (relationship-navigation-analysis) EVA (eamed value analysis) BVA (boundary value analysis) CAD (computer aided design) COTS lcomercial off-the-shelf)

AlE larchivos de interfaz extemos) "75

AU (archlVOS 16gicos intemos) 474 ADO (analisis orientado a objetos) 201 APD (acceso publico a datos) 495

APH larbol de profundidad de la herencia) 484 AR.N (anallsis relad6n-navegaci6n) 560 AVO (iinallSIS del valor ganado) 742
AVL lanaUsis de valore!'; limite) 437 CAD (dl5ei'lo asistido por computadora) 700

CCYD ICOmponentes comerciales ya desarrotJados)

695
COL (componentes comerctales de Ilnea) 881
CE (consultas extemasj 474 f;N (conU~dor numtrlco) 6% co (complejidad de la operaci6n) 491 COCOM O (model0 COf\5tn.u:tIVO de costOS) 710 COM (modelo de obJelos para componentes) 889 CORDA (arqultectura comun de distnbuci6n de obJetos) CPTC (costo presupuestado para el trabajo calendarizado) 743 CPTR !costo presupuestado del trabajo realizado) 743 CRC (c!ase-responsabilidad-colaborador) 225 CRTR (costo real del tTabajo reallzado) 743 erc (condici6n-transici6n-consecuencia) 759 DAS (desarrollo adaptativo de software) 89 D BC (desarrollo basado en componentes) 63 D BMS (gestor de bases de datos) 614 DCA (disei'io de contexto arquitect6nico) 288 DCBD (descubnmiento de conocimiento en base de datos) 278 DeC (desarrollo conduddo par caraCleriSlicas) 95 DCS (diagrama de contexto del sistema) 1<15 DFD (dlagrama de flujo de datos) 21 I, 298 DFS (dl3grama de flujo del sistema) 146 DIE IdesvIadOn inteneional de las especiflcaciones) 784 DO -Idocumentaci6n imprecisa 0 incompleta) 784

COTS (cornercial off-the-shelf) EQs (external inquiries)

N C (numerical control)

oc (operation compleKity)
COCOMO (constructive cost model) COM (component object model) CORDA (common object request broker architecture)

'"

sews

(budgeted cost of work scheduled)

BCWP (budgeted COSt of wort: perfonned) fTR (formaltechn!ca\ reviews) ACWP (actual cost of work perfonner) ere (condition-transilion--ronsequence) ASO (adaptative sof\ware development) CBO (component based development) DBMS (database manager system) ACD (architecture context diagram) KDD (knowledge discovery In databases) FDD (feature dnven development) SCD (system context diagram) DFO (data now diagram) SFD (system flow diagram) IDS (intentional deviation from specifications) 110 (inaccurate or incomplete documentation)

953
DMADV (defimr, medlr, analizar, disei'iar y venflCaf) 786 DPR (disei'io para Ja reutilizad6n) 891 DRA (desarrollo rapido de aplicadones) 53 D50A (desarrollo de sollware orientado a aspectos) 6S DU (cadena definiciOn-uso) 431 EAT (eSlructura de anillisis del trabajo) 737 EC (espedflcacl6n de control) 215 ECS (elementos de configurad6n del sonware) 800 EDt (entomos de desarrollo integrado) 4 13 EE (entradas eXl emas) 474 EO (eflCacia en La elimlnad6n de defectos) 677 ELE (espec!ncadones Incomp1etas 0 ert6rleas) 784 ElS \entomo de ingenierla del software) 696 ELD (elTor de la I6gic.a del diset\o) 784 EP (espedflcaci6n de proceso) 217 EPI (equipos de producto lntegrado) 40 ER (exposkl6n al riesgo) 757 ERD (errores de la representad6n de 10$ datos) 784 FA (factor de acoplamlento) 487 FCM (falta de cohesl6n en mi!:todos) 485 FCP (rundOn de control periferica) 701 FDN (formas de navesaci6n) 591 FIN (dependenda hada dentro) 495 FIUC (facilidades de interfaz del usuario y control) 701 FPCC (facilidades de presentad6n gtiflca de compulaDMA1)V (define, measure, analyze, design, and verify! DFR {design for reuse) HAD (rapid appl icatIon development) AOSD (aspect - onented software development) DU (definition-use chain) WBS (work. breakdown structure) CSPEC (control specificat ion) SCIs (sollwa re configuration Items) IDEs (lnlegrated development environment) EIs (external inputs)

DRE (delTect removal efficiencyJ

1ES (incomplete or e~ specUkalion) SEE (software engineering environment) EDL (error in design logiC) PSPEC (process specincaUon) IPT (Integrated product teams) RE (risk exposure) ERD (error in data representation) CF (coupling factor) LCOM (lack of cohesion In methods) FCF (peripheral control function) WoN (ways of navigating) FIN (fanin) UICF (user interface and control facUitles) CGOF (computer graphla display facililies)
DBM (database management) SCM (software configuration ntarklgement) ITG (independent test group) GUl$ (graphIcal user Interfaces) DSQI (design structure quality index) ICI (mconsistent component interface) AOCE (aspect-oriented component engineering) CPt (cost performance index) HCI (human-computer interadion) CMMI (capability maturity model Integration) SMI (software maturity index) API (application programming interface) BPE (business processes engineering) HE (requirements engineering) CBSE (component based software engineering) ISO (international organi~atlon for Slandardi~ation) UI (user interface) KLOC (thousands lines of code) ADl..I (architectural description languages) POL (program design language) AM (agile modeling) AT AM (architecture trade-olT allaltsis method)
DAM (design analYSIS modules) M CC (miSinterpretation of customer communication)

dlxa) 70 1
GBO (gestl6n de bases de datos) 701 GCS <gestiOn de la cooflguracl6n del software) 796 GIP (grupo indepel'ldlente de pruebal 386 GUls (interfaces grilflcas de usuario) 452 ICED (indice de calidad de la estructura de dlSei\o) 480 ICI (interfaz de componente inconsistente) 784 ICOA (ingenlerla de componentes orientada a aspectos)

65
IDeo (Indice de desempel'lo del costO) 744 IHC (interfaz hombre-computadora ambigua 0 inconsistente) 784 IMCM (lntegrad6n del modele de capacidad de madurez) 29 IMS (Indlce de madurez del software) 496 IPA (interfaz de programacl6n de la aplkacl6n) 887 IPN (ingenleria de procesos de negocios) 140 IR (ingenieria de requisitos) 157 ISBC (Ingenler1a del software basada en componente51 879 ISO (orsanlzacl6n Internacional de estandarizadOn) 38 IU (interfaz con el usuario) 264 KLDC (miles de Hneas de c6di801 669 LOA (lenguaje de descripcl6n arquitect6nical 296 LOP (Ienguaje de disei'io de programas) 217 MA (modeJado agil) 97 MACA (metodo de analisis de compensaci6n para la arqulteclural 294 MAD (m6dulos de antllisls de diseno) 701 MCC (mala interpretaciOn de Ia comunicacl6n del cliente) 784 MDHOO (metodo de diseflo htpermedla orienlado a objelOS) 595

OOHDM lobfect-()liented hlpennedia design method)

...
MJ)SD (mttodo de

desarrollo de sistemas dinamlcos) 91 ME (metas especHicas) 31

M.EIEMP (metoda de evaluaci6n de la lMCM estandar

para eJ mejora miento del proce50) 37 MEPS (mejora estadlstica del proceso de software) 667
MFH (metodo del factor de herenci a) MG (metas senericas) 32 MIS (mlscel~neo) 784 487

MM CGP (modelo de madurez de la capacidad de sesti6n

de personal) 641 MPC (mclodos ponderados pot clase) 484 MRC (metodo de ruta critical 736 MVC (modelo-vista-ronlrolador) 589 NCR (numero de clases ralz) 495
NCSC (nuevos componentes de sotl:ware com erclalesJ

6l
NOD (numero de descendientes) 485 NOA (numero de operaciones af\adi das) 488 NPO (nuevos punlOS objeto) 711 NPOp<OIn (numero promedio de par;imetros de la operaci6n) 492

DSDM (dynamic system s development method) SG (specific goals) SCAMPI (standard CMMI assessment method for process improvement) SSP) (statistical software process improvement) MIF (met hod Inheritance factOr) GG (generic goals) MIS (miscellaneous) PM-CMM (people management capability maturity model) WMC (weighted methods per class) CPM (critical path method) MVC (modcl-vicw-controller) NOR (number of root classes) NCSC (commercial off-the-sclf (COTS) sofiware component) NOC (number of children) NOA (number of operations added by a subclass) NOO (number of operations overridden by subclass) NP.., (average number of parameters per operation)
ECO (engineering change order) OCL (object constraint language) OMG (object management group) GQM IgOaVquestion/metric) ORB (object request broker) OCP (open closed principle) CCP (common closure principle) CRP (common reuse principle) PDL (program design language) SP (specific practIces) REP (release reuse equivalency pri nciple)

OCI (orden de cambia de la ingenier1a) 810

OCl (lenguaje de restricci6n de objeto) 332 OMG (grupo de gestiOn de objetos) 889 OPM (objellvo/pregunta/mttrica) 470 ORB (diSlribuidor de objetOS) 889
PAC (pnnciplO abierto-cerrado) 322 Pee (principio del cicrrc comun) 325

PCR lpnnclpio comiln de )01 rel.ltilizacin) 325 PDl Oenguaie de diseno de programas) ~3
p o; IPrAcdcas c5f"cHlcasj ;)1

P ER (prlncipio de cquivaJencia entre reutilizaclOn y ver-

sIOn) 325 PERT (tunica de evaluacion y revision

PF /punto de funclOn)

de programa)

PERT (program evaluation and review technique)

PG (practlcas genencas) 32
PIO (pnncipio de inversi6n de la dependenaa) 324 "'1 Iprucba tnOJrnpleta 0 errollCal 71:14 PNR (curva PuUlam-Norden-Rayleigh1 730 POA (programaci6n orientada a aspeclOS) 65 PSE (proceso de software en eqUlpo) 40 PSI (principlo de segregaciOn de la interfaZ) 324 PSL (principio de sustituci6n de Uskov) 324 PSP (proceso de software personal) 39 PU tproceso unHlcado) 67 PYP (porcenlaje publico y protegido) 495 QFD (desphegue de Ia funciOn de caUdad) 171 RPC (respucsta para una clase) 485

'"

474

RJ1" (revisiOn tecnica formal)

145

RSGR (reducciOn. supen.'\siOn y gestiOn del riesgo) 761 774 SCCT (sistema de clasificaciOn de cinta transportadora) 5 (salidas extemas) 474 51 (mstltuto de ingenierta del software) 29 SQA Igarantla de la calidad del software) 767 SQL (lenguaje de consultas estruct urado) 614

FP (fullCtion points) GP (generic practices) DIP (dependency inversion principle) lET (Illcomplete or erroneous testing) PNR (Putnam-Norden-Rayleigh curve) AOP (aspec.t-ofienled programming) TSP (team sofiware process) ISP (i nterface segregation princip le) LSP (Usltov substitution principle) PSP (personal sofiware process) UP (unifled process) PAP (percent public protected) QFD (quality function deployment) RFC (response for a class) RMMM tnsk m itigation, manitonng and management) F11'; tformal technical reviews) CLSS (conveyor line sortlllg system)
EOS {COS (external outputs) SEI (software engineering institute) SQA (software quality assurance) SQL (structured query language)

9
SVC (siSl:ema de versiones concurrentes) 809
CVS (concurrent versions system)

TC (tamaflo de Ia clase) 488 TI (tecnologla de I. Informad6n) 278 n..p (error de Ia traducc\6n del dlseno al lenguaje de programaci6n) 784 TMC (tiempo medlO de cambio) 677 TMDF Y TMDR (Iiempo medic de falla y liempo medio de reparadOn) 787 TMEF (tiempo medic entre fall.s) 787.874 TMR (tiempo medic de reparac;6n) 407 TO_ (tamano promedio de operadOn) 491 UML (lenguaje de modelado unificado) 68 USN (unidad semointica de navegaclOn) 591 VAD (visiOn abstracta de datos) 597 VC (varianza del costO) 744 YEP (VioladOn de los estoindares de programaciOn) 784 VyV (verificadOn y valldaci6n) J84

CS (class size) IT (information technologies) PLT (error programmins language translation)

M'1TC (mean-l lme-to-change) MTTC ... MTn' (mean-lime-Io-ch.argel and (meantime-to-failure) Mmf (mean time between railures) MTTR (mean lime to repair) (averase operation size) UML (unified modeling languase) NSU (navigation semantic unit) ADV (abstract data view) CV (cost variaroce) VPS (violation of programming standards) vav (verlncatkm and validation)

os..

Siglas Ingles/espallol
Tcrmino en Ingles
3DGA (three-dimensional geometric analysis) 2DGA (two-dImensional geometrk: analysis)

Termlno equlvalenle en

~palIol

ACD (architecture context diagram) ACWP (actual cost o(work performer) ADU (architectural description languages) ADP (abSl:ract deslng paradigm) AnV (abstract data view) AM (agiie modeling) AOCE (aspect-oriented component engineering)

AOP (aspect-oriented programming) AOSD (aspect-orlented software development) API tapp lkation programming Interface) ASD (adaptaUve software development) ATAM (architecture trade-ofT analisis method)

BCWP (budseted cost of work performed)

8CWS (budgeted cost of work scheduled)

BPE (business processes engin~ring) BVA [boundary value analysis) CAD (computer aided design) CBD (component based development) COO (coupling between object classes) CSSE (component based software engineering) CCA (change control authority)
CCP (common closure principle)

CF (coupling factor) CGDf (computer graphics display ractlitles)

AG30 (anoili$is geometrlco tridimensional) 701 AG2D (anoilisis geometnco b1dlmensional) 101 DCA (disef1o de contexte arquitectOnIoo) 288 CIn'R (costo real del trabaJo realizado) 743 lDA (lenguaje de descripci6n arquitect6nica) 2% ADP (paradigm" de disci\o abstracto) 883 VAn (visiOn abstracta de datos) 597 MA (modelado igil) 97 ICOA (ingenieria de oomponente5 orientada a aspectos) 6S POA (programaci6n orientada a aspectos) 6S DSOA (desarrollo de software orientado a aspectos) 6S IPA (interfaz de programaciOn de la aplicaci6n) 887 DAS (desarrollo adaptativo de software) 89 MACA (metodo de aniilisis de compensaclOn para la arquitectura) 294 CPTR (costo presupuestado del trabajo realizado) 743 CPTC (costo presupuestado para el trabaJo calendarizado) 743 IPN (lngenleJia de procesos de negoclos) 140 AVL (ami.lisis de valores limite) 437 CAD (dlseno asistido per computadora) 700 DBC (desarrollo basado en componentes) 63, 886 AECO (acoplamiento entre clases de objetos) 485 lSBC l ingenierla del sol'l:ware basada en componenles) 879 ACe lautoridad del control del cambio) 8 10 PCC (pnncipio del derre cornun) 325 fA (factor de aooplamiento) 487 FPGC (facilidades de presentaciOn groinca de cornputadora) 701

...
COTS (comercial off-the-shell) CLSS (conveyor line sortmll system)

CMM (based appraisal for Internal procces improvement

CBA [PI)

CMMI (capability matunty model Integration)

COCOMO (constroctlve cost model)
COM (component object model) CORDA (common object request broker architecture)

CPt (cost performance index) CPM (critical path method)

CRP (common reuse principle) CS (class size) CSPEC (control spectncalJonj

ere (condition - transition - consequence)

cv (cost variance) cvs (concurrent versions system)

DAM (design anal)'5is modules) OBM (database management) DBMS (database manager system)

DFD (data Row diagram)

DFR (design for reuse) DIP (dependency inversl6n principle)

OIT (depth of the inheritance tree) DMADV (define, measure, analyze, design, and verify) ORE (deITec! removal efficiency)

o'DM (dynamic ~CfTl!) development methOd)

[)Qt (de..ign structure quality lndex) DU (defln ition-use chain)
~(;O

lengmeenng Change order)

EDL lerror 1n design logic)

lOIS lexternal inputs) (external interface files) EOs (external outputs) Qs (e ldemal i nquiries) lORD (error in dal a represenlallon) EVA teamed value analysis) FDD (feature driven ~Iopment) FIN (fan-in) FP (function points) fTR (forma l technical reviews) fTR (forma l technical reviews) e.G (generic goals) GQM (goal/questi(m/metric) CiP (generic practices) GUls (graphical user interfaces) HCI (human-computer interaction)

EIFs

ICI (lnconsiSient componenl interface)

lOEs (integrated developmenl environments)
IDS (intentional deviation from specifications) IES (inc:ornJMete or erroneous specificahon) lET lmcompletc or erroneous testing)

COL (componentes comerdales de Unea) 695 SCCT (sistema de clasificaci6n de clnta transportaoora) 145 ABC MPI (apreclaci6n basada en eJ cmm para el mejoramiento del proceso Interno) 31 lMCM tintegraci6n del modelo de capacidad de madurez) 29 COCOMO (modelo constructivo de castos) 710 COM (modelo de objetos para componentes) 889 CORDA (arquitectura comun de distribuci6n de objetos) 889 lOCO (Indice de desempei'lo del costa) 744 MRC (metodo de ruta critical 736 PCR (principjo cornun de Ia reutilizaci6n) 325 TC (tama i'lo de la clase) 488 EC (especiflcaci6n de control) 2 15 CTC (condicl6n-transici6n--oonsecuencia) 759 VC (varianza del costa) 744 SVC (sistema de versiones concurrentes) S09 MAD (m6dulos de analisis de disei'lo) 701 GBD (gesti6n de bases de datos) 701 DBMS (gestor de bases de datos) 6 14 OFO (diagrama de nujo de datos) 21 1,298 OPR (disetlo para la re1Jtilizaci6n) 891 PlO (principia de Inversi6n de la dependencial 324 APH (arbol de profundidad de la herencia) 484 DMADV (definir, medir, analizar, dJsei'iar y verificar) 786 EEO (eflcacla en la eliminaci6n de defectos) 677 MDSD (metoda de desarrollo de sistemas diMmicos) 91 ICED (lndice de calidad de 18 e5tructura de disei'lo) 480 OU (cadena definici6n-uso) 431 OCI (orden de cambio de (a ingenierfa) 810 ELD (errOr de la J6gica del disei'io) 784 EE (entradas exl emas) 414 AlE (archlvos de interfaz extemos) 475 SE (salidas extemas) 474 CE tconsultas exlemas) 414 ERD terrores de la representaci6n de los datos) 784 AVG (anflllsls del valor ganado) 742 DCC (desarrollo conducido por caracteristicas) 95 FIN (dependencia hada dentro) 495 PF (punto de funci6n) 474, 670 CRC (clase-responsabilidad-colaborador) 225 RTF (revisl6n t~nica formal) 774 MG (metas gentricas) 32 OPM (objetivo/pregunta/metrica) 470 PG (pTacticas genericas) 32 GUis (interfaces graflcas de usuario) 452 IHC (interfaz hombre--computadora arnbigua 0 lnconslstente) 784 ICI (interfaz de componente inconsistente) 784 EDI (entornos de desarrollo inlegrado) 413 DIE (desviacl6n intencional de las especilkadones) 784 EIE (especificaciones incompletas 0 err6neas) 784 PIE (prueba incompleta 0 err6nea) 784

110 (inaccurate or imcomplete documentation) II..P.I (internal logical tilesl IPT (integrated product teams) ISO (international organization for standardizatiOn)

ISP (interface segregation principle) IT (information technologies) rro (independent test grouP) KDO (knowledge discovery In databases)
KLOC (thousands lines of code)

LCOM (]act of cohesion in methods) LSP (Liskov substitution principle) MCC (miSinterpretatIOn of customer communicatIon) MIF (method inheritance factOr) MIS (miscellaneous) MTOF (mean time between failures) MTTC II. MTTF (mean-time-to-dlillrge) and (mean-timeto-failure) MTTC (mean-time-to--dumge) M1TR (mean time to repair) MVC (mooel-view-control1er) NC (numerical control) NCSC (commerdal off-the-self (COTS) software component) NOA (number of operations added by ill subclass) NOC (number of children) Noo (number of operations OIIerridden by subclass) NOR (number of rOO classes) NP... (average number of parameters per operation) NSU (navigation semantic unit) OC (operation complexity) OCL (object constraint language) OCP topen closed principle) OMG (object management group) ooOA (object-oriented domain analysis) ooHOM (object.-oriented 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) POL (program design language) PERT (program evaluation and review technique) PlI (error pTogTamming language translation) PM -CMM (people
ma~ment

capability matunty model)

PNR (Putnam-Norden-Rayleigh curve) PSP (personal software process] P$PEC (process speciocation) QFD (quality function deployment) RAn (rapid application developmen t) RE (requirements engineering) RE (risk exposure)

Oil (documentatiOn unpreOsa 0- mcompleta) 184 l6gicos intemes) 414 PI (eqUlpos de producto integrado) 40 ISO (organaad6n International de estandarizaci6n) 38 PSt (principlo de segregaci6n de la interfazl 324 n (tecnologia de 13 informaci6n) 278 GIP (grupo independiente de prueba) 386 DCBD (descubrimiento de conocimiento en base de datos) 278 KLDC (miles de Hneas de COdigo) 66~ FCM (falta de cohesl6n en mttodosJ 485 PSL (principlo de sustltucl6n de Uskov) 324 MCC (mala Interpretaci6n de la comunicaci6n del C\iente) 784 MFH (metooo del factor de herencia) 481 MIS (miscelaneo) 784 TMEF (Uempo medio entre fallas) 787 TMOF Y TMDR (tiempo medic de falla y tlempo medlo de reparaci6n) 787 TMC (tiempo medio de cambio) 617 TMR (tiempo medio de reparaci6n) 401 MVC (modelo-vtsta-controlador) 589 CN (contador numerlcol 696 NCSC (nuevos componenles de sof\ware comeraaJes) 63 NOA (numero de operaciones anruildas) 488 NO~ (numero de descendientesl 485 NPO (nuevos puntas objeto) 111 NCR (numero de cJases ralz) 495 NPO,...... (ntimero promedio de paramel ros de la operacl6n) 492 USN (unidad semantica de navegad6n) 59t CO (complejidad de la operaci6n) 491 OCL (lenguaje de restrlccl6n de obJetol 332 PAC (principlo abierto-cerrado) 322 OMG (grUpo de gesti6n de ob}elos) 889 Aoo (analisis orientado a oojetos] 201 MOHoo (metodo de diseno hipermedia orlentado a objetos) 595 ORB (distribuldor de obJetos) 889 TO,...... (tamano promedlo de operaci6n) 491 APO (acceso pUblico a datos) 495 PYP (porcentaje pUblico y protegido) 495 FCP (funci6n de control periferica) 701 LDP (lenguaje de diseno de programas) 217 PERT ttecnica de evaluaci6n y revisl6n de programa) 136 TI..P (error de la traduccl6n del diser\o allenguaje de programaci6n) 784 MMCGP (modelo de madurez de la capacidad de gesti6n de personal) 641 PNR lcurva Putnam-Norden-Ray)elgh) 130 PSP lproceso de software personal) 39 EP (espectrlCac\6n de proceso) 2 11 QFO (despliegue de la runcl6n de calidad) 17' ORA (desarrollo rapido de apUcaciones) 53 IR (ingenierla de requiSltos) 157 ER (exposici6n al riesgo) 757
AU (archivos

...
REP (release reuse equivalency principle)

RFC (response for a class) RMMM (risk mitigation, monitoring. and management)

RNA (rc lationship-navegation-analisys)

SCAMPI (standard eMM1 assessment method for process i mprovement) SCD (system context diagram)

self (software configuration items)

SCM (softwa re configuration management) SG (specific goals)

SEE (software engineering environment) SE) (software enginccring institute) SFO (syste m flow diagram) SMI (software maturity indell] SQA (software quality assurance) SQL (structured query language)

SP (specific practices)

SSPI (statistical software process improvement)

T$P (learn software process) UI (user interface) UlCE (use r interface and control facilitie5)

UML (unirled modeling language) UP (unified process)

V6.V (venflCation and validation) VPS (violation ofprogrammml! standards) was (work breakdown structure) WMC (weighted methods per class) WoN (ways af navegating)

PER {principia de equivalencia entre retltilizaci6n y versl6n) 325 RPC {respuesta para una elase) 485 RSGR (reducci6n, supervisi6n y gesti6n del riesgo) 761 ARN {antdisis relacibn-navegaclbn) 560 MEIEMP (metodo de evaluaci6n de la IMCM estAndar para eI rnejoramienla del proceso) 37 DCS (diagrama de contexto del sistema) 145 ECS (elementos de configuraci6n del software) 800 GCS (gesti6n de la configuraci6n del software) 796 ME (metas espec!flcas) 31 EIS (entemo de ingenierta del software) 696 SEI (institute de ingenierla del software) 29 DFS tdiagrama de Oujo del sistem a) 146 IMS (Indice de madurez del software) 496 SQA (garanlla de la calidad del software) 767 SQL (Ienguaje de oonsultas estructurada) 6 14 PE (practicas especlflcas) 31 MEPS (me}ora estadlslica del proceso de software) 667 PSE (proceso de software en equipo) 40 IU (interfaz can el usuario) 264 FlUC (fadlidades de interfaz del usuario y control) 701 UML (lengua)e de modelado unlficado) 68 PU (proceso uniflcado) 67 VyV (verlficacl6n y validaci6n) 3&4 YEP (Vialacl6n de los esttmdares de programaci6n) 784 EAT (estructura de antllisis deltrabajo) 737 MPC (metodos ponderados por elase) 484 FdN (fonnas de navegad6n) 591

Los 32 copitulos de 10 sexto edici6n se han orgonizodo en cinco partes:

Parte 1. EI proceso del software, presenta diferentes perspectivas del proceso del software y considera todos los modelos de proceso importantes; ademas, aborda el debate entre las filosofias del proceso prescriptiv~ y del proceso agil. Parte 2. Practica de la ingenieria del software, presenta metodos de analisis, disefio y prueba con especial interes en las tecnicas orientadas a objetos y el modelado UML. Parte 3 . Aplicaci6n de la ingenieria Web, presenta un enfoque completo de ingenieria para el anal isis, disefio y prueba de aplicaciones Web. Parte 4. Gesti6n de proyectos de software, presenta temas relevantes para quienes planean, gestionan y controlan un proyecto de software . Parte 5. Temas avanzados en ingenieria del software, presenta capitulos que abordan metodos formales, ingenieria del software de sala limpia, ingenieria de software basada en componentes, reingenieria y tendencias futuras.

Ademas de muchos capitulos nuevos y significativamente revisados, la sexta edici6n incluye aproximadamente 120 recuadros que: Permiten allector seguir a un equipo de proyecto (ficticio) conforme planifica y disefia 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 ingenieria del software. Sugiere herramientas automatizadas de interes para los temas de los capitulos.

McGraw-Hili Interamerlcana
ISBN 970 - 10-5473-3

The McGrawHiII Compames

9 78970 1 054734

1 111111 111 I

Visite nuestra pagina WEB www.mcgraw-hiIl-educacion.com