./

Un enfoque practico

PARTE UNO

PARTE DOS

PARTE TRES

CAPlTuLO 1 Software e ingenierio del software

EI proceso del software 21

CAPlTuLO 2 CAPlTuLO 3 CAPlTuLO 4

EI proceso: una vision general 22 Modelos prescriptivos de proceso 48 Desarrollo agil 77

Practica de la ingenieria del software 103

CAPlTuLO 5 La practica: una vision generica 104 CAPITuLO 6 Ingenierio de sistemas 133 CAPlTuLO 7 Ingenieria de requisitos 155 CAPlTuLO 8 Modelodo del analisis 191 CAPlTuLO 9 Ingenieria del diseno 245 CAPlTuLO 10 Diseiio arquitectonico 275 CAPlTuLO 11 Diseiio 01 nivel de componentes 315 CAPlTuLO 12 Diseiio de 10 interfaz de usuario 350 CAPlTuLO 13 Estrategias de prueba del software 382 CAPlTuLO 14 Tecnicas de prueba del software 418 CAPlTuLO 15 Metricas del producto pora el software 462

Aplicacion de la ingenieria Web 501

CAPlTuLO 16 CAPlTuLO 17 CAPlTuLO 18 CAPlTuLO 19 CAPlTuLO 20

Ingenieria Web 502 Formulacion y planeacion pora ingenieria Web 517 Modelado de anal isis pora aplicaciones Web 544

Modelado de diseiio pora aplicaciones Web 566 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 640 Metricas de proceso y proyecto 663 Estimacion pora proyectos de software 690 Calendarizacion de proyectos de software 724 Gestion del riesgo 747 Gestion de 10 calidad 767 Gestion del cambio 796

vii

vill

PARTE CINCO

CONTENIDO BREVE

Temas avanzados en ingenieria del software 829

CAPITuLO 28 CAPITULO 29 CAPITuLO 30 CAPITuLO 31 CAPITuLO 32

Metodos formales 830

Ingenieria del software de sola limpia 858 Ingenieria del software basada en componentes 879 Reingenieria 902 EI camino por recorrer 927

Pre/acio xxviii Recorrido xxxi CAPiTuLo 1 SOFTWARE E INGENIERlA DEL SOFTWARE 1 . 1 EI papel evolutivo del software 2 1 .2 Software 5 1 .3 La naturaleza cambiante del software 8 1 .4 Software heredado 1 1

1 .4 .1 Calidad del software heredado 12 1 .4 .2 Evoluci6n del software 12

1.5 Mitos del software 14 1 .6 C6mo inicia todo 17 1 .7 Resumen 1 8 Referencias 1 8 Problemas y puntos a considerar 1 9 Otras lecturas y fuentes de informaci6n 20

PARTE UNO: EL PROCESO DEL SOFTWARE 21

CAPiTuLO 2 EL PROCESO: UNA VISION GENERAL 22 2. 1 Ingenieria del software: una tecnologia estratificada 23 2.2 Marco de trabajo para el proceso 24 2.3 Integraci6n del modelo de capacidad de madurez (IMCM) 29 2.4 Patrones del proceso 34 2.5 Evaluaci6n del proceso 36 2.6 Modelos de proceso personales y en equipo 38

2.6 .1 Proceso de software personal (PSP) 39 2.6 .2 Procesos de software en equipo (PSE) 40

2.7 Tecnologia del proceso 42 2.8 Producto y proceso 43 2.9 Resumen 44 Referencias 45 Problemas y puntos a considerar 46 Otras lecturas y fuentes de informaci6n 47

CAPiTuLO 3 MODELOS PRESCRIPTIVOS DE PROCESO 48 3.1 Modelos prescriptivos 49 3.2 EI modelo en cascada 50 3.3 Modelos de proceso incrementales 51

3.3.1 EI modelo incremental 52 3.3.2 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 3 4 4 Un comenlOrio final sobre bs pr!Xe$O$ Mutivos 61

3.5 ~ e5peCKllizodos de ploceso 63 3.5. I Desarrollo bosodo eo componenlel 63 35.2 EI modeIo de metodos formoies 64 3.5.3 Desarrollo del sohwore ollentodo 0 o~ 65

3.6 EI p'ClCeSO uni~cado 67 3.6.1 Uoo breve historic 67 3.6.2 Foses del procer.o un ilicodo 68 36.3 ProcilJcto5 de (labolO del proceso umf>codo 71

3 .7 Resumen 72 Referencias 73 Problemas y puntos 0 conSlderO! 7.4 OlIOS lecturos y fueoles de InlofmociOn 75 CAPfruLo 4 DESARROU.OAGIL 77 .4 1 aGue es 10 ogilidod? 79 .4 2 aGue es un prOC85O 6gil? 81

.4 2, I los poIilioos del de5mrollo 6gil 81 42.2 Fodores humorlO$ 82

4.3 NIocIeIos 6grles de prOCE!$O 84 .4 3, I Progromoci6n exrremo Iff) 84 , 3 2 "''''''''''' ~ de """""" 10AS1 80 4 3.3 ~ de desorrolo de SIstemas drn6miCoslMOSDI 91 4.34 !Vela 92 4.3.5 Cristol 95 .4 3.6 Desarrollo cooducido pot ccrocterisllCOS (OCC! 95 4 3 7 ~ 6giliNoAI 97

4 4 Resumen 99 Relerencios I 00

Pr~emo$ y pvnlos a conSldero! 101 OIfos lecturos y fuentes de mformoci6f1 102

PARTE DOS: mcnCA DE LA INGENIERiA DEL SOFTWARE 103

cAPITuLo 5 LA PRAC'I1CA: UNA VlSI6N GENtmCA 104 5 I La pllxlico de b ingeniefia del ~re 105

5.11 loesenciodeloprootaJ 106 5.1 2 PrinoptOS e5etlCioles 107

5 2 Pr6d1COS de comurucoci60 109 5 3 Pr6dOCO$ de 10 pIoneociOn 1 1 3 5 4 Pr6chco del mcdeIodo 1 16

CONTENIOO

5.4.1 Princ,ptos del modeIodo del on6!isi$ 117 5.42 Principi05demodelododeldi~ 119

5.5 Pr6dico de 10 con5hua;i6n 122 5.5.' Pr,nc,pios y concepb5 de codifiCoci6n 123 5.5 2 Pronciptos de los proebos 124

5.6 ~iegue 126 57 Resumen 128 Rel"erencias 129 Problemas y punlos 0 considerof r 30 O!Ios leclvros y fuenle5 de infOfmociOo I 31 cAPlnn.o. INGENIERiA DE SISTEMAS 133 6.1 Sistemas baKldos en compvtoc:b-o 134 6.2 La ieforquio de 10 ingenierio de sistemas I 36

62.1 NoodeIado del sistema 137 622 SimulocK>f1 del sistema 139

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

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

6.6 Resumen 151 Rel"efenoos 152 Problemas Y punlos 0 comiderar 152 Otros leduras y fuenle5 de informoci6n 153 CAPfnn.o 7 INGENIERiA DE REQUISITOS 155 7.1 Un puente hocia eI dlsei\a Y Ia conSlrucci6n 156 7 2 Tareas de Ia inge",eria de requiSl10s 157

7.2.1 I",cla 158 722 Ob4enci6n 158 7 2.3 Elaboroci6n 159 72.4 Negocklci6n 160 7.2.5 EspecificociOO 160 7.2.6 Vol;dociOn 161 7.27 Ges/i6n de requisitos 161

73 Inkio del prCoC:MO de Ia ingenieria de requisilos 163 7.3.1 IdentilkociOO de los inlerewclos 164 7.32 Reconocimienlo de mul~ples punlo.s de visla 164 7 3 3 Trobo;o con respedO a 10 coloboroci6n 164 7.34 Formuloci6n de los pnmefas preguntos 165

7 4 Obtenci6n de requisilos 166 7 4 1 Recopoloci6n conjunlo de requlsilOs 167 742 Despliegue de 10 funC16n de calodod 171 7

xU CONnNlDO

7 4 4 Producbs de lIobolO de 10 OOtenci6n 173 7 5 De50rrollo de 0000$ de lISO 173 76 Conslrucci6n del modeIo de an61,sis 179

76 1 Elementos del modele de oOOll$ls 179 7 6.2 Patrone! de 0001'51$ 183

7 7 NegoclOCi6n de requlsllo5 184 7 8 \IoI,daci6n de requisltos 186 7 9 R:esomen 1 86 Refereocias 187 Problemas y puntos a consideror I 88 OIfos lecturos y rueotes de informaciOn 189

cAPfnn.o MODELADQ DEL ANAusIs 191 81 An6I,sis de requisites 192

811 Filosofia y obietivos generales 193 8.12 Regia! pr6cticos de orl6lisis 194 81.3 An6lisis de! domlt'lJo 194

82 Enloques de modeIodo del ooolisis 196 83 Conceplos dej modeIodo de doJos 197

831 ~dodok 197 832 A/ribulos 198 8.33 R:eIociones 199 834 Cordl/lOl.dad y modolidod 199

84 An6I'sls aleIlIodo a obtetos 201 85 ModeIodo bosodo en escenorios 202

8 5 1 serillKa de cmos de U$O 202 8 5 2 Desonollo de un doogromo de octrvtdod 208 85.3 Doaglomosdeconil 209

8 6 fvI.odebdo Oflentxio 01 Aup 21 t 86_1 CreociOO de un modeIo de Auto de dalO.t 211 8 6 2 Creoc!60 de un modelo de contrd del A(.I,o 2 14 8.6.3 bpecificoct6n de control 215 8.6.4 EspecificociOn de JXoce~ 217

87 !Y\:xIelodo basodo en closes 219 8 7 1 Identificoci6n de doses de cooli!.! 219 8.7 2 Especificoci6n de olribulo5 222 87.3 Defmici6n de operociooes 223 8.7 4 NoocleIodo de Close-Repon50bllododCoIoborodolICRC) 225 B 7_5 AsocioOones y dependencicl5 232 876 Poqueles de on6I;$is 233

8 8 Cleoci6n de un modeIo de cOITlpo!"lomoenlo 234 88 J Idenlrococi6n de evenlQ5 con eI CO$O de U$O 235 8 8 2 RepesenioclOOeS de e$IOdo 236

8 9 Resumen 239

,

CONTENIDO

ReferencKU 241 Pioblemas y punlO5 0 con.sode!ar 241 OtrO$ lecturo$ Y Iuen~ de IIllormoci6n 243 cAP!nn.o INGENIERiADELDISENO 2

...

10.4.2 10.4.3 10.4.4

Definici6n de orquetipo$ 289 Reiinomienb de 10 orquiledlJro en componenles 2QO Descripci6n de 10 creoci6n de insbocicu del slst&mO 292

10.5 EvoIuoci6n de diseiios CJI!lUiled6nicos ohefnos 294J 10.5.1 Un rne.odo de on6lisi.s de comperuoci6n pora 10 orquitecturo 294 10.5.2 Complejidod orquiled6nico 296 10.5.3 lMiguoje5 de descripci6n orquiled6nico 296

10.6 eo.reloci6n del Rujo de doIos eo uno O/quitecluro del software 297 10.6.1 Flujo de lfoNlormaci6n 297 10.6.2 Flujo de 1f0fUClCCi6n 298 10.6.3 Co.reloci6n de Irornbmociol'les 29Q 10.6.4 COI"reloci6n de IrofUClCCiOoes 306 10.6.5 Reiinomienlo del di$eoo Olquilecl6niCo 310

1 0.7 Re~umen 3 1 1 Reierencia5 312 Problemas y punlo5 0 CCln$idemr 312 OIro$ lecluro~ y ~ de inFormaci6n 313 cAJliTuLo 11 olSDio AL NIVEL DE COMPONINTES 315 1 1 . 1 aGue es un componenIe? 316

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

11.2 Diseno de componeNe$ ~ en doses 322 11 .2.1 Pfinciplo$b6sioosdediseiio 322 11 .2.2 Uneos gener. de diseiio 01 niilel de c:ornponentM 325 11.2.3 Cohesi6n 327 11 .2.4 Ac.opIomienlo 329

11 .3 Conducci6n del di$eno 01 nWel de componenle! 331 11.4 lMiguoie de re~tricci6n de objeto.s 337 11 .5 Diw.a de Componenle5 convencKxlo~ 340

11 .5.1 NoIoci6n gf6fiw del diseiio 340 11.5.2 NoIoci6n tabular del di$eoo 342 11.5.3 lenguoje de di~ de progromos 343 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 DISIHo DE LA INTERFAZ DE USUAltlO 350 12.1 Los regIos de 01"0 351

1 2. 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 NIodeIo5 del an6lisi~ y diseno de 10 inllH/oz 356 12.2.2 EI pr

CONTENIDO

13.7.3 EstrolegiO$ de depuroci6n 4 12 13.7.4 Conecci6n del enOl 414

13.8 Resumen 415 R:elerend os 4 16 ProbIemos y punlo$ 0 considerOt" 4 16 Otros leduros y fuentes de inbmoci60 4 17 CAPiTuLO ,. Tf:cNICAS DE PRUEIA DEL SOfTWARE 418 14. 1 Fundomentos de 10.0; prueOOs del software 4 19 14.2 Pruebos de cojo negro y c:ojo blanco 422 14.3 Pruebos de cojo blanco 423 14.4 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 427 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 PruebodelRujodedolo6 431 t 14 .5.3 Pruebo de budes 432

14.6 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

1 4 7 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 14.7.3 14.7,4 14.7,5

Proebo bosado en!ollos 443 CoSO$ de pruebo y jerorquio de dO$8 444 Pruebo ba.sodo en escenorios 444

14.7.6 EstruclurO$ de wp8ff;cie y de fondo en pfUebos 446 14.8 ~ de prveb:l oplic:obles 01 nivel de c:bse 447

14.8.1 Pruebo oleolorkl poro do5es OIienloOos 0 objelo6 447 14.8.2 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 451

14.10 ?ueba de enlornos ~kllizodc.a: OlquitedurO$ y oplicoc:iones 452 14. 10. 1 ~ de inlerloces gr6Iicos de UWOfio 452 14. 10.2 Pruebodaorquiledurosdienle/-w:h 452 14. 10.3 Pruebo de 10 documenllXi6n y las Iunci0ne5 de oyudo 454 14. 10.4 Pruebodemlemosdetiemporeol 455

14. 11 PotrOt'lM 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 Jr.drmcAS DEL PIlODUCTO PARA EL SOI'TWARE 462 15.1 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

t '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 15.4 .8

M6tricos orienlodos 0 10 operocl6n 491 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 Y pulllo$ 0 consideror 499 Otros lecturos y fuenle5 de informrxi6n 500

PARTI1US: APUCACJ6N DI LA DfGiIIrIIIIdA. WEB 501 cA>irvLo 16 16. 1 AIIibutos de los ~ y oplicociones bosodos eo V\Ieb 504 16.2 EaC*;lt de 10 Ingenieria de 'vVebApp 507

CONTENIDO

16.2.1 16.2.2 16.2.3

Proceso 507 """"'" 507 Henomienkls y lecnoIogio 508

10.3 EI proceso de ingenieria Web 508 \6.3. 1 Oefinici6n dell1lQlCO de .obajo 5W 16.3.2 Refinomioolo del morro de IrObo;o 512

16,4 .M&jores pr6cticos en ingenierio Web 512 16.5 Resumen 514 Refefeocios 515 Probiemo.s V ponlo.s a considerar 5 15 Otros Iecturos y fuentes de inloonoci6n 5 16

CAPtnn.o 17 FORIfULACl6N y PLAHEACl6N PARA INCiINIERIA WEB 517 17. 1 Formuloci6n de sislemos b:cxh en Web 518

1 7. I. 1 Pregunlas de flxmvloci6n 5 19 17.1.2 l1ecopiloci6n de reqvisilo5 paro W~ 520 17.1 3 El puente hocie eI modeIodo de on6Jisis 525

17.2 f'Ioneoci6n de ployeclos de ingeniefio VVeb 525 17.3 EI equipo de ingenielia Web 526

17.3.1 Los odofes 526 17.3.2 Constrvcci6n del equipo 528

17.4 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

17.5 l'v\Idici6nporoingenierioWebyV\febApp$..536 17.5.1 Mediciones para mfuerzo de ingenierla Web 537 17.5.2 Wledici6n dehdor de negocil 538

17.6 Los "peores pr6dicos' pora proyeclo$ 'vVebApp 539 1 7.7 Resumen 540 Referencios 54 1 Problemas y puntos 0 comideror 542 OIros IeclurQ.S y fuefiles de infoflTloci6n 542 cAPfTuLo 18 MODELADO DE ANAusls PARA APLICACIONES WEB 544 18. 1 l1equis ilos pora ~ on6!isis de los Web,to.pps 545 '

18 .1.1 La ieforquia de IJ$OOrio 546 18.1.2 Desarrollo de CCl$OS de \ISO 547 18.1.3 Afinoci6n del modeIo de coso de U$O 549

18.2 EI ~ de on61Ws poro WebApps 550 18.3 El modeIo de conlenido 551

18.3.1 Definic:i6ndeobjelosdecontenido 551 18.3.2 Relocionesyjerorquiocleconienido 552 18.3.3 Oases de CII"I6Iisl$ pclfO WebApps 553

18.-4 El modeIo de interoc:ci6n 554 18.5 El rnocWo funcionol 557

CGi'UWWO

IS .6 EI modeIo de confIguroci6n 559 IS.7 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 CA>Inn.o ,. UODELADO DB DISDlo PARA APUCACIONES WEB 566 19.1 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 19.4.2 Cuestiooes de disei\o gr6fico 583

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. 1 0 .v.etodo Oe 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 1 9. 1 2 Rer.umen 599 Referenclos &:Xl Problemas y punIO$ 0 oonsideror 002 Otros Iecturo y fv1res de inlormoci6n 603 CAPfTuto 20 c6uo PIlOUJI: APUCAClOHBS WEI 604 20.1 Pruebo de

..

20.1.2 EI'TOf9$ dentro de un ombien\e 'v\feb4.pp 606 20.1.3 E~oIegios de ~ 007 20.1 . .4 Plolleoci611 de 105 pruebo, 608

20.2 EI ~ de pn.rebo: Ufl panoromo tI:R 20.3 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

20.4 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

20,5 PrLl8bo 01 nive! de componentes 623 20,6 PrLlllbos de novegaci6n 625

20.0.1 Pruebo de 10 ~nklxis de 1'l

21.3 .1 21.3.2

21 .4 EJ proceso

Ambito del software 651 0esc0mp0sici6n del problemo 652

21 .4. 1 Combiooci6n del produdo y eI proo!SO 653 21 .4.2 ~delproceso 654

21.5 EI proyedo 656 21.6 EI principia W~HH 657 21.7 Pr6c:ticos csilicol 658 21 .8 Re.wmefl 659 Refereocios 6ti) Problmnos y pufllos a oon.sidefm 6ffi Otro.s lectufo.s Y luenles de inlormoci6n 661

cAPfTtn.o 22 MiTRICAS DE PROCESO Y PROYECTO 663 22.1 Mefficos en los domink del proceso y Ell proyeclo 664

22.1 1 N.etricos del proceoo y mejoro del proceoo de 50ftware 664 22.1.2 ..'v\6!ricos 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 22 .4 .3

Esioblecimienlo de uno ~neo bose 6B 1 Recopi1oci6n. 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 ESmU.CI6N PAllA PROY!C'I'05 DE SOFTWARE 690 23 .1 Cbservociones ocerca de 10 estimoci6r1 691 23 .2 EI proceso de pIonificoci6n del proceso 692 23 .3 Ambito del software y foc:tibilidod 693 23 .4 Recur-lOS 694

23.4.1 RecurlOS humonos 695 23.4.2 Recur$O$ de ~re revtilizobles 695

-23.4 .3 l1eoJr~ del enIomo 696

23.5 Estimoci6n de proyectos de sofIwofe 696 23.6 T8cnic::m de ~ 698

23.6 . I Tomono del soI!wore 698 23.6 .2 23.6 .3 23.6.4 23 .6.5 23 .6 ,6 23.6] 23 .6 .8 23 .6.9

Estimaci6n bosodo en eI problema t:RQ Un ejemplo de esIimoci6n Ixlsodo en lOC 700 Un ejemplo de es~moci6n bosoda en Pf 702 Estimaci6n bosoda en eI proceso 704 Un eiempIo de estimoci6n bosoda en eI PfOCMO 705 Eslimoci6n coo oosas de uso 705 Un ejemplo de e5timoci6n oosoda en CO.50S de uso 707 li:econciliod6n de eslimociooes 708

23.7 fvIodeIo5 ernpiriCO$ de estimaci60 7ey:; ..

23.7.1 La estrocturo de ~ moc!eIos de estimoci6n 710 23.7.2 EI modeIo COCQNO II 710 23.7.3 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 .11 Resumen 720 Referencios 721 Ptoblemos y puna Q consideror 72 , Otros lecturos y fuentes de inlormoci6n 722

24 .1 Conceplos b6slcos 725 24 .2 Calendorizoc:iOO de P'oyecto 727

24.2.1 Principios b6~ 728 24.2.2 Rebci6n entre eI p8f~1 Y eI esluerzo 729 24,2.3 Distriboci6n M esfuerzo 732

24.3 Definici6n de un conjunlo de !oreos poro eI provectO de x:Jtware 732 24.3.1 Ejemplo de conjunlo de Icm~as 733 24.3.2 Refinamie/llo de los lareos ptincipales 734

24..4 Definlci6n de una red de Ioreas 735 24.5 Colendaritoci6n 736

24.5.1 Cranagramos 738 24.5 .2 Seguimienlo de 10 caIenOOri.toci6n 739 24.5.3 Seguimienlo del progreso en un proyecIO 00 741

24.6 An61i$i$ del YQJa, gonoda 742 24.7 Resumen 744

CONTINIDO -

Referential" 744 Problemas y pontes 0 coosideror 744 c:>h-as Ieduros y Iuer1Ies de informoci60 746

GlESim DEL RIESGO 747 25.1 Utrotegios de rie$go reodillOS y prooctivos 7418 25 ,2 Riesg05 del $Ohware 749 25.3 Idenrificoci6n de riesgo$ 750

25.3.1 EvoIuoci6n del riesgo global del proyedo 752 25.3.2 Componenles y cooIrolOOores del riesgO 753

25,4 Pf~i6n del riesgo 754 25.4 .1 Desarrollo de uno labia de ~ 755 25.4.2 E...aIuoci6n del impoclO del riesgo 757

25.5 Relinomlenlo del ri&sgo 759 25.6 Redl.lCc;oo, wpervisi6n y ges~6n del rie:.go 759 25.7 EI pion RSGR: 763 25 .8 Resumen 764 Referencias 764 ProbIemos y punlO$ a coosideror 765 OIros Iecturos y ~ de inb~ 765 CAPtnn.o 26 Gii!Si16N DE IA CA1lDAD 767 26.1 ~clecolidod 768

26.1.1 Ca

-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 GiiSlt6N DEL CAMBtO 196 27.1 GesIi6n de 10 configvraci6n del KItwore 197

27.1.1 Un e~enorio de GCS 798 27.1. 2 Elementos de un sistema de geJti6n de 10 configuroci6n 79Q 27. 1.3 I.ioeos be", 800 27.1 .4 EIemet1Io5 de con~guroci6n del sof!wore 801

27.2 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

27.3 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 eon.oI del combio 810 27.3.4 Audib'1o de 10 conIiguroci6n 813 27,3 .5 Infofmedeeslodo 814

27.4 Gesti6n de 10 conhguraci6n poro ingenierio VVeb 815 27.4.1 Problemos en 10 gesti6n de 10 configulOd6n poro WebApps 815 27.4.2 Objelos de configuroci6n ~ 817 27.4 .3 Gesti6ncielconlenido 817 27.4 .4 Gmti6n del combio 820 27 A .S Conkel de 10 versi6n 822

, 27.4.6 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 INGmNIER1A DEL SOFTWARE 129 c:.utrm.o 28 a.droDos FORM AI IS 330 28.1 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

2S.2 Preliminores moI8m6ticos S37 28 .2.1 CaljI.Wllos Y especificoci6n coruIIudMJ 837

28.2.2 28 .2.3 28 .2.4

Operodones de con(unlO$ 838 Operodores l6gioos 840 Sucesiones 84 I

28.3 ~icod6n de 10 IIOOd6n motem6Iico pora 10 especilicoci6n formal 842 28.4 lenguo)es bmoles de especificoc!6fl 844 28.5 lengooie reslring~ 0 objelO$ (OCl) 845

28.5.1 Un breve panoroma de 10 sintoxis y 10 sem6ntico del OCL 845 28.5.2 EjempIo de LISO del OCt 847

28.6 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 Resumen 954 Referenclos 855 Problemos y pvnIos 0 COI"I$ideror 855 Otros lecMos y fuentes de inlormoci6n 856

cAPfnn.o 29 INGIENIERIA. DEL SOfTWARE DE SALA UJDIA 858 29.1 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

29.2 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

29.3 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 871

29.4 Pruebos de solo Ilmpio 872 29.4 .1 29.4.2

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 DfCDNIERfA. DEL SOFTWARE BAS.ADA EN COMPONEN1'ES 879 30.1 Ingenierio de $islefnos bcuodo en componentes 8BO 30.2 EI pnxe3(l de Isse 882 30.3 Ingenierio del dominic 883

30.3.1 EI ptOCe$O de on61isis del dominio 883 30.3.2 FlJnciones de caraderizoci6n 884 30.3.3 !V'odeIodo eslrucl\trol y punlos de estrucllJfO 885

30.4 Clesorrollo basoda en COfnponet'lles 886

....

30.4 .1 30.4.2

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

30.4 .3 An6lisi$ y d iseiio poro 10 reutiliZDci6tl 891 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 EI enIomo de reutilizo06n 894

30.6 Economic de Ia lS8C 895 30.6. 1 ImpacIo me 10 coIidod, 10 productMdod y eI com SQ6 30.6.2 An6lisis de coskl empleondo fJU'1D5 de estruduro 897

3D] 1I:8SUIlIef1 898 Refefencios 89Q Problemas y ponlos 0 coosideror QQO Otros leduras y fventes de inlormoci6n 90 \

CAPtnn.o 31 31 . 1 Reingenierio de procesos de negocio 903

3 1 1. 1 Procesos de negocios 904 3 1.1 .2 Un II'lOdt.Io de RPN 904

31 .2 I/:eingenlerlo del ~e 906 H7 :) 31. 2. 1 MlnIenimienlo dehd'woll~ 907 31 .2.2 Un modeIo de procexlIS de felngenierio del softwofe 908

31.3 Ingeoierio il'M!lnO 912 31 .3. 1 Ingenierio inYefso pora cornpIender 10$ dolos 913 31 .3.2 Ingeniefio inYerso p::uo compender eI ~Ienb 9\ 4 31.3.3 Ingenierio irMwso de inIerfaces de I..I$UCIrlo 9 15

31.4 Rl!IMInJduroci6n 916 31.4. 1 Rees/fuduroci6ndelc6digO 9\7 J 1.4 .2

3 1 .5 Ingenie60 diredo 91 8 3 \ .5 .1 Ingenieria diredo para aquileduros dlente/seMdor 920 31 .5.2 Ingenierio direclo pora orquil8cluros Ofienlodos 0 objeIos 921 31 .5.3 Ingeniedo dir6Cto de inleffoces de uwc:nio 922

31 ,6 La economic de 10 reingenierio 923 31.7 Rewmen 923 Referencios 924

Pr~5 y ponies a considerar 925 OIfoslecrufos y Iveoles de inlormaci6n 926 CAPtruLo 32 D. CAJr.IINO POll ppcopprp 927 32 .1 La importondo del soItwore. Segundo porte 928 32.2 EI6mbito del combio 929 32.3 los personas y Ie forma en Ie que consInJyen sistemas 930 32.4 EI "ntJf!YO" prOCMO de ingenieria del softwore 931 32.5 N\JI!IY05 mor:Ios de represenlcr 10 inlormoc::i6n 933 32 .6 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

CoNcEPTos ct.AVE _ ....

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

-.............

--....... .

-...

.. Mftw.e ..... S

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

.......... 12

.............. 1 __ ...... .. .14

..tu ........ 11

-.......... .. .11

,-"'"""""" y 10

SOFTWARE E INGENIERiA DEL SOFTWARE

CAPiTULO

E s comun darse cuenta que la invenci6n de una tecnologfa puede tener efectos profundos e inesperados en otras tecnologias con las que en apa-riencia no tiene ninguna relati6n, como en empresas comerciales. en per-sonas y aun en la cullura en su conjunto. Este fen6meno a menudo se

2

~VI B dIwtnIes .:U.1 _ ..... m klpIIII" ....

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 compu-ladora 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

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 paten-cia de c6mputo presentada como hardware de una computadora 0, de manera mas amplia, por una red de computadoras accesible mediante hardware local. Sin impor-tar el lugar en que resida el software, ya sea en un celular 0 dentro de una compu-ladora central, este es un transformador de informaci6n; realiza la praducci6n, el maneto, la adquisici6n, la modificad6n, el despliegue 0 la transmlsi6n de la informa-ci6n que puede ser tan simple como un solo bit 0 tan compleja como una presenta-ci6n multimedia. En su papel de vehlculo para la entrega de un producto, el softwa-re actua como la base para el control de la compuladora (sistemas operativos) , Ja co-municaci6n de informaci6n (redes), y la creaci6n y el control de olras programas (utilerfas de software y ambientes) .

~IIIIIIO_ i" ....... ,.. _.omdsdt.,. .~ddsims. .... 1IiIImI .. ............

-""., upeI' .1Drm .. .b .... oMnlDsy ........ C ..... Jr Iuntirt ,m., ..... .-"fu. ... til /os sistemas .. Sf CMSIrt.oyJrtI,

3

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 in-formaci6n de negocios para mejorar la competitividad; proporciona una via para las redes de informacl6n alrededor del mundo (Internet) y proporciona los m edios 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 varie-dad 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 softwa-re y su impacto en la cultura. OSborne [05B79] describi6 una "nueva RevoluciOn In-dustrial", Tomer [TOF8O]lIam6 al surgimiento de la microelectr6nlca parte de "la ter-cera 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", Fei-genbaum y MCCOrduc\( [FEI83] sugirieron que la informaci6n y el conocimiento (con-trolados 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 po-der'" en el que todas las viejas estructuras (gUbernamentales, educativas, industria-les, 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 cal-da del programador estadounidense", Hammer y Champy [HAM93) argumentaban que las tecnologlas de infprmaci6n representarian un papel primordial en la "reingenie-ria de la corporaci6n", A mediados de la decada de 1990 la penetraci6n de las compu-tadoras 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 en-fatlzar inquietudes Jegltimas, pero ignorando los grandes beneficios que ya se hablan obtenido (LEV95],

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 progra-mador 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"

~VI Oscitwe 58 desooato, no ..........

CAPlnn.o 1 SOFTWARE., INGENlERlA. DEL SOf'TWARE

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

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

5

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 con-ducicto a 1a adopci6n de 1a practica de la ingenlerla del software.

En 1970, menos del uno por deRla de las personas podrlan haber deflnido 10 que sig-nlficaba "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 ejecutar-51! proporcionan las caracterisdcas, jimdones y eJ grado de desempdlo deseodos; 2) las estructuras de datos que permiten que los programas manipulen inJonnaci6n de mane-ra adecuada; y 3) los documentos que describen la operad6n y el uso de los progmmas. No existe duda de que se pueden encontrar deflniclones mas completas. Pero se re-qulere 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 huma-no. El software es un eiemento 16gico, en lugar de fisico, de un sistema. Por 10 tan-to, el software tiene caractertstlcas muy diferentes a las del hardware:

I . El software 51! desarrolla 0 constnry'e; no se manu Jactura en e/ sentido c1dsico. A pesar de que existen similitudes entre el desarrollo del software y Ja manu-factura del hardware, las dos actividades son diferentes en 10 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 fun-cl6n del tlempo. La relacl6n, Ilamada a menudo U curva de la banera", indica

6

flan-S. Si SI desea reda tI -""'-, lIS naSoriI Uzt. "' .... _r,.

"'~m

~VI "" ....... ~ _dO ..... , .-.... .

,.,.fu! do .. ,." V 10 pendionte de 10 am ..... SI

..-"'~ "'" 1.2.

j ..

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 (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, las temperaturas extremas y muchas atres males amblentales. Expresado en forma mas simple, el hardware comienza a desgastarse.

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 for-ma 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 pro-grama. 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 im-plicaciOn es dara: el software no se desgasta, pero 51 se det.eriora.

Esta contradicci6n aparente se puede explicar de mejor manera si se consi-dera 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 errores, 10 que ocasiona que la curva de fallas tenga un pico, como se mues-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, 10 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 .

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

-.

curva tenga alro picc. De esta manera, el nivel de (alias minima se comienza a elevar; el software se deteriora debido a los camblos.

7

otro aspecto del desgaste ilustra la diferencia entre el hardware y el soft-ware. Cuanda un componente del hardware se desgasta se sustituye con un repuesto. Pero en el software no existen repuestos. Cualquier falla del softwa-re implica un error en el disei'io 0 el proceso mediante el cual se pas6 del dise-no 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 compo-nentes, 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--e-n reaUdad son Innovadores e'n el dls:eno; es declr,.en las par-tes 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 venta-nas graficas, menus despJegables y una amplia variedad de mecanismos de

, interacci6n. Las estructuras de datos y los detalles de procesamiento requerl-dos para construir la interfaz estan contenldos en una IIbrerla de componen-tes 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 cIe....... 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 es-tructuras de informaci6n complejas pero detenninadas.4 Otras aplicaciones de siste-mas (por ejemplo, componentes del sistema operatlvo, controladores, software de red, procesadores para telecomunicadones) procesan datos Indeterminados. En ca-da caso, el area de software de sistemas se caracteriza por una interacci6n muy in-tensa con el hardware de la computadora; utilizaci6n por multiples usuarios; opera-ci6n concurrente que requlere la gesti6n de itinerarios, de comparticl6n de recursos, y de procesos sofistlcados; estructuras de datos complejas y multiples interfaces ex-temas.

SOftware de apHcad6n. E1 software de apllcacl6n conslste en programas inde-pendientes 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 opera-dones de negocios 0 la toma de decisiones tecnicas 0 de gesU6n. AdemAs del pro-cesamiento 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 transac-dones 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 aigoritmos ~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 ma-nufactura automatizada. Sin embargo, las aplicaciones modemas dentro del Area cientifica y de ingenieria se alejan en la actualidad de los algoritmos numericos con-vencionales. 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 microon-das) 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 pa-ra proporcionar una capaddad espedfica y la utilizad6n de muchos dientes diferen-tes, 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, apli-cadones 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 aplica-dones B2B adquieren mayor importancla, las WebApps evoludonan hacia ambientes computacionales sofisticados que no 5610 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 1 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 aplicacio-nes exislentes se comgen, adaptan y mejoran. Es cornun ver a un joven ingeniero de software que trabaja en programas m

Estamos entrando en una era caracterizada por las comunicaciones entre las maquinas dis-tribuidas y la genie dispersa, en lugar de 1a que define una conex\6n entre dos individuos 0 entre un Individuo y una maquina. El 3ntiguo enfoque de la teleronla se reliere a ~conexiones 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 BlackBe-me.

11

EI reto para los ingenieros de software es construlr aplicaclones que faclhten la comu-nicaci6n y la distribuci6n de productos en masa mediante pnxluctos apenas en forma-d6n.

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 sufi-cienle 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 aplica-ci6n, 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. Dayani-Fard 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 nego-cios 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 Nmuchos siste-mas heredados persisten como el soporte de las funciones centrales de negocios y son indispensables para las empresas" . Por 10 lanlo, al software heredado 10 carac-terizan su longevidad y el ser cntico para los negocios

12

,eM" .... 1M 100"",

M .....

softW.'._ (011 poco mIi-

-

tipas de mmbios '" M ,HlJ 1 If IOftwar. ....... 1

,._wo. e ...... _,.

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

""",~.

1.4.1 Colidad del software heredado 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, ca-sos de prueba y resultados que nunea fueron archivados, un historial de cambio ma-nejado con pobreza, etcetera; la !ista podrta seguir hasta tener una longitud consi-derable. 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 sis-tema heredada experimente alglln cambia significativa. Perc si salisface las necesi-dades 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 am-bientes a las nuevas tecnalogias de c6mputa.

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.

Cuando suceden estas fonnas de evoluci6n en un software heredado, este debe so-meterse a una reingenieria (capitulo 3 1) de modo que conserve su viabilidad en el futuro. La meta de la ingenieria de software moderna es Nimaginar metodologlas que se basen en la noci6n de la evaluci6nN; esto es, la noci6n de que Nlos sistemas de software cambian de manera continua, los nuevas sistemas de software se constru-yen a partir de los viejos, y ... todos deben interaCluar y cooperar can los demasN 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 soli-clta caraeteristicas 0 funciones nuevas, y cuando la aplicaci6n experimenta una rein-genieria 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 softwa-re, 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

,"''' '" ... -, , s

cAPhtn.o I !OfTWARE E INGENlERfA DEl. SOFTWARE

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 he-redado 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

13

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 de-sarrollar 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 eleclr6nic07 deben adaplarse en forma continua, de 10 contrario se volveran menos satisfactorios a tra-ves del tiempo.

La ley de la compleJldad creclente (1974) . Cuando un sistema de tipo elec-tr6nico esta en evoluci6n, su complejidad se incrementa a menos que se realice el trabajo necesario para mantenerla 0 reducirla.

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 no varia a 10 largo del periodo de vida del producto.

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 ere-d miento excesivo disminuye ese dominio. Por tanio, el credmienlo promedio per-maneee 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 sa-tisfacci6n 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

6 Para una clara explkad6n de la evolucl6n del software. elleaor interesado puede revisar {L.EHl)7al 7 Los sistemas de flpo ekctrOnk:o son programas de software que han sido implementados en un con

texto computacional del mundo real y que, por tanto. evoluclonaran a trav~5 del tiempo

14

D"""UIII~y *SfIIIIoI_lkIio. lIpadmrtlt. - . ..--

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 signifi-cativas 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 10 sucesivo, en este texto se discutirtm mo-delos 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 mi-tos parecen una relaci6n de hechos razonables (algunas veces contienen elementos verdaderos), se observan de manera intuitiva, y con frecuencia los promulgan prac-ticantes experimentados, quienes ~conocen eJ terrenoH

"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 adrnlnlstrad6n , Los administradores con responsabilidades sobre el sonware, al igual que sus pares en la mayorla de las disciplinas, a menudo estan ba-jo presi6n por mantener los presupuestos, evitar que los itinerarios se extiendan y mejorar la calidad. De la misma forma que una persona a punta de ahogarse se afe-rra 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 canocimien-ta 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? ,Es-ta completo? ,Es adaptable? ,Esta dirigido al mejoramiento del tiem-

- ..........

... ,..-

...... lrutlt' CDI*IlIr, en .-s no IS JJMi .. - ... -1iIIIIIs. PfIO fIfI" ."srSIIJIII,/III" _ 'SII fifsgo /PI Sf

-

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 programado-res 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 manu-factura. En palabras de Brooks (BR07S): HAgregar gente a un proyec-to de software atrasado 10 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 de-be invertir tiempo en la ensenanza a los rech~n lIegados, 10 cual redu-ce el tiempo dedicado al esfuerzo para el desarrollo productiv~. Sc puede agregar gente, pero 5610 de una manera planeada y bien coor-dinada,

Mito: Sf decido 5ubcontmtar eI proyecro de sojhNare a un tercero, puedo rela-janne y dejar que esa compania 10 construya.

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

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 departa-mento de ventas a de mercadolecnia, 0 una compania exlema que ha solicitado el software bajo contralo. En muchos casos, el cliente cree en mitos acerca del softwa-re porque los profesionales y administradores del software hacen muy poco para co-rregir 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 es-cribir progmmas; los detaUes se pueden afinar desputs.

Realidad: A pesar de que no siempre es factible que el enunciado de los reque-rimientos 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 de-sarrollan 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 im-pacta del cambia varia de acuerdo con el momento en que este se in-troduce. Cuando los cambios en los requerimientos se solicitan en

16

Siem{n ~ Sf (lien-Sf ~ 00 Ir7y Iiefr90 pall lJ iIgeiioi1 dol sohwutt, Sf debe coosidtta si hot.6 ..... "'" I." .. IDdo de 1IIAIM1.

CAPinn.o I SOf'T\I{ARE E INGENlERlA DEL SOFTWARE

etapas tempranas (antes de iniciar con el disefio 0 el c6digo), el im-pacta en el costo es relativamente pequeno.' Sin embargo, conforrne pasa el tiempo, eJ impacto en el costo crece con rapidez -se han dis-tribuido [os recursos, se ha establecido un marco general para eJ dise-flo- y el cambia puede provocar una convulsi6n que requiera recur-50S 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. Du-rante 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 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 siste-ma 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 .

Realidad: Uno de los mecanismos mas efectivos para el aseguramiento de la ea-lidad del software se puede apliear desde el inicio de un proyeclO: la revisi6n tecniea formal. Las revisiones al software (descritas en el capi-tulo 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 pro-porciona un fundamento para [a ingenieria exitosa y, aun mas impor-tante, representa una gu[a para el mantenimiento del software.

Wto: La ingenierfa del so.fi'Nare obJigard a emprender /a creaci6n de una docu-mentaci6n 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 documen-los. 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

17

conduce a 1a reduccl6n de los trabajos redundantes. Y una menor can-tidad 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 me-jor enfoque. El reconocimiento de las realidades del soll.ware es el primer paso ha-cia 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 necesi-dad 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 pro-ductos 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_,. I 'I

__ M!"':'~:'::::;::=; po .... ~-

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

.... o .... grN ~ ... -.... ~

5 r ._11 ..... " Oil. cit nwsIro

.....

.... (Ii.... .'171 Jr lidad cIt.-a __ ....

a ......

""" Joe: .......... _"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 impor-tanles 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 informaci6n, hasta convertirse en una industria par sl mismo. Todavia se lienen pro-blemas 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 tecno-logias 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 in-tenci6n de la ingenieria del software es proporcionar un marco general para cons-truir 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.context-

mag.com/. [UU98] Liu, K. et al., "Report on the First SEBPC Workshop on Legacy Systems, Durham Uni-

versity, 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 of the 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 conse-cuencias 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 mdi-car 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 Debtltan-se con los companeros de clase.

t .4. ,La 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 usua-rio 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 docu-mento de una cuartilla que describa la tecnologla y los retos que representa para los ingenieros de software.

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 cempu-ladora 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 dis-cute 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 Kauf-mann, 2000) sugieren que el impacto extendido de las PC dismlnuira conforme los inslIumen-tos de informaci6n y \a computaci6n omnipresente conecten a lodos en el mundo industriallzado y casi cualquier HaparatoH que 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 modernaH de las impurezas del software se puede eliminar y sugiere fonnas de iogrario. Compaine (Digi-tal Divide: Facing a Crisis or Creating a Myth, MIT Press, 2001) escribe que la "brechaM entre aque-lIos que tienen acceso a los recursos de informad6n (como la web) y los que no 10 tienen se es-ta 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 Us-Ia 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

EL PROCESO DEL SOFTWARE

En esta parte de Ingcnierfa del software: un enJOque practico se estudiara eJ proceso que proporciona un marco de trabajo para la practica de la ingenieria del software. En los capitu-los sigUientes se responden estas preguntas:

iQUe es un proceso de software?

CAPiTULO

EL PROCESO: UNA VISION GENERAL

CONCEPTOS CLAVE tM1Io1Jadu ........... 2t

En un fascinante hbro que ofrece la visi6n de un economista sobre el soft-ware y la ingenierfa del software, Howard Baetjer. Jr. IBAE98) comenta 50-bre el proceso del software: -lie twfft ... 21 .-

HI!,,"oc", ... 36 IMCM 29 ISO 9001: 2000 .38 ..... trakfe tit! ""Ise ..... 24 ""-

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 PSI' .......... 39

........

.. "..,. 42:

De hecho, la construcd6n del software de computadora es un proceso itera-tivo de aprendizaje. y el resultado, alga que Baetjer lIamaria ~el capital del soft-ware", es una malerializaci6n del conocimiento recolectado, depurado y orga-nizado conforme el proceso estuvo en ejecuci6n

22

.QuO .. 1 Cuando .. trnboja panI construir un producto 0 sistema_ porlonle seguir uno wje d. potOIS pre-deables: uno &specie de mapa de OCt-rreMro$ que ayude a creer \.WI ,...

de alta colidad yo tiempo. EI mapad. ........ a. que debe ~uirMl MI tIoma ~ de ~.

lQuien 10 hoc.? los ingeniercs de soItwa.w y SUS tefes odoplan eI proceso a !.US~ despues 10 siSuerJ. Aciem6s, 1a gente que ho licitodo el software liene uno nmo6n qW sempenar en el proceso de defimlo. COMtrvIrlo y pmbado

LPor que .$ importante? Porque ob.ce ..... bilidod, control y orgonizoci6n 0 UfMI ocom.lod que puede voIverMl coOtieo SI no .. conRIa embargo, un enfoqve de ingenieno cW soItww. modemo debe MIl' "6gil". Debe ,..,.., aquella! octividodes contl'oMs y doc:un. ...... '"'' ~ porn eI oqu;po doI_ producto que ho de producirse

,-_Ioo-,E.doooIo, ~_que adap. del soItwore que 58 esl6 cons-~. lM_ puedo .... ~ porn a.' ..... ~ po-a tI'I Sistema de Oeronoutica, miIntiaI que \.WI Pf'CX*O distinto par ~ serio .......... pcwa Ia Cf1ICJCi6n de un sitio Web.

,Cu6I .... prallucto obteniclo? Desde el punto 0. vWo del u'geniero de wHware, los ~ obt.ntdot son 10$ programas, docu-

y datos que .. producen como (oose" ""~"' de lot odividode, y tareas definida, .-

,-.. .... _...-deq ... 10 he .... _.w . ,,,,? Existen muchos meea-

.~ doI_ de soItwo .. q ... '!"'~~ Q 1m organ 'zociones determiner Ie "ma-

doI_ de -.. No ob .... Ie, 10 oI"""""...,."ndo, 10 viobilidod 0 10"" ~-doI: ...,.Mto quo .. con..",.. "'" 10. mojo-~ "'Iea"", .. de Ia eficocio del proceso que 58

1rI-'twor.?

CAPiTuLo 2 EL PROCESO UNA VISION GENERAL 23

Pera, (que es can exactitud un proceso de software desde un punta de vista tec-nico? 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 softwa-re 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 madu-ro 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 funda-mental 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 eficien-te en maquinas reales.

casi cualquier lector se sentira tentado a sumar otras ideas a esta definici6n. Dice pa-co sobre los aspectos tecnicos de \a caUdad del software; no se refiere de manera di-recta a la necesidad de satisfacer aJ cJiente 0 aJ tiempo de entrega de un producto; ami-te 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\ desa-rrollo 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" dife-rentes? 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 enfoque sistematico, dlsclpllnado y cuanti -flcable al desarrollo, operaci6n y mantenimiento del software; es decir, la aplicaci6n de ta Ingenierfa al software. 2) El estUdlO de enfoques como en I).

Y aun asI, 10 que es ~sistematjco, disciplinado" y "cuantificable" para un equipo de soft-ware, puede ser gravoso para otro. Se requiere de disciplina, perc tambien de adap-tabilidad y agilidad.

2.

Estratos de Ia Ingenleria de software.

~ ~~ C&VE

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

IIIXeso, miIodos y

-.

o

PARTE UNO n PROCESO DEl. SOf'TWARE

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 softwa-re) 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-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 in-genierfa del software es el elemento que mantiene juntos los estratos de la tecnolo-sla 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 con-texto en eI cual se aplican los metodos tecnicos, se generan los productos del traba-jO (modelos, documentos, datos, reportes, fonnatos, etcetera). se establecen los fun-damentos, se asegura la caUdad, y el cambio 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 soft-ware se basan en un conjunto de principlos basicos que gobleman cada area de la tee-nologla e incluye actividades de model ado y otras tecnicas descriptivas.

Las herramienftJs de la ingenieria del software proporcionan el soporte automati-zado 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.

'f~' _ _ ,'0,

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

Un maroa de trabajo del ....-

dllsoftwme.

cAPiTuLo 2 Il. moctSO: UNA ~N GENERAL 25

Proceso del software

Marco de trobajo del proceso Actividodes sombrillo I

AClividod del morco de troboio # 1 occi6n de 10 ing8flieria de software 111 .1

_. d.I"obojo Conjunto producto. d-' Irobojo de lareos punlos de o~vromienlo 0.10 colictod

~d.~

occi6n de 10 iogenierio de sohwore III .10:. _. d.! lfoboio

Conjunlo prodldoo del Irobopo pumoo 0. o"Y""""_ delar80s do """'" ~d.p"~

I Adividod del morco de troboio #n

occi6n de 10 ingenierla del software #n. l lOtIO. d.llfobopo

Conjunto podudoo dill II'obop de Ioreos puntoo d. o-eufOl"lelllo 0.1a coIidod

M1~ 0.1 proyoedo

occi6n de 10 inge:nierio de sohware IIn.m _ .w Irabojo

Conjvnto produoos d.llrObojo de toreos po,IMoII de o~ ...... 1Q de Ia colidod

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

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 relacio-nadas 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 ac-ci6n .

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

26

,CHIn ..... -

",_oW ..

27

~ ff>. C&VE

quisitos) . EI diseflo abarca tareas de tTabaja (diseno de datos, diseflo arquitect6ni-co, diseflo de interfaz y diseno al nivel de componentes) que crean un modele de di-seno (una especificaci6n de diseiiO) . .)

----.....-s.blQS. I_cit .....

",~_do _anbese., ........ yenlos _dol

-

Como tambil~:n se aprecia en la figura 2.2, cada acci6n de la ingenierla del softwa-re [a representa un gran numero de direrentes conjunlos de lareas: una serie de ta-reas de tTabaja, productos relacionados, puntas para el aseguramiento de la calidad y fundamentos de proyecto dentro de la ingenieria del sonware. EI conjunto de la-reas que mejor se ajuste a las necesidades del proyecto y a las caracteristicas del equi-po es el que se escoge a1 final. Esto implica que una acci6n de la ingenieria del soft-ware (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.

!'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:

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:

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 .-.idado. .

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 dienle